In the last couple of days I had to revisit some Tracks to improve a config file for some edge case acceleration testing.
Files are having cycle slips and other problems but I managed to get them improved.
I use the Emlid Rinex logging and the latest demo5 RTKLIB library for this (need the CLI).
In addition I started testing the convbin from demo5 libraries and was wondering why getting sometimes very different numbers in the satellite lines.
I ran this demo5 convbin Rinex files and was able to eliminate nearly all problems with my files - just by switching from standard “emlid rinex” to “emlid ubx with conversion in demo5 convbin”. (CLI config file etc. is the same)
I am wondering now, if there is something weird with the conversion at some place (either emlid or demo5). But getting cleaner results in demo5 I am also wondering that there could be a possible improvement?
I always could do a convbin round in our script and use ubx, but maybe I can avoid that…
Files are from testing in March (Rinex emlid convbin 2.4.3), but the difference in files remains in files from today.
I am happy to share files via PM but config is heavily edited.
What I have seen in the past doing the same exercise and viewing the 2 rinex files in skyplot is that in the UBX it gives you a truer picture in terms of cycle slips (more CS’s showing) and also displaying lower angle data.
If that then contributes, that is a tough call.
One thing to check out is the header of the Rinex. That will give you an indication of obs-types etc.
so far I was able to replicate this on 7 different files/days
just using the UBX and convert them by hand seems to give better results…at least with a lot of cycle slips in my files
I’ve checked the processing performance of the Demo5 b34c compared with Emlid Studio Beta 9 as we are moving away from the RTKlib V2.4.3.
The solution track looks similar. However, there are differences in the percent of fix acquired. I’ve passed this info to our devs to take a look. I’ve also checked other datasets we have with the same results.
I’ve sent you processed POS files from my RTKlib Demo 5 and Emlid Studio attempts in the email.
I was checking your files, and it does look better with the Beta 9. Is there a way to get the CLI out of it to test myself (Studio crashes on my workstation…like always ).
And using CLI to work on multiple files automatically parallel, emlid studio isn´t my first choise anyway…
I also have the same test at the same place the next week (the second one I was posting)
I will run the receiver with the now latest firmware (non beta) and record ubx and rinex.
If you want I could send you these files next end of week.
Anything else that would help for this and I could test?
@andrew.belov
an update from the field with the latest firmware (non beta)
Files again are somewhat problematic (cycle slips etc.)
Fixes are handled better (compared to the firmware in march from my previous files, but I wouldnt know, if there was any update internally to it)
But there is still an improvement with simply using the demo5 ubx to rinex conversion instead of using the Emlid Rinex directly.
For Q1 it is about 1-4% better. But for q5 (single) it gets drastically better and can be nearly eliminated like an internal RTK solution would be.
@andrew.belov
is there maybe any update?
today we were at the same place - same test.
But today the difference was a little bigger for the Single solutions.
I converted UBX logs in Demo 5, and I can say that the Rinex from Reach unit looks a bit cleaner to me.
Cycle slips at low elevations are a regular thing for the mountains.
However, I see that the data from Rover 002 is much worse than from Rover 001. You can try swapping antennas between two receivers to identify the source of cycle slips at high elevations. It can be the antenna or the bitten cable.
The processing result relies a lot on the applied settings and involved satellites. I’ve listed some recommendations down below for better results in processing:
Excluding noisy satellites. They can affect the solution significantly
Using Combined processing. The combined mode can help to double-check the solution.
Let me know the results of your tests with swapped antennas.
I couldnt tell if the Rinex are cleaner from Reach (wouldnt know enough about it).
All I can say that the resulting POS file is definitely cleaner from the Demo5 Rinex and results in nearly no single solutions compared to the reach rinex (~1000 compared to ~50).
Those singles are often these bows from my previous post that stick out.
For me its not a big problem, just a conversion step more.
I just thought, that maybe there is a way to improve on your system even more as it is right now (and avoid my conversion step in the progress).
I will stay on demo5, cause it is (for my very very niche usecase) the better solution shown in the POS files every day now. Maybe it handles these cycle slips, in combination with my config, a little better…
But if there is an update internally on this topic in the future or close to it, I would really appreciate a update here.
).
You can share it in email as always.
just noticed an altitude values in the data 
