[IGSSTATION-6841] Re: RINEX 3.02 bug in TRIMBLE NETR9 firmware v5.14
Nacho Romero
nacho at canaryspaceconsulting.co.uk
Thu Oct 27 23:33:18 PDT 2016
Dear Octavian,
on the issue of the extra "#" in the header this was Trimble's answer as
obtained by UNAVCO last month when the issue first came up;
Thanks for passing this along. We are aware of this issue and plan to
have this updated in a future firmware build. To fair, the standard did
correctly list the header record in the text, but then included a typo in
the header example table. When implemented unfortunately this ambiguity
wasn't caught and the '#' was included in the build. Regardless, we're on
it and will have an update in the near future.
Additionally the RINEX WG Chair has already prepared an update to the
latest Rinex 3 format definition document (Rinex 3.03) correcting the
inconsistency in the example table, as the record definition was always
correctly defined. The update to the Rinex 3 standard is under review
for a few more days and will be posted to the IGS website shortly
thereafter.
Sincerely,
Nacho Romero
IGS Infrastructure Committee Chair
_______________________________________________________________
Ignacio (Nacho) Romero
Aerospace Engineer, PhD
CSC Ltd @ ESA/ESOC/OPS-GN
Satellite Navigation Engineer @ ESOC Navigation Support Office
IGS Infrastructure Committee Chair
www.navigation-office.esa.int
www.canaryspaceconsulting.co.uk
_______________________________________________________________
On 27/10/2016 13:10, Octavian Andrei wrote:
> 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 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) 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
>
>
>
> _______________________________________________
> IGSSTATION mailing list
> IGSSTATION at igscb.jpl.nasa.gov
> https://igscb.jpl.nasa.gov/mailman/listinfo/igsstation
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igs.org/pipermail/igsstation/attachments/20161028/31110d1d/attachment.html>
More information about the IGSSTATION
mailing list