I’m trying to read the data from a CC1101 chip. I have the SPI data currently. I used the Salae_CC1101 decoder, which gave me the register setting, extremely helpful. The configuration for the CC1101 is putting into Async Serial mode which changes the GDO0 pin to “data” and sets the GDO2 pin as the clock.
I can see data coming back on the GDO0 pin (see attached capture) but I’m having difficulty configuring either the Async Serial or Simple Parallel analyzers. To be honest, I’m not really sure which one will fit my purposes. The SP has a clock and data “configuration” but the data coming back is all 0’s.
I’d appreciate any guidance to get me on track to decode the raw RF data coming back on the GDO0 pin.
Out of curiosity, I took a quick peek at your capature file. It looks like it is putting the packet format (PKTCTRL0.PKT_FORMAT[1:0]) into 3 (11): Asynchronous serial mode and setting IOCFG2.GDO2_CFG[5:0] to (0x0D) Serial Data Output. In asynchronous output, I think the GDO2 pin is the ‘raw demodulated’ signal, where the serial encoding scheme depends on the RF transmitter. What is transmitting the data you’re trying to decode?
Depending on the transmitter/receiver you’re trying to decode, it may be better to use the Manchester or Async Serial analyzer to decode it. It may also be handy to use the Glitch filter on the serial output channel to remove the possible noise pulses that may occur in the raw RF demodulated signal.
Otherwise, you could use the Simple Parallel Analyzer along with your own high-level analyzer to create a custom decoder in python, or write your own low-level analyzer using the Saleae Analyzer SDK. However, this is a more advanced method vs. being able to use the built-in analyzers and/or finding a suitable 3rd party analyzer, if available.
Finally, it looks like there are two CC1101 high-level analyzers listed in the Logic extensions:
… and it looks like the first may have a bit better higher-level decoding that may be more helpful for reverse-engineering your CC1101 settings, as it seems like you can search the data table for registers and more easily see the values being written.
The next step requires more detailed analysis of the CC1101 settings, and/or more knowledge about the specific RF protocol(s) and device(s) that are being monitored – to help figure out which asynchronous serial protocol to expect, and what analyzer(s) would best help you to decode your serial output data.
Thank you BitBob for taking the time to look over my capture. I’m trying to decode the signals sent by an Autel MX-1 programmable TPMS sensor. The capture is from an Autel MaxiTPMS, TS508 tool. I connected the logic analyzer to the SPI pins of the CC1101. I thought having the configuration they were setting the CC1101 to would help me to understand how to decode the messages coming from the MX-1 sensor. Since I posted this question, I’ve done further testing and it appears that most, if not all of the different vehicles use the same CC1101 settings. I believe what is happening is, they are setting the CC1101 to receive the message from the MX-1 in serial mode and depending on which vehicle is selected, they use internal firmware to correctly parse out the data into something meaningful.
I think you are correct though and I’ve been trying to decode the wrong signal. After looking at the capture again, I was misinterpreting the data, the GDO2 line, which I initially thought was a clock signal does in fact look like the raw data coming out of the CC1101.
I’ve since been trying different decoders, async serial, manchester, etc to try and get the 0’s and 1’s to possibly pass onto some RF decoder to try and find the Hex(ID) of the TPMS sensor that the TS508 reads, in this case, 60AD7489. Haven’t had much luck thus far but I’ll keep trying :).
Again, thank you for your assistance, it’s greatly appreciated!
Did you capture data after the sensor was already programmed, or was it still new? If so, what vehicle make/model/year was it programmed for?
There is a whole ecosystem for RF based hacking known as Software Defined Radio (SDR), and an open source tool rtl_433 that has a lot of different TPMS sensors (and other wireless devices) supported:
… and device encoding schemes:
For a general overview on rtl_433, see:
As far as your capture, I think one channel is indicating signal strength, while the other is the async serial data. The CC1101 is doing the RF demodulation that may be using:
… and the just de-modulated pulses come out the async serial line.
These de-modulated signals/pulses may be:
Manchester encoded bits
Pulse-Width modulated (PWM) bits
Pulse-Code modulated (PCM) bits
or other bit-encoding scheme
However, the de-modulation could be noisy, and have false edges (noise pulses) in the digital output. If so, it may prevent any of the built-in decoders from working properly, as most decoders aren’t very noise tolerant. That would require you to use the software glitch filter (linked above) to ignore & filter out any pulses that are too short.
The main triq.org site has a lot of additional useful tools for helping to reverse engineer RF encoded data, and you can also look at the rtl_433 github site for more hints on how to analyze RF signals. Knowing the bit-level encoding scheme is critical to figuring out you logic setup & analyzer settings.
That’s actually where I started this whole process. Catching RF signals out of the air with my RTL-SDR was a little daunting with all the variances that can make my head explode, LOL. My thinking was that if I could get what the CC1101 was pulling out of the air, I’d have a better shot at trying to figure this stuff out. It appears that there truly is no easy way for this.
I have the Autel tool that can program the TPMS sensors and I have a cheat test rig (old tire balancer) that I’ve been using to spin the wheel to try and get “real world” information from the TPMS sensor. I’ve also started using Universal Radio Hacker to try and make sense of it as well. The capture that I posted here is from an X7 BMW which the rtl_433 guys have figured out a couple of the generations of the BMW sensors but what I’ve found is, this must be another newer generation at least from what I’ve seen from the preamble, but I’m so new at this, I don’t even know if the preamble I think I’m getting is actually the preamble.
I can honestly say, this whole process is maddening, LOL. I’ll keep plugging away though and I really do appreciate your time helping a newbie and giving me new ideas and thought processes to build upon.