433MHz-communicatie met microcontrollers

In het topic [howto] Klik-aan-klik-uit aan computer, waarin m.b.v. een PC draadloos apparaten aan-/uitgeschakeld worden, heeft een aantal mensen al geëxperimenteerd met microcontrollers, ipv een PC.

Voor het Arduino-systeem, een goedkoop, open source microcontrollerbordje, heb ik nu een library geschreven om eenvoudig deze draadloze schakelaars te simuleren: Download RemoteSwitch library.

De gebruikte setup kan haast niet eenvoudiger: een 433MHz SAW oscillator, precies dezelfde als in het KaKu-topic hiervboven, direct aan de Arduino gehangen:



M.b.v. de library kun je hiermee dan zeer eenvoudig je bestaande apparaten schakelen. Er zit een voorbeeld bij, waarmee je direct aan de slag kunt.

Voorbeeldje om KaKu-apparaat 10 op adres M aan te schakelen:
C:

1 2 3

KaKuSwitch kaKuSwitch(11); kaKuSwitch.sendSignal('M',10,true);

Easy does it

De code is gewoon C++, dus ook voor andere platformen zou dit een basis kunnen zijn. Ik heb voor zowel de "echte" KlikAanKlikUit als voor enkele goedkope klonen (m.n. de set verkocht bij de Action) een class aangemaakt. Extra remotes zouden makkelijk toe te voegen zijn.

Maar de topic-titel is niet voor niets algemeen gehouden; de ambitie reikt veel verder! Denk hierbij aan: het ontvangen van 433MHz-signalen vanaf remotes. En veel van die weerstationnetjes van o.a. de Kijkshop werken ook op 433MHz. Dus het uitlezen van de draadloze sensoren m.b.v. microcontroller is wellicht ook mogelijk!

Kortom, interessant voor heel veel home automation projecten!

Dubbel tops. Getest op iMac. Works.
Probleem met downloaden op iMac maar gedaan op Windows OK >> transfer to iMac.
Ga morgen testen en installeren Arduino IDE op Fedora Linux en kijken voor download probleem en testen.

Ga eerst de library doorlezen.

Thxs Fuzzillogic

Jarimacfed wijzigde dit bericht 05-01-2008 18:49 (7%)

Lees met veel interesse de RF topics.
Dit heeft me er toe aan gezet om een DMX naar RF schakeling te bouwen en te programmeren. Met de standaard RF modules van Niels zend ik de info met 2400 baud over naar mijn ontvangers (RGB Led lampen). Als er niet te snelle wisselingen zijn is dit prima te doen. Alleen blokkeer ik op dit moment nog alle klik-aan-klik-uit setjes in de directe omgeving omdat ik continue zend :-) Bij interesse wil ik de (Mikrobasic) code wel posten.

Volgende RF project op mijn lijst is het ontvangen van draadloze (temperatuur) sensoren om de temperatuur van diverse ruimtes te loggen.

@Mardaso: ben toevallig net naar het signaal van zo'n remote sensor (standaard Cresta Kijkshop-ding) aan het kijken. (screenshot). Ben je ook zoiets van plan? Of wil je je eigen sensoren maken? Mijn voorkeur gaat uit naar een bestaande remote sensor. Cresta-dingen zijn goedkoop (~€10, meerdere kanalen, geschikt voor buiten, riante batterijduur) Alleen het signaal 'even' reverse engineren is weer andere koek. Het lijkt op Manchester encoding, maarja, verder .. Wel vond ik nog een PDF met info over Radio Shack sensor, maar de daar genoemde timings kloppen niet met wat ik meet.

Maar voor het zover is, is er nog een heel ander probleem: hoe ueberhaupt binnenkomende signalen te verwerken op een (beperkte) microcontroller? De ontvangertjes pikken altijd een berg ruis op, en zetten die doodleuk ook op de digitale uitgang. Je zult het signaal op zijn minst al moeten herkennen. Heeft iemand daar ervaring mee?

Voor het ontvangen/verwerken van onze KaKu-systemen kan ik me wel een relatief simpele work-around voorstellen: gewoon een decoder-chipje van een kaku-apparaat aan de microcontroller hangen. Dat IC doet dan al de decodering. Maar toffer is het als het volledig op de μc zou kunnen draaien.

Fuzzillogic wijzigde dit bericht 05-01-2008 22:51 (8%)

Op Samenkopen.net loopt nu een 433 MHz zender/ontvanger + toebehoren actie. Ik ben er hard over aan het nadenken, zeker gezien de ultralage prijzen, om een usb1.1 chippie aan zo'n en/decoder te hangen en een prachtig algemeen wireless sensormoduletje te bouwen voor van alles in mijn huis.

@Fuzzillogic: Ik wil ook voor de kant en klaar zenders gaan voor dat geld kun je zelf niets bouwen.
Er zitten veel verschillende signalen op de 433MHz je zult je sensoren er op een of andere manier uit moeten pikken. Zag bij het testen van de DMX naar RF schakeling veel "vreemde" signalen voorbij komen en moest hier rekening mee houden met het zend protocol. Ik ben me nog aan het orienteren hoe ik dit het beste kan aanpakken.

Ik heb de RX433 van Velleman met 8 pinnen. Pin 2 van de Rx heb ik aangesloten op de Arduino.
Pin 3 dit is de lineare uitgang van de RX module.
Ik heb een variable pot meter van 1MOhm van de VCC naar de _
De center tap van de potmeter met in series een 820kOhm resistor naar de lineare ingang/uitgang.
Ik gebruik dit als een soort "squelch" om de ruis er uit te halen.
Iemand die een uitgebreide data sheet hiervan heeft oid ( niet die van Velleman)

De signalen van de Kaku TX kan ik ontvangen en decoderen met de status die ik opsla.
De microchip onthoud dan de codes die evt door andere remotes verzonden zijn.
zie voorbeeld De eerst letter zijn de lettercodes, tweede de cijfercode vertaald naar letter
derde aan of uit. De cijfers 1 of 0 zijn de status van de groep in binary formaat
D A ?
1

D B A
11

D C A
111

D C A
111

D A A
110

D A U
110

D B U
100

D B U
100

D C U
0

voorlopige Arduino code
C:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155

//Test set up for Arduino met Rx 433 ontvanger tbv KaKu int  ir_pin = 3;                //Rx ingang pin 3  int led_pin = 13;                //"Klaar om te ontvangen" flag, not needed but nice unsigned int a ; int v= 0; int b= 0; int c= 0; unsigned int time1 =0; unsigned int time =0; unsigned long code = 0; unsigned int  codea = 0; char lettercode;  unsigned int mystatus[16]; unsigned long data[110]; int samples[16] ={   0,0x100,0x400,0x500,0x1000,0x1100,0x1400,0x1500,0x4000,0x4100,0x4400,0x4500,0x5000,0x5100,0x5400,0x5500}; char mijnstring[6] ={   0,0x20,0x0,0x20,0x3F,0xA,}; //Chr 1 Letter, chr 3 cijfer, char 5 status A Aan U uit void setup() {   pinMode(led_pin, OUTPUT);        //Klaar om te ontvangen   pinMode(ir_pin, INPUT);   digitalWrite(led_pin, LOW);        //bog niet klaar   Serial.begin(9600); } void loop() {   int key = getIRKey();            //Haal de code   delay(80);   } int getIRKey() {   int z;   digitalWrite(led_pin, HIGH);       //Ok, ik ben klaar voor ontvangst  do{   a = pulseIn(ir_pin, LOW);  }  while(a >10000);  //Wait for repeat  b = getdata();    if (b ==0){ //geen errors   digitalWrite(led_pin, LOW);   decode(16); //decodeer 16 bits   codea = codea <<3; // bit shift 3 naar links   if  (codea == 0xA000){ //kijk hier naar de bits die altijd aanstaan     decode(0);  //decode 8 bits vanaf bit 0     convert(codea); //converteer naar letter     mijnstring[0] =lettercode; //eerste command     decode(8); //decode 8 bits vanaf bit      convert(codea);     mijnstring[2]=lettercode; //2e command     mijnprint();      decode2(22); //command aan-uit   }   else {          // ik heb signalen gekregen maar niet voor mij bestemd zijn     // worden deze herhaald??     time = millis() - time1;     if (time > 35000){       v++;       Serial.print("niet gevonden ");       Serial.println(v);       Serial.print("tussenpauze  ");       Serial.println(time,DEC);     }     time1 =millis();   }    }   else{     // bit errors  //    Serial.print("error  ");  //     Serial.print(b,HEX);   }      } int getdata(){   int error=0;   for (int i =0 ; i <25; i++)   {     data[i] = pulseIn(ir_pin,HIGH);     if (data[i] < 320 ){ // pulse is te kort       error = i;       break;     }   }   return error; } void decode(int stcode) {   // converteer 8 samples naar letter   codea = 0;   for(int i=stcode ;i < stcode + 8;i++) {     codea = codea >> 1;             if (data[i] < 1000)     {             // nothing at the moment     }     else {       codea = codea + 0x8000;     }   } } void decode2(int stcode) {   mijnstring[4]=0x3F;   codea = 0;   for(int i=stcode ;i < stcode+1;i++) {     codea = codea >> 1;             if (data[i] < 1000)     {             mijnstring[4]=0x55;       status(20);     }     else {       codea = codea + 0x8000;       mijnstring[4]=0x41;       status(21);     }   } } char convert(int mijnnummer){   for (int i =0; i<16; i++){     if (samples[i]== mijnnummer){       lettercode = i +0x41;     }   } } void mijnprint(){   for (int i =0; i<6; i++){     Serial.print(mijnstring[i]);   } } void status(int x){   int z;   c=01;    b =(mijnstring[2]-0x41);   z =(mijnstring[0]-0x41);   c =  c << b;   if(x ==21){     mystatus[z] = mystatus[z]| c;      }   else {     c = ~c;     mystatus[z] = mystatus[z] & c;   }   Serial.println(mystatus[z],BIN); } void printstatus(){   for (int i =0; i <16; i++)     Serial.println(mystatus[i],BIN); }

Probleem 1 is dat het gelijktijdig andere signalen kan ontvangen die in de buurt uitzenden.

In mijn omgeving krijg ik iedere 45 seconden een signaal binnen. Waar het van is ?? Weerstation

Probleem 2 Beperkt opslag geheugen voor data. of communiceren met computer.

Probleem 3 RX ontvangen op interrupt basis zodat niet konstant naar een input gekeken wordt.

Jarimacfed wijzigde dit bericht 24-01-2008 23:06 (0%)
Reden: code in block gezet

Ah cool Om de RSSI-out van zo'n ontvanger te gebruiken is idd een logische stap. Op de scoop zag ik dat je juist als je het eerste 'echte' signaaltje ontvangt hier een mooie piek op krijgt, waar je dan op kunt triggeren met een interrupt.

Je kunt overigens de hardware-timers gebruiken van de Atmega voor het meten van pulselengtes. Dit gaat dan icm interrupts, zodat je de gemeten waardes zou kunnen opslaan. Je moet hiervoor wel echt de datasheet van de atmega induiken, en flink wat low-level gehack moeten doen. Het kan iig wel gewoon vanuit de Arduino-omgeving, het is allemaal gewoon nog C. Hiervoor heb ik wel wat code gemaakt, maar geen commentaar En ik verdrink nu nog in ander werk, waardoor ik helaas weinig tijd voor hobby overhoud.

Wellicht dat het Arduino forum nog wat info kan geven, of anders misschien de arduino index. Op de site kun je eventueel ook een handleiding vinden om zelf een library te maken.

Tip: als je hier code post, zet het in een [code=c] [/code] blok

Jeuj ik heb weer wat tijd. Dus meteen de electronics maar weer uit de dozen gehaald

@Jarimacfed: ik heb ook de Velleman (althans, de foto is identiek met mijn exemplaar), maar ik snap niet hoe je die squelch nu geregeld hebt? Je zet een spanning op de RSSI uitgang van de RX?

Voor korte afstanden is het mogelijk om de RSSI-out zelf al direct als trigger te gebruiken. De spanning varieert van 0V tot 4V, afhankelijk van de ontvangen sterkte. 4V haal je alleen als je op hele korte afstanden naast de ontvanger uitzendt. De Atmega168 heeft een omslagpunt van LOW naar HIGH op 2,5V.

Scoopplaatje van ruissignaal (links) en eerste ontvangstsignalen (1V/div)



Achtergrondruis zit dus op zo'n 0,5V. De initiele piek zit hier op zo'n 3,0V, hetgeen dus voldoende is... ware het niet dat er geen muur (of mens ) tussen zender en ontvanger mogen zitten, want dan daalt het niveau teveel.

Het is dus zaak om het trigger-punt goed te kunnen instellen. Lukt dat dus met jouw potmeter? (Kan niet testen, enkel een 10K-pot hier). Iemand enig idee hoe dit aan te pakken? (MOSFET met een instelbaar spanningsdelertje (potmeter) voor de gate comes to mind, maar ik heb enkel een IRF540 liggen. Beetje overkill Bovendien heeft deze een triggerspanning van ongeveer 3V, daar schiet ik nog niks mee op)

Dit is mijn aansluiting


Ik heb nog een test gedaan van de zolder en had nog ontvangst in de woonkamer,
De spanning op de lineare ingang was omgeveer 2,7 Volt.

Hmm, ok, dus als ik het goed begrijp maskeer je de ruis nu gewoon door alles onder een bepaald niveau weg te drukken onder een offset-spanning. De waardes van die weerstanden, heb je daar nog documentatie over gevonden, of is het een educated guess geweest? Als ik het zo zie dan kan het ook prima met een potmeter van 10k en een weestand van zo'n 1M.

Maar maakt het eigenlijk uit? Die ruis zit toch rond het niveau 1V-1,5V, ver beneden het omslagpunt van de microcontroller. Het wordt dus toch al genegeerd.

Sowieso zul je dan blijven zitten met het probleem dat je signaal onder de 2,5V kan zakken op grotere afstanden/door meer muren. Inmiddels heb ik een oplossinkje die dat probleem verhelpt: een 10k potmeter aangesloten op pin 3 (RSSI out) en de massa. Sleepcontact via een 1k weerstand naar basis van BC547 (de enige transistor die ik los heb ) Emitter aan massa, collector via 10k weerstand aan +5V. Met de potmeter kun je nu heel nauwkeurig de gevoeligheid afregelen. RSSI komt versterkt, maar geinverteerd op de collector van de transistor te staan. De 10k-weerstand doet hier eigenlijk dienst als pull-up-weerstand, maar die zit al in de ATMega en is dus niet nodig als je em aan de Arduino hangt.

offtopic:
Ondertussen kwam ik erachter dat scope niet galvanisch gescheiden is van USB, en tijdens een stomme controleactie daarvan zekering van m'n multimeter doorgefikt. Leermomentje.

Fuzzillogic wijzigde dit bericht 25-01-2008 00:48 (6%)

Even een updateje. Afgelopen weekend bezig geweest om te kijken hoe betrouwbaar het signaal van KaKu (-achtige) remotes op te vangen en te interpreteren, puur op de microcontroller dus.

Valt toch niet mee eigenlijk.. Ik heb de volgende uitgangspunten gehanteerd:

• Hardware gebaseerd, non-blocking code voor het monitorren van radioverkeer. Dat betekent dus interrupts en hardware-timers. Dat is gelukt. M.b.v. de transistoroplossing hierboven hoeft het systeem niet constant te luisteren, maar kan getriggerd worden op een signaal van instelbare sterkte.
• Meerdere typen signalen ontvangen en verwerken. Dus niet alleen KaKu, maar ook m'n remote van action-setje, en later wellicht ook remote temperatuursensor en m'n Philips all-in-one TV-remote, welke ook op RF 433MHz kan uitzenden. Het signaal kan daardoor niet 'realtime' worden verwerkt, maar moet worden opgeslagen. Dat werkt nu. iig voor KaKu-achtige systemen.
• Herkennen van het type van het signaal (KaKu? RC5? temperatuursensor?) en decoderen m.b.v. microcontroller. Daar ben ik nog niet aan toegekomen.

De huidige arduino-code is vrij rommelig en buggy (pas na 1 seconde lang uitzenden van een signaal wordt er pas op gereageerd.. raar), maar het oppikken van een signaal werkt nu vrij aardig. De gemeten timings worden nu via seriele lijn doorgegeven aan de PC, waar ik m.b.v. processing even een tooltje gemaakt heb dat het signaal weer omzet in een grafiekje:



Dit signaal komt van m'n Action-remote, en ziet er zo perfect uit! De volgende stap is decoderen. Voor KaKu-achtigen lijkt me dat geen probleem, daarvan weten we al precies hoe het signaal is opgebouwd

Zoals gezegd is de code nu te rommelig, dus die volgt nog. Daarnaast, de methode van Jarimacfed om enkel de digitale uitgang van de RX te gebruiken en dan te triggeren op een langere '0', is wellicht beter dan wat ik nu heb: het geeft maximale gevoeligheid met minimale componenten. Maar die methode wil ik dan wel zoveel mogelijk in hardware hebben, m.b.v. de hardwaretimers en interrupts. Op die manier kan de code non-blocking worden gemaakt, iets dat essentieel is als je onafhankelijk zowel input als output wilt doen

Cool
Ik ben zeer benieuwd naar je code, ook al zal ik er behoorlijk wat voor moeten bijleren Hardware timers en interupts heb ik nog geen kaas van gegeten.
Als ik nog een tip mag geven:
http://www.samenkopen.net/action_products/965623/344301
Samenkoopactie met erg veel érg goedkope componenten, alleen verzenden is ietwat prijzig.
en dan specifiek dit:

Graphic Touch screen LCD Display 128x64 Blue, €17,95

daar kan je zoiets mee maken, ook totaal niet moeilijk

Volgens mij is een "squelch" op basis van reduceren van het signaal niet niet zo'n fantastisch idee omdat je de gevoeligheid eveneens onderuit haalt. Tevens is het output signaal volgens mij ongeveer TTL-like. Ik denk dat het beter is om de gevoeligheid maximaal te behouden en om een slimmere manier de "prut" uit het signaal te krijgen.

Ik heb een redelijk universeel non blocking Arduino routinetje gemaakt dat met een interrupt werkt. De Arduino doet gewoon andere taken op full-speed totdat er signaal is. Deze gebruik ik om op solide manier seriele signalen te kunnen ontvangen. Momenteel gebruik deze voor een infrarood AB maar KAKU signaal kan ik er ook prima mee ontvangen. In een proefopstelling heb ik e.e.a. werkend gekregen met een gekanibaliseerde 433 "Conrad"-ei.

Mijn ervaringen:
- Arduino kan uit uitstekend seriele signalen uitpluizen tot een fractie van een milliseconde.
- Geen additionele hardware voor squelch nodig. Dit beperkt het bereik en de betrouwbaarheid.
- KAKU-codering bevat (net als veel andere signalen) voldoende overhead en een vaste timing om niet op iedere scheet te reageren. Gewoon slim signaal uitpluizen en alleen de Arduino echt aan het werk zetten als er voldoende zekerheid is dat de ontvangen "pulp" werkelijk voldoet aan een codering.

quote:

P.K.Tonkes schreef op dinsdag 29 januari 2008 @ 20:53:
Mijn ervaringen:
- Arduino kan uit uitstekend seriele signalen uitpluizen tot een fractie van een milliseconde.
- Geen additionele hardware voor squelch nodig. Dit beperkt het bereik en de betrouwbaarheid.
- KAKU-codering bevat (net als veel andere signalen) voldoende overhead en een vaste timing om niet op iedere scheet te reageren. Gewoon slim signaal uitpluizen en alleen de Arduino echt aan het werk zetten als er voldoende zekerheid is dat de ontvangen "pulp" werkelijk voldoet aan een codering.

Heb je ook code? Inmiddels is het me gelukt om een behoorlijk betrouwbaar signaal uit te lezen, non-blocking. Nu wil ik het wel nog zo hebben dat-ie ook repeated code kan opnemen, zodat je, net als KaKu, kunt controleren of je bijv 3x dezelfde code achter elkaar ontvangen hebt.

Toevallig heb ik echt net gekeken hoe 'snel' de ruis op de digitale uitgang is. Het probleem is dat je bij elke flank toch iets moet doen voor de tijdmeting, en dat kost dus CPU-cycles. De kortste piekjes waren iets van 23µs. Daarmee gaat er toch wat CPU-power verloren aan overhead vanwege de ruis. Of dat echt een probleem is weet ik nog niet, maar je voorkomt het wel door al met hardware wat ruis te filteren. Met een simpele tor + potmeter (meer heb je niet nodig) lukt dat al aardig; je genereert pas een interrupt op het moment dat er ook een serieus signaal is.

Het bepalen of je een serieus signaal hebt te pakken biedt nog een ander voordeel: als je niet alleen 433MHz ontvangt met µC, maar ook uitzendt, dan kun je nu eenvoudig collision voorkomen, door simpelweg even te kijken of de weg vrij is. Dat is niet fool-proof natuurlijk, andere apparaten kunnen alsnog jouw data vernaggelen, maar het is tenminste iets.

Maar ik ben benieuwd naar andere ideeën

Je zal de Rx (interrupts) moeten blokkeren tijdens het zenden. want dat gaat parten spelen met software timing van het zenden.

Rf storingen van dimmers kan mischien ook nog problemen opleveren.


Mogelijk heden zijn ook nog om IR signalen te ontvangen van af de TV remote en hierdoor het licht aan te schakelen.

Je display ziet er goed uit. Ik heb ook iets dergelijks gemaakt maar kan dan afonderlijk meerdere kanalen bekijken
Ook met processing. Dit om te controleren of het signal steeds op het zelfde tijdstip start.

Eveneens is mijn code ook nog rommelig en duurt het nog langer om te programmeren.

Het zou ook handig zijn om een soort leer functie te bouwen.

Je moet toch rekening met externe signalen
Dit is een signaal die ik iedere 40 seconden ontvangt. Ik weet ook niet wat het is.
Dit zegt niet veel alleen +/- 112 pulsjes of informatie
Als ok het kan ontcijferen dan een gratis weer meter?? Wie weet.

code > 0_56_E10117/4-128-166-128-E10117/4-128-165-161-eoc 54........
code > 0_56_E10117/4-128-166-128-E10117/4-128-165-161-eoc 55............
code > 0_56_E10117/4-128-166-128-E10117/4-128-165-161-eoc 56..................................
code > 3_59_E10117/4-128-166-128-E10117/4-128-165-160-eoc 57....................
code > 0_56_E10117/4-128-166-128-E10117/4-128-165-161-eoc 58........................
code > 0_56_E10117/4-128-166-128-E10117/4-128-165-161-eoc 59......................
code > 0_56_E10117/4-128-166-128-E10117/4-128-165-161-eoc 60.................................
code > 1_57_E10117/4-128-166-128-E10117/4-128-165-160-eoc 61..............................
code > 2_58_E10117/17-0-138-96-E10117/17-0-138-80-eoc 62...........................

Met behulp van software gezocht naar de zelfde trigger informatie en kan je zien dat bepaalde code herhaald wordt. Het triggert niet altijd op het zelfde punt en ik weet ook niet wat het uitzendt

Geweldig topic
Heel mooi gedaan TS (en andere mensen die hiermee bezig zijn!!)
Prachtig gewoon. Precies waar ik al een tijdje over aan het denken ben, maar er nooit van komt.

Ik ga dit zeker blijven volgen.
Heel interessant allemaal.
Keep up the good work

quote:

Fuzzillogic schreef op zondag 27 januari 2008 @ 23:39:

• Meerdere typen signalen ontvangen en verwerken. Dus niet alleen KaKu, maar ook m'n remote van action-setje, en later wellicht ook remote temperatuursensor en m'n Philips all-in-one TV-remote, welke ook op RF 433MHz kan uitzenden. Het signaal kan daardoor niet 'realtime' worden verwerkt, maar moet worden opgeslagen. Dat werkt nu. iig voor KaKu-achtige systemen.

@Fuzzlogic als het een all-in-one remote is dan kan je deze waarschijnlijk ook programmeren voor een sony protocol. Als je eveneens een IR ontvanger heb
dan kan je deze code gebruiken en met de RemoteSwitch library de KaKU setjes bedienen.

toegevoegd
C:

1 2 3 4

if (key ==29)  //mijn key return code      {       sendCommand();     }

+ dit
C:

1 2 3 4 5 6 7 8

#include <RemoteSwitch.h> KaKuSwitch kaKuSwitch(11); void sendCommand() { kaKuSwitch.sendSignal('A',1,false); }

dit moet wel heel bekend zijn.

Dit heb ik uitgeprobeerd met mijn universeel remote control.

@Jarimacfed: de grap is dat mijn remote (Philips SBC RU885) direct de infraroodsignalen ook via 433MHz kan uitzenden Helaas zit daar wel nog een probleem: het gaat redelijk gezapig, waardoor er lange tijd een '0' wordt uitgezonden, dus niets. Daardoor kickt de automatic gain control van de RX weer in, met als gevolg een dikke ruis op de digital out

---

Maar zojuist heb ik fase 1 afgerond: het betrouwbaar onvangen van de KaKu-signalen, geheel in interrupts

Voor zowel Arduino als Processing heb ik wat software online gezet. Met de processing-tool krijg je de binnengekomen data realtime als grafiel op scherm gepresenteerd, zoals hierboven al getoond is.

Werking van het systeem
Hoewel de ATMega168 genoeg tijd heeft om nuttige signalen uit de rommel van de digitale uitgang van de 433MHz RX te filteren, leek mij dat zonde van de CPU cycles. De RSSI-uitgang geeft ook het ontvangen signaal weer, maar dan niet genormaliseerd; de signaalsterkte kun je hiermee dus bepalen. Zoals al eerder gezegd bleef het signaal op de RSSI-uitgang helaas ook bij voldoende signaalsterkte onder het omslagpunt van 2,5V van een arduino-ingang. Het signaal moet dus wat versterkt worden.

Daarvoor heb ik de RX dus middels een tor aan de Arduino gehangen. Nu met schemaatje:


Met de potmeter kun je de gevoeligheid instellen, zodoende houd je de meeste rommel buiten de deur en spaar je dus CPU-cycles uit.

Op pin 2 van de Arduino komt nu een 0 te staan als het signaal sterk genoeg is (geinverteerd dus!) Dit levert een interrupt op, waardoor startTimer() wordt aangeroepen. Deze functie luistert nu naar de digitiale uitgang van 433MHz RX. De signalen tussen 'lange' 0-signalen worden nu opgeslagen in een queue van 3 buffertjes. Deze buffertjes bevatten dus alleen de tijd die verstreken is tussen opeenvolgende hoge en lage edges, maar dat is ook precies wat we willen hebben.

De loop-functie, die dus volcontinu wordt uitgevoerd, kijkt steeds of er weer nieuwe data in de buffers is gekomen. Zo ja, dan wordt deze via de seriele poort naar de PC gestuurd. Als je daar de Processing-tool op hebt draaien dan zie je brute grafiekjes

Opmerkingen:

• De LED + weerstand in het schema zijn enkel ter indicatie. Je kunt zeg beiden weglaten, mits je de pull-up weerstand van pin 2 activeert.
• Je zou de hele schakeling weg kunnen laten en alleen naar de digital out kunnen luisteren. Er komt dan wel wat troep binnen, maar aangezien een geldig KaKu-signaal altijd 50 edges heeft kun je daar heel eenvoudig al op filteren
• Let bij Processing even op dat je de juiste com-poort gebruikt, anders doet-ie niks.
• In de code zie je dat ik een ledje op pin 13 aanstuur. Dit is natuurlijk geheel optioneel, maar wel lekker makkelijk. Zie ook foto
• De datasheet van de ATMega168 is een must!

Volgende stap is wat makkelijker: decoderen

Knap werk! Nu heb ik tenminste weer wat uit de dokteren

Potverdikke dit is gaaf zeg. Echt vette shit
Ik kan niet wachten totdat ik zo'n AVR in handen krijg... Eindalijk alles (Klik Aan Klik Uit) bedienen ZONDER computer Ik neem aan dat ik allemaal kan namaken en testen zonder zo'n Arduino-boardje? Dus gewoon met alleen die ATmega168?

Bedankt ook voor je mail Randy!!

quote:

atmoz schreef op donderdag 31 januari 2008 @ 22:36:
Potverdikke dit is gaaf zeg. Echt vette shit
Ik kan niet wachten totdat ik zo'n AVR in handen krijg... Eindalijk alles (Klik Aan Klik Uit) bedienen ZONDER computer Ik neem aan dat ik allemaal kan namaken en testen zonder zo'n Arduino-boardje? Dus gewoon met alleen die ATmega168?

In theorie.. ja. De atmega kan behoorlijk stand-alone werken, ik meen dat er slechts 1 weerstand nodig is. Maar dan draait-ie maar op 1MHz. Wellicht niet zo'n probleem, dan zul je de pre-scaler voor de timer op 16 ipv 256 kunnen zetten voor hetzelfde resultaat. Maar je kunt dan niet zomaar de arduino-code draaien; de bootloader stelt vast het e.e.a. in.

Je kunt ook een Arduino op een breadboardje maken. Zoals je ziet is dat ook nog best te doen. Maar ook hiermee zit je nog met de bootloader; je zult een programmer nodig hebben om die te kunnen flashen.

Ik wil niet heel veel reclame maken, maar er zijn nu enkele verkooppunten voor Arduino binnen Europa. De mijne komt uit Italië. Geen gezeik met douane en BTW! Hee, en ik zie net dat er ook in Nederland een verkoper is! Alleen zijn de verzendkosten wel exorbitant daar! Het loont misschien nog de moeite om het dan toch maar uit het buitenland te halen.

Maar misschien dat ik nog eens de bluetooth-versie aanschaf, dat maakt alles nog draadlozer

Fuzzillogic wijzigde dit bericht 01-02-2008 00:27 (4%)
Reden: Opmerking over verzondkosten eztronics

quote:

Fuzzillogic schreef op donderdag 31 januari 2008 @ 23:15:
[...]

In theorie.. ja. De atmega kan behoorlijk stand-alone werken, ik meen dat er slechts 1 weerstand nodig is. Maar dan draait-ie maar op 1MHz. Wellicht niet zo'n probleem, dan zul je de pre-scaler voor de timer op 16 ipv 256 kunnen zetten voor hetzelfde resultaat. Maar je kunt dan niet zomaar de arduino-code draaien; de bootloader stelt vast het e.e.a. in.

De timer op 16 zetten in plaats van 256 doe je toch alleen maar in het geval je geen externe osc gebruikt toch? Normaal werkt hij op 16Mhz, maar zonder externe osc werkt hij "maar" op 1Mhz, dus dan delen door 16 om toch op de "normale" snelheid van het programma uit te komen. Begrijp ik dat zo goed?

En wat die bootloader betreft, is dat een stukje code wat ervoor zorgt dat je met een simpele programmer de volgende keer sneller kunt programmeren? Met andere woorden: om die bootloader erin te krijgen moet je eerst een moeilijke programmer maken?

quote:

Je kunt ook een Arduino op een breadboardje maken. Zoals je ziet is dat ook nog best te doen. Maar ook hiermee zit je nog met de bootloader; je zult een programmer nodig hebben om die te kunnen flashen.

Hmzz, daar moet ik nog eens achteraan...

quote:

Ik wil niet heel veel reclame maken, maar er zijn nu enkele verkooppunten voor Arduino binnen Europa. De mijne komt uit Italië. Geen gezeik met douane en BTW! Hee, en ik zie net dat er ook in Nederland een verkoper is! Alleen doet de site het nu niet... Maar misschien dat ik nog eens de bluetooth-versie aanschaf, dat maakt alles nog draadlozer

Thanks, daar ga ik zeker ook naar kijken.
Zo'n Arduino kun je dus gebruiken om je programma erin te laden, om vervolgens de chip "stand alone" te gebruiken, right?

Hopelijk snap ik het een beetje. Ik ga hier echt snel mee aan de slag. Heb het eigenlijk een beetje gehad met PIC's in combinatie met de programmeertaal die ik tot nu toe altijd gebruikte.. (JALcc).

De atmega 168 draait standaard op 8MHz, alleen staat standaard ook de CKDIV8 (8 deler op de clock) fuse geprogrammeerd Die moet je dan eerst uitzetten, anders is het idd 1MHz.
In principe heb je geen enkel extern onderdeel nodig Al is het wel netjes als je een c'tje in de voedingslijn van de avr zet.

edit:
Je kan avr's gewoon programmeren met de paralelle poort (dapa kabel), zijn maar 5 draadjes. Met een bootloader kan je hem via de seriele poort flashen.

real_FireFly wijzigde dit bericht 31-01-2008 23:38 (20%)

quote:

atmoz schreef op donderdag 31 januari 2008 @ 23:28:
[...]


De timer op 16 zetten in plaats van 256 doe je toch alleen maar in het geval je geen externe osc gebruikt toch? Normaal werkt hij op 16Mhz, maar zonder externe osc werkt hij "maar" op 1Mhz, dus dan delen door 16 om toch op de "normale" snelheid van het programma uit te komen. Begrijp ik dat zo goed?

Het gaat om de kloktikken die geteld worden. Dus ja, die factor 16 trager kun je compenseren door de divider ook weer een factor 16 op te voeren. Overigens is de divder compleet arbitrary. Mijn doel was/is om buffertjes van 8 bit ipv 16 bit te gebruiken, waardoor je dus veel meer data kunt opslaan. Maar wellicht is het niet eens nodig.

quote:

En wat die bootloader betreft, is dat een stukje code wat ervoor zorgt dat je met een simpele programmer de volgende keer sneller kunt programmeren? Met andere woorden: om die bootloader erin te krijgen moet je eerst een moeilijke programmer maken?

Indeed. Met bootloader kan de controller zichzelf weer programmeren. Tevens kan het de controller initieren na het resetten, en zelfs een soort van BIOS

quote:

Zo'n Arduino kun je dus gebruiken om je programma erin te laden, om vervolgens de chip "stand alone" te gebruiken, right?

Klopt! Het bordje is eigenlijk enkel een I/O-bordje. Zelf heb ik ook een 2de 168 meebesteld. Enerzijds backup voor als ik er eentje om zeep help, anderzijds geeft het me dus de mogelijkheid om heel makkelijk een stand-alone iets te maken.

quote:

real_FireFly schreef op donderdag 31 januari 2008 @ 23:35:
De atmega 168 draait standaard op 8MHz, alleen staat standaard ook de CKDIV8 (8 deler op de clock) fuse geprogrammeerd Die moet je dan eerst uitzetten, anders is het idd 1MHz.
In principe heb je geen enkel extern onderdeel nodig Al is het wel netjes als je een c'tje in de voedingslijn van de avr zet.

Ah, thanks for the input Come to think of it, ik meen dat je die weerstand nodig hebt als je een reset-knop wilt gebruiken. Maar door te powercyclen reset je ook al, dus wellicht niet nodig

Wil je stand-alone arduino-code draaien, dan zul je wel rekening moeten houden met de gewijzigde kloksnelheid. Of je koopt een 16MHz kristalletje om de boel alsnog gewoon op 16MHz te krijgen. Dat staat allemaal wel in de datasheets.

quote:

Je kan avr's gewoon programmeren met de paralelle poort (dapa kabel), zijn maar 5 draadjes. Met een bootloader kan je hem via de seriele poort flashen.

Ah ja. Dat was het probleem: ik heb geen parallelle poort (laptop). Nou heeft m'n servertje er wel nog een, wellicht eens handig om daarnaar te kijken. De controllertjes zelf zijn maar enkele euro's, dus het is prima te doen om daar een zooitje van te kopen voor extern gebruik