Author Topic: RFM01 communicate with RFM69  (Read 2806 times)

CCob

  • Newbie
  • *
  • Posts: 2
RFM01 communicate with RFM69
« on: October 13, 2015, 05:56:32 PM »
Hi,

I wonder if someone could help.  I am trying to receive packets from an RFM01 transmitter from a CurrentCost electricity CT based transmitter.  I am trying to configure an RFM69 and it's corresponding registers to be compativle with the RFM01

So far I have been following the sterling work of Jack Kelly who has managed to do the same with the RFM12b here, http://jack-kelly.com/sniffing_spi_data_from_my_current_cost_envir

I can configure the RFM69 with the correct bit rate, frequency range, one byte premable along with a 2 byte sync word, fixed packet length of 21 bytes.  I have disabled any CRC checks as these are not used on the transmitter side, but so far all I seem to be getting is garbage.

Just wondering if anyone has had this working.  I have seen work from various places which has made it's way into the PowerLabs github repos on getting the RFM12b receiving packets from an RFM69, but not the other way.

Any help would be appreciated.
Thanks

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: RFM01 communicate with RFM69
« Reply #1 on: October 13, 2015, 09:12:19 PM »
Unless you are absolutely constrained to having to receive packets from RFMXXX to RFM69, I would highly recommend looking to replace the RFMXXX with RFM69, this not only gives you a boatload more features but you will thank yourself later for making your life easy.
Otherwise this is a blog post I wrote about RFM12B - RFM69 RF compatibility, perhaps a place to start. I know nothing about a "RFM01".

CCob

  • Newbie
  • *
  • Posts: 2
Re: RFM01 communicate with RFM69
« Reply #2 on: October 14, 2015, 03:34:37 PM »
Hi Felix,

Thanks for the reply.  Unfortunately I cannot control the transmitting end, as it's an OEM CurrentCost device.  The RFM01 inside is indeed compatible with the RFM12b as Jack Kelly has done this already with and RFM12b receiving packets from the device.  But so far I cannot yield the same results with the RFM69. I think part of the problem is the RegRxBw has limited channel filter bandwidth that doesn't match that of the RFM12b.  The closest I can get is 62.5Khz, but the transmitter has a channel bandwidth of 67Khz.

Thanks.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: RFM01 communicate with RFM69
« Reply #3 on: October 14, 2015, 10:01:06 PM »
Ok, sorry I cant help more, unless others have something to add here perhaps.
If you make progress please come back and post your findings.
-Felix

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: RFM01 communicate with RFM69
« Reply #4 on: October 15, 2015, 11:31:37 AM »
The CostCurrent packet trace implies that there is a single TX preamble byte. This will be tough for an RFM69 to lock on to since it is below the minimum length specified.
The Rx BW setting is a red herring - provided the Rx BW is greater than the transmit spectrum -20 dB width (+ some allowance for misalignment of the two crystals), it has little effect on decoding FSK.  if the Rx signal is well above the noise floor, setting it somewhat wider will be fine.
Printing the RSSI level alongside your 'junk' packet trace would be helpful, though it is only meant to be valid after preamble detect triggers.

rinie

  • Newbie
  • *
  • Posts: 3
Re: RFM01 communicate with RFM69
« Reply #5 on: October 18, 2015, 04:31:51 AM »
RFM01 is the chip used in Lacrosse IT+ transmission that can be received by RFM12b or RMF69.
Working code to receive IT+ or WS1600 (on 868MHZ) is at https://github.com/rinie/LaCrosseITPlusReader
Same code with a switch between Jeenode (RFM12b) and Moteino (RFM69) is used.

See http://fredboboss.free.fr/articles/tx29.php for links (he did the original RMF01 SPI sniffing for IT+) and
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip?format=raw for the original software

Regards,
 Rinie