Peeling Back The Layers of the Onion

In my "past life", I worked with a guy who was designing a Phase Lock Loop (PLL) for a receiver that HAD to work if the company could possibly succeed (the company eventually failed, but for other reasons).  The chip at the heart of the receiver would be critical to the design's success.  The data rate that this thing operated at was insane, and that in turn drove the complexity of the chips he had to decide from.  He had been in the business for long enough to know that the datasheet only told part of the story.  Once the chip was decided on, he knew he was in for the long haul of peeling back the layers of the onion to get to the nitty-gritty of how the chip was designed.  Only then could be built the rest of the support circuitry up around that chip.

I'm feeling a little that way as I dig into the wireless transmissions between the Davis weather station ISS and the VP2 console that receives its data.  One of the things I really needed to know if I had any hope of building a compatible receiver was to understand how the console configures the key internal registers of the CC1021 chip.  Regular readers will know that I recently picked up a $50 logic analyzer and have been using that to analyze the console's frequency hopping sequence (this was a lot easier than using a scope to figure out the chip configuration between hops).  What I found during those exercises was that, quite sensibly, the console was only configuring the registers it needed to when it needed to.  I wasn't seeing some important registers configured on a regular basis.  It seemed reasonable to assume that these registers were configured as the console was coming out of reset.

Now the problem with buying a $50 logic analyzer is that you don't necessarily get the world's most powerful triggering capabilities.  This unit's weak spot is serial triggering.  The CC1021 is configured via an SPI serial interface.  I knew the bit pattern I wanted to see because I knew which registers would be configured, but I couldn't teach my little analyzer to recognize the bit pattern.  I tried powering on the console with the analyzer connected and hoping for the best, to no avail: I ran out of capture memory way before I got to any interesting activity on the SPI bus.  I tried various trigger conditions but couldn't set up what I needed.  There is enough crap going on during initial power-up that I couldn't find what I wanted.  Things started to look a little grim.

But there was still hope.  Anyone who has a VP2 knows that when you power it on, you get this:

• BEEP
• Pause
• BEEP with associated LCD display test
• Pause
• "CONGRATULATIONS..." text thanking you for buying from Davis
• "RECEIVING FROM..." text that starts the configuration

So what I tried doing was triggering my analyzer with a very simple setup that just waited for the MOSI data line to be low and the clock and chip select lines to be high (Note that Davis doesn't seem to use chip select when talking to the radio, but the line does toggle up and down with some valid SPI activity on it as the console boots up - not sure why yet).  That looks like this on the analyzer's user interface:

Needle in a Haystack Time

Next, I started the capture at various times as the console was powering up.  Doing so on initial powerup gave me nothing useful.  Same with starting the capture between the first and second beeps.  Starting it as the "CONGRATULATIONS..." text scrolls by is interesting, as that gives some data on how the console starts looking for an ISS (breaking that down will have to wait fo another day).  I said "interesting", but I still wasn't getting the information I wanted.  The key registers I needed to see still weren't showing up in the capture.

It wasn't until I triggered the capture right after the second beep during the LCD test.  This is the capture I refer to as "The Holy Grail".

"I Seek the Grail."

The key thing to see here is the value "0x5" on the MOSI line.  This is the console's processor writing to the CC1021's RESET register.  I had never seen this before in previous captures.  The next register it writes to ("0x7") is the SEQUENCING register.  Another new one!  It seems I had finally caught what I was looking for.

So let's make a long story less long.  I had captured all of the data from reset to the console's calibration of its Phase Locked Loop (there's that word again).  I put all the data into a spreadsheet and then went through the long and laborious process of documenting what all those register reads and writes actually mean.  Here is what they mean:

Yes, it did take forever to type all of that in, thanks for asking.

But here's the thing: in the time it took to enter all that stuff, I was able to wrap my brain about what Davis is trying to do here, both in the configuration and in the sequencing.  It also forced me to really dig in to the CC1021 datasheet.  So much so, in fact, that I saw several things that Davis seems to do either unnecessarily or just plain incorrectly.  Stuff like:

• Setting the transmit PA power to zero every chance they get and then some.  I understand common code in subroutines, but this stuck me as a little much.
• They reset the CC1021 in Byte 4 and 5, and then do so pointlessly again in Byte 10 and 11
• They write all 1's to a RESET register at Byte 16 that is self-clearing anyway.  If you aren't writing some 0's to this register, ur doin' it wrong.
• They write to register VGA4 in Byte 68 and then read it back in Byte 70.  Why?  These settings don't appear to be volatile.  Did they think the chip was going to forget?

Davis engineers who are reading this (and I'm sure there are some): no hard feelings... right?

I do need to take another pass through this spreadsheet to catch any errors that I made first time around (the thought of pouring through it again right this second makes me violently ill).  Let me know in the comments if you see anything I've screwed up.

A quick check against the datasheet will show that all the register information you need to build a compatible receiver around say, something like this, is here in this spreadsheet.  There are a couple more things I still want to do yet, though:

• verify the CC1021 oscillator frequency in the console
• take the oscillator frequency and the register settings and run through the various frequency and bandwidth calculations in the datasheet to make sure I get the numbers I expect
• take a closer look at the console's signal acquisition process from the ISS

Stay tuned...