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
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, ...
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.
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...
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.
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
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
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.
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.
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
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.
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
Muell.PNG
(39 KB)
