BPSK on TI CC chips, 2

18.06.2016 13:07

A few days ago I described how a Texas Instruments CC1101 chip can be used to transmit a low bitrate BPSK (binary phase-shift keying) signal using the minimum-shift keying (MSK) modulator block. I promised to share some practical measurements.

The following has been recorded using an USRP N200 with sampling frequency of 1 MHz. Raw I/Q samples from the USRP were then passed to a custom BPSK demodulator written in Python and NumPy.

The transmission was done using a CC1101, which was connected to the USRP using a coaxial cable and an attenuator. MSK modulator on CC1101 was setup for hardware data rate of 100 kbps. 1000 MSK symbols were used to encode one BPSK symbol, giving the BPSK bitrate of 100 bps. The packet sent was 57 bytes, which resulted in packet transmission time of around 4.5 seconds. The microcontroller firmware driving the CC1101 kept repeating the same packet with a small delay between transmissions.

Recorded signal power versus time.

This is one packet, shown as I/Q signal power versus time:

Signal power during a single captured packet.

In-phase (real) component of the recorded signal, zoomed in to reveal individual bits:

Zoomed-in in-phase signal component versus time.

Both the CC1101 and USRP were set to the same central frequency (868.2 MHz). Of course, due to tolerances in both devices their local oscillators had slightly different frequencies. This means that the carrier translated to baseband has a low, but non-zero frequency.

You can see 180° phase shifts nicely, as well as some ringing around the transitions. This has to be filtered out before carrier recovery.

After carrier recovery we can plot the carrier frequency during the time of transmission. Here it's plotted for all 4 packets there were recorded:

Recovered carrier frequency versus time for 4 packets.

You can see that the frequency shifts by around 20 Hz over the time of 4.5 seconds. This is around 20% of the 100 Hz channel occupied by the transmission. At 868.2e6 central frequency, 20 Hz drift is a bit over 0.02 ppm, which is actually not that bad. For comparison, the quartz crystal I used with CC1101 has specified ±10 ppm stability over the -20°C to 70°C range (not sure what USRP uses, but it's probably in the same ballpark). However, I think the short-term drift seen here is not due to the quartz itself but more likely due to changes in load capacitance. Perhaps the oscillator is heating slightly during transmission. In fact, just waving my arm over the PCB with the CC1101 has a noticeable effect.

Finally, this is the phase after multiplying the signal with the recovered carrier. The only thing left is digital clock recovery, bit slicing and decoding the upper layers of the protocol:

Signal phase after multiplication with recovered carrier.

Posted by Tomaž | Categories: Analog

Comments

You'd hope that the USRP would have a better crystal than the C1101, given its price. Unless you're using "ballpark" to mean, like, order of magnitude

Posted by bbot

I just checked: according to the datasheet, the USRP N200 has a temperature compensated oscillator with 2.5 ppm accuracy. CC1101 datasheet specifies ±40 ppm total oscillator accuracy due to crystal load and aging (although that depends on what kind of a quartz crystal is used). So USRP should be more than an order of magnitude better.

I was a bit sloppy in writing that section. To clarify: There are two frequency differences in play here. One is the relatively static frequency offset between transmitter and receiver. This was probably in the 10s of kHz range here. I roughly compensated for it in my receiver before the start of the measurement and unfortunately I did not write down the actual offset. I wrote about frequency offsets in a previous blog post:

https://www.tablix.org/~avian/blog/archives/2015/11/cc2500_radios_and_crystal_tolerances/

In this experiment I was more interested in the short-term frequency drift that happens during the time of a single packet transmission. That one is not noticeable in transmissions with wider bandwidth. It is harder to compensate for in the receiver. and it's also something that is not well specified in the datasheets.

Posted by Tomaž

Add a new comment


(No HTML tags allowed. Separate paragraphs with a blank line.)