Debug RX5808?

[SidneyBovet]

Hi, I just got my feet wet by building a Solo device using Bluetooth. I could set the baud rate on the module, and the Android app connects successfully, but there seems to be an issue with the RX5808 module.

The RSSI value reported by the app seems to move up slowly as the radio module heats up (value moves within the 80 - 90 range). When I manually disconnect the RSSI pin (A3 on the Arduino) I see that value changing, so I am assuming everything works correctly on the Arduino side.

The module I got it this one. It looks like it is already working in SPI mode, but just to be sure I opened the lid and checked, the SPI_SE pin on the MCU is missing an SMD resistor. So it seems that it indeed is SPI ready.

Now, when I probe the SPI_CLK pin (CH3 on the PCB) I don't see a clock signal. Is it because the clock signal is only there when the board tries to communicate with the radio module? More generally, how would you go about debugging this?

[SidneyBovet]

I got it working. I don't know how but I did. What may have solved it all is I was playing with the Android interface, and I unticked the channel right above the pilot name on the Pilots tab. When I ticked it back on, I got a sensible RSSI reading that corresponded to how I moved with my drone.

Anyhow, I guess the question of how to debug such a situation still holds, but this issue may be closed!

[StarrrLiteNL]

Just to chime in: I have the same "issue" with the Android app; Whenever first connecting, I have to disable all channels and enable them 1 by 1 to get them to reliably work.

I think this stems from the fact that the communication between the app and the chorus is via UDP, which has no guaranteed delivery or acknowledgement state.

This means that the app sends a "enable this channel on this frequency" message, but it has no way of checking wether the chorus device actually received the message. Thats just a downside of using UDP instead of TCP (upside is speed, less overhead and simpler to program/manage).

The same issue can arise when switching channels or changing RSSI thresholds. It sometimes misses a message/command, especially if you are at the edge of your Bluetooth/WiFi range.

The best way to solve these issues would be to switch to switch the app and firmware to TCP/IP and/or have an acknowledgement for each sent command to the tracker, with the ability for the app to resend lost commands etc.

Perhaps worth it to open a new ticket to improve this, since it can be quite annoying and would improve (perceived) reliability .