Az alap DS1307 eleve rohadt pontatlan, erre még rátesz egy lapáttal, hogy rossz minőségű (vagyis pontatlan) kristályt tesznek mellé és rosszul méretezett ellenállásokkal rakják körbe. Leveleztem erről egyszer egy emberrel, majd visszakeresem.
DS3231 eddig bevált, de a pontosságát ennyire még nem mértem (az biztos, hogy napi 20 mp alatt van, sokkal).
Szerintem az eredeti kérdés az volt, hogy a PC-ről le lehet-e kérdezni az időt (ha már úgy is rá van dugva). Gondolom a soros monitoron keresztül.
Én erre nem tudok egyszerű megoldást.
Az RTC-vel nekem annyi gondom volt, hogy mindig sietet, sokat. 3 RTC-t próbáltam (ds1307), kb. állandó szoba hőmérsékleten, és kb. mindegyik ugyanúgy járt. További érdekesség, hogy ha az arduino ki volt kapcsolva, akkor kevesebbet, ha ment az arduino akkor többet. (napi 20mp-t én soknak érzek) (két RTC modul és egy data logger shield, de ezen is DS1307 van)
Itt megakadtam, és kitört a jó idő és az Arduino félre lett téve. Most csak 2 helyen mér hőmérsékletet és naplozza a thingspeak-ra. Majd ha újra beszorulok a szobába, akkor nekilátok újra.
Prof egy kicsit misztikusan fejezte ki magát, nem gondolt bele, hogy olyan ember tette fel a kérdést, aki nem olvasott egyéb Arduino fórumot, könyveket, és még nem böngészett órákig ebajos kínálatokat.
Tehát az óra (RTC=Real Time Clock) modul valahogy így néz ki:
Van egy kis gombelem benne, hogy akkor is tárolja az időt, amikor az Arduino alszik, rebootol vagy ki van kapcsolva. Van rajta IRQ, ami roppant hasznos, ha szabott időben alvásból fel kell ébreszteni az Arduino-t (nem mindegy, hogy üresjáratban 1 mA-t vagy 16 mA-t fogyaszt az egység). Kínában 2 dolcsi körül van darabja.
Viszont a legtöbb arduino panelen, különösen az óccó kínai másolatokon durva varianciák vannak a kristályokkal, ezért roppant pontatlanok (15 perc alatt simán összehoz 10-20 mp eltérést a valós időhöz képest).
Megfelelő pontosságú időméréshez én inkább valamilyen RTC-t javaslok, inkább a jobbik fajtából.
Hello, szerintem az idő tartományt tudod ilyen formátumba átkonvertálni, ugyanis tulajdonképpen a vezérlő csak számolja az időt, valamitől kezdve (milisekundumban), ha ebből napot percet órát akarsz akkor azt konvertálja át, szóval mint a rendes óránál először be kell állítani, hogy hány óra hány perc van, és ehhez adja hozzá a saját kis számolását 24 óránként újrakezdve. Van egy ilyen parancs h millis (50 nap után automatikusan újra kezdi 0-tól)
Arduino GPS module beszerzését, programozását tervezem. Az eszköz célja a bejárt helyek pozíciójának naplózása.
Sok példaprogramot átnéztem, és egy feltételre nem találtam választ, ebben kérem hozzáértők segítségét:
Hogyan lehet szoftveresen meggyőződni az eszköz állapotáról, azaz arról, hogy sikerült-e legalább 4 szatellit adását fognia, és így készen áll a pozíció naplózására. Az eszköz olyan helyre lesz beépítve, hogy az szemmel nem lehet ellenőrizni, így vizuális jelzése haszontalan (pl. villogó led). Csak olyan programozási függvény jöhet szóba, amelyik "igaz" értéket ad vissza, vagy legalábbis logikaira konvertálható értéket (pl. a fogott szatellitek számát).
Most már kezd idegesíteni, hogy mennyire béna vagyok. Az arduinoval, valahogy le lehet kérdezni a pontos időt? Az alap felállás össze van kötve az arduino meg a pc, és serial monitorra, ki szettném íratni a a pontos időt.
Köszi, igen kicsit több a munka veled, de igazából annyira nem fontos, össze hozom, valahogy csak kíváncsi voltam, hogy meglehet mert ha igen akkor megépítem, mert nekem az arduino, saját magam fejlesztésére használom, tanuljak belőle.
Szerintem szopás van az ilyen LCD kijelzőkkel. Persze meg lehet csinálni, de a kelleténél több forrasztással jár. Itt a szükséges kapcsolási rajz és a kód, ami neked kell:
Ma tesztelem a hatótávot falakon keresztül, mert nemrég kifogytam a 9V elemekből. Ezek a rádiók nagyon le tudják zabálni folyamatos üzemmódban. Nézted a linket, hogy milyen rádiót használok? Neked is az erősítős változat van? Az NRF24L01+PA+LNA közvetlen rálátással 1 km-ig garantálja az átvitelt.
Nekem is az a tapasztalatom, hogy 250 KBps-en sokkal jobb a hatótávolság, és az is bőven elég (nekem). Milyen messzire kellett átvinni a jelet? Szobán belül?
Nekem 250 kbps-el két falat és 5-10 métert átvisz, bár a másik irányba 3 falat már nem.
Nemrég jutottam, hozzá egy BC1602HYPLEH típusú led panelhez, az lenne a kérdésem, hogy ezt a arduino, meg tujda-e hajtani, és ha igen, akkor egy bekötési rajz nem ártana, vagy az jó e ami az alap honlapon van led panelekhez.
Nézegettem a nagy Arduino fórumon mások kódját, és sok ember tett delay(20)-at a rádióadás után, hogy ne zavarodjon meg a rádiójuk. Ezt beszúrtam mindhárom feltételem rádióadása után, és az lett az eredmény, hogy egy kumma rádióadás nem ment át. Abszolút süket volt a vétel. Ezen berágtam, és delay helyett megtöbbszöröztem a rádióadást így:
Néztem az ACK választ, de azzal az a gondom, hogy ahhoz vételi módba kell raknom az adót is, hogy megvárja a választ. Az adó pedig elemről megy, és én nem a kis gyenge 1 mA antennateljesítményű NRF24L01+ változatot használom, hanem a 115 mA NRF24L01+PA+LNA változatot (link). Aláírom, az antenna 2 dBm, de azt még lehet javítani. A rádió elég intelligens ahhoz, hogy nem vesz fel folyamatosan ennyi áramot, csak akkor van tüske a fogyasztásban, amikor lead egy csomagot. De ha vételre kapcsolom, akkor elkezdi zabálni az elemet, Ardunino Minivel együtt 130 mA körülre ugrik a fogyasztás. A vevőegység nagyrészt hálózatról fog menni, ott nem szempont a fogyasztás.
Millis túlcsordulás - valóban nem szempont, hamarabb cserélek elemet.
Szekvenciaszám - Tudom, hogy vesznek el csomagok, a gyakorlatban négy pöckölésből hármat mutat a vevő. Az jobban aggaszt, hogy nullás csomagok is érkeznek, amikor a tömb egyik vagy az összes eleme nulla. Pedig két bitang rádióról beszélek egymástól 20 centire.
Köszönöm az eddigi válaszokat, de mivel még nem vagyok okosabb, közlöm a teljes kódot, hogy ne legyen félreértés.
/* transmit YourDuinoStarter Example: nRF24L01 Transmit Joystick values - WHAT IT DOES: Reads Analog values and transmits them over a nRF24L01 Radio Link to another transceiver. - SEE the comments after "//" on each line below - CONNECTIONS: nRF24L01 Modules See: http://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo 1 - GND 2 - VCC 3.3V !!! NOT 5V 3 - CE to Arduino pin 9 4 - CSN to Arduino pin 10 5 - SCK to Arduino pin 13 6 - MOSI to Arduino pin 11 7 - MISO to Arduino pin 12 8 - UNUSED
// NOTE: the "LL" at the end of the constant is "LongLong" type const uint64_t pipe = 0xE8E8F0F0E1LL; // Define the transmit pipe
/*-----( Declare objects )-----*/ RF24 radio(CE_PIN, CSN_PIN); // Create a Radio /*-----( Declare Variables )-----*/ int joystick[3]; // 3 element array holding Joystick readings int erzekenyseg = 10; int helyzet=1; int longhelyzet=1; int x=1; int riaszt=1; int increment=1; long previousMillis = 0; long previousMillis2 = 0; int xtengely = 0; int ztengely = 0; int ytengely = 0;
Ja, még egy ötlet: csinálj egy szekvenciaszámot (1,2,3,...) amit folyamatosan növelsz. Ezt küldd el a csomag elején. Így látni fogod, hogy vannak-e kieső (elveszett) csomagok! Lehet, hogy más csomag is elveszik, nem csak amit keresel.
Ha ez RF24 - NRF24L01+ akkor az már önmagában csomagokat küldő, CRC-zett, akár még ACK-zott is protokollt használ. Még automatikus újrapróbálkozást is tud.
Ez elég robusztus, ráadásul 250kbps - 1/2 mbps sebességet tud, ami szintén elég jó.
Nekem a tippjeim: 1. rossz felparaméterezés (bár nem valószínű) 2. vevő oldalon hibás kezelés, esetleg puffer betellik??
Másrészt érdemes arra is gondolni majd a jövőben, hogy a millis() túlcsordul, bár ez csak 49 nap után történik meg, lehet, hogy itt felesleges ezt kezelni. (Utolsó szavak.)
Egyszerre tudom most is monitorozni putty nélkül a két eszközt. Az adót olvassa a serial monitor, a vevőre pedig egy LCD kijelzőt kötöttem, és ott jeleníti meg a kapott adatokat (ha kap).
A serial.print köröket már lefutottam, mindhárom ciklusban kiírja adó oldalon a megfelelő értékeket, tehát a ciklus lefut a feltételek teljesülése esetén, a paraméterek pedig megfelelők.
A rádió nagyon megbízhatatlan csatorna. Azt feltételezed, hogy mindig, minden byte a megfelelő helyen érkezik. Pedig a két eszköz nincs szinkronizálva.
Szerintem nem jó ötlet folyamatosan küldeni az adatokat. Ha lemarad egy-egy byte, azt honnan tudja a vevő?
Először készíts belőle adatcsomagokat (packet).
Adj hozzá headert, footert, esetleg CRC-t.
A vevő oldal pedig keresse ki a stream-ből a csomagot, dekódolja, és utána adjon értéket a tömb elemeinek.
Ha kétirányú a rádiód:
Utána legyen mindig nyugtázás. Amíg nem jött a másik féltől nyugtázás, addig ne küldje a következő csomagot.
Röviden: A rádiós library annyit tesz, hogy a kapott adatokat ráülteti a fizikai rétegre. Nem ellenőriz, nem szinkronizál, stb. Ezeket neked kell megoldanod.
Nem volt időm alaposan átrágni magam rajta. Első körben a Serial.print a megoldáshoz vezető első kulcs a változók kiírásával. A kódfejtésben mondjuk némi segítség lenne a void.Setup().
Persze mindez az adó és a vevő oldalon is (szívás, mert ugye két futó terminálképernyő kell hozzá, és nem tudom, hogy ez megvalósítható-e, soha nem próbáltam).
Egy mozgásérzékelőt kötöttem egy Nano-ra, s a kapott adatokat RF24 rádióval átlőni egy másik RF24-gyel felszerelt Uno-ra. A következő kódom van adó oldalon:
Az a gondom vele, hogy a mozgást simán átlövi, és annak megfelelően a vevő rendesen megkapja az adatokat. Tehát az első if lefut. A második és harmadik feltétel is lefut, de ott a rádió már nem küld jelet. A Nano-n látom felvillanni a 13. kimenethez csatlakozó ledet, ami jelzi, hogy rádiókommunikáció van. A vevő mégis csak az első feltétel teljesülése esetén fogadja az adatokat. A vevő lényes kódja:
done = radio.read( joystick, sizeof(joystick) );
Ugyanazt a tömböt használom, a tömb minden eleme mindig integer, mégsem kapom meg a két másodpercenkénti bejelentkező jelet. A bejelentkezést néha akkor kapom meg véletlenszerűen, ha megmozgatom a szenzort, s akkor több csomag között esetleg megy egy bejelentkezés is. Van valakinek esetleg ötlete? Próbáljak más libraryt a rádiókhoz?
Tippem szerint (nem mértem) táp-gond lesz. A 3 ultrahang plusz ez a negyedik opto már határra húzhatja a Nano-t. Bár a specifikációk szerint összesen nincs ki 100 mA, de jobb kétszer mérni. Feszültséget és áramokat is mérj, külön-külön és egybe is.
Plusz nem lenne nagyon hátrány egy Fritzing rajz sem a bekötésről.
Nem vagyok guru, de nem is értem a problémát. Az ultrahangos szenzorokkal nem távolságot mérsz? Akkor miért kell ez a cucc? Vagy ezzel elmozdulást akarsz érzékelni? A specifikáció egyébként 10 uF-ot javasol, és az eszköz közelében.
Arduino nano-ra van rákötve 3 ultrahangos szenzor, amik jól is működnek, míg rá nem csatlakoztatom ezt:
http://www.sharpsma.com/webfm_send/1487 Ekkor ugyanis elkezdek hibás értékeket kapni az ultrahangos szenzorok felől. 100 nF -os kondit kötöttem az 5V és a GND közé. Mi lehet a hiba?
