Arduino RF -sensor dekoder: 5 trinn

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

Mitt forrige hus kom med et forhåndsinstallert sikkerhetssystem som hadde dørsensorer, en bevegelsessensor og et kontrollpanel. Alt var fast kablet til en stor elektronikkboks i et skap, og det var instruksjoner for å koble en fasttelefon til å automatisk ringe ut i tilfelle alarm. Da jeg prøvde å leke med det, oppdaget jeg at en av dørsensorene var ufullstendig installert og at en annen var periodisk på grunn av feil justering. Så mye for den profesjonelle installasjonen som ble spilt på visittkortet til sikkerhetsselskapet. Min løsning den gangen var å kjøpe et par internett -sikkerhetskameraer og en billig trådløs sikkerhetsalarm.

Spol frem til i dag og den trådløse alarmen sitter i en boks i kjelleren min. Etter at jeg kjøpte en billig RF -mottaker bestemte jeg meg for å se om jeg kunne dekode meldingene som sendes av forskjellige alarmsensorer og fjernkontroller jeg har. Jeg skjønte at siden de alle jobbet med den billige alarmboksen, må de alle bruke det samme meldingsformatet med bare en annen ID. Jeg fant snart ut at de bare er like i den generelle strukturen til meldingene. Så prosjektet gikk raskt fra trivielt til veldig interessant.

Trinn 1: Sensormoduler

Som du kan se på bildene ovenfor, inkluderer senderne døråpne sensorer, bevegelsesdetektorer, tilkoblings fjernkontroller og et trådløst tastatur som brukes til programmering av alarmboksen. Som det viser seg, bruker ikke to av disse enhetene den samme synkroniseringslengden eller bitvarigheten. Den eneste fellesheten, bortsett fra meldingslengden, er grunnformatet til bitene. Hver bit tar en fast tidsperiode med forskjellen mellom null og en som er arbeidssyklusen til de høye/lave delene.

Den vakre bølgeformen vist ovenfor er IKKE det jeg først mottok. Fordi det er så mye trafikk i 433-MHz-frekvensbåndet, måtte jeg sørge for å aktivere sensoren like før jeg angav omfanget til å utføre en enkelt trigger. Heldigvis legger sensorene ut flere kopier av datameldingen når de er aktivert, og fjernkontrollene og tastaturet fortsetter å sende ut meldinger så lenge en tast trykkes. Ved å bruke omfanget kunne jeg bestemme synkroniseringslengden og databitens varighet for hvert element. Som nevnt tidligere er synkroniseringstidene forskjellige og bitetider er forskjellige, men meldingsformatene har alle synkronisering på lavt nivå etterfulgt av 24 databiter og en stoppbit. Det var nok til at jeg kunne bygge en generisk dekoder i programvare uten å måtte kode alle de forskjellige detaljene for hver enhet.

Trinn 2: Maskinvare

Jeg bygde opprinnelig en sensordekoder ved hjelp av en PIC -mikrokontroller og monteringsspråk. Jeg har spilt med Arduino -varianter nylig, så jeg tenkte jeg skulle se om jeg kunne replikere det. Den enkle skjematikken er vist ovenfor, og det er også et bilde av prototypen min. Alt jeg gjorde var å bruke tre vanlige hoppetråder for å gå fra Arduino Nano til RF -mottakerkortet. Strøm og en enkelt datalinje er alt som trengs.

Hvis du leser Instructable på “3-i-1 tids- og værdisplayet”, vil du se at jeg bruker en vanlig RXB6, 433 MHz mottaker. Du kan kanskje få de veldig billige mottakerne til å fungere på kort avstand som er nødvendig for dette prosjektet, men jeg anbefaler fortsatt å bruke en super-heterodyne-mottaker.

Trinn 3: Programvare

Programvaren konverterer de mottatte bitene til ASCII -tegn som kan vises. Den sender ut verdien av synkroniseringslengden og lengden på 1 og 0 bits. Fordi jeg allerede kjente synkroniseringslengdene og bitformatene, kunne jeg ha skrevet programvaren spesielt for dem. I stedet bestemte jeg meg for å se om jeg kunne skrive det for å sortere synkroniseringslengdene og automatisk finne ut databitsene. Det burde gjøre det lettere å endre i tilfelle jeg vil prøve å oppdage andre formater på et tidspunkt. Det er viktig å merke seg at programvaren ikke vet om den første biten i en melding er en 1 eller en 0. Den antar at den er en 1, men hvis den finner ut at den burde vært et null, vil den invertere biter i den ferdige meldingen før du sender den ut av serieporten.

Tidspunktene for synkroniseringspulsen og databitsene bestemmes ved å bruke INT0 ekstern avbruddsinngang for å utløse en avbruddshåndterer. INT0 kan utløse på stigende, fallende eller begge kanter, eller på et jevnt lavt nivå. Programvaren blir avbrutt på begge kanter og måler hvor lang tid pulsen forblir lav. Det forenkler ting fordi meldingsstart/-synkronisering er en lavnivåpuls og bitene kan bestemmes basert på lavtidstiden.

Avbryterbehandleren bestemmer først om det registrerte antallet er langt nok til å være en start/synkroniseringspuls. De forskjellige enhetene jeg har bruker synkroniseringspulser på 4, 9, 10 og 14 millisekunder. Defineringsuttalelsene for min/maks tillatte synkroniseringsverdier er på forhånd i programvaren og er for øyeblikket satt til 3 og 16 millisekunder. Bittidene varierer også mellom sensorene, så algoritmen for dekoding av biter må ta hensyn til det. Bittiden for den første biten lagres som tiden for en påfølgende bitte som har en vesentlig forskjell fra den første biten. En direkte sammenligning av påfølgende bitetider er ikke mulig, så en "fudge factor" definere ("Variasjon") brukes. Bitavkodingen starter med å anta at den første databiten alltid blir registrert som en logikk 1. Denne verdien blir lagret og deretter brukt til å teste etterfølgende biter. Hvis et påfølgende databitantall er innenfor variansvinduet for den lagrede verdien, blir det også registrert som en logikk 1. Hvis det er utenfor variansvinduet for den lagrede verdien, blir det registrert som en logikk 0. Hvis logikken 0 bittiden er kortere enn den første bitetiden, så blir et flagg satt til å fortelle programvaren at byte må inverteres før de vises. Det eneste tilfellet der denne algoritmen mislykkes, er når bitene i en melding alle er 0 -er. Vi kan godta den begrensningen fordi den typen meldinger er meningsløse.

Sensorene jeg er interessert i har alle en meldingslengde på 24 databiter, men programvaren er ikke begrenset til den lengden. Det er en buffer for opptil syv byte (flere kan legges til) og definerer for minimum og maksimal meldingslengde i byte. Programvaren er konfigurert for å samle bitene, konvertere dem til byte, lagre dem midlertidig og deretter sende dem ut i ASCII -format via den serielle porten. Hendelsen som utløser meldingen er mottak av en ny start/synkroniseringspuls.

Trinn 4: Datalogging

Programvaren er konfigurert for å sende ut de konverterte dataene som ASCII -tegn via den serielle (TX) utgangen til Arduino. Da jeg laget PIC -versjonen, trengte jeg å koble til et terminalprogram på PCen for å vise dataene. En fordel med Arduino IDE er at den har en Serial Monitor -funksjon innebygd. Jeg satte seriell portfrekvens til 115,2k og deretter satte jeg Serial Monitor -vinduet til samme rate. Skjermbildet her viser en typisk skjerm med utganger fra en rekke sensorer som jeg har. Som du kan se, er dataene noen ganger ikke perfekte, men du kan enkelt bestemme hva den virkelige verdien av hver sensor skal være.

Trinn 5: Eksempel på mottakerprogramvare

Jeg har inkludert et eksempel på programvareliste som viser hvordan du kan bruke den innsamlede informasjonen til å motta et bestemt sett med koder for applikasjonen din. Dette eksemplet er konfigurert for å etterligne et av mine Etekcity eksterne utsalgssteder. Den ene kommandoen slår på LED -en som er innebygd i Nano (D13) og den andre kommandoen slår av LED -en. Hvis du ikke har en LED innebygd i Arduinoen din, kan du legge til motstand og LED som vist i diagrammet. I en ekte applikasjon vil denne funksjonen slå strømmen på/av for en stikkontakt (ved hjelp av et relé eller en triac). Synkroniseringstidene, bitetider og forventede databyte er alle definert på forhånd for enkel endring. Du kan bruke hvilken som helst av de gjenværende datalinjene til å slå ting på/av, etc. for din spesifikke applikasjon. Bare legg til den gjeldende kommandokoden, og erstatt LED -av/på -logikken i "loop" for å passe dine behov.