Heading calculated incorrectly

[bri2k1]

1. Stratux version: stratux-v1.6r1-eu028-32d5e58b-us

2. Stratux config:

   SDR

   • single
   • [X ] dual

   GPS

   • [ X] yes
   • no
     type: u-blox M8

   AHRS

   • yes
   • [X ] no

   power source: 120VAC to 5V 2.1A adapter

   usb cable: USB-A to USB-C

3. EFB app and version: Adventure Pilot iFly GPS 11.1.43, and Garmin FltPlan Go 5.0.12

   EFB platform: Android 12

   EFB hardware: Galaxy Tab S7

4. Description of your issue: The heading is not calculated correctly, displayed both by the EFB and in the Stratux web page on GPS/AHRS page. It is not reciprocal or otherwise obviously offset; at times it somewhat matches actual heading. But it's never completely accurate. For example, the aircraft may be heading due north, but the displayed heading will be 270. Other times, the aircraft may be heading 270, but the displayed heading is 110. It's not wildly variable or changing, but it's just not right. The u-blox M8 is configured for GNSS only, 10x rate, NMEA sentences GGA.

[bri2k1]

I have connected the u-blox directly to a Windows PC and verified the GNVTG COG (true and magnetic) are accurate. However, connecting the same board to any Stratux results in incorrect heading being displayed, both in the Stratux web page and on the EFB. The Stratux web page and EFB display the same (incorrect) heading.

[jeffdamp-wave]

I'm currently on a custom build based on 1.6r1-eu027. I was out flying yesterday with the Stratux connected to my iPad running GP and a GDL52 connected to a Garmin 760. Both were in agreement with each other. After updating did you remember to "Set AHRS Sensor Orientation"? I'll be flying next week so will get my branch in sync and test again next week.

[jeffdamp-wave]

P.S. I was only 1 change behind the build you are using and it was a fix for race condition in disk usage.

[bri2k1]

@jeffdamp-wave appreciate the info, but I'm more confused now. I don't have an AHRS module, just the u-blox M8 GPS chip. It's a good GPS chip that can do ded reckoning if signal is lost, which is a frequent occurrence during steep turns and a reason I chose the chip. But I can't set the AHRS sensor orientation, it's disabled, since I don't have AHRS enabled. Could you please elaborate?

[jeffdamp-wave]

@jeffdamp-wave appreciate the info, but I'm more confused now. I don't have an AHRS module, just the u-blox M8 GPS chip. It's a good GPS chip that can do ded reckoning if signal is lost, which is a frequent occurrence during steep turns and a reason I chose the chip. But I can't set the AHRS sensor orientation, it's disabled, since I don't have AHRS enabled. Could you please elaborate?

Right so it should be picking up current and previous position and displaying that as a heading. Yes the Unit orientation shouldn't matter. I'm pretty sure I'm using a ublox 8 myself. Like I said I didn't see any discrepancies in direction when I was out the other day.

Where are you putting the Stratux in the plane? I found in Cessnas (high wing) the back window or the front window off to the side works best. If I put it on one of the side windows, the GPS loses lock a lot. You could turn on log to storage and then check the log file.

P.S. from looking at the code I see that my Heading comes from my AHRS sensor while yours would come from the GPS

stratux/main/gps.go

Line 2027 in ec997fb

mySituation.AHRSGyroHeading = float64(mySituation.GPSTrueCourse)

code has not changed much in a long time so not sure what would be going on.

[bri2k1]

@jeffdamp-wave I don't think the heading bug issue is related to losing lock. I have a dedicated Garmin GA35 antenna on the top of the rear empennage for the Stratux. Losing lock is just a consequence of doing 45 degree banked turns for 180 degrees of heading at the end of a survey line. The heading is wrong all the time, even in straight and level flight with great lock.

The heading problem is reproducible in the car too with an external antenna. I enabled verbose, persistent logging and drove due south down a street. I have a video of the car's navigation system showing us going due south, and the EFB showing our position translating south, but the heading of the "plane" pointed almost due west the whole time. There was great lock with 13 satellites in view.

I'm really interested in how the code produces the heading. It seems it's definitely not directly using the NMEA GNVTG COG field, which would be the best for me. Maybe I can try to just jam that in. Since it's not using that, at least not without some manipulation, there seems to be a problem with what it is doing -- I just haven't dug in far enough to know myself yet.

Not knowing which files would be helpful, I grabbed all the logs and will attach them here with the video. Please let me know if any other diagnostics would be useful and thanks for your help in troubleshooting.

pi.zip

20220619_124144.mp4

[jeffdamp-wave]

I didn't see the stratux.log file in your zip anywhere, that would be the most useful log. You might want to turn on the DEBUG settings too.
The code that collects the True heading is here:
https://github.com/b3nn0/stratux/blob/9a5f8a2f56aa388e1599a82618bae11a92586a93/main/gps.go#L1025
It does a split string on the NMEA line and then processes each item. GPSTrueCourse is getting assigned from index 1 of the line (second "," field).
On the output side for GDL90:
https://github.com/b3nn0/stratux/blob/9a5f8a2f56aa388e1599a82618bae11a92586a93/main/gps.go#L1979
Note that it does a * 10 and converts to a unit16 before splitting it into the two-byte GDL90 field.
Someone like cyoung or b3nn0 are going to be more familiar to the code. I'm just trying to point you in the right direction.
Building and running the code is pretty easy: https://github.com/b3nn0/stratux/wiki/Developing-Stratux

[N129BZ]

@bri2k1 -
This is some GNVTG data coming in from my stratux (latest version) with a ublox8 GPS. The code errors out when attempting to parse the truecourse value, which is x[1] = "". I don't ever see a GPVTG message, so I can't verify that. I also looked at GPRMC message, which has a Course Over Ground field.
GNVTG field values observed
[0]:"GNVTG"
[1]:""
[2]:"T"
[3]:""
[4]:"M"
[5]:"0.252"
[6]:"N"
[7]:"0.466"
[8]:"K"
[9]:"A"

[bri2k1]

@N129BZ thank you, I want to clarify what you are saying. Where did you see those values? Do you have additional logging/debugging enabled in Stratux to see them being parsed? I think I can add a line in gps.go to just use the value I am getting from GNVTG, because my u-blox does provide a valid COG in that message.

@jeffdamp-wave here is a stratux.log from the flight I am currently on. You can see my flight track at https://flightaware.com/live/flight/N6439N, I am obviously flying E-W survey lines. When I am flying east (heading 090), the Stratux heading on my EFB is somewhere around 300, and when I am flying west (270) it's reporting around 120. This seems like maybe it's miscalculating a +/- sign somewhere, as a guess.

I do not see the log trying to parse any GNVTG strings at any time. I also don't see any errors or anything obvious. When I'm not flying, I will try to hand-parse one of these strings through the code and see if I can catch the error, unless someone smarter than me gets to it first.
stratux.log

[b3nn0]

FWIW: I've never seen such behaviour, and cannot reproduce it. Some ideas though:
It would be interesting to know what heading your EFB is actually displaying.
There is Track from G[NP]VTG and G[NP]RMC.
I would be very surprised if these are handled incorrectly - everybody would have that issue then.

Then there is AHRS heading. If no AHRS is present, Stratux does some pseudo AHRS calculation based on GPS. That's what you can see as "GPS Attitude" in your log and will be transmitted in GDL90 AHRS messages. However, in case no AHRS is present, this will also be set to the GPS track. Maybe that's what's being displayed by your app, but has wrong values (or is encoded incorrectly, your your app decodes it incorrectly?)

Anyway, without a proper dev setup - preferably with a debugger - this is hard to figure out.
I'd rather recommend trying to figure this out from the other side: find out which value in which protocol message is actually wrong, then find out why it is wrong.

EDIT:
maybe check http://192.168.10.1/getSituation to see if the internal values are correct. If yes, it must fail later during encoding or decoding the respective protocol. If no, which one is wrong?

[bri2k1]

@b3nn0 thank you, I'm not sure if you posted before seeing my last message. I will repeat a couple relevant details:

1. The (incorrect) heading I reported is displayed in both the 192.168.10.1/getSituation page numerically, and situationally on the EFB.
2. I would love to figure out which message is being used by Stratux for heading/course. If I could see that, I would be able to figure out why it's wrong. The stratux.log with debug enabled that I uploaded today does not show any GxVTG messages that I can see. Looking at the code, I'm not sure I see where GxVTG is enabled if the device is ublox 8.
3. I'm happy to provide any details needed, but I'm not particularly familiar with Stratux. Can you please point me to how to set up a debugger?

[b3nn0]

the http://192.168.1.1/getSituation is raw JSON output of all internal headings.
Which one on there is wrong?
This one? AHRSGyroHeading
or this one? GPSTrueCourse

Same with the web interface. There is AHRS heading and GPS Track.
Most EFBs I know use the GPS Track to display the airplane icon. Maybe not yours (which would explain why you see the issue and many others don't)?

There is no logging during GxVTG parsing, that's probably why you don't see anything in the log.

For setting up a development environemnt with debugging, see here: https://github.com/b3nn0/stratux/wiki/Developing-Stratux

You can then set breakpoints and step through gps.go step by step, and inspect exactly what's going on. But that requires some developer experience..

[N129BZ]

@bri2k1 -
I followed the development environment steps as linked to by @b3nno above, so I am using Visual Studio Code with a remote connection to my Stratux, and I'm debugging gps.go in real time as the messages come from the GPS. The code in gps.go for GxVTG processing begins on line 1068 and the code for GxRMC processing begins on line 1202. I don't get any values in either message for a true course or COG, but that's because my Stratux is totally stationary. I was thinking I would put the Stratux in my car and use my laptop to run the debugging setup while driving around to see if I could duplicate your issue. (I'm retired so I need diversions from daily hum-drum. ;)

[b3nn0]

That's a way.. or you could just change the code slightly to provide a fake GxVTG and GxRMC ;-)

[bri2k1]

I'm used to running gdb, it's just tough to do all this while flying around 1,500 AGL so I appreciate the assist.

There is some useful info here, confirmed with the attached files.

1. The Stratux web page GPS tab "Heading" value matches the /getSituation GPSTrueCourse and AHRSGyroHeading values, which are also equal to each other.
2. The EFB is displaying the heading as reported in no. 1 above, e.g. not an EFB issue per se.
3. The actual heading of the aircraft is nowhere near what no. 1 above is reporting.
4. The ublox is reporting the correct Course Over Ground in the GNVTG messages, witnessed by the picocom.log file; note on line 82 "$GNVTG,270.05,T,274.90,M,132.979,N,246.276,K,A*31^M" which matches the due west heading of the aircraft, but the screenshots of no. 1 above show a heading of 069. Almost the reciprocal but not quite.

This was all gathered within a few seconds, with the aircraft on a constant heading of 270 true. I'm open to suggestions on what to do next. Thanks again
picocom.txt

[bri2k1]

@N129BZ I often run the Stratux from a high current USB outlet in my car. I do believe the GNVTG COG disappears when stationary. Today I'm in the airplane (with another pilot, don't worry) so I'm doing some airborne testing too.

[b3nn0]

4. The ublox is reporting the correct Course Over Ground in the GNVTG messages, witnessed by the picocom.log file; note on line 82 "$GNVTG,270.05,T,274.90,M,132.979,N,246.276,K,A*31^M" which matches the due west heading of the aircraft, but the screenshots of no. 1 above show a heading of 069. Almost the reciprocal but not quite.

Just used precisely that GNVTG line and put it in my gps.go. It correctly parsed that and set GPSTrueCourse to 270.05.

GxRMC also provides track, maybe these are wrong? Can you provide some samples?

EDIT: ah nvm. Just noticed you appended a whole log. Thanks

[bri2k1]

@b3nn0 from the same picocom.log here is a RMC message:
$GNRMC,154931.00,A,3252.99801,N,08507.75237,W,132.979,270.05,210622,4.85,W,A*2A^M

The value 270.05 does appear here too, but it's in a different order in the message compared to the VTG.

[b3nn0]

so yes, this GNRMC is also parsed correctly. When I hard-code that in gps.go, it will also parse and show up as 270°.

There are exactly two assignments to the GPSTrueCourse variable in the whole code base.
One for GxVTG and one for GxRMC...

Are you somehow injecting NMEA in any other way, e.g. via socket or something?
Otherwise I have no idea how that could happen...

[b3nn0]

So for the sake of completeness, I just used your whole log file and let Stratux read from it, instead of from the GPS serial port..
There is something very strange going on with your Stratux.

[N129BZ]

I just added a special standalone log file to my Stratux code that captures only the $GNRMC and $GNVTG sentences, and drove around the neighborhood... I can't reproduce @bri2k1 's issue either. My logged data faithfully reproduces all of the course and speed of my route. Now I'm wondering if I should try it again without the AHRS chip and with an external antenna and see if that makes any difference...

Is it that this issue may be caused by the antenna being used... a Garmin GA35 WAAS antenna may be incompatible with a ublox gps... @bri2k1, how are you connecting a Garmin WAAS antenna to your Stratux?

[bri2k1]

@b3nn0 no, it's just a USB connection to the Stratux, which again is a Pi 4. The specific ublox part is the Neo M8-U, which means built in USB, and ded reckoning capability. Btw I have run several different builds, including eu027, eu028, and the VirusPilot build, and they are all consistent in this way. I have tried on 3 different Pi boards and multiple antennas.

@N129BZ I'm not sure why they would be incompatible, I use this setup with the same ublox and GA35 antenna and my own software for aerial survey. But I also reproduce the issue with a Trimble 66800-52D puck antenna and the stratux.

[N129BZ]

I just re-ran my driving route test with the AHRS removed from my Stratux and the headings in my logs were 100% accurate. FWIW I'm using a ublox8 gps without external antenna in my Stratux.

@bri2k1 , can you post a link to the Neo-M8U that you are using?

[kdknigga]

The dead reckoning features of the NEO-M8U need to be configured and calibrated. I doubt Stratux knows how to do that.

See section 29 starting on page 119:

https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf

Perhaps a miscalibration problem is throwing off what the unit is reporting to Stratux.

[N129BZ]

@bri2k1 - I just bought a Neo M8-U so I am going to try and duplicate the issue with that.

[bri2k1]

Hey @kdknigga you were right on! We didn't know the M8 with its ded reckoning was orientation-sensitive, but it certainly is. Orienting it as printed on the PCB, or using the ublox utility to set the orientation, has completely resolved this. Thanks so much!

We would like to suggest a feature where the Stratux webpage could include the orientation utility for the ublox with ded reckoning. @cyoung or whomever might log such requests. It includes an AHRS orientation function, so hopefully this is within reach. Thanks again all for the great support!

[N129BZ]

It would be interesting to see if the Neo M8-U could also source the AHRS data since the device has an on-board IMU

[N129BZ]

The roll, pitch, and heading is definitely available in the Neo M8U device, the data comes over serial as a UBX-HNR-ATT message, or alternatively this data can be accessed over I2C or SPI interfaces. The device is avaliable at Mouser for $69.65 at https://www.mouser.com/ProductDetail/474-GPS-16329 which seems very reasonable since it's around the same cost as buying a u-blox GPS and the AHRS chip separately...