Closed welbo97 closed 8 years ago
An error of ~ 1.5 degrees would be consistent with a quantization of the GDL90 track calculation.
Your GPS reports track as a float with a couple decimals of precision. This has to be encoded to an 8-bit byte for the GDL90 ownship message, leaving encoded track with a resolution of about 1.4 degrees:
The Track/Heading field "tt" provides an 8-bit angular weighted value. The resolution is in units of 360/256 degrees (approximately 1.4 degrees).
In Stratux, it's done here:
groundTrack := uint16(0)
if isGPSGroundTrackValid() {
groundTrack = mySituation.TrueCourse
}
trk := uint8(float32(groundTrack) / TRACK_RESOLUTION) // Resolution is ~1.4 degrees
This encodes all tracks between 0-1.4 deg as 0x00, 1.4-2.8 deg as 0x01, 2.8-4.2 deg as 0x02, etc. If ForeFlight is multiplying the encoded value by 360/256, these values decode to the floor of each "bin": 0x00 = 0 deg, 0x01 = 1.4 deg, 0x02 = 2.8 deg, etc. ForeFlight doesn't display decimals in the status window, so these would be visually displayed as 0, 1, 3...
In other words, a 2.75 degree true track is in the 1.4-2.8 degree bin. It would encode as 0x01, would decode to 1.4 degrees, and be displayed as 1 degree on the ForeFlight instrument bar.
I'd think the best way to remove this bias would be to convert based on the center of each "bin" by biasing the heading 360/512 degrees upwards before converting to the byte value:
groundTrack := uint16(0)
if isGPSGroundTrackValid() {
groundTrack = mySituation.TrueCourse + TRACK_RESOLUTION / 2
if groundTrack > 360 {
groundTrack =- 360
}
}
trk := uint8(float32(groundTrack) / TRACK_RESOLUTION) // Resolution is ~1.4 degrees
This change would need to be validated against other EFBs to ensure that they're not doing a similar unbiasing calculation on the decoded track.
Nice catch.
Strict adherence to gdl90 protocol seems to be important. It is unfortunate. The displayed track integer in FF is less precise than the visual track on the map. It looks like the stratus device conveys a more precise track as very small changes (possible 1/10th a degree) are visible on the map view while even the GPS track does not change. A 16 bit track message is desirable.
There was one other issue: GPS track was being stored internally as an integer. Even though most GPS receivers give us two places past the decimal, that data was lost, and track was rounded down.
This meant that any actual track between 0° and 2° was being encoded as 0°, between 2° and 3° was encoded as 1.41°, between 3° and 5° as 2.81°, and so on.
@welbo97:
Strict adherence to gdl90 protocol seems to be important. It is unfortunate.
An EFB developer doesn't have to use GDL90 -- Stratux has a comprehensive HTTP / websocket interface that provides far more detailed ownship data than we can provide with the legacy GDL90 protocol. Unfortunately, most developers haven't updated their products to use it, so we're stuck with all its limitations -- 5 or 25 foot altitude increments, 1.4 degree track increments, etc.
I'm pretty new to this so I'm sure I'm not suggesting anything new- what is the possibility of using the stratus protocol for communication? I assume the appearance of the "Genuine Stratus" indicator in the connected device settings has something to do with that.
@welbo97 - switching to a different protocol may help. We'll have to make do with GDL90 for now. Improvements by @AvSquirrel are now added and will be included in the next release. Should improve things.
Stratux config:
SDR [ ] single [ x] dual
GPS [x ] yes [ ] no type:vk-172
AHRS [ ] yes [x ] no
power source:RAV power 16,000mAh
usb cable:
EFB app and version: (e.g., WingX Pro7 8.6.2) Foreflight 7.6
EFB platform: (e.g., iOS 9.2) iOS 9.3.1
EFB hardware: (e.g., iPad Mini 2) iPad Air 2 wifi+verizon
GPS data transmitted from Stratux 8r2 release box displays in foreflight with a consistent -1 to -1.5 degree track error from the ship's various GPS sources (multiple aircraft). iPad internal GPS functions properly. Stratus 1 box functions properly.
Stratux and foreflight logs are available and will be added to this issue shortly.