RTK Torch: RTCM1033 at 10Hz while all other messages at 1Hz

Other
1

Is there a technical reason that the 1033 message is set to 10 Hz by default for the RTK torch? Is there any harm in dropping that down to 1Hz like all of the other messages are set to? doesn’t it only pertain to some base station information (like what type of antenna)?

2

I believe it’s because the data is relatively static vs positional messages, so there’s little benefit to updating it more often…the downside of increasing its frequency to 1Hz would be bandwidth considerations

So…yes you can, but there isn’t anything to be gained from doing so (no increase in accuracy, time-to-fix, etc)

1 Like
3

@Patrick_Davis , You are correct: Sending The RTCM 1033 message 10 times a second is a mistake, if that’s the default. The station descriptors can be set to once every 30-60 seconds, typically.

1 Like
4

Wow, that does indeed appear to be the default on my Torch also.

image
image204×689 4.65 KB

[Edit]. That’s not Hz, it’s the # of seconds between messages. So the default is once per 10 seconds. Sorry :slight_smile:

Enter number of seconds between RTCM1033 messages (0 to disable) [min: 0.00 max: 65.00] (or x to exit): 30
1 Like
5

Thank you guys so much for your replies, that helped a ton.

My goal is to have a setup where a torch acts as a base, and it sends corrections to a drone via NTRIP and another torch that will be on a survey pole for measuring roads.
a follow up question but first let me describe my setup:

  1. I have one torch setup in Base Caster mode and LoRa enabled;
  2. I have another torch in rover mode and LoRa enabled;
  3. I have a drone (the Autel Evo2 Pro v3 with RTK antenna), I connect to the wifi of the Base Caster Torch, and am able to log in and connect to the Access Point of the torch

Now here is what happens:

  1. If I leave the GNSS options at their defaults (all constellations, default RTCM messages enabled at default rates) on the base, I get a float but not a fix, the stddev starts at around 300 cm, sort of gradually decreases to about 150 cm, then goes back to 300 cm. and of course the rover torch gets a fix no problem.
  2. If I turn off Beidou and QZSS and hit the “low bandwidth” button on the base in the RTCM messages menu to get the lower frequency transmission of messages, I am able to get a fix on both the drone and the torch acting as a rover.
  3. If I turn off Beidou and QZSS but leave the RTCM rates and messages at their defaults, The drone stays at float and the torch rover gets a fix. Now I did not leave the torches running for too long because I was in a hurry, so is it possible that if i left it for longer it could get fix? I need to see.

I am trying to figure out what specifically is keeping the drone from getting a fix. I have two possible ideas, let me know if you have others:

  1. The drone’s manual indicates it only uses Gallileo, GLONASS, GPS and Beidou, I am wondering if QZSS is messing with how the drone calculates an rtk position or something
  2. There is a bandwidth issue somewhere, and since the Rover Torch was able to get a fix with all of the default settings enabled on the base, then the issue would have to be on the drone’s side, and I need to figure out what that is. Does anyone have an idea on how to determine the bandwidth that is going between the Drone and torch? or what messages are making it through?
6

Great reply with a lot of useful info :slight_smile:

That means we know the Autel is working with MSM4 from the Torch and your WiFi connection, NTRIP credentials, mountpoint, etc are all working. That’s a great start.

As for your list of possible ideas :

The Autel’s receiver shouldn’t care either way, but you likely aren’t receiving or sending any QZSS signals anyway from the Torch Base.

The easy check would be to check the Age of Differential on your Controller.

I will say that when I first added RTK to a Quad, I tested on the ground and had similar results. I assumed that sorting out RTK would be easiest on the ground without the Electrical noise from the 4 motors. Turns out getting the Quad off the ground made a huge positive difference, despite the noise.

I will add to your list :

  1. Focus on the WiFi connection from the Torch to your Controller. I’ll assume that the Controller-to-UAV link is stable, since it’s Tri-Band. But the issue might be Torch-to-Controller getting bogged down with extra data?
  2. Make sure the ESP-NOW radio is turned OFF on Torch, especially the Base. I can’t swear the FW will allow both radios at the same time, but it appears it’s possible in the config.

Test with the Autel hovering 30’ or more, with the controller near the Base Torch, and as you’ve already expected- turn off any RTCM and NMEA Messages that are not beneficial to the System. I would even start with only GPS, Galileo, and GLONASS to confirm a reliable Torch-to-Controller link.

Here’s the RTCM that you can try for MSM4 for 3 constellations.

Menu: Message RTCMBase
5) Message RTCM1005: 1
15) Message RTCM1033: 10
23) Message RTCM1074: 1
30) Message RTCM1084: 1
37) Message RTCM1094: 1
52) Message RTCM1124: 0 (Change to 1 later if you want BeiDou, after your link is stable)
x) Exit

Good luck, and let us know if you see any improvements.

2 Likes