RAK1910 GPS on RAK5005-0: GPS obtains no location fix after FW 1.2.46.dce2fe4

[feh123]

Describe the bug
RAK1910 on RAK5005-0 gets a gps fix on 1.2.46.dce2fe4, later versions do not get a fix.

To Reproduce
Steps to reproduce the behaviour:

1. Connect device to PC and install FW. Try a version later than 1.2.46.dce2fe4.
2. Check meshtastic --nodes for lat/lon.

Expected behaviour
Expected all versions after 46 to work.

Device: RAK5005-0/RAK4631/RAK1910 set up with gps in slot A.
Additional context
Curiously RAK19003/RAK4631/RAK1910 does not show this problem and gets a GPS fix up to FW 1.2.48.
I only have the iOS app and you can see the missing gps locations in this too. I cannot check the radio function to see if that varies with FW.
I have discussed this on Discord under device.

[mc-hamster]

@feh123 Do you have device logs for this?

[feh123]

Hi I have a serial output from platformio. It consists of a lot of lines - the first set show a 4631/1910 with working gps
Rak5005_4630_1910 Log 15-Dec-21.pdf on 1.2.46. Later (it's not that clear but if you check the times you see a gap) the pdf shows the problem 1.2.48 data. Hope this helps. The problem exists on 1.2.49 too. I can try to do it again if you need. Thanks.

[garthvh]

@a-f-G-U-C This seems to be related to a number of GPS changes you made, any insight in to why UBLOX stoped working for RAK after your changes?

[a-f-G-U-C]

Thanks @garthvh - good catch, although at a quick glance I couldn't really spot any problematic code.

Unfortunately I don't have a RAK device to test, and no fixed address to order some now, but I should still be able to get a pretty good idea from some good logs.
If someone (@feh123 , if you're still around, or anyone else) could please gist some before-and-after logs that actually show the problem, I would love to have a closer look.

What I'd like to see in the logs:

• (in the working case) the complete messages from boot until the first GPS fix
• (in the nonworking case) the complete messages from boot until either a GPS error or twice as long time has passed as in the working case, whichever comes first
• in plain text (TXT) format, please :)

Thank you

[feh123]

Hi @a-f-G-U-C I could try but can you give me some instruction on what log you need? The iOS app log is easiest but misses the start up of the rak device. I can connect the rak to my mac and I have meshtastic python running on that. I have not tried platformio on my mac yet nor any other serial type output software (Putty). So I maybe too limited on logging!

[garthvh]

@a-f-G-U-C There is already a log attached above. This (or some of the other changes that went into 1.2.46) are also likely affecting android app functionality per @andrekir and seems to have broken a number of GPS display modes.

[a-f-G-U-C]

@feh123 Unfortunately I'm not familiar with the RAK platform, but the easiest way to capture the messages is to connect a serial terminal (Putty is an unusual choice, but should work nonetheless), enter the correct port settings, and once you see the log messages correctly, press the reset button on the board.

@garthvh If you mean the PDF log, it doesn't really seem to capture the problem, but I may be wrong - can you please let me know which lines you had in mind?

[garthvh]

@a-f-G-U-C you can see on the first page of the log where there is WANT GPS=1 and it is powered on and then there is no response.

[tropho23]

I've attached ~40 minutes' worth of logs from my RAK 5005, hopefully it helps
RAK_log_dump.txt
.

[a-f-G-U-C]

Thanks @tropho23 , it does help.
Can you please confirm this is a WORKING case? Because I can see the position structs being populated and propagated correctly - as indicated by the pos@xxxxxxxx:[1-5] messages.

I am still not clear why the very first boot messages (with the firmware version, hardware initialization etc) are missing from all the RAK logs I've seen so far, is this normal for the RAK platform? There's an important piece of information in those early stage messages that we're currently missing:

https://github.com/meshtastic/Meshtastic-device/blob/7a9450b250e82b53e9f394540785aa447920f9df/src/gps/UBloxGPS.cpp#L57
This tells us whether the GPS is speaking the UBLOX or NMEA protocol - a simple setting that is probably the most frequent cause of GPS issues in these boards (protocol mismatch).

[mc-hamster]

I am still not clear why the very first boot messages (with the firmware version, hardware initialization etc) are missing from all the RAK logs I've seen so far, is this normal for the RAK platform? There's an important piece of information in those early stage messages that we're currently missing:

Hmm… That is normal for the nrf family of chips. The usb device needs to be initialized sooner in the startup sequence because they’re not using a usb bridge. This needs to happen before the rest of the M startup or the M startup delayed to accommodate the timing.

If a bug can be opened for this, I’ll work on the fix.

[tropho23]

Thanks @tropho23 , it does help. Can you please confirm this is a WORKING case? Because I can see the position structs being populated and propagated correctly - as indicated by the pos@xxxxxxxx:[1-5] messages.

I am still not clear why the very first boot messages (with the firmware version, hardware initialization etc) are missing from all the RAK logs I've seen so far, is this normal for the RAK platform? There's an important piece of information in those early stage messages that we're currently missing:

https://github.com/meshtastic/Meshtastic-device/blob/7a9450b250e82b53e9f394540785aa447920f9df/src/gps/UBloxGPS.cpp#L57

This tells us whether the GPS is speaking the UBLOX or NMEA protocol - a simple setting that is probably the most frequent cause of GPS issues in these boards (protocol mismatch).

I'm not sure what you mean by working; the RAK seems to function fine IRT LoRa and Bluetooth comms, it just never acquires any satellites. Is there something I should do or try to produce the information you need?

[a-f-G-U-C]

it just never acquires any satellites

@tropho23 , thanks for the clarification.
In your case (RAK_log_dump.txt), as far as my code is concerned, the position is read correctly from the GPS module, travels through the entire position workflow and is updated correctly in the node database - and this is the complete scope of my changes, as far as I'm aware.

Here are the log lines showing the correct operation:

16:56:22 2613 [GPS] lookForLocation() new pos@61f17d37:1
16:56:23 2613 [GPS] publishing pos@61f17d37:2, hasVal=1, GPSlock=1
16:56:23 2613 [GPS] New GPS pos@61f17d37:3 lat=39.368961, lon=-76.974702, alt=167, pdop=4.09, track=0.00, sats=5
16:56:23 2613 [GPS] onGPSChanged() pos@61f17d37:4, time=1643216183, lat=393689611, bat=94
16:56:23 2613 [GPS] updatePosition LOCAL pos@61f17d37:5, time=1643216183, latI=393689611, lonI=-769747023

Simply put, this is the correct lifecycle of a position object with timestamp 0x61f17d37 from acquisition (lookForLocation()) until the update of the node DB (updatePosition()). See also sats=5 which indicates a fair GPS lock.

Can you please give more details of your experience?

• is it the onboard display not updating correctly? or
• does the command meshtastic --nodes show bad data in the lat/lon/alt columns? or
• do your outbound position messages include bad lat/lon/alt data, or perhaps no data at all?
• what does the Preferences section of your meshtastic --info look like?

[tropho23]

it just never acquires any satellites

@tropho23 , thanks for the clarification. In your case (RAK_log_dump.txt), as far as my code is concerned, the position is read correctly from the GPS module, travels through the entire position workflow and is updated correctly in the node database - and this is the complete scope of my changes, as far as I'm aware.

Here are the log lines showing the correct operation:

16:56:22 2613 [GPS] lookForLocation() new pos@61f17d37:1
16:56:23 2613 [GPS] publishing pos@61f17d37:2, hasVal=1, GPSlock=1
16:56:23 2613 [GPS] New GPS pos@61f17d37:3 lat=39.368961, lon=-76.974702, alt=167, pdop=4.09, track=0.00, sats=5
16:56:23 2613 [GPS] onGPSChanged() pos@61f17d37:4, time=1643216183, lat=393689611, bat=94
16:56:23 2613 [GPS] updatePosition LOCAL pos@61f17d37:5, time=1643216183, latI=393689611, lonI=-769747023

Simply put, this is the correct lifecycle of a position object with timestamp 0x61f17d37 from acquisition (lookForLocation()) until the update of the node DB (updatePosition()). See also sats=5 which indicates a fair GPS lock.

Can you please give more details of your experience?

* is it the onboard display not updating correctly? or

* does the command `meshtastic --nodes` show bad data in the lat/lon/alt columns? or

* do your outbound position messages include bad lat/lon/alt data, or perhaps no data at all?

* what does the Preferences section of your `meshtastic --info` look like?

1. It always shows "No sats"
2. meshtastic --nodes reports gps info for the other active node, but N/A for the RAK node
3. I'm not sure how to inspect outbound positions messages
4. Output of meshtastic --info follows:

Connected to radio

Owner: RAKed7d (RKd)
My info: { "myNodeNum": 2744446333, "hasGps": true, "numBands": 13, "firmwareVersion": "1.2.52.b63802c", "bitrate": 17.08847, "messageTimeoutMsec": 300000, "minAppVersion": 20200, "maxChannels": 8, "channelUtilization": 4.6 }
Nodes in mesh: {'num': 2744446333, 'user': {'id': '!a394ed7d', 'longName': 'RAKed7d', 'shortName': 'RKd', 'macaddr': 'c8:f6:a3:94:ed:7d', 'hwModel': 'RAK4631'}, 'position': {'batteryLevel': 97}, 'lastHeard': 1643252198} {'num': 2475225456, 'user': {'id': '!9388f170', 'longName': 'Unknown f170', 'shortName': '?70', 'macaddr': '44:17:93:88:f1:70', 'hwModel': 'TBEAM'}, 'position': {'time': 1642545139}, 'lastHeard': 1642545128, 'snr': 7.0} {'num': 2475225712, 'user': {'id': '!9388f270', 'longName': 'Unknown f270', 'shortName': '?70', 'macaddr': '44:17:93:88:f2:70', 'hwModel': 'TBEAM'}, 'position': {'latitudeI': 393689595, 'longitudeI': -769746515, 'time': 1643252134, 'latitude': 39.368959499999995, 'longitude': -76.9746515}, 'lastHeard': 1643252134, 'snr': 6.5}

Preferences: { "phoneTimeoutSecs": 900, "lsSecs": 300, "region": "US", "positionFlags": 35 }

Channels:
PRIMARY psk=default { "modemConfig": "Bw125Cr48Sf4096", "psk": "AQ==" }

Primary channel URL: https://www.meshtastic.org/d/#CgUYAyIBAQ

[garthvh]

@a-f-G-U-C it works in the 1.2.45 firmware and it looks to me like all of the GPS code 1.2.46 contains is from you.

[tropho23]

I confirmed satellite acquisition works when using firmware 1.2.46; I just shared my results with garthvh to help isolate the bug.

[a-f-G-U-C]

Interesting, this is starting to look like a bug in, or downstream from updatePosition()

1. Position is provided to updatePosition() (which SHOULD update the nodeDB):

16:56:23 2613 [GPS] updatePosition LOCAL pos@61f17d37:5, time=1643216183, latI=393689611, lonI=-769747023

2. Position is not found in nodeDB:

{'num': 2744446333, 'user': {'id': '!a394ed7d', 'longName': 'RAKed7d', 'shortName': 'RKd', 'macaddr': 'c8:f6:a3:94:ed:7d', 'hwModel': 'RAK4631'}, 'position': {'batteryLevel': 97}, 'lastHeard': 1643252198}

Funny that it only seems to trigger on the RAK, it doesn't seem reproducible on the T-Beam. It also passed everyone else's tests at the time with no issues reported.

I'll keep looking and will update if I find anything. Thanks everyone for the info.

[garthvh]

Funny that it only seems to trigger on the RAK, it doesn't seem reproducible on the T-Beam. It also passed everyone else's tests at the time with no issues reported.

Sadly based on the timeframe involved I don't think much device testing was done. Are your pulls in 1.2.46 and 1.2.47 mostly plumbing for external apps? It seems like it may be necessary to start backing these pulls out and seeing when it starts working again. Is there any new or updated functionality that would be lost by Meshtastic if these changes are backed out? Will any external apps be broken?

[a-f-G-U-C]

Is there any new or updated functionality that would be lost by Meshtastic if these changes are backed out? Will any external apps be broken?

As far as my work is concerned, I work in a private offline repo. All the code that I pushed back to mainline has been with the expectation that it could be further modified, improved, broken, refactored or removed by other devs with no unintended backflow effect to worry about. So feel free to change anything.

As far as mainline Meshtastic is concerned, the Position plugin is obviously the one most intertwined with the GPS code. If you're going to rollback the GPS, you will likely need to revert the plugin code to match.

As far as external apps are concerned, any app that relies on device-originated Position might also be impacted - unfortunately I have no info about other (published) apps and no easy way to find out.

[a-f-G-U-C]

@tropho23 , @garthvh , all - just to understand the scope of the problem, does it affect all RAK devices? or is it all nRF devices, or even all non-ESP32 devices?

Thank you

[mc-hamster]

Funny that it only seems to trigger on the RAK, it doesn't seem reproducible on the T-Beam. It also passed everyone else's tests at the time with no issues reported.

I was troubleshooting something that sounds like this with @andrekir . He was having trouble receiving position updates on the android app connected to a tbeam while it worked fine on my end.

[a-f-G-U-C]

position updates on the android app connected to a tbeam

Could be related but I'm reluctant to conflate. I think the key symptom to check for is whether --info or --nodes shows no position when one is available (see above)

[mc-hamster]

For him, it didn't show position in the python cli while it did for me. Jm Casler Always Agile & Life Long Maker https://www.casler.org <http://www.casler.org/> +1 408 806 8098

…

On Tue, Feb 1, 2022 at 7:59 PM a-f-G-U-C ***@***.***> wrote: position updates on the android app connected to a tbeam Could be related but I'm reluctant to conflate. I think the key symptom to check for is whether --info or --nodes shows no position when one is available (see above) — Reply to this email directly, view it on GitHub <#998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBWG7INASUO3K4CZBDMGF3UZCTZ7ANCNFSM5KECR2WQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[tropho23]

@tropho23 , @garthvh , all - just to understand the scope of the problem, does it affect all RAK devices? or is it all nRF devices, or even all non-ESP32 devices?

Thank you

This only happens on my nRF-based RAK 5005. My T-beams works perfectly and my Heltecs do not have GPS add-ons.

[garthvh]

@tropho23 , @garthvh , all - just to understand the scope of the problem, does it affect all RAK devices? or is it all nRF devices, or even all non-ESP32 devices?

Thank you

The UBLOX based RAK 1910 GPS on the RAK 5005 base board is the combo having trouble getting a fix.

Thanks

[andrekir]

I think the key symptom to check for is whether --info or --nodes shows no position when one is available (see above)

@a-f-G-U-C @mc-hamster output for my 2 test nodes below.

---

$meshtastic --info
Owner: Unknown bebc (?BC)
My info: { "myNodeNum": 3186671292, "hasGps": true, "numBands": 20, "firmwareVersion": "1.2.53.19c1f9f", "rebootCount": 3, "bitrate": 17.08847, "messageTimeoutMsec": 300000, "minAppVersion": 20200, "maxChannels": 8, "hasWifi": true, "airUtilTx": 1.6891111 }
Nodes in mesh:  {'num': 3186671292, 'user': {'id': '!bdf0bebc', 'longName': 'Unknown bebc', 'shortName': '?BC', 'macaddr': '7c:9e:bd:f0:be:bc', 'hwModel': 'TBEAM'}, 'position': {'batteryLevel': 79, 'time': 1643804433}, 'lastHeard': 1643804433}  {'num': 1514768816, 'user': {'id': '!5a4989b0', 'longName': 'Unknown 89b0', 'shortName': '?B0', 'macaddr': 'dd:8c:5a:49:89:b0', 'hwModel': 'T_ECHO'}, 'position': {'latitudeI': -231985776, 'longitudeI': -458923268, 'altitude': 42949626, 'batteryLevel': 57, 'time': 1643804379, 'latitude': -23.1985776, 'longitude': -45.8923268}, 'lastHeard': 1643804369, 'snr': 6.5}

Preferences: { "phoneTimeoutSecs": 900, "lsSecs": 300, "region": "ANZ" }

Channels:
  PRIMARY psk=default { "modemConfig": "Bw125Cr48Sf4096", "psk": "AQ==" }

Primary channel URL: https://www.meshtastic.org/d/#CgUYAyIBAQ

$meshtastic --nodes
Connected to radio
╒═════╤══════════════╤═══════╤═══════════╤════════════╤═════════════╤════════════╤═══════════╤═════════╤═════════════════════╤══════════════╕
│   N │ User         │ AKA   │ ID        │ Latitude   │ Longitude   │ Altitude   │ Battery   │ SNR     │ LastHeard           │ Since        │
╞═════╪══════════════╪═══════╪═══════════╪════════════╪═════════════╪════════════╪═══════════╪═════════╪═════════════════════╪══════════════╡
│   1 │ Unknown bebc │ ?BC   │ !bdf0bebc │ N/A        │ N/A         │ N/A        │ 79.00%    │ N/A     │ 2022-02-02 09:21:15 │ just now     │
├─────┼──────────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼─────────┼─────────────────────┼──────────────┤
│   2 │ Unknown 89b0 │ ?B0   │ !5a4989b0 │ -23.1986°  │ -45.8923°   │ 42949626 m │ 57.00%    │ 6.50 dB │ 2022-02-02 09:19:29 │ 1 minute ago │
╘═════╧══════════════╧═══════╧═══════════╧════════════╧═════════════╧════════════╧═══════════╧═════════╧═════════════════════╧══════════════╛

---

$meshtastic --info
Owner: Unknown 89b0 (?B0)
My info: { "myNodeNum": 1514768816, "hasGps": true, "numBands": 20, "firmwareVersion": "1.2.53.19c1f9f", "bitrate": 17.08847, "messageTimeoutMsec": 300000, "minAppVersion": 20200, "maxChannels": 8, "airUtilTx": 1.8424444 }
Nodes in mesh:  {'num': 1514768816, 'user': {'id': '!5a4989b0', 'longName': 'Unknown 89b0', 'shortName': '?B0', 'macaddr': 'dd:8c:5a:49:89:b0', 'hwModel': 'T_ECHO'}, 'position': {'batteryLevel': 100, 'time': 1643804562}, 'lastHeard': 1643804562}  {'num': 3186671292, 'user': {'id': '!bdf0bebc', 'longName': 'Unknown bebc', 'shortName': '?BC', 'macaddr': '7c:9e:bd:f0:be:bc', 'hwModel': 'TBEAM'}, 'position': {'latitudeI': -231989513, 'longitudeI': -458939716, 'time': 1643804479, 'latitude': -23.198951299999997, 'longitude': -45.8939716}, 'lastHeard': 1643804494, 'snr': 5.25}

Preferences: { "phoneTimeoutSecs": 900, "lsSecs": 300, "region": "ANZ", "positionFlags": 35 }

Channels:
  PRIMARY psk=default { "modemConfig": "Bw125Cr48Sf4096", "psk": "AQ==" }

Primary channel URL: https://www.meshtastic.org/d/#CgUYAyIBAQ

$meshtastic --nodes
Connected to radio

╒═════╤══════════════╤═══════╤═══════════╤════════════╤═════════════╤════════════╤═══════════╤═════════╤═════════════════════╤══════════════╕
│   N │ User         │ AKA   │ ID        │ Latitude   │ Longitude   │ Altitude   │ Battery   │ SNR     │ LastHeard           │ Since        │
╞═════╪══════════════╪═══════╪═══════════╪════════════╪═════════════╪════════════╪═══════════╪═════════╪═════════════════════╪══════════════╡
│   1 │ Unknown 89b0 │ ?B0   │ !5a4989b0 │ N/A        │ N/A         │ N/A        │ 100.00%   │ N/A     │ 2022-02-02 09:23:09 │ a while      │
├─────┼──────────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼─────────┼─────────────────────┼──────────────┤
│   2 │ Unknown bebc │ ?BC   │ !bdf0bebc │ -23.1990°  │ -45.8940°   │ N/A        │ N/A       │ 5.25 dB │ 2022-02-02 09:21:34 │ 1 minute ago │
╘═════╧══════════════╧═══════╧═══════════╧════════════╧═════════════╧════════════╧═══════════╧═════════╧═════════════════════╧══════════════╛

[feh123]

Hi I have a nodes list (sorry for the poor formatting):
meshtastic --nodes
Connected to radio
╒═════╤══════════════╤═══════╤═══════════╤════════════╤═════════════╤════════════╤═══════════╤═════════╤═════════════════════╤══════════════╕
│ N │ User │ AKA │ ID │ Latitude │ Longitude │ Altitude │ Battery │ SNR │ LastHeard │ Since │
╞═════╪══════════════╪═══════╪═══════════╪════════════╪═════════════╪════════════╪═══════════╪═════════╪═════════════════════╪══════════════╡
│ 1 │ Unknown 6ce6 │ ?E6 │ !8ca26ce6 │ 52.0808° │ 0.0142° │ 99 m │ 85.00% │ N/A │ 1999-11-30 15:41:07 │ 22 years ago │
├─────┼──────────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼─────────┼─────────────────────┼──────────────┤
│ 2 │ Unknown 4958 │ ?58 │ !abf84958 │ 52.0804° │ 0.0148° │ N/A │ 100.00% │ 5.00 dB │ 1999-11-30 15:41:02 │ 22 years ago │
├─────┼──────────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼─────────┼─────────────────────┼──────────────┤
│ 3 │ Unknown 1b2a │ ?2A │ !be811b2a │ 52.0808° │ 0.0142° │ N/A │ 78.00% │ 4.75 dB │ 1999-11-30 15:37:36 │ 22 years ago │
├─────┼──────────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼─────────┼─────────────────────┼──────────────┤
│ 4 │ Unknown 4ec0 │ ?C0 │ !abf84ec0 │ 52.0808° │ 0.0143° │ N/A │ N/A │ 7.00 dB │ 1999-11-30 15:34:32 │ 22 years ago │
├─────┼──────────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼─────────┼─────────────────────┼──────────────┤
│ 5 │ Unknown 38a8 │ ?A8 │ !58dc38a8 │ N/A │ N/A │ N/A │ N/A │ 5.00 dB │ 1999-11-30 15:34:13 │ 22 years ago │
├─────┼──────────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼─────────┼─────────────────────┼──────────────┤
│ 6 │ Unknown e568 │ ?68 │ !c4f7e568 │ 52.0808° │ 0.0142° │ N/A │ N/A │ 6.25 dB │ 1999-11-30 15:33:36 │ 22 years ago │
╘═════╧══════════════╧═══════╧═══════════╧════════════╧═════════════╧════════════╧═══════════╧═════════╧═════════════════════╧══════════════╛
All are running 1.2.52. The tbeams and the 19003/1910 (2A) and 19003/12500 (E6) are all fine. The 5005/1910 (A8) shows no gps fix although under info hasgps is true. I can test these devices quite easily with any FW versions so if anyone wants to try out some new code just let me know. My plan was to use the 5005/1910/E-ink setup but that's rather doomed now unless the gps fault can be fixed. Thanks!

[kingoffoxes]

My RAK just arrived and i am having the same issues on 1.2.55.9db7c62

GPS must be getting a fix as LED on the board is blinking.

Owner: Garry 9 (G9)
My info: { "myNodeNum": 3321538461, "hasGps": true, "numBands": 20, "firmwareVersion": "1.2.55.9db7c62", "bitrate": 24.592716, "messageTimeoutMsec": 300000, "minAppVersion": 20200, "maxChannels": 8, "channelUtilization": 24.666668, "airUtilTx": 4.0366387 }
Nodes in mesh: snip

Preferences: { "phoneTimeoutSecs": 900, "lsSecs": 300, "region": "ANZ", "positionFlags": 35 }

Channels:
PRIMARY psk=default { "modemConfig": "Bw31_25Cr48Sf512", "psk": "AQ==", "name": "My Channel", "id": 1234 }

Primary channel URL: https://www.meshtastic.org/d/#ChYYAiIBASoKTXkgQ2hhbm5lbFXSBAAA

C:\Windows\system32>meshtastic --port COM9 --nodes
Connected to radio
╒═════╤═════════╤═══════╤═══════════╤════════════╤═════════════╤════════════╤═══════════╤══════════╤═════════════════════╤════════════════╕
│ N │ User │ AKA │ ID │ Latitude │ Longitude │ Altitude │ Battery │ SNR │ LastHeard │ Since │
╞═════╪═════════╪═══════╪═══════════╪════════════╪═════════════╪════════════╪═══════════╪══════════╪═════════════════════╪════════════════╡
│ 1 │ Garry 9 │ G9 │ !c5faa79d │ N/A │ N/A │ N/A │ 100.00% │ N/A │ 2022-02-21 21:23:30 │ 52 seconds ago │
├─────┼─────────┼───────┼───────────┼────────────┼─────────────┼────────────┼───────────┼──────────┼─────────────────────┼────────────────┤

[joshbowyer]

I am having the same issue on my RAK5005-O with RAK1910

[joshbowyer]

@andrekir @a-f-G-U-C Ive inspected the log dump from @tropho23 and have found that the RAK device in question, ID a394ed7d, never appears in the following blocks:

16:45:26 1957 [GPS] lookForLocation() new pos@61f17aa7:1
16:45:27 1957 [GPS] WANT GPS=0
16:45:27 1957 [GPS] publishing pos@61f17aa7:2, hasVal=1, GPSlock=1
16:45:27 1957 [GPS] New GPS pos@61f17aa7:3 lat=39.368909, lon=-76.974726, alt=176, pdop=5.13, track=0.00, sats=4
16:45:27 1957 [GPS] onGPSChanged() pos@61f17aa7:4, time=1643215527, lat=393689089, bat=90
16:45:27 1957 [GPS] updatePosition LOCAL pos@61f17aa7:5, time=1643215527, latI=393689089, lonI=-769747261
16:45:27 1957 [GPS] Node status update: 1 online, 3 total

It looks like the RAK device never runs the GPS code, as every single [GPS] block in the log dump is only for other node ID's

[joshbowyer]

Not too sure about REMOTE and LOCAL (I saw them defined in the code somewhere but forgot) but here is gps information in the same log for the RAK device (a394ed7d), again not sure if REMOTE is it obtaining gps info for another node or for itself:

16:37:38 1488 toRadioWriteCb data 0x20013ca0, len 43
16:37:38 1488 PACKET FROM PHONE (id=0x355d3f83 Fr0x7d To0xff, WantAck0, HopLim0 Ch0x0 Portnum=3 priority=10)
16:37:38 1488 Warning: phone tried to pick a nodenum, we don't allow that.
16:37:38 1488 handleReceived(USER) (id=0x355d3f83 Fr0x00 To0xff, WantAck0, HopLim0 Ch0x0 Portnum=3 rxtime=1643215058 priority=10)
16:37:38 1488 Plugin 'position' wantsPacket=1
16:37:38 1488 Received position from=0x0, id=0x355d3f83, portnum=3, payloadlen=18
16:37:38 1488 Incoming update from MYSELF
16:37:38 1488 POSITION node=a394ed7d l=18 LAT LON MSL TIME
16:37:38 1488 updatePosition REMOTE node=0xa394ed7d time=1643215059, latI=393688365, lonI=-769746631
16:37:38 1488 Node status update: 0 online, 3 total
16:37:38 1488 Plugin 'position' considered
16:37:38 1488 Plugin 'routing' wantsPacket=1
16:37:38 1488 Received routing from=0x0, id=0x355d3f83, portnum=3, payloadlen=18
16:37:38 1488 Routing sniffing (id=0x355d3f83 Fr0x00 To0xff, WantAck0, HopLim0 Ch0x0 Portnum=3 rxtime=1643215058 priority=10)
16:37:38 1488 FIXME not implemented addRoute
16:37:38 1488 FIXME-update-db Sniffing packet
16:37:38 1488 Plugin 'routing' considered
16:37:38 1488 Add packet record (id=0x355d3f83 Fr0x00 To0xff, WantAck0, HopLim0 Ch0x0 Portnum=3 rxtime=1643215058 priority=10)
16:37:38 1488 Expanding short PSK #1
16:37:38 1488 Installing AES128 key!
16:37:38 1488 enqueuing for send (id=0x355d3f83 Fr0x7d To0xff, WantAck0, HopLim0 Ch0xb1 encrypted rxtime=1643215058 priority=10)
16:37:38 1488 txGood=4,rxGood=0,rxBad=0

[joshbowyer]

How can I generate the type of log that @tropho23 did? I can do it for my RAK5005 and see what it says as well

[prokrypt]

How can I generate the type of log that @tropho23 did? I can do it for my RAK5005 and see what it says as well

meshtastic --no-time --noproto
or...
unbuffer meshtastic --no-time --noproto|egrep -i "gps|ubx" --line-buffered

[caveman99]

There's been quite a reshuffle on the GPS code for 1.3, which makes GPS on all supported RAK devices work.

[joshbowyer]

There's been quite a reshuffle on the GPS code for 1.3, which makes GPS on all supported RAK devices work.

How can I install this firmware? It isnt shown in the flasher, and I dont see a branch or release on the git repo...

[garthvh]

you have to install the flasher with --pre