Author Topic: Transmitting to standard temperature sensor receivers  (Read 3640 times)

kalbanowski

  • NewMember
  • *
  • Posts: 4
Transmitting to standard temperature sensor receivers
« on: May 05, 2014, 01:35:44 AM »
Hi folks; I thought I'd leave some notes here after I achieved my original goal for some R4/RFM69W Moteino boards: transmitting in the Oregon Scientific 3.0 temperature sensor format, at least closely enough that an RFXtrx 433 USB can pick up my packets just as well as those from OS's own temperature/humidity senders. This was for a home automation project where I wanted to interface my own sensor nodes with existing automation equipment.

While there's some existing documentation of the format, particularly http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf, I found some of it ambiguous, particularly the exact clock rates and bit ordering, which is then made more complicated by trying to set up the RMF69 for Manchester encoding with a specific sync word -- get just about anything wrong, and packets are dropped on the floor.

The basic (low-level) pieces of the protocol are:
    Chip rate (raw data data) = 2048 bits per second.
    Message bit rate = 1024 bits per second.
    Message bits are Manchester encoded, 0=0/1, 1=1/0 (raw bits, in time order).
    OOK modulation is used (raw bit 0 = 0hz, raw bit 1 = 433.92Mhz).
    OS3 packets are built out of nybbles, which are sent/encoded from least to most significant message bit, timewise.
    (All nybble values I'll mention below are numeric values, not a direct representation of a timewise bit sequence.)
    OS3 packets have a preamble of 24 raw 1/0 bit sequences (aka 6 encoded 0xF nybbles).
    OS3 packets have an initial sync word of 8 raw bits: 0/1/1/0/0/1/1/0, timewise (aka 1 encoded 0xA nybble).
    OS3 packets have different lengths, each type of packet has a specific length, and there is no data value in the packet which directly gives its length (especially not the first byte.)
    OS3 packets do not start with a single 'address byte'.

To relate this to the RFM69, first let's go through the raw bits, and do the manchester decoding ourselves:
   
    We receive a byte on the RFM69: 0x56
    The bits were received most significant bit first, least significant last, timewise.
    Looking at the individual bits in time order, we get: 0/1/0/1/0/1/1/0.
    Following the Manchester encoding, we decode each pair of bits: 0, 0, 0, 1.
    Finally, turn that into a nybble in OS3 packet order, and we get the numeric nybble value: 0x8

Now we can configure the RFM69 to transmit, including auto Manchester encoding:

    Frequency = 433.92Mhz
    Bitrate = 2048
    Modulation = OOK
    Packet config = Fixed, Manchester, CRC disabled, Address filtering disabled
    Preamble, LSB = 6, rest are 0
    Sync config = On, 1 byte
    Sync value 1 = 0x66
    Payload length = length of packet you want to send, in message nybbles/2. Do not include the preamble or sync nybbles in this count.

For each two nybbles we want to transmit in time order, with numeric values X and Y, we put a byte in the RMF69 FIFO consisting of the bits swapped into the right order:

      (( X & 8 ) ? 0x10 : 0x00) |
      (( X & 4 ) ? 0x20 : 0x00) |
      (( X & 2 ) ? 0x40 : 0x00) |
      (( X & 1 ) ? 0x80 : 0x00) |
      (( Y & 8 ) ? 0x01 : 0x00) |
      (( Y & 4 ) ? 0x02 : 0x00) |
      (( Y & 2 ) ? 0x04 : 0x00) |
      (( Y & 1 ) ? 0x08 : 0x00)

If you're transmitting an odd number of nybbles, you'll still have to put something in the last bits, but it didn't matter to my receiver. (Unless you turn off auto Manchester encoding and do it yourself, you cannot keep the air quiet for such odd four last message bits.)

It's entirely possible to do the Manchester encoding yourself, in software. The configuration for the RFM69 is the same, same bitrate, same sync value, only the payload length needs to be the number of nybbles to transmit, and each payload byte needs to be built out of the manchester encoded bits of a single nybble.

I did have to set up a custom transmit routine to ensure that I didn't send a length or address byte, and everything was in the FIFO and ready to send before waking and enabling transmission. (One interesting problem I ran into was transmission starting too early and exhausting the FIFO, which lead to an extra preamble transmitted in the middle of the packet.)

This configuration works for reception as well, though I haven't yet gotten a receiver working 100%: I've picked up lots of valid packets, but then they fade out, and I haven't had much luck in getting it to work consistently. I expect I just don't have a good enough idea (or examples) of how to set the RF reception tuning parameters, especially for OOK.

One tip I'll suggest to folks (especially those like me who have limited RF experience) is that it was invaluable to be able to record and visualize raw RF data: a PC with a $20 NooElec SDR USB receiver, the free SDRSharp software for recording, and Audacity for displaying, made it very affordable and easy to look at the chunk of the spectrum that these devices are transmitting in, and compare OOK transmissions without having to configure an RFM69 or other specialized receiver in just the right way to demodulate, decode and accept the data. Just adjust the encoding parameters until the waveforms visibly match. :)

Felix, thanks for designing and producing the Moteinos, they've been great fun, and the R4s have been very robust, and completely lived up to expectations. My next challenge is to get these nodes to be as low power as possible.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Transmitting to standard temperature sensor receivers
« Reply #1 on: May 05, 2014, 07:58:51 AM »
Felix, thanks for designing and producing the Moteinos, they've been great fun, and the R4s have been very robust, and completely lived up to expectations. My next challenge is to get these nodes to be as low power as possible.
Thanks so much for the kind feedback and for sharing your solution!

bennyboom

  • NewMember
  • *
  • Posts: 1
Re: Transmitting to standard temperature sensor receivers
« Reply #2 on: May 06, 2018, 04:36:11 PM »
Hello

I trying to use an Atmega328 with a RFM69 to send temperature as it was Oregon Scientific sensor.
But I don't know how to program arduino to dial with RFM69 and send temperature .
Could you share you program please ?

Thanks a lot,

Regards

Ben