Issues getting a fix with a drone using rtk torch in base caster mode with wifi AP

GPS/GNSS
1

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.
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?
2

Let’s start from the concept that the RTK position is nothing more than one of the possible solutions derived from statistical & probability calculations, offered in particular by the Kalmann filter…
When you have latency or reception problems, it’s best to limit the computation to the bare minimum.
Once upon a time, GPS L1 and Glonass G1 signals were sufficient, but now, with the computing power and greater bandwidth available, it’s preferable to compute the entire known constellation.
In short, it’s enough (if RTCM3):
1074
1084
1094
1124
1005 or 1006 every 10 seconds (10)
1230 (10)
which consumes about 7000 bps .
Wi-Fi 2.4 doesn’t have latency problems, but range, about 30 meters.
Lora, on the other hand, offers a greater range of about 400 meters, but has very limited bandwidth latency due to the time cycle. Even in FHSS mode, it’s best to lower the “air rate” to the minimum (16Kbps) to achieve optimal balance.
To better diagnose the situation, it’s best to connect the receiver module to a TTL-USB converter and connect it to a terminal to see what actually happens to the flow sent by the transmitter.If the RTCMs are received intact and without interference/latency, you can try the even RTCM’s of the 1xx7 group…