433MHz FSK Receiver modules

Hi,
Well I seem to be quite a way from understanding the HopeRF RFM01, given that it's presenting my FSK signal (post #5) as :-

The original signal in #5 looks quite "OOK-Like" (which of course has only two levels) so it may be that you don't need the RSSI signal. It might avoid wasting time trying to decode "data" when there is no useful signal, but a major issue can be the congestion of the 434 MHz band. So there might be a "useful" RSSI level, but not of FSK data, or for the Data that you're actually trying to capture.

A problem with data streams of this complexity is fitting enough information into a single screen image. Most Oscilloscopes seem to be "sampling" types now; with yours showing 5 ms/div, the sampling rate is probably 0.5 ms or 0.25 ms, which is probably insufficient to record all of the data samples. You really need at least two samples per timeslot. Even the low cost "24 MHz" Logic Analysers can take millions of samples with sampling rates of around 1 - 10 us and then you can "zoom in" as required. But also, use the 'scope as a sanity check, that the LA sampling threshold (typically around 1.5 volts) will give sensible results.

The Logic Analyser should also be able to decode Manchester Coding, whose appearance is not intuitive because the data is carried on the Edges of the square wave. It's also known as Phase Encoding because, for example, 000000... and 111111... appear as an almost identical "High frequency" waveform, whilst 0101010101... appears as a "Low(er) frequency. ;)

Cheers, Alan.
 
I've have also got the Logic Analyser hooked up - but the results are the same.

One thing I've not yet seen is the "preamble", which ought to be very obvious. I didn't know if the Si4320/RFM01 would treat this as some sort of 'magic' and not o/p it, but reading through some of the questions in the Silabs forums, seems to indicate that it should be there.

The device seems to be understanding that there is a signal - in the shape of those two 25mS pulses; it's just the decoding of the two frequencies within the transmisson, that I've not got right yet.

Seeing the same (wrong) output twice, would be a start - but I don't think I'm even at that stage yet :(
 
Hi,

The only other thing I can suggest is: "Is the carrier frequency from the Fob correct?" 433 MHz is a "band", where I believe the majority of "License Exempt" ISM devices actually use 433.92 MHz, which is why it's often called 434 MHz. I think I saw that the RFM01 is set to that frequency, but didn't notice the bandwidth (both of which should be adjustable by using the SPI bus).

The RSSI output is probably low-pass filtered, so wouldn't show if one of the FSK frequencies was out of band, but it would probably show some delay relative to the FSK data stream.

Cheers, Alan.
 
I think I've addressed that. The RFM01 is marked to show which frequency it is intended for, but it turns out that that is just some sort of 'default'.

My "434MHz" module has no difficulty picking up signals on 868MHz as well - even with an inappropriate aerial. Using SDR#, I ascertained that the Fob uses approx. 433.96 and 433.87Mhz as its two frequencies, so the centre is at 433.915MHz and that's what I've configured it for.
According to the datasheet, the default "synthesizer centre frequency" works out as 432.08MHz...which doesn't make a whole lot of sense.

I have tried a few different settings for 'bandwidth' as well, but with no effect so far.

Additionally, I have tried changing the Data Rate (through its entire range, but in quite coarse steps). This radically changes the appearance of the output data stream, but does not produce anything recognisable (or repeatable).

I tried to get my 'scope to trigger on that 800uS start pulse, but I can't find any valid data doing that either :(

The RSSI output is probably low-pass filtered, so wouldn't show if one of the FSK frequencies was out of band, but it would probably show some delay relative to the FSK data stream.

The RSSI output is controlled by the VDI pin configuration (part of Command #3, Receiver Setting Command) :-

d1d0VDI Output
00Digital RSSI Out (DRSSI)
01Data Quality Detector o/p (DQD)
10Clock Recovery Lock
11DRSSI && DQD

The level at which DRSSI goes high, is no doubt configurable, but the default setting gives me my promising 25mS pulses when the Fob transmits (reflecting the envelope of the entire signal).

DQD gives a high signal, which goes low at seemingly random intervals ... for 25uS or thereabouts!?!

The last two variants, just give me a permanently high signal.


While scouring the web, I came across this old conversation:


(The Apollo Watchman uses the Si4320 ... and I happen to own one...)

Sadly, the conversation peters out with no real resolution; they retreated into the world of SDR and integrated it into RTL_433.
 
Last edited:
I had a thought ...

"If the RFM01 is seeing both the FSK frequencies successfully, why not try detuning it so it can only hear one. May be the DRSSI o/p will then reflect that single frequency (which is the data signal I'm seeking)."

It didn't work :cry:

I can tune the RFM01 well outside the allowed limits of the datasheet and still get noisy 'data' and a valid looking DRSSI representing the signal 'envelope'. (I turned the AFC off).

The data sheet says to use setting values between 96 and 3903. (It says invalid values are ignored - but they're not, so I tried 0-4095).

Below 430.1375MHz, the module misbehaves 'big time', but this is below the supposed allowed minimum of 430.24MHz. At the lowest useable setting (430.1375MHz), there is noticeably no background data signal - it's only present when DRSSI (ie. VDI) goes high. The background noise gets progressively worse as the frequency increases and is constant by the time the supposed minimum frequency is reached.

I think that maybe DRSSI is being raised to say "there is a signal", not "there is a valid signal"). I'm not convinced I am decoding a valid signal and this may be due to the short preamble. I know it is only 8 bits long and various sources say it should be at least 16. Of course, I can't change it :(

Frequencies.png
 
Last edited:
I made some progress; I decided to fire-up the RFM02 transmitter and see if I could get the RFM01 to receive that.

I succeeded - sort of - and sent some asynch serial data, which was generated by the 20X2's HSERSOUT, running at a custom bit rate of 5000bps. I have been using 5000bps to-date, because the signal I am trying to receive, seems to use multiples of 200µS. Of course, asynch data is a bit 'lumpy', because of Start/stop bits, inter-byte gaps etc.

I ended up with a signal that could be received (almost) perfectly by RTL_433 (ie SDR) and on one or two occasions appeared at the Dout pin of the RFM01. It wasn't perfect, and only appeared very occasionally, but it represents the only data I've managed to receive!

Key:-
  1. Signal at the RFM01 (receiver) Dout pin.
  2. Signal at the RFM01 VDI pin(configured as RSSI)
  3. Data Clock o/p of the RFM01. Seems to match the 5kbps data-rate that is set.
  4. Modulating data, sent to the FSK (in) pin of the RFM02 transmitter. I manually added 16 on/off transitions of 200µS each, as a preamble. They did not all 'arrive'
Somehow, Dout and VDI at the receiver, both go HIGH before the transmitter starts sending. Presumably, this is just in response to hearing the carrier frequency?...

AsynchDataat5Kbps.png

Flushed with this success :rolleyes: I set about writing code to emulate my Hyundai Fob. I added an additional 8 'Preamble' bits for good measure and RTL_433 (SDR) cannot tell it apart from the actual Fob. It is reliably received by RTL - but not at all by the RFM01 :(

On the RFM01, I just get VDI and Dout as constant high signals throughout the duration of the transmission, but there is no sign of any 'demodulation'.

Anyway, onwards and upwards ;)
 
Last edited:
I ended up with a signal that could be received (almost) perfectly by RTL_433 (ie SDR) and on one or two occasions appeared at the Dout pin of the RFM01. It wasn't perfect, and only appeared very occasionally, but it represents the only data I've managed to receive!

It turns out it's all been working, for a while ... sometimes :rolleyes:

My code initialises the RFM01/Si4320 and then just sits in a loop, pausing for a second - all monitoring of the RFM01 being external. About 8 in every 10 starts, it apparently fails to initialise properly, but every now and then it works ❗

(It's not a power-cycle thing; I put a switch-initiated RESET in the 20X2's delaying loop and that is sometimes enough to make it spring into life).

There are lots of timing details in the datasheet that I suspect I'm not honouring at the moment!

But I finally got to see the response from my Hyundai Fob, in all its glory :-

EvenMoreProbeAndReplyTiming.jpg

UPDATED 23/11/24

It seems it wasn't so much 'timing', as the order of the 'commands' I was sending to the RFM01. I'd reorganised all the example code into the order that the datasheet presents the (numbered) commands, that the module understands.

It seems that Command #3 Receiver Setting Command needs to come near the end of the initialisation, because one of the things it can do, is "Enable the whole receiver chain". However, it seems that the "whole receiver chain"- once enabled - ignores some of the subsequent settings!
 
Last edited:
Back
Top