DCF77 & PPS

[folkert]

Hi,

Now that my two servers have a garmin 18x lvc connected to them, their
time keeping is nice.

E.g. this one:

remote refid st t when poll reach delay offset jitter
o127.127.20.0 .GPS. 0 l 6 16 377 0.000 -0.006 0.003
[ other clocks skipped for brievety ]

They can be reached from the internet at:
- clock1.trustedtimestamping.com ipv4 & ipv6
- clock2.trustedtimestamping.com ipv6 only <- I had to restart ntpd on
that system 10 minutes ago because I confused ntpd by opening the
serial via which the gps is connected accidently with an other
program, so it has to settle

Both systems run Linux. Clock1 kernel 3.2 and clock2 runs 2.6.38.

Without ntpd + gps it looses minutes per day (altough when I checked
minutes ago the drift was only 13.637 ppm?!).

I used to also have an MSF receiver but a couple of years the radio
transmitter in England was replaced by a weaker one so I receive mostly
noise now.

Now that it works, it is somewhat boring.
So I got my DCF77 clock from the attic and decided to use it different
then how I'm supposed to use it: as a PPS source! I figured (inspired by
http://remco.org/index.php/2008/06/09/dcf77-pps-experiments-with-a-dcf77-radio-module-using-ntpd/
).
As a quick test I hacked the testdcf.c to show the number of
milliseconds the clock was at when it had received a bit. If I remember
correctly DCF77 sends 60 bits per minute so each bit should be at a
second edge. I expected either a small constant difference or values
that would be over the whole -0.5s ... 0.5s band.
The result was neither! From visual inspection it looked as if only 3 or
4 different offsets were registered. So I ran 3 tests where I took 120
offset-samples, masked of the microseconds and checked how often each
offset occured:

test run 1:
1 251
17 255
38 259
37 263
22 267
5 271

test run 2:
1 251
10 255
1 257
43 259
1 261
44 263
17 267
3 271

test run 3:
2 255
18 259
60 263
32 267
8 271

Column 1: number of occurences, column 2: the offset.

So my guestimate is that 259 and 263 are the values to look for and I
should ignore the others so that I don't confuse ntpd.

What do you guys think?


(Regarding the 250+ ms offset: the distance of my house to Mainflingen
in Germany (where the DCF77 atomic clock is located) is +/- 374.766km (I
live in Gouda, the Netherlands), so that is an offset of +/- 1.25012s.)


Folkert van Heusden

--
----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[Bob Camp]

Hi

Ummm…. errrrr….. I think you slipped a decimal point...

On Mar 15, 2013, at 8:49 PM, folkert <folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org> wrote:

> Hi,
>
> Now that my two servers have a garmin 18x lvc connected to them, their
> time keeping is nice.
>
> E.g. this one:
>
> remote refid st t when poll reach delay offset jitter
> o127.127.20.0 .GPS. 0 l 6 16 377 0.000 -0.006 0.003
> [ other clocks skipped for brievety ]
>
> They can be reached from the internet at:
> - clock1.trustedtimestamping.com ipv4 & ipv6
> - clock2.trustedtimestamping.com ipv6 only <- I had to restart ntpd on
> that system 10 minutes ago because I confused ntpd by opening the
> serial via which the gps is connected accidently with an other
> program, so it has to settle
>
> Both systems run Linux. Clock1 kernel 3.2 and clock2 runs 2.6.38.
>
> Without ntpd + gps it looses minutes per day (altough when I checked
> minutes ago the drift was only 13.637 ppm?!).
>
> I used to also have an MSF receiver but a couple of years the radio
> transmitter in England was replaced by a weaker one so I receive mostly
> noise now.
>
> Now that it works, it is somewhat boring.
> So I got my DCF77 clock from the attic and decided to use it different
> then how I'm supposed to use it: as a PPS source! I figured (inspired by
> http://remco.org/index.php/2008/06/09/dcf77-pps-experiments-with-a-dcf77-radio-module-using-ntpd/
> ).
> As a quick test I hacked the testdcf.c to show the number of
> milliseconds the clock was at when it had received a bit. If I remember
> correctly DCF77 sends 60 bits per minute so each bit should be at a
> second edge. I expected either a small constant difference or values
> that would be over the whole -0.5s ... 0.5s band.
> The result was neither! From visual inspection it looked as if only 3 or
> 4 different offsets were registered. So I ran 3 tests where I took 120
> offset-samples, masked of the microseconds and checked how often each
> offset occured:
>
> test run 1:
> 1 251
> 17 255
> 38 259
> 37 263
> 22 267
> 5 271
>
> test run 2:
> 1 251
> 10 255
> 1 257
> 43 259
> 1 261
> 44 263
> 17 267
> 3 271
>
> test run 3:
> 2 255
> 18 259
> 60 263
> 32 267
> 8 271
>
> Column 1: number of occurences, column 2: the offset.
>
> So my guestimate is that 259 and 263 are the values to look for and I
> should ignore the others so that I don't confuse ntpd.
>
> What do you guys think?
>
>
> (Regarding the 250+ ms offset: the distance of my house to Mainflingen
> in Germany (where the DCF77 atomic clock is located) is +/- 374.766km (I

Last time I checked the speed of light was right around 300,000 KM / second (299,792.xxx). More or less it should take DCF77 a bit over 1 milliseconds (not 1 second) to get to you.

> live in Gouda, the Netherlands), so that is an offset of +/- 1.25012s.)
>
>
> Folkert van Heusden
>
> --
> ----------------------------------------------------------------------
> Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

Bob

[Chris Albertson]

Something is wrong. The delays you are seeing are NOT caused by
propagation delay unless you are living on the moon.

I think it is more likely your NTP server is misconfigured and is off
by one. But then you'd notice that you do not track the Internet
pool servers. Must be something else. As for why there are only a
few fixed offsets, my guess is there are fixed delays in your
measurement system. You'd have to tell us EXACTLY how you are
measuring.




On Fri, Mar 15, 2013 at 5:49 PM, folkert <folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org> wrote:
> Hi,
>
> Now that my two servers have a garmin 18x lvc connected to them, their
> time keeping is nice.
>
> E.g. this one:
>
> remote refid st t when poll reach delay offset jitter
> o127.127.20.0 .GPS. 0 l 6 16 377 0.000 -0.006 0.003
> [ other clocks skipped for brievety ]
>
> They can be reached from the internet at:
> - clock1.trustedtimestamping.com ipv4 & ipv6
> - clock2.trustedtimestamping.com ipv6 only <- I had to restart ntpd on
> that system 10 minutes ago because I confused ntpd by opening the
> serial via which the gps is connected accidently with an other
> program, so it has to settle
>
> Both systems run Linux. Clock1 kernel 3.2 and clock2 runs 2.6.38.
>
> Without ntpd + gps it looses minutes per day (altough when I checked
> minutes ago the drift was only 13.637 ppm?!).
>
> I used to also have an MSF receiver but a couple of years the radio
> transmitter in England was replaced by a weaker one so I receive mostly
> noise now.
>
> Now that it works, it is somewhat boring.
> So I got my DCF77 clock from the attic and decided to use it different
> then how I'm supposed to use it: as a PPS source! I figured (inspired by
> http://remco.org/index.php/2008/06/09/dcf77-pps-experiments-with-a-dcf77-radio-module-using-ntpd/
> ).
> As a quick test I hacked the testdcf.c to show the number of
> milliseconds the clock was at when it had received a bit. If I remember
> correctly DCF77 sends 60 bits per minute so each bit should be at a
> second edge. I expected either a small constant difference or values
> that would be over the whole -0.5s ... 0.5s band.
> The result was neither! From visual inspection it looked as if only 3 or
> 4 different offsets were registered. So I ran 3 tests where I took 120
> offset-samples, masked of the microseconds and checked how often each
> offset occured:
>
> test run 1:
> 1 251
> 17 255
> 38 259
> 37 263
> 22 267
> 5 271
>
> test run 2:
> 1 251
> 10 255
> 1 257
> 43 259
> 1 261
> 44 263
> 17 267
> 3 271
>
> test run 3:
> 2 255
> 18 259
> 60 263
> 32 267
> 8 271
>
> Column 1: number of occurences, column 2: the offset.
>
> So my guestimate is that 259 and 263 are the values to look for and I
> should ignore the others so that I don't confuse ntpd.
>
> What do you guys think?
>
>
> (Regarding the 250+ ms offset: the distance of my house to Mainflingen
> in Germany (where the DCF77 atomic clock is located) is +/- 374.766km (I
> live in Gouda, the Netherlands), so that is an offset of +/- 1.25012s.)
>
>
> Folkert van Heusden
>
> --
> ----------------------------------------------------------------------
> Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



--

Chris Albertson
Redondo Beach, California

[Hal Murray]

folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org said:
> So my guestimate is that 259 and 263 are the values to look for and I should
> ignore the others so that I don't confuse ntpd.

That doesn't make sense to me, probably because I don't understand your data
collection environment and/or maybe it's dong something strange.

I see several things that I don't understand. One is the big offset. The
second is the 4 ms steps between sample buckets.

Do you have a scope? The simplest way to see what's going on would be to
trigger on the PPS from the GPS unit and look at the DCF77 signal.

> The result was neither! From visual inspection it looked as if only 3 or 4
> different offsets were registered. So I ran 3 tests where I took 120
> offset-samples, masked of the microseconds ...

How did you mask off the microseconds? Did you do that in binary or drop the
right part of an ascii string? If you masked in binary, maybe you got 2
extra bits.


There are 2 parts to decoding something like the DCF77 signal. One is to get
an accurate marker for the PPS signal. The other is to figure out the time
for each PPS by decoding the pattern of pulse widths. You should be able to
see the pulse widths if you capture both sides of the PPS signal.

One common way to get a large/strange offset is to use the wrong edge of the
PPS signal. If that's what was happening, I'd expect to see several clumps
of offsets corresponding to the different pulse widths. I only see one broad
clump.

I wouldn't worry about confusing ntpd, at least not at this level. It has a
noise reduction mechanism. It puts all the samples into a fifo. When the
driver (PPS/Atom or SHM or ...) gets polled, ntpd sorts the buffer then
discards 1/3 of the samples as (potentially crazy) outliers.

Other things to try:
Unplug and/or turn off GPS.
Unplug and/or turn off DCF77.



--
These are my opinions. I hate spam.

[folkert]

Silly 1,2 instead of 0,0012 fudge: indeed a mistake.

How I measured when I wrote the first message:
- I waited for a bit to be received
- exact after the bit was received and "read" by my testprogram, I
would check what the offset was to a second. e.g 13:45:12.456 would
be an offset if 456ms
- the linux system returns in microseconds, I would simple discard
those 3 extra digits. eg. 13:45:12.456987 would become .456

Saturday night I "connected" the testprogram to NTP: when a bit was
received, I would check how many microseconds "after the second" the
system was and send that to NTPd (like above but doing microseconds
here).
After a couple of days this gives:

remote refid st t when poll reach delay offset jitter
==============================================================================
o127.127.20.1 .GPS. 0 l 1 16 377 0.000 -0.001 0.002
-192.168.64.1 .GPS. 1 u 52 64 376 0.114 -0.021 0.021
x192.168.62.129 SHM(0) 2 u 49 64 37 2.080 154.251 82.784
x82.95.142.92 129.70.132.36 3 u 25 64 377 36.867 78.199 1.989
x127.127.28.0 .SHM0. 1 l 5 8 377 0.000 -263.48 3.437 <---
-194.109.22.18 193.79.237.14 2 u 18 64 377 17.321 -3.490 0.468
-194.109.20.18 193.79.237.14 2 u 12 64 377 17.292 -3.296 0.776
*193.79.237.14 .PPS. 1 u 20 64 377 19.607 -2.342 0.294
+192.87.36.4 .GPS. 1 u 64 64 377 21.556 -2.370 0.730
+134.221.205.12 .PPS. 1 u 40 64 377 20.372 -2.363 0.441
-172.29.0.11 134.221.205.12 2 u 42 64 377 18.350 -2.479 6.184

The 127.127.28.0 (SHM0) source is the dcf77 pps source.
192.168.62.129 does the same trick by the way using an MSF receiver but
lets ignore that for now.

Allan deviation plot:
http://keetweej.vanheusden.com/~folkert/SHM0-peerstats.2013w10.png

Offset plot:
http://keetweej.vanheusden.com/~folkert/SHM0-offset.png
last 800 measurements:
http://keetweej.vanheusden.com/~folkert/SHM0-offset-last800.png

> > So my guestimate is that 259 and 263 are the values to look for and I should
> > ignore the others so that I don't confuse ntpd.
> That doesn't make sense to me, probably because I don't understand your data
> collection environment and/or maybe it's dong something strange.

Hopefully my explanation above makes it more clear.

While writing this I got an epiphany: I think I know what causes the
0.26s offset: the serial port is configured at 50Bps, 8, n, 1. So each
byte takes 10 bits (8 data-, 1 start- and 1 stop bit). So a maximum of 5
characters per second or 0,2s per character. Each DCF77 bit is signalled
as a byte to the system, so that explains 0,2s of the offset seen. Maybe
the receiver needs another 0,6s +/- to convert the received bits into
something it can transmit over the TX line of the serial port.

What I should do, is open the casing of the receiver and connect the
signal coming from the antenna to the DCD pin of that serial port.

> Do you have a scope? The simplest way to see what's going on would be to
> trigger on the PPS from the GPS unit and look at the DCF77 signal.

I don't have one but in a couple of weeks it is my birthday so maybe
then.

> > The result was neither! From visual inspection it looked as if only 3 or 4
> > different offsets were registered. So I ran 3 tests where I took 120
> > offset-samples, masked of the microseconds ...
> How did you mask off the microseconds? Did you do that in binary or drop the
> right part of an ascii string? If you masked in binary, maybe you got 2
> extra bits.

I did it the ascii way.
E.g.:
value = floor(value * 1000.0) / 1000.0;

> There are 2 parts to decoding something like the DCF77 signal. One is to get
> an accurate marker for the PPS signal. The other is to figure out the time
> for each PPS by decoding the pattern of pulse widths. You should be able to
> see the pulse widths if you capture both sides of the PPS signal.

Yes, I read this weekend that 0 and 1 are 100ms versus 200ms.

> One common way to get a large/strange offset is to use the wrong edge of the
> PPS signal. If that's what was happening, I'd expect to see several clumps
> of offsets corresponding to the different pulse widths. I only see one broad
> clump.

It's probably the naive way of measuring (see my epiphany).

> I wouldn't worry about confusing ntpd, at least not at this level. It has a
> noise reduction mechanism. It puts all the samples into a fifo. When the
> driver (PPS/Atom or SHM or ...) gets polled, ntpd sorts the buffer then
> discards 1/3 of the samples as (potentially crazy) outliers.

Thanks & regards,


Folkert van Heusden

--
www.vanheusden.com/multitail - win een vlaai van multivlaai! zorg
ervoor dat multitail opgenomen wordt in Fedora Core, AIX, Solaris of
HP/UX en win een vlaai naar keuze
----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[Hal Murray]

folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org said:
> I own a couple of GPS modules (garmin 18(x) lvc) which I would like to use
> as a time-source. Now my server already has such a module connected (via
> gpsd and a pci rs232 interface) and my raspberry pies too (adafruit modules)
> so I'm looking for a low-power computer with a complete RS232 connector
> (DB9) with all signals attached so that I can feed it a PPS. Also real RS232
> so that I don't have to mess with resistors and such.

I'm not sure what you mean by "resistors and such". At a minimum, you will
have to do some wiring to provide power.

> I'm considering either this one:
> http://www.antratek.com/nanosg20-with-128-mb-sdram-and-512-mb-flash
> or this one:
> http://www.antratek.com/ontwikkelboard-met-cirrus-logic-ep9302
> What do you guys think: would they be any good for
> timekeeping? Known issues?

Both web sites have schematics.

On the Olimex board, there is nothing connected to the PPS input pin. It is
a dev board, so it should be easy to connect up power and PPS.

On the Ledato board, there are level shifters on all the signal pins. One of
the connectors has a slot for a resistor to supply power on RI.

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

I think there are 2 basic approaches.

One is to use a board like the above or others that have been discussed here.
You will probably have to do some fiddling. They don't have a real disk so
you may not want to do a lot of logging. This is the lowest power approach.

The other is to use an embedded PC. If you get one with an Atom chip, the
power can be pretty low. I have one (with disk) that uses 14 watts.

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

There are a handful of tangled considerations:

Cost of initial gear and cost of power:
You can get refurbished PCs for under $200. An embedded type PC with an
Atom chip will pay for itself in under a year.

How much fiddling do you have to do to the hardware?
How much fiddling do you have to do to the software?
Using a real PC often simplifies both.
If you can find a HOWTO type web page, that may be good enough.

PCs use display and keyboard/mouse to get off the ground. Low end boards
without a display probably default to using an RS-232 port to get off the
ground. Once you get setup, you can probably run both over the Ethernet.

Some PCI-RS232 cards have a jumper to supply power on one of the signal pins.
They were intended to power things like scanners before USB. (I'll fish out
some details if anybody wants them.) You still have to solder the wires from
the GPS hockey-puck to a DB-9 connector.



--
These are my opinions. I hate spam.

[Chris Albertson]

I think the problem is that if you are not clear about what your "big
picture" goal is then yu only get a bunch od not so helpful comments like
"use this is worked for me.".

So what exactly do you want. Are you looking for a very low power, say
under 5W server. Something that is very easy to set up and maintain.
You have two GPSes, will both go on the same NTP server or do you wnt to
set up two NTP servers

>From the looks of it NTP will run on either ARM or Atom. The Atom costs
about $100 and ARM can be as low as $40.

[folkert]

> I think the problem is that if you are not clear about what your "big
> picture" goal is then yu only get a bunch od not so helpful comments like
> "use this is worked for me.".
> So what exactly do you want. Are you looking for a very low power, say
> under 5W server. Something that is very easy to set up and maintain.
> You have two GPSes, will both go on the same NTP server or do you wnt to
> set up two NTP servers

It must be a system < 5 watt, so probably an ARM system. It will only
run ntpd so not much ram is required.
It will have 10 (ntp-)clients so a very powerfull processor is not
required.


Folkert van Heusden

--
----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[Chris Albertson]

OK, good specs. The The Raspberry Pi should work. They cost about $40
each.

The Atom is about $100 and has just over your 5 watt limit but is very much
easier to set up, becuase it is just a standard PC and can run a "normal"
version of Linux or BSD Unix.

I'd go with a Pi for NTP but if you need any other kind of server, perhaps
a NAS for backups then go with Atom and it can run multiple services and
still keep very good time. I had one doing this until recently when the
mainboard failed after years of running 24x7


It must be a system < 5 watt, so probably an ARM system. It will only
> run ntpd so not much ram is required.
> It will have 10 (ntp-)clients so a very powerfull processor is not
> required.
>
>
> Folkert van Heusden
>
> --
> ----------------------------------------------------------------------
> Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Attila Kinali]

On Fri, 28 Jun 2013 11:28:44 +0200
folkert <folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org> wrote:

> It must be a system < 5 watt, so probably an ARM system. It will only
> run ntpd so not much ram is required.
> It will have 10 (ntp-)clients so a very powerfull processor is not
> required.

Get a board with a modern uC that has an ethernet interface and
32bit capture/compare unit, and a cheap, low power gps module and
you get to <1W including all losses.

eg:
https://www.olimex.com/Products/ARM/ST/STM32-E407/
plus
http://www.ebay.com/itm/Ublox-NEO-6M-GPS-Module-w-Antenna-For-Arduino-MWC-IMU-Multi-Rabbit-Flight-A100-/261165592580

As OS i would suggest using nuttx or similar to get all the ground work.
I've also seen some uC ntp implementations, but i cannot find them currently.

Oh.. and if you want to go the linux way and use a Raspberry Pi.. just dont!
Use a Beaglebone black instead. It uses less power and is easier to deal with.
Not to mention that you dont have all those USB related problems.

There has been some discussion about using the BBB as an NTP server in
the past weeks on this list.

Attila Kinali

--
The people on 4chan are like brilliant psychologists
who also happen to be insane and gross.
-- unknown

[David J Taylor]

From: Attila Kinali
[]
Oh.. and if you want to go the linux way and use a Raspberry Pi.. just dont!
Use a Beaglebone black instead. It uses less power and is easier to deal
with.
Not to mention that you dont have all those USB related problems.
[]
Attila Kinali
===========================================

I've built three Raspberry Pi stratum-1 NTP servers:

http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

one of which has both a Wi-Fi dongle and a DVB TV receiver stick attached,
and on none of these have I seen any USB problems. I'm using a 5.25 V 2A
power supply from ModMyPi.com. You can view the timekeeping accuracy here:

http://www.satsignal.eu/mrtg/performance_ntp.php

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org

[Dennis Ferguson]

On 30 Jun, 2013, at 08:50 , David J Taylor <david-taylor-***@public.gmane.org> wrote:
> From: Attila Kinali
> []
> Oh.. and if you want to go the linux way and use a Raspberry Pi.. just dont!
> Use a Beaglebone black instead. It uses less power and is easier to deal with.
> Not to mention that you dont have all those USB related problems.
> []
> Attila Kinali
> ===========================================
>
> I've built three Raspberry Pi stratum-1 NTP servers:
>
> http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
>
> one of which has both a Wi-Fi dongle and a DVB TV receiver stick attached, and on none of these have I seen any USB problems. I'm using a 5.25 V 2A power supply from ModMyPi.com. You can view the timekeeping accuracy here:
>
> http://www.satsignal.eu/mrtg/performance_ntp.php

You aren't necessarily showing the part where the Raspberry Pi is a bit
weak, though. How well do clients which receive their time via the
USB ethernet interface do?

The Beaglebone Black has about three advantages going for it in this
application:

- The ARM CPU is about twice as fast as the Raspberry Pi's for about
the same power consumption (I'm not sure this is a particular advantage
for NTP, however, so I won't count it).

- The Ethernet MAC core is built into the SOIC, and tightly coupled to it,
so packet traffic doesn't have to sit waiting for the USB scheduler to
get around to doing something with it.

- The Ethernet MAC core also provides fairly good, complete IEEE1588
support. This is not of direct use to NTP but does provide a way to
calibrate the software timestamps which NTP produces and consumes to
better match when the packets arrive from and are transmitted by the actual
hardware. I.e. you can measure the typical difference between hardware
and software inbound timestamps (measuring interrupt latency), and hardware
and software outbound timestamps (measuring the processing time spent in the
outbound network stack) for PTP UDP packets, and then use these results
to improve the symmetry of software timestamps for NTP UDP packets. There
is no way I know of to measure this without the IEEE 1588 support (and the
outbound number in particular is often big enough to deserve correction).

- The TI SOIC also has a hardware timestamp capture peripheral (look for
eCap in the documentation) which can capture PPS edge times with
single-digit-nanosecond accuracy. That's a couple of orders of magnitude
better than interrupt sampling and eliminates the jitter of the latter
measurements.

For a $5-$10 difference in price for the board I think these are worth it.
The RPI makes a fine, low-power replacement for Intel hardware for this,
but the Beaglebone Black has the raw material to do significantly better at
this than either of them. The only problem with the Beaglebone is that it
is not as popular as the Raspberry Pi, so making use of the former is going
to require one to do more work on one's own to take advantage of it.

Dennis Ferguson

[Chris Albertson]

So yu are getting the Beaglebone Black for about $45. Do you have a link
to a supplier. I thought they were at least twice that price.

On Sun, Jun 30, 2013 at 1:43 PM, Dennis Ferguson <
dennis.c.ferguson-***@public.gmane.org> wrote:

>
>
> For a $5-$10 difference in price for the board I think these are worth it.



Chris Albertson
Redondo Beach, California

[David J Taylor]

From: Dennis Ferguson
[]
You aren't necessarily showing the part where the Raspberry Pi is a bit
weak, though. How well do clients which receive their time via the
USB ethernet interface do?

The Beaglebone Black has about three advantages going for it in this
application:
[]
For a $5-$10 difference in price for the board I think these are worth it.
The RPI makes a fine, low-power replacement for Intel hardware for this,
but the Beaglebone Black has the raw material to do significantly better at
this than either of them. The only problem with the Beaglebone is that it
is not as popular as the Raspberry Pi, so making use of the former is going
to require one to do more work on one's own to take advantage of it.

Dennis Ferguson
======================================

Dennis,

I've tested with 75 clients (simulated load) and not seen any problems with
the Raspberry Pi's own time keeping. I'll set my FreeBSD PC to look at the
the three Raspberry Pi cards and report back....

A first report is that the offset is shown as 0.091 ms from one RPi and
0.065 ms from the second, and 0.056 ms on the third RPi which is operating
over Wi-Fi. This is far better than I see from any Internet servers on my
Cable Modem ISP service. Jitter is 0.022 and 0.027 ms for the LAN connected
devices, again much better than the best Internet device which shows 0.110
ms (at what is the middle of the night for many - 06:00 clock time here).

Here the two units are similarly priced, so you can take your choice.

There is one write-up here:

https://groups.google.com/forum/#!topic/beagleboard/bU_xZ9tWoiA

for using the BeagleBone Black as an NTP server, but he seems to have an
offset of -0.281 ms from his PPS source, which is rather high.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org

[David J Taylor]

How do folks think that the Odroid/U2 might compare?

http://www.hardkernel.com/renewal_2011/products/prdt_info.php

More expensive than Raspberry Pi or BeagleBone black, but higher
performance?

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org

[Bob Camp]

Hi

Is there a serial port on that board? NTP with USB serial is a bit clunky.

Bob


On Jul 1, 2013, at 6:57 AM, David J Taylor <david-taylor-***@public.gmane.org> wrote:

> How do folks think that the Odroid/U2 might compare?
>
> http://www.hardkernel.com/renewal_2011/products/prdt_info.php
>
> More expensive than Raspberry Pi or BeagleBone black, but higher performance?
>
> Cheers,
> David
> --
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-taylor-***@public.gmane.org
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

[David J Taylor]

Hi

Is there a serial port on that board? NTP with USB serial is a bit clunky.

Bob
===========================================

Good point! I don't see one on that board, but the X2 has GPIO ports.
Getting more expensive again, though....

http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135235611947&tab_idx=2

David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org

[Bob Camp]

Hi

For a lot of what we do, having a board with 16 GPIO's and a couple of UART's pinned out is probably more important than 1.2 vs 1.7 GHz on the CPU(s). A lot of the Korean and Chinese boards seem to be aimed at driving a TV for streaming video. All the other stuff is probably still there. Getting at it on the bottom of a BGA - not so easy. The i/o connector on the Pi has it's issues, but at least it's there.

Of course for timing applications, having a couple of timers and some high speed capture pins is the ultimate goal. Externally accessible >=32 bit timers driven off a > 1 GHz clock would also be nice. I suspect all that's going to be a bit hard to find in a cheap generic board. Since all of these boards run a fairly complex OS, we'd also need kernel code to support them ...

Bob

On Jul 1, 2013, at 8:58 AM, "David J Taylor" <david-taylor-***@public.gmane.org> wrote:

> Hi
>
> Is there a serial port on that board? NTP with USB serial is a bit clunky.
>
> Bob
> ===========================================
>
> Good point! I don't see one on that board, but the X2 has GPIO ports. Getting more expensive again, though....
>
> http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135235611947&tab_idx=2
>
> David
> --
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-taylor-***@public.gmane.org
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

[Chris Albertson]

For a few dollars LESS you can get an Intel dual-core Atom board. It is a
standard PC motherboard. These can run a file server, a web server, SSH
and NTP all at the same time and have about 90% idle time on the CPU.
(Running those other processes does not effect NTP.)
Intel-BOXD2500HN-Dual-Core-Mini-ITX-Motherboard<http://www.amazon.com/Intel-BOXD2500HN-Dual-Core-Mini-ITX-Motherboard/dp/B007BHTMX6/ref=sr_1_5?ie=UTF8&qid=1372689454&sr=8-5&keywords=intel+atom>

Those tiny Arm boards are best until the price gets about about $45. Above
that I think they are not a great value.


On Mon, Jul 1, 2013 at 3:57 AM, David J Taylor <
david-taylor-***@public.gmane.org> wrote:

> How do folks think that the Odroid/U2 might compare?
>
> http://www.hardkernel.com/**renewal_2011/products/prdt_**info.php<http://www.hardkernel.com/renewal_2011/products/prdt_info.php>
>
> More expensive than Raspberry Pi or BeagleBone black, but higher
> performance?
>
>
> ______________________________**_________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/**
> mailman/listinfo/time-nuts<https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[folkert]

Yes but how much power do they use?
These arm boardjes are < 5 watt, some even 1 watt.


On Mon, Jul 01, 2013 at 07:43:49AM -0700, Chris Albertson wrote:
> For a few dollars LESS you can get an Intel dual-core Atom board. It is a
> standard PC motherboard. These can run a file server, a web server, SSH
> and NTP all at the same time and have about 90% idle time on the CPU.
> (Running those other processes does not effect NTP.)
> Intel-BOXD2500HN-Dual-Core-Mini-ITX-Motherboard<http://www.amazon.com/Intel-BOXD2500HN-Dual-Core-Mini-ITX-Motherboard/dp/B007BHTMX6/ref=sr_1_5?ie=UTF8&qid=1372689454&sr=8-5&keywords=intel+atom>
>
> Those tiny Arm boards are best until the price gets about about $45. Above
> that I think they are not a great value.
>
>
> On Mon, Jul 1, 2013 at 3:57 AM, David J Taylor <
> david-taylor-***@public.gmane.org> wrote:
>
> > How do folks think that the Odroid/U2 might compare?
> >
> > http://www.hardkernel.com/**renewal_2011/products/prdt_**info.php<http://www.hardkernel.com/renewal_2011/products/prdt_info.php>
> >
> > More expensive than Raspberry Pi or BeagleBone black, but higher
> > performance?
> >
> >
> > ______________________________**_________________
> > time-nuts mailing list -- time-nuts-***@public.gmane.org
> > To unsubscribe, go to https://www.febo.com/cgi-bin/**
> > mailman/listinfo/time-nuts<https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
> > and follow the instructions there.
> >
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.


Folkert van Heusden

--
Always wondered what the latency of your webserver is? Or how much more
latency you get when you go through a proxy server/tor? The numbers
tell the tale and with HTTPing you know them!
http://www.vanheusden.com/httping/
-----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[Chris Albertson]

For a NTP use the $40 ARM. The Atom is going to pull maybe 10W of power
but can do a lot more. I just did not see the use of the $90 quad core
ARM. It is over kill for NTP

I had my Atom running NTP, file server and inside a VMware virtual machine
Lady Heather to monitor the Thunderbolt GPS. The Atom was headless so the
LH display screen was exported to one of the other computers when needed.

Related Topic: It would be great to run LH on an ARM and not need to have
to keep a PC running, even if the PC is an Atom running a virtual PC.


On Mon, Jul 1, 2013 at 7:47 AM, folkert <folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org> wrote:

> Yes but how much power do they use?
> These arm boardjes are < 5 watt, some even 1 watt.
>
>
> On Mon, Jul 01, 2013 at 07:43:49AM -0700, Chris Albertson wrote:
> > For a few dollars LESS you can get an Intel dual-core Atom board. It is
> a
> > standard PC motherboard. These can run a file server, a web server, SSH
> > and NTP all at the same time and have about 90% idle time on the CPU.
> > (Running those other processes does not effect NTP.)
> > Intel-BOXD2500HN-Dual-Core-Mini-ITX-Motherboard<
> http://www.amazon.com/Intel-BOXD2500HN-Dual-Core-Mini-ITX-Motherboard/dp/B007BHTMX6/ref=sr_1_5?ie=UTF8&qid=1372689454&sr=8-5&keywords=intel+atom
> >
> >
> > Those tiny Arm boards are best until the price gets about about $45.
> Above
> > that I think they are not a great value.
> >
> >
> > On Mon, Jul 1, 2013 at 3:57 AM, David J Taylor <
> > david-taylor-***@public.gmane.org> wrote:
> >
> > > How do folks think that the Odroid/U2 might compare?
> > >
> > > http://www.hardkernel.com/**renewal_2011/products/prdt_**info.php<
> http://www.hardkernel.com/renewal_2011/products/prdt_info.php>
> > >
> > > More expensive than Raspberry Pi or BeagleBone black, but higher
> > > performance?
> > >
> > >
> > > ______________________________**_________________
> > > time-nuts mailing list -- time-nuts-***@public.gmane.org
> > > To unsubscribe, go to https://www.febo.com/cgi-bin/**
> > > mailman/listinfo/time-nuts<
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
> > > and follow the instructions there.
> > >
> >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> > _______________________________________________
> > time-nuts mailing list -- time-nuts-***@public.gmane.org
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
>
> Folkert van Heusden
>
> --
> Always wondered what the latency of your webserver is? Or how much more
> latency you get when you go through a proxy server/tor? The numbers
> tell the tale and with HTTPing you know them!
> http://www.vanheusden.com/httping/
> -----------------------------------------------------------------------
> Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Paul]

On Mon, Jul 1, 2013 at 1:31 AM, <David J Taylor> wrote:

> There is one write-up here:
> ...
> for using the BeagleBone Black as an NTP server, but he seems to have an
> offset of -0.281 ms from his PPS source, which is rather high.

It happens. Particularly if the discipline is botched for some
reason. The jitter is low so that's a good sign. However I think
he's using a BeagleBoard not a BeagleBone of either flavor, certainly
not a Black since the ntpq output is reported as a year ago -- not
that that should really matter for a simple PPS clock.

[Paul]

>folkert folkert at vanheusden.com
>Fri Jun 28 05:28:44 EDT 2013

>It must be a system < 5 watt, so probably an ARM system. It will only
>run ntpd so not much ram is required.
>It will have 10 (ntp-)clients so a very powerfull processor is not
>required.

While not exactly matching your original request I'd get a Laureline
from Partially Stapled, a level shifter from any number of places, a
power supply, a case and the misc. bits of glue hardware you'd need.
Sadly I have no idea when the new Laurelines will be available and
what the configurations might be since he's stated a desire to include
an optional ublox part on the board.

It will do only one thing -- NTP -- with a ~ 1 watt budget.

It's open hardware (Cortex microcontroller based) so you could build
the previous (current) model but that would require messing with
resistors.

[David J Taylor]

From: Paul

While not exactly matching your original request I'd get a Laureline
from Partially Stapled, a level shifter from any number of places, a
power supply, a case and the misc. bits of glue hardware you'd need.
Sadly I have no idea when the new Laurelines will be available and
what the configurations might be since he's stated a desire to include
an optional ublox part on the board.
[]
===================================

Paul,

I would have got one of those, except that it (as I understand it) doesn't
support any of the NTP management functions such as ntpq -p or ntpq -c rv
from remote nodes, nor does it run MRTG. Not being able to monitor remotely
was a show-stopper for me.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org

[Paul]

>David J Taylor
>Fri Jun 28 12:56:57 EDT 2013

>I would have got one of those, except that it (as I understand it) doesn't
>support any of the NTP management functions such as ntpq -p or ntpq -c rv

I was being a bit lazy. It doesn't run NTP. It emits NTP compatible
timestamps in response to queries. No NTP means no NTP management
functions. Using one as your only clock is unwise but that's true of
any clock. As part of a group you monitor it indirectly via peerstats
or ntpq/dc from a peer.

I believe Michael will be adding support for multiple gps messages (it
currently only supports a single output message e.g. zda) which would
all be cloned to the monitor port so you could directly observe the
state of the receiver.

As I tend my flock of clocks the current lack of ntp management
support on one is the least of my worries.

[Paul]

> Chris Albertson albertson.chris at gmail.com
>Sun Jun 30 23:12:23 EDT 2013

>So yu are getting the Beaglebone Black for about $45. Do you have a link
>to a supplier.

The Beagle Bone Black is about half the cost of the Beagle Bone
(White) and the pricing is reasonably consistent across vendors.

[Chris Albertson]

Thanks. I didn't know there were two kinds. This is more useful for only
$5 more.

Loots like a good platform for porting Lady Heather. Any interest in
that. My idea is to have a web based GUI so you don't need a display or
keyboard. The ARM (or whatever) runs both NTP and LH and shares a power
supply with the Thunderbolt.


On Sun, Jun 30, 2013 at 9:47 PM, Paul <tic-toc-sq1Vm0FqdD/***@public.gmane.org> wrote:

> > Chris Albertson albertson.chris at gmail.com
> >Sun Jun 30 23:12:23 EDT 2013
>
> >So yu are getting the Beaglebone Black for about $45. Do you have a link
> >to a supplier.
>
> The Beagle Bone Black is about half the cost of the Beagle Bone
> (White) and the pricing is reasonably consistent across vendors.
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Attila Kinali]

Although quite a bit OT, i would like to coment a bit on the topic of
application processor boards, as there seem to be a lot of handwaving
in this area.

On Mon, 1 Jul 2013 08:14:55 -0700
Chris Albertson <albertson.chris-***@public.gmane.org> wrote:

> Thanks. I didn't know there were two kinds. This is more useful for only
> $5 more.

There are actually 4 kinds of the beagle family:
Beagle Board
Beagle Board xM
Beagle Bone (White)
Beagle Bone Black

The Board and Board xM are more of the "let's replace a PC" kind of design,
while the two Bone variants are more experimenter, development boards,
similar to the idea of arduino.

A word on the different boards there are out there:
Please keep in mind that most of these boards are using CPUs designed
for other uses than most people will use them for. the Beagle Board and
the Beagle Bone White use processers that orignally come from wireless
(aka cell phone and similar stuff) business. While the xM and the Black
use one from the industrial division. You can see that clearly in the
features that they support.

For comparison, the Raspberry Pi CPU was meant for video applications.
That's why you have a humongus GPU whith a tiny CPU attached to it.
The CPU was not meant to run an OS, but to support the GPU. Hence the
weird USB design, where the USB "controller" generates interrupts every
start of frame (aka every 125us) and the CPU has to do every low level
stuff USB needs in software, instead of the hardware doing it (i guess
it was cheaper to design that way). Which leads to a lot of problems when
doing more than just a little bit of communication over USB. It also
explains why an ARM9 processor does not have an hardware ethernet MAC.

Similar things can be said about boards like the cubieboard, which
uses an AllWinner A10, or A20 for the cubie2. These are CPU designed
for tablets and settop boxes.

Thus each of the design has their own set of advantages, disadvantages
and quirks, depending on where the original CPU design came from.

Also keep in mind that you will not run the board without software.
The quality of the software package and how easy it is to customize
is very different for the various boards out there. General rule of
thumb: if lots of people are using it, there is a better chance
to find good support for it. The Odroid/hardkernel boards are a nice
negative example in that regard. Another rule of thumb: being able
to compile the whole software package yourself is not just a nice
feature, it's a must have. Stay away from any board that needs any
binary only stuff or where you cannot compile everything from source.
Also, if you don't get full schematics, that should make you suspicious.


HTH

Attila Kinali

--
The people on 4chan are like brilliant psychologists
who also happen to be insane and gross.
-- unknown

[Alberto di Bene]

On 7/1/2013 10:47 PM, Attila Kinali wrote:

> General rule of
> thumb: if lots of people are using it, there is a better chance
> to find good support for it. The Odroid/hardkernel boards are a nice
> negative example in that regard.

Attila,

could you please comment a bit further on the Odroid board ? I intended to use
one for a project, but now you made me rethinking my choice, considered that
I am far from being a Linux guru...

TNX

73 Alberto I2PHD

[NeonJohn]

Before anyone wastes his money on a BeagleBone, I suggest you join the
mailing list and read the hundreds of messages each day that pass
through, most of them citing problems, mostly with the Linux implementation.

Basically, the ancient implementation of Angstrom Linux is a POS. Just
barely enough code to be able to say, for example, that SPI works. It
does - sorta - but not well enough for any application where clock
timing or jitter matters.

I had intended to embed the BB white in my next revision induction
heater. After several months of frustration and a considerable amount
of money to a kernel programmer to write drivers that actually worked, I
gave up. I could easily had a man-year in the application that I can do
bare metal in a few months.

The thing that finally canned the BB for me was the short SD card life.
Even though the implementation uses a virtualized root file system, it
still writes to the SD card about once a second. The result is that
even industrial grade SD cards rarely live over a year. With the Black
they tried to address the problem by putting some NAND memory on board
but that only prolongs the problem and with components that are not
easily changed.

A final negative is the support. The team member, a guy named Gerald,
who provides official support on the mailing lists is one of the most
hateful persons I've encountered on the net. No, I never personally had
an encounter with him but I daily shook my head in amazement that TI
would let such a person rep them.

PS: Before you go to buy the Black, take a careful look at what all they
left off in an effort to compete with the Pi.

PSS: I have a couple of Whites, one unopened, and a prototyping board
for sale. Cheap :-)

John



On 07/01/2013 11:14 AM, Chris Albertson wrote:
> Thanks. I didn't know there were two kinds. This is more useful for only
> $5 more.


--
John DeArmond
Tellico Plains, Occupied TN
http://www.fluxeon.com <-- THE source for induction heaters
http://www.neon-john.com <-- email from here
http://www.johndearmond.com <-- Best damned Blog on the net
PGP key: wwwkeys.pgp.net: BCB68D77

[Eric Williams]

What did they leave out of the hardware? Hard to tell what to look for
when it's not there.

Thanks for sharing your experience.
--
eric


On Mon, Jul 1, 2013 at 10:43 PM, NeonJohn <jgd-7o1kDznDRwqaMJb+***@public.gmane.org> wrote:

> Before anyone wastes his money on a BeagleBone, I suggest you join the
> mailing list and read the hundreds of messages each day that pass
> through, most of them citing problems, mostly with the Linux
> implementation.
>
> Basically, the ancient implementation of Angstrom Linux is a POS. Just
> barely enough code to be able to say, for example, that SPI works. It
> does - sorta - but not well enough for any application where clock
> timing or jitter matters.
>
> I had intended to embed the BB white in my next revision induction
> heater. After several months of frustration and a considerable amount
> of money to a kernel programmer to write drivers that actually worked, I
> gave up. I could easily had a man-year in the application that I can do
> bare metal in a few months.
>
> The thing that finally canned the BB for me was the short SD card life.
> Even though the implementation uses a virtualized root file system, it
> still writes to the SD card about once a second. The result is that
> even industrial grade SD cards rarely live over a year. With the Black
> they tried to address the problem by putting some NAND memory on board
> but that only prolongs the problem and with components that are not
> easily changed.
>
> A final negative is the support. The team member, a guy named Gerald,
> who provides official support on the mailing lists is one of the most
> hateful persons I've encountered on the net. No, I never personally had
> an encounter with him but I daily shook my head in amazement that TI
> would let such a person rep them.
>
> PS: Before you go to buy the Black, take a careful look at what all they
> left off in an effort to compete with the Pi.
>
> PSS: I have a couple of Whites, one unopened, and a prototyping board
> for sale. Cheap :-)
>
> John
>
>
>
> On 07/01/2013 11:14 AM, Chris Albertson wrote:
> > Thanks. I didn't know there were two kinds. This is more useful for
> only
> > $5 more.
>
>
> --
> John DeArmond
> Tellico Plains, Occupied TN
> http://www.fluxeon.com <-- THE source for induction heaters
> http://www.neon-john.com <-- email from here
> http://www.johndearmond.com <-- Best damned Blog on the net
> PGP key: wwwkeys.pgp.net: BCB68D77
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

[NeonJohn]

On 07/02/2013 02:11 AM, Eric Williams wrote:
> What did they leave out of the hardware? Hard to tell what to look for
> when it's not there.
>
> Thanks for sharing your experience.

I'm not sure what all is gone other than the USB port since I haven't
bought one. There is a list of omissions in the mailing list archive,
though.

One other thing I forgot to mention. There is no voltage regulation or
over-voltage protection on the board. The 5.0 volt input goes directly
to the TI power management chip. My white BB would not boot on 5.1
volts. It required exactly 5.0 volts. I ended up taking a 9 volt wall
wart and hacking an LM7805 voltage regulator into the positive lead. I
did not test it for under-voltage but I imagine it's just as sensitive
in that direction.

John

--
John DeArmond
Tellico Plains, Occupied TN
http://www.fluxeon.com <-- THE source for induction heaters
http://www.neon-john.com <-- email from here
http://www.johndearmond.com <-- Best damned Blog on the net
PGP key: wwwkeys.pgp.net: BCB68D77

[Iain Young]

On 02/07/13 06:43, NeonJohn wrote:

> Before anyone wastes his money on a BeagleBone, I suggest you join the
> mailing list and read the hundreds of messages each day that pass
> through, most of them citing problems, mostly with the Linux implementation.
>
> Basically, the ancient implementation of Angstrom Linux is a POS. Just
> barely enough code to be able to say, for example, that SPI works. It
> does - sorta - but not well enough for any application where clock
> timing or jitter matters.

You are not restricted to just Angstrom. My fleet run Debian. FreeBSD is
also available. First thing I do is blow away Angstrom from any SD card.

> I had intended to embed the BB white in my next revision induction
> heater. After several months of frustration and a considerable amount
> of money to a kernel programmer to write drivers that actually worked, I
> gave up. I could easily had a man-year in the application that I can do
> bare metal in a few months.

Hmm, is this a case of Angstrom being beind the kernel curve, or is it still
an issue when running things like Debian ? I've not had the need to use
SPI on the BB yet, only the Pi.

> The thing that finally canned the BB for me was the short SD card life.
> Even though the implementation uses a virtualized root file system, it
> still writes to the SD card about once a second. The result is that
> even industrial grade SD cards rarely live over a year. With the Black
> they tried to address the problem by putting some NAND memory on board
> but that only prolongs the problem and with components that are not
> easily changed.

I've only ever had one SD card go dead on me on my entire fleet, and I
suspect that was actually my fault, not Debian's :)

> A final negative is the support. The team member, a guy named Gerald,
> who provides official support on the mailing lists is one of the most
> hateful persons I've encountered on the net. No, I never personally had
> an encounter with him but I daily shook my head in amazement that TI
> would let such a person rep them.
>

I've heard he can be somewhat robust to deal with. That said, he is
very knowledgeable from what I've seen/understand. Never actually had
to mail the mailing list itself though - found all the answers I needed
in the archive - often from him!

> PS: Before you go to buy the Black, take a careful look at what all they
> left off in an effort to compete with the Pi.

Hmm. I checked a lot of the things I'd need on the black for this type of
application, and found they were all still there (Serial Ports, PRUSS,
Timers etc). Yes you may need to twiddle the pinmux as by default it
goes to he HDMI stuff etc, but they are still there

Is there something specific here you are thinking of ? Maybe I just
don't need what they left off. I do remember looking and going "Meh,
not important for what I'm doing"


Best Regards

Iain

[NeonJohn]

On 07/02/2013 02:14 AM, Iain Young wrote:
> On 02/07/13 06:43, NeonJohn wrote:
>

>> Basically, the ancient implementation of Angstrom Linux is a POS. Just
>> barely enough code to be able to say, for example, that SPI works. It
>> does - sorta - but not well enough for any application where clock
>> timing or jitter matters.
>
> You are not restricted to just Angstrom. My fleet run Debian. FreeBSD is
> also available. First thing I do is blow away Angstrom from any SD card.

Yeah, and so is Ubuntu. So if you want to become a Linux (kernel)
hacker instead of concentrating on your application, a BB is just for
you. OTOH, if you expect it to "just work" out of the box like the
Arduino and many other boards do, you'll be sorely disappointed.

One other thing I forgot to mention. BeagleBoard actively discourages
volume purchases and commercial use. Circuitco, the company that
actually makes the BB will sell into commercial applications but at a
considerably higher price.

Finally https://www.gumstix.com/ offers a BB white clone with
commercially rated parts for about $100. Supposedly their Linux
implementation is much better supported, though I have no personal
experience.

One positive thing is that TI offers something called StarterWare for
people who don't want to bother with an OS. It abstracts much of the
intricacies of the bare metal. I downloaded a copy and took a look and
was fairly impressed but by then I knew that a commercial grade board
was going to cost in the $100 range so I had already abandoned the product.

John



--
John DeArmond
Tellico Plains, Occupied TN
http://www.fluxeon.com <-- THE source for induction heaters
http://www.neon-john.com <-- email from here
http://www.johndearmond.com <-- Best damned Blog on the net
PGP key: wwwkeys.pgp.net: BCB68D77

[folkert]

> >The thing that finally canned the BB for me was the short SD card life.
> > Even though the implementation uses a virtualized root file system, it
> >still writes to the SD card about once a second. The result is that
> >even industrial grade SD cards rarely live over a year. With the Black
> >they tried to address the problem by putting some NAND memory on board
> >but that only prolongs the problem and with components that are not
> >easily changed.
>
> I've only ever had one SD card go dead on me on my entire fleet, and I
> suspect that was actually my fault, not Debian's :)

Recent Linux kernels (3.8) have a new filesystem called 'f2fs'.
This is a logging filesystem: it appends data instead of overwriting
(and does a flush if the fs gets full).
This should increase the lifespan.
I have a couple (6) of raspberry pi's (pies?) using this filesystem and
indeed it seems to help.


Folkert van Heusden

--
Multitail est un outil permettant la visualisation de fichiers de
journalisation et/ou le suivi de l'exécution de commandes. Filtrage,
mise en couleur de mot-clé, fusions, visualisation de différences
(diff-view), etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[Mark C. Stephens]

At the risk of hijacking a thread, shooting of the subject and just generally bad etiquette for news group posting, I am running all my S1 NTP servers on HP thin clients!
They only draw ~14 watts of power.
I have managed to fit a 3.5 inch laptop drive in the T150's so they run a (minimal text based) full version of centos.

And the serial port seems to be okay:
NTP 1 running of a HP 58534A integrated timing antenna:
State Remote Refid Stratum Type When Poll Reach Delay Offset Jitter
o 127.127.20.0 GPS 0 Local clock 8 16 377 0.000 -0.001 0.002

NTP2 running off an Acutime (hmm, marketing) Gold:
State Remote Refid Stratum Type When Poll Reach Delay Offset Jitter
* 127.127.29.0 GPS 0 Local clock 2 32 377 0.000 0.166 0.005

I Don't know about Load handling, I farm most of the NTP requests off to a Stratum 2 (well technically S3 as GPS PPS is not true stratum 1, please correct me if I am wrong?)

But works well for me, I'd love to find a ref driver for the Z3805A port 2 even second string...
Perhaps using the parse driver w/ PPS refclock (is possible?)

Anyway, there is my 0.02c :p

-marki


-----Original Message-----
From: time-nuts-bounces-***@public.gmane.org [mailto:time-nuts-bounces-***@public.gmane.org] On Behalf Of Iain Young
Sent: Tuesday, 2 July 2013 4:14 PM
To: time-nuts-***@public.gmane.org
Subject: Re: [time-nuts] looking for low-power system for gps ntp timekeeping

On 02/07/13 06:43, NeonJohn wrote:

> Before anyone wastes his money on a BeagleBone, I suggest you join the
> mailing list and read the hundreds of messages each day that pass
> through, most of them citing problems, mostly with the Linux implementation.
>
> Basically, the ancient implementation of Angstrom Linux is a POS.
> Just barely enough code to be able to say, for example, that SPI
> works. It does - sorta - but not well enough for any application
> where clock timing or jitter matters.

You are not restricted to just Angstrom. My fleet run Debian. FreeBSD is also available. First thing I do is blow away Angstrom from any SD card.

> I had intended to embed the BB white in my next revision induction
> heater. After several months of frustration and a considerable amount
> of money to a kernel programmer to write drivers that actually worked,
> I gave up. I could easily had a man-year in the application that I
> can do bare metal in a few months.

Hmm, is this a case of Angstrom being beind the kernel curve, or is it still an issue when running things like Debian ? I've not had the need to use SPI on the BB yet, only the Pi.

> The thing that finally canned the BB for me was the short SD card life.
> Even though the implementation uses a virtualized root file system,
> it still writes to the SD card about once a second. The result is
> that even industrial grade SD cards rarely live over a year. With the
> Black they tried to address the problem by putting some NAND memory on
> board but that only prolongs the problem and with components that are
> not easily changed.

I've only ever had one SD card go dead on me on my entire fleet, and I suspect that was actually my fault, not Debian's :)

> A final negative is the support. The team member, a guy named Gerald,
> who provides official support on the mailing lists is one of the most
> hateful persons I've encountered on the net. No, I never personally
> had an encounter with him but I daily shook my head in amazement that
> TI would let such a person rep them.
>

I've heard he can be somewhat robust to deal with. That said, he is very knowledgeable from what I've seen/understand. Never actually had to mail the mailing list itself though - found all the answers I needed in the archive - often from him!

> PS: Before you go to buy the Black, take a careful look at what all
> they left off in an effort to compete with the Pi.

Hmm. I checked a lot of the things I'd need on the black for this type of application, and found they were all still there (Serial Ports, PRUSS, Timers etc). Yes you may need to twiddle the pinmux as by default it goes to he HDMI stuff etc, but they are still there

Is there something specific here you are thinking of ? Maybe I just don't need what they left off. I do remember looking and going "Meh, not important for what I'm doing"


Best Regards

Iain


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

[Chris Albertson]

The way to run an embedded Linux system is NOT to run off the SD card.
Set up a small RAM disk and write to the disk image.

I think you could get this to work but you" have to know a little about
unix-like OSes so you can make changes.

That is one reason I suggested the Item Atom. It is a standard PC
motherboard and can run the more common un-modified version of any OS you
like. I boot them off the network or from a a USB flash drive and then
un-mound the boot drive. A boot drive should be read-only and never
written to.




On Mon, Jul 1, 2013 at 10:43 PM, NeonJohn <jgd-7o1kDznDRwqaMJb+***@public.gmane.org> wrote:

> Before anyone wastes his money on a BeagleBone, I suggest you join the
> mailing list and read the hundreds of messages each day that pass
> through, most of them citing problems, mostly with the Linux
> implementation.
>
> Basically, the ancient implementation of Angstrom Linux is a POS. Just
> barely enough code to be able to say, for example, that SPI works. It
> does - sorta - but not well enough for any application where clock
> timing or jitter matters.
>
> I had intended to embed the BB white in my next revision induction
> heater. After several months of frustration and a considerable amount
> of money to a kernel programmer to write drivers that actually worked, I
> gave up. I could easily had a man-year in the application that I can do
> bare metal in a few months.
>
> The thing that finally canned the BB for me was the short SD card life.
> Even though the implementation uses a virtualized root file system, it
> still writes to the SD card about once a second. The result is that
> even industrial grade SD cards rarely live over a year. With the Black
> they tried to address the problem by putting some NAND memory on board
> but that only prolongs the problem and with components that are not
> easily changed.
>
> A final negative is the support. The team member, a guy named Gerald,
> who provides official support on the mailing lists is one of the most
> hateful persons I've encountered on the net. No, I never personally had
> an encounter with him but I daily shook my head in amazement that TI
> would let such a person rep them.
>
> PS: Before you go to buy the Black, take a careful look at what all they
> left off in an effort to compete with the Pi.
>
> PSS: I have a couple of Whites, one unopened, and a prototyping board
> for sale. Cheap :-)
>
> John
>
>
>
> On 07/01/2013 11:14 AM, Chris Albertson wrote:
> > Thanks. I didn't know there were two kinds. This is more useful for
> only
> > $5 more.
>
>
> --
> John DeArmond
> Tellico Plains, Occupied TN
> http://www.fluxeon.com <-- THE source for induction heaters
> http://www.neon-john.com <-- email from here
> http://www.johndearmond.com <-- Best damned Blog on the net
> PGP key: wwwkeys.pgp.net: BCB68D77
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Didier Juges]

John,

The SD Card issue is serious but not unique go the BBB. I believe there are ways to configure any Linux distro to make the SD card read only, at the cost of losing logging and data every time you power off. Alternately, one could partition the SD card with a second partition just for data you want to save.

If you Google for Flash and Linux, you will get lots of suggestions for things to do.

Didier KO4BB

NeonJohn <jgd-7o1kDznDRwqaMJb+***@public.gmane.org> wrote:
>Before anyone wastes his money on a BeagleBone, I suggest you join the
>mailing list and read the hundreds of messages each day that pass
>through, most of them citing problems, mostly with the Linux
>implementation.
>
>Basically, the ancient implementation of Angstrom Linux is a POS. Just
>barely enough code to be able to say, for example, that SPI works. It
>does - sorta - but not well enough for any application where clock
>timing or jitter matters.
>
>I had intended to embed the BB white in my next revision induction
>heater. After several months of frustration and a considerable amount
>of money to a kernel programmer to write drivers that actually worked,
>I
>gave up. I could easily had a man-year in the application that I can
>do
>bare metal in a few months.
>
>The thing that finally canned the BB for me was the short SD card life.
> Even though the implementation uses a virtualized root file system, it
>still writes to the SD card about once a second. The result is that
>even industrial grade SD cards rarely live over a year. With the Black
>they tried to address the problem by putting some NAND memory on board
>but that only prolongs the problem and with components that are not
>easily changed.
>
>A final negative is the support. The team member, a guy named Gerald,
>who provides official support on the mailing lists is one of the most
>hateful persons I've encountered on the net. No, I never personally had
>an encounter with him but I daily shook my head in amazement that TI
>would let such a person rep them.
>
>PS: Before you go to buy the Black, take a careful look at what all
>they
>left off in an effort to compete with the Pi.
>
>PSS: I have a couple of Whites, one unopened, and a prototyping board
>for sale. Cheap :-)
>
>John
>
>
>
>On 07/01/2013 11:14 AM, Chris Albertson wrote:
>> Thanks. I didn't know there were two kinds. This is more useful for
>only
>> $5 more.
>
>
>--
>John DeArmond
>Tellico Plains, Occupied TN
>http://www.fluxeon.com <-- THE source for induction heaters
>http://www.neon-john.com <-- email from here
>http://www.johndearmond.com <-- Best damned Blog on the net
>PGP key: wwwkeys.pgp.net: BCB68D77
>_______________________________________________
>time-nuts mailing list -- time-nuts-***@public.gmane.org
>To unsubscribe, go to
>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>and follow the instructions there.

--
Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other things.

[Chris Albertson]

There are many ways to solve the SD card problem. One is to write the file
to a networked disk drive, or set up a disk image in RAM, but then you
loose the data if the power fails or you can use a small notebook disk in
place of the SD card.

You could write to the SD card in batches, say one batch per hour or per
day. Set up a cron job to transfer files from the RAM based disk image to
the card.


On Tue, Jul 2, 2013 at 12:11 PM, Didier Juges <shalimr9-***@public.gmane.org> wrote:

> John,
>
> The SD Card issue is serious but not unique go the BBB. I believe there
> are ways to configure any Linux distro to make the SD card read only, at
> the cost of losing logging and data every time you power off. Alternately,
> one could partition the SD card with a second partition just for data you
> want to save.
>
>
--

Chris Albertson
Redondo Beach, California

[Hal Murray]

folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org said:
remote refid st t when poll reach delay offset jitter
==============================================================================
x127.127.28.0 .NMEA. 0 l 3 16 377 0.000 -994.05 7.857
x127.127.28.1 .PPS. 0 l 7 16 377 0.000 -250.13 572.812
+192.168.64.18 .PPS. 1 u 66 128 377 0.553 -0.055 0.033
*192.168.64.2 .PPS. 1 u 99 128 377 0.237 -0.062 0.039
+192.168.64.168 .PPS. 1 u 44 128 377 0.646 -0.013 0.321

Something is broken. What NMEA device are you using? Why are you using gpsd
rather than ntpd's NMEA driver?

It looks like the NMEA side it is off by a second. Some devices do that.
You can fix that with some fudging.

The PPS stuff is off by 250 ms. Are you using the wrong edge? (Got a scope
handy?)




--
These are my opinions. I hate spam.

[folkert]

> folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org said:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> x127.127.28.0 .NMEA. 0 l 3 16 377 0.000 -994.05 7.857
> x127.127.28.1 .PPS. 0 l 7 16 377 0.000 -250.13 572.812
> +192.168.64.18 .PPS. 1 u 66 128 377 0.553 -0.055 0.033
> *192.168.64.2 .PPS. 1 u 99 128 377 0.237 -0.062 0.039
> +192.168.64.168 .PPS. 1 u 44 128 377 0.646 -0.013 0.321
>
> Something is broken. What NMEA device are you using? Why are you using gpsd

It is a garmin 18x lvc.

> rather than ntpd's NMEA driver?

Oh for convenience. I need to patch ntpd to use linux pps (afaik) and on
other systems I successfully run gpsd with ntpd (read: low jitter).

> It looks like the NMEA side it is off by a second. Some devices do that.
> You can fix that with some fudging.

Yes, I'm not so worried about the nmea part, I might even decide to
remove it from the configuration. What I mean is: if I set the clock to
the current time, than it is only a matter of keeping it at that with
the pps.

> The PPS stuff is off by 250 ms. Are you using the wrong edge? (Got a scope
> handy?)

Well, the offset is not constant. If you look at
http://keetweej.vanheusden.com/~folkert/nanosg20.png you see it is
between 0 and -1ms. I now notice that it is not random-ish but consists
of a few specific values:

***@belle:~$ cat peerstats | grep 127.127.28.1 | awk '{ print $5; }' | cut -c 1-6 | sort | uniq -c | sort -rn
503 -0.874
497 -0.875
486 -0.999
467 -1.000
365 -0.249
332 -0.250
201 -0.857
188 -0.125
184 -0.142
140 -0.124
131 -0.000
113 0.0000
108 -0.166
24 -0.833
5 -0.200
2 -0.856
2 -0.799
2 -0.199
1 -0.167
1 -0.143
1 0.0002
1 0.0001

This is with 3754 lines.

If I clean it a little:

1000x -0.8745
953x -0.9995
697x -0.2495
328x -0.1245

and so on.


Folkert van Heusden

--
MultiTail är ett flexibel redskap för att följa en eller flera logfiler, utföra
kommandon, filtrera, färglägga, sammanfoga, o.s.v...
----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[Doug Calvert]

On Wed, Jul 3, 2013 at 4:14 PM, folkert <folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org> wrote:
>
>
> Oh for convenience. I need to patch ntpd to use linux pps (afaik) and on
> other systems I successfully run gpsd with ntpd (read: low jitter).


Using gpsd with ntpd reduces the jitter versus just using ntpd by itself?

[folkert]

> > Oh for convenience. I need to patch ntpd to use linux pps (afaik) and on
> > other systems I successfully run gpsd with ntpd (read: low jitter).
>
> Using gpsd with ntpd reduces the jitter versus just using ntpd by itself?

No I meant that running that combination is successfully because I see
low jitter.


Folkert van Heusden

--
Multitail est un outil permettant la visualisation de fichiers de
journalisation et/ou le suivi de l'exécution de commandes. Filtrage,
mise en couleur de mot-clé, fusions, visualisation de différences
(diff-view), etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[folkert]

Here's a review of several small low power linux systems:
http://www.cooking-hacks.com/index.php/blog/new-linux-embedded-devices-comparison-arduino-beagleboard-rascal-raspberry-pi-cubieboard-and-pcduino


Folkert van Heusden

--
MultiTail is a versatile tool for watching logfiles and output of
commands. Filtering, coloring, merging, diff-view, etc.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com

[Gary]

Regarding Linux on Arm, I'd suggest opensuse. The opensuse arm forum was
the only one that actually helped me. While they have an official list
of boards they support, they will help on pretty much any Arm board out
there.

You can't reach anyone of authority at Ubuntu. You can get help, but bug
fixes are another story. Fedora is hopelessly behind on Arm. Opensuse
has dipped their toes in embedded linux for some time, so Arm isn't a
stretch for them. I believe they are serious about Arm.

I have openuse running on a Beagleboard XM. About the only thing that
wasn't working was mono.

[Tim Shoppa]

What sort of nanosecond timing PPS interface is available on these boards?
I don't mind hacking a kernel with some oddball PPS patch, but I haven't
done that for years, and if someone told me that distro X worked well with
PPS interface Y out of the box, that would be a big win.

I still don't trust USB for precise PPS timing but folks could convince me
different. Doubt GPIO14 would get there either but I could be educated
there too.

Tim N3QE


On Wed, Jul 3, 2013 at 3:00 PM, folkert <folkert-Beo89p9qyDM6GGFevw1D/***@public.gmane.org> wrote:

> Here's a review of several small low power linux systems:
>
> http://www.cooking-hacks.com/index.php/blog/new-linux-embedded-devices-comparison-arduino-beagleboard-rascal-raspberry-pi-cubieboard-and-pcduino
>
>
> Folkert van Heusden
>
> --
> MultiTail is a versatile tool for watching logfiles and output of
> commands. Filtering, coloring, merging, diff-view, etc.
> http://www.vanheusden.com/multitail/
> ----------------------------------------------------------------------
> Phone: [phone], PGP-key: 1F28D8AE, www.vanheusden.com
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

[Hal Murray]

> It is a garmin 18x lvc.

That's pretty vanilla. It really should work. I won't be surprised if the
NMEA is off by hundreds of ms and/or has 100 ms of wander, but the PPS should
work.

Would you please try ntpd's NMEA driver, preferably from the latest ntp-dev
http://support.ntp.org/bin/view/Main/SoftwareDownloads
The PPS code used by ntpd is different from gpsd.

If that doesn't work we should try to fix it.


>> rather than ntpd's NMEA driver?
> Oh for convenience. I need to patch ntpd to use linux
> pps (afaik) and on other systems I successfully run gpsd
> with ntpd (read: low jitter).

Were any of those systems ARM?

---------

One possibility is that the CPU is getting turned off when idle to save
power. If that includes the stuff normally used for timekeeping, things
could get screwed up when it gets turned back on. It has to reset the time,
probably getting it from the RTC.

Can you measure the power when idle? (kill off as much as possible, things
like ntpd) If that's suspiciously low that might be the problem.

Can you keep it busy? If nothing else, "while true; do true; done"


--
These are my opinions. I hate spam.

[Mark C. Stephens]

You could also try questions-***@public.gmane.org

The developers etc hang out on that list.
There are a lot of helpful experts on NTP there.

-----Original Message-----
From: time-nuts-bounces-***@public.gmane.org [mailto:time-nuts-bounces-***@public.gmane.org] On Behalf Of Hal Murray
Sent: Thursday, 4 July 2013 8:34 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] looking for low-power system for gps ntp timekeeping NANOSG20

> It is a garmin 18x lvc.

That's pretty vanilla. It really should work. I won't be surprised if the NMEA is off by hundreds of ms and/or has 100 ms of wander, but the PPS should work.

Would you please try ntpd's NMEA driver, preferably from the latest ntp-dev
http://support.ntp.org/bin/view/Main/SoftwareDownloads
The PPS code used by ntpd is different from gpsd.

If that doesn't work we should try to fix it.


>> rather than ntpd's NMEA driver?
> Oh for convenience. I need to patch ntpd to use linux pps (afaik) and
> on other systems I successfully run gpsd with ntpd (read: low jitter).

Were any of those systems ARM?

---------

One possibility is that the CPU is getting turned off when idle to save power. If that includes the stuff normally used for timekeeping, things could get screwed up when it gets turned back on. It has to reset the time, probably getting it from the RTC.


Can you measure the power when idle? (kill off as much as possible, things like ntpd) If that's suspiciously low that might be the problem.

Can you keep it busy? If nothing else, "while true; do true; done"


--
These are my opinions. I hate spam.



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

[Chris Albertson]

>
>
> One possibility is that the CPU is getting turned off when idle to save
> power. If that includes the stuff normally used for timekeeping, things
> could get screwed up when it gets turned back on. It has to reset the
> time, probably getting it from the RTC.
>

I don't think this is the case. Look at how well the system to sync'd with
other NTP servers. It is only the local GPS ref. clocks that are not
doing well. Also you might check the NMEA output by some other means,
some Garmin units are really bad. If you can turn off all the un-needed
NMEA sentences it might help. Simply watching the NMEA output in a
terminal window is a good enough check. You can see by eye if there is a
one second error


--

Chris Albertson
Redondo Beach, California

[Hal Murray]

tshoppa-***@public.gmane.org said:
> I still don't trust USB for precise PPS timing but folks could convince me
> different. Doubt GPIO14 would get there either but I could be educated there
> too.

USB is probably good enough for ms level timing.


I haven't looked carefully at the details of the chips used in any of the
boards discussed recently.

Several years ago, I worked with ARM SOCs. These were the ones designed to
run out of on-chip RAM and flash rather than external memory. The limitation
was pins. The chips had more IO devices than there were pins for. Each pin
had 2 or 3 possible uses. If you were considering using a chip, you had to
do more than just check the summary info sheet to make sure in had enough
timers, UARTs and whatever you needed. You also had to make sure that you
could find a pinout assignment that wouldn't conflict.

With that in mind, there are two possible ways to get PPS timing into one of
those chips.

1) You could get an interrupt on a GPIO pin and save the time, just like the
traditional PPS on a modem control signal.

2) You could find an unused GPIO pin that is connected to a previously unused
counter/timer and set things up to latch the count when the level changes.
...


--
These are my opinions. I hate spam.

[Hal Murray]

***@vanheusden.com said:
> I noticed that the accuracy of a crystal makes a big difference. Did a bit
> of googling and I learned that a txco may help solve that. Something that
> keeps a constant temperature that is that I can then glue/solder to the
> crystal of those systems. My question now is: does anyone know of a simple
> schema for such a thing? I'm not entirely new to soldering but large schemas
> with lots of components are a bit daunting as I don't have the background
> knowledge to debug them if I soldered something wrong.

There are two sorts of parts you can get for making a clock to run a bunch of
electronics. You can get the crystal without any electronics (and build the
electronics yourself), or you can get an oscillator which has the crystal and
all the electronics in one handy package.

If you feed >10 MHz< to Digikey's search box, the Crystals and Oscillators
section (4th section) has 12775 Crystals and 13769 Oscillators.

For low cost systems like Raspberry PIs and Arduinos, the CPU chip generally
includes the electronics. They have 2 pins that connect to the crystal (and
a few caps). Most of them can use an external clock (rather than a crystal),
just connect it to the right pin.

The O in TCXO or OCXO tells you it is an oscillator. They need power, so
it's not quite as simple as just replacing the crystal with a TCXO. Here is
a very good writeup on providing an external clock to a Soekris net4501:
http://www.febo.com/time-freq/ntp/soekris/


--
These are my opinions. I hate spam.



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

[Hal Murray]

***@vanheusden.com said:
> Isn't this that "we as time nuts community" can help the scientific world
> with? E.g. create some kind of grassroots effort where our very accurate
> clocks can detect this?

Our clocks aren't good enough.

It's a very hard problem. Here is the scale:
http://www.ligo-la.caltech.edu/


--
These are my opinions. I hate spam.



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

[Alberto di Bene]

On 12/12/2014 10:08 PM, Hal Murray wrote:

> /Our clocks aren't good enough.
>
> It's a very hard problem. Here is the scale:
> //http://www.ligo-la.caltech.edu//

Yes. There are experiments set up in the US, in Italy and in Japan, to detect
gravitational waves, funded by various universities.
So far, not a single event has been detected...

73 Alberto I2PHD




---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

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

[Mark Sims]

My Mickey Mouse watch was... it detected a gravity anomaly when the strap broke and it hit the garage floor. This apparently caused a complete cessation of temporal flow around the unit, ;-)

---------
Our clocks aren't good enough.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[xaos]

When LIGO was announced I read up on it as much as I could.
The problems seemed enormous.

Bob Darlington mentioned shock mounts. That in itself seemed
like a show stopper.

Then I think there was some kind of accident. Anyway
these guys did finish the LIGO. But unfortunately
no space differential was measured. What an incredible
experiment.

-G

On 12/12/2014 04:31 PM, Mark Sims wrote:
> My Mickey Mouse watch was... it detected a gravity anomaly when the strap broke and it hit the garage floor. This apparently caused a complete cessation of temporal flow around the unit, ;-)
>
> ---------
> Our clocks aren't good enough.
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

> Conclusion: not feasible.

Actually, timing isn't the critical part. Yet. First you have to detect
something.

If you have only one working detector, timing isn't very important. If your
detector doesn't tell you the direction, you can build a phased array antenna
by putting several detectors around the earth. With good clocks, you can
work out the direction it came from. The timing has to be good within a
fraction of a wavelength. Maybe less if you can live with reduced pointing
accuracy. (VLBI astronomers use hydrogen masers.)

In 1987, 3 neutrino observatories observed a supernova.
http://en.wikipedia.org/wiki/SN1987A#Neutrino_emissions
But their timing is far from good enough to work out the direction. (Their
fundamental detector technology is slow.)

It might be possible to get a more sensitive system if you have a detector
that is low cost so you can sprinkle many of them around around the Earth.
With good clocks, phased array type math will give you antenna gain if you
have enough compute power to search the whole sky. (or know where you want
to look)


--
These are my opinions. I hate spam.



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

[Hal Murray]

***@gmail.com said:
> Gotcha with modulating the PPS onto a RF carrier, is that for time
> resolution of 1 nanosecond, you would end up using a Gigahertz of bandwidth.

You might be able to use near-field antennas. Picture 2 PCBs spaced a few mm
apart with circular antennas. It would be interesting to measure all the
timing quirks of not having things lined up accurately.



--
These are my opinions. I hate spam.



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

[Hal Murray]

***@gmail.com said:
> Don't have any good ideas for 14121 kHz.
> Any thoughts?

I threw together a quick hack to scan for all PLL coefficients less than 50.
Here are the answers closer than 50 kHz. (I didn't remove lines with a
common factor.)

17 12 14166666.67 45667
24 17 14117647.06 3353
31 22 14090909.09 30091
34 24 14166666.67 45667
38 27 14074074.07 46926
41 29 14137931.03 16931
48 34 14117647.06 3353

So multiply by 24 and divide by 17 gets you a reasonable offset.


--
These are my opinions. I hate spam.



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

[Bob Camp]

Hi

One practical trick is to do the divide by N shown below and simply let the
normal harmonic process do the multiply by M. If both the M / N *and* the
off the air signal are inside the passband of the radio, the data reduction simply
becomes the relation between the two audio tones. Yes there is some messing
around to keep the relative signal levels in the same ballpark….

If you use a PIC to do the divide, the whole process is pretty cheap ….

Bob

> On May 15, 2015, at 4:29 AM, Hal Murray <***@megapathdsl.net> wrote:
>
>
> ***@gmail.com said:
>> Don't have any good ideas for 14121 kHz.
>> Any thoughts?
>
> I threw together a quick hack to scan for all PLL coefficients less than 50.
> Here are the answers closer than 50 kHz. (I didn't remove lines with a
> common factor.)
>
> 17 12 14166666.67 45667
> 24 17 14117647.06 3353
> 31 22 14090909.09 30091
> 34 24 14166666.67 45667
> 38 27 14074074.07 46926
> 41 29 14137931.03 16931
> 48 34 14117647.06 3353
>
> So multiply by 24 and divide by 17 gets you a reasonable offset.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@gmail.com said:
> I know of many proprietary digital recording applications that make WAV's or
> MP3's or proprietary codec formats, where the filename includes a timestamp.
> Much more interested in standard formats where the timestamp is embedded in
> the file itself.

What sort of accuracy to you want? Is nearest second good enough or do you
want time-nut level accuracy?

One thing to keep in mind is that the recording clock may not be accurate, so
if all you know is the start time, your error bars grow as you move down the
file.

Recording IRIG on another channel is the best suggestion I've seen.


--
These are my opinions. I hate spam.



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

[Götz Romahn]

there is a timecode associated with Audio CDs.
https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio
maybe this helps, Götz


Am 21.12.2015 um 22:06 schrieb Hal Murray:
>
> ***@gmail.com said:
>> I know of many proprietary digital recording applications that make WAV's or
>> MP3's or proprietary codec formats, where the filename includes a timestamp.
>> Much more interested in standard formats where the timestamp is embedded in
>> the file itself.
>
> What sort of accuracy to you want? Is nearest second good enough or do you
> want time-nut level accuracy?
>
> One thing to keep in mind is that the recording clock may not be accurate, so
> if all you know is the start time, your error bars grow as you move down the
> file.
>
> Recording IRIG on another channel is the best suggestion I've seen.
>
>

--
Götz Romahn
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@gmail.com said:
> My opinion if you want to serve reliable time through a longer GPS outage:
> add a WWV or WWVB based radio clock. e.g. a shortwave radio and https://
> www.eecis.udel.edu/~mills/ntp/html/drivers/driver36.html

Do you have any graphs comparing WWV or WWVB to GPS when your GPS is working
correctly?

When I run out of other things on my list, I'd like to collect that data.
What receivers do people recommend?

I have one of the low cost WWVB receiver modules but I never got any useful
data out of it. Maybe it's time to try again. It might work better on the
end of a long cable to get it away from all the EMI in my office.


--
These are my opinions. I hate spam.



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

[Tim Shoppa]

Hal -
In my experience over more than a decade, the ntpd WWV audio refclock has
jitter circa 0.1ms.

This is not nanosecond-time-nut PPS territory. But it is more than good
enough for WAN ntpd.

I use a Ten-Tec RX-320 as a cheap frequency-agile receiver for WWV. In
between 5MHz/10MHz/15MHz usually one or two bands are open from me to
Colorado.

On the subject of WWVB - if you are near Colorado then you can have 24x7
reachability, day or night. For me on the east coast, WWVB 60kHz is
reliable in darkness but not in daylight.

Tim.

On Wed, Feb 24, 2016 at 1:56 PM, Hal Murray <***@megapathdsl.net> wrote:

>
> ***@gmail.com said:
> > My opinion if you want to serve reliable time through a longer GPS
> outage:
> > add a WWV or WWVB based radio clock. e.g. a shortwave radio and https://
> > www.eecis.udel.edu/~mills/ntp/html/drivers/driver36.html
>
> Do you have any graphs comparing WWV or WWVB to GPS when your GPS is
> working
> correctly?
>
> When I run out of other things on my list, I'd like to collect that data.
> What receivers do people recommend?
>
> I have one of the low cost WWVB receiver modules but I never got any useful
> data out of it. Maybe it's time to try again. It might work better on the
> end of a long cable to get it away from all the EMI in my office.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

Hi

The tick is a burst of audio at a fairly low frequency. You are going to need pretty
good conditions to get 0.1 ms. The fade process over much of the day will spread
that out a *lot*.

Bob

> On Feb 24, 2016, at 5:11 PM, Tim Shoppa <***@gmail.com> wrote:
>
> Hal -
> In my experience over more than a decade, the ntpd WWV audio refclock has
> jitter circa 0.1ms.
>
> This is not nanosecond-time-nut PPS territory. But it is more than good
> enough for WAN ntpd.
>
> I use a Ten-Tec RX-320 as a cheap frequency-agile receiver for WWV. In
> between 5MHz/10MHz/15MHz usually one or two bands are open from me to
> Colorado.
>
> On the subject of WWVB - if you are near Colorado then you can have 24x7
> reachability, day or night. For me on the east coast, WWVB 60kHz is
> reliable in darkness but not in daylight.
>
> Tim.
>
> On Wed, Feb 24, 2016 at 1:56 PM, Hal Murray <***@megapathdsl.net> wrote:
>
>>
>> ***@gmail.com said:
>>> My opinion if you want to serve reliable time through a longer GPS
>> outage:
>>> add a WWV or WWVB based radio clock. e.g. a shortwave radio and https://
>>> www.eecis.udel.edu/~mills/ntp/html/drivers/driver36.html
>>
>> Do you have any graphs comparing WWV or WWVB to GPS when your GPS is
>> working
>> correctly?
>>
>> When I run out of other things on my list, I'd like to collect that data.
>> What receivers do people recommend?
>>
>> I have one of the low cost WWVB receiver modules but I never got any useful
>> data out of it. Maybe it's time to try again. It might work better on the
>> end of a long cable to get it away from all the EMI in my office.
>>
>>
>> --
>> These are my opinions. I hate spam.
>>
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

> From what others on the list have said before, WWVB offers performance
> that's at least a couple orders of magnitude worse than GPS, even if you
> correct for all of the expected diurnal variations in LF propagation. Given
> that a fairly pedestrian GPS module offers a nominal PPS accuracy of ~10ns
> for $25...

Yes. But it would be fun to measure the diurnal variations.

I thought WWVB was actually good at that. It's ground wave rather than
bouncing off the ionosphere. But I'd like to measure both WWVB and WWV.

Has anybody built a WWV(B)DSO? You would need a stable oscillator so you
could average over days or weeks rather than hours. I'm thinking of a
surplus rubidium. Maybe a manual screwdriver adjustment would be good enough
and a PIC/AVR to make a PPS and fake GPRMC.



--
These are my opinions. I hate spam.



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

[Bob Camp]

Hi

WWVB DSO’s were a pretty common thing back in the 70’s and 80’s. You could hold
fractions of a ppm with them. With manual intervention / scheduling you could get into
the “couple ppb” range on a good week.

Comparative numbers would be 1x10^-11 on a GPSDO. All the same qualifiers about
“is that really this or that” apply equally (or more so) to it’s WWVB cousin.

Bob

> On Feb 24, 2016, at 5:22 PM, Hal Murray <***@megapathdsl.net> wrote:
>
>
>> From what others on the list have said before, WWVB offers performance
>> that's at least a couple orders of magnitude worse than GPS, even if you
>> correct for all of the expected diurnal variations in LF propagation. Given
>> that a fairly pedestrian GPS module offers a nominal PPS accuracy of ~10ns
>> for $25...
>
> Yes. But it would be fun to measure the diurnal variations.
>
> I thought WWVB was actually good at that. It's ground wave rather than
> bouncing off the ionosphere. But I'd like to measure both WWVB and WWV.
>
> Has anybody built a WWV(B)DSO? You would need a stable oscillator so you
> could average over days or weeks rather than hours. I'm thinking of a
> surplus rubidium. Maybe a manual screwdriver adjustment would be good enough
> and a PIC/AVR to make a PPS and fake GPRMC.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@kfu.com said:
> Yes, that’s true. Given the facilities I have available with the present
> hardware, I don’t believe I have much choice. I am not confident that I
> could tell the difference between noise in the phase detection system and
> PPS jitter variations that small. If the PA6H receiver gave sawtooth
> corrections, I’d be able to do better.

It would be interesting to look at the data to see if you can find the sort
of pattern that a sawtooth correction would help and where a hanging bridge
might cause confusion.

If the bridge isn't hanging, the data samples should be spread over a range
that is the clock period of the GPS unit. Round that up to 100 ns. I doubt
if you will see that with a PC.

On the other hand, you can get the same sort of pattern with a PPS over USB.
That would be a ms wide and easy for a PC to get time stamps much finer
grained than that.


--
These are my opinions. I hate spam.

[Tom Van Baak]

> It would be interesting to look at the data to see if you can find the sort

Hi Hal,

There's lots of examples of sawtooth patterns at: http://leapsecond.com/pages/MG1613S/

In particular there's this monster: http://leapsecond.com/pages/MG1613S/tic-72-hour.gif

It's simple for a microprocessor-based GPSDO with its TIC to realize when it's getting too lost in a hanging bridge. There are a number of ways around the problem. My favorite is gluing a resistor on top of the GPS chip and pumping a few tens of mW through it when you want the bridge to stop.

Here's the proof-of-concept: http://leapsecond.com/pages/vp/heater.htm

/tvb


----- Original Message -----
From: "Hal Murray" <***@megapathdsl.net>
To: "Nick Sayer" <***@kfu.com>
Cc: "Discussion of precise time and frequency measurement" <time-***@febo.com>; "Hal Murray" <***@megapathdsl.net>
Sent: Monday, July 18, 2016 9:41 PM
Subject: Re: [time-nuts] How does sawtooth compensation work?


>
> ***@kfu.com said:
>> Yes, thatâ?Ts true. Given the facilities I have available with the present
>> hardware, I donâ?Tt believe I have much choice. I am not confident that I
>> could tell the difference between noise in the phase detection system and
>> PPS jitter variations that small. If the PA6H receiver gave sawtooth
>> corrections, Iâ?Td be able to do better.
>
> It would be interesting to look at the data to see if you can find the sort
> of pattern that a sawtooth correction would help and where a hanging bridge
> might cause confusion.
>
> If the bridge isn't hanging, the data samples should be spread over a range
> that is the clock period of the GPS unit. Round that up to 100 ns. I doubt
> if you will see that with a PC.
>
> On the other hand, you can get the same sort of pattern with a PPS over USB.
> That would be a ms wide and easy for a PC to get time stamps much finer
> grained than that.
>
>
> --
> These are my opinions. I hate spam.
>

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

[David]

On Mon, 18 Jul 2016 22:01:01 -0700, you wrote:

>> It would be interesting to look at the data to see if you can find the sort
>
>Hi Hal,
>
>There's lots of examples of sawtooth patterns at: http://leapsecond.com/pages/MG1613S/
>
>In particular there's this monster: http://leapsecond.com/pages/MG1613S/tic-72-hour.gif
>
>It's simple for a microprocessor-based GPSDO with its TIC to realize when it's getting too lost in a hanging bridge. There are a number of ways around the problem. My favorite is gluing a resistor on top of the GPS chip and pumping a few tens of mW through it when you want the bridge to stop.
>
>Here's the proof-of-concept: http://leapsecond.com/pages/vp/heater.htm
>
>/tvb

Universal timer/counters and equivalent time sampling DSOs can have
this problem when their timebase ends up synchronized with the signal
they are measuring. Some carefully modulate their timebase to prevent
this.

When I was testing my Garmin 18x against my Racal-Dana 1992, I could
see it happen when the outside temperature was just right.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

The Tektronix TM509/5009 (and I think the 5010) counter modules have a National Semiconductor noise generator chip in them. It injects noise into the counter to get around counter oscillator/input frequency synchronization. I was once given a TM509 with a bad noise generator chip... Some Very Smart People spent ages thinking the problem was in the device they were working on until they tried a different counter. The Very Smart People (too smart to RTFM) could never figure out why the counter was flakey and finally tossed it. A little dumpster diving a few minutes with a scope yielded a very nice little counter.

----------------------------
> Universal timer/counters and equivalent time sampling DSOs can have
this problem when their timebase ends up synchronized with the signal
they are measuring.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bill Byrom]

A slight correction to a typo in the description below (sorry for the
long delay). The correct Tektronix model numbers of these counters start
with DC (not TM).

The Tektronix TM500 (manual control) and TM5000 (GPIB or manual control)
instruments which used the National Semiconductor MM5837 noise generator
chip were the following:
DC509
DC510
DC5009
DC5010
These models were manufactured from the early 1980's until 1995.

The first two digits of the instrument model number designated the type
of instrument. So:
DC = Digital Counter
DM = Digital Multimeter
SG = Signal Generator
PG = Pulse Generator
AA = Audio Analyzer
PS = Power Supply
TM = Test Mainframe (which includes the power supply for the plug-
in modules)

Typically the 10 MHz internal standard or proportional oven timebase
(or external 1/5/10 MHz rear edge connector timebase input) is dived
down with 7490 TTL /5 and /2 divider sections to 1 MHz. The 1 MHz
reference then drives a X100 PLL (using an ECL oscillator with varicap
frequency control and 4044 phase detector) to create the 100 MHz main
internal clock. The MM5837 pseudo-random noise generator phase
modulates the PLL in some instrument modes of operation so that time
interval averaging works correctly if the input signal is synchronously
related to the clock.

--
Bill Byrom N5BB
Tektronix Application Engineer


On Tue, Jul 19, 2016, at 01:52 AM, Mark Sims wrote:
> The Tektronix TM509/5009 (and I think the 5010) counter modules have a
> National Semiconductor noise generator chip in them. It injects noise
> into the counter to get around counter oscillator/input frequency
> synchronization. I was once given a TM509 with a bad noise generator
> chip... Some Very Smart People spent ages thinking the
> problem was in
> the device they were working on until they tried a different counter.
> The Very Smart People (too smart to RTFM) could never figure
> out why the
> counter was flakey and finally tossed it. A little dumpster
> diving a few
> minutes with a scope yielded a very nice little counter.
>
> ----------------------------
>> Universal timer/counters and equivalent time sampling DSOs can have
> this problem when their timebase ends up synchronized with the signal
> they are measuring.
> _________________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[David]

The DC510 and DC5010 phase lock a 320 MHz varicap oscillator to the 1
MHz reference giving them a 3.125ns single shot timing resolution.

The DC509, DC5009, DC510, and the DC 5010 are reciprocal counters.

The universal timer/counters in the 2236, 2236A, 2247A, and 2252
oscilloscopes phase lock 100 MHz varicap oscillators to their
references and are reciprocal counters which is important since they
can gate their timer/counters which is incredibly handy on a dual
timebase oscilloscope. The 2247A and 2252 use noise modulation but I
do not think the 2236 and 2236A do.

On Sun, 07 Aug 2016 21:36:21 -0500, you wrote:

>A slight correction to a typo in the description below (sorry for the
>long delay). The correct Tektronix model numbers of these counters start
>with DC (not TM).
>
>The Tektronix TM500 (manual control) and TM5000 (GPIB or manual control)
>instruments which used the National Semiconductor MM5837 noise generator
>chip were the following:
>DC509
>DC510
>DC5009
>DC5010
>These models were manufactured from the early 1980's until 1995.
>
>The first two digits of the instrument model number designated the type
>of instrument. So:
>DC = Digital Counter
>DM = Digital Multimeter
>SG = Signal Generator
>PG = Pulse Generator
>AA = Audio Analyzer
>PS = Power Supply
>TM = Test Mainframe (which includes the power supply for the plug-
>in modules)
>
>Typically the 10 MHz internal standard or proportional oven timebase
>(or external 1/5/10 MHz rear edge connector timebase input) is dived
>down with 7490 TTL /5 and /2 divider sections to 1 MHz. The 1 MHz
>reference then drives a X100 PLL (using an ECL oscillator with varicap
>frequency control and 4044 phase detector) to create the 100 MHz main
>internal clock. The MM5837 pseudo-random noise generator phase
>modulates the PLL in some instrument modes of operation so that time
>interval averaging works correctly if the input signal is synchronously
>related to the clock.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@gmail.com said:
> I'm all for a diversity of systems - putting all our eggs in the GPS basket
> seems unwise (and I maintain WWV receivers hooked to NTP at home!)

What is available in the way of WWV receivers? Anybody got a summary handy?


--
These are my opinions. I hate spam.



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

[Ruslan Nabioullin]

On 10/26/2016 02:54 AM, Hal Murray wrote:
>
> ***@gmail.com said:
>> I'm all for a diversity of systems - putting all our eggs in the GPS basket
>> seems unwise (and I maintain WWV receivers hooked to NTP at home!)
>
> What is available in the way of WWV receivers? Anybody got a summary handy?

Yes, diversity is generally good, as it is in a sociological context.
Despite being such a ubiquitous and critical system in all domains,
military and civilian, US and foreign, and therefore being a recipient
of extensive funding and R&D, it is a high-profile target to adversaries
by means of anti-satellite weapons, cyberattacks, ground segment
attacks, and jamming; additionally, the constellation is subject to the
natural threats that all satellites face, and the system is controlled
by a homogeneous structure of human entities, which reserve the right to
deny coverage to a subset (typically hotspots in times of conflict). It
was a goal of my time metrology project, so I did do research in this
area, expecting to use CHU (which also adds political diversity, for
then it would be US [GPS] and Canada [CHU]) and maybe also WWV, but I
abandoned the idea in favor of allocating the bulk of the budget to
procurement of equipment and supporting equipment for my own house
standard by means of a rubidium ensemble.

Yes, standalone WWV receivers of course do exist; if one wishes to go
this route, the only practical means is by purchasing one of those
ancient (late 70s era probably) Systron Donner time code generator units
off eBay, which you'll notice has a BNC port on the back for an HF
antenna (or just the audio feed---who knows? Documentation is scarce).
However, unless you need WWV-derived PPS, this approach is *greatly*
suboptimal; the best approach would be to find your desired HF
receiver(s) and connect them via sound card(s) to the NTP server(s),
using the WWV module (and/or CHU). Besides the unknowns resulting from
documentation scarcity, this approach brings flexibility and the
benefits of the ``less is more'' philosophy, for you gain: the freedom
to decide what models of equipment to incorporate; flexibility in
channels (you can also do CHU, and even within WWV you can do 2.5, 5,
10, 15, and/or 20 MHz); and avoidance of obsolescence---remember, you're
relying on some human entity's signal, who in this case of a
seemingly-unpopular (at least nowadays) signal is under little
obligation to preserve the characteristics and even presence of such a
signal---look at what happened with the WWVB signal change, which
effectively rendered what were once nice standard frequency WWVB
receivers into paperweights.

For the radio, the best overall approach might be using $32 or so
RTL-SDRs which feature a case. However, the reception quality of these
units is not so great, the DSP might overwhelm low-power and embedded
servers, and there might be latency issues; I'm not familiar enough with
SDRs to state for sure. Another cheap approach is to simply use $12 or
so, incl. shipping, handheld HF receivers, though from past experience
the reception quality of them is absolutely awful and they are portable,
consumer-grade devices, meaning that there's no antenna BNC port, there
might be no power input apart from the terminals in the battery
compartment, and there are no means of elegantly rack-mounting them. A
more costly approach is to use a general-purpose HF receiver (like
typical Icom or Yaesu units that typical amateur radio operators use) or
a professional HF receiver; unfortunately one is very limited in the
latter, which consists of, in ascending order of price: HP 3586C (a
measuring receiver actually), Ten-Tec (from the research I have done, is
generally similar to Watkins Johnson [WJ], but lacks high-reliability
specifications), and WJ.

For the sound card, it has been reported that those cheap Chinese USB
sound cards, costing <$2 each incl. shipping, are adequate; I actually
ordered a quantity-discounted lot of 5 or so of the popular variant
which contains status LEDs before changing plans, so that's the best
approach if you wish to use multiple sources or servers.

Note that for high-reliability setups, one must factor in potential
service degradation caused by civil unrest or remote equipment failure,
such as reduced station power output due to electricity shortages, loss
of some channels, or jamming by adversaries.

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

[Nick Sayer via time-nuts]

If you’re in North America, a CHU receiver is a lot easier to make than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - it was a one-chip solution 20 years ago when I made one in college. On the software side, you’ll want a serial line discipline kernel module of some sort that timestamps the incoming characters. The result is as good as HF radio will get you, which is to say probably 2 or 3 orders of magnitude minimum worse than GPS.

IMHO the diversity of which you speak is exactly what NTP delivers. I believe NIST and USNO run NTP servers that aren’t sourced from GPS. Folks with Cesium clocks could conceivably do the same to provide independent standards.

> On Oct 25, 2016, at 11:54 PM, Hal Murray <***@megapathdsl.net> wrote:
>
>
> ***@gmail.com said:
>> I'm all for a diversity of systems - putting all our eggs in the GPS basket
>> seems unwise (and I maintain WWV receivers hooked to NTP at home!)
>
> What is available in the way of WWV receivers? Anybody got a summary handy?
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Chris Albertson]

I started to set up a WWV based reference clock. As for a receiver SDR is
the best way to go but I built a tunnel front end. It is easy to do
because it needs to only work at ne specify frequency so you can use a
crystal filter with norrow bandwidth. The SDR receiver did direct
conversion that sampled in quadrature using a stereo sound card type
interface. I disagree that even the cheap sound cards are good enough.
Get one that does 24-bit sample because they have enough dynamic range so
they can still work without a human operator tuning a gain knob.

The part I did not do was to modify the NTP reference clock drivers to
accept audio feed from Jack Audio. This would allow internal software to
route audio between applications and not have to use multiple sound cards
and analog cables which seems silly.

Other projects came up and I figure it the world ends and the Internet goes
dark and GPS fails I can still know what time it is by watching the sun set
over the ocean every day.

Actually I've disconnected the GPS from my NTP server and notice only a 5
millisecond error on average using just pool servers

On Wed, Oct 26, 2016 at 5:46 AM, Nick Sayer via time-nuts <
time-***@febo.com> wrote:

> If you’re in North America, a CHU receiver is a lot easier to make than
> WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - it was a
> one-chip solution 20 years ago when I made one in college. On the software
> side, you’ll want a serial line discipline kernel module of some sort that
> timestamps the incoming characters. The result is as good as HF radio will
> get you, which is to say probably 2 or 3 orders of magnitude minimum worse
> than GPS.
>
> IMHO the diversity of which you speak is exactly what NTP delivers. I
> believe NIST and USNO run NTP servers that aren’t sourced from GPS. Folks
> with Cesium clocks could conceivably do the same to provide independent
> standards.
>
> > On Oct 25, 2016, at 11:54 PM, Hal Murray <***@megapathdsl.net>
> wrote:
> >
> >
> > ***@gmail.com said:
> >> I'm all for a diversity of systems - putting all our eggs in the GPS
> basket
> >> seems unwise (and I maintain WWV receivers hooked to NTP at home!)
> >
> > What is available in the way of WWV receivers? Anybody got a summary
> handy?
> >
> >
> > --
> > These are my opinions. I hate spam.
> >
> >
> >
> > _______________________________________________
> > time-nuts mailing list -- time-***@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-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

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

[Poul-Henning Kamp]

--------
In message <5A002554-8D90-4C75-95DA-***@kfu.com>, Nick Sayer via time-
nuts writes:

>If you’re in North America, a CHU receiver is a lot easier to make
>than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
>it was a one-chip solution 20 years ago when I made one in college.

We have CPUs and sounds-cards these days...

Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
station you want: You can track GPS and four (possibly 8) VLF/HF
stations at the same time.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Nick Sayer via time-nuts]

That single-chip version is going to have a *LOT* less (and less variable) latency than an SDR.

> On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <***@phk.freebsd.dk> wrote:
>
> --------
> In message <5A002554-8D90-4C75-95DA-***@kfu.com>, Nick Sayer via time-
> nuts writes:
>
>> If you’re in North America, a CHU receiver is a lot easier to make
>> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
>> it was a one-chip solution 20 years ago when I made one in college.
>
> We have CPUs and sounds-cards these days...
>
> Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
> station you want: You can track GPS and four (possibly 8) VLF/HF
> stations at the same time.
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> ***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

Hi

Let’s see…. WWV (not WWVB) gets here via a variety of propagation mechanisms
that vary over the day. According to NIST (who probably know :) that puts a random timing
variation of ~1 ms on the signal. Since some modes get me a signal and others don’t, there
is no real reason to assume it is random. It can easily be an offset that varies month to month.

Net result, forget about the chip delays. The signal already has a bunch of built in variability
that will swamp anything in the silicon.

https://www.nist.gov/pml/time-and-frequency-division/nist-radio-broadcasts-frequently-asked-questions-faq

Also in the same data is the fact that the “as transmitted” signal is good to 100 ns. That’s plenty good
enough for the system as described. It also is a pretty modest number for a GPS timing module. One
would guess that the number is a bit better than 100 ns (it is NIST after all). It also does not directly
compare to the GPS number since there are UTC offset numbers there as well. Bottom line is that
there inevitably *are* numbers like that buried in the system once you get past the 1 ms.

Bob

> On Oct 29, 2016, at 1:36 AM, Nick Sayer via time-nuts <time-***@febo.com> wrote:
>
> That single-chip version is going to have a *LOT* less (and less variable) latency than an SDR.
>
>> On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <***@phk.freebsd.dk> wrote:
>>
>> --------
>> In message <5A002554-8D90-4C75-95DA-***@kfu.com>, Nick Sayer via time-
>> nuts writes:
>>
>>> If you’re in North America, a CHU receiver is a lot easier to make
>>> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
>>> it was a one-chip solution 20 years ago when I made one in college.
>>
>> We have CPUs and sounds-cards these days...
>>
>> Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
>> station you want: You can track GPS and four (possibly 8) VLF/HF
>> stations at the same time.
>>
>> --
>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>> ***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[paul swed]

Good thread. Thanks for the clue on the kiwiSDR. I went to the sites and
lots of fun playing with the receivers. As an example hearing LORAN C in
the Asia region.
Certainly seems the receiver is pretty sensitive and capable. Went hunting
for various low frequency timing signals such as JJY and the submarine
crusher signals. All were heard.
I agree with Bobs comments that the signal at WWV range can be all over the
place and though seasonal effects can be a somewhat accounted for the
reality is, its still pretty random. The changes can occur slowly or
rapidly.
Regards
Paul
WB8TSL

On Sat, Oct 29, 2016 at 9:03 AM, Bob Camp <***@n1k.org> wrote:

> Hi
>
> Let’s see…. WWV (not WWVB) gets here via a variety of propagation
> mechanisms
> that vary over the day. According to NIST (who probably know :) that puts
> a random timing
> variation of ~1 ms on the signal. Since some modes get me a signal and
> others don’t, there
> is no real reason to assume it is random. It can easily be an offset that
> varies month to month.
>
> Net result, forget about the chip delays. The signal already has a bunch
> of built in variability
> that will swamp anything in the silicon.
>
> https://www.nist.gov/pml/time-and-frequency-division/nist-
> radio-broadcasts-frequently-asked-questions-faq
>
> Also in the same data is the fact that the “as transmitted” signal is good
> to 100 ns. That’s plenty good
> enough for the system as described. It also is a pretty modest number for
> a GPS timing module. One
> would guess that the number is a bit better than 100 ns (it is NIST after
> all). It also does not directly
> compare to the GPS number since there are UTC offset numbers there as
> well. Bottom line is that
> there inevitably *are* numbers like that buried in the system once you get
> past the 1 ms.
>
> Bob
>
> > On Oct 29, 2016, at 1:36 AM, Nick Sayer via time-nuts <
> time-***@febo.com> wrote:
> >
> > That single-chip version is going to have a *LOT* less (and less
> variable) latency than an SDR.
> >
> >> On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <***@phk.freebsd.dk>
> wrote:
> >>
> >> --------
> >> In message <5A002554-8D90-4C75-95DA-***@kfu.com>, Nick Sayer
> via time-
> >> nuts writes:
> >>
> >>> If you’re in North America, a CHU receiver is a lot easier to make
> >>> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
> >>> it was a one-chip solution 20 years ago when I made one in college.
> >>
> >> We have CPUs and sounds-cards these days...
> >>
> >> Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
> >> station you want: You can track GPS and four (possibly 8) VLF/HF
> >> stations at the same time.
> >>
> >> --
> >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> >> ***@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-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Chris Albertson]

Are you sure the single chip receiver is not itself an SDR? Maybe using a
little 8-bit uP inside? I don't know.

In any case the jitter on the SDR depends on the sample rate clock. If you
use a decent audio interface the clocks are not bad. A little 4-pin
crystal oscillator controls the sampling. Compared to the propagation
delay the quality of that crystal is a not a big deal.

On Fri, Oct 28, 2016 at 10:36 PM, Nick Sayer via time-nuts <
time-***@febo.com> wrote:

> That single-chip version is going to have a *LOT* less (and less variable)
> latency than an SDR.
>
> > On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <***@phk.freebsd.dk>
> wrote:
> >
> > --------
> > In message <5A002554-8D90-4C75-95DA-***@kfu.com>, Nick Sayer
> via time-
> > nuts writes:
> >
> >> If you’re in North America, a CHU receiver is a lot easier to make
> >> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
> >> it was a one-chip solution 20 years ago when I made one in college.
> >
> > We have CPUs and sounds-cards these days...
> >
> > Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
> > station you want: You can track GPS and four (possibly 8) VLF/HF
> > stations at the same time.
> >
> > --
> > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> > ***@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-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

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

[Nick Sayer via time-nuts]

No, no, no.

The single chip in this case is an AFSK decoder. You still have to have an ordinary HF AM radio.

> On Oct 29, 2016, at 11:21 AM, Chris Albertson <***@gmail.com> wrote:
>
> Are you sure the single chip receiver is not itself an SDR? Maybe using a little 8-bit uP inside? I don't know.
>
> In any case the jitter on the SDR depends on the sample rate clock. If you use a decent audio interface the clocks are not bad. A little 4-pin crystal oscillator controls the sampling. Compared to the propagation delay the quality of that crystal is a not a big deal.
>
> On Fri, Oct 28, 2016 at 10:36 PM, Nick Sayer via time-nuts <time-***@febo.com <mailto:time-***@febo.com>> wrote:
> That single-chip version is going to have a *LOT* less (and less variable) latency than an SDR.
>
> > On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <***@phk.freebsd.dk <mailto:***@phk.freebsd.dk>> wrote:
> >
> > --------
> > In message <5A002554-8D90-4C75-95DA-***@kfu.com <mailto:5A002554-8D90-4C75-95DA-***@kfu.com>>, Nick Sayer via time-
> > nuts writes:
> >
> >> If you’re in North America, a CHU receiver is a lot easier to make
> >> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
> >> it was a one-chip solution 20 years ago when I made one in college.
> >
> > We have CPUs and sounds-cards these days...
> >
> > Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
> > station you want: You can track GPS and four (possibly 8) VLF/HF
> > stations at the same time.
> >
> > --
> > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> > ***@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-***@febo.com <mailto:time-***@febo.com>
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts <https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
> and follow the instructions there.
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California

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

[Hal Murray]

***@kfu.com said:
> That single-chip version is going to have a *LOT* less (and less variable)
> latency than an SDR.

Latency isn't an issue as long as it is known so that you can correct for it.

Has anybody measured the jitter through SDR and/or tried to reduce it? I'd
expect that even if you counted cycles and such there would still be jitter
from not being able to reproduce cache misses and interrupts.

--
These are my opinions. I hate spam.



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

[Attila Kinali]

On Fri, 28 Oct 2016 23:01:52 -0700
Hal Murray <***@megapathdsl.net> wrote:

> ***@kfu.com said:
> > That single-chip version is going to have a *LOT* less (and less variable)
> > latency than an SDR.
>
> Latency isn't an issue as long as it is known so that you can correct for it.
>
> Has anybody measured the jitter through SDR and/or tried to reduce it? I'd
> expect that even if you counted cycles and such there would still be jitter
> from not being able to reproduce cache misses and interrupts.

Should not be too high. If Jeff Sherman's and Robert Jörden's paper[1]
is any indication, then the jitter should be dominated by the jitter
of the ADC and its reference oscillator. So sub-ps, order of 100fs jitter
should be possible with proper design. Long term drift is another issue
and I have not completely figured out what are the contributors there.
Temperature stabilizing for sure helps, but it doesn't seem to be the
only effect.


Attila Kinali

[1] "Oscillator metrology with software defined radio",
by Jeff Sherman and Robert Jörden, 2016
http://dx.doi.org/10.1063/1.4950898
http://arxiv.org/abs/1605.03505


--
Malek's Law:
Any simple idea will be worded in the most complicated way.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Poul-Henning Kamp]

--------
In message <***@kinali.ch>, Attila Kinali writes:

>> ***@kfu.com said:
>> > That single-chip version is going to have a *LOT* less (and less variable)
>> > latency than an SDR.
>>
>> Latency isn't an issue as long as it is known so that you can correct for it.
>>
>> Has anybody measured the jitter through SDR and/or tried to reduce it? I'd
>> expect that even if you counted cycles and such there would still be jitter
>> from not being able to reproduce cache misses and interrupts.
>
>Should not be too high.

It should be nonexistent.

The sensible way to do SDR-timing, is to capture a signal from the disciplined
oscillator with the ADC samples, so that their precise timing relationship is
firmly bolted down.


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[jimlux]

On 10/29/16 4:49 AM, Attila Kinali wrote:
> On Fri, 28 Oct 2016 23:01:52 -0700
> Hal Murray <***@megapathdsl.net> wrote:
>
>> ***@kfu.com said:
>>> That single-chip version is going to have a *LOT* less (and less variable)
>>> latency than an SDR.
>>
>> Latency isn't an issue as long as it is known so that you can correct for it.
>>
>> Has anybody measured the jitter through SDR and/or tried to reduce it? I'd
>> expect that even if you counted cycles and such there would still be jitter
>> from not being able to reproduce cache misses and interrupts.
>
> Should not be too high. If Jeff Sherman's and Robert Jörden's paper[1]
> is any indication, then the jitter should be dominated by the jitter
> of the ADC and its reference oscillator. So sub-ps, order of 100fs jitter
> should be possible with proper design. Long term drift is another issue
> and I have not completely figured out what are the contributors there.
> Temperature stabilizing for sure helps, but it doesn't seem to be the
> only effect.


Well, that's "jitter in the original samples" which can be very low, as
you describe. But I would interpret the original question as "jitter
*through* an SDR" which implies that we're looking at the timing of
output vs input.

Consider an SDR which receives a RF signal that's BPSK modulated, and
puts out a stream of data bits on a wire (as opposed to dumping into a
file or network connection)- and you want to look at an eye diagram of
the output.


>
>
> Attila Kinali
>
> [1] "Oscillator metrology with software defined radio",
> by Jeff Sherman and Robert Jörden, 2016
> http://dx.doi.org/10.1063/1.4950898
> http://arxiv.org/abs/1605.03505
>
>

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

[Attila Kinali]

On Sat, 29 Oct 2016 09:35:25 -0700
jimlux <***@earthlink.net> wrote:

> > Should not be too high. If Jeff Sherman's and Robert Jörden's paper[1]
> > is any indication, then the jitter should be dominated by the jitter
> > of the ADC and its reference oscillator. So sub-ps, order of 100fs jitter
> > should be possible with proper design. Long term drift is another issue
> > and I have not completely figured out what are the contributors there.
> > Temperature stabilizing for sure helps, but it doesn't seem to be the
> > only effect.
>
>
> Well, that's "jitter in the original samples" which can be very low, as
> you describe. But I would interpret the original question as "jitter
> *through* an SDR" which implies that we're looking at the timing of
> output vs input.

Oh.. yes...The whole latency into the PC is a whole different game.
I don't know the numbers for SDR, but for soundcards that delay jitter
is usually in the couple 100µs range, Ie way lower than most people
would notice. But this is only true if the OS reports the buffer sizes
correctly. On Linux that means no pulseaudio as it is known to mess up
the buffer reporting completely, to the point where it was off by 10's of ms.

I don't know what the numbers under windows are, but as I have never heard
of any problems there it might just work correctly out of the box.

Those I know who do precsision timing with SDR usually use the timestamping
facilities on the SDR hardware and process those timestamps within GnuRadio.

Attila Kinali
--
Malek's Law:
Any simple idea will be worded in the most complicated way.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Chris Albertson]

There is zero jitter through the SDR software because you can always buffer
the output and then reclock it on output and all you have to deal with is a
known fixed delay. If the samples are clocked in accurately that is all
you need.

Some audio interfaces have can have very good timing and run off an
external reference oscillator. But those are typically found in
professional studios. (Some studios have coax or fiber frequency
distribution.) But The typical home studio audio interface that sells for
under $200 uses a four pin oscillator.

The bigger question is propagation.



On Sat, Oct 29, 2016 at 12:07 PM, Attila Kinali <***@kinali.ch> wrote:

> On Sat, 29 Oct 2016 09:35:25 -0700
> jimlux <***@earthlink.net> wrote:
>
> > > Should not be too high. If Jeff Sherman's and Robert Jörden's paper[1]
> > > is any indication, then the jitter should be dominated by the jitter
> > > of the ADC and its reference oscillator. So sub-ps, order of 100fs
> jitter
> > > should be possible with proper design. Long term drift is another issue
> > > and I have not completely figured out what are the contributors there.
> > > Temperature stabilizing for sure helps, but it doesn't seem to be the
> > > only effect.
> >
> >
> > Well, that's "jitter in the original samples" which can be very low, as
> > you describe. But I would interpret the original question as "jitter
> > *through* an SDR" which implies that we're looking at the timing of
> > output vs input.
>
> Oh.. yes...The whole latency into the PC is a whole different game.
> I don't know the numbers for SDR, but for soundcards that delay jitter
> is usually in the couple 100µs range, Ie way lower than most people
> would notice. But this is only true if the OS reports the buffer sizes
> correctly. On Linux that means no pulseaudio as it is known to mess up
> the buffer reporting completely, to the point where it was off by 10's of
> ms.
>
> I don't know what the numbers under windows are, but as I have never heard
> of any problems there it might just work correctly out of the box.
>
> Those I know who do precsision timing with SDR usually use the timestamping
> facilities on the SDR hardware and process those timestamps within
> GnuRadio.
>
> Attila Kinali
> --
> Malek's Law:
> Any simple idea will be worded in the most complicated way.
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

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

[jimlux]

On 10/28/16 11:01 PM, Hal Murray wrote:
>
> ***@kfu.com said:
>> That single-chip version is going to have a *LOT* less (and less variable)
>> latency than an SDR.
>
> Latency isn't an issue as long as it is known so that you can correct for it.
>
> Has anybody measured the jitter through SDR and/or tried to reduce it? I'd
> expect that even if you counted cycles and such there would still be jitter
> from not being able to reproduce cache misses and interrupts.
>

Since I make my living doing SDRs with very stringent output vs input
timing requirements --

This is a little bit like discussing "what is hard real-time software"

distinguish between an SDR where the signal processing chain is
implemented in a reprogrammable FPGA (hence, "soft") and one where the
signal processing chain is implemented in a general purpose processor
(e.g. gnuradio).

Having low jitter in an FPGA implementation isn't hard, down to the
basic timing resolution of the FPGA: the clock rate, etc. That gets
you into questions about jitter relative to what: if I feed in a highly
accurate 1pps and use that as the sampling clock, then the jitter
relative to the 1pps will be quite small (if not zero) - if I register
that 1pps with a 10 MHz clock that is asynchronous to the 1pps, then
I've bumped the jitter to 100ns - plenty of discussion on this list
about hardware level jitter (which is what FPGA implementations really are).


In the more traditionally software (running on a CPU) it depends a lot
on your design architecture: If your hardware time stamped the samples,
and the "output" of the system has a hardware control that can read time
stamps, then you can have a system with large latency, but small jitter.
You put some FIFOs in the system to accommodate the processing time
variation, and the latency is determined by hardware tick in to hardware
tick out.

If you're talking about something like gnu radio - it has almost no
provision for latency control - it's a non-deterministic processing
chain where data is passed from block to block like a signal flow
diagram. What control is there is limited by the host OS being able to
"keep up". Implementing closed loop systems in gnu radio is very
tricky as a result, likewise, implementing something like a coherent
transponder (where the output signal has to have a precise and
consistent phase relationship with the input signal) with gnuradio would
be tough

Somewhere in between are various "real time" implementation approaches:
if your processor has a periodic interrrupt capability, and the CPU
clock is driven from the same clock as everything else (e.g. it's a soft
core in an FPGA), then you're in the "hardware controlled" area: if I
get an interrupt every millisecond, counted down from my 100 MHz master
clock, then I can make a pretty low jitter system with 1 kHz sample
rates - most processors have fairly deterministic interrupt handling
time if the interrupt is high enough priority. And you keep your
interrupt code very simple and short:

my_isr:
load register from ValueFromMemory
output register to I/O address
return from interrupt

you might also need to do some stuff like hold the value in a register
all the time (so you don't get a variable time in the fetch)

Would this work on a modern X86 with pipelines, speculative
execution, multiple thread CPUs, etc.? I don't know enough about how
the interrupt logic works - is code executing in an ISR running in a
mode where the CPU has all the fancy bells and whistles turned off?




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

[Chris Arnold via time-nuts]

Any freeware out there to decode WWVB or any of the other standards out there? Using an audio card and pc?
I've tried RadioClock and Clock that comes with Multipsk, but want to see whats else is out there. Not looking for anything to set the PC clock, just a mild curiosity of whats happening, signal quality or other info its putting out.


N3IZN



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

[Chris Albertson]

Yes, you may even already have such software installed on your computer.
It comes with the standard NTP server installation. If you modify the NTP
config file to use a WWVB reference clock then it will load the driver and
listen on an audio interface

On Sat, Oct 29, 2016 at 12:32 PM, Chris Arnold via time-nuts <
time-***@febo.com> wrote:

> Any freeware out there to decode WWVB or any of the other standards out
> there? Using an audio card and pc?
> I've tried RadioClock and Clock that comes with Multipsk, but want to see
> whats else is out there. Not looking for anything to set the PC clock, just
> a mild curiosity of whats happening, signal quality or other info its
> putting out.
>
>
> N3IZN
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

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

[Hal Murray]

***@gmail.com said:
> I have some long (24 hour) WAV files and will see if I can come to any
> determination about the offset and spread of the sampling rate. e.g. if the
> sampling rate nominally 44100, how precise is that in my PC's hardware? I
> would bet this is tied to a crystal in the audio section of the sound card
> and thus completely independent of any ntpd stabilatization being done to
> the system clock.

It's important/interesting if you are a geek.

I think the IRIG refclock driver for ntpd used to tell you the actual speed
of your audio clock. Overall, it worked well enough that the clock speed was
significant and was corrected for.


--
These are my opinions. I hate spam.



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

[Hal Murray]

***@gmail.com said:
> Or should I, say, take the PPS from a GPS, and feed it into channel 2, with
> the audio going into channel 1, and make a stereo recording? ...

I assume the audio API is for a batch of samples. If you get time stamps on
a stream of batches, you can work out the frequency of the crystal the audio
A/D is using.

I think you will need the PPS approach to calibrate the delay through the
system. If it's low enough, you can drop it.

--
These are my opinions. I hate spam.



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