Last time we worked out that data was being transferred from the microprocessor to the CC1150 chip using synchronous serial mode at 6.5kBaud. This time, we are going to look at that data using the logic analyser and try to interpret it.
This is what our data looks like – channel 1 is data, channel 3 is a clock. The Saleae Logic software can help to interpret this as plain synchronous serial.
You might notice that the software doesn’t have an option for synchronous serial – only asynchronous. It does however have “Simple Parallel”. This takes a number of channels and a clock. Serial is just parallel with a single channel, so that is what we will use.
Another plus of the Saleae software is that you can use multiple analysers against the same channels i.e. on our MISO/GDO1 line we can have an SPI and simple parallel decoder running.
Now we have successfully decoded a series of pulses, and the software has conveniently added little dots to show the data bits:
You might quickly notice that the pulses are either 1, 2 or 3 bits long. Never 4 or more. This is the case along the entire stream of data. 1 and 2 bit pulses are common, and 3 bit pulses are at the beginning, end and at regular intervals. We could guess that 1 bit = 0, 2 bits = 1, and 3 bits signifies the start and end of a packet? Seems sensible to me.
As an aside, it is fairly common for RF systems to encode data so that there are frequent transitions between 1 and 0. This is for a few reasons:
- To try and keep the average value of the signal midway between 1 and 0, allowing automatic gain controls and DC filters to work correctly.
- To make sure any clock recovery or synchronisation has frequent edges to work on.
- Representing 1 bit of data as multiple bits can provide redundancy and error checking.
Manchester encoding is very common, but there are a lot of proprietary and ad-hoc schemes in use. I have seen infrared protocols used on AM OOK systems before now – they kind of meet the requirements and allow the use of existing chips and code.
The entire data burst lasts about 1.20s. At a data rate of 6.5kBaud, that is 7.8k symbols. I don’t fancy manually transcribing or interpreting that much data. There is a high probability that the data repeats to a certain extent, but it can be hard to see the boundaries on a logic trace. Automating this process makes more sense.
Looking back at the data, and my initial observations, I can see:
- 111 is always followed by 000, and I can see this happens relatively infrequently but regularly
- 1 is always followed by 00
- 11 is always followed by 0
So, let’s make some arbitrary choices:
- 111000 is the start/end of a packet
- 100 is a 0
- 110 is a 1
Where to from here then? Python! Let’s read the data in, and try to process it using these simple rules.
Why am I using Python? In recent years I have found it is by far the quickest way to get simple data processing tasks like this done. It seems naturally suited to arrays of data and is tolerant of idiocy. I use Pycharm as a cross-platform IDE – it’s really useful.
I’ve knocked up a very simple program to read in a Saleae logic file, and then interpret the data as above.
With the input from my trace, I get the following repeating pattern:
001100011101111101100000010000000000000000010000 001100011101111101100000010000000000000000010000 001100011101111101100000010000000000000000010000
No change at all from packet to packet, 48 bits long. This encodes to 150 bits long, and re-transmits about 50 times in the 1.2s burst (retransmission is a common technique to ensure the receiver hears the transmission, even in noisy environments).
We know from the documentation the system uses 20 bit IDs. Just a gut feeling, but I would expect the address to have a lot of entropy, so might assume that the first 20 bits are the address – 001100011101111101 – and the rest is data. There may be a pre-amble and sync word before the ID, meaning it might be shifted a bit further on. To confirm this, I will need to put the sensor into different states (triggered/not triggered,tamper/safe,battery low etc.) and compare to other sensors.
Is the system rolling code? We can’t really say at this stage – we need to grab more traffic. I’d expect the code to roll in 50 retransmits though. It’s not looking good.
What is interesting is that to see this data, I didn’t actually need to look at any RF at all. In fact, I don’t even need the comparatively expensive Saleae Logic – a Bus Pirate acting as a logic analyser would be able to do this.
Where to from here? Let’s start sniffing data from the other door contact and start changing their states. For next time 🙂