Author Topic: Receiving Zwave with RFM69  (Read 1362 times)

vc1234

  • NewMember
  • *
  • Posts: 5
Receiving Zwave with RFM69
« on: November 11, 2018, 10:19:29 PM »
I have a somewhat unusual application for RFM69 -- trying to use it to receive zwave signals to troubleshoot various problems.

Firstly,  I have to say that I already build a zwave receiver using a CC1110 development board two years ago, and it works reasonably well.  It appears that it can see all the frames on the air that the controller does withing a 30'-40' radius.  However, the board is not very portable, so I thought about using a moteino or an arduino pro either of which can be placed in a small box with a battery.

Programming an RFM69 was not too hard -- I just had to subclass a couple of functions, mainly to be able to receive unlimited length packets since the zwave frame has its length byte in position 7 as opposed to the standard variable length location than the RFM69 expects in position 0.

However, I've encountered two issues:

1. The RSSI settings below -90 cause too many false positives (as matched by the sync word) which is problematic because a typical zwave signal is usually  about -85 to -90 at about 25' from the source and some walls.  Interestingly and encouragingly, RSSI is about the same as indicated by my old probe at the same location.  The old probe has about a couple of false positives a day at a -100 RSSI threshold, though, so I have a much better measurement safety margin with it than with the RFM69.

2. The Manchester encoding used for the old R1 zwave devices does not quite work.  The datasheet is vague about it, but I suspect that Manchester simply does not work with unlimited length packets on the RFM69.  The CC1110 decodes the Manchester frames just fine.  This problem is less important because I have only 3 R1 zwave device but still unpleasant.

I've spent probably 95% time trying to improve signal selectivity with no success.  I tried changing LNA settings, RxBw, AutoAfc, preamble length to no avail.  Afc is especially tricky as it apparently puts the RFM69 chip into a state that only a power reset can cure it.

Here are my best performing settings.  If you have any helpful comments, they'll be appreciated:

Code: [Select]
 // Bitrate 40K:
  radio.writeReg(0x03, 0x03);
  radio.writeReg(0x04, 0x20);

  // Deviation 20K:
  radio.writeReg(0x05, 0x01);
  radio.writeReg(0x06, 0x48);
   
  // Zwave frequency:
  radio.setFrequency(908400000); //908.4 MHz

  // RxBw filter:
  radio.writeReg(0x19, 0x4A);       // 100 kHz *

  // RSSI threshold -90:
  radio.writeReg(0x29, 0xB4);

  // Preamble size 8:
  radio.writeReg(0x2D, 0x8);

  // Two byte sync:
  radio.writeReg(0x2E, 0x88);

  // Sync word:
  radio.writeReg(0x2F, 0xAA);
  radio.writeReg(0x30, 0x0F);

  // Packet cfg1 (Fixed length, no CRC):
  radio.writeReg(0x37, 0x0);

  // Payload length -- unlimited:
  radio.writeReg(0x38, 0x0);

The rest of the settings are the library defaults.


Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Receiving Zwave with RFM69
« Reply #1 on: November 12, 2018, 08:11:47 AM »
Very nice of you to share this, opens up an interesting range of new applications.
I looked at zwave very early even before coming up with the Moteino.
Are you able to communicate back to zwave devices in any way? Or is this just a 1way road for now?

vc1234

  • NewMember
  • *
  • Posts: 5
Re: Receiving Zwave with RFM69
« Reply #2 on: November 12, 2018, 10:04:52 AM »
The zwave protocol layers design, command set, etc.  had  been closely guarded by Sigma until recently.  Some parts of it have been successfully reverse engineered (the serial communication protocol). About a year ago, Sigma started to open some docs, and after Silicon labs acquired Sigma earlier this year more information appeared.  They even made public their RF sniffer code which used to cost about $1,500.  To my knowledge, they did not disclose the RF/MAC layer details and the routing protocol specifics, though.

Nothing of that was available three years ago when I got motivated by my malfunctioning lock and thermostats and could not find any tools to diagnose problems.  I stumbled over this: https://sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf, but their firmware did not work for me at all, so I wrote my own which was not very hard if you know the signal parameters and the frame layout.  This document was also helpful re. the frame layout: https://www.itu.int/rec/T-REC-G.9959-201501-I.

Yes, with CC1110 I can issue simple lighting commands as the lighting commands RF frame structure is pretty straightforward and the payload is in clear text (lock frames are encrypted). The thermostat commands are also in clear text and can be emulated easily as well. I did not try with my RFM69 implementation yet as I am trying to improve RFM69 low level signal capture -- I cannot go below -90 RSSI it seems.  With CC1110 I can capture at about -98 /-101, at least about 60% frames.

However, the application layer/overall command set is quite elaborate, so I do not think it's worthwhile to try and reproduce it all at the RF level. OpenZwave does it at the serial protocol layer and OpenHAB has an independent zwave serial protocol implementation that is better in some respects than OpenZwave.  When I say "serial protocol", it means that a typical zwave hardware implementation works as a "coprocesor":

zwave serial protocol commands -> UART of the zwave SoC->RF frames transmitted by the zwave SoC.