CC110x-Signale mit RFM22 lesen/senden

[Sebastian V. (voitzsch)]

Hallo zusammen,

wie im anderen Thread "AskSin/BidCos mit RFM22 lesen" bereits 
geschrieben, versuche ich gerade, HomeMatic-Signale mit einem RFM22 erst 
zu lesen, dann aber gerne auch zu schreiben. RFM22 deshalb, weil 
CC110x-Module für 868 MHz ziemlich rar sind, die RFM22 dagegen für 5-6,- 
€ gut verfügbar sind.

Inzwischen habe ich festgestellt, dass meine Probleme weniger mit dem 
verwendeten AskSin-Protokoll als vielmehr mit "Verständnisproblemen" 
zwischen dem CC110x und dem RFM22b zu tun haben, daher mache ich dafür 
mal einen neuen Thread auf.

Größtes Problem ist das data whitening. Laut Datenblatt gibt es bei 
beiden Chips die Möglichkeit, die 0/1-Verteilung der über Funk 
gesendeten Daten durch XOR-Verknüpfung mit einem Pseudo-Random-Code 
etwas gleichmäßiger zu gestalten. Der XOR-Schlüssel wird aus einem 
9-Bit-Startwert erzeugt, der Startwert wird zu 0xff + Carry-Bit 
initialisiert. Für den nächsten Schlüssel wird für das Carry-Bit Carry 
und Bit 5 XOR-verknüpft, danach wird der Schlüssel-Wert um ein Bit nach 
rechts verschoben und das alte Carry-Bit in´s MSB. Nach acht Durchläufen 
(entsprechend dem Einshiften der neuen Datenbits in ein Schieberegister) 
steht der nächste Schlüssel bereit, wird per XOR mit den Daten-Bits 
verknüpft und das Ergebnis gesendet.

Da im Modus mit variabler Packet-Länge auch das Längenbyte mit 
übertragen und auch mit in das data whitening einbezogen wird, überträgt 
der CC110x (Länge ^ 0xff). Das führt dazu, dass der RFM22B nur Müll 
empfängt. Schön zu sehen ist das, wenn man am CC110x doppeltes Sync-Word 
aktivert hat, beim RFM22b dagegen als Sync nur 3 & 2 aktiviert. Dann 
müssten die Daten als erste beiden Werte das zweite Sync-Wort enthalten 
(bzw. Länge = Sync-Byte 1 und erstes Daten-Byte = Sync-Byte 0, data 
whitening empfängerseitig deaktiviert). Das passiert aber nicht: das 
Längen-Byte entspricht dem Sync-Byte 1, das erste DAten-Byte ist 
irgendein Wert, der mit den gesendeten Daten nichts zu tun hat.

Dass die Daten korrekt ankommen, kann man überprüfen, indem man beim 
Sync-Word alle 4 Bytes aktiviert: völlig problemlos erkennt das RFM22 
die eingehenden Daten bzw. Sync-Wörter und löst einen entsprechenden 
Interrupt aus.

Bisher konnte ich mir nur so behelfen, dass ich beim RFM22b eine feste 
Paketlänge einstelle und die dann korrekten Daten manuell auseinander 
nehme.

Hat jemand ähnliche Erfahrungen bzw. vielleicht andere Lösungen, die die 
Programmierung auf RFM22-Seite vereinfachen? Da ich zu einem 
existierenden Produkt kompatibel sein möchte, scheidet die Möglichkeit, 
beim CC110x auf das data whitening zu verzichten, leider aus ;-)

Die neueren TRX868-SFX-Module, welche sich in den neuen Heizungsreglern 
finden, verwenden übrigens ebenfalls den SI443x, ELV muss das Problem 
also ebenfalls gehabt - und gelöst! - haben!

Grüße,
Sebastian

[Harald (Gast)]

Zum RFM22 kann ich nicht beitragen, aber vielleicht hilft Dir ein 
günstiges TI Modul (gibt es auch bei ebay)

http://shop.ciseco.co.uk/xrf-wireless-rf-radio-uart-rs232-serial-data-module-xbee-shape-arduino-pic-etc/

Weiterhin hat amber-wireless.de auch zahlreiche TI Module.

[Sebastian V. (voitzsch)]

Hallo Harald,

die RFM-Module sind derzeit vom Preis, von der Größe und der 
Beschaffbarkeit sowie grundsätzlich von der Art der Beschaltung ideal, 
daher würde ich es gerne damit probieren.

Bevor ich auf die RFM22-Module gekommen bin, habe ich schon ziemlich 
ausführlich geguckt, welche preisgünstigen und verfügbaren Module es 
gibt. Die TI-Module von eBay (selbst die aus China mit x Wochen 
Lieferzeit) sind alle für 433 MHz spezifiziert; idR sind sie auch etwas 
größer als die RFM-Teile.

Viele Grüße,
Sebastian

[Harald (Gast)]

Die von mir angesprochenen Module haben selbstverständlich 868MHz, sonst 
hätte ich die wohl kaum verlinkt. Aber man kann natürlich erkennen, dass 
es für Dich keine Alternative zu den RFM gibt.

[Ulli (Gast)]

Sebastian, könntest du schon eine Lösung finden?
Ich stehe vor dem selben Problem....