(Ab)using CurrentCost dev boards part 2

In part 1 of this series, I went over what the CurrentCost digital dev board was, and what was on it. In this part, I'm looking a bit more in depth at the components, and trying to figure out how it works.
Just in case you don't remember from previously, the Dev Board board looks like the following:

In order to understand how things are connected together, it's important to know what the pins on various devices are. In the previous part, I linked to the RFM02 entry on HopeRF's website, where you can find a datasheet. What I hadn't said is that I spent some time trying to work out what the device actually was. First up is just the recognition it appears to be an off the shelf component. I'd come across HopeRF's parts before in the form of the RFM12 boards, which have been used on things like JeeNode. I'd originally assumed it probably was an RFM12 (because I'd seen one of those and they look similar), until I realised the pinout is completely different. In terms of frequency, a handheld radio tuned to 433MHz was enough to identify the frequency in use. To identify the board, I basically ended up going through all the different boards that HopeRF had, hoping that I'd find a match. I did - otherwise I'd have to move onto other manufacturers!

The first thing to notice is that the RFM02 transmitter is "upside down" on the board. That means we need to transpose the pinout. Rather than expect you to do the same, I'm reproducing a picture below that has the pins marked on it - saves me getting confused.

If you read the RFM02 datasheet, there's a fair amount of detail, but not quite enough clarity. What you might not realise is that RFM02 chip (under the epoxy glob) is actually an RF Monolitics TXC102 400-1000MHz transmitter IC. That's really useful to know as the TXC102 datasheet is a lot clearer!

Anyhow, the TXC102/RFM02 uses an SPI like serial bus. I say "like" because the interrupt pin also doubles up as a status output pin, which is not SPI. We can see that we have a chip select pin (!SEL), a serial clock (SCK) pin, and a serial data in (SDI) pin. These are how we can configure the chip to do our bidding.  However, when we come to transmit data, we send the data to transmit via the FSK pin instead. From the datasheet it is possible to use the SDI pin, but as there's a separate connection, it seems easier to use.

There's also other pins that do various things. For example, the interrupt request (!IRQ) pin indicates the TXC102/RFM02 needs attention and the CLK pin that can supply the clock for the microcontroller. In this case, we're using a microcontroller that can already generate it's own internal clock, so I'm not entirely sure why this is connected.

Back to the SPI bus - I used the Bus Pirate with the SPI sniffer tool in order to monitor the data sent on the SPI bus. Literally, you can solder wires to the SCK and SDI pins, and monitor what's going on. Looking at what was coming out of the sniffer (after a bit of decoding!) I could see that the firmware performed some setup when the power was connected, some setup when data was about to be transmitted, and some setup at the end of the transmission. Looking at the datasheet, I could see that all the configuration commands are in the form of 16bits words. What got sent was the following messages: 0xCC00, 0x88F0, 0xC857, 0xD240, 0xA634, 0xC220,0xC001. That's handy... if you understand it. Fortunately the datasheet has a table that shows the messages and what they mean. I was hoping for a more consistent mask to indicate what the command is, but nothing that a piece of paper and pencil (or notepad) can't sort out.

So, doing some decoding indicates the following commands are sent.

Command	Description
0xCC00	Read status register.
0x88F0	Set Frequency band, crystal load capacitance, TX polarity and TX bandwidth
0xC857	Data rate set - 3918 bits/sec - formula is 10MHz/29/(R+1)
0xD240	PLL bandwidth - this is only documented on RFM02 datasheet.
0xA634	Set centre frequency for FSK - formula is 10 MHz*1*(43+F/4000).
0xC220	TX bit sync set, and low battery threshold set.
0xCC01	TX power down.

That's great! That is all the configuration that's needed in order to set the module to the right settings to transmit. When it came to data actually being transmitted, there's a short command (0xC039) that's sent to turn on the TX. That's a power management command that basically wakes up the oscillator, power amp and modulator ready to transmit the data that's supplied.

Then finally, two more commands are sent after the data is transmitted. Firstly (0xC001) powers down the oscillator, power amp and modulator, then (0xC400) puts the module to sleep.

So, knowing all this should mean that we can configure the transmitter, turn it on to send data, and turn it off and back into power saving mode afterwards (always helpful!). Of course, sending the data didn't turn out to be quite so simple, but you'll just have to wait for the next part.

Next Part 2.5