<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 <jra@febo.com> wrote:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Larry --

<br>

Good deal!

<br>

<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

in sync with the GPS.  It will always report close to dead on.

<br>

<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

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>

<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

output is quite a bit better than any other unit I've looked at.

<br>

<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

order of magnitude, at least.

<br>

<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

quantization error message.  That's something I need to test.

<br>

<br>73,

<br>John

<br>----

<br>

<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

> 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

> but not sure how to go about that - possibly using the RS232 interface?

> Thanks for all your professional work.

<br>> Larry, K4LED

<br>> 

<br>>> On 4/23/2020 10:05:07 AM, John Ackermann N8UR via TangerineSDR

<br>>> <tangerinesdr@lists.tapr.org> wrote:

<br>>>

<br>>> Thanks, Gerry!

<br>>>

<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>>> performance.

<br>>>

>> I just got my SkyTraq board yesterday and hope to fire it up soon.

<br>>>

<br>>> John

<br>>> ----

<br>>>

<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>>> >

<br>>> > Gary's very impressed with the SkyTraq engineering, but said,

>> > essentially, that post-sales support and quality control were not good.

>> > Assuming this is a family forum, I'll not be literal.

<br>>> >

<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>>> >

<br>>> > 73

<br>>> > Gerry N5JXS

<br>>> >

<br>>> > On Fri, Apr 17, 2020 at 1:38 PM John Ackermann N8UR via TangerineSDR

<br>>> > > wrote:

<br>>> >

<br>>> > Just FYI --

<br>>> >

<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>>> >

<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

>> > ppm when in RTK mode.

<br>>> >

>> > There is a PPS signal with claimed 12 ns accuracy.

<br>>> >

<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>>> >

<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

>> > listed, but it also supports RTCM 3.1 and "Skytraq raw data binary".

<br>>> >

<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>>> >

<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>>> >

<br>>> > Links:

<br>>> > Data sheet:     http://navspark.mybigcommerce.com/content/PX1122R_DS.pdf

<br>>> >

<br>>> > Module:

<br>>> >

<br>>> http://navspark.mybigcommerce.com/px1122r-multi-band-quad-gnss-rtk-module/

<br>>> >

<br>>> > Breakout board:

<br>>> >

<br>>> http://navspark.mybigcommerce.com/ns-hp-gn2-px1122r-multi-band-quad-gnss-rtk-breakout-board/

<br>>> >

<br>>> > Eval Board:

<br>>> >

<br>>> http://navspark.mybigcommerce.com/px1122r-evb-px1122r-multi-band-quad-gnss-rtk-evaluation-board/

<br>>> >

<br>>> > John

<br>>> >

<br>>> >

<br>>> > --

<br>>> > TangerineSDR mailing list

<br>>> > TangerineSDR@lists.tapr.org

<br>>> > http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org

<br>>> >

<br>>> >

<br>>> >

<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>>>

<br>>>

<br>>> -- 

<br>>> TangerineSDR mailing list

<br>>> TangerineSDR@lists.tapr.org

<br>>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org

<br>

<br></tangerinesdr@lists.tapr.org></div></blockquote></div>