Hi,
I did not plan for maximum satellites. The results are for complete log. And Forward first good fix at about 5-7 minutes, so see upload for expected real-time forward only…
I’m not sure how much testing of this latest version has been done as some of the revision seem a little hard to decipher in the RTKLIBexplorer blog. I also don’t know if they can be used realtime.
He has recently started testing low-moderate priced L1L2 receivers, so I don’t expect any upgrades. Most of the last changes are changes in the RTKCONV module. EDIT Corrected RTKLIBExplorer Forward. Typo error on my RTLCONV OPTIONs.
Note that processing FORWARD only and selecting only FIX after good FIX yields the same ENU values as the FORWARD-REVERSE plot. The FORWARD only yields slightly increased STDDEV. In this case, it is insignificant compared to my placement accuracy.
Hello all,
This is a conceptual question.
As per my knowledge from the books I’ve read, fix status is achieved when the integer ambiguity of the carrier wave is resolved by the gps receiver, anyone have an idea how does this happens in reach, moreover on what factors and settings the fix status depends.like what external factors and what settings in the reach view app.
Thank you!
So, here is same data with Emlid RTKCONV and using same options. Emlid RTKCONV PPK forward got FIX sooner (by several minutes) than other RTKCONV. COMBINED results were very similar (0.2mm).
I’m not sure what the difference is between the Emlid and RTKExplorer last update. Apparently, it is not much.
Yes, the processing is done with RTKPOST. However, in post processing, the raw data UBX files are converted into .OBS RINEX files by RTKCONV. It is my understanding that some the recent changes were in the RTKCONV application and had to do with transitions between good and bad satellites making loss of lock less likely.
(Please note that GLO Fix&Hold works here because ROVER and BASE receivers are identical.)
Edit**** Corrected FORWARD plot for RTKLIBExplorer…See previous plots… Not too shabby for obstructed sky both Rover and Base…Good correlation with Emlid post processing.
I have had successes with the RTKExplorer binaries lately as well - also with obstructed sky. For static points, I was using all available constellations, static mode, continuous AR, minimum 40 SNR, and a 5Hz log.
It appears that Emlid Post Processing is either the same or close to RTKLIBExplorer latest version. What may be missing in the Emlid DOCs is the OPTIONS entries and mask modifications. In my view, they are so close that I don’t see much difference. I have not tried new RINEX logs saved by ReachView to do post processing.
In terms of masking, everything below 15 degrees is usually much noisier, 35-40dBhz mask on SNR will be good as well. It is not really that critical to get it “exactly right”. It is just a tool to exclude data that is definitely bad.