[teqc] problem generating rinex file

Lou Estey lou at unavco.org
Wed Jul 18 09:55:41 MDT 2018


dear Leonardo,

Thank you for sending me the .t02 file.  Converting to .tgd with runpkr00 ver. 5.40,
I see that same as you are seeing.  Upon digging into the .tgd file at a binary level,
here's what I can tell you:

There are several places in the .tgd where a normal .tgd record ends and the next
byte indicates that the next .tgd record is going to start, i.e. there is the
expected synchronization byte (what Trimble calls a 'preamble' byte).  However, the
the byte that would represent the record ID (soon after the synchronization byte)
has a value that is far outside of the expected range of accepted IDs.  (Obviously
at this point the .tgd file is not normal.)  So teqc says, ok, start looking for
the next synchronization byte -- which it finds. Then the byte where the record ID
would occur in the next potential record has a value in the range of valid record IDs
and teqc tries to interpret the next block of bytes as a valid record -- which is fine
logic when the next block of bytes really is a valid record -- but the problem
in this case is that the apparent valid record ID just a random happenstance and
this the next bunch of bytes isn't really a valid record.  At this point teqc
gets really messed up.  It's worth mentioning that Trimble's .dat/.tgd format is
composed of records that don't have a checksum or CRC per record, so one has to
resort to somewhat heuristic methods to determine if a valid record has been found.

Trimble's software seems to have methods in place that get past these places in the
.tgd that aren't quite right, which one would hope since they know more about their
formats that I ever will. :)

In short, I don't immediately see anything I can do to improve teqc's parsing of
these kinds of rare, problematic .dat/.tgd files.

cheers,
--lou

On 12-Jul-18 09:10 AM, Leonardo Alexander Cardona wrote:
> Dear Lou,
> 
> I generate the tdg file without errors:
> 
> runpkr00 -dm -f -g -v -k2048 -tT02 CCYO201807110800Y.T02
> runpkr00:  Version 5.40 (Linux)
> runpkr00:  T01Lib: 8.63
> runpkr00:  DAT: CCYO201807110800Y.tg!
> runpkr00:  MES: CCYO201807110800Y.mes
> runpkr00:  Input file: CCYO201807110800Y.T02
> runpkr00:  records: 87970
> runpkr00:  status : 0
> 
> 
> To check the T02 file I used the Web GUI of the receiver to convert
>   T02 file to RINEX. And the RINEX file was generated well.
> 
>        first epoch    last epoch    hrs   dt  #expt  #have   %   mp1   mp2 o/slps
> SUM 18  7 11 08:00 18  7 11 08:59 1.000   1     -  104047  -   0.30  0.32    269
> 
> Cheers,
> 
> Leonardo Alexander Cardona
> **
> 	
> SERVICIO GEOLÓGICO COLOMBIANO	|		|	
> Diag. 53 N.° 34-53,
> Bogotá, Cundinamarca,
> +(571) 2200 200 <tel:%28571%29+2200+200> Ext. 2313		f/ServicioGeologicoColombiano 
> <https://www.facebook.com/pages/Servicio-Geol%C3%B3gico-Colombiano/344228072328140>
> t at sgcol <https://twitter.com/sgcol>
> yyoutube <https://www.youtube.com/channel/UCkwTkQ5dmO16fPPnhE3SrMg>
> 
> 
> On Thu, Jul 12, 2018 at 9:19 AM, Lou Estey <lou at unavco.org <mailto:lou at unavco.org>> wrote:
> 
>     dear Leonardo,
> 
>     You could try adding '-f' to the runpkr00 command:
> 
>     runpkr00 -f -k2048 -g -dv -tT02 CCYO201807110800Y.T02
> 
>     (See https://postal.unavco.org/pipermail/teqc/2017/002305.html <https://postal.unavco.org/pipermail/teqc/2017/002305.html>)
> 
>     But quite honestly given the date of the notice shown here:
> 
>     ! Notice ! 2208 Jun 12 00:00:00.000: poss. incr. of sampling int. OR data gap of 1698310395.000 seconds (min. dt found= 1.000 s)
> 
>     and the messages that follow, I think it's quite possible that
>     the .t02 file is corrupted in some way.  (Plus there are possible
>     warning signs given that teqc is reporting records it knows nothing
>     about even before that, although Trimble might have defined new records
>     23, 38 and 39 and released these in firmware without informing us.)
> 
>     Have you gotten good (e.g. normal) .tgd converted from this particular
>     NetT9 with firmware 5.14?
> 
>     --lou
> 
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     Louis H. Estey, Ph.D.              office:  [+001] 303-381-7456
>     UNAVCO, 6350 Nautilus Drive <https://maps.google.com/?q=6350+Nautilus+Drive&entry=gmail&source=g>           FAX:  [+001] 303-381-7451
>     Boulder, CO  80301-5554            e-mail:  lou unavco.org <http://unavco.org>
> 
>     "If the universe is the answer, what is the question?"
>                                                     -- Leon Lederman
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
>     On 12-Jul-18 08:04 AM, Leonardo Alexander Cardona wrote:
> 
>         Dear all,
> 
>         I have a T02 file generate by NetR9 Receiver with firmware 5.14 that when i try to convert to RINEX format using teqc I get a next
>         error:
> 
>         runpkr00 -k2048 -g -dv -tT02 CCYO201807110800Y.T02
>         teqc -tr d +nav CCYO1920.18N CCYO201807110800Y.tgd > CCYO1920.18O
> 
>         ! Notice ! no routine for Trimble .dat record 23 in file 'CCYO201807110800Y.tgd' ... skipping
>         ! Notice ! 2018 Jul 11 08:31:20.000: poss. incr. of sampling int. OR data gap of 6.000 seconds (min. dt found= 1.000 s)
>         ! Notice ! no routine for Trimble .dat record 23 in file 'CCYO201807110800Y.tgd' ... skipping
>         ! Notice ! no routine for Trimble .dat record 39 in file 'CCYO201807110800Y.tgd' ... skipping
>         ! Notice ! 2018 Jul 11 08:35:17.000: poss. incr. of sampling int. OR data gap of 6.000 seconds (min. dt found= 1.000 s)
>         ! Notice ! 2208 Jun 12 00:00:00.000: poss. incr. of sampling int. OR data gap of 1698310395.000 seconds (min. dt found= 1.000 s)
>         ? Error ? 'CCYO201807110800Y.tgd' rejection due to SV count @ 2208 Jun 12 00:00:00.000 appears wrong: total= 177 max= 44 (use option
>         '-max_rx_SVs 177'?)
>         ! Notice ! 2018 Jul 11 08:38:43.000: poss. incr. of sampling int. OR data gap of 14.000 seconds (min. dt found= 1.000 s)
>         ! Notice ! 2018 Jul 11 08:40:04.000: poss. incr. of sampling int. OR data gap of 6.000 seconds (min. dt found= 1.000 s)
>         ! Notice ! 2609 Nov 26 00:00:00.000: poss. incr. of sampling int. OR data gap of 1482153998.000 seconds (min. dt found= 1.000 s)
>         .dat 27/0x57-6: unknown SV type= 57
>         ! Notice ! secondary antenna data being skipped ...
>         .dat 27/0x57-6: unknown SV type= 40
>         ! Warning ! wrong order of OBS epochs found in 'CCYO201807110800Y.tgd': last = 2609 Nov 26 00:00:00.000, curr = 2018 Jul 11 08:40:26.000
>         ! Notice ! decompose_Trimble_28_55h(): unknown Trimble .dat record 28 subtype 231 in file 'CCYO201807110800Y.tgd' ... skipping
>         ! Notice ! no routine for Trimble .dat record 38 in file 'CCYO201807110800Y.tgd' ... skipping
>         ! Notice ! no routine for Trimble .dat record 39 in file 'CCYO201807110800Y.tgd' ... skipping
> 
>         The RINEX file is generated but its quality check report is not good.
> 
>         grep -B1 SUM CCYO1920.18S
>                 first epoch    last epoch    hrs   dt  #expt  #have   %   mp1   mp2 o/slps
>         SUM 18  7 11 08:00 09 11 26 00:00 .0000 .00     -       0  -     -     -       0
> 
>         At the end of the rinex file some empty lines were generated which were removed with the last observation and the quality report was
>         generated again:
> 
>                 first epoch    last epoch    hrs   dt  #expt  #have   %   mp1   mp2 o/slps
>         SUM 18  7 11 08:00 18  7 11 08:40 .6642   1  24002  23716  99  0.27  0.29  23716
> 
>         The RINEX file is incomplete because it's a full hour of tracking.
> 
>         Does anyone have any idea how to fix my data and generate a good RINEX file?
> 
>         In the following link you can download the file T02 used: https://drive.google.com/open?id=1I7Q0KFMUSSe5ZrMgBC7kg85EEfh-50GP
>         <https://drive.google.com/open?id=1I7Q0KFMUSSe5ZrMgBC7kg85EEfh-50GP>
> 
>         I am grateful for the support provided,
> 
>         Cheers,
>         Leonardo Alexander Cardona
>         **
> 
>         SERVICIO GEOLÓGICO COLOMBIANO   |               |
>         Diag. 53 N.° 34-53,
>         Bogotá, Cundinamarca,
>         +(571) 2200 200 <tel:%28571%29+2200+200> Ext. 2313
>                  f/ServicioGeologicoColombiano <https://www.facebook.com/pages/Servicio-Geol%C3%B3gico-Colombiano/344228072328140
>         <https://www.facebook.com/pages/Servicio-Geol%C3%B3gico-Colombiano/344228072328140>>
>         t at sgcol <https://twitter.com/sgcol>
>         yyoutube <https://www.youtube.com/channel/UCkwTkQ5dmO16fPPnhE3SrMg <https://www.youtube.com/channel/UCkwTkQ5dmO16fPPnhE3SrMg>>


More information about the teqc mailing list