Bandwidth issues: Using RTK torch NTRIP WiFi Access Point for drone while using LoRa to correct a Torch Rover

GPS/GNSS
1

For a long time I have been trying to get the RTK Torch to send RTCM messages with our drone (Autel evo2 pro v3 RTK) while also sending corrections via LoRa to another RTK Torch acting as a Rover.

I have finally gotten it to work.

It turns out that the main issue (at least since version 3.2 of RTK everywhere) is that of bandwidth on the ESP32 has available when the LoRa radio is running.

RTK Everywhere v3.3, UM980 firmware v 17548, STM32 Firmware v2.0.2

Here is what I have observed:

When the Base is in base caster mode, and has all of its default settings, but LoRa is off, the Torch is able to send corrections to the drone without issue. The Fix indicated by the drone is very stable and indicated accuracy is consistently within 2-4 cm.

When the Base is in base caster mode, and has all of its default settings, but LoRa is on, the RTK Torch acting as a rover maintains a steady fix, however, the drone stays on float, it never reaches a fix and the indicated accuracy ranges from 150 to 300 cm.

Now here is the configuration that finally worked. When the Base is in base caster mode:

- LoRa is enabled,

-the QZSS and BeiDou constellations are disabled,

-bluetooth is disabled,

-the RTCM messages button that says “reset to low bandwidth link” has been selected in the “RTCM rates” menu in the “Base configuration” menu (which changes the RTCM message rate from 1 to 2),

-and in the “message rates” menu of the “GNSS configuration” menu I turn all of the message rates to zero, except the following which I set to 10: GPGGA, GPGSA, GPGST

Only with this configuration will bot the RTK Torch Rover and my drone get an RTK Fix. The Fix on the rover is fairly stable, the Fix on the drone takes about 3 minutes to be attained and stays within 2-6 cm indicated accuracy most of the time. The Drone occasionally goes to float, but after about 3-5 minutes has its fix again. I have only tested this so far in a relatively open and unobstructed environment, so i don’t know how stable it would be with a lot of trees.

Is there a way to configure the Torch so that the LoRa does not take up so much bandwidth on the ESP32 so that the NTRIP wifi access point can send all of the default corrections without turning anything off?

Or are there other ways we could save bandwidth without having to disable constellations and fiddle with the message rates?

It would be ideal if the Torch acting as a rover could get the full constellations and RTCM messages at a rate of once per second while the base’s wifi AP can send corrections to the drone.

2

Using the Torch in Base Cast mode, with LoRa active is not a setup we ever expected and is unfortunately outside our ability to support.

LoRa is limited as you’ve seen. You’ve reduce the data rate and constellations, that’s a great start!

3

Would I run into similar issues if I had the torch broadcasting RTCM messages over both LoRa and USB?

My intention would be to have some kind of intermediary device like another esp32 or a raspberry pi that would take the data from the USB output and broadcast an NTRIP access point for the drone.

Any thoughts?

4

You are very close to what you want.
I wouldn’t be upset about turning off QZSS and BeiDou. They wont contribute much to the RTK performance anyway.

This is concerning, and something that might could be sorted out. That should only take a few seconds. Since you mentioned the UAV’s RTK works fine when the Base’s LoRa is turned off, I would tend to agree with your theory.

I would first attempt to tweak the RTCM settings a little more, before throwing more tech at the problem.

The internet will tell you how incredibly important timely 1Hz delivery is for RTCM, but that’s just not the case with the newer receivers.

If you want to keep the LoRa radio ON for your Torch Rover, you could tweak/test the RTCM rates to :
1074 (GPS) = 1 sec, the most important
1084 (GLO) = 2 sec
1094 (GAL) = 3 sec
And station info (1005 & 1033) at 11 and 13 seconds.

Note: I actually use prime numbers for NMEA message rates for custom devices I build. Folks don’t always agree with the benefit of minimizing unnecessary data, but that’s from 1,000’s of hours of testing :nerd_face:

A similar strategy for the RTCM messages might be all it takes to have both Rover comms successful ?

Also, you don’t need the Base worried about producing any NMEA, do you?

If tweaking the RTCM doesn’t work for you, maybe a slight adjustment in your workflow will? I assume you’re using the Torch Rover to collect assets and Ground Control Points for the UAV’s aerial photography. If so, you might do that before/after the mission and have the LoRa off during the flights?

One more random thought: Why can’t the Torch Rover (or data collector) connect to Base NTRIP just like the UAV does (WiFi) at the same time…and leave the LoRa off? I haven’t thought about that for more than a few seconds.

5

Thanks so much for the reply, the reason we want this type of capability is because it gives us a fallback when we do not have internet out in the field.

We have used the Torch and drone with NTRIP of course. But we often find Ourselves in the boonies with limited internet. And if we were to use something like starlink on a company vehicle, our Torch acting as a survey rover would be limited to the Starlink wifi range.

Now, as for the idea of Turning the LoRa off for the drone flights:

Can we do that?

My understanding was, that if we turn the base off and then back on, It would do another “survey in”, and this means that the absolute positions of the drone photographs and the survey points could be a few feet off of where they should be relative to eachother.

Is there a way to turn the LoRa off and on on the RTK Torch so that the survey data and drone photograph positions are all in the same coordinate system and are accurately positioned relative to eachother?

6

Hmmm… does turning off the LoRa radio require the Base Session to restart, IDK ?

Also, there was feature request on GIT to allow a previously saved base position to be used instead of a survey-in… easily.

I don’t see it as an open issue, so I assume that was included in a FW update.