- Garmin topik
- Külföldi SIM-ek itthon
- Azonnali mobilos kérdések órája
- One mobilszolgáltatások
- CMF Phone 2 Pro - a százezer forintos kérdés
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Netfone
- Mobil flották
- Xiaomi 15 - kicsi telefon nagy energiával
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
-
Mobilarena
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
-
gyapo11
őstag
válasz
ecaddsell
#12552
üzenetére
A 4 MHz 40-szerese a 100 kHz-nek, az órajel pedig nem annyival gyorsabb (80-240 MHz). Az én ciklusomban azt hiszem volt egy if is, ami valahány váltásonként kiírt valamit.
Nem ledvillogtatót szeretnék, hanem tudni, hogy kb. mire számíthatok pollozással, hogy eszerint válasszak processzort.
Játszottam kicsit egy nanoval interruptosat, és furcsa dolgok történtek, kétszer írta ki azt amit csak egyszer szabadott volna. Pedig az interruptot azonnal letiltottam amikor beérkezett a jel. Szóval nem értettem mi történik, és így nem tudom használni az irq-t. -
gyapo11
őstag
Ha valakinek van egy nagyobbacska programja arduinoban, kíváncsi lennék a loop időre, hogy 1 másodperc alatt hányszor fut le. Egyszer egy számláló cikussal mértem, az 100 kHz fölött volt kicsivel, nyilván egy több soros program lassabb. Akár ez a legutóbbi Nyirike hőmérő, vagy egy programozható ledszalag meghajtó, ilyesmi.
Érdekelne még az esp32 és stm32 is, hogy ott az órajel többletnek megfelel-e a loop idő rövidülése.
Persze csak delay nélküli programok játszanak, illetve esp32-n talán még ez se akadály a két mag miatt. -
gyapo11
őstag
válasz
Janos250
#12545
üzenetére
Már megérte, hogy itt vagyok.
Aryes: szívesen, én analóggal kezdtem, AC125 germánium tranzisztor, zéner, kondi, relé, exponáló óra az Ezermesterből, de sajnos nem működött, viszont nem adtam föl.
És javaslom a feszültségben gondolkodást. Először én is áramban akartam látni az áramkörök működését, de úgy nehezebb. A feszültség lent meg fönt sokkal közelebb van a digitális áramkörökhöz is.
-
gyapo11
őstag
Ha az emitteren kicsi ellenállás van, ami már meghaladná a tranyó kollektor-emitter áram képességét, akkor persze tönkremenne, tehát erre figyelni kell. A bázis oldalon lehetnek tized Ω-ok is. Miért? Mert a bázis nem vesz föl több áramot, mint az emitteráram bétáadnyi része.
Van egy szabályozó tényező, az hogy az emitter mozogni tud feszültségben le-föl és a bázis-emitter feszültség igyekszik 0.7 V-on maradni.
A bázisba a tized Ω nagyon sok áramot be tudna tolni ha pl. hirtelen ugrik ott a feszültség fölfelé, de ahogy nő az áram, a kollektor-emitter vonalon több áram kezd folyni, ettől az emitter emelkedni kezd (követi a bázist), és a bázis-emitter feszültség tartja a 0.7 V-ot, mert az emitter emelkedésével a tranzisztor nyitni kezd. Ha csökken a feszültség a bázison, akkor meg a B-E feszültség 0.7 V alá megy, a tranzisztor nyitni kezd, a kollektor-emitter áram csökken, ettől az emitter lefelé indul, a B-E feszültség nő és 0.7-nél beáll a követett állapot. Tehát az emitter mindig szigorúan követi a bázis mozgását.Ha az osztó korlátozza a bázisáramot, nem ugyanannyi áram "folyik el" a mért körből?
Az osztón átfolyik a bázisáram is meg a kollektor-emitter áram is. De a bázisáram az bétáadnyi, több százas bétánál a kollektor-emitter áram több század része, és nem az osztó korlátozza, hanem a föntebb leírt folyamat, a B-E feszültség 0.7 V-on tartása.
Ha pl. változatlan bázis feszültségnél ráteszel egy négyszögjelet az emitterre, és méred a bázisáramot szkóppal, akkor ugrálni fog le-föl.
Kb. hasonló elven működik a földelt bázisú kapcsolás, amikor a bázis földre van kötve és az emitterre adjuk a jelet, ami erősítve jelenik meg a kollektoron. -
gyapo11
őstag
válasz
Nyirike
#12540
üzenetére
Tehát van egy mért táblázatod, és ezzel hasonlítottad a függvény értékeit. Ha én csináltam volna ilyet, akkor kb. 3 állapot lenne, alacsony, jó, és magas.
Vagy használod valamire a infót? Hogy pl. nem 90 fokos a víz hanem 80 vagy 70, függ ettől valami? De alkotásnak/gyakorlásnak jó kis project. -
gyapo11
őstag
Azt nem tudok, de elég egyszerű. Van egy feszültség, amit le akarunk követni minél kisebb terheléssel. A tranyó bázisa rajta van a mérendő ponton, az emittere meg ~0.7 V-tal lejjebb követi. Az emittert már lehet terhelni. Mi történik ekkor? Az emitter felé elindul a terhelő áram, de ezt nem a bázison keresztül kapja a mérendő pontról, hanem a kollektorból a tápról. A bázison csak emitter áram/béta áram folyik.
-
-
gyapo11
őstag
válasz
Nyirike
#12527
üzenetére
Igen, az emitter követőt kipróbálhatod, de közben rájöttem, hogy nem az osztott értékre kell kötni, hanem az osztó tetejére, és akkor szinte mérhetetlenül kis mértékben fog beleszólni a feszültségviszonyokba. Jó nagy bétájú tranyó kell hozzá, esetleg lehet darlington is.
A számolás elég egyszerű, van egy 90 Ω, ezzel sorban a termisztor. Ott van még a műszer is, amiről nem tudunk semit, hogy milyen ellenállása van és hogy lineáris-e. De ha nem lenne ott, akkor a soros kapcsolás miatt a termisztoron mérhető feszültség:
U(t)=R(t)/(90+R(t))
Azt figyelembe kell venni, hogy a tranzisztor bázis-emitter diódáján esik kb. 0.7 V feszültség, tehát az osztóra ennyivel kevesebb kerül, a termisztoron 0.7 V az már 0 lesz az osztón.
-
gyapo11
őstag
Akkor be kell tenni egy emitter követő tranzisztort, az bétával szorozza az osztóról érkező áramot. Tehát egy 500 bétával rendelkező tranzisztor bázisát a két ellenállás közös pontjára, az emitterét az arduino bemenetére (ide esetleg még egy szivárgó áram elleni 1 MΩ-ot is), a kollektorát meg 5 V-ra. Az osztási arány ugyanannyi, de az ellenállások értékét meg kell szorozni bétával, vagyis 500-zal, akkor a fölső ellenállás 500 kΩ, az alsó meg 165 kΩ. Nem tudom mennyi az arduino bemenő ellenállása, esetleg azt is bele kell számolni.
-
gyapo11
őstag
válasz
Nyirike
#12519
üzenetére
Szerintem az a 90 Ω a tápra elég kicsi ahhoz, hogy az arduino analóg bemenete nem dumál bele. Szóval a TH pontra tegyél egy osztót, pl. 1 KΩ és 330 Ω, a 330 alsó lába testre, és a két ellenállás közös pontjára az arduino bemenet. Így még egy gázfröccs esetén sem lépi túl az 5 V-ot a feszültség a bemeneten, még akkor sem, ha leszakad a termisztor és a teljes táp megy az osztóra (14.4 V).
-
gyapo11
őstag
válasz
Janos250
#12512
üzenetére
Ez jó, meg tudom írni.
Mit lehetne kitalálni az ellen, hogy az első próbálkozásra pont eltalálja a helyes kódot? Ennek persze iszonyat kicsi az esélye, de nem 0.
Olyasmire gondoltam, hogy a kód hossza is változzon minden adásnál, de ezt is eltalálhatja. Vagy egyszerűen csak legyen jó hosszú a kód, és ezzel jó kicsi az esély? -
gyapo11
őstag
válasz
ecaddsell
#12511
üzenetére
A törés nálam azt jelenti, hogy nem tudja a kódot, ezért más módon jut hozzá a dekódolt tartalomhoz. A brute force meg azt, hogy a lehetséges összes kódot végigpróbálja, és valamelyik betalál.
A véletlen számokat nem lehet törni, végig kell próbálgatni mindet. Minél több a byte a kódban, annál tovább tart. De már az első helytelen után leáll a folyamat, mert utána már kettőt vár a vevő.
A public kulcsos mókát nem tudom megírni, az egészben meg az a poén, ha én meg tudom csinálni, max a flash ic írás-olvasásához használok mások által megírt libraryt. -
gyapo11
őstag
Kerestem arduino+infra projecteket, de az első oldalon mindegyik gyári távirányítót olvas, esetleg annak megfelelő jeleket ad ki.
De én sajátot szeretnék, pár byte-ot szeretnék küldeni és azt venni. Ez egy törhetetlen távirányító lenne, mert a benne levő adatsor véletlen számok halmaza, senki nem fogja tudni egy esetleg leolvasott számból, hogy mi lesz a következő, ezt csak az adó meg a vevő tudja.
Ez az egyik része, hogy adni-venni kell byte-okat.
A másik az, hogy nyilván sok byte kell, hogy sokáig ne ismétlődjön a kód, tehát kell egy flash ic tárolónak, ez gondolom nem lesz nagy kihívás.
Viszont előfordulhat, hogy megnyomkodom az adót a vevőtől távol, és a következő kód már nem az lesz, amit a vevő vár. Erre azt találtam ki, hogy a vevő elutasítja a kódot, ekkor újra megnyomom az adón a gombot de hosszan, amire két egymást követő kódot küld, amit a vevő megkeres az ő tárolójában (valószínűleg 1-2 kóddal tovább kell lépnie), és ha talál ilyet, akkor elfogadja a kódot.
Jó-e ez, vagy van jobb ötlet?
Lehetne rádiós is, de amikor játszottam a TSOP IR vevővel, annyira jól és érzékenyen működött, hogy a szoba bármely pontjára lőttem az adóval, mindig jól vette a kódot, másrészt nem lehet olyan könnyen zavarni, mint a rádióst, és talán leolvasni sem, bár itt az mindegy. -
gyapo11
őstag
válasz
JozsBiker
#12481
üzenetére
Mennyire van szinkronban a mérés a frekvenciával? Ha nincs, akkor össze-vissza értékek lesznek. Érzékeld a 0 átmenetet és utána mérj 5 ms-mal amikor csúcson van a szinusz. Ha 0-át mérsz, akkor vagy nincs áram, vagy a negatív félperiódust mérted, végezz új mérést 10 ms múlva a pozitív félhullám tetején.
-
-
gyapo11
őstag
válasz
cog777
#12483
üzenetére
Lehet logikat modositani ugy hogy nem inditod ujra?
Nem tudom, a plc-khez én se értek, de ilyet szeretnék. Inkább egyszer dolgozzak vele többet, mint minden apró módosításnál mindent leállítani, mert jön a reset.
Ha egy szelep megszűnik a programban, akkor nincs mit tenni, le kell választani a hardware-ből és vége. Esetleg azt a portot megkapja valami más, szóval veszélyes is lehet otthagyni és nem rácsatlakoztatni az új eszközt. Ha változik a hw, akkor az már nem annyira simple user feladat.
Ezt a módosítást kifejezetten arra az esetre gondolom, amikor apró változtatások kellenek, mert nem jól találta ki a user, hogy 1 percig világítson a lámpa vegy kettőig. Még az is lehet, hogy ezek a paraméterek egy külön adatblokkban csücsülnek, és a parser onnan olvassa ki az adott sor értelmezésekor, így még könnyebben módosíthatók. Az időzítő minden beolvasáskor összeveti a futó időt a fölső határral, és ha túllépte egy adatmódosulás miatt, akkor leáll. Abban az egy loopban lehet, hogy hosszabb lesz, de a következőben már jó.Pl 3 blokkbol egyet kitorolt a felhasznalo. Mi legyen ha eppen a masodik volt futas alatt. stb.
Szerintem megvárnám a loop végét, és akkor olvasnám be a programot, illetve az elején a változásokat, amit még a pc írt oda, hogy ne az arduinonak kelljen kitotózni, hogy a változások milyen portokat érintenek. A megszűnő vagy megjelenő eszközök portját, alapállapotát, időzítőket, hogy amikor a parser elölről kezdi beolvasni a sorokat, akkor már minden be legyen állítva. Az időzítőkön még gondolkodnom kell, ott még nem látok tisztán.
Mindenképpen megjegyzem az esp32+python ajánlást. Mindkettő ismeretlen egyelőre, jócskán kell tanulnom hozzájuk, de a jövő arrafelé mutat.
-
gyapo11
őstag
-
gyapo11
őstag
válasz
cog777
#12478
üzenetére
A python egy programnyelv. Akkor az esp-ben a python értelmező futna, és byte kód helyett python forrást kellene átküldeni? Ez azzal járna, mintha arduino forrást vinnék át, vagyis reset. Ha egy csomó kapcsoló, relé, triak, szelep, motor van valamilyen állapotban, időzítők futnak, akkor egy reset nem túl jó. Ha elmentem az állapotokat, és reset után beolvasom, akkor talán folytatható minden ugyanonnan, de ezt ha lehet elkerülném. Lehet olyan program, ahol semmi ilyesmi nincs, ott nyugodtan lehet resetelni.
Az alapötlet az, hogy nem vadi új programokat töltök rá, hanem az ott levőt kicsit változtatva. PL. hozzáadok új feladatokat vagy törlök másokat, ez az egyszerűbb, a bonyolultabb, hogy meglévő feladatok változnak, ezen még gondolkodnom kell hogyan tudom egyeztetni az aktuális állapotot az új részekkel. Pl. megy a szivattyú 5 perc időzítéssel, most 3 percnél tart, az új programban viszont 7 vagy 2 perc időzítés van, egyiknél 2 perccel meg kell hosszabbítani az időzítést, a másik esetben viszont azonnal ki kell kapcsolni a szivattyút.
Lehet, hogy ezt is a pc-vel kell feldolgozni, és infót tenni a byte kód mellé, hogy mit kell csinálni, jobb ha nem akarom ezt is bezsúfolni az arduinoba. -
gyapo11
őstag
Scratchet láttam már, képernyőn mozgott ez-az, azt nem tudtam, hogy program kimenete is van, ez akár még használható is lehet. Az xml-ből csinálhatok könnyen értelmezhető tömör byte kódot. Meg kell néznem ezt a scratchet közelebbről, elsőre nem tűnt túl egyszerűnek a frontend. Persze nem vagyok már gyerek.
A lego robotjának is valami grafikus összetologatós frontendje van, de épp csak futólag láttam.
Nekem is a saját nyelv jutott először eszembe, csak nem a hagyományos programnyelvekhez hasonló de szűkített utasításkészlettel, hanem minél közelebb az emberi nyelvhez, hogy a programozáshoz legkevésbé értő emberek is tudják használni. Még talán az is hasznos lenne, ha lenne egy arduino forrásnyelvű kimenet is, amit csak bele kellene tölteni az IDE-be, onnan lefordítva az arduinoba, ez is sokaknak segítség lenne. -
gyapo11
őstag
válasz
robohw
#12475
üzenetére
Szeretnék elszakadni a programnyelvektől, mert az sok embernek nem megy. Egészen emberközeli utasításokat kell feldolgozni. Itt a fórumon is jó párszor volt kérdés, hogy nem vállalná-e valaki erre vagy arra a feladatra megírni a programot. Az emberek szívesen használnának egy ilyen olcsó és jó kis eszközt mint az arduino, de a c vagy c++ nyelv már probléma.
Éppen ez lesz a legnagyobb nehézség is szerintem, hogy az élő beszédből hogy csinálok a pc-n futó compilerrel olyan byte kódot, ami egy programnyelvet helyettesít és az arduinoban futó program értelmezni tudja.
Generálhatnék arduino kódot, és akkor nem kell az értelmező, de az nehezíti a betöltést, és főleg a betöltés közbeni futást.
Meg az ipari plc-k is hasonlóan működnek, nem bízzák a felhasználóra a processzor által futtatott kódot, azt megírják a fejlesztők, a felhasználó meg a létradiagrammal adja meg a feladatot. Ezt a létradiagramot akarom én helyettesíteni egy még könnyebben megérthető nyelvvel.
És hogy még nehezebb legyen, nem egy feladatot szeretnék elvégezni, hanem többet. Egymás után jönnek a feladatok a loopban, és sorban hajtja végre az értelmező. Tehát a fűtés vezérlése és a lépcsőt megvilágító lámpa kapcsolása az nem két arduino, hanem két feladat.
hőfok=ai1, fény=di1, kazán=do1, lámpa=pwm1
ha hőfok<20 fok kazán bekapcsol
ha hőfok>21 fok kazán kikapcsol
ha fény=0 lámpa=200 bekapcsolMi ez a wireless adapter? Byte kód átvitelre kell. Egy rf adó-vevő modulpár nem tudom elég megbízható átvitelt tud-e.
A byte kód miatt várhatóan elég kevés adatot kell hordozni, ha 10 byte egy feladat, akkor 20 feladat elfér 200 byte-on, ami már azért elég sok mindent lefed, még a hűtőt is lehet vezérelni, akár egy riasztót pár szenzorral stb. -
gyapo11
őstag
válasz
robohw
#12469
üzenetére
Még a basicnél is sokkal egyszerűbb nyelvet szeretnék, input/output melyik portra mit, feltételek, időzítés, mindezt byte kódokkal. A kódolást ugyanis pc programmal szeretném megoldani, ott valami emberközeli beviteli móddal, aztán ez állítja elő az arduinoba töltendő kódot. A cél az is lenne, hogy programozni nem tudó emberek is tudjanak működő kódot gyártani.
Tehát valaki kiteszi a kertbe a cuccot, méri a talaj nedvességet, hőfokot, és beállított feltételek alapján be-kikapcsolja az öntözést. Ha nem jó, a pc-n módosítja, kiírja az adathordozóra, odamegy az arduinohoz, rádugja, beolvas, kihúzza, kész. -
gyapo11
őstag
Van egy régi elképzelésem, hogy csinálok egy home plc-t. Két dolog nem tiszta, a software, de azzal majd birkózok, és hogy milyen módon vigyem a pc-ről a programot a plc-re. A plc persze arduino lesz, és nem a pc mellett, tehát a kábeles kapcsolatot kizártam.
Lehet sd-kártya, vagy egy kis panelen iic flash vagy eeprom, amit a pc is tud kezelni meg az arduino is, valami tüskesorral vagy élcsatlakozóval. Ha van jobb ötlet, írjátok.
Az adathordozó föl- vagy lecsatlakozásakor nem szabad leállítani a plc programot, az fusson az eredeti programmal. Valahogy detektálni kell az új adat megjelenését, beolvasni az új programot, és onnantól azt futtatni. Ekkor már le is lehet húzni a tárolót.
A program nem arduino kód lesz, hanem tömény adat, még ezt sem tudom hogy hova fog kerülni, valószínűleg az arduino eepromjába, és egy arduino kódban megírt értelmező fogja értelmezni.
Szóval milyen megoldást javasoltok a kód hordozására? -
#12428
gyapo11
őstag
férfiállat
#12422
gyapo11
őstag
válasz
férfiállat
#12422
üzenetére
Ha 0 a hardware és software ismeret, akkor szerintem érdemes előbb azokkal kezdeni, mert semmi nem fog működni az arduinon. Kész projectet letölteni a netről és betölteni az arduinoba menni fog, de bármi változtatás már nem.
A software résznél nézegetni kell sok kis példaprogramot és megérteni a működést. Pl. én nem tanultam c-t se meg c++-t se, basic, pascal, fortran, clipper, assembly pár processzorra, de ezekből már el lehet indulni. Ja és sokszor semmit nem értek abból amit itt a kollegák mutatnak, nagyon alap tudással is lehet boldogulni.
Ott van a 13-as porton a led, egy másikra lehet tenni egy csipogót, harmadikra nyomógombot, analóg bemenetre potmétert, pwm kimenetre ledet, ezekkel már lehet ügyeskedni.
Hardware téren meg a külvilággal való kapcsolatot lehet kezelni, akár ki vagy befelé. Érzékelők kellenek, vannak készen kapható kis modulok, ezekkel kevesebb a gond. Kimenetként relés modul. Ha megy a tranzisztor, fet vezérlése, akkor már sok mindenhez lehet illeszteni. -
gyapo11
őstag
Bevezető: valamikor régen volt egy olyan házi feladat, hogy számítógép program kap egy év-hónap-nap adatot, és írja ki, hogy az a hét melyik napja. Valamelyik HP számológép doksijában találtam egy képletet erre, 2 sor volt.
Most azon gondolkodom, hogy arduinoval szeretném tudni, hogy az adott napon (itt elég a hónap-nap) mikor van napkelte-napnyugta (itt Magyarországon). Egyik lehetőség, hogy beírom a flashbe ha belefér.
Másik lehetőség, hogy a téli meg a nyári napfordulótól kiszámolom hányadik nap van, és valami átlagos napi lépésekkel kivonok vagy hozzáadok perceket.
De van-e esetleg egy ilyen csodaképlet, amivel 2 sorból kijön az adat? -
gyapo11
őstag
válasz
puritan
#12272
üzenetére
A NAT-ot derítsd ki először, mert ha ott vagy és nem tesz át a szolgáltató publikusba, akkor nem kell a dinamikus dns-sel szórakozni.
Én az ip8.com-ot szoktam használni, most 85.66.x.x a címem, ez publikus, a netről elérhető. A router NAT-ja mögötti címem meg 192.168. 1.44 ezt nem lehet a netről elérni. Azt hiszem szokásos még a 10.x.x.x NAT-olt címtartomány is. -
gyapo11
őstag
válasz
puritan
#12263
üzenetére
Dinamikus IP-re vannak serverek, pl. noip.com. Kell egy klienst futtatnod, ami időnként följelentkezik, és közli az IP-címedet a serverrel, ezután már megy is az elérés, a neved.no-ip.org címen az otthoni eszközöd fog válaszolni. Router is tudhatja managelni az egyes dyndns servereket.
De ha NAT mögött vagy és nem kapsz publikus IP-címet a szolgáltatótól, akkor csak a pollozás marad. Egy webserverre teszel egy kis php kódot, otthonról indítod időközönként, ez csak annyit csinál, hogy ha beérkezett az előző indítás óta parancs, akkor azt megkapja. A világból pedig ezt a servert eléred, és a parancsot ide küldöd. Otthonról küldhetsz állapotjelzést is amit a világból leolvashatsz.
Ennek előnye, hogy mindig működik mindenhonnan, de amilyen sűrű a pollozás annyi időt kell várni a parancs végrehajtására. Ha percenként pollozol, és egy indítás után 1 másodperccel érkezik be a serverre a parancs, akkor csak 1 perc múlva történik a végrehajtás. Van amihez ez elég, de ha a kapu előtt állsz és nyitnád a zárat, akkor lassan fog eltelni az 1 perc. Persze egy url kiküldése nem olyan sok byte, a válasz is lehet 1-2 karakter, szóval akár másodpercenként is lehet pollozni. -
gyapo11
őstag
Ha a letöltési helyen vagy hozzácsomagolva nem tiltják, akkor igen, fejleszthetsz vele olyat, amit pénzért adsz el, mivel saját szellemi terméked.
Mint ahogy egy kalapácsot megveszel és dolgozhatsz vele pénzért.
De ha pl. ott van, hogy csak saját használatra free, akkor már problémás, mert amíg saját célra készítesz programot vele, addig OK, de ha pénzt keresel vele, az már nem, hiába akkor is a te szellemi terméked. Pont azért tesznek ilyen kikötést, hogy te szabadon megismerhesd, megszeresd, és akarj vele készült programokkal keresni, de akkor már kérik érte a pénzt. -
gyapo11
őstag
válasz
zsolti_20
#12212
üzenetére
Az összes programozó ezt csinálja, akár free akár fizetős a fejlesztő környezet, az abban készült saját szellemi termék vagyis a program szabadon értékesíthető. Ha kellene a futtatáshoz valami lib akkor kellene utánanézni, hogy az mellékelhető-e, illetve hogy ingyen vagy pénzért is. De arduinonál nincs ilyen kérdés.
-
gyapo11
őstag
válasz
Janos250
#12156
üzenetére
Sokszor az Ali, néha az Ebay az olcsóbb. Banggood Gearbest csak kuponnal tud labdába rúgni. Sajnos az utóbbi pár hónapban sorra refundoltattam a vásárlásaimat Alin mert nem érkezett meg 60 nap alatt. Nyomkövetés nélküliek voltak, kis értékűek. Szerencsére szépen visszafizetik, de akkor is bosszantó. Banggoodos vásárlásom is járt így, volt rajta biztosítás, újraküldték trackinggel, az 2 hét alatt megérkezett. Szóval úgy néz ki, hogy meg kell drágítani a vásárlásokat nyomkövetéssel vagy biztosítással, hogy több esély legyen a megérkezésre.
-
gyapo11
őstag
válasz
vargalex
#12068
üzenetére
74VHC123AFT akadt elsőre a kezembe, 4 μA standbyban. Mos fet szintén pár μA lehet. De nem is csak az arduino fogyaszt, mert mi van az rf modullal és a hőmérőkkel ha a táp rajtuk van, és még ott van a táp konverter modul alapárama is. Legyen mondjuk 10 μA, az 2000 mAh kapacitást feltételezve 240000 óra, ami 27 év készenlét. Persze ez se igaz, mert mérni kell az időt ami valami oszcillátorral meg számlálóval megy, szóval több lesz azért a fogyasztás.
-
gyapo11
őstag
válasz
Tankblock
#12063
üzenetére
Fetre szavazok én is, nem kell altatni, hanem 5 percenként rákapcsolni a tápot. Elindul, mér, adatot küld és kikapcsolja magát. Fet vezérléséhez cmos ic-k. Így két mérés között nem fogyaszt az arduino, az rf modul, a hőmérő, a táp konverter, csak a cmos ic-k meg a nyitott fet.
-
#11970
gyapo11
őstag
tonermagus
#11968
gyapo11
őstag
válasz
tonermagus
#11968
üzenetére
Mekkora feszültségesést akarsz megengedni és milyen hosszú a tápvezeték? Ha jól emlékszem 16 A/mm2 az ajánlott minimum rézre, ez valami melegedéses számolás eredménye, de a feszültség szerintem lényegesebb a lednél, és ahhoz kell számolni a vezeték ellenállását, ami ugye nem csak az átmérőtől hanem a hossztól is függ.
-
gyapo11
őstag
válasz
zsolti_20
#11784
üzenetére
Nem tárolja az időt, hanem jár az óra. Ha beírsz egy dátumot-időt, akkor onnantól jár, ha egy másikat akkor onnantól. Mivel van ott egy elem, akkor is jár tovább, ha az arduinotól nem kap tápot.
Az arduino és a timer modul függetlenek egymástól, csak akkor kerül át idő a modulba, ha a megfelelő utasításokkal beleírod, és akkor kerül át az idő az arduinoba ha a megfelelő utasításokkal kiolvasod. -
gyapo11
őstag
Nincs gyakorlatom a wifizésben, csak logikai alapon, ha beírod az eepromba a lehetséges routerek ssid-it, és addig próbálgatsz kapcsolódni, amíg meg nem találja a helyeset, az nem jó? Vagy írni egy programágat, amivel be lehet írni a helyes ssid-t az eepromba, és utána futtatni a kapcsolódási kísérletet. Persze az ssid-t az eepromból kell kiolvasni.
-
#11618
gyapo11
őstag
balintarduin
#11612
gyapo11
őstag
válasz
balintarduin
#11612
üzenetére
Kiolvasod az időt az óramodulból, beteszed 6 byte típusú változóba úgy, hogy órák tízesei, órák egyesei, percek tízesei, egyesei, másodpercek tízesei, egyesei. Ezután a millis()-t figyeled, és mindig amikor 1000-rel több az értéke, akkor kivonsz egyet a másodpercek egyeseiből ha még legalább egy az értéke. Ha 0 volt, akkor 9-et írsz bele és eggyel csökkented a másodpercek tízeseit ha legalább egy az értéke. Ha 0 volt, akkor 5-öt írsz bele és eggyel csökkented a percek egyeseit, ha legalább egy az értéke.
Ezt így végigfuttatod az órák tízeseiig, és még léptetsz egy számláló változót is, hogy 295 lépés után, ami 4 perc 55 másodperc befejeződjön a folyamat. Ha nem 4:55-ig tart a folyamat, hanem azt az időt kell elérni, akkor nem számláló kell, hanem minden lépés után összehasonlítani az időt, hogy elérte-e már a kitűzött célt. Esetleg egy vizsgálatot érdemes a visszaszámlálás megkezdése előtt végezni, hogy nagyobb-e a mostani idő mint a kitűzött cél, ha ez lényeges, mert amúgy akár egy napig is tarthat a visszaszámlálás. -
-
gyapo11
őstag
válasz
Mexbacsi
#11469
üzenetére
Nem mondom, hogy mindenről tudom a képen hogy micsoda, de nem látok relét, ami hasznos a 230-as kapcsolgatásokban, meg egyéb elektronikai alkatrészeket, amik a bemeneteknél hasznosak, pl. optocsatoló, tranzisztor, fet. Jól jöhet még rs485 modulok a távoli adatok továbbításához, esetleg rádiós modulok, táp modulok. Ha megveszed a szenzor csomagot, akkor abban biztos lesz fény-, mozgás-, hangérzékelő.
-
gyapo11
őstag
válasz
robohw
#11426
üzenetére
A kezdő emberkéknek először is sikerélmény kell, aztán, ha azt megélték, akkor hajlandók több időt invesztálni, mélyebben megismerkedni azzal, amit csinálnak.
Igen, a sikerélmény fontos, és azt is könnyebb megszerezni egy arduino lappal és a hozzá tartozó IDE-vel, mint pár alkatrészhez nyákot csinálni, assembly vagy c programot írni, lefordítani és valamelyik programozó programmal áttölteni.
Nálam a ch340-hez a driver megkeresése volt a legnehezebb művelet, IDE letölt, fut, rádug, fölismer, áttölt, fut.
Aztán hogy később növekszik-e az érdeklődés az elektronika vagy a programozás irányában, az más kérdés.
Az viszont igaz, hogy én elektronikai képzettségű (is) vagyok, és a programozás is ment már valamennyire, bár c-ben, c#-ban vagy c++-ban még sosem írtam előtte semmit. -
gyapo11
őstag
válasz
robohw
#11422
üzenetére
Sokáig én is csak álmodoztam a mikrovezérlőkről, a hw még ment volna, de az assembly meg a biztosíték bitek, meg a programozás elriasztott. Aztán jött az arduino, és minden sokkal egyszerűbb lett, szóval csak akkor javaslom a váltást, ha valakit közelebbről érdekel a dolog, és nem csak a felhasználáshoz egy eszközt keres.
-
gyapo11
őstag
válasz
vargalex
#11174
üzenetére
A böngésző a NAT mögül kapcsolatot tud teremteni egy serverrel, aminek van netes IP címe. Ugyanígy egy másik NAT mögött levő gép is, ezután a server szerintem már kihagyható, és mindkét gép számára a másik lép a server helyére.
Arra gondoltam, hogy a teamviewer servert használni, de persze ha a protokoll nem ismert, akkor erős reverse engineering kellene hozzá.
Ott van a bittorrent, két NAT mögötti gép képes egymással adatot cserélni, kapcsolat felépítéséhez kell a server, de utána már nem. De voltak más ilyen peer to peer filecserélő programok is. -
gyapo11
őstag
válasz
vargalex
#11171
üzenetére
Nem arra gondoltam, hogy a kódot egy az egyben mikrovezérlőn futtatni, hanem a módszert követni, bejelentkezni egy serverre mind a kliens mind a server, és azon keresztül adatokat továbbítani. Azt nem tudom, hogy a teamviewer csak a bejelentkezés idejére használja a servert, és aztán már a két külső gép közvetlen kapcsolatban van, vagy minden a serveren keresztül megy, de utóbbi esetben elég nagy terhelése lenne.
A lényeg, hogy ha két pc tud kapcsolódni NAT mögül, akkor két mikrovezérlő vagy pc és mikrovezérlő is, csak kell hozzá a program. -
gyapo11
őstag
A válaszhoz ismerni kellene a kapcsolási rajzot, az ic-k működését, de szerintem az a/d konverter bemenete tud meghalni a nagyobb fesztől. Aztán meg ha zárlatos is lesz, az usb portnak még attól sem kell kinyiffannia, mert van valami áramkorlátozás vagy biztosíték, de ez is alaplapfüggő lehet. Gondolom egy ilyen hangkártya fogyasztása nem lehet túl sok, főleg ha a kimenete nincs terhelve, vagyis egy soros ellenállás a tápba a maximális usb port áramra méretezve (mondjuk 10 Ω) megfelelő lehet a zárlat ellen.
A jel már nehezebb, mert a mikrofon bemenet mV nagyságrendű lehet. -
gyapo11
őstag
válasz
robohw
#11124
üzenetére
Pár hozzászólással előbb volt a 9 V-os akku probléma, ahhoz pl. a hangkártyás is tökéletes lenne ránzéni, hogy a táppal mi is van terhelés alatt, mennyire horpad be. Usb-s hangkártya 1 $, software ingyen, 3.5 jack to bnc 5 $, de akár egy 3.5 dugóba két drót is jó, és ezt multiméterrel nem nagyon lehet kimérni. De pl. nyomógomb prelljét megnézni meg az állapot analizátor jobb mint a szkóp, bár ezek a digitális tárolós szkópok már eléggé alkalmasak erre is, jel indítja, trigger egyszeri lefutásra állítva és ott a hullámforma a kijelzőn.
Szóval kell mindenféle műszer, az arduino is csak egy elektronika, táp, kontakt, zavarjelek, mindenre van legjobban alkalmas műszer. -
gyapo11
őstag
válasz
robohw
#11115
üzenetére
Ehhez már jó pár éve begyűjtöttem pár software-t, meg vettem egy kis usb-s hangkártyát is, csak még a 3.5-ös jack to bnc átalakító kell és mehet a móka. Viszont ez talán 44.1 kHz-cel tud mintavételezni, szóval hangfreki.
Viszont végre összeforrasztottam a DIY dso150-et, ez 200 kHz sávszélességű analóg bemenet és 1 Msps max mintavétellel megy.
És úton van egy dso188, 1 MHz sávszélesség, 5 Msps mintavétel, akkus, nem kell dróttal tápolni.
És még lehetne följebb menni, de 60 $-ért már van 20 MHz-es 48 Msps mintavétellel kétcsatornás usb szkóp, szóval nem érdemes.Ez a kis Saleae másolat a 24 MHz-es mintavétellel mutatja, hogy milyen idők vannak, analóg jelet nemigen néznék ekkora frekin. Arduino kimeneteknél is pár tíz kHz a jellemző, ha rövidke program fut, erre tökéletes akár az állapot analizátor, akár valamelyik olcsóbb analóg szkópocska. A dso188 még akciós 23.99 $-ért + 2.37 szállítás.
-
gyapo11
őstag
Ez a hw csak digitális, de van a Saleae-nek olyan hw-e ami analógot is tud, 349-889 Euró közötti árakon.
Megnéztem a pulseview-t, kicsit kellett izmozni a 3.0-ás usb driverrel, de végül sikerült, bár nem mutat az elérhető eszközöknél semmit mint egy videón, fönt mégis választható a Saleae. Nekem a Saleae programja könnyebben leolvasható infót ad. A protokoll dekódereket nem próbáltam, több van a pulseview-ban.
-
gyapo11
őstag
válasz
zsolti_20
#11082
üzenetére
Az előző hozzászólásban írtam, hogy szerintem mehet párhuzamosan.
De ha ezt mégsem szeretnéd, akkor több lehetőség is van.Pl. minden akkuról egy diódával csatlakozol a fogyasztóhoz, megakadályozva ezzel az akkuk közötti kiegyenlítő áram folyását. Mindegyik cella annyit tesz a fogyasztó áramához, amennyit az adott feszültségen tud. Ha valamelyikből kifogy a szufla, akkor az nem ad áramot a közösbe. Bár ha állandóan töltöd, akkor ez nem következik be. Persze ebben az esetben 4 töltőáramkör kell, nem lehet a cellákat összekötni. Esetleg egy töltő, és 4 Schottky diódával menni a cellákra, ez kb. 0.3 V-ot levesz a töltőfeszültségből, 4.2 helyett kb. 3.9-re fognak töltődni. A diódákon termelődő hő veszteség a töltési és a fogyasztási oldalon is.
Vagy pl. párhuzamosan kötöd a cellákat, de az arduinoval vezérled a töltést. Ha eléri a 3.9 V-ot, akkor lekapcsolod, 3 V-nál meg bekapcsolod. Ekkor elég egy töltőáramkör, és sose lesznek a cellák a fölső feszültséghatár fölött. Ekkor a Sony esetében a cellák kapacitásából elveszítesz 600 mAh-át, a 2600-as cellák 2000-esnek felelnek meg a 3.9 V-ig töltéssel. Talán érdemes a cellákat összeválogatni, hogy a töltési görbéjük azonos legyen, mert Kirchoff bácsi szétosztja az áramot közöttük, és az a jó ha egyenletesen.
És persze lehetne sorba is kötni a cellákat, és balancerrel tölteni. Dc-dc konverter van 14 V-ról 5-re is. Töltés közben a balancer leveszi a feltöltődött celláról a töltést, tehát túltöltés kizárva, viszont a mélykisütés veszélye töltés nélkül fennáll.
Mindegyiknek van előnye és hátránya is, amelyik neked az adott alkalmazásban fontosabb, aszerint válassz.
-
gyapo11
őstag
Mi lehet e töltőben a töltés leállításának kritériuma? Gondolom eléri a 4.2 V-ot és az áram csökkenését figyeli, és nem süllyed az alá a határ alá, ahol már kiírná hogy kész. Ha még melegszik is, akkor biztos folyik annyi áram, ami nem jó. Viszont szerencsére ez jó cellákkal nem történik meg, nálam a Lii500 és a Zanflare C4 is minden cellámmal rendesen viselkedik, ez kb. 20-25 cella , nagy része 18650 és 4 db 26650, meg még pár 14450 és 16340.
A tapasztalatod azt is megerősíti, hogy nem elég pusztán egy cella kapacitását nézni, az önmagában kevés információ a cella állapotára vonatkozóan.
Szóval azt mondanám, hogy nem bontott cellákból nyugodtan párhuzamosan lehet kötni, esetleg egy-két kisütés-töltés ciklust megfigyelni. Az enyémek közül is mennek páran gyárilag párhuzamosan elektromos cigiben, lámpában.A teljes töltésnél abból indultam ki, hogy nem hívják föl a gyártók a figyelmet arra, hogy ne töltsd tele az akkut. A töltők is teletöltik, vagyis ha nem kezded el töltés után azonnal terhelni, akkor jelentős időt fog eltölteni a 4.2 V környékén. A Sony VTC5 fél amperrel terhelve kb. 600 mAh kivétele után éri el a 3.9 V-ot. Persze ha 3.9 V fölé nem töltenénk, akkor csak 60 %-ig töltődne, nem lehetne olyan jól eladni.
-
gyapo11
őstag
Azt jó lenne tudni, hogy a cellák elhasználódás közben mennyiben térnek el a gyári grafikontól:
Mert itt kb. 0.8 óránál eléri a 4.2 V-ot, az áram innentől csökken, 1.5 óránál eléri kb. a 0-t, és onnantól nincs áramfelvétel, tehát nincs csepptöltés.
Vagyis ilyen cellákból tetszőleges darabot köthetünk párhuzamosan, legföljebb a töltés sokáig fog tartani.
Ha megnézzük a kisütési görbét, azt látjuk, hogy 4.2 V-tól indul, vagyis a töltés után a cella 4.2 V üresjárási feszültséget ad. Ha nincs kisütés, akkor ezt jó sokáig tartja, illetve nagyon lassan csökken. Ebből én arra következtetek, hogy ezen a feszültségen létezés az akku természetes tulajdonsága, lehet hogy árt neki, de elkerülhetetlen ez az állapot, hacsak soha nem töltjük föl teljesen.
Vagyis ha van a párhuzamosan kötött akkuk között kisebb kapacitású, ami a 4.2 V elérése után hamar lecsökkenti az áramfelvételét 0-ra, akkor az kb. olyan állapot lesz, mintha nem is lenne a töltőben, hanem a polcon várná a felhasználást, vagy egy kikapcsolt eszközben várná a bekapcsolást, ami az akku természetes felhasználási módja.
Akkor tehát az a kérdés, hogy az elhasználódott cellának van-e olyan tulajdonsága, hogy 4.2 V-on folyamatosan vesz föl áramot, ha igen mennyi ez az áram és milyen hatással van a cellára? -
gyapo11
őstag
Ha sleepben szeretném tartani az arduinot és mondjuk 10 percenként fölébreszteni, hogy csináljon valamit majd megint menjen sleepbe, akkor nem tudom belső időzítéssel ezt elérni? Mindenhol csak 8 másodperces WDT időzítést látok.
Másik kérdés, hogy a sleep állapotból a 2-es lábra beállított interrupttal fölébred? Tehát van egy szenzor, ami valamikor szintet vált a 2-es lábon, ekkor lefut a beállított függvény. De ha éppen sleepben van akkor is? Fölébred, lefut az interrupthoz rendelt függvény, és mi történik? Elkezdi futtatni a loopot elölről? Vagy emlékszik hogy hol aludt el és onnan folytatja a futást? -
gyapo11
őstag
válasz
ecaddsell
#10932
üzenetére
Ezt a MECHANIC-ot láttam ugyanezzel az összetétellel tégelyes kiszereléssel olcsóbban, akkor az jó lesz.
Jártam olyan helyen, ahol smd nyákokat gyártottak, és ott is gond volt a beszáradás, pedig hűtőben tartották. Nálam ez különösen fontos kérdés, mert keveset használok hosszú idő alatt. Szóval ha fluxot keverek hozzá amikor már besűrűsödött az nem jó? A friss fluxtól tapad, hígabb lesz, az a kérdés, hogy be tud-e hatolni a friss flux a szemcsék közötti sűrű régi flux helyére egyszerű keveréssel. Esetleg melegíteni is lehet, az biztos segít. Az én forrasztózsírom biztos van vagy 20 éves, és semmi baja, ugyanolyan állagú és működőképes mint amikor vettem, a forrasztóón szemcsék sem változnak, tehát így örökre működhet egy tégely paszta.
Ja, és offtopic kéztisztító krémmel volt az, hogy nagyon besűrűsödött, és folyékony szappannal kevertem össze, teljesen tökéletes lett, lágy krém állagú és tökéletesen tisztítja a kezet. -
gyapo11
őstag
válasz
t72killer
#10924
üzenetére
Mindig is flux core-os forrasztóónt használtam, ennek ellenére sokszor jól jön a plusz gyanta vagy forrasztózsír. Főleg ha a forrasztandó felületek nem teljesen tiszták, régebbi vezeték vagy akár nyák reze. Persze lehet mechanikusan tisztítani, de nem mindig hozzáférhető, esetleg már ott levő alkatrészek sérülnek. A folyasztószer viszont kémiailag hat, az oxidokat megeszi, és a tiszta fém bukkan elő, ami már jól forrasztható.
Régebben én is oldottam föl alkoholban fenyőgyantát, ezzel átkentem az egész nyákot, melegítettem és ahol nem volt réz ott "eltűnt" a gyanta, a rézen meg szép fényes vékony réteget alkotott, az ón csak úgy szaladt rajta. A forrasztózsír is nagyon jól működik, zsír állagú, bele lehet mártani a vezeték végeket, a pákától azonnal folyadékká válik és mindent forraszthatóvá tesz, a vasat, acélt is, elemek akkuk bármelyik pólusát. -
gyapo11
őstag
válasz
zsolti_20
#10908
üzenetére
Persze.
Amikor megnyomod a gombot, akkor elküldöd az adatot, és kell egy while, ami azt figyeli, hogy a gomb nyomva van-e még. Amíg el nem engeded a gombot, addig pörög a while és nincs további küldés. Ha fölengeded a gombot, akkor tovább megy a loop, de mire megint a gomb vizsgálathoz és, akkor már nem lesz megnyomott állapotban, tehát nem lesz megint küldés.
Ha közben másnak is futnia kell, tehát a loopot nem lehet megállítani, akkor bonyolultabb, de azt is meg lehet oldani. -
gyapo11
őstag
válasz
zsolti_20
#10872
üzenetére
Nehéz képről meg leírásból megmondani egy akkuról hogy jó-e, egy nagyon kicsit keveslem a súlyát, a jó cellák inkább 48-49 g-osak szoktak lenni, ez 45. Minél könnyebb egy cella, annál valószínűbb, hogy kevesebb a kapacitása, kivéve ha megtöltik homokkal, hogy meglegyen a súly.
-
gyapo11
őstag
Ha usb-re dugod, akkor az ic megbeszéli az oprendszerrel a dolgokat, ez tart 2-3 másodpercig és közben villog a led és ezek szerint más lábak is. Nem tudom mit csinál a bootloader, de elképzelhető, hogy amikor megtudja, hogy usb kapcsolat van, akkor is csinál valamit.
Ha nem usb-n táplálod, vagy megszünteted a data lábak kapcsolatát, akkor ez nincs, hanem a sima processzor éledés, de az sem biztos, hogy parazita impulzusoktól mentes.
Van talán valami reset ic, ami ezen segíthet, alapjában a resetet aktív állapotban kell tartani addig, amíg a tápfesz megfelelő feszültséggel stabilizálódik, ekkor fölengedni a resetet, és a lábak bemenetekként indulnak, és bootloader nélkül csak a programot hajtja végre, tehát semmi nem várt impulzus nem lesz. -
gyapo11
őstag
Nem olyan ez mint egy astabil multivibrátor, ami azonos alkatrészekből áll a két tranyónál, és nem lehet tudni, hogy melyik zár előbb? Amíg nem kap a programból beállítást, hogy out legyen és 0 vagy 1, addig nem lehet tudni, hogy be vagy kimenetként működik, van belső felhúzó vagy nincs, szóval bizonytalan. Ha fontos, hogy csak a program határozza meg a kimenet állapotát, akkor én tennék a proc és a külvilág közé egy áramkört, amit a program kapcsol be és csak ezután jutnak ki a jelek. A bekapcsolás pedig legyen olyan, amit az éledő processzor nem tud produkálni, pl. egy 5 kHz-es négyszögjel.
-
gyapo11
őstag
Távolságra szerintem kell egy mérést csinálni sötétben, hogy az adó mekkora jelet állít elő a vételi oldalon. Elég egy távolságot lemérni, mert abból már más távolságok is számolhatók.
Meg kell mérni a vevőt, hogy különböző fénymennyiségekre mekkora jelet ad. Lényegében egy függvényt kell mérni, illetve abból egy táblázatot valamilyen lépésközzel.
A jeladó megkülönböztetése a környezeti fénytől meg modulálással végezhető, legegyszerűbb esetben négyszögjel, meg kell mérni a bekapcsolt jeladóval a fényt meg kikapcsolttal, a kettő különbsége az, amit a jeladó adott, ebből megvan a távolság. -
gyapo11
őstag
válasz
Teasüti
#10520
üzenetére
Vannak kis szaturációs feszültségű tranzisztorok. Vagy fet, de annak is kell a feszültség. Vagy leültetni a tranzisztort test alá negatív feszóltségre esetleg egy védődiódával, vagy egy rail-to-rail műveleti erősítő, aminek a kimenete pozitív táptól testig tud működni.
-
gyapo11
őstag
válasz
Pubszon
#10411
üzenetére
Ha egy ellenállás le- vagy felhúzza a bemenetet, az addig fix, amíg rá nem kötsz egy drótot, mert a drót viszi be a zavart. Ha árnyékolt a drót és minél rövidebb, minél kisebb az ellenállás a táp felé, illetve kis induktivitású kondi testeli, akkor jobb a helyzet.
Itt software-ből is lehet ügyeskedni, mert ha beérkezik a megnyomás/bekapcsolás jele, akkor elég várni pár tíz ms-ot a prell miatt, majd nézni, hogy folyamatosan aktív-e a jel még pár tíz ms-ig, ha igen, akkor nem zavarjel.
-
gyapo11
őstag
válasz
Honkydoo
#10398
üzenetére
Nem tudom milyen cpu-ra gondolsz, én a 328-assal próbáltam egy nagyon egyszerű ciklust, ami csak számol, és 100 kHz fölött valamivel futott le egy másodperc alatt. Szóval a 44 kHz-es megszakításban ha 2 utasításnál több van (egy inkrementálás és egy if volt nálam), akkor nem fog beleférni az időbe.
-
gyapo11
őstag
válasz
tvamos
#10342
üzenetére
Ha vannak mérések, és azokból látszik, hogy a klón nem jó, az OK. De ha csak tapasztalások vannak, az nem elég bizonyíték, mert sok minden okozhatja, aminek semmi köze az áramkör klónságához.
Pc javítós koromban alap módszer volt két gép között cserélni valamit (pl. billentyűzet, egér, floppy, vga kártya). Ami az egyik gépben rossz volt, az a másik gépben jó, és a másik gépből áttett valami az egyik gépben is jó volt, így mindkét gép jó lett és nem használtam föl semmit hozzá. Vagyis egy rendszer úgy is lehet problémás, hogy minden eleme jó, az arduino lap körül is vannak még dolgok, táp, vezetékek a külvilág felé, perifériák, ezek is mind jók lehetnek, de összerakva meg néha nem. Ha valaki kiméri, hogy mikor melyik impulzus volt hosszabb vagy rövidebb vagy fölösleges, és kimutathatóan a klón arduino okozta, akkor rendben, az a klón rossz, de egyéb esetben csak ráfogjuk, pedig nem biztos. Lehet, hogy egy másik klónnal már jó az a környezet, mint a pc-knél a cserélt eszközök. -
gyapo11
őstag
válasz
Janos250
#10325
üzenetére
Csak hw szinten nézve, én nem bízok eléggé a wifiben ahhoz, hogy pl. a riasztó szenzorait rábízzam. Néha a telefonok nem tudnak kapcsolódni a routerre, ilyenkor pc-n routerbe belép, wifi off, wifi on ls megint jó napokig/hetekig. Tlink router dd-wrt-vel. Egy fényforrást bekapcsolni OK, max nem kapcsol be, de egy vízaknában vízszint figyelő szenzor, egy füstjelző, vagy más kritikusabb szenzor jelét már nem akarnám, csak vezetéken. Egyik ismerősömnek befulladt több tízezer szál virágja a fóliába, mert kisütött a nap, és a megbízott lányka elfelejtette kinyitni a szellőzőnyílásokat. Ezt sem bíznám wifire pl.
Nekem nagyon tetszik az RS-485 hibatűrése, igénytelensége, képessége a távolságra és eszközszámra, egyszerű használhatósága arduinoval és pc-vel egyaránt.
Sokféle protokoll elképzelhető, szerintem alapnak jó a pollozás, amikor a központi egység lekérdezi ciklikusan a perifériákat akár olvassa akár írja őket, de lehet olyat is, hogy a periféria jelez egy plusz vezetéken, és akkor kérdezi le a központ, hogy ki volt az és mit akar, meg még sokféle elképzelhető. A lényeg, hogy az adat biztonságosan elérjen egyik pontról a másikra.
A földhurokra meg a trafós táp biztos megoldás, a kis kapcsolóüzeműekről se tudom elképzelni, hogy galvanikus kapcsolatban lenne a kimenetük a 230 V-os hálózattal. Pc már érdekesebb, mert abba sokféle madzag megy. -
gyapo11
őstag
Nálam úgy volt, hogy a gomb benyomására egy változóba került a millis() értéke, indult egy while ciklus, ami figyelte a gomb felengedését, amikor ez bekövetkezett, akkor a jelenlegi és eltárolt millis összehasonlításából kiderült a nyomvatartási idő. Hátránya ennek a megoldásnak, hogy amíg a while fut, addig a loopban levő többi teendő nem fut, de nálam ez nem volt gond.
Ha fontos, hogy közben a loop pörögjön, akkor kicsit bonyolultabb.
Gomb benyomása után változóba millis, ezután olvasgatni a millist meg a gomb állapotát, 50 ms-en belül nem kell nézni a gomb felengedését, az még prell idő, utána már igen, és a felengedéskor kiszámolni a jelenlegi és a tárolt millis értékéből a nyomvatartási időt.
Hogy mikor mit csináljon a pörgő loopban, azt egy változóval lehet vezérelni, értékétől függően pl. egy switch egy-egy ága fut. Ha a változó 1, akkor mondjuk várja a gomb benyomását. Ha benyomódott a gomb, akkor a változóba 2, ekkor várja a felengedést. Ha felengedted, akkor változóba megint 1, és ismét várja a megnyomást.
Vagy vannak időzítő libek is, amikkel talán egyszerűbb, még nem próbáltam ilyeneket. -
gyapo11
őstag
Csinálok egy mozgásérzékelős lámpát arduinoval, és nyilván sleepben kellene lennie az idő nagy részében, és a szenzortól jövő jelre kell fölébrednie. Van valakinek kéznél kód erre?
Van egy ilyen kódom, ezt is itt kaptam:#include <avr/sleep.h>
void sleepNow() // here we put the arduino to sleep
{
byte adcsra = ADCSRA;
wait(100);
ADCSRA = 0;
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_enable();
attachInterrupt(0, wake_up_pin, LOW);
sleep_mode();
sleep_disable();
ADCSRA = adcsra;
detachInterrupt(0);
}
void loop()
{
Serial.println(" Megyek aludni..");
sleepNow() ; // elmegy aludni, majd felkelted
Serial.println(" Most keltem fel."); // majd innen folytatja
}Lehet, hogy ez jó is, a wake_up_pin-re kell kötni a szenzort, szintet majd meglátom, és elaltatás előtt ellenőrizni kell, hogy ne legyen aktív a szenzor. Vagy lehet, hogy ez se kell, mert akkor azonnal fölkel megint, indul az időzítés, ha az lejárt, jöhet az altatás.
Meg még az lenne a kérdés, hogy ha van egy másik ébresztés egy másik lábon, akkor kell egy másik sleepNow függvény arra a lábra és kész? Vagy még több esetén? Össze kell vagy kapcsolattal gyűjteni, egy lábon ébreszteni, és más lábakon beolvasni, hogy ki volt az? -
gyapo11
őstag
válasz
rsanya87
#10136
üzenetére
Ja, nem írtam elég részletesen. Szóval nem a távcsővel kell pólusra állni, hanem annak a platformnak a tengelyét kell a pólusra irányítani, ami aztán a távcsővel együtt forog. Tehát kell egy másik arduino, vagy az egy arduinonak egy másik funkciója, ami nem a platformot forgatja a Föld forgásával ellentétes irányba, hanem a platform tengelyét állítja két koordináta mentén, hogy az pontosan a pólusra nézzen. És ennek a vezérlését lehetne úgy megcsinálni, hogy a távcsövet a tengellyel párhuzamos helyzetbe állítani, ráállni gombok nyomogatásával a Polarisra vizuális visszacsatolással, majd egy gombnyomásra az időpont ismeretével rá tudna állni a pólusra. Innentől már bárhova nézhet a távcső, a csillagok állnak.
-
gyapo11
őstag
válasz
rsanya87
#10134
üzenetére
Úgy tudom, hogy több képet készítenek, és azokat adják össze software-rel, mert így az egyes képek zaja kioltja egymást, a hosszabb expós egy képen viszont ott lesz a zaj.
Ha már arduinoval vezérled a távcsövet, akkor meg lehetne oldani a pólusra állást úgy, hogy a pólus közelében egy csillagra ráállítod pontosan a távcsövet, célszeűen a Polarisra, és onnan az arduino lépteti a pólusra, csak az időpontot kell tudnia pontosan az arduinonak ehhez.
-
gyapo11
őstag
válasz
Attix70
#10130
üzenetére
Lehet, hogy az erősebb táp megoldaná a mostani áttétellel is, de ha a software-ben át tudja állítani több lépésre adott idő alatt, és a két kerék is megvan, akkor így is jó lehet, 1/2.4 erő fog hatni a motor lépése ellen. Ha nem elég, akkor jöhet a nagyobb táp vagy még nagyobb áttétel. Nem tudom melyik tudós mondta, hogy adjatok egy fix pontot, és kimozdítom a Földet a helyéről. És tényleg, csak áttétel kérdése. Bármilyen kis motorral lehet mozgatni bármekkora távcsövet, csak áttétel kérdése. Ha túl nagy áttétel kell, akkor persze a Föld forgása gyorsabb lesz, és nem tudja követni.
-
gyapo11
őstag
válasz
rsanya87
#10123
üzenetére
Persze, csak az arány számít, ha több méter átmérőjű/több száz fogú kerekek vannak, akkor is. Vagy ha több kerék adja ki a végáttételt, akkor is.
Szerintem itt célszerűbb a 4:1, mert a meghajtás felől nézzük a vége felé, a meghajtó motor 4-szer annyit fog forogni, mint a végső kerék. -
gyapo11
őstag
válasz
rsanya87
#10116
üzenetére
Az áttétel változásának arányában kell változni a meghajtó fordulatszámnak, hogy a végfordulatszám azonos maradjon.
A 18-as kerék 1 fordulatára a 30-as kerék 0.6-nyit fordul el, a 10:40-es áttételnél meg 0.25-nyit.
18/30 helyett a 10/40 2.4-szeres, ezért az új rpm 6.38675*2.4 = 15.3282. -
gyapo11
őstag
-
gyapo11
őstag
Kipróbálhatod a symlinket, nálam bevált. Fogod a c: meghajtón a foldert és átmásolod máshova, pl. külső wincsire. Ezután létrehozol egy symlinket, ami létrehoz egy virtuális foldert a c: meghajtón, de a file-ok valójában a külső wincsin vannak, a software ebből nem vesz észre semmit. Nálam az rss olvasó megy így.
-
gyapo11
őstag
válasz
kulturg
#9854
üzenetére
Kell egy akkora kondi az arduino tápjára, amiről elmegy pár tizedmásodpercet. A kondi meg egy diódán át kapja a töltést, a dióda előtt egy feszosztó ellenálláspár, és innden tudja az arduino, hogy mikor ment el a delej, a pár tizedmásodperc alatt meg elvégzi amit kell a halál előtt.
-
gyapo11
őstag
Virághoz nem is kell elektronika.
Bele kell tenni a cserepeket egy tálcába, abba szájjal lefelé egy pet palackot tele vízzel a tálca aljától 1-2 cm-re legyen a palack szája, és ez folyamatosan tartja az 1-2 cm vízréteget amíg ki nem fogy a palack. A cserepekbe alulról fölszivárog a víz, tehát legyen az aljukon lyuk. -
gyapo11
őstag
válasz
adatfalo
#9706
üzenetére
Ha az uno sokat kajál deepsleepben, akkor külső tápkapcsoló kell, minden cmos, oszcillátor, osztó 24 óránként 1 impulzusra osztva az oszcillátor jelét, az impulzus egy bistabil oszcillátorra, ez egy fettel rákapcsolja a delejt az unora. Aztán amikor az uno végzett, elmenti a változókat eepromba, visszabillenti a bistabilt, ezzel megszünteti a saját tápellátását, és a rendszer vár a követlező 24 óra múlva jövő impulzusra.
Vagy használod valamire a infót? Hogy pl. nem 90 fokos a víz hanem 80 vagy 70, függ ettől valami? De alkotásnak/gyakorlásnak jó kis project.
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Remek áron Lenovo Flex 5 14 laptop/2in1/Touch/Ryzen i5-1135G7/8GB/512 GB SSD/14"/Gari
- Exclusive ajánlat! Dobozos új LG GRAM /13. gen i7-1360P/32GB RAM/512GB SSD/14"COL/FHD+/IPS/Garancia/
- Pénztárcakímélő áron eladó HP Pavilion laptop/I5-1135G7 8GB 256SSD 13" FHD IPS Gari
- Samsung Galaxy Book 3 /i5-1335u/8GB/512SSD/FHD/Garancia/ 6 napot ment eddig összesen
- Xiaomi Redmi Note 14 Pro Plus 12/512GB Újszerű,Dobozos,Kétkártyás 1év Garanciával!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged