Arduino 3-i-1 tids- och vädervisning: 11 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

Av Boomer48Följ mer av författaren:

Jag gillar PIC -mikrokontroller och jag gillar att programmera på monteringsspråk. Faktum är att under de senaste åren har jag lagt ut cirka 40 projekt på min webbplats baserat på den kombinationen. Nyligen beställde jag några delar från en av mina favoritleverantörer i USA och jag såg en Arduino Nano, med en programmeringskabel, för endast $ 1,20 mer än ett rent ATMEGA328 -processorchip. Så jag köpte ett par av dem. Sedan laddade jag ner Arduino IDE och dammade bort mitt minne av "C ++" -programmering.

Detta projekt är en sammanblandning av en klocka som använder GPS för timing och en RF-mottagare som avkodar vädermeddelanden från en vanlig AcuRite-sensor. Resultatet är en tids- och temperaturvisning i liten skala. GPS -klockan och väderrutinerna är konfigurerade som separata, inklusive filer, så det är lätt att gå in i huvudrutinen och konfigurera den för att göra bara klockfunktionen eller bara väderfunktionen. Avmarkera bara lämplig "#define" högst upp i huvudrutinen om du bara vill ha en av funktionerna.

Om båda funktionerna används visar den övre raden på LCD -skärmen den lokala tiden och LCD -skärmens nedersta rad visar luftfuktigheten och temperaturen i både Celsius och Fahrenheit. Om bara klockfunktionen används, visar den översta raden lokal tid och den nedersta raden visar UTC. Om bara väderfunktionen används, visar den översta raden den första mottagna sensorn och den nedersta raden visar alla andra mottagna sensorer. Jag lade till den möjligheten eftersom jag har två vädersensorer.

Steg 1: Vädergivare

AcuRite -vädersensorn som används här skickar information om temperatur och luftfuktighet var 16: e sekund. På baksidan visar det ett modellnummer på 000592TXR men det annonseras vanligtvis som modell 06002M. Denna sensor används av många olika väderstationsmodeller så det är lätt att hitta och jag kunde få dem på eBay för under $ 20. AcuRite säljer liknande sensorer för några av deras väderstationer, men de följer eller kanske inte samma kommunikationsprotokoll. Det finns en indikation på webben att 00606-temperatursensorn endast använder samma meddelandeformat men med en ogiltig luftfuktighetsbyte.

Som framgår av den första vågformen som visas ovan skickas vädermeddelandena i skurar med ett avstånd på 2 ms mellan på varandra följande meddelanden. Den andra vågformen som visas ovan expanderar en del av ett meddelande för att se bittiden och mönstren. Det finns fyra synkroniseringsbitar som är cirka 600us höga följt av 600us låga. Databitar representeras av 400us hög följt av 200us låg (1) eller 200us hög följt av 400us låg (0).

Meddelandeformatet består av 7 byte data. De två första byten är sensor -ID och dessa ändras inte (det vill säga: den använder inte en rullande kod). Den sista byten är en enkel additiv kontrollsumma för de första sex bytesna. Den tredje byten är en batterinivåindikator och bör alltid vara 44 hex om batteriet är bra. Den fjärde byten är luftfuktigheten och det är ett oskalat värde mellan 0 och 99. Det är viktigt att komma ihåg att den viktigaste bitgruppen 4, 5 och 6 är en paritetsbit och inte är en del av mätningen värden. Byte 5 och 6 är den skalade temperaturen (Celsius) med de nedre 4 bitarna av byte 5 sammanfogade med de lägre 7 bitarna av byte 6 för att bilda ett 11-bitars värde. Temperaturen representeras alltid som ett positivt tal och blir bara negativt när skalningen tillämpas. Skalningen är (C / 10) - 100. Delningen med 10 krävs eftersom temperaturupplösningen är i tiondelar av en grad. Subtraktionen krävs eftersom 100 adderas av sensorn för att hålla det överförda värdet positivt.

Steg 2: RF -mottagare

RF -modulen jag använder för detta projekt är RXB6. Det är en super heterodynmottagare i motsats till de mindre önskvärda superregenerativa mottagarna. Om du tittar på de billiga RF -modulerna där ute hittar du att sändar- och mottagarkort ofta buntas ihop. De flesta av de medföljande mottagarna är superregenerativa typer, så de tenderar att ha mycket lägre prestandaegenskaper (inklusive intervall) än super heterodyne -mottagare. Vi behöver bara mottagarmodulen för detta projekt eftersom vi kommer att få signaler från en vädersensorsändare.

Steg 3: RF -antenner

RXB6 levereras inte med en antenn. Du kan köpa några spiralformade ganska billigt men det är också lätt att göra din egen antenn. Faktum är att en brödkabelkabel kan halkas på modulens antennstift om du inte vill bli för tjusig. Helst skulle en rak trådantenn ha en våglängd på 1/4 som är cirka 6,8 tum. Jag gjorde först bygeln och hade inga problem att plocka upp min yttre sensor trots att min elektronikverkstad ligger i min källare.

En annan möjlighet är att göra din egen spiralformade antenn. Det finns en mängd olika planer för det på webben men den som visas på bilden ovan är vad jag gjorde. Jag använde en massiv kärntråd från en skrot av Ethernet -kabel och lindade den runt den släta skaftet på en 5/32 tums borr. Låt isoleringen vara på förutom spetsen som löds till RF -kortet. Du behöver 20 varv. Du kan också använda en 7/32 tums borr och linda 17 varv istället. Någon av dessa kommer förmodligen att fungera bra för de intervall som du sannolikt kommer att ha för dina sensorer. Den verkliga nyckeln är att ha en bra RF -mottagare till att börja med. AcuRite -sensorerna har också ganska starka sändare.

Steg 4: RF -kommunikationsprotokoll

Det finns några olika moduleringstekniker för överföring av data men dessa sensorer använder den enklaste som är OOK (on-off-keying) eller ASK (amplitude-shift-keying). Eftersom vi har att göra med 0/1 databitar i detta exempel är amplituden full på eller helt av. Så för våra syften är OOK och ASK desamma eftersom OOK betyder att RF -bäraren antingen är full på eller full av. Meddelandeformatet definieras i allmänhet av tillverkaren av sändaranordningen och de kan använda i stort sett vilken överföringshastighet som helst, vilken formateringsstil som helst och vilken meddelandelängd som helst. 433-MHz-bandet är fullt av sändningar för saker som smarta mätare, etc. så programvaran måste justeras för att filtrera efter bara det meddelandeformat vi vill använda.

Steg 5: Tidsdata

Jag använder en billig GPS -enhet för att få exakta tidsdata som automatiskt startar om efter ett strömavbrott. Jag har flera GPS-enheter (utan bildskärmar) som matar ut standard NMEA-meningar men den minsta och billigaste av de enheter jag har är NEO-6M. NEO-6M-modulen är enkel att ansluta till Arduino eftersom den använder en seriell port på TTL-nivå. Den enda verkliga skillnaden är att NMEA-standarden anger en seriell överföringshastighet på 4800 men NEO-6M är som standard 9600 baud. Du kan köra gratis "u-center" -programmet för att ändra överföringshastigheten men jag lämnade det bara vid fabriksinställningen. Det finns också ett gratis verktygsprogram som heter GPSInfo (släppt av Globalsat) som är mycket praktiskt för att visa GPS -information på datorn. Du kan ansluta GPS -enheten till en vanlig USB till TTL -kabel för att kontrollera den eller för att konfigurera den med en dator. Tänk på att GPS-chipet på modulen faktiskt körs på 3,3 volt (via en inbyggd spänningsregulator) så om du vill ansluta till dess RXD-port bör du nivåskifta ner från 5 volt. TXD -porten kan anslutas direkt till Arduino eller datorn.

Steg 6: Tidszoner

Att visa GPS -tid är en enkel sak att göra så länge du bara vill visa UTC (Universal Time Coordinated). NMEA -meningarna består av ASCII -tecken som kan matas ut direkt till LCD -skärmen. Tidsdelen är i formatet HHMMSS. FF (timmar, minuter, sekunder och bråkdelar). För vår klocka är bråkdelen inte användbar så allt vi behöver hantera är sex tecken. Problemet är att du sedan måste konvertera till din lokala tid och till ett 12-timmars AM/PM-format om du vill det. Men ibland är det problem som gör livet intressant så det är vad den delen av programvaran egentligen handlar om.

När det gäller tidszoner kanske du tror att det helt enkelt skulle finnas 24 av dem med 12 av dem öster om UTC-platsen (+ zoner) och 12 av dem väster om UTC-platsen (- zoner). I själva verket finns det några udda som är fraktionerade timmar och ett par som överskrider 12 -timmars "gräns". Om du råkar bo i ett av dessa områden ber jag om ursäkt eftersom min programvara bara står för 24 hela timmars zoner. Det finns också några av oss som använder sommartid en del av året men det redovisas inte automatiskt i programvaran. Det skulle kräva en uppslagstabell över framtida datum, extra komplexitet i programvaran och behovet av att uppdatera programvaran om veckorna på året för övergången ändras. Istället använder hårdvaran en tillfällig kontaktbrytare för att möjliggöra enkel inställning av tidszonen (UTC -förskjutning).

Steg 7: Schematisk

Schemat visas ovan och inkluderar anslutningarna för ett 4-bitars 1602 LCD-gränssnitt. Seriell data från RF -mottagaren är på digitala logiknivåer så att den är ansluten direkt till en av Arduino -datainmatningsstiften. Stiftet är konfigurerat i programvaran för att utföra en interrupt-on-change-funktion så att vi kan mäta pulsbredderna. GPS TXD -utgången är direkt ansluten till Arduino RX -ingången.

Det används två omkopplare. Som nämnts tidigare möjliggör en tillfällig kontaktomkopplare inställning av UTC -förskjutningen. Man kan trycka på strömbrytaren när som helst för att gå in i det inställda läget. Inledningsvis visar displayen en ogiltig UTC -förskjutning på “+77”. Se avsnittet “Klockprogramvara” för inställningar för UTC -offset.

Den andra omkopplaren är en enkel strömbrytare. I "av" -läget visas tiden i 12-timmarsformat (AM/PM) och i "på" -läget visas tiden i 24-timmarsformat. Denna omkopplare kan ändras när som helst för att växla mellan format.

Om bara klockfunktionen önskas behöver RF -mottagarmodulen inte anslutas. Om bara väderfunktionen önskas behöver GPS och de två omkopplarna inte anslutas.

Steg 8: LCD -programvara

Jag brukar använda en av två typer av LCD -gränssnitt. Den ena är standard 4-bitars gränssnitt och den andra är ett 3-trådars gränssnitt som använder ett skiftregister. Jag utformade det gränssnittet när jag arbetade med små PIC -mikrokontroller som hade ett begränsat antal I/O -stift. Jag använde 4-bitars gränssnittet för det här projektet men har min egen LCD-fil med fil istället för att använda det generiska Arduino LCD-biblioteket. Det minskar minneskonsumtion och kodkomplexitet och låter mig också justera koden för specifika projekt som det här.

Steg 9: Klockprogramvara

GPS-enheten matar ut standard NMEA-0183 meningar som är ASCII-strängar som innehåller en mängd information. För denna applikation valde jag GGA -meningen för att få tidsinformation eftersom det är meningen jag använde för ett tidigare GPS -projekt. Informationsfält i NMEA -meningar separeras med kommatecken, så efter att GGA -satsrubriken har upptäckts skulle programvaran normalt räkna kommatecken och anropa lämplig rutin för varje önskat fält med GPS -information. Endast tidsinformation behövs här och det är i fältet efter det första komma så ingen räkning behövs.

De sex tidssiffrorna (HHMMSS) buffras och bearbetas sedan efter att alla har tagits emot. GPS: n kan utfärda vissa ofullständiga meddelanden tidigt så buffertrutinen verifierar att varje tecken är ett ASCII -numeriskt värde. Om ett dåligt tecken tas emot, kasseras meddelandet. Detta kan också hända i sällsynta fall under normal drift, särskilt om seriell portkommunikation sjunker lite. Jag har bara sett detta en gång och allt som hände är att tiden pausade en sekund och sedan hoppade två sekunder istället för en.

Om programvaran är konfigurerad att endast visa tidsvisning, kommer den första raden på LCD -skärmen att visa lokal tid och den andra raden visar UTC. För UTC skickar programvaran bara ASCII -tecknen direkt till displayrutinen, med kolon (:) infogad på lämpligt sätt.

För att konvertera UTC till lokal tid måste UTC -förskjutningen (tidszon) tillämpas. Eftersom UTC -tiden från GPS: n är i ASCII -format konverterar programvaran ASCII -timtecknen till decimaler och lägger sedan till UTC -förskjutningen. UTC -förskjutningen lagras som ett positivt BCD -värde med en teckenbit så att den först konverteras till ett heltal och sedan negeras om teckenbiten är inställd. När det lokala tidstimvärdet har beräknats används en uppslagstabell för att konvertera det till BCD och sedan konverteras BCD tillbaka till ASCII för visning. Uppslagstabellen måste hantera 24-timmars UTC-format samt +/- 12 tidszoner. För att göra detta upptar UTC -tiderna från 0000 till 2300 de mellersta 24 posterna i tabellen med 12 poster före och 12 poster efter för att ta hänsyn till tidszonerna. En tabell är i 12-timmarsformat så jag har också lagt till en uppslagstabell för AM/PM-delen av displayen. Den andra tabellen är i 24-timmarsformat. Som nämnts tidigare möjliggör en på/av-omkopplare val av 12-timmars- eller 24-timmarsformat.

Tidszonen hämtas från EEPROM under initialiseringen och visas kort. Om den inte har ställts in minst en gång kallas inställningsrutinen. Inställningsrutinen kan också anropas när som helst genom att trycka på den momentana kontaktomkopplaren. Inställningsrutinen initierar displayen till “UTC OFFSET +77”. Ett kort tryck på strömbrytaren ändrar värdet till “-00”. Om en positiv tidszon krävs, kommer ytterligare en kort tryckning att ändra värdet till “+00”. Ett långt tryck (> 1 sekund) flyttar inställningsläget till nästa steg. Vid denna tidpunkt kommer varje kort tryckning att öka tidsvärdet till maximalt 12. När du har nått önskad tidszon, håll knappen intryckt i mer än 1 sekund och släpp sedan den. Programvaran sparar sedan UTC -värdet i EEPROM och visar kort "OFFSET SAVED". Om du gör ett misstag under inmatningen är det bara att avsluta och sedan trycka på strömbrytaren igen för att återställa det.

NEO-6M kräver inte en bra positionsfixering för att mata ut tiden så den bör mata ut så snart den får en satellit. Fram till dess kommer displayen att visa “NO DATA”.

Steg 10: Väderprogramvara

PIC -mikrokontrollern har möjlighet att koppla en timer till/från med en extern puls. Samma ingångspuls kan också användas som ett externt avbrott för att signalera en läsning av varaktigheten av pulsen. Arduino har inte den exakta kapaciteten så jag använde funktionen interrupt-on-change. På ena kanten av RF -meddelandepulsen sparas den aktuella mikrosekundtiden av avbrottshanteraren. På den motsatta kanten beräknas den förflutna tiden för att bestämma pulsbredden.

Programvaran har en”DEBUG” -definition som gör det möjligt att visa rådataformatet för de mottagna meddelandena. Det finns också en definition för att specificera Arduino -ingångsstiftet för serieströmmen från RF -mottagaren. Programvaran är inställd för att beräkna lämpliga interrupt-on-change-registerinställningar baserat på denna definition. Beräkningen fungerar bara för Arduino digitala stift. En analog pin kan användas istället men det skulle kräva hård kodning av registervärdena.

Avbrottshanteraren avgör om den fångade räkningen är tillräckligt lång för att vara en startpuls. Som nämnts tidigare är gapet mellan flera meddelanden 2 ms så det är vad programvaran letar efter. På grund av all 433-MHz-trafik säkerställer den första screening i programvaran att den uppmätta tiden är minst 1,8 ms men inte större än 2,4 ms. När starten har upptäckts letar programvaran efter synkroniseringsbitarna (600us) och räknar för att se till att fyra av dem tas emot. När dessa test har klarats letar programvaran efter de rätta bettiderna 200us och 400us.

Mottagna bitar formas till byte och varje byte sparas. Efter att sju bytes har mottagits kontrolleras kontrollsumman för meddelandet innan ytterligare behandling tillåts. Om råa byte ska matas ut (felsökningsläge), konverteras byte till ASCII -tecken och skickas ut till LCD -skärmen. Om luft- och temperaturutmatning önskas, utförs lämpliga omvandlingar.

De två byten med Celsius-data i RF-meddelandet sammanpressas för att bilda ett 11-bitars värde. Den nedre delen förskjuts åt vänster en bit för att eliminera paritetsbiten och för att rikta in den med bitarna i den övre delen. De två byten formas till en 16-bitars ordvariabel och sedan högerförskjuts det hela en bit för att få den slutliga bitjusteringen. Ordet variabel konverteras sedan till en flytande punktvariabel för matematiska beräkningar.

En stor fördel med att använda C ++ på Arduino kontra monteringsspråk på PIC är att det förenklar matematiska beräkningar. Som nämnts tidigare är Celsius -omvandlingen (C / 10) -100. Resultatet konverteras till en sträng och skickas till LCD -skärmen för visning. Fahrenheit -beräkningen är (C * 1,8) + 32. Resultatet konverteras igen till en sträng och skickas till LCD -skärmen för visning. I båda fallen innehåller strängkonverteringen det negativa tecknet (om lämpligt) och decimalpunkten. En kontroll görs för decimalpunkten för att säkerställa att endast ett tecken efter decimalen skickas till displayen. Den kontrollen behövs eftersom strängen kan sträcka sig från 3 till 5 tecken.

Jag har två AcuRite -sensorer så jag lade till en kontroll i programvaran för att säkerställa att data för den ena inte skriver över data för den andra om programvaran är inställd på att bara göra väderfunktionen. Den första sensorn som tas emot efter uppstart visas på rad 1 och den andra visas på rad 2. Genom att använda felsökningsläget kan jag se vad ID är för varje sensor så att jag enkelt kan kontrollera koden om jag bara ville bearbeta data från en av dem.

Programvaran övervakar batteristatus (byte3) och visar ett meddelande om det indikerar låg batterinivå. Detta meddelande skriver över all annan data för den sensorn.

Steg 11: Visar

Här är några exempelvisningar för de olika funktionerna. Jag har några andra instruktioner, men de flesta av mina PIC -mikrokontrollerprojekt finns på min webbplats på: www.boomerrules.wordpress.com