Hallo, ich versuche derzeit, mit einem RFM22-Modul Homematic-Nachrichten mitzulesen. Wenn ich die Informationen aus dem Datenblatt richtig lese, müsste das gehen (RFM12 geht wegen des fixen Sync-Words nicht, was beim RFM22 aber frei konfigurierbar ist). Ich habe die Schaltung von Ulrich Radig übernommen und die Init-Routine wie folgt angepasst: rf22_write(0x05, 0x02); // valid packed received interrupt on rf22_write(0x06, 0x00); // all interrupts off rf22_write(0x07, 0x01); // operating mode: ready mode rf22_write(0x09, 0x7f); // xtal load capacitance rf22_write(0x0A, 0x02); // uC CLK: 10MHz rf22_write(0x0b, 0xf2); // GPIO0: TX_ANT - f2 rf22_write(0x0c, 0xf5); // GPIO1: RX ANT - f5 rf22_write(0x0d, 0x00); // GPIO2: uC Clock out rf22_write(0x0e, 0x00); rf22_write(0x0f, 0x70); // ADC Input: GND rf22_write(0x10, 0x00); // ADC offset: 0 rf22_write(0x12, 0x00); // temp sensor calibration off rf22_write(0x13, 0x00); // temp sensor offset: 0 rf22_write(0x1C, 0x01); // IF bandwidth rf22_write(0x1d, 0x44); // enable AFC rf22_write(0x1e, 0x0A); // afc timing rf22_write(0x1f, 0x00); // afc timing rf22_write(0x20, 0x90); // Clock Recovery Oversampling Rate rf22_write(0x21, 0x20); // Clock Recovery Offset 2 rf22_write(0x22, 0x51); // Clock Recovery Offset 1 rf22_write(0x23, 0xEC); // Clock Recovery Offset 0 rf22_write(0x24, 0x10); // Clock Recovery Timing Loop Gain 1 rf22_write(0x25, 0x58); // Clock Recovery Timing Loop Gain 0 rf22_write(0x2A, 0x1C); rf22_write(0x2C, 0x28); rf22_write(0x2D, 0x7D); // RSSI Threashold: -120dB rf22_write(0x2E, 0x2A); rf22_write(0x30, 0xAC); // data access: RX/TX packet handling, enable crc: CCIT rf22_write(0x32, 0x80); // header check enable rf22_write(0x33, 0x06); // 2 word synchronisation rf22_write(0x34, 0x08); // preamble length: 16 nibbles, = 64bits rf22_write(0x35, 0x22); // preamble detection control: 6 nibbles = 24bits rf22_write(0x36, 0xE9); // sync word 3 rf22_write(0x37, 0xCA); // sync word 2 rf22_write(0x38, 0xE9); // sync word 1 rf22_write(0x39, 0xCA); // sync word 0 /* rf22_write(0x3a, 'h'); // transmit header 3 rf22_write(0x3b, 'o'); // transmit header 2 rf22_write(0x3c, 'p'); // transmit header 1 rf22_write(0x3d, 'e'); // transmit header 0 rf22_write(0x3e, 0x3d); // packet length rf22_write(0x3f, 'h'); // check header 3 rf22_write(0x40, 'o'); // check header 2 rf22_write(0x41, 'p'); // check header 1 rf22_write(0x42, 'e'); // check header 0 rf22_write(0x43, 0xff); // header enable mask 3 rf22_write(0x44, 0xff); // header enable mask 2 rf22_write(0x45, 0xff); // header enable mask 1 rf22_write(0x46, 0xff); // header enable mask 0 */ rf22_write(0x58, 0x80); rf22_write(0x69, 0x60); // AGC on rf22_write(0x6a, 0x0b); // agc override 2 rf22_write(0x6d, 0x0F); // tx power: +17dBm rf22_write(0x6E,0x51); // set baud high rf22_write(0x6F,0xEC); // set baud low rf22_write(0x70, 0x2D); // modulation control rf22_write(0x71, 0x22); // modulation control 2: FIFO mode, OOK //0x21 / 0x00 rf22_write(0x72, 0x20); // frequency deviation: 45kHz rf22_write(0x73, 0x00); // offset: 0 rf22_write(0x74, 0x00); // offset: 0 rf22_write(0x79, 0x0); // frequency hopping off rf22_write(0x7a, 0x0); // frequency hopping off #ifdef BAND_868 rf22_write(0x75, 0x73); // 860-880MHz range #else rf22_write(0x75, 0x53); // 430-440MHz range #endif rf22_write(0x76, 0x67); rf22_write(0x77, 0xC0); rf22_write(0x7C, 0x09); rf22_write(0x7E, 0x38); Die empfangenen Pakete sollen per RS232 im Hex-Format ausgegeben werden, leider sehe ich nix. Den nIRQ-Pin habe ich lt. Radig-Schaltplan mit PD2 verbunden. Hat jemand dergleichen schon mal gemacht und kennt die richtige Init-Sequenz für das RFM-Modul? Die Werte habe ich der Excel-Tabelle entnommen, die Daten für HomeMatic diversen Foren-Beiträgen sowie den Config-Bytes der culfw. Schönen Sonntag, Sebastian
Hallo, ich bin ein bisschen weiter gekommen: der RFM22 mag es nicht, wenn er die SPI-Daten der Programmierung "mitliest". Dadurch gerät er durcheinander und ist hinterher auch durch einen Software-Reset nicht mehr einzufangen, ich muss das STK500 nach jedem Flashvorgang aus- und wieder einschalten und das ISP-Kabel abziehen, um vernünftig mit dem RFM22 "reden" zu können. Mit den Parametern 868,3 MHz, 20kHz Deviation, 4 Preamble-Bytes, 4 Sync-Bytes (E9 CA E9 CA), kein CRC, kein Manchester, kein Whitening empfange ich schon mal Daten, wenn mein Sender funkt. Allerdings sind diese Daten nicht im Ansatz mit dem überein zu bringen, was ein parallel mitlaufender HM-CFG-USB ausgibt. Den XOR-Code aus der culfw habe ich bereits implementiert, was aber nichts bringt. Außerdem ist schon das Längen-Byte, welches von der XOR-Geschichte ausgenommen ist, "falsch". Nach meinem Verständnis haben nur Manchester-Kodierung und Data-Whitening Einfluss auf die Daten. Manchester wird dabei auch auf Preamble und Sync-Word angewendet. Da ich beim RFM eingestellt habe, dass 4 Sync-Words überprüft werden müssen und ohne korrekt erkanntes Sync-Word der FIFO-Puffer überhaupt nicht gefüllt wird, scheidet Manchester aus. Testweises Aktivieren von Whitening bringt mich auch nicht weiter, die Daten sehen zwar dann "anders" aus, sind aber ebenfalls nicht korrekt. An welchen Stellschrauben könnte ich noch drehen? Sebastian
Sebastian Voitzsch schrieb: > Hallo, > > ich bin ein bisschen weiter gekommen: der RFM22 mag es nicht, wenn er > die SPI-Daten der Programmierung "mitliest". Dadurch gerät er > durcheinander und ist hinterher auch durch einen Software-Reset nicht > mehr einzufangen, ich muss das STK500 nach jedem Flashvorgang aus- und > wieder einschalten und das ISP-Kabel abziehen, um vernünftig mit dem > RFM22 "reden" zu können. Ein Pullup an CS bewirkt bei solchen Phänomenen meist wahre Wunder. Grüße Oliver
:
Bearbeitet durch User
Hat das Problem wer lösen können? Ich versuche es schon länger und ich bekomme auch keine plausiblen daten!
Hallo Ulli, ja, das Problem konnte ich lösen: die Data-Whitening- und CRC-Routinen der Chips sind nicht kompatibel, sodass man beides "zu Fuß" erledigen muss. Ich hänge mal meinen Code an, mit dem ich erfolgreich per RFM22b Homematic-Daten empfangen und senden kann. Leider ist das Projekt bei mir mangels Zeit eingeschlafen. Der Code sollte auf einem Tiny24 laufen und einen Homematic-Schaltaktor mit einem Kanal nachbilden. Die Belegung müsstest Du aus den Kommentaren im Code ersehen können. Die CRC- und Data-Whitening-Routinen befinden sich in rf22.c (get_next_key und calc_crc). Aus irgendeinem Grund habe ich mich damals dagegen entschieden, das Homematic-Encoding auch von "rf22_sendpacket" bzw. "rf22_getpacket" erledigen zu lassen - aber frag' mich nicht mehr, warum... Grüße, Sebastian PS: Wenn Du ein funktionierendes HM-Device realisierst, halt' uns auf dem Laufenden!
:
Bearbeitet durch User
Besten Dank das hilft ungemein. Ich hatte inzwischen schon rausgefunden das das data whtening anders ist und konnte Daten empfangen. Nur senden ging nicht und jetzt weiß ich das es vermutlich am fehlenden CRC liegt!! Besten dank für den code vorerst! Schau ich mir heute abend an. Grüße ulli
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.