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
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!
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.