EMLID Caster Accuracy error a few minutes later?

Hi,

We are using Fieldgenius android to stake Golf Greens and we have localized to the existing survey maker. The site is challenging enough to mitigate the use of LoRa antennas for corrections, therefore EMLID caster seems to be the way to avoid moving the base because it keeps losing the link.

The crew is telling me that while staking a surface of a green and placing the physical ground with the digital surface (desirable elevation), 20-30 minutes later is saying they are 0.2ft off.

We didn’t have an issue using the LoRa antennas (other than the distance issue) and now the problem flipped using the Caster. Is there anything that can cause these elevation differences in this short time span?

Thanks!

What is your baseline length and have you confirmed if the internet connection (at either the base or rover) is spotty? If I had to guess, the accuracy slipping could be due to the rover going in and out of data coverage. See what the real time age is on the status screen after the 25 or 30 minutes. I would guess that it’s in the tens of seconds or upwards of a minute when you are seeing 2 tenths.

1 Like

The baseline is around 1000 ft. That is going to change in a golf course. Both are using independent mobile hotspots (jetpacks). I am not aware of their speeds but it’s in an urban area in Florida. So, the network issue is further down of possibilities. I might reset the settings and do redo the caster. I would let you know.

Any advice is welcome!

As a follow-up, we only reset the settings on the rover, and now seems to be working properly. Stake-out is consistent after going back a few minutes later and the day after. Is there any evidence to suggest that jetpacks/mobile hot spots, have a data throttle using the caster? How fast does the internet source need to be for the emlid caster to work properly?

Thanks!

Hi @avelez,

Sorry for the delayed comments!

Great news that it works well now. But, like Zach @Zaz5400, I’d also suggest paying attention to the Age of differential (AoD) in your measurements. Normally, it should be about 2 seconds. If the issue shows up again, AoD may give us a clue on what’s going on.

Can’t say the exact value of the Internet speed needed to pass the corrections. But in general, RTCM3 messages are lightweight, so they don’t need much. The main thing here is that the connection itself should be stable.

You know, a while ago, my colleague, Andrew, did some tests to check the weight of the RTCM3 messages:

These calculations are for messages needed for single-band receivers. MSM ones, most likely, are heavier. But I believe it may give a rough idea. So using these values you can calculate the approximate speed.