Dears,
This is my first post here.
I am trying to post-process surveys I have done with two Emlid Reach. I am a beginner and even after reading the Emlid post-processing tutorial, Kinematic processing | Emlid Studio, I have doubts.
My survey
I did several point surveys in a remote area without benchmarks, with 2 Emlid Reach antennas: a base B and a rover R. The surveys are far one from another so I placed the B in different site for each survey. The surveys need to be joined and therefore I need to georeference all in absolute coordinates (including heights).
B did not receive any correction (I need to improve the understanding of NTRIP for the future surveys!) so I set it with “average single”. I did not note the coordinates because I thought they would be stored somewhere in the logs (next time I will do it for sure!). R, connected to B, worked well with float average and fix solution.
I have up to date firmware and ReachView version.
To obtain absolute coordinates, I postprocess in static mode B with the closest permanent station S, working with S as base and B as rover. In this case I will obtain the absolute coordinate x_abs, y_abs, z_abs of B and, knowing the approximated (average single) coordinates x_rel, y_rel, z_rel of B (when I launched B), I can calculate the differences in coordinates dx = x_abs - x_rel, dy … , dz …, and apply this translation to the survey operated with R.
I am using the RTKLIB suite to convert the logs in RINEX and postprocess. My B has a huge log (all life) so I need to trim to the time window of the survey (not trivial). Following the EMLID tutorial for my field configuration I have doubts related to the log files to be used.
When calculating base position with RTKPOST, EMLID suggest
a) Choose my B .obs file for the Rover field (RINEX file from your rover which is my B).
b) Select my S .obs file for the Base Station field (RINEX file from your base which is S).
c) Put B or S .nav file in the third field.
d) (Optional) You can as well add precise ephemeris and clocks at this stage. They are required for long baselines.
Questions
Since R and B both have base and rover logs I am confused. Can somebody state which rinex should I use in a)? Rinex from *raw.ubx log coming from B or *base.RTCM3 log coming from R, or is the same?
If I put .nav from B or from R or from S in c) I have different results. Which one should I put?
What are precise ephemeris and in which format are given ? Are they necessary?
Ideally, once the postprocess is achieved I would make an average of the postprocessed positions of the B coming from the .pos so that to have x_abs, y_abs, z_abs. Since I didn’t write down the average coordinates of B, I can get the x_ave, y_ave, z_ave from the header of the base RINEX .obs obtained from the rover R. Finally I have the differences and I apply it to shift my points surveyed with R. Is it a correct workflow?
Any help is really appreciated!
Thanks,
Francesco
You can use both, they contain the same information. However, keep in mind that RTCM3 is a format used for corrections, so it contains highly compressed data with less resolution. It’s not a deal breaker, but raw log from the base is slightly better.
Ideally, you should choose a period of time during which you want to calculate the position of B. Pick the one that fills it the most. All three should mostly contain same info. R is a less likely choice for this, as it could be further from S than B and see a little less of the same sky. Also RINEX versions you work with depend. All files you use should either be 2.xx or 3.xx. B is a better choice, because some parts of the RINEX standard are not strict enough and may be implemented differently by other software.
You don’t need those for PPK, AFAIK they are used for PPP, which we don’t support at the moment.
RINEX headers only contain approximate coordinates(by design). I would suggest averaging B position, than manually entering it when post-processing R against B.
Egor, @egor.fedorov
Thank you for the quick reply!
So, observing your answer I can conclude
Use *raw.ubx log coming from B in a)
Use .nav RINEX coming from B in c), or alternatively the .nav from the permanent station S. For the record, I am using RINEX 3.03 for the Reach logs, and RINEX 2.11 from the UNAVCO permanent station.
understood
Doubt
4. I can take the averaged B position obtained from the above post-process and manually put it in the post-processing of R against B. Understood. However if I do this I will have as a result all the rover path and not only the surveyed points. Does it mean that I need to identify the time windows of each point measurement and than make an average of it? That, repeated for every point and for all the surveys I have, is too much work. Is there a way to automatically or quickly get the surveyed points post-processed coordinates for this last step? If not, does the use of RINEX header, coming from rover-base.RTCM3 to calculate the shifting, introduce a considerable error?
I am not sure what exact consequences mixing RINEX v2 and RINEX v3 will bring. I strongly advise against. You can regenerate RINEX v2 from you raw log.
We are working on software improvements to support this type of workflow. For now, your proposition of shifting the surveyed points might be the best option. I think using specialized software, like QGIS, will make this operation a breeze.
Egor,
Again thanks for the quick answer and the suggestions.
Ok, I will do it.
If somebody has a prompt solution for the workflow above (isolate surveyed points in postprocessing), please advise me.
Otherwise for the moment I will use the shifting, since it is true that can be done in a second in GIS.
@egor.fedorov, once the improvement is ready make sure to clearly announce it to the community! It will be a great advancement!
Hi Egor,
I have a doubt. To have the original base position of B (prior to postprocess), should I take the header from the RINEX obtained from the R rover_base log or the RINEX from the R rover_raw log?
They are quite different.
Thanks!
For future surveys I would advise you to use one of two possible methods:
Update to the dev-firmware “v2.10.2 dev” and use CSV when exporting your surveyed points. Then use the “collection start” and “collection end” timestamps in Excel or other spreadsheet software to extract the averaged fix solution of the postprocessed Rover path for each surveyed point. Some tinkering with formulas will be needed.
Another method would be to connect a temporary on/off push button switch to the Rover Reach’s “Time Mark” and “GND” pin. You then have to press the button at start and end of a point survey to get timestamps written to the raw log. You will find the timestamps in a seperate “.pos” file which has the ending “_events.pos”. With those timestamps proceed like above.
