gabrielcox
commented
4 years ago You are correct that this is a bit of a bug.
The data dictionary in the spec says the following:
Vertical speed upward relative to the WGS84 datum, meters per second. Special Values: Invalid, No Value, or Unknown: 63m/s, if speed is >= 62m/s: 62m/s**
The field description block definition shows the following:
Vertical Speed m/s (+ up, - down) Multiplier = 0.5 Up to +-63.5 m/s (12.5k ft/min) Example: 15(enc)=7.5m/s
The spec itself has a bug in the block definition, where it should say "up to +- 62m/s (12.2k ft/min)" to be consistent with the data dictionary. I'll put that bugfix in the backlog of the spec. (I chair the ASTM workgroup). Also, the there's a "sentinel" value of 63m/s (126 encoded) that represented "unknown/invalid". This is where the INV_SPEED_V comes in (which is properly defined in the code) We chose this value since 0 is legit as is -1, etc. So we went to (near) the top of the range.
It's a signed byte. So, the encoded range is -124 to +124. You decode it by multiplying the encoded value by 0.5. This allows 0.5m/s increments (since m/s is rather course for vspeed). 1 m/s is roughly 200ft/min
The decoded range is -62m/s to 62 m/s, or -12,205 ft/min to + 12,205ft/min
The range checking that uses these constants are against the decoded range (line 289 of opendroneid.c), therefore the value of MIN_SPEED_V should be -62, not 0.
Will fix.
https://github.com/opendroneid/opendroneid-core-c/blob/4127148e925784c38c4cb7401e6dffffb5912ed5/libopendroneid/opendroneid.h#L36
I may be missing something, but the current definition does not allow negative vertical speeds, i.e. a UAS cannot report it is descending.