RSSI readout stuck
phpcoder opened this issue · comments
Thank you for your work on this library.
I have come to the use of cc1101 for its rare ability to give the RSSI estimate, though not absolutely precise without proper calibration. However, using cc1101 with Elechouse library when RSSI value is readout periodically makes it freeze with some small random value (-84dBi, -87dBi etc) after minutes or hours from the program start.
The RSSI readout is included into main loop after status validation. The problem can be reproduced using the example
SmartRC-CC1101-Driver-Lib/examples/ESPiLight examples cc1101/Receive_cc1101/Receive_cc1101.ino
I include the RSSI related code just after status check:
// check if message is valid and process it
if (status == VALID) {
Serial.print("RSSI: ");
Serial.print(ELECHOUSE_cc1101.getRssi());
Serial.print("dBm - ID HEX: ");
It is hard to guess of the reasons for such a behaviour. It can be related to the bug described in CC1101 Silicon Errata
SPI Read Synchronization Issue SPI read synchronization results in incorrect read values for register fields that are continuously updated
or anything else. It would be nice to hear of any possible workaround for this problem from the maintainer of this prooject.
hello, how often is the rssi query in the code? which microcontroller is used? which cc1101 module? regards
Hello, thanks for your attention.
I use Wemos D1 mini (ESP8266) with a module shown here.
Regarding the frequency of RSSI query, it depends on the protocol used. For example in my own application it is read after every packet is decoded, min 75-100ms. If it is included into your example code as mentioned above (rfCallback function) it can be much more often. In both cases the behaviour is similar: after minutes or hours RSSI readings are not updated anymore and stuck with values like -88dBi, etc.
Did you test to having the CC1101 add the RSSI and LQI values to the packet by setting
ELECHOUSE_cc1101.setAppendStatus(1);
and take the RSSI from these two additional bytes instead of using the ELECHOUSE_cc1101.getRssi() ?
I use this function also to speed up transfer, as the two bytes can be read using burst transfer together with the packet data.
From the silicon errata i doubt that this bug is the issue, the probability for this SPI read error for the RSSI is estimated a 80 ppm at a data rate of 500 kbps, so it is very low and would not cause a permanently stuck RSSI value.
@Gemikro1: thanks for the idea. The reason I refer to the example using ESPiLight library is that CC1101 is used there as a raw data receiver, where protocol decoding is implemented in the ESP device. In my application I use my own decoder, but the application is similar - packet sync is done in software rather than in CC1101 hardware. So the RSSI is queried upon decoding a packet (or two) using getRssi(). The way CC1101 measures RSSI is based on automatic gain control level which, I believe, should be valid even the hardware packet handling is not used. I am not sure that the way you propose could be applicable to my case, but any idea is welcome. I am still able to use CC1101 as described in antenna efficiency evaluation, which, I found quite handy, as the RSSI values it gives seem relevant.
Wow, that sounds as a real explanation for the problem.
My use case is a bit different from yours. I normally use some superheterodyne type 433MHz RX module. For that I have a self-made universal decoder for some protocols like Nexus, PT2262, Keeloq. (You can see some of my repositories). Clearly, for such a case a ESP8266 should do all decoding job without external sync, etc. Such decoder is integrated into Tasmota Lite firmware. I found that CC1101 is not bad as a receiver (hoped that its declared sensitivity is better than the modules I normally use - which is not true) and offer some extra bonuses like frequency shift, bandwidth control, rssi readout and, if needed data transmission.
So, when I connect CC1101 to my decoder, no internal registers are ever used, only raw data. See the elechouse example as mentioned before. From your explanation may follow that some activity is going on in CC1101 -- it may catch some random sequence and treat it as a preamble. Perhaps some extra effort is needed to disable such a behaviour.
As a workaround, I just made a Tasmota command issued from console to reset a receiver when it is stuck... As you seem to be more involved in CC1101 internals, maybe you can suggest a sequence to disable internal sync which may solve that stucking issue. Thanks anyway for the idea.
If you have the manual of the CC1101:
Sections 15.5 describes the receive sequence in different modes.
Section 17.3 describes the RSSI readout and the RSSI freezing on sync word detection.
If you do not want Sync word detection this can be disabled with setSyncMode(0) but i found it quite hard to handle the data stream that i am dealing with without at least sync word detection.
In this mode you should also disable any other packet handler features as FEC and address check... (see synchronous serial operation chapter 27.2).
You can program a carrier sense signal to be output on one of the GDO pins if a certain threshold for the RSSI is exeeded to avoid getting too much noise (17.4 in the manual).
Resetting the stuck receiver could be performed by issuing an SIDLE strobe SpiStrobe(CC1101_SIDLE); or better changing from RX to TX and back, but i did not yet test this.
By the way, i am using the Anaren (now TTM) CC1101 modules (A1101R04C and A1101R08C) with an integrated U.FL antenna connector, these have quite good performance. Only disadvantage is that they use a 27 MHz crystal for the US market instead of an 26 Mz as most other modules like your TO-CC1101.
Just had a look on your repositories, quite interesting !
My current project as to implement a MQTT gateway for 868 MHz devices based on a custom PCB that uses an ESP-16e and one Anaren A1101R08C module together with an AC/DC power supply. The whole unit can be housed (currently i am using an empty Kopp switch housing) and installed in a flush mounted box.
Already working ist Kopp FreeControl (2) protocol and i am currently implementing the X-Sense (fire alarm) wireless protocol.
Up to now i based the gateway on the OpenMQTTGateway project but i found it a bit of a disadvantage that this does implement a web interface. I will have a look on your implementation based on Tasmota (which i use anyway for all the remote switches and shutter controls), could be a nice option to use this as a base for my gateway. Would be nice if i could get your help on this if required !
Thanks for the hints with configuring CC1101, I will give it a try.
No time to update, my repository describes Tasmota v10.0.0. Now things are a bit different, so please open a ticket if you decide to try. Hope I can find the time to publish new notes on Tasmota integration.
I have also tried OpenMQTTGateway and found it too cumbersome, so figured out an own implementation of RF protocol decoder a la RCSwitch with the possibility to extend protocol list with MQTT support as part of Tasmota. I think 433 vs 868MHz is a matter of RF interface only.
My solution using OMQ is already up and running, but i will have a look at your Tasmota version anyway. OMQ is still undergoing a lot of changes and improvements, i think Tasmota has a much higher maturity level.
I recently set up a custom firmware project using Tasmota 12.4.0 sources, so i think i should not have a hard time to migrate the code from your v10 version.