433MHz Wetterstation PWM Signal demodulieren??

[NilsRoe]

Moin moin,

ich habe aus einer Abstandswarnanlage fürs Auto aus der Grabbelkiste beim blauen C je ein Modul zum Senden und Empfanen auf 433 MHz ergattert. Das Empfangsmodul scheint vollanalog aufgebaut zu sein. Beim Anschließen an den Line-In meines PC hat's erst einmal jede Menge Rauschen gegeben; ab und an aber auch ein offensichtliches Datenpaket. Wie sich der Außensender meiner Wetterstation anhört, habe ich schnell herausbekommen; auch, dass dieser einige Male hintereinander ein Datenpaket mit 40 Byte abfeuert; danach ist für ca. eine Minute Ruhe. In dieser Minute Ruhe wird jedoch wieder jede Menge Rauschen empfangen (auch teils fremde Signale, aber die interessieren mich nicht).


So sieht ein Datenpaket aus. Gut zu erkennen ist die Präambel, mit der ein Datenpaket angekündigt wird. Die 40 Bits folgen; in ihnen sind Sender-ID, Kanalnummer, Temperatur und Luftfeuchtigkeit codiert. Mein eigentliches Problem ist hier jedoch nicht die Datenstruktur, sondern: Von Hand Pulse decodieren ist doof; das kann doch ein kleiner Rechenknecht viel besser! Am Besten ein Controller; Arduinos habe ich haufenweise herumliegen.

Soweit habe ich an Daten erfasst:
Präambel: ca. 1500µs (750µs LOW/ 750µs HIGH), 4 Pulse
Bit 1: ca. 750 µs (500µs LOW/ 250µs HIGH)
Bit 0: ca. 750 µs (250µs LOW/ 500µs HIGH)

--> Wie bekomme ich das einem Controller beigebracht, auf eine Präambel zu warten (dabei Rauschen möglichst auszublenden) und dann die 40 Bit auszuwerten? Ich stehe da gerade voll auf dem Schlauch.

Timer, der bei LOW (los) läuft und bei HIGH ausschaltet? Zeit-Delta auswerten? Zwei Timer? Alles im Hauptloop?

Das Gegenteil, Bits in die Luft zu blasen ist dagegen ein Kinderspiel.

Gruß
Nils

[xoexlepox]

Ich würde einen Timer nehmen, der alle ca.50µs einen Interrupt erzeugt, das Eingangssignal sampelt, und das empfangene Bit in einen Puffer schiebt. Die Hauptschleife schaut dann nur noch im Puffer nach, wieviele gleiche Bits aufeinanderfolgen, und dröselt so die Daten auseinander.

[zauberkopf]

Die Präambel gibt sagt nicht nur aus :
Ein packet beginnt.
Es sagt auch aus : Das ist hier der Takt, mit dem die nachfolgenden Daten kommen.

[xoexlepox]

Das ist hier der Takt, mit dem die nachfolgenden Daten kommen.

Deshalb auch ein Abtastinterval von einem Fünftel des kürzesten Bits. Das sollte innerhalb der 40Bit-Folge nicht ganz so weit "weglaufen". Wenn es richtig exakt sein muß, kann man nach dem dritten Präambel-Bit auch auf "Interrupt on Change" umschalten, um die Flanken noch genauer zu ermitteln, und dann in der Mitte der Bitzelle samplen. Die Variante "Nur Interrupt on Change" könnte bei "Rauschen" ziemlich eklig werden

Edith meint: Alternativ könnte der 50µs-Interrupts auch zwei Zähler für "aufeinanderfolgende, gleiche Bits" hochzählen. Dann wir jedoch eine Synchronistion zwischen Hauptschleife (Auslesen der Zähler) und dem Interrupt nötig...

[NilsRoe]

Moin,

das mit dem Sampeln ist eine gute Idee! Da muss ich mir nur noch überlegen wie ich das mit dem Zwischenpuffer und dessen Prüfung am Besten mache. Das kommt dann irgendwann zwischen den Klausuren.


Gruß,
Nils

[BMS]

Hallo,
genau diese Probleme gibt es auch bei den üblichen Infrarot-Fernbedienungs-Protokollen.
Aus dem uC Forum könnte man sich an dem IR-Multiprotokoll-Decoder orientieren bzw. den umbauen
https://www.mikrocontroller.net/articles/IRMP
Viele Grüße,
Bernhard

[ferdimh]

so ein Problem löst man akademisch per Korellation.
Ich würde die Kiste auf 8 Smples pro Bit einstellen, also alle 750/8µs. Das ist mit einer Interruptroutine noch machbar, wenn man nicht Arduinosoftware benutzt, sondern C schreibt. Ansonsten hat man verloren.
Wenn man das Signal das man erwartet und das Signal das man sieht miteinander multipliziert (Wenn beides nur 0 oder 1 sein kann, ist das die XNOR-Funktion, die geht schneller)
Schritt 1 ist jetzt "Synchronisieren": Wir nehmen erstmal die letzten 64 gesampleten Bits und schreiben die weg. Jetzt verXORen wir das Ganze mit der erwarteten Präambel (8 1er, 8 0er, 8 1er etc) und zählen die Nullen im Ergebnis (0 heißt "richtig geraten"; Möglicherweise ist Zählen der Einser schneller, muss man ausprobieren). Wenn wir mindestens 90% Nuller haben, haben wir eine Präambel erkannt (also maximal 6 Einser). Genau dann ist der Startzeitpunkt. Ab jetzt stellt man eine Variable um, so dass die nächsten 40*8 Samples eine andere Routine aufgerufen wird.
Das ist Schritt 2:
Daten decodieren. Theoretisch kann man das auch mit einem Korellationsansatz wie oben machen, wir können aber die Mathematik vereinfachen:
Die ersten 2 Samples sind auf jeden Fall ne 1. Wenn die Datenrate halbwegs sinnvoll eingehalten wird, müssen wir für 40 Bits nicht nachsynchronisieren.
1. und 2. Sample werden also einfach ignoriert.
3. Sample ist vielleicht oder vielleicht auch nicht... ignorieren.
4.und 5. Sample enthalten Daten. Da es dummerweise zwei sind, können wir hier keinen Mehrheitsentscheid treffen. Wenn die beiden nicht gleich sind, haben wir Bullshit empfangen. Eventuell müsste man hier auf 9 Samples pro Bit umstellen, dann wirds aber kompliziert.
das 6. Sample ist wieder ander Kante -> ignorieren.
Das 7 und 8. Sample ist sicher 0 -> wieder ignorieren.
Nachdem wir das 40 mal durchgekaut haben, werden die Daten ausgewertet (hier darf die Interruptroutine auch ausnahmsweise mal lange brauchen, im Hauptprogramm wäre aber besser) und es geht zurück in die Synchronisationsroutine.

[Anse]

Das ist wahrscheinlich Manchester-Code. Der ist gut geeignet für einfache Funkübertragungen da eine anhaltende Folge von Nullen oder Einsen zu einem ständig wechselnden Signal führt. Die Information liegt also nicht in dem Pegel sondern in der Änderung des Pegels.
Ich hab schon mit Sampling Datenströme mit 2kHz decodiert. Wenn das Signal sauber ist kann man auch einen Interrupt verwenden. Das reduziert die Belastung etwas.
Das Arduino typische DigitalRead ist dabei aber eher wenig produktiv.