Clooney82
commented
8 years ago Hi Paul,
as I remember currently we will not sent new GPS Data if ap_fixtype is lower than 3. Only heading is updated and sent always, GPS Data should stay at last known value when ap_fixtype>=3. See Mavlink.ino:
- Line: 290-300 (GPS Data - lon, lat, speed, alt, hdop)
- Line: 463-485 (Heading from Compass)
But in FrSkySPortTelemetry.ino (lines you posted) no new data will be sent when ap_fixtype < 3 This behavior is/was needed to set home position on Taranis and prevent resetting it if ap_fixtype < 3.
I think cause of resending "old"/ last know position where ap_fixtype>=3 this is not needed anymore. To test you only need to remove line 390.
I currently cannot test it, cause I have no working copter.
athertop
Even though the Hdg sensor is sourced from the HUD mag data (which is constantly available), because this is sent to smart-port inside the GPS sensor, this is only sent when there is a 3d fix. This is set by the code (in FrSkySPortTelemetry.ino - from line 389):
void FrSkySportTelemetry_GPS() { if(ap_fixtype>=3) { gps.setData(ap_latitude / 1E7, ap_longitude / 1E7, // Latitude and longitude in degrees decimal (positive for N/E, negative for S/W) ap_gps_altitude / 10.0, // Altitude (AMSL, NOT WGS84), in meters * 1000 (positive for up). Note that virtually all GPS modules provide the AMSL altitude in addition to the WGS84 altitude. ap_gps_speed * 10.0,// / 100.0, // GPS ground speed (m/s * 100). If unknown, set to: UINT16_MAX ap_heading , // Heading, in degrees * 100, 0.0..359.99 degrees. If unknown, set to: UINT16_MAX ap_gps_hdop);The suggestion is to send the GPS data even when there is no 3d fix, but always include the ap_heading value as this will always be available.
My original thought was that if ap_fixtype<3 then we would want to do the gps.setData but just including the ap_heading value, with all other values being set as null, but I think this could cause another issue: At present, once we have a 3d fix, we see this GPS data updating our telemetry, but if that fix is dropped, then the telemetry feed will retain the last known GPS - this is a feature I am sure we would like to keep. If my original idea of sending null values if ap_fixtype<3 would cause those GPS values to be zeroed when we lose the fix - so this is not what we need. Instead, we need that if we lose the fix (I.e. if if ap_fixtype>=3 then it goes to <3) then I would think we need to send the data with last known values rather than null values, such that the telemetry sensor retains its last known GPS info, but it will always have current Heading information updated.
Jochen, would you be willing to look at this suggestion please - its a bit beyond my programming abilities ;-)