I’m using Frsky pasthrough telemetry for my personal tracker, and Altitude msl appears to be one order of magnitude too small and truncated/rounded, or am I missing something?
True altitude here is 1466m msl (yes very high!)
Altitude msl contained in GPS Status frame (Data ID 5002) is binary 15.
Actual data frame = 0xFC011B7
I understand that the stated unit of measure is decimetres, and power = 2, but how do we end up with 15? The granularity is way too course to be useful.
I see the Arducopter code looks like this:
// Altitude MSL in dm
const Location &loc = _ahrs.get_gps().location();
gps_status |= prep_number(roundf(loc.alt * 0.1f),2,2)<<GPS_ALTMSL_OFFSET;
return gps_status;
Thanks for the feedback. The code works as intended, but I agree that when there is such an offset (1466m), the representation used is not that useful: 15dm x 1000 = 1500m (100m intervals).
I think it’s one of those situations where a revision to the protocol would significantly improve on the usefulness of the value and is therefore warranted.
Do you have a suggestion on the representation? Is meter accuracy sufficient? There’s enough room for a 16bit representation (max; sign included) but if we can save a few bits to reserve them for some other purpose, that’s always a plus…
A 16bit float may no be the best suited. Since we have to keep in mind that the value could be slightly negative (for locations below sea level), a principle similar to what is found for coding altitude in the GDL-90 protocol for ADS-B looks like a good option: https://www.faa.gov/nextgen/programs/adsb/Archival/media/GDL90_Public_ICD_RevA.PDF
Thank you for your response. My view is that you need to represent four decimal digits to a resolution of a metre. I have observed several trackers, for example, using initial MSL to determine “home” altitude. Local altitude is then relative to home (obviously), and you definitely need 1m local alt resolution for a nearby craft elevation calculation.
I read the altitude relevant parts of the faa document, but I must say I’m not keen to mix metric and imperial units, especially since I understand that even the US has an agenda to move to metric over time. Also, 25 ft resolution is not ideal.
Using 12 bits we can get metre resolution to a maximum altitude of 4095 m, or 4.095 km. 11 bits will give us a max alt of 2047m. Add a bit to make it signed = total of 12 or13 bits. I agree that floating point will not buy us any advantage.
Looking at the Passthrough protocol spec, the data id 5002 GPS Status record will not accommodate our needs. Do we use vertical and horizontal dilution of precision, say for FlightDeck?
Interestingly, the faa document seems to recommend a record type for altitude. Why not just use the Frsky DATA_ID_BARO_ALT_AP 0x21 record type? Sure it eats slightly into your link bandwidth budget, but must be viable already at 1 or 2 Hz.
Talking about baro altitude, I would like to draw your attention to a problem related to GPS altitude. I have observed constant fluctuations and drift up and down of GPS local and absolute altitude, even with good locks on good GPS receivers. This is easily observed on FlightDeck for example, where it often drifts a few metres negative or positive while the craft is on the ground. The problem does not occur when using barometric altitude, as it is far more stable.
In the special case where our data source is Ardupilot, like when creating Pasthrough data, using baro altitude may be a better choice. I understand that you may not wish to tamper with working code.
The protocol spec is in the process of getting updated (just need to get it replaced on the server) and the GPS frame is one of the very few changes that were made a while back… Compared to what is currently on the wiki, VDOP has been dropped (not that useful) and some of the bits are now used for the advanced GPS fix status (e.g., RTK Float). The last 16bits are available to replace the current representation of Alt MSL…
Regarding your tracker needs, is the Kalman filtered (GPS/INS/baro) altitude relative to home not suitable (that’s what FlightDeck uses for altitude)? It’s found in the HOME (0x5004) frame. I agree that the GPS altitude (or the baro alt for that matter) in and of itself is not that great but it’s there in case someone needs it and because there was room in the GPS frame for that. So if we can’t make the case that it’s useful for anybody, we could even discuss replacing with some other GPS info altogether if the motivation for that is good enough…
The FAA doc is for reference only (I though it was interesting because it showed the offset) and I wouldn’t advocate for implementing it the exact same way in ArduPilot (not enough bits for that anyway).
It would be great if we could use the 16 bits you mention. That would solve the space problem,.
I imagine the filtered altitude shouldn’t fluctuate a metre or two on the ground, but that’s happening. Strange?
When I use the mavlink library call
ap_bar_altitude = mavlink_msg_vfr_hud_get_alt(&msg) * 100; // m
then altitude on the ground is steady.
When the home altitude varies while the craft is on the ground the antenna, rightly, moves around to point at the imaginary location of the craft, and frankly it looks bad. The aesthetics are unacceptable. At a practical level it does not matter, because when the craft is close you don’t need the gain of the antenna, and when it is far the error is irrelevantly small.
I’m just checking if you are aware of any further developments around this issue. In particular, any improvement in the representation of GPS altitude in Passthrough data ID 5002.
I’m writing firmware to convert Frsky Mav passthrough out of a Taranis TX back to Mavlink for display in Mission Planner, and the truncation of altitude is a stumbling block.
This can be changed on your end for now by editing the ArduPilot source code. The advantage would be two-fold: 1) you wouldn’t have to wait for changes to occur in the official code to continue your development, and 2) we can then use the code you tested as proposed changes to the official ArduPilot code.
I can correctly decode the distance from home, and angle from home, but the altitude values I am calculating do not make any sense. I am referring to the data fields at bit offset:
19-20 10^x
21-30 decimetres
31 sign
I am flying a pixhawk which I assume can provide this data, since the altitude is displayed correctly on my GCS (Tower) via the 433 telemetry radio.
SOLVED??
I checked a working LUA script, and it appears that the altitude and angle fields are in the wrong order in the spreadsheet referred to above!
At a practical level it does not matter, because when the craft is close you don’t need the gain of the antenna, and when it is far the error is irrelevantly small.