Rtk torch: does exiting the bluetooth serial config menu cause the torch to completely restart?

GPS/GNSS
1

I have two torches: one is a rover and one is a base.

They both have the latest firmware as of writing: v3.3, stm32 2.0.2, latest um980 firmware

I have LoRa enabled for both of them.

After 1.5 or so hrs of running, the LoRa on the base just stopped broadcasting.

I went into the bluetooth serial config menu for the base torch. It indicated the LoRa was enabled, so i just toggled it off and back on in the menu, and then I hit x twice to blackout of the serial config, and I ensured the base was broadcasting over bluetooth again.

Does exiting out of the serial config menu cause the torch base to restart and do another survey in?

Or would it be broadcasting the same data from when it was first turned on? would the rtcm messages be broadcasting based on the surveyed in position that was determined when the base first turned on?

This would be really helpful to know, because I have been trying to get our drone to communicate with the torch for a while now, and if we are able enable or disable features while the base is still broadcasting the same rtcm data, then we could turn off the LoRa, turn on the wifi NTRIP access point and switch between doing survey rod work and Drone survey work, and it would be all in the same coordinate system, the drone and survey data would have accurate relative positions.

Please help with clear answers, I have asked questions like this in the past and gotten indirect answers from the sparkfun team.

2

@Patrick_Davis, since RTK Everywhere FW has so many available options…I think the answer depends on your workflow.

If the Base Mode is set to Survey-In, then yes - anytime the BASE is restarted it would cause a new position to be captured.

However (my understanding is) if you use Base Assist Mode, the position is captured and the Base is started with Fixed Coordinates which would be remembered on subsequent restarts (if the Base Mode is set to Fixed Coordinates on the restart).

I wanted to try this for myself and to confirm for you, but I only have 1 torch.

I started a Base Session with Survey-In, assuming that’s what you are doing.
The Base Menu has Commonly Used Base Coordinates now, which tells you the ECEF for the current Base Position after the default 60 seconds of initial observation. Use menu “l” (lower-case L) to load the ECEF From GNSS.
IE: [3 -Base], [7-Commonly Used Base Coordinates], [l-Load ECEF from GNSS]

After taking a pic of the ECEF, I turned LoRa OFF on the Base Torch and didn’t notice anything over bluetooth serial that would make me think the Base restarted.
I checked the ECEF again, and the ECEF of the Base had not changed.

So cycling the LoRa radio did not cause a new Base Session to begin for my Torch, in this particular scenario.

I think a safer workflow might be to Start your base with Base Assist, and have the Base Mode always set to Fixed/Static with ECEF.

image
image343Ă—102 1.04 KB

image

That method allows you to save that day’s Base Coordinates in the Commonly Used List (with a name) and you know the Base will reuse that position if the Torch crashes, restarts, etc. That workflow (Base Assist) also works well if you want to use NTRIP/PointPerfect to establish the Local Base position…the same workflow for different in-field scenarios.

I’m sorry if this can be frustrating, but there is a learning curve to Base/Rover + UAV’s, etc. There are dozens of variables for any application.
Please continue to share your experiences so we can all learn from it :slight_smile:
I learn something almost everyday on this forum.

3

Hello, Thank you so much for the reply (and the patience).

I have attached the results of a test that I ran.

All torches had the latest firmware as of writing.

In the test, I had the torch in base mode and I was enabling/disabling the LoRa and Wifi AP on the torch via the serial bluetooth menu.

I started up the base and rover at the same time. It took about 2-3 min for the rover to get a steady fix (you will see this in the first couple of points labeled “moved again” and such, it stabilized at point 4 it seems).

Based on the results, it appears that the um980 does not restart when you switch the lora off and on or the wifi ap off and on. Over the course of 3.5 hours, the points that had a good fix were well within 3 inches most of the time.

I forgot to include it in the remarks, but somewhere through points 59 to 87 I switched from lora, to ntrip wifi ap, and back to lora again.

I also placed the drone next to the rover torch, getting the antennas as close to each other as I could without moving the rover. I connected the drone to the wifi ap, let it git a fix, and took some photos to get data points. The data from the drone was within centimeters of that measured by the rover.

In other words, it looks like it all lines up.

If someone could speak give me thoughts on the following though:

When I first turned the Torch base on (so LoRa is only enabled initially), the torch was broadcasting the RTCM messages as well as the NMEA messages over bluetooth.

After I turned LoRa off and the NTRIP wifi AP on, it stopped broadcasting the NMEA messages, it only broadcast the rtcm. I checked the messages menu, and they were still enabled but they were not broadcasting. If i switched NTRIP wifi ap off and LoRa back on, the torch was still not broadcasting the nmea messages. Anyone have thoughts on that?

lora tst 3_t1_.txt (20.9 KB)