Hi David
I was able to get NRC to process your file, but only after converting it in rtklib. NRC only accepts gps and glosnass although I have been unable to get glosnass to work.
Jim
Hi David, you are welcome, believe it or not I have never used ReachView, Iām still waiting for my Emlid Reach to arrive, but I have ample experience in the GNSS industry, my suggested plan of action for you is:
- Check you are using the latest released Emlid firmware.
- If the RINEX header still reports:
8 C1 L1 D1 S1 C2 L2 D2 S2 # / TYPES OF OBSERV
instead of
4 C1 L1 D1 S1 # / TYPES OF OBSERV
report that to Emlid as a bug in their firmware.
It is interesting to note that ReachView is just a web based frontend for RTKlib and RTKlib default conversion parameters are:
8 C1 L1 D1 S1 C2 L2 D2 S2 # / TYPES OF OBSERV
If you canāt wait for a firmware fix, you can use your Ublox formatted files and use this: RTKConv which is Emlidās build of RTKlib converter, in there you can uncheck the L2 checkboxes.
Note also that RINEX files can be manually edited BUT you MUST preserve spacing (like I did on my example).
Hi Jim, thanks for checking that for me. So when you converted in RTKlib, you deleted the second L2 flag in the header? How do I do that in ReachView? Frankly - trying to find a way around not using RTKlib as I donāt have a Windows machine. Only Mac. Do you know anybody with an OSX version of RTKlib?
Hi Jim & Isaac -
OK, stupid me, didnāt realize I could manually edit the .obs file, which I have just done, and re-submitted to NRC. Hopefully this works. Will let you know. Thanks again
Well ā got an error again. Good that the error has changed this time to:
CSRS-PPP online was unable to process your submitted RINEX file. Most likely causes are bad data, bad satellite identification or time tag problems.
Any ideas?
Hi David
Sorry I donāt know about rtklib and the mac os.
I do not see any way to change in Reachview either I know I have tried just using gps and seems that I still need to convert the reachās rinex 2.11 in rtklib to get it to go on NRC site.
JIm
Hi David,
Thanks for continuing this conversation! Iāve been unable to participate for the past few days. I, too, am a Mac user. It appears that weāre being drawn into unfamiliar territory.
Hi David,
I submitted a 2.11 RINEX observation file (generated by ReachView) to NRCanās PPP tool just last night and also ended up receiving the same error message:
raw_201711172336.obs
Error : CSRS-PPP online was unable to process your submitted RINEX file. Most likely causes are not enough epochs or missing data types.
I decided to convert the RAW uBlox data to a RINEX 2.11 observation file using RTKLib and and resubmitted to NRCan. This time the PPP tool was able to process it without any errors. This left me scratching my head as to what the problem was and my Google search of the issue led me to your post.
After reading Isaacās comments regarding the RINEX header, I investigated my original ReachView generated RINEX file and lo and behold it read:
8 C1 L1 D1 S1 C2 L2 D2 S2 # / TYPES OF OBSERV
It appears that is indeed a bug that the Emlid guys should be made aware of. With the problem identified, I also downloaded your file, removed C2, L2, D2, and S2 from the header file while preserving spacing, submitted the .obs file to NRCan, and successfully received an output without any errors. Iāve included a screenshot below, which hopefully may help!
Regarding macOS, Iām also a user, but unfortunately havenāt had very much luck with getting RTKLib working. I was actually forced to install Bootcamp on my MacBook specifically so I could use RTKLib in the field.
If I can help in any other way please just let me know!
Cheers,
Adam
Thanks Adam! Will look into the details.
Hi Adam, thanks a lot. Would you mind reposting the corrected .obs file? I tried once again tonight, taking care to keep the spaces etc, and it still errored out on me.
Appreciate the help. Bootcamp maybe the best way forward, otherwise, Iāve got to purchase a cheap windows laptop.
David
Hi Adam -
Cancel that, I was able to get it to work now. In the line ending:
/ TYPES OF OBSERV
I thought that the initial numeral (ā8ā) was an flag for the number of conversion parameters that follows, so when you delete C2, L2, D2 and S2, then (erroneously) that this number should be changed to 4. That doesnāt work. You need to leave it at 8, and then it works.
Donāt understand why, given Isaacās post above, but anyway???
Thanks again
Hi David,
You know, that was a complete oversight on my part, sorry! I forgot to change the 8 to a 4, which I believe is how the line should read. When I examine the headers of other RINEX observation files generated by RTKCONV, they do indeed show:
4 C1 L1 D1 S1
So, the fact that it works with 8 and not 4 is a bit perplexing! Maybe others can weigh in.
Cheers,
Adam
That said, I am wondering why my coordinates are like +/- 0.5m, for a 45 minute stationary observation ā¦
Hi David,
I also conducted a survey this afternoon and my results were slightly worse (see Sigmas (95%) below). Iām assuming that 46 minutes is just not long enough of an occupation time for my location and I will try a longer survey in the future. Iām currently in British Columbia, Canada, right on the coast and in a valley with mountains 1000 m+ high on either side, which might explain some things.
On a side note, in order for me to successfully get results from the NRCan PPP tool using my ReachView generated RINEX file, I had to change the header file from 8 to 4, as shown below.
8 C1 L1 D1 S1 C2 L2 D2 S2 # / TYPES OF OBSERV
4 C1 L1 D1 S1 # / TYPES OF OBSERV
When I removed C2, L2, D2, and S2 but left the 8, I received the following message:
Error : CSRS-PPP online was unable to process your submitted RINEX file. Most likely causes are bad data, bad satellite identification or time tag problems.
There doesnāt appear to be a lot of consistency to these error messages. It would be nice if NRCan had some in depth documentation!
Cheers,
Adam
Hi Adam - thanks for the info. Iām stumped as to NRCanās lack of consistency. Amazing. So given both of our accuracies (+/- 1m), how does one achieve centimeter level accuracy? Longer survey times?
Hi David,
If you havenāt already, Iād check out the following post by @EarthImage: 24hr Reach Collect : NRCan PPP results
Peter presents the results of some of his extended duration surveys with the Reach and compares them to those obtained by an L1/L2 receiver. To sum things up, the Reach generally appears to be limited to a horizontal accuracy of 15-30 cm when post-processing with PPP. I believe this is due mainly to the fact itās only a single frequency (L1) receiver. While L1 data can work with NRCanās PPP tool, ideally youād have a dual frequency receiver that can obtain information on the carrier wave, which would allow you to account for the effects of the ionosphere.
I recently conducted a 5h40m survey with the Reach and my PPP results showed a horizontal accuracy of 24-33 cm and a vertical accuracy of 58 cm. Granted, I wasnāt able to verify this against a known point, so who knows if itās truly accurate. As I donāt current have access to a survey-grade L1/L2 receiver to establish a known point, Iāve been trying to find a ground control marker recently surveyed in by the government or a surveying firm, but they appear to be pretty scarce in my part of the province!
Cheers,
Adam
PPP (precise point positioning) is not the same as differential post-processing (PP kinematic or PP static).
PPP requires long observation time (usually +60 minutes).
If your static session is long enough (over 60 min) you will be able to reach PPP accuracy which translates into:
- few centimeter (2-3 cm) with dual frequency receiver
- about half meter for single frequency receiver (staying longer does not help to improve accuracy)
On the other hand differential post-processing can provide amazing results with single frequency receiver!
Differential post-processing means you have a base station nearby. The accuracy is superior in comparison to PPP and the observation time is much shorter! With a short baseline (distance to the base), single frequency and dual frequency receivers give the same level of accuracy. The advantage of dual frequency is:
- the baseline can be longer
- a shorter observations time is needed to reach a good level of accuracy
For example if the base station is within 10km (or less):
- dual frequency receiver will reach sub-centimeter with short static observation (2-5 minutes)
- single frequency will reach sub-centimeter with about 15 minutes static observation
- PPK (roving antenna) dual frequency will reach 1 cm accuracy if your file last 2minutes
- PPK (roving antenna) single frequency will reach 1 cm accuracy if your file last at least 30minutes (with very few obstructions)
Single frequency on the UAV can provide excellent accuracy because there is no obstruction in the air and it is easy to record data over 30 minutes (if the flight last 20min, juts leave the data logging on for few minutes after landing). This way you make sure to reach centimeter accuracy with PPK.
1 Like
Hi Stephanie,
Thank you for your informative post!
So, if we are unable to establish a basestation for differential post-processing, due to either not having a known-point or access to a L1/L2 receiver to survey one on, and if weāre beyond the range of a reference station, the best we can hope for is +/- 50 cm using PPP?
I also wasnāt aware that for single frequency PPK with a roving antenna you should ensure the Reach logs for a minimum of 30 minutes. This may explain some of the poor results we obtained from our field work earlier this year, as a number of our rover logs were less than 30 minutes in duration. Is this information included in the Reach RTK kit documentation?
The first time we used the Reach RTK in the field this past May, the greatest challenge we faced by far was a lack of information regarding the best settings for a post-processing kinematic setup. Luckily for us however, the Emlid community is amazingly supportive and we were able to get some good advice. While the documentation has improved since then, I still think itād be great to have some additional tutorials for the more common applications and post-processing workflows.
Cheers,
Adam
Hi Adam,
I guess 50cm is the best you can hope for from PPP L1. That being said, you would probably get better results from static differential post-processing. With static file, you can achieve centimeter accuracy with base separation of max 45km (with L1). With 45km baseline make sure to observer over a long period (ideally 2-3 hours). Other than that L1 float solution would most probably be more accurate than PPPā¦ PPP is a great solution for dual frequency receiver, not really good for L1.
I use EZSurv post-processing software for PPK. To insure PPK at centimeter level with EZSurv, it is highly recommended to have over 30 minutes of un-obstructed data. It may work with 15 or 20 minutes, but it may not, so if you do not want any surprises and want to insure your job will be at centimeter level, leave the recording on until you get a 30 minutes of dataā¦ Well that statement is good EZSurv OTF post-processing engine.
If you want to try EZSurv with some of your drone file, you can ask for a trial:
http://www.effigis.com/freetrial/
EZSurv is very simple to use, it comes with quick start guide and a step by step video on how to PPK UAV files.
Cheers,
Stephanie
Thanks Stephanie for the clarification and suggestion of EZSurv! Iāll definitely check it out! 
Cheers,
Adam