NorthernMan54 / rtl_433_ESP

Trial port of the rtl_433 Library for use with OpenMQTTGateway on a ESP32 and a CC1101 Transceiver
GNU General Public License v3.0
506 stars 119 forks source link

Support for FSK Modulation - WH51 Soil Moisture sensor #5

Closed NorthernMan54 closed 1 year ago

NorthernMan54 commented 3 years ago

Status on the FSK Project

Backlog

[x] Addition of FSK device decoders to the build [x] Update build process to allow refreshes of rtl_433 components [x] Wire FSK device decoders into rtl_433_ESP code base [x] Create FSK Transmitter to emulate a FSK device, tks @AusGunno ( https://github.com/NorthernMan54/rtl_433_ESP/tree/fsk/example/FSK_Transmitter ) [x] Create FSK Receiver ( https://github.com/NorthernMan54/rtl_433_ESP/tree/fsk/example/FSK_Receiver ) [x] Create FSK Sample ( https://github.com/NorthernMan54/rtl_433_ESP/tree/fsk/example/FSK_Sample ) [x] Demodulate signal pulse train into rtl_433 device decoders

[ ] Add backwards compatibility for old RSSI Signal detection mode [x] Final tuning of signal reception to improve success rate from 10% [x] Review change for bad code, simplify compiler definitions [ ] Add support for verbose mode of a single device decoder [x] Fix broken debug mode setting [ ] Update documentation for FSK Decoders and new wiring requirement [ ] Enable modulation switches in openMQTTGateway to enable switching between FSK and ASK modulation [ ] Create pull request for OpenMQTTGateway for breaking change on usage of gpio2 and removal of minimumRSSI option

AusGunno commented 3 years ago

@NorthernMan54 Will work on this tonight. Here is the -A data from RTL_433 and SDR dongle Detected FSK package 2021-04-06 13:21:09


time : 2021-04-06 13:21:09 model : Fineoffset-WH51 ID : 00ca1d Battery level: 1.111 Battery : 1700 mV Moisture : 0 % Transmission boost: 0 AD raw : 20 Integrity : CRC Analyzing pulses... Total count: 48, width: 10.26 ms ( 2564 S) Pulse width distribution: [ 0] count: 1, width: 0 us [0;0] ( 0 S) [ 1] count: 38, width: 56 us [56;68] ( 14 S) [ 2] count: 3, width: 116 us [116;120] ( 29 S) [ 3] count: 3, width: 172 us [172;176] ( 43 S) [ 4] count: 1, width: 404 us [404;404] ( 101 S) [ 5] count: 1, width: 288 us [288;288] ( 72 S) [ 6] count: 1, width: 1392 us [1392;1392] ( 348 S) Gap width distribution: [ 0] count: 33, width: 56 us [48;60] ( 14 S) [ 1] count: 6, width: 172 us [172;176] ( 43 S) [ 2] count: 2, width: 464 us [464;468] ( 116 S) [ 3] count: 3, width: 112 us [112;116] ( 28 S) [ 4] count: 2, width: 256 us [232;280] ( 64 S) [ 5] count: 1, width: 348 us [348;348] ( 87 S) Pulse period distribution: [ 0] count: 1, width: 48 us [48;48] ( 12 S) [ 1] count: 27, width: 116 us [116;120] ( 29 S) [ 2] count: 9, width: 232 us [232;232] ( 58 S) [ 3] count: 3, width: 172 us [172;176] ( 43 S) [ 4] count: 2, width: 576 us [520;636] ( 144 S) [ 5] count: 3, width: 308 us [292;340] ( 77 S) [ 6] count: 1, width: 872 us [872;872] ( 218 S) [ 7] count: 1, width: 1448 us [1448;1448] ( 362 S) Pulse timing distribution: [ 0] count: 1, width: 0 us [0;0] ( 0 S) [ 1] count: 71, width: 56 us [48;68] ( 14 S) [ 2] count: 6, width: 116 us [112;120] ( 29 S) [ 3] count: 9, width: 172 us [172;176] ( 43 S) [ 4] count: 3, width: 444 us [404;468] ( 111 S) [ 5] count: 3, width: 264 us [232;288] ( 66 S) [ 6] count: 1, width: 1392 us [1392;1392] ( 348 S) [ 7] count: 1, width: 348 us [348;348] ( 87 S) [ 8] count: 1, width: 0 us [0;0] ( 0 S) Level estimates [high, low]: 15873, 7 RSSI: -0.1 dB SNR: 33.6 dB Noise: -33.7 dB Frequency offsets [F1, F2]: 7357, -7395 (+28.1 kHz, -28.2 kHz) Guessing modulation: Pulse Code Modulation (Not Return to Zero) Attempting demodulation... short_width: 56, long_width: 56, reset_limit: 57344, sync_width: 0 Use a flex decoder with -X 'n=name,m=FSK_PCM,s=56,l=56,r=57344' pulse_demod_pcm(): Analyzer Device bitbuffer:: Number of rows: 1 [00] {177} 55 55 55 55 55 51 6e a2 88 06 50 e8 8b f8 07 c0 a7 ff ff fb 9a 20 80

Noting that the bit buffer seems to be out of sync by 1 bit. 55 <<1 = AA (Sync), 55 55 55 55 5 = AA AA AA AA A - sync 5 51 6e a = AA 2D D4 - pre etc

Given that this actually has a well defined packet Data format: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 aa aa aa 2d d4 51 00 6b 58 6e 7f 24 f8 d2 ff ff ff 3c 28 8 FF II II II TB YY MM ZA AA XX XX XX CC SS Sync: aa aa aa ... Preamble: 2d d4 - actually preamble[] = {0xAA, 0x2D, 0xD4}; FF: Family code 0x51 (ECOWITT/FineOffset WH51) IIIIII: ID (3 bytes) T: Transmission period boost: highest 3 bits set to 111 on moisture change and decremented each transmission; if T = 0 period is 70 sec, if T > 0 period is 10 sec B: Battery voltage: lowest 5 bits are battery voltage * 10 (e.g. 0x0c = 12 = 1.2V). Transmitter works down to 0.7V (0x07) YY: ? Fixed: 0x7f MM: Moisture percentage 0%-100% (0x00-0x64) MM = (AD - 70) / (450 - 70) Z: ? Fixed: leftmost 7 bit 1111 100 AAA: 9 bit AD value MSB byte[07] & 0x01, LSB byte[08] XXXXXX: ? Fixed: 0xff 0xff 0xff CC: CRC of the preceding 12 bytes (Polynomial 0x31, Initial value 0x00, Input not reflected, Result not reflected) SS: Sum of the preceding 13 bytes % 256

It should be simple enough to set up the parameters in the normal packet TX code. I will do it tonight - I can verify against RTL_433 using the SDR, the Misol receiver and ESP. Hopefully, the transmitter (WH51) will be stable enough clock wise to use Packet Rx mode on the CC101. I have not tried to date but wanted to start with the RTL_433 approach. Cheers Gunno

AusGunno commented 3 years ago

Have been playing with the transmit serial example - modified to send a predefined message. Mixed success so far but the parameters that RTL_433 SDR reports are no way near what is required (tried various bit rates etc). The spectrum seems really messy as well. The WH51 has a clean spectrum with the two frequencies for the 0/1 pulses. The CC1101 in some cases seems to have way more frequencies. So wondering if the config is not optimised and may be unstable. Will get a reg config from RF Studio for what I think the TX parameters should be and modify the RegConfigSettings() directly. Cheers Gunno

NorthernMan54 commented 3 years ago

Sounds like your getting close

AusGunno commented 3 years ago

OK Getting close now. Used RF Studio to set most register values. Tweaked a few afterwards. RTL_433 shows:

Detected FSK package 2021-04-11 22:59:41 Analyzing pulses... Total count: 39, width: 9.11 ms ( 2278 S) Pulse width distribution: [ 0] count: 26, width: 56 us [52;72] ( 14 S) [ 1] count: 6, width: 116 us [116;120] ( 29 S) [ 2] count: 3, width: 172 us [172;176] ( 43 S) [ 3] count: 1, width: 408 us [408;408] ( 102 S) [ 4] count: 1, width: 292 us [292;292] ( 73 S) [ 5] count: 1, width: 1392 us [1392;1392] ( 348 S) [ 6] count: 1, width: 232 us [232;232] ( 58 S) Gap width distribution: [ 0] count: 24, width: 56 us [56;64] ( 14 S) [ 1] count: 3, width: 172 us [172;172] ( 43 S) [ 2] count: 1, width: 348 us [348;348] ( 87 S) [ 3] count: 7, width: 112 us [112;116] ( 28 S) [ 4] count: 1, width: 520 us [520;520] ( 130 S) [ 5] count: 2, width: 232 us [232;232] ( 58 S) Pulse period distribution: [ 0] count: 18, width: 116 us [112;136] ( 29 S) [ 1] count: 3, width: 228 us [228;232] ( 57 S) [ 2] count: 8, width: 172 us [172;176] ( 43 S) [ 3] count: 4, width: 420 us [348;464] ( 105 S) [ 4] count: 2, width: 288 us [288;292] ( 72 S) [ 5] count: 2, width: 548 us [520;580] ( 137 S) [ 6] count: 1, width: 1508 us [1508;1508] ( 377 S) Pulse timing distribution: [ 0] count: 50, width: 56 us [52;72] ( 14 S) [ 1] count: 13, width: 116 us [112;120] ( 29 S) [ 2] count: 6, width: 172 us [172;176] ( 43 S) [ 3] count: 2, width: 376 us [348;408] ( 94 S) [ 4] count: 2, width: 292 us [292;296] ( 73 S) [ 5] count: 1, width: 1392 us [1392;1392] ( 348 S) [ 6] count: 3, width: 232 us [232;232] ( 58 S) [ 7] count: 1, width: 520 us [520;520] ( 130 S) Level estimates [high, low]: 5406, 5 RSSI: -4.8 dB SNR: 30.3 dB Noise: -35.2 dB Frequency offsets [F1, F2]: 24416, 6640 (+93.1 kHz, +25.3 kHz) Guessing modulation: Pulse Code Modulation (Not Return to Zero) Attempting demodulation... short_width: 56, long_width: 56, reset_limit: 57344, sync_width: 0 Use a flex decoder with -X 'n=name,m=FSK_PCM,s=56,l=56,r=57344' pulse_demod_pcm(): Analyzer Device bitbuffer:: Number of rows: 1 [00] {162} aa aa aa 2d d4 0e 51 00 6b 58 6e 7f 24 f8 d2 ff ff ff 3c 28 00

Problem is the CC1101 is inserting the packet length byte (0e) into the stream, so it will not decode. Have looked at various datasheets CC1101, CC430 etc. Packet Length byte is described as optional - but documentation varies as to which mode it is optional (may be Variable). Have tried fixed, variable and infinite - no change. Have loaded the modified Elechouse_CC1101 CPP file and my platformio project main.cpp file.

CC1101 WH51.zip

NorthernMan54 commented 3 years ago

I would say that you have nailed it

Detected FSK package    2021-04-11 18:18:51
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-04-11 18:18:51
model     : Fineoffset-WH51                        ID        : 006b58
Battery level: 0.778     Battery   : 1400 mV       Moisture  : 36 %          Transmission boost: 3     AD raw    : 210           Integrity : CRC
pulse_demod_pcm(): Fine Offset Electronics/ECOWITT WH51 Soil Moisture Sensor
bitbuffer:: Number of rows: 1 
[00] {162} aa aa aa 2d d4 0e 51 00 6b 58 6e 7f 24 f8 d2 ff ff ff 3c 28 00 
Analyzing pulses...
Total count:   40,  width: 9.42 ms      ( 2356 S)
Pulse width distribution:
 [ 0] count:   26,  width:   56 us [52;72]  (  14 S)
 [ 1] count:    6,  width:  116 us [112;120]    (  29 S)
 [ 2] count:    3,  width:  172 us [172;176]    (  43 S)
 [ 3] count:    1,  width:  408 us [408;408]    ( 102 S)
 [ 4] count:    2,  width:  260 us [232;288]    (  65 S)
 [ 5] count:    1,  width: 1392 us [1392;1392]  ( 348 S)
 [ 6] count:    1,  width:   20 us [20;20]  (   5 S)
Gap width distribution:
 [ 0] count:   24,  width:   56 us [56;68]  (  14 S)
 [ 1] count:    3,  width:  172 us [172;172]    (  43 S)
 [ 2] count:    2,  width:  316 us [288;348]    (  79 S)
 [ 3] count:    7,  width:  112 us [112;116]    (  28 S)
 [ 4] count:    1,  width:  520 us [520;520]    ( 130 S)
 [ 5] count:    2,  width:  232 us [232;232]    (  58 S)
Pulse period distribution:
 [ 0] count:   18,  width:  116 us [112;140]    (  29 S)
 [ 1] count:    3,  width:  228 us [228;232]    (  57 S)
 [ 2] count:    8,  width:  172 us [172;176]    (  43 S)
 [ 3] count:    5,  width:  404 us [344;464]    ( 101 S)
 [ 4] count:    2,  width:  288 us [288;292]    (  72 S)
 [ 5] count:    2,  width:  548 us [520;580]    ( 137 S)
 [ 6] count:    1,  width: 1508 us [1508;1508]  ( 377 S)
Pulse timing distribution:
 [ 0] count:   50,  width:   56 us [52;72]  (  14 S)
 [ 1] count:   13,  width:  116 us [112;120]    (  29 S)
 [ 2] count:    6,  width:  172 us [172;176]    (  43 S)
 [ 3] count:    2,  width:  376 us [348;408]    (  94 S)
 [ 4] count:    5,  width:  252 us [232;288]    (  63 S)
 [ 5] count:    1,  width: 1392 us [1392;1392]  ( 348 S)
 [ 6] count:    1,  width:   20 us [20;20]  (   5 S)
 [ 7] count:    1,  width:  520 us [520;520]    ( 130 S)
 [ 8] count:    1,  width:    0 us [0;0]    (   0 S)
Level estimates [high, low]:  15879,     55
RSSI: -0.1 dB SNR: 24.6 dB Noise: -24.7 dB
Frequency offsets [F1, F2]:   -1551, -17242 (-5.9 kHz, -65.8 kHz)
Guessing modulation: No clue...

I went and changed the rtl_443 WH51 device decoder to include the additional '0e' in the preamble, rebuild rtl_433 and it worked on the first try

fineoffset.c

static int fineoffset_WH51_callback(r_device *decoder, bitbuffer_t *bitbuffer)
{
    data_t *data;
    uint8_t const preamble[] = {0xAA, 0x2D, 0xD4, 0x0e};
    uint8_t b[14];
    unsigned bit_offset;

Now onto the next phase, getting this to work within the rtl_433_ESP

AusGunno commented 3 years ago

Agree - for the purposes of testing it will work. But I did solve the issue. The ELECHOUSE driver is inserting the length of the message into the FIFO buffer:

void ELECHOUSE_CC1101::SendData(byte *txBuffer, byte size, int t) {

SpiWriteReg(CC1101_TXFIFO, size);

SpiWriteBurstReg(CC1101_TXFIFO, txBuffer, size); //write data to send SpiStrobe(CC1101_SIDLE); SpiStrobe(CC1101_STX); //start send delay(t); SpiStrobe(CC1101_SFTX); //flush TXfifo trxstate = 1; }

If we comment out that line it works as intended with the standard definition in RTL_433.

Detected FSK package 2021-04-13 11:56:02


time : 2021-04-13 11:56:02 model : Fineoffset-WH51 ID : 006b58 Battery level: 0.778 Battery : 1400 mV Moisture : 36 % Transmission boost: 3 AD raw : 210 Integrity : CRC Analyzing pulses... Total count: 42, width: 9.11 ms ( 2278 S) Pulse width distribution: [ 0] count: 30, width: 56 us [52;68] ( 14 S) [ 1] count: 6, width: 116 us [116;120] ( 29 S) [ 2] count: 2, width: 172 us [172;172] ( 43 S) [ 3] count: 1, width: 404 us [404;404] ( 101 S) [ 4] count: 1, width: 292 us [292;292] ( 73 S) [ 5] count: 1, width: 1392 us [1392;1392] ( 348 S) [ 6] count: 1, width: 232 us [232;232] ( 58 S) Gap width distribution: [ 0] count: 28, width: 56 us [56;68] ( 14 S) [ 1] count: 4, width: 172 us [172;176] ( 43 S) [ 2] count: 1, width: 520 us [520;520] ( 130 S) [ 3] count: 2, width: 228 us [228;232] ( 57 S) [ 4] count: 6, width: 116 us [116;116] ( 29 S) Pulse period distribution: [ 0] count: 22, width: 116 us [112;136] ( 29 S) [ 1] count: 4, width: 228 us [228;232] ( 57 S) [ 2] count: 8, width: 172 us [172;176] ( 43 S) [ 3] count: 4, width: 504 us [460;580] ( 126 S) [ 4] count: 2, width: 316 us [288;348] ( 79 S) [ 5] count: 1, width: 1508 us [1508;1508] ( 377 S) Pulse timing distribution: [ 0] count: 58, width: 56 us [52;68] ( 14 S) [ 1] count: 12, width: 116 us [116;120] ( 29 S) [ 2] count: 6, width: 172 us [172;176] ( 43 S) [ 3] count: 1, width: 404 us [404;404] ( 101 S) [ 4] count: 2, width: 292 us [292;296] ( 73 S) [ 5] count: 1, width: 1392 us [1392;1392] ( 348 S) [ 6] count: 3, width: 228 us [228;232] ( 57 S) [ 7] count: 1, width: 520 us [520;520] ( 130 S) Level estimates [high, low]: 5572, 9 RSSI: -4.7 dB SNR: 27.9 dB Noise: -32.6 dB Frequency offsets [F1, F2]: 24348, 6356 (+92.9 kHz, +24.2 kHz) Guessing modulation: Pulse Code Modulation (Not Return to Zero) view at https://triq.org/pdv/#AAB02A08010038007400AC01940124057000E40208808080808080808080808080808080828090A0808280828755+AAB01708010038007400AC01940124057000E40208908090809655+AAB01D08010038007400AC01940124057000E4020890A1B18181C2908180D1E655+AAB01408010038007400AC01940124057000E40208808455 Attempting demodulation... short_width: 56, long_width: 56, reset_limit: 57344, sync_width: 0 Use a flex decoder with -X 'n=name,m=FSK_PCM,s=56,l=56,r=57344' pulse_demod_pcm(): Analyzer Device bitbuffer:: Number of rows: 1 [00] {162} aa aa aa aa 2d d4 51 00 6b 58 6e 7f 24 f8 d2 ff ff ff 3c 28 00

NorthernMan54 commented 3 years ago

Tks for finding that

I have updated the example in the FSK branch with this

https://github.com/NorthernMan54/rtl_433_ESP/commit/3f2ca304f55924f55b31053a9c4963526e7b6564

I'm still working thru getting the receiver to work with FSK modulation. I had thought it would be just set the modulation and deviation to match your sample to go. But nope.

DigiH commented 3 years ago

Watching this closely, and already tried some testing with the fsk branch to get my (possibly)

memcpy(&cfg->devices[48], &fineoffset_wh1080_fsk, sizeof(r_device));

weather station added. No luck so far ;)

NorthernMan54 commented 3 years ago

@DigiH with FSK, I’m currently work thru getting the cc1101 transceiver to receive FSK signals in asynchronous serial mode ( the cc1101 needs to have its packet control functions disabled to function as a simple receiver ). Next step after that is to add a signal decoder for fsk encoding pulse streams to rtl_433 bitbuffers.

As I don’t have a FSK device available I’m using the sample fsk transmitter code from above on one device to transmit a signal to test against. So far after 3 evenings I can see the test signal (Rssi), but no pulses yet. What is frustrating is that I see the occasional ook signal and pulses from my ook devices.

DigiH commented 3 years ago

@NorthernMan54 - my issues here being that I ordered a weather station, which I've always been interested in getting one, after reading some comments in issues in the RTL_433 repo.

There the command to get info from the station is stated as

/usr/local/bin/rtl_433 -f 868.319M -R 32 -d1 -p 28 -Y classic -s 250k

which to me sounds it needs the classic FSK pulse detector mode for its recognition.

In fineoffset_wh1080.c I can also see

.modulation = FSK_PULSE_PCM,

Since these stations seem to be rebranded by many companies I'm also not sure if this particular company might have added some changes to the signals. I might decide to return the station for the time being, and getting another one at a later stage. Also I should finally get a Realtek RTL2832 based DVB dongle to do some direct RTL_433 RTL-SDR testing of the devices I get ;)

I'm more than happy to do any testing with the weather station with your changes, as long I I still have it.

NorthernMan54 commented 3 years ago

With the way a cc1101 works, the receiver would not be able to receive ook and fsk signals at the same time. As the signal demodulation is done in the cc1101 chip, it needs to know the modulation first. So if you have devices with fsk and ook you will need multiple receivers.

DigiH commented 3 years ago

I've already made two gateways, one for 433Mhz, all ook devices so far, and one for 868Mhz, where I only have the one, probably fsk, device. So that would not be an issue for me.

BTW, just ordered my Realtek RTL2832 based DVB dongle. Should be here on Saturday for more testing of my weather station.

DigiH commented 3 years ago

As an update. I have received my Realtek RTL2832 dongle and tested my new weather station with the rtl_433 package. Contrary to my expectations it isn't recognised as a Fine Offset 1080/3080 station, but a Fine Offset WH65B, therefor using the same fineoffset.c device file as the WH51 soil moisture sensor, with the same FSK_PULSE_PCM modulation. With rtl_433 I'm getting

time      : 2021-04-17 12:28:47
model     : Fineoffset-WH65B                       ID        : 72
Battery   : 1            Temperature: 20.6 C       Humidity  : 41 %          Wind direction: 27        Wind speed: 0.0 m/s       Gust speed: 0.0 m/s       Rainfall  : 0.0 mm        UV        : 1
UVI       : 0            Light     : 0.0 lux       Integrity : CRC

every 16 seconds, as expected.

So the station stays and I'm ready for more testing with rtl_433_ESP.

NorthernMan54 commented 3 years ago

Status on the FSK Project

Backlog

[x] Addition of FSK device decoders to the build [x] Update build process to allow refreshes of rtl_433 components [x] Wire FSK device decoders into rtl_433_ESP code base [x] Create FSK Transmitter to emulate a FSK device, tks @AusGunno ( https://github.com/NorthernMan54/rtl_433_ESP/tree/fsk/example/FSK_Transmitter ) [x] Create Receiver Sample ( https://github.com/NorthernMan54/rtl_433_ESP/tree/fsk/example/FSK_Receiver )

[ ] Demodulate signal pulse train into rtl_433 device decoders [ ] Update documentation for FSK Decoders [ ] Enable modulation switches in openMQTTGateway

I'm currently stuck on getting the proper settings for the cc1101 to receive FSK modulated signals in 'Asynchronous Serial Operation' mode. I have been using this operation mode for OOK/ASK devices with great success but can't seem to get it too work with FSK signals. I need to use Asynchronous mode, as I need to pass the raw pulse signal train to the rtl_433 device decoders.

With the current receive sample, in OOK/ASK mode I can see the FSK signal ( RSSI ) but no pulses. And when I switch the cc1101 into 2-FSK modulation mode, I can still see the FSK signal, but no pulses. It feels very close, but no success yet.

The FSK receive sample is currently checked in with the current OOK/ASK modulation settings. This is so I can track the changes needed to enable FSK modulation.

Next step for me is to fire up SmartRF Studio to explore the 2-FSK settings in async mode. ( I'm a Mac user so need to install virtual box etc to get the software running ). I think I'm missing something simple when changing modes.

NorthernMan54 commented 3 years ago

Receiver Sample in ASK Mode

In here are 2 different signals, the 70K signal length is the FSK Transmitter Sample, and the 891K Signal is a Prologue Temperature Sensor I have

Signal Train: 0
Signal length: 71079
Signal RSSI: -43
Pulses: 0
Time: 25269

Signal Train: 0
Signal length: 891710
Signal RSSI: -36
Pulses: 255
Time: 28988
+130-570+405-680+306-2016+431-3934+475-1982+456-3922+480-1966+461-3937+479-3925+470-1960+481-1960+485-1955+466-1978+454-3951+456-3924+486-1974+463-1951+494-3910+471-1976+469-1988+450-1969+479-1966+460-3933+483-1955+486-3906+482-3922+477-1958+484-1959+486-3932+459-1957+465-1994+459-1978+455-1969+465-3778+8888-19637+398-2034+404-3982+426-2010+435-3941+455-3941+474-1983+459-1957+490-1948+489-1972+469-3908+492-3907+491-1973+468-1959+473-3935+446-1988+452-1988+462-1982+463-1975+465-3925+466-1974+457-3929+464-3954+460-1967+465-1970+491-3915+469-1980+446-1991+451-1992+483-1953+459-3927+463-2000+464-1969+465-3910+498-1954+469-9219+585-1924+492-3938+442-1983+473-3922+467-1964+474-3914+465-3942+467-1963+474-1987+485-1954+486-1950+466-3929+464-3923+486-1975+466-1973+468-3909+492-1952+471-1963+476-1964+483-1961+460-3946+479-1957+487-3910+457-3944+472-1965+457-1991+458-3933+455-1987+458-1981+461-1993+473-1951+469-3937+468-1982+444-1989+453-3941+473-1963+455-9224+563-1956+469-3937+468-1959+475-3913+497-1957+483-3908+476-3947+468-1963+479-1959+485-1956+464-1979+463-3926+464-3931+484-1954+465-1977+482-3900+465-1975+503-1973+442-1983+475-1966+454-3937+475-1961+482-3932+452-3941+445-1990+456-1983+461-3932+479-1956+461-1992+466-1974+470-1975+467-3916+468-1985+471-1969+451-3942+473-1956+484-9195+541-2007+445-3940+468-1962+472-3921+495-1960+450-3939+472-3924+493-1935+501-1957+461-1980+484-1950+489-3903+468-3953+462-1976+458-1974+476-3929+464-1970+470-1955+468-1988+480-1953+487-3906+477-1969+461-3945+480-3910+445-1987+482-1960+460-3944+460-1979+485-1950+467-1973+466-1975+492-3913+440-2010+452-1969+480-3921+475-1960+482-9195+586-1934+494-3918+467-1963+474-3921+470-1963+501-3910+471-3918+468-1984+453-2007+436-1989+462-1976+466-3922+465-3925+488-1971+470-1952+468-3940+470-1963+473-1964+485-1982+461-1978+439-3954+465-1975+460-3922+466-3929+459-1993+460-1978+465-3925+457-1970+491-1971+467-1981+470-1964+477-3911+476-1961+457-1991+486-3894+476-1982+461-9215+535-2012+430-3964+424-2011+432-3959+478-1958+485-3910+453-3948+469-1964+481-1957+487-1979+432-1971+489-3925+465-3926+463-1975+469-1987+453-3917+469-1990+450-1987+483-1971+462-1976+468-3908+472-1975+468-3918+493-3915+466-1981+445-1988+480-3919+473-1985+459-1956+490-1954+486-1949+487-3900+489-1971+470-1964+476-3921+494-1940+481-9090

Signal Train: 1
Signal length: 68420
Signal RSSI: -58
Pulses: 0
Time: 31270

Signal Train: 0
Signal length: 68319
Signal RSSI: -34
Pulses: 0
Time: 34272
NorthernMan54 commented 3 years ago

Receiver sample in 2-FSK Mode

When running in this mode ( I just changed the modulation default in ELECHOUSE_CC1101_SRC_DRV.cpp from 2 to 0 ) I can see the FSK Transmitter Sample signal, but no pulses. What is odd is the the signal length is different between OOK/ASK modulation and 2-FSK Modulation.

Signal Train: 1
Signal length: 8869
Signal RSSI: -24
Pulses: 0
Time: 60327

Signal Train: 0
Signal length: 8977
Signal RSSI: -43
Pulses: 0
Time: 63329

Signal Train: 0
Signal length: 8975
Signal RSSI: -24
Pulses: 0
Time: 66331

Signal Train: 0
Signal length: 8860
Signal RSSI: -24
Pulses: 0
Time: 69333

Signal Train: 0
Signal length: 8958
Signal RSSI: -37
Pulses: 0
Time: 72335
DigiH commented 3 years ago

While I'm totally out of my depth with the whole signal subject matter, please let me know if and when I can help in any way with my FSK devices.

Thanks so much for all your time and effort on this :)

AusGunno commented 3 years ago

I have tried the fsk code and cannot get it to work as is.

I modified the WH51 TX packet code for RX mode and it receives the packets - with one exception it seems to be missing the first byte 0x51. However when I insert that into the buffer and run the WH51 callback routine it decodes properly with CRC and bit checks. So the CC1101 works in packet mode. I have seen Ti forums discuss that async mode should work before sync mode will - so I suppose the converse is true. The below is a similar type packet signal though at 915Mhz carrier- he played with the bandwith and deviation settings in async mode to get the best signal - so perhaps that is worth a shot.

https://e2e.ti.com/support/wireless-connectivity/other-wireless/f/other-wireless-technologies-forum/231753/cc1101-2-fsk---help-needed

The standard async settings in ELECHOUSE DRV for CCMode = 0 are for 5k baud rate. I think the CC1101 samples at 8x that so may be good enough for 17k signal. I read somewhere - not sure though that in async mode baud rates above 5k can be unstable. THe deviation in the standard settings is 47k so perhaps worth setting that higher

Cheers AusGunno

NorthernMan54 commented 3 years ago

Hit a minor setback last night, and need to get the soldering iron back out again. I was looking at using carrier sense to determine start and end of signal as the level of RSSI background noise is different between ASK and FSK mode, and after I had flashed the device with the config I could no longer flash it again.

To push the default ELECHOUSE DRV config further I have found I need to set SYNC_MODE to 0 on setup so that it captures signal in FSK mode.

void ELECHOUSE_CC1101::RegConfigSettings(void) 
{   
    SpiWriteReg(CC1101_FSCTRL1,  0x06);
    SpiWriteReg(CC1101_MDMCFG2, 0x00);    // Disable sync mode

Currently playing with bandwidth, deviation and data rate to pull in the signal in asynchronous mode. Before I bricked my device I had been seeing portions of the sync section of the signal 'AA AA AA', so its looking close.

DigiH commented 3 years ago

and after I had flashed the device with the config I could no longer flash it again.

I had this issue as well before. As you described in your CC1101-Driver-Lib issue, disconnecting gpio2 solves this, but I also found that OTA updates still worked fine for me.

Thanks for the hint about gpio2 in connection with the LED, as I'm trying to mute the LED here.

On another topic and out of curiosity regarding the conversation on the OMG community

https://community.openmqttgateway.com/t/support-of-rtl-433-library/1498/22

Looking at the included rtl_433_esp code, the OOK_PULSE_MANCHESTER_ZEROBIT decoder seems to be already included, but the devices are not. Is this only because of you not having any OOK_PULSE_MANCHESTER_ZEROBIT devices for testing, or are there other limitations similar to FSK devices?

Thanks

NorthernMan54 commented 3 years ago

Well I have had some initial success with receiving FSK signals from the sample transmitter your created @AusGunno. This is the FSK branch and the example/FSK_Sample complied under platformio and flashed to my ESP32. Please note that I made some changes to the wiring required, and having gpio2 connected to the cc1101 gdo0 will 'brick' your unit ( see this https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/issues/78 ). The change was needed to enable carrier sense to detect start and end of signal. Please change the definitions in platform.ini for CC1101_GDO0 and CC1101_GDO2 to match your setup ( I changed the definition's from RF_EMITTER_GPIO and RF_RECEIVER_GPIO )

In my setup it is currently decoding the signal about 1 in 10 times, so some further tuning is needed but it is now feeling close.

rtl_433_ESP(6): Time: 75855, Signal length: 8939, Signal RSSI: -34, train: 0, messageCount: 24, pulses: 39
Exact bit width (in us) is 57.90 vs 58.00, 20 bit preamble
rtl_433_ESP(6): data_output {"model":"Fineoffset-WH51","id":"006b58","battery_ok":0.77778,"battery_mV":1400,"moisture":36,"boost":3,"ad_raw":210,"mic":"CRC","protocol":"Fine Offset Electronics/ECOWITT WH51 Soil Moisture Sensor","rssi":-34,"duration":8939}
N: Received message : {"model":"Fineoffset-WH51","id":"006b58","battery_ok":0.77778,"battery_mV":1400,"moisture":36,"boost":3,"ad_raw":210,"mic":"CRC","protocol":"Fine Offset Electronics/ECOWITT WH51 Soil Moisture Sensor","rssi":-34,"duration":8939}
pulse_demod_pcm(): Fine Offset Electronics/ECOWITT WH51 Soil Moisture Sensor
bitbuffer:: Number of rows: 1 
[00] {155} aa aa a8 b7 51 44 01 ad 61 b9 fc 93 e3 4b ff ff fc f0 a1 40 
rtl_433_ESP(6): # of messages decoded 1

rtl_433_ESP(6): Time: 78857, Signal length: 8940, Signal RSSI: -34, train: 1, messageCount: 25, pulses: 37
Exact bit width (in us) is 58.75 vs 58.00, 16 bit preamble
Fineoffset_WH51: short package. Header index: 42
bitbuffer:: Number of rows: 1 
[00] {152} 84 aa aa 8b 75 14 40 1a d6 1b 9f c9 3e 34 bf ff ff cf 0a 
rtl_433_ESP(6): # of messages decoded 0

rtl_433_ESP(6): Unparsed Signal length: 8940, Signal RSSI: -34, train: 1, messageCount: 26, pulses: 37
rtl_433_ESP(6): RAW (8940): (-34)+43-240(-34)+44-117(-34)+55-45(-34)+57-72(-34)+74-54(-34)+62-56(-34)+59-56(-34)+59-58(-34)+58-59(-34)+56-60(-34)+56-174(-34)+58-58(-34)+116-59(-34)+172-58(-34)+60-58(-34)+57-173(-34)+58-60(-35)+57-174(-35)+58-522(-35)+115-59(-34)+58-56(-34)+116-60(-34)+56-59(-34)+117-230(-34)+116-58(-34)+175-115(-34)+407-115(-34)+57-116(-34)+59-115(-34)+290-173(-34)+116-58(-34)+60-114(-34)+60-55(-34)+1394-114(-34)+231-232(-34)+58-59(-34)+43-42 

N: Received message : {"model":"unknown","protocol":"signal parsing failed","duration":8940,"signalRssi":-34,"pulses":37,"train":1,"messageCount":26,"_enabledReceiver":1,"receiveMode":0,"currentRssi":-73,"modulation":0}
NorthernMan54 commented 3 years ago

I have updated the first comment into a tracker of release status of this feature.

NorthernMan54 commented 3 years ago

I think I found the issue with the FSK Reception and why I was only successfully receiving and decoding 1 signal in 10, the sample transmitter was shutting down too soon. I padded the message with some additional zero's and was then able to receive almost 100% of the samples with only the occasional dropped signal.

AusGunno commented 3 years ago

Cool. Awesome work. Will have a play this weekend using the live transmitter. Cheers

Terry Gunson


From: Northern Man @.> Sent: Friday, April 23, 2021 12:57:12 PM To: NorthernMan54/rtl_433_ESP @.> Cc: Terry Gunson @.>; Mention @.> Subject: Re: [NorthernMan54/rtl_433_ESP] Support for FSK Modulation - WH51 Soil Moisture sensor (#5)

I think I found the issue with the FSK Reception and why I was only successfully receiving and decoding 1 signal in 10, the sample transmitter was shutting down too soon. I padded the message with some additional zero's and was then able to receive almost 100% of the samples with only the occasional dropped signal.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/NorthernMan54/rtl_433_ESP/issues/5#issuecomment-825350658, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK7B7UY3TD3TQSHZRUZ6E7TTKDOYRANCNFSM42NKX62A.

psychos4 commented 2 years ago

I'am using a sonoff rf bridge with tasmota + modified Portisch firmware and a docker container with halfbakery/rtl_433 for decoding incoming mqtt rf raw data.

But the big problem of the sonoff rf bridge is that it can only OOK devices. For my OOK devices (e. g. RainPoint-Soil) its greet. ;) But my MISOL/1 sensor is a Fineoffset-WH51 which is using FSK based communication.

So i need a solution which supports both OOK + FSK. the current readme says only OOK_PPM and OOK_PWM are supported. What's the status of FSK implementation now?

NorthernMan54 commented 2 years ago

It’s sitting as a future todo, and the major blocker is access to a device to test with. My current farm of sensors are all OOK based.

psychos4 commented 2 years ago

but with the fsk branch - i can already try it?

NorthernMan54 commented 2 years ago

No change in status of FSK support

Also with the cc1101 receiver, it would only be able to support a single modulation scheme at a time, either OOK or FSK modulation, and not both at the same time like a rtl_sdr.

DigiH commented 2 years ago

Also with the cc1101 receiver, it would only be able to support a single modulation scheme at a time, either OOK or FSK modulation, and not both at the same time like a rtl_sdr.

I'd be very happy to have a separate FSK only gateway with a 868 Mhz CC1101, as my OOK devices are all 433 Mhz anyway, so on a gateway with a different 433 CC1101.

obones commented 2 years ago

Hello, Sorry to "barge in" like this, but I'm trying to compile the project with a CC1101 module that I have here so that I can see if I receive my two temperature sensors that are FSK based at 868MHz. I checked out the fsk branch and tried opening the root folder in VSCode with PlatformIO extension, but there is no platformio.ini file so I created one. But then, it complained about ELECHOUSE_CC1101_SRC_DRV being missing. I copied the files from example\FSK_Receiver but now it complains about setup and loop functions being missing as well. I also tried compiling the example directly, but it does not seem to embark any of the rtl_433 devices. Would anyone be kind enough to share instructions?

NorthernMan54 commented 2 years ago

@obones To try out the FSK sample, try opening VSCode in the example/FSK_Receiver directory. The platformio.ini file is there.

https://github.com/NorthernMan54/rtl_433_ESP/tree/fsk/example/FSK_Receiver

And for the library I had been putting a symlink into the platformio lib directory to the library ie

pwd
/Users/northerMan/.platformio/lib
ln -s ~/Code/rtl_433_ESP rtl_433_ESP

This was on MacOS, and I had the library installed in the ~/Code directory

obones commented 2 years ago

Thanks, I was able to compile and run the FSK sample just fine, even it is not seeing any of my temperature sensors.

What I'm having a hard time figuring out is how to get the code to call the rtl_433 devices. I mean, the example/FSK_Receiver code makes no mention of src\rtl_433_ESP.h, nor did I see any example projects that do.

But maybe I completely misunderstand the way this project is supposed to work.

NorthernMan54 commented 2 years ago

You have to for give me, it has been awhile since I was in this branch and gave you the wrong subdir

this one is the complete sample

https://github.com/NorthernMan54/rtl_433_ESP/blob/fsk/example/FSK_Sample

the other directory was code I was using to tune the cc1101 receiver settings for fsk, it does not have the decoders just the receiver logic. But it should log received signals.

obones commented 2 years ago

Thanks, I was able to compile the FSK_Sample folder after a bit of mucking around with files. However, just like with FSK_Receiver, no signal is ever seen by the ESP32 code, despite my RTL-SDR dongle seeing them just fine. Do you want me to start another issue or should we keep discussing in this one?

NorthernMan54 commented 2 years ago

The first sample is just a simple receiver, with fsk enabled. So if no signal is output by it, you either have a wiring / config issue, a bad cc1101 or the transmitter is out of range, or another issue.

I would start their, as the board not sharing a signal is not the same as a signal not being decoded. As the decoder needs a signal.

one thing I did find was that the receiver was not as sensitive as a rtl-sdr and had significantly reduced range for receiving signals.

DigiH commented 2 years ago

@NorthernMan54 I've been digging out my weather station again after seeing others are testing the FSK example more recently. With setting

#define CC1101_FREQUENCY 868.319

things look fine for the CC1101 receiving signals with FSK_Sample, but unfortunately no decoding for my Fineoffset-WH65B.

Again many unparsed signals coming from all my Homematic devices, but running rtl_433 on my Mac at the same time and the weather station flashing a red LED when sending I can get the a pretty good monitoring output of the signals with '-DRTL_DEBUG=2'

Any other setting changes which I could try for *Fineoffset-WH65B** decoding?

Thanks

marrog86 commented 2 years ago

Hello, I am interested in trying out your code. I have an CC1101 433 Module on an Esp32 connected like OpenMqttGateway documented and an WH51 on 433 Mhz

Whats the best way to compile your code and getting my sensoors running? I have VSCode with Platformio running and opend the Project, but what do i need for the build target? There are several esp32 extensions.

Thanks!

donoghdb commented 1 year ago

@NorthernMan54 how do I go about adding oil_watchman.c to the decoders? Keeping my second PI running is breaking me :) https://github.com/merbanan/rtl_433/blob/master/src/devices/oil_watchman.c

cartwrightian commented 1 year ago

I have FSK working with a current cost energy monitoring device at 433 with FSK pulse PCM using a lilygo TTGO LORA32 V2.0. As noted elsewhere seems the sx1278 can either be in OOK or FSK mode, as I just needed to get things working with this one device this was not a problem for me.

The fork is here in case it's useful for anyone else looking at FSK reception https://github.com/cartwrightian/rtl_433_ESP_ic

NorthernMan54 commented 1 year ago

@cartwrightian I took a quick look at your changes, and they are rather straightforward, and as the changes to the radio receiver settings are exceptionally simple, would it make sense to use a slightly different design approach and have the switch between FSK and OOK modulation be a real time switch and not a compiler directive, similar to how receive frequency can be changed? This would reduce the number of pre built OMG binaries needed dramatically.

obones commented 1 year ago

So I take it that you simply changed setOOK(true) to setOOK(false) without changes to the frequency deviation and bandwith? And with this the sx1278 picks valid pulses that not full of noise? Looks very promising indeed

cartwrightian commented 1 year ago

@NorthernMan54 I had assumed there was no way to make the switch prior to the on-chip demodulation being complete, but quite possible I am misunderstanding things? @obones only slightly more than that, had to wire up the call to the fsk demod method as well, plus disable a few register settings that only apply in ook mode. I left everything else default which worked with my device, but I imagine for lower strength signals etc other tuning of the params will be needed.

NorthernMan54 commented 1 year ago

@AusGunno - If you want to give it a try, I was able to receive and decode the FSK signal from the sample FSK transmitter. For a receiver I was using a LilyGo board with the SX127x chipset. I will need to work with the CC1101 chipset setting before it will work.

N: Received message : {"model":"Fineoffset-WH51","id":"006b58","battery_ok":0.77778,"battery_mV":1400,"moisture":36,"boost":3,"ad_raw":210,"mic":"CRC","protocol":"Fine Offset Electronics/ECOWITT WH51, SwitchDoc Labs SM23 Soil Moisture Sensor","rssi":-41,"duration":9000}
N: Received message : {"model":"Fineoffset-WH51","id":"006b58","battery_ok":0.77778,"battery_mV":1400,"moisture":36,"boost":3,"ad_raw":210,"mic":"CRC","protocol":"Fine Offset Electronics/ECOWITT WH51, SwitchDoc Labs SM23 Soil Moisture Sensor","rssi":-40,"duration":9000}
N: Received message : {"model":"Fineoffset-WH51","id":"006b58","battery_ok":0.77778,"battery_mV":1400,"moisture":36,"boost":3,"ad_raw":210,"mic":"CRC","protocol":"Fine Offset Electronics/ECOWITT WH51, SwitchDoc Labs SM23 Soil Moisture Sensor","rssi":-42,"duration":9000}
rtl_433_ESP(7): Average RSSI Signal -100 dbm, adjusted RSSI Threshold -88, samples 50000
N: Received message : {"model":"Fineoffset-WH51","id":"006b58","battery_ok":0.77778,"battery_mV":1400,"moisture":36,"boost":3,"ad_raw":210,"mic":"CRC","protocol":"Fine Offset Electronics/ECOWITT WH51, SwitchDoc Labs SM23 Soil Moisture Sensor","rssi":-42,"duration":9000}
N: Received message : {"model":"Fineoffset-WH51","id":"006b58","battery_ok":0.77778,"battery_mV":1400,"moisture":36,"boost":3,"ad_raw":210,"mic":"CRC","protocol":"Fine Offset Electronics/ECOWITT WH51, SwitchDoc Labs SM23 Soil Moisture Sensor","rssi":-42,"duration":9000}

This is with the current master, and the latest commit from today. To enable FSK, you need to add the compiler directive,

'-DOOK_MODULATION=false'       ; False is FSK, True is OOK
NorthernMan54 commented 1 year ago

Tested and working with the latest code base