#Rescue N/A Trouble Shooting MSP/Remote ID

3 messages · Page 1 of 1 (latest)

keen locust
#

Disclaimer - this is a question for someone familiar with the BetaFlight code. Possibly @cyan otter or @unkempt vapor
I'm trying to troubleshoot an issue where I get Rescue N/A during maneuvers. Here is my setup:
Configurator 10.10.0
IFRC/IFLIGHT_BLITZ_F722(STM32F7X2), version: 0
BTFL, version: 4.5.1
Remote ID Module: Phoenix UAS.
GPS BE-220 GPS M10 MSP Connected via Remote ID Module 57600 baud.
Blackbox 2kHz, GPS Connection set as debug.
So using MSP with GPS signal going through Remote ID on the way to the FC.
Everything works fine when just flying around, but during maneuvers I sometimes get Rescue N/A. I have examined blackbox data with GPS Connection set as debug mode and see where the Rescue N/As are triggered because the GPS_FIX state flag is removed and GPS Sat Count drops to 0. This typically happens if you have more than 2500ms between GPS updates. Then gpsSetState(GPS_STATE_LOST_COMMUNICATION) is called inside gps.c and among other things number of sats are set to 0 and GPS_FIX State is disabled.
Now the problem is that when I look at Blackbox data, it looks like there is useable & updated GPS data on both sides of the drop out, so 400ms apart. way shorter than the 2500ms required to trigger the GPS_STATE_LOST_COMMUNICATION call.
The only other place I can see the GPS_FIX Flag could be removed is by gpsSetFixState during the parsing of the GPS data, but judging from the rest of the data when GPS_FIX is removed, it look like there is a good fix. Everything looks valid.
Any recommendations for further troubleshooting? Worth noting is that the Baud Rate / FC Interval goes during the "outage", but it shouldn't be enough to trigger the 2500ms, but enough to drop slightly below a 5Hz refresh.

I have included 3 Screenshots from Blackbox viewer. Right before, during and after dropout. The dropouts are in the second flight in the log.

cyan otter
#

I can't open the logfile, it isn't a nromal log. Is it compressed somehow?

#

OK its a zip archive of a CSV file... the normal log file, uncompressed, would be best.