FSK mit dem SIGNALDuino

Begonnen von Ralf9, 22 Dezember 2019, 17:30:36

Vorheriges Thema - Nächstes Thema

Ralf9

Zitat von: HomeAuto_User am 26 Januar 2020, 12:46:41
Das Register setzt, so empfängt dieser noch nichts sichtbar. Dafür sind noch minimale Änderungen in der Firmware / Software notwendig. Bekommen wir es hin, diese noch zu ergänzen. Alternativ bist du bereit diese ggf. an anderer Stelle zu erläutern.

Um welche Änderungen geht es Dir?

Ich hab mal im ersten Beitrag ein paar Sachen ergänzt.

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

Irgendwas passt bei den PCA 301 Registereinstellungen noch nicht.

Wenn ich versuche von einem sduino zum anderen was zu senden, kommt beim anderen nichts an.

Beim Kopp Free Control kann ich problemlos von einem zum anderen sduino was senden.
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

plin

Zitat von: Ralf9 am 27 Januar 2020, 00:22:06
Irgendwas passt bei den PCA 301 Registereinstellungen noch nicht.

Ich habe da ja kürzlich ein Script geschrieben, um  alle Register-Settings in interpretierter Form auszugeben. Vielleicht hilft Dir das.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Ralf9

Ich habe jetzt erstmal zum Vergleich die SlowRF defaultwerte und die Werte nach dem Reset in ein Array eingetragen:
my %cc1101_register = ( # for get ccreg 99
"00" => ['IOCFG2  ', '0D', '29' ],
"01" => ['IOCFG1  ', '2E' ],
"02" => ['IOCFG0  ', '2D', '3F' ],
"03" => ['FIFOTHR ', '07' ],
"04" => ['SYNC1   ', 'D3' ],
"05" => ['SYNC0   ', '91' ],
"06" => ['PKTLEN  ', '3D', '0F' ],
"07" => ['PKTCTRL1', '04' ],
"08" => ['PKTCTRL0', '32', '45' ],
"09" => ['ADDR    ', '00' ],
"0A" => ['CHANNR  ', '00' ],
"0B" => ['FSCTRL1 ', '06', '0F' ],
"0C" => ['FSCTRL0 ', '00' ],
"0D" => ['FREQ2   ', '10', '1E' ],
"0E" => ['FREQ1   ', 'B0', 'C4' ],
"0F" => ['FREQ0   ', '71', 'EC' ],
"10" => ['MDMCFG4 ', '57', '8C' ],
"11" => ['MDMCFG3 ', 'C4', '22' ],
"12" => ['MDMCFG2 ', '30', '02' ],
"13" => ['MDMCFG1 ', '23', '22' ],
"14" => ['MDMCFG0 ', 'B9', 'F8' ],
"15" => ['DEVIATN ', '00', '47' ],
"16" => ['MCSM2   ', '07', '07' ],
"17" => ['MCSM1   ', '00', '30' ],
"18" => ['MCSM0   ', '18', '04' ],
"19" => ['FOCCFG  ', '14', '36' ],
"1A" => ['BSCFG   ', '6C' ],
"1B" => ['AGCCTRL2', '07', '03' ],
"1C" => ['AGCCTRL1', '00', '40' ],
"1D" => ['AGCCTRL0', '90', '91' ],
"1E" => ['WOREVT1 ', '87' ],
"1F" => ['WOREVT0 ', '6B' ],
"20" => ['WORCTRL ', 'F8' ],
"21" => ['FREND1  ', '56' ],
"22" => ['FREND0  ', '11', '16' ],
"23" => ['FSCAL3  ', 'E9', 'A9' ],
"24" => ['FSCAL2  ', '2A', '0A' ],
"25" => ['FSCAL1  ', '00', '20' ],
"26" => ['FSCAL0  ', '1F', '0D' ],
"27" => ['RCCTRL1 ', '41' ],
"28" => ['RCCTRL0 ', '00' ],
"29" => ['FSTEST  ' ],
"2A" => ['PTEST   ' ],
"2B" => ['AGCTEST ' ],
"2C" => ['TEST2   ' ],
"2D" => ['TEST1   ' ],
"2E" => ['TEST0   ' ]
);


Dann habe ich eine Liste der cc1101 Register beim PCA 301, bei den Werten die vom Resetwert abweichen, steht der Resetwert in [ ]
ccregAll:

ccreg 00: 01 2E 46 07 2D D4 FF 00 02 00 00 06 00 21 6B D0
ccreg 10: 88 0B 06 22 F8 53 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 10 EC 0C 3D 11 41 00 59 7F 3E 88 31 0B

cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2   - 0x01 (0D) [29]
0x01 IOCFG1   - 0x2E
0x02 IOCFG0   - 0x46 (2D) [3F]
0x03 FIFOTHR  - 0x07
0x04 SYNC1    - 0x2D (D3)
0x05 SYNC0    - 0xD4 (91)
0x06 PKTLEN   - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
0x09 ADDR     - 0x00
0x0A CHANNR   - 0x00
0x0B FSCTRL1  - 0x06 [0F]
0x0C FSCTRL0  - 0x00
0x0D FREQ2    - 0x21 (10) [1E]
0x0E FREQ1    - 0x6B (B0) [C4]
0x0F FREQ0    - 0xD0 (71) [EC]
0x10 MDMCFG4  - 0x88 (57) [8C]
0x11 MDMCFG3  - 0x0B (C4) [22]
0x12 MDMCFG2  - 0x06 (30) [02]
0x13 MDMCFG1  - 0x22 (23)
0x14 MDMCFG0  - 0xF8 (B9)
0x15 DEVIATN  - 0x53 (00) [47]
0x16 MCSM2    - 0x07
0x17 MCSM1    - 0x00 [30]
0x18 MCSM0    - 0x18 [04]
0x19 FOCCFG   - 0x16 (14) [36]
0x1A BSCFG    - 0x6C
0x1B AGCCTRL2 - 0x43 (07) [03]
0x1C AGCCTRL1 - 0x68 (00) [40]
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1  - 0x87
0x1F WOREVT0  - 0x6B
0x20 WORCTRL  - 0xF8
0x21 FREND1   - 0x56
0x22 FREND0   - 0x10 (11) [16]
0x23 FSCAL3   - 0xEC (E9) [A9]
0x24 FSCAL2   - 0x0C (2A) [0A]
0x25 FSCAL1   - 0x3D (00) [20]
0x26 FSCAL0   - 0x11 (1F) [0D]
0x27 RCCTRL1  - 0x41
0x28 RCCTRL0  - 0x00
0x29 FSTEST   - 0x59
0x2A PTEST    - 0x7F
0x2B AGCTEST  - 0x3E
0x2C TEST2    - 0x88
0x2D TEST1    - 0x31
0x2E TEST0    - 0x0B


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

KölnSolar

Hi Ralf,
mich wundern etwas Deine Daten. Beim CUL gibt es ja OOK(rfmode=SlowRF=default=Deine 1. Liste). Gegenüber dessen Registereinstellungen werden für native(2-FSK "allgemein") diese Register beim Lesen geändert
NATIVE_CFG[46] = {
 
  CC1100_FSCTRL1, 0x06,
  CC1100_FREQ2, 0x21,   // FREQ2     Frequency control word, high byte.
  CC1100_FREQ1, 0x65,   // FREQ1     Frequency control word, middle byte.
  CC1100_FREQ0, 0x6A,   // FREQ0     Frequency control word, low byte.
 
  CC1100_MCSM1, 0x00,   // always go into IDLE after RX or TX
  CC1100_MCSM0, 0x18, // automatic calibration when going from IDLE to RX or TX (or FSTXON)
  CC1100_FOCCFG, 0x16,
  CC1100_AGCCTRL2, 0x43,
  CC1100_AGCCTRL1, 0x68,
  CC1100_FSCAL1, 0x00,
  CC1100_FSCAL0, 0x11,
 
  CC1100_IOCFG2, 0x01,   // IOCFG2  Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty
  CC1100_IOCFG0, 0x46,   // IOCFG0   invert output, i.e. select active low (1) / high (0)
 
  CC1100_SYNC0, 0xd4,
  CC1100_SYNC1, 0x2d,
 
  CC1100_FIFOTHR, 2,     // 12 byte in RX - see page 72 of CC1101.pdf
 
  CC1100_PKTCTRL1, 0x00,   // PKTCTRL1  Packet automation control -
  CC1100_PKTCTRL0, 0x02,   // PKTCTRL0  Packet automation control - Infinite packet length mode
 
  CC1100_MDMCFG4, 0x89,   // MDMCFG4   Modem configuration. - channel bandwidth
  CC1100_MDMCFG3, 0x5C,   // MDMCFG3   Modem configuration. - data rate
  CC1100_MDMCFG2, 0x06,   // !! 05 !! MDMCFG2   Modem configuration. Modulation 2-FSK with sync-word 16/16 + carrier-sense above threshold
 
  CC1100_DEVIATN, 0x56,   // DEVIATN   Modem deviation setting (when FSK modulation is enabled).
 
  0xff
};

Für PCA301 zusätzlich
  // Mode 3 - PCA 301 - 868.9500MHz 6.631kbps
  {
    CC1100_FIFOTHR, 0x02,   // 32 byte in RX   0x07  RX  0x02 12 bytes / TX 0x12 13 bytes
    CC1100_MDMCFG4, 0x88,   // MDMCFG4   Modem configuration.
    CC1100_MDMCFG3, 0x0B,   // MDMCFG3   Modem configuration

    CC1100_FREQ2, 0x21,   // FREQ2     Frequency control word, high byte.
    CC1100_FREQ1, 0x6B,   // FREQ1     Frequency control word, middle byte.
    CC1100_FREQ0, 0xD0,   // FREQ0     Frequency control word, low byte.

    CC1100_DEVIATN, 0x53,   // DEVIATN   Modem deviation setting (when FSK modulation is enabled).

    0xff,
  }

zumindest bei FIFOTHR(in der culfw 0x07, aber den halte ich für falsch),FSCALx ist mir ein Unterschied aufgefallen.

Und fürs Senden hab ich mir damals nur
CC1100_FIFOTHR, 0x12,  //TX 0x12 13 bytes
aufgeschrieben. Ob das richtig ist, weiß ich nicht.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Ralf9

#95
Die Registerwerte habe ich von hier, der Empfang funktioniert ja problemlos
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/rf_native.c
In der zweiten Liste sind die Registerwerte die ich verwende.

Mit Hilfe des HashArrays %cc1101_register wird aus
ccreg 00: 01 2E 46 07 2D D4 FF 00 02 00 00 06 00 21 6B D0
ccreg 10: 88 0B 06 22 F8 53 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 10 EC 0C 3D 11 41 00 59 7F 3E 88 31 0B

die zweite Liste erzeugt
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

KölnSolar

Zitatder Empfang funktioniert ja problemlos
das wundert mich ja, wenn FSCALx anders ist. Steht doch im Link auch anders
  CC1100_FSCAL1, 0x00,
  CC1100_FSCAL0, 0x11,

und in Deiner 2.Liste steht0x23 FSCAL3   - 0xEC (E9) [A9]
0x24 FSCAL2   - 0x0C (2A) [0A]
0x25 FSCAL1   - 0x3D (00) [20]
0x26 FSCAL0   - 0x11 (1F) [0D]


ZitatUnd fürs Senden hab ich mir damals nur
Code: [Auswählen]
CC1100_FIFOTHR, 0x12,  //TX 0x12 13 bytes
aufgeschrieben. Ob das richtig ist, weiß ich nicht.
Ist (aus dem Kopf) schon wichtig, da dann ja überhaupt erst bei der korrekten Anzahl von bytes im Puffer das Senden erfolgt(wie gesagt: Gedächtnis von vor über einem Jahr) :-\
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Ralf9

0x23 FSCAL3   - 0xEC (E9) [A9]
0x24 FSCAL2   - 0x0C (2A) [0A]
0x25 FSCAL1   - 0x3D (00) [20]
0x26 FSCAL0   - 0x11 (1F) [0D]


Die FSCAL Werte sind beim späteren auslesen der Register anders als wie sie am Anfang mit den Werten im EEPROM initialisiert wurden.
Mit diesen Werten werden sie initialisiert
0x23 FSCAL3   E9
0x24 FSCAL2   2A
0x25 FSCAL1   00
0x26 FSCAL0   11



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

ZitatIst (aus dem Kopf) schon wichtig, da dann ja überhaupt erst bei der korrekten Anzahl von bytes im Puffer das Senden erfolgt(wie gesagt: Gedächtnis von vor über einem Jahr)
Nach meinem Verständnis hat dies nichts mit dem Senden zu tun, dies ist nur ein Schwellwert ab dem sich der Status auf TXFIFO_UNDERFLOW ändert.

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

KölnSolar

ZitatFSCAL Werte sind beim späteren auslesen der Register anders
OK, dann haben die wohl keine Bedeutung. Ich guckte halt nur stumpf in die culfw-source.
ZitatNach meinem Verständnis hat dies nichts mit dem Senden zu tun, dies ist nur ein Schwellwert ab dem sich der Status auf TXFIFO_UNDERFLOW ändert.
Das hab ich anders im Kopf. Ich hab mich am Anfang gewundert, dass viel-zu-viele bytes/Telegramm empfangen wurden. Immer die selbe Anzahl. Und dann meine ich den "Fehler" im CC1100_FIFOTHR, 0x07 gefunden zu haben. Umgekehrt sind dann fürs Senden die volle Anz. bytes notwendig, weil erst ein voller Puffer den/das Empfang/Senden auslöst. Ich kann da aber auch völlig auf dem Holzweg sein....
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Ralf9

ZitatMode 3 - PCA 301 - 868.9500MHz 6.631kbps
Was mir auf gefallen ist, mit diesen Registern kommt ein etwas andere Datenrate raus
ccconf: freq:868.950MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:6620.41Baud)
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

Ich bin inzwischen etwas weitergekommen, so wies aussieht liegts an den Registereinstellungen. Ich bin so weit, daß ich weiß das ich das Schalten und den Statusrequest des PCA 301 hinbekommen werde.
Ich mache hier erst mal nicht weiter, ich weiß bis jetzt überhaupt nicht ob überhaupt Interesse und Bedarf an dem besteht was ich hier mit dem FSK und dem Signalduino mache.
Ich weiß auch mangels Rückmeldungen nicht ob schon jemand mit meiner Firmware den FSK Empfang getestet hat.
Ich warte jetzt erst mal ab ob Interesse und Bedarf an LaCrosse, Kopp Free Control und PCA 301 und weiteren Sensoren mit dem Signalduino besteht.

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

sash.sc

LaCrosse definitiv. Habe von den it 29-dth ein paar. Brauche dafür ja noch das LaCrosse Gateway.

Gebe ich richtig in der Annahme, daß der geänderte sduino mit 2x cc1101 (433 und 868Mhz) ausgestattet werden wird bzw kann?

Gesendet von meinem MI 9 mit Tapatalk

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

plin

Zitat von: Ralf9 am 28 Januar 2020, 19:13:05
Ich mache hier erst mal nicht weiter, ich weiß bis jetzt überhaupt nicht ob überhaupt Interesse und Bedarf an dem besteht was ich hier mit dem FSK und dem Signalduino mache.
Ich weiß auch mangels Rückmeldungen nicht ob schon jemand mit meiner Firmware den FSK Empfang getestet hat.
Hallo Ralf,

ich habe mittlerweile eine Lösung für meine RIO-Motoren, die senden per FSK. Ich weiß welche Register ich dafür wie umschießen muss. Ich hatte das auch mit Deiner Firmware gestetet. Mittlwerweile ist das Protokoll ins Modul SD_Keeloq eingeflossen.

Aber: Ich nutze den SIGNALduino nicht im FIFO-Mode sondern nur als Modem. Wenn ich von OOK auf FSK wechsele, Trägerfrequenz, Hub und Bandbreite anpasse kann ich die Rolladenmotoren steuern und auch die Signale der Fernbedienung empfangen.

Also: Ja, es gibt Leute die Interesse an FSK mit SIGNALduino haben. Ich sehe hier insbesondere den Vorteil, dass der SIGNALduino recht frei konfigurierbar ist und die Demodulation erst im Modul erfolgt. Wenn man es mit Exoten, unbekannten oder neuen Protokollen zu tun hat ist das recht hilfreich.

Viele Grüße
Peter
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Ralf9

ZitatGebe ich richtig in der Annahme, daß der geänderte sduino mit 2x cc1101 (433 und 868Mhz) ausgestattet werden wird bzw kann?
Ja, die sduino Firmware auf dem Maple Mini wird 1 x 433 oder 868  (SlowRF) und bis zu 3 x 868Mhz mit FIFO können.
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