RS2 Ubx to Rinex 3.03 converting issue with EZSurv and RTKConv

Reach RS2 / RS2+ RTK / PPK configuration
1

We’ve been having problems getting fix locations with the RS2. For some reason, the Rinex 3.03 files are incomplete or missing satellites. I urgently needed to post-process something so I used RTKconv to get those Rinex files from the UBX. It worked this time, but I know that conversion through RTKconv may cause to lose data to post-process and I want to avoid that as much as possible.

Through a rep from Onpoz, there have been arguments that RS2 is been having converting issues to RINEX 3.03. A test area was done and these were the findings for BASE and ROVER post-process on 4 GCPs, 20-25 minute base logging and 1-minute collecting rover over each GCP, with CORS site less than 3 kilometers away:

  1. Some missing epochs (data is dropped for unknown reason). When native file is converted to RINEX we can observe the same missing epochs.

Below graph shows missing GPS epochs, but exact same issue is observed on all constellations (missing epochs at same time)

image
image1416×591 23.8 KB

  1. Missing L2 carrier phase for some satellites

The first graph shows L1 carrier phase (the same file as above but the above graph shows L1 code signal, while the following graph shows the carrier phase). As expected, the L1 carrier phase is received for all satellites.

image
image1416×591 22.7 KB

HOWEVER, if we look at the L2 carrier phase (or L2 code) for the same file as above: **L2 is not available for all satellites **.

The below graph is missing 2 GPS satellites G21 and G21.

This issue was observed on GPS and Beidou constellations (Galileo and Glonass seem ok).

image
image1416×591 26.7 KB

  1. RINEX conversion issue: When UBX file is converted to RINEX some L2 data is dropped during conversion

Always using the same file: Native_UBX file shown above was converted to RINEX shown below, in the RINEX file there is less L2 signal than in the equivalent UBX file.

Note: conversion to Rinex made by Emlid (using Emlid RINEX conversion tool).

image
image1416×591 22.8 KB

…end of findings.

We also have an RS+ and we can post-process with Rinex 3.03 with no issues. Hence, awareness rose when we weren’t able to get good results from post-process with the RS2.
We reach the emlid developers if this has been an issue and if it can be solved.

Thanks!

3 Likes
2

true. the same happens to me

3

Same here. I am patient and trust Emlid will solve it in no time

1 Like
5

This is our issue as well. Any input from Emlid?

6

Hi @avelez,

May I ask you to send us your UBX and RINEX files for investigation?

@gujahu, @richie1aubyn, @fking907, which one of these three issues do you encounter? Could you please describe it in more detail?

1 Like
7

Hi @gleb.gira , for my issues with rinex and ubx issues, I would have to state them step by step together with that of the data I logged and used. I plan to contact your technical support team via email. Should do that through support@emlid.com or is there an alternate email address???

8

Hi Richard,

Please contact us on support@emlid.com.

1 Like
9

Hi @gleb.gira
Thanks for following up.

Here is the data used with the issues.

Let us know as soon as you can.
BASE Rinex 21.48.zip (2.3 MB) Base UBX 22.16.zip (3.0 MB) Rover Rinex 21.49.zip (5.9 MB) Rover UBX 22.13.zip (5.3 MB)

1 Like
10

Same issues for us. FLOAT after conversion from UBX to Rinex and post processing (missing epochs, L2 data dropped during conversion, missing L2 carrier phase for some satellites, etc). We’ve had to go back to using our Rs+. Unfortunately we have wasted days trying to get our 2 new RS2 units to work.

11

I am having trouble opening the Rover UBX zip file. WinRar just gets a csv file out, and Windows Explorer can’t open it at all.

12

Does EZsurv support C2L ? I know that NRCAN drops Rinex 3.03 files because of this signal, which they haven’t implemented support for yet.

With Ezsurv or RTKlib ?
In RTKlib it is important to have the “Scan obs types” ticked on for L2/E5b data to be included.

  • G20,G21 and G14 are all IIR generation sats (launched 1997-2004), that, as far as I can see, does not transmit L2C, so maybe that’s the issue ?
  • G32, G27, G24, G10 are all IIF generation, transmitting L2C.
  • G04 is generation IIIA and is undergoing testing.

Sources:

2 Likes
13

Hi Christian

You are right about L2C, but the issue is not L2C, the issue is with L2 carrier phase not being recorded.

When looking at the closest CORS station, G20 and G21 do have L2 carrier phase signal.
Therefore RS2 should also have L2 carrier phase signal for these satellites, but this is not the case.
For these 2 satellites L2C is not present (as per your explanation).

Your observation regarding L2C might be a very good clue to help Emlid fix the recording L2 carrier phase issue! Thanks for pointing it out!

1 Like
14

UBX to rinex conversion issue is only observed when file are converted with RTKLib.

Issue is: when converting RS2 UBX file to rinex using RTKLib, some L2 carrier phase is dropped during the conversion process.

When using EZSurv rinex converter, there is no issue.
A RS2 UBX file and it’s equivalent rinex file, when converted to rinex using EZSurv are similar (L2 carrier phase remains available for all satellites when conversion is made with EZSurv).

That being said, it seems there is an issue with RTKLib converter (issue is only with L2 carrier phase).

PDF file attached shows 3 graphs

  1. L2 carrier phase signal as recorded by RS2 in native UBX format

  2. L2 carrier phase signal for same file, file converted to rinex with EZSurv

  3. L2 carrier phase signal for same file, file converted to rinex with RTKLib (drops of L2 carrier phase are observed on almost all satellites in view)

I have also shared the file (RS2 UBX).
Hope the “Scan obs types” setting can solve that issue. Please advise if you have a solution to that issue.

rinex_conversion.pdf (215.6 KB)
RS2ubxdata.zip (4.7 MB)

15

From converting the attached UBX I get this file: ConvertedWithRTKConvWithScanObsType.zip (3.4 MB)

The header of the file looks like this:
G 8 C1C L1C D1C S1C C2L L2L D2L S2L SYS / # / OBS TYPES
R 8 C1C L1C D1C S1C C2C L2C D2C S2C SYS / # / OBS TYPES
E 8 C1C L1C D1C S1C C7Q L7Q D7Q S7Q SYS / # / OBS TYPES
C 8 C2I L2I D2I S2I C7I L7I D7I S7I SYS / # / OBS TYPES

To my knowledge, the L2L is the carrier phase.

For RTKConv, this is what the manual says on the scan obs types:

For RINEX 3, you had better check
Scan Obs Typesʺ to obtain effective OBS TYPES in input files. In this case, the input files are scanned to
obtain available OBS TYPE list as the first conversion path and then RTKCONV outputs RINEX as the
second conversion path. If ʺScan Obs Typesʺ unchecked, the OBS TYPES in output RINEX files are
determined by the default OBS TYPES set depending on the input format and the ʺSignal Maskʺ
settings described below.

Can you upload a Rinex file converted with EZsurv ?

16

here you go
the file is the UBX file I provided earlier, it was converted to RINEX using EZSurv Rinex converter

EZSurv_RNX.zip (3.5 MB)

17

Can you provide it in Rinex 3.03 ? It is currently in Rinex 2.xx, which makes it difficult to compare in clear-text.

18

Hey there,

At the moment, we’re working on the solution for these issues and I’ll write back once we have any news.

Stephanie, may I ask you to elaborate on this a bit? Do you mean these carriers are dropped during converting or they aren’t recorded at all?

Thank you!

1 Like
19

@tatiana.andreeva, just to make sure, as this is a long thread by now, with multiple issue: the one you are looking into is the break-up issue, not the seemingly missing L2-carrier phase?

20

Hi Christian,

We’re looking into the following issues discussed in this thread:

  1. Missing epochs in raw data recorded by Reach RS2
  2. Missing L2 for some satellites in RINEX files recorded by Reach and in RINEX files converted from UBX in RTKLib

May I ask you to clarify if these carriers are only missing in the RINEX files recorded by Reach and in the RINEX files converted from UBX in RTKConv? Do I understand correctly that when UBX is converted in EZSurv all L2-carriers are presented?

21

That is how I understand it. However, seeing that there is a L2L obs type in the file I myself have converted with RTKconv, it might be more complex?
This is speculation of the worst kind, but maybe it is a combination of wrong conversion settings in RTKconv, and lack of support for the L2L signals in EZsurv (maybe expecting L2X?)?