Pre-arm: GPS x: not healthy but RTK fixed and flying without issues if forced

ArduCopter Copter 4.5
1

CubeOrangePlus
ArduCopter V4.5.7
GPS 2: Septentrio AsteRx SBi3 Pro+ (primary)
(GPS 1: here3 is secondary)

I am using an Septentrio AsteRx SBi3 Pro+ (dual antenna) and get an RTK fixed and zero errors from the Septentrio side. Arducopter is not happy though and reports GPS 2: not healthy every few seconds and won’t let me arm. If I takeoff in Alt-Hold and switch to Loiter in the air it works seemily fine. Also switching off the pre-arm check would work, but obviously neither is my preferred solution.
I think it is supposed to indicate that arducopter expects a specific pattern of data but is not receiving it?

I followed this guide: https://customersupport.septentrio.com/s/article/How-to-integrate-latest-Septentrio-GNSS-receivers-with-Ardupilot-using-Pixhawk-standard-boards

So I end up with that:
3

gps_delta
gps_delta1551×808 9.21 KB

356×284 28.5 KB

SERIAL3_BAUD,115 (same on Septentrio)
SERIAL3_OPTIONS,0
SERIAL3_PROTOCOL,5

GPS_AUTO_CONFIG,0 (tried both)
GPS_AUTO_SWITCH,1 (tried both)
GPS_BLEND_MASK,5
GPS_CAN_NODEID1,125
GPS_CAN_NODEID2,0
GPS_COM_PORT,1 (tried both)
GPS_COM_PORT2,1 (tried both)
GPS_DELAY_MS,0
GPS_DELAY_MS2,0
GPS_DRV_OPTIONS,0
GPS_GNSS_MODE,7 (tried different settings)
GPS_GNSS_MODE2,63 (tried different settings)
GPS_HDOP_GOOD,140
GPS_INJECT_TO,127 (tried different settings)
GPS_MB1_TYPE,0
GPS_MB2_OFS_X,0
GPS_MB2_OFS_Y,-1
GPS_MB2_OFS_Z,0
GPS_MB2_TYPE,1
GPS_MIN_DGPS,100
GPS_MIN_ELEV,-100
GPS_NAVFILTER,8
GPS_POS1_X,0
GPS_POS1_Y,0
GPS_POS1_Z,0
GPS_POS2_X,-0.014
GPS_POS2_Y,0
GPS_POS2_Z,0
GPS_PRIMARY,1 (tried different settings)
GPS_RATE_MS,100 (tried different settings)
GPS_RATE_MS2,100 (tried different settings)
GPS_RAW_DATA,0
GPS_SAVE_CFG,2
GPS_SBAS_MODE,2
GPS_SBP_LOGMASK,-256
GPS_TYPE,9
GPS_TYPE2,26
GPS1_CAN_OVRIDE,0
GPS2_CAN_OVRIDE,0

Any help would be much appreciated.

2

Does no one have an idea?

3

It needs to be below 200ms otherwise it will signal bad health.

4

Thank you for the input!

Right not I am running double the frequency, yet it still throws the error :frowning:

Screenshot 2025-02-17 104713
Screenshot 2025-02-17 1047131383×261 53.7 KB

GPS_RATE_MS,100
GPS_RATE_MS2,100

Is there a window where the frequency should be in order for it to be considered “healthy” or just <200ms?

Thanks again!

5

125ms-200ms is optimal. And it needs to be consistent.

6

Thank you, that is very good to know!

Tried 200ms on the GNSS and 200ms on Autopilot - no luck.

Since I can only choose 100ms or 200ms on the GNSS side, nothing in-between, it should work if e.g. I set the Autopilot to 8Hz/125ms and the GNSS to 100ms? However it does not.

The baudrate of 115200 can’t be the issue I think. GNSS says 0,82kB/s, which should be easily covered.

7

Ask Septentrio how to get hard realtime 200ms out of their system.

8

Thanks, I will!
How did you come to this conclusion? Because of the 1-2Hz deviations in GPA?

Given the price of a Septentrio system you’d think it would be perfect…

9

GPS not healthy in ArduPilot FW context means: realtime (<= 200ms) not met.

1 Like
10

It seems like regardless of the set rate, via SBF, data is output every 500ms, which is bothering and proves you were right.

After switching to NMEA with all messages enabled, it worked without issues first try. What I am still unsure about is if Arducopter is using the heading info from the NMEA message HDT or just calculating using the GNSS antennas’ distances. It seems like it is actually using the data provided via NMEA but I am not sure.