Just want to verify the PPP process for the new Reference Station. As I understand it from the documentation available, the survey process will essentially be:
Configure Base Station Logging for a 24 hour survey of RAWX data
Wait 24 hours, and retrieve SD Card. (Or possibly use file manager feature in firmware over Ethernet?)
On a separate computer, process the log with RTKCONV from RTKLIB
Upload to CSRS/OPUS and wait
Return SD card to Base Station, set logging back to defaults, set known coordinates, and reboot into base mode.
Is this correct?
Also, is there any future roadmap towards an automated (Or at least more automated) PPP process?
Yes, that is correct. The process is exactly the same as for the other RTK products.
Automated PPP? No, sorry, that’s not on the roadmap. The process is way too dependent on which service you choose to process the PPP (depending on your locale)…
But many thanks for the interest and for the suggestion. It has been a fun product to develop. I’m looking forward to seeing how many users use the Reference Station in ways we haven’t even thought about…!
Regarding step 3, there are a few things you can do to make the process easier and more likely to generate good OPUS results. There’s a learning curve to submitting data that OPUS likes; if it doesn’t like your data, OPUS will abort. The NGS runs periodic webinars on using OPUS and they are well worth your time if you’re going to use it more than once or twice.
- OPUS currently only processes GPS data (not GLONASS, not Beidou, not Galileo) data. Filter out the other constellations before you upload to OPUS to reduce the upload file size. You could also turn the constellations off in the RTK Reference Station configuration but you might want this data for other processing.
- OPUS currently decimates your data to even 30-second intervals, i.e. on the 0th and 30th second. I generally collect data every 5 or 10 seconds and then filter the data to every 10, 15, or 30 seconds for OPUS to reduce the upload file size. Uploading unnecessary data just slows down the upload and wastes OPUS processing resources.
- OPUS likes observations that are aligned on even seconds. The F9P often writes messages at, eg, 0.004 or 30.005 seconds, when OPUS would really like, eg., 0.000 and 30.000. There are a number of solutions for this; there's a SparkFun python aligner script (I think PaulZ wrote it), RTKCONV has an option, and Emlid Studio (a RTKLIB wrapper app) has a check box option. The latter is easy peasy.
- You might want to discard the first 10 minutes of your log data before submitting to OPUS. Sometimes the F9P is still "settling in". As an alternative to manipulating the log data, I usually mount my unit (I have Facets), power it on, take paper notes about what I'm doing and otherwise kill some time, and then start the logging (or open a new log file.)
[*} Wait 24-36 hours after the end of your data collection before uploading to OPUS. OPUS needs to collect and process data about the space vehicle orbits to give you better results. If you submit too early OPUS might just abort. The NOAA website has best practices on using OPUS, there are more details about this there.
Of course, setup with clear sky view on a physically stable mount.