Arduino RF -sensoravkodare: 5 steg

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

Mitt förra hus kom med ett förinstallerat säkerhetssystem som hade dörrsensorer, en rörelsesensor och en kontrollpanel. Allt var fastkopplat till en stor elektroniklåda i en garderob och det fanns instruktioner för att koppla in en fast telefon för att automatiskt ringa ut vid larm. När jag försökte spela med det upptäckte jag att en av dörrsensorerna var ofullständigt installerad och en annan var intermittent på grund av felaktig inriktning. Så mycket för den professionella installationen som speglas på säkerhetsföretagets visitkort. Min lösning då var att köpa ett par internet -säkerhetskameror och ett billigt trådlöst säkerhetslarm.

Snabbspolning fram till idag och det trådlösa larmet sitter i en låda i min källare. Efter min förvärv av en billig RF -mottagare bestämde jag mig för att se om jag kunde avkoda meddelandena som sänds av olika larmsensorer och fjärrkontroller som jag har. Jag tänkte att eftersom de alla arbetade med den billiga larmboxen måste de alla använda samma meddelandeformat med bara ett annat ID. Jag fick snart reda på att de bara är liknande i den allmänna strukturen för meddelandena. Så projektet gick snabbt från trivialt till mycket intressant.

Steg 1: Sensormoduler

Som du kan se på bilderna ovan inkluderar sändarna dörröppna sensorer, rörelsedetektorer, tillkopplingsfjärrkontroller och en trådlös knappsats som används för att programmera larmboxen. Som det visar sig använder inte två av dessa enheter samma synkroniseringslängd eller bittid. Den enda gemensamma, förutom meddelandelängden, är bitars grundformat. Varje bit tar en bestämd tidsperiod med skillnaden mellan noll och en som är arbetscykeln för de höga/låga delarna.

Den vackra vågformen som visas ovan är INTE vad jag först fick. Eftersom det är så mycket trafik i 433-MHz-frekvensbandet var jag tvungen att se till att aktivera sensorn precis innan jag ställde in omfånget för att göra en enda trigger. Lyckligtvis lägger sensorerna ut flera kopior av datameddelandet när de aktiveras och fjärrkontrollerna och knappsatsen fortsätter att skicka meddelanden så länge en knapp trycks in. Genom att använda omfånget kunde jag bestämma synkroniseringslängden och databitens längd för varje objekt. Som nämnts tidigare är synkroniseringstiderna olika och bettiderna är olika men meddelandeformaten har alla en lågnivåsynkronisering följt av 24 databitar och en stoppbit. Det var tillräckligt för att jag skulle kunna bygga en generisk avkodare i programvara utan att behöva hårdkoda alla olika detaljer för varje enhet.

Steg 2: Hårdvara

Jag byggde ursprungligen en sensoravkodare med en PIC -mikrokontroller och monteringsspråk. Jag har spelat med Arduino -varianter nyligen så jag tänkte se om jag kunde replikera det. Den enkla schemat visas ovan och det finns också en bild på min prototyp. Allt jag gjorde var att använda tre vanliga bygelstrådar för att gå från Arduino Nano till RF -mottagarkortet. Ström och en enda datalinje är allt som behövs.

Om du läser min Instructable på “3-in-1 Time and Weather Display” kommer du att se att jag använder en vanlig RXB6, 433-MHz-mottagare. Du kanske kan få de riktigt billiga mottagarna att fungera på den korta räckvidd som behövs för detta projekt, men jag rekommenderar fortfarande att använda en super-heterodyne-mottagare.

Steg 3: Programvara

Programvaran konverterar de mottagna bitarna till visbara ASCII -tecken. Det matar ut värdet för synkroniseringslängden och längden på 1 och 0 bitarna. Eftersom jag redan visste synkroniseringslängderna och bitformaten kunde jag ha skrivit programvaran speciellt för dem. Istället bestämde jag mig för att se om jag kunde skriva det för att reda ut synkroniseringslängderna och automatiskt räkna ut databitarna. Det borde göra det lättare att ändra om jag vill försöka upptäcka andra format någon gång. Det är viktigt att notera att programvaran inte vet om den första biten i ett meddelande är ett 1 eller ett 0. Det förutsätter att det är ett 1 men, om det räknar ut att det borde ha varit en nolla, kommer det att invertera bitar i det färdiga meddelandet innan du skickar det från serieporten.

Tiderna för synkpulsen och databitarna bestäms med hjälp av INT0 extern avbrottsingång för att utlösa en avbrottshanterare. INT0 kan utlösa vid stigande, fallande eller båda kanterna eller på en stadig låg nivå. Programvaran avbryts på båda kanterna och mäter hur lång tid pulsen förblir låg. Det förenklar saker eftersom meddelandet start/synkronisering är en lågnivåpuls och bitarna kan bestämmas utifrån deras lågnivåtid.

Avbrottshanteraren avgör först om det fångade antalet är tillräckligt långt för att vara en start/synkroniseringspuls. De olika enheterna jag har använder synkroniseringspulser på 4, 9, 10 och 14 millisekunder. De definierade påståendena för min/max tillåtna synkroniseringsvärden finns i programmet i förväg och är för närvarande inställda på 3 och 16 millisekunder. Bitiderna varierar också mellan sensorerna så algoritmen för avkodning av bitar måste ta hänsyn till det. Bitiden för den första biten sparas liksom tiden för en efterföljande bit som har en signifikant skillnad från den första biten. En direkt jämförelse av efterföljande bittider är inte möjlig så en "fudge factor" -definition ("Variation") används. Bitavkodningen börjar med att anta att den första databiten alltid registreras som en logik 1. Det värdet sparas och används sedan för att testa efterföljande bitar. Om ett efterföljande databitantal ligger inom variansfönstret för det sparade värdet registreras det också som en logik 1. Om det ligger utanför variansfönstret för det sparade värdet registreras det som en logik 0. Om logiken 0 bittiden är kortare än den första bittiden då en flagga ställs in för att berätta för programvaran att byte måste inverteras innan de visas. Det enda fallet där denna algoritm misslyckas är när bitarna i ett meddelande är alla 0: or. Vi kan acceptera den begränsningen eftersom den typen av budskap är meningslös.

Sensorerna som jag är intresserad av har alla en meddelandelängd på 24 databitar men programvaran är inte begränsad till den längden. Det finns en buffert för upp till sju byte (fler kan läggas till) och definierar för lägsta och maximala meddelandelängd i byte. Programvaran är inställd för att samla bitarna, konvertera dem till byte, lagra dem tillfälligt och sedan mata ut dem i ASCII -format via serieporten. Händelsen som utlöser utmatningen av meddelandet är mottagandet av en ny start/synkroniseringspuls.

Steg 4: Dataloggning

Programvaran är inställd för att mata ut konverterade data som ASCII -tecken via den seriella (TX) utgången från Arduino. När jag gjorde PIC -versionen behövde jag ansluta till ett terminalprogram på datorn för att kunna visa data. En fördel med Arduino IDE är att den har en serieövervakningsfunktion inbyggd. Jag ställer in seriell portfrekvens till 115,2 k och ställer sedan in fönstret Seriell bildskärm till samma hastighet. Skärmbilden här visar en typisk display med utgångar från en mängd olika sensorer som jag har. Som du kan se är data ibland inte perfekta men du kan enkelt avgöra vad det verkliga värdet för varje sensor ska vara.

Steg 5: Provmottagarprogramvara

Jag har inkluderat ett exempel på programvarulista som visar hur du kan använda den insamlade informationen för att ta emot en specifik uppsättning koder för din applikation. Det här exemplet är utformat för att efterlikna en av mina Etekcity fjärranslutningar. Ett kommando tänder lysdioden inbyggd i Nano (D13) och det andra kommandot släcker lysdioden. Om du inte har en LED inbyggd i din Arduino, lägg sedan till motståndet och LED som visas i diagrammet. I en verklig applikation skulle denna funktion slå på/av strömmen för ett eluttag (med hjälp av ett relä eller en triac). Synkroniseringstiderna, bettiderna och förväntade databyte definieras alla på förhand för enkel ändring. Du kan använda vilken som helst av de återstående dataraderna för att slå på/av saker, etc. för din specifika applikation. Lägg bara till den tillämpliga kommandokoddefinieringen och byt ut LED på/av -logiken i "loop" för att passa dina behov.