I recently completed a survey in an area where there was inconsistent cell coverage. I usually run NRTK but in this case I setup a base over a control monument and logged from both my base and rover as well. My baseline was around 2 km. I observed points for at least 5 s with my rover. Once I pulled my logs and downloaded the CSV, I tried to post-process in Emlid Studio. The issue that is coming up is that I am only getting success post-processing on 29 of 135 points (something like that). When I look at the resultant CSV I see several of the points that wouldnt post-process as “#NAME?”. I am not sure why this is happening. I adjusted some of the post-processing settings and still the same thing.
I had a quick look and can’t get better than 23 out of the 106 to fix, using various combinations of masks. I uploaded the base to NRCAN and it wasn’t great, report attached. The local CORS at TRUR, BASS, KTCK are all giving me a float low quality in Carlson as well for static base position. I think your base may not be good in the first place. Did you check if it had been disturbed during the session? Might sound silly, but I’ve had someone lift the tripod and move it a few times, so best to ask.
Looking at the data, you have quite a few cycle slips in the base:
I can get the main log to process out to ~90% fix but it looks like the area to the NE of the site is very close to tree cover. How high is the canopy there? Using TRUR as the base for stop and go, isn’t great as the occupations are so short for the 12Km baseline.
If the base location was good, other than a base shift on the RTK positions I’m not sure what you can do. If you have all the ENH and apply the difference between the derived base (201) location used for the RTK survey (I’m assuming it was an average fix on the NTRIP service?). The RTK results look OK, the floats are still within 4cm. How critical are the points, what is the error budget for the job? It may do for what you need after that base shift to the correct monument location. I’m wary the base logs are not good. Both NRCAN, Studio and Carslon are not giving a good result for that file.
Thanks for sharing your data! I took a look, and it seems the points in your CSV file weren’t in chronological order by time. Once you rearrange them, Emlid Studio should process everything just fine. I’ve attached a corrected CSV file for you to use.
To improve the ratio of FIX solutions, I adjusted a few settings that worked for me:
Scott, thanks for your help looking into this. I setup on a High Precision Control Monument and I am quite confident the base nor tripod moved. The published coordinate is well established also.
In my opinion, and others have discussed this, you need longer occupation times in order to post process. If it was me , it would be a minimum of 5 minutes per point. In your data, there’s not enough data to post process. I would bet if you reoccupy the base at another point you computed and re observe all your points you would discover errors in you data.
It’s great you can tweak the data with various variables, but if you don’t have a minimum of 98% fix on all your baselines, your data will not be accurate. My opinion from over 35 years of GNSS post processing is the more data the better the accuracy confidence in your overall project.
Thanks for your comment. I understand that observations times really should be considerably long and generally for baselines less than 10 Km, a minimum of 5 minutes. I guess for future reference, I should focus on establishing control closer to site and leverage RTK over UHF.
No worries at all, glad there’s been a fix for you. I didn’t look at the stop and go file point order, so keep that in mind for future. Not sure why the file was reordered, was that the same file you exported from Flow? Any ideas @inkar.madikyzy?
I agree with @EBE111057, the time on point is important. It’s easy to nip the time to get through the collection stage more quickly, but for points requiring higher precision then it’s worth making that extra time. Or pulling your base much closer onto site.
I wasn’t questioning the monument, that’s fine. I was looking at the quality of the log file on that point. Having to ramp up the masks to 45 degrees to fix out the survey isn’t the best result. I ran the base file through NRCAN, Auspos, emlid studio with TRUR as base and using three cors in Carlson and all gave a float solution. NRCAN couldn’t fix any ambiguities, Auspos only around 35%. Was the monument out in the open and no obstructions?
