Temperature Sensors: La Crosse Technology IT+ Decoding

In the continuation of using commercial sensors for reason explained on that page, here is a new post on the last change I made to the project: using La Crosse Technology IT+ sensors.
After approximately one year of usage on two sites, it came that Oregon sensors are not very satisfying, at least for me. Main drawback I saw is the range, which is not so high.
I think it’s partly due to the 433 MHz band used, so I started since a few months investigations on 868 MHz.
I found the La Crosse Technology TX29 IT+ sensors very interesting, and very affordable.
Unfortunately, I where not able to decode the protocol used. First the hardware: after opening the box, I saw that the RF receiver looks like a RF12 transceiver (the one that is bundled with the Jeenode), but Google queries did not give any hint on the reference printed on the module.

I was even not able to say if it is using FSK or OOK.
I considered getting an analyser, but finally renounced.

But recently, I found someone very motivated (the least to say: very impressive work!) that analysed signals on the pins and decoded exchanges on what ended up to be SPI dialogs.
The author even give details on the CRC calculation!
Bingo! The module IS something of the same family as the RF12, and enough information is given on the site to decode the protocol and check CRC.
In that case, I considered not doing the same I did for Oregon sensor, e.g. using the receiver that come with the temperature station, but using directly the Jeenode RF12 transceiver that is in my so called “central node” (see here) to receive IT+ frames.
On that, I found additional help on this post to go ahead, but did not follow strictly what others did.

The result is that with some slight changes in Jeenode parameters like baud rate & RF frequency, I got compatibility with both protocols.
If someone is interested, I can explain in more detail what I did. Otherwise, you can look into the code.
As a summary, I added:

a flag entitled “ITPlusFrame” that tells if a frame just received is a Jeenode protocol or an IT+ frame.

Here is code excerpt of usage:

C++

1

2

3

4

5

6

7

8

9

10

11

12

13

14

// Initialize as usual, BUT:

// NodeID MUST be < 32 (higher bit = 0)

// AND NetGroup MUST = 0xd4, the one used by IT+

rf12_initialize(1,RF12_868MHZ,0xd4);

// Override some parameters

rf12_initialize_overide_ITP();

// Then, just after rf12_recvDone(), a check on ITPlusFrame tells what to do:

if(rf12_recvDone()){

// Is it IT+ or Jeenode frame ?

if(ITPlusFrame)

ProcessITPlusFrame();

else{

if(rf12_crc==0){

// Process JeeNode frame here

Patching directly the library is not very nice, but I did not find another solution yet. Jean-Claude, the JeeNode designer is too busy at that time to think about that, and as I had also to patch the Ethernet library for my project, I continued on that approach.
Also, we can say that this mod is breaking some good properties of the protocol (or best wishes from the designer), as for instance lowering at the maximum power consumption, as we have to slow down baud rate to meet IT+ specs, which is making the transmission longer, hence consuming more power.
To go further, receiving frame is not enough, there is some tricky paring between sensors and receiver station to be implemented too.
I guess that this pairing is part of the low cost of this device: it enables having a lot of different channels (up to 64) on the IT+ protocol without having switches on sensors to set channel.
Principle is that a channel number is randomly chosen by transmitter upon initialisation. The transmitter will use this channel ID forever, up to the next initialization (battery change). To help pairing, a flag telling the transmitter is in this pairing phase is set during approximately 4h30mn.
On the other end, the receiver is looking for such transmitter in pairing phase during it’s initialisation.
I implemented the pairing using the WEB interface implemented on the central node, in the setup page.
In my implementation, it’s still possible to “pair” a sensor that is no more in pairing phase. To help the process, the interface displays the temperature of the detected sensors to help distinguishing them.
Again, I don’t give full detail on this page. If someone is interested, I can explain in more detail what I did. Otherwise, you can look into the code.
Here is the patched RF12 library.
Here is the complete code for the new central node (Arduino IDE Sketch).