433MHz-communicatie met microcontrollers

[Fuzzillogic]

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. [edit] Nieuwste code en wiki: https://bitbucket.org/fuzzillogic/433mhzforarduino

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:

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!

[ Voor 2% gewijzigd door Fuzzillogic op 25-09-2011 18:18 . Reden: Link naar bitbucket voor de nieuwste code ]

[Jarimacfed]

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

[ Voor 7% gewijzigd door Jarimacfed op 05-01-2008 18:49 ]

[Anoniem: 163226]

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.

[Fuzzillogic]

@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.

[ Voor 8% gewijzigd door Fuzzillogic op 05-01-2008 22:51 ]

[mux]

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.

[Anoniem: 163226]

@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.

[Jarimacfed]

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:

//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.

[ Voor 0% gewijzigd door Jarimacfed op 24-01-2008 23:06 . Reden: code in block gezet ]

[Fuzzillogic]

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

[Fuzzillogic]

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)

[Jarimacfed]

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.

[Fuzzillogic]

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.

[ Voor 6% gewijzigd door Fuzzillogic op 25-01-2008 00:48 ]

[Fuzzillogic]

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

[j-a-s-p-e-r]

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

[Anoniem: 164441]

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.

[Fuzzillogic]

Anoniem: 164441 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

[Jarimacfed]

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

[Atmoz]

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

[Jarimacfed]

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:

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

+ dit

C:

 
#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.

[Fuzzillogic]

@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

[Jarimacfed]

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

[Atmoz]

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!!

[Fuzzillogic]

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

[ Voor 4% gewijzigd door Fuzzillogic op 01-02-2008 00:27 . Reden: Opmerking over verzondkosten eztronics ]

[Atmoz]

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?

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...

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).

[Anoniem: 83328]

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.

[ Voor 20% gewijzigd door Anoniem: 83328 op 31-01-2008 23:38 ]

[Fuzzillogic]

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.

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

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.

Anoniem: 83328 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.

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

[LED-Maniak]

Hoe snel zijn die 433.92 modules van niels trouwens? Ik wil er een 20 servo sturing mee maken, dat draait nu op 9600 bps, maar volgensmij kunnen ze dat neit aan, of wel?(moet natuurlijk ook nog de/encodering bij dus rate zal wel hoger moeten?)

[mux]

2.4 kbaud volgens mij. Ik krijg ze komende week binnen, dan krijg je uitsluitsel van me.

[j-a-s-p-e-r]

Ik meen mij 4800baud te herinneren.

[edit] Bron oa TD-er op het samenkopen.net forum. (van de actie van niels)

Over het algemeen hebben die dingen een bandbreedte van zo'n 5 kHz, oftewel 4800 baud.
Als je het signaal erover dus een beetje zou moduleren zou je vrij makkelijk 9600 bit/s kunnen halen.
Daarnaast lijkt het me dat je wel een of andere vorm van error-correctie zou moeten toepassen ergens tijdens de communicatie, omdat de 433MHz band nogal druk bezocht wordt door diverse apparaten (Afstandsbediening-verlengen, weerstation, draadloze hoofdtelefoon, etc)
Verder zijn die dingen vaak 1 richting, dus heb je al 2 setjes nodig en moet je voorkomen dat er tegelijk gezonden en ontvangen moet worden, dus zou je de handshake zelf moeten doen.

[ Voor 91% gewijzigd door j-a-s-p-e-r op 01-02-2008 13:20 ]

[Fuzzillogic]

j-a-s-p-e-r schreef op vrijdag 01 februari 2008 @ 13:18:
Ik meen mij 4800baud te herinneren.

[edit] Bron oa TD-er op het samenkopen.net forum. (van de actie van niels)

[...]

De digitale uitgang van het ding is 'all or nothing'. Hoe wil je daar nog op gaan moduleren? Lijkt mij lastig.

De 433MHz-moduletjes lijken me hier niet strikt noodzakelijk, aangezien je toch zelf zowel zender als ontvanger bepaalt. Waarom dan niet een betrouwbaarder 2-richting-systeem? Bijv iets als dit. Of bluetooth. Of Zigbee. Een stuk duurder dan die simpele 433MHz-modules, maar het bespaart je wellicht wel een hoop gedonder.

[teun-v]

Als het echt makkelijk moet zijn zou je ook kunnen kijken naar de Easy-Radio ER400TRS, dit is een 433MHz transceiver die direct op de uart van je microcontroller kan. Helaas wat aan de dure kant, bij farnell moet deze 31 euro opbrengen en je hebt er twee van nodig, hij kan daarvoor wel op redelijke snelheden (19200bps volgens het datasheet )verbindingen legen en is eenvoudiger dan de 2.4MHz transceiver als hierboven gesuggereerd wordt.

[Fuzzillogic]

Op de site van KlikAanKlikUit hebben ze nu een stel aanbiedingen. Ik heb net 2 bewegingsmelders daar besteld. De signalen kunnen ongetwijfeld prima met µC worden opgepikt, het is immers gewoon een KaKu. Misschien een automatische 'away from home'-detectie, die lichten dooft en de kachel lager zet.

Wellicht handig ook voor op de plee

[Willie-wortel]

ik wil me ook graag even mengen in dit topic. Na succesvol enige ervaring opgedaan te hebben met 2 modules: Circuitsonline wil ik nu ook proberen om de KaKu AB uit lezen.

Heb een ontvanger aan mijn ATmega32 gehangen, de externe interrupt (PD2) aangezet. Bij elke signaal verandering krijg ik nu een interrupt, op deze manier kan ik nu m.b.v. de Timer de tijd meten. Even wat test resultaten (2 x 255 heb ik er zelf ingezet om de start aan te geven):

255 255 7 247 221 186 140 86 21 204 120 27 179 66 199 66 178

255 255 5 246 222 187 142 87 22 203 118 22 173 57 187 51 161

Je ziet dat deze redelijk overeenkomen met elkaar.

[ Voor 4% gewijzigd door Willie-wortel op 01-02-2008 21:02 ]

[Fuzzillogic]

Damn, nu ben ik nog niet aan decoderen toegekomen De halve avond aan het zoeken naar mogelijke informatie van de standaard wireless thermo/hygro-sensors voor weerstations zoals die dingen van Cresta die ze bij de Kijkshop verkopen. Helaas kan ik echt compleet niets daarover vinden De sensors zijn gemaakt door Hideki Electronics, en worden ook verkocht door Mebus, Irox, Honeywell, Cresta en RST voor zover ik heb kunnen nagaan.

De bufferlengte moest worden opgevoerd, en nu krijg ik dit als output van het ding: breed plaatje. Kan iemand een educated guess doen over welk coderingsschema hier gehanteerd is? Het lijkt een beetje op Manchester-codering, maar toch ook weer niet eigenlijk...

[Jarimacfed]

Deze link beschrijft de protocol van Oregon Scientific data encoding. THN128. Misschien is dit een aanknopings punt.

Tussen haakjes Ik heb mijn hardware aangepast met je circuit en de software ge-implementeerd en de codes die ik nu ontvang zijn heel stabiel. (MacOSX)

Dit is de codes die ik ontvang met behulp van je software en waarschijnlijk ook een temperatuur station.

0 2 20 7793
1 2 14 7794
2 2 12 7176
0 38 45 79 42 81 41 51 10 52 9 82 10 52 9 52 39 54 7 54 7 54 7 55 6 86 6 55 6 55 6 57 34 60 1 214 30 171 12 6123
1 50 44 79 43 79 43 51 9 50 12 81 10 51 10 50 42 51 10 51 9 52 10 51 10 83 8 53 8 52 9 54 38 53 8 84 7 55 6 55 37 87 4 56 36 89 33 91 31 281 24 5572
2 32 43 81 41 82 40 52 9 52 9 84 7 54 8 54 37 56 5 57 4 56 5 58 3 88 3 58 3 59 2 63 29 6613
0 22 43 80 41 82 40 54 7 54 7 85 7 54 7 55 36 57 4 59 2 59 2 345
1 3 44 19 6612
2 21 43 42 80 42 82 40 54 7 53 8 84 7 54 7 55 37 57 4 59 1 401
0 6 37 89 33 98 21 7537
1 6 37 88 34 92 30 7531
2 6 38 85 37 88 34 7531
0 14 40 84 38 86 36 58 2 59 3 89 1 125 28 7163
1 4 25 164 18 5230
2 49 38 44 78 44 79 43 49 12 51 10 80 11 51 10 52 40 52 9 52 9 51 10 52 9 82 10 52 9 53 8 53 38 54 7 86 5 55 6 56 36 87 5 56 35 89 33 93 29 5877
0 16 39 82 40 83 39 55 6 55 6 86 5 57 4 57 35 7161
1 6 40 85 37 89 33 7532
2 34 42 81 41 81 41 51 10 52 9 83 8 53 8 54 38 56 5 55 6 57 4 57 4 87 4 57 4 58 4 61 30 281 24 6308
0 44 44 79 43 80 42 50 11 51 9 82 10 52 9 52 39 53 8 54 7 54 7 55 7 84 7 56 5 55 6 55 37 57 4 87 4 57 4 59 33 156 26 98 24 6001

De transmissie lengtes zijn niet bepaald constant

Deze link heb ik ook nog gevonden eveneens info over KaKu

[ Voor 3% gewijzigd door Jarimacfed op 02-02-2008 00:24 . Reden: Toegevoegd link ]

[Fuzzillogic]

Info over dat Oregon Scientific-spul kwam ik ook tegen. Op zich geeft dat wel aan dat het toch manchester zou kunnen zijn. Ik heb eens verschillende captures gemaakt met alleen de kanalen gewijzigd, maar echt veel duidelijkheid bracht dat nog niet

Om die sensors te ontvangen zul je minimaal 128 edges moeten bufferen, (ik heb em op 150 staan) en het aantal buffers van 3 naar 2 terugschroeven, anders past het niet Hiervoor zou het dus nuttig zijn om de buffer van 8-bit integers te maken ipv 16-bit. Maargoed, het werkt nu.

Aan de kant van processing vervolgens nog een vlaggetje toegevoegd zodat-ie alleen het eerste signaal toont, te resetten met een muisklik. Dat omdat het laatste signaal nogal mangeled was.

Morgen maar eerst eens met decoderen van KaKu aan de slag gaan, en wel zo dat er gelijk een 'sanity check' is op de ontvangen code, om te verifieren dat het ook echt een KaKu-achtig apparaat is en niet wat toevallige rommel.

[mux]

j-a-s-p-e-r schreef op vrijdag 01 februari 2008 @ 13:18:
Ik meen mij 4800baud te herinneren.

[edit] Bron oa TD-er op het samenkopen.net forum. (van de actie van niels)

[...]

Pardon, ik vergat te vertellen: er zijn idd twee versies, ik heb een 2.4 kbaud gekocht, er zijn er ook 4.8 kbaud en extra long range (hoewel ik betwijfel of het de meerprijs waard is; je kunt zelf ook gewoon een betere antenne maken)

[Megamind]

Even vraagje tussendoor. Jullie hebben nu die ontvangers aangesloten via een PIC aan je seriële poort? Je kan een ontvanger niet direct aansluiten op je seriële poort, om te testen? Of krijg je er dan teveel prut uit.

[Atmoz]

Megamind schreef op zaterdag 02 februari 2008 @ 16:57:
Even vraagje tussendoor. Jullie hebben nu die ontvangers aangesloten via een PIC aan je seriële poort? Je kan een ontvanger niet direct aansluiten op je seriële poort, om te testen? Of krijg je er dan teveel prut uit.

Dit topic heeft niet zoveel met computers te maken. En ook niet met PIC's.
Wel met AVR (Atmel) via een dev-boardje (Arduino). Hier worden RF zenders en ontvangers direct op een microcontroller aangesloten ZONDER tussenkomst van een computer. En dat is nu nét het leuke van dit alles.

_{ben al de hele middag op de Arduino site aan het kijken...(echt GEWELDIG dit allemaal. Hier ga ik zeker uren mee stil zijn!!!)}

[Megamind]

Ah ok, omdat het topic over algemene 433MHz microcontrollers gaat

Maar niemand heeft het om gewoon effe te testen op z'n PC direct aangesloten zonder tussenkomt van PIC of AVR of Adruino ?

[Fuzzillogic]

@Megamind: [howto] Klik-aan-klik-uit aan computer

Ok, even iets gemaakt dat uiteindelijk ook nog daadwerkelijk nuttig kan zijn: een schemerschakelaar Het principe is natuurlijk zeer eenvoudig: met een normale weerstand (10kΩ) en een lichtgevoelige weerstand (70Ω-100kΩ) een spanningsdelertje gemaakt, en die aan een analoge ingang gehangen. Komt de waarde een tijdje onder een drempelwaarde -> lamp aan. Komt de waarde boven de drempelwaarde -> lamp uit. De LDR zul je wel zodanig moeten opstellen dat je geen last hebt van het licht dat je juist aanzet, want anders gaat het licht ook weer uit, en heb je een knipperlicht

Arduino code, uiteraard met de KaKu-library die je dus in de eerste posting kunt vinden.

Het idee van de code is dat-ie ook rekeninghoudt met hoeveel lichter danwel donkerder het is dan de drempelwaarde. Stel de zon is al bijna donker en er schuift nog net een dikke regenwolk voor, dan wil je dat het licht snel aangaat.

Dit is slechts een opzetje, 'proof of concept'. Als iemand betere oplossingen hiervoor kan bedenken, dan graag!

[Anoniem: 164441]

Fuzzillogic schreef op dinsdag 29 januari 2008 @ 21:19:
[...]

Heb je ook code?

Hierbij een stukje voor uitlezen van KAKU AB's voor de Arduino met een ATMega168
- Non blocking, o.b.v. interrupts
- Na een kleine puls direct retour naar void loop(); minimale processor belasting
- Checksum controle zodat kans op onzin-codes minimaal is.

---

#include "wiring_private.h"
#include "pins_arduino.h"
#define KAKU_SignalPin 2 // Op deze input komt het signaal binnen. (Alleen pin 2 en 3 worden afgehandeld door interrupt) HIGH bij geen signaal.
#define KAKU_LedPin 13
#define KnipperLed 4
volatile int KAKU_Home, KAKU_Channel, KAKU_Command;
volatile unsigned long KAKU_Code;
void KAKU_Receive(void);

unsigned long IntervalTimer_1;
int status=HIGH;

void setup()
{
pinMode(KAKU_SignalPin,INPUT);
pinMode(KAKU_LedPin,OUTPUT);
pinMode(KnipperLed,OUTPUT);
attachInterrupt(KAKU_SignalPin-2, KAKU_Receive, RISING);

beginSerial(19200);
Serial.println("Ready.");
}

void loop()
{
// Gebruik bijvoorkeur geen delay(). Dit vertraagt de reactietijd van de verwerking na een ontvangen IR_Code
if(IntervalTimer_1<millis())
{
IntervalTimer_1=millis()+500;
digitalWrite(KnipperLed,status=!status);
}

if(KAKU_Code) // kijk of er iets ontvangen is.
{
Serial.print("Home=");
Serial.print(KAKU_Home,DEC);
Serial.print(", Channel=");
Serial.print(KAKU_Channel,DEC);
Serial.print(", Command=");
Serial.println(KAKU_Command,DEC);
KAKU_Code=0; // KAKU_Receive() doet niets zolang deze variabele niet terug is gezet naar nul.
}
}

void KAKU_Receive(void)// deze functie wordt uitsluitend aangesproken via een interrupt.
{
/* De data is gecodeerd in de vorm 1D0, waar D de databit is:

A B C
| | |
xxxxxxxxxxxxxxxxx
x : x
x 1 : DATA x 0
x : x
xxxx ........xxxxxxxxx........
| | | |
0 0.42 0.85 1.28 mS.

De databits worden per 25 verstuurd. De hele reeks van 25 bits wordt in 32ms verzonden. Er zijn drie dezelfde
reeksen binnen 500mSec nodig om een KAKU device te laten schakelen. Standaard 4ms rusttijd tussen de opeenvolgende reeksen.

KAKU_code heeft het volgende formaat: (msb) 0H0H0H0H0K0K0K0K0001010C0 (lsb)

H: huis-installatie (A-P)
K: kanaal
C: commando (1=aan, 0=uit)

Van de h's en de k's staat de msb rechts.
Overige nullen en enen worden gebruikt als checksum.*/

// Waarde van Counter_HIGH is na één milliseconde 1599 (praktijk gemeten)
// Waarde van Counter_LOW is na één milliseconde 941 (praktijk gemeten)

#define KAKU_CodeLength 25
#define KAKU_bit_Min 400 // A: alles kleiner wordt gezien als een stoorpuls
#define KAKU_bit_Max 2000 // C: goter is niet van KAKU afkomstig
#define KAKU_bit_Data 1000 // B: kleiner wordt gezien als een 0, groter als een 1
#define KAKU_TimeOut 1200

uint8_t bit=digitalPinToBitMask(KAKU_SignalPin);
uint8_t port=digitalPinToPort(KAKU_SignalPin);
unsigned int Counter_LOW=0, Counter_HIGH=0; // variabele alvast vullen zodat initialisatie niet in tijdkritische deel valt.
int BitCounter,x;

// TEST-1: voor als er timingproblemen zijn en de waarde van KAKU_bit_Max, KAKU_bit_Min en KAKU_bit_Data opnieuw bepaald moeten worden
// TEST-1: unsigned int KAKU_RawCode[KAKU_CodeLength];

if(KAKU_Code!=0)return; // ga direct terug als er nog niets uitgelezen is. Voorkomt herschrijven a.g.v. interrupt tijdens verwerking in loop()
BitCounter=0;
do{
Counter_HIGH=0;
while((*portInputRegister(port)&bit)==bit)Counter_HIGH++; // tel hoe lang signaal HOOG blijft
// TEST-1: KAKU_RawCode[BitCounter]=Counter_HIGH;
if(Counter_HIGH<KAKU_bit_Min || // <A: te kleine puls om een goed signaal te zijn. Steek hier verder geen cpu-tijd in en ga direct terug.
Counter_HIGH>KAKU_bit_Max) // >C: Te lang, kan niet van KAKU zijn. Steek hier verder geen cpu-tijd in en ga direct terug.
{
KAKU_Code=0;
return;
}
KAKU_Code=(KAKU_Code<<1)|(Counter_HIGH>KAKU_bit_Data);
Counter_LOW=0;
while(Counter_LOW<KAKU_TimeOut &&(*portInputRegister(port)&bit)==0)Counter_LOW++; // wacht zolang puls LAAG is.
}while(BitCounter++<KAKU_CodeLength && Counter_LOW<KAKU_TimeOut);// Zolang nog niet alle bits ontvangen en er niet vroegtijdig een timeout plaats vindt

// TEST-1: // gebruik onderstaande TEST=1 code voor oplossen van problemen met de timing
// TEST-1: if(BitCounter>20) // niet op iedere puls een verslag doen
// TEST-1: {
// TEST-1: Serial.print("BitCounter=");
// TEST-1: Serial.print(BitCounter,DEC);
// TEST-1: Serial.print(", KAKU_RawCode[]=");
// TEST-1: for(x=0;x<BitCounter;x++)
// TEST-1: {
// TEST-1: Serial.print(KAKU_RawCode[x],DEC);
// TEST-1: Serial.print(",");
// TEST-1: }
// TEST-1: Serial.println();
// TEST-1: }

digitalWrite(KAKU_LedPin, HIGH); // lampie aan om aan te geven dat er iets ontvangen is.
if(BitCounter==KAKU_CodeLength)// we hebben een complete reeks te pakken
{
if((KAKU_Code&0x15555FD)==0x28) // Kijk of de checksum klopt.
{// filter home, kanaal en commando er uit.
KAKU_Home =((KAKU_Code&0x20000)>>14 | (KAKU_Code&0x80000)>>17 |(KAKU_Code&0x200000)>>20 |(KAKU_Code&0x800000)>>23)+1;
KAKU_Channel=((KAKU_Code&0x200)>>6 | (KAKU_Code&0x800)>>9 |(KAKU_Code&0x2000)>>12 |(KAKU_Code&0x8000)>>15)+1;
KAKU_Command=(KAKU_Code&2)>>1;
}
else
{
Serial.println("Checksum error");
KAKU_Code=0;
}
}
else
{// onjuist aantal bits ontvangen
KAKU_Code=0;
}
digitalWrite(KAKU_LedPin,LOW); // lampie uit.
}

[LED-Maniak]

Nog even een vraagje betreft die 433.92MHz dingen van niels.

Ik heb nu een microcontroller die stuurt gegevens naar de zender en de andere controller ontvangt de gegevens en meld dit weer terug zodat ik weet dat alles goed aankomt.

Als ik alles bedraad doe, dan zie ik communicatie ontstaan. Doe ik de rf devices er tussen dan gebeurt er niets. Doe ik echter beide rf dingen(TX & RX) aan de rs232 poort van de pc, dan zie ik duidelijk dat de data perfect over en weer gaat.

Kan het zijn dat er een level converter tussen ontvanger en controller moet?


Hij loopt overigens goed op 4800 baud. Maar staat nu op 2400 baud voor de zekerheid.

[ Voor 7% gewijzigd door LED-Maniak op 03-02-2008 01:52 ]

[Atmoz]

Klinkt goed P.K.Tonkes, wat je daar gemaakt hebt Ik heb echt veel respect voor jullie die dit allemaal maken/testen/online zetten etc...

Kan zoals gezegt niet wachten om beide codes (zend en ontvang) van jullie uit te proberen. En omdat het hier toch vooral gaat om dat "Arduino" gebeuren heb ik meteen een vraagje: Heeft hier iemand ervaring met de ArduinoBT (BlueTooth)? Ik ben aan het denken om deze ook (naast de "gewone" Arduino) aan te gaan schaffen. Of hebben jullie zoiets van, dat is het geld (4x zo duur) niet waard?

[Fuzzillogic]

@P.K.Tonkes: geweldig, works as advertised Alleen.. je hebt de codering gebruikt van Emiel Mols? Het werkt duidelijk prima, en knap reverse engineering werk, maar zoals ik eerder aangaf is de officiele encoding net iets anders.

Jouw code werkt dus prima, en lijkt me uitstekend geschikt voor als je toch alleen met KaKu-apparaten in huis werkt. Zelf heb ik een mengeling van echte KaKu en wat goedkoop Action-spul, waardoor de timings net wat anders zijn. Ik moet de signalen haast wel opslaan om ze verder te verwerken.

@LED-Maniak: opvallend dat communicatie met PC vlekkeloos verloopt.. Dat het met de RX/TX van de microcontroller minder goed werkt was me wel al opgevallen. Wellicht dat de microcontroller minder goed met de rommel/ruis kan omgaan dan de PC?

@atmoz: ik overweeg ook nog om een BT-variant aan te schaffen. Jammer dat het zo duur is. Losse BT-chippies zijn duur, worden pas goedkoop vanaf grote aantallen. Ook jammer dat ze geen DIL-vesie van de atmega gebruiken, dus als-ie stuk is, dan kun je gaan leren hoe je SMD moet gaan solderen.

Wellicht een beter alternatief is om een losse BT-module aan te schaffen, en deze gewoon op de RX/TX van een normale arduino te hangen; in feite is de arduinoBT niet meer dan dat. Op de site en forum staat ongetwijfeld meer informatie, dus moeten we daar eens gaan snuffelen.

[Atmoz]

Fuzzillogic schreef op zondag 03 februari 2008 @ 13:48:

@atmoz: ik overweeg ook nog om een BT-variant aan te schaffen. Jammer dat het zo duur is. Losse BT-chippies zijn duur, worden pas goedkoop vanaf grote aantallen. Ook jammer dat ze geen DIL-vesie van de atmega gebruiken, dus als-ie stuk is, dan kun je gaan leren hoe je SMD moet gaan solderen.

Klopt helemaal. Zo heb ik er ook over gedacht. Was alleen aan het twijfelen of een "gewone" Arduino en een losse BT-module toch op hetzelfde neer kwam. Maar dit:

Wellicht een beter alternatief is om een losse BT-module aan te schaffen, en deze gewoon op de RX/TX van een normale arduino te hangen; in feite is de arduinoBT niet meer dan dat. Op de site en forum staat ongetwijfeld meer informatie, dus moeten we daar eens gaan snuffelen.

bevestigd het dus

En dat "snuffelen" op de site/forum ben ik al een paar dagen aan het doen Heb net even bij m'n broertje een Symbian60 telefoon opgehaald om alvast wat met BT te kunnen klooien... Als straks de ArduinoBT er is (of losse Adruino + BT-module) kan ik meteen aan de slag. Prachtig om alle KaKu apparaten te kunnen bedienen met je GSM

[Fuzzillogic]

Waarom een perse een Symbian-telefoon? Ik heb zelf een N95, dus dat maakt me verder niet uit, maar J2ME lijkt me hier juist de ideale oplossing voor. J2ME kan al lange tijd ook bia bluetooth kletsen, via het serial profile, dus ideaal voor deze toepassing. Een losse BT-module zoals de BlueSMiRF is redelijk ideaal. Het zal wel weer een opgave zijn om zoiets hier in NL of Europa te vinden

Natuurlijk is het wel leuk om ook direct een display aan de µC zelf te hangen. Om de boel te bedienen kun je eenvoudigweg de knoppen van je KaKu-remote gebruiken

Speaking of which: de ElCheapo Action-remote (zie beroerd plaatje) heeft een "feature" die de KaKu niet heeft: je kunt knopcombinaties maken! De 5 apparaten hebben allemaal hun eigen bit, naast dus de 5-bit kanaalselectie van het systeem! Ook 'aan' en 'uit' heeft zijn eigen bit: je kunt een aparaat gelijktijdig een aan- en uit-signaal versturen De ontvangers zelf reageren er niet op, maar voor de software is dat geen probleem.

[Atmoz]

Fuzzillogic schreef op zondag 03 februari 2008 @ 23:38:
Waarom een perse een Symbian-telefoon? Ik heb zelf een N95, dus dat maakt me verder niet uit, maar J2ME lijkt me hier juist de ideale oplossing voor. J2ME kan al lange tijd ook bia bluetooth kletsen, via het serial profile, dus ideaal voor deze toepassing. Een losse BT-module zoals de BlueSMiRF is redelijk ideaal. Het zal wel weer een opgave zijn om zoiets hier in NL of Europa te vinden

Natuurlijk is het wel leuk om ook direct een display aan de µC zelf te hangen. Om de boel te bedienen kun je eenvoudigweg de knoppen van je KaKu-remote gebruiken

Speaking of which: de ElCheapo Action-remote (zie beroerd plaatje) heeft een "feature" die de KaKu niet heeft: je kunt knopcombinaties maken! De 5 apparaten hebben allemaal hun eigen bit, naast dus de 5-bit kanaalselectie van het systeem! Ook 'aan' en 'uit' heeft zijn eigen bit: je kunt een aparaat gelijktijdig een aan- en uit-signaal versturen De ontvangers zelf reageren er niet op, maar voor de software is dat geen probleem.

[afbeelding]

Hmzz, tja. Daar heb ik nog niet aan gedacht. Ben dus zoals gezegt al de hele tijd op die Arduino site aan het kijken, en daar kwam ik iets tegen met Symbian60 telefoons... Dus vandaar dat ik daar naar ben gaan kijken. Heb dit ook vanavond uitgeprobeert en getest. Het werkt als een gek Alles bedienen via de Nokia is nu geen probleem. Maar inderdaad, ook zeker de moeite waar om eens naar dat Java spul te kijken. Hoef ik misschien toch geen andere telefoon te kopen/zoeken, en kan ik gewoon m'n fantastische Nokia 6230 hiervoor gebruiken.

Als ik het Arduino boardje deze week ontvang ga ik alles aan elkaar knopen. Nu heb ik alleen seriele (via BT) communicatie tussen telefoon en laptop kunnen testen. Maar dat is in princiepe hetzelfde als tussen telefoon en microcontroller. Ook ben ik bezig geweest met een SMSje te laten sturen via de seriele verbinding. Dat werkt volgens mij ook, maar kon het laatste gedeelte niet testen omdat de telefoon "geen netwerk" aangaf. Wel kwam er de melding dat de sms niet verstuurd kon worden, dus volgens mij heeft'ie het wel geprobeert Ik ben al met al zéér tevreden over de vorderingen vandaag!! Straks wordt alles aan elkaar geknoopt en heb je echt een prachtig systeem waar je ALLE kanten mee opkunt. Morgen weer verder prutsen. Nu eerst even wat rust

[Atmoz]

Waarom een perse een Symbian-telefoon? Ik heb zelf een N95, dus dat maakt me verder niet uit, maar J2ME lijkt me hier juist de ideale oplossing voor. J2ME kan al lange tijd ook bia bluetooth kletsen, via het serial profile, dus ideaal voor deze toepassing. Een losse BT-module zoals de BlueSMiRF is redelijk ideaal. Het zal wel weer een opgave zijn om zoiets hier in NL of Europa te vinden

J2ME werkt inmiddels ook Het is dus ook mogelijk om de Arduine (en dus de rest v/d wereld ) te besturen met een "simpele" telefoon zoals bijvoorbeeld de Nokia 6230.

Ik had nog 2 BlueTooth modules liggen, dus die ga ik aan de Arduino koppelen zodra die hier is... Die 100 euro voor de ArduinoBT bespaar ik me dus liever! Wel heb ik nog wat RFID spullen gekocht. Natuurlijk de lezer (die direct wordt ondersteunt via Arduino) en wat losse spullen zoals die kaartes (voor in de beurs), wat druppel-keys en een paar buttons. Ook heb ik me een glazen RFID ampule besteld (zeer klein) die ik ga laten implanteren (sick vet!! Althans, dat is mijn mening) sommigen vinden het raar en stom, maar na het vertellen dat sommige mensen hele sierraden onder de huid laten implanteren vinden ze het best leuk Of what about die chirurgen die soms hele "tools" zoals messen en scharen in lichamen laten zitten. Dan kan zo'n kleine glas ampule er wel mee door. Wat vinden jullie eigenlijk van dit idee? Sorry voor de offtopic... maarja het gaat toch een beetje over (interfacing the) Arduino he?

[Fuzzillogic]

Heh, wilde plannen. Maar wat wil je ermee doen?

Zelf wil ik eerst de basics eens werkend hebben alvorens ik meer spul ga bestellen. Het hele electronicagebeuren heeft me inmiddels al honderden euro's gekost aan tools, componenten, meetapparatuur.. en dan zijn het ook nog low-end spullen eigenlijk. Is niet erg hoor, hobby's kosten geld en ik vermaak me er prima mee. Maar het kopen van stuff is geen doel op zich natuurlijk.

Enfin, naast dit projectje heb ik nog wel andere redenen om een BT-module te bestellen, maar nu even niet. Bovendien, aangezien ik toch een webserver hier 24/7 heb draaien lijkt het mij logischer om de arduino daaraan te hangen, en dan kan ik de boel via een webpage beheren. Ik heb flatfee mobiel internet, dus dat kan dan ook prima vanaf telefoon. De range is dan 'iets' groter dan met bluetooth. Ideaal, alvast de kachel aanzetten als je weet dat je over half uurtje thuis bent

First things first, ik wil buffersysteem verbeteren, zodat er nog wat geheugen voor nuttigere zaken overblijft. Maar nu weer wat druk

[ Voor 7% gewijzigd door Fuzzillogic op 04-02-2008 23:01 ]

[Atmoz]

Fuzzillogic schreef op maandag 04 februari 2008 @ 23:00:
Heh, wilde plannen. Maar wat wil je ermee doen?

Alles Eigenlijk wat ik sinds klein af aan al wil: alles in en om het huis besturen wat er maar te besturen valt. De oven, frituurpan en verwarming kon ik al aanzetten via de GSM (DTMF). Maar dit gaat nog iets verder. Nu moet alles aan elkaar hangen via IR, RF(433 en RFID), BT, GSM, WiFi, internet, touchscreens, computer, etc etc etc. Gewoon alles wat je kunt bedenken moet kunnen. Ofja, moet... ...dat zou ik willen. Daar wil ik naartoe. Niet alles zal meteen lukken, maar uiteindelijk moet er eindelijk eens een systeem komen waarin de gekste dingen niet ontdenkbaar zijn!

Zelf wil ik eerst de basics eens werkend hebben alvorens ik meer spul ga bestellen. Het hele electronicagebeuren heeft me inmiddels al honderden euro's gekost aan tools, componenten, meetapparatuur.. en dan zijn het ook nog low-end spullen eigenlijk. Is niet erg hoor, hobby's kosten geld en ik vermaak me er prima mee. Maar het kopen van stuff is geen doel op zich natuurlijk.

Daar doe ik niet al te moeilijk over als ik eerlijk mag zijn. Sommige dingen moeten gewoon Een ArduinoBT van 100 euro terwijl er nog BT modules liggen vond ik bij nader inzien toch wat onzinnig, maar voor nieuwe, interessante onderdelen heb ik toch wel wat over.. Heb vanmiddag bijvoorbeeld voor meer dan 500 euro aan "hobby" electronica besteld. Puur om mee te kloten, me te vermaken en natuurlijk om dingen bij te leren. Niets is écht nodig. Maar altijd leuk om te hebben en ermee bezig te zijn toch?!

Enfin, naast dit projectje heb ik nog wel andere redenen om een BT-module te bestellen, maar nu even niet. Bovendien, aangezien ik toch een webserver hier 24/7 heb draaien lijkt het mij logischer om de arduino daaraan te hangen, en dan kan ik de boel via een webpage beheren. Ik heb flatfee mobiel internet, dus dat kan dan ook prima vanaf telefoon. De range is dan 'iets' groter dan met bluetooth. Ideaal, alvast de kachel aanzetten als je weet dat je over half uurtje thuis bent

Als je wilt kan ik je m'n 2e BT module toesturen. Kun je daar ook mee aan de gang. Als je dan ooit code ervoor maakt (voor Arduino) kan ik die ook weer gebruiken Laat maar weten als je die wilt, dan stuur ik 'm je op!

First things first, ik wil buffersysteem verbeteren, zodat er nog wat geheugen voor nuttigere zaken overblijft. Maar nu weer wat druk

Ik ken het. Maar voor leuke dingen maak ik wel tijd!! En dit zijn toch wel dingen die écht heel gaaf zijn. Succes met alles! Ik ga je KaKu code zeer binnenkort gebruiken. Als alles goed werkt kun je (of iemand anders...?ik?) er misschien een lib voor op Arduino.cc voor maken?! Lijkt me erg leuk om aan die (goede) site wat mee te helpen namelijk.

[Fuzzillogic]

De KaKu bewegingssensoren zijn vandaan binnengekomen. Als ik nu de badkamer oploop, en het is donker, dan floept het licht automatisch aan En weer uit, als ik wegloop )

Ik ben vandaag eindelijk ook eens verdergegaan met het decoderen. download Arduino code.

Hiermee krijg je (nog) niet te zien welk KaKu-apparaat aan- of uitgezet wordt, maar je krijgt een getal terug. En ik denk dat dat uiteindelijk misschien nog wel handiger is, als je het systeem toch gaat "leren" welke knop welke actie moet ondernemen. Het getal is uniek voor elke knop/instelling en loopt van 0 tot 531441. (==3^12. Q: "3? Waarom 3?" A: "De zenders van de remotes hebben 12 tri-state ingangen de ze encoderen. Vandaar 3".)

Tevens is er nu gebruik gemaakt van een cyclische queue als tijdelijke opslag van de ontvangen data. Op deze manier wordt er een stuk efficienter met het geheugen omgegaan

De timings van de KaKu-remotes en van die van de klonen wijkt behoorlijk af (factor 2 ongeveer), maar de code houdt daar rekening mee. Je kunt KaKu-remotes en die van (o.a. de Action) klonen door elkaar gebruiken!! De kans op 'collision', dus dat een KaKu-knop dezelfde getal geeft als een Action-knop, is erg klein. Eventueel onderscheid zou nog te maken zijn op basis van de cyclusduur.

Tenslotte: ik heb gemerkt dat de remotes bij het loslaten van een knop toch nog even een signaal doorsturen, maar dan met de code 'geen knop ingedrukt'. Laat je daardoor niet van de wijs brengen

[Jarimacfed]

Dit gaat echt de goede richting uit!

Ik heb met succes je vorige code toegepast op IR. De schakeling heb ik aan moeten passen aangezien het geen RSSI heeft.
De ingang en interrupt heb ik mbv een weerstand aan elkaar gekoppeld en de INTERESTING_LOW_SIGNAL aangepast.

De nieuwe code werkt ook zeer goed!

Kan het principe van deze decodering code ook gebruikt worden voor het decoderen van RC5/6 signalen of was dit de bedoeling?

Ik ga in ieder geval binnnenkort nog 2 Arduino's bijkopen maar dan met de Xbee shield.

Van dit weekeinde ga ik proberen om met mijn Asus router (OpenWrt) communicatie met te Arduino via de USB port te leggen. Deze kan ik dan als server gebruiken.

[Fuzzillogic]

RC5/RC6 is (iirc) Manchester-gecodeerd. Er zal dus een decoder moeten komen voor manchester-code. Lijkt mij niet bijzonder lastig meer eigenlijk. Je zult wel rekening moeten houden met het feit dat 1 edge (dus een laag of hoog signaal) onderdeel kan uitmaken van 2 bits.

Ik denk dat het handiger is om eerst de code in Processing ofzo te ontwerpen en te fine-tunen (De tooltje signaalweergave kunnen als basis dienen) en het later te porten naar C(++) voor de microcontroller.

Als je wat code hebt, laat het zien! Ik heb zelf dus een remote die RC5/RC6 over RF 433MHz kan sturen, en vooral: misschien dat de Cresta-weerstations ook Manchester gebruiken. Wellicht dat de eerste decodeerstap daar meer duidelijkheid in de data geeft.

[maddog_rvo]

Anoniem: 163226 schreef op zaterdag 05 januari 2008 @ 21:30:
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.

Ik ben daar wel in geinstresseerd, dus graag

[maddog_rvo]

Fuzzilogic, ik krijg je code in mijn geval niet werkend, ik heb een receiver die alleen maar 1 datapin uit heeft. Ik heb deze receiver al wel werkend met winlirc.

Ik probeer je processing tooltje aan de gang te krijgen echter heb ik geen flauw idee hoe dit moet (heb nog nooit gewerkt met c / c++) alleen C# en BASCOM AVR (moge het duidelijk zijn dat c# geen zin heeft met uC )

wat ik wel voor elkaar krijg is de normale seriele ontvangst van de code.

Onderstaande is hetgene wat ik van m`n KaKu remote ontvang :

code:

0 6 1 123 1 187 3 434 
1 3 0 3 621 
2 3 0 1 560 
0 11 1 2 123 1 123 2 229 1 18 1 687 
1 7 0 0 1 251 59 0 1000 
2 3 0 127 2872 
0 7 1 1 61 2 185 3 622 
1 3 0 1 747 
2 3 0 750 65534 
0 5 1 0 1 0 311 
1 3 0 313 2060 
2 3 0 0 437 
0 3 1 438 65221 
1 3 0 124 500 
2 3 0 625 65033 
0 7 1 1 186 0 61 3 811 
1 3 0 1063 64474 
2 7 0 748 0 1 58 3 311 
0 3 1 1122 64662 
1 7 0 249 187 2 248 2 310 
2 3 0 1 311 
0 5 1 0 185 3 310 
1 3 0 1 873 
2 5 0 1 122 2 310 
0 3 1 0 438 
1 3 0 438 65345 
2 3 0 2 309 
0 3 1 0 436

Komt iemand hier wijs uit / heeft iemand een idee om mijn ontvanger werkend te krijgen op de Arduino?

Ik weet overigens wel dat ik pin2 hoog moet trekken om ontvangst te activeren (tenminste dan wordt de serial link actief)

[ Voor 56% gewijzigd door maddog_rvo op 19-02-2008 12:24 ]

[Fuzzillogic]

Heh, die ontvangen code lijkt nergens op Waarschijnlijk heeft jouw ontvanger geen RSSI-out. Je kunt de digitale uitgang dan ook direct aan pin 2 hangen, en op regel 94 FALLING wijzigen in RISING (de schakeling met de tor maakt er juist een negatieve flank van)

KaKu-remote hebben altijd 50 edges. Dus in je code hierboven, als het tweede getal op elke regel geen 50 is, dan is het zeker geen KaKu.

Je kunt ook de code die eerder gepost is kunnen proberen. Anoniem: 164441 in "433MHz-communicatie met microcontrollers" Deze code werkt ook zonder RSSI, dus misschien dat dat je verder kan helpen.

Overigens ben ik van de pot gerukt, want ik ben een compilertje + 'mini VM' aan het schrijven voor het systeem. Het idee is om een taaltje te ontwikkelen waarmee je makkelijker het geheel kunt aansturen zoder dat je telkens voor elk wissewasje de boel opnieuw moet gaan flashen - dat kan uiteraard maar een beperkt aantal keer. Denk hierbij aan IF ontvangen KaKuSignaal = 'D 13 on' THEN zend ActionSignal(3,1,off); zend KaKuSignal(D,14,off);

De compiler draait op de PC (Java), de gegenereerde code wordt dan met-een-druk-op-de-knop geupload naar de µC, alwaar de code in de 'mini VM' wordt uitgevoerd. Tot zover het concept. Nu de uitvoering nog, waar ik eigenlijk geen tijd voor heb maar zo nu en dan toch mee bezig ben.

[maddog_rvo]

Fuzzillogic schreef op dinsdag 19 februari 2008 @ 13:17:
Heh, die ontvangen code lijkt nergens op Waarschijnlijk heeft jouw ontvanger geen RSSI-out. Je kunt de digitale uitgang dan ook direct aan pin 2 hangen, en op regel 94 FALLING wijzigen in RISING (de schakeling met de tor maakt er juist een negatieve flank van)

Hmm dat heb ik nu gedaan, maar nu ontvangt ie helemaal niets meer, het ledje op pin 13/GND aangesloten blijft continu branden (knippert ook niet)

Onderstaande is trouwens de winlirc config file, lijkt niet echt op een KaKu zeker, zie nl. dat ie maar 16bits is?

code:

#
# this config file was automatically generated
# using WinLIRC 0.6.5 (LIRC 0.6.1pre3) on Wed Feb 13 19:49:23 2008
#
# contributed by 
#
# brand:             KaKu
# model:             
# supported devices: 
#

begin remote

  name  KaKu
  bits           16
  flags SPACE_ENC
  eps            25
  aeps          100

  one           322   987
  zero          986   319
  ptrail        322
  pre_data_bits   8
  pre_data       0xFF
  gap          10262
  toggle_bit      0


      begin codes
          A-aan                    0x000000000000FAAE
          A-uit                    0x000000000000FAAB
          B-aan                    0x000000000000EEAE
          B-uit                    0x000000000000EEAB
          C-aan                    0x000000000000EBAE
          C-uit                    0x000000000000EBAB
          D-aan                    0x000000000000EAEE
          D-uit                    0x000000000000EAEB
          E-aan                    0x000000000000EABE
          E-uit                    0x000000000000EABB
      end codes

end remote

[Fuzzillogic]

Dat ledje aanblijft verbaast me niet zo heel veel. Of eigenlijk: je zit niet dat-ie uitgaat, want er wordt nu ook op de ruis getriggerd. En ruis is er genoeg Waarom het niet werkt weet ik zo 123 ook niet.. Heb zelf ook zo'n ding met alleen digital-out, geript uit een thermometer-unit. Zal tzt eens testen.

De representatie die WinLirc uit het ontvangen signaal afleidt klopt niet echt, maar kan wel werken. Dat het '16 bit' is hoeft nog niet perse iets te zeggen over het aantal edges; dat hangt van de condering af. In werkelijkheid zijn het 12 'bits' die elk 3 waardes kunnen aannemen: 0, 1 of 'floating'. Elke bit wordt gecodeerd mbv 4 edges. Ter afsluiting volgen nog 2 edges, totaal dus 50.

[maddog_rvo]

Fuzzillogic schreef op dinsdag 19 februari 2008 @ 15:03:
Dat ledje aanblijft verbaast me niet zo heel veel. Of eigenlijk: je zit niet dat-ie uitgaat, want er wordt nu ook op de ruis getriggerd. En ruis is er genoeg Waarom het niet werkt weet ik zo 123 ook niet.. Heb zelf ook zo'n ding met alleen digital-out, geript uit een thermometer-unit. Zal tzt eens testen.

De representatie die WinLirc uit het ontvangen signaal afleidt klopt niet echt, maar kan wel werken. Dat het '16 bit' is hoeft nog niet perse iets te zeggen over het aantal edges; dat hangt van de condering af. In werkelijkheid zijn het 12 'bits' die elk 3 waardes kunnen aannemen: 0, 1 of 'floating'. Elke bit wordt gecodeerd mbv 4 edges. Ter afsluiting volgen nog 2 edges, totaal dus 50.

Ik ben je compleet kwijt (nooit geweten dat een bit floating kan zijn??)
Ben mbv jouw tip mbt tot de code van P.K. Tonkes toch wat verder gekomen, het signaal blijkt 25 bits volgens zijn code te zijn, vervolgens klopt dit ook nog want als ik de knop inhoud dan blijven exact dezelfde codes terugkomen. In Winlirc staat trouwens ook dat 0xFF van te voren gezonden wordt. Vervolgens concludeer ik : 8bits + 16bits data + 1bit (einde?) = 25bits. Overigens komt er dit uit zijn code :
502,502,502,502,502,502,502,502,502,502,503,1471,500,1468,500,1466,497,1465,497,498,498,1465,496,497, 497

dus zou rond de 500us een 1 zijn en rond de 1500us een 0 (komt daarna ook precies overeen met wat winlirc laat zien)

Echter wat doet onderstaande regel :
KAKU_Code=(KAKU_Code<<1)|(Counter_HIGH>KAKU_bit_Data);

en dit stukje:
//edit => ben erachter wat KAKU_Code&0x15555FD doet nu de rest nog

if((KAKU_Code&0x15555FD)==0x28) // Kijk of de checksum klopt.
{// filter home, kanaal en commando er uit.
KAKU_Home =((KAKU_Code&0x20000)>>14 | (KAKU_Code&0x80000)>>17 |(KAKU_Code&0x200000)>>20 |(KAKU_Code&0x800000)>>23)+1;
KAKU_Channel=((KAKU_Code&0x200)>>6 | (KAKU_Code&0x800)>>9 |(KAKU_Code&0x2000)>>12 |(KAKU_Code&0x8000)>>15)+1;
KAKU_Command=(KAKU_Code&2)>>1;
}

Want uiteindelijk worden al die bits tot een Long omgezet (KAKU_Code is een unsigned long) en vervolgens wordt er een checksum over gedaan -> ik heb geen flauw idee wat ik hiermee aan moet

[Anoniem: 163226]

@ maddog_rvo: Hier de mikrobasic code:

Zender:

Visual Basic:

program DMX_RF
'Processor 16F628A,  20MHz kristal
'Schema afgeleid van http://www.decolicht.nl/Downloads.html
'
'DMX ontvangst afgeleid van MikroC code van M14 van het gathering.tweakers.net/forum
'RF zend en ontvangst protocol is een eigen ontwikkeling
'
' Protocol:
' Sync($AA),($AA),($AA),($AA),($AA), Start($AB),address, val0, val1, val2, EndSign ($AE)
' Example:
' 170, 170, 170, 170, 170, 171, 128, 20, 50, 80, 174
'
'       Value     :   0 - 127
'       Address   : 128 - 160
'       All devices: 164     Group0
'       All devices: 165     Group1
'       All devices: 166     Group2
'       All devices: 167     Group3
'       Sync      : 170  ($AA)
'       Startbyte : 171  ($AB)
'       endbyte   : 175  ($AE)
'       Command   : 201 - 223
'       Store     : 251  (not yet implemented)
'                        startbyte, storecode, newaddress, endbyte
'                           171   ,     251  , 128 - 160 ,   175
'                        returns the new address on the serial line
'
' Mardaso   November 2007
'
'******************************************************************************


Const aantalkanalen as byte=3
Dim ch_count, offset, i, j, adres as Integer
Dim data as byte[aantalkanalen]
Dim startcode, nutteloos, brk as byte
Dim counter as word
dim fade, fade2, fade3, flag  as byte

Sub procedure init_usart
    SPBRG = 0x04
    TXSTA.BRGH = 1

    TXSTA.SYNC = 0
    PIE1=0
    PIE1.RCIE = 1
    RCSTA.RX9 = 1

    nutteloos=RCREG
    nutteloos=RCREG
    nutteloos=RCREG

    RCSTA.CREN = 1
    RCSTA.SPEN = 1
    INTCON.PEIE=1
    INTCON.GIE=1
End sub

Sub procedure Stop_usart
    INTCON = 0
    PIE1=0
    PIE1.RCIE = 0
    RCSTA.CREN = 0
    RCSTA.SPEN = 0
    nutteloos=RCREG
    nutteloos=RCREG
    nutteloos=RCREG
End sub

sub procedure SendDelay
     Delay_ms(1)
end sub

Sub procedure syncCom
'sync bytes first
   Soft_Uart_Write($AA)
   Soft_Uart_Write($AA)
   Soft_Uart_Write($AA)
   Soft_Uart_Write($AA)
   Soft_Uart_Write($AA)
   'Start byte
   Soft_Uart_Write($AB)
end sub

sub procedure Send_Data(dim adresRF as byte)
       'Address byte
       Soft_Uart_Write(adresRF)
       'Data bytes
       Soft_Uart_Write(fade)
       Soft_Uart_Write(fade2)
       Soft_Uart_Write(fade3)
       'End command
       Soft_Uart_Write($AE)
end sub

Sub procedure interrupt
  'Uart interrupt routine
  if PIR1.RCIF=1  then
    portb.3=1
    if (RCSTA.OERR) then
       RCSTA.SPEN=0
       RCSTA.SPEN=1
       nutteloos=RCREG
       nutteloos=RCREG
       nutteloos=RCREG
       ch_count=0
       brk=0
    else
       if (RCSTA.FERR) then
          nutteloos=RCREG
          ch_count=0
          offset=0
          brk=0xFF
       else
          if (brk = 0xFF) then
             if (ch_count=0) then
                startcode=RCREG
             else
                 if (adres<1)  then
                    nutteloos = RCREG
                    for j=0  to aantalkanalen-1
                        data[j]=0
                    next j
                  else
                     ' ------------------------------ Hier adres controleren en evt. uitlezen
                     if (ch_count >= adres) and (ch_count < (adres + aantalkanalen)) and (startcode = 0) then
                        data[offset] = RCREG
                        offset= offset + 1
                        if offset = aantalkanalen then
                           flag = 1
                           portb.3 = 0
                        end if
                     else
                        nutteloos = RCREG
                     end if
                    ' ------------------------------
                 end if
             end if
             ch_count = ch_count + 1
          else
              nutteloos = RCREG
              ch_count = 0
          end if
       end if
      end if
    PIR1.RCIF=0
    end if
end sub


main:
  TRISA = 0xF0              ' PORTA is output
  PORTA = 0x00              ' Initialize PORTA
  TRISB = 0x02              ' PORTB is output
  PORTB = 0x00              ' Initialize PORTB
  CMCON = 0x07              ' comperators off

  PORTB.0 = 0               ' Set SN75176 to recieve data
  PORTB.3 = 1
  ch_count=0
  brk=0

  for j=0 to aantalkanalen-1
     data[j] = 0
  next j

   init_usart

   counter = 0            ' Initialize counter
   Delay_ms(500)                    '
   'Software uart voor het aansturen van de rf module
   Soft_Uart_Init(PORTB, 5, 4, 2400, 0)
   Delay_ms(100)
   'Beginwaarden om wat reactie te zien zonder dmx signaal bij de ontvanger
   fade = 0
   fade3 = 40
   flag = 0


while TRUE
   adres = 1
   if flag = 1 then
       'Laten zien dat er wat verzonden wordt
       portb.3 = 0
       'Stop de dmx ontvangst zodat dit de software uart niet stoort
       stop_usart
       'Deel de ontvangen dmx waarden door 2 (ontvanger protocol werkt met waarden van 0-127)
       Fade = data[0]/2
       Fade2 = data[1]/2
       fade3 = data[2]/2
'      'sync bytes first
       SyncCom
       'daarna data zenden naar adres
       'adres 164 is in dit geval groep0 waar alle ontvangers van groep 0
       'naar luisteren en hun waarde hierop aanpassen
       Send_Data(164)
       'en naar andere ontvangers
       'Second device
'       Fade = data[3]/2
'       Fade2 = data[4]/2
'       fade3 = data[5]/2
       'SyncCom
       'Send_Data($81)
       flag = 0
       init_usart
  end if
wend

[Anoniem: 163226]

en ontvanger:

Visual Basic:

program PWM_SER

' microcontroller  P16F628A
'
' Project PWM_SER
' This project is designed to work with PIC 16F628A on EasyPic2
' with minor adjustments, it should work with any other PIC MCU.
'
' This code demonstrates using interrupts in mikroBasic.
' Program turns on/off leds on PORTB on serial/RF send commands and values.
' Protocol:
' Sync($AA),($AA),($AA),($AA),($AA), Start($AB),address, val0, val1, val2, val3, EndSign ($AE)
' Example:
' 170, 170, 170, 170, 170, 171, 128, 20, 50, 80, 174 
' you can send 1 to 3 values, when sending
' Designed for RGB LEDs but you could dim all sorts of leds
' No Warranty!
'
'       Value     :   0 - 127
'       Address   : 128 - 160
'       All devices: 164     Group0
'       All devices: 165     Group1
'       All devices: 166     Group2
'       All devices: 167     Group3
'       Sync      : 170  ($AA)
'       Startbyte : 171  ($AB)
'       endbyte   : 175  ($AE)
'       Command   : 201 - 223
'       Store     : 251  (not yet implemented)
'                        startbyte, storecode, newaddress, endbyte
'                           171   ,     251  , 128 - 160 ,   175
'                        returns the new address on the serial line
'
' Mardaso   November 2007
'
'******************************************************************************


dim counter , errCount as word
dim i , led0 , led1, led2, tel1, Timeout, fadeT as byte
dim  buf0, buf1, buf2, Dev_adr, flag, flag2 as byte
dim telr, telg, telb, fflag as byte


sub procedure interrupt
    inc(counter)          ' Increment value of counter on every interrupt
    inc(errCount)
    If errCount > 5000 then
       errcount = 0
       inc(Timeout)
       inc(fadeT)
       if (Timeout > 8) and (fflag = 0) then  'about 6 seconds no signal goto auto Fade mode
          errCount = 0
          Timeout = 0
 '         led0 = 0
          led1 = 0
          led2 = 0
          buf0 = 0
          buf1 = 0
          buf2 = 0
          telr = 2
            telg = 0
            telb = 0
          fflag = 1                             ' Auto Fade mode active
       end if
    end if
    If counter <= led0 then
       portb.5 = 1
    else
       portb.5 = 0
    end if
    If counter <= led1 then
       portb.4 = 1
    else
       portb.4 = 0
    end if
    If counter <= led2 then
       portb.6 = 1
    else
       portb.6 = 0
    end if
    if counter = 127 then ' if counter is 127, then reset counter
      counter = 0
    end if
   TMR0   = 150          ' load value TMR0
   INTCON = $20          ' Set T0IE, clear T0IF
end sub


sub procedure ClearBuf     'Clear the buffer
          buf0 = 0
          buf1 = 0
          buf2 = 0
end sub

sub procedure Cmd_effect(dim bf0, bf1, bf2 as byte)
          buf0 = bf0
          buf1 = bf1
          buf2 = bf2
          flag = 1
end sub


sub procedure Fade(Dim speed as byte)
    If fadeT > Speed Then
        fadeT = 0
        If telr = 1 Then
            Led0 = Led0 - 1
        End if
        If telr = 2 Then
            Led0 = Led0 + 1
        End if
        If telg = 1 Then
            Led1 = Led1 - 1
        End if
        If telg = 2 Then
            Led1 = Led1 + 1
        End if
        If telb = 1 Then
            Led2 = Led2 - 1
        End if
        If telb = 2 Then
            Led2 = Led2 + 1
        End if
        If Led0 = 127 Then
            telr = 1
            telg = 2
            telb = 0
        End if
        If Led1 = 127 Then
            telr = 0
            telg = 1
            telb = 2
        End if
        If Led2 = 127 Then
            telr = 2
            telg = 0
            telb = 1
        End if
    End if
end sub

main:

  OPTION_REG = $80       ' Assign prescaler to TMR0
  TRISA = $F0             ' PORTA is output
  PORTA = $00            ' Initialize PORTA
  TRISB = $02             ' PORTB is output
  PORTB = $00            ' Initialize PORTB
  CMCON = $07             'comperators off

'  OPTION_REG = $80       ' Assign prescaler to TMR0
'  TRISA = $F0             ' PORTA is output
'  PORTA = $00            ' Initialize PORTA
'  TRISB = $00             ' PORTB is output
'  PORTB = $00            ' Initialize PORTB  'TRISC = $80
  'PORTC = $00
  
  led0 = 0                  ' Put values from buffer to PWM outputs
  led1 = 0
  led2 = 0
  tel1 = 0
  Dev_adr = 128          ' Change this if you need another address 128-158 (199?)
  flag = 0
  flag2 = 0
  errCount = 0
  Timeout = 0
  fadeT=0
  telr = 2
    telg = 0
    telb = 0
    fflag = 0

   Delay_ms(500)                    '
   Usart_init(2400)                ' Initialize USART module (8 bit, 1200 baud rate, no parity bit...
   Delay_ms(500)
'  Lcd_Init(PORTD)                      ' Lcd_Init_EP4, see autocomplete
'  Lcd_Cmd(LCD_CLEAR)
   
   'portb.0 = 1

  counter = 0            ' Initialize counter
  TMR0 = 150             ' load value TMR0
  INTCON = $A0           ' Enable TMRO interrupt

   
  while TRUE
     if Usart_Data_Ready <> 0 then ' If data is received:
       i = Usart_Read              ' Read the received data
'       Usart_Write (i)            ' For debug only
        if flag2 = 1 then          ' if startbyte recieved flag is set proces data
           goto datapart
        end if
        if (i = $AB) and (flag2 = 0) then    ' Check for startbyte
'            Lcd_Cmd(LCD_CLEAR)
'            Lcd_Cmd(LCD_FIRST_ROW)
            flag2 = 1
        else
            goto uit01
        end if
        
Datapart:
       inc(tel1)                   ' Increase incoming byte counter
       If tel1 > 3 then
          tel1 = 0
       end if
       'Lcd_Chr_CP(i)
       if (i = Dev_adr) or (i = 164) then         ' Is this device called?
'       if i = Dev_adr then         ' Is this device called?
          tel1 = 0
          flag = 1
          ClearBuf
       end if

       if (i < 128) and (flag = 1) then goto Value end if 'Device active and a value?
       if (i = $AE) and (flag = 1) then  ' Device active and EndSign recieved?
          led0 = buf0                    ' Put values from buffer to PWM outputs
          led1 = buf1
          led2 = buf2
          tel1=0                         ' reset incoming byte counter
          flag = 0                       ' done for this time
          flag2 = 0
          errCount = 0
          Timeout = 0
          fflag = 0
       end if
       
       if (i >200) and (i<228) then        ' Command recieved?
         select case i                     ' check for commands
                case 201                   ' command all devices 0 value change
                     tel1 = 0
                     Cmd_effect (0,0,0)
                case 202                   ' command all devices 1 value change
                     tel1 = 1
                     Cmd_effect (0,0,0)
                case 203                   ' command all devices 2 value change
                     tel1 = 2
                     Cmd_effect (0,0,0)
                case 204                   ' command all devices 3 value change
                     tel1 = 3
                     Cmd_effect (0,0,0)
                case 205                   ' command all devices 4 value change
                     tel1 = 4
                     Cmd_effect (0,0,0)
                case 206                   ' command all devices 5 value change
                     tel1 = 5
                     Cmd_effect (0,0,0)
                case 207                   ' command all devices 6 value change
                     tel1 = 6
                     Cmd_effect (0,0,0)
                case 208                   ' command all devices 7 value change
                     tel1 = 7
                     Cmd_effect (0,0,0)
                case 209                   ' command all devices value change
                     tel1 = 0
                     Cmd_effect (0,0,0)
                case 210                   '  command clear outputs of all devices
                     Cmd_effect (0,0,0)
                case 211                   '  command outputs all devices at 10%
                     Cmd_effect (10,10,10)
                case 212                   '  command outputs all devices at 20%
                     Cmd_effect (20,20,20)
                case 213                   '  command outputs all devices at 30%
                     Cmd_effect (30,30,30)
                case 214                    '  command outputs all devices at 40%
                     Cmd_effect (40,40,40)
                case 215                    '  command outputs all devices at 50%
                     Cmd_effect (50,50,50)
                case 216                     '  command outputs all devices at 60%
                     Cmd_effect (60,60,60)
                case 217                     '  command outputs all devices at 70%
                     Cmd_effect (70,70,70)
                case 218                     '  command outputs all devices at 80%
                     Cmd_effect (80,80,80)
                case 219                     '  command outputs all devices at 90%
                     Cmd_effect (90,90,90)
                case 220                     '  command outputs all devices at 100%
                     Cmd_effect (100,100,100)
                case 221                   '  command all devices RED (portb.0)
                     Cmd_effect (100,0,0)
                case 222                   '  command all devices GREEN (portb.1)
                     Cmd_effect (0,100,0)
                case 223                   '  command all devices BLUE (portb.2)
                     Cmd_effect (0,0,100)
         end select
      end if
       
      goto uit01

Value:
       if tel1 = 1 then         ' set 0 Value
          buf0 = i
       end if
       if tel1 = 2 then         ' set 1 Value
          buf1 = i
       end if
       if tel1 = 3 then         ' set 2 Value
          buf2 = i
       end if

uit01:
     end if
     if fflag = 1 then
        Fade(1)
     end if
  wend
  
end.

Als de ontvanger een bepaalde tijd niets ontvangen heeft gaat deze faden tussen de kleuren zodat deze ook stand-alone te gebruiken is. En er zitten wat truckjes in om alle ontvangers (of groep) gelijkertijd om te schakelen.

Code is te compileren met de demo-versie van MikroBasic v6.0.

Al met al nog een beste lap met code als het te veel is haal ik het weg.

Mocht iets niet duidelijk zijn dan lees ik het wel.

[Fuzzillogic]

maddog_rvo schreef op dinsdag 19 februari 2008 @ 15:45:
[...]


Ik ben je compleet kwijt (nooit geweten dat een bit floating kan zijn??)
Ben mbv jouw tip mbt tot de code van P.K. Tonkes toch wat verder gekomen, het signaal blijkt 25 bits volgens zijn code te zijn, vervolgens klopt dit ook nog want als ik de knop inhoud dan blijven exact dezelfde codes terugkomen. In Winlirc staat trouwens ook dat 0xFF van te voren gezonden wordt. Vervolgens concludeer ik : 8bits + 16bits data + 1bit (einde?) = 25bits. Overigens komt er dit uit zijn code :
502,502,502,502,502,502,502,502,502,502,503,1471,500,1468,500,1466,497,1465,497,498,498,1465,496,497, 497

Ik zei ook 'bits', niet bits . En wat WinLirc en P.K. Tonkes denken is helaas onjuist. Werkt wel, maar onjuist.

Kijk eens in de code van de Remote Switch library. Die is gebaseerd op de datasheet van de IC's. Verklaart meteen de floating-waarde van de 'bits'

[maddog_rvo]

Anoniem: 163226 schreef op dinsdag 19 februari 2008 @ 16:13:
@ maddog_rvo: Hier de mikrobasic code:

Hele lap code

Thanks dat is wat leesbaarder voor mij, ben nu nog steeds bezig dat andere programmatje te ontcijferen en loop nu vast bij :

KAKU_Code=(KAKU_Code<<1)|(Counter_HIGH>KAKU_bit_Data);

Ik denk dat deze regel de bits opschuift en een 1 toevoegd indien counter_high groter is als KAKU_bit_data, maar zeker weten doe ik het niet, probleem is nl. dat ik de getallen die er uiteindelijk uitkomen niet kan ontcijferen

[maddog_rvo]

Whoohoo tis gelukt

Ik heb zojuist een chat programmatje gemaakt op basis van Winlirc en de P.K. Tonkes Arduino code

Jaja ik weet dat het inefficient is maar wel grappig

Moet toch ff flink wat dieper in C code duiken en leren hoe ik het zelf kan schrijven want het is uiteindelijk een stuk makkelijker dan BASCOM AVR (Dit omdat bijna iedereen zijn uC in C schrijft en zodoende zijn er volop voorbeelden)

Straks nog een zendertje en touchscreen erbij en dan ben ik al een heel eind

[ Voor 9% gewijzigd door maddog_rvo op 19-02-2008 22:21 ]

[maddog_rvo]

Ben nu weer een stapje verder, heb er een analoge temp meter + analoge licht intensiteits meter opgezet, temp meter voor in de toekomst de verwarming aan en uit te kunnen zetten, lichtmeter voor het aan en uitzetten van de lampen.

Komt de lichtintensiteit nu onder de 12% gaan de lampen aan en boven de 15% gaan de lampen weer uit

[Fuzzillogic]

Helaas ben ik nog niet heel veel verder. Ik heb net een zender uit de nieuwe serie gehaald, om te zien in hoeverre dat compatible is/lijkt op het 'oude' systeem.

Scope-plaatje
(boven digital out van de 433MHz TX, onder de RSSI)

Totaal anders dus dan het oude systeem. Maar toch erg helder, zou je denken. 1, 2 of 3 piekjes gevolgd door een pauze. Er lijkt een 'headerpiekje' te zijn met een iets langere pauze, gevolgd door 33 blokjes van 1, 2 of 3 piekjes.

Het nadeel is dat het veel edges zijn, wat dus veel data kost om te bufferen. En de handleiding heeft het over "67 miljoen combinaties", dat lijkt verdraaid veel op 2^26, maar dat kan ik weer niet rijmen met deze 'bits' die 3 verschillende waardes kunnen aannemen (dus base 3, ipv base 2 bij normaal binair systeem)

Vragen: hoe past "67 miljoen combinaties" in dit plaatje? Is er een checksum? Toch wel dingen die handig zijn om te weten. Maar niet perse noodzakelijk, want we hoeven alleen maar een signaal te herkennen, niet te 'begrijpen'.

Uiteraard is de garantie reeds vervallen, want ik heb het ding openschroefd op zoek naar meer info In de schakelaar bevindt zich een chip met opdruk "MDT10P55". Dat blijkt een microcontroller te zijn, mogelijk een kloon van de PIC16C505. Fancy, maar daarmee kom ik weinig verder

Kan iemand wat zinnigs vertellen over het gebruikte schema? Of dan toch maar de stoute schoenen aantrekken en simpelweg de specs vragen aan Pan Trade? Inmiddels heb ik Pan Trade gemaild met het verzoek voor info/specificaties. Hopelijk zien ze het niet als 'bedrijfsgeheim' ofzo Ik ben benieuwd iig!

[ Voor 4% gewijzigd door Fuzzillogic op 22-02-2008 14:11 ]

[Fuzzillogic]

Hmm helaas:

Geachte heer,

Ook wij zijn niet in het bezit van meer informatie, dit is in handen van
de fabriek en wordt niet vrijgegeven.

met vriendelijke groet,

PAN-TRADE INTERNATIONAL BV

Nouja, niet zo'n hele ramp, aangezien de nieuw ontvangers ook het oude zend-systeem ondersteunen. En zoals gezegd is het herkennen van het signaal van de nieuw zenders goed genoeg, het signaal 'begrijpen' voegt niet heel veel toe. Maar reverse engineren is altijd nog een optie

Maar nu weer verder met de compiler. Ja het duurt lang, en hoewel er tools zijn om het allemaal een stuk makkelijker te maken (ANTLR, bijv.) vind ik het ook wel leuk om alles from scratch zelf te doen

[mauws79]

He geweldig topic, recent wat spullen besteld om zelf aan de slag te gaan. Ik vroeg mij alleen
af welke techniek je gebruikt om resultaten terug te koppelen. Ik denk zelf aan U(S)ART op
9600 baud, maar je kan ook de debugwire gebruiken. En die handel gebruik je ook gewoon
vanuit arduino? Ik heb mij nog niet zo heel erg in arduino verdiept maar 't lijkt meer te zijn dan
een one-day-fly..?

[Fuzzillogic]

Arduino heeft een RS232 to USB-interface op het bordje. Op de PC installeer je dan een driver voor het gebruikte FTDI-chipje, waarmee je dan een virtual COM-port op de PC krijgt. Feitelijk communiceer je dan direct via good old RS232 tussen PC en microcontroller. Veel simpeler dan dat wordt het niet

De driver is bijgeleverd bij de software, maar Windows Update kent hem ook, dus eigenlijk is het plug&play. Voor Linux en MacOSX zijn er ook drivers.

Lees de 'Getting started' en 'Tutorials' maar op arduino.cc.

[Jarimacfed]

Fuzzillogic schreef op zaterdag 09 februari 2008 @ 14:33:
RC5/RC6 is (iirc) Manchester-gecodeerd. Er zal dus een decoder moeten komen voor manchester-code. Lijkt mij niet bijzonder lastig meer eigenlijk. Je zult wel rekening moeten houden met het feit dat 1 edge (dus een laag of hoog signaal) onderdeel kan uitmaken van 2 bits.

Ik denk dat het handiger is om eerst de code in Processing ofzo te ontwerpen en te fine-tunen (De tooltje signaalweergave kunnen als basis dienen) en het later te porten naar C(++) voor de microcontroller.

Als je wat code hebt, laat het zien! Ik heb zelf dus een remote die RC5/RC6 over RF 433MHz kan sturen, en vooral: misschien dat de Cresta-weerstations ook Manchester gebruiken. Wellicht dat de eerste decodeerstap daar meer duidelijkheid in de data geeft.

Ik ben een tijd bezig geweest om wat uit te werken maar er zelf niet in geslaagd
Na onderzoek op het internet ben ik dit ook tegengekomen. Het is wel voor IR maar wel voor RC5 code. De hardware interface is niets bijzonders. In ieder geval een basis om verder te onderzoeken Geprobeerd om het samen te werken met de Kaku bibliotheek maar dit wilde niet lukken. Ik heb een stop timer functie er aan toegevoegd en nu werkt het met de KaKu bibliotheek.

code

code:

#include <RemoteSwitch.h>

// RC5 remote control receiver decoder.
// Tested with Philips or Philips compatible TV remotes.
// Developed by Alessandro Lambardi, 25/12/2007
// Released under Creative Commons license 2.5.
// Non-commercial use, attribution, share alike.
//
// Completely interrupt driven, no 'wait until' loops.
// When a valid code is received it is made available at
// variable data_word (main loop).
// External Arduino clock 16Mhz, hardware prescaler = 1
// Designed for AVR ATtiny24, adapted for Arduino.
//
// Program memory resources used (ATtiny24):
// 670 Program bytes circa out of 2048 (1/3 circa)
// 4 data bytes out of 128
//
// Internal hardware resources used:
// 8Bit Timer 0:    reset by software as required
// PORTA B, bit 0   can be relocated together with pin
//          change interrupt assignments

// added stop_timer function to solve problem with the KakuSwitch library

KaKuSwitch kaKuSwitch(3);

#define F_CPU 16000000UL    // CPU clock in Hertz.
#define TMR0_PRESCALER 256UL
#define IR_BIT 1778UL   // bit duration (us) in use for IR remote (RC5 std)
#define IR_IN  8    //IR receiver is on digital pin 8 (PORT B, bit0)

#define TMR0_T (F_CPU/TMR0_PRESCALER*IR_BIT/1000000UL)
#define TMR0_Tmin (TMR0_T - TMR0_T/4UL) // -25%
#define TMR0_Tmax (TMR0_T + TMR0_T/4UL) // +25%
#if TMR0_Tmax > 255
#error "TMR0_Tmax too big, change TMR0 prescaler value ", (TMR0_Tmax)
#endif

// Variables that are set inside interrupt routines and watched outside
// must be volatile
volatile uint8_t    tmr0_OC1A_int;  // flag, signals TMR0 timeout (bad !)
volatile uint8_t    no_bits;        // RC5 bits counter (0..14)
volatile uint16_t   ir_data_word;   // if <> holds a valid RC5 bits string (good !)

void start_timer0(uint8_t cnt) {
  OCR0A = cnt;
  TCNT0 = 0;
  tmr0_OC1A_int = 0;
  TIMSK0 |= _BV(OCIE0A);    // enable interrupt on OC0A match
  TCCR0B |= _BV(CS02);  // start timer0 with prescaler = 256
}

// Interrupt service routines
ISR(PCINT0_vect) {          //  signal handler for pin change interrupt
  if(no_bits == 0) {        // hunt for first start bit (must be == 1)
    if(!digitalRead(IR_IN)){
      start_timer0(TMR0_Tmax);
      no_bits++;
      ir_data_word = 1;
    }
  } 
  else {
    if(!tmr0_OC1A_int) {        // not too much time,
      if(TCNT0 > TMR0_Tmin) {   // not too little.
        // if so wait next (mid bit) interrupt edge
        start_timer0(TMR0_Tmax);
        no_bits++;
        ir_data_word <<= 1;
        if(!digitalRead(IR_IN)){
          ir_data_word |= 1;
        } 
        else {
          ir_data_word &= ~1;
        }
      }
    }
  }
}

ISR(TIM0_COMPA_vect) {      // timer0 OC1A match interrupt handler
  TCCR0B &= ~(_BV(CS02) | _BV(CS01) | _BV(CS00));   // stop timer
  tmr0_OC1A_int = 1;    // signal timeout
  no_bits = 0;      // start over with hunt for valid stream
  ir_data_word = 0;
}

void stop_timer0() {
  TCCR0B  &= ~(_BV(CS02) | _BV(CS01) | _BV(CS00));
}

void setup() {
  Serial.begin(115200); // opens serial port, sets data rate to 115200 bps
  // IR remote control receiver is on IR_IN digital port
  pinMode(IR_IN, INPUT);

  pinMode(4, OUTPUT);  // test output : LED for remote key "1"

  // pin change interrupt enable on IR_IN port
  PCMSK0 |= _BV(PCINT0);
  PCICR |= _BV(PCIE0);

  // Timer 0 : Fast PWM mode. Stopped, for now.
  TCCR0A = _BV(WGM00) | _BV(WGM01);
  TCCR0B = _BV(WGM02);
  no_bits = 0;
  sei();            // enable interrupts
}

void loop() {    
  uint8_t data_word;    // 0..63 holds a valid RC5 key code.

  for(;;) {
    if((no_bits == 14) && ((ir_data_word & 0x37C0) == 0x3440)){  // Tuner  function 
// if((no_bits == 14) && ((ir_data_word & 0x37C0) == 0x3xxx)){  // remote control type
      no_bits = 0;
       stop_timer0(); //added
      // prepare for next capture
      data_word = ir_data_word & 0x3F;  // extract data word

      switch(data_word) {
      case 0x01:                // button 1 on most RC5 remotes
        // do something
         kaKuSwitch.sendSignal('A',2,true);  
        digitalWrite(4,1);
        break;
      case 0x04:                // button 4 on most RC5 remotes
        // do something
        kaKuSwitch.sendSignal('A',2,false); 
        digitalWrite(4,0);
        // etcetera for other codes,  some are in the table below
      }
    }
  }
}

[Fuzzillogic]

Fuzzillogic schreef op dinsdag 26 februari 2008 @ 19:53:
Maar nu weer verder met de compiler. Ja het duurt lang, en hoewel er tools zijn om het allemaal een stuk makkelijker te maken (ANTLR, bijv.) vind ik het ook wel leuk om alles from scratch zelf te doen

HA! En jullie maar denken: "die zien we nooit meer terug".

Maar dan, om 2:21 kwam de Virtual Machine dan toch tot leven op de Arduino!

Het programma:
loop setvar(0,getvar(0)+1)

De gegenereerde assembly:
0: PUSHINT6 1
1: GETVAR 0
2: ADD
3: SETVAR 0
4: PUSHINT6 -6
5: LOOP

De instructies:
129, 96, 0, 64, 186, 235

uitvoer:
PC: 0. Stack:
PC: 1. Stack: 1,
PC: 2. Stack: 1, 0,
PC: 3. Stack: 1,
PC: 4. Stack:
PC: 5. Stack: -6,
PC: 0. Stack:
PC: 1. Stack: 1,
PC: 2. Stack: 1, 1,
PC: 3. Stack: 2,
PC: 4. Stack:
PC: 5. Stack: -6,
PC: 0. Stack:
PC: 1. Stack: 1,
PC: 2. Stack: 1, 2,
PC: 3. Stack: 3,
PC: 4. Stack:
PC: 5. Stack: -6,
PC: 0. Stack:
PC: 1. Stack: 1,
PC: 2. Stack: 1, 3,
PC: 3. Stack: 4,
PC: 4. Stack:
PC: 5. Stack: -6,
PC: 0. Stack:

Het oplettende oog ziet dat bij instructie 3 er telkens een hoger nummertje op de stack verschijnt, dus het werkt!

Nu denk je "nou, geweldig. Een variabele ophogen", maar het ontwerp van het taaltje, de bytecode, de bijbehorende compiler en de virtual machine op de Arduino zijn nu in een zeer vergevorderd stadium. De virtual machine is een simpel stack-based dingetje, maar de bytecode heb ik zo compact mogelijk gehouden. De Atmega168 van de Arduino heeft slechts 512 byte EEPROM, zeg maar de harde schijf van het ding, en uiteindelijk moet het programmaatje dus daarin komen, vandaar de noodzaak voor een uiterst compacte bytecode.

Nu denk je "nou, geweldig. Maarehh?? Dus?? :?". Wat het dus bijna kan/gaat kunnen: vanaf je PC een simpel programmaatje schrijven in een simpel taaltje, waarmee je makkelijk KaKu-apparaten kunt zenden en ontvangen. Tevens kun je gebruik maken van de ingangen van de arduino, zodat je bijv ook het licht aan kunt laten gaan als het donker wordt, of dat je de arduino voorziet van een simpel hardwareschakelaartje. Ook timers zijn reeds mogelijk, dus bijv, je drukt op de knop om het licht buiten aan te laten gaan, en een minuut later gaat-ie vanzelf weer uit.

Nu denk je "nou, geweldig. Maarehh?? Dus?? Dat kan ik zelf ook wel in C!". Jah. Klopt. Maar dit is makkelijker en leuker Je hoeft de arduino niet meer te flashen, maar het programmaatje wordt opgeslagen in de EEPROM, welke 10x zoveel write-cycles (100.000) aankan als het flashgeheugen. En omdat het een simpele VM is zou het in princiepe ook goed te porten zijn naar andere microcontrollers en goh, waarom niet, naar de PC.

Alles komt als open source beschikbaar, maar er moet eerst commentaar bij de code, en ehm.. er moet nog een GUI bij En nu ga ik pitten want er moeten nog batavierenracewisselpuntpoortjes gerepareerd en gelakt worden om 10u...

Zijn er hier trouwens andere enthousiastelingen uit Enschede?

[j-a-s-p-e-r]

Ik ben zeer geïnteresseerd in de source. Erg leuk principe om hier een VM van te maken! Vind het eigelijk tamelijk geniaal!
Jammer dat het meeste hiervan mij boven de pet gaat Maar het is wel ongeveer waar ik in het KaKu topic hardop over na zat te denken; soort van hardware interface om de boel een stuk simpeler aan te kunnen sturen.
Nogmaals: mijn complimenten!

[Jarimacfed]

Fuzzillogic schreef op zaterdag 15 maart 2008 @ 02:49:
[...]


Zijn er hier trouwens andere enthousiastelingen uit Enschede?

enthousiastelingen?? Ik dacht dat het verslaving was.

Helaas niet Steenbergen (NB).

Ben er nu ook ingeslaagd om RC6 IR remote controls werkend te krijgen. Eveneens kan ik nu ook communiceren met de Velleman K8056 Interface kaart via de serieele software poort. Aan de serieele poort heb ik een TX 433 module aangesloten en is de kaart nu ook op afstand te bedienen.

Ik ben benieuwd naar de VM, wat wordt het de VMDuino?? Als ik kan helpen met testen op een MacosX dan hoor ik het graag. .

Ook deze week 2 Arduino's besteld met XBee modules om daar mee te experimenteren.

[Freek]

Even een kick onder de kont van dit topic. Ik heb zojuist een Arduino bordje besteld en ben bezig met een project waarbij ik weer informatie (temperatuur, luchtvochtigheid, zon enz.) wil uitlezen en doorsturen naar een software pakket. Nou was mijn originele plan om gewoon met losse componenten voor al deze functies te werken maar nu lees ik in dit topic dat er mensen bezig zijn geweest om de draadloze communicatie van Kijkshop weerstations uit te lezen. Is iemand dat gelukt en zo ja valt er iets mee te doen?

[Shorty24]

Hallo allemaal,
ik was al een tijd spullen aan het verzamelen voor m'n huisautomatiseringsproject. Nadat ik in de fora van tw.net (waaronder deze thread) info had gevonden over Arduino en RF, heb ik de spullen die de meeste van jullie gebruiken ook aangeschaft.
Ik heb vanmiddag de eerste testjes kunnen uitvoeren. Hartstikke leuk!

Ik heb vanavond een eigen stukje code geschreven voor het monitoren van 't 433mhz RF signaal. Ik twijfel echter of de code snel genoeg zal gaan worden.

De hele truuk van het ontvangen van RF signalen van KAKU zenders is blijkbaar het onderscheiden van een RF signaal t.o.v. ruis. In mijn eigen code ga ik expirimenteren met een sliding-window. Dit zodat automatisch alle typen (X10, KAKU,etc) RF-signalen ontdekt worden.

Kortom... Er is weer iemand actief op deze thread...

gr. Sander
(en iedereen bedankt voor het geven van de info op deze thread)

[Fuzzillogic]

Shorty24 schreef op woensdag 30 april 2008 @ 03:28:

Ik heb vanavond een eigen stukje code geschreven voor het monitoren van 't 433mhz RF signaal. Ik twijfel echter of de code snel genoeg zal gaan worden.

De hele truuk van het ontvangen van RF signalen van KAKU zenders is blijkbaar het onderscheiden van een RF signaal t.o.v. ruis. In mijn eigen code ga ik expirimenteren met een sliding-window. Dit zodat automatisch alle typen (X10, KAKU,etc) RF-signalen ontdekt worden.

Nice X10 stond ook nog op mijn verlanglijstje. Maar waarom denk je dat dat de ATmega te traag is? Mij lijkt eerder het beperkte SRAM-geheugen een groot probleem, zeker als je in die ene kilobyte ook nog andere zaken kwijtmoet. Maar als je Craft ziet (ATMega88!) dan moet het duidelijk zijn dat het toch best mogelijk moet zijn

Kortom... Er is weer iemand actief op deze thread...

Oh, ik ben er ook nog steeds mee bezig. Alleen was/is er een structureel gebrek aan tijd

Wel heb ik net het voorlopige ontwerp voor de bytecode van de VM online gezet, in de vorm van een Freemind mindmap (je hebt de nieuwste betaversie nodig). 80% hiervan werkt ook al prima op de Arduino, en de compiler doet dus ook al prima zijn ding. Ik wil de VM eerst in een generieke vorm afronden, en daarna specialiseren voor gebruikt met KAKU e.d.

Overigens, Arduino software v0011 is al een tijdje uit! Met enkele mooie nieuwe features.

[mux]

Het is mij ook niet helemaal duidelijk waarom een atmega te langzaam zou zijn... als je hem op een kristal laat lopen gaat ie volgens spec 24 MHz, en dan kun je nog overklokken.

En anders heb je nog atmega88's bij dickbest voor geen geld.

[Shorty24]

Inderdaad.. Dat kleine zwarte beestje is idd best wel snel. Sneller dan ik had ingeschat.
Ik heb die gelinked stond in deze thread genomen en aangepast. Hij decodeerd nu de signalen van m'n Ranex-afstandsbediening en Elro AB600-afstandsbediening. Ik zal de code binnenkort posten.

[Shorty24]

Ik heb een Arduino Diecimila (met 168). Als ik het goed heb begrepen is die even snel als de Atmega88's. Ik ben er inderdaad achter dat vooral geheugen "kostbaar" is. In mijn code registreer ik drie data-streams: de ruwe codes (hoog/laag, duratie), de KAKU-bitstream en de RANEX-bitstream. De laatste te nemen horde voor me is nog een X10-bitstream op te gaan bouwen. Hopelijk heb ik straks nog genoeg geheugen over om nog iets te gaan doen met de signalen.

Als iemand m'n code wilt (inzien), moet je hier even een berichtje achter laten. Ik heb niet een ftp achtig iets tot m'n beschikking.

Ik heb from-scratch de KAKU-decode-code geschreven. Ik bemerk dat ik (wellicht) niet de meest handige implementatiewijze heb gekozen. Ik bouw een buffer op tot en met 50 bits. Boven de 50bits reset ik de buffer en begin ik opnieuw. Als ik een terminator-pulse heb gevonden, dan wordt de bitbuffer-lengte gecontroleerd. Is de bitbuffer-lengte 50 bits, dan is het een Ranex/KAKU-signaal. Is het korter dan wordt de buffer geleegd. Ik kan zien dat de KAKU-afstandsbediening meerdere keren de code verzend. Alleen door mijn wijze verkrijg ik meestal maar 1 of 2 keer de code. Op zich natuurlijk genoeg, maar het geeft wel aan dat m'n code niet optimaal is.
Ik denk dat ik de 50bits lange buffer ga proberen door te schuiven bij elke nieuwe bit. Op het moment dat ik dan een terminator ontvang, moet er gecontroleerd worden of het een valide code was. Ook moet ik nog even uitzoeken hoe ik om moet gaan met het halverwege ontvangen van een bit. Elke bit bestaat uit "Hoog-Laag-Hoog-Laag" in de vorm van "Kort-Lang-Kort-Lang" of "Lang-Kort-Lang-Kort". Als ik halverwege een bit begin te registreren kan ik volgens mij de "X"-bit krijgen. "Kort-Lang-Lang-Kort" of vica-versa. Kortom er is nog genoeg te verbeteren...

[j-a-s-p-e-r]

@Shorty24

Hey Shorty. Ik heb deze vraag ook aan P.Tonkes gesteld, maar ook aan jou. Ik heb vd week een aduino besteld en sta te popelen om deze te gebruiken als KaKu aansturing. Nu zag ik dat jij hiervoor een programma hebt geschreven, zou je die met mij/ons willen delen? Dat zou heel erg tof zijn!

[Atmoz]

j-a-s-p-e-r schreef op dinsdag 27 mei 2008 @ 21:06:
@Shorty24

Hey Shorty. Ik heb deze vraag ook aan P.Tonkes gesteld, maar ook aan jou. Ik heb vd week een aduino besteld en sta te popelen om deze te gebruiken als KaKu aansturing. Nu zag ik dat jij hiervoor een programma hebt geschreven, zou je die met mij/ons willen delen? Dat zou heel erg tof zijn!

In de TS staat toch een (werkend) programma?

Hiermee lukt het mij perfect om KaKu switches aan te sluiten...

[Shorty24]

atmoz, je hebt gelijk. Ik heb ook goed (af)gekeken naar die programma's. Ik wil alleen uiteindelijk veel verder gaan. En ik vind het ook wel een uitdaging om dit zelf te coderen.

Ik heb inmiddels een reeks classes opgebouwd die X10, Elro, Ranex, m'n autosleutel en McVoice signalen herkennen en decoderen. Ik ben nu bezig met de terugweg, dus het encoderen tot een signaal en versturen. Het ontvangen lukt al erg goed.
Het verzenden nog niet helemaal: apparaten reageren nog niet. Mijn vermoeden is dat dit komt doordat de pulsen niet regelmatig genoeg zijn. Ik zie op m'n Arduino de pulsen verzonden en direct ook weer ontvangen worden. In de puls-lengtes die ik nog te veel variaties.
Ik moet nog gebruik maken van interrupts voor het verzenden.
Ik loop echter al wel tegen de 16KB grens aan. Ik moet dus binnenkort nog eens flink compactere code schrijven.
Ik heb inmiddels al een flinke berg onderdelen verzameld: 2 * URC MX-3000, 2 * RX418-ontvangers, 3 * RX433-ontvangers, 1*TX433-zender, 8 bewegingssensors, dimmers, schakelaars, RF-rookmelders... Eigenlijk de hele mikmak. Mijn bedoeling is om de Arduino als state-machine te gebruiken..
* Als de rookmelders een signaal afgeven, dan alle lampen aanzetten, alarm buzzers af laten gaan
* Als een bewegingssensor getriggered wordt, tijdelijk lampen in die kamer aanzetten
* Als de MX-3000 gebruikt wordt, signalen versturen naar apparatuur..
* De boiler + cooker alleen aanzetten wanneer er iemand in de keuken is.
Naast bovenstaande ideeen verzin ik vast nog wel meer (on)zinnige mogelijkheden..

[Atmoz]

Klinkt érg interessant!!
Zoveel mogelijk in je omgeving "aan elkaar knopen"
En dan alles met elkaar laten reageren. Heerlijk is dat.

Wekker gaat af: badkamer lamp/verwarming aan, senseo koffie-apparaat aan (en misschien al laten ingschenken) computer alvast aan (als die nog niet aan stond ) etc etc.....

[Fuzzillogic]

Da's ook mijn doel, en da's ook precies waar dat programmeertaaltje voor maak. Maarja, tijd.. Kan niet iemand mij een zak geld geven zodat ik m'n baan op kan zeggen en hiermee aan de slag kan gaan?

[Anoniem: 221963]

@Shorty24

Wow, dat is wel heel uitgebreid. Zo ver wil ik niet gaan; om mezelf even te quoten uit het kaku topic:

Anoniem: 221963 schreef op dinsdag 20 mei 2008 @ 15:38:
[...]
Ik wil ook wat gaan knutselen met de Arduino in combinatie met X10 en KaKu. Het idee is om X10 signalen te ontvangen met een RF ontvanger, te detecteren en om te zetten met het Arduino bordje en weer te verzenden met de RF zender. Zo kan ik goedkope KaKu modules gebruiken met bijvoorbeeld de X10 CM15Pro programmeerbare interface om zo ook makkelijk macros te kunnen gebruiken (om mee te beginnen, want dat zou met de Arduino natuurlijk ook kunnen).
Om niet opnieuw het wiel te hoeven uitvinden ben ik dus wel geïnteresseerd in de routines.

Vandaar ook dezelfde vraag als j-a-s-p-e-r, zou je deze code beschikbaar willen stellen?

[Shorty24]

Ik heb mn sourcecode inmiddels bij 3 mensen naar deze thread gestuurd.

@FrodoKenny: Je had alleen in je galary geen emailadres staan.. Helaas kon ik je de code dus niet mailen.. Helaas heb ik nog niet de beschikking over een f tp-servertje..

Wellicht wilt randysimons wel de code even voor je hosten..

Ik ben even een weekje op vakantie. Ik hoop dat jullie in de tussentijd er lekker op los kunnen hobbyen..

Oh ja.. Voor iedereen die huis automatisering wil doen, maar geld wilt besparen.. Door zelf iets in elkaar te knutselen, kan je meerdere protocollen tegelijk ondersteunen. Hierdoor kan je goedkopere componenten aanschaffen..
Ik heb 2 rookmelders voor 12,50euro per stuk gekocht.
Halogeen dimmer (opbouw) voor 14,50euro per stuk
Watermelders voor 24,50euro per stuk
Bewegeingsmelders voor 40euro per 4 stuks

greetz, Sander

[ Voor 32% gewijzigd door Shorty24 op 07-06-2008 01:07 ]

[Anoniem: 221963]

Ja, dat was ook mijn idee. X10 spul is niet echt goedkoop in vergelijking met KaKu ofzo.

@Shorty24
Thanks voor het rondmailen. Ik heb nog geen host url gezien, dus ik heb mijn email adres even zichtbaar gemaakt in de gallery (je kan ook mijn gebruikersnaam nemen met kleine letters en er hotmail achter plakken )

[Atmoz]

Shorty24 schreef op zaterdag 07 juni 2008 @ 01:04:
Ik heb mn sourcecode inmiddels bij 3 mensen naar deze thread gestuurd.

Hé ik heb 'm ook ontvangen
Thanks!!

Moet hier ook weer eens snel mee verder gaan.
Té leuk spul om te laten liggen allemaal!!

[nick_haak]

hey, interessant topic, eerste keer dat ie me opvalt

klein beetje offtopic misschien, maar aangezien mensen het hier over bluetooth in combinatie met microcontrollers hadden, weet iemand toevallig een adres waar je die modules (voor op een arduino, of los aan een microcontroller) voor een schappelijke prijs kan krijgen? zijn vrij prijzig, en hier niet zo makkelijk te krijgen

iemand? bedankt

[Anoniem: 175972]

Kijk hier maar eens tussen: http://www.sparkfun.com/commerce/categories.php?c=16. Ik heb zelf de BR-SC11A module gebruikt (http://elec.rommelkist.nl/bluetooth.html).

[nick_haak]

bedankt voor de link, via jouw site ben ik toevallig pas geleden op het idee gekomen om wat te prutsen met bluetooth in combinatie met een microcontroller (atmega8 bijvoorbeeld).

de sparkfun link ben ik toen ook al tegengekomen, maar toen viel ik even achterover van de prijzen de goedkoopste is 40 euro, en dat is nog wel te doen, maar dan komen je verzendkosten er ook nog bij, ben bang dat dat flink oploopt

[Anoniem: 175972]

Ja, die modules zijn idd nogal prijzig, maar met de lage $-koers ....

[nick_haak]

daar zit wat in

weet jij nog hoeveel je kwijt was aan verzendkosten? misschien wordt het dan toch nog interessant

[Anoniem: 175972]

Volgens de website:

United States Postal Service Express Mail International (EMS) $27.95
United States Postal Service First Class Mail International Package $4.20

Ik heb 't gewoon via de mail laten komen. Werkte prima.

[nick_haak]

da's niet verkeerd zeg, had eerder prijzen als de bovenste verwacht, bijna 30 dollar is een beetje teveel van het goeie

ik houd me uiteraard aanbevolen als iemand anders een nog goedkopere manier weet ben en blijf een Nederlander uiteraard

[Atlas]

Zo ik heb die 433 Mhz ontvangers/ verzenders van Niels ook maar eens onder het stof gehaald en uitgeprobeerd. Alleen werkt het niet

Ik heb nu deze opstelling:
• Een Atmega8 met een verzend-module eraan die (ter test) alleen nog maar 'G' over de seriele poort stuurt met 4800 baud.
• Een PC aan de andere kant, met de ontvanger eraan icm een Max232.
Beide antenna's zijn de goeie lengte (17.4 cm geloof ik).

Als ik bijvoorbeeld realterm open op mijn PC dan zie ik allemaal bagger als de Atmega8 uit staat. Zet ik de Atmega8 aan dan komt er niets meer binnen (de bagger is dus ook weg) op de seriele poort. Hij doet dus wel iets, maar ik zie zelf ook niets binnen komen.
Doe ik wat verkeerd?
(als ik het geheel hardwire aansluit werkt het wel ).

[Anoniem: 175972]

@ nick_haak:
Ik heb eens naar de ZigBee modules gekeken. Worden al voor ca. €19,- aangeboden, maar daarvan zijn de dongles een stuk duurder! Als je alleen maar communicatie wilt tussen microcontrolers dan is het wellicht ook een optie!

[ Voor 3% gewijzigd door Anoniem: 175972 op 18-06-2008 16:28 ]

[nick_haak]

bedankt voor het idee, maar de opzet zou juist communicatie tussen pc <> microcontroller, of gsm <> microcontroller worden.... dus dat is ook geen optie.

toch bedankt

[sunoke]

@Atlas: Die 433MHz is geen directe vervanger voor een draadje, dwz. je krijgt behoorlijk wat rotzooi binnen. Die zul je op een of andere manier moeten kunnen identificeren (of omgekeerd, de data identificeren). Vaak wordt de data hiervoor geencodeerd. Zoek bijvoorbeeld eens naar manchester codering.

[Atlas]

Ik zie dat ik de rotzooi binnen krijg ja, maar ik kan dus niet op het ene ding ascii tekens sturen en die eruit filteren in de RX buffer van de andere Atmel?
Ik wilde eerst wat 01010101's sturen om de attentie van de ontvanger te krijgen, daarna de boodschap, en daarna de checksum. Zodat ik kan controleren of alles goed binnen is gekomen. Maar ik denk dus te simpel?