X10 rf receive / rf_receive.c / raw
327 views
Skip to first unread message
Joerg
Mar 23, 2012, 1:45:37 PM3/23/12
to CUL fans
Hallo zusammen,
ich bin neu zu den cul fans gestossen. Danke an alle die sich hier
einbringen.
Da ich noch einige X10 Komponenten im Einsatz habe die ich
weiterverwenden möchte suche ich eine Möglichkeit die über den cul zu
bedienen. (erstmal nur Empfang).
Dazu betreibe ich den CUL im raw modus (x18) und nähere mich mit einem
Script an die Auswertung.
Zu X10: das rf Signal startet mit einem 9ms RF Träger, 4,5ms Pause und
32 Datenbits.
Wenn ich mir die rf_receive.c anschaue meine ich das der Sync auch
nicht idealisiert abgebildet werden kann. Imho (bin ich da richtig???)
würde der nach 4ms High der Overflow IRQ (Zeile 560/2) aktiv werden
und das hochzählen des Timers gestoppt werden. (?)
Die anschliessende falling edge würde dann in Zeile 666 'c' mit dem
"alten Wert" laden, der Timer würde nicht neu anlaufen. Zeile 700 lädt
die 4000 in die hightime. Nach 4ms würde der Overflow erneut
anspringen und die folgende rising edge des ersten Datenbits würde
dann 0 als lowtime liefern (c - hightime) liefern.
Da kann ich jetzt natürlich auch total danebenliegen ;-) und wäre auch
ganz froh darüber.
Ich würde mich freuen wenn mal jemand mit Ahnung diese Theorie
überprüfen könnte.
Danke schonmal und Grüße
Jörg
ich bin neu zu den cul fans gestossen. Danke an alle die sich hier
einbringen.
Da ich noch einige X10 Komponenten im Einsatz habe die ich
weiterverwenden möchte suche ich eine Möglichkeit die über den cul zu
bedienen. (erstmal nur Empfang).
Dazu betreibe ich den CUL im raw modus (x18) und nähere mich mit einem
Script an die Auswertung.
Zu X10: das rf Signal startet mit einem 9ms RF Träger, 4,5ms Pause und
32 Datenbits.
Wenn ich mir die rf_receive.c anschaue meine ich das der Sync auch
nicht idealisiert abgebildet werden kann. Imho (bin ich da richtig???)
würde der nach 4ms High der Overflow IRQ (Zeile 560/2) aktiv werden
und das hochzählen des Timers gestoppt werden. (?)
Die anschliessende falling edge würde dann in Zeile 666 'c' mit dem
"alten Wert" laden, der Timer würde nicht neu anlaufen. Zeile 700 lädt
die 4000 in die hightime. Nach 4ms würde der Overflow erneut
anspringen und die folgende rising edge des ersten Datenbits würde
dann 0 als lowtime liefern (c - hightime) liefern.
Da kann ich jetzt natürlich auch total danebenliegen ;-) und wäre auch
ganz froh darüber.
Ich würde mich freuen wenn mal jemand mit Ahnung diese Theorie
überprüfen könnte.
Danke schonmal und Grüße
Jörg
Rudolf Koenig
Mar 23, 2012, 2:23:41 PM3/23/12
to cul-...@googlegroups.com
> Zu X10: das rf Signal startet mit einem 9ms RF Tr�ger, 4,5ms Pause und
> 32 Datenbits.
> 32 Datenbits.
Der SlowRf Parser in culfw erwartet mind. 4 gleiche "bits" (0-er?) gefolgt von
einem eins (== andersartig). Dann irgendwelche Bitfolge, und dann mind 4ms
Pause. -> Nicht kompatibel mit der o.g. Bitfolge.
Man kann natuerlich einen anderen Parser bauen fuer X10. Oder eine Idee haben,
wie man es in dem existierenden integriert... :)
Gruss,
Rudi
Joerg
Mar 26, 2012, 5:39:40 AM3/26/12
to CUL fans
Hallo Rudi,
2 Optionen ... schaun wir mal. :)
Da ich ein CUL Newbie bin stelle ich mir aber gerade die Frage ob die
Firmware "weiss" ob sie auch einem 433 oder 868 cul läuft.
Und ob die FW den CC1101 auch gleich entsprechend tuned ? Oder muss
ich das, quasi von Hand, in die entsprechenden Register
schreiben. ... ?
zur Klarstellung; ohne FHEM, also nur mit einem Terminal...
Danke und Grüße
joerg
2 Optionen ... schaun wir mal. :)
Da ich ein CUL Newbie bin stelle ich mir aber gerade die Frage ob die
Firmware "weiss" ob sie auch einem 433 oder 868 cul läuft.
Und ob die FW den CC1101 auch gleich entsprechend tuned ? Oder muss
ich das, quasi von Hand, in die entsprechenden Register
schreiben. ... ?
zur Klarstellung; ohne FHEM, also nur mit einem Terminal...
Danke und Grüße
joerg
Rudolf Koenig
Mar 26, 2012, 6:23:51 AM3/26/12
to cul-...@googlegroups.com
> Firmware "weiss" ob sie auch einem 433 oder 868 cul l�uft.
Ja, ein pin der MCU ist anders gesetzt.
> Und ob die FW den CC1101 auch gleich entsprechend tuned ?
Ja.
Joerg
Mar 26, 2012, 7:44:15 AM3/26/12
to CUL fans
ah, in der c1100.c auch gefunden. Dankeschön.
Ausserdem ist mir aufgefallen das der 1100 ohne rf Träger viel weniger
Rauschen liefert als ich annehmen würde.
Findet da in der slow rf Betriebsart eine art Filterung statt ? Wenn
ja; was ist denn (in etwa) die minimale mark und space zeit ?
Grüße
jörg
Ausserdem ist mir aufgefallen das der 1100 ohne rf Träger viel weniger
Rauschen liefert als ich annehmen würde.
Findet da in der slow rf Betriebsart eine art Filterung statt ? Wenn
ja; was ist denn (in etwa) die minimale mark und space zeit ?
Grüße
jörg
Rudolf Koenig
Mar 26, 2012, 7:52:41 AM3/26/12
to cul-...@googlegroups.com
> Ausserdem ist mir aufgefallen das der 1100 ohne rf Tr�ger viel weniger
> Rauschen liefert als ich annehmen w�rde. Findet da in der slow rf
> Betriebsart eine art Filterung statt ? Wenn ja; was ist denn (in etwa) die
> minimale mark und space zeit ?
> Rauschen liefert als ich annehmen w�rde. Findet da in der slow rf
> Betriebsart eine art Filterung statt ? Wenn ja; was ist denn (in etwa) die
> minimale mark und space zeit ?
Filter? Wie, Filter... Ich verstehe nur Bahnhof :)
Evtl. hilft Dir das Durchlesen der cc1101.pdf von TI, und das Nachschlagen der
eingestellten Registerwerte. Culfw filtert nur Nachrichten ohne ausreichende
Sync-Bits bzw. unerkannten/falschen Checksum, aber das duerfte Dich nicht mehr
interessieren.
Joerg
Dec 29, 2012, 6:35:07 AM12/29/12
to cul-...@googlegroups.com
Hallo zusammen,
Wahnsinn wie die Zeit vergeht - ich hoffe alle hatten ein gutes Fest.
Unter dem Jahr konnte ich leider nur wenig Zeit investieren, die Feiertage und der Resturlaub sind jetzt willkommen ;).
Stand jetzt habe ich die Firmware des CUL modifiziert, der sendet jetzt binär gepackt die High and Low Pulsdauern eines getasteten RF Signals. Ziel ist ja die Dekodierung der Nachrichten nach FHEM zu verlagern um weitere Protokolle einfach abbilden zu können.
Mein Proof of Concept in Java funktioniert ganz leidlich - X11 RF, Elro und einige Senoren sind zu identifizieren.
Jetzt stehe ich allerdings völlig auf dem Schlauch wie ich das in FHEM einbaue, vielleicht kann ja der eine oder andere erfahrene Mitleser mit Hinweisen helfen, konkret:
- gibt es so was wie ein Grundgerüst für ein "plugin" auf das ich aufbauen kann ?
- FHEM hat die Logik für das lesen des USB Ports ja eingebaut, wie hänge ich mich da dran ?
- Werden die Daten asyncron geliefert oder muss ich pollen ? Wenn ja, wie (Timer etc). Best practice ?
- Wohin und in welchem Format liefere ich die Nachrichten an FHEM damit FHEM damit weiterarbeiten kann ?
- in welche Quellfiles kann ich mich einlesen, zeitsparend ;-) ?
Danke und viele Grüße
Jörg
Wahnsinn wie die Zeit vergeht - ich hoffe alle hatten ein gutes Fest.
Unter dem Jahr konnte ich leider nur wenig Zeit investieren, die Feiertage und der Resturlaub sind jetzt willkommen ;).
Stand jetzt habe ich die Firmware des CUL modifiziert, der sendet jetzt binär gepackt die High and Low Pulsdauern eines getasteten RF Signals. Ziel ist ja die Dekodierung der Nachrichten nach FHEM zu verlagern um weitere Protokolle einfach abbilden zu können.
Mein Proof of Concept in Java funktioniert ganz leidlich - X11 RF, Elro und einige Senoren sind zu identifizieren.
Jetzt stehe ich allerdings völlig auf dem Schlauch wie ich das in FHEM einbaue, vielleicht kann ja der eine oder andere erfahrene Mitleser mit Hinweisen helfen, konkret:
- gibt es so was wie ein Grundgerüst für ein "plugin" auf das ich aufbauen kann ?
- FHEM hat die Logik für das lesen des USB Ports ja eingebaut, wie hänge ich mich da dran ?
- Werden die Daten asyncron geliefert oder muss ich pollen ? Wenn ja, wie (Timer etc). Best practice ?
- Wohin und in welchem Format liefere ich die Nachrichten an FHEM damit FHEM damit weiterarbeiten kann ?
- in welche Quellfiles kann ich mich einlesen, zeitsparend ;-) ?
Danke und viele Grüße
Jörg
Joerg
Dec 30, 2012, 3:09:32 PM12/30/12
to cul-...@googlegroups.com
Erledigt - falsches Forum. Das fhem Wiki hat ein Developer Bereich
Danke
Reply all
Reply to author
Forward
0 new messages