UNKNOWNCODE sniffen und "unbekanntes" Gerät (28-key RF Controller) schalten

[lichtimc]

Mach ich heute Abend. Ich danke dir für die Analysen-Hilfe... 

Memo an mich (und eventuell andere mitlesende):
r416f1712: entspricht kurz lang, also Bit 0
r1664f464: entspricht lang kurz, also Bit 1

Übrigens hab ich hier noch den culfw RAW Command Generator gefunden. Damit lässt sich der raw-Wert, der zu senden ist, noch ein bisschen leichter berechnen: culfw_raw_comm_gen.png

Und das dürfte auch eine große Hilfe sein um direkt mit dem CUL Analysen von Funkprotokollen durchzuführen...

[KölnSolar]

Nett der RAW Command Generator. Und ich mach immer alles zu Fuß. Hält aber geistig fit 

Allerdings gibt es das Byte Final High G0130C31A68681A1A580008 irgendwie gar nicht in der commandref. Und ich könnt schwören, dass ich den G-Befehl funktionierend eingesetzt habe. Ist aber schon länger her.....

[lichtimc]

Aja... muss ich diesen FinalHigh-Parameter nun weglassen oder nicht? Und wenn nicht welchen Wert hat er? Auch 420?

Jetzt hab ich das hier noch gefunden: Abweichung zw. culfw reference, culfw Verhalten und rawcmd Generator

...
Dabei ist mir aufgefallen, dass:

• die culfw ref
• die CUL FW (1.66)
• der culfw Raw Command Generator (rawcmd.html)

nicht ganz zusammen zu passen scheinen.

Der "Raw Command Generator" hat ein label "Final high". Dieses sorgt dafür, dass ein zusätzliches DatenByte in den String übernommen wird, welches auch als Datum con der CUL FW gesendet wird. Wenn man dieses Label im .html entfernt passt es wieder. Evtl. ist dieses Byte früher mal als Parameter verwendet worden.

Also nehme ich an, ich muss dieses FinalHigh-Byte wieder entfernen, wenn ich den RAW Command Generator verwenden will...

Was sind eigentlich diese "broken bits" und wie spiegeln sich diese in meinem Funkverkehr wieder? ("Number of bits in the last byte" ist bei mir ja 0, würde lt. Dirk1975 aber bedeuten, dass 7 Bits gesendet werden...)

Die culfw reference doku verstehe ich so, dass "N" die Anzahl aller "ganzen" zu sendenen Bytes darstellt, und "n" die Anzahl der übrig geblieben Bits. So generiert auch der "culfw Raw Command Generator" den command string.
Die culfw allerdings (sendraw in rf_send.c) erwartet als Parameter (bitoff) die Bitposition, ab der keine Bits mehr gesendet werden soll (inkl. dieser Position).
Beispiel:
0: Bits[7:1] werden gesendet
1: Bits[7:2] werden gesendet
6: Bit[7] wird gesendet
7: keine extra Bits werden gesendet

[KölnSolar]

was auch immer Dirk meinte, meine Interpretation: das broken byte ist das letzte Datenbyte. Broken aber deshalb, weil nicht alle 8 bits gesendet werden sollen, sondern nur n bits. So hat man sich aus der Affäre gezogen in der Syntax byteweise zu deklarieren, aber nicht vollständig zu senden, sofern es eben N*8 + n bits mit n#0 zu senden gilt.
Edit: ich vermute, ich weiß jetzt was Dirk meinte: die bits des broken bytes werden um n verschoben, also muss man lsb eintragen und nicht hsb. Er hat nur den verwirrenden Fehler gemacht, den index des bit-arrays bei 1 beginnen zu lassen anstatt 0.

Ich hab auch wieder "mein" raw-command gefunden: G00407F57241960   87a97a2c(data), also ohne finalhigh

Hier bei Lust und Laune mal meinen "leidvollen" Weg nachlesen

[lichtimc]

G0130C31A68681A580008 geht auch nicht... 
Ich hab einen Logic Analyzer. Wo am CC1101 müsste ich den anschließen um die Impulse genau mitloggen zu können?

[KölnSolar]

ist der GDO0 (glaub ich). Letztendlich bekommst da aber auch nicht mehr. nur schöner

Mich verwirrt noch, dass die culfw im debug-mode einen Faktor 3 auswirft, während die Protokollanalyse Faktor 4 ergibt 

Kannst Du nochmal X1e anschmeißen. Aber nur mit kurzem Tastendruck wg. repetition rate. Und dann alles, also auch alle Wiederholungen, wieder in Deiner 4-Spalten-hex-bildform(gefällt mir) posten.

[lichtimc]

Nur wenn ich länger auf der Taste bleibe erhalte ich schöne gleichmäßige Signale: long_press.png
Wenn ich nur einmal kurz drücke schauts so aus: short_press.png

[KölnSolar]

da kann ich jetzt nicht so richtig viel mit anfangen. 

Nur wenn ich länger auf der Taste bleibe erhalte ich schöne gleichmäßige Signale: long_press.png
Wenn ich nur einmal kurz drücke schauts so aus: short_press.png

Die Aussage macht mich aber arg stutzig und wenn ich mir den short press angucke, findet man in der ersten Hälfte erstaunlich oft u. regelmäßig efbfed(ca. 250 sek !)  als Pulsweite für ein low signal.  Das müsste man doch auch im Log am Datum/Zeitstempel erkennen können
Spekulation: Das Datentelegramm ist viel länger als bisher angenommen und besteht aus 2 Teilen. Der erste Teil wird nur einmal gesendet. Es schließt sich der 2. Teil an, der dann bei long press x-fach wiederholt wird ?
Kannst Du fremde Sender ausschließen ? Man bräuchte wirklich mal einen Extrakt, wo man mehrmals die gesamten Daten eines short press erkennt. Du könntest mal bei raw X1E in den event monitor gucken, um ein Gefühl zu entwickeln. Oder mal ein file mit dem Original-Log-Extrakt einstellen.

[lichtimc]

Heißt das, immer wenn efbfbd im Log vorkommt, war 250 Sekungen lang Funkstille? Wie komme ich zu diesen ganzen Bedeutungen von Bitfolgen?
Im Log war das eine Zeile... kann es sein, dass der CUL ab Setzen von X1e und dem ersten Log mehr anzeigt, als eigentlich da ist? (Buffer oder so??)
Ich überprüfe heute Abend mal, ob wirklich bei jedem kurzen Druck diese Zeichenfolgen vorkommen.
Und nein, fremde Empfänger kann ich nicht ausschließen... mit X1e kommt immer wieder mal was fremdes dazwischen...

[KölnSolar]

Heißt das, immer wenn efbfbd im Log vorkommt, war 250 Sekungen lang Funkstille?

Na ja, das sagen die Hex-Zahlen hinter dem f. Ob das wirklich so ist, kann ich nicht sagen. Dann würde das aber sicherlich in einer neuen Zeile mit neuem timestamp im Log stehen.

Wie komme ich zu diesen ganzen Bedeutungen von Bitfolgen?

Was meinst Du ? Die 250 sek. ? hex in dec *16 sind die µs.

Im Log war das eine Zeile... kann es sein, dass der CUL ab Setzen von X1e und dem ersten Log mehr anzeigt, als eigentlich da ist? (Buffer oder so??)

Schließe ich aus.

[lichtimc]

Inzwischen habe ich die Erkenntnisse dieses Threads in Form eines Blog-Beitrags zusammengefasst!


Ich habe nun direkt an der Fernbedienung den Logic Analyzer angehängt. Das ist dabei rausgekommen:
Tastendruck.png: Ein ganzer Tastendruck mit den Bits 100010000000000100001100 (88010C) (auch im fhem-log i88010C)
Timing.png: Der obere Streifen zeigt die Pause zwischen den einzelnen Paketen, wenn ich auf der Taste drauf bleibe, der mittlere Streifen ist ein Bit (ein 1er) und der untere zeigt das kurze High vor der Pause (, das ein klein wenig länger ist, als die, die im Paket sind)

Auch wenn ich nur kurz drücke kommt im Logic Analyzer genau diese Bitfolge. Nur der CUL misst beim ersten Paket oft irgendwas...
Und bitte nicht wundern über die Werte die rauskommen (88010C). Das ist die zweite Fernbedienung der selben Bauart, die dabei war. Ich hab diese auseinandergenommen weil ich die sowieso nie brauchen werde und die erste wollte ich nicht kaputt machen.

Mit raw G0036c51b4b4b1b880109 funktionierts... 
Ganz richtig ist G0036c51b4b4b1b88010900, denn:

Ich habe mich grade mit folgendem beschäftigt:
raw GssNnprHHLLhhllDDDD:
N Number of data bytes (exclusive the last byte if it is not complete)
n Number of bits in the last byte

Dabei bin ich, wie schon Dirk, auch auf die fehlerhafte Doku im Bezug auf n (Number of bits in last byte) aufmerksam geworden.
Der Parameter n ist nicht die Anzahl der Bits im (zusätzlichen unvollständigen) letzten Byte, sondern die Position ab der keine Bytes mehr gesendet werden.
Da in meinem Fall genau 3 Bytes und ein Bit gesendet werden müssen, muss ich n=6 verwenden. Damit werden N=3 Bytes und vom letzten Byte nur 1 Bit gesendet.
Hätte ich kein 25. Bit müsste ich n=7 verwenden (nicht n=0!).

Zusätzlich wäre es für mich noch hilfreich gewesen, wenn erklärt wäre, wo ich dieses letzte Bit definieren muss: Nämlich am Ende von DDDD.
Das heißt: Ich gebe an, dass ich 3 Datenbytes zu senden habe, gebe aber in Wirklichkeit 4 Bytes an und definiere mit n was von diesem 4. Byte gesendet werden soll. Wenn man kein 4. Byte angibt, nimmt CUL automatisch 00.

Ich würde also die culfw-reference folgendermaßen abändern:

GssNnprHHLLhhllDDDD...
Send raw data, only if HAS_RAWSEND is enabled.
Everything after the command G is hex.
ss Number of sync bits. Sync is always 0, followed by exactly one 1-bit.
N Number of data bytes (exclusive the last byte if it is not complete)
n incomplete last-byte: LSB-Position (7=first bit) after which no more bits will be transferred (7-n = Number of bits in the last byte)
p Number of ms pause between repeats
r Number of repeats (e.g. FS20: 3)
HH High-Time for the 0-bit, Unit is 16us (!)
LL Low- Time for the 0-bit, Unit is 16us (!)
hh High-Time for the 1-bit, Unit is 16us (!)
ll Low- Time for the 1-bit, Unit is 16us (!)
DDDDD... Databytes (inclusive the last byte, that is incomplete, if there is one, else use n=7 and omit this byte)
See also X04 (loggt bei mir gar nichts, heißt: "Bit 2: Report detailed data, even with wrong parity / checksum." aktiviert.)
Use X67 and X1E to find your rawsend-pattern.

[KölnSolar]

D.h. mein ursprünglicher Vorschlag G0130C31A4E4E1A580008 müsste mangels syncbit und 1 weiteren bit so funktionieren:
G0036C31A4E4E1A58000800

Toll, dass Du Dich da durchgequält hast 

Für eine Änderung der Doku müsste sicherlich Rudi ran.

[lichtimc]

Ich danke euch (vor allem dir, Markus) für die Zeit, die ihr euch genommen habt um mich anzuleiten.  Ich hätte nicht gewusst, wo ich beginnen soll...

Kann das hier jemand vervollständigen? Außerdem passt das nicht mit der Doku zusammen... (Ich hab die Fehler rot markiert...)

raw X67 log: (meine FB)
p 7    State of the state machine (?)
400    zhi
1232      zlo
1152      ohi
464      olo
400      ?
1216      ?   
24      ?
1      NSYNC Number of 0 sync bits
3      NBYTE Number of whole bytes received
0      Nbit Number of bits (last partial byte)
400      ?
12288   ?
0      ?      
3D      RSSI
580008   Raw data with parity/checksum(, where is my last incomplete byte)

Wenn der rot markierte 1er und 0er überhaupt NSYNC und NBIT sind, dann sind sie vertauscht...

[juergs]

Alternative?

[lichtimc]

Für eine Änderung der Doku müsste sicherlich Rudi ran.

Und will der Rudi nicht ran , oder müsste ich ihn irgendwie informieren? (Wenn ja, wie denn?)