Rak12500 Heading value is millions of degrees

[paoloponzano]

Category

Other

Hardware

Rak4631

Firmware Version

2.3.6

Description

Im using a node based on Rak Meshtastic starter kit + Rak12500 ZOE-M8Q GPS. When looking at the reported Heading of the node on the map, the values are always millions of degrees. It can for example show 15.043.000° at one gps fix and 8.588.000° at the next one. Has always been wrong since I started using it with 2.2.15 and behavior is the same now on 2.3.6. I’m using the iOS app, latest version. If i disable the gps module and have my phone share the location instead, then heading is correctly reported with values between 0° and 360°. The speed indication is also way too high, showing speeds over 300km/h when I’m actually traveling at about 40-50km/h, but that seems wrong even when using the phone for location. I activated both speed and heading position flags when screenshot were taken. Another thing i think is worth noting: -if speed position flag is active and heading is disabled, only HEADING is indicated (still wrong) and speed is always 0 -if heading position flag is active and speed is disabled, only SPEED is indicated (seemingly slightly more accurate) and heading shows always 0. -if both position flags are disabled then they will both show 0. This behavior seems unaffected by the other flags. If any other information may be useful, please let me know and I’ll gladly help.

Relevant log output

No response

[thebentern]

@GPSFan think this is another TinyGPS bug?

[GPSFan]

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.

[GPSFan]

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

[paoloponzano]

@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?

[GPSFan]

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.

[paoloponzano]

Rak12500_LOG.txt

[GPSFan]

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

[paoloponzano]

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

[paoloponzano]

Rak12500_LOG.txt

[GPSFan]

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

[paoloponzano]

[GPSFan]

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.

[GPSFan]

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

[paoloponzano]

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

[paoloponzano]

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

[GPSFan]

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.

[paoloponzano]

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?

[GPSFan]

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.

[garthvh]

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

[garthvh]

[GPSFan]

@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...

[paoloponzano]

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

[paoloponzano]

@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

[GPSFan]

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.

[paoloponzano]

Also with legacy map

[garthvh]

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

[GPSFan]

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.

[GPSFan]

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) ;>))

[paoloponzano]

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? 👉👈

[GPSFan]

@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.

[paoloponzano]

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

[garthvh]

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.

[GPSFan]

@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.

[garthvh]

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

[GPSFan]

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

[garthvh]

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. https://github.com/meshtastic/firmware/issues/3984

[GPSFan]

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.

[paoloponzano]

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