Szenzorok adatait kiolvasni, hosszabb időzítések hol tartanak, események számát nézni, tehát a program futása alatt a keletkezett adatokat követni.
Vezérelni olyat, amit a program írásakor még nem tudok meghatározni. Pl. elmegyünk két napra, és a fűtést vegye lejjebb, a lámpákat kapcsolgassa este véletlenszerűen, a redőnyöket csak félig vagy egyáltalán ne húzza föl.
Html-t kapiskálom pc-s környezetben, csak arduinon nem tudok semmit. Tehát van egy ethernet vagy wifi az arduinon, kap a routertől ip-címet. Hogy lesz ebből weboldal? Van erre library? Ha elő tud állítani az arduino egy táblázatot valamilyen adatokkal, akkor az jó az adatok kiolvasására, ha formot is tud, amibe a pc-ről írhatok adatokat, amit olvasni tud, az jó adatok beírására.
Bele tudja írni az ethernet kapcsolatba a html forrásszöveget amit a pc azon az ip-címen elér mint weboldal? És a formnak mi lesz az actionje? Simán az ip-cím? Akkor a GET vagy POST adatküldést le kell tudnia kezelni, kiolvasni az adatokat. Jó lenne egy hello world weboldal példa.
Mit akarsz monitorozni rajta? És mit akarsz vezérelni, pláne távirányítással? Mert ha már akár wifi, akár ethernet van, akkor magától értetődő egy kő egyszerű html honlap összerakása, amit egy sima böngészőből hívsz meg.
Kapcsolgatni is lehet, sőt, elvileg html felületen adatot is beadhatsz (elvben legalábbis, bár ezt még nem próbáltam).
Kapcsolódva a wifis kérdéshez, hogyan lehet pc-ről (xp) monitorozni az arduino működését?
Usb bedugva és soros portra íratni az arduinoval, ezt sok példában is használják.
Hogy megy ugyanez etherneten, wifin? Minek kell futni a pc-n, ami meg tudja kapni ezeken a csatornákon küldött byte-okat?
Tovább csavarva, ha az arduinon futó program föl van készítve erre, hogyan kaphat vezérlő parancsokat futás közben? Pl. hőmérséklet vagy bármi más szintadatokat, ami szerint kapcsolgatnia kell valamit.
Attól, hogy valamit te csinálsz (DIY), még működhet az Arduino keretrendszer alatt, annak sallangjai (mondjuk például az USB csatolófelület, a stabilizált tápegység "házon belül") nélkül. A prototipizálást 1-2-3 kártyával megcsinálod, utána a "kész termék" egy egyedileg kialakított nyák (vagy próbanyák), azokkal és csak azokkal az alkatrészekke, amire szükséged van, vagyis: egy atmel 328p (kvarc, pár ellenállás, védődióda, kapacitás), egy i2c eeprom, esetleg még pár apróság, kivezetés az érzékelőhöz, és egy darab 485 ic, esetleg még ha kell, mellé pár alkatrész az üzembiztos működéshez. A soros programozást meg tudod csinálni egy másik arduinoval (Arduino ISP), és gyakorlatilag egy UNO vagy Nano áráért van egy működő rendszered, amit aztán kiöntesz műgyantával és kirakhatsz akár a tyúkok közé is, ha épp arról van szó. Ez így:
-- jó eséllyel számottevően olcsóbb (kb. fele),
-- nem prototípus, vagyis jóval üzembiztosabb,
-- jóval kisebb,
-- valamivel üzembiztosabb,
mintha Arduino bizbaszok ide-oda kötögetésével és egymásra dugdosásával oldanád meg.
A kínai vacak alkatrész meg nem kockázat, 50-ből egy hibás esetleg, de az kiderül az elején és a projekt árának töredékéért tudod cserélni.
Az, hogy nálad tapasztaltabb programozók írták, semmire sem garancia. Van itt kotvány gazdagon és nem csak sketch, de library szintjén is.
Amennyire en olvastam a gyari fw olyan, hogy adsz tapot es o megjelenikint access point. Racsatlakozol, es elered a benne levo webszervert, ahol tudod konfigolni.
Szinten az alap fw azt tudja hogy sorosan beszelhetsz vele at commandokkal. Tehat kellene ra akasztani egy sIntillesztot es utanna hajra hiperterminal.
A pro mininél tapasztaltam a lábak jelölésével kapcsolatban a feliratozás nem mindig korrekt, de figyelmetlen is voltam, eleve keresztezni kell a tx rx vezetékeket az rs232 szabvány szerint.
Én még előtte vagyok, de majd figyelek. Már amit eddig olvastam fórumokat látszik, hogy nem mindig az első library működik, amit talált az ember. Talán itt is a csoport tapasztalata a legjobb, ami már több embernél bevált, annak jó esélye van nálam is, ha ugyanolyan modulokat használunk. Ez is előnye a nem saját fejlesztésnek, hogy mások kínlódásának eredményét felhasználhatom.
A rádiós megoldás szerintem nem rossz, én az NRF24L01+ (modulokat) használtam és nekem jól megy. az NRF ráadásul csomagokat küld, kényelmes.
Azt kell végiggondold, hogy mi a következménye annak, ha szakadás vagy kiesés van a rádiókapcsolatban? (Pl. valami zavar van.) Ha katasztrófális, akkor mindenképpen drótos kapcsolat kell, de ha nem kritikus. Bár én nem tapasztaltam ilyet, a legrosszabb ami volt, hogy van olyan hely a házban (kívül) ahová nem megy el rendesen a jel, de ezt egy ismétlős rendszerrel meg lehet oldani.
Ez a communication link nagyon jó, még sokat kell nézegetnem az arduino.cc oldalt.
Tkp. nem találtam ki előre a protokollt. A feladatot találtam ki, azt is csak nagy vonalakban, mégpedig a viszonylag sok szenzort viszonylag nagy távolságban. Ezzel kilőttem a kis lokális megoldásokat, pár méterre jól működő beolvasásokat, amikkel az asztalon lehet játszani. Nekem akkor érdekes az arduino, ha tudom használni ilyen célra, kint vannak a mérendő dolgok, valahol fedett, árammal rendelkező helyen a feldolgozás, és az adatoknak el kell jutni a feldolgozás helyéhez. Persze nem csak szenzorok, hanem beavatkozó egységek, motorok, fényforrás, hangjelzés stb. is, csak ott ugye ellenkező irányú az adatközlés.
Tetszik az ethernet, a rádiós vezeték nélküli és az rs485. A konkrét feladat határozza meg, hogy melyiket érdemes használni. Ezeket meg fogom nézni közelebbről, kipróbálom, mert a gyakorlatban is szeretném látni, hogy belefér a program, megfelelő a sebesség és biztonságos az átvitel, fogyasztások hogy alakulnak, zavarvédettség milyen.
Abban igazad van, hogy a legegyszerűbb megoldásban van a legkevesebb hibalehetőség, de a szenzor nem kommunikál (mondjuk egy fotoellenállás vagy thermisztor), viszont analóg mennyiséget mér. Analóg jelet nem akarok vinni, lehetne próbálkozni a 4-20 mA árammal, de sokkal jobban tetszik a digitális átvitel, vagyis processzor kell. Lehetne csupasz mikrovezérlő, de akkor ahhoz board, programozó, és nyernék 300 ft-ot az arduinohoz képest. És arduinora már ki van dolgozva sokféle protokoll. Hogy mennyire stabil folyamatos üzemben azt nem tudom. A chip adott, az csupaszon se lenne stabilabb, a bootloader és az áttöltött sketch megbízhatóságáról nem tudok semmit, ezt tesztelni fogom. A nanon alig van alkatrész, elko egy se, az usb-ttl átalakító nem fog működni programáttöltés után, gyakorlatilag nagyon közel van ahhoz, mintha a csupasz chipet használnám a minimálisan szükséges alkatrészekkel. Lehetne találni valami kis 8 lábú mikrovezérlőt, ami szintén olvasni tudná a szenzort és át tudná fütyülni a buszon, de én ezzel a megtakarítható összeg kicsinysége és az általam belevitt bizonytalanság (saját nyák fejlesztés, saját forrasztás, felhasznált alkatrészek minősége) miatt nem foglalkoznék. Ráadásul ha én veszek egy chipet vagy a kínai 1 milliót, egész más áron kapjuk, lehet nem tudnék olcsóbb lenni az egyedi nyákommal és alkatrészeimmel.
A tesztelés OK, nem breadboardon fogom, hanem a valódihoz közelebbi konfiggal, kiviszek az udvar végébe egy nanot, kihúzom a madzagot, lehetőleg forrasztott, toldott, összesodrott, szigszalagozottat, és ha azon bejön meg kimegy jól az adat, akkor az jó. Ez az rs485-re vonatkozik, az ethernethez cat5 kell, a rádióshoz meg semmi.
Az egyedi fejlesztésről már írtam, valahogy az nekem nem tetszik. A sokféle kapható perifériát már sokan tesztelték, azok már bizonyítottak, csak a minőségre kell figyelni, hogy a kínai milyen szutyok alkatrészekből rakta össze milyen szutyok forrasztógéppel. Ebben van bizonytalanság. Megvan hozzájuk a software library, ami szintén nem kevés munka és nem kis bizonytalanság, ha nekem kell megírnom. Valószínűleg nálam jobb programozók írták, tesztelték, javították. Nekem csak a feldolgozást kell megírnom, hogy azt csinálja amit szeretnék. Tehát én most mindenképpen a kész modulokkal fogok indulni, még a szenzoroknál is, bár ott sokhoz nem is kell protokoll, egyszerűen digitalizálni kell az analóg mennyiséget. Ha viszonylag közel van pár szenzor, azt még egy arduino is le tudja kezelni, és olyan programot kap, ami mindegyik rákötött szenzor megszólításakor válaszol a megfelelő értékkel.
Igen az ár azért nem lényegtelen, egyrészt nem ipari cuccról van szó, hanem hobby szint, másrészt éppen a sok érzékelős kiépítés a cél, ha csak 1-2 szenzor van, akkor egyszerűbb a feladat. 4900-ért látok az ebayen can shieldet, mellé még az uno egy ezres. Biztos jó, de ennél az rs485 sokkal olcsóbb (244 Ft), és az 32 egység 1200 m-en atombiztos átvitellel. És jó mellé egy mini pro vagy nano is. Elkezdem jobban megnézni az rs485-ös műszaki adatokat, ez már eléggé ipari is, egyszerű vezetéken megy, zavarérzéketlen, valószínűéeg a software kezelése sem túl bonyolult.
Ez a rádiós modul egész korrektnek néz ki. Nem annyira olcsó, és szinte már bonyibb mint az arduino. Eltettem a libraryt, látom már külön gyűjtemény lesz ezekből.
Itt az Arduino és Arduino, illetve Arduino és perifériák közötti kommunikációs lehetőségek vannak csokorra szedve.
Én mindenekelőtt a következő elvet követném: a szenzorok mellett lehetőleg az elképzelhető legkevesebb, legnagyobb üzembiztonságot nyújtó alkatrész legyen. Egy szimpla érzékelőhöz (akár analóg, akár digitális) egy 328P mikrokontroller plusz egy shield többé-kevésbé az ágyúval verébre kategória. Csak itt van a 22-es csapdája, mert olyan mikrokontroller, amely képes az önálló adatfeldolgozásra, kicsi, nem ágyuval verébre és nem utolsó sorban lehetőleg eleve tudja azt a kommunikációs protokollt (vagy inkább csatolófelületet), amit a projektre kitaláltál, gyors keresés után nem találtam. A CAN bus elegáns lenne, de ez is kicsit több a kelleténél. Munkás ugyan, de többé-kevésbé úgy állnék neki, hogy alap alkatrészekből (128P-alapú alap DIY arduino) + CAN bus vezérlő (vagy más, amit választasz), teleraknék 4 breadboard-ot, plusz egy nagyobb, későbbi adatfeldolgozásra alkalmas kártyát. Aztán tesztelnék feszt.
A kész kiépítés meg vagy egyedileg gyártott nyákokon vagy forrasztós próbapaneleken menne ki, szintén minimálkonfigurációba (ami nem kell, azt nem bekötni stb.). Az egyes adatgyűjtőket pedig az adott szenszornak megfelelően tudod felprogramozni (ICSP vagy soros, irreleváns), és jöhet a telepítés.
Plusz egy eszköz. Ilyen projektek esetén én a minimálkonfigurációt javasolnám, már csak azért is, mert a minőségi +40 usd vagy az óccókínai 17 dolláros ár érzékelőnként (vagy néhány érzékelőnként) azért jelentős többletköltség.
A rádiót lehet broadcast üzemmódban is használni, de lehet csoportokba is rendezni őket, és csoporton belül még csatornát is lehet rendelni hozzájuk. Nem fogják zavarni egymást.
Nem elég csak a hőmérséklet, akármi más is lehet szükséges. Fotoellenállás/dióda/tranzisztor fényt mér, folyadékba vagy földbe merülő fémpálcapár szintet vagy nedvességet mér, mikrofon hangszintet, potméter szellőzőzsaluk nyitottságát, de lehet mágneses térerő, közelség és még soksokféle mennyiség, ami analóg. Nincs mindenre 1wire szenzor, amit csak rá kell dugni a többi meg tisztán program. Millió féle szenzor van, és újakat is ki lehet találni, a mért értéket pedig el kell vinni a feldolgozó egységhez, a központi arduinohoz. Ez egy mindennapos probléma, erre kell megoldásnak lenni, különben az arduino meg a mérési adatok nem találkoznak.
Egyelőre eljutottam a gondolatkísérletben oda, hogy digitalizált adatokat kell továbbítani, buszon kell továbbítani (bár a cat5+router pont nem az, hanem csillag), ezért processzálni kell a szenzornál, amire olcsó és jó megoldás egy arduino. Milyen busz legyen? Amit a központi feldolgozó arduino és a szenzorok melletti arduinok összekötésére lehet használni. Az a jó, ha nem kell megírni hozzá a protokollt, hanem kész libraryt lehet használni. Lehet 1wire, csak tud-e a sok arduino úgy beszélgetni, mint ahogy sok ds hőmérő tud? Lehet soros, csak meg kell oldani a címzést, hogy ne legyen ütközés. Lehet egyedi, de akkor meg kell írni mindent, ami nem feltétlenül extra bolnyolult, hiszen pár bit a cím, majd beszél a szenzor, és ez ismétlődik. Viszont ehhez kell valami saját hw is, hogy kis impedancián menjenek a bitek elnyomva a zavarokat. Két pinnel megoldható, egyen kifelé küldi a központi egység a címet, a másikon befelé jönnek az adatbitek openkollektoros vonalon valami jól követhető sebességgel. Mivel a mérési eredmények 10 bitesek az arduino analóg bemenetével mérve, ha 10 ms egy bit, akkor is tizedmásodperc alatt bejön egy mérés, de lehet gyorsabb is, még nem jöttek meg az arduinok, nem tudok sebességet mérni. Igazából nem annyira kritikus a sebesség, inkább a zavarmentesség.
Javasolnám is, hogy akinek van már gyakorlata pl. ethernettel, írja meg hogy is nézne ez ki pl. két szenzorral és egy központi egységgel. Hogyan kapja meg a központi egység a két mérési adatot, ami 0-tól 1023-ig egy szám.
Illetve ha az egyedi megoldást nézzük, hogyan célszerű a mondjuk 4 címbitet kiírni, és a 10 adat bitet beolvasni?
Pl. legyen a fél bitidő L, és az utána következő fél bitidőben az adatbit H vagy L. Ezzel az a baj, hogy ha minden adatbit L, akkor végig L-ben lesz a busz.
Akkor legyen egy harmad bitidő H, harmad bitidő L és harmad bitidőben az adatbit. De más bevált megoldás is lehet, a lényeg, hogy ne legyen túl bonyolult megírni hozzá a programot, és biztonsággal olvashatók legyenek az adatbitek.
A cat5 kábel jó, elég olcsó és 4 csavart érpár van benne. Ethernet+arduino már 1500.- Ft/mérőhely, de sokkal jobban megbíznék az átjött adatban, mint egy analóg jelben röbbtíz m távolból. Teljesen szabványos, router vagy switch olcsó, semmit nem kell barkácsolni.
Ha hőmérséklet érzékelőket akarsz üzemeltetni, ott a DALLAS 1-Wire rendszere (pl.: Ds18b20) egyszerű és sokat fel lehet fűzni a buszra. (mivel magának az érzékelőnek van egydi címe) 1db digitális portot visz el, és nálam 30-40m síma 4-eres telefon vezetéken megy, több helyen szabványos RJ-11-es aljzatokat raktap bele, így kialaítva a leágazásokat. UTP-n még messzebre is mehet. De lehet két, vagy több buszt kialakítani, ha a busz hossza vagy iránya gondot jelent.
Nem kell különleges kliens-szerver szoftvert írni hozzá, egy egyszerű könyvtár és már lehet is címezgetni az érzékelőket.
Ha meg magas hőmérsékletet akarsz mérni (120C fölött), akkor már a MAX6675+K type páros, és nincs gond a torzuló jellel.
Az sebességre hivatkoztok itt, de miért is?
Az érzékelők lekérdezése kb. 1mp. Ezek mellett szerintem érdektelen, hogy az I2C 100KHz, vagy az SPI 400KHz. Tudtommal ezeket a protokolokat elsősorban eszközön belüli komunikációra találtak ki, tehet néhány 10cm. Tudom elmennek nagyobb távolságra is, de minek.
Mi a célja a mérésnek? Ha csak hőmérséklet naplózás, akkor a mérési intervallumok 30mp-1perc közöttiek (extrém esetben 10mp). Aztán csinálsz belőle 5 perces átlagokat és azt jeleníted meg grafikonon.
Én kb. így látom, várom más véleményét ezzel kapcsolatban.
Az analóg jel továbbításával az a baj, hogy torzul, zavarokat szed föl, hacsak nem nagyon kis ellenálláson/nagy árammal történik. Ez viszont külön erősítőt igényel. És nehéz buszra szervezni, tehát ha 7 analóg jelet mérnék, akkor a 6 arduino bemenet nem elég, míg ha digitalizálom, és úgy akarom begyűjteni, az sokkal egyszerűbb. Habár most egyből nem tudnám megmondani, hogyan is kapcsolgatnék a buszra adatot. Könnyen lehet, hogy nem lehet megúszni az intelligens jeladót, ami pl. egy arduino nano vagy mini pro, és ezeket minden szenzor mellé kitenni, majd nem a szenzorokkal kommunikálni, hanem az arduinokkal. Egy vezérlőkóddal kezdeni a vételt, kiküldeni egy sorszámot, ezt minden arduino veszi, és az szólal meg a mért értékkel, amelyiket megcímeztem. Az rs232 és rs485-nél nem tudom hogyan megy a buszra szervezés. Ezeket könnyű megcsinálni hosszú vezetékkel hibamentesre. Meghajtás kell, az arduino kimenet önmagában nem elég, meg a védelem miatt is. A címzés miatt igazából a kézfogós protokollok nem jók, mert először csak hallgatni kell, amíg kimegy a cím, hogy kinek kell beszélni, aztán meg csak beszélni kell, és mindenki más hallgat. Már emiatt is a buta eszközök, mint pl. shiftregiszter nehezen elképzelhetőek. Ha meg a központi egységnél akarnám multiplexelni a távoli szenzorokat, akkor millió vezeték kellene, mindegyikhez vinni kellene a saját vezetékét, az nyilván nem jó. Vezeték nélkül a BT-t kihagynám, 50 m-re nem érzem elég stabilnak, már a wifi is kérdéses, a 433 MHz-es modulok viszont kellően olcsók, és azt hiszem 100 m-t írnak rálátással. Csak nem tudom mi van, ha viszonylag közel vannak a szenzorok, szét kellene hangolni őket más-más frekvenciára, de nem hiszem hogy van ilyen lehetőség rajtuk. Ha nincs, akkor kiesett ez is.
Ha nagyon nagy idiótaságot írok, majd legfeljebb valaki pontosít.
Ami nagy vonalakban a lényeg: Alapvetően az Arduino analóg bemenetei erre a célra vannak, magát a jelet (ha az analóg jellegű, tehát alapvetően egy feszültség/áram viszony változó ellenálláson át való megváltoztatását jelenti), különösebb nehézség nélkül (elvben legalábbis) végtelen távolságra lehet szállítani. Itt csak a kábel minőségét, ellenállását, kapacitását kell figyelembe venni, illetve azt, hogy a jel mennyire érzékeny külső tényezőkre (környéken futó nagy feszültségű elektromos vezeték, telefonkábel, internetkábel stb.). Amikor valamilyen buszt használsz, akkor egy meglévő analóg jelet alakítasz át digitális jellé, amelyet aztán valamilyen módon továbbítasz. Az egyes szabványok nagyjából determinálják az átvitel formáját és módját is, de pl. TCP/IP mehet soros kábeltől elkezdve wifin át BT-ig (meg még ugye kis millió más módon is). Minél komplexebb a továbbítandó adat (mérési sűrűség, mérési pontosság, hibahatár stb.), annál megbízhatóbb módot kell választani. A DS18B20 One Wire buszt használ, nem kell hozzá semmilyen további elem az érzékelő oldalán, a tápfeszültség alapján létrehozza és a busz-csatornán küldi a jeleket, akár elég jelentős távolságra (megfelelő minőségű kábelen persze). A megoldás előnye egyben a hátránya is: van kábel. Biztonságosnak tekinthető, nincs gond a tápellátással, cserébe telepíteni kell.
A kábeltelen megoldások közül mindegyiknek három fontos tulajdonsága van. Egyrészt a távolsággal arányosan veszít (rendszerint) a megbízhatóságából, mindenképp kell hozzá egy komplett jelfeldolgozó rendszer az érzékelő oldalán (igen, ez lehet akár egy arduino is, bár nem feltétlen kell), végül meg kell oldani a tápellátást valahogy (ami kábelezést igényel).
Az i2c elvileg alaplai kommunikációra lett kitalálva, elég érzékeny a rádiófrekvenciás zavarokra, bár én ezt annyira (eddig) nem tapasztaltam, igaz, hogy Arduino viszonyban ez azért elég alacsony órajelet jelent.
Az SPI egy klasszissal gyorsabb bír lenni (pláne, ha meghajtja valaki), tehát érzékenyebb valamivel, cserébe a kétirányúsága folytán megbízhatóbb.
E kettő inkább a klasszikus "szerver--kliens" vagy "master--slave" felállás szerint üzemelnek, tehát van egy központi (vezérlő) elem és egy külső, perifériális elem (pl. adatgyűjtő vagy kimenet).
Az RS485 -- ha jól emlékszem -- erősítés nélkül 100 métert kibír CAT5 kábelen, ami azért elég baráti (bár a One Wire is).
RS232 inkább szükségmegoldás szerintem, bár pokoli olcsó és egyszerű.
E kettő többé-kevésbé azonos "erősségű" berendezések közötti strukturált adatforgalmat tud megvalósítani (bár Master asszem így is kell hozzájuk). Okos ház tervezéshez ezek működőképes megoldások.
