Decoding MT1046

[Fr0sT-Brutal]

Currently 1045 and 1046 are decoded identically but according to BNC source, MT1046 is intended for I/NAV Galileo ephemerides and has additional fields: tgd[1] and two flags E5b DVS and E5b HS that are added to SV_Health field. Reference: \BNC\Src\src\RTCM3\RTCM3Decoder.cpp

[DavidKelleySCSC]

All: Just a small word of caution. Technically that is still a draft message. According to my notes from last months' RTCM SC 194 meeting on the message status which was provided by the document editor - the 1044 one is stable (approved May 2013 for use with F-Nav GALILEO Ephemeris) but the 1046 one (intended for use with I-Nav GALILEO Ephemeris) is still in development, pending some better definitions. So those additional fields are still subject to further changes before formal adoption. As a design goal, it tends to follow the Galileo OS SIS ICD (Nov. 2015) when it can. The 13 bits that were added also rearranged a few details, so 1045 is not "1044+plus more" in the style used by older RTCM messages. I can not speak regarding the details of the BNC code.

[And 1042, for the BDS Ephemeris, was also approved in May 2013, and 1044 for QZSS Ephemeris in Sept. of that same year. While 1043 has been assigned for SBAS Ephemeris but has not been worked on much at this time.]

[tomojitakasu]

Thanks. In my understandings, MT1046 is still a draft. So the code will be fixed after the final RTCM issued. For BDS ephemeris, currently MT63 is assigned as an experimental message, which is supported since 2.4.3 b16. Just tentative MT and format MT1047 is also used but these will be deleted after the RTCM finalized.

[DavidKelleySCSC]

tomojitakasu:
Except that for "sandbox-experimental" messages (anything in 0~100
range) the final message structure developed will simply be re
assigned to a final permanent number (hence your investment in the
coder logic is preserved - not deleted), that is my understanding as
well. It likely that any evolved message details will be part of the
normal committee only drafts.  The value 1046 was assigned before
the committee adopted the "prove it in the sandbox first" rules
(which I will take a tiny bit of credit for, having used this method
in IEEE and SAE stds).  I believe the plan for these older values
(ie 1046) is the keep the assigned number under a "grandfathered"
mindset but to use the sandbox numbering system hence forth.  By
with a committee is is wise not to bet on outcomes. The sandbox
range, by definition is reused therefore no assignment there is
permanent.  This will prevent some prior issues SC104 has had with
RTCM 2.x where selected messages never made it to "recommended"
level for various reasons, and some other issues where other parties
elected to create conflicting numbers of their own.
On 10/7/2016 3:21 PM, Tomoji Takasu
  wrote:

  Thanks.
    In my understandings, MT1046 is still a draft. So the code will
    be fixed after the final RTCM issued. For BDS ephemeris,
    currently MT63 is assigned as an experimental message, which is
    supported since 2.4.3 b16. Just tentative MT and format MT1047
    is also used but these will be deleted after the RTCM finalized.

  {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tomojitakasu/RTKLIB","title":"tomojitakasu/RTKLIB","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/tomojitakasu/RTKLIB"}},"updates":{"snippets":[{"icon":"PERSON","message":"@tomojitakasu in #233: Thanks.\r\nIn my understandings, MT1046 is still a draft. So the code will be fixed after the final RTCM issued.  For BDS ephemeris, currently MT63 is assigned as an experimental message, which is supported since 2.4.3 b16. Just tentative MT and format MT1047 is also used but these will be deleted after the RTCM finalized."}],"action":{"name":"View Issue","url":"https://github.com/tomojitakasu/RTKLIB/issues/233#issuecomment-252375010"}}}

Regards, David Kelley

[nunojpg]

Hi,

I have confirmed that there are still problems with RTCM1045 and 1046 at least in regard to health decoding. I'm testing with NTRIP:products.igs-ip.net/RTCM3EPH.

RTKLIB decodes HEALTH for most Galileo SVs as 38. When decoding from uBlox, the same SVs have the correct healthy value (00).

Naturally some Galileo SVs are unhealthy like E14 and E18 (the ones in orbit "4") which RTKLIB decodes health as 1C7.

Thanks, Nuno

[nunojpg]

To make a summary about Galileo free signals health status words:

F/NAV (E5a-I / RTCM1045)

Represented with 3 bits in RTCM1045 ordered as:

2 bit E5aHS Signal Health Status
1 bit E5aDVS    Data Validity Status

I/NAV (E1B and E5b-I / RTCM1046)

Represented with 6 bits in RTCM1046 ordered as:

2 bit E5bHS Signal Health Status
1 bit E5bDVS    Data Validity Status
2 bit E1-BHS    Signal Health Status
1 bit E1-BDVS   Data Validity Status

Meaning:

Data Validity Status 0 Navigation data valid 1 Working without guarantee

Signal Health Status 0 Signal OK 1 Signal out of service 2 Signal will be out of service 3 Signal Component currently in Test

Looking at https://github.com/tomojitakasu/RTKLIB/blob/rtklib_2.4.3/src/rtcm3.c, type 1045 looks to be properly decoding the 3 bits:

 e5a_hs    =getbitu(rtcm->buff,i, 2);              i+= 2; /* OSHS */
 e5a_dvs   =getbitu(rtcm->buff,i, 1);              i+= 1; /* OSDVS */

But RTCM1046 have the same logic, so is not updating the e1-b and e5b at all!

[tomojitakasu]

Again, MT1045 and MT1046 are still drafts. They are not finalized in my understandings. Current RTKLIB implementation is based on early drafts. I'm not sure the modification after that. So formal fixing will be done after the final document issued. Until that, you can freely modify them by yourself.

[nunojpg]

Dear Dr. @tomojitakasu,

To me it looks that MT1045 and MT1046 have been stable. Could you check if they are final or not? In any case the problem is not that the draft of 1046 have changed, is that it was wrong from the beggining.

Can I provide a pull request to at least fix what was always wrong?

Thanks

[tomojitakasu]

MT1045 and MT1046 are formally incorporated in RTCM 3.3. They are supported in RTKLIB 2.4.2 p13.

[nunojpg]

@Fr0sT-Brutal please check and close the issue if appropriate.

[Fr0sT-Brutal]

Change seems correct!