Stratux VK-162 Altitude about 70 ft higher than actual (Ground Testing)

[PM490]

1. Stratux version: v1.0r1 (945c8bf6bc)

2. Stratux config: IMG

   SDR

   • [ ] single
   • [X] dual NooElec NESDR Nano 2

   GPS

   • [X] yes VK-162
   • [ ] no type:

   AHRS

   • [ ] yes
   • [X] no

   power source: Car Adapter (https://www.amazon.com/gp/product/B00M6QODH2/ref=oh_aui_search_detailpage?ie=UTF8&psc=1)

   usb cable: Micro-USB to USB Cable - 3 Feet

3. EFB app and version: (e.g., WingX Pro7 8.6.2) Foreflight 8.0.3 (2324)

   EFB platform: (e.g., iOS 9.2) iOS 9.3.5

   EFB hardware: (e.g., iPad Mini 2) iPad Mini 2

4. Description of your issue: Ground Testing Stratux (first time user), Indicated GPS Altitude is about 70 ft higher than actual. Local for testing is about 10-15 ft and unit indicated 85 ft. Tested unit while driving, and other GPS indications appear correct, including speed, heading, etc. Any advice before flight testing? Thanks for the great work everyone is doing.

Additional information - Revised 9/15 with Screenshots. The discrepancy in altitude is presented in the Stratux screen (see screenshot). While on the ground, the error stays constant.

The same error is observed on the EFB while on the ground.

What was unusual is that during flight, the altitude error does not show... the Stratux indications are very close to a Garmin 430W.

[skypuppy]

How long did you watch it? Is SBAS (WAAS) active? There are many reasons why it could show up that way. Did you get altitude off the stratux user screen or off your EFB?

[PM490]

@skypuppy Had it running for about an hour, the altitude was solid (not bouncing) but it was just higher. Was looking at the info from the EFB, don't recall checking altitude from the stratux screen, but from the indications were solid (more than 10 satellites, etc).

[skypuppy]

Ah ha. We had some discussion on reddit about that some time back. Basically, some EFB's use a different model of the Earth (geoid) than others. GPS's in the US are supposed to standardize around WGS84 (yeah, nitpicking details) but there are at least 2 ways to interpret it. Not all EFB vendors implement it the same way, either. Some try to take the raw data they get from GPS's and basically subtract (or add) 100 feet then display that as aircraft data (which does not use WGS84, I think.) There are other reasons the EFB differs, but that is the most likely. If you get a chance, please compare the readings from the stratux web interface to the EFB. Btw, which EFB are you using? Sunstorms can make gps readings incorrect for hours at a time but they usually fluctuate. Further, if the EFB is "averaging" the altitudes over time (and they have many algorithms to choose from,) that can lead to readings being off as well. It's way to complicated for my little brain.

[PM490]

EFB Foreflight 8.0.3 (2324) (I should have entered the info on another line, but is above). Thanks for the tips, exactly what I was looking for to do a better troubleshooting. Before Stratux, I have use the EFB with Dual Electronics XGPS150A, and do not have an issue of accuracy is actually very reliable and virtually the same readings as the Garming 430W. With the info you provided I will do another test run and report. Being in South Florida, ground at 85 ft is not the norm. Thanks again.

[PM490]

@skypuppy information was very helpful, included additional information on the issue, following the troubleshooting guidance above.

I think there may be an issue with the Stratux altitude calculation while on the ground, since the information displayed by Foreflight matches the information on the Stratux GPS status.

Additionally, while inflight, ownship is shown in the EFP as -100 ft... is the EFB thinking that it is higher, and therefore not identifying itself?

I do not have an explanation of why the error disappear while inflight... I was flying solo, so didn't have the availability to check it all the way to landing...

Thanks again for the great work everyone is doing with Stratux, and hope that this information is useful in addressing issues with the present build/components.

[ghost]

@skypuppy - you're onto something with the WGS84 vs MSL hypothesis.

@PM490 - on the ground, point Safari to your Stratux at http://192.168.10.1/getSituation . This is a JSON formatted output of the current position-related data, and includes all processed GPS-related height information, plus the most recent message received from your VK-162.

Output will look something like this (this is from one of my dev branches -- some fields will be different).

I'm looking for the values for the following variables (highlighted above in green):

• HeightAboveEllipsoid
• GeoidSeparation
• Alt
• LastValidNMEAMessage (this should be a string starting with $PUBX,00. If it starts with $PUBX,03 or $PUBX,04 hit refresh once or twice to pick up a $PUBX,00 message.)

What @skypuppy touched on is the fact that GPS altitudes are initially calculated against a relatively simple mathematical spheroid (WGS84 datum). However, the Earth isn't graviatationally smooth; it has, for the lack of a better description, corners. For example, mean sea level over most of the US and Canada is about 20-35 meters below zero height on this ellipsoid.

(Source: http://cddis.nasa.gov/926/egm96/egm96.html)

To compensate for this, applications have to apply a correction ("geoid separation") to the WGS84 height above ellipsoid, or the GPS has to apply the correction to the raw data. Most EFB apps expect the latter, so Stratux reads a HAE value from the raw GPS data, applies a correction (also provided by the GPS), and sends this corrected MSL altitude out to the EFB.

I have a hunch that the HAE handling on your particular GPS is getting a bit wonky at heights below 0' HAE. In south Florida, the geoid separation is about -95 feet: +15' MSL would be about -80' HAE. If the GPS was reporting height of 0', rather than -80', the "corrected" MSL height reported by Stratux would be about +95'. This would also explain why the error goes away once you're airborne: once you hit +95' MSL, you're above 0' HAE, and the GPS would indicate correctly.

Additionally, while inflight, ownship is shown in the EFP as -100 ft... is the EFB thinking that it is higher, and therefore not identifying itself?

If your plane isn't ADS-B Out equipped, that yellow target is probably a TIS-B target corresponding to your Mode C. The indicated altitude would be the pressure altitude reported by your transponder, and there is a -100 foot difference between that altitude and whichever altitude FF is using as a reference.

[PM490]

@AvSquirrel Thanks for the very instructive overview. Your track certainly matches the behaviour. Here is the info from getSituation while on the ground.

{"LastFixSinceMidnightUTC":76459.4,"Lat":25.962639,"Lng":-80.14081,"Quality":1,"HeightAboveEllipsoid":0,"GeoidSep":-87.59843,"Satellites":5,"SatellitesTracked":15,"SatellitesSeen":14,"Accuracy":4.4,"NACp":10,"Alt":87.59843,"AccuracyVert":4.6,"GPSVertVel":0.28871393,"LastFixLocalTime":"0001-01-01T00:02:42.07Z","TrueCourse":0,"GroundSpeed":0,"LastGroundTrackTime":"0001-01-01T00:02:42.07Z","GPSTime":"2016-09-15T21:14:18Z","LastGPSTimeTime":"0001-01-01T00:02:40.68Z","LastValidNMEAMessageTime":"0001-01-01T00:02:42.07Z","LastValidNMEAMessage":"$PUBX,00,211419.40,2557.75831,N,08008.44829,W,0.000,G3,2.2,2.3,0.487,357.26,-0.088,,2.38,4.95,4.13,5,0,0*56","Temp":0,"Pressure_alt":0,"LastTempPressTime":"0001-01-01T00:00:00Z","Pitch":0,"Roll":0,"Gyro_heading":0,"LastAttitudeTime":"0001-01-01T00:00:00Z"}

I have not been actively programming professionally for many years, and restarted coding some Arduino last year. Sounds like it is time to learn more about Raspberry Pi... In the mean time, hope this troubleshooting info is helpful to improve Stratux.

Understood completely on the ownship showing as traffic, the plane has Mode-S and is TIS.

[ghost]

@PM490 - thanks for the data. Agreed that this seems to confirm my hypothesis: the HAE field in the PUBX,00 message (after "W" and before "G3") is zero, when it should be about -22 m. This causes the geoid separation (87.6 feet) to be reported as altitude.

$PUBX,00,211419.40,2557.75831,N,08008.44829,W,0.000,G3,2.2,2.3,0.487,357.26,-0.088,,2.38,4.95,4.13,5,0,0*56"

There's one other GPS message (GGA) that might be able to give valid altitude data. If you are able to plug the Pi into your LAN and SSH in, run cat on the GPS port and it will stream the output of the GPS device, i.e.:

cat /dev/ublox7 (if you have the newer version of VK-162) cat /dev/ublox6 (if you have the older version of VK-162)

You'll get a GPGGA message about once per second, interspersed with about eight PUBX messages, e.g.:

$GPGGA,165840.90,44xx.xxxxx,N,093xx.xxxxx,W,1,12,0.77,281.8,M,-30.7,M,,*74

Hit ctrl-C once one appears. MSL altitude in meters (e.g. 281.8) is towards the end of this string, before the first "M". If that give a proper reading (~5 m, rather than 27 m) then it should be possible to rework the code to resolve this issue.

[Ergonomicmike]

So, do you think he has a bad GPS unit? I mean, aren't there a lot of Stratux users in FL using the VK that don't have this issue? Not to mention all the other VK users around the country?

[PM490]

@AvSquirrel Here is the information for the new reading on the ground (using cat /dev/ublox7).

$PUBX,00,175424.60,2557.76257,N,08008.44676,W,0.000,D3,0.70,2.0,0.362,332.47,-0.223,,1.03,2.08,1.35,9,0,0*6E
$GPGGA,175425.00,2557.76259,N,08008.44678,W,2,09,1.03,6.8,M,-26.7,M,,0000*65

For comparison, also below the getSituation info. {"LastFixSinceMidnightUTC":64366.2,"Lat":25.962725,"Lng":-80.14077,"Quality":2,"HeightAboveEllipsoid":0,"GeoidSep":-87.59843,"Satellites":9,"SatellitesTracked":15,"SatellitesSeen":11,"Accuracy":2,"NACp":11,"Alt":87.59843,"AccuracyVert":5.2,"GPSVertVel":0.6922572,"LastFixLocalTime":"0001-01-01T00:02:24.32Z","TrueCourse":0,"GroundSpeed":0,"LastGroundTrackTime":"0001-01-01T00:02:24.32Z","GPSTime":"2016-09-16T17:52:46Z","LastGPSTimeTime":"0001-01-01T00:02:24.13Z","LastValidNMEAMessageTime":"0001-01-01T00:02:24.32Z","LastValidNMEAMessage":"$PUBX,00,175246.20,2557.76352,N,08008.44616,W,0.000,D3,1.0,2.6,0.106,0.00,-0.211,,1.03,2.09,1.36,9,0,0*58","Temp":0,"Pressure_alt":0,"LastTempPressTime":"0001-01-01T00:00:00Z","Pitch":0,"Roll":0,"Gyro_heading":0,"LastAttitudeTime":"0001-01-01T00:00:00Z"}

@AvSquirrel If I understand it correctly, the GPGGA does have a valid altitude closer to the actual (6.8 M). @Ergonomicmike I am no expert on GPS, but from the troubleshooting support that @AvSquirrel and @SkyPuppy have kindly provided, this looks more like a bug in the GPS processing. I just happen to be at a location where the separation of the geoid is negative, apparently the only condition at fault.

Thanks to everyone for their time and support.

[skypuppy]

Just reading the rest of this now, and even though it is too late for this question, an easy way to get the gps data is "apt-get install minicom cutecom" and use either tool to capture as much data as you want by sending the strings into a file. You'll need to know, using above info, where the gps is /dev/ublox7. Cutecom is more intuitive while minicom use control characters you have to memorize.

[ghost]

@PM490 -- that's encouraging information. I agree that the GGA message is reporting your MSL altitude correctly (antenna height of +6.8 m / 22') to within "reasonable" measurement uncertainty.

I wrote a simple patch against v1.0r1 (https://github.com/AvSquirrel/stratux/commit/9939ba986af0c48173221746371e6b74f75b226f) to work around the PUBX,00 zero floor. This will ignore altitude updates from the PUBX,00 message if (and only if) PUBX,00 HAE == 0, and effectively to fall back onto the 1 Hz GGA messages (which do correctly report altitudes below the reference ellipsoid) as long as PUBX,00 reports HAE of 0. I intentionally did not "bypass" PUBX,00 HAE values < 0, in case there are versions of the ublox firmware that handle this correctly.

If you don't want to pull from my repo and compile, the following update script can be unzipped and loaded via the Stratux web UI: update-stratux-v1.0r1-9939ba986a.sh.zip

Give it a shot and let me know if the UI (and ForeFlight) report your ground elevation correctly. If it works I'll submit a PR to get this into the main development branch.

@Ergonomicmike - this seems to be a bug in the firmware of this version of the ublox 7 chipset, seen only in one type of position message. I'm guessing that most it hasn't been squawked before now since it would only be seen below about 75-100' MSL, and because it's not unusual for many of us to see ±50 feet variations in GPS altitude while running ground tests -- the offset is about the same magnitude as our gauge capability.

@skypuppy - yeah, they're both good tools. I've used minicom here and there, especially when I want to send control commands back to the GPS without having to recompile or write a shell script. But, cat is quick if I just need a peek at something, and I can run it without taking over the port.

[Ergonomicmike]

@AvSquirrel I'll take any excuse to fly to FL to test this further.

[PM490]

I wrote to U-blox asking about the issue. Initially they indicated the issue as one of documentation... I don't follow that one. Below the response I got:

This is not a u-blox bug but a documentation oversight. u-center describes these fields as "Geoid Separation = Alt(HAE) - Alt(MSL)". The GPS compendium document on the u-blox website describes this field as "Height differential between an ellipsoid and geoid". The descriptions for GGA and GNS messages within the document u-blox 7 Receiver Description and Protocol Specification should indicate "Geoid separation: Altitude above ellipsoid - Altitude above mean sea level" but do not.
This updated description for Geoid separation is in the latest version of u-blox M8 Receiver Description and Protocol Specification.

I didn't follow how this related to a PUBX,00 altRef (HAE) being 0 when it should probably be a negative number for this location. After requesting clarification to U-blox, I got confirmation of the issue reported.

That the PUBX HAE value would never go negative was found as an issue in u-blox 7. As AvSquirrel has implemented, the suggested workaround for u-blox 7 is to use one of the standard NMEA messages that display altitude.

Thanks to u-blox for reviewing this thread and confirming the issue... Great work @skypuppy @AvSquirrel in finding the issue.

In the mean time, installed @AvSquirrel patch and the in ground testing reported altitude in the EFB now active while on the ground, instead of pegged at 85 ft as before. Will probably not get a chance to fly test for a few days, but will do and report anything else then. Unless @Ergonomicmike makes it to South Florida and beats me to it.

Thanks again for sharing the knowledge, support (including U-blox), and for taking the time to assist in troubleshooting.

Also, would appreciate any recommendations on getting up to speed on Go to help the Stratux cause?

Regards to all.

[Ergonomicmike]

Nice job, everyone! As someone else said when a user came up with that neat OLED mod, it's amazing what we can do when DHS isn't looking. The synergy is amazing.

We get so much done that, unfortunately, I fear that one of these days the powers that be will cripple the net.

(Ironically, those powers might include makers of production ADS-B units who are seeing their profits drop because Stratux development. Remember the patent wars over FM and Color TV and how those in power abused their power to stifle innovation.)

[ghost]

@PM490 -- thanks for testing, and thanks for reaching out to u-blox. I submitted a PR to incorporate this into the master branch.

Also, would appreciate any recommendations on getting up to speed on Go to help the Stratux cause?

Three "official" sites that you'll probably come back to include: A Tour of Go - interactive tour / tutorial / overview Go Documentation - descriptions / syntax for all Go libraries Effective Go - overview of key Go concepts: structure, style, variables, etc.

Go By Example is another good hands-on resource.