Rak12500 Heading value is millions of degrees about firmware HOT 38 OPEN

The firmware does some rudimentary sanity checks, TinyGPS++ sets course to 0 if the RMC sentence has a bad checksum, and GPS.cpp will log a warning if the course >360.
The NMEA data for the cog (course over ground) field of the RMC sentence is in degrees, it is either 0-359, or empty.
TinyGPS++ also looks at the Validity flag in the RMC sentence to determine if the GPS has a "FIX".
DOP (PDOP, HDOP, VDOP) are not indicators of the quality of a fix. They indicate how much the CEP is degraded by the geometry of the satellites used for the position fix. In general a bad DOP means a bad position fix, but a good DOP does not necessarily mean a good, or accurate position fix.
In the 2 NMEA sentences that Meshtastic uses (GGA & RMC) there is no other quality indication. The GSV NMEA sentences, include individual satellite signal strengths. In the u-blox binary protocol there are several messages that contain a variety of "quality" indicators. such as NAV-SVINFO, NAV-STATUS, NAV-SOL, NAV-PVT, NAV-DOP. Other GPS manufactures have similar data. Relying in DOP to throw out bad fixes will certainly work for bad DOP, but will not rule out poor fixes with good DOP.
In all the cases I have seen with "millions of degrees" of heading have had correct course indications in the serial log stream, and the incomprehensible headings displayed on @paoloponzano's phone were obvious scaling errors, 90 degrees being displayed as 9,000,000, 143 degrees being displayed as 14,300,000.
Where is this happening? that's the real question. We know that the NMEA data can't be outside the 0-359 range, and we know that when it gets to the IOS map display it is inflated by many orders of magnitude. The serial log stream reports the heading correctly, but that doesn't mean that it gets broadcast to the mesh correctly, or interpreted by the receiving app correctly.

from firmware.

@GPSFan think this is another TinyGPS bug?

from firmware.

A log, taken when the issue is present would also be helpful.

from firmware.

Copying the output should be ok, let's see what it looks like for a minute or 2, make sure that there are at least 2 position updates in the log.
Thanks.
My12500 should be here this weekend so I'll be able to dig more then.

from firmware.

That log is ok, but there are no position updates, let it go for 10-15 min or so.

from firmware.

Next thing to try is an android device connected to the node and see what it says. This will tell us whether it is the firmware of the app.
To me the heading issue is a conversion/display problem. the track is clearly reported as 96.99, the display in the app is 9.699.000

from firmware.

I don't do IOS, I looked at my android app and don't see a spot for heading, so help needed from someone with a clue about IOS.
I might be able to grab the Android sources, build the app and run it under debug to see what it gets from the mesh as a heading value, but I don't have time to do that in the near future.

from firmware.

If your friends are using LiliGo boards, and it's not an Imperial vs. Metric issue, and the heading is only displayed on iPhone/iPad, then I have to believe that it is an IOS app problem.

from firmware.

I have setup a NMEA simulator and connected it to my Chatter 2. I set the position to roughly @paoloponzano 's location and the Heading to 90 degrees. Works ok with my Android app, but alas no heading display, now all I need is an iPhone (I wonder if I can borrow my wife's) ;>))

from firmware.

Not sure about a TinyGPS+ bug, certainly could be, I'll have to see if I can replicate it, but the way it is displayed up above 7.540.000 reads as 7.5 degrees to me, and 26.535.000 reads as 26.5 degrees to me. %^%@! comma vs decimal point issues...
I have a 12500 on the way and will dig into it as soon as it arrives.
I should put together a NMEA message simulator so we can inject known NMEA data into the serial ports when stuff like this happens.

from firmware.

@GPSFan yes it was taken from an iPhone
Is there any particular way or method for me to take the log or do I just copy the serial output from VS?

from firmware.

Rak12500_LOG.txt

from firmware.

That log is ok, but there are no position updates, let it go for 10-15 min or so.

Seems like ctrl-c ctrl-v betrayed me and I forgot to check it copied the whole output...
I'm taking a new log, brb

from firmware.

Rak12500_LOG.txt

from firmware.

During that log, what was your app saying about the speed and heading?

from firmware.

from firmware.

These are the GPS position reports that got logged:

Rak12500_LOG_1.txt:DEBUG | 22:58:11 301 [GPS] New GPS pos@663a95e4:3 lat=44.984718, lon=7.731272, alt=242, pdop=7.88, track=93.21, speed=0.06, sats=8
Rak12500_LOG_1.txt:DEBUG | 22:58:42 332 [GPS] New GPS pos@663a9603:3 lat=44.984806, lon=7.730480, alt=242, pdop=3.80, track=96.99, speed=0.14, sats=9
Rak12500_LOG_1.txt:DEBUG | 22:59:12 362 [GPS] New GPS pos@663a9621:3 lat=44.984931, lon=7.730615, alt=265, pdop=7.37, track=96.99, speed=0.04, sats=12
Rak12500_LOG_1.txt:DEBUG | 22:59:46 396 [GPS] New GPS pos@663a9643:3 lat=44.984902, lon=7.730365, alt=257, pdop=8.46, track=96.99, speed=0.01, sats=9
Rak12500_LOG_1.txt:DEBUG | 23:00:17 428 [GPS] New GPS pos@663a9662:3 lat=44.985109, lon=7.730379, alt=292, pdop=4.34, track=96.99, speed=0.00, sats=9

As you can see, none of the speeds are very large and all the headings (track=) are about 93-96, and all the altitudes are 240-290.

from firmware.

Next thing to try is an android device connected to the node and see what it says. This will tell us whether it is the firmware of the app.

To me the heading issue is a conversion/display problem. the track is clearly reported as 96.99, the display in the app is 9.699.000

I might be able to check with an android device later today, I'll report back

from firmware.

Any ideas about the flag's mismatch thing? Could that be an app issue too?

from firmware.

It could be either the firmware or the app, it is most likely not TinyGPS++ since the position report in the log is correct.
Sorry I have no clue about flag mismatch.

from firmware.

I don't think the android app shows the heading, or at least I can't find it 😅
Maybe @garthvh could help us understand if this issues could be app related?

from firmware.

I don't think it gets displayed on android anywhere.

from firmware.

from firmware.

@garthvh so your display is correct where you are the US, whereas @paoloponzano has an incorrect display in Italy. Also Imperial vs metric units, but degrees are the same in both unit systems where the issue is.
Very strange...

from firmware.

@GPSFan good point, I'll try setting my phone to imperial unit to see if the heading value is affected

from firmware.

@garthvh @GPSFan it is not related to imperial/metric units
Another thing i just noticed: seems not related to just rak but other boards too (i know these people and they use lilygo)🤔🤔🤔🤔
And btw it happens on iPad too

from firmware.

Also with legacy map

from firmware.

The firmware does no quality checks for gps data, likely these are low accuracy headings.

from firmware.

The firmware does some rudimentary sanity checks, TinyGPS++ sets course to 0 if the RMC sentence has a bad checksum, and GPS.cpp will log a warning if the course >360.
The NMEA data for the cog field of the RMC sentence is in degrees, it is either 0-359, or empty.

from firmware.

I have setup a NMEA simulator and connected it to my Chatter 2. I set the position to roughly @paoloponzano 's location and the Heading to 90 degrees. Works ok with my Android app, but alas no heading display, now all I need is an iPhone (I wonder if I can borrow my wife's) ;>))

Any update on this? 👉👈

from firmware.

@paoloponzano I was able to borrow my wife's iPhone and using my NMEA simulator I injected position data into my Chatter 2 node. I set the position to roughly your location and the heading to 90. As you have shown, the heading displayed in the iPhone was 9,000,000. I then adjusted the position a bit at a time so I crossed the Atlantic and all of the US to a point in the Pacific Northwest. throughout the simulated journey, the heading remained the same. I do not believe that the heading displayed on the iPhone is the result of poor signal quality as my NMEA simulator produced NMEA data with lots of sats and good DOP.
I have no Apple development skills or hardware, so to debug this issue further we need someone with both who is willing to instrument the firmware and iPhone app to see what is going on.

from firmware.

@GPSFan thank you very much! I think we'll need @garthvh help

from firmware.

You can see the raw value from the firmware in the CSV download, it is passing through ridiculous values like 1370000 I updated database on the phone to not show values <= 0 or >360 but it should be fixed in the firmware.

from firmware.

@garthvh Please pardon my lack of knowledge about the finer points of Meshtastic, where and how do you get this CSV file? Is it the rangetest.csv, or something else.

from firmware.

There is a position log for each node that can be downloaded on iOS

from firmware.

Can the CLI, Web client or android app see that data? Can it be extracted out of the debug panel?

from firmware.

They are position flags so should be in the debug panel and the values show in the serial log. We don't validate any of the position data currently, I am sure we have quality values like DOP we can use here to throw out useless readings. #3984

from firmware.

@GPSFan thank you for the great info! I find these 'behind the scenes' very interesting :D

from firmware.