[Timing probleem] Nabootsen signaal...

[Atmoz]

Beste,

Onderstaand signaal (zie gecapturde screenshots) zou ik graag willen nabootsen met een microcontroller.
Dit is een 433,92Mhz signaal wat voor de besturing van automatische rolgordijnen is. Aan de bron (handzender) heb ik een oscilloscoop hangen om naar het signaal te kijken.

Het probleem is dat ik niet zeker weet of mijn aanpak correct is. Maak ik een "laag" en/of een "hoog" wel zoals in het originele signaal zit verwerkt? (of moet het juist geïnverteerd worden?) Zijn de timings ZEER belangrijk, of kun je er best iedere puls een paar honderd microseconden naast zitten? Hoe zit het met een zogenaamde "preamble"? (wist niet wat dat betekende, dus die maak ik in mijn test-programma niet, m'n pa kwam daar zojuist mee...)























De test-code (waarmee het uiteraard niet werkt ) is als volgt:

code:

void setup() {               
  pinMode(3, OUTPUT); 
  pinMode(13, OUTPUT); 
}


//800 laag
void Laag(){
  digitalWrite(3, LOW);
  delayMicroseconds(680);
  digitalWrite(3, HIGH);
  delayMicroseconds(120) ;
}


void Hoog(){
  digitalWrite(3, LOW);
  delayMicroseconds(150);
  digitalWrite(3, HIGH);
  delayMicroseconds(650) ;
}




void loop() {

  Hoog();
  Laag();
  Hoog();
  Laag();
  Hoog();
  Hoog();
  Hoog();
  Laag();
  Laag();
  Hoog();
  Hoog();
  Hoog();
  Laag();
  Hoog();
  Hoog();
  Laag();
  Laag();
  Laag();
  Laag();
  Laag();
  Laag();
  Hoog();
  Hoog();
  Hoog();
  Laag();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Laag();
  Laag();
  Laag();
  Laag();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Laag();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Laag();
  Hoog();
  Hoog();
  Laag();
  Hoog();
  Hoog();
  Hoog();
  Hoog();
  Laag();
  Laag();
  Laag();
  Hoog();
  Hoog();
  Laag();
  Laag();
 
  digitalWrite(13, HIGH);
  delay(1000);
  digitalWrite(13, LOW);
  delay(1000);
 
}

Belangrijkste vragen: zijn mijn timings correct? Of moet dit véél preciezer? Vergeet ik nog iets?
Hopelijk kom ik met jullie hulp een (flinke) stap verder Thanks alvast in ieder geval!

[alexandersamson]

Ik weet niet wat voor microcontroller je hebt, maar stel dat je een Arduino DUE zou hebben, die draait geloof ik op 84 MHz. Die kan nooit een draaggolf creeren van 434 MHz, waar de ontvanger mee werkt.
Pulsen genereren binnenin die draaggolf zou misschien wel kunnen, ze zijn zo te zien ongeveer een millisec per stuk. Pulsen zo op deze manier, zoals je dat nu wil doen sturen naar een ontvanger van 434MHz zal niet werken, want de antenne en de resonator van de ontvanger zijn niet ingesteld op de veel lagere frequentie van je microcontroller. Je moet dus eerst een goede draaggolf hebben van de juiste frequentie. Zal je een HF zender/oscillator voor moeten maken en daar binnenin je signaal moduleren. Daar heb ik zelf trouwens verder geen verstand van.

[JER00N]

Ik neem aan dat je wel een of andere 433 MHz-zender gebruikt?

Heb je jouw signaal al eens bekeken op de scoop?

Preamble is een reeks 'lege' data (meestal 0101010101....) aan het begin van een zending die wordt gebruikt om ontvangers a.h.w. wakker te maken. De ontvangers gebruiken die preamble om hun ontvangstversterking op af te regelen. Als jouw handzender een preamble heeft zou je dat natuurlijk ook moeten zien. Maar het zou ook kunnen (net als bij klik-aan-klik-uit etc.) dat het pakket gewoon meerdere keren achter elkaar verstuurd wordt waardoor een preamble niet nodig is.

Wat betreft timing, dit zou ik vergelijken met je scoop. Die digitalWrite()-functies van Arduino zijn nogal traag geloof ik omdat ze eerst nog controleren of een pin als input of als output staat ingesteld. Ter compensatie zou je dan die delayMicrosecond()-functies wat moeten verkorten.

[ Voor 19% gewijzigd door JER00N op 30-07-2013 10:04 ]

[Atmoz]

Ik maak inderdaad gebruik van zo'n (standaard/goedkoop) RF433Mhz TX-module:



Goede tip over dat met die delayMicrosecond()-functie!
Straks maar eens proberen Maar zo heel "super nauwkeurig" komt het dus niet? (beetje proberen zegmaar...)

Helaas heb ik zelf niet de mogelijkheid om m'n eigen signaal via de scoop te bekijken.
Daarvoor moet ik naar m'n pa. Maar is zeker ook iets wat ik nog kan doen mocht het niet werken als ik nog wat geprobeerd heb thuis.

Ziet mijn code er verder wel goed uit om dat signaal in de screenshots na te bootsen? (behalve dan de tijden even wat korter maken)

[JER00N]

Probeer trouwens ook eens om in plaats van elke seconde één keer die reeks te versturen, meerdere keren hetzelfde pakket te sturen. Bijvoorbeeld 10 keer achter elkaar met een pauze ertussen van 10 ms (of 5 ms zoals in je scoopbeelden). Zo wordt dat ook gedaan bij veel ander 433 MHz-spul. Bij zo'n klik-aan-klik-uit-set wordt bijvoorbeeld uitgezonden zolang je de knop ingedrukt houdt. Zelfde verhaal bij infrarood-afstandbedieningen. Puur omdat de ontvanger even tijd nodig heeft om zich in te stellen.

Hang er trouwens ook een antenne aan, een draad van 17 cm aan dat 'ANT'-padje scheelt ook een hoop. Anders is je ontvangst soms maar een paar meter.

[Sissors]

Als ik die golfvormen zie denk ik niet dat timing heel kritisch zal zijn. Uiteraard wil je er wel redelijk in de buurt van komen, maar het lijkt me redelijk triviaal om zo'n signaal te decoderen ook al zitten er wat timing foutjes in, dus ik neem ook aan dat ze dat doen.

[Atmoz]

Ah top! Dat zijn dingen waar ik wederom iets aan heb. Super

Ik had al een antenne genomen van 16cm omdat ik dat in m'n hoofd had zitten als luiste lengte.
Maar na een beetje zoeken kwam ik inderdaad op 17(,4) uit! Ook maar even aanpassen dan..

Verder had ik zelf nog een idee om de timings te testen:

code:

start=millis();

... hier alle Hoog() en Laag() aanroepen...

finished=millis();
elapsed=finished-start;
Serial.print(elapsed);

Heeft zoiets nog nut om te kijken of ik (ongeveer) de juiste (totale verzend) tijden heb?
Uiteindelijk zou "elapsed" toch ongeveer 53 moeten zijn, right?

[edit]

Nog beter zou misschien micros(); zijn Dat zou in feite toch goed (lees: redelijk secuur) moeten werken..

[ Voor 9% gewijzigd door Atmoz op 30-07-2013 14:44 ]

[Piepersnijder]

Jouw code gaat zo niet werken omdat je voor hoog en laag een vaste tijdswaarde hebt gemaakt terwijl de tijdsduur voor hoog en laag verschillend zijn.

[Atmoz]

Piepersnijder schreef op dinsdag 30 juli 2013 @ 16:35:
Jouw code gaat zo niet werken omdat je voor hoog en laag een vaste tijdswaarde hebt gemaakt terwijl de tijdsduur voor hoog en laag verschillend zijn.

Hoe bedoel je dat precies?
De duur van een "0" (korte puls neem ik even aan) is toch even lang als een "1"?
(de totale tijd, dus inclusief het lage signaal)

Zoals hier:



De afstand tussen de 2 rode is toch even groot als de 2 blauwe?
Of bedoel je wat anders? Thanks voor het meedenken igg!

[Piepersnijder]

Sorry, ik heb niet goed naar je code gekeken. Het klopt wel.
Je moet wel deze pulsenreeks een aantal keren herhalen en niet vergeten de lange periode 0 (sync) in te voegen.
Aan de hand van deze sync kan de ontvanger zien wat het begin en einde is van deze pulsreeks.
Ik zou het minimaal 5 keer herhalen.

de opbouw van de pulsereeks is gelijk aan de wijze waarop de klikaan-klikuit systemen zijn opgebouwd. Ook heel veel andere systemen werken hiermee. Ik heb de code uitgelegd op mijn website.

Zit er geen verschil tussen het openen en sluiten van de rolgordijn?

[Atmoz]

Piepersnijder schreef op woensdag 31 juli 2013 @ 08:08:
Sorry, ik heb niet goed naar je code gekeken. Het klopt wel.
Je moet wel deze pulsenreeks een aantal keren herhalen en niet vergeten de lange periode 0 (sync) in te voegen.
Aan de hand van deze sync kan de ontvanger zien wat het begin en einde is van deze pulsreeks.
Ik zou het minimaal 5 keer herhalen.

de opbouw van de pulsereeks is gelijk aan de wijze waarop de klikaan-klikuit systemen zijn opgebouwd. Ook heel veel andere systemen werken hiermee. Ik heb de code uitgelegd op mijn website.

Zit er geen verschil tussen het openen en sluiten van de rolgordijn?

Thanks Piepersnijder, goed om te horen dat het toch klopt. Dan kan ik daar op voortborduren
En mijn interpretatie van '1' en '0' klopt dus ook? (zoals hieronder)



Als ik een '1' moet nabootsen/sturen maak ik dus heel kort het datapinnetje LAAG, en erna iets langer HOOG. En voor een '0' lang LAAG, en erna kort HOOG. Dat klopt ook hoop ik?

Het valt allemaal nog niet mee (heel anders dan KAKU) want ik kwam er gisteren achter dat ook de zender (d.m.v. een klein knopje wat "vrij" kwam omdat de behuizing open was...) ook in een bepaalde "programmeer-stand" kan staan en daardoor niet altijd hetzelfde signaal verstuurd als je bijvoorbeeld "omhoog" indrukt... Waarschijnlijk heb ik (m'n pa) dát signaal gecaptured en proberen na te maken. (waar verder niets mee gebeurt als de ontvanger niet ook in de "prog" modus staat argggghhh

Maarja, blijft lekker he: klommelen

[Piepersnijder]

Ik heb je timingtabel omgezet in blokjes in de exacte verhoudingen zoals jij die hebt toegepast.
Vervolgens deze blokjes achter elkaar gezet en over jouw afbeelding gelegd.
Klik voor afbeelding

de bovenste rij blokjes zijn in de orginele verhouding.
In de onderste rij blokjes heb ik de timing iets aangepast zodat deze beter samenvallen met de pulsen.

De timing zou ik veranderen in:

void Laag(){
digitalWrite(3, LOW);
delayMicroseconds(580);
digitalWrite(3, HIGH);
delayMicroseconds(180) ;
}

void Hoog(){
digitalWrite(3, LOW);
delayMicroseconds(150);
digitalWrite(3, HIGH);
delayMicroseconds(680) ;
}

[Atmoz]

Wow, dat ziet er goed uit Thanks Piepersnijder!!
Mijn timing zag er inderaad niet zo heel netjes uit...

Helaas ligt het niet alleen aan de timing, want ook met die aanpassingen lukt het niet.

Ik gebruik onderstaande code. Valt daar nog wat aan op te merken?

code:

unsigned long start;
unsigned long eind;
unsigned long elapsed;

void setup() {  
  //Serial.begin(9600);   
  pinMode(11, OUTPUT); 
  pinMode(13, OUTPUT); 
}


void leesArray(){
  
  byte nr;

    int myArray[66]={1,0,1,0,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,1,1,1,0,1,1,1,1,0,0,0,0,1,1,1,1,1,1,0,1,1,1,1,1,1,1,1,1,1,1,0,1,1,0,1,1,1,1,0,0,0,1,1,0,0};
  
  
  for (int i=0; i <= 65; i++){
    nr = myArray[i];
           
      if (nr == 1){
        //Serial.println("1");
        Hoog();
        //Laag();
      }else{
        //Serial.println("0");
        Laag();
        //Hoog();
      }
   } 
}


void Laag(){
  digitalWrite(11, LOW);
  delayMicroseconds(580);
  digitalWrite(11, HIGH);
  delayMicroseconds(180) ;
  digitalWrite(11, LOW);
}

void Hoog(){
  digitalWrite(11, LOW);
  delayMicroseconds(150);
  digitalWrite(11, HIGH);
  delayMicroseconds(680) ;
  digitalWrite(11, LOW);
}


void loop() {

  //start = micros();  
 
  //digitalWrite(3, HIGH);
  //delay(100);
    
  for (int i=0; i <= 10; i++){
    digitalWrite(3, LOW);
    delay(5);
    leesArray();
    delay(5);
  } 
 
  //eind = micros();  
  //elapsed=eind-start;

  //Serial.println(elapsed);
  delay(1000);

}

Het signaal (overal in die screenshots dus) is gemeten tussen de DATA pin die richting de TX module op de afstandsbediening gaat, en de PLUS 5 volt.

Zijn de pulsen dan wel goed om? Of moet ik ze juist inverteren? (ook gedaan, maar werkt ook niet).
En is het normaal dat ik een "bit-trein" krijg van 66 bits? (waarom 66 en niet 64 bijvoorbeeld? Dat is toch makkelijk naar bytes om te rekenen!)

En wat zou ik nog meer kunnen proberen om dit projectje met succes te laten slagen?

Nogmaals heel erg bedankt allemaal, zonder hulp gaat die rolgordijn nóóit open

[Piepersnijder]

Ik heb jouw code in een arduino gezet en het resultaat daarvan met een logic analyzer bekeken.
Dit is het resultaat: Plaatje

Als ik dit plaatje leg op het plaatje van jouw (scope1.jpg) zie ik dat de timing iets uit de pas loopt en dat de sync puls veel te lang duurt. Ik vraag me af of dit laatste zo erg is.
Verder klopt het wel aardig.

edit:
Wat ook nog zou kunnen is dat jouw rolgordijn is uitgerust met een roling code systeem. Dit wil zeggen dat telkens wanneer je dezelfde toets in drukt, de code anders is. In dat geval heb je een uitdaging.

Je zou het nog eens kunnen meten en vergelijken met een eerdere meting.

[ Voor 62% gewijzigd door Piepersnijder op 02-08-2013 09:42 ]

[Atmoz]

Piepersnijder schreef op vrijdag 02 augustus 2013 @ 09:00:
Ik heb jouw code in een arduino gezet en het resultaat daarvan met een logic analyzer bekeken.
Dit is het resultaat: Plaatje

Als ik dit plaatje leg op het plaatje van jouw (scope1.jpg) zie ik dat de timing iets uit de pas loopt en dat de sync puls veel te lang duurt. Ik vraag me af of dit laatste zo erg is.
Verder klopt het wel aardig.

edit:
Wat ook nog zou kunnen is dat jouw rolgordijn is uitgerust met een roling code systeem. Dit wil zeggen dat telkens wanneer je dezelfde toets in drukt, de code anders is. In dat geval heb je een uitdaging.

Je zou het nog eens kunnen meten en vergelijken met een eerdere meting.

Sjiek dat je er zoveel verstand van hebt, en dat je me hiermee wilt helpen. Echt gaaf
De rolgordijnen werken gelukkig niet met een "rolling code" want alle screenshots in dit topic zijn gemaakt van _verschillende_ knop-drukjes Ik ga straks de sync puls eens verkorten, en dan kijken wat er gebeurt. Man wat zou het mooi zijn als dat gordijn opeens open/dicht gaat via m'n Arduino

Vanavond nog maar weer eens wat proberen. Thanks again!

[Piepersnijder]

Ik heb mijn meting over jouw afbeelding gelegd zodat je een beetje kunt zien hoe het zit.
Helaas is jouw scherm capture niet erg duidelijk dus dat maakt het een beetje last om het goed te kunnen zien. Hier het Plaatje.
vanaf de helft lopen de pulsen uit de pas, daarna klopt het weer. De syncpuls is veel te lang.
Ik hoop dat het een beetje duidelijk is.

Succes.