[IGSSTATION-6839] RINEX 3.02 bug in TRIMBLE NETR9 firmware v5.14

Octavian Andrei octavian.a at chula.ac.th
Thu Oct 27 05:10:09 PDT 2016


Dear all,

I would like to bring into your attention the following bugs we discovered after we updated the receiver firmware at our CUUT IGS multi-GNSS station. I believe the information will contribute to higher consistency in the IGS data archive.

The receiver internal translator to RINEX 3.02 in firmware v5.14 for Trimble NetR9 receivers introduces two new bugs.

1) 
The first bug is an inconsistency with RINEX 3.02 standard. Page A10 / A14 at https://igscb.jpl.nasa.gov/igscb/data/format/rinex302.pdf <https://igscb.jpl.nasa.gov/igscb/data/format/rinex302.pdf> defines the RINEX header label 'GLONASS COD/PHS/BIS’. However, the receiver internal translator to RINEX outputs an extra hashtag instead of a white space.

> GLONASS COD/PHS/BIS#


As a result, other data management or processing software that rigorously implements the standard fail to recognise the RINEX 3.02 generated observation file as valid file.

I have done a quick check on all long name files on 2016-290. There are 30 stations reporting firmware 5.14. Twelve stations report their RINEX files with the above bug. I give the list below:

> ANMG00MYS_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> BRUN00BRN_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> CMUM00THA_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> CPNM00THA_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> CUT000AUS_R_20162900000_01D_30S_MO.crx.gz                                                             GLONASS COD/PHS/BIS#
> DAE200KOR_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> DLTV00VNM_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> EUSM00MYS_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> JCTW00ZAF_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> JNAV00VNM_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> NCKU00TWN_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#
> PFRR00USA_R_20162900000_01D_30S_MO.crx.gz  C1C    0.000 C1P    0.000 C2C    0.000 C2P    0.000        GLONASS COD/PHS/BIS#


However, only CUT0 reports firmware NetR9 5.14 and thus gets this bug from the receiver internal translator.

> CUT000AUS_R_20162900000_01D_30S_MO.crx.gz NetR9 5.14          N Nadarajah         20161016 000000 UTC PGM / RUN BY / DATE
> CUT000AUS_R_20162900000_01D_30S_MO.crx.gz 5023K67889          TRIMBLE NETR9       5.14                REC # / TYPE / VERS


The other stations seem to get this bug from JAXA’s dconv program (or preserve the above bug if the program does not apply rigorous checks on the RINEX format):

> ANMG00MYS_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004302 UTC PGM / RUN BY / DATE
> BRUN00BRN_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004354 UTC PGM / RUN BY / DATE
> CMUM00THA_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004518 UTC PGM / RUN BY / DATE
> CPNM00THA_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004531 UTC PGM / RUN BY / DATE
> DAE200KOR_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004406 UTC PGM / RUN BY / DATE
> DLTV00VNM_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004554 UTC PGM / RUN BY / DATE
> EUSM00MYS_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004547 UTC PGM / RUN BY / DATE
> JCTW00ZAF_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004619 UTC PGM / RUN BY / DATE
> JNAV00VNM_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004339 UTC PGM / RUN BY / DATE
> NCKU00TWN_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004450 UTC PGM / RUN BY / DATE
> PFRR00USA_R_20162900000_01D_30S_MO.crx.gz dconv               JAXA                20161017 004506 UTC PGM / RUN BY / DATE



2)
In addition, the v5.14 receiver internal translator to RINEX also does not fix the IGS naming convention (https://igscb.jpl.nasa.gov/igscb/station/general/rcvr_ant.tab <https://igscb.jpl.nasa.gov/igscb/station/general/rcvr_ant.tab>) for the receiver type name that is still reported uncapitalised (i.e., Trimble NetR9 instead of TRIMBLE NETR9). 

Again at a check on the same files, there are 23 stations reporting correct 'TRIMBLE NETR9'. However, eight stations (seven with 5.14) report non-IGS name:

> AUCK00NZL_R_20162900000_01D_30S_MO.crx.gz 5035K69859          Trimble NetR9       5.14                REC # / TYPE / VERS
> CHTI00NZL_R_20162900000_01D_30S_MO.crx.gz 5049K72269          Trimble NetR9       5.14                REC # / TYPE / VERS
> DUND00NZL_R_20162900000_01D_30S_MO.crx.gz 5444R50040          Trimble NetR9       5.14                REC # / TYPE / VERS
> MQZG00NZL_R_20162900000_01D_30S_MO.crx.gz 5049K72153          Trimble NetR9       5.14                REC # / TYPE / VERS
> SCTB00ATA_R_20162900000_01D_30S_MO.crx.gz 5034K69673          Trimble NetR9       5.14                REC # / TYPE / VERS
> SPTU00BRA_R_20162900000_01D_30S_MO.crx.gz 5239K52833          Trimble NetR9       4.85                REC # / TYPE / VERS
> WARK00NZL_R_20162900000_01D_30S_MO.crx.gz 5522R50052          Trimble NetR9       5.14                REC # / TYPE / VERS
> WGTN00NZL_R_20162900000_01D_30S_MO.crx.gz 5034K69714          Trimble NetR9       5.14                REC # / TYPE / VERS


As a result, some processing software may not recognise correctly the receiver type, once again depending on how strict are the internal checks for the input files.

Hopefully, the responsible persons to correct these bugs and inconsistencies will find the information beneficial.

Best regards,
Octavian

---
Dr. Octavian Andrei, lecturer
Chulalongkorn University
Faculty of Engineering
Department of Survey Engineering

Phayathai Road, Pathumwan,
Bangkok 10330
THAILAND

tel. +66 2 218 6651-307
m. 09 2267 1421
Skype: octavianandrei.work
Twitter: @coandrei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igs.org/pipermail/igsstation/attachments/20161027/57d4fabc/attachment.html>


More information about the IGSSTATION mailing list