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

François Meyer fmeyer at obs-besancon.fr
Mon Jan 20 08:34:44 UTC 2020


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
> www.lsr-aalen.de
> 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
>>
>> ftp://geodesy.noaa.gov/cors/rinex/
>> 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
>>> www.lsr-aalen.de
>>> 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