Arduino 3-i-1 tids- og værvisning: 11 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:23

Av Boomer48Følg Mer av forfatteren:

Jeg liker PIC -mikrokontrollere, og jeg liker programmering på samlingsspråk. Faktisk har jeg i løpet av de siste par årene lagt ut omtrent 40 prosjekter på nettstedet mitt basert på den kombinasjonen. Nylig bestilte jeg noen deler fra en av mine favoritt amerikanske leverandører, og jeg så en Arduino Nano, med en programmeringskabel, for bare 1,20 dollar mer enn en ren ATMEGA328 prosessorbrikke. Så jeg kjøpte et par av dem. Deretter lastet jeg ned Arduino IDE og tørket ut minnet om 'C ++' programmering.

Dette prosjektet er en sammensetning av en klokke som bruker GPS for timing og en RF-mottaker som dekoder værmeldinger fra en vanlig AcuRite-sensor. Resultatet er en tidsskala og temperaturvisning i liten skala. GPS -klokken og værrutinene er satt opp som separate, inkludert filer, så det er enkelt å gå inn i hovedrutinen og konfigurere den til å gjøre bare klokkefunksjonen eller bare værfunksjonen. Bare kommenter den riktige "#define" øverst i hovedrutinen hvis du bare vil ha en av funksjonene.

Hvis begge funksjonene brukes, viser topplinjen på LCD -skjermen lokal tid og nederste linje på LCD -skjermen viser fuktighet og temperatur i både Celsius og Fahrenheit. Hvis bare klokkefunksjonen brukes, viser topplinjen lokal tid og nederste linje viser UTC. Hvis bare værfunksjonen brukes, viser den øverste linjen den første mottatte sensoren og den nederste linjen viser enhver annen mottatt sensor. Jeg la til den muligheten fordi jeg har to værsensorer.

Trinn 1: Værsensor

AcuRite -værsensoren som brukes her, sender temperatur- og fuktighetsinformasjon hvert 16. sekund. På baksiden viser det et modellnummer på 000592TXR, men det er vanligvis annonsert som modell 06002M. Denne sensoren brukes av mange forskjellige værstasjonsmodeller, så den er lett å finne, og jeg klarte å få dem på eBay for under $ 20. AcuRite selger lignende sensorer for noen av værstasjonene, men de følger eller ikke den samme kommunikasjonsprotokollen. Det er noe som tyder på at 00606-temperatursensoren bare bruker det samme meldingsformatet, men med en ugyldig fuktighetsbyte.

Som sett i den første bølgeformen vist ovenfor, blir værmeldingene sendt ut i utbrudd med et gap på 2 ms mellom påfølgende meldinger. Den andre kurven som er vist ovenfor, utvider en del av en melding for å se bitens varighet og mønstre. Det er fire synkroniseringsbiter som er omtrent 600us høye etterfulgt av 600us lave. Databitene er representert med 400us høy etterfulgt av 200us lav (1) eller 200us høy etterfulgt av 400us lav (0).

Meldingsformatet består av 7 byte med data. De to første byte er sensor -ID og disse endres ikke (dvs. den bruker ikke en rullende kode). Den siste byten er en enkel additiv kontrollsum av de seks første byte. Den tredje byten er en batterinivåindikator og bør alltid være 44 hex hvis batteriet er bra. Den fjerde byten er fuktigheten, og den er en uskalert verdi mellom 0 og 99. Det er viktig å huske på at den mest betydningsfulle byten 4, 5 og 6 er en paritetsbit og ikke er en del av målingen verdier. Byte 5 og 6 er den skalerte temperaturen (Celsius) med de nedre 4 bitene av byte 5 som er sammenkoblet med de nedre 7 bitene av byte 6 for å danne en 11-bits verdi. Temperaturen er alltid representert som et positivt tall og blir bare negativt når skaleringen brukes. Skaleringen er (C / 10) - 100. Delingen med 10 er nødvendig fordi temperaturoppløsningen er i tideler av en grad. Subtraksjonen er nødvendig fordi sensoren legger til 100 for å holde den overførte verdien positiv.

Trinn 2: RF -mottaker

RF -modulen jeg bruker for dette prosjektet er RXB6. Det er en super heterodyne mottaker i motsetning til de mindre ønskelige superregenerative mottakerne. Hvis du ser på de billige RF -modulene der ute, vil du finne at sender- og mottakerkort ofte er samlet sammen. De fleste av de medfølgende mottakerne er superregenerative typer, så de har en tendens til å ha mye lavere ytelsesegenskaper (inkludert rekkevidde) enn super heterodyne -mottakere. Vi trenger bare mottakermodulen for dette prosjektet fordi vi får signaler fra en værsensorsender.

Trinn 3: RF -antenner

RXB6 kommer ikke med antenne. Du kan kjøpe noen spiralformede ganske billig, men det er også enkelt å lage din egen antenne. Faktisk kan en brødbrettkabel slippes på antennestiften på modulen hvis du ikke vil bli for fancy. Ideelt sett vil en rett trådantenne være 1/4 bølgelengde som er omtrent 6,8 tommer. Jeg gjorde i utgangspunktet jumper wire ting og hadde ingen problemer med å plukke opp sensoren min, selv om elektronikkverkstedet mitt er i kjelleren min.

En annen mulighet er å lage din egen spiralformede antenne. Det er en rekke planer for det på nettet, men den som er vist på bildet ovenfor er det jeg laget. Jeg brukte en solid kjernetråd fra et stykke Ethernet -kabel og lindet den rundt den glatte skaftet på en 5/32 tommers borekrone. La isolasjonen være på bortsett fra spissen som selder til RF -kortet. Du trenger 20 svinger. Du kan også bruke en 7/32 tommers borekrone og vikle 17 svinger i stedet. Noen av disse vil sannsynligvis fungere helt fint for områdene du sannsynligvis vil ha for sensorene dine. Den virkelige nøkkelen er å ha en god RF -mottaker til å begynne med. AcuRite -sensorene har også ganske sterke sendere.

Trinn 4: RF -kommunikasjonsprotokoll

Det er noen få forskjellige modulasjonsteknikker for overføring av data, men disse sensorene bruker den enkleste som er OOK (on-off-keying) eller ASK (amplitude-shift-keying). Siden vi har å gjøre med 0/1 databiter i dette eksemplet, er amplituden full på eller full av. Så for våre formål er OOK og ASK de samme fordi OOK betyr at RF -bæreren enten er full på eller full av. Meldingsformatet er vanligvis definert av produsenten av sendeenheten, og de kan bruke stort sett hvilken som helst overføringshastighet, hvilken som helst formateringsstil og hvilken som helst meldingslengde. 433-MHz-båndet er full av overføringer for ting som smarte målere osv., Så programvaren må justeres for å filtrere for bare meldingsformatet vi vil bruke.

Trinn 5: Tidsdata

Jeg bruker en billig GPS -enhet for å få nøyaktige tidsdata som automatisk starter på nytt etter strømbrudd. Jeg har flere GPS-enheter (uten skjermer) som sender ut standard NMEA-setninger, men den minste og billigste av enhetene jeg har er NEO-6M. NEO-6M-modulen er enkel å koble til Arduino fordi den bruker en seriell port på TTL-nivå. Den eneste virkelige forskjellen er at NMEA-standarden spesifiserer en seriell overføringshastighet på 4800, men NEO-6M er som standard 9600 baud. Du kan kjøre gratis "u-center" -programmet for å endre overføringshastigheten, men jeg la den bare stå på fabrikken. Det er også et gratis verktøy som heter GPSInfo (satt ut av Globalsat) som er veldig praktisk for visning av GPS -informasjon på PCen. Du kan koble GPS -enheten til en standard USB til TTL -kabel for å sjekke den eller konfigurere den ved hjelp av en PC. Husk at GPS-brikken på modulen faktisk kjører på 3,3 volt (via en innebygd spenningsregulator), så hvis du vil koble til RXD-porten, bør du nivåskifte ned fra 5 volt. TXD -porten kan kobles direkte til Arduino eller PC.

Trinn 6: Tidssoner

Å vise GPS -tid er en enkel ting å gjøre så lenge du bare vil vise UTC (Universal Time Coordinated). NMEA -setningene består av ASCII -tegn som kan sendes direkte til LCD -skjermen. Tidsdelen er i formatet HHMMSS. FF (timer, minutter, sekunder og brøk sekunder). For klokken vår er brøkdelen ikke nyttig, så alt vi trenger å forholde oss til er seks tegn. Problemet er at du deretter må konvertere til din lokale tid og til et 12-timers AM/PM-format hvis du vil ha det. Men noen ganger er problemer det som gjør livet interessant, så det er det den delen av programvaren egentlig handler om.

Når det gjelder tidssoner, kan du tro at det bare ville være 24 av dem med 12 av dem øst for UTC-plasseringen (+ soner) og 12 av dem vest for UTC-plasseringen (- soner). Faktisk er det noen oddball -er som er brøkdager og et par som overskrider 12 -timers "grense". Hvis du tilfeldigvis bor i et av disse områdene, beklager jeg fordi programvaren min bare står for 24 hele timers soner. Det er også noen av oss som bruker sommertid en del av året, men det blir ikke automatisk redegjort for i programvaren. Det vil kreve en oppslagstabell for fremtidige datoer, ekstra kompleksitet i programvaren og behovet for å oppdatere programvaren hvis ukene i året for overgangen endres. I stedet bruker maskinvaren en kortvarig kontaktbryter for å muliggjøre enkel innstilling av tidssonen (UTC -forskyvning).

Trinn 7: Skjematisk

Skjematisk er vist ovenfor og inkluderer tilkoblinger for et 4-biters 1602 LCD-grensesnitt. Seriedataene fra RF -mottakeren er på digitale logiske nivåer, så de er koblet direkte til en av Arduino datainngangsstifter. Pinnen er konfigurert i programvaren til å utføre en interrupt-on-change-funksjon slik at vi kan måle pulsbreddene. GPS TXD -utgangen er direkte koblet til Arduino RX -inngangen.

Det brukes to brytere. Som nevnt tidligere tillater en øyeblikkelig kontaktbryter innstilling av UTC -forskyvning. Bryteren kan trykkes når som helst for å gå inn i innstilt modus. I utgangspunktet vil displayet vise en ugyldig UTC -forskyvning på “+77”. Se avsnittet "Klokkeprogramvare" for instruksjoner for innstilling av UTC -forskyvning.

Den andre bryteren er en enkel av/på -bryter. I “av” -posisjonen vises klokken i 12-timers format (AM/PM) og i “på” -posisjonen vises tiden i 24-timers format. Denne bryteren kan når som helst endres for å veksle mellom formater.

Hvis bare klokkefunksjonen er ønsket, trenger ikke RF -mottakermodulen å være tilkoblet. Hvis bare værfunksjonen er ønsket, trenger ikke GPS -en og de to bryterne å være tilkoblet.

Trinn 8: LCD -programvare

Jeg pleier å bruke en av to typer LCD -grensesnitt. Den ene er standard 4-biters grensesnitt og den andre er et 3-leder grensesnitt som bruker et skiftregister. Jeg designet det grensesnittet da jeg jobbet med små PIC -mikrokontrollere som hadde et begrenset antall I/O -pinner. Jeg brukte 4-bits grensesnittet for dette prosjektet, men har min egen LCD-fil med fil i stedet for å bruke det generiske Arduino LCD-biblioteket. Det reduserer minneforbruket og kodekompleksiteten og lar meg også justere koden for spesifikke prosjekter som dette.

Trinn 9: Klokkeprogramvare

GPS-enheten sender ut standard NMEA-0183 setninger som er ASCII-strenger som inneholder en mengde informasjon. For denne applikasjonen valgte jeg GGA -setningen for å få tidsinformasjon fordi det er setningen jeg brukte for et tidligere GPS -prosjekt. Informasjonsfelt i NMEA -setninger er atskilt med kommaer, så etter at GGA -setningsoverskriften er oppdaget, vil programvaren normalt telle kommaer og kalle den riktige rutinen for hvert ønsket felt med GPS -informasjon. Bare tidsinformasjonen er nødvendig her og det er i feltet etter det første kommaet, så det er ikke nødvendig å telle.

De seks tidssifrene (HHMMSS) blir bufret og deretter behandlet etter at alle er mottatt. GPS -en kan sende ut noen ufullstendige meldinger tidlig, slik at buffererutinen bekrefter at hvert tegn er en ASCII -numerisk verdi. Hvis et dårlig tegn mottas, blir meldingen kastet. Dette kan også skje i sjeldne tilfeller under normal drift, spesielt hvis seriell portkommunikasjon faller litt. Jeg har bare sett dette en gang, og alt som skjedde er at tiden stoppet et sekund og deretter hoppet to sekunder i stedet for en.

Hvis programvaren er konfigurert til bare å vise tidsvisning, viser den første linjen på LCD -skjermen lokal tid og den andre linjen viser UTC. For UTC sender programvaren bare ASCII -tegnene direkte til skjermrutinen, med kolon (:) satt inn på riktig måte.

For å konvertere UTC til lokal tid, må UTC -forskyvningen (tidssonen) brukes. Fordi UTC -tiden fra GPS -en er i ASCII -format, konverterer programvaren ASCII -timetegnene til desimaler og legger deretter til UTC -forskyvningen. UTC -forskyvningen lagres som en positiv BCD -verdi med en tegnbit, så den blir først konvertert til en heltallsverdi og deretter negert hvis tegnbiten er angitt. Når verdien for lokal tid er beregnet, brukes en oppslagstabell for å konvertere den til BCD, og deretter konverteres BCD tilbake til ASCII for visning. Oppslagstabellen må håndtere 24-timers UTC-format samt +/- 12 tidssoner. For å gjøre dette opptar UTC -tidene fra 0000 til 2300 de midterste 24 oppføringene i tabellen med 12 oppføringer før og 12 oppføringer etter for å ta hensyn til tidssonene. Ett bord er i 12-timers format, så jeg har også lagt til en oppslagstabell for AM/PM-delen av skjermen. Den andre tabellen er i 24-timers format. Som nevnt tidligere lar en av/på-bryter velge 12-timers eller 24-timers format.

Tidssonen hentes fra EEPROM under initialisering og vises kort. Hvis den ikke er angitt minst én gang, kalles innstillingsrutinen. Innstillingsrutinen kan også kalles når som helst ved å trykke på den øyeblikkelige kontaktbryteren. Innstillingsrutinen vil initialisere displayet til “UTC OFFSET +77”. Et kort trykk på bryteren vil endre verdien til “-00”. Hvis det kreves en positiv tidssone, vil et nytt kort trykk endre verdien til "+00". Et langt trykk (> 1 sekund) vil flytte innstillingsmodusen til neste trinn. På dette tidspunktet vil hvert kort trykk øke tidsverdien til maksimalt 12. Etter at du har nådd ønsket tidssone, trykker du på og holder bryteren i mer enn 1 sekund og slipper den. Programvaren lagrer deretter UTC -verdien i EEPROM og viser kort “OFFSET SAVED”. Hvis du gjør en feil under oppføringen, er det bare å gå ut og trykke på bryteren igjen for å tilbakestille den.

NEO-6M krever ikke en god posisjonsfiksering for å sende ut tiden, så den bør sende ut meldinger så snart den får en satellitt. Inntil da vil displayet vise “NO DATA”.

Trinn 10: Værprogramvare

PIC -mikrokontrolleren har mulighet til å slå en timer på/av ved hjelp av en ekstern puls. Den samme inngangspulsen kan også brukes som et eksternt avbrudd for å signalisere en lesning av varigheten av pulsen. Arduino har ikke den nøyaktige muligheten, så jeg brukte funksjonen interrupt-on-change. På den ene kanten av RF -meldingspulsen lagres gjeldende mikrosekundtid av avbryterbehandleren. På motsatt kant beregnes den forløpte tiden for å bestemme pulsbredden.

Programvaren har en "DEBUG" -definisjon som gjør det mulig å vise rådataformatet til de mottatte meldingene. Det er også en definisjon for å spesifisere Arduino -inngangspinnen for seriestrømmen fra RF -mottakeren. Programvaren er satt opp for å beregne passende innstillinger for avbrudd ved endring av register basert på denne definisjonen. Beregningen fungerer bare for Arduino digitale pinner. En analog pin kan brukes i stedet, men det vil kreve hard koding av registerverdiene.

Avbryterbehandleren bestemmer om den registrerte tellingen er lang nok til å være en startpuls. Som nevnt tidligere er gapet mellom flere meldinger 2 ms, så det er det programvaren ser etter. På grunn av all trafikken på 433 MHz sørger den første screeningen i programvaren for at den målte tiden er minst 1,8 ms, men ikke større enn 2,4 ms. Etter at starten er oppdaget, ser programvaren etter synkroniseringsbitene (600us) og teller for å sikre at fire av dem mottas. Når disse testene er bestått, ser programvaren etter riktige bitetider på 200us og 400us.

Mottatte biter formes til byte og hver byte lagres. Etter at syv byte er mottatt, bekreftes sjekksummen for meldingen før videre behandling er tillatt. Hvis rå byte skal sendes ut (feilsøkingsmodus), blir bytes konvertert til ASCII -tegn og sendt ut til LCD -skjermen. Hvis det er ønskelig med fuktighets- og temperaturutganger, utføres de passende konverteringene.

De to byte med Celsius-data i RF-meldingen blir stappet sammen for å danne en 11-bits verdi. Den nedre delen forskyves til venstre en bit for å eliminere paritetsbiten og for å justere den med bitene i den øvre delen. De to bytes er formet til en 16-biters ordvariabel, og deretter blir det hele forskjøvet en bit for å få den endelige bitjusteringen. Ordet variabel blir deretter konvertert til en flytende punktvariabel for matematiske beregninger.

En stor fordel med å bruke C ++ på Arduino kontra monteringsspråk på PIC er at det forenkler matematiske beregninger. Som nevnt tidligere er Celsius -konverteringen (C / 10) -100. Resultatet konverteres til en streng og sendes til LCD for visning. Fahrenheit -beregningen er (C * 1.8) + 32. Resultatet blir igjen konvertert til en streng og sendt til LCD -displayet for visning. I begge tilfeller inkluderer strengkonverteringen det negative tegnet (hvis det er aktuelt) og desimaltegnet. Det kontrolleres for desimaltegnet for å sikre at bare ett tegn etter desimalen blir sendt til displayet. Denne kontrollen er nødvendig fordi strengen kan variere fra 3 til 5 tegn.

Jeg har to AcuRite -sensorer, så jeg la til en sjekk i programvaren for å sikre at dataene for den ene ikke overskriver dataene for den andre hvis programvaren er satt til å bare gjøre værfunksjonen. Den første sensoren som mottas etter oppstart, vises på linje 1 og den andre vises på linje 2. Ved å bruke feilsøkingsmodus kan jeg se hva ID -en er for hver sensor, så jeg kan gjøre en enkel sjekk i koden hvis jeg bare ønsket å behandle data fra en av dem.

Programvaren overvåker batteristatusen (byte3) og viser en melding hvis den indikerer lavt batterinivå. Denne meldingen overskriver alle andre data for den sensoren.

Trinn 11: Viser

Her er noen eksempelvisninger for de forskjellige funksjonene. Jeg har noen andre instrukser, men de fleste av mine PIC -mikrokontrollerprosjekter finner du på nettstedet mitt på: www.boomerrules.wordpress.com