culfw Erweiterung G - sendraw

[fichtennadel]

Hallo,

bei meinen Arbeiten am BelFox Handsender (http://forum.fhem.de/index.php/topic,36810.msg291267.html) bin ich ja zuerst vom fixen Schema des G Befehls ausgebremst worden.
Da ich aber auf die Schnelle wissen wollte, ob ich das Signal überhaupt korrekt verstanden habe, habe ich dann mit pilight-send raw die Signalfolge direkt erzeugt: hier kann man einfach nach der Reihe die Timings in High / Low und die Pause angeben, der Befehl sendet dann 10 Mal. Beispiel hier: http://wiki.pilight.org/doku.php/pdebug

Jetzt wäre meine Idee, diese Funktionalität auch in culfw zu ermöglichen, indem man den G Befehl wie folgt erweitert:
GxpprNNMM...NNMM
x ... Buchstabe 'x' oder 'X', dient zur Unterscheidung zur bisherigen G Funktionalität
      x = Kodierung eines Bits in low/high
      X = Kodierung eines Bits in high/low
ab hier in hex:
pp ... Pause in ms (2 Stellen, damit auch längere Pausen möglich sind)
r ... Anzahl Wiederholungen
NN ... Zeit für den ersten Teil (abhängig von x ob high oder low), in 16us
MM ... Zeit für den zweiten Teil (abhängig von x ob high oder low), in 16us
NNMM können jetzt mit beliebigen Werten wiederholt werden, somit kann man sich ein Signal fast nach Belieben erstellen

Beispiel: Gx0f43e7d7d3e für 4x "low 1000us high 2000us low 2000us high 1000us" mit 16ms Pause dazwischen.

Sinnvoll? Brauchbar? Würde in die Standard culfw integriert werden?

Falls ja, könnte ich das implementieren.

Viele Grüße,
Georg

[rudolfkoenig]

Dein Vorschlag ist sehr BelFox spezifisch, und ignoriert in x-Fall die ss/N/n Angaben (siehe culfw Doku).

Vermutlich ist N ueberfluessig (bzw. kann man errechnen), und ss kann man in den Datenstrom integrieren.
Fuer n habe ich aber keine Loesung.

[fichtennadel]

Dein Vorschlag ist sehr BelFox spezifisch, und ignoriert in x-Fall die ss/N/n Angaben (siehe culfw Doku).

Eigentlich wollte ich das gerade eben nicht xyz-spezifisch, sondern universell einstetzbar, aber vielleicht bin ich auch gerade betriebsblind.

Ich denke, ss/N/n benötigt man bei meinem Vorschlag nicht mehr, da man die Syncbits in die NNMM kodiert und Bytes und Rest-Bits gibts in diesem Sinn auch nicht mehr, da einfach alle NNMM gesendet werden, bis sie aus sind, egal ob sie in 8er Blöcken sind oder nicht.

Auf die Idee hat mich eben dieses pilight-send raw gebracht, das erzeugt zB aus
"286 2825 286 201 289 1337 287 209 283 1351 11302" ein Signal, das 286us high, 2825us low, 286us high 201us low usw. sendet und nach der letzten Flanke die restliche Zeit bis auf 11302us pausiert.
Und das wäre die Idee auch in der culfw einzubauen.

Damit könnte man jedes beliebige, vorab bekannte OOK Signal erzeugen und müsste auch nicht mehr für jedes Sendeprotokoll eine eigene Funktion implementieren.

Oder stelle ich mir das gerade zu einfach vor?

[rudolfkoenig]

Sorry, ich hab dein Text nicht aufmerksam genug gelesen.
Das Problem mit dieser sehr flexiblen Loesung ist, dass es zu schnell die vorhandene Input-Laenge sprengt.
Auf dem CUL_V3 ist TTY_BUFSIZE 128, d.h. du koenntest (128-4)/4 == 31 Bits (<4Bytes) senden, ich meine das ist zu wenig.
FS20 z.Bsp. braucht 11+5*9 = 56 bits, S300/EM/ESA sind deutlich laenger.