Hallo zusammen,
bei der Analyse eines derzeit nicht erkannten Sensors (Eberle Instat+) habe ich die beiden folgenden seltsamen Phänomene, Sensor sendet bei 868,95MHz per FM ein proprietäres Protokoll. Codierung der Daten erfolgt über differentielles Manchester.
Ich habe die Register des CC1101 so gesetzt, dass über slowRF der Sender im log-file geloggt wird und readings abgesetzt werden, aber ohne eine Idee wie das optimiert werden könnte.
ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71 ccreg 10: 57 C4 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B ccreg 20: F8 56 11 EF 2D 13 1F 41 00 59 7F 3F 88 31 0B
Ursprüngliche Analyse erfolgte mit URH und RTL-SDR. Den Daten und Werten vertraue ich grundlegend.
Die dekodierten Pulse des CC1101 habe ich am GDO2-Pin mit dem Oszi abgefangen.
Frage 1) Die Datenpulse haben laut URH eine Länge von demodulierten 350µs. sH und sL haben jeweils ziemlich exakt die gleiche Länge, ebenso lH und lL.
Bei den demodulierten Pulsen des CC1101 dagegen sind diese "unsauber" und asymmetrisch, sH und lH sind deutlich länger als sL und lL. Auch die einzelnen sL sind in der Länge deutlich unterschiedlich.
Beides zusammen ist einer zuverlässigen Erkennung nicht zuträglich.
Hat jemand eine Idee, welche Register ich im CC1101 wie setzen muss, um da eine Verbesserung zu erzielen?
Gibt es eine Strategie, wie ihr die gesetzt habt für die schon bestehenden Geräte?
Bild 3 und Bild 4
Frage 2) Gegenüber dem Signal in URH fehlt der initiale lange Puls: Hat jemand eine Idee, welches Register ich im CC1101 wie setzen muss, damit das übereinstimmt? Ich meine, das hat keinen Einfluß auf die eigentliche Daten und wäre damit eher sekundär.
Es könnte allerdings schon eine Rolle spielen, da ich zukünftig auch Daten senden möchte,
Bild 1 und Bild 2
Anmerkung: Signale kommen vom selben Sender, da dieser aber eine Art rolling Code sendet, und ich nicht mit beiden Geräten exakt dasselbe Signal eingefangen habe, stimmen am Ende des Signal die einzelnen Daten nicht überein.
Hallo DerD,
deine URH-Screenshots zeigen
Modulation: FSK bei 350 Samples/Symbol (1 MSps) → ~2857 Baud, sauber dekodiert. Die Modulation ist also klar. Zwei Dinge an deinem ccreg-Dump, das Wichtigere zuerst:
1. Frequenz: FREQ2/1/0 =
10 B0 71 ist die culfw-433-Default-Konfig → 26 MHz / 2^16 × 0x10B071 = 433,92 MHz. Der Instat+ sendet aber auf 868,95 MHz; fürs 868-Band muss FREQ2 = 0x21 sein. Läuft dein Stick real auf 433, fängst du das Signal nur über Nahfeld-Leakage ins falsche Frontend — das macht schon allein unsaubere, asymmetrische Pulse. Bitte zuerst prüfen.
2. Modulation: der Rest ist die culfw-SlowRF-Konfig, also reines ASK/OOK (MDMCFG2=0x30 = MOD_FORMAT ASK/OOK; DEVIATN=0x00 hat in OOK laut DB SWRS061I S.79 ,,no effect"). Du demodulierst FSK mit einem Amplitudendetektor — ein FSK-Signal hat aber konstante Hüllkurve, du siehst nur die FM-zu-AM-Konversion über die Flanke deines 325-kHz-Filters, daher die asymmetrischen Pulse.
Sobald die Frequenz stimmt: auf FSK-Demod umstellen, GDO2 bleibt async Serial-Output (IOCFG2=0x0D):
- MDMCFG2 (0x12): 0x30 → 0x00 (2-FSK), Manchester aus, SYNC_MODE=0 → Roh-Bitstrom.
- MDMCFG3 (0x11): DRATE auf ~2,8 kBaud (deine 350 µs/Symbol), nicht 5603.
- MDMCFG4 (0x10): CHANBW deutlich enger als 325 kHz (~2×(Deviation + halbe Symbolrate)).
- DEVIATN (0x15): auf die tatsächliche Deviation; muss im RX laut DB ,,approximately right" sein.
Was für DEVIATN/CHANBW noch fehlt: wie groß ist die Deviation (Tonabstand / 2) in deiner URH-Aufnahme?
Gruß
Danke schon mal, leider komme ich die nächsten Tage nicht zum testen. Die Frequenz teste ich auf jeden Fall als erstes, da war ich mir sicher die 868Mhz eingestellt zu haben.
Die Deviation hatte ich mit 50kHz abgelesen und unterschiedliche Breiten dem CC mitgegeben, ohne erkennbaren Effekt auf die Erkennung. Die Asymmetrie hatte ich da noch nicht im Blick.
Geschickterweise gibt es vom Instat auch noch unterschiedliche Versionen mit großer und kleiner Deviation. Mir scheint, das wurde verbreitert um den Empfang zu verbessern.
Ach ja, das Modul ist sicher eines für 868Mhz.
Hi DerD,
der Knackpunkt zuerst: Solange MDMCFG2 = 0x30 ist, läuft der CC1101 im ASK/OOK-Modus — und da ist DEVIATN laut Datenblatt schlicht wirkungslos (,,ASK/OOK: This setting has no effect."). Deshalb hat das Variieren der Deviation nichts gebracht: Du demodulierst ein FSK-Signal mit dem Amplitudendetektor, daher die verzerrten/asymmetrischen Pulse (FM-zu-AM über die Filterflanke). Zwei Dinge müssen stimmen — die richtige Frequenz und 2-FSK statt OOK. Als Startpunkt (Cw schreibt das CC1101-Register live, danach strobt der CUL selbst SCAL + RX):
set CUL raw Cw0D21 ; FREQ2 = 0x21 -> 868,95 MHz (war 0x10 = 433,92!)
set CUL raw Cw0E6B ; FREQ1 = 0x6B
set CUL raw Cw0FD1 ; FREQ0 = 0xD1
set CUL raw Cw1200 ; MDMCFG2 = 0x00 -> 2-FSK (war 0x30 = ASK/OOK)
set CUL raw Cw1550 ; DEVIATN = 0x50 -> +/-50 kHz Hub
set CUL raw Cw1096 ; MDMCFG4 = 0x96 -> RX-BW 162 kHz + DRATE-Exp
set CUL raw Cw11CD ; MDMCFG3 = 0xCD -> DRATE ~2,86 kBaud
DEVIATN / RX-BW / DRATE sind nur Startwerte — die hängen an zwei Zahlen, die ich aus deinem Post nicht sicher ableiten kann. Kannst du in URH nachmessen:
- Tonabstand der beiden FSK-Frequenzen — und ist das der gesamte Abstand oder schon der Hub je Seite? Der CC1101 will den Hub (= halber Tonabstand).
- kürzeste Pulslänge / Symbolrate (deine 350 µs deuten auf ~2,86 kBaud).
Wichtig zur Einordnung: Der CUL/culfw hat keinen Eberle-Instat-Decoder — er kann dir nur den rohen demodulierten Bitstrom liefern (am GDO2-Pin, dein IOCFG2 = 0x0D = serial data out). Das Telegramm selbst (differentieller Manchester → Frame) musst du daraus rekonstruieren.
Für diesen Roh-Blick gibt es zwei Wege:
- Am saubersten: GDO2 direkt mit Logic-Analyzer/Scope abgreifen — dann siehst du den echten FSK-Demod-Strom 1:1 und kannst ihn neben URH legen (Firmware ist dabei egal, das macht der CC1101-Demodulator). Vermutlich machst du das ohnehin schon?
- Software-Alternative über culfw: der Monitor-Modus `set CUL raw X18` gibt die rohen Pulszeiten (r/f) über die serielle Schnittstelle aus. Das ist modulations-unabhängig, funktioniert also auch im FSK-Demod — allerdings als Binärwerte, über die FHEM-Konsole eher fummelig.
Wie greifst du die Pulse aktuell ab — GDO direkt oder über die culfw-Konsole?
Ausblick: SIGNALduino auf derselben Hardware ist für das FSK-Reverse-Engineering an sich die dankbarere Firmware (generischer FSK-Pfad, Register via W<reg><val>, FIFO-Empfang). ABER: seine rohen Pulslisten (MU) laufen nur im OOK-Modus — sobald MDMCFG2 auf FSK steht, schaltet es auf den FIFO-Empfang um, der ein bekanntes Sync-Word braucht. Für den jetzigen Schritt (rohen FSK-Strom ansehen) bringt es dir also noch nichts; es wird erst interessant, wenn du Sync-Word und Frame-Format kennst — dann holt es die Telegramme direkt als Hex aus dem FIFO. Bis dahin bist du mit GDO-Abgriff bzw. culfw-Raw besser dran.
Gruß
Hallo,
ich habe in meiner sduino Variante den Eberle-Instat-Decoder eingebaut, damit wird es bis auf das Problem mit den asymmetrischen Pulslängen recht brauchbar dekodiert.
DerD verwendet dazu einen Raspi Pico
https://forum.fhem.de/index.php?topic=143942.msg1357980#msg1357980
Da diese Firmware bis zu 4 cc1101 Module unterstützt, hat er vermutlich in der ersten Nachricht die cc1101 Register config vom default Slowrf cc1101 gepostet.
Damit werden nur die symetrischen Pulslängen erkannt, für die asymmetrischen Pulslängen ist eine weitere Definition notwendig.
zero => [-1], # 0 -330 short low
one => [1.18], # 1 390 short high
two => [-2.1], # T -700 long low
float => [2.2], # F 720 long high
start => [2.2, -3.2, 2.2], # 720, -1050, 720
clockabs => 330,
2026.06.16 17:18:12.152 4: sduinoD/msg get raw: MU;P0=-680;P1=-341;P2=363;P3=-4535;P4=2578;P5=-2454;P6=765;P7=-1035;CP=2;R=179;D=2345676060606120612121212060212160216021;p;
2026.06.16 17:18:12.152 4: sduinoD: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.06.16 17:18:12.152 5: sduinoD: Starting demodulation (StartStr: 676 cut Pos 4; Signal: (?:2|1|6|0){10,} Pos 0) length_min_max (10..0) length=33
2026.06.16 17:18:12.152 5: sduinoD: applying postDemodulation , value before : T F T F T F 0 1 T F 0 1 0 1 0 1 0 1 T F T 1 0 1 0 F T 1 0 F T 1 0
2026.06.16 17:18:12.152 4: sduinoD: EberleInstat, rawbitmsg=001100110011010011010101010011001010110010110010 (48)
2026.06.16 17:18:12.152 5: sduinoD: rcode=1, modified after postDemodulation: 04E139_000000100111100011001001_(24)
2026.06.16 17:18:12.152 5: sduinoD: dispatching bits: 04E139_000000100111100011001001_(24)
Gruß Ralf
Hallo,
das lies mir keine Ruhe, so habe ich Prios geändert :)
Zitat von: tostmann am 15 Juni 2026, 12:01:03deine URH-Screenshots zeigen Modulation: FSK bei 350 Samples/Symbol (1 MSps) → ~2857 Baud, sauber dekodiert. Die Modulation ist also klar. Zwei Dinge an deinem ccreg-Dump, das Wichtigere zuerst:
1. Frequenz: FREQ2/1/0 = 10 B0 71 ist die culfw-433-Default-Konfig → 26 MHz / 2^16 × 0x10B071 = 433,92 MHz. Der Instat+ sendet aber auf 868,95 MHz; fürs 868-Band muss FREQ2 = 0x21 sein. Läuft dein Stick real auf 433, fängst du das Signal nur über Nahfeld-Leakage ins falsche Frontend — das macht schon allein unsaubere, asymmetrische Pulse. Bitte zuerst prüfen.
Zitat von: tostmann am 15 Juni 2026, 21:27:51der Knackpunkt zuerst: Solange MDMCFG2 = 0x30 ist, läuft der CC1101 im ASK/OOK-Modus — und da ist DEVIATN laut Datenblatt schlicht wirkungslos (,,ASK/OOK: This setting has no effect."). Deshalb hat das Variieren der Deviation nichts gebracht: Du demodulierst ein FSK-Signal mit dem Amplitudendetektor, daher die verzerrten/asymmetrischen Pulse (FM-zu-AM über die Filterflanke). Zwei Dinge müssen stimmen — die richtige Frequenz und 2-FSK statt OOK. Als Startpunkt (Cw schreibt das CC1101-Register live, danach strobt der CUL selbst SCAL + RX):
set CUL raw Cw0D21 ; FREQ2 = 0x21 -> 868,95 MHz (war 0x10 = 433,92!)
set CUL raw Cw0E6B ; FREQ1 = 0x6B
set CUL raw Cw0FD1 ; FREQ0 = 0xD1
set CUL raw Cw1200 ; MDMCFG2 = 0x00 -> 2-FSK (war 0x30 = ASK/OOK)
set CUL raw Cw1550 ; DEVIATN = 0x50 -> +/-50 kHz Hub
set CUL raw Cw1096 ; MDMCFG4 = 0x96 -> RX-BW 162 kHz + DRATE-Exp
set CUL raw Cw11CD ; MDMCFG3 = 0xCD -> DRATE ~2,86 kBaud
mea culpa, beim hin- und herkopieren habe ich einen falschen Satz Registerwerte hier reinkopiert. Sorry dafür, echt peinlich :-[ . Hier die tatsächlich eingestellten Register, die zu der Sollfrequenz 868MHz passen:
FREQ2 21
FREQ1 6B
FREQ0 F6
Zitat von: tostmann am 15 Juni 2026, 12:01:032. Modulation: der Rest ist die culfw-SlowRF-Konfig, also reines ASK/OOK (MDMCFG2=0x30 = MOD_FORMAT ASK/OOK; DEVIATN=0x00 hat in OOK laut DB SWRS061I S.79 ,,no effect"). Du demodulierst FSK mit einem Amplitudendetektor — ein FSK-Signal hat aber konstante Hüllkurve, du siehst nur die FM-zu-AM-Konversion über die Flanke deines 325-kHz-Filters, daher die asymmetrischen Pulse.
Sobald die Frequenz stimmt: auf FSK-Demod umstellen, GDO2 bleibt async Serial-Output (IOCFG2=0x0D):
- MDMCFG2 (0x12): 0x30 → 0x00 (2-FSK), Manchester aus, SYNC_MODE=0 → Roh-Bitstrom.
- MDMCFG3 (0x11): DRATE auf ~2,8 kBaud (deine 350 µs/Symbol), nicht 5603.
- MDMCFG4 (0x10): CHANBW deutlich enger als 325 kHz (~2×(Deviation + halbe Symbolrate)).
- DEVIATN (0x15): auf die tatsächliche Deviation; muss im RX laut DB ,,approximately right" sein.
Was für DEVIATN/CHANBW noch fehlt: wie groß ist die Deviation (Tonabstand / 2) in deiner URH-Aufnahme?
DEVIATN / RX-BW / DRATE sind nur Startwerte — die hängen an zwei Zahlen, die ich aus deinem Post nicht sicher ableiten kann. Kannst du in URH nachmessen:
- Tonabstand der beiden FSK-Frequenzen — und ist das der gesamte Abstand oder schon der Hub je Seite? Der CC1101 will den Hub (= halber Tonabstand).
- kürzeste Pulslänge / Symbolrate (deine 350 µs deuten auf ~2,86 kBaud).
Auch hier nun die aktuell eingestellten Register, der FSK Demod ist zumindest an (nicht ASK/OOK)
Die mit URH gemessene deviation (also halber Abstand zwischen oben/unten) ist 50kHz und die Datenrate hatte ich auch mal auf 2700-2800 Baud abgeschätzt. Im URH sind es manchmal 700, manchmal 720µs für long.
MDMCFG4 57
MDMCFG3 43
MDMCFG2 0
MDMCFG1 23
MDMCFG0 B9
Zitat von: tostmann am 15 Juni 2026, 12:01:03Wichtig zur Einordnung: Der CUL/culfw hat keinen Eberle-Instat-Decoder — er kann dir nur den rohen demodulierten Bitstrom liefern (am GDO2-Pin, dein IOCFG2 = 0x0D = serial data out). Das Telegramm selbst (differentieller Manchester → Frame) musst du daraus rekonstruieren.
Ja, das ist klar. Da ist Ralf9 zusammen mit mir dran und das funktioniert grundsätzlich schon mal so. Nur wollte ich die Basis sicher aufsetzen, weil ich eben diesen deutlichen Unterschied zwischen URH und CUL sehe.
Zitat von: tostmann am 15 Juni 2026, 12:01:03Wie greifst du die Pulse aktuell ab — GDO direkt oder über die culfw-Konsole?
mein Oszi hängt direkt am GDO2 Pin, eben weil ich real sehen wollte was da kommt. Ohne irgendwelche Interpretationen/Zusatzmodule. das funktioniert auch hinreichend gut.
Zitat von: Ralf9 am 16 Juni 2026, 18:00:40DerD verwendet dazu einen Raspi Pico
https://forum.fhem.de/index.php?topic=143942.msg1357980#msg1357980
Da diese Firmware bis zu 4 cc1101 Module unterstützt, hat er vermutlich in der ersten Nachricht die cc1101 Register config vom default Slowrf cc1101 gepostet.
Das stimmt nur teilweise. Mein Zielsystem wird der Pico sein, die aktuellen Tests liefen aber über einen Arduino Nano mit CC1101, also CUL Setup aber mit spezieller Debug-Software über die Arduino-IDE von hier: https://github.com/LSatan/CC1101-Debug-Service-Tool
das hat zwei Gründe:
1) Prüfung, ob auch das alternative System diese Asymmetrie zeigt => was der Fall ist
2) am GDO2 eines CC1101-Breakout boards kommt man deutlich einfacher mit Testklemmen des Oszis ran
Über das Debugtool kann ich auch jedes Register einzeln setzen und auslesen, und Bänke speichern. Zudem auch hier: alternatives System. Und so kam es zum Fehler beim einkopieren der Registerwerte.
Der Vollständigkeit halber hier alle Register direkt aus der IDE ausgelesen und einkopiert:
18:09:03.018 -> CC1101 Register
18:09:03.018 -> ------------------------------
18:09:03.018 -> IOCFG2 D
18:09:03.018 -> IOCFG1 2E
18:09:03.018 -> IOCFG0 2D
18:09:03.018 -> FIFOTHR 7
18:09:03.018 -> SYNC1 D3
18:09:03.018 -> SYNC0 91
18:09:03.018 -> PKTLEN 3D
18:09:03.018 -> PKTCTRL1 4
18:09:03.018 -> PKTCTRL0 32
18:09:03.018 -> ADDR 0
18:09:03.018 -> CHANNR 0
18:09:03.018 -> FSCTRL1 6
18:09:03.018 -> FSCTRL0 0
18:09:03.018 -> FREQ2 21
18:09:03.018 -> FREQ1 6B
18:09:03.018 -> FREQ0 F6
18:09:03.018 -> MDMCFG4 57
18:09:03.018 -> MDMCFG3 43
18:09:03.018 -> MDMCFG2 0
18:09:03.018 -> MDMCFG1 23
18:09:03.050 -> MDMCFG0 B9
18:09:03.050 -> DEVIATN 31
18:09:03.050 -> MCSM2 7
18:09:03.050 -> MCSM1 0
18:09:03.050 -> MCSM0 18
18:09:03.050 -> FOCCFG 14
18:09:03.050 -> BSCFG 6C
18:09:03.050 -> AGCCTRL2 43
18:09:03.050 -> AGCCTRL1 0
18:09:03.050 -> AGCCTRL0 90
18:09:03.050 -> WOREVT1 87
18:09:03.050 -> WOREVT0 6B
18:09:03.050 -> WORCTRL F8
18:09:03.050 -> FREND1 56
18:09:03.050 -> FREND0 10
18:09:03.050 -> FSCAL3 EC
18:09:03.050 -> FSCAL2 2D
18:09:03.050 -> FSCAL1 14
18:09:03.050 -> FSCAL0 11
18:09:03.050 -> RCCTRL1 41
18:09:03.050 -> RCCTRL0 0
18:09:03.050 -> FSTEST 59
18:09:03.050 -> PTEST 7F
18:09:03.050 -> AGCTEST 3E
18:09:03.050 -> TEST2 88
18:09:03.050 -> TEST1 31
18:09:03.050 -> TEST0 B
Na also — das sieht doch jetzt rund aus!
Damit haben sich die beiden Punkte von neulich bestätigt: einmal die Frequenz (FREQ2 muss 0x21 sein, sonst hörst du auf 433 statt auf 868,95 MHz — so ein verrutschter Dump ist der Klassiker, da ist schon mancher reingelaufen), und einmal die Modulation (mit MDMCFG2=0x00 demodulierst du jetzt echtes 2-FSK, statt das FSK-Signal über die Filterflanke als Amplitude zu "raten"). Dass die Pulse damit sauberer kommen, war zu erwarten.
Die kleine Rest-Asymmetrie (sH/lH etwas länger als sL/lL) würde ich gar nicht mehr über die Register jagen — ein bisschen davon bleibt beim asynchronen GDO2-Abgriff im FSK-Demod fast immer übrig (Slicer-Flankenzeiten, minimaler Carrier-Offset). Und da bist du bei Ralf9 goldrichtig: sein Eberle-Instat-Decoder im SIGNALduino fängt genau das ab, weil er symmetrische und asymmetrische Pulsdefinitionen kennt. Das ist der robustere Weg als Register-Feintuning — das Telegramm-Decoding gehört in die Firmware, nicht in den Demodulator.
Viele Grüße
Zitat von: tostmann am 17 Juni 2026, 19:27:11Damit haben sich die beiden Punkte von neulich bestätigt: einmal die Frequenz (FREQ2 muss 0x21 sein, sonst hörst du auf 433 statt auf 868,95 MHz — so ein verrutschter Dump ist der Klassiker, da ist schon mancher reingelaufen), und einmal die Modulation (mit MDMCFG2=0x00 demodulierst du jetzt echtes 2-FSK, statt das FSK-Signal über die Filterflanke als Amplitude zu "raten"). Dass die Pulse damit sauberer kommen, war zu erwarten.
Vielleicht war das unklar ausgedrückt, der verrutschte Dump war vom CC1101 ins Forum hier, nicht in den CC1101 selber. Mit den korrekten Einstellungen (868MHz + FM) wurden genau eben die Bilder oben mit dem Oszi aufgenommen.
Sprich "sauberer" ist noch nichts geworden. Nur die Einstellungen passen so zur Theorie.
Zitat von: tostmann am 17 Juni 2026, 19:27:11Die kleine Rest-Asymmetrie (sH/lH etwas länger als sL/lL) würde ich gar nicht mehr über die Register jagen — ein bisschen davon bleibt beim asynchronen GDO2-Abgriff im FSK-Demod fast immer übrig (Slicer-Flankenzeiten, minimaler Carrier-Offset). Und da bist du bei Ralf9 goldrichtig: sein Eberle-Instat-Decoder im SIGNALduino fängt genau das ab, weil er symmetrische und asymmetrische Pulsdefinitionen kennt. Das ist der robustere Weg als Register-Feintuning — das Telegramm-Decoding gehört in die Firmware, nicht in den Demodulator.
Wenn die im ersten Post beschriebene Asymmetrie aber nicht einfach zu beheben ist, dann ist es halt so. Keine Frage, ich bin froh um die Möglichkeit das über Instat-Decoder abzufangen, nur schien mir das der falsche Weg wenn es auch schon am Anfang der Kette, sprich am Demodulator über die Registereinstellungen, gegangen wäre.
Rein Interessehalber: meine 2,8kBaud sind ja vergleichsweise lahm. Bei 10-facher Rate würde das Asymmetrieverhältnis sL/sH gleich bleiben, oder ist die Differenz sH-sL absolut (also ~10µs) und das Verhältnis würde dann damit deutlich ansteigen?
Zum Senden kann ich dann aber schon sL und sH gleichlang machen, oder?
Beide Fragen lassen sich trennen, weil die Asymmetrie ein reines RX-Artefakt ist.
Zur Skalierung: deine zweite Vermutung trifft's. Der Löwenanteil der Differenz sH−sL ist absolut, nicht proportional — er entsteht aus zwei zeitlich festen Effekten: der Flankenzeit des Datenslicers (begrenzt durch die feste digitale Kanalfilter-Bandbreite) und einem minimalen Restträger-/Frequenzoffset, der über die Diskriminator-Steilheit in eine feste Kantenverschiebung umgerechnet wird. Beides hängt nicht von der Symbolrate ab. Heißt: die ~10 µs bleiben grob gleich, und damit steigt das Verhältnis sH/sL bei 10-facher Rate deutlich (10 µs auf ~35 µs Halbbit statt auf ~350 µs). Irgendwann wird die Verschiebung vergleichbar mit der Symbollänge und das Slicing kippt — die langsame Rate kommt dir hier also eher entgegen.
Dazu kommt im asynchronen Serial-Mode noch eine feste Quantisierung: GDO2 gibt die Daten zeitdiskret mit 8 Samples pro Bit aus, Jitter ±1/8 Bitperiode (CC1101-Datenblatt, Abschnitt 27.1). Dieser Anteil skaliert mit der programmierten Datenrate, der Offset-/Slicer-Anteil oben nicht.
Zum Senden: ja, da machst du sL und sH exakt gleich lang. Beim TX läuft kein Demodulator in der Kette — der Modulator folgt einfach deiner Eingangsflanke. Die Asymmetrie ist allein ein Empfangs-/Diskriminator-Effekt; was du raussendest, ist so symmetrisch wie dein Pulstiming.
Besten Dank, auch für die Erläuterung zu dem was ich im Datenblatt zwar gelesen, aber nur bruchstückhaft verstanden hatte.
Testweise habe ich mal die drate auf das 10-fache gesetzt. Die Asymmetrie wird, wie zu erwarten weil ja "Dieser Anteil skaliert mit der programmierten Datenrate", damit deutlich besser. Allerdings sind die sL/sH/lL/lH nicht mehr wie bisher sauber abgegrenzt und es tauchen Dekodierungsartefakte auf, was das Ergebnis insgesamt deutlich verschlechtern wird. Also keine Option und ich belasse es wie es war.
Und GFSK (MDMCFG2=0x10) macht hier auch keinen Unterschied zu 2-FSK.
Hallo Dieter,
passt — und ist auch datenblattseitig sauber erklärbar. Im Async-Serial-RX trifft der CC1101 keine On-Chip-Datenentscheidung (§27.1): der rohe Demod-Ausgang ist zeitdiskret mit 8 Samples/Bit, Jitter ±1/8 Bitperiode, und dieses Raster ist an die programmierte DRATE gekoppelt. 10x DRATE -> 10x feineres Raster -> besseres sH/sL. Dieselbe Verfeinerung nimmt aber die "Glättung" raus: ohne Datenentscheidung läuft der rohe Demod-Jitter jetzt ungefiltert durch, also verschmieren sL/sH/lL/lH und es entstehen Fehlflanken. Klassischer Trade-off - die an ~2,7-2,8 kBaud angepasste DRATE ist das Optimum.
GFSK (MDMCFG2=0x10): §14.1 behandelt 2-FSK/GFSK/4-FSK/MSK im selben Demod-/FOC-Pfad, der Gauß-Filter ist reine TX-Formung -> RX-seitig erwartungsgemäß kein Unterschied.
Bleibt: reines Empfangsartefakt, per Register nicht wegzubekommen. Sauber nur toleranzbehaftet im Decoder (Ralfs postDemod).
Gruß