[time-nuts] Z3805 serial ports

BD Systems Inc. bdsysco at yahoo.com
Mon Sep 17 01:07:39 UTC 2012


The Z3805A has two serial ports:
 	* An 
I/O Port (Port 1) 25-pin female DB series connector which provides a serial 
interface under RS-232 control. 
	* A 
second Output Port (Port 2) which provides a continuous (broadcast) time and 
date serial output once every two seconds (even second) at 9600, N, 8, 1. 
 

________________________________
 From: "time-nuts-request at febo.com" <time-nuts-request at febo.com>
To: time-nuts at febo.com 
Sent: Sunday, September 16, 2012 11:48 AM
Subject: time-nuts Digest, Vol 98, Issue 64
  
Send time-nuts mailing list submissions to
    time-nuts at febo.com

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
or, via email, send a message with subject or body 'help' to
    time-nuts-request at febo.com

You can reach the person managing the list at
    time-nuts-owner at febo.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of time-nuts digest..."


Today's Topics:

   1. Z3805 serial ports (John Ackermann N8UR)
   2. FS: PICTIC and DMDT Boards (Stanley)
   3. Re: GPSDO control loops and correcting quantizationerror
      (Poul-Henning Kamp)
   4. Re: Z3801 Replacement GPS Receiver Card (mike cook)
   5. Re: Z3801 Replacement GPS Receiver Card (Chris Albertson)
   6. Re: GPSDO control loops and correcting quantizationerror
      (Magnus Danielson)
   7. Re: GPSDO control loops and correcting quantizationerror
      (Bob Camp)
   8. Re: GPSDO control loops and correcting quantizationerror
      (Poul-Henning Kamp)


----------------------------------------------------------------------

Message: 1
Date: Sun, 16 Sep 2012 11:16:59 -0400
From: John Ackermann N8UR <jra at febo.com>
To: Discussion of precise time and frequency measurement
    <time-nuts at febo.com>
Subject: [time-nuts] Z3805 serial ports
Message-ID: <5055ED6B.7070207 at febo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I just acquired one of fluke.l's "Samsung" labeled z3805a units (the one 
with double-oven 10811A, 2 10 MHz, 2 PPS, and 2 comm ports.  Bob tells 
me that the comm ports are configured for RS-232, but I haven't powered 
the thing up yet (still working on power supply) so haven't inspected 
what the signals really look like.

I'm curious whether the PPS is on the "port 1" connector (the port 2 
connector only has TXD, RXD, and SG wires, so it's definitely not 
there).  Has anyone used one of these with software that looks for PPS 
on the DCD line?  Anything need to be done to make that work?

Thanks,

John



------------------------------

Message: 2
Date: Sun, 16 Sep 2012 10:45:10 -0500
From: "Stanley" <timenuts at n4iqt.com>
To: "time nuts list" <time-nuts at febo.com>
Subject: [time-nuts] FS: PICTIC and DMDT Boards
Message-ID: <E2CBB0B758A14119A83F3C7560B28DF9 at StanleyPC>
Content-Type: text/plain;    charset="iso-8859-1"

I've been unable to ship this summer but I am back now and have PC boards for the PICTIC II and DMDT projects for 8 USD each plus shipping. If you are interested please reply direct to me and not the list. If you have questions please check links below. Will also help with parts that are not available  from other sources.

http://ko4bb.com/dokuwiki/doku.php?id=precision_timing:pictic

http://www.ke5fx.com/pictic.htm

http://www.n4iqt.com/picticii/

http://www.wriley.com/A%20Small%20DMTD%20System.pdf

http://www.n4iqt.com/BillRiley/

Stanley

------------------------------

Message: 3
Date: Sun, 16 Sep 2012 15:47:17 +0000
From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
To: "Tom Van Baak" <tvb at leapsecond.com>
Cc: Discussion of precise time and frequency measurement
    <time-nuts at febo.com>
Subject: Re: [time-nuts] GPSDO control loops and correcting
    quantizationerror
Message-ID: <82536.1347810437 at critter.freebsd.dk>
Content-Type: text/plain; charset=ISO-8859-1

In message <5C52FBDBA5084AD4A36300FBA73BEF5E at pc52>, "Tom Van Baak" writes:
>> Yes, timing accuracy has been my main focus and in general I have been
>> using integration times on the low side of 10000 seconds for that,
>> but it depends a lot on the OCXO/Rb and environment.
>> 
>> The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL
>> for optimal time stability, and it does a surprisingly good job at it.
>
>Are there papers that talk about how to optimize for best timing or best 
>frequency or (no free lunch) some compromise combination of the two?

The only writings I am aware of, is what Dave Mills has written and
the PLL code in NTPns, but I havn't followed this closely in the last
10 years, so do check for newer writings.

Dave Mills coined the term "allan intercept" as the cross over of
the two sources allan variances and it's a good google search for
his relevant papers.

I'm not entirely sure his rule of thumb for regulating to that point
is mathematically sound & precise, but the concept itself is certainly
valid, even if you have to compensate for the timeconstant of the
PLL you use to regulate to that point.

I spent a lot of time with the code in NTPns, to try to get that PLL
to converge on the optimum, and while generally good, it's not perfect.

The basic problem is that the data you have available for autotuning,
is the allan variance between your input and your steered source.

If you also have the allan variance between the steered source and
a 3rd, better, source, the task is pretty trivial:  Minimize the
area below that curve.

But if you do that on the curve you have, you don't optimize, you
pessimize, since the lowest area, is with a timeconstant of zero.

Going the other direction and maximizing the area is no good either
and trying to balance the area around some pivot related to the
present PLL timeconstant does not converge in my experience.

What I did instead was to (badly) reinvent Shewarts ideas for testing
if the phase residual is under "statistical process control":

I increase the timeconstant if the phase residual has too frequent
zero-crossings and loosen it if they happen too seldom.

Having read a lot more about statistical process control, since I
built those NTP servers for the Air Traffic Control 10 years ago,
I would leverage more of the theory and heuristics developed in
process control. (3sigma violations, length of monotonic direction
etc. etc.)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



------------------------------

Message: 4
Date: Sun, 16 Sep 2012 18:02:23 +0200
From: mike cook <mc235960 at gmail.com>
To: Discussion of precise time and frequency measurement
    <time-nuts at febo.com>
Subject: Re: [time-nuts] Z3801 Replacement GPS Receiver Card
Message-ID: <5055F80F.10900 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 16/09/2012 15:38, Hui Zhang a ?crit :
> I just bought a second-hand Z3801A, it also had a error message when self test - GPS Rcv error, and I saw a red LED on main board on. I want test it alone but I don't know GPS board's pin define, can someone tell me? Thanks.
>
>

-- 
Les chiens aboient, et la caravane passe.



------------------------------

Message: 5
Date: Sun, 16 Sep 2012 09:08:08 -0700
From: Chris Albertson <albertson.chris at gmail.com>
To: Discussion of precise time and frequency measurement
    <time-nuts at febo.com>
Subject: Re: [time-nuts] Z3801 Replacement GPS Receiver Card
Message-ID:
    <CABbxVHt6vad2ZycMVTrLFKBDBAHqCWfmsmptxYv7=pxwLw9rVw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 15, 2012 at 7:04 PM, paul swed <paulswedb at gmail.com> wrote:
> As Bob mentions there may be more to it then just nailing that particular
> command.
> But worth taking a look after I deal with the wwvb psk issue. As far as the
> 5 to 3 V I would just use a 3 term reg like the cherry semi chip. But there
> are plenty of alternates. It will take 5 in and give 3.3 out at plenty of
> current.

You can power it with a regulator chip but the slightly harder part is
getting the 3V serial port level shifted to either 5V or RS232 and the
same for the PPS.  You can do it with a few transistors but maybe it
introduces error or noise if you are not carful.  I've used the 3.3
volt Oncore and really the hardest part is the new smaller connectors
that you have to find.

One good thing about the Oncore series is the quality of the
documentation.  All those commands are explained.
-- 

Chris Albertson
Redondo Beach, California



------------------------------

Message: 6
Date: Sun, 16 Sep 2012 19:20:24 +0200
From: Magnus Danielson <magnus at rubidium.dyndns.org>
To: time-nuts at febo.com
Subject: Re: [time-nuts] GPSDO control loops and correcting
    quantizationerror
Message-ID: <50560A58.5010607 at rubidium.dyndns.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote:
> In message<5C52FBDBA5084AD4A36300FBA73BEF5E at pc52>, "Tom Van Baak" writes:
>>> Yes, timing accuracy has been my main focus and in general I have been
>>> using integration times on the low side of 10000 seconds for that,
>>> but it depends a lot on the OCXO/Rb and environment.
>>>
>>> The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL
>>> for optimal time stability, and it does a surprisingly good job at it.
>>
>> Are there papers that talk about how to optimize for best timing or best
>> frequency or (no free lunch) some compromise combination of the two?
>
> The only writings I am aware of, is what Dave Mills has written and
> the PLL code in NTPns, but I havn't followed this closely in the last
> 10 years, so do check for newer writings.
>
> Dave Mills coined the term "allan intercept" as the cross over of
> the two sources allan variances and it's a good google search for
> his relevant papers.
>
> I'm not entirely sure his rule of thumb for regulating to that point
> is mathematically sound&  precise, but the concept itself is certainly
> valid, even if you have to compensate for the timeconstant of the
> PLL you use to regulate to that point.

Well, what is being used is phase-noise intercept. Conceptually a 
similar intercept point will be available in Allan variance. However, as 
you shift between noise-variants, the Allan (and Modified Allan) 
variance has different scaling factor to the underlying phase noise 
amplitudes. The danger of using the Allan variance variant is that you 
get a bias in position compared to the phase-noise plots cross-overs.
However, the concept is essentially the same, and the relative slopes is 
the same. You get in the right neighbourhood thought.

The concept has been in use in the phasenoise world of things, so you 
would need to search the phase-noise articles to find the real source. 
It's been used to generate stable high-frequency signals.

The analysis of PLL based splicing of ADEV curves is tricky, and I have 
not seen any good comprehensive analysis even if the general concept is 
roughly understood. The equivalent on phase-noise is however well 
understood and leaves no magic too it.

> I spent a lot of time with the code in NTPns, to try to get that PLL
> to converge on the optimum, and while generally good, it's not perfect.
>
> The basic problem is that the data you have available for autotuning,
> is the allan variance between your input and your steered source.

You need to treat the data as loose and tight PLL measure, depending on 
what you look for. There is loads of calibration issues, covered in 
literature.

> If you also have the allan variance between the steered source and
> a 3rd, better, source, the task is pretty trivial:  Minimize the
> area below that curve.
>
> But if you do that on the curve you have, you don't optimize, you
> pessimize, since the lowest area, is with a timeconstant of zero.
>
> Going the other direction and maximizing the area is no good either
> and trying to balance the area around some pivot related to the
> present PLL timeconstant does not converge in my experience.
>
> What I did instead was to (badly) reinvent Shewarts ideas for testing
> if the phase residual is under "statistical process control":
>
> I increase the timeconstant if the phase residual has too frequent
> zero-crossings and loosen it if they happen too seldom.
>
> Having read a lot more about statistical process control, since I
> built those NTP servers for the Air Traffic Control 10 years ago,
> I would leverage more of the theory and heuristics developed in
> process control. (3sigma violations, length of monotonic direction
> etc. etc.)
>

It's a complex field, and things like temperature dependencies helps to 
confuse you.

Cheers,
Magnus



------------------------------

Message: 7
Date: Sun, 16 Sep 2012 13:34:39 -0400
From: Bob Camp <lists at rtty.us>
To: Discussion of precise time and frequency measurement
    <time-nuts at febo.com>
Subject: Re: [time-nuts] GPSDO control loops and correcting
    quantizationerror
Message-ID: <ACD158CA-D76C-4A8B-B77D-4FA691D0B50B at rtty.us>
Content-Type: text/plain; charset=us-ascii

Hi

The time constant can indeed be changed dynamically, that's what is often done.

The purpose of my examples was to keep things simple and look at the "running condition" of the loop rather than it's performance while it settles down.

Bob

On Sep 16, 2012, at 9:49 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> In message <CE93652A-1DA6-48E3-9883-D7616AC24A78 at rtty.us>, Bob Camp writes:
> 
> Bob,
> 
> There's one thing makes me scratch my head here:  Why do you keep
> arguing like the timeconstant cannot be changed dynamically ?
> 
> I use a very aggresive timeconstants initially, to quickly get the
> phase offset under control, and then I ramp up the timeconstant in
> order to reduce phase noise of the GPS, until I hit something which
> looks like the "Allan-intercept" (as Dave Mills calls it).
> 
> It' won't take long time for us to agree that the timeconstant
> is a tradeoff between phase and frequency error, but just because
> it is called a "timeconstant" doesn't mean we cannot change it.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




------------------------------

Message: 8
Date: Sun, 16 Sep 2012 17:48:11 +0000
From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
To: Discussion of precise time and frequency measurement
    <time-nuts at febo.com>
Subject: Re: [time-nuts] GPSDO control loops and correcting
    quantizationerror
Message-ID: <1498.1347817691 at critter.freebsd.dk>
Content-Type: text/plain; charset=ISO-8859-1

In message <50560A58.5010607 at rubidium.dyndns.org>, Magnus Danielson writes:

>> What I did instead was to (badly) reinvent Shewarts ideas for testing
>> if the phase residual is under "statistical process control":
>>
>> I increase the timeconstant if the phase residual has too frequent
>> zero-crossings and loosen it if they happen too seldom.
>>
>> Having read a lot more about statistical process control, since I
>> built those NTP servers for the Air Traffic Control 10 years ago,
>> I would leverage more of the theory and heuristics developed in
>> process control. (3sigma violations, length of monotonic direction
>> etc. etc.)
>
>It's a complex field, and things like temperature dependencies helps to 
>confuse you.

No, not really.

The reason I went with the "statistical control" approach was exactly
to not be confused or mislead by environmental or other factors: I
wanted a PLL which on its own would adapt to circumstances on its
own, while still maximizing the hold-over time in case of GPS loss,
and all in all it has worked very well.

So far I have seen it cope admirably with an OCXO which went from
indoors to outdoors environment in the middle of winter, a PRS10
which gradually ran out of steam and only locked 40% of the time and
various other odd-ball events, so I think I'm justified in saying
that it does a pretty good job for autonomous and even unattended
operation.

It's certainly not perfect, but it is painfully obvious that the
adaptive PLL based on statical control heuristics is much more
resilient than a fixed or hand-tuned PLL.

I've been trying to find an excuse for giving NTPns an overhaul,
(PTP is a leading candidate for this) to get a chance to iron out
the kinks I have spotted over the last 10 years, but so far
life keeps me busy with other interesting stuff.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



------------------------------

_______________________________________________
time-nuts mailing list
time-nuts at febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

End of time-nuts Digest, Vol 98, Issue 64
*****************************************


More information about the time-nuts mailing list