Using the CC1101 for OOK reception

Using the settings from DN022 is a good starting point yes. I noticed that you use async mode though. In asynchronous mode you get the raw data and no data deciscion or synchronization is done-on chip. This needs to be handled by the interfacing MCU. Since the data is oversampled by a factor 8 of the programmed data you will see that the raw data has jitter. One thing to try to reduce the jitter is to program a higher data rate than is actually used. E.g program the data rate to for instant the double of what your signal is might help.

Charlotte

Hi Charlotte,

Thank you for the quick reply!

I did a test with higher data rate, it helped on the jitter a little bit. I am using asynchronous mode just for determing the quality of the incoming signal. If I'll get the signal okay, I'll switch to synchronous mode. The problem of the reception is not only jitter, but more the missing symbols. As you can see in the pictures, there's even no raw data present while it should be. There's no way further processing can recover the missing data.

I tried to set it to synchronous though, but it didn't make any sense in getting better (missing) data.

Are there any other registers to control the agc / threshold besides the ones in DN022?

Regards,

Rolf

Hi,

We have several customers using ASK in receive, async mode and CC1101 so we know it works. I assume you started with the SmartRF studio settings for ASK 1.2kbaud and just changed the datarate? Can you explain your test set-up further? You are using your own transmitter, what power level are you sending at? what is the freq offset for your transmitter? On the receiver side, do you use a CC1101 EM on a SmartRF04 board or your own HW? What SW do you use, SmartRF Studio? What input level are you reading from the CC1101? Have you tried increasing the preamble?

Charlotte

Hi Charlotte,

The application is for receiving data from a thermostat. We have developed a unit for controlling central (floor) heating. We use the CC1101 to receive the signals from different brands of thermostats. All brands of thermostats use their own proprietary protocol. 

We prefer to use their protocol rather than have it changed for us. This means I have to deal with the used preamble and protocol, and I can not control any settings on the transmitter side.

If finally seems reception of the OOK signal seems too unstable, we will let the thermostat manufacturer redesign the thermostat to use it with the CC1101 (but we prefer not to).

The test setup is:

- a  transmitting thermostat:

12mW @ 868.350 MHz at several distances. Modulation = OOK, manchester encoded. See picture for protocol.

- My own hardware as receiver.

I am using SmartRF studio to generate the register settings but I am also capable of entering the settings on my hardware at runtime.

Thanks,

Rolf

Hi,

Have you tried using the CC1101EM on a SmartRF04 EB? Just to eliminate anything with the HW?

I'll try and let you know the results, thanks!

650 baud is slooooooow.  The chip normally works with 10Kbaud sort of rates.

It demodulates the OOK data by the RSSI.  If the attack/decay times for the RSSI are wrong...it will lose bits.  I believe there is a register to modify the RSSI time constants in there somewhere.

Hi Rich,

Yes, I notice the AGC / threshold shifts on the higher DC level on the received data. If the data will be fast, the threshold will not rise too much and the output will be better.

There are some register settings (AGCCTRL2) where AGC constants can be defined. I tuned for optimal reception, but still no satisfying reception.

Would you let me know if you find out which register settings I need to change for the RSSI time constants, I will do some more tests.

Regards,

Rolf

"It demodulates the OOK data by the RSSI" - thus this means that actually an envelope detection scheme is used. Well, I have been seeking for more info about the details of demodulation, but the datasheet doen't tell much about it. It's all in the digital core past the two ADC's.

I'm using a CC1101 with OOK in the vicinity of a high performance DSP MCU (with high wideband CPU noise and ethernet) and some clock signals. Envelope detected OOK is quite prone to interference effects, unless a sort of coherent demodulation scheme is used. Can an expert provide a bit more detailed info about such demod details?

Hi I have an interesting problem with receiving data in OOK with a CC1101. 

Data rate is 2kbps and is coming from an analogue transmitter (I have measured the datarates for several transmitters and they range between 1.95 to 2.03kbps) which I am trying to capture the data from. The project is to create a receive upgrade for a product that the Receiver chip has gone EOL (RX5000). The existing receiver takes a feed from the output of the receiver and does it's own decoding where as I am trying to use the digital decoder in this application. The problem I am having is sometimes the data is correct but offset. I am expecting 12 byte packets with the packet being defined as Frame header (0xFC), Frame Number (0x08,0x09,0x0A,0x0B) followed by the data byte. A good Packet might look like FC,08,AC,FC,09,A2,FC,0A,A3,FC,0B,61. However I am often not getting the data correctly aligned. The data I sometimes receive is a few bits to a nybble offset  in either direction. I just received a packet offset by a nybble 1F,C0,8A,CF,C0,9A,2F,C0,AA,3F,C0,B6,1F, although this is not always the case, often it is offset by 1 or 2 bits (in either direction however this could be redefined as offset in one direction but 6 or 7 bits)

I am polling the Status register and when there is enough data I retrieve it and then process it. I am looking for the FC and then I process my buffer from there to retrieve the data.  I have looked at but not implemented the Sync word as I don't have the ability to change the transmitter (transmitted data). This is for two reasons 1) there is no preamble sent 2) the sync word (if using the Frame header and Frame number FC0X ) has a threshold of 15/16 and I (think I) need a 14/16 to capture the 0A and 0B with the lsb disregarded.

The offset is consistent during a transmission burst but after a period of radio silence and a new transmission starts the offset will change. So it is as if it simply picks up the data coming in partway through an internal bitcounter. EG the receiver has started counting bits (real or imagined) and then the transmitted data starts to arrive and it just continues on.

I am presently contemplating a routine to process the incoming data stream to determine the offset and then manually offset the array and return the data array back to my existing processing routine.

I was thinking that the RSSI should be able to act as gate but to date either it is not working as I think it should OR it is not set up correctly.

My Register settings are derived from Smart Studio 7 and are as follows (taken from my source code where I have marked them up with comments). If there is other information that is needed to help with or solve this please ask. 

Regards,

Steve B

const uint8_t SetupStringOOK[]={ //OOK
0x0B, 0x06, //FSCTRL1
0x0C, 0x00, //FSCRTL0
0x0D, 0x10, //FREQ2
0x0E, 0xB0, //FREQ1
0x0F, 0x71, //FREQ0
0x10, 0x86, //MDMCFG4 - changed this to 0x86 (203kHz BW))
0x11, 0x43, //MDMCFG3
0x12, 0xB0, //MDMCFG2
0x13, 0x12, //MDMCFG1
0x14, 0x00, //MDMCFG0
0x0A, 0x00, //CHANNR
0x15, 0x00, //DEVIATN
0x21, 0x56, //FREND1
0x22, 0x11, //FREND0
0x17, 0x30, //MCSM1
0x18, 0x18, //MCSM0
0x19, 0x00, //FOCCFG
0x1A, 0x6C, //BSCFG
0x1B, 0x04, //AGCTRL2 changed from 0x03 as per DN022
0x1C, 0x00, //AGCTRL1 changed from 0x40 as per DN022
0x1D, 0x92, //AGCRTL0 changed from 0x91 to 0x92 as per DN022
0x23, 0xE9, //FSCAL3
0x24, 0x2A, //FSCAL2
0x25, 0x00, //FSCAL1
0x26, 0x1F, //FSCAL0
0x29, 0x59, //FSTEST
0x2C, 0x81, //TEST2
0x2D, 0x35, //TEST1
0x2E, 0x0B, //TEST0
0x00, 0x00, //IOCFG2 - Does nothing as this is not connected
0x02, 0x0D, //IOCFG0 - Changed to 0x0D - Serial Data Out. Changed to 0x01 - RX FIFO 1 when above the threshold act as interrupt/Control for Micro
0x07, 0x00, //PKTCTRL1
0x08, 0x01, //PKTCRTL0
0x09, 0x00, //ADDR
0x06, 0xFF, //PKTLEN
0x03, 0x0F, //FIFOTHR - changed to 0x47 try as per DN022 was 0x0F
};

PA_Table[9]={0x7E, 0x00, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};