That in turn looks like it’s coming from GCS_MAVLINK::send_sys_status() in Ardupilot, where control_sensors_health comes from a call to gcs().get_sensor_status_flags, which in turn calls GCS::update_sensor_status_flags(). That in turn seems to be running this check:
In the screenshot near the beginning of the thread it’s reporting that it has a 3D fix, which means that it passes the min_status_for_gps_healthy() threshold, which seems to imply that gps.is_healthy() is failing. That in turn could be due to lost frames, frame rate below 5Hz, or other driver-specific things.
Sorry, but I got troubles with SD-card compatibility and so failed to write and download logs for analysis. Postpone checks to the next weekend - will take three SD-cards of different brands with me to avoid such a problem for sure next time.
Final result is a little bit confusing - after sd-card has been installed and initialized this annoying “Unhealthy GPS signal” message stopped to appear when arming. Here is the picture of GPA:deltas log showing that at arm/disarm data stream rate dropdown to 260ms when between this actions it is stable 200ms.
Ardupilot have very bad threads management - if some thread break other - this is bad behaviour and for me - this is serious reason why im not using AP now.
Now im using betaflight and flying only in acro mode.
But if need auto modes - for me only ardupilot best choice for this. Inav very bad imho…
As im remember old versions AP dont have problems with gps health warnings, because im think dont have crossfire protocol which introduce some problems in AP.
Imho…
Do you mean that mentioned problems has been invoked just by CRSF protocol support introduction in AP or they takes place only if this protocol is used for communication between FC and RC receiver?
As I remember yes use of crsf - creates problems. But if you test AP well after 4.0.7 you will see that it started throwing internal errors when you download logs or when you calibrate compass or whatever…
This is just due to one thread interrupting another and not maintaining the exact time frame for each thread.
I had a copter crash from 150 meters once and the first time in all the use of the ardupilo just on version 4.1+ Perhaps due to some kind of internal error …
And that was enough for me. At the same time, this error did not exist on earlier versions 4.1+ - it somehow appeared later …
How do you think - is it safer to use simple PPM as a communication protocol between FC and RC-receiver instead of CRSF (thanks God it is supported still)?
To be honest I’m not interested in CHSF telemetry channel at all due to SiK modems usage and OSD telemetry projection, CHSF low latency benefit is also not relevant to long range planes.
