Hdg value only sent whilst 3d GPS fix

[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 ;-)

[Clooney82]

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]

Jochen,
Thanks for the info, I do understand that the mavlink.ino will cause the heading value to constantly be read from the HUD data, and I also see that this does not get sent when ap_fixtype < 3 (along with the GPS sourced data). I am wondering if I simply remove line 390, then in the instance where the satellite signal is lost, what would happen to the displayed GPS data? Would this not just revert to zero?

I will do some testing tomorrow to find out. The weather here is not kind to flying, but I believe it is to improve this week so hopefully I can find time and conditions to go outside!!

Thanks again, Paul

[athertop]

Hey Jochen,
I removed the line 390, 391 and 458 - essentially removing that 'if' statement, and it works perfectly as you suggested it would - we now get the Hdg updated as soon as telemetry comes online, and it continues updating even when the GPS fix is lost (I put a metal cup over the GPS to create the attenuation in signal ;-)
When the GPS fix is lost, it simply keeps the coordinates set to the last known fix, and once the fix is recovered, the coordinates start updating again - exactly as these did before this change.

I will merge the change shortly. The teensy code changes will include also the new Airspeed ("ASpd") sensor and the updated plane217.lua file containing the Airspeed and the reformatted power panel - I have NOT made these changes in the copter217.lua yet and will only do this in the future if @wolkstein is OK with this change. Haven't managed to speak to him yet about this.

Cheers, Paul

[athertop]

The changes are now merged. Will advise the OP that this has happened and shortly close this issue.

[athertop]

Issue resolved