teqc dos not generate NAV-RINEX-file from ubx-data

Freymueller, Jeffrey freymuel at msu.edu
Mon Jan 20 15:33:04 UTC 2020


In addition, whether the receiver can receive and use the ephemeris information and whether the receiver records it in a data file in a form that teqc can decipher are two different things. You would know very quickly if the receiver could not get any ephemeris information from the satellites, because it would probably stop tracking very soon. So the only problem here is that the way the receiver is recording this in the file is not as expected by teqc. There could be several reasons for that, but I would have to guess, and it really goes beyond my expertise as I don't know anything about the ublox format.

One likely problem based on your warning messages is that the receiver is not reliably recording the GPS week in some navigation data records. The reason I am guessing that is because you are getting navigation records in the file from the year 6075, which would be approximately GPS week 212,000. I don't know whether the ublox receiver (or teqc) uses something like this as an "out of range" value to indicate missing information, or if the receiver is simply writing the navigation record in a format different to the one that ublox provided to Lou Estey at some point in the past.

This is just a guess, but it could be that the receiver records the GPS week at the beginning of the file on Sunday when the week rolls over but does not record it at other times. That might explain why it works on Sundays -- do you always get a host of the warning messages on the Sunday files?

Many receivers record time in the form of two variables (GPS week, seconds in the week). Individual data records from receivers that use this scheme always reliably record the seconds in the week, but don't always record the GPS week number. So there are cases in which teqc has to reconstruct this.

In any case, if you are really curious you could try poking around in the raw binary data records yourself, at least if ublox has documented them, but it doesn't really matter because you don't actually need the RINEX navigation file from this specific receiver as long as you have internet connectivity.

Jeff
--------------
Dr. Jeffrey T. Freymueller
Endowed Chair for Geology of the Solid Earth
Dept. of Earth and Environmental Sciences
Michigan State University
URLs: https://ees.natsci.msu.edu/people/faculty/freymueller-jeffrey/,  https://msu.edu/~freymuel/
 
 
 

-----Original Message-----
From: François Meyer <fmeyer at obs-besancon.fr>
Date: Monday, January 20, 2020 at 3:34 AM
To: albrecht57 <helmut at albrecht57.de>
Cc: "teqc at postal.unavco.org" <teqc at postal.unavco.org>
Subject: Re: teqc dos not generate NAV-RINEX-file from ubx-data

    On Sun, 19 Jan 2020, albrecht57 wrote:
    
    > First of all, let me thank Giovanni,  Francois  and  Marco  for  their
    > proposals.  Grabbing  Ephemeris-data  from  other  sources  my  be   a
    > solution. But it is not really convincing, because the  receiver  also
    > depends on the EPH-data receiving from the satellites… :-(
    
    Maybe I miss your point but these data are receiver-independent, 
    they can be gathered from any receiver, they will always be
    identical. All the measurements performed by the receivers are 
    available in the obs file.
    
    > But let me all of you tell a strande thing happening just now which I
    > did nearly expect: I told you about my first successful try at Jan.
    > 12., which was a sunday. The next efforts at wendesday, thursday,
    > friday and saturday all failed! Today, at Jan. 19 and again sunday,
    > everything worked fine: I did record a short receiver-file and teqc
    > could translate both an OBS- and a NAV-file! I know, a gps-week
    > starts on sundays. Why can receiver-data recorded at sundays be
    > correctly processed by teqc but not data recorded later on during
    > the week? I will try to find the gap between working and not
    > working and keep you informed.
    >
    > Thank you all
    >
    > Helmut
    >
    > Dr. Helmut Albrecht
    > 0170 3221107
    > Vorstandsvorsitzender
    > Luftsportring Aalen e.V.
    > Hinteres Härtle 6
    > Flugplatz Elchingen
    > 73450 Neresheim
    > 07367/7122
    > edpa at lsr-aalen.de
    > https://urldefense.com/v3/__http://www.lsr-aalen.de__;!!HXCxUKc!iIfDoI28_8TrCFtykF1BustCjEE3iwgsja-bejppkx95t3ZuOwmXgXhQtmQedZE$ 
    > Eingetragen im Vereinsregister
    > des Amtsgerichts Ulm VR 500126
    >
    >> Am 17.01.2020 um 23:34 schrieb Giovanni Sella - NOAA Federal <giovanni.sella at noaa.gov>:
    >>
    >> Global IGS archives Kasi cddis ign sopac and many regional data centers bkg ngs euref provide globally  valid brdc files
    >> E.g My organization Provides
    >>
    >> https://urldefense.com/v3/__ftp://geodesy.noaa.gov/cors/rinex/__;!!HXCxUKc!iIfDoI28_8TrCFtykF1BustCjEE3iwgsja-bejppkx95t3ZuOwmXgXhQKD_oAZ0$ 
    >> Either read the readme file or
    >> Go to year
    >> Day of year directory
    >> You will find two files
    >> brdc{ddd}0.{yy}n.gz or g.gz
    >> The first is gps the second glonass
    >> Ddd is day if year yy is two digit year
    >>
    >>
    >> On Fri, Jan 17, 2020 at 16:33 François Meyer <fmeyer at obs-besancon.fr> wrote:
    >> Hi Helmut,
    >>
    >> Some of us have the same problem with an ashtech Z12t that only generates 0 byte
    >> nav files ; (you can check in the archives, the thread "Curing files with
    >> GPS rolllover issues" april 2019, contains some info) ; primary cause
    >> remains unclear, and then unsolved.
    >>
    >> Bottom line : grab a nav file from another receiver (nav files are
    >> generic for a given date they are not specific to a station).
    >>
    >> Its only problematic if you want to process more or less in real time
    >> but do not have easy access to third party nav data. But after 1 day, you
    >> should find nav data easily.
    >>
    >> Best,
    >> --
    >> fm
    >>
    >> On Fri, 17 Jan 2020, albrecht57 wrote:
    >>
    >>> Dear all,
    >>>
    >>> beeing in despair with an inexpectable problem I now dare to ask you. First of all let me tell you, I am not(!) an GNSS-expert but a math-prof at an university of education in Germany. To solve interesting real problems together with my students by the use of math, I decided to compute the GNSS-receiver-position only using pseudeo-ranges and ephemeris. So I bought a Navilock NL-6002U USB containing an ublox-chip and recorded the RAW- and EPH-data to an ubx-file, which I processed with teqc to get a RINEX-OBS and a RINEX-NAV file. In both files I find the data I need to compute the receiver-position. This worked all fine for some years since 2014.
    >>> Now, 2020 Jan. 12., I started another try which worked fine, what means, I could translate the recorded ubx-file into the needed NAV- ond OBS-file!
    >>> Three days later (without altering anything) I tried again, recorded receiver-ubx-data and tried to translate with tecq. In both cases I used the latest version of teqc.
    >>>
    >>> teqc +nav rinex_n.txt data.ubx > rinex_o.txt
    >>>
    >>> But now I only receive the OBS-file, the NAV-File will be generated but with 0 K.
    >>> I tried on different computers under Windows and OSX with the same poor result. teqc produces (amongst others) the following warnings which my be responsible:
    >>>
    >>> Notice ! NAVSTAR GPS SV G10 in 'data2.ubx': ToC 2020 Jan  9 18:00:00.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G12 in 'data2.ubx': ToC 2020 Jan  9 17:59:44.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G14 in 'data2.ubx': ToC 2020 Jan  9 18:00:00.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G15 in 'data2.ubx': ToC 2020 Jan  9 16:00:00.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G17 in 'data2.ubx': ToC 2020 Jan  9 18:00:00.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G19 in 'data2.ubx': ToC 2020 Jan  9 18:00:00.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G24 in 'data2.ubx': ToC 2020 Jan  9 17:59:44.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G25 in 'data2.ubx': ToC 2020 Jan  9 18:00:00.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G29 in 'data2.ubx': ToC 2020 Jan  9 17:59:44.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>> ! Notice ! NAVSTAR GPS SV G32 in 'data2.ubx': ToC 2020 Jan  9 18:00:00.000 not in 2020 Jan 16 16:55:20.000 to 6075 Dec 31 23:59:59.999 by +/- 140 min
    >>>
    >>> I do not understand why teqc assumes the date of Jan 9, because the ubx-file was recorded Jan 16 (the same GPS-week 2088 as Jan 12!)
    >>> On my Windows-PC I found older versions of teqc from 2013, 2015 and 2016. All those versions do the desired job and produce OBS- and NAV-files.
    >>>
    >>> My students use Windows-PC and Mac, so I am dependant on the proper working of the availabe version of teqc.
    >>> Perhaps it's not an issue of teqc, but I always used the same receiver and I record its data always the same way with u-center and I've already tried different versions of u-center.
    >>>
    >>> Having no more ideas, I dare to ask you...
    >>> Thanks in advance for your time and ideas
    >>>
    >>> Best regards
    >>>
    >>> Helmut
    >>>
    >>> Dr. Helmut Albrecht
    >>> 0170 3221107
    >>> Vorstandsvorsitzender
    >>> Luftsportring Aalen e.V.
    >>> Hinteres Härtle 6
    >>> Flugplatz Elchingen
    >>> 73450 Neresheim
    >>> 07367/7122
    >>> edpa at lsr-aalen.de
    >>> https://urldefense.com/v3/__http://www.lsr-aalen.de__;!!HXCxUKc!iIfDoI28_8TrCFtykF1BustCjEE3iwgsja-bejppkx95t3ZuOwmXgXhQtmQedZE$ 
    >>> Eingetragen im Vereinsregister
    >>> des Amtsgerichts Ulm VR 500126
    >>>
    >>>
    >>
    >> --
    >> Dr François Meyer  Tel : (+33) 3 81 66 69 27   Mob : (+33) 6 27 28 56 83
    >> Dir. exécutif plateforme OscIMP
    >> Dir. LNE-LTFB, laboratoire temps-fréquence associé au LNE
    >> Institut UTINAM / OSU Theta
    >> 41b avenue de l'Observatoire, BP1615
    >> 25010 Besancon cedex - FRANCE
    >> ** Universite de Franche-Comte ** CNRS UMR 6213 ** UMS 3245
    >> --
    >> Giovanni Sella
    >> Information System Security Officer (ISSO)
    >> NOAA-National Geodetic Survey
    >> 001-240-533-9479
    >
    >
    
    -- 
    Dr François Meyer  Tel : (+33) 3 81 66 69 27   Mob : (+33) 6 27 28 56 83
    Dir. exécutif plateforme OscIMP
    Dir. LNE-LTFB, laboratoire temps-fréquence associé au LNE
    Institut UTINAM / OSU Theta
    41b avenue de l'Observatoire, BP1615
    25010 Besancon cedex - FRANCE
    ** Universite de Franche-Comte ** CNRS UMR 6213 ** UMS 3245



More information about the teqc mailing list