I use the Reach with corrections for establishing anchor point, from which I survey trees, buildings, etc using a laser range finder. Since purchasing the Reach unit my results have been very impressive!
The process, however, is a bit clunky so I’m looking for suggestions or future software enhancements.
My current process is to run in Kinematic mode with corrections streamed from my iPad data plan. When I want to establish an anchor point I turn on raw logging (so I can post-process later) then go to survey and collect a point, either FIX or FLOAT. Once I have my point collected I go back and stop the raw logging.
Is there a better flow I’m not aware of, or would it be possible to include raw logs with the survey point collection? It’s difficult to match up the raw log with the survey point as all I have to go on is finding a similar time stamp. Thanks, and great product!!
I think you are doing it correctly. If you are post-processing your raw logs, then the point collection isn’t necessary. All I do is start the raw log, write down the log time and a name for the point, and stop the raw log before moving to the next point. Then, when I download each raw log, I just add the point name from my notes to the filename.
Of course setting some parameters for a survey project and starting a point collection has the benefit that you can do something else and then check in a few minutes to see if the point was successfully collected (meaning that there was no hiccup in the RTK status, and your project requirements were met for that point). Now you can be confident that you can get the same or better results from processing the raw logs later.
But yes, this could be streamlined. It could be as simple as being able to append a note or a point name to a raw log while it is recording. More likely this could be solved better by a third party program/script which takes your survey project with it’s saved points; then extracts the start and end time of each point; then automatically triggers a post-processing job for each point. Theoretically, that job could also be done on the Reach module itself instead of your computer. Of course, you would have to leave it on while traveling back to the office.
Then again, if you give post-processing control over to an automated process, then it is hard to make the manual adjustments that are sometimes necessary to get the most of your data. It’s not a one-size-fits-all situation, but there’s definitely room for it to evolve!
For a RTK survey use I think the project / survey point option is a bit weak, with only one point averaged. We have raw data (absolutely needed !) and E/N/H position log possibility, but they are continuous logs. So it is very difficult to go there and extract point per point when needed.
I think survey would need as a minimum to log also individual RTK Time/E/N/H solutions when we station a point. We could look for eventual outliers more easily.
I have been trying to apply this process, with moderate success. It seems that I need to occupy a point for quite a while to get a Q1 PPK solution for any given point. I am hoping you can share your field procedures and RTKPOST workflow. Here is what I have been doing so far.
- Set up REACH RS Base and lay out 4 GCP’s within 15 m of base
- Turn on base and start raw logging
- Turn on Rover, move to GCP 1, start raw logging for 30 seconds. Turn off raw log an move to next point.
- Repeat for all 4 points.
- Wait 10 minutes, then log all 4 points again.
- Start continuous raw logging, stopping for 30 seconds over each GCP. After all 4 collected, turn of raw log.
- Make sure 30 minutes raw logging time allowed for base, and then shut raw log off, and go back to office.
Thus far, I am not getting a Q1 solution on my individual GCP points. I am however getting Q1 on my continuous raw log where I visited all of the points.
Before getting into any of the PPK stuff however, can you tell me how long you normally log raw data for a point of interest?
Thanks!
I think an update to the post process side would be great, meaning, that you could load all your individual RAW logs and run them all at once against the base log. Instead of doing one at a time.
Hopefully an update to the RTKpost could solve this.
Example:
Load 10 RAW rover logs and process against 1 base log.
30 seconds is very short for a log file that you expect to produce a fix. You should set up for RTK and see how long it takes for Q=1 fix and adjust the length of your occupation time to something more reasonable (try 5 minutes).
Otherwise, if you are in a hurry and want to occupy for only 30 seconds, then you could adjust your procedure like so:
- Start base and rover.
- Start both raw logs.
- Set up a survey project for single mode collection of 30 seconds.
- Keep rover pointing up with good satellite view while you travel.
- Take rover to point and start point collection.
- Repeat 5 for each point.
- Pack up and head back to office.
- Download log files and survey project.
- Post process your base and rover log file in Kinematic mode into one solution file.
- Look in survey project file and get start and end time of each point.
- Use the start/end time feature of RTKPLOT to align with start/end time of each point.
- Use the statistics feature of RTKPLOT to get your averaged coordinate or other stats.
- Done!
This method lets you run a long rover log file so that it can establish Q=1 before you set up on your first point and it should maintain it for the entire survey as long as the rover has a consistent view of the sky.
Additionally, if you post-process in “combined” mode instead of “forward” mode then you are most assured of a fix for your first point.
For now there is no better option. I also would recommend recording a longer raw log for every point, as @bide mentioned.
We are working on a solution for this.
Thank you for the reply.
I was able to get the accuracy I wanted by letting the raw log run continually on the rover, stopping for 30 seconds and surveying a point, and IDing the points in the PPK output track by looking for clusters. It took a while to isolate the clusters and average the position to get a single point (did this in excel)
It is good to know that the EMLID team is working on improving the workflow 
Hopefully you can add a time GPST time stamp to the survey files exported as a shapefile that will allow used to match the surveys points to the raw log. That should allow for better automation.
Thanks!
Shapefile and DXFs are tricky in terms of adding additional fields. Looking into this at the moment. Maybe CSV is the way to go for you?
CSV is much more flexible than DXF or SHP. Excel is the surveyor best friend for first raw data works, GIS come just after.
Something like this would be great as a detailed survey log:
- x lines per fix : E,N,H,Q,Time
- 1 line per point : average(E,N,H), std_dev(E,N,H), Nb_fix, Time_start, Time_end
Like this you can quickly discard Q=2 points, or simply outliers.
The survey log as it is now is a bit “black box”. We don’t really know what happened during average.
I am having the same issue. I expected that I could post process Rover survey points using the raw Base Rinex Logs, but with the only export options of Survey points being Shape, DXF and Geojson. Geojson looks most promising because it includes a Time field but I cannot find a way to convert to a RINEX OBS file to do the base corrections. Turns out this is why I purchased this equipment and I’m a bit disappointed. BTW there is an online utility to convert to Geojson to CSV at http://www.convertcsv.com/geojson-to-csv.htm, which works very well.
If anyone has any ideas please share, otherwise I have just wasted $700+ for equipment that I cannot use. I understand that if the Base is set up in radio range of the Rover, the corrections will be applied to the Survey Points (I hope), but due to my local terrain and radio range, I would prefer to set the Base on a known point and post process. I imagine that I am not the only one that needs to do this. Thanks. PE Retired.
We use RTKLIB for that. It is free and open source. Emlid has their own flavour, which is downloadable right from the page as you read the official POST-PROCESSING GUIDE in the docs.
While it may be true for the software version you are currently running, that is not a correct statement. CSV export has been available as one of the export options in the ReachView DEV (development) version since this public news announcement on Dec 18, 2017. You could have switched to DEV version at any time since then by clicking that button in ReachView. But even better than that, you could have easily upgraded your ReachView stable version to get CSV export according to this recent public news announcement from 3 days ago.
Now, I’d also like to clear up a misconception you may have based on the way I read your post:
- The survey tool export files are final products. They do not get post-processed, and they will not convert to RINEX OBS files.
- The raw data log that you choose to record (in the logging tab) is automatically converted to RINEX when logging is finished. The appropriate RINEX files are included in the compressed ZIP file that you will download.
To give some background information, the survey tool is currently designed for RTK use and so it can’t be expected to automagically work for PPK without traveling forward in time to retrieve the accurate solution data that you will be doing the post-processing for later. I don’t mean that in a cheeky way, but just to make the point that when you are set up for PPK work, your rover when collecting points is doing so in single mode which is neither RTK or PPK and by that nature the points collected are not what we consider accurate. The accurate solution data will be determined later by a different piece of software called RTKPOST (see the docs).
The solution to the time-travel catch-22 situation is that while in single mode and your rover is logging raw data for PPK, you set up a survey project to collect single mode points. Later, when post-processing your raw logs, you can download the CSV survey project; grab the columns with point name and start/end times and discard those inaccurate coordinates. Now, with a table of the start and end times for each point, you can then retrieve the accurate position data from your processed solution file based on those times. There are ways you could automate the process, but it is worth noting that the program RTKPLOT (see the docs) has a manual process to view data from any of your collected points, based on their start/stop times, along with statistical information which may be helpful as well.
I hope that helps alleviate your fear of wasting your money. Surely, you must have known that people have been doing PPK with Reach and Reach RS from the beginning! 
One more thing. If you don’t like this PPK workflow, there are other ways to approach it, plus I believe there is non-free software available that can automatically do some of the work for you.
Thanks for your great response. I learned more than in all my poking around at the Emlid website, RTKLIB manual/ tutorials and trial and error. I, like many of the users are not software experts, but merely "beggars at the banquet ". Given that my next choice for true survey RTK would have been $10k or more, so I am very happy to have this opportunity . That said, one solution will be make my Base setup more mobile. Current problem seems to be range limitations of the 3DR radios and line of sight. Have looked into LoRa but apparently only available with RS. Any recommendations would be welcome. So, thanks for the good advice, and I do think I got my money’s worth.
So was I a couple of years ago. Most of what I learned has been one small piece at a time. It would have been really nice to download it all into my brain in a day, but the most valuable learning was in the time spent using the hardware and software. Don’t be afraid to ask questions though, because there are some easy answers that can save you some grief.
No problem, and glad to hear it!
As far as getting a better RTK experience beyond 3DR radios (assuming you’ve tried different settings), then you could try the similar license-free radios by RF Design in Australia. Or you could try some third-party LoRa radios, or for really challenging environments, you could look at the high-power radios that require a license, such as those by Pacific Crest. Alternatively, if you are operating within a cellular coverage area, you could use two smartphones by setting up a Wi-Fi hotspot on each, or use cellular modems, etc.
Thanks for the detailed info! One thing I would like to clarify, based on reading your post:
When operating in RTK mode, the RINEX file is raw, single, uncorrected data, correct? It is possible to use survey mode for RTK, then take the raw data you logged and post-process it against a different base station after the fact? Thanks!
When operating in RTK mode, the goal is to produce final, processed/corrected, and accurate data. That data is saved in the position log, or it could be collected and saved as a survey point within a survey project.
At the same time as that, you can be saving raw, single, unprocessed/uncorrected data. When when finished saving, it will be converted into RINEX and both the raw and RINEX data are saved in a ZIP file for download. You use those files for PPK (post-processing).
Does that make sense?
You lost me at the end. When I view the log files I can download the Raw data as either RINEX or UBX (does this format matter?). In the RINEX zip file I see nav/obs/sbs files. This is the uncorrected data, right?
- Each GNSS receiver spits out raw binary data which can be saved to a UBX file.
- That UBX file is converted to RINEX files: .OBS, .NAV, .SBS (and for older versions also .GNAV and .HNAV)
- That conversion can be done for you by ReachView and presented in a compressed ZIP file
- or you can perform the conversion from UBX to RINEX yourself with the RTKCONV program, etc.
- Then when you have a set of RINEX files from the base station and also from the rover, you can post-process them with the RTKPOST program.
Yes, each set of RINEX files is uncorrected data from one GNSS receiver (base or rover).
Does that explain it a little better? Of course that is not all there is to say, but I hope it is enough to satisfy the question.
That answers my question, thanks!
You might be interested in the following related thread:
Regards,
-FGN.