SIGNALDuino Empfänger Firmware V 3.3.2r-dev

Begonnen von Ralf9, 07 Januar 2018, 21:37:44

Vorheriges Thema - Nächstes Thema

Ralf9

ZitatIch kann zum Testen noch vom signalduino rawmsg von ITv3 für on und off gebrauchen.
Hat sich inzwischen erledigt, ich habe die rawmsg erhalten.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

pejonp

Hallo Ralf,

vielleicht kannst du mir weiterhelfen. Ich habe mir vor Jahren eine Beleuchtung (Weihnachtskugel) mit einem ATiny13a zusammengebaut. (http://danyk.cz/avr_rdo_en.html)
Ich konnte diese letztes Jahr auch noch mit dem Signalduino schalten. Jetzt geht es nicht mehr (version: V 3.3.1-experimental SIGNALduino - compiled at Jun 16 2019 00:08:41)
Beim senden des Strings


W433:.* set SIGRBX raw SR;;R=3;;P0=419;;P1=-230;;P2=105;;P3=-1104;;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;;


wird das im Log angezeigt. ??


2019.12.01 17:33:52.084 4: SIGRBX/keepalive ok, retry = 0
2019.12.01 17:33:53.554 4: set SIGRBX raw SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:53.555 5: AddSendQueue: SIGRBX: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121; (1)
2019.12.01 17:33:53.658 5: SIGRBX SW: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:53.669 4: SIGRBX SendrawFromQueue: msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:53.718 4: SIGRBX/msg READ: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.718 5: SIGRBX/noMsg Parse: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.720 5: SIGRBX/msg READ: regexp=^S(?:R|C|M);. cmd=sendraw msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.720 4: SIGRBX/read sendraw answer: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:53.722 4: SIGRBX/HandleWriteQueue: nothing to send, stopping timer
2019.12.01 17:33:56.758 4: set SIGRBX raw SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:56.758 5: AddSendQueue: SIGRBX: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121; (1)
2019.12.01 17:33:56.862 5: SIGRBX SW: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:56.872 4: SIGRBX SendrawFromQueue: msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;D=01212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121210121210123010101212121210101212101212101230101012121212101012121012121012301010121212121010121;
2019.12.01 17:33:56.920 4: SIGRBX/msg READ: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.921 5: SIGRBX/noMsg Parse: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.922 5: SIGRBX/msg READ: regexp=^S(?:R|C|M);. cmd=sendraw msg=SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.922 4: SIGRBX/read sendraw answer: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
2019.12.01 17:33:56.924 4: SIGRBX/HandleWriteQueue: nothing to send, stopping timer



Vielen Dank.

Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Ralf9

Zitatsendraw answer: SR;R=3;P0=419;P1=-230;P2=105;P3=-1104;send cmd to long
Das Sendekommando ist zu lang, bei der verwendeten Firmware ist die Länge auf 255 begrenzt.

Bei meiner V 3.3.2.1-rc9 ist je nach verwendeter Hardware die Länge auf 350 oder 400 begrenzt:
sduinoRXB/noMsg Parse: cmd to long! (max 400)

Mir ist nicht klar, warum Du so ein langes Sendekommando verwendest, funktioniert dies nicht?
SR;;R=25;;P0=419;;P1=-230;;P2=105;;P3=-1104;;D=30101012121212101012121012121012;;

Gruß Ralf


FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

pejonp

#303
Hallo Ralf,

habe die SignalDuino auf Version beim CC1101 (V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01) und beim RFM83C (V 3.3.2.1-rc9 SIGNALduino - compiled at Jun 16 2019 18:11:42) umgestellt. Und Version


00_SIGNALduino.pm           10488 2019-07-10 12:00:00Z v3.4.0


Jetzt geht der alte String wieder.

Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

D3ltorohd

#304
Ich würde gerne eine it 3500 Steckdose anlernen, aber irgendwie will die nicht. Autocreate ist an, an der Steckdose habe ich den Knopf länger gedrückt, danach fängt sie an mit blinken, aber es wird kein device angelegt. Ich weiß nicht mehr wie ich das bei der it1500 gemacht hab, da hat es damals auch geklappt.

EDIT:.

Hab es hinbekommen, man musste die ja erst mal anlegen und dann per On anlernen.

define Steckdose_Dunstabzug IT <26 Bit> <2Bit> <4 bit>
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

RaspII

Hallo,
ich bin neu hier und versuche ein Protokoll via V 3.3.2.1-rc9 zu dekodieren (GFSK Modulation, Signalduino Nano, CC1101)
Mit der Standard Signalduino Firmware kann ich einen Teil des Protokolles dekodieren, allerdings ist der Block sehr lang und diese Firmware gerät out of Sync.

Mit Eurer V 3.3.2.1-rc9 habe ich jetzt das Problem, dass ich, sobald ich eine Taste an der FB drücke nur noch Schrott sehe, wie wenn Baudrate etc. falsch eingestellt ist.

Unsupported command
Unsupported command
Mu;;£ì;´
;Ä;ø;§;C1;RF6;DRg;p;
Mu;CCBSCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCsCCCsB;p;
Mu; ôÈ;
;¢î;¨;´;Ô;¦
;ü;C1;RF6;D42Vvp;p;
Mu;ø;¡;
;³¥ì;¶
;¼;C2;RF6;D###################################################################%##&s%#%%;p;
Mu;r2P2;p;
Mu; øÈ;ø;¢î;¤;´¨;Ô;¦
;ø;C1;RF6;D42Vvp;p;
Mu;ø;¡;
;³¥ì;¶

;¼;C2;RF6;D###################################################################%##&s%#%%;p;
Mu;r2P2;p;
Mu;°
¢î;³
;¼;
ü;¦;¦;C1;RF6;d!4!a!' ;p;
Mu; ;¡£
;ó;;´CCBSCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCcCCCcBc`;p;
Mu;r2P2;p;
Mu; àÈ;;¢î;¨;´¡;Ô;¦42Vvp;p;
Mu;ø;¡;
;³¥ì;¶
;À;C2;RF6;D###################################################################%##&s%#%%;p;


Normale Befehle wie C99 beantwortet die Firmware jedoch lesbar.

Allerdings kommt mit meinen korrigierten EEPROM Werten folgende Meldung beim Booten
Using sFIFO
Reading values from eeprom
CCInit ok. ccVer=20 ccPartnum=0
Starting timerjob
cc1101 is not correctly set. Please do a factory reset via command e


Was bedeutet hier eigentlich "Using sFIFO"?

Hier ist beschrieben, was genau ich machen will:
https://github.com/RFD-FHEM/RFFHEM/issues/711#issuecomment-566156624
RaspII

Ralf9

ZitatMit Eurer V 3.3.2.1-rc9 habe ich jetzt das Problem, dass ich, sobald ich eine Taste an der FB drücke nur noch Schrott sehe, wie wenn Baudrate etc. falsch eingestellt ist.
Mu;;

Da ist die Datenkomprimierung (config: Mred=1) noch eingeschaltet, dies ist auch am kleinen "u" erkennbar.
Damit wird die Ausgabe der sehr langen MU-Nachrichten aktiviert und die Datenkomprimierung abgeschaltet:
get sduino raw CEO
get sduino raw CDR


Ein get config ergibt dann folgendes:
config: MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;...

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

RaspII

Kaum macht man es richtig schon klappts  ;) (hab mir die Freiheit genommen und "get" durch "set" ersetzt  ;D
Danke für die Hilfe, dann mach ich mich mal ans dekodieren
MU;P0=-784;P1=260;P2=-170;P4=-364;P5=-1436;P6=1696;P7=868;CP=1;R=246;D=121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121412121562141270;p;
MU;P0=-18532;P1=1724;P2=-784;P3=-156;P4=259;P5=-364;P6=-1311;P7=886;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18532;P1=1724;P2=-780;P3=-159;P4=256;P5=-366;P6=-1310;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18544;P1=1724;P2=-784;P3=-159;P4=256;P5=-366;P6=-1311;P7=886;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18540;P1=1724;P2=-784;P3=-156;P4=257;P5=-366;P6=-1312;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18528;P1=1724;P2=-784;P3=-156;P4=260;P5=-365;P6=-1307;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18544;P1=1724;P2=-784;P3=-156;P4=260;P5=-367;P6=-1304;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18540;P1=1732;P2=-784;P3=-156;P4=258;P5=-364;P6=-1306;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18536;P1=1720;P2=-784;P3=-156;P4=261;P5=-365;P6=-1305;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18524;P1=1724;P2=-784;P3=-156;P4=260;P5=-366;P6=-1309;P7=886;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18532;P1=1720;P2=-784;P3=-157;P4=258;P5=-365;P6=-1310;P7=888;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18524;P1=1724;P2=-784;P3=-156;P4=260;P5=-365;P6=-1309;P7=890;CP=4;R=246;D=6764343454340434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434343434543434613454372;p;
MU;P0=-18528;P1=-156;P2=1724;P4=259;P5=-364;P6=-1311;P7=888;CP=4;R=246;D=676414145414041414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141454141462145417;p;


Kann man das eigentlich auch alles innerhalb einer Zeile ausgeben lassen (würde mir das dekodieren erleichtern)
RaspII

Ralf9

Da sind jetzt aber keine sehr langen MU-Nachrichten dabei.
Das p am Ende bedeutet daß der Patternspeicher (P0-P7) übergelaufen ist
Hinter den P7 und P2 am Ende folgen wahrscheinlich noch P8 und P9

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

#309
Kannst Du abschätzen wieviele verschiedene Pattern noch fehlen, würde es reichen, wenn es noch ein P8 und P9 geben würde?

Nachtrag:
ZitatWas bedeutet hier eigentlich "Using sFIFO"?
Dies ist nur eine Debugausgabe, daß für die empfangenen Pulse ein Fifo verwendet wird.

Zitatcc1101 is not correctly set. Please do a factory reset via command e
Dies kommt daher:
bool regCheck()
{
return (readReg(CC1100_PKTCTRL0, CC1101_CONFIG) == initVal[CC1100_PKTCTRL0]) && (readReg(CC1100_IOCFG2, CC1101_CONFIG) == initVal[CC1100_IOCFG2]);
}


Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

RaspII

Hab mir das mal angeschaut. Es fehlen tatsächlich Bits.

Erwarten würde ich folgende Botschaft:
17mal 0xaa, dann   0x54 0x07 0xfa 0x5e 0x14 0x75 0xcc 0x0f 0x02 0xa9

Erhalten tu ich:
17mal 0xaa, dann   0x54 0x07 0xfa 0x5e   dann ist Zeile 1 fertig und es kommen ab Zeile2 nicht mehr die erwarteten Werte

Das Problem könnte sein, dass der Sender nach der ersten Botschaft (=was ich erwarten würde) erst mal Pause macht (das sind die ca. 18500 usec) d.h. nichts sendet.
Variabel sind im Block nur die 0x14, 0x75 und 0xa9 (am Ende). Diese können beliebige Werte zwischen 0x00 und 0xff annehmen, daraus ergeben sich die möglichen Pattern.

Wenn ich die doppelten Pattern mal rausstreiche ergibt sich:

MU;P0=-784;P1=260;P2=-170;P4=-364;P5=-1436;P6=1696;P7=868;
MU;P0=-18532;P1=1724;P2=-784;
MU;P1=-156;P6=-1311;


Die Frage ist nur wie groß die Toleranz ist.
Bsp.:
Zeile 1 P2=-170 ist das selbe Pattern wie Zeile 3 P1=-156, d.h. hier sieht man einen Jitter von 14usec
Zeile 1 P6=1696 ist das selbe Pattern wie Zeile 2 P1=1724 d.h. 28usec Jitter

Ich könnte ja schauen ob ich mit 3...5 zusätzlichen Pattern zurechtkomme sofern mir jemand die Firmware ändern kann
RaspII

Ralf9

ZitatDie Frage ist nur wie groß die Toleranz ist.
Bsp.:
Zeile 1 P2=-170 ist das selbe Pattern wie Zeile 3 P1=-156, d.h. hier sieht man einen Jitter von 14usec
Zeile 1 P6=1696 ist das selbe Pattern wie Zeile 2 P1=1724 d.h. 28usec Jitter
Die Toleranz ist 0.2, d.h. die Pattern sind noch in der Toleranz.

ZitatIch könnte ja schauen ob ich mit 3...5 zusätzlichen Pattern zurechtkomme sofern mir jemand die Firmware ändern kann
Ich habe es mir mal angeschaut, ich kann es mit überschaubarem Aufwand einbauen,
Es gibt dann 2 zusätzliche Konfigurationsvariablen: maxnumpat und maxpulse

Mit maxnumpat kann man dann die max Anzahl Pattern bis auf 16 erhöhen (P0-PF Hex), default ist 8.
Mit maxpulse kann man die max Pulslänge (default -32001) verkleinern, ab der ein Ende erkannt wird. Z.B. mit maxpulse 17000 wird -18532 als Ende erkannt.

Kannst Du abschätzen ob es evtl noch mehr Protokolle gibt wo die max Anzahl Pattern von 8 nicht ausreicht?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

RaspII

Hallo Ralf,
Mit 0.2 meist Du 1/5tel des Patzers also z.b 20% von 170 usec?

Bzgl. der Protokolle:
Abschätzen kann ich das nicht, je nach Länge des Protokolls müssten es m .e. aber deutlich mehr wie 8 sein, da ja beliebige Bitkombinationen kommen können.
Nimm mal eine variable Botschaft von nur 3 Bytes und überlege Dir welche Pattern auftreten können, da bist Du schnell deutlich über 10. Ein Maxpulse von 8000 für den ersten Test wäre mir am liebsten


RaspII

Ralf9

ZitatMit 0.2 meist Du 1/5tel des Patzers also z.b 20% von 170 usec?
ja

ZitatNimm mal eine variable Botschaft von nur 3 Bytes und überlege Dir welche Pattern auftreten können, da bist Du schnell deutlich über 10.
Mir ist das Prinzip nicht klar.
Bei OOK habe ich 2 Pattern für Bit=1 und zwei Pattern für Bit=0, anscheinend ist es hier anders.


FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

RaspII

#314
Da geht es mir genauso mit OOK, deshalb reden wir vielleicht etwas aneinander vorbei.
Ich erklär mal was der CC1101 mit dem GFSK Verfahren beim Demodulieren macht:

  • eigentlich funktioniert der Baustein in diesem Mode wie eine synchrone serielle Schnittstelle. D.h. am GDO2 Pin kommen direkt die Bits hintereinander raus. Normalerweise gibt es einen zweiten Pin als Takt den ebenfalls der CC1101 liefert, d.h. mit jedem Takt kommt ein Bit (High oder Low, 8 Bits ergeben dann direkt ein Byte der Empfangsbotschaft ohne weitere Umrechnungen)
  • Da beim Signalduino der Takt Pin nicht angeschlossen ist bzw. nicht ausgewertet wird, habe ich den CC1101 auf assynchronen Mode umkonfiguriert, dann reicht ein Pin aus (GO2), allerdings muss man die Taktzeiten angeben (das empfangene und demodulierte Signal wird dann mit Faktor 8 abgetastet). Der Takt vom Sender und Empfänger können leicht unterschiedlich sein, das ist vermutlich der Grund warum die High-/Low Zeiten nicht 100%ig identisch sind
  • Der Signalduino sieht als Pattern dann aber die unterschiedlichen Bitkombinationen, und die sind dann abhängig vom der Empfangenen Botschaft
  • Bsp.: 1. Byte = 0x00, 2.Byte = 0xFF, 3.Byte = 0x00 (also jeweils 8 Bit 1 oder 8 Bit 0)
    Als Pattern würdest du dann 8x die Bitzeit für "1" und 8x die Bitzeit für "0" finden. Kommt direkt danach z.B. als:
    1. Byte 0x00, 2.Byte = 0X00 und als 3. Byte 0xFF würdest Du noch das Pattern für 16x "1" dazubekommen usw.
    (das Patter für 8x "0" hast Du ja schon)
    Jetzt können aber auch die einzelnen Bits inerhalb eines Bytes unterschiedlich sein, d.h. die Pattern die Du findest sind beliebig unterschiedlich, je nach empfangenen Bits
  • Ich vermute mal, dass beim OOK Verfahren die Bits Pulsweitenmoduliert sind, d.h. Du findest immer nur 4 verschiedene Pattern
    2 Pattern für die Low und High Zeit des "0" Bits, und nochmal 2 Pattern für das "1" Bit. Dann kommt evt. noch der Sync Impuls dazu und das sollte es dann schon sein.
  • Wie gesagt, bisher nur Vermutung, ich lese mich gerade ein.

Hoffe damit konnte ich zumindest den GFSK Mode erklären.

Da bei meinem Anwendungsfall max. 2 Bytes in folge "variabel" sind, sollten 16 Pattern völlig ausreichen. Zumindest für meinen Anwendungsfall. Wenn man den einen FSK Mode wirklich implementieren möchte, sollte man sich aber überlegen ob man hierfür nicht die Pattern vermisst, sondern die synchrone serielle Schnittstelle in Betrieb nimmt und die Bitfolgen direkt weitergibt.

Bleibt für mich erstmal eine Frage:
Kannst Du mir evt. eine Signalduino Variante erstellen, die 16 Pattern erfassen kann? Ich könnte dann zumindest sagen ob es für meinen Anwendungsfall ausreicht.
RaspII