Revolt NC-5461

[mehf]

Hallo,

ich versuche gerade das Funkprotokoll für revolt-Energierkostenmeßgeräte in die CUL Firmware zu integrieren.
Die Analyse der Funksignale ergab dabei folgendes:
- OOK Modulation 433.92MHz
- Sync: 10ms high; 345us low
- 1-Bit: 260us high; 220us low
- 0-Bit: 130us high; 220us low
- am Ende der Übertragung erfolgt ein low von 29ms
- übertragen werden dabei 12byte + 7bit
- davon 11 byte Nutzdaten
- byte 12 ist eine Prüfsumme: untere 8bit der Summe über alle 11byte
- die letzten 7bit scheinen auch eine Art Prüfsumme zu - konnte ich aber noch nicht entschlüsseln.
- die ersten beiden bytes scheinen eine ID zu beschreiben
- das sieht dann in etwa so aus:
70 6a df(223V) 0001(0.01A) 32( 50Hz) 0011(  1.7W) 64(1.00Pf) 156f( 54.87kWh) e5(ok) 74  sum: e5

Die erste Implementierung habe ich bereits in den cul-Code eingebracht - ich kämpfe allerdings noch ein wenig mit der Empfangsqualität. Ich habe die Datenrate auf 5,6k (~doppelte Datenrate) erhöht, was bereits einiges gebracht hat. Gibt es noch irgendwelche Tricks, oder Parameter, die man anpassen könnte? Macht es vielleicht Sinn, während der Synchronisierung die Datenrate des CC1101 anzupassen? Wie kommen die anderen Protokolle mit der erhöhten Datenrate zurecht?

Weiterhin fehlt mir noch die Interpretation der letzten 7bit - kann mir jemand weiter helfen?

Ansonsten würde ich den Code gerne zur Verfügung stellen... - Hab' auch noch was zum Empfang des IT Protokolls. Wie funktioniert das hier so? (Hab' noch nie mit svn gearbeitet)

[rudolfkoenig]

Das "normale" rf_receive.c (Verantwortlich fuer SlowRF) erwartet im Sync das gleiche 0/1 Muster wie in den Daten, das scheint hier aber nicht der Fall zu sein, ich vermute deswegen, dass Du das Protokoll nicht in rf_receive.c implementiert hast.

Mitglieder der SlowRF Familie (hier wird alles in der MCU dekodiert) haben eine Datenrate von 1kHz, und selbst hier muss ich mit der Ungenauigkeit der CC1101 Meldungen (+/- 50us) kaempfen, die (nicht vorhandene :) Geschwindigkeit der MCU ist eigentlich kein Problem. Wenn ich mich recht erinnere, die Datenrate zu aendern hat mir nicht geholfen bessere Daten zu bekommen.

Alle anderen Protokolle (HM/MAX/RWE:10kHz, FastRF:250kHz) verwenden die Paketfunktionen der CC1101.

> Wie funktioniert das hier so? (Hab' noch nie mit svn gearbeitet)

Die ersten Version(en) hier posten, und wenn alles ok ist, dann gibt es einen SVN Zugang.
SVN Einleitungen bitte im Netz suchen, den Code auschecken kann jeder.

[mehf]

Doch ich hab' das Protokoll in rf_receive.c implementiert. Ich wollte eigentlich den Code für die Bit-Erkennung (STATE_COLLECT) wieder verwenden, hab dann aber doch STATE_COLLECT_REVOLT hinzugefügt.

Bei den ersten Versuchen habe ich mit den Standard Einstellung des CUL gearbeitet und mich gewundert, dass ich praktisch null saubere Signale bekam. Erst als ich die Datenrate auf 2,8k, dann auf 5,6k (hab in einem TI Forum gelesen, dass das sinnvoll wäre) gesetzt hatte, konnte ich korrekte Bitfolgen erkennen. Ich würde denken, dass eine Optimierung dieser Parameter (auch für andere slowRF Protokolle) noch einiges bringen könnte. Deswegen meine Idee die Parameter dynamisch anzupassen.

Die Paketfunktion der CC1101 würde - wenn ich das richtig im Kopf hab' - diese Art der Signale nicht erkennen können, oder?

Den Code muss ich noch etwas "aufhübschen" - enthält noch zu viel hack-debug-müll... folgt aber demnächst.

[rudolfkoenig]

> Erst als ich die Datenrate auf 2,8k [...] gesetzt hatte, konnte ich korrekte Bitfolgen erkennen.

Das ist klar, "deine" Bitrate entspricht ungefaehr 2.4kHz.


> Ich würde denken, dass eine Optimierung dieser Parameter (auch für andere slowRF Protokolle) noch einiges bringen könnte.

Wie geschrieben, ich habe das ohne Erfolg getestet. Da CUL+SlowRF inzwischen in mehreren tausend Faellen eingesetzt wird, reicht mir ein Verdacht nicht, ich benoetige aussagekraeftige Tests.


>  Die Paketfunktion der CC1101 würde [...] diese Art der Signale nicht erkennen können, oder?

Nein, unter anderem weil die Sync-Bitfolge nicht konfigurabel ist.


> Den Code muss ich noch etwas "aufhübschen" [...] folgt aber demnächst.

Bitte beim Patch daran denken, dass es sauber vom Rest getrennt, und optional uebersetzbar ist.

[mehf]

...hier mal eine erste Version des Codes für die Erweiterungen Revolt ('r') und Intertechno ('i').

[mehf]

okay, das "optionale Übersetzen" muss ich noch einbauen.

[mehf]

So, ich hab jetzt alle Codeteile entsprechend mit HAS_IT bzw. HAS_REVOLT geklammert. Die Erweiterungen an TIMER1_COMPA_vect und die Verbreiterung von lowtime,hightime um die langen Pulse zu messen habe ich allerdings nicht geklammert - ich hoffe das geht in Odnung.

Weiterhin würde ich mir noch gerne eine Funktion zum schreiben von CC1101 Registern wünschen (um z.B. einfach die Datenrate ändern zu können). Habe bei mir folgendes implementiert:
void wccreg(char *in)
{
  uint8_t reg,val, out;

  if(fromhex(in+1, &reg, 1) && fromhex(in+3,&val,1)) {
    cc1100_writeReg(reg,val);

      out = cc1100_readReg(reg);
      DC('C');                    // prefix
      DH2(reg);                    // register number
      DS_P( PSTR(" = ") );
      DH2(out);                  // result, hex
      DS_P( PSTR(" / ") );
      DU(out,2);                  // result, decimal
      DNL();
    }
}

und auf das Kommando 'c' gelegt - dies ist ja aber nun eigentlich schon belegt und würde noch einen neuen "Namen" brauchen.

[rudolfkoenig]

> Die Erweiterungen an TIMER1_COMPA_vect

Wenn Du das mit allen SlowRF Protokollen gegengetestet hast, vielleicht :) Aber selbst dann haette ich bedenken, dass die 10x laengeren Timeouts in manchen Situationen den Empfang verschlechtern.
IT & REVOLT sind 433MHz Protokolle, die beim 868MHz (was > 95% der Leute verwenden) keine Rolle spielt,
und ich will nicht deswegen Empfangsqualitaet (eh ein heikles Thema) dafuer opfern.


> und die Verbreiterung von lowtime,hightime

Das ist nur "halb" durchgefuehrt, da wave_t auch hightime & lowtime speichert.
Ich mache mir noch sorgen, dass dann fuer den CUL_V2 kein RAM bleibt.


Meiner Ansicht nach ist eine Kopie von rf_receive.c (rf_receive433.c) die richtige Loesung, die man alternativ zu rf_receive.c uebersetzt (siehe Devices/CUL/Makefile): ich brauche mir keine Sorgen mehr wg. Kompatibilitaet zu machen, und du kannst ohne Sorge fuer andere alles testen. An Protokollen muesste rf_receive433.c nur S300, IT und REVOLT unterstuetzen, der Rest (FHT/FS20/EM/ESA) ist eh 868MHz only.
Den gemischten Betrieb (433&868 gleichzeitig) halte ich fuer einen Irrweg.


> Weiterhin würde ich mir noch gerne eine Funktion zum schreiben von CC1101 Registern wünschen

Gibt es schon: EEPROM schreiben (W), und Empang aktivieren.

[mehf]

> Die Erweiterungen an TIMER1_COMPA_vect

Der Timeout bleibt weiterhin wie bisher erhalten (SILENCE). Nachdem der Interrupt dann ausgeführt wird, wird er ja deaktiviert und der Timer würde weiterhin bei SILENCE == 4000 umbrechen. Da ich im Sync Zeiten >10000 brauche setzte ich das Time-Compare Register entsprechend hoch damit kein rücksetzen (in diesem Zeitraum) mehr passiert. Da der Timer dann gerade 4000 erreicht hatte und auf 0 gesetzt wurde, setze ich ihn nochmal auf 4000. => Das funktionale Verhalten bleibt eigentlich komplett erhalten, außer dass nun Zeiten größer 4000 gemessen werden können.

> und die Verbreiterung von lowtime,hightime

Die Verbreiterung brauche ich ja nur für den aktuellen Pulse, um entsprechend einen sync-Pulse zu erkennen. Alle anderen Daten können bei 8-bit bleiben.

=> Du hast aber Recht und man sollte kein Risiko eingehen mit den Änderunen irgendetwas kaputt zu machen. Ich werde also auch diese Codeteile optional machen. Über rf_receive433.c denke ich noch mal nach: befürchte das man dann auch einen hohen Anteil an Copy&Paste Code hat. Hab übrigens bei mir das FS20 Protokoll auf 433MHz laufen, um die Betty (einfach) zu integrieren...

> Gibt es schon: EEPROM schreiben (W), und Empang aktivieren.
Ist der Umweg übers EEPROM - gerade bei vielen Änderungen - auf Dauer nicht auch sehr belastend fürs EEPROM?

[rudolfkoenig]

> befürchte das man dann auch einen hohen Anteil an Copy&Paste Code hat.

Stimmt, aber dieser Code wird kaum noch geaendert.

> Ist der Umweg übers EEPROM - gerade bei vielen Änderungen - auf Dauer nicht auch sehr belastend fürs EEPROM?

Fuer den Empfang sollte dieser Parameter doch nur einmal verstellt sein.
Beim Entwickeln sollte es kein Problem sein, laut Spec ist das EEPROM fuer 100.000 Schreibzyklen ausgelegt.

[mehf]

Da fh168 mit der 868MHz CUL Variante bereits gute Ergebnisse erzielt hat, habe ich den Code in rf_receive.c belassen. Dieser ist nun aber vollständig abschaltbar.
Für die letzten 7bit fehlt zwar noch die Interpretation, aber da es sich wohl "nur" um eine weitere Prüfsumme handelt, kommt man wohl erstmal auch ohne aus.

[rudolfkoenig]

Habs eingecheckt.