Bitcraze Forums

Hi.

Looking through the source code for CF2 and looking at the conversation on the blog detailing the range test I can see that there is now support for accessing the RSSI of the radio in the radio firmware. I'm wondering if there is a way to expose this functionality through the brilliant logging system of the CF. I can try and implement this my self if this is low priority, but before I start that I would like to hear if it is at all possible or if one can only access the RSSI through the radio firmware.

The idea has always been to have the RSSI exposed but with the first implementation we did we ran into compatibility issues with the Crazyflie 1.0 as it does not have RSSI. What we did was that we injected the RSSI as the first byte in the packages we sent. The problem then is that we break the package structure and the firmwares must be matched to this. For the RSSI test we did it was fine but for the official release it wasn't and we ran out of time. Exposing the RSSI as a log variable would be better, but then requires the information to be sent from the nRF51 to the STM. This shouldn't be to difficult to implement though.

In nRF FW: main.c. You can copy much of how the battery info is sent. Then create a new syslink define in sylink.h. Maybe: Then in the STM FW: radiolink.c take care of the RSSI in the dispatch function by saving it to a variable so that you can log it.

Hi Nordmoen,

<My message apparently collides with Tobias, but I wrote more info so I post it anyway >

The rssi measurement is done by the nrf firmware (the radio firmware), during development we did things like sending back the RSSI in empty ack packet: https://github.com/bitcraze/crazyflie2- ... /esb.c#L99 or sending back the rssi as header of all packet. Though this breaks compatibility with the current radio protocol so what you are proposing (having RSSI accessible from log) is a good idea.

If you are interested about implementing it go ahead, that would allow to get a much more precise link quality indication on the client! It does require to modify both the radio firmware and the stm32 firmware.

Currently the radio implementation fills up the rssi in every received packet: https://github.com/bitcraze/crazyflie2- ... esb.c#L147 so what needs to be done is to communicate the packets rssi in some way to the stm32. The communication between STM32 and NRF51 is packet-based (we called the protocol syslink, you can find it in both stm32 and nrf51) which mean that we can either add a packet for RSSI report, or add the RSSI to each received packet.

Then in the stm32 RSSI values can be made accessible to the log subsystem. I guess those values needs to be filtered a bit to be usable.

I hope this is enough info to get you started, tell me if you need more.

Thanks to the both of you for the prompt reply.

We worked a bit on this today and got something working at least. I have sent pull request on both firmware repositories (https://github.com/bitcraze/crazyflie2- ... are/pull/1) (https://github.com/bitcraze/crazyflie-firmware/pull/41) if the quality is good enough and the improvement is worth it.

From what we could see the values sent though at 100Hz seem to be quite reasonable when plotted. Indicating to me that the raw values could be used as link quality indicator.

Great, it was as simple as I imagined .

Though I have some suggestions. From what I recall the RSSI can only be a value between 30-108 something. So I suggest using a uint_8 instead to save bandwidth in both the syslink and the radio transfer.

Also we should probably investigate if the added bandwidth can effect some other performance effect on the radio communication. The timing for the nRF has proven to be quite important.

Sorry for the late reply.

I updated both pull requests, changing the sent RSSI value from uint32_t to uint8_t as per your comment.

Thanks Nordmoen, I merged the NRF pull request and I am looking at the STM. You are triggering a bug in systlink that I need to fix. The thing is that for radio data packet we need flow control and this is done by sending a radio packet only when one has been received. But the way it is done now the rssi packet is seen as a radio data packet which is wrong. I am fixing this and I will merge the pull request.