Hello. Is anyone having trouble shifting the stakeout points? the marked point with the RTK method, after disconnecting from the base and reconnecting, moves the point within 8-10cm.
Sorry for the silence in this thread!
RTK result may slightly vary if you collect the point at different time intervals. Satellites move during the day, so the coordinates change as well.
This can also happen when you work on longer baselines. The instrumental horizontal accuracy for Reach receivers is 7 mm + 1 ppm, so each kilometer of the baseline adds 1 mm to the total error.
Please let me know if your observation conditions involve any of these factors. If not, please share your CSV file and raw data logs for further analysis. You can send them to support@emlid.com.
1 Like
Hello. I also raised the topic in this thread Check known controlpoint with ntrip?. The distance to the ntrip mount point was 4-5km an error of 8-10cm shouldn’t happen but I read on the site of the ntrip service provider ASG-Eupos that GNSS measurements may be difficult due to the peak of the 25th cycle of the sun and the ionosphere influence. it is possible that this was the cause of the shifting of the “running” of the instrument. we will collect more data on this and we will definitely share the conclusions. Regards, Damian
What does “ppm” mean exactly? Couldn’t find it anywhere. 1mm/1000 ? If so why not just say 1 mm per kilometer on the data sheet for simplicity.
Hi Damian,
Oh, I see the photo on that topic. Indeed, 8-10 cm seems like a pretty big error on such a baseline, but let’s check if this is a repeatable behavior.
Please collect more data, preferably on known benchmarks, and let us know the results!
Hi Dave,
PPM stands for points per million, also known as permille or per mile. I’m aware that some specs show it as mm/km, so some manufacturers do that. But PPM is a more metrology-standard format.
hello kirill. yes the error was quite big. the instrument during stakeout was on fix all the time but staked out with this error. disconnecting from the mount point did not correct the stakeout error. tell me why emlid calculated the fix correctly? when we realized that the stakeout was wrong we changed the instrument to chc, the chc instrument was connected to the same mounting point ntrip errors 12-15mm repeatable measurement. I don’t understand why this happened emlid worked in rtcm3.2 stream and chc rtcm3.1
Were you using all GNSS constellations during this test (and does your NTRIP provide corrections for all constellations)? It would be an interesting test in the field if this is happening to try removing a constellation or try GPS only to see if it still has the same error.
What is your elevation mask and SNR set at during the tests?
Hello. yes, the station supports all corrections depending on the stream rtcm3.1 GPS Glonas, rtcm3.2 everything possible, link to the station ASG-EUPOS, Opis systemu, Stacje referencyjne - GWWL . elevation mask settings 15, noise SNR 35.
Hi Damian,
Could you please send your CSV file and raw data logs to support@emlid.com? I’d like to look closer at them to check out what could go wrong.
Didn’t you record the same point when you noticed the stakeout offset? So I can compare both coordinates in the CSV file.
Besides that, have you checked that the base station didn’t change when you performed a repeat measurement?
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.