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

albrecht57 helmut at albrecht57.de
Sun Jan 19 08:15:52 UTC 2020


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… :-(

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



More information about the teqc mailing list