Watch This, Or Nothing From Here On Will Make Sense
The intricacies of wireless RF transmission put a slightly different spin on any Scarface reference you might want to make, so let's look at it this way.
First you get the signal: I unlocked this achievement a little while ago when I used my Pretty Pink Pager to successfully receive a signal from the Davis Outdoor Integrated Sensor Suite (ISS) out in my yard. A good start, but there was still a long way to go.
Then you get the data: This turned out to be rather tricky, and is the subject of today's post.
Quite some time ago, I looked at how the radio chip in the Davis console is configured for each frequency hop it makes. That was all well and good, but as I dug deeper in actually trying to grab the data over the air, I realized that there were a few more things I'd need to figure out.
The CC1021 datasheet (for the RF chip in the Davis console) treats this subject pretty lightly, but once you delve into the CC1110 datasheet (the compatible RF chip in the Pretty Pink Pager), you hit David Rumsfeld's known unknowns. That datasheet makes it clear that there is a lot more going on than just the data coming in over the air. I figured out how to see the data a long time ago by using STRMON and a terminal program, but there is more to it than that. There are actually three parts to the transmission from the ISS that need to be sorted out.
- Preamble. From the CC1021 datasheet: "The recommended preamble is a ‘010101...’ bit pattern... This is necessary for the bit synchronizer to synchronize to the coding correctly." This doesn't show up in the STRMON output. How long is this bit pattern? Where is it in relation to the data?
- Sync Words. Again from the CC1021 datasheet: "The recommended sync words for CC1021 are 2 bytes (D391), 3 bytes (D391DA) or 4 bytes (D391DA26) and are selected as the best compromise of the above criteria." Does the Davis system really use these recommended sync words? If so, how many bytes do they use? Where are they in relation to the data?
- Data: I know what this is at any given time. STRMON tells us that this is seven bytes of information plus an eighth byte for a checksum. As we'll see in a bit, knowing what the data in the transmission is was critical in figuring out the other stuff.
My first attempt to do this did not go well. I soldered a few wires directly to the console's processor in an attempt to break these lines out. Something broke all right, and that was my console. I had hoped it was just a blown LCD and ordered one of those up from Ryan at Archer Trading Post. That didn't work, so I actually had to order up a whole new console. Those are the breaks. The new console arrived on Wednesday. By Saturday, it looked like this.
|Much To The Chagrin of My Lovely Wife,|
This Is Our Kitchen Table
I was a little more careful on my second attempt. If you are going to try this (don't try this), here is the pinout you need to know.
CC1021 DCLK Pin 7 connects to ATMEGA (SCL/INT0) PD0 Pin 25It was time to break out my $50 logic analyzer and try, try again. I figured I didn't need to worry about LOCK. But I did worry about something else: shorting some spins and frying another console. The spacing between pins on the processor's TQFP package is a mere 0.8 mm, and I now know that new consoles don't come cheap.
CC1021 LOCK Pin 9 connects to ATMEGA (SDA/INT1) PD1 Pin 26
CC1021 DIO Pin 8 connects to ATMEGA (ICP1) PD4 Pin 29
With one hand I held a probe to the DCLK line, with my other hand I held a probe to the DIO line, and with my third hand I triggered the analyzer. That third hand was actually that of My Lovely Wife, without whom I would have been well and truly screwed once again. It worked, and this was what I got.
|Sniffing CC1021 DIO / DCLK Data, Very Carefully. Click To Embiggen.|
|I Got A Clock. I Got Some Data.|
|What In Here Am I Looking For?|
Since I had the STRMON data, I would start looking for the eight data bytes and then look for the Sync and Preamble bytes after that. What helped was finding a spot in the bitstream where there were eight or nine 1's followed a short while later by eight or nine 0's. There was some data in the capture log that had an 0xff byte, followed by something else, followed by a 0x00 byte. It took a while and I went down several blind alleys, but I finally sorted it out.
corresponds to this...
Here are the key points to know:
- The eight data bytes (six plus two byte CRC) appear in the bitstream as numbered in the STRMON output
- Each byte is Least Significant Bit (LSB) first.
- The data is taken on the rising edge of DCLK
LSB Order Byte MSB Order Time After TriggerHere is a closeup of the first data byte to help you see what I'm talking about.
00000110 0x60 01100000 8.125 ms
11000000 0x03 00000011 8.540 ms
01010101 0xaa 10101010 8.960 ms
11111111 0xff 11111111 9.375 ms
10000011 0xc1 11000001 9.795 ms
00000000 0x00 00000000 10.210 ms
10011011 0xd9 11011001 10.625 ms
10001000 0x11 00010001 11.045 ms
|First Byte of Data|
0 0 0 0 0 1 1 0That is LSB order. So we reverse the bit order to get the more conventional MSB order.
0 1 1 0 0 0 0 0That is 0x60, our first byte in the table above. Going from there to the right, each byte works out exactly. There is no Start Bit, Parity, or Stop Bit. Booya.
Next thing we need to sort out is the Sync bytes. Remember from above that what we are looking for is probably something that looks like D391DA26 or less. It turns out the Sync bytes look like this.
- The Davis system uses only two Sync bytes
- The Sync bytes are 0xD3 followed by 0x91
- The two Sync bytes immediately precede the data bytes. There is no gap between them.
- The Davis system uses four Preamble Bytes
- The Preamble is more correctly a '101010...' pattern if we don't do a LSB to MSB conversion (and we shouldn't in this case)
- The four Preamble bytes immediately precede the Sync bytes. There is no gap between them.
|CC1110 Packet Format|
The sharp eyed amongst you will notice that there is some stuff going on on either side of the Preamble, Sync, and Data bitstream in those first couple screen captures. I haven't dug into this yet, but my suspicion is that this is there for a couple reasons:
- allow the CC1021 to detect and lock on to the carrier when it first starts being transmitted from the ISS
- allow the console to determine the frequency error on the signal transmitted from the ISS so it can precisely tune to the signal and minimize bit errors
Then you get the women: That is pretty much automatic when you do cool stuff like this all weekend. Have a good one.