Hello Emlid community,
I am a marine biologist (totally foreign to these issues before discovering Emlid) and since about two years I started working with aerial UAS mapping.
I would like to ask you some opinion and suggestion about PPK data deriving from my Reach Rs+ units and Rinex files from a CORS. I apologize in advance because maybe I will ask some trivial questions but since previously I was able to get awesome results thanks to your suggestions, I am really motivated to ask again
My scenario is the following:
- Two Reach RS+ units used to collect GCPs before aerial mapping in RTK mode
- A CORS station very far from me 150 Km but without particular obstruction because I work on an Island.
My trials gave to me some difficult results to understand given my poor knowledge. So please help me to better understand this odd word_
So by using RtkPost, I processed the data deriving from my Rover unit against CORS Rinex and I achieved a very good result (with 99.8% FIX solutions which is quite unexpected given the long baseline) but only when I use the following settings regarding Ionosphere and Ephemeris.
However, I learned that with Precise Ephemerids available at ftp://igs.ensg.ign.fr/pub/igs/products/ the results should be improved, so I downloaded rapid ephemeris file (igr-number of the GPS day-.sp3) some day after my survey (igu, that is ultra rapid are available almost immediately but rapid should be better from my knowledge). I changed only these settings in Rtkpost and the results seemed to get worse. As you can see below the Fixed solution percentage dropped at 88.9%
Moreover when I tried to compare both results (green e blue points are the fixed solution) in RTkPlot I noticed that the my tracks along which I collected GCPs are shifted more than 1 m each other.
Now my thoughts are that with rapid effemerid the ambiguities are resolved differently and probably the correct absolute coordinates of both my track and then of the GCPs are stored in the second .pos file derived from PPK with precise ephemerids.
Someone could confirm this idea ? What I am missing?
The second step I tried was a trial to work with a shorter baseline during PPK in order to avoid using the CORS data to process directly Reach rs Rover track to get its absolute positions.
My workflow is the following:
I put my Reach Base unit on a tripod and recorded raw UBX logs for three hours, before starting my operation with the rover unit . Subsequently, I collect in RTK mode the track and GCPs (remaining on the point for 5 minutes) with my rover unit (so in the field I collected with Reachview App only relative coordinates because I averaged position of my base unit on a unknow point).
At home I processed the raw log of my base against rinex file from the CORS to estimate absolute coordinates of my base unit (also in this case I noticed a shift in my data when using rapid Ephemeris so the same problem as before). However, beside this aspect I choose one result (namely that derived from PPK with ephemerids) and I was able to filtering it according time in order to preserve only fix solutions on my static point (the base). I noted the ORI coordinates displayed in the top right corner of Rtkplot.
Finally, in RtkPost I uploaded .obs files of both rover and base, .nav of the base, precise ephemerids and in the base position tab I manually entered the absolute coordinates estimated before.
In such way I supposed that by adding the absolute coordinates also the rover positions will be changed from relative (linked to cumulating and averaging processes of base unit in the field) to absolute (linked to the PPK with CORS). However, the results reported below was no so good because many float (Q2) solutions, even in the parts where fixed (Q1) solution was achieved before (when I processed rover data directly against the rinex from the CORS).
Again what I am missing ? I need to change some settings or my workflow is absolutely wrong?
Sorry for this long post and I hope that someone else will find it useful for other similar questions.