GNURadio Companion Blocks for Z-Wave using RTL-SDR dongle

Question

I'm using RTL-SDR generic dongle for receiving frames of Z-Wave protocol. I use real Z-Wave devices. I'm using scapy-radio and I've also downloaded EZ-Wave. However, none of them implements blocks for all Z-Wave data rates, modulations and codings. I've received some frames using original solution of EZ-Wave, however I assume I can't receive frames at all data rates, codings and modulations. Now I'm trying to implement solution according to their blocks to implement all of them.

Z-Wave procotol uses these modulations, data rates and coding:

9.6 kbps - FSK - Manchester 
40 kbps - FSK - NRZ
100 kbps - GFSK - NRZ

These are my actual blocks (not able receving anything at all right now):

For example, I will explain my view on blocks for receiving at

9.6 kbps - FSK - Manchester

RTL-SDR Source

variable center_freq = 869500000

variable r1_freq_offset = 800e3

Ch0: Frequency: center_freq_3-r1_freq_offset, so I've got 868.7 Mhz on RTL-SDR Source block.

Frequency Xlating FIR Filter

Center frequency = - 800Khz to get frequency 868.95 Mhz (Europe). To be honest, I'm not sure why I do this and I need an explanation. I'm trying to implement those blocks according to EZ-Wave implementation of blocks for 40 kbps-FSK-NRZ (as I assume). They use sample rate 2M and different configurations, which I did not understand.

Taps = firdes.low_pass(1,samp_rate_1,samp_rate_1/2,5e3,firdes.WIN_HAMMING). I don't understand, what should be transition bw (5e3 in my case)

Sample rate = 19.2e3, because data rate/baud is 9.6 Kbps and according to Nyquist–Shannon sampling theorem, sampling rate should be at least double to data rate, so 2*9.6=19.2. So I'm trying to resample default 2M from source to 19.2 Kbps.

Simple squelch

I use default value (-40) and I'm not sure, if I should change this or not.

Quadrature Demod

should do the FSK demodulation and I use default value of gain. I'm not sure if this is a right way to do FSK demodulation.

Gain = 2(samp_rate_1)/(2*math.pi*20e3/8.0)*

Low Pass Filter

Sample rate = 19.2k to use the same new sample rate

Cuttoff Freq = 9.6k, I assume this according to https://nccgroup.github.io/RFTM/fsk_receiver.html

Transition width = 4.8 which is also sample_rate/2

Clock Recovery MM

Most of the parameters are default.

Omega = 2, because samp_rate/baud

Binary Slicer

is for getting binary code of signal

Zwave PacketSink 9.6

should the the Manchester decoding.

I would like to ask, what should I change on my blocks to achieve proper receiving of Z-Wave frames at all data rates, modulation and coding. When I start receiving, I'm able to see messages from my devices at FFT sink and Waterfall sink. The message debug doesn't print packets (like from original EZ-Wave solution) but only

Looking for sync : 575555aa
Looking for sync : 565555aa
Looking for sync : aa5555aa

what should be value in frame_shift_register, according to C code for Manchester decoding (ZWave PacketSink 9.6). I've seen similar post, however this is a bit different and to be honest, I'm stuck here.

I will be grateful for any help.

score 2 · Answer 1 · answered Mar 11 '19 at 10:06

Let's look at the GFSK case. First of all, the sampling rate of the RTL source, 2M Baud is pretty high. For the maximum data rate, 100 kbps - GFSK, a sample rate of say 400 ~ 500kbaud will do just fine. There is also the power squelch block. This block prevents signals below a certain threshold to pass. This is not good because it filters low power signals that may contain information. There is also the sample rate issue between the lowpass filter and the MM clock recovery block. The output of the symbol recovery block should be 100kbaud (because for GFSK, sample rate = symbol rate). Using the omega value of 2 and working backward, the input to the MM block should be 200kbaud. But, the lowpass filter produces samples at 2Mbaud, 10 times than expected. You have to do proper decimation.

I implemented a GFSK receiver once for our CubeSat. Timing recovery was done by the PFB block, which is more reliable than the MM one. You can find the paper here: https://www.researchgate.net/publication/309149646_Software-defined_radio_transceiver_for_QB50_CubeSat_telemetry_and_telecommand?_sg=HvZBpQBp8nIFh6mIqm4yksaAwTpx1V6QvJY0EfvyPMIz_IEXuLv2pODOnMToUAXMYDmInec76zviSg.ukZBHrLrmEbJlO6nZbF4X0eyhFjxFqVW2Q50cSbr0OHLt5vRUCTpaHi9CR7UBNMkwc_KJc1PO_TiGkdigaSXZA&_sgd%5Bnc%5D=1&_sgd%5Bncwor%5D=0

Some more details on the receiver could also be found here: GFSK modulation/demodulation with GNU Radio and USRP

M.

score 1 · Answer 2 · answered Mar 12 '19 at 21:18

1

I appreciate your answer, I've changed my sample rates. Now I'm still working on 9.6Kbps, FSK demodulation and Manchester decoding. Currently, output from my M&M clock recovery looks like this:

I would like to ask you what do think about this signal. As I said, it should be FSK demodulation and then I should use Manchester decoding. Do I still need usage of PCB block? Primary, I have to do 9.6kbps, FSK and Manchester, so I will look at 100Kbps GFSK NRZ if there will be some time left.

answered Mar 12 '19 at 21:18

2

The polyphase filter bank (pfb) timing recovery is an alternative to MM clock recovery. There are of course other timing recovery algorithms (Gardner, early-late etc). When there is no ISI, the frequency response of the output of the timing recovery block should be flat. I therefore think something is not right with your flowgraph. The peak looks like a shifted DC offset to me. I also notice that you do low-pass filtering twice. Is there any particular reason for that? Btw, it will be easy for us to help if you could upload the picture of the modified flowgraph. – Moses Browne Mwakyanjala Mar 13 '19 at 00:53
1

I've responded using the Asnwer because of the character count limitation of comments and links. – Mar 13 '19 at 11:48

score 1 · Answer 3 · answered Mar 13 '19 at 11:39

Sample rate is 1M because of RTL-SDR dongle limitations (225001 to 300000 and 900001 to 3200000).

Current blocks:

I don't understand :

Taps of Frequency Xlating FIR Filter firdes.low_pass(1,samp_rate_1,40e3,20e3,firdes.WIN_HAMMING)

Cuttoff Freq and Transition Width of Low Pass filter

Clock Recovery M&M aswell, so consider its values "random".

ClockRecovery Output:

I was trying to use PCB block according to your work at ResearchGate. However, I was unsuccessful because I still don't understand all that science behind the clock recovery.

Doing Low-pass filtering twice is because original Z-Wave blocks from scapy-radio for 40Kbps, FSK and NRZ coding are made like this (and it works):

So I thought I will be just about changing few parameters and decoder (Zwave PacketSink9.6).

I also uploaded my current blocks here.

score 0 · Answer 4 · answered Mar 18 '19 at 00:32

Moses Browne Mwakyanjala, I'm also trying to implement that thing according to your work.

Maybe there is a problem with a clock recovery and Manchester decoding. Manchester decoding use transitions 0->1 and 1->0 to encode 0s and 1s. How can I properly configure clock recovery to achieve correct sample rate and transitions for Manchester decoding? Manchester decoder (Z-Wave PacketSink 9.6) is able to find the preamble and ends only with looking for sync.

I would like to also ask you, where can I find my modulation index "h" mentioned in your work?

Thank you

GNURadio Companion Blocks for Z-Wave using RTL-SDR dongle

4 Answers4