Ublox F9P PPS output measurements

[texaspyro]

I got in a Ublox F9P multi-band receiver from Sparkfun.   Lately I've been testing the 1PPS output.   This data is from the F9P tracking GPS and GLONASS L1 and L2.  The PPS was measured by a TAPR TICC clocked by an HP-5071A.   BTW, processing the raw F9P measurement data with CSRS-PPP produces  lat/lon/alt location error ellipses in the 5/10/20mm range with my horrible antenna location.  Bob got 3/6/12 mm.

 The GREEN plot is the PPS output from the F9P.  The ORANGE plot is that value adjusted by the sawtooth correction.   The BLUE line is the PPS ADEV plot.  It is interesting that the reported F9P sawtooth values don't average to 0.000 nsec.

#
#   Device: Ublox F9P receiver
#
#   Unit type:     TAPR TICC
#   Serial number:
#   Firmware ver: 
#   Board ver:     
#   EEPROM ver:    0
#   Mode:          Timestamp
#   Ref clock:     HP-5071A
#
#
#   Unit type:     Ublox F9 receiver
#   SW:            EXT CORE 1.00 (eba0dc
#   HW:            00190000
#   ROM 1:         ROM BASE 0x118B2060
#   ROM 2:         FWVER=HPG 1.10
#   ROM 3:         PROTVER=27.10
#   ROM 4:         MOD=ZED-F9P
#   ROM 5:         GPS;GLO;GAL;BDS
#   ROM 6:         QZSS
#
#
#  PPS ADEV for 84955 points - sample period=1.000 secs  - bin count:14
#      1.000 tau  3.4621e-009 (n=43197)
#      2.000 tau  1.7355e-009 (n=43195)
#      5.000 tau  6.8783e-010 (n=43189)
#     10.000 tau  3.4520e-010 (n=43179)
#     20.000 tau  1.7183e-010 (n=43159)
#     50.000 tau  7.0574e-011 (n=43099)
#    100.000 tau  3.6007e-011 (n=42999)
#    200.000 tau  1.8072e-011 (n=42799)
#    500.000 tau  7.2585e-012 (n=42199)
#   1000.000 tau  3.6834e-012 (n=41199)
#   2000.000 tau  1.8453e-012 (n=39199)
#   5000.000 tau  7.4818e-013 (n=33199)
#  10000.000 tau  3.5851e-013 (n=23199)
#  20000.000 tau  1.6814e-013 (n=3199)
#
#  PPS HDEV for 84955 points - sample period=1.000 secs  - bin count:13
#      1.000 tau  3.6499e-009 (n=43196)
#      2.000 tau  1.8313e-009 (n=43193)
#      5.000 tau  7.2455e-010 (n=43184)
#     10.000 tau  3.6413e-010 (n=43169)
#     20.000 tau  1.8064e-010 (n=43139)
#     50.000 tau  7.4202e-011 (n=43049)
#    100.000 tau  3.7939e-011 (n=42899)
#    200.000 tau  1.9034e-011 (n=42599)
#    500.000 tau  7.6306e-012 (n=41699)
#   1000.000 tau  3.8724e-012 (n=40199)
#   2000.000 tau  1.9281e-012 (n=37199)
#   5000.000 tau  7.8140e-013 (n=28199)
#  10000.000 tau  3.5864e-013 (n=13199)
#
#  PPS MDEV for 84955 points - sample period=1.000 secs  - bin count:13
#      1.000 tau  3.4621e-009 (n=43197)
#      2.000 tau  1.2295e-009 (n=43194)
#      5.000 tau  3.0416e-010 (n=43185)
#     10.000 tau  1.0540e-010 (n=43170)
#     20.000 tau  3.8724e-011 (n=43140)
#     50.000 tau  1.5815e-011 (n=43050)
#    100.000 tau  7.9180e-012 (n=42900)
#    200.000 tau  3.5732e-012 (n=42600)
#    500.000 tau  1.1746e-012 (n=41700)
#   1000.000 tau  5.9070e-013 (n=40200)
#   2000.000 tau  3.3584e-013 (n=37200)
#   5000.000 tau  1.4796e-013 (n=28200)
#  10000.000 tau  5.1583e-014 (n=13200)
#
#  PPS TDEV for 84955 points - sample period=1.000 secs  - bin count:13
#      1.000 tau  1.9989e-009 (n=43197)
#      2.000 tau  1.4197e-009 (n=43194)
#      5.000 tau  8.7803e-010 (n=43185)
#     10.000 tau  6.0855e-010 (n=43170)
#     20.000 tau  4.4715e-010 (n=43140)
#     50.000 tau  4.5654e-010 (n=43050)
#    100.000 tau  4.5714e-010 (n=42900)
#    200.000 tau  4.1260e-010 (n=42600)
#    500.000 tau  3.3908e-010 (n=41700)
#   1000.000 tau  3.4104e-010 (n=40200)
#   2000.000 tau  3.8780e-010 (n=37200)
#   5000.000 tau  4.2712e-010 (n=28200)
#  10000.000 tau  2.9781e-010 (n=13200)
#
#
#  PPS MTIE for 32768 points - sample period=1.000 secs  - bin count:16
#      1.000 tau  6.5166e+000 (n=32768)   (nanoseconds max time interval error)
#      2.000 tau  6.5166e+000 (n=32766)
#      4.000 tau  6.5166e+000 (n=32764)
#      8.000 tau  6.5166e+000 (n=32760)
#     16.000 tau  6.5166e+000 (n=32752)
#     32.000 tau  6.5166e+000 (n=32736)
#     64.000 tau  6.5166e+000 (n=32704)
#    128.000 tau  6.5166e+000 (n=32640)
#    256.000 tau  6.5166e+000 (n=32512)
#    512.000 tau  6.5166e+000 (n=32256)
#   1024.000 tau  6.5166e+000 (n=31744)
#   2048.000 tau  6.5166e+000 (n=30720)
#   4096.000 tau  6.5166e+000 (n=28672)
#   8192.000 tau  6.5166e+000 (n=24576)
#  16384.000 tau  6.5166e+000 (n=16384)
#  32768.000 tau  6.5166e+000 (n=1)
#
#
#
#  Plot statistics:
#
#     Sawtooth:
#       rms: 2.257634439 ns
#       avg: -0.109084539 ns
#       sdv: 2.254997522 ns
#       var: 5.085013825 ns
#       min: -4.047000000 ns
#       max: 3.808000000 ns
#       span: 7.855000000 ns
#
#     Tpps: (measured PPS deviation form 1.0000 seconds)
#       rms: 3.255180518 ns
#       avg: 0.000165522 ns
#       sdv: 3.255180514 ns
#       var: 10.596200180 ns
#       min: -8.712959243 ns
#       max: 8.774804883 ns
#       span: 17.487764126 ns
#
#     Tadj: (PPS measurement adjusted for sawtooth error)
#       rms: 2.305958761 ns
#       avg: -0.108871574 ns
#       sdv: 2.303387242 ns
#       var: 5.305592789 ns
#       min: -5.626733815 ns
#       max: 5.401032108 ns
#       span: 11.027765923 ns
#
#     Sats:  (tracking GPS and GLONASS)
#       rms: 14.592751290
#       avg: 14.485540834
#       sdv: 1.765643501
#       var: 3.117496974
#       min: 9.000000000
#       max: 19.000000000
#       span: 10.000000000
#

[clive.one]

Will be interesting to see how the ZED-F9T performs

$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX 9 00190000*12
$GNTXT,01,01,02,EXT CORE 1.00 (264600)*39
$GNTXT,01,01,02,ROM BASE 0x118B2060*20
$GNTXT,01,01,02,FWVER=TIM 2.00*52
$GNTXT,01,01,02,PROTVER=29.00*13
$GNTXT,01,01,02,MOD=ZED-F9T*75
$GNTXT,01,01,02,GPS;GLO;GAL;BDS*77
$GNTXT,01,01,02,SBAS;QZSS*60
$GNTXT,01,01,02,ANTSUPERV=*22
$GNTXT,01,01,02,ANTSTATUS=DONTKNOW*2D
$GNTXT,01,01,02,PF=FFF7A*48

[uncle_bob]

Hi

As long as I let mine run for a while, getting single digits on the post processed error ellipse seems to be pretty certain. The same "it's got to be a good chunk of a day" applies to the F9P as it does to the NetR9. That said, the NetR9 gets there a little bit quicker. It also is running on a disciplined external clock and the F9P is just on its internal TCXO.  Indeed it will be *very* interesting to see what the F9T does in terms of sawtooth correction compared to the F9P. Especially now that Digikey has announced that the F9P is "obsolete"

Bob

[uncle_bob]

Hi

The "rest of the story" on the F9P:

If I feed the NTRIP output from uCenter into either RTKLIB or into BKG's BNC client it is a bit wonky. It will run along for a while showing < 0.1 m sort of errors (just like the NetR9 pr NetR8 or NetRS). It then will decide that the back yard has moved 10,20,30, .... 80 meters in one direction or another. For whatever reason it will hang out there for hours and hours. Eventually it will come back to somewhere near right. Just why is unclear. One F9P will do it at a time. The other one will stay where it should be. The NetR9 and other Trimble receivers all agree that the back porch did not take an 80 M hike over a couple of seconds ....

I can take the NTRIP log files, convert them to Rinex and ship them off to NRCan for analysis. They are quite happy with them (as long as I fake the L2 designations) and give me great output data (as long as Glonass is present). The early solutions with just GPS are normally a bit disappointing. That may be due to the small number of GPS satellites transmitting L2C right now. The Trimble gear I keep comparing things to will do traditional L2 as well as L2C. That gives a few more sat's to work with.

Bob

[texaspyro]

The early solutions with just GPS are normally a bit disappointing. That may be due to the small number of GPS satellites transmitting L2C right now.

When I submitted a 14 hour GPS only file to CSRS-PPP the results came back with lat/lon/alt error ellipses of 11/25/54 mm.   A similar run with GPS+GLONASS came back with 10/15/50 mm.  I was not using NTRIP corrections.  Also my antenna environment is rather horrible.

[uncle_bob]

Hi

When I send in a 2 to 4 hour file, the GPS only ellipse is dimensioned in meters (or close to meters). When the Glonass data comes along (it's delayed a bit) the exact same file reports an ellipse roughly 1/10 the size. Again, this is all from NTRIP data translated via either BNC or RTKLIB. Both the 18.x and 19.x versions of uCenter show the same thing when used as NTRIP sources. It has been suggested by those brighter than I that slips may be miss corrected in the GPS data. Once the Glonass shows up, the magic post processing software can "repair" the damage.

One thing I noticed on the post above from Clive, the T seems to be on a 2.00 version of the firmware. The firmware we have on the P is still back in the 1.10 era.

Bob