- Milyen videókártyát?
- Azonnali notebookos kérdések órája
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- AMD Navi Radeon™ RX 9xxx sorozat
- Projektor topic
- Milyen billentyűzetet vegyek?
- Nvidia GPU-k jövője - amit tudni vélünk
- Milyen egeret válasszak?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
-
PROHARDVER!
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
-
Szabad kérdezni, hogy ezek az értékek az LTC által teoretikusan kiadott értékek, vagy ezeket mérted?
Azért kérdezem, mert az értékek önmagukban nagy ugrásokat mutatnak, de a pontosságuk emellé túl nagy. LTC2630-ból ahogy néztem 12-10-8 bitesek vannak.
A legkisebb ugrás amit találtam az 28.3mV. Egy 12bites DAC 4.095V maximum érték mellett 1mV-ot tud léptetni. Neked fele a tartomány, így 0.5mV lépésekkel számolhatunk. De a lépések ennél is pontosabbak, kb. 0.1mV pontosságot kívánnának, ami inkább 14bit feladat.
Szóval a kérdés, hogy valóban szükséged van tízezred volt pontossággal ezekre az értékekre, vagy csak ezen körülbelüli értékeket lőtte be az LTC, de azért van +-0.5mV tűrésed?
Szerk.: Közben bekerült a pontos típus, ami egy 10bit-es DAC, kizárt, hogy ezeket a pontosságokat az generálta. Ha nekimész a feladatnak egy számodra jól elérhető 12bit-es DAC-al, biztos, hogy meg tudod közelíteni az értékeket, amire szükséged lesz. -
válasz
JulianSinulf #22278 üzenetére
Ha van ilyesmi kérdésed, gyere nyugodtan.
Beépített akksis cuccokhoz egyszer azt csináltam, hogy visszafejtettem egy olcsóbb powerbank áramkörét. Egy SO8 IC, egy induktivitás, egy dióda és pár ellenállás megoldja az 5VIN-ről töltését, és 5VOUT-ra boostolását a cellának.
Aztán pont nem lehetett többet kapni abból a powerbankból, úgyhogy kellett rendelnem az IC-ből, mert a PCB már köré lett tervezve. Azt hiszem 100 db volt a MOQ ahol még árulták. Azóta is abból élek -
válasz
JulianSinulf #22276 üzenetére
Szia!
Szerintem el kell itt férjen, bár a [Hobby elektronika] inkább profilba vág.
Köznyelven szólva ez LiPo akku.
Helyesen a LiPo is Li-ion, csak folyékony elektrolit helyett polimer anyag tölti be az elektrolit szerepet. A folyékony elektrolitos Li-ion cellák - amit általában Li-ion néven emlegetnek kemény "tégelyes" tartóban vannak.Ha LiPo cseredarabot keresel, úgy célszerű keresni, hogy méreteit milliméterre megadva egymás után teszed, a vastagságát 10-el szorozva.
Tehát ha a szám rajta erre utal, akkor ennek a mérete 4.2mm vastag, 34mm széles és 48mm hosszú.Ami befér a helyére, szerintem nyugodtan beteheted. Ha sokkal kisebb a cella, akkor esetleg adódhat gond, hogy az eredeti cellához méretezett töltőáram túl nagy a kicsi cella számára.
Én egyébként ilyenkor rá szoktam mérni, mert néha vannak furcsaságok. Pont nemrég kellett egy távirányítós mini autóban cellát cserélnem. Kimértem, és a 330mAh akksit simán engedték 1A-el tölteni, ami 3C-nek felel meg. Az ökölszabály szerint biztonságos limit 1C, azaz egy 700mAh-s akksit 700mA-el szabad tölteni. Új korában. Ahogy elkezd öregedni, nő a belső ellenállása, úgy egyre inkább fűti magát a cella töltés közben, ami egyre inkább roncsolja a kémiáját -> Előbb utóbb pufi lesz. LiPo-nál én bele szoktam kókányolni a töltőáramkörbe ha lehet, és az elfogadható legkisebb értékre leveszem a töltőáramot.
-
válasz
Wolfram #21742 üzenetére
LDR van benne, ami talán még logaritmikus is, de biztos, hogy magas fokon nem-lineáris.
Emiatt a modulon található ellenállás (amivel feszültségosztót képez) erősen behatárolja a működési tartományt, ahol különbséget tud tenni fény- és fény között. Alap modulokon ezt leginkább a komplett sötétség vs. világosság között állítják be, ezért fény és fény között kevésbé stabil.
-
-
válasz
JulianSinulf #21699 üzenetére
Amit eredetileg linkeltél áramváltót, abból itthon is kapni 10A-es verziót, de ezek az áramváltó tekercsek AC-t tudnak mérni, lényegében transzformátorok.
DC mérésnél a lakat hall szenzorral van kiegészítve, így a lakat nem egymenetes trafó, hanem egymenetes elektromágnes lesz (ami DC esetén is értelmezhető) ennek az erejét méri. Az invazív szenzorok azért olcsóbbak ilyen téren, mert az IC-ben megoldható a mért vezeték, a "vasmag", és a hall szenzor nagyon pontos illesztése kis távolságokkal, ezáltal könnyen mérhető a mágneses mező. Lakatfogós kivitelnél egy jóval zavarosabb rendszert kell kezelni. Szóval ha lakatfogósat szeretnél, akkor sajnos zsebbenyúlós lesz. -
-
Őszinte leszek, azt hittem, a WLED az w mint WS. Az oldalukon az első mondatig olvastam:
A fast and feature-rich implementation of an ESP8266/ESP32 webserver to control NeoPixel (WS2812B, WS2811, SK6812) LEDs or also SPI based chipsets like the WS2801 and APA102!
Mindig tanulok itt valamit -
válasz
Wolfram #21330 üzenetére
A WLED nem sima dimmelést használ, hanem címezhető RGB ledszalagot. Ez kicsit drágább, cserébe ledenként meghatározhatóak a színek, fényerők.
Ha ez teljesíti az elvárásaidat, akkor mindenképp egy egyszerűen megoldható dolog, talán a legegyszerűbb.
Arra vigyázz, hogy ebben az esetben 3 vezetékre lesz szükséged, mert 2 a táp és 1 az adat. Emellett ezek 5V-al mennek, érdemleges fényerő mellett ez nagyobb áramot is jelent. Ha csak a hangulatvilágítás a cél, akkor persze kevéssel is beéri.
A másik, amit fontos megemlíteni, hogy ez nem tud fehér fényeket szépen alkotni. Fővilágításnak, főleg konyhába semmiképp sem ajánlom. Ahhoz RGBW kell, amit persze a WLED ugyanúgy kezel, csak figyelembe kell venni, hogy tisztán fehér fény mellett a fényintenzitás 1/4-e egy azonos, de kizárólag fehér ledeket használó szalagnak. -
válasz
Ton-ton #21325 üzenetére
Lehet, hogy túltoltam, de a témaindító egy komplett lakás okosítása volt. A ledszalagok hangulatvilágításnak elmennek, de normál háztartási világítás esetén - amit az ember feltételez, ha villanykapcsolókról beszélünk - szinte biztos, hogy belefutni azokba a világítótestekbe, amikről írtam.
-
válasz
Wolfram #21322 üzenetére
Dimmelni igazából majdnem* mindent lehet, a kérdés inkább a hogyan. Leírom azokat, amiket én ismerek:
- A hagyományos izzószálas körtéket, és a "dimmable" jelzővel ellátott LED világítótesteket simán fázishasítással lehet dimmelni. Egy thyristorral megoldható, a referencia feszültséget pedig az ESP megadhatha egy digitális potméter segítségével, vagy valami jól megtervezett optocsatolós megoldással.
- A külső meghajtós LED paneleket a fenti módon nem lehet dimmelni, mert a tápegységük áthidalja a fázishasítás okozta kieséseket. Viszont lehet:
-- A meghajtó módosításával. Ezek a meghajtók lényegében áramgenerátoros tápegységek. Ha megvan a referencia ellenállás (amin keresztül a vezérlője az áramot méri) akkor annak a manipulálásával módosítható a fényerő. Ez a megoldás egyébként sokszor villódzás mentes címszóval is fut.
-- A meghajtó elhagyásával. Ilyenkor kell egy olyan tápfeszültség, amivel a LED panel biztonságban használható. Ezt a tápfeszültséget PWM-el korlátozva elérhető a dimmelés.
Fontos, hogy a gyári meghajtó kimenetét csak alapos ellenőrzés után szabad PWM-el megkínálni. Az a baj ugyanis, hogy általában ezekhez univerzális meghajtókat adnak, amik 24V-80V közötti feszültséget tudnak, és csak az áramuk korlátozott 280mA-re. Ez nekik jó, mert ugyanazt a tápot tudják adni kétszer-háromszor akkora panelekhez is, mert az azonos LED-ek sorban vannak rajta, a feszültségigény nagyobb, de az áramgenerátor ugyanaz. Viszont! Tegyük fel, hogy a LED panel amihez használnák normál esetben, 30V-ot igényel, hogy a névleges 280mA menjen át rajta. Ha ezt PWM-el megszaggatjuk, akkor egy időpillanatra nem folyik a névleges áram, amire a meghajtó a feszültség emelésével reagál, ha elég gyors, akár 80V-ra is emeli. Utána a PWM újra rákapcsolja a LED-et a tápra, és a 80V-ot megkapja a 30V-hoz való string, ami nem egészséges.
-- Ugyancsak elhagyható a meghajtó, és használható egy áramkorláttal rendelkező változtatható feszültségű tápegység elektronika. Ilyenekből van olyan, ami akár i2c-n is vezérelhető, de lehet a sima XL4015-ből is ilyet építeni. Ilyenkor az áramkorlátot elég kézzel beállítani, mert az csak egy biztonsági korlát, hogy hiba esetén a mikrokontroller túlfeszelni ne tudja a LED-eket, de alulfeszelni igen. Én ez utóbbival akarok elindulni majd egy saját tervezéssel. -
válasz
fchris82 #21309 üzenetére
Bár én mindent csillagban húztam, igazából csak a jelvezeték kell csillagban. A maradék kettő (fázis-null, +/-, buszvezeték vagy ami lesz) mehet akármerre.
A TP223 az egyik legelterjedtebb touch modul, nagyon jól működik, az érzékenysége konfogurálható hardveresen.
Dimmeléshez a nyomvatartást használhatod, és akkor csak egy tapira van szükség.
A kábelezéssel kapcsolatban:
Lehet kapni "épületgépész" színeket. Én fehéret, lilát és narancssárgát vettem, azokat biztos nem tévesztik semmivel. -
válasz
fchris82 #21301 üzenetére
Szia!
A beépülő tetőterünkben hasonlót csináltam. Ott mondjuk annyi volt a jó adottság, hogy az elosztószekrénytől csak a mosdó volt viszonylag messze.
Én nem babráltam egyedi fali kapcsolókkal. A használt szerelvénycsalád vakfedelének (majdnem annyiba került darabja, mint a kapcsolóknak
) hátuljára felragasztottam TP223 touch sensort. Ez sima digitális jelet ad. Azért nem akartam egyedi busszal elbonyolítani, mert ha egy villám elviszi az összes kapcsolót, akkor szívás azon hajtani, hogy mindet lecseréljem, mert addig nincs kapcsolható világítás. Ebből a szenzorból 20db 1500Ft, bármennyit tarthatok tartalékban. Vagy ha elköltözünk, nem akarom, hogy az új tulaj, vagy annak szerelője szidja anyámat az egyedi kivitelezéssel.
A kapcsolókhoz 3x0.75 vezetékkel álltam ki. Ez ugyancsak visszafelé kompatibilitás miatt van. Ha egyszer valami okból hagyományos kapcsolókra kell visszaállni, akár váltóra, akár wifis okosra, akkor meglegyen a vezeték.
A vezérlőközpont ESP alapú, ami egy arduino végfokozattal beszélget. Azért dupláztam, mert a logikát az ESP viszi, azon lehetséges hogy kell új firmware, amit OTA fel tudok rá tenni, de közben nem szeretném, hogy a kimenetek villódzanak, vagy elfelejtsék az utolsó állapotukat. Amint az ESP magához tér frissítés után, csak visszakéri a státuszt az atmega chiptől.Amit még nem oldottam meg, az a dimmelés. A legtöbb lámpa GK-ba süllyesztett LED panel. A gyári tápjuk a legalapabb gagyi LED meghajtó amit csak kapni lehet. Ezt valószínűleg kiváltom egy központi táppal, és sok áramgenerátoros kimenettel.
-
válasz
Micsurin #21299 üzenetére
Én Újpesten vagyok, szóval írj nyugodtan, ha kell, de innen szerintem is sínen vagy.
Jó lenne végre úgy foglalkozni ezekkel, hogy nem a szakdogán ketcselek hanem mehetne szépen nyugiban a saját elektromos redőny projektem.
Az egyetemen ezt elképesztő nehezen tanultam meg kezelni. Amikor hajtásban voltam, és az agyam 150%-on pörgött folyamatosan, jobbnál jobb ötleteim támadtak különböző projektekre. Néha annyira jók, hogy az eredeti feladattól elment a kedvem... -
-
-
-
Szia!
Teljesen replikálni szeretnéd a projektet, vagy hasonlót elérni? Hol helyezkedik el a projekt az árérzékenység/bütykölés arányon?
Csak azért kérdezem, mert ez az egész simán megoldható egy Attiny85-el, 4db 8bites kaszkádolt shift regiszterrel, és egy 8 bites multiplexerrel.
Az Attiny tud billentyűzetet emulálni, csak kevés az IO rajta (5, ill reset kiiktatásával 6)
A shift registereket 2 pinnel meghajtva meg tudod címezni a billentyűzet 23 pinjét, és a 8 bites multiplexer 3 címző bemenetét. A multiplexer a 8 visszatérő ágat 1 kimenetre fésüli be címzés szerint, így 1 pinnel olvashatod a visszatérő eredményt. 1 pint használhatsz resetnek a multiplexeren és a regisztereken.
Sebességét tekintve persze lassabb lesz. Attiny85-ön sima digitalWrite-al 132kHz egy output sebessége, portmanipulációval ~800kHz+
Ahhoz, hogy végigscanneld a billentyűzetet, a 23 kimenetet mind-mind meg kell címezni, és mellé minden alkalommal a 8 multiplexer címet is. Ez 184 teljes címzés ami 26 kimenet címzéséhez ~4800 output művelet. 800kHz mellett ez azt jelenti, hogy másodpercenként 166x tudod lescannelni a teljes billentyűzet állapotát. Azaz 6ms-ig el kell tartson egy lenyomás, és két lenyomás közti szünet, hogy legyen esély észrevenni. A valóságban szeretünk ilyen műveleteknél 3 ütemet fenntartani, hogy kiszűrhetőek legyenek a zavarok.
Itt leteszteltem hogy átlagosan meddig tartom nyomva a laptop billjét gépelés közben. 50ms jött ki, és a legrövidebb amit szándékosan okozni tudtam 34ms volt.
Szóval szerintem bőven jó lehet.
Szerk.: Ja és a scannelés amivel számoltam, az szimpla bruteforce, ennél léteznek okosabb megoldások, amivel minimum le lehet felezni a ciklust.
-
Szia!
Ha mindenképpen ragaszkodsz a vezetékes megoldáshoz, akkor a CAN nem egy rossz megoldás, de tartsd szem előtt, hogy az Arduinok nagy részében még CAN controller sincs, CAN transceiver pedig tudtommal egyikben sincs. Ezt nodeonként megvenni igen drága mulatság.
Mekkora mintavételben gondolkodsz? Egy kisebb sávszélességű kommunikációt esetleg megoldhatsz 1-wire jellegű protokollal is, ami nem kerül plusz alkatrészbe.
-
válasz
lanszelot #21082 üzenetére
Az ESP32 egy mikrokontroller. Te egy erre a mikrokontrollerre épülő fejlesztőpanelt vettél, amit úgy kell kezelned, mintha egy arduino lenne. Plusz mikrokontroller nem kell hozzá, de valamivel programoznod kell, mert ezeken nincs USB-Serial átalakító, mint mondjuk egy Nano esetén.
Programozni különböző fejlesztőkörnyezetekben lehet, akár Arduino IDE szoftverrel is tudsz rá programot írni, mint egy Arduino boardra.
Wifi-BT és még millió opció van benne, amit vagy használsz, vagy nem.Szvsz, ha felmerül a kérdés, hogy "Azzal mit csinálok?" akkor általában az a válaszom, hogy ha ez kérdés, akkor egyelőre semmit. Nézegess projekteket. Youtube, Instructables, Hackaday és majd megjön az ihleted.
-
válasz
Gergosz2 #21076 üzenetére
Igen, azt tudom, csak abban nem vagyok biztos mi történik, ha a vevők egyszerre ACK-olnak mind, azért gondoltam, hogy az kuszává válhat multicastnál, de másodjára belegondolva biztos, hogy nem ez az első alkalom, hogy valaki így akarja használni, biztos van rá valami megoldás.
-
-
-
válasz
Undoroid #20825 üzenetére
Szia!
Az Uno-n sértetlen marad a bootloader. Ami történik fele, az az, hogy felkerül rá egy program aminek köszönhetően egy ISP programozóvá változtathatod magát az UNO-t.
Ezzel az ISP programozóval fog írni egy bootloadert a 3D nyomtatóra, aminek köszönhetően a 3D nyomtató mikrokontrollere programozható lesz Arduino környezetben. (Gyárilag csak ráírják a firmware-t, nincs rajta booloader). A Marlin firmware viszont már Arduinoban vagyon írva, így utána feltölthető a nyomtatóra, ha az rendelkezik a megfelelő bootloaderrel.
-
válasz
Wolfram #20802 üzenetére
Ha picike levélszekrény (tehát újságot nem nyomkodják bele), és teljesen robosztusra akarod, akkor ezekből a precíziós "ékszer" mérlegekből indulnék el, amit a szekrény aljában el tudsz helyezni, egy méretre vágott vakpadlóval a szekrény aljába.
Lehet valami látó szenzorral is persze, csak az érzékennyé válhat a párára, porra, esetleg átverhető, ha bedugnak valamit, majd visszahúzzák. -
-
Visszatérve az eredeti kérdésedre, igen, sajnos velem is fordult már elő, hogy valamiért hibás volt az mcu.
Én Atmega128-al jártam úgy, hogy az analóg multiplexere be volt "ragadva". Sokáig nem értettem, miért viselkedik úgy-ahogy. Aztán hosszas debug után rájöttem, hogy nem mindig azokat a fizikai pineket analogRead-eli, amiket elvárok. Próbálgatás után dekódoltam a hibát, és arra vezettem vissza, hogy a 8 helyett folyton csak 4 pint olvas, és a lépésekből lehetett rá következtetni, hogy a multiplexer melyik bitje hibás.
Azóta sem találkoztam ilyennel sosem. Hozzátartozik, hogy ebben az esetben IC formájában vettem a mikrokontrollert, és én építettem be egy koleszos íróasztalnál (ESD-s Chio chipset, és Monster energyt fogyasztva). Simán lehet, hogy én öltem meg valamit, nagyjából 15 példányból egy volt a problémás.
A gyártás közben egyébként van több helyen quality-control, aminek ki kéne köpni az ilyesmit, de nyilván nem tévedhetetlenek ezek a gyártók, nem beszélve arról, hogy sok esetben emberi operátorok hozzák a végső döntést, és bizony vannak velük tapasztalataim, egész közelről. -
-
-
válasz
lanszelot #20299 üzenetére
Akkor viszont kapcsold ki az interruptot a teker() elején, és a végén kapcsold vissza.
Az a baj, hogy ezzel nem pergésmentesítesz, mert az interrupt megszakítja az interruptot minden váltásnál.
Szerk.: Pergésre egyébként inkrementális jeladónál nem lehet így kompenzálni. Alapelv, hogy semmilyen állapotot nem szabad elszalasztani, másképp ugrott az INKREMENTÁLIS jellege. Ha van is pergés, +/- 1 felbontást ugrál oda vissza, mert ahol a clk prellez, ott a dt nem, és vica versa. Ezt kell lekezelni, ha nagyon fontos a pergésmentesség, de saját szájízre nem szabad blokkolni a számolást.
Ugyanez igaz a nagy felbontásra. Ne az inkrementek skippelésével kezeld, hanem vezess be egy plusz változót, és a valós értékben az inkrementeket vezesd, és a keses legyen inkrementek/1000 például. Ez prellmentesít is.
-
válasz
lanszelot #20292 üzenetére
void teker(){
currentStateCLK = digitalRead(inputCLK);
if(digitalRead(inputDT) == currentStateCLK){
keses = keses+100;
}else{
if(keses > 100){
keses = keses-100;
}
}
previousStateCLK = currentStateCLK;
}
Ne korlátozd időben az interruptot, mert azzal lépéseket hagyhatsz ki.A currentState és a previousState pedig az interrupton belül legyen kezelve, mert az interrupt bárhol történhet a futás során. Akár a loopban lévő értékadás előtt vagy után is, ami következetlenné teszi a viselkedését.
-
válasz
lanszelot #20283 üzenetére
Nem tudom milyen enkódered van, de kénytelen leszel vagy interruptot használni, vagy ütemezőt, ahogy Aryes is írta.
Ha az a tipik pozícióba billenős kattogós enkódered van, akkor hiába forgatod, mert annak a clock lába mindig ugyanaz a stabil állapotban.
Mivel a kódod csak két villogás között mintavételez, ezért mindig csak az az állapot számít, ami a kék led kialvása + keses utáni DE a piros felvillanása előtti időben, azaz pár mikroszekundumban áll fenn. Tehát neked akkor kellene a CLK egy pillanatra más legyen. De ezt nagyon nehéz elkapni, leginkább lehetetlen, ezért a kódod folyamat azt látja, hogy a CLK változatlan, így nem tesz semmit a keses értékével.Interrupttal azt tudod csinálni, hogy a uC figyeli az inputot, és amint az változik, végrehajt egy kódot (esetedben a loop
/*read current state of inputCLK*/)
Ennek köszönhetően a kód nem marad le a váltásokról, mert az interrupt szépen kierőszakolja a futást minden váltáskor.
Ütemezéssel pedig maradhat így a kódod, csak a delay-eket törlöd, és helyettesíted if() feltételekkel. Esetedben 4 ütemre van szükség: redOn, redOff, blueOn, blueOff. A kód elején meghatározod, hogy a piros először mondjuk a futás első másodpercében kell felvillanjon (redOn = 1000). Akkor kialudnia redOff = redOn+keses; időben kell. A blueOn ideje redOff+keses. blueOff = blueOn+keses. Ezután csak kitalálod if használatával, hogy a futásidő millis() éppen melyik ütemen belül van, és annak az ütemnek a feladatát hajtja végre. Mikor az utolsó ütemből is kilépsz, újra kell számolni az ütemek új időpontját. Így a loop nagyon gyorsan ismétlődik, és van esély, hogy nem marad le a futásod az enkóder mozgásáról. Igen, arra is van esély, hogy lemarad, főleg attól függően, hogy mennyire bonyolult marad egy-egy ütem.
-
-
Az újabb verzió (2812B) kettős PWM-et használ. Az első fok az output driverek bemenő feszültségét csökkenti, így értek el jelentősen kisebb hőtermelést a chipen belül az előző verzióhoz képest. A blokkdiagramjuk persze teljesen titkos, de ha lehet hinni a marketing-kommunikációnak, akkor bizony nem sima stabkockákkal tömték meg.
Egyszerűen ellenőrizhető egyébként: 3.3V-ról és 5V-ról is táplálható a szalag, pár LED esetén már mérhető az áram csökkenése.ViZion: Azért neveztem közhiedelemnek, mert maga a gyártó sosem állított ilyet. Sőt a Pololu pl. egyenesen 50mA-t ír a datasheetjeibe pixelenként. A WorldSemi pl. sosem nyilatkozott arról, hogy maga a belső áramkör milyen referencia értékekkel dolgozik. Lehet, hogy a ledek benne 20mA-el mennek névlegesen, de ők alulhajtják gyárilag a közös tokozás miatt. A biztonsági tényező persze attól nem árt, csak imhol az ékes példája, amikor valaki az urban legend alapján üzemi értékek helyett abs.max értékekkel tervez. Aztán amikor elkészül, szomorúan látja, hogy alig 50%-ban használja ki a forrását.
-
Ha jól látom, a videóban 5V-on mér áramfelvételt.
A WorldSemi egyébként a datasheetben nem ír áramfelvételt. Csak felsorolja, hogy mely színeket milyen LED-ek adnak a tokozásban.
A piros LED datasheetje itt van. Ebben olvasható, hogy az üzemi árama valóban 20mA (gyanítom a többi LED-nek is ennyi, innen ered a közhiedelem, hogy LED-enként 20mA), viszont ilyenkor a hajtófeszültség akár 2.8V is lehet a piros LED esetén.Tehát amennyiben csak a piros színt hajtod maxon, akkor 5V-on akár 60%-a is lehet a mért áram. (5Vx12mA ≈ 2.8Vx20mA + veszteségek)
Ugyanez tovább árnyalódik a többi LED-el, és azok varianciájával, a chip-die melegedésével ha mind mennek, stb.
Az urban legend 60mA egy WS2812-re tehát inkább amolyan absolute-maximum ratingnek tekinthető, mintsem üzemi áramigénynek. -
válasz
gordonfreemN #19641 üzenetére
Ha egy folyamatos kihunyó-felerősödő állapotot szeretnél, akkor altatás helyett lehet célszerűbb csak simán lejjebb venned az órajelet. Ilyenkor a fade effekt delay nélkül (vagy jelentősen kisebb delayel) pöröghet.
Ha ilyen szívdobogás jellegűt szeretnél, amikor a két felderengés között hosszabb idő eltelik, akkor érdemes altatni is. Ilyenkor az alap fogyasztásod az effekt hossza / üres idő aránya javítja.
Ugyanakkor megkérdezném: Ennyire energiakritikus az alkalmazás? Csak azért, mert az 328p fogyasztása összemérhető egy villogó LED-ével.
- Ha nagyon energiakritikus, akkor gondold át a standby LED-et is
- Ha nem energiakritikus, nincs szükség valós altatásra, csak berakod egy állapotba, amiből bármelyik pinnel ki tudod léptetni, és amíg a kilépő feltételt várja, fadeli a ledet. -
-
-
válasz
gya/352 #19584 üzenetére
Egyébként örülök, hogy pörög ez a netrádió téma itt, mert nekem is van tervem ilyesmivel. Nekem az a tervem, hogy a házban minden valamirevaló hangfalhoz rádobok aux-ra egy ESP alapú netrádió vevőt. A cél, hogy ha kell, az egész házban szólhasson ugyanaz a forrás kellemes hangerőn anélkül, hogy egy kitüntetett helyen üvöltené be a házat.
-
long readVcc()
{
long result; // Itt olvasod ki a belső referenciát AVCC-hez viszonyítva
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
delay(2);
ADCSRA |= _BV(ADSC);
while (bit_is_set(ADCSRA,ADSC));
result = ADCL;
result |= ADCH<<8;
result = 1125300L / result; // 1023*1100mV osztva 1.1 értéke AVCC-re vetítve// ha 1023-at mértél, akkor AVCC 1100 mV
// ha 256-ot mértél, akkor AVCC ~4400 mV
return result; }
Itt van fent a kód, sajnos fejből nem vágom ennyire a regisztereket, ezért csak egy régi kódomból tudtam kipuskázni, de lehetséges.
Ahol megismerkedtem ezzel, ott Attiny45-öt táplálok direktben 18650-ről a gyerek egyik csillagprojektorában. Eredetileg elemmel ment és nem tudott magától kikapcsolni. Akksira váltottam, viszont azzal mire észreveszem a merülést a fényerőn, addigra kinyírtam volna a cellát. Szóval van benne egy szimulált "merülés" effekt, ami leveszi a LED-ek fényerejét, amikor a cella már közeledik a 3V-hoz.
-
Jó ötlet a saját implementációjú BOD.
Nem resetel magától, de megvéd a rossz írástól.Ha esetleg a hardver módosítás akadály lenne, akkor szoftverből is megoldható egy kis trükközéssel.
Az atmega tartalmaz egy beépített feszültségreferencia adót, ami kvázi egy ultrapici 1.1V stabkocka.
Az analóg referencia feszültség a legtöbb alap tervezésben egyezik a tápfeszültséggel, tehát az analóg mérés 1023 esetén a pillanatnyi tápfesz, fele esetén fél tápfesz, stb.
Ha megméred az internal vref feszültségét, abból vissza tudsz skálázni a tápfeszre.
Pl. ha 512-nek méred, akkor kb. 2.2V a tápfesz. Ha 256-nak, akkor kb. 4.4V -
válasz
Harcipocok84 #19335 üzenetére
A brown-out önmagában azt jelenti, hogy a mikrokontroller olyan üzemi feszültségen kezd működni, ahol már instabillá válHAT. Tehát ezen a tartományon még nem feltétlenül indul újra, de már csinálhat buta dolgokat.
Ezek a buta dolgok magukban foglalnak olyan eseteket is, amikor a feszültség már nem elegendő például egy eeprom lebegő tranzisztorának átkapcsolására.
Kérdésedre válaszolva: EEPROM írás befejezésében nem tud segíteni, inkább abban segít, hogy az írás el se kezdődjön.
Ha az írás előtti pillanatban még nem alacsony a feszültség, akkor azt az egy írási műveletet megszakítatlanul be tudja fejezni. (Megfelelően kondenzátorozott elektronika esetén a brownout feszültség felső határától a blackoutig van annyi energia, hogy egy-egy byte eeprom írást még befejezzen vele).Amikor a brownout detection be van kapcsolva, olyankor a mikrokontroller felismeri mikortól nem kellene pl. EEPROM írásba fogni, és szándékosan reset állapotba teszi magát, így még akkor is újraindul, ha nem kéne, sőt általában beállít egy status bitet is, amiben jelzi magának, hogy az újraindulás oka az alacsony feszültség volt.
Ha nálad nincs bekapcsolva, az pontosan okozhat olyan gondot, hogy a kódfutás megszakítatlan, de az eeprom-ba szemetet írsz, ha nincs meg a kellő tápfeszültséged. Definíció szerint az ilyen állapotokat igyekszik a brownout-detection megakadályozni.
Szerk.:
2.7V lehet kicsi, de akár nagy is. Ez az Atmega328p esetében 10MHz órajelhez a biztonságos feszültség.
Ezt mehet feljebb, 20MHz esetén 4.5V, de lehet akár még alacsonyabb is, ugyanis a chip minimum feszültsége 1.8V a 8MHz-es belső oscillátort használva.
Ha az elterjedt Nano/Uno kártyák valamelyikét használod, akkor azon 16MHz oscillátor lesz, tehát inkább átmennék 4.5V-ra. -
válasz
Harcipocok84 #19328 üzenetére
A probléma megértéséhez kicsit bele kell mélyedni az EEPROM-ok lelki világába.
Fizikai rétegen egy eeprom írás igazából úgy zajlik, hogy törlődik az összes byte. Ez az általános elképzeléssel ellentétben nem azt jelenti, hogy nullázódik, hanem azt, hogy minden érték 1 lesz. Majd ebből az állapotból szelektíven állít mindent nullára.
Ugyebár te egy viszonylag kicsi tartományon operálsz, tehát a bytejaid (arduino int 2 byte) valahogy így festenek:
0b1000000010010110 (előjelbit, +150 15 maradék biten)
Amikor a dínó írni próbál, átáll erre:
0b1111111111111111
majd elkezd nullázni. Ha azonban nem ér végig brownout miatt például, akkor kapsz a memóriába egy bármilyen számot, ami 32,767 és az általad menteni kívánt szám között szerepel valahol.Ha kritikus információt akarsz menteni, akkor ahogy a többiek írták, mentsd el többször, és vezess ellenőrző összeget a mentésekről, hogy tudd, ki a hibás.
-
Oké, csak ő most mégis ezt a kódot dobta be, hogy szeretné továbbgondolni, ebben akartam segíteni.
A korábban linkelt másik kód önmagában nem fog működni, csak ha kalibrálja. Abban van egy konstans és egy elsőfokú korrekció, idő alapon integrál (feltételezi, hogy két mérés között más idő telik el).Ha tiszta jelalaknál jól működik, akkor én nem gyanakodnék a nyers adatra, inkább az utófeldolgozás kétséges.
-
A 10bit ADC az 5A méréshatárt 1024 részre osztja. Előjelesen 512-re. Az még 0,01A precizitás.
A gond egyértelműen a számolás menetével van. Ahogy korábban írtuk, a pillanatnyi csúcsok értékéből nem következik egyértelműen a folytonos áramfelvétel.
Itt vannak ezek a jelalakok. Egyértelműen belátható, hogy más más fogyasztás (és ezáltal folytonos áram) tartozik a piros-zöld-kék áramokhoz. A peak-to-peak mégis azonos mindnél, így a számolás ugyanazt fogja adni.
Azért írtam az RMS-t, mert az egy közelítő integrált fog adni a görbe alatti területekre (gyakolatilag kicsi hasábok területei lesznek, melyek magassága a pillanatnyi érték, szélessége a mintavételi idő.).
Kódban ez valahogy így nézne ki:
void Measure()
{
int mAmps=0;
uint32_t RMS=0; //ide jó sok nagy szám befuthat
int RMScount=0;
uint32_t start_time = millis();
int sensoValue;
while((millis()-start_time) < 200)
{
sensorValue = analogRead(CURRENT_SENSOR);
RMS+=sensorValue*sensorValue;
RMScount++;
}
RMS = RMS/RMScount;
RMS = sqrt(RMS);
RMS = RMS * tapasztalatitenyezo; //ha esetleg kéne, a szorzót meg lehet állapítani, talán lineáris is elég
}Egyébként ha akarsz rajta pontosítani, akkor érdemes tesztelgetni, hogy az ADC prescaler felgyorsításával javul e a pontosság. Ugyebár akkor a mérés maga pontatlanabb lesz, de a mérések mennyisége több lesz, így jobban közelíti a függvény alatti területet a pici téglalapok átlaga.
Szerk.: A csatolt kép lemaradt -
válasz
JozsBiker #18965 üzenetére
Én a min-max kiválasztás helyett inkább négyzetes átlagolnám (RMS) a 10 ciklus alatt vételezett adatokat, majd arra alkotnék "tapasztalati tényezőt".
A peak-to-peak értékek nagyon becsapják a mérésed, mert ugyanazt fogja adni akkor is, ha:
- Egy cikluson belül egy-egy mérés idejére leng ki a csúcs (tüske kapcsüzemű tápok esetén)
- Egy cikluson belül teljes szinusz hullám ideje alatt ment a terhelés (ohmikus fogyasztók)Gondolom a lakatfogó is használ valami mozgóátlagot, és emiatt nem egyezik a mérés a tieddel.
-
válasz
Speeedfire #18962 üzenetére
Ha mindenképpen a "szeretek ilyennel szenvedni" résznek áldozol, és meg akarod oldani, akkor íme egy lehetőség:
Felteszel a gépre egy null-modem emulátort (com0com). Ez azt tudja, hogy szoftveresen emulál neked néhány új COM portot a gépen, amit össze tudsz kötni.
Csinálsz egy COM10<->COM11 párost pl.
Hyperion csatlakozik COM10-re.
A Pyton kódod csatlakozik COM11-re. Amikor COM11-en bejövő adat van, az elejére (vagy végére) csapod azt az X byte infót, ami a displayre kell, majd kiküldöd az arduino felé COM2-n (vagy amelyiken eléred) a csomagot.Az Arduino kódodhoz pedig a serial buffer kiolvasásánál az első (vagy utolsó) X byteot kiolvasod, és frissíted a kijelzőt ez alapján.
-
válasz
kemcso #18869 üzenetére
Elnézve az eredeti kódot, a kávéfőző software serialon beszélget, de inicializálva van a saját serial port is ami USB-n megy.
A táplálás "töltő" esetén azt jelenti, hogy ugyanazon USB kábelt nem a laptopba, hanem egy telefontöltőbe dugsz? (Nano esetén nincs kimondott jack adapter aljzat, de van VIN pin ezért kérdezem).
Csak azért, mert ha ugyanazon a porton táplálsz, és más különbség nincs laptopos és töltős üzem között, akkor hardveres oka nem lehet az anomáliának.
Egyébként én azt próbálnám meg, hogy, a fő loop-ba tennék egy delay(50); sort a végére. Precizitásban nem ront sokat a programodon, cserébe sokkal kevésbé spammeli a komm csatornákat. Gondolj bele, hogy uC nyélgázon pingeli a szoftveres serialt, majd ír a hardveresre, majd kijelzőt frissít. Sőt, igazából kijelzőt frissít akkor is, ha nincs értelme, mert a getMaraData()-ban a mySerial.available() lehet, hogy false, és nem jön friss adat. Az updateView akkor is lefut. Sokszor okozott már nekem különböző problémát, hogy a kód eszetlenül darál.
Ebből a szempontból érdekes lenne az is, hogyan oldottad meg a reed szenzor figyelését, mert ahogy ViZion is írta, a prellezéséből is adódhat gond.Szerk.:
C1.06,116,124,093,0840,1,0\n every ~400-500ms
Az 50ms delay nem fog sokat rontani a kódodon, tekintve, hogy a komment szerint a kávéfőző 400-500ms intervallummal küld friss adatot. -
Én használom, szerintem elég klassz. EEPROM-ban tárolja a konfigurációt.
Korábban úgy oldottam meg hogy (VIGYÁZAT komoly túlbonyolított agyf*sz következik):
- Beégettem kódba egy fallback SSID/pw párost
- EEPROM-ból kiolvastam egy megadott helyről egy másik SSID/pw párost
- Ha az EEPROM-ból olvasott AP-ra fel tudtam csatlakozni, akkor ment minden üzemszerűen
- Ha az EEPROM-ból olvasott AP nem létezett, vagy nem tudtam csatlakozni, akkor a fallback-et próbáltam
- Ha a fallback sikerült, akkor egy szerverről lekértem, az ajánlott SSID/pw párost. (Itt be lehet tenni tetszőleges visszafejthető titkosítást, akár már a szerver eléréséhez, akár a kommunkált adatokba is)
- Ha az ajánlott SSID egyezett a jelenleg EEPROM-ban lévővel (amihez ugye nem tudtunk csatlakozni) akkor fentmaradt az ESP a fallback hálózaton, és indulhat az üzemszerű működés
- Ha az ajánlott SSID változott, akkor frissítettem az EEPROM-ot és reboot.Így ha valahova vittem egy ilyen eszközt, akkor a szerveren letároltuk a hozzá tartozó logint, és mobilról hotspottal megadtam neki a fallback hálót amíg inicializált.
-
válasz
Wolfram #18784 üzenetére
A Sonoff Touch okoskapcsolók elég sokat meg tudnak jegyezni (nem találtam még meg a limitációját), szóval nekem van egy-két ilyen 433MHz-es cuccom. Mozgásérzékelők, reed-relés nyitás érzékelők, elárasztás érzékelők. Azért preferálom, mert szinte semmit nem fogyasztanak, de jelentősen olcsóbbak mint a ZigBee eszközök.
Lehet kapni kismillió 4 gombos tanítható távirányítót (ezeken szerintem azért "limitáció" a 4 gomb, mert egyszerűen ennyi kényelmes méretben). Van 10 gombos kapcsolóm, és abból a típusból lehetett kapni 12 gombosat is. Sőt, bizonyos autókulcsokat is megismernek. Nekem sokáig úgy ment a kinti világítás, hogy amikor bezártam a kocsit, felkapcsolt a lámpa, amikor kinyitottam elaludt. (A mostani autó contactless kulcsos, és ez már valami komolyabb cucc, mert a sima rádiók semmit nem látnak belőle).Lehet venni 433MHz RX/TX modulokat, amik még olcsóbbak (már-már nevetségesen) és kb olyan üzenetet generálsz - vagy másolsz le, amit nem szégyellsz.
Szóval szerintem az alapvető ok az a praktikum, és az olcsósítás, de nem technikai limitáció az én meglátásom szerint.
Analóg szenzor témában
Ha van egy szabad digit pined, hogy megcímezd, akkor használj analóg multiplexert:
[link] -
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.
-
-
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. -
-
válasz
its_grandpa #17627 üzenetére
Ha weben szövegként megjelenik valami, én simán lekérem az oldalt, és a forrásban regex-el megkeresem a számomra érdekes részt.
xbox360-hoz van ilyen ventillátoros bázis, USB-vel csatlakoztatható, de csak ki-be állás van rajta. Beletettem egy esp-t és az xbox IP-jéről az rgh dashről lekérem a hőmérsékleteket, az alapján pedig pwm-el hajtom a ventit. A feladat más, de a logkia ugyanaz (csak nálad a pwm görbe egy ugrás lesz 0-100 között)
-
válasz
Janos250 #17621 üzenetére
Annyival kiegészíteném, hogy ha a fórumtárs minimálisat akar hardverezni, akkor inkább menjen a ProMicro irányába.
A legolcsóbb kontrollerek esetében a mikrokontroller FTDI chipen keresztül vannak USB-re kötve (vagy egyáltalán sehogy sem). Ilyenkor kell egy minimális bonyolultságú segédáramkör az USB-re illesztéshez.
A ProMicro ezzel szemben direktben az USB-re van kötve, ráadásul dedikált USB kontroller van benne, míg a Nano-n csak bitbanginggel lehet vUSB-t használni.
-
-
válasz
Janos250 #17391 üzenetére
Elképesztő bosszantó a facebook hozzáállása ehhez.
Egyszer vettem a fáradságot, és felgöngyölítettem egy komplett csalásra specializálódott csapatot. Úgy kezdődött, hogy az arcomba tolt a fb egy hirdetést, ami kamu volt, de mégis sokan írták alatta, hogy "Szuper ajánlat, épp egy hete használom" stb. Ellenőriztem a profilokat, és egyértelműen látszott, hogy erre a célra létrehozott profilok. Vagy 10-15 darab. Internetről származó profilképek, kommentek 8-10 nyelven itt-ott, teljesen belterjes ismerettségi kör. Az aktivitásukat visszatrackelve találtam még 4 hasonlóan csaló hirdetést, amiken keresztül találtam még 30-40 darab kamuprofilt.
Mindet jelentettem a facebook felé, és 0, azaz 0 db profilt töröltek. A hirdetések is sokáig fent voltak, valószínűleg nem a fb vette le őket.
Egyszer már komponáltam egy bejelentést az NMHH-nak, de végül elengedtem.
-
válasz
tonermagus #17322 üzenetére
Mindenképpen csak passzív elemekkel szeretnéd kiegészíteni az Arduinot?
Nekem erre a felhasználásra első körben egy SPI-on kommunikáló izolált IC jut eszembe. Ott nem lesz gond a visszatáplálással, és talán olyat is találni, aminek van polaritásfüggetlen verziója.
-
bár a követelményed ellent mond a csendességnek...
Szerintem azért, mert ha pedál (vagy bármi mechanikus), akkor van benne két végállás, amelyeknél a felkoppanásokat nehéz tompítani.Ha vékonyra csinálod a házat, és nem holdjáróban koncertezel, akkor érdemes megpróbálni egy nagy "antennát" a lábszenzor belsejében. Én hackeltem már meg TTP szenzort, hogy érzékeljen 18-as bútorlapon keresztül.
Ismerve a felhasználást, én valamilyen távolságérzékelőben gondolkodnék, ami könnyen már azt is látná, ha fölé fordítod a lábfejed.
Persze tudom, hogy nem ezzel kapcsolatban kértél tanácsot -
Ugyanezt akartam írni, de túl trollnak találtam
Tomika86
Olvastam a másik topicban a feedbacket. ESP8266-nál a watchdogból ki lehet olvasni, hogy mi volt az oka a legutóbbi resetnek, biztos van ilyen az ESP32-nél is (sajnos nincs sok tapasztalatom vele, de hátha itt valaki meg tudja mondani, hogyan csináld). -
-
-
válasz
tonermagus #17156 üzenetére
A "tárgy"-ban lévő elektronikában követelmény, hogy passzív legyen?
Egy lecsökkentett TX poweres ESP-t (vagy herpákolt antennásat) ha beleteszel, egy másikkal az oszlopban tudod mérni a jelerősséget.
-
Mutatok képet, másról - érthetően, a szóban forgóról nincs. De majd behozok a melóba egy MPU modult és meglövöm azt is.
Amit látni ezen, az egy QFN16-os tokozás röntgenképe. A hűtőlapra általában gyártói előírás van, ami az IPC-t felülírhatja. Ebben általában két dolgot határoznak meg: teljes zárvány (void) százalék, és maximális egybefüggő zárvány százalék.
Ha nagy/sok a bubi, az jelentősen rontja a thermal-pad hőleadó képességét, így olyan esetekben kritikus ez, amikor jelentős disszipációt végez a chip.
Az MPU mems szenzorai ezzel szemben nem fejlesztenek sok hőt. A baj azzal van, hogy a thermal-pad a leadframe része, gyártás közben erre rögzítik a szenzort. A csatolt képen látod, hogy a "sarkokba" kinyúlik, de a lábakkal nincs összeköttetésben.
Emiatt, ha a lábakat leforrasztod, akkor az epoxy tokozás kevésbé adja át a gondot a MEMS-nek.
Viszont, ha leforrasztod a hűtőlapot, akkor lehűlés közben a forrasz kb. 200 foktól mereven tartja a felületet, amiben még bennevan a hőtágulásnyi alakváltozás. Amikor lehűl, akkor nem tudja felvenni a hideg méretét, marad benne egy kis "megnyújtás".
Ekkora méretekben a hőtágulás persze elképesztően kis méreteket ölt, de a benne lévő MEMS léptékeivel óriási számokról beszélünk.Szerk.:
Az Invensense előírások az MPU-t fogadó PCB-re. Harmadik oldal közepén keresd az "exposed die pad" részeket. Nem hogy leforrasztani nem szabadna, de még copper layert alárakni sem. [link] -
Kedvencem ezekkel az MPU chipekkel, hogy a hasuk alatti thermal-pad-re kiköti az invensense, hogy tilos leforrasztani, mert lehűlés után statikus feszültséget okoz a tokozásban.
Na ehhez képest 0, azaz 0 olyan MPU modullal találkoztam a piacon, ahol ne forrasztották volna le.
Hova tovább, egyszer egy csillió dolláros hadiipart kiszolgáló cég bérgyártóinál dolgoztunk, és a munkám végzése közben véletlenül felismertem az MPU egyik chipjét a quality checklisten. (Csak a helyzete és a PCB footprint alapján felismertem, kombinálva azzal, hogy volt sejtésem róla, hogy mibe építik.)
Felröhögtem, amikor megláttam, hogy nemhogy forrasztják, de 5% void limittel engedik át a röntgenes vizsgálaton. Odahívtam a qualitys mérnököt, és mondtam neki, hogy tegyünk úgy, hogy ezt nem én mondtam - mert amúgy nem lett volna szabad másra sem bámészkodnom, mint amiért odamentünk, nemhogy még kitalálni mi az és milyen IC-ket használnak rajta - de menjen, és szóljon a feletteseinek, vagy akinek akar, és mutassa meg az Invensense PCB design guideline doksiját nekik. Mókuska elment, majd az iroda ahová bement hangyabollyá változott 5 percen belül -
válasz
Tankblock #16934 üzenetére
Én is éreztem némi zavart az erőben, de volt egy ilyen:
De mivel én csak egy szálhoz férek hozzá
Gondolom a ledek és a mikrovezérlő nem tud egy helyen lenni, és nem vihető több vezeték sem a kettő között. Mondjuk a 3A akkor is indokolatlan továbbra is 5 normál ledhez.
-
válasz
tonermagus #16932 üzenetére
5db fehér ledet az alábbi konfigurációkban tudsz használni 12V-ról
feltételezve, hogy sima fehér ledek, (tipikusan 3.2V és 20mA)
https://www.amplifiedparts.com/tech-articles/led-parallel-series-calculator -
válasz
tonermagus #16922 üzenetére
A PWM-es meghajtásnál nincs - jelentős - disszipáció és a vezérelt eszköz átlagárama is lineáris összefüggésben marad a PWM kitöltési tényezőjével.
Ez arra vezethető vissza, hogy eredetileg analóg szabályozást említettél.
Analóg szabályozás esetén az elektronika (ez általában több, mint egy FET) egy parancsjel alapján kimeneti feszültséget szabályoz. Egyszerű, egy IC-s elektronika esetében ez úgy történik (egyszerűen magyarázva), hogy az IC változtatja a saját ellenállását, ezzel engedve nagyobb áramot/feszültséget a fogyasztóra. Ezekkel az a gond, hogy a fölös energiát - mint egy ellenállás - elfűti (disszipálja).
A PWM meghajtásnál az IC (esetünkben a FET) csak full bekapcsolt, és csak full kikapcsolt állapotban működik. Tehát vagy végtelen az ellenállása, és egyáltalán nem folyik rajta áram (emiatt nem disszipál), vagy közel nulla az ellenállása, ezért minimális a disszipáció rajta. -
Szerintem az analogWrite alatt a PWM-et értette (az Arduino legalábbis analogWrite használatakor PWM-et generál).
tonermagus
Csak hogy ne zavarjunk össze, a PWM tehát továbbra is jó neked arra a célra, amire szeretnéd. Csak a megfogalmazás volt nekünk félreérthető (ahogy ezt már kitárgyaltuk).
A low-side jelentését, és a gate-lehúzó ellenállást And kolléga megválaszolta. Ha van még kérdésed, tedd fel nyugodtan. -
válasz
tonermagus #16916 üzenetére
Szia!
Teljesen jó az irány, már csak egy kérdés van: mekkora áramot kell tudnia?
Én az irlml2502-t szoktam használni, hasonló ahhoz amit Janos250 kolléga használ. Amire figyelj, hogy a FET-ek low-side szoktak lenni inkább (tehát a földre szaggat).
Ami még esetleg fontos lehet: A Gate lábat érdemes lehúzni a földre egy nagyobb ellenállással: A uC-k induláskor nagyimpedanciás módban indulnak, ilyenkor az áramkör zajból összeszedett néhány elektronja elég lehet, hogy a FET analóg módban elinduljon (azaz sem teljesen bekapcsolva, sem teljesen kikapcsolva nincs) - ez néha meg tudja őket füstöltetni. -
válasz
tonermagus #16908 üzenetére
Nem tudom mi az alkalmazás, de PWM-nek definícó szerint pont az a lényege, hogy nem analóg feszültségszabályzással éred el a kívánt teljesítményt, hanem a max és a min teljesítmény időarányainak beállításával nagy frekvencián.
Persze előállítható PWM segítségével feszültségszabályozás is megfelelő szűrőelektronika és visszacsatolás használatával, de ez nem csak a FET paramétere lesz. Ideális esetben PWM használatakor a FET egy nagy kapcsoló, és a kimenetén csak a 0 és a táp jelenik meg. A többit a szűrés oldja meg.
Ha tehát a terhelésed nem bírja az 5V-ot (legalább impulzus szerűen) akkor nem ajánlott 0-3.3V között PWM-el szabályozni.
-
válasz
Undoroid #16899 üzenetére
Az irány jó amerre indultál. Vagy csinálj egy void color2(...) eljárást, vagy a color(...)-t változtasd meg úgy, hogy a két(x3) kimenetekre más értéket tehess.
Gyomláld ki a hibákat amiket kapsz - ezek valószínűleg azért keletkeznek mert:
- nem tehetsz a kódba kétszer ugyanazon névvel void-ot, a másik legyen color2
- ha az argumentumokon változtatsz, akkor mindenütt, ahol meghívod a void-ot, ott bővítened kell az argumentumok számát, hogy megfeleljen a deklaráltnak.void color (unsigned char red, unsigned char green, unsigned char blue)// the color generating function
{
analogWrite(redPin, 255-red); // PWM signal output
analogWrite(greenPin, 255-green); // PWM signal output
analogWrite(bluePin, 255-blue); // PWM signal output
}
void color2 (unsigned char red, unsigned char green, unsigned char blue)// the color generating function
{
analogWrite(red2Pin, 255-red); // PWM signal output
analogWrite(green2Pin, 255-green); // PWM signal output
analogWrite(blue2Pin, 255-blue); // PWM signal output
} -
válasz
ekkold #16865 üzenetére
Ebben az esetben beletennék a kódba egy flaget, és amíg az nincs igazra téve, addig a az enkóder süket.
Amíg a flag hamis, addig azt figyelném, hogy az 11 állapot fennáll e egy általad meghatározott ideig egy meghatározott időn belül.
Mivel az egyik enkóder stabil állapotban csak 00 lehet, ott ez biztos hogy nem fog előfordulni könnyen.
Indulás után vársz 2 másodpercet az egyik stabil állapotban, és utána elfordítod egyel, és ott is vársz 2 másodpercet. Ha egyikben sincs 11 állapot stabilan (a kettő között észre tudod venni hogy már megtörtént a mozgás) akkor tudod, hogy melyik tipus. -
válasz
ekkold #16860 üzenetére
Ahogy értem, ez mind a kettő inkrementális AB enkóder.
A feldolgozási logika mindkettőnél ugyanaz, csak a mechanikája az egyiknek egyszeres felbontásra van stabilizálva, a másiknak pedig kétszeresre.
Az elsőnek az a logikája hogy az A jelre "rising" interruptot teszel. Tehát amikor a jel 0->1 átmeneten halad át, akkor hajtasz végre feladatot.
A feladat az, hogy ellenőrzöd B-t. Ha B=1, akkor pozitív irányba történt fordítás, ha B=0 akkor negatívba.
A másodiknak annyival bővül a logikája, hogy az A jelre "falling" interruptot is teszel (a kettő együtt "changing" interrupt).
A logika pedig:
- Ha A=1 és B=1 -> előre fordult
- Ha A=1 és B=0 -> vissza fordult
- Ha A=0 és B=0 -> előre fordult
- Ha A=0 és B=1 -> vissza fordulttovább egyszerűsítve akár a fentit, akár a lentit:
Ha az interrupt eseményben A és B értéke egyezik -> előre fordult, ellenkező esetben hátra.(négyszeres felbontás esetén pedig a B váltásait is lehet figyelni, és eljárni A értéke szerint)
-
válasz
Sebiferi #16835 üzenetére
Az áramváltós és a hall-effektes mérők tudtommal nem tudnak ilyen kis áramokat mérni.
Ez igaz, de sokkal könnyebben meg tudod emelni a rajtuk keresztül folyó áramot, mint hinnéd.
Mondok egy példát:
Veszel egy 5A-es lakatot ami 5mA-re vált. Teszel rá egy terhelőt, ami az 5mA-ből 5V-ot csinál (1kOhm).
Ezt az 5V-ot 1024 felé tudod bontani, azaz az 5A-t is. Az már 4,8mA felbontás.
Ha viszont a vezetékedet 4x viszed át a hurokban (ügyelve az azonos áramirányra) akkor 4x olyan érzékeny lesz, azaz 1,2mA felbontást kapsz.
Ezekben az áramváltókban a vasmag szaturációja a névleges értékre van belőve, afölött nem - vagy nem sokkal nagyobb - feszültség/áram nyerhető belőlük, így amikor a valós 10 amperes fogyasztás megérkezik, nem fog túlfeszültséget okozni a mérő oldalon. (Illetve amit okoz, azt simán elviszed egy ellenirányú 5V-os zenerrel).
A közös nullpont azt hiszem nem lesz gond, ennek (is) utánajártam. Pl. a sonoff cuccok is ilyenek és jól működnek.
A Sonoff cuccokban az ESP-k nem az AC vonallal közösítenek nullát, hanem a dedikált energiamonitorozó chippel (HLW8012). A schematicon ne keverd össze az Earth és a GND pontokat, mert azok nincsenek közösítve. -
válasz
Sebiferi #16831 üzenetére
Az indukción alapuló mérés semmiképp nem megfelelő? DIY esetben a galvanikus leválasztás nem csak az érintésvédelem miatt fontos, hanem mert ha valami zárlatba megy, akkor a hálózati feszültségből elég energia nyerhető a tűzeset kiváltásához. Söntös árammérésnél pedig sorosan kell kapcsolódnod a hálózati feszültségre, ami az egyébként jól működő védelmek egy részét kizárja. Már maga a közös nullapont kialakítása egy DC mikrokontroller és egy hozzá képest lebegő AC között megfelelő elektronikai ismereteket igényel.
Ha egy Arduinoval mész, az 1024 értékre tud skálázni. Ez azt jelenti, hogy 2mA felbontáshoz a max mérhető érték 2A körüli (ha a kvantálás szabályait betartod és valóban 2mA pontosságot szeretnél, akkor persze a mérést 1mA-es, vagy még inkább 0.5mA-es küszöbbel kell végezni, akkor már csak 1A illetve 0.5A körül alakulhat az áram (100-200W körüli fogyasztóra elég).Vannak persze olyan perverz gondolataim, hogy betehetnél egy digitális potmétert a rendszerbe. Ha a potméteren mért feszültség a szélső 20%-ok felé jár, akkor programatikusan állítasz az ellenállásosztáson. Ezt a kódban ismerve megvan a dinamikus szorzó a pontos érték visszaszámításához.
-
-
Távolról sem kell 3byte wear counter
Ha valós wear-counter van, akkor hogyan számolod 100.000-ig, hogy hányszor írtad azt az adatcsomagot? Vagy csak sima load-balancera gondolsz? Mert persze, akkor elég csomagonként egy bit, ami jelzi hogy hol írtál legutoljára. Csak a kolléga mindent IS számolni szeretne, pont egy ilyen kritikus dolgot ne tartana számon?
-
Wear levelinggel valóban több, de messze nem örörkélet (persze lehet, hogy rosszul számolok):
10.000 órát percalapon tárolva kell 3bájt, és ő akar 3 számlálót párhuzamosan az 9.
A wear-leveling miatt minden ilyen 9 bájtos blokknak kell egy - jól optimált esetben 3bájtos wear-counter.1024 / 12 az cca. 85. Beszorozva ezt az 1666 órával kb. 16 év jön ki. Tiszta üzemórának véve ez már van olyan sok, hogy cserélni kelljen a kapacitorokat is, de reálisan rövid ahhoz, hogy szem előtt legyen tartva.
A kérdés, hogy mi a projekt tervezett élettartama, és hogy 10+ év távlatban mi a fenntarthatóbb: A uC cseréje, esetleg egy külső EEPROM cseréje, vagy a kondenzátoroké. -
-
Teljesen jogos a kérdés, bennem is megfordult már, amikor láttam a 10másodperces áthidalási igényt korábban.
Dißnäëß
Egy Arduino 3.3ms alatt ír egy bájtot. Tegyük fel, hogy ennyi kell egy ESP-nek is (úgy gondolom, az gyorsabb, de számoljunk a legrosszabb esettel).
Legyen szükséged 8 bájtra, az 26,4 ms.
Az ESP8266 tombolás közben 400mA-t tud fogyasztani - ez megint a legrosszabb eset. Idleben, bekapcsolt rádióval is 80mA körül eszik csak.
Számoljunk 5V-os táppal - bár az ESP 3.3V-al megy, de gondolom a modulon LDO van, ami veszteséggel konvertál, így marad az 5V.5V-on 0,4A az 2W
2W-ot 26,4ms-ig fenntartani kell 0.0528J energia.
0.0528J energiát egy 5V-os kondenzátorban 4224uF-al tudsz tárolni.
Persze a kondenzátor feszültsége folyamatosan esik energia leadása közben, az akksikkal ellentétben egészen nulláig. Az LDO miatt pedig ez azt jelenti, hogy kb. 25%-át tudod elfogyasztani a kondiknak.
Tehát vagy négyszerezed a kapacitást, és mondjuk használsz 2mF-od, vagy használsz 5000uF-ot és valami jó boost convertert.
Esetleg ha nagyobb feszültségű tápod lesz valahol, pl. 12V akkor tegyél 16V 5000uF-ot (0,36J). Annak már ki tudod használni a bő 2/3-át, ami 0,24 J, azaz bő négyszerese amire szükséged van.Ebben a pesszimista helyzetfelmérés miatt már jó kis biztonsági tartalék is van.
Hasznos linkek:
[Energia számoló teljesítmény és idő alapján]
[Kondenzátor kapacitás számoló energia és feszültség alapján] -
-
válasz
Janos250 #16737 üzenetére
Én úgy gondolom, hogy azért bukik meg a validáción, mert maga az .ino fájl plain-text dokumentumként nem szerepel egyik webes szabványban sem.
Emiatt - még ha valószínűleg a nagyobb böngészők ismerik is - nem következetes az, hogy minden eszközön/böngészőben ugyanúgy jelenik meg, vagy ugyanazt a hatást indukálja.
-
Nem úgy értettem, hogy csináld újra.
ESP-ből tudsz csinálni egy dongle-t, amit USB-n a leonardora dugsz. USB hosztként felismeri a Leonardot, mint egy kontrollert, és bluetoothon emulál egy BT-s kontrollert, amire proxyzza a már elkészült eszközödet.
Más megoldást nem fogsz találni az adott problémára:
A Leonardon csak USB van szabad -> az USB-t protokoll szinten nem tudod átvinni BT-on, tehát kell egy aktív eszköz, ami fordít USB-ről BT-ra. -
Plug-and-play megoldás sokáig nem létezett, majd az igényt felismerve az egyik kedvelt youtuberem csinált, azt hiszem meg is veheted tőle, vagy megycsinálhato magad is.
[Cheap USB Host Microcontroller [CH559, ESP32, HID]]Szerk.: Bocsi, azt elfelejtettem hozzátenni, hogy ez csak az USB-host rész. De utána ebből BT kontrollert csinálni már csak egy lépés: [link]
Szerk2.: A Blitzwolf cucc az csak audio. -
Pontosan milyen Arduino, és mit szeretnél az USB átvitel közben megoldani?
Ha sima Uno/Nano/Mega, ott amúgy is az Rx/Tx-en van az USB egy USB-Serial chipen keresztül. Ha arra az Rx/Tx-re felteszed a BT modult, akkor utána tudsz vezeték nélkül kommunikálni. A programozás is megoldható.
Persze az ajánlott ESP-vel egyszerűbb a dolog. Ott van OTA is.
Ha valami komolyabb USB protokollt (pl. HID) akarsz átvinni bluetoothon, az már annyira nem evidens.
-
válasz
tibi-d #16706 üzenetére
A wifi eléggé kézenfekvővé teszi az Esperif SoC-it.
Ha kell a 12bit analógnál jobb, akkor tehetsz mellé külső ADC-t.
A 4 digit jel valamilyen periféria? Van előírt jelszint? (5V / 3.3V)Az érintőképernyő csak kezelőfelület lesz, vagy aktív kijelző is lesz? Képfrissítés miatt kérdezem.
(Damn 4 másodpercet késtem :D)
-
-
-
válasz
Undoroid #16656 üzenetére
Annyit szólnék bele a dologba, hogy az Arduino Nano-n van gyárilag LDO, emiatt a VIN-nek papíron 6V-20V, gyakorlatban 7V-12V betáppal mennie kell, ha nincs extra terhelés az 5V-ján.
(Szerk.: Innentől Szancsó-nak):
De ha nagyon akarod, akkor beiktathatsz egy külsőt is, akár 5V-osat is, de akkor már ne a VIN-en táplálj. Vagy tegyél be egy 7809-et, és a 9V-ot vidd az arduino VIN-jébe. Ez utóbbi azért javallott, mert kevesebb lesz az ohmos ellenállás a stabkocka és a fogyasztó között.Ha pedig mindenképp step-down-al akarod megoldani, akkor vegyél egy nagyobbat, lehetőleg olyat, aminek tisztességes pufferkondi van a kimenetén, és csinálj vele egyből 5V-ot.
(Bár ha nem akksis felhasználás lesz, akkor mehetsz stabkockával, mert hiába fűtöd el a 60%-ot, arányaiban és abszolút értékben is minimális a nyereség a LED-ek fogyasztásával összevetve.) -
válasz
tonermagus #16632 üzenetére
Nekem anno azt mondta az egyik tanárom, hogy mindig van jobb, olcsóbb meg gyorsabb. A jó mérnök nem az, aki mindenből a legjobbal dolgozik, hanem aki tudja, hogy mibe fektesse a leghasznosabban a forrásait.
Ha valóban szükséged lesz valami miatt platformot váltani, akkor pedig majd fogod tudni, hogy mit keress, mi az amiből jobb kell.
-
válasz
tibi-d #16591 üzenetére
A 2560-ra tudsz kódot feltölteni, vagy pont az lenne a pláne, hogy a babrálása nélkül másold ki az eeeprom-ot?
Előbbi esetben csatold a külső eepromot i2c-n, és byte-ról bytera írd át rá a belső eepromot.
Utóbbiban kell egy icsp programozó (egy másik arduinobol is tudsz csinálni) avrdudával kiolvasod az eepromot, aztán pedig felírod egy olyan arduinoba, aminek babrálhatod a kódját, és goto:előbbi eset.
-
válasz
Dißnäëß #16490 üzenetére
Igen, saját eepromba mentem unsigned long-ban (4byte) tárolom másodperc alapon. Cca. 130 évig elég.
De ha nem megy várhatóan többet szumma 49 napnál, akkor nyersen a millis értékét is beleteheted.Szerk.: EEEPROM.write és EEEPROM.read használatával ki tudod olvasni a byteokat (mondjuk fixen az eeeprom első 4 byteját használod erre) kiolvasod az elsőt, eltolod 8 bittel, hozzáadod a másodikat, eltolod 8 bittel, stb.
-
válasz
Dißnäëß #16488 üzenetére
Szia!
Én egy projektben úgy oldottam meg, ezt, hogy:
- Leválasztottam az MCU tápkörét egy diódával és tettem egy nagy kondit mellé, hogy csak az MCU-t táplálja, a többi fogyasztót ne.
- Figyeltem a betáp feszültséget egy interrupt lábbal
- Ha leesett a betáp, akkor felírtam eepromba az üzemidőt, amíg a kondi élve tartotta az mcu-t.Én erre mondjuk nem használtam RTC-t, csak az arduino saját számolását, ami pontatlanabb, de amire kellett, arra még úgyis bőven elég. Illetve én leherpákoltam minden LED-et róla, mert a fogyasztás jelentős részét azok tették ki.
Szerk.: Ha graceful shutdown-t használsz, akkor nem kell még a kondival sem foglalkozni. -
-
-
Új hozzászólás Aktív témák
Hirdetés
- EAFC 25
- Milyen videókártyát?
- A Fehér Házban marad a Starlink Trump és Musk rossz kapcsolata ellenére
- Hobby rádiós topik
- Kazy Computers - Fehérvár - Megbízható?
- Fotók, videók mobillal
- Kecskemét és környéke adok-veszek-beszélgetek
- Lakáshitel, lakásvásárlás
- Azonnali notebookos kérdések órája
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- További aktív témák...
- BESZÁMÍTÁS! 2TB Kingston KC3000 NVMe SSD meghajtó garanciával hibátlan működéssel
- Lenovo Legion 5 Gaming. Az ár irányár, komoly érdeklődés esetén van lehetőség egyeztetésre
- BESZÁMÍTÁS! 2TB Samsung 980 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- AKCIÓ! "ÚJ" Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
- Bomba ár! Lenovo X1 Yoga 2nd - i7-7G I 8GB I 256SSD I 14" WQHD Sérült I W11 I CAM I Garancia!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest