Re: [time-nuts] Designing an embedded precision GPS time server

[Andrew Rodland]

Hi Nick,

I've got a project along those lines that I've been hacking on for the past
three years or so, and always meaning to do a thorough writeup on. I'm more
of a software than hardware guy, so the heart of it is a Taijiuino Due (a
weird Chinese clone of the Arduino Due, so an 84MHz ATSAM3X8E, with the
difference from the official board being that it brings out the SAM's
Ethernet pins to a header that you can perch a PHY module on). It then
talks to a GPS (Resolution-SMT) and Rb (SA.22c, digitally controlled),
multiplied up 25/8 times by a TAPR Clock-Block to get 32ns granularity
(more or less). Apart from some of the low-level MAC code which is from
Atmel it's all my code for GPS decoding, timekeeping, NTP, etc, and has
some basic support for health monitoring and holdover.

As a NTP server it's pretty good when it's behaving -- I've got a
particularly-stable Linux machine on the same Ethernet segment polling it
at 16s interval and chrony reports a 500ns - 1us stdev for it, so you can
take that as a jitter figure. It outperforms the old Spectracom NetClock
9183 (w/OCXO option) I've got, in any case.

I'd be interested in comparing notes, and also interested in any
possibility of designing a PCB to replace the rat's nest of wires I've got
going on -- as I mentioned, I'm not "really" a hardware guy and EDA isn't a
skill I've picked up at this point. I've always wanted to derive the
micro's clock from the Rb (and PLL it up on the chip) rather than having to
live with the restrictions of an externally-clocked timer... but making
that happen is beyond my abilities :)


On Wed, Oct 25, 2017 at 8:53 PM, Nick Sayer via time-nuts <
time-nuts@febo.com> wrote:

> I’ve just completed a project (off topic) with the ATSAMS70 chip and
> learned a lot in a relatively short time, and I really like the result.
>
> I am considering a new project based on its cousin, the ATSAME70. The E70
> has an Ethernet 10/100 MAC built in as well as the rest of the stuff the
> S70 has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice),
> and Atmel Start (the software development framework I’ve been using)
> purports to have a ready-to-use IP stack (alas, no IPv6, but it’s a
> starting point at least).
>
> Where I am going with this is I am considering designing a precision
> embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got
> piles of up to a GPIO and USART and the Ethernet port would provide
> NTP/PTP. The idea behind making it an embedded system would be to try and
> make it as accurate as it reasonably can be with the hope that (at least on
> the local segment) it would wind up being more accurate than a Pi Zero
> doing the same thing. At the very least, you’d expect such a thing to be a
> whole lot less hassle to set up, given decent firmware.
>
> This may be a fool’s errand, certainly, but looking at it from here, I
> would think that such a design might offer accuracy in the microsecond
> range, but that’s just a tremendously uninformed guess at this point (and
> what does that accuracy mean to a peer that might itself be incapable of
> better than 2 orders of magnitude coarser?).
>
> Anybody have any ideas or suggestions along these lines?
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPS seconds conversion on an Arduino

[Andrew Rodland]

On Sat, May 13, 2017 at 9:58 PM, Mark Sims  wrote:
> Converting GPS seconds to Gregorian date/time on the Arduino will be an 
> arduous task.  You take GPS seconds and add it to the GPS starring epoch to 
> get a Julian date.  Then add in the number of leap seconds as a fraction of a 
> day to get UTC and possibly add in a time zone offset for local time.  Don't 
> forget to do daylight savings time conversion...  Then convert the result to 
> Gregorian date/time for display.
>
> The problem is the Arduino floating point library is single precision only 
> and does not have the resolution needed to handle the numbers involved.  
> Doing it with integer arithmetic (long longs) opens up a whole new can of 
> worms.

My old Arduino NTP server (the new one is built on an ARM chip)
converted from GPS time to NTP time (which is a 32.32 bit unsigned
fixed point format, at least for v3) without any particular trouble.
Given GPS week, (integer) GPS TOW, fractional seconds, and UTC
difference in separate variables, the code amounted to:

1. Start with 2,524,953,600 (the number of seconds between the NTP
epoch (1900-01-01) and the GPS epoch (1980-01-06); for the Unix epoch
of 1970-01-01 you would need 315,964,800 instead.)
2. Subtract the current GPS-UTC difference (leap second count).
3. Add 604,800 times the GPS week.
4. Add the TOW.
5. Store this value in the upper 32 bits of the output.
6. Convert fractional seconds from whatever units they're in, to units
of 2^-32 second using an appropriate fixed-point multiply, and store
the result in the lower 32 bits of the output.

Calendrical stuff is of course its own pain, but it's still true that
you can work with whole seconds (or even whole days) there, and deal
with fractions separately, without ever touching floating-point.
Fixed-point *is* extra work, but if you make the right choices it's
not *much* extra work. Depending on your application, you can of
course lose some (or all) of the lower bits in the fractional part,
and if you have the ability to choose your epoch to be relatively
close to the present, you can lose upper bits of the integer part.
It's worth noting that since the AVR is fundamentally an 8-bit
processor and all arithmetic on larger quantities has to be
synthesized from 8-bit operations anyway, AVR-GCC helpfully provides
__int24 and __uint24 types, as there's no good reason not to. That
means that if you want to do 24.8 fixed-point, you can.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Nortel NTGS and LH 5

[Andrew Rodland]

Looks like it's exactly 1024 weeks off. I'm not sure if it's LH or the
receiver doing it, but one of them is convinced that the year 2019 has
come and gone. The GPS week number is displayed as 1937 (0x791) but
the UTC time displayed is for the same day/date in GPS week 2961
(0xB91).

On Thu, Feb 23, 2017 at 2:45 AM, Bryan _  wrote:
> Perhaps something just went wonky in my setup but just noticed that the date 
> that LH 5 (TSIP) is displaying with my Nortel is very wrong. Any idea how to 
> correct. Could have happened after I did a cold reset a couple weeks ago.
>
>
> -=Bryan=-
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] My TICC came in the mail yesterday

[Andrew Rodland]

On Fri, Feb 24, 2017 at 7:08 PM, John Ackermann N8UR  wrote:
> Hi Andrew --
>
> There seems to be more than a little magic involved in getting sane
> three-corner measurements.  I've gotten best results when the run is long
> enough to have many data points per tau, and also that results when you're
> noise limited tend to go imaginary.  Finally, I think things work best when
> the three sources have similar noise processes, e.g., looking at 3x OCXO or
> 3x Rb or whatever.
>

Thanks. I'm not even complaining here, like I said, this is more
visibility than I've had in the past, and the TICC is looking pretty
good. As for more points, that was just the first 9 or so hours of a
24-hour run, which is now completed. At the end of that, it's more
reasonable: http://i.imgur.com/7v3obqy.png — although I'm certainly
not putting much faith in anything past 1000s. And the non-hat plot:
http://i.imgur.com/xWTsqCX.png .

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] My TICC came in the mail yesterday

[Andrew Rodland]

Which means, after a bit of scrounging for some BNC to SMA adapters, I
have some plots worth using (more or less) of my clock!

Background info: my clock's main purpose is to be a GPS-disciplined
NTP server on an Arduino Due clone board. As such, accuracy beyond
tens to hundreds of microseconds isn't really relevant. But for purely
time-nut reasons, it has an Rb oscillator (cheap surplus X72), and for
similar reasons it has a PPS output generated by the CPU timer. I
didn't hack the Due apart to replace the crystal, so the CPU clock
(84MHz) is asynchronous from the Rb, which has some limitations, but
also introduces a nice little bit of dither

The TICC is set up with 10MHz from a Spectracom NetClock, chA from a
(probably insufficiently thermally stabilized) LTE-Lite, and chB from
my clock. Output is in Timelab mode.

A representative bit of the phase plot: http://i.imgur.com/cRXv9ia.png

You can see all the quantization noise on my clock, but also that in
the ~100s region, it does better than the LTE-Lite. You can also see
the nice smooth (at short time) plot of the LTE-Lite which gives me
some good faith in the TICC.

ADEV plot so far: http://i.imgur.com/DLb15rt.png

Timelab loses the thread a little bit and comes up with negative
computed deviations for my clock for some tau. Not sure how much of
that is due to instrument limitations, and how much is due to the
noise being not-really-independent, since all three clocks are GPS
receivers, with rather nearby antennas. Still, more than I've ever
seen before!

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab question

[Andrew Rodland]

On Tue, Feb 21, 2017 at 5:26 PM, Bob Stewart  wrote:
> Thanks, John.  That will certainly get it to work as I expect it to.  I doubt 
> I'm the only one who's lost a dataset due to being distracted and hitting the 
> enter key to clear the dialog box.
>
> Wine is just a mess as far as Timelab is concerned.  Most of the time it 
> doesn't display the plot area.  I've pretty much given up on it.

This, at least, is easily fixed; use "winetricks gdiplus" to replace
Wine's GDI+ implementation with Microsoft's (the native DLL). Then all
the stuff that didn't draw before will work just fine. It does have a
few other little issues, but on the whole it works remarkably well for
me.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Survey plot as art.

[Andrew Rodland]

On Sun, Jan 15, 2017 at 6:23 AM, Andrew Rodland <and...@cleverdomain.org> wrote:
> Relatedly, and just for fun, here's a video I made several years ago
> from a few days worth of constellation status data out of a cheap SiRF
> receiver. It's interesting to see how the satellite geometry changes
> over time... or maybe it's just fun to watch the pretty colors. If
> you're observant you can also get an idea for where the tall trees
> were at my old apartment and maybe my approximate latitude.
>
> The projection is stereographic from the nadir (I think), with 90°
> elevation at the center, 0° elevation at the edges, and north up. The
> "wiggles" near the edges are due to the granularity of the positions
> from the receiver (half-degree, IIRC). Points are drawn with size and
> brightness proportional to the log signal strength, and the trails
> fade out exponentially.
>

And here is the actual video:
https://www.youtube.com/watch?v=VZHK1c54YRk -- sorry about the
suspense.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Survey plot as art.

[Andrew Rodland]

On Sat, Jan 7, 2017 at 12:54 PM, Peter Reilley  wrote:
>
> This is the survey from my Trimble NTBW50AA.   It looks like some bacteria
> floating around.

Relatedly, and just for fun, here's a video I made several years ago
from a few days worth of constellation status data out of a cheap SiRF
receiver. It's interesting to see how the satellite geometry changes
over time... or maybe it's just fun to watch the pretty colors. If
you're observant you can also get an idea for where the tall trees
were at my old apartment and maybe my approximate latitude.

The projection is stereographic from the nadir (I think), with 90°
elevation at the center, 0° elevation at the edges, and north up. The
"wiggles" near the edges are due to the granularity of the positions
from the receiver (half-degree, IIRC). Points are drawn with size and
brightness proportional to the log signal strength, and the trails
fade out exponentially.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] New Timestamping / Time Interval Counter: the TICC

[Andrew Rodland]

On Wed, Nov 23, 2016 at 10:48 AM, John Ackermann N8UR  wrote:
> The TICC is implemented as a two-channel timestamping counter.  That means
> it can measure one or two low-frequency (e.g., pulse-per-second) inputs
> against an external 10 MHz reference, or it can do a traditional time
> interval measurement of one input against the other.  It can also measure
> period, ratio, or any other function of two-channel  timestamp data.  (And
> by the way -- multiple TICCs can be connected to yield 4, 6, 8, or more
> synchronized channels, though we haven't tested this capability yet.)

Very exciting, I will definitely be wanting one :)

There's *almost* a way to do the coarse timer counting with almost no
CPU overhead, but unfortunately the Arduino folks were terribly
inconsistent about which timer signals they decided to assign to
Arduino pins. Of the six external clocks for timers, they brought out
two (T0 and T5), and of the four input captures, they brought out two
(ICP4 and ICP5). If they had brought out T4 then with a little bit of
timer configuration you could use COARSE to clock TIMER4 and TIMER5 in
lockstep, run STOP_A and STOP_B to ICP4 and ICP5, and instead of
interrupting at 10kHz to increment PICcount, you would only have to
interrupt every 6.5536 seconds to increment the upper bits. Plus
handling the actual events of course. I find that very appealing, but
unfortunately, T4 is out of reach of a shield.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] A different way to think about time dilation?

[Andrew Rodland]

Yes, the math works out. Whether it actually has physical meaning is
kind of a philosophical question, but it's a useful tool.
https://en.wikipedia.org/wiki/Proper_time#Examples_in_special_relativity
is an example worth looking at.

On Sun, Jul 10, 2016 at 12:01 PM, Chris Albertson
 wrote:
> Is this a valid TN subject?  It's about time but a little off of the usual
> subject of 10Mhz oscillators.
>
> I heard  of an alternate way to describe time dilation caused by velocity.
>   I think this makes it easier to understand but I've not been able to
> verify the math.  This alternate explanation also makes it easy to see why
> we can never go faster than light.   But I've not seen a mathematical
> derivation so it could be wrong or just an approximation.
>
> Here goes:
>
> 1) We assume a 4 dimensional universe with four orthogonal axis, x, y, z,
> and time (t)
> 2) assume that at all times EVERY object always has a velocity vector who's
> magnitude is "c", the speed of light.  The magnitude of this vector (speed)
> never changes and is the same for every particle in the universe.
>
> This at first seems a radical statement but how is moving at c much
> different from assuming every partial is at rest in t's own reference
> frame?  I've just said it is moving at c in it's own reference frame.  Both
> c and zero are arbitrary speeds selected for connivance.
>
> How can this be?  I know I'm sitting in front of my computer and have not
> moved an inch in the last four hours.  c is faster than that.   Yes you are
> stationary in (x,y,z) but along the t axis you are moving one second per
> second and I define one second per second as c.  Now you get smart and try
> to move faster than c by pushing your chair backward in the Y direction at
> 4 inches per second.  So you THINK your velocity magnitude is the vector
> sum of c and 4 inch/sec which is greater than c.   BUT NO.  Your speed
> along Y axis causes time dilation such that your speed along T is now
> slower than 1 second/second.   In fact if you push your chair backward
> along Y real fast at exactly c your speed along t axis is zero, time
> stops.  Try pushing your chair at 0.7071 * c and you find yourself moving
> through t at 0.7071 sec/sec and the vector sum is c.  You can NOT change
> you speed from c all you can do to change the direction of the velocity
> vector and your speed through time is determined by the angle between that
> vector and the t axis.
>
> It works ok to just use one of the three spacial axis because we can always
> define them such that (say) the Y axis points in the direction of motion.
> So a plot of your speed in the dy,t plane covers the general case and looks
> like an arc of radius c.
>
> If this works out then I have some work to do, like defining momentum as a
> function of the area between the velocity vector and the t axis
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Advise on building a DIY GPSDO?

[Andrew Rodland]

On Sun, Apr 3, 2016 at 6:04 PM, Nicolas Braud-Santoni
 wrote:
> Hi,
>
> I've been slowly becoming a fellow timenut over the last few years,
>   though said nuttery had yet to go beyond adding some wiring to
>   get the PPS signal out of my GPS and into my NTPd.
>
>
> Lately, I have been looking into designing & building a home-brew
>   GPSDO (and my copy of TAoE 3rd ed. came in quite handy), but quite
>   a few questions came up:
>
> - Does it indeed make sense to build a GPSDO using an “ordinary”
>   high-quality oscillator? (as opposed to using a Ru standard)
>
>   It seems that decomissioned rubidium standards are large, rather
>   expensive (hundreds of €), consume lots of power and have
>   uncertain lifetime.

Depending on your definition of large and expensive, I'd say it's not
so bad. I've been able to get X72s and more recently SA.22cs off of
fleabay for between $100 and $150 (about 90 - 130 EUR at present
rates). They're pretty small, steady-state power draw is about 5
watts, and although the lifetime is a question, a good seller should
show you the diagnostic output including power-on hours and various
temperatures and voltages -- the one I trust does!

> - Are there recommendations people can make for not-too-expensive
>   VCOs to use in a GPSDO?
>
> - Are there GPS modules that people here can recommend?
>
>   I have been looking at the uBlox NEO-7 and the GNS TC6000GN-P1
>   GPS modules.  Both retail around 40€, and promise <100ns PPS jitter.
>   I would probably prefer the NEO-7, because uBlox makes more precise
>   PPS jitter claims for GPS, with 30ns RMS and 60ns for 99 percentile.

The uBlox ones are nice. I have one sitting around but I haven't
gotten around to writing a protocol decoder for it yet, so I'm using
an older Trimble Resolution T. If your goal is purely hobby and you
want to save some money, that might be a perfectly good option -- you
can find them for very cheap, and if your main aim is to build an NTP
server then anything better than the Trimble will be lost in the noise
anyway. Like the uBlox ones, the Trimble supports doing
survey-in/stationary mode for the best time stability.

> - While trying to design this on my own is fun and educational, are
>   there existing designs for DIY GPSDOs that I should look at?

I'm not making any great promises of educational value, but I've spent
a bunch of time building GPS-disciplined NTP servers on the Arduino
platform as a purely hobby thing and I do have a bit to share. I've
failed repeatedly to do a decent write-up of my work in blog form, but
I do have code and I'd be happy to answer questions about it.

First: https://github.com/arodland/Due-GPS-NTP-Server . This one is
newer, and it runs on the ARM-based Arduino Due (actually a clone
board called the Taijiuino that allows using the SAM3X's onboard
Ethernet MAC). It works with a Symmetricom rubidium oscillator and
either Trimble or SiRF GPS. It has a timing granularity of 32ns and
the NTP stdev as measured from my desktop is about 5 microseconds. It
also sends out statistics packets every second over UDP that I use to
make graphs, and has a serial CLI for tweaking the settings :)

Second: https://github.com/arodland/Arduino-GPS-NTP-Server . This is
the older version. I don't keep up with it anymore, it only supports
the SiRF GPS driver, it uses an FLL algorithm that I no longer think
is right, and it doesn't discipline an external oscillator, it just
does digital frequency synthesis on the Arduino's own 16MHz clock.
However there's some potentially interesting stuff in there in terms
of managing the timer interrupts, keeping time, and doing all of the
requisite math on an 8-bit chip without burning more cycles than we
have available, as well as hacking the Arduino Ethernet Shield to
support an interrupt-driven mode to allow better timestamping of
incoming packets. It has a timing granularity of 500ns and due to the
iffy performance of the WizNet ethernet adapter the NTP stdev is in
the 10-20 microsecond range (it was worse than that before I figured
out the interrupt trick).

> For reference, my use-case (beyond simply building it) is two-fold:
> - I want an accurate ref. clock for my local NTP setup.
> - I need a frequency reference for QRSS (low-power RF transmissions),
>   and getting a 8MHz reference out of the GPSDO would help a lot  :)

In that case you may want to forget the rubidiums that I mentioned and
go for a VCXO after all; my rubidiums use digital frequency synthesis,
and I understand that makes them unusable for radio work -- unless
you're just using them as a reference to lock some other, cleaner,
oscillator.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Belated leap second video / result

[Andrew Rodland]

Here's a video of my Spectracom 9183 and my homebuilt GPS/Rb NTP
server both cruising through last month's leap second (the first one
in my new lab) without incident. Apologies for the blur/bloom on the
laptop screen, I guess I didn't get the focus exactly right. You can
still read it as long as you already know what you're looking for :)

https://vimeo.com/133728097


Leap second is at 1:09 in the video, both devices display 23:59:60
UTC. A second later, both display 00:00:00 and the LEAP (upcoming leap
second) indicator on my GPS clock cleared. A few minutes later, I
checked NTP sync and both of my Linux boxes also adjusted correctly
(this time without any kernel bugs) and were within 1ms of the NTP
clock.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPS for ntp

[Andrew Rodland]

On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote:
 The one thing that hasn't yet happened is making the beaglebone timestamp
 on the linux side in a way that works for ntp.

 Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there
 yet.

 I have been working on it but if anyone has some insight its appreciated.


It appears to support gpio class devices, with interrupts, so the
pps-gpio driver (in-tree since 3.2) should work just fine. The only
thing that's needed (other than building the driver) is a bit of code
in the board support file to register the device. Various folks have
done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example),
and I've done it for the UDOO Dual
(https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is
probably about as easy.

I'm not sure if there's other hardware that lets you do better than
grabbing an interrupt, but that will get you in the microsecond range
or a bit better, anyhow.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop

[Andrew Rodland]

Simon,

This is a fantastic idea and I have every intention of trying to
replicate it at home with tools on hand. Thanks for sharing, and I
hope you can show off some results.

On Wed, Oct 8, 2014 at 1:09 PM, Simon Marsh subscripti...@burble.com wrote:
 I've been a lurker on time-nuts for a while, most of the discussion being
 way over my head, but I thought there may be interest in some proof of
 concept code I've written for simple digital hetrodyne mixing using just a
 BeagleBone Black and an external dual D Flip Flop.

 The idea is based on the following article which describes creating a
 digital DMTD with an FPGA for clocks @ 125mhz:

 http://www.ee.ucl.ac.uk/lcs/previous/LCS2011/LCS1136.pdf

 My setup follows the same principle, but scaled down to 10mhz to make it as
 simple as possible (and not require an FPGA).

 The hardware side is just a 74AC74 dual flip flop to sample the input clocks
 being tested. Instead of having a helper PLL for the mixer frequency, I
 simply have a 3rd, de-tuned oscillator. The output from the two flip-flops
 together with the mixer clock are fed to the BBB.

 On the BBB, the approach is to do as little as possible in real time using a
 PRU core, and then post-process on the ARM core afterwards.

 The BBB PRU has a 16-bit, asynchronous, parallel, capture mode, where 16
 GPIO pins can be latched based on an external clock (described in section
 4.4.1.2.3.2 of the TRM for those interested). In this case, the external
 clock is the mixer oscillator. All the PRU needs to do is wait for the
 sample to take place, read the GPIOs and store the results in main memory.
 The PRU is plenty fast enough to capture samples @10mhz and, in theory at
 least, each PRU could sample up to 16 clocks simultaneously (depending on
 whether the relevant GPIO pins were free).

 Once the sampling is complete, the ARM core can process the results in its
 own time, and this includes any more complicated algorithms for de-glitching
 etc

 The theoretical minimum time resolution depends on the beat frequency and is
 described in the article, for example with a beat frequency of 50 hz the
 minimum resolution is 50 / (1000 - 50)*1000 = ~5E-13. In practice
 the available accuracy is determined by the stability of the mixer clock and
 noise of the setup. The impact of this noise is described in the article as
 glitching and there are some suggested ways for processing this out. I'm
 trying this on an open bench, with basic oscillators, using pluggable
 breadboard and lots of hanging wires, I'm not at risk of getting near the
 theoretical limit quite yet :)

 Note that the BBB itself has no impact on the accuracy or noise of the raw
 data. Once the input is latched at the flip-flop, the only bit of critical
 timing required is to ensure that samples can be captured fast enough and
 that the flip-flop state is captured when it is stable (i.e. not
 transitioning).

 I make no excuses that this is very simplistic, and there are many, many
 ways that it can (should!) be improved. For me the next steps will probably
 be:

 1) Get off the breadboard and focus a bit more on getting the signals to the
 flip-flop with a 'reasonable' amount of noise.
 2) Improve the PRU code so that it stores transitions and not just the raw
 samples, this would offload a significant bit of work from the ARM core,
 save a load of memory and allow continuous streaming of data (instead of the
 current one shot approach).
 3) Experimentation with different algorithms for processing the data on the
 ARM.

 I don't think anyone has posted a similar set up, so any feedback on whether
 the approach is viable or I'm wasting my time are welcome.

 I've posted the code to Google drive for anyone to take a look. It shouldn't
 be too difficult to reproduce if someone wants to, but again please remember
 it's just 'prove it can be done' code.

 https://drive.google.com/open?id=0BzvFGRfj4aFkblAwcWxGNHdCSDgauthuser=0

 Cheers


 Simon
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Sun Outage

[Andrew Rodland]

You pick up satellite TV with a parabolic dish that points at one spot
in the sky where the geostationary satellite lives. A sun outage
happens when the sun wanders into the focus and overloads the receiver
with noise that drowns out the satellite signal (at least, it raises
the noise floor enough that you can't receive the high bitrates needed
for a TV picture).

You pick up GPS with a whole-sky antenna that receives signals from
the constantly-moving swarm of GPS satellites. It undoubtedly receives
some noise from the sun, but the only factor in how much of that you
get is the sun's elevation above the horizon. It's not really relevant
whether the sun is aligned with a satellite or not. Even if it was,
the satellite would be somewhere else a minute later. :)

Andrew

On Thu, Oct 9, 2014 at 1:40 PM, Bob Stewart b...@evoria.net wrote:
 Two days this week, there was a 3 or 4 minute outage on DirecTV as the sun 
 aligned with the satellite and my dish.  So I was wondering what kind of 
 effect this has on the GPS system and especially timing receivers.


 Bob - AE6RV
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First few measurements of my Arduino Due GPSDO

[Andrew Rodland]

On Thu, Sep 25, 2014 at 3:34 AM, Neil Schroeder gign...@gmail.com wrote:
 Are all the devices you're using or considering capable of hardware
 timestamps?  Or are you doing it in software today?

The PPS from the GPS is timestamped fully in hardware using the input
capture function of the hardware timer to copy its value to another
register on a signal edge. The outgoing PPS is generated by the same
timer.

The NTP stuff relies on software; the receive timestamp is captured
from the timer as early as possible in the Ethernet ISR, and the
transmit timestamp is captured as the last thing before sending the
packet to the MAC to be transmitted. It's not perfect, but it's as
good as I'm likely to get right now. Some day I might look into
whether I can integrate a PTP-capable Ethernet PHY :)

Right now I have the UDOO board (which is no longer serving as the
mainboard of the clock) running ntp on Linux with both the PPS and the
NTP as sources; numbers from that forthcoming when I have them.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First few measurements of my Arduino Due GPSDO

[Andrew Rodland]

Yes indeed, that board is dead. Luckily, though, I had a substitute
(see some conversation around Sep 10 on the other thread about
adapting a UDOO to do the job -- it's a board that has both the Due's
SAM3X and an i.MX chip running Linux, with serial and GPIO shared
between them) and I've made some slower progress using that, mostly
tweaking the control loop for smoother response, and improving the
health-monitoring / holdover logic.

More excitingly, a board that I ordered from China even before killing
the EtherDue arrived yesterday. It's a Due clone called Taijiuino
that brings out the SAM3X's own Ethernet MAC pins, instead of using an
offboard Ethernet controller like the EtherDue does. I'm optimistic
that this will give me much finer control over packet timestamping and
lower the ethernet-induced NTP jitter by an order of magnitude or so,
which would really give me something to show for this project. The
only downside is I have to write the Ethernet driver first! Definitely
hoping to have something to report there.

On Sun, Sep 14, 2014 at 5:35 PM, Shane Morris edgecombe...@gmail.com wrote:
 I'll be looking for that blog post. By the way, how did the burnt out
 EtherDue go? I remember saying after you had taken your last set of
 pictures that you'd popped it...!


 On Mon, Sep 15, 2014 at 6:48 AM, Andrew Rodland and...@cleverdomain.org
 wrote:

 Neil,

 I'm working on a blog post now, I'm hoping to have it complete by
 Monday or Tuesday. I'll send a followup here when it's posted.

 On Sun, Sep 14, 2014 at 11:47 AM, Neil Schroeder gign...@gmail.com
 wrote:
  I have nothing constructive to add at this time but I would truly enjoy
  reviewing your design and build logs/notes.
 
 
 
  On Sunday, September 14, 2014, Andrew Rodland and...@cleverdomain.org
  wrote:
 
  Hi all,
 
  I've got some figures in from my clock, and I figured I would post
  them here in hopes of getting some eyes on them and some help with
  interpretation.
 
  Reference is a Spectracom NetClock 9183 with OCXO option. Frequency is
  good to better than 10^-9, PPS is specified as +/- 50ns.
 
  Instrument is an HP 5335A (in lovely condition given that it was built
  in 1985 according to the serial number) in time difference mode.
 
  My clock is quantized at 10MHz, so you wouldn't expect better than
  100ns accuracy. But I added -50ns to the offset in software, making it
  zero in on the edge where the offset is 0 counts 50% of the time and
  -1 count the other 50%. (Dithering provided by noise in the system and
  the Resolution-T's own sawtooth). This seems to have worked better
  than expected.
 
  (On a side note: this means that the gain of my control loop is
  obviously pretty non-linear inside of 1us. Anything I should read
  about that?)
 
  So far I've done two 24-hour runs, one with PLL and FLL constants at
  3600s, and one with them at 7200s.
 
  Phase plot:
  3600s: http://i.imgur.com/LLfYgXe.png
  7200s: http://i.imgur.com/zUbgNHc.png
 
  Both keep within +/-20ns the majority of the time, which is better
  than I expected given the specs of both clocks. 1us offset is
  deliberately added at the PPS output of my clock to make the 5335A
  happy.
 
  Frequency plot:
  3600s: http://i.imgur.com/7GoXdoF.png and
 http://i.imgur.com/rjBa7gf.png
  7200s: http://i.imgur.com/KcyGT3r.png and
 http://i.imgur.com/GZH4Pcl.png
 
  Both have similar envelopes that seem to reflect the quantization more
  than anything (100s averaging shrinks the envelopes by very close to a
  factor of 100x). 7200s looks like it has some kind of oscillation with
  2000s period, which is worth looking into.
 
  MDEV:
  3600s: http://i.imgur.com/RmAcAwT.png
  7200s: http://i.imgur.com/xO7aYf9.png
 
  ADEV was a perfectly straight line so I didn't bother. MDEV displays a
  little more structure, but I'm not really clear on the interpretation.
 
  TDEV both: http://i.imgur.com/YamRIui.png
 
  I like TDEV. Same information as MDEV but since it turns slope=-1 to
  slope=0  it makes this kind of graph more readable. The two plots are
  within each other's error bars, so any difference between them might
  be imaginary, but they depart at 1000s, which probably corresponds to
  the 2000s oscillation.
 
  I guess I'm seeking general input on where I should go next -- do the
  graphs tell me anything interesting? Should I keep working on the
  control loop even though it already manages to keep things within half
  a clock tick? Or should I start looking for ways to reduce the
  Ethernet jitter since that's the dominant source of error in the use
  that I care about?
 
  Andrew
  ___
  time-nuts mailing list -- time-nuts@febo.com javascript:;
  To unsubscribe, go to
  https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
  and follow the instructions there.
  ___
  time-nuts mailing list -- time-nuts@febo.com
  To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman

[time-nuts] First few measurements of my Arduino Due GPSDO

[Andrew Rodland]

Hi all,

I've got some figures in from my clock, and I figured I would post
them here in hopes of getting some eyes on them and some help with
interpretation.

Reference is a Spectracom NetClock 9183 with OCXO option. Frequency is
good to better than 10^-9, PPS is specified as +/- 50ns.

Instrument is an HP 5335A (in lovely condition given that it was built
in 1985 according to the serial number) in time difference mode.

My clock is quantized at 10MHz, so you wouldn't expect better than
100ns accuracy. But I added -50ns to the offset in software, making it
zero in on the edge where the offset is 0 counts 50% of the time and
-1 count the other 50%. (Dithering provided by noise in the system and
the Resolution-T's own sawtooth). This seems to have worked better
than expected.

(On a side note: this means that the gain of my control loop is
obviously pretty non-linear inside of 1us. Anything I should read
about that?)

So far I've done two 24-hour runs, one with PLL and FLL constants at
3600s, and one with them at 7200s.

Phase plot:
3600s: http://i.imgur.com/LLfYgXe.png
7200s: http://i.imgur.com/zUbgNHc.png

Both keep within +/-20ns the majority of the time, which is better
than I expected given the specs of both clocks. 1us offset is
deliberately added at the PPS output of my clock to make the 5335A
happy.

Frequency plot:
3600s: http://i.imgur.com/7GoXdoF.png and http://i.imgur.com/rjBa7gf.png
7200s: http://i.imgur.com/KcyGT3r.png and http://i.imgur.com/GZH4Pcl.png

Both have similar envelopes that seem to reflect the quantization more
than anything (100s averaging shrinks the envelopes by very close to a
factor of 100x). 7200s looks like it has some kind of oscillation with
2000s period, which is worth looking into.

MDEV:
3600s: http://i.imgur.com/RmAcAwT.png
7200s: http://i.imgur.com/xO7aYf9.png

ADEV was a perfectly straight line so I didn't bother. MDEV displays a
little more structure, but I'm not really clear on the interpretation.

TDEV both: http://i.imgur.com/YamRIui.png

I like TDEV. Same information as MDEV but since it turns slope=-1 to
slope=0  it makes this kind of graph more readable. The two plots are
within each other's error bars, so any difference between them might
be imaginary, but they depart at 1000s, which probably corresponds to
the 2000s oscillation.

I guess I'm seeking general input on where I should go next -- do the
graphs tell me anything interesting? Should I keep working on the
control loop even though it already manages to keep things within half
a clock tick? Or should I start looking for ways to reduce the
Ethernet jitter since that's the dominant source of error in the use
that I care about?

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First few measurements of my Arduino Due GPSDO

[Andrew Rodland]

On Sun, Sep 14, 2014 at 4:29 AM, Andrew Rodland and...@cleverdomain.org wrote:
 My clock is quantized at 10MHz, so you wouldn't expect better than
 100ns accuracy. But I added -50ns to the offset in software, making it
 zero in on the edge where the offset is 0 counts 50% of the time and
 -1 count the other 50%. (Dithering provided by noise in the system and
 the Resolution-T's own sawtooth). This seems to have worked better
 than expected.

I'm in the middle of measuring a free-run with the control loop
disabled and I realized that this explanation is pretty well mistaken.

The thing is, even though I can only *measure* time (the PPS offset,
or NTP timestamps) in multiples of the 10MHz clock, my PPS *output* is
actually quantized by the 84MHz crystal clock on the Due. +/- 1 cycle
at 84MHz = ~24ns, and that agrees much better with the noise I see at
very short times.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First few measurements of my Arduino Due GPSDO

[Andrew Rodland]

Neil,

I'm working on a blog post now, I'm hoping to have it complete by
Monday or Tuesday. I'll send a followup here when it's posted.

On Sun, Sep 14, 2014 at 11:47 AM, Neil Schroeder gign...@gmail.com wrote:
 I have nothing constructive to add at this time but I would truly enjoy
 reviewing your design and build logs/notes.



 On Sunday, September 14, 2014, Andrew Rodland and...@cleverdomain.org
 wrote:

 Hi all,

 I've got some figures in from my clock, and I figured I would post
 them here in hopes of getting some eyes on them and some help with
 interpretation.

 Reference is a Spectracom NetClock 9183 with OCXO option. Frequency is
 good to better than 10^-9, PPS is specified as +/- 50ns.

 Instrument is an HP 5335A (in lovely condition given that it was built
 in 1985 according to the serial number) in time difference mode.

 My clock is quantized at 10MHz, so you wouldn't expect better than
 100ns accuracy. But I added -50ns to the offset in software, making it
 zero in on the edge where the offset is 0 counts 50% of the time and
 -1 count the other 50%. (Dithering provided by noise in the system and
 the Resolution-T's own sawtooth). This seems to have worked better
 than expected.

 (On a side note: this means that the gain of my control loop is
 obviously pretty non-linear inside of 1us. Anything I should read
 about that?)

 So far I've done two 24-hour runs, one with PLL and FLL constants at
 3600s, and one with them at 7200s.

 Phase plot:
 3600s: http://i.imgur.com/LLfYgXe.png
 7200s: http://i.imgur.com/zUbgNHc.png

 Both keep within +/-20ns the majority of the time, which is better
 than I expected given the specs of both clocks. 1us offset is
 deliberately added at the PPS output of my clock to make the 5335A
 happy.

 Frequency plot:
 3600s: http://i.imgur.com/7GoXdoF.png and http://i.imgur.com/rjBa7gf.png
 7200s: http://i.imgur.com/KcyGT3r.png and http://i.imgur.com/GZH4Pcl.png

 Both have similar envelopes that seem to reflect the quantization more
 than anything (100s averaging shrinks the envelopes by very close to a
 factor of 100x). 7200s looks like it has some kind of oscillation with
 2000s period, which is worth looking into.

 MDEV:
 3600s: http://i.imgur.com/RmAcAwT.png
 7200s: http://i.imgur.com/xO7aYf9.png

 ADEV was a perfectly straight line so I didn't bother. MDEV displays a
 little more structure, but I'm not really clear on the interpretation.

 TDEV both: http://i.imgur.com/YamRIui.png

 I like TDEV. Same information as MDEV but since it turns slope=-1 to
 slope=0  it makes this kind of graph more readable. The two plots are
 within each other's error bars, so any difference between them might
 be imaginary, but they depart at 1000s, which probably corresponds to
 the 2000s oscillation.

 I guess I'm seeking general input on where I should go next -- do the
 graphs tell me anything interesting? Should I keep working on the
 control loop even though it already manages to keep things within half
 a clock tick? Or should I start looking for ways to reduce the
 Ethernet jitter since that's the dominant source of error in the use
 that I care about?

 Andrew
 ___
 time-nuts mailing list -- time-nuts@febo.com javascript:;
 To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Help understanding an ADEV

[Andrew Rodland]

Your intuition isn't completely wrong -- the law of averages still
applies. As you provide more and more good data it will eventually
overwhelm the initial bad data, and the result will get closer to
correct.

But it will take a *lot* of data to overwhelm even a few data points
that have a deviation a hundred thousand times as large as the
deviation you're trying to measure. You would probably have to run for
months before you could trust the plot out to tau = 1s. Removing
the bad data is a superior alternative, if you ask me :)

Andrew

On Thu, Sep 11, 2014 at 5:21 PM, Bob Stewart b...@evoria.net wrote:
 Hi Tom,

 And thank you very much for taking the time to look at this.  No, I don't 
 know what the heck a lot of this means, and it's no surprise that I used the 
 wrong tool.  I had noticed the first few seconds of bad data, but didn't 
 think it would matter over long sample sessions.

 I'll take some time to get this together properly and see what I can find 
 out.  The new PIC arrives tomorrow, so I'll know pretty quickly if there is a 
 big improvement in the noise.

 Thank you again, and everyone else who has taken even a moment of time to 
 help me during this project!


 Bob



 
  From: Tom Van Baak t...@leapsecond.com
 To: Discussion of precise time and frequency measurement time-nuts@febo.com
 Sent: Thursday, September 11, 2014 3:53 PM
 Subject: Re: [time-nuts] Help understanding an ADEV


 I've been wondering if it would be better to look in the frequency domain.
 I'll have to look at Tom's site to see if he has code to do that.
 Bob

 Hi Bob,

 Ok, I think I found the problem with your plot. There's one mistake, one 
 misunderstanding, and a miscalibration.


 1) It appears you're allowing bogus DAC readings to pollute the ADEV 
 calculation. Based on the raw data you kindly sent, your nominal DAC value is 
 about 2.1 volts and your DAC voltage typically changes by tens or low 
 hundreds of microvolts.

 However the first couple of data points are 0.0 and 1.0 volts. The ADEV 
 calculation is therefore seeing changes of millions (!) of microvolts. This 
 completely messes up every ADEV calculation at every tau of your plot. You 
 must feed clean data into any ADEV calculation. Either fix your 
 instrumentation, or put checks in your scripts, or visually examine time 
 series data before you blindly feed it into a statistical formula or a tool.

 I don't know why the plotting package you used does not show these points. 
 Those four bogus points should have been an instant red flag.


 2) Realize that we normally make ADEV plots only from phase data or from 
 frequency data. Phase data is the net time difference (or time interval) 
 between the DUT and the REF. Units are seconds. Frequency data is the 
 (normalized) relative frequency difference between the DUT and the REF. This 
 is unitless.

 Now in your case, you want to make an ADEV plot from DAC data. This is ok, 
 since DAC voltage is essentially a proxy for frequency offset. But you can't 
 feed DAC or frequency data into the adev1 tool, since that tool expects phase 
 data only. Make sense?

 The details are that ADEV is based on the 2nd difference in phase, which is 
 the 1st difference in frequency. You have accidentally feed frequency data 
 into a phase calculation and the result is some sort of 3rd difference! This 
 is not what you want.

 The solution is either to integrate your DAC or frequency data so it looks 
 like phase. Or, just use a tool that will take frequency data instead of 
 phase data. Stable32 and TimeLab offer this option. Or you can use adev1f.exe 
 (www.leapsecond.com/tools/) which I just made for you.


 3) To get an accurate ADEV plot you must scale your arbitrary DAC voltage to 
 real Hz. Use the known or measured EFC offset and gain to convert absolute 
 voltage to relative voltage to relative frequency error. This data can then 
 be given to Stable32 (Data Type: Freq), or TimeLab (File data: Frequency 
 difference), or feed directly to the new tool, adev1f.

 Let me know if you have any questions.

 /tvb


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic

[Andrew Rodland]

Bill,

Since I accidentally let the smoke out of my Due, and I just *happen*
to have an UDOO Dual sitting around, I decided to play with it while I
wait for a replacement board to come around.

UDOO ships an ARM version of Arduino IDE 1.5.4, which is a little bit
too old to compile my code properly (I built against 1.5.7), but
compiling the project on another machine with 1.5.7 and shipping the
.bin to the udoo to upload with bossac works just fine. I removed the
call to ether_init() since of course there's no W5100 Ethernet on the
udoo.

On the i.MX side of the UDOO I have Debian installed (UDOObuntu would
work just fine, but it comes with loads and loads of unnecessary
crap). First I tested using http://vanheusden.com/time/rpi_gpio_ntp/
which is a user-space daemon that listens for events from a Linux
/sys/class/gpio device (Due pin 13 maps to Linux gpio40) and writes to
an SHM segment compatible with the ntpd/chrony SHM refclock. That
worked just fine, with about 5us jitter most of the time, but you
could see that it was occasionally quite a bit higher.

Then I worked on getting PPSAPI working. This requires rebuilding the
kernel, but turned out to be relatively easy: there's a pps-gpio
driver in Linux 3.2 that was easily backported to 3.0 just by applying
the patch from LKML, and then it was just a little bit of work to init
the device in the UDOO-specific board init function. My changes can be
found at https://github.com/arodland/Kernel_Unico/compare/ppsapi if
you're interested.

With that in place, and the Rb sufficiently warm (I think) I'm seeing
between 600ns and 1200ns RMS jitter on the PPS refclock as reported by
chrony on the UDOO (pretty good!) and between 3us and 7us RMS jitter
on the UDOO as measured over NTP from my desktop with 64-second
polling, which is 4 or 5 us better than what I could get with the
Due+W5100 combination. I bet at this point half of that figure is
coming from instability on the desktop machine itself and
nondeterministic ethernet switching delay.

I still like the appeal of the bare metal approach, and when I get
my new board (Taijiuino, a Due-alike board that routes the SAM3X's
Ethernet MAC pins) I'm going to keep going with that, but this is
pretty good performance for Linux, I'd say.

Andrew

On Sat, Sep 6, 2014 at 12:06 PM, Bill Dailey docdai...@gmail.com wrote:
 Will add it to my list of projects.  Will touch bases when I get close.

 Sent from my iPad

 On Sep 6, 2014, at 10:18 AM, Andrew Rodland and...@cleverdomain.org wrote:

 Yes, the source is at http://github.com/arodland/Due-GPS-NTP-Server .
 It should be able to run just fine on the Due part of an Udoo, but
 you'll have to come up with a different arrangement for the Ethernet.

 One way would be to use chip-to-chip SPI to make the i.MX side of the
 Udoo act more-or-less like the W5100, translating between serial and
 Ethernet and interrupting the SAM3X when it gets packets.

 Another way would be to run regular ntpd on Linux (or FreeBSD?) on the
 i.MX side but give it a custom refclock driver that syncs to the Due
 (either by locking onto the generated PPS, or by asking the Due to
 timestamp events and reading the timecode back). If this works well,
 it could outperform my setup, since the i.MX is clocked quite a bit
 faster and has its Ethernet MAC on-chip :)

 Andrew

 On Sat, Sep 6, 2014 at 12:08 AM, Bill Dailey docdai...@gmail.com wrote:
 I was wondering if a board like the udoo would help your ntp performance.  
 I have one and would be willing to try this configuration.  Have you posted 
 your source?   I think I got confused as to who was doing this.  I don't 
 have a rubidium but I have a 6T on a breakout and a couple of very good 
 ocxo's (mid 10-13 at 1s) that I could use.  I have about 100 projects going 
 on but a project like this has been on the back burner for awhile.  I have 
 a couple of furies I could test it against also.

 Bill

 Sent from my iPad

 On Sep 5, 2014, at 2:07 PM, Andrew Rodland and...@cleverdomain.org wrote:

 After some productive work, and some frustrating weeks spent fighting
 weird flakiness and needlessly replacing components, only to find that
 the problems went away after I reseated my main power connector, IT
 WORKS!

 Here's where I am now:

 * Main board: Arduino Due (ATSAM3X ARM Cortex-M3 CPU @ 84MHz)
 * Oscillator: Symmetricom X72.
 * GPS: Trimble Resolution T with a cheap Gilsson puck antenna.
 * Ethernet: Wiznet W5100.

 The X72 is used to externally clock one of the ARM's hardware
 timer/counters at 10MHz (I'm not multiplying it up and using it to
 clock the CPU). The same timer timestamps the rising edge of the PPS
 using capture mode, jitter free @ 100ns resolution.

 All the PLL is done digitally using these values and the adjustment is
 sent to the X72 over serial (DDS, 2 ppt resolution).

 After about a day's solid running, the PPS phase stays within +/-
 100ns as measured on the board itself, even out to a PLL tau of 1
 hour, and the frequency adjust

[time-nuts] Arduino Rb NTP server: good news, bad news, a photo

[Andrew Rodland]

I've done some more work on the code, mostly in the area of health
monitoring -- it's able to look at whether the GPS is locked, whether
the Rb is locked, and whether the PLL has a good capture, and decide
accordingly whether to enable 1PPS and whether to report a good lock
on NTP. It will holdover on the Rb if it was previously in an ideal
state and the GPS lock (but nothing else) is lost.

I also tidied things up (relatively speaking), moved them into a case,
and took a picture: anyone who wants to see what the build looks like
can take a look at
https://www.flickr.com/photos/hobbified/14999762988/ .

And then, minutes after taking that picture, I shorted something that
I shouldn't have and fried the Due. I think everything else survived
(I see 1PPS and serial out of the GPS, and 10MHz out of the Rb) but
I'm out of business until I can replace that board, and the supplier
is in Australia.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic

[Andrew Rodland]

Yes, the source is at http://github.com/arodland/Due-GPS-NTP-Server .
It should be able to run just fine on the Due part of an Udoo, but
you'll have to come up with a different arrangement for the Ethernet.

One way would be to use chip-to-chip SPI to make the i.MX side of the
Udoo act more-or-less like the W5100, translating between serial and
Ethernet and interrupting the SAM3X when it gets packets.

Another way would be to run regular ntpd on Linux (or FreeBSD?) on the
i.MX side but give it a custom refclock driver that syncs to the Due
(either by locking onto the generated PPS, or by asking the Due to
timestamp events and reading the timecode back). If this works well,
it could outperform my setup, since the i.MX is clocked quite a bit
faster and has its Ethernet MAC on-chip :)

Andrew

On Sat, Sep 6, 2014 at 12:08 AM, Bill Dailey docdai...@gmail.com wrote:
 I was wondering if a board like the udoo would help your ntp performance.  I 
 have one and would be willing to try this configuration.  Have you posted 
 your source?   I think I got confused as to who was doing this.  I don't have 
 a rubidium but I have a 6T on a breakout and a couple of very good ocxo's 
 (mid 10-13 at 1s) that I could use.  I have about 100 projects going on but a 
 project like this has been on the back burner for awhile.  I have a couple of 
 furies I could test it against also.

 Bill

 Sent from my iPad

 On Sep 5, 2014, at 2:07 PM, Andrew Rodland and...@cleverdomain.org wrote:

 After some productive work, and some frustrating weeks spent fighting
 weird flakiness and needlessly replacing components, only to find that
 the problems went away after I reseated my main power connector, IT
 WORKS!

 Here's where I am now:

 * Main board: Arduino Due (ATSAM3X ARM Cortex-M3 CPU @ 84MHz)
 * Oscillator: Symmetricom X72.
 * GPS: Trimble Resolution T with a cheap Gilsson puck antenna.
 * Ethernet: Wiznet W5100.

 The X72 is used to externally clock one of the ARM's hardware
 timer/counters at 10MHz (I'm not multiplying it up and using it to
 clock the CPU). The same timer timestamps the rising edge of the PPS
 using capture mode, jitter free @ 100ns resolution.

 All the PLL is done digitally using these values and the adjustment is
 sent to the X72 over serial (DDS, 2 ppt resolution).

 After about a day's solid running, the PPS phase stays within +/-
 100ns as measured on the board itself, even out to a PLL tau of 1
 hour, and the frequency adjust stays within 1 ppt when 5-minute
 averaged. I'm collecting data against an outside reference now (PPS
 generated by the board against the PPS of a Spectracom NetClock with
 OCXO option). Too early for graphs, but it looks good.

 On the Ethernet end, things are less good, but still respectable --
 about 10us RMS added jitter. I think a lot of this is introduced by
 the W5100, and I'm working on getting my hands on a board that uses
 the same chip but actually makes use of the onchip Ethernet MAC that
 the Arduino doesn't bother to route, which should help substantially.
 Already it's better than conventional wisdom says NTP gets :)

 Questions I still have:

 1. Should I try using the analog EFC to zero out the amount of
 correction I ask the X72's DDS for? Could reduce jitter in the
 timebase, could just add noise. I suppose I can test this one easily
 enough.

 2. Is there any point in decoding the sawtooth correction from the
 GPS, or in wiring up the PICTIC and using it to measure the GPS offset
 more accurately, when my clock granularity is 100ns anyway? I suppose
 at best I'd be improving my accuracy from +/- 1.5 ticks to +/- 0.5
 ticks.

 3. Anything else I should consider?

 If anyone is curious, code is at
 https://github.com/arodland/Due-GPS-NTP-Server .

 Thanks for following,

 Andrew

 On Tue, Jul 29, 2014 at 12:42 AM, Andrew Rodland
 and...@cleverdomain.org wrote:
 Hi all,

 After a couple years not doing anything except letting it sit in my
 den and provide time for my home network, I've decided to start
 hacking on my hobby project again.

 For reference, what I've got right now is a Freetronics EtherMega
 (ATMega2560-based Arduino clone with integrated W5100 ethernet), wired
 up to a USGlobalSat ET-318-02 (a pretty cheap consumer SiRF-III
 module). It runs totally custom timekeeping, PLL, and NTP protocol
 code. The timebase is the onboard crystal, which I have no way of
 influencing directly, so it basically does DDS, adding or duplicating
 the occasional tick to keep lock. For such a ramshackle collection of
 equipment it does a pretty good job, tracking within around 10us of a
 Spectracom NetClock (and showing less Ethernet-induced jitter than the
 NetClock itself)

 I've been thinking for years about building a next-gen version, and
 sketched a few designs, but I could never quite find a board that I
 wanted to use as the core of it. Well, Freetronics sent me a product
 announcement for their EtherDue board (built around the ATSAM3X, which
 is an ARM Cortex-M3 chip

Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic

[Andrew Rodland]

On Fri, Sep 5, 2014 at 3:07 PM, Andrew Rodland and...@cleverdomain.org wrote:
 1. Should I try using the analog EFC to zero out the amount of
 correction I ask the X72's DDS for? Could reduce jitter in the
 timebase, could just add noise. I suppose I can test this one easily
 enough.

Update on this: well, it works just fine, and I have a usable driver
in my code that integrates the digital correction and pushes it to 0
by adjusting a DAC connected to the X72's EFC.

But, reading the X72 manual a little closer it mentions that the
analog EFC is sampled and has a resolution that happens to be
identical to the resolution available using the digital commands. So,
most likely, this is no C-field adjust at all, but another way of
controlling the DDS, provided for LPRO compatibility and analog
designs. So there's no possible gain for me in doing indirectly what I
can do directly more easily.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] OCXO Voltage Input? (Bob Camp)

[Andrew Rodland]

On Sat, Sep 6, 2014 at 9:13 PM, Hal Murray hmur...@megapathdsl.net wrote:
 What's the mechanism for making spurs with a crystal?


Get the corners nice and pointy and strap it to a boot.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic

[Andrew Rodland]

After some productive work, and some frustrating weeks spent fighting
weird flakiness and needlessly replacing components, only to find that
the problems went away after I reseated my main power connector, IT
WORKS!

Here's where I am now:

* Main board: Arduino Due (ATSAM3X ARM Cortex-M3 CPU @ 84MHz)
* Oscillator: Symmetricom X72.
* GPS: Trimble Resolution T with a cheap Gilsson puck antenna.
* Ethernet: Wiznet W5100.

The X72 is used to externally clock one of the ARM's hardware
timer/counters at 10MHz (I'm not multiplying it up and using it to
clock the CPU). The same timer timestamps the rising edge of the PPS
using capture mode, jitter free @ 100ns resolution.

All the PLL is done digitally using these values and the adjustment is
sent to the X72 over serial (DDS, 2 ppt resolution).

After about a day's solid running, the PPS phase stays within +/-
100ns as measured on the board itself, even out to a PLL tau of 1
hour, and the frequency adjust stays within 1 ppt when 5-minute
averaged. I'm collecting data against an outside reference now (PPS
generated by the board against the PPS of a Spectracom NetClock with
OCXO option). Too early for graphs, but it looks good.

On the Ethernet end, things are less good, but still respectable --
about 10us RMS added jitter. I think a lot of this is introduced by
the W5100, and I'm working on getting my hands on a board that uses
the same chip but actually makes use of the onchip Ethernet MAC that
the Arduino doesn't bother to route, which should help substantially.
Already it's better than conventional wisdom says NTP gets :)

Questions I still have:

1. Should I try using the analog EFC to zero out the amount of
correction I ask the X72's DDS for? Could reduce jitter in the
timebase, could just add noise. I suppose I can test this one easily
enough.

2. Is there any point in decoding the sawtooth correction from the
GPS, or in wiring up the PICTIC and using it to measure the GPS offset
more accurately, when my clock granularity is 100ns anyway? I suppose
at best I'd be improving my accuracy from +/- 1.5 ticks to +/- 0.5
ticks.

3. Anything else I should consider?

If anyone is curious, code is at
https://github.com/arodland/Due-GPS-NTP-Server .

Thanks for following,

Andrew

On Tue, Jul 29, 2014 at 12:42 AM, Andrew Rodland
and...@cleverdomain.org wrote:
 Hi all,

 After a couple years not doing anything except letting it sit in my
 den and provide time for my home network, I've decided to start
 hacking on my hobby project again.

 For reference, what I've got right now is a Freetronics EtherMega
 (ATMega2560-based Arduino clone with integrated W5100 ethernet), wired
 up to a USGlobalSat ET-318-02 (a pretty cheap consumer SiRF-III
 module). It runs totally custom timekeeping, PLL, and NTP protocol
 code. The timebase is the onboard crystal, which I have no way of
 influencing directly, so it basically does DDS, adding or duplicating
 the occasional tick to keep lock. For such a ramshackle collection of
 equipment it does a pretty good job, tracking within around 10us of a
 Spectracom NetClock (and showing less Ethernet-induced jitter than the
 NetClock itself)

 I've been thinking for years about building a next-gen version, and
 sketched a few designs, but I could never quite find a board that I
 wanted to use as the core of it. Well, Freetronics sent me a product
 announcement for their EtherDue board (built around the ATSAM3X, which
 is an ARM Cortex-M3 chip from AVR), I read some specs, and decided to
 dive in.

 I've got a working, tuned-up LPRO-101, and I always figured that my
 next build would desolder the clock crystal and use the Rb as the CPU
 timebase, like most builds I've seen do. But I realized that the
 ATSAM3X is happy to run its timer/counters off of an external clock as
 long as it's less than 1:2.5 the CPU clock. 10MHz fits that bill. I
 lose a little bit on granularity by not letting the CPU multiply that
 up 8x for me, but probably no real change in accuracy. Just feed the
 Rb to a pair of pins and get a register that counts up every 100ns,
 seems simple!

 For locking to the PPS I could do the usual thing and use input
 capture on the timer clocked by the Rb, which would handily timestamp
 the rising edge of the PPS. But I have a couple of PICTIC IIs laying
 around, and I'm a bit tempted to instead use the timer to generate a
 PPS from my board and let the PICTICs compare. Since START has to come
 before STOP I figure I need two of them in parallel, only listen to
 the one that gives a report  0.5 seconds, and which one gives me the
 sign. Does that make sense? Or should I just use one and lock to a
 nonzero offset? I've found surprisingly little material on the tricks
 of using a TIC in a digital GPSDO.

 Finally there's adjusting the Rb. It would be nice to be able to slew
 nice and gently by actually nudging the clock instead of
 adding/dropping them, especially if I have the PICTIC to give me
 precision offsets. I'm not sure whether

Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic

[Andrew Rodland]

Well, my *previous* clock was on the Mega 2560 (an AVR chip, although
admittedly one with more code space and IO than usual). I made some
mention of it back in 2012. It had 500ns timer granularity and no Rb
(just DPLL of a timer running off of the onboard crystal) but it still
managed well enough :)


On Fri, Sep 5, 2014 at 8:34 PM, Chris Albertson
albertson.ch...@gmail.com wrote:
 On Fri, Sep 5, 2014 at 2:28 PM, Ryan Stasel rsta...@uoregon.edu wrote:

 Cool idea though. I've found very few (none) instances of people actually 
 running NTP servers from arduino hardware... most use Raspi or the like.


 Note the Arduino Due has an ARM based CPU inside.   It's not jet the
 old AVR chip.   It is more than enough for NTP.  Arduino is now a WIDE
 range of products all the way for from this is the tiny $3 Chinese
 versions.


 --

 Chris Albertson
 Redondo Beach, California
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Update on my Arduino GPSDO / NTP server - going atomic

[Andrew Rodland]

Hi all,

After a couple years not doing anything except letting it sit in my
den and provide time for my home network, I've decided to start
hacking on my hobby project again.

For reference, what I've got right now is a Freetronics EtherMega
(ATMega2560-based Arduino clone with integrated W5100 ethernet), wired
up to a USGlobalSat ET-318-02 (a pretty cheap consumer SiRF-III
module). It runs totally custom timekeeping, PLL, and NTP protocol
code. The timebase is the onboard crystal, which I have no way of
influencing directly, so it basically does DDS, adding or duplicating
the occasional tick to keep lock. For such a ramshackle collection of
equipment it does a pretty good job, tracking within around 10us of a
Spectracom NetClock (and showing less Ethernet-induced jitter than the
NetClock itself)

I've been thinking for years about building a next-gen version, and
sketched a few designs, but I could never quite find a board that I
wanted to use as the core of it. Well, Freetronics sent me a product
announcement for their EtherDue board (built around the ATSAM3X, which
is an ARM Cortex-M3 chip from AVR), I read some specs, and decided to
dive in.

I've got a working, tuned-up LPRO-101, and I always figured that my
next build would desolder the clock crystal and use the Rb as the CPU
timebase, like most builds I've seen do. But I realized that the
ATSAM3X is happy to run its timer/counters off of an external clock as
long as it's less than 1:2.5 the CPU clock. 10MHz fits that bill. I
lose a little bit on granularity by not letting the CPU multiply that
up 8x for me, but probably no real change in accuracy. Just feed the
Rb to a pair of pins and get a register that counts up every 100ns,
seems simple!

For locking to the PPS I could do the usual thing and use input
capture on the timer clocked by the Rb, which would handily timestamp
the rising edge of the PPS. But I have a couple of PICTIC IIs laying
around, and I'm a bit tempted to instead use the timer to generate a
PPS from my board and let the PICTICs compare. Since START has to come
before STOP I figure I need two of them in parallel, only listen to
the one that gives a report  0.5 seconds, and which one gives me the
sign. Does that make sense? Or should I just use one and lock to a
nonzero offset? I've found surprisingly little material on the tricks
of using a TIC in a digital GPSDO.

Finally there's adjusting the Rb. It would be nice to be able to slew
nice and gently by actually nudging the clock instead of
adding/dropping them, especially if I have the PICTIC to give me
precision offsets. I'm not sure whether the 12-bit DAC on the board
stands any chance of being clean or accurate enough to drive the
LPRO's C-field adjust, or whether I need something external, or
whether I should just locate an Rb with digital adjustment (on a
related note, has the price of surplus Rbs gone up a *lot* lately?
Anyone know why? Can't be hobbyist demand, can it?)

Got a lot of questions to answer, but I'm ready to start building and
learning again. :)
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] zero crossing of venus

[Andrew Rodland]

Jim Lux jimlux@... writes:

 
 On 6/5/12 5:20 PM, Tom Van Baak wrote:
  Attached are two snapshots of a NASA live feed -- an interesting reminder 
about the difficulty measuring
 timing signals with great precision.
 
  When you look closely, the leading edge of the sun is rather ill-defined, 
not unlike many 1PPS pulses. I
 suppose with enough photos, modeling, and image processing one could pinpoint 
when the transit (zero
 crossing) really occurs to great precision. Does anyone know more details how 
this is done? Is the
 state-of-the-art at the millisecond level? microsecond? nanosecond?
 
  Thanks,
  /tvb
 
 
 or do something like compare the centroid of venus to centroid + 
 radius of sun (or segment thereof.. )
 
 it's pretty easy to get 0.1 pixel centroid precision, from what the star 
 tracker, tiny moon finder folks tell me.

Drifting off topic, but the (apparent) radius of Venus is actually significant
here, being about 1 minute of arc — about 1/30th the apparent radius of the Sun.
In the case of the current transit of Venus, there are 18 minutes between the
time when the leading edge of Venus touches the Sun's disc from the outside, and
the time when the trailing edge of Venus touches the Sun's disc from the inside.

So if you want to talk precision, don't treat Venus as a point. It's too nearby
for that.

Andrew


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] PICTIC II ready-made?

[Andrew Rodland]

Hal Murray hmurray@... writes:

 
 
 albertson.chris@... said:
  2) The IDE is written in Java and is portable.  It is truly identical on 
all
  platforms.  Yes it uses gcc but the end user never has to deal with gcc or
  even know what gcc is.  Same with saving your code, hit just puts it some
  place and keeps track of it 
 
 Do I have to use their particular style/GUI?  Or can I drive it from make, 
 mixing in pieces I like?
 

You can use make, as does my project. In fact, I have a system that compiles
the bulk of the project twice; once for the Arduino, and once in a simulator
harness where I can test things like the PLL response.


 How is the documentation on the tool chain and libraries?  Are their good man 
 pages?
 

The toolchain is of course avr-gcc and avr-binutils, and the library is
mostly avr-libc, which is very well documented; the remainder is the Arduino
libraries, which are in C++ and have mediocre (but existent, at least)
documentation. I'd like to point out that using the Arduino libs is 
*optional*; while the main target audience certainly will be using them,
there's nothing about the hardware that prevents you from writing code in
plain C and uploading it, or picking and choosing which parts of a project
will make use of the Arduino libs and which will access the bare metal. 
Again, I've done this with my project. The Serial library is pleasant enough
to use; the Ethernet is marginal (no interrupt support, but I had an easier
time hacking around that than attempting to rewrite the driver); the timing 
code is of course useless for my purposes so I stay away from it.
I never call attachInterrupt(), which involves a trampoline, but instead
declare my own ISRs -- the mixing is mostly unproblematic. It's been pretty
pleasant for me overall.

Andrew


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] PICTIC II ready-made?

[Andrew Rodland]

I've been having a lot of fun with this time-nut stuff over the past year or
so, and I'm thinking about going atomic in the next year (GPSDRbO), but I'm
a microprocessor kind of guy, and I have incredibly clumsy hands with
electronics and soldering. As much, I'm wondering:

Would anyone be willing to sell (or loan for an extended period) one or two
ready-to-go PICTIC IIs within the United States? I realize this may be rude
to ask since it's a hobby project, but what can I say? All I want it for is
to further my own hobby project.

Thanks,

Andrew



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Rigol scopes

[Andrew Rodland]

 lstoskopf@... writes:

 
 I bought one of the 50 MHz versions at Dayton last year.  OK for my needs.
 Not mentioned here is that the difference between the 50 and 100 MHz scopes
 is software control of roll off on  the input.  I haven't done it,
 but procedure was available on the WEB on how to spoof the software.
 
 N0UU

On the other hand, the prices have dropped since that procedure came out,
with the 100MHz model going for what the 50MHz used to cost, and the 50MHz
selling for about 80% of the price of the 100MHz. Those who want to avoid
the hassle might prefer to just buy the DS1102E directly. It's really
pretty decent, for what it is, and the interface is not nearly as bad as it
could be.

Andrew


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] FPGA GPSDO (Was: Re: NTP jitter with Linux)

[Andrew Rodland]

Chris Albertson albertson.chris@... writes:

 
 On Fri, Apr 6, 2012 at 9:41 PM, Andrew Rodland andrew@... wrote:
 
  Another option would be building something on an FPGA. This would be a
  considerable stretch for me, since I've never done FPGA work, but if I build
  from the ground up, I can have *very* tight control over things that are 
chosen
  for me with a micro controller.
 
 A compromise is to find a soft core for the FPGA.  This is a CPU
 implemented in FPGA and then it runs software just like a real CPU.
  This would let you move your micro controller based be sign over to
 the FPGA quickly.   After that you can implement some specialized
 peripherals that do time stamping
 
 How does the performance of the Arduino based NTP compare with what
 you could do with Linux on (say) and Atom or ARM processor?

Pretty well, I think. A PPS generated by my board shows an RMS absolute jitter 
of 174ns compared to a Spectracom 9183, which is almost impossibly good 
considering that all the timing is done off of a 2MHz clock.

As measured from the NTP side, the performance is diluted a lot by the fact 
that 
the W5100 ethernet chip has unknown and unpredictable delays, but it still 
comes 
back with a jitter of 20us (possibly better — the box I'm using to measure the 
NTP is a Linux machine that isn't really a timing champ. Wish I still had my 
net4801.)

Andrew


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] FPGA GPSDO (Was: Re: NTP jitter with Linux)

[Andrew Rodland]

Azelio Boriani azelio.boriani@... writes:

 
 On a side note, speaking of deterministic systems, why has no one built a
 GPSDO with an FPGA yet? Or an NTP server? :)
 
 Yes, I have: I have a GPSDO entirely on a 50Kgates FPGA (Spartan3 XC3S50)
 without microprocessor. GPS is the iLotus M12M and OCXO is a Morion MV201,
 the DAC is... well, not exactly the best choice but it is an AD5660 16bit
 only, anyway it works.

I'd be interested in hearing more about this. For about the past year I've been 
building an NTP server on an Arduino (ATMega2560 microcontroller, WizNet W5100 
ethernet/TCP/IP offload engine, boring off-the-shelf 16MHz quartz crystal). 
Nowadays it's nearing completion (meaning I've hit the limits of the accuracy I 
can get with this setup) and I've been thinking about what I can do next to 
make 
it better.

One option is keeping the AVR platform, but building a custom board instead of 
using the Arduino, and disciplining an OCXO in proper GPSDO fashion instead of 
the digital frequency synthesis that I'm doing now. This would be interesting 
for the pure timekeeping aspect, although it wouldn't improve the accuracy of 
the NTP server very much.

Another option would be building something on an FPGA. This would be a 
considerable stretch for me, since I've never done FPGA work, but if I build 
from the ground up, I can have *very* tight control over things that are chosen 
for me with a microcontroller. I can timestamp Ethernet frames while they're 
still coming in from the wire, and timestamp outgoing NTP packets at the last 
possible moment; I can make delays pretty much as deterministic as I want; I 
can 
control counter widths and divisors, and interrupt priorities, etc. It's really 
fascinating and I think at some time I'd like to try it.

Andrew


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.