Galileo week rollover issue in RINEX nav

[michael.pattinson@…]

Hi.
We have seen an issue with Galileo week rollover when we use BNC (2.12.10) to log the RTCM v3 straight to RINEX.
We are getting message types 1045 and 1046 for Galileo, and for both we see in the RINEX files written by BNC that some messages received just after the week rollover (i.e. early on Sunday morning) have week number increment by 1 but the toe is still a high number (e.g. 604000) and the toc jumps forward by 1 week. I attach an example file when you can see this for E01, E05, E15 and others.
From what I can tell, the receiver manufacturer is simply putting the week number of the message (i.e. when it was received) in the WN field in 1045 and 1046 and expecting that the user of the RTCM data will modify this as necessary (allowing for rollover) to derive the reference week number of the toe and toc, but this does not seem to be happening.
Can you check how you are using the WN field in the 1045 and 1046 messages and confirm the correct interpretation of the RTCM standards?
Thank you.

[stuerze]

Dear Michael,

Thank you very much for your hint. Bur I have difficulties to verify your description with respect to the attached file. The attached file contains navigation data sets for Galileo from 15th of December together with data sets from 21th of december but no one from 22th of December. Are you shure that file is written by BNC? The header line doesn't contain a BNC version etry. Furthermore, BNC write RINEX version 3.04 files since version 2.12.7.

I have looked into a RINEX file written from BNC: The file BRDC00WRD_S_20193560000_01D_MN.rnx.gz you can find in our archive at IGS/BRDC/2019/356/.

Within this file I can find for example

BNC 2.12.10         rtproc              20191222 235009 UTC PGM / RUN BY / DATE

and the following entry for E01:

E01 2019 12 21 23 50 00-7.572927861474e-04-7.929656931083e-12 0.000000000000e+00
     1.110000000000e+02 1.413750000000e+02 2.991910339361e-09 2.004742453959e+00
     6.657093763351e-06 1.836252631620e-04 4.075467586517e-06 5.440622339249e+03
     6.042000000000e+05 6.891787052155e-08-2.730763247776e+00 6.891787052155e-08
     9.853341415449e-01 2.637187500000e+02-7.506663040590e-01-5.773811931014e-09
     2.482246252663e-10 5.170000000000e+02 2.084000000000e+03 0.000000000000e+00
     3.120000000000e+00 0.000000000000e+00-1.862645149231e-09-2.095475792885e-09
     9.999000000000e+08 

An entry for E01 for the next day (Sunday) is as follows:

E01 2019 12 22 00 00 00-7.572976173833e-04-7.929656931083e-12 0.000000000000e+00
     0.000000000000e+00 1.412187500000e+02 2.994410443500e-09 2.079109313740e+00
     6.642192602158e-06 1.836055889726e-04 4.090368747711e-06 5.440622377396e+03
     0.000000000000e+00 6.891787052155e-08-2.851181968476e+00 6.705522537231e-08
     9.853342907625e-01 2.636562500000e+02-7.506482384836e-01-5.773454773280e-09
     2.475103097979e-10 5.170000000000e+02 2.085000000000e+03 0.000000000000e+00
     3.120000000000e+00 0.000000000000e+00-1.862645149231e-09-2.095475792885e-09
     9.999000000000e+08 

From my point of view it looks OK. The week is increased by one and the TOE in seconds of Galileo week is starting with zero. Isn't it?

Best regards, Andrea.

[michael.pattinson@…]

Hi Andrea,

Sorry you are right - those were not files generated by BNC. For the files I sent we had logged data raw RTCM data with SNIP caster and then converted to RINEX with RTKlib. I am confusing myself! But the issue I am trying to get to the bottom is how to correctly interpret the Galileo (and BeiDou) week number information in RTCM messages because we see strange values in RINEX files created from RTCM and I am not sure if the problem lies with the receiver manufacturer putting the wrong value in the RTCM messages or with 'user' software in decoding those RTCM messages and converting to RINEX. I will try to explain better.

In the example data files I sent you, all the data was logged on 15th December. We had been using SNIP caster to log real-time stream and then we had two ways to create RINEX: one was to convert the raw RTCM log files using RTKlib and the other was to connect to the SNIP caster with BNC and use BNC to log directly to RINEX.

As the data was logged in real time we would expect that the toc and toe information for all satellites should have been from late on 14th or early on 15th December, and in most cases that is correct. However in the file I sent you we see that there are some Galileo satellites apparently with toc and toe from 21st December, i.e. one week in the future, but this is incorrect - the toc and toe should have been for 14th December. What seems to have happened is that the RTCM messages for Galileo nav include a WN and the receiver uses this to send the week number when it received the message, rather than the week number of the toe/toc. So when the week rolls over, any Galileo messages with clock and orbit models that have toe and toc at the end of the previous week are shifted on by one week when RTKlib writes them to RINEX. Does that make sense?

It is true when I look at the files written directly by BNC that is not normally the case, so I thought BNC must be either ignoring those messages or adjusting the Galileo WN in the RTCM in order to get the correct toc and toe. Do you know if that is the case? However, I also see in the BRDC file you pointed out in IGS/BRDC/2019/356/ that, although the Galileo nav appears fine, some of the BeiDou navigation messages, e.g. C06, C23, C24 have toc values that are one week in the future (28/12 instead of 21/12), which seems odd as well.

So I was wondering if you could confirm how you are interpreting the WN information in Galileo and BeiDou RTCM nav messages and how you use this to set toc and toe values when you write to RINEX.

Many thanks.

Best regards,

Michael

[stuerze]

Dear Michael,

I can speak for BNC only. BNC has some checks regarding the age of navigation data included:

https://software.rtcm-ntrip.org/export/HEAD/ntrip/branches/BNC_2.12/src/bnchelp.html#upeph

So, future data sets should be excluded. If it doesn't work, a raw data example (https://software.rtcm-ntrip.org/export/HEAD/ntrip/branches/BNC_2.12/src/bnchelp.html#rawout) would really help me with respect to an error analysis.

With respect to your RTCM3 and RINEX questions I recommend to study the respective methods within the source code:
https://software.rtcm-ntrip.org/browser/ntrip/branches/BNC_2.12/src/RTCM3/RTCM3Decoder.cpp

bool RTCM3Decoder::DecodeGalileoEphemeris(unsigned char* data, int size) {..}

https://software.rtcm-ntrip.org/browser/ntrip/branches/BNC_2.12/src/ephemeris.cpp

QString t_ephGal::toString(double version) const {..}

The same can be found for BDS within the respective files.

Best regards, Andrea