-
-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for FSK Modulation - WH51 Soil Moisture sensor #5
Comments
@NorthernMan54 Will work on this tonight. time : 2021-04-06 13:21:09 Noting that the bit buffer seems to be out of sync by 1 bit. 55 <<1 = AA (Sync), Given that this actually has a well defined packet 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. |
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. |
Sounds like your getting close |
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 Problem is the CC1101 is inserting the packet length byte (0e) into the stream, so it will not decode. |
I would say that you have nailed it
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
Now onto the next phase, getting this to work within the rtl_433_ESP |
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 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 |
Tks for finding that I have updated the example in the FSK branch with this 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. |
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 ;) |
@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. |
@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
which to me sounds it needs the classic FSK pulse detector mode for its recognition. In fineoffset_wh1080.c I can also see
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. |
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. |
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. |
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
every 16 seconds, as expected. So the station stays and I'm ready for more testing with rtl_433_ESP. |
Status on the FSK Project Backlog [x] Addition of FSK device decoders to the build [ ] Demodulate signal pulse train into rtl_433 device decoders 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. |
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
|
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.
|
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 :) |
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. 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 |
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.
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. |
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 |
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 LSatan/SmartRC-CC1101-Driver-Lib#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.
|
I have updated the first comment into a tracker of release status of this feature. |
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. |
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 GitHub<#5 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AK7B7UY3TD3TQSHZRUZ6E7TTKDOYRANCNFSM42NKX62A>.
|
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. ;) So i need a solution which supports both OOK + FSK. |
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. |
but with the fsk branch - i can already try it? |
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. |
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. |
Hello, |
@obones To try out the FSK sample, try opening VSCode in the 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
This was on MacOS, and I had the library installed in the ~/Code directory |
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 But maybe I completely misunderstand the way this project is supposed to work. |
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. |
Thanks, I was able to compile the |
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. |
@NorthernMan54 I've been digging out my weather station again after seeing others are testing the FSK example more recently. With setting
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 |
Hello, I am interested in trying out your code. Whats the best way to compile your code and getting my sensoors running? Thanks! |
@NorthernMan54 how do I go about adding oil_watchman.c to the decoders? Keeping my second PI running is breaking me :) |
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 |
@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. |
So I take it that you simply changed |
@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. |
@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.
This is with the current master, and the latest commit from today. To enable FSK, you need to add the compiler directive,
|
Tested and working with the latest code base |
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
The text was updated successfully, but these errors were encountered: