search

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
492 stars 110 forks source link

Question/contact #6

Closed cpainchaud closed 3 years ago

cpainchaud commented 3 years ago

Hi!

I am writing here because I didn't find your email.

I just realized you and I had been hacking around the same topics (ESP32 based 433mhz/home sensors) and toying wit the same projects (RFLink-ESP, RTL433...) and realized it would be wonderful to be able to use RTL433 on an ESP32 and you took this step further with this project.

Currently I am fairly busy with my ESP32 fork of RFLink (https://github.com/cpainchaud/RFLink32 https://github.com/cpainchaud/rflink-webui) which is to date the most advanced fork/rework with full UI/CLI configurations (no more recompilation!), support of several Radio modules (SX12XX, RFM69...) and replay/test capabilities among other things.

Anyways I do feel the limitations of RFLink approach to rely on a classic demodulator/transceiver and polling it constantly and also fore us to stick to 1 frequency/channel ; but I have yet failed to find a piece of hardware which would sample several channel (so we could cover FSK, 2FSK etc).

I see here that you are using CC1101 and from the little I could you are using it in packet mode but how could that work without knowing first what frequency/channel/bitrate/message length in first place? am I mistaken? RTL433 uses a SDR/sampling method to get their data which is not your case thus I am curious to understand how you're going to approach this with a standard transceiver.

NorthernMan54 commented 3 years ago

For my implementation of the signal receiver logic I'm using the signal RSSI level to indicate start and end of signal

https://github.com/NorthernMan54/rtl_433_ESP/blob/38ee89a37772320be595b4aceb10c5b5f7f7d693/src/rtl_433_ESP.cpp#L356

Which I found works significantly better than some of the other approaches I have seen with watching for a long signal gap, but limits the implementation to receivers that support RSSI.

In regards to frequency and frequency/channel hopping, I feel that this is a real challenge. I did try having the receiver jump between various frequencies, but found I missed the early portion of a lot of signals and the decoding become challenging. So I parked that.

With the CC1101 receiver demodulation is occurring within the receiver module itself and not in software which is what rtl_433 is doing. Currently the CC1101 receiver is operating in ASK demodulation mode, and I have fork where I'm looking at enabling the FSK demodulators.

https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/blob/50512abf62a4b86c457426f142ae05d1faff5aa3/ELECHOUSE_CC1101_SRC_DRV.cpp#L347

Taking this up a level now, and getting to your original question in regards to the packet mode of the CC1101, and I'm not using packet mode and am just using it as a basic receiver. I chose not to leverage the advanced features of the CC1101 so I could implement generic signal decoder logic and feed that into the rtl_433 codebase. This allows me to not know the message bitrate, message length and pulse structure when receiving a signal. But stay within a particular modulation scheme.

cpainchaud commented 3 years ago

Thank you for taking the time to reply.

In have been using RSSI as well in my RFLink32 for a few months ( with RFM69 and SX1278 ), it helped a lot to detect the beginning of a message like you said.

I also started a FSK branch but I am currently hitting a wall because devices are not using the same channel bandwidth so my pulses are way too corrupted for the moment.

Ideally I am looking to replace RFlink outdated Plugin structure with RTL433 so your project interests me a lot. I might work on a new branch in my project which would use your project to decode packets.

I will be watching (and potentially contributing), thank you!

NorthernMan54 commented 3 years ago

I would gladly accept pull requests with additional functionality, much appreciated

When it comes to additional receiver modules I have a similar request from another party in regards to supporting additional modules so I will add that to the roadmap. The current CC1101 dependancy is pretty light ( just RSSI ) so supporting additional chipsets seems pretty simple.

When you look at the codebase, please keep in mind that with the initial port my focus was on making it work with minimal / no changes to the rtl_433 codebase, but not efficiency. I'm not 100% comfortable with memory footprint and how I linked in the code ( the memcpy block ) and at some point want to look at alternate approaches and further simplify keeping the code in sync with the main rtl_433 codebase.