- Gurulunk, WAZE?!
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Argos: Szeretem az ecetfát
- sziku69: Szólánc.
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
-
LOGOUT
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
rednifegnar
senior tag
válasz
daninet #23606 üzenetére
ja hat egy rendes borda sokat tud ezen segiteni, de van tobb ismim akik regebbi felesleges okostelot hasznalnak webkameranak ilyen celra.
nekem pinyoban van a nyomtato ott is jol jonne ilyen tavfigyeles, de viszonylag keveset nyomtatok igy annyira nem kell hogy tegyek is erte -
JulianSinulf
őstag
válasz
daninet #23606 üzenetére
A Prusa 3Dbuddy kamerája 10-15 másodpercenként küldi a képet.
Valami ilyesmit esetleg beleprogramozhatsz.
A másik megoldás, hogy csak akkor kapcsolod be a stream-et, amikor nézni akaraod.Nekem a másik fajta ESP-Cam modulom van, amin van SD kártya foglalat és még régi mini(micro?) USB csati van rajta. Megtáplálni szigorúan erős forrásról kell, mert a gép 500mA-e nem sokáig viszi el. Ezen is melegszik a kamera rendesen, bár azért fogdosható.
Jobb képet ad, mint a pusa kamerája, úgyhogy gondolkodom ennek a felszerelésén, illetve van ebből kettő, ami a 350-es ágyat jobban átláthatóvá tenné. De egyelőre nem sürget a dolog. Jó a nyomtató, nem nagyon kell félnem, hogy feljönne a tárgy az asztalról.A lényeg, amit ki akartam hozni, hogy az ESP-n lévő szoftver létrehoz egy weboldalt, amire IP cím alapján rácsatlakozhatok böngészőből. Itt indíthatom, leállíthatom a stream-et, így a kamera kímélve van, amikor nem használom. Vannak egyéb beállítási lehetőségek is, mint fényerő, felbontás, stb.
Már kísérleteztem azzal is, hogy a vezérlő elemek nélkül, csak a képet beépítem egy egyszerű html-be. Ez is megoldható, így 1 oldalra akár több kamera képe is kirakható. Mondjuk ilyenkor egy stop stream parancsos gomb lehet, hogy nem árt.
De arra is van lehetőség, hogy a képet a vezérlőgombokkal együtt betegye az oldalra. Ebbe már nem mentem bele.
Az ESP-n futó kód valami alap cucc a netről vagy az arduino-ból, miután hozzáadtam a library-t. De az is lehet, hogy eleve az ESP-n volt. Már egy ideje megvan, nem emlékszem pontosan.
A html kódos részhez segítségül hívtam a chatgpt-t, de a pontos parancsért az ESP-n futó weboldal forrását is nézegetnem kellett, hogy tényleg működjön. -
daninet
veterán
válasz
daninet #23603 üzenetére
mire leírtam megtaláltam. Lényegében arról van szó, hogy babi néni átbacott a kakassal
Az OV5640-ben egy olyan fesz stabilizátor van ami 1.8V-ot vár. Mivel 3.3V-ot kap az ESP-től elfűti a maradékot és 80 fokig melegszik.
Vagy meg kell oldani a külső 2.8V betáplálást (fogalmam sincs egy ilyen integrált lapon ez hogy működik), vagy csak fotókat szabad vele csinálni, streamelni nem szabad. -
ViZion
félisten
válasz
daninet #23440 üzenetére
Nem csak azokat érinti, még a régebbi Wemosoknál is sok leírásban ott volt, hogy a wifi powert nem szabad maxra tolni, mert hibát okozhat. Voltak nem ajánlott típusok abból is.
Egyelőre én ezekkel nem tapasztaltam a problémát, de majd este ránézek, h milyeneket vettem, lehet ott más a design. -
JulianSinulf
őstag
válasz
daninet #22631 üzenetére
Szia!
Anno foglalkozgattam a témával.
Ez eleve nem olyan pontos, kell neki egy szoftveres korrekció is, akkor pontosabb lesz.
Az 5V vs. 3V3 még torzít is, ott eleve be kell állítani egy korrekciót a feszültségosztó miatt.
És az ESP ADC-je sem olyan jó, az arduinoké jobb.
A fogyasztás méréséhez a feszültséget is mérni kellene, ami egy plusz áramkör lenne.
Inkább vettem pár Sonoff S60TPF konnektort. Ez is ESP-s de nem nekem kellett bíbelődnöm vele.
A szórás az ilyen mérőknél meg akkora, hogy egyikkel sem akarok tizedwattokat mérni. Sőt, még 10W léptékben is pontatlanok egymáshoz képest. A terheléssel a különbség meg csak nő.Nálad a programban most az van, hogy megméred a szenzor osztott feszültségét, amiből kivonsz 2,5-öt, majd megszorzod tízzel.
0A terhelés esetén a modul kimenetén 2,5V-nak kellene lennie. A feszültségosztó miatt ez eltolódik, így nem számolhatsz 2,5-tel. Vagyis az ACS_Offset értéke hibás.
1,667V körül kellene lennie az A0 lábon terheletlenül, ha a modul kimenetén 2,5V van és tényleg 1k(felső a rajzon) és 2k(alsó a rajzon) az osztóellenállások értéke.
Ha a modul kimenetén 5V van, akkor az A0 lábon 3,33333V-nak kellene megjelennie. Vagyis a VREF inkább 3,333V, nem 5V.
És szerintem az áram számításánál egy osztás kellene a zárójeles műveletek közé, nem szorzás. Nem légből kapom, hanem egy példaprogramot nézek.
És úgy jobban is közelít az 5W/230V izzó áramfelvételéhez az érték. -
JozsBiker
aktív tag
válasz
daninet #22631 üzenetére
Próbálkoztam régebben hasonlóval áramkörrel, de a részletek sajnos már nem maradtak meg. Az ACS712 nemtom ilyen szempontból hogyan áll, én ZMCT103C -vel szerettem volna megoldani, de kiderült hogy már a kapcsolástechnikájából következően nem lehet tőle várni számottevő pontosságot. A kimenetén ugye le kellene képeznie a bemenő jelalakot, nos a ZMCT103C erre nem volt képes maradéktalanul. Azt javasolnám hogy ha még nem tetted próbáld megnézni szkóppal a ACS712 kimenetét.
Az is fontos, hogy ha az Arduino program nem trueRMS -es csak ohmikus terheléssel próbálkozz ( izzós lámpa, régi forrasztópáka ), különben elvisz az erdőbe.Néhány hasznos link:
230Voltos készülékek fogyasztás mérése
Measure Any AC Current up to 30A with ACS712 and Arduino
AC Power Theory - Arduino Maths -
daninet
veterán
válasz
daninet #22530 üzenetére
Megoldódott
Természetesen a C3 kicsit más amit a doksi nem említ. Szóval ami a dokumentációban van azzal nem megy. A globális hold funkció nem elég, kell az adott pin hold funkciója is. Ha csak az van nem megy, kell a globális isAlant a megoldás:
Setup részbe ez kell:
gpio_hold_dis(static_cast<gpio_num_t>(mosfetPin));
gpio_deep_sleep_hold_dis();
Aztán a sleep funkció meg így néz ki:
gpio_deep_sleep_hold_en();
gpio_hold_en(static_cast<gpio_num_t>(mosfetPin));
esp_sleep_enable_timer_wakeup(sleepTime * 1000000);
esp_deep_sleep_start();
-
válasz
daninet #22526 üzenetére
Ha kellene lehúzó ellenállás akkor ébrenléti állapotban is kellene, nem?
Erre te is sejted a választ.
Az ilyen vezérlő kimenetekre eleve jobb külső fel- vagy lehúzó ellenállást tenni, mert boot közben bármi is történhet, nem jó, ha esélye van a lebegésre.
A 25. oldalt nézd meg (Strapping Pins)! Ahogy írtam, az esp-ken vannak dedikált pinek, amiknek funkciója van a boot során. A gpio2 is ilyen, válassz másik vezérlő pint. Lehet ha lehúzod azt a pint, be sem fog tudni bootolni. Ha ragaszkodsz ahhoz a pinhez, lehet meg kell fordítanod a logikát.
-
válasz
daninet #22508 üzenetére
Azt írja, nem ebben a sorrendben kell megadni a paramétereket! Hogy a példában miért így van, azt nem tudom, talán az idf automatikusan javítja.
A helyes sorrendet itt tudod megnézni: [link]typedef struct {
int gpio_num; /*!< the LEDC output gpio_num, if you want to use gpio16, gpio_num = 16 */
ledc_mode_t speed_mode; /*!< LEDC speed speed_mode, high-speed mode (only exists on esp32) or low-speed mode */
ledc_channel_t channel; /*!< LEDC channel (0 - LEDC_CHANNEL_MAX-1) */
ledc_intr_type_t intr_type; /*!< configure interrupt, Fade interrupt enable or Fade interrupt disable */
ledc_timer_t timer_sel; /*!< Select the timer source of channel (0 - LEDC_TIMER_MAX-1) */
uint32_t duty; /*!< LEDC channel duty, the range of duty setting is [0, (2**duty_resolution)] */
int hpoint; /*!< LEDC channel hpoint value, the range is [0, (2**duty_resolution)-1] */
struct {
unsigned int output_invert: 1;/*!< Enable (1) or disable (0) gpio output invert */
} flags; /*!< LEDC flags */
} ledc_channel_config_t;
/**
* @brief Configuration parameters of LEDC timer for ledc_timer_config function
*/
typedef struct {
ledc_mode_t speed_mode; /*!< LEDC speed speed_mode, high-speed mode (only exists on esp32) or low-speed mode */
ledc_timer_bit_t duty_resolution; /*!< LEDC channel duty resolution */
ledc_timer_t timer_num; /*!< The timer source of channel (0 - LEDC_TIMER_MAX-1) */
uint32_t freq_hz; /*!< LEDC timer frequency (Hz) */
ledc_clk_cfg_t clk_cfg; /*!< Configure LEDC source clock from ledc_clk_cfg_t.
Note that LEDC_USE_RC_FAST_CLK and LEDC_USE_XTAL_CLK are
non-timer-specific clock sources. You can not have one LEDC timer uses
RC_FAST_CLK as the clock source and have another LEDC timer uses XTAL_CLK
as its clock source. All chips except esp32 and esp32s2 do not have
timer-specific clock sources, which means clock source for all timers
must be the same one. */
bool deconfigure; /*!< Set this field to de-configure a LEDC timer which has been configured before
Note that it will not check whether the timer wants to be de-configured
is binded to any channel. Also, the timer has to be paused first before
it can be de-configured.
When this field is set, duty_resolution, freq_hz, clk_cfg fields are ignored. */
} ledc_timer_config_t; -
válasz
daninet #21173 üzenetére
Gpio0-t manuálisan (érts a vezetéket földhöz nyomom) lehúzom földre.
Miközben bedugod a gépbe az FTDI-t, a másik kezeddel földeled a GPIO0-t? Mert utána már hiába.
A flash egyébként nem csak a GPIO0 állapotától függ, a GPIO15-nek is alacsony szinten kell lenni, a GPIO2-nek pedig magasan (vagy ellenállással felhúzni, vagy ne legyen semmi rákötve).
[link]...
GPIO2: pin is high on BOOT, boot failure if pulled LOW
GPIO15: boot failure if pulled HIGH
...
GPIO1: pin is high at BOOT, boot failure if pulled LOWEzeket nézted már? Mivel áramkörben van, lehet, hogy ezekre kötve van valami gyárilag, ami bezavar.
Ez itt nem egy rövidzár?
-
válasz
daninet #21171 üzenetére
Milyen ESP8266 ez? A GPIO0 földre van húzva programozás előtt? Ezt az FTDI nem csinálja meg automatikusan, általában neked kell megtenni, vagy gombbal, vagy más módon.
Ha ez rendben van, akkor lehet, hogy a kábelt érdemes kicserélni és működni fog. Nemrég esp32cam modullal jártam így, hogy nem akarta a jót az egyik kábellel, aztán egy másikkal sikerült.
Ha végül egyik se működik, akkor igen, elég, ha csak a GND, TX, RX lábak össze vannak kötve, és nem kell ellenállás. -
válasz
daninet #21017 üzenetére
Az egész koncepció ott borul szerintem, hogy a vonalon a földhöz képest negatív feszültség is van (tkp váltakozó feszültség). Először is el kellene tolni az egészet pozitív irányba, egy műveleti erősítő segítségével, illetve egyenirányítani, majd egy nagyobb kondi segítségével integrálni/kisimítani a hullámzó feszültséget, hogy mérhetővé váljon.
Egy másik megközelítés lehetne, hogy megpróbálsz rajta frekvenciát mérni Fourier transzformációval, ha harmonikus frekvenciákat tudsz mérni a jelen, akkor zene szól, ha nem, akkor fehérzaj. De itt szintén offset-elni kell a jelet, hogy ne menjen a feszültség GND alá. Esetleg egy schottky dióda sorba kötve megoldja, azon kisebb feszültség esik, de inkább opamp-ot használnék.
A mérésnél lehet csalni esetleg, ha popzenéről van szó, általában 440Hz-re vannak hangolva a hangszerek, a temperált skála frekvenciáit érdemes keresni direktben. -
Janos250
őstag
válasz
daninet #19126 üzenetére
Először tanulja meg példákon a html-t, mert ha nekiáll html előismeretek nélkül AJAX-ot tanulni, úgy elhajítja, hogy az életben többet elő sem veszi.
Nekem már volt némi html ismeretem, amikor AJAX-ot kellett használni, de vagy tízszer kérdeztem itt a srácoktól.Maradjon egyelőre annál, hogy frissítéssel jön az új adat az oldalra.
-
Tankblock
aktív tag
válasz
daninet #19086 üzenetére
Szia
a vezérlőn az egy 555 Timer IC és véletlenül nem a poti helyét próbálod meg PWM ezni? Sajna a fotón nem látszik....A OUTPUT állítása után írjál rá ki a pinre 0 át.
Másik megoldás h felparaméterezed az egyik timert PWMre és elhagyod a jól megszokott arduinot és rendes C ben megírod....
-
Janos250
őstag
-
Tankblock
aktív tag
válasz
daninet #18060 üzenetére
Egyszerű mint az egyszeregy....
Ha egyfajta paraméter van akkor kétdimenziós tömb, ha sokféle akkor struktúrákat tartalmazó tömböt használsz. Az elején az állapotgépednek megfelelő paraméterekkel inicializálod.Majd kiolvasod a bemeneteidet ami kiválasztja az állapotgéped állapotát azaz a tömb 1 sorát.
Ezt használod a függvényeidhez mint paraméter.Remélem hogy érthető így :-)
-
válasz
daninet #18051 üzenetére
A nem okoz tüzet részhez azért szerényen állnék, de legalábbis nem versenyeztetném a 230VAC-val.
- 24VDC esetén ugyanarra a teljesítményre tízszeres áram szükséges. Ehhez jelentős keresztmetszet növelés kell(het) a veszteségek csökkentésére. Persze LED fényforrásból 100-200W már jelentős, ami még mindig 10A alatt lesz.
- De a tartós üzemi áram miatt a hibaáram elenyészővé válik. Például keletkezzen egy hibás kötés miatt egy zárlat, aminek 24Ohm az ellenállása. 24V esetén ez 1A zárlati áramot okoz, ami semmiség az üzemi 10A-hez képest, így a táp vígan dolgozik tovább, és 24W-al fűt a zárlatos pont. (A 10W-os USB-s pákám is elég a tűzgyújtáshoz).
Ugyanakkor ez a 24Ohm-os zárlat 240V esetén 10A, ami tízszerese az előbb feltételezett 240W-hoz számolható ~1A üzemi áramnak.
- A tartósan magas üzemi áram esetén nem csak a zárlat veszélyes, hanem az ívhiba is. Egy kilazult kötésnél a megnövekedő átmeneti ellenállás, adott esetben kontakthiba melegedéshez, ívképződéshez vezet úgy, hogy az áramfelvétel nem haladja meg a normális értéket. DC esetén az ívhiba különösen veszélyes, mert nincs nullátmenet, ami megszakítaná az ív fenntartását.Ezzel persze nem azt mondom, hogy rossz dolog a DC hálózat, de egyáltalán nem máz és hab, megvannak a hátrányai is, éppen ezért nem egy elterjedt dolog a mai napig sem.
-
Tankblock
aktív tag
válasz
daninet #18045 üzenetére
// init parameters
int aiParameters[3][5] = {
{1,2,3,4}, // switch state 1
{5,6,7,8}, // switch state 2
{9,10,11,12} // switch state 3
};
// Ha különbozők kellenek akkor marad a struct
struct myParameters {
bool isNoGood;
double dRandomValue;
int iIntegerMe;
};
myParameters myParam[] = {
{isNoGood = true, dRandomValue = 0.0, iIntegerMe = 1},
{isNoGood = false, dRandomValue = 0.1, iIntegerMe = 2},
{isNoGood = true, dRandomValue = 0.2, iIntegerMe = 3}
};
int giSwitctState = 0;
giSwitctState = ReadSwitch();
// itt hívódik 1x ami kell
funcPntr_set(aiParameters[giSwitctState][0],aiParameters[giSwitctState][1],aiParameters[giSwitctState][2],aiParameters[giSwitctState][3]);
//vagy itt
funcPntrMagic_set(myParam[giSwitctState].isNoGood);Na valami ilyenre gondoltam....
A sok ifből generált jumpok helyett egy sorfolytonos dolog lesz. Bővíteni nem nehéz, remélem átmegy a lényege. Esetenként nézd meg melyik mekkora kódot generál. If else megoldás és ez.... -
válasz
daninet #18051 üzenetére
Az enyém ragaszkodott hozzá, hogy minden ledcsík külön tápon legyen és a villanykapcsoló a tápot kapcsolja, nem a szalagot. Nálad ha gond van, egyszerre fog kimenni mindenütt a világítás.
A routerem mostanában sokat vacakol, lehet nálam is táp gond van? 🤔 Kösz a tippet! -
ViZion
félisten
válasz
daninet #18047 üzenetére
Nálam minap vetődött fel -csak elfelejtettem bárhol utánajárni
- hogy router + modem + switch + NAS + egyéb kis trafó van bedugva, nem lenne vajon hatékonyabb, ha PC tápról (az is ott van, molexről csak ki kell vezetni) kapna 12 V-ot, aminek az kell és step-down-al 5V-ot (táp 5V ága nem szokott erős lenni, de nem néztem alaposabban), aminek az kell?
Egy baCCot nagy elosztót nyernék vele, ami most ott van... de hatékonyságban melyik lenne a jobb?Valaki foglalkozott ilyesmivel?
-
-
Tankblock
aktív tag
válasz
daninet #18041 üzenetére
Szia,
nem az a lényeg hogy spóroltál-e, vagy sem.
A jó arhitechtúrának nem az a célja hogy spóroljunk.
Átlátható-e, és bővíthető-e más elemekkel ha szükséges később, pl 4 állapotra, vagy még egy változó kezelésével.
Ha előveszed 1 év múlva mennyi időt fogsz a kódod megértésével tölteni...
Itt jön elő az hogy milyen a kód minősége.
Nem állítottam hogy spórolsz vele, csak azt hogy olvashatóbb lenne.mint írtam csak próbálok segíteni.
-
Tankblock
aktív tag
válasz
daninet #18038 üzenetére
Ha csak 3 eshetőség lehetséges akkor nem látom értelmét az egész if else résznek.
Olvashatatlan.....Hozzáteszem szerintem egyszerűbb lenne ha egy tömbbe beletennél az egész változó kavalkádot és a pinek kilovasása után a tömb azon elemét címeznéd meg ahányadik.....
Majd az így kapott paraméterhalmazzal 1x megtetnéd ugyanazon fvnyeket.....nem lennének átláthatatlan feltételeid.....
Kapcsoló végett nézheted az állapotát csak 50 [ms]enként és probléma megoldva....Csak próbálok segíteni....
-
Undoroid
őstag
válasz
daninet #18008 üzenetére
Értem...sajnos az ok elhárításában segíteni nem tudok! Minden esetre elég érdekes!
* * *
Ha már itt járok, akkor kérdeznék is: szereztem egy W88-C szolár töltésvezérlőt (nagyon valószínű, hogy klón) ami úgy tűnik, hogy feladta a harcot. Nem volt füst! Megy is, de nem állítja meg az akku töltését, ha már elérte a beállított max értéket! A kijelzőn továbbra is a töltést jelzi és végre is hajtja! Ennek a központi egységét szeretném rendbe tenni! Nos, erről a vezérlőről nem találok semmit: UH3887 (esetleg VH3887) QSOT-tokos és 24lába van. LCD-kijelzőt hajt meg, a kezelő gombokat figyeli és a töltő FET-ek vezérlését is felügyeli! Amiért itt kérdeztem meg: a panelon van kialakítva egy olyan hely, amin keresztül programozni lehet a központi egységet! (összesen 4pólus, ebből kettő a belső tápfesz...) Ismeri valaki ezt a vezérlő IC-t?
-
Undoroid
őstag
válasz
daninet #18003 üzenetére
Szia!
" Ráadásul ha megy a serial monitor nem tudja bezárni és hibát dob kód feltöltésnél, eddig ez sem volt " Ez nálam akkor fordult elő, amikor rájöttem arra, hogy behalt az adatkábelem... vagyis akkor, amikor egy régen feltöltött kódot szerettem volna lecserélni az új adatkábelemmel, amiről végül kiderült, hogy kizárólag csak akkutöltésre való!
Feltöltéskor szépen elindult a program fordítása és ment volna át a vezérlőre, de az nem indult el, hanem hibával zárult! Röviden: cserélj adatkábelt és nagyon valószínű, hogy el fog múlni a problémád!
Egy gondolat: nem ez okozta a múltkori rotary-enkóderes anomáliát is?
-
And
veterán
válasz
daninet #17959 üzenetére
Képtalálatok: [link], itt tényleg csak az RC-tagok (a jelúttal soros R- ill. utána a 0V felé kötött C-tag) érdekesek. A konkrét értékük több tényező függvénye lehet, mint pl. a PWM frekvenciája, a szükséges időállandó (R*C érték) vagy épp a vezérelt áramkör bemeneti impedanciája. Ha a PWM frekvencia és a fogadó áramkör impedanciája kellően magas, akkor elég széles tartományból válogathatunk, de alapesetben néhány kΩ és pár µF megfelelő.
-
And
veterán
válasz
daninet #17957 üzenetére
Ehhez nem kell feltétlenül analóg kimenet. Egy kellően magas frekvenciásra állított PWM-kimenet és egy külső aluláteresztő / integráló szűrő (egyetlen RC-tag formájában) is megfelelő lehet. A kitöltési tényező változtatásával az RC-tag után egy változó DC-szintet kapsz. Ha a PWM-kimenet 5V-os, akkor 0..100% kitöltésre 0..5V DC-t kapsz.
-
-
-
biker
nagyúr
válasz
daninet #17872 üzenetére
az a baj, nem tudom mit csinálsz rosszul, sőt abban sem vagyok biztos, hogy rosszul működik, csak nem az elvárt eredményt kapod és az zavar, holott a jó működés van, csak mást szeretnél.
Én tucatszám rakok össze buttonboxokat, kormány vezérlő panelt (simhez) és sosem volt még gond rotaryval
de használtam saját terhelés megosztóhoz is rotaryt, na ott kicsit macerás volt, mert a megszakítások gondot okoztak, de végül jó lettA képen a legutóbbi rendszer, 2 arduni, 8 rotary, 28 nyomógomb + 4 rotary nyomógomb, LCD és RGB led kijelző
-
ekkold
Topikgazda
válasz
daninet #17868 üzenetére
Ha felhúzó ellenállással nézzük akkor egyetlen lépésre ezt kellene kapni:
11 (mindkét kontakt nyitva)
01 (egyik kontakt zár)
00 (másik kontakt is zár)
10 (első kontakt bont)
11 (második kontkt is bont)
A másik irányba forgatva, a 01 és az 10 állapot fordított sorrendben jön.A kis panelen ugye bekötötted a GND-t és a +Tápot is az arduino panelre?
-
-
ekkold
Topikgazda
válasz
daninet #17864 üzenetére
1, Valószínűleg fizikailag vagy nincs az enkóder panelján felhúzó ellenállás, vagy túl nagy értékű.
2, Mindenképpen kell felhúzó ellenállás (akár belső, akár külső) mert különben lebegni fog a bemenet és mindenféle zavart összeszed.
Felhúzó ellenállással valószínűleg azért nem működik amit írtam - mivel kicsi az esélye, hogy két különböző helyről, két különböző enkóder is hibás lenne. -
válasz
daninet #17864 üzenetére
Mindenféle kódot mellékelve, használj egy multimétert az enkóder kivizsgálására.
Adatlapja szerint vagy 10K ellenállást kell mérned a + pin irányba, vagy zárlatot a GND-re.
Nézd meg épp hogyan áll, és mozdíts egy ugrást rajta (gondolom diszkrét pozíciói vannak, 20 impulzus nem sok) majd nézd meg újra. Csak az egyiknek kellene változnia.
Ugyanitt elkövetheted azt is, hogy digitális pin helyett analógra kötöd, és az analóg értéket írod így ki sorosan, hogy lásd valóban analóg zaj van az enkóderen, vagy digitális. -
ekkold
Topikgazda
válasz
daninet #17860 üzenetére
A kapott adatokról: a programod soros portra küldi ki amit kap, viszont a soros portra írás ideje összemérhető (vagy akár hosszabb) mint az enkóder impulzus-ideje. Ezért össze kellene gyűjteni egy csomó adatot és egyben kiírni - vagy méginkább egy megfelelő programmal számlálni az enkóder lépéseit, és csak a számláló változása után kiírni az értékét.
-
ekkold
Topikgazda
válasz
daninet #17860 üzenetére
Minden mechanikus kapcsoló hajlamos egy olyan jelenségre amit "prellezésnek" hívnak. Fizikailag amikor az érintkezők összeérnek akkor rugalmasan torzulnak, majd az érintkező visszapattan, az áramkör megszakad majd újra összezáródik (akár többször is egymás után). Ez általában ezredmásodperces időtartományban zajlik (vagy akár 100usec tartományban). Emberi szempontból ez nagyon rövid idő, de digitális elektronikák szempontjából ez sok idő, simán észreveszi az áramkör és megpróbálja feldolgozni - ami alaphelyzetben hibás működéshez vezethet.
Két megoldási lehetőség van:
- Szoftveresen felkészülni a prellezés kezelésére - ahhoz hogy ez jól működjön nem lesz elég egy egyszerű kód. Persze megoldható teljesen jól is, csak az nem pár soros programrész lesz (készítettem már ilyet).
- A prellezés hardveres kezelése: a kontaktusokra kapcsolt felhúzó ellenállások után egy megfelelő időállandójú R-C szűrő is kell (ilyenkor a belső felhúzó ellenállást ki kell kapcsolni). Ez több alkatrészt igényel, viszont a szoftver viszonylag egyszerű maradhat.
Ha a programozás nem az erősséged, akkor a hardveres megoldás a könnyebb út, mivel az egyszerű áramkört igényel... Már én is elgondolkoztam rajta, hogy nekem is egyszerűbb lett volna hardveresen megoldani, mint szoftveresen, csak akkor már a hardver kész volt, így nem volt választásom. -
Undoroid
őstag
válasz
daninet #17836 üzenetére
Szia!
Csak halkan kérdezem meg: zsír új az enkóder?! Honnan kap tápot ez az egész masina? Nem lehetséges, hogy egy kapcsoló üzemű tápegység 'zaja' (f)okozza ezeket az anomáliákat?
Ha van lehetőséged, akkor próbáld meg szűrni közvetlenül az enkóder betápját egy 1000uF/10V elkóval és egy 100nF/50V-os kerámiakondival! Hátha csak ennyi a probléma...vagy -első körben- mehetne ugyanez a mikrovezérlő betápjára (is) Kezdő lévén sajnos más ötletem nincs! -
biker
nagyúr
válasz
daninet #17808 üzenetére
Aryes leírta, de a rotaryk lapján is ott a metódus, 0101 vagy 1010 a forgatás, plusz van félosztású rotary is.
Kell hozzá feldolgozás, hogy a bejövő 0101 az CW a kimenő és jó lesz
a néha visszaforgás jelaz meg olyan hiba ha félosztásba rakod és 0101 0101 0110 jön véletlen
és szimulátor kormányokhoz építek lapokat, azokon kitapasztaltam -
daninet
veterán
válasz
daninet #17805 üzenetére
kiírtam a két láb pulzusát, hogy lássam mi történik. Ha balra ha jobbra tekerem ez a kimenet:
Ez egy darab fordítás18:52:07.316 -> DT: 1 CLK: 1
18:52:07.349 -> DT: 1 CLK: 1
18:52:07.349 -> DT: 1 CLK: 1
18:52:07.384 -> DT: 1 CLK: 1
18:52:07.384 -> DT: 1 CLK: 1
18:52:07.417 -> DT: 1 CLK: 1
18:52:07.417 -> DT: 1 CLK: 1
18:52:07.451 -> DT: 1 CLK: 1
18:52:07.451 -> DT: 1 CLK: 0
18:52:07.485 -> DT: 0 CLK: 0
18:52:07.485 -> DT: 0 CLK: 0
18:52:07.520 -> DT: 0 CLK: 0
18:52:07.520 -> DT: 0 CLK: 0
18:52:07.553 -> DT: 0 CLK: 0
18:52:07.553 -> DT: 0 CLK: 0
18:52:07.587 -> DT: 0 CLK: 0
18:52:07.587 -> DT: 0 CLK: 0
18:52:07.620 -> DT: 0 CLK: 0
18:52:07.620 -> DT: 0 CLK: 0
18:52:07.655 -> DT: 0 CLK: 0
18:52:07.655 -> DT: 0 CLK: 1
18:52:07.688 -> DT: 1 CLK: 1
18:52:07.688 -> DT: 1 CLK: 1
18:52:07.721 -> DT: 1 CLK: 1
18:52:07.721 -> DT: 1 CLK: 1
18:52:07.754 -> DT: 1 CLK: 1
18:52:07.754 -> DT: 1 CLK: 1
-
Atamano
csendes tag
válasz
daninet #13687 üzenetére
Az Arduino az egy fejlesztő környezet. Ezzel a fejlesztő környezettel kompatibilisek az Arduino-t fejlesztő cég saját lapjai és ezek kínai klónjai.
A fejlesztő lapon található mikrokontrollerek pl atmega328p normál körülmények között 20 éves időtartamra számolva alacsony meghibásodási százalékot garantál a gyártója (Atmel).
Csak gondolj bele,hogy mennyi 20-30 éves 8 bites konzol muzsikál jól még manapság is.
Természetesen a várható élettartamot erősen befolyásolja a nyáklapon található egyéb alkatrészek száma,fajtája. Pl szerintem az elektrolit kondenzátorok hamarabb adják meg magukat.
Azonban leszögezném,hogy minden egyes kínai klón alapvetően egy nagy big black box,mert ezeket a költséghatékonyság jegyében állították elő.Tehát a legolcsóbb készleten lévő alkatrészekből. Amivel nincs is baj addig,amíg az ember csak led villogtatásra használja a lapokat.Ahhoz aztán tényleg csak annyi kell,hogy működjön.
Itt csak,akkor kezdődik a baj,amikor mindenre is ezeket akarjuk felhasználni.Az oke lenne,ha a prototípust tervező asztalon próbapanelon összerakjuk, teszteljük.Arra viszont felvonnom a szemöldökömet ,amikor egy uno nyáklap dupont csatlakozóit + egy rakat ragasztót felhasználva készülnek komoly feladatok kivitelezésére eszközök.
Ettől ne várjunk már megbízhatóságot,hosszú élettartamot meg minőséget. -
Dißnäëß
nagyúr
válasz
daninet #13687 üzenetére
Nemrég lettem kész egy picivel, erősítőbe standby gomb on/off implementáció, zajszűréssel (Examples -> Debounce) együtt, mivel az nyomógomb. (Görgess lentebb, megtalálod a nagy üdvrivalgásomat).
Eddig jó, sokat megy.
Cimbi geotermikus, napenergiás és mindenféle vegyes modern rendszert vezérel Pi-kkel meg egy raklap Arduino-val egy hotelnek és a teljes "rancsnak" (minden melléképület, uszoda, stb). Hőmérséklet, pára, mindenféle figyelések, szivattyúk, stb. komplett a teljes hóbelevanc vezérlése. Hibátlanok, betonstabil évek óta az egész. Fontos a jó táp, áramfelvételekre ügyelni, ha relék is vannak, + környezeti jellemzőkre, ha nem csak házon belül lesz 21 fokon, azért ezek alapjáraton nem durván Szibériába szánt kütyük. Ilyen alap dolgokat betartva teljesen megbízhatóak, elmondása szerint. Ahol kell, olyan dobozba tette őket, medence közelben, párás helyen, ilyesmiknél, de ez a már említett alapdolgok tartozéka, szóval ha gyári speckókon belül maradsz (bőven belül), elvileg hibátlan.
-
M@nH.
aktív tag
válasz
daninet #13679 üzenetére
Szia
Szintén kezdő vagyok, de ha jól értem valami ilyesmit szeretnél.bool buttonState = 0;
bool lastButtonState = 0;
void setup()
{
pinMode(2, INPUT);
pinMode(13, OUTPUT);
Serial.begin(9600);
}
void loop()
{
buttonState = digitalRead(2);
if (buttonState != lastButtonState)
{ if (buttonState == HIGH)
{
Serial.println("on");
}
else
{
Serial.println("off");
}
delay(5);
}
lastButtonState = buttonState;
}
-
válasz
daninet #13679 üzenetére
Állapotgép. Egy végtelen ciklusban minden alkalommal beolvasod a bemenet értékét. Kell egy változó, amit még a ciklus előtt deklarálsz, és amiben az előző állapotot tárolod. A beolvasás után összehasonlítod az aktuális állapotot az előző ciklusban elmentett állapottal, ha nem egyforma, akkor végrehajtod a feladatot, amit változáskor kell lefuttatni, felülírod az előző állapotot a mostanival és kész.
-
bacus
őstag
Valamit kerversz, mert az arduinora a kódot egyszer kell feltölteni (előtte megirni), utána az ha tápot kap, akkor csinálja amire programoztad.
Ennek az egész projektnek nem igen látom értelmét, mert itt a notebookról kell mindenképpen lejátszani, és azon kell fusson egy szoftver, ami átadja az adatokat az arduiononak.
Nekem inkább ez tetszik, ennek látom értelmét https://www.youtube.com/watch?v=tRDAzJrfZiM#t=287
Persze itt is van gond, mert ez ugyan teljesen egy raspi on fut, de ennek meg hdmi bemenet kell, azaz a normál tv még nem lesz ilyen ambilight rendszer, rtl klubot nem nézheti igy az ember...
Nem tudom, hogy a modern tv-k kinyomják e magukból scarton, vagy kompositon vagy akár hdmi-n a jelet (mert a régi tévék közül sok ment úgy, hogy a videoval a tv tunerjének a jelét vettem, az ugyanis jobb tuner volt, mint ami a videokban volt)
Új hozzászólás Aktív témák
Hirdetés
- MSI RTX 4070 SUPER 12GB GAMING X SLIM WHITE - 20 hónap garancia
- GIGABYTE RTX 4070 SUPER WINDFORCE OC 12GB - 20 hónap garancia
- iKing.Hu - Samsung S25 Ultra - Titanium Black - Használt, karcmentes
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Bomba ár! HP EliteBook 850 G2 - i5-5GEN I 8GB I 256GB SSD I 15,6" FULL HD I Cam I W10 I Gari!
- Lenovo LEGION Pro 5 / Pro 7, Lenovo Yoga Pro gépek (RTX 4060 / 4070 / 4080 / 4090)
- ASUS TUF Gaming F15 FX506 - 15.6"FHD IPS 144Hz - i5-11400H - 8GB - 512GB - RTX 3050 Ti - 1,5 év gari
- Csere-Beszámítás! Xbox One X 1TB Játékkonzol Olvass! Model 1787
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest