I searched for “PPL is offline” but didn’t find anything.
I continue to struggle to get an RTK Torch configuration that will work on my woods, where not only are the woods deep, the Cell Signal isn’t always the greatest….
Spent 3 hours Saturday at the top of the ridge, so less mountain in the way of satellite signal. And I could get e-mail on my phone so I believe data signal was working.
My configuration is SparkFun RTK Torch, connected to Android Tablet via Bluetooth for SW MAPS. RTK Torch connected over Wifi to iPhone HotSpot to get PointPerfect corrections. It was getting corrections from what I was seeing via serial port.
I could not get RTK Fix no matter what configuration tweak I tried.
And watching serial port for messages noticed this below:
Warning: PPL is offline.
The PUSHING statements would have varying byte sizes around xxx= 607, 177, 304, 152
Pushing xxx bytes from pp/ip/LAxxxxxxxxxx/N35 topic to PPL for UM980
Warning:PPL is offline
And I have occasionally seen an error
UM980 Rover failed to configure Rover config failed
but didn’t think I saw it this Saturday….. What does PPL is offline mean and did I just need to reboot to fix (which I failed to try ;( – stupid of me for sure….
ChatGPT says… this may actually be a known problem in firmware 2.2 ??
But Sarah Connor said not to trust it……
is there a Serial port command to restart PPL in the field or just need to get lucky and reboot until there isn’t an error?
And I didn’t read in Release Candidate 2.3RC that it was going to do anything about PPL Offline error?
Replaced firmware to 11833 and the errors for PPL Offline and UM980 Rover failed to Configure went way… but Version of UM980 does not show version on boot up, so not sure what version is really running
Testing Oct 9th 5pm. Better… but in mostly wide open in my opinion it lost RTK Fix after only about 100 points averaged. Then in about 5 min got it back for 60avg, lost it briefly then averaged continued to get to 120 before writing it.
And I did it 3 times and via SW Maps it said the 3 readings were 0.9ft apart?(Per SWMaps, however when I exported and had ChatGPT calculate distances apart point 1 was 5 inches from 2&3 and 2&3 were only 0.75 inches apart) even when the points were recorded with RTK FIX avg of 80-12 readings each?
Does this look like too much surrounding trees to maintain RTK Fix??
, or do I still have some software configuration issues? No PPL error on push to UM980. And it seemed to be downloading bytes from PointPerfect and pushing them over to UM980 without error.
clarifying the first reading where RTK Fix failed after 60 average points was 5 inches away from points 2 and 3. Points 2 and 3 recorded as only 0.75 inches apart… darn good, but not good that within 15 minutes they should all be 0.75 right? I’m I just expecting too much from PointPerfect corrections and bad cell service? And trees and not a wide open 100 acres field in Iowa?
Hi Chris - you’re reports and testing are superb. I don’t want to muddy the waters too much, but your correction source (PointPerfect MQTT over IP) is good but not what we’re recommending anymore. 1) u-blox is EOL’ing it fall of 2026, and 2) We’ve found it performs worse than their Flex RTCM/NTRIP service. I have a strong belief they use different models behind the curtain (MQTT being the original, NTRIP being newer/better). Would you consider giving the NTRIP/RTCM a test and letting us know your results? I’m happy to give you NTRIP credentials that will last for 30-days.
Sorry - I didn’t address your other issues: v11833 is what ships on most Torches, v13504 has HAS support, and v17548 is the newest/latest that our ESP32 firmware is not wholly tested with. I recommend v13504. Additionally, we release ‘release candidates’ of the ESP32 firmware that may be helpful if you want to try the latest features and compatibilities with v17548 UM980 firmware. Just know the RCs are in a great state of flux (so don’t use it in the field if you need to get work done!) but should be functional.
Sparky, would be more than happy to test RTCM/NTRIP, but let’s do it in December when the leaves are down in East Tennessee, I will have more time to test, and the test is more likely to succeed. (I used the Book Mark function to set a reminder for me December 1 to reach out to you)
My “Work” isn’t too serious, so I can try some things occasionally, but then some deadline comes up and I need drop everything else to take care of the “new” priority. I will first tryout v13504 and see how it changes any of my results testing either on my 155ft test stretch or out in the valleys and ridge tops of our forest. The big push this December is a 3,517.33ft stretch along the ridge top, with 34 directional calls. I’m hoping that being on the ridge top increases my odds of success.
GNSS UM980 online
Profile ‘PPerfectTiltOFF’ loaded
Fuel gauge configuration complete
Charger configuration complete
UM980 configuration maintained
No GNSS date/time available for system RTC.
Bluetooth SPP and BLE broadcasting as: Torch Rover-7CC2
Initial test outdoors achieved RTK Fix quickly, and I will do additional testing this afternoon to see if UM980 v13504 holds RTK Fix better (assuming upgrade worked as version is not reported)
October 10th - hour and half of testing outside…. Failure
upgraded to v13504 on UM390. Boot up did not show version of UM390 but doing the upgrade did not show any errors so assuming it worked. Unfortunately this upgrade did not help get RTK FIX. And in testing in the exact same locations, and also in one area with clearer view of the sky I still failed to get RTK Fix. And after trying various satellite elevation settings, signal/noise settings the WARNING: PPL Offline came back but after a reboot went away. I am going to try to go to a more wide open field, and if that fails on RTK Fix there must be something else wrong with what I am doing.
