UBX conversion problem/testing/optimization?

Hi there

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)

left is Emlid Rinex, Right is ubx to rinex

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.


Are you using UBX or Rinex as a source for your conversions?

in this testing I use the original Rinex from the receiver (left picture) and the original UBX from the receiver (right picture) for conversion

and then after that I rtkpost them each and get different result with the same config

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.

As I understand it: Isn´t the Rinex file from the Receiver also just a convbin file (it says so in the header).

And for rtkpost I always would need a Rinex.
So I get why UBX should have more info - but why should it after convbin (either Emlid onboard or demo5)?

they somewhat similar but stuff is missing or additional here and there (emlid rinex misses an obs type, UBX rinex has more other lines)

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

Hi @goamberg,

Thanks for calling our attention to this theme!

It’s time to conduct a test with the described setup. I’ll get back with an update shortly.

Can you also share your files to support@emlid.com?


Hi @andrew.belov

Files sent via mail

Thanks! Received.

Maybe any news on this one?
We would go testing again in the upcoming weeks and would be nice to maybe include some of your findings.

Hi Matthias,

Thanks for your patience!

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.

Hi Andrew

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 :wink:).
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?



Naah, we have only GUI version available for the Emlid Studio and don’t have plans for updating the CLI of our RTKlib version.

By the way, does the Emlid Studio crash during PPK? Do you have any crash reports to share?

Sure, I’m always glad to take a look at a dataset from the field :slight_smile: You can share it in email as always.

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.

Will send some files today via mail

Hi @goamberg,

I received the files, thanks!

I’m checking the data now and have some questions about it:

  • I see lots of cycle slips in the rover’s data. Can you share some photos of your setup? It looks like working motors jam the signal.
  • There are two data sets from the rover. Am I correct that these are two rovers installed on the same vehicle?

I am quite sure there is no motor involved… :wink: :grinning:

The 2 Rovers are 2 seperate athletes on the same track.
so 2 different sets of data


Unexpected :smile: just noticed an altitude values in the data :slight_smile:

Great that the ski season has started in some regions!

1 Like

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.

In the problematic cycle slip areas we got these bows.
UBX to Rinex was able to catch this and pos file was really clean

Hi @goamberg,

Thanks for your patience!

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.

1 Like

thanks for the reply

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.