I created this topic because I had to carry out a long process to obtain absolute precision in my ppk process.
I did a survey of a drinking water system, I read some advice in the forum that although this information is raised in RTK, placing the base in a known coordinate (as it was my case), as a precaution it can be stored the raw data in the registry to later perform a PPK if necessary to the lack of some coordenda for signal problems at the time of performing the RTK.
In my case I did the post process as shown by EMLID in its tutorial, only that I put the known coordinate and the result was the wait. But my problem was that the events are not saved and then I can locate exactly the points that correspond, it took me a good time to relate the times of the rtkplot with those of the coordinates that I picked up with the survey tool, and that is why I ask you these questions:
Is it possible to save events with the Rover? I have seen that apparently this can be saved only with the camera shot.
When you say data in registry are you talking about logging? You can take topo shots in survey, turn logging on and off at each point keep note of the time or post-process and plot - you will be able to visually see the shots on the line graph to note.
Like Michael said. I think you are asking for the individual occupation time of each survey point? If you used the Reach survey tool to record a point you can pull time from these to use in RTKPost. If not did you record start and end times manually? One could also individually log a file for each point. See a thread I wrote below. There are lots of others out there as well.
I have certainly read your post and I think it is more or less similar to what I did. Compare the times of my GCP collected with the “Survey” tool of EmlidView, I opened in excel the result .pos of the ppk and I was comparing the time data to be able to find my GCP. I have achieved this but it has taken a long time, besides that my time data from the “survey” tool only has seconds and apparently the .pos file contains milliseconds, I think this would give me a few centimeters or millimeters less precision and every second in this .pos file is divided into four, I choose the first one that is second time in “0”, because that is how the seconds of my GCP are exported from the “survey” tool.
I see. I ask how long were you occupying each point roughly? A few seconds, a few minutes, hours? Depending how long you could “trim” in RTKPlot in combination with manual assessment of the position and velocity graphs. You will surely see when your antenna was moving vs. stable (collecting a point). You may lose a few points here or there but would not expect a drop of a few centimeters of precision if all other processing was sound and the occupation time was sufficient. I understand how you were trying to arrive at a solution as a workflow but in your case I would be less concerned with the time of the data but rather when it was stable analytically because this is your GCP collection window. As they say there are multiple ways to skin the cat. Maybe the Emlid team or others can chime in on the timestamp difference between survey file and log file if you want to arrive at it this way.
I didn’t see it above, so what has been your need to post-process all the points? Is the survey function not working, not getting fixes? This is why the stop-and-go survey method we enjoy today was created. To me post-processing seems more of a control point method and not the entire survey.
From my recent experience with PPK on my drone I wonder if that method could be somehow applied? I have actually wondered myself why I couldn’t use an inexpensive gps camera to trigger an M+ and post-process the events just like I do with the drone? Then I have pictures of the points as well…
a please ask, at the time of performing RTK, the height of the cane is already compensated in the reading or is it necessary to remain the height of the cane to the elevation value in RTK?
If you are surveying shots it’s best to put in the pole height to save work and confusion later. If you are processing logs then all of that can be entered in RTKPOST.
I didn’t want to hijack your post, but our friend @timmyd was already wondering the same thing as I just stated.
Well it would be to have the same precision of the known coordinate, I am not very clear is subtracted or not the height of the stick in RTK at the end?
Pues serĂa de tener la misma precisiĂłn de la coordenada conocida, no me quedo muy claro se resta o no la altura del bastĂłn en RTK al final?
Your are collecting (stakeout) “known” points? And collecting the data for verification? Apologies, I am unclear on your use-case and what data you need in the end.
The pole (rod) height is positive, which in turn tells the software that the point in question is lower than the receiver.
If I’m just testing the accuracy, I have some values in a bit high heights compared to the real data, apparently I also see that in RTK my data has not yet subtracted the height of the stick, I do not know if I’m right, put when I rest the height to these values, my heights are more similar to the values obtained in PPK, barely with a difference between 2 to 8 cm in Z.
Makes sense. If you don’t put in the rid height it thinks the ground is where the receiver head is. Were you able to put the rid height in rtkpost to counteract?
I wish the same as Marlon to ease my work flow.
I am surveying typically 800-1000 points a day, about 1-3 seconds each, not always having a fix from the base (RS+). I need about 5-10 cm accuracy. At the office I have to PPK the base and the rover data to get fixed rover .pos file. Then I have to open the rover .pos file and the rover survey .csv file in Excel and correct the survey point coordinates there. I am using the timestamps to correct the point coordinates from float to fix (averaging from start to end of survey time). So, it would be great to have a tool or a good advice to get the fix survey points more easily.
Another thing I have noticed. Maybe after 200-250 survey points Reach RS+ gets slow in saving an individual point. It takes only a few seconds more, but it is still to much I get around this by creating a new survey job. So this is not a big deal.
Mine Reach RS+ also gets slow with 200+ points. I think, that the problem is with the list of all the points, when it gets there back from the measurement.
I made a script, that helps me in PPK. Usually, I am taking log files, processing them with RTKLib and afterwards putting pos file and csv from the Survey to the script. Script is reading CSV file and taking out measurement starting times and end times. Correcting time from UTC to GPS time and then filtering pos file based on the time period for each point. After that, I am just finding centroid of all the points. Sometimes, especially, when you don’t have all the points fixed, I see, that coordinates can be not so accurate, so I am using only FIX points.
The script is written in R language, but I am in the process to make a small tool, that will run independently from R. Basically, a small program, that does the same job, but with user interface.
That sounds a good tool. I have been thinking something similar, but without coding skills it is a bit challenging. I am certainly interested in having your tool. Great work!
You may want to try EZSurv post-processing software. EZSurv can read the CSV file created with ReachView, therefore each point is post-processed and a weighted average is made (if the points are recorded over few seconds or minutes). The output from EZSurv is the position for each points in the projection of your choice with ellipsoid height and also mean sea level height if you use a geoid model.
I get around this by creating a new survey job. So this is not a big deal.