Installed a fixed base for transmission of corrections via Ntrip.
I’m waiting to process via final PPP and get the final coordinates of your position.
In the meantime, out of curiosity, I put the base to receive corrections from the SCCH0 base in Chapecó/SC, 46.3km from here.
The connection is continuous, for more than 24 hours and monitoring, I noticed that the position of my receiver varies up to 14cm.
I recorded some points and monitor by doing a Stake Out.
I’m using an M2 on my base and per Emlid’s specs I would have an accuracy of 7mm + 1ppm, which would give me 53.3mm of horizontal accuracy (kinematic).
Based on this I ask:
Is it normal for this variation in the position of my receiver receiving corrections from this IBGE base?
What are the optimal settings in RTK SETTINGS and BASE MODE for Ntrip corrections?
IBGE has the option of corrections 3.0 and 3.2, which is the ideal?
14 cm variations over 24 hours with that baseline isn’t uncommon. What is the stddev over the 24h duration?
In my opinion, anything above 20 km baseline will vary a bit too much (you will get above 3-4 cm height difference). Over days durations, the average will still be good, but for short observations, baselines should be kept under 20 km, or you should post-process the results instead.
Is the stddev you refer to the one presented in the Position field in ReachView?
Or stddev based on the points I collected?
This second I still haven’t calculated.
But the stddev informed in the Position field, below the coordinates is in the place of 0.01m +/-.
That’s interesting! Can you share the LLH log from your test? It shows how the coordinates, solution statuses, and RMS changed over time, which will help to evaluate the solution.
You need to fill in the Base mode tab only if you set the receiver as a base. If you use it as a rover, these settings are not applied. For the RTK Settings, I’d recommend using the ones from our Base and rover setup guide.
Reach M2 can handle any RTCM3 corrections, but I’d suggest going for 3.2 as they provide more GNSS. It can help to calculate the coordinates more effectively.
All points collected with fixed solution receiving constant Ntrip correction (no drop) from SCCH0 base.
I collected points for 10 seconds.
I took morning and night collections. Two a day.
Firmware version I can analyze at night.
But, it’s been 20 days since I turned on the M2 and updated it on the first use, so I believe it’s in the latest version.
Looks like there were issues with the satellite geometry on the base. Together with the relatively long baseline, it could lead to some position fluctuations.
Nevertheless, I checked the RTCM3 log, not the data from the base. It’s better to double-check it with the base’s raw data log to ensure that all data was transmitted to the rover correctly. Is it possible to get this log for the same period from IBGE?
If you conduct additional tests and record raw data, base corrections, and position logs, it’ll give me more data for investigation. This way, we can either find other factors that negatively influence the solution or confirm the initial assumption. If you want to do more testing, please enable the Raw data debug option in the General Settings tab. It gives more info for troubleshooting.
Also, can you share a photo of your Reach M2 base on the site? It can be a bit tricky to set a Reach M2 this way as it doesn’t have a survey thread, so it’s interesting to know how it looks in your case!
I hadn’t thought of that Christian. I’m wandering if the M2 has adequate shielding from radio waves that close to the WiFi. I don’t think it would affect the GNSS signals with coaxial cable coming from the antenna, however it looks like an awful lot of electromagnetic noise coming from the outlet and chargers that close together. It may cause some long term effects, I don’t know. I’d probably would install some shelving to spread things out a little.
Do you have the LLH log from the described test?
