Jag håller på med ett hobbyprojekt som går ut på att både mäta temperaturer runt om huset och även i förlängningen styra olika saker. Ett Homeautomation-system. Jag har fått en hel del info här från forumet och tänkte att det är dags att "betala tillbaka" litegrann. Det hela bygger på en PIC 16F684 och en trancievermodul från Electrokit http://www.electrokit.com/transceiver-4 ... data.48031 och en MAX232 för RS232 till datorn.
Jag kan i dagsläget ta emot och avkoda:
Temperatursensorer från Auriol (Säljs på Lidl ibland)
Temp/fukt/vind/regn från Esic (Säljs på CO)
Nexa fjärrkontroller
Mitt eget protokoll för hembyggda sensorer
Jag kan sända:
Mitt eget protokoll
Nexa
Jag jobbar på att kunna ta emot:
Biltema
Esic och Nexa finns beskrivet på wikin här.
Beskrivning av Auriol (Lidl) Protokoll
Mottagaren
Den digitala utgången (DData) från trancievermodulen (RTX-MID-5V) brusar friskt när det inte finns någon bärvåg i luften. Efter mycket testande så kom jag fram till att det är bäst att polla DData istället för att använda interupt. Enligt databladet så kan man lägga en spänning på 1,2V på den analoga utgången (AData) för att få den att sluta brusa, med kostnaden att känsligheten sjunker något. Den 1/4 4066 som används i schemat lägger på 1,2V på AData styrt från PIC. Det är så att Esic har c:a 78 ms mellan paketen i sin sändning. Under den tiden hinner AGC-kretsen i RTX att dra på full förstärkning och börja brusa, vilket får mitt program att tappa fattningen. När jag känner av en Stop-bit från Esic så lägger jag på 1,2V tills första biten i nästa paket ramlar in. På så vis kan jag fånga alla tre paket utan att tappa känslighet. Dessutom är det händigt när man mäter och testar att kunna slå på brusspärren från programvaran.
Mitt program bygger helt på tidmätning, jag använder Timer1 (16 bit) som tickar på med 1 us steg. Jag mäter alltid en hel period och får då två (16 bit)värden bitH och bitL. Jag ser på det som ett antal händelser. Händelse 1, när DData går hög för första gången så startas Timer1. Händelse 2, när DData går låg så stoppas Timer1 och om tiden är längre än 255us så sparas värdet i bitH. Annars så så hoppar jag tillbaka och väntar på Händelse 1 igen. När det brusar så kommer programmet att fara mellan Hänelse 1 och 2 mest hela tiden. I sällsynta fall lyckas bruset ta sig förbi Händelse 2. Händelse 3, när DData går hög igen så kontrollerar jag om tiden är längre än 255 us. I så fall kopieras värdet till bitL. annars så tillbaka och invänta händelse 1 igen.
Nu när vi kommit till händelse 3 så är det dags att avgöra vilket protokoll sändningen har. Jag har ett "tidfilter", en rutin som avgör om ett värde ligger inom ett interval. I filen tidfilter.h så har jag definierat tidsgränser för de olika protokollen. Rutinen SelProtocol fungerar (förenklat) så här:
Om bitH ligger inom 288 - 547us --> Lidl, PW eller Nexa
Om bitH ligger inom 800 - 1200 us --> Esic
Om bitH ligger inom 1368 - 1672 us --> Biltema
Lidl, PW eller Nexa
Om bitL ligger inom 800 - 1200 us --> NexaPre --> skifta in 0, vänta på Händelse 4
om bitL ligger inom 5200 - 7000 us --> PWPre (mitt eget protokoll) --> vänta på Händelse 4
Om bitL ligger inom 8568 - 10 472 us --> LidlPre --> Vänta på Händelse 4
Esic
Om bitL ligger inom 800 - 1200 us --> EsicPre --> skifta in 1, vänta på Händelse 4
Biltema
Om bitL ligger inom 1368 - 1672 us --> BiltemaPre --> Gör inget, kan ej tolka resten.
Händelse 4
Stoppa Timer1, kontrollera om t > 255 us. Spara i bitH. Annars --> Restore. Vänta på Händelse 5
Händelse 5
Stoppa Timer1, kontrollera om t > 255 us. Spara i BitL. Annars --> Restore.
Nu hoppar programmet till resp. protokolls rutiner för att tolka etta, nolla eller Start/Stop.
Och skiftar in bitarna i bufferten.
Vänta på Händelse 4
Nu hoppar vi mellan Händelse 4 och 5 tills Start/Stop.
Vid Start/Stop har jag två vägar att gå, har inte bestämt mig eller testat klart vilken som är den rätta vägen.
Väg 1: Om antalet mottagna bitar i paketet stämmer med antal förväntade --> Skicka paketet över RS232.
+ Snabbt, får iväg paketet nästan direkt.
- Riskerar att skicka samma paket 2 ggr.
Väg 2: Vänta in förväntat antal paket och kolla sedan och skicka det första som har rätt antal bitar över RS232.
+ Fler chanser att fånga ett korrekt paket
- "Döv" under tiden som jag väntar in paketen, riskerar att missa en sändning som ligger nära i tiden.
Restore
Återställer i lyssnarläge, nollar bufferten och valt protokoll mm. --> Händelse 1
Till datorn över RS232 så skickas följande (exempel):
Paket: protokoll #batchnummer (antal mottagna bitar) data
Paket: 3 #249 (036) 0C|23|00|20|D2
Paket: 3 #018 (036) 0C|23|00|21|01
Paket: 3 #198 (036) 0C|23|00|21|C7
Paket: 3 #009 (036) 0C|23|00|22|70
Batchnummret använde jag tidigare när jag skickade hela bufferten till datorn för att avgöra om paketen kom från samma sändning.
Det skulle gå att korta ner meddelandet över RS232 och på så sätt snabba upp så att risken att tappa sändningar minskar. Men det var ett bra sätt i början när jag kollade i ett terminalfönster vad jag fick ut ur maskineriet.
Vidare avkodning till temp, vind, regn mm gör jag i datorn. Sedan sparas datat i en MySQL-databas. just nu har jag en applikation som hämtar ur databasen när den startas och sen får den realtidsuppdateringar från 433RXTX. Det ska väl bli en webb-app senare men mycket går att återvinna.
Skickar med asm-filerna, jag har sett att det fins fler här som sysslar med sånt här. Kanske kan vara användbart för någon. Kom gärna med förslag till förbättring.
Så här ser labb-bygget ut.
Kretskort och snyggare bygge kommer senare.
