RTK Everywhere RC v2.2 Not Provisioning Pointperfect token

GPS/GNSS Enclosed Products
1

I’ve had a history of unstable / unusable pointperfect corrections with my device, so I shelved it. Today I thought I’d check up and see if there had been any improvements in stability. I fired it up using firmware v2.1 Feb 20. RTK Fix came up rather quickly. I dropped into the config to check an instrument height setting, reset, and never could get RTK back. Back and forth between RTK Float and DGPS… which is what I’ve run into forever.

I installed firmware RC v2.2 May-21. Reset settings to factory default. Re-input my wifi settings and pole length. So far so good. Turned on point perfect corrections and set to “flex NTRIP/RTCM”. Went outside and tried to get RTK Fix - no dice. Turned off E6 / Gallileo precise positioning, rinse and repeat. No dice.

Dropped into the serial config. Went into the PP corrections submenu. Enabled “Update Credentials” and exited out. No dice. Enabled debugging and went through the credential update request again. The following is being reported:

Provisioning state: PROVISIONING_WAIT_FOR_NETWORK
GNSS RX: rtkParse Unicore Binary, 0x0094 (148) bytes
WiFi: Station online (XXX: X.X.X.X)
Rover Accuracy (m): 3.519, SIV: 17 GNSS State: 3D Fix
Batt (100%): Voltage: 8.28V Discharging: 0.00%/hr
Default Network Interface: None --> WiFi Station
HTTP Client start
Using token: 0000
{
  token: 0000
  givenName: Torch d2.2 - AC1518927C[REDACTED]
  hardwareId: AC1518927C[REDACTED]
}
Sending JSON, 135 bytes
[215325][E][NetworkClient.cpp:319] setSocketOption(): fail on 0, errno: 9, "Bad file number"
HTTP response: {"errors":["token invalid token format"]}
HTTP response error 422: {"errors":["token invalid token format"]}
HTTP response error 422: {"errors":["token invalid token format"]}
SIV: 17, HPA (m): 3.579, Lat: 25.9, Lon: -97.4, Altitude (m): 19.999
Rover Accuracy (m): 3.579, SIV: 17 GNSS State: 3D Fix
updateProvisioning: ZTP_UNKNOWN_ERROR
NTRIP Client state: NTRIP_CLIENT_OFF, Not enabled!
HTTP Client stopped
Correction Source: None
Provisioning state: PROVISIONING_OFF

Thought maybe I’d been left behind on a UM980 firmware update, so I updated to UM980_R4.10Build17548.pkg. On reboot, I received a UM980 error stating

UM980 Rover failed to configure

Rolled back to firmware build 11833 and the UM980 is communicating again. Still no PP RTCM with the same token error.

Gonna roll forward to build 13504 and then retry 17548. Any other ideas here?

2

tagging @PaulZC. If someone could point out NSeidle as well, I don’t know his handle.

3

Tried UM980 fw build 13504. Seems to work fine in the terminal, but in webconfig I’m seeing the following in the status bar:

“UM980 Firmware: Error ID: ff3b0c971e9aba3b”

4

Same error in the webconfig with build 17548.

Via terminal:

Identified variant: Torch
LittleFS Started
Using profile #0
PSRAM Size (bytes): 2097152
I2C Devices:
  0x08 - HUSB238 Power Delivery Sink Controller
  0x0B - BQ40Z50 Battery Pack Manager / Fuel gauge
  0x5C - MP27692A Power Management / Charger
  0x60 - ATECC608A Cryptographic Coprocessor
=======================
SparkFun RTK Torch d2.2
=======================
GNSS UM980 online
Profile 'Profile1' loaded
Fuel gauge configuration complete
Charger configuration complete
UM980 configuration maintained
No GNSS date/time available for system RTC.
UM980 Rover failed to configure
Rover config failed
Batt (100%): Voltage: 8.28V Discharging: 0.00%/hr
Rover Accuracy (m): 0.000, SIV: 0 GNSS State: No Fix
5

Hi Jeff (@OWB ),

You’re heading off into the Wild West - a little…

It looks like you have two issues: one linked to your Torch’s PointPerfect plan; and a second one caused by the UM980 firmware.

For the first issue:

Your Torch is registered on the “PP Flex 100H” plan with corrections in SPARTN format over MQTT.

The new “Flex NTRIP/RTCM” option uses RTCM format corrections over NTRIP (TCP).

Looking at the ThingStream logs, it looks like your Torch is connecting and subscribing successfully to the old MQTT topic. But, I guess, the RTK Everywhere Firmware is expecting different credentials for the new NTRIP service.

I think this will need intervention from @sparky. We will, I think, need to delete you from the old whitelist and add you to the new one for NTRIP if you want to migrate.

For the UM980 firmware, the “Error” in “UM980 Firmware: Error” means the RTK Everywhere firmware doesn’t recognise or can’t extract the gnssFirmwareVersion. That’s a surprise. I believe we tested 17548 successfully. All I can suggest there is that you reset the RTK Everywhere Firmware to the Factory Defaults and give it another try.

Best wishes,
Paul

6

Hi @OWB - (I’m nseidle on github) I’ve got your firmware ID error issue started here. I’ll start testing with 17548.

Paul is correct about PointPerfect changes. I thought the firmware failed more gracefully for folks who are already registered. I’ll do some testing.

7

HTTP response error 422: {“errors”:[“token invalid token format”]}

Ok, I found/fixed this issue. The token was getting modified due to a previous commit (my fault!).

I can’t yet replicate your problems with UM980 firmware version 17548, it’s behaving for me. After the firmware update, I did a factory reset. Everything is working really well.

in webconfig I’m seeing the following in the status bar: “UM980 Firmware: Error ID: ff3b0c971e9aba3b”

This is a known issue on the UM980 (to my future self, see comment in codebase “Shortly after reset, the UM980 responds to the VERSIONB command with OK but doesn’t report version information”), that only happens on release candidates that have some delays turned off. I’ll put in a fix for that.

8

Personally, I think migrating would be preferable. The MQTT delivery just hasn’t ever worked out well (reliably) for me. I suspect that may be why y’all are working on a NTRIP solution.

On the firmware, I’ll try resetting to factory defaults. I did that originally, but I guess it may not have taken. I will add that I don’t believe I have ever updated the STM32, but I don’t think that would be part of this issue.

9

Do I need to download a new firmware RC, or do I just fire it up and try again?

On the factory reset, that’s system submenu S, option R? I think I my reset through the webconfig and I’m wondering if that’s just a soft reset instead of a factory “hard” reset.

10

You are fast!

Do I need to download a new firmware RC?

Please load the new firmware found on the binaries repo.

The MQTT delivery just hasn’t ever worked out well (reliably) for me. I suspect that may be why y’all are working on a NTRIP solution.

Yup.

I’ve put in the request to get you off MQTT. Please give ThingStream ~24 hours to remove your account. After that, if you try to use MQTT, you should see a warning that you’re not whitelisted. Similarly, I’ve whitelisted you onto RTCM service. Choose that, and give RTCM over NTRIP a try. We would love to hear your feedback.

11

You caught me while I was sitting in front of my computer looking at it.

I’ll load the rest this evening and see what happens. Does the firmware handle the NTRIP client settings behind the scenes, or does it load it all into the GNSS receiver submenu settings after you select and save “Flex RTCM/NTRIP” on the pointperfect submenu?

12

If a user requests PointPerfect Flex NTRIP/RTCM credential update, and new NTRIP credentials are available from PointPerfect, they are loaded (overwrite) into the NTRIP Client in the unit, and the client is automatically enabled.

13

RC Jul-14 loaded. Had to use the GUI loader, as the OTA wifi loader would not finish uploading and I was receiving a timeout error:
[212526][E][NetworkClient.cpp:429] write(): fail on fd 53, errno: 104, "Connection reset by peer"

Anyways, I got it uploaded via GUI, did a hard reset using the serial menu (s->r->y). After I did that, I decided to re-flash the UM980 firmware to the latest 17548 and then hard reset again. Its now all up-to-date. Living on the bleeding edge over here…

From this, the only thing I can figure is that using the wifi webconfig page to reset to enable factory defaults is not the same thing as the reset procedure using the serial menus. That’s the only difference in what I did, but maybe I screwed it up.

Off to test pointperfect…

14

PM sent with detail. Looks like I’ve provisioned my access credentials but now there’s a caster client timeout issue that’s preventing the client from staying connected long enough to get RTCM data.

SWMaps reports a “single” fix. Not sure why it can’t at least get to DGPS.