[time-nuts] uBlox F9T testing - best settings?

[Michael Wouters]

Hello Anders,
Yes, we used  TAPR TICCs do the testing. It’s a very economical solution
for testing multiple receivers in parallel.

The OpenTTP software mktimetx applies sawtooth corrections to the TIC
measurements, as you guessed. The corrected TIC measurements are combined
with the raw GNSS pseudo ranges, and then this is what goes into the output
RINEX and what is used for CGGTTS generation.

One complication is that the raw pseudo ranges have ms ambiguities in them.
  But mktimetx fixes that.

I’ll put the paper on the openttp website.
Unfortunately, it appears that it will otherwise be behind a paywall.

Cheers
Michael





On Mon, 23 Sep 2019 at 12:00 am, Anders Wallin <anders.e.e.wallin at gmail.com>
wrote:

> Hi Michael, thanks for the reminder about your slides!
> Your page 4 has the two setups. I think you are right in that the F9T
> doesn't seem to take an external receiver clock (even if working with the
> bare part, not the RCB-board).
> (FWIW, AFAIK the not-so-low-cost septentrios use the left external receiver
> clock scheme, while Dicom GTRs use the right - both in the 15k cost range)
>
> Did you use an external TIC (like the TICC?) - to get lower than the 8ns
> granularity of the TIMEMARK?
>
> If I understand CGGTTS the TIC and sawtooth-correction are used to provide
> one single time-offset value into the CGGTTS file, for each 780s=13 min
> satellite track observed?
> https://tycho.usno.navy.mil/cggtts.html
> is that correct?
> Can the same TIC-based sawtooth correction work for 30s RINEX data instead?
> If gpsd can produce dual-frequency RINEX from the F9T, then the new
> (software)part needed is the sawtooth-correction at 30s intervals applied
> to the raw RINEX from the F9T.
> https://gpsd.gitlab.io/gpsd/ppp-howto.html
>
> Anders
>
>
>
> On Sun, Sep 22, 2019 at 3:00 AM Michael Wouters <michaeljwouters at gmail.com
> >
> wrote:
>
> > Hello Anders,
> >
> > We did some work on single-frequency time-transfer with the F9P earlier
> > this year which we presented at IFCS-EFTF in April.
> > http://www.openttp.org/downloads/Multi-GNSS_IFCS-EFTF_2019.pdf
> > There's a paper too, which I should upload.
> > In short, the F9P is very suitable for code-based time-transfer, and we
> > will be using it , or the F9T, in the next iteration of our time-transfer
> > system.
> >
> > But, I don't see how you can feed an external 10 MHz and 1 pps to the
> F9T.
> > There don't appear to be any inputs for this on the chip. The TIMEMARK
> > inputs only seem to be useable for measurements. Have I missed something?
> >
> > Regards
> > Michael
> >
> > > Further down the road, if the F9T really can do dual-frequency
> > > observations, and either the receiver clock 1PPS measured (TICC?)
> against
> > > an external 1PPS, or the entire receiver clocked from external
> 10M/1PPS -
> > > and dual-frequency RINEX generated from this - then there seems to be
> an
> > > obvious opportunity for making a low-cost dual-frequency time-transfer
> > > setup? Or am I missing something?
> > > PPP with F9T seems to be possible:
> > > https://gpsd.gitlab.io/gpsd/ppp-howto.html
> >
> >
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>