IM-ME Proof of Life

I have been making progress on using a Pretty Pink Pager as a receiver for the Davis Instruments Wireless Integrated Sensor Suite (ISS).  The ISS, in case you weren't aware, is the outside part of the weather station that records wind speed, wind direction, rainfall, temperature, and humidity.  Anyhoo, I got this going last night.

Click to Embiggen

Here is what this display is showing:

• Freq is the frequency the IM-ME is set to receive to, in Hz.  The hex value below that is the corresponding settings written to the FREQ2, FREQ1, and FREQ0 registers on the CC1110 processor in the IM-ME.  I wrote a simply Python script to make sure I was properly converting the raw frequency to the register values as a double-check.
• Chan is the channel ID.  The Davis system uses 51 channels for its Frequency Hopped Spread Spectrum (FHSS) scheme.  This really doesn't do anything.  Yet.
• Cal is the result of the frequency calibration executed using the RFST_SCAL command.  This value gets written to the FSCAL3, FSCAL2, and FSCAL1 registers on the CC1110 processor.
• RSSI is the current Received Signal Strength Indicator.  In other words, this is the received power picked up by the IM-ME.  It updates many times per second.
• Max is the good stuff.

I fired up my little program and watched as the RSSI value bounced around in the noise at a value of around 65 to 70.  Then I brought over my wireless console over and put it into diagnostics mode by pressing the TEMP and HUM(idity) buttons at the same time.  Pressing 2nd CHILL brings up a second display that shows the channel number the receiver expects the ISS to transmit next.

Just after the Davis console started scanning for Channel 0, the Max value of the RSSI jumped from around 70 to the 113 value shown above.  YES!  The IM-ME was seeing the power in the signal transmitted from the ISS.  This made me pretty happy to say the least as it proved out a number of things:

• I was properly calculating the frequencies based on the hex values sniffed when I worked out the Davis frequency hopping sequence.
• I was getting other basic aspects of the radio configuration correct.
• I can write a simple program.

The first bit about the frequencies being calculated correctly was a big deal.  I had been led to believe from some of the Davis FCC documentation that the 51 hop frequencies were evenly spaced by 500 kHz between 902.5 and 927.5 MHz.  The values I sniffed in the link above told a different story: the frequencies were only roughly aligned to that spacing, with significant deltas of 100 kHz or more in places.  I wasn't sure which was correct, and I wasn't prepared to take my ISS to work to look at the signal on a spectrum analyzer to find out.

One thing I built in to my little test program was the ability to adjust the center frequency of the radio in steps as large as 1 MHz and as small as 1 kHz.  This let me tune to other channels in the hop sequence.  If I saw a big spike in the RSSI value at the right time, I would know that I wasn't getting lucky on just the first channel.  And indeed, I was able to tune to the next calculated channel frequency and watch the Max RSSI value jump up at the right time in the sequence, as expected

As far as being able to write a simple program, that is probably overstating it a bit.  If it weren't for the amazing work by Michael Ossman, who wrote the IM-ME spectrum analyzer on which my program is based, I'd be totally screwed.  Michael, in turn, based his work on an earlier reverse engineering effort on the IM-ME at Dave's Hacks. And so on down the line it goes.  I will of course share whatever I come up with once things get further along.

So I can see the power in the signal now, but I'm still a ways off from getting actual data.  The first problem that I have to overcome is determining how the ISS sends synchronization and preamble information to the console.  I never really realized how much this involved until I dug in to it this weekend.  The CC1021 in the ISS and the console leaves this chore to the firmware of the processor controlling it.  The CC1110 does a lot more to handle this automatically, but you still have to tell it what to look for.  And the problem is I don't know what to tell it to look for: that information isn't available for sniffing on the SPI bus.  What I think I'm going to have to do is open up the console yet again and look at the signal lines that carry the data bits back and forth between the CPU and the radio chip.

Stay tuned.