Arduino RF Sensor Decoder: 5 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:27

Mit tidligere hus kom med et forudinstalleret sikkerhedssystem, der havde dørsensorer, en bevægelsessensor og et kontrolpanel. Alt var hårdt kablet til en stor elektronikboks i et skab, og der var instruktioner til tilslutning af en fastnettelefon til automatisk at ringe ud i tilfælde af en alarm. Da jeg prøvede at lege med det, opdagede jeg, at en af dørsensorerne var ufuldstændigt installeret, og at en anden var periodisk på grund af forkert justering. Så meget for den professionelle installation, der blev spioneret på visitkortet til sikkerhedsselskabet. Min løsning dengang var at købe et par internet -sikkerhedskameraer og en billig trådløs sikkerhedsalarm.

Spol frem til i dag, og den trådløse alarm sidder i en kasse i min kælder. Efter min anskaffelse af en billig RF -modtager besluttede jeg at se, om jeg kunne afkode de meddelelser, der blev transmitteret af forskellige alarmsensorer og fjernbetjeninger, jeg har. Jeg regnede med, at da de alle arbejdede med den billige alarmboks, at de alle skulle bruge det samme meddelelsesformat med bare et andet id. Jeg fandt hurtigt ud af, at de kun ligner hinanden i meddelelsernes generelle struktur. Så projektet gik hurtigt fra trivielt til meget interessant.

Trin 1: Sensormoduler

Som du kan se på billederne ovenfor, omfatter transmitterne døråbningssensorer, bevægelsesdetektorer, tilkoblede fjernbetjeninger og et trådløst tastatur, der bruges til programmering af alarmboksen. Som det viser sig, bruger ikke to af disse enheder den samme synkroniseringslængde eller bitvarighed. Den eneste fællesart, bortset fra meddelelsens længde, er bitsformatets grundformat. Hver bit optager en fast tidsperiode med forskellen mellem et nul og et er arbejdscyklussen for de høje/lave portioner.

Den smukke bølgeform, der er vist ovenfor, er IKKE det, jeg først modtog. Fordi der er så meget trafik i 433-MHz frekvensbåndet, var jeg nødt til at sørge for at aktivere sensoren lige før jeg indstillede omfanget til at udføre en enkelt trigger. Heldigvis udsender sensorerne flere kopier af datameddelelsen, når de er aktiveret, og fjernbetjeningerne og tastaturet fortsætter med at udsende meddelelser, så længe der trykkes på en tast. Ved at bruge omfanget kunne jeg bestemme synkroniseringslængden og databitens varigheder for hvert element. Som tidligere nævnt er synkroniseringstiderne forskellige, og bitiderne er forskellige, men meddelelsesformaterne har alle en synkronisering på lavt niveau efterfulgt af 24 databit og en stopbit. Det var nok til, at jeg kunne bygge en generisk dekoder i software uden at skulle kode alle de forskellige detaljer for hver enhed.

Trin 2: Hardware

Jeg byggede oprindeligt en sensordekoder ved hjælp af en PIC -mikrokontroller og samlingssprog. Jeg har spillet med Arduino -varianter for nylig, så jeg tænkte, at jeg ville se, om jeg kunne replikere det. Den enkle skematisk er vist ovenfor, og der er også et billede af min prototype. Alt, hvad jeg gjorde, var at bruge tre almindelige springtråde til at gå fra Arduino Nano til RF -modtagerkortet. Strøm og en enkelt datalinje er alt, hvad der er nødvendigt.

Hvis du læser min Instructable på “3-in-1 Time and Weather Display”, vil du se, at jeg bruger en almindelig RXB6, 433-MHz modtager. Du kan muligvis få de virkelig billige modtagere til at fungere på den korte afstand, der er nødvendig for dette projekt, men jeg anbefaler stadig at bruge en super-heterodyne-modtager.

Trin 3: Software

Softwaren konverterer de modtagne bits til ASCII -tegn, der kan vises. Det udsender værdien af synkroniseringslængden og længderne på 1 og 0 bits. Fordi jeg allerede kendte synkroniseringslængderne og bitformaterne, kunne jeg have skrevet softwaren specielt til dem. I stedet besluttede jeg mig for at se, om jeg kunne skrive det for at sortere synkroniseringslængderne og automatisk regne ud databitene. Det burde gøre det lettere at ændre, hvis jeg på et tidspunkt vil prøve at opdage andre formater. Det er vigtigt at bemærke, at softwaren ikke ved, om den første bit af en meddelelse er en 1 eller en 0. Den antager, at den er en 1, men hvis den finder ud af, at den skulle have været et nul, vil den invertere bits i den færdige meddelelse, før du sender den ud af den serielle port.

Tidspunkterne for synkroniseringspulsen og databitene bestemmes ved hjælp af INT0 ekstern afbrydelsesindgang til at udløse en afbrydelseshåndterer. INT0 kan udløse ved stigende, faldende eller begge kanter eller på et stabilt lavt niveau. Softwaren bliver afbrudt på begge kanter og måler den tid, pulsen forbliver lav. Det forenkler tingene, fordi meddelelsesstart/-synkronisering er en lavniveaupuls, og bitene kan bestemmes ud fra deres lavniveaustid.

Afbrydelsesbehandleren afgør først, om det registrerede antal er længe nok til at være en start/synkroniseringspuls. De forskellige enheder, jeg har, bruger synkroniseringspulser på 4, 9, 10 og 14 millisekunder. De definerede sætninger for de min/max tilladte synkroniseringsværdier er på forkant i softwaren og er i øjeblikket indstillet til 3 og 16 millisekunder. Bittiderne varierer også mellem sensorerne, så algoritmen til afkodning af bits skal tage højde for det. Bittiden for den første bit gemmes, ligesom tiden for en efterfølgende bit, der har en væsentlig forskel fra den første bit. En direkte sammenligning af efterfølgende bitider er ikke mulig, så en "fudge factor" definere ("Variation") bruges. Bitafkodningen starter med at antage, at den første databit altid registreres som en logik 1. Denne værdi gemmes og bruges derefter til at teste efterfølgende bits. Hvis et efterfølgende databittal er inden for variansvinduet for den gemte værdi, registreres det også som en logik 1. Hvis det er uden for variansvinduet for den gemte værdi, registreres det som en logik 0. Hvis logikken 0 bit tid er kortere end den første bit tid derefter er et flag sat til at fortælle softwaren, at bytes skal inverteres, før de vises. Det eneste tilfælde, hvor denne algoritme mislykkes, er når bitene i en meddelelse alle er 0’ere. Vi kan acceptere den begrænsning, fordi den slags beskeder er meningsløse.

De sensorer, jeg er interesseret i, har alle en beskedlængde på 24 databit, men softwaren er ikke begrænset til den længde. Der er en buffer til op til syv bytes (flere kan tilføjes) og definerer for minimum og maksimal beskedlængde i bytes. Softwaren er konfigureret til at indsamle bitene, konvertere dem til bytes, gemme dem midlertidigt og derefter sende dem i ASCII -format via den serielle port. Hændelsen, der udløser meddelelsens output, er modtagelsen af en ny start/synkroniseringspuls.

Trin 4: Datalogning

Softwaren er konfigureret til at udsende de konverterede data som ASCII -tegn via Arduino's serielle (TX) output. Da jeg lavede PIC -versionen, var jeg nødt til at interface til et terminalprogram på pc'en for at vise dataene. En fordel ved Arduino IDE er, at den har en indbygget serieovervågningsfunktion. Jeg indstillede seriel porthastighed til 115,2k og indstillede derefter seriel monitorvindue til den samme hastighed. Skærmbilledet her viser et typisk display med output fra en række forskellige sensorer, som jeg har. Som du kan se, er dataene undertiden ikke perfekte, men du kan nemt bestemme, hvad den reelle værdi af hver sensor skal være.

Trin 5: Eksempel på modtagersoftware

Jeg har inkluderet en eksempelsoftwareliste, der viser, hvordan du kan bruge de indsamlede oplysninger til at modtage et specifikt sæt koder til din applikation. Dette eksempel er konfigureret til at efterligne en af mine Etekcity -fjernforretninger. Den ene kommando tænder LED'en, der er indbygget i Nano (D13), og den anden kommando slukker LED'en. Hvis du ikke har en LED indbygget i din Arduino, skal du tilføje modstanden og LED'en som vist i diagrammet. I en rigtig applikation ville denne funktion tænde/slukke for en stikkontakt (ved hjælp af et relæ eller en triac). Synkroniseringstiderne, bitetiderne og de forventede databyte er alle defineret på forhånd for nem ændring. Du kan bruge en hvilken som helst af de resterende datalinjer til at tænde/slukke ting osv. For din specifikke applikation. Tilføj blot den relevante kommandokode, der definerer, og udskift LED -tænd/sluk -logikken i "loop", så den passer til dine behov.