Other Parts Discussed in Thread: CC1101
Hello,
I'm still working on optimizing a CC110L receiver application (see this thread), and there are some unresolved issues and questions.
Summary: I have set up the CC110L to receive Manchester-encoded data at 1 kHz data rate. As built-in Manchester decoding does not work reliably with this old data format (30% packet loss), I simply use twice the data rate (2 lHz) with a 2-byte sync word 0x55 0x56.
I expect 4 bytes Manchester-encoded payload, so I set RX_LENGTH to 8 bytes, which are decoded in software to the original 4 bytes. I also attached RSSI and CRC bytes, so in total, I expect to receive packets of 10 bytes in RX _FIFO. After processing, this results in 4 bytes payload, plus one byte RSSI (I don't use the CRC value yet) This is an example of a successful payload received:
0x01 0x53 0xA4 0xFF 0x53
The payload is 0x01 53 A4 FF (as expected), and the RSSI value is 0x53 (-32,5 dB, ~1 meter distance)
This setup works fine, and packet loss is almost zero - except for one thing: the receiver also picks up spurious packets ('ghost packets'), often several per minute, although this can vary wildly.Sometimes 10 minutes go by without anything received, and then 3 or 4 packets arrive within just 10 seconds. I think it is simply receiver noise that is sometimes falsely recognized as a sync word, but I'm not quite sure - it is rather irregular for noise.
This was received in the past 2 minutes:
0x60 0x94 0x91 0x07 0xB5
0x15 0x02 0x00 0x04 0xBD
0xA2 0x04 0x0C 0x00 0xB7
0xC0 0x05 0x3C 0xD4 0xBF
0x00 0x4C 0x0B 0x02 0xBD
0x44 0x10 0x00 0xC4 0xC0
The RX payload bytes are basically noise, and the RSSI values are way lower (around -105 dBm). Each spurious packet takes approximately 70 milliseconds of time to be received and processed. During this time, no other packets can be received, so with 3 spurious packets per minute, the receiver can be 'deaf' for about 0.2 seconds per minute. This translates in missing 1 in 300 legitimate packets. It isn't dramatic, but still annoying, especially since I have no idea if this might get worse in a noisier environment.
I tried tinkering with the AGCCTRL2 and AGCCTRL1 registers, and especially increasing MAGN_TARGET and CARRIER_SENSE_ABS_THR seems to improve things somewhat - but spurious packets at low dBm levels still get through. The desired function is to set an RSSI threshold below which those packets are simply ignored ( e.g. everything below 0xD0 or -98 dBm). I could also decrease the LNA and/or DVGA gain, but I'm afraid that this will decrease the overall range of the RF link - and as I frankly don't know what other effects changing those values can have, it is pretty unlikely that I will arrive at an optimal solution that way.
There is also another strange thing that I noticed at the hardware level, when looking at CS and RX-sync (I'm using RX-sync = configuration 0x06 for GDO0 to signal the arrival of a packet, and CS = 0x0E for GDO2).
When a legitimate packet is received, I see Carrier Sense (yellow trace) as well as the RX-sync (blue trace):
However, when a spurious packet is received, I only see RX-sync, but no Carrier Sense:
The datasheet suggests that CS is used to evaluate if a valid signal is received:
"5.18.3 Carrier Sense (CS)
Carrier sense (CS) is used as a sync word qualifier and for Clear Channel Assessment (see Section 5.18.4)."
But this is contradicted by what I see happening: even though CS is not asserted, a sync word is still recognized and RX FIFO is filled with noise. I tried looking here on the forum and elsewhere on the Internet for more information and examples of how to use those AGCCTRL registers to set receiver thresholds, but can't find any useful information. It is also unclear how the internal logic of the CC110L receiver works with regard to CS and RX-sync.
So basically this is the question: how can I set an RSSI threshold below which packets are ignored? Hours of trial-and-error haven't led to a solution (or even better insight), although this is also caused by the stochastic nature of those spurious packets. After making a change, it can take half an hour or more to conclude if anything has changed or not.
So thanks again already for any leads,
Richard
