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?
Grateful for the attention and help!
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.
Just wanted to check if you need further help with it Do you have the LLH log from the described test?
I will download the raw data and send it here today or tomorrow.
Here are files on the link.
The UBX, RTCM3 and LLH files.
They are not of equal time because I had been recording only UBX and RINEX.
I also created a work where I recorded points for a few days and monitored the oscillation.
Here follows drawing the dots on a 5cm grid for visual analysis.
The PPP point at the center is a point created with the coordinates processed by IBGE’s PPP.
I’ve downloaded the files. Give us some time to check them, and we’ll get back.
I looked for information about IBGE’s RBMC-IP Base to see if it could be something with the origin of the correction.
Here are the specifications of the IBGE database:
Antenna: ZEPHYR 3 GEODETIC (TRM115000.00)
Receiver: TRIMBLE NETR9
Specifications available at: https://geoftp.ibge.gov.br/informacoes_sobre_positioning_geodesico/rbmc/relatorio/Descritivo_SCCH.pdf
http://www.bdg.ibge.gov.br/appbdg/ (Station 94026)
Were all the points (except for the PPP one) collected in RTK Fix with the SCCH0 base? For how long did you collect each point?
hello here too,
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.
Thanks! I’ll look into all the data keeping it in mind, and write back. In the meantime, please tell me the firmware version installed on your Reach.
How are you?
Happy with your return.
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.
The DOP value in the RTCM3 log is unstable and surpasses 2 from time to time:
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!
How are you?
I think the IBGE database only allows for Rinex data.
I’m going to do a test also analyzing only my base fixes for my rover over long distances.
I’ll post some pictures of my base here:
Great looking mount Mauricio ! That looks like an NGS (USA) recommended mount !
I would get the M2 unit away from those Wifi antennas in any case. Move it like 1-2 meters away.
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.