UUENDAMINE: Pärast selle artikli ilmumist jätkus töö meie Arduino ilmajaama juures, mis tipnes ajakirja ilmumisega Avatud ilmajaam (OWS) . Vaadake seda täiendavate värskenduste, ressursside, koodi ja uute õpetuste kohta.
Lohesurf on üks kõige sõltuvust tekitavaid spordialasid maailmas. Selleks on vaja ainult lohelauda, veekogu ja mõnda lisaseadet. See on suurepärane viis loodusega ühenduse võtmiseks, meele vabastamiseks ja treenimiseks. Lisaks saate hulluks läheb tõesti sellega.
Oh, unustasin ühe olulise nõude: tuule. Ja seal on meil probleem: kunagi ei tea, kas tuult on või ei, kui te ei ela otse oma lemmik lohesurfikoha juures.
Ma elan Cordoba Argentina , umbes 130 kilomeetri (~ 80 miili) kaugusel järvest, kus harrastan lohesurfi. See on umbes kahetunnine sõit, millega saan hakkama. Kuid ma ei saa hakkama sellega, et ilmateade on ebatäpne. Ja kus ma elan, kestavad head tuuleolud vaid paar tundi. Viimane asi, mida soovite teha, on selgeks teha esmaspäevane ajakava, et minna lohesurfile ja leida end kahetunnise sõidu järel tuulevaiksel järvel jumalaid kirumas.
Mul oli vaja teada oma lemmik lohesurfi koha tuuleolusid - reaalajas. Nii otsustasin ehitada oma ilmajaama.
tegelike inimeste krediitkaarditeave
Eesmärk oli reaalajas ilmateate edastamine kodus brauserisse:
Enne kui lähen üksikasjadesse, võtkem hetkeks aega, et kaaluda sellise projekti põhiküsimusi ja hoiatusi:
Võite arvata, et kinnas on selleks, et jaam sõbralikumana paistaks; kuid tegelikult kasutatakse seda õhurõhuanduri testimiseks (kinnasurve suureneb täispuhutud kinda sees). Paremal näete jaama selle lõplikus asukohas, mis asub lähedal asuva torni kohal.
Kujundasin ja programmeerisin ka a lohesurfi teemaline veebisait , mis sisaldab a jaama mõõtmiste reaalajas graafik lohesurfi kogukonna välja aitamiseks. Lõpuks lõin a lohesurfirühm Facebookis .
Noh, ma käsitlen iga punkti kordamööda:
See oli kriitiline tegur ja paljuski viis kogu ülejäänud projekteerimisprotsessi. Enamik eeltoodud jaamu, mis on alla $ 2000 joone, nõudis USB-ühendus arvutiga . Kui varas tunnistab, et jaama kõrval on arvuti, oleks asi sellega lõppenud, kuna arvuti ja jaama vahetamise kulud ületaksid minu isikliku eelarve. Seetõttu otsustasin testida mitut riistvaraplatvormi, et jaama nullist juurutada madalamate kuludega.
Toetasin üksi selle kõrvalprojekti kulusid ja tegin kogu töö vabal ajal, nii et loomulikult oli see suur mure. Alustasin populaarsest PIC32 ja mõned eelnevalt kokku pandud mikrokiibiga Etherneti moodulid, kuid kulud ei olnud nii madalad, kui ma ootasin, ja riistvara kokkupanekul ja laiendamisel oli liiga palju üldkulusid. Siis hakkasin uurima Arduino : avatud lähtekoodiga riist- ja tarkvara elektroonika prototüüpimiseks C-keelt kasutades. See oli täpselt see, mida ma tahtsin ja sain mooduleid osta DealeXtreme . Ma sain hakata mängima vaid 15 dollari suuruste kulutuste ja kahe päevaga.
Muidugi Arduino on ka oma piirangud: minu kompileeritud tarkvara jaoks on ainult 2KB RAM-i ja 32Kt - see ei jäta palju ruumi väljamõeldud stringidele või kasututele muutujateleüks.
Praegu saab minu jaam mõõta: tuule kiirust, tuuleiili, tuule suunda, temperatuuri, niiskust, vihma ja atmosfäärirõhku. Temperatuuri, niiskuse ja rõhuga tegelevad paar raamatukogu, mis tegi elu palju lihtsamaks.
Tuule kiiruse ja vihma mõõtmine oli natuke segane. Andurid töötavad lüliti avamise ja sulgemise abil ( pilliroo lüliti ). Seega oli mul vaja rakendada riistvarakatkestusi, et andur kinni haarata kohe, kui see sisendi käivitab. See tähendab, et mul oli vaja helistada mõnele meetodile:
attachInterrupt(RAINGAUGE_PIN, countRainCycles, FALLING);
See katkestus rikuks tavapärase koodi täitmise ja kutsuks funktsioonid countAnemometerCycles või countRainCycles kohe, kui lülitil tekib voolu sulgemisel või avamisel tekkiv langev serv. Lüliti igal päästikul suurendatakse mõnda muutujat. (Hiljem kaalute ühikute teisenduste arvestamiseks need muutujad.)
void countRainCycles() { rainCyclesCounter++; // This is easy! And it actually works. }
Kuid mitte nii kiiresti! See protsess genereerib mis tahes riistvaralülitile omase lüliti hüppelise efekti tulemusel sadu valesid päästikuid. Õnneks on sellele probleemile olemas nii riist- kui ka tarkvaralahendused.
Põrkefekt tekib selle tagajärjel, et lüliti avab või sulgeb füüsiliselt oma kontaktid, mis loovad kontakti ülejäänud vooluahelaga. Kui kontaktid hakkavad eralduma (lüliti avamine) või ühendama (lüliti sulgema), võivad tekkida mõned väikesed elektrikaared, samuti vooluahela mehaaniline elastsus, mis käivitab vooluahela paariks millisekundiks. Kui lülitate valguslülitit, pole see mõju ilmne; kuid kui kinnitate signaali langevale servale katkestuse, käivitab see põrgatav efekt tonni katkestusi. Veel siin .
kliendi pool vs serveri pool
Rakendasin tarkvaras nii riistvaralise väljaütlemisahelat kui ka sarnast versiooni. Kuidas aga tarkvaraväljendust täpselt rakendada? Lihtne! Pärast esimese eeldatava päästiku tekkimist 'oodake' piisavalt aega, kuni põrge lahendub, enne kui hakkate uusi katkestusi kuulama. Seda saab teha paari C-reaga:
void countRainCycles() { if (nextTimeRainIterrupt == 0 || nextTimeRainIterrupt Funktsioon millis () tagastab praeguse täitmisaja millisekundites alates Arduino sisselülitamisest. Samuti väärib märkimist, et need muutujad tuleb määratleda volatiilsetena, et anda kompilaatorile käsk mitte optimeerida täitmist ja vältida riistvarakatkestuste ajal ebatäpseid väärtusi.
Kuidagi vajasin jaama kogunenud andmete salvestamiseks ja nende mõõtmiste perioodiliseks saatmiseks MySQL-i andmebaasi. Nii lisasin väärtuste registreerimiseks ja hankimiseks alati SD-pesaga Etherneti mooduli, kui kasutaja (server) jaamaga ühendust võtab. Kodus ADSL-ühendusega testimise ajal toimis see hämmastavalt hästi - kuid ma katsetasin seda 3G-Interneti (3G-modemi abil) 'põllul' katsetades peaaegu juuksed ära, kuna jaam lähtestas end juhuslikult, kui proovisin mõõdud! Pärast olulist katsetamist leidsin lõpuks, et Internetis pakutavad näited, mis kirjeldavad ühendatud kliendile andmete 'serveerimist', ei arvanud, et ühendus võib olla nii nõrk, et ühendus kliendiga võib kaduda pakettide keskel, mis põhjustab väljundpuhver oleks üle voolanud. Kuid miks peaks katkenud ühendus põhjustama puhvri ülevoolu? Noh, öelge, et ülekandeseanss algab ja jaam hakkab väljundpuhvrit andmetega täitma. Ideaalis tarbib klient seda puhvrit kiiremini kui täidetakse. Kuid 3G-modemiga ühenduse loomisel see nii ei olnud! Ühendus kliendiga oli liiga nõrk, nii et puhver täitus kiiremini kui seda kulutati, mis põhjustas nii puhvri ülevoolu kui ka jaama järsu taaskäivitamise.
Probleemi lahendamiseks pidin lisama funktsiooni Etherneti raamatukogu varustatud Arduinoga, mis läks umbes nii:
int EthernetClient::free() { if (_sock != MAX_SOCK_NUM) return W5100.getTXFreeSize(_sock); return 0; }
Siis sain enne, kui proovisin seda täiendavate andmetega täita, kontrollida, kas kliendil on puhvris ruumi.
while (file.available() > 0) { if (client.free() > 0) { // This was key to solving the issue c = file.read(); client.print((char)c); } else { // No free buffer? Ok, I'll wait a couple of millis... delay(50); } } file.close();
Muide, kui olete huvitatud Arduino programmeerimisest, siin on suurepärane juhend.
Teine huvitav ülesanne oli LIFO logi juurutamine. Miks see oli vajalik? Noh, tavaliselt kui salvestan mõõtmised antud faili, on lähenemine lihtne: avage fail, lisage uued proovid lõpule ja sulgege fail. Kuid öelge, et tahan tuua uusimad 1000 mõõtmist kronoloogilises järjestuses. Need mõõtmised on toimiku lõpus; nii et peaksin faili avama, viima kursori lõpuni, väljastama uusimad mõõtmised ja seejärel viima failikursori tagasi eelmise mõõtmise juurde ja väljastama selle, otsides piiritleja näidist, et tuvastada, kust alustada ja peatada. Arduinol pole selle RAM-i kiireks teostamiseks piisavalt RAM-i ega protsessori võimsust, seega vajasin teist lähenemist. Selle asemel otsustasin faili serverisse vastupidises järjekorras väljastada ja seejärel stringinumbrid serveripoolele tagasi tuua:
unsigned long filePosition = file.size(); file.seek(filePosition); while (filePosition >= 0) { if (client.free() > 0){ file.seek(filePosition); c = file.peek(); if (c != -1) { client.print((char)c); } if (filePosition <= 0) { break; } filePosition--; } }
Kõigi PHP-arendaja kogemustega on lihtne hankida uusimaid märke õiges järjekorras:
// $output has the reversed string measures, each sample is delimited by ; $rows = split(';', trim($output)); array_walk_recursive($rows, 'reverseString'); if (strlen($rows[0]) == 0) { array_shift($rows); // Remove the first line if empty } function reverseString(&$row, $key) { $row = trim(strrev($row)); } // $rows is now the array of the latest samples :)
Serveri poolel seadistan seejärel croni protsessi, et tuua iga kahe minuti tagant uusimad mõõtmised ja sisestada andmed MySQL-i mootorisse. Andmete kuvamiseks lõin www.kitesurfcordoba.com.ar ja kasutas jQuery graafikute (mis on ise loodud abil pChart v2.0 , suurepärane avatud lähtekoodiga raamatukogu).
Asjade toimimiseks oli vaja veel hulgaliselt trikke, mis on seotud nii tarkvara- kui ka riistvaraehitusega, kuid olen piisavalt kaua veninud - nii et räägime hoolduse minimeerimisest.
'Kuidas saan hooldust vähendada (peaaegu) nullini?'
See oli suur probleem, sest mul pole kindlasti lihtne jaama jõuda - kui ma oleksin nõus sõitma kaks tundi eemale vaid väiksema rikke kõrvaldamiseks, siis poleks ma pidanud teda esmajärjekorras tegema (ma ei maininud seda varem, kuid lõppude lõpuks oleme läbi elanud jaam tegelikult 'ta' ja tema nimi on Dorothy).
Millistest vigadest me siin räägime? Noh, näiteks: tarkvara võib riputada, võrk võib kaotada ühenduse, energiavarustus võib ebaõnnestuda (ja see juhtub) jne.
Põhimõtteliselt peab jaam tegema võimalikult palju enese taastamist. Sellepärast kasutasin ma nii pehmet kui ka kõva Vaata koeri . Neile, kes pole tuttavad, on valvekoer tarkvara- või riistvara, mis kontrollib, kas süsteem töötab õigesti, ja kui ei, siis üritab selle uuesti ellu äratada. Arduinol on sisseehitatud valvekoer, mida saate kasutada. Seadsin selle ootama 8 sekundit: kui kõne võtab sellest tähtajast kauem aega, lähtestab tarkvara valvekoer plaadi.
wdt_enable(WDTO_8S); // 'wdt' stands for 'watchdog timer'
Ma armastan seda funktsiooni. Siiski on olukordi, kus plaat lähtestatakse ja Etherneti moodul mitte. Miks? Noh, see on suhteliselt taskukohane prototüüpimisplaat, mitte eriti kallis, tõrkekindel seade (kindlasti ei tohiks sellega südamestimulaatorit ehitada). Selle puuduse ületamiseks pidin Arduino häkkima, ühendades riistvara lähtestamise sisendi ristjuhtmega plaadi enda digitaalsesse väljundisse. Lähtestamise vältimiseks tuleb lisada ka paar koodirida:
void setup() { digitalWrite(RESET_ARDUINO_PIN, HIGH); // Set it to HIGH immediately on boot pinMode(RESET_ARDUINO_PIN, OUTPUT); // We declare it an output ONLY AFTER it's HIGH digitalWrite(RESET_ARDUINO_PIN, HIGH); // Default to HIGH, set to LOW to HARD RESET ...
Pärast seda suutsin Arduinole ja kõigile selle peal asuvatele moodulitele (ka Etherneti moodulile) riistvara lähtestada, helistades lihtsalt digitalWrite(RESET_ARDUINO_PIN, LOW)
, mis Dorothy paari sekundi pärast taas ellu äratas.
Lisaks taaskäivitub plaat pärast energiakadu. Ja kui Interneti-ühendus ebaõnnestub, kasutame SD-kaardi salvestusvõimalusi (andmeid saab kaardil hoida üle nädala ja server võib puuduvate proovide taastamiseks hankida vanu andmeid). Kõigi nende funktsioonide kombineerimine annab meile ülitugeva ilmajaama, mis suudab ellu jääda vaenulikes tingimustes, mille jälgimiseks see ehitati. Kokku läks see asi mulle maksma umbes 300 dollarit.
Gestalti põhimõtete näited päriselus

Ja lõpuks
Jaam töötab alates 2012. aasta detsembrist. Siiani pole see ebaõnnestunud (või kui juhtus, siis jaam taastus piisavalt kiiresti, et lohesurfi kogukond ja mina seda ei märganud). Ligikaudu 500 lohesurfarit kontrollib ilmajaama regulaarselt enne kohale sõitmist. Nii et peale raskete tehniliste väljakutsete lahendamise tasu on mul olnud ka võimalus pakkuda hunnikule inimestele nauditavamat lohesurfikogemust.
üksEsialgu kasutasin Arduino uno . Hiljem läksin üle Arduino Mega suurenenud RAM-i ja välkmälu vajaduse tõttu.
Seotud: Töö ESP32 heliproovidega