<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi John,<div class="mb_sig"></div>
<div>Thanks! I suspected those numbers also were perhaps not actual accuracy. When I first powered it up it was showing .005, then .004 and after several days now .002 us but I agree it is probably suspect. I used 162stable32 to graph the data from u-Center and I also see the 4 nanosecond jitter over time. This is a mind boggling level of accuracy to me. Thanks for the tips John appreciate it very much.</div><div>Larry , K4LED</div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">On 4/23/2020 11:40:57 AM, John Ackermann N8UR <email@example.com> wrote:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Larry --
<br>I think the offset and frequency values you're seeing are sort of
<br>artificial -- the F9P is probably steering its internal clock to keep it
<br>in sync with the GPS. It will always report close to dead on.
<br>[ The Trimble NetRS has an option called "Clock Steering" that does
<br>this, and they warn you to turn it off if you are using an external
<br>reference. With an external reference, the processing results will tell
<br>you the performance of the reference vs. the GPS system clock.
<br>Unfortunately, the ZED-F9 doesn't provide for an external reference;
<br>that would be really cool! ]
<br>The jitter on the ZED-F9P or -F9T PPS output is about +/- 4 nanoseconds,
<br>which is less than half what other receivers provide. So the raw PPS
<br>output is quite a bit better than any other unit I've looked at.
<br>It is remarkable how well the software "quantization error" message
<br>predicts that jitter, and if you can apply the error message as a
<br>correction value in software, you can reduce the noise by another half
<br>order of magnitude, at least.
<br>My strong suspicion is that using RTK correction will *not* improve the
<br>hardware PPS output, because the PPS jitter is mainly caused by the
<br>receiver hardware and there's just not anything inside the module that
<br>cam improve that. An interesting question, though, is whether adding
<br>RTK to the mix would improve the performance of the software
<br>quantization error message. That's something I need to test.
<br>On 4/23/20 11:12 AM, Larry Dodd wrote:
<br>> John, All, FYI
<br>> I have two SparkFun RK2 F9P boards for testing and learning. My original
<br>> idea was to use one for RTCM correction data but using the internet
<br>> NTRIP client alone is giving good results. Spectacular in fact. UBX -
<br>> NAV - Clock status reporting .002 us and Frequency .000324 ppm. I
<br>> received a TICC and some other boards from TAPR yesterday to learn more.
<br>> I would like to eventually use the F9P 1PPS to correct my computer clock
<br>> but not sure how to go about that - possibly using the RS232 interface?
<br>> Thanks for all your professional work.
<br>> Larry, K4LED
<br>>> On 4/23/2020 10:05:07 AM, John Ackermann N8UR via TangerineSDR
<br>>> <firstname.lastname@example.org> wrote:
<br>>> Thanks, Gerry!
<br>>> From the testing I've done on the ZED-F9P and ZED-F9T, the timing
<br>>> performance is quite spectacular -- using software sawtooth correction,
<br>>> an order of magnitude plus better than what are used to as "GPS PPS"
<br>>> I just got my SkyTraq board yesterday and hope to fire it up soon.
<br>>> On 4/23/20 9:51 AM, Gerry Creager - NOAA Affiliate wrote:
<br>>> > I chatted with Gary Miller, the primary developer active these days on
<br>>> > gpsd, about the uBlox Zed-f9 and the SkyTraq PX1122R dual frequency
<br>>> > products. Gary's used more of the OEM boards than anyone else I know,
<br>>> > and because of the ongoing work with gpsd, has a lot of hands-on time
<br>>> > making code work.
<br>>> > Gary's very impressed with the SkyTraq engineering, but said,
<br>>> > essentially, that post-sales support and quality control were not good.
<br>>> > Assuming this is a family forum, I'll not be literal.
<br>>> > His impression of the Zed-F9 was a little muted, as he's not yet laid
<br>>> > hands on one, but has extensive uBlox experience. He's of the impression
<br>>> > that this system is likely both of higher quality and more readily
<br>>> > supported than the SkyTraq.
<br>>> > 73
<br>>> > Gerry N5JXS
<br>>> > On Fri, Apr 17, 2020 at 1:38 PM John Ackermann N8UR via TangerineSDR
<br>>> > > wrote:
<br>>> > Just FYI --
<br>>> > I just discovered that SkyTraq has a new GPS module, PX1122R, that seems
<br>>> > very comparable to the uBlox ZED-F9P, with a couple of exceptions noted
<br>>> > below.
<br>>> > It's dual frequency and has a built-in RTK processing engine -- that
<br>>> > means you can feed it correction data and get corrected results in
<br>>> > real-time. The claimed accuracy is 1.5m CEP autonomous, or 1 cm plus 1
<br>>> > ppm when in RTK mode.
<br>>> > There is a PPS signal with claimed 12 ns accuracy.
<br>>> > The good news is that the module is $99 quantity 1 (they also have a
<br>>> > breakout board for $125 and an evaluation board for $150).
<br>>> > The bad news is that, at least from the data sheet, it's unclear what
<br>>> > data outputs it provides -- there are a limited number of NMEA sentences
<br>>> > listed, but it also supports RTCM 3.1 and "Skytraq raw data binary".
<br>>> > I *think* but am not sure that the RTCM message output provides the raw
<br>>> > data needed to create RINEX files and generate TEC (I'm happy for input
<br>>> > on that point). And I don't know whether the binary protocol provides a
<br>>> > sawtooth or quantization error correction message to improve the PPS
<br>>> > quality.
<br>>> > I ordered one of the evaluation boards to test, but depending on the
<br>>> > data output capabilities this device may not be well suited for
<br>>> > timekeeping or the TangerineSDR.
<br>>> > Links:
<br>>> > Data sheet: http://navspark.mybigcommerce.com/content/PX1122R_DS.pdf
<br>>> > Module:
<br>>> > Breakout board:
<br>>> > Eval Board:
<br>>> > John
<br>>> > --
<br>>> > TangerineSDR mailing list
<br>>> > TangerineSDR@lists.tapr.org
<br>>> > http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
<br>>> > --
<br>>> > Gerry Creager
<br>>> > NSSL/CIMMS
<br>>> > 405.325.6371
<br>>> > ++++++++++++++++++++++
<br>>> > /The way to get started is to quit talking and begin doing./
<br>>> > / Walt Disney/
<br>>> TangerineSDR mailing list