RTK fix availability?

[BenLewis]

Hi Egor (@egor.fedorov),

I’m still hoping to hear from you regarding my questions above.

Regards, Ben

[Simon_Allen]

Hi Ben
I can answer the delay question.
No a big AOD does not mean your position solution has a lag, but it does mean the measurements provided for the RT part of the K have are getting on a bit. With the stored obs from GA their daily records have a 30 second update rate, so RTK can cope with latency in the corrections. The calculated position however is as up to date as it can be. (less than 0.2 sec if you have 5Hz output set. With conventional L1/L2 receivers I know I used to be able to cope with 15 sec delays in the correction input. Not sure what the ideal limit is with reach.

[egor.fedorov]

Sorry for the delay,

@BenLewis

I have observed that a 2 Hz data rate has a much lower and more consistent AOD (this seems to translate into a more reliable fix, but I may be mistaken here)

With 2 Hz AOD will obviously be less, because it is the difference between the rover’s last observation time and base’s last observation time. So, if you have 1 Hz coming in from the base and a stable link, the AOD will grow up to 1 second, then reset, then grow back to 1 second. If you have 2 Hz, AOD will grow up to 0.5 seconds.

Having 0.5 instead of 1 second will not change much in terms of RTK performance, but will definitely affect the quality of the link. In LoRa’s case that might be important.

@BenLewis

Does the AOD create lag on the output data? For example, if I have an AOD of 4 sec does this mean that my current position output (NMEA) is 4 seconds old?

Of course not. Rover always outputs solution in its own update rate. That only means that rover is working with outdated corrections and the solution will be slightly degraded. While rover is able to extrapolate data, big breaks in correction link might cause you to go back to float.

@BenLewis

With regards to RTCM3 message data rates. I have been working on the assumption that the data rate of all GNSS messages (1010, 1097, 1107, 1117, 1127) need to match the data rate of GPS messages (1002). All other messages (1006, 1008, 1019, 1020) can be set independently (typically slower). Is this assumption correct? If not can you please list which messages need to have matching data rates (e.g. GPS and GLONASS) and which can be set independently?

You needed to do this before, but that’s not an issue starting with v2.9.0. You can now set systems independently. In the release notes I mentioned using 1 Hz GPS and 0.5 Hz GLONASS and Galileo.

@BenLewis

I have noticed that the bandwidth requirement of Biedou messages is significantly higher that of other messages. Is there something special about Beidou messages that warrants this extra bandwidth?

I am not sure about those, actually. Will try to do some logs during our next outdoor testing.

[Johannes_Eberenz]

I’m also working to getting more stable fixes with LoRa.
Using recommend settings (18.23kb/s 1002 1Hz, 1006 0.1Hz, 1010 1Hz) often the AOD goes up to 2, 3, 4 sec. … often when this happens the AR stops increasing or drops…
It keeps happening even if I don’t send GLONASS messages.
Best results i get with GPS 1Hz, GLONASS & GALILEO at 0.5Hz.

The AOD increase happen even at very short baselines (few meters) with line of sight.
Under same conditions,sam messages, using TCP or NTRIP I get fixes faster and more stable, AOD stays around 1.1 s usually for NTRIP.

Some Noob questions:

1. I assume it’s best to keep the Antennas pointing vertical and not blocke dby metal in any direction?
2. Does it matter two which power output I set the Rover?
3. Does the Freq. matter? (Regulation wise, i have free choice here)

[timd1971]

Wonder if you added a 1’ or 2’ extension to your tripods?

Maybe look at a rover pole also with a bipod attachment and a topo foot (dirt, terrain etc) for the rover pole so you can use a fixed antenna height on your rover instead of moving a tripod around all the time. Get a data collector mount that works with your phone or tablet also.

So much reading really helps when we get responses from the Emlid people… but really wish all the mysterious info only the Emlid team (and a few others) knew was in 1 easy spot… just seems so much TRIAL & ERROR just to get good fix to start working.

I wouldn’t imagine all these guys using Trimble, Topcon, Leica, etc equipment go through so much of this… they just wouldn’t get their work done? Yes, I know u get what u pay for. I guess my point is, takes quite a bit of time and trial to get up and working optimally. : /

[Simon_Allen]

All those guys with trimble, topcon etc either have the training and experience before coughing up 10-20K or get set up by the rep.