Funkprotokoll Störungssicher machen

[Florian E. (fofi1)]

Hi,

ich habe derzeit für eine kleine Gartenbeleuchtung die RFM98W (Lora 
Module) im Einsatz. Da die Beleuchtung kaum Funktionsumfang hat bestehen 
die Nutzdaten des Funk-Datenpakets aus gerade mal 3 Bytes.

1) Slaveadresse + Arbeitsmodus(jeweils 4 bit)
2) Farbwert
3) CRC8

Nun empfängt das Modul aber im Sekundentakt "Müll" von umliegenden 
Wetterstationen usw.. Nach einigen Stunden wird dann durch Zufall 
CRC+Datensatz richtig erraten und somit dann die Einstellung in der 
Beleuchtung verändert.


Wie kann ich das verhindern? Muss ich zwingend mehr Nutzdaten haben, 
damit die Wahrscheinlichkeit eines Zufallstreffers sinkt?



PS: Ich hab euch im Anhang mal einen Mitschnitt des Datenmülls 
angehängt. Es sind die 3 empfangenen Bytes zu sehen und dann die intern 
berechnete CRC.

Gruß,
Flo

[Wolfgang (Gast)]

Florian E. schrieb:
> Wie kann ich das verhindern?

Indem dein Datentelegramm sich besser von anderen Telegrammen 
unterscheidet.

Wenn die sporadische Reaktion auf fremde Signale daran liegen, dass ein 
anderer Sender ein für deine Steuerung passendes Datentelegramm sendet, 
hilft nur ein anderer Aufbau deines Telegramms. Du könntest ein anderes 
Generatorpolynom für deine CRC verwenden, eine weitere Prüfsumme 
hinzufügen, Rolling Code Verschlüsselung verwenden, oder, oder, ...

[... (Gast)]

Ja du brauchst auf jeden Fall mehr Nutzdaten bzw. überhaupt mehr Daten. 
Du kannst z.B. deinen Datensatz 5 mal hintereinander kopieren. Eine 
längere Checksumme wäre auch gut, CRC32 oder gleich CRC64.

[Marc V. (Firma: Vescomp) (logarithmus)]

Florian E. schrieb:
> Wie kann ich das verhindern?


 Indem du ein bisschen nachdenkst ?

 Wieso empfängst du stur 3 Byt, wenn schon Byt Nr.1 nicht stimmt ?
 Wenn die Slaveadresse nicht stimmt, wird gleich von vorne angefangen
 und nicht erst nach zwei weiteren Bytes.

 Wenn danach CRC nicht stimmen sollte, werden auch nicht gleich alle
 3 Bytes verworfen, sondern nur das erste Byte.
 Falls dann Byte Nr.2 nicht die richtige Adresse enthält, wird er
 auch verworfen.
 Usw...

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Bei solch kurzen Paketen kann es auch sinnvoll sein (so mache ich das 
für mein Wireless DMX), die Daten zweimal zu senden. Dazu sende ich Wert 
und den binär invertierten Wert direkt hintereinander, welche der 
Empfänger sofort auf Checksum 0 prüft. Wenn da was nicht stimmt, wird 
gar nicht erst auf die Paket CRC gewartet, sondern gleich verworfen. 
Sowas geht natürlich auch mit deiner Geräteadresse und der CRC selber.
Da gibts es unendlich viele Möglichkeiten, der Tenor ist aber, wie schon 
o.a., mehr Daten zu senden und diese redundant auszulegen.

[Florian E. (fofi1)]

Marc V. schrieb:
>  Wieso empfängst du stur 3 Byt, wenn schon Byt Nr.1 nicht stimmt ?

Weil das HF Modul gerade so eingestellt ist, dass es eine feste 
Paketlänge selber empfängt und in den Fifo speichert. Danach löst es 
einen Interrupt aus und ich lese alle 3 Bytes aus.



@All:
Danke für die Infos. Schlussendlich läuft es also fast immer darauf 
hinaus mehr Daten zu senden bzw. weitere Variablen ins Spiel zu bringen 
um die Wahrscheinlichkeit eines Zufallstreffers zu verringern. Dann 
werde ich das mal im Code umsetzen

[Florian E. (fofi1)]

Marc V. schrieb:
>  Wieso empfängst du stur 3 Byt, wenn schon Byt Nr.1 nicht stimmt ?

Weil das HF Modul gerade so eingestellt ist, dass es eine feste 
Paketlänge selber empfängt und in den Fifo speichert. Danach löst es 
einen Interrupt aus und ich lese alle 3 Bytes aus.



@All:
Danke für die Infos. Schlussendlich läuft es also fast immer darauf 
hinaus mehr Daten zu senden bzw. weitere Variablen ins Spiel zu bringen 
um die Wahrscheinlichkeit eines Zufallstreffers zu verringern. Dann 
werde ich das mal im Code umsetzen

[Stefan F. (Gast)]

Ja, auf jeden Fall mehr Daten, mindestens 8 Bytes.

Ich sende sie immer mindestens 3 mal (wenn langsames Timing tolerierbar 
ist, dann sende ich sogar 10 mal). Der Empfänger reagiert erst, wenn er 
mindestens 2x hintereinander das gleiche Paket empfangen hat.

Wenn du das so machst, genügt auch eine einfache Prüfsumme anstatt CRC.

[Mark U. (residuum)]

Ein anderer Ansatz ist es, ein einfaches Protokoll zu verwenden.

Wenn Daten übertragen werden sollen, könnte das so ablaufen:

Steuerung schickt Anfrage an Beleuchtung: Kann ich Daten senden?
Beleuchtung antwortet der Steuerung: Ja, ich bin bereit.
Steuerung sendet Daten an Beleuchtung: Hier sind die Daten.

Falls die Steuerung irrtümlich meint, eine Anfrage der Steuerung 
erhalten zu haben und darauf antwortet ("bereit"), kann
a) die Steuerung diese Antwort ignorieren, die Beleuchtung läuft in ein 
Timeout und unternimmt nichts weiter.
b) die Steuerung eine Nachricht an die Beleuchtung schicken "keine 
Daten"

Dieses einfache Protokoll zusammen mit den oben beschriebenen Maßnahmen 
wird ein versehentliches Schalten der Beleuchtung verhindern.

[Hans M. (Gast)]

Florian E. schrieb:
> Nun empfängt das Modul aber im Sekundentakt "Müll" von umliegenden
> Wetterstationen usw..

>>Wie das denn? Das sollte LoRa nicht störnen ;-)

Hans

[Mark U. (residuum)]

Der "Müll" kommt einfach aus dem Rauschen. Auch wenn das Modul in einem 
HF-dichten Gehäuse liegt, wird es immer wieder eine vermeintlich gültige 
Nachricht empfangen.

[Hans M. (Gast)]

Ist der "Müll" im Rauschen nicht eigentlich die LoRa Kommunikation?! :-P

Hans

[uwe (Gast)]

reed solomon
Beitrag "Reed-Solomon Encoder / Decoder in C"
http://rscode.sourceforge.net/
http://www.drdobbs.com/cpp/reed-solomon-error-correction/184410107

[Jobst M. (jobstens-de)]

Florian E. schrieb:
> Schlussendlich läuft es also fast immer darauf
> hinaus mehr Daten zu senden bzw. weitere Variablen ins Spiel zu bringen
> um die Wahrscheinlichkeit eines Zufallstreffers zu verringern.

Naja, mit 24 Bit hast Du 2^24, also 16M Kombinationen. 65536 sind 
sinnvoll. D.h. jede 256ste trifft.

Du musst einfach das Verhältniss hoch schrauben.

Gruß
Jobst