Re: [time-nuts] Linux TSC clocksource on multi-core systems

[Michael Tharp]

On 04/26/2014 02:27 PM, Laszlo Hanyecz wrote:

It's fine to disable the additional cores/cpus on a dedicated NTP machine, but 
I wonder if there is a solution that allows both the TSC and all the cores to 
be used at the same time.  Is it even possible to completely sync the counters 
across CPUs (not just get close)?


You could try pinning ntpd to a single CPU using the "taskset" command. 
It wouldn't give all the applications the benefit of a perfectly 
synchronized clock, but if you just want ntpd to be happy then it ought 
to work as well as turning SMP off.


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

Re: [time-nuts] ARM boards for low-cost GPSDOs

[Michael Tharp]

On 04/10/2014 05:38 PM, Hal Murray wrote:


Does anybody have a favorite low-cost ARM board?  I'm looking for a simple
Arduino like setup rather than something that runs Linux.  The idea is to get
32 bit counters so a bunch of the recent discussion can be ingnored.



Another endorsement for a STM32 Discovery board from me. The F3 and F4 
ones have plenty of peripherals to play with and they're cheap as dirt.


For a concrete example of how the kind of PPS capture that's being 
discussed would pan out on STM32, here's mine:


https://github.com/mtharp/laureline-firmware/blob/master/src/ppscapture.c

The timers are 16-bit but I extend it to 64 bits in software. When the 
timer rolls over I add 65536 to the software variable "mono_epoch". At 
both the rollover and at the half-way mark I poll the timer-capture 
peripheral to see if it captured a PPS. It's polled twice per period to 
ensure that I can disambiguate whether the captured value came from the 
current period or the previous one. The result is a 64-bit timestamp 
from the free-running clock, and it's completely glitch-free and not 
affected by interrupt latency in any way.


The same timer is also used as the base for the UTC clock, which is a 
software-disciplined clock like you'd find in any OS kernel. That makes 
it easy to compare the phase of the PPS captured to the nearest UTC 
second and feed into the PLL. Not as interesting for a GPSDO where you 
need to actually steer a hardware oscillator, but useful nonetheless.

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

Re: [time-nuts] GPS choices.

[Michael Tharp]

On 9/9/2013 11:08, Paul wrote:

Although the inexpensive yet high sensitivity units are nice I'm not
sure why someone would choose a positioning MTK (e.g. Adafruit) over a
timing Ublox (or even an old Motorola style timing receiver).

Am I missing something?


In a word, availability. Try buying a NEO-6T in quantity of less than a 
reel (hundreds of pieces), for less than $180 (cost of a sample direct 
from u-blox). NEO-6M can be bought in small quantities on the grey 
market, for example aliexpress has dozens of such vendors. You also have 
many choices of evaluation board if you don't want the raw module.


Good positioning modules like NEO-6M are more than sufficient for less 
demanding applications like NTP, and even have some timing features like 
sawtooth correction. It also has a "stationary" mode that isn't really 
position hold but at least tunes the algorithm to assume the antenna 
usually isn't moving.



Also is the (up to) 10MHz output from a 6T as useful as it seems it
should be given ~30/15ns quoted accuracy?


Not sure but I suspect you wouldn't want to use it directly. Locking a 
OCXO to it would be trivial.

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

Re: [time-nuts] display on sale

[Michael Tharp]

On 5/29/2013 12:11, Robert Darlington wrote:

I ordered two PoE clocks, one with the 12 hour face, one with the 24 hour
face.Earlier this week I considered using the Vetenari Clock project
circuit board to control a cheap analog clock movement and have it do my
bididng -however I can't write the code in $99 of my free time!


Note that the clock in the Vetenari kit is just a cheap quartz clock 
like you could get anywhere, and the replacement board it comes with 
isn't of any use if you're trying to do something different. Basic 
quartz clocks are not a good choice for hacking into a precision display 
because they can only tick forward in one second increments, with no way 
to know what time is being displayed nor a reasonable way to adjust 
forward or backward an hour for daylight time changes. In other words, 
you can make it tick precisely but you can't really set it.


I'm sort of interested in getting an analog WWVB type clock and seeing 
how much work it would be to coopt *that* hardware since it is designed 
to set arbitrary times, but I have a feeling I'd be better served making 
my own mechanics with a stepper motor and reduction gear. Of course a 
digital clock would be much less complicated, which is what Miguel was 
asking about to begin with, but that's not nearly as much fun.


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

Re: [time-nuts] 5V antenna on 3V receiver via dist. amp?

[Michael Tharp]

On 05/02/2013 03:26 PM, Paul wrote:

Is it reasonable to to use a GPS distribution amplifier (viz. HP
58516A) to power a five volt antenna feeding three volt receivers or
should I get a "bias tee"?  The internal operation of my electronics
is largely a mystery to me.


Bias tee would be best because it does exactly the thing you need and no 
more, so it is difficult to miss some small detail and end up in a bad 
configuration. Bias tees have a DC connector to supply power so it will 
be easier to hook up. Look for models that block DC, so you don't expose 
your 3V GPS receiver to 5V power.


A distribution amplifier (like the 58516A) should also be OK. If you are 
going to have a GPS receiver that can provide 5V to the antenna and 
amplifier, that would be ideal. Otherwise you will need to make a 
connector to put 5V on the DC port of the amplifier.


What you don't want is a passive splitter. If you connect a power supply 
directly to the DC port it will short the GPS signal into the supply's 
capacitance and your signal will be distorted or suppressed.

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

Re: [time-nuts] Atomic Watch.

[Michael Tharp]

On 5/1/2013 11:40, Sarah White wrote:

I tweeted the author of this article, trying to point out that (as I
understand) "radioactive decay" is not relevant in any way for cesium
frequency standard/reference thingies:

https://twitter.com/kuzetsa/status/329618223916011520

If someone more authoritative and/or experienced (or at least more
awake) wanted, please let me know if I was confused and such


Symmetricom doesn't go out of their way to say how the damn thing 
actually works, but it sure isn't radioactive decay. Decay is entirely 
unpredictable due to the nature of quantum mechanics and can only be 
described in statistical terms (averages and probabilities). But it's a 
very common misconception that I, too, once held. To most people, 
"atomic" means radioactive, fissioning, or fusioning.


This seems to be the technology being used, it looks similar in a broad 
sense to a Rb oscillator but without the microwave excitation:


http://tf.nist.gov/ofm/smallclock/CPT_clocks.html

CSAC has definitely been discussed here before but the threads my 
searches are turning up do not seem to investigate its theory of operation.


As for the article, The Register is not an outlet known for precise 
reporting. Take it as a journalistic liberty.


NB: Your tweet is not visible to me, so it's somewhat difficult to 
fact-check :-)


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

Re: [time-nuts] Is possible precise 1pps?

[Michael Tharp]

On 03/13/2013 09:05 PM, David wrote:

This brings up something that I have wondered about for a while.

The Garmin GPS18x (and many other receivers) specify the PPS output as
within 1uS but does that mean it wanders around over say 12 or 24
hours within 1uS of GPS Time or does it mean something else?  I can
easily see the granularity of the PPS output but that is obviously not
what the specification refers to.


If it's anything like the ancient Motorola receivers I purchased off 
fleabay on the mistaken assumption that they were UT+, it might have a 
1uS phase skip every 20s or so. In other words, after a random number of 
seconds the PPS (and all subsequent PPS) will be exactly 1uS early. The 
idea being that it loosely tracks UTC/GPS, but jumps whenever it gets 
too far away. Totally useless for timing but at least they were cheap.

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

Re: [time-nuts] Is possible precise 1pps?

[Michael Tharp]

On 3/13/2013 13:15, Azelio Boriani wrote:

Then you will start to
appreciate things that will lead you to a timing receiver with the sawtooth
correction.


For what it's worth: I have been evaluating the NEO-6M, a navigation 
receiver, for use in a NTP server which I have posted here in the past. 
It seems to perform quite well. It *does* have sawtooth correction, 
probably because it has a timing cousin (NEO-6T), and is stable enough 
to get RMS jitter to sub-10ns where the "noise floor" of my input 
capture is. It does not, however, have position hold (they have to have 
*some* reason to charge triple the price for a 6T) so over moderate 
timescales it might wander slightly more.


Would I use 6M in a GPSDO? Probably not. But the PPS is pretty good, and 
some navigation receivers *do* have sawtooth correction, which I guess 
was really the point I was getting at.


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

Re: [time-nuts] Embedded NTP server ideas and feature requests

[Michael Tharp]

On 02/10/2013 11:22 AM, Chris Albertson wrote:

Yes there is a standard but there are also may non-standard implementations.

I was a little worried about the comment regarding "isolation" being
hard to implement.   The standard for Ethernet required galvanic
isolation on all Ethernet ports by use of a transformer.  So POE
simply buts a DC bias on the wire.  I think it can provide 12 Watts of
power


Of course the Ethernet data is isolated, as is required by the spec and 
also pretty much needed for anything to work at all. Many transceivers 
won't even work without a transformer to drive into.


I was referring to *power* isolation. Regardless of whether it's the 
more common "unused pairs" type or using center taps as you describe, 
passive adapters don't provide any galvanic isolation between the Cat5 
line and the power input to the device. 802.3af requires this, which 
means a 48V, isolated SMPS is required.


The other advantage to 802.3af is that the powered device advertises its 
readiness to accept power to the switch, and the switch absolutely will 
not turn on the power until it sees that the device can accept it. So no 
surprise 48V on your laptop.


But I suspect this is quite enough PoE talk; I don't want to tire the 
list with non-time-related matters.


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

Re: [time-nuts] Embedded NTP server ideas and feature requests

[Michael Tharp]

On 02/09/2013 08:35 PM, Chris Albertson wrote:

Features?
1) Power the thing with "power over Ethernet" then you can remove the
coaxial power input.  Also this would make it real easy to place the
server right at the antenna location.   You would simply run cat-5 up
to the roof.  The mount the antenna on top of a water proof box with
the server inside the box.  If power has to come in via the coaxel
power connection to a wall-wort then it wil be hard to mount this
server outdoors, near the antenna.


PoE is a great idea, but I think this is better served by using a 
separate, off-the-shelf splitter. It's hard to compete with economies of 
scale. "Real" 802.3af in particular is difficult because of the required 
isolation.



2) You really should make provision for a 5V antenna.  All it will
cost is a tiny little 78L05 to provide a few milliamps.  Put a jumper
on the board to select the antenna voltage.


You're right, and I've been in "digital mode" long enough that I hadn't 
even considered using a linear regulator for that function. Depending on 
the antenna and input voltage the regulator could end up dissipating up 
to a watt but that's quite feasible. That will definitely be in the next 
revision, then.



With the GPS on the server using power over Ethernet makes even more
sense because peoplewill want to place the seaver very near the
antenna to make the wiring simpler.  Wha not go all the way and put a
patch antenna on the board?


Again, this sort of comes down to not being able to serve everyone with 
one board. Maybe I can make a "rooftop package" with a patch antenna and 
passive power injector/splitter in the box. It looks like most ceramic 
patch antennas already have a u.FL (they call it "IPEX") connector which 
is what I was already planning on using internally.


Thanks a bunch for your feedback.
-- m. tharp
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Embedded NTP server ideas and feature requests

[Michael Tharp]

Greetings time-nuts,

I've finally gotten the software for my NTP server project to the point 
where I'm comfortable shipping the boards I have now, so it's about time 
to spin the next revision. If you could take a minute to look over the 
feature list and let me know on- or off-list what you'd like to see, 
hardware or software, I'd really appreciate it.


Here's the current product. I have 3 built and tested, so if you like 
what you see and you have a GPS to hook it up to I'd be happy to send 
one your way.


https://www.tindie.com/shops/gxti/laureline-gps-ntp-server/
http://partiallystapled.com/2013/01/laureline-gps-ntp-server/

There are a few things that I will definitely be changing. For one, 
instead of a "bring your own GPS" I will be integrating a u-blox NEO-6M 
receiver. It's not a timing receiver, but from what I've been able to 
find on this list it is quite suitable for NTP. Should add about $10 to 
the cost but compared to a $30 used Resolution T or similar that's a 
good tradeoff. There will be a header where you can connect your own 
favorite receiver. Alternately, the NEO-6T timing receiver uses the same 
footprint and be soldered down instead, but is much harder to source.


The 5V antenna power will also be removed so there is one less power 
supply to deal with, but if you have an antenna that requires more than 
3.3V then you can use a header to supply any voltage that it might need. 
I will also be beefing up supply filtering. It performs well now but I 
want to make absolutely sure that EMI is a non-issue.


I've heard some people say they'd like a 10MHz output from the server. I 
can break out the (digital) 10MHz clock from the VCXO, and/or provide a 
way to connect your own OCXO if people are interested. The latter will 
require some kind of adapter though as most OCXOs need more than the 
3.3V VFC used here - a simple op-amp gain will work fine - and a limiter 
might also be needed to digitize the sine-wave coming in from the OCXO. 
These can be dealt with separately, though.Simply adding an ovenized 
oscillator and timing GPS one can turn Laureline into a pretty good GPSDO.


On a semi-related note, I have two PPS Piggies in stock in my Tindie 
store as well, so anyone with a Trimble Resolution T or SMT who needs a 
way to hook them up should take a look.


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

Re: [time-nuts] Smart fiber-optic cable ( a reference to Hp's smart clock )

[Michael Tharp]

On 02/04/2013 05:09 PM, Stanley wrote:

If a fiber-optic cable had temperature sensors either installed with or 
embedded inside of this could make for better modeling changes in delay making 
more accurate transfer of time and frequency possible. With fiber to tower 
installs now under way to provide more data at cell towers why not backup GPS 
frequency and time transfer with the same medium ? Would this also increase the 
data rate of the cable ? That is faster rates due to the better timing 
uncertainty.


Take a look at CERN's White Rabbit project. They're doing sub-nanosecond 
time transfer over fiber, including compensating for temperature variations.


http://www.ohwr.org/projects/white-rabbit/wiki

Here is a demonstration in which fiber is blasted with a heat gun:
https://www.youtube.com/watch?v=ZSRQEExbdq8

The hardware is rather specialized at the moment but it seems there is 
ongoing work on making it more generally available. Certainly if the 
telcos were interested they could make it happen, but probably they are not.


There is quite a lot of useful, open-source material coming out of this 
project including a VHDL implementation of a Vernier TDC. At some point 
I plan to use it to build a high-performance TIC.


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

Re: [time-nuts] Raspberry Pi Competition...

[Michael Tharp]

On 1/21/2013 10:26, Rob Kimberley wrote:

http://www.electronicsweekly.com/Articles/28/09/2012/54676/raspberry-pi-gets
-a-competitor.htm
   


Olimex is also making an A10 board with sound industrial design, to be 
available in the near future. The advantage here for time-nuts is that 
the A10 comes with a real Ethernet MAC instead of the USB-based one used 
on the Raspberry Pi, which will vastly improve network performance for 
NTP or PTP. Both the Cubie and the Olimex board should be making


I don't know how much the Olimex board will cost, it will probably be 
slightly more again than the Cubie but considering the Olimex will have 
a more flexible power input scheme and some other nice features I would 
recommend it over this board. Olimex is also a long-running 
hobbyist-friendly business and sells through Digi-Key and other 
distributors, wheras Cubie is "kickstarted" and thus more likely to have 
some teething problems getting a product out the door.


https://olimex.wordpress.com/2013/01/21/a10s-olinuxino-micro-first-prototypes-work-fine/

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

Re: [time-nuts] An embedded NTP server

[Michael Tharp]

On 01/02/2013 08:34 PM, Tom Harris wrote:

Do you really need an OS? Surely for a box that is only ever going to be an
NTP server you just need a network interface and good maths? I've just seen
a later comment where you mention floating point support, but would 64 bit
integer maths work just as well?


You certainly do not need an OS. For this project I am using a RTOS 
called ChibiOS that provides a threading interface and handles the 
tedium of flinging packets as well as timers, serial, etc. but it's not 
an OS in the same sense as Linux is and I'm still interacting directly 
with the critical peripherals.


Since the PPS measurements are being done in dedicated hardware and the 
Ethernet interface is a hard-wired MAC and not USB, it performs quite a 
bit better than something with the overhead of a managed OS. Raspberry 
Pi and some other Linux-ready boards I've seen also use Ethernet 
interfaces built into the USB host, not quite sure why that's more 
cost-effective but it's sure to result in much poorer jitter versus a 
direct MAC.


I'm using a F1 part which does not have a FPU, so all the math is 64bit 
integers. Soft floats are also an option, and for even the fanciest 
GPSDO there's not nearly enough number crunching going on to make a FPU 
absolutely necessary.


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

Re: [time-nuts] An embedded NTP server

[Michael Tharp]

On 12/28/2012 12:34 PM, Chris Albertson wrote:

One idea that I like is to first get a large FPGA.  Then you load in a
"soft CPU" and then you run an OS and NTP on the soft CPU.   Inside
the softCPU the counter is implemented like it is in a real CPU but
you can add the ability for a PPS to "latch" it.  Basicaly you move
the interrupt handler to hardware. The trick is if you can get
good enough performance out of the soft CPU?There is some
intelectual property problems with some soft CPS but I'm pretty sure
there are free SPARC CPS you can use and SPARC is ideal for this as it
can run BSD Unix.


Most microcontrollers that I have seen (PIC, ARM, presumably AVR as 
well) already have a peripheral called "input capture" that does exactly 
this, and that's what my project is using. Since it's part of the timer 
peripheral it usually runs at (up to) the same speed as the CPU which in 
my case is 72MHz, plenty for a decent lock. It simply grabs the current 
value of the counter when a pulse arrives and saves it until the CPU can 
get around to retrieving it. To get another order of magnitude the next 
step would be an analog TDC or a FPGA running a vernier TDC, but you can 
get quite satisfactory results with just an off-the-shelf microcontroller.


Free CPU cores for FPGAs are not a problem, I have investigated a little 
and come up with a few candidates. Right now my favorite would be a 
microblaze clone called aemb, but there is also light8080 (tiny but 
8-bit is a headache) and OpenRISC (fat but full-featured). There is a 
free vernier TDC core as well that is made available by CERN. They are 
using it in their White Rabbit system which does some rather neat things 
with custom Ethernet transceivers and switches that can distribute time 
across significant lengths of fiber to very good precision. I have not 
yet dedicated enough time to finish wiring the TDC to a CPU but I have 
made some progress; it synthesizes but is not yet operating correctly. I 
will be the first to admit I am not very experienced with FPGAs but 
given enough time and interest it can be made to work.


-- m. tharp

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

Re: [time-nuts] An embedded NTP server

[Michael Tharp]

On 12/27/2012 01:41 AM, Michael Tharp wrote:

The good news is that the disciplining algorithm I lifted from my
previous GPSDO project works quite well, and I have the gritty details
of measuring the PPS worked out. If I can get the Trimble working
tomorrow I might have much better results soon, otherwise I'm traveling
for a few days so it'll have to wait until the new year.


And here we go, it works. Much more reasonable, tens-of-microseconds 
jitter figures.


[root@rei ~]# ntpq -pn
 remote   refid  st t when poll reach   delay   offset 
 jitter

==
-138.236.128.36  216.218.254.202  2 u   21 1024  377   68.8193.228 
 0.641
+108.59.14.130   209.51.161.238   2 u  298 1024  377   34.9201.167 
 0.288
+108.61.73.244   96.47.67.105 2 u  300 1024  377   39.5241.135 
 1.604
-64.6.144.6  128.252.19.1 2 u  772 1024  377   84.3296.609 
 0.252
*172.24.0.6  .GPS.1 u2   16  3770.320   -0.073 
 0.016
-172.24.0.66 135.34.116.162   3 u  237 1024  3770.1970.130 
 0.581
x172.24.0.68 172.24.0.6   2 u  291 1024  3770.237  113.341 
77.665
-172.24.0.1  172.24.0.6   2 u  287  512  3770.1232.382 
 0.876


[root@maruko ~]# ntpq -pn
 remote   refid  st t when poll reach   delay   offset 
 jitter

==
-67.18.187.111   129.7.1.66   2 u  965 1024   37   66.6951.952 
 0.842
+174.129.25.69   131.188.3.2212 u  753 1024  377   35.9261.734 
 0.250
*2001:470:1:15b: 132.239.1.6  2 u  513 1024  377  107.2400.982 
 0.373
-172.24.0.1  172.24.0.6   2 u  786 1024  3770.1872.960 
 1.027
+172.24.0.6  .GPS.1 u   55   16  3770.356   -0.008 
 0.060
-172.24.0.64 108.59.14.1303 u  912 1024  3770.3010.058 
 0.685
x172.24.0.68 135.6.140.0  3 u  938 1024  3770.378  243.604 
166.234


[root@hanmyo ~]# ntpq -pn
 remote   refid  st t when poll reach   delay   offset 
 jitter

==
*172.24.0.6  .GPS.1 u   25   64  3770.399   -2.390 
 0.258
 172.24.0.64 172.24.0.6   2 u9 1024  3770.134   -2.273 
  0.708
-172.24.0.66 135.34.116.162   3 u  342  512  3770.216   -2.607 
 1.728
 172.24.0.68 172.24.0.6   2 u  300  512  3770.092  245.910 
124.378
-72.251.251.11   62.192.15.2123 u   22 1024  377  122.988   -0.097 
 1.585
+67.18.187.111   129.7.1.66   2 u  270  512  377   66.916   -1.235 
 3.977
-199.7.177.206   64.147.116.229   2 u  368  512  377   59.0353.838 
 1.815
+50.97.210.169   131.107.13.100   2 u8 1024  377  100.0032.547 
 1.025


hanmyo (172.24.0.1) is a small "digital engine" computer that I use as a 
router; it is pretty much 100% idle, has no fans, and is located in a 
closet where it is temperature stable. At the same time, it shows by far 
the highest jitter figure so I'm guessing its clock is not very good. I 
will have to probe around and see if there is something I can replace, 
because it is the best candidate for characterizing the performance of 
my little NTP server. It's hard to get quality measurements when the 
peer boxes are just ordinary desktops.


I've only been testing this new firmware for ~30m so I will let it soak 
while I'm traveling and when I get back the numbers should look even better.


-- m. tharp


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

Re: [time-nuts] An embedded NTP server

[Michael Tharp]

On 12/26/2012 12:01 PM, Chris Albertson wrote:

The VXCO quality hardly matters for an NTP server.   As long as it
does not gain out loose more then 1 uSecond per second.  In other
words one part per million is fine for NTP.  The goal is not to
produce a 10MHz GDPDO.  Clients using this server over the Ethernet
are happy to keep time ti 1 millisecond.

Most (almost all) NTP servers use a TTL can oscillator.


Indeed, it's just a chip VCXO. Not much of an additional cost, and it 
can be disciplined in hardware. In a PC, the main oscillator is not 
tunable so the kernel has to emulate a tunable clock by tweaking the 
numbers on the way out.


Now that I have the disciplining algorithm implemented I immediately 
discovered a problem -- and it's not my hardware. The receiver I assumed 
was a UT+ is actually a R1121N1145, which doesn't support position hold. 
But even worse, the PPS seems to jump forward by precisely 1ms every 
16-20s and sticks that way. This probably explains the mediocre jitter 
of 0.3-0.6ms in the NTP results I posted on the 25th. With enough 
smoothing I can probably make it work, but in the meantime I will switch 
to using the Trimble receiver which I know works well. My goal with this 
project was always to support as many receivers as possible but the 
100mil pitch header on the Oncore is much more convenient so that's 
where I started.


The good news is that the disciplining algorithm I lifted from my 
previous GPSDO project works quite well, and I have the gritty details 
of measuring the PPS worked out. If I can get the Trimble working 
tomorrow I might have much better results soon, otherwise I'm traveling 
for a few days so it'll have to wait until the new year.


-- m. tharp

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

Re: [time-nuts] An embedded NTP server

[Michael Tharp]

On 12/25/2012 02:51 PM, David J Taylor wrote:

I think you should be able to do better on the jitter as your algorithms
develop.


Yes, for starters something is causing a silly amount of extra latency 
hence the 2.4ms round-trip. I managed to cut that in half by changing 
compiler options but talking to someone using the same stack I should be 
able to get it down to ~ 400us round-trip, at worst. I have some ideas 
on how to achieve that but I want to get all the functionality working 
before I start optimizing.


The main lack of functionality, which may or may not be the cause of the 
jitter, is that I haven't actually integrated the PLL/disciplining stuff 
yet. I just have a timer that resets with each GPS pulse, and runs at 
whatever nominal frequency the oscillator has. Not great but it 
succeeded at getting results fast. Not up to time-nuts standards though. 
Now I'm going back and adding the PLL.



"SNTP" does imply something else, so perhaps avoid calling it that,
although if it doesn't respond to all the NTP management calls I'm
unsure what it should be called!


I suppose that I could call it NTP and still sleep at night since, while 
not a traditional NTP implementation, it does still feature control 
loops similar to those found in purely software-based NTP. I have not 
yet looked at what administrative/query functionality I could implement. 
Some of it like listing peers does not make sense but perhaps other 
commands could be mapped to make it more complete. I would also like to 
expose some of the internal statistics via SNMP or some other means for 
graphing.



Oh, and your Windows box 172.24.0.68 is either poorly configured or
broken - they can work much, much better than yours illustrates as I
expect you know.


Yes, it's not healthy. I installed Meinberg's NTP build and configured 
it using defaults other than the server list but it seems to not be 
tracking well. Right now it's "only" 30ms off but as shown in the forum 
snippet it makes excursions into the hundreds. Still an improvement over 
default Windows timekeeping but I'd love for it to work properly.


-- m. tharp


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

[time-nuts] An embedded NTP server

[Michael Tharp]

Hello and Merry Christmas,

I made an embedded (S)NTP server. The software is still under 
development and will eventually include a low-grade GPSDO but right now 
even the simplistic algorithm is working quite well so I figured I'd share.


http://www.eevblog.com/forum/oshw/%27laureline%27-embedded-gps-ntp-server/

This is a low-level microcontroller implementation, there is no OS nor 
ntpd in the traditional sense. Just enough logic to keep time using the 
incoming PPS and timestamps, and a tiny VCXO to discipline. It's no 
Thunderbolt and there is no clock output but it should be fantastic at 
NTP. Before too long I will have adapters for connecting to Oncore 
GT+/UT+ (and maybe M12, haven't checked) as well as Trimble Resolution T 
and Resolution SMT using a ribbon cable instead of the jumper wires.


All open-source hardware and software. Pictures, details, and design 
documents are in the eevblog thread. I'll let you all know if and when 
I'm ready to sell them, for now I just wanted to show what I've got.


-- m. tharp

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

Re: [time-nuts] STM32 based thing (was GPSDO Alternatives)

[Michael Tharp]

On 12/6/2012 4:26 AM, Fabio Eboli wrote:

Here are the design documents, if you're curious:
http://hg.partiallystapled.com/circuits/serafine/raw-file/d75ab09ca163/out/production.PDF




Thank you very much, I will study it with interest,
it will be very helpul to see what you have done.
Can I ask you more details? I didnt's understand
how you are using the timers: are you timestamping
each pps transistion using the internal clock?
Are you using the pll to obtain 72MHz (x9) for the clock?


Yes, the crystal oscillator is multiplied up to 72MHz which then drives 
the timer. Even though the particular timer peripheral I chose happens 
to be on the APB1 bus which is restricted to 36MHz, the timer itself is 
still fed with the 72MHz clock. Both PPS signals (generated from OCXO 
and received from GPS) are then independently timestamped. The 
timestamps are extended to 64 bits by adding the value captured from the 
IC to an "epoch" variable that is incremented every time the timer 
itself rolls over. This works fairly well but my implementation is 
slightly buggy, occasionally the timestamps will be off by an epoch 
(plus or minus 65536 ticks) but such a large deviation is easily 
detectable and is discarded. The timestamps are subtracted to get phase 
difference which is then fed into the proportional-integral controller 
which seeks to zero the phase difference, with two different "speeds" 
for early startup and later settling once the oscillations dampen. This 
last part is the bit that needs major work since the phase difference 
continues oscillating by up to 5 "ticks" (72MHz periods) and sometimes 
has excursions to 10 or 15 before it settles down again. NTPns seems to 
be self-tuning which could help a great deal. The coefficients I'm using 
are experimentally determined which is probably why the settling isn't 
very good. There's also the problem of not currently having a TIC or 
similar equipment for quantifying the performance of the system as a 
whole, I should buy or build one sooner rather than later.


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

Re: [time-nuts] STM32 based thing (was GPSDO Alternatives)

[Michael Tharp]

On 12/05/2012 08:03 AM, Fabio Eboli wrote:

I'm seriously thinking to attempt a gpsdo.
It's mainly to learn something new.
For some reason I collected some Rb oscillators,
and I'd like to have a 10MHz absolute reference,
so I will try to discipline one of the Rb, and
later maybe an OCXO.

The project will proceed slowly and there is
some probability (small, but not null) that
it will be abandoned, because of time problems
of the author (could be a paradox?).

The platform I will try to use is the STM32F103
microcontroller


Coincidentally, my previous time-nut project was built around the same 
chip. I built a simple GPSDO using a STM32F103C with a bit of support 
circuitry, using the timer in "input capture" mode to timestamp pulses 
and act as a coarse time-to-digital converter. I got a simple PLL 
control algorithm working but haven't yet refined it so it tracks rather 
poorly. My intent was to adopt some of the self-tuning attributes of 
NTPns, which I will likely revisit for the next project.


Some more details about what was on the board:
- A NC7WZ14 CMOS inverter to square up the sine wave from the OCXO, 
which then feeds...
- A PIC12F1501 as a programmable divider, using TVB's picDIV code 
lightly modified to work on that particular chip
- The STM32F103 itself, which compares pulses from the divider to pulses 
from the GPS receiver and makes adjustments via...
- A slow 16-bit DAC constructed from a PWM output on the STM32, a 
two-pole RC filter, a buffer op-amp, and a third RC pole. This drives 
the OCXO's frequency control. The PWM is also tweaked over 16 
consecutive periods to add 4 more bits of precision, a sort of crude 
pulse-density modulation.
- There's also an op-amp to buffer the 10MHz sine wave for 50 ohm 
output, and a digital buffer for a 50 ohm PPS output from the divider


Here are the design documents, if you're curious:
http://hg.partiallystapled.com/circuits/serafine/raw-file/d75ab09ca163/out/production.PDF

The precise parts of course are not important, it's just an example of 
things I chose to get the job done. The general shape of it is the same 
as many, if not all, other GPSDOs out there. I'm reasonably happy with 
the hardware as a GPSDO experimentation platform (but not looking to 
sell anything at this time).


The current project, as I've mentioned before, is a self-contained 
GPS-to-NTP server based on STM32F107, which has built-in ethernet but is 
otherwise very similar to the F103. The finished board won't be nearly 
precise enough to compete with a "real" GPSDO as it is based on a small 
on-board VCTCXO but should shore up the algorithms enough for me to 
revisit the GPSDO again.


-- m. tharp

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

Re: [time-nuts] eBay Ublox

[Michael Tharp]

On 11/21/2012 06:24 AM, David J Taylor wrote:

I only use gpsd on the Linux system, and then only because it was the
first thing I discovered when searching with Google.  As the precise
timing is from the PPS signal fed to the GPIO pin, with a GPIO interrupt
handler, I am forced to use that.  I don't think the interrupt handler
talks to the gpsd at all, but I might be wrong.  There is no DCD line on
the Raspberry Pi for gpsd to receive the PPS signal.


What you have is probably better than the typical RS-232 DCD line. 
Ultimately it's doing the same thing with mostly the same code -- 
triggering an interrupt when the line changes, and timestamping that in 
the kernel to keep the slippage between the pulse being input and NTP 
getting to process it as low as possible. There is also a PPS driver for 
serial ports, which is the best way to do it when you are using a serial 
port.



As a lot of this is new to me, my understanding is not as complete as I
would like.  VMS device drivers I used to understand.  I think I have a
moderate knowledge of Windows and how .SYS drivers fit in, and how DLLs
might support them.  What Linux "modules" are I don't yet know, so why I
need both a revised kernel /and/ modules on Linux to support PPS is
currently unknown - although my guess is that the modules are the
equivalent of Windows device drivers.


They are the same, although Linux modules almost always need to be 
compiled against the specific kernel version while Windows drivers are 
typically only bound to which release you're running. That is the reason 
you have to compile the kernel, rather than just plop down a driver 
downloaded from the internet. That said, the reason your PPS driver is a 
module is that it makes it easier to tweak options. Almost all modules 
that are part of the main kernel source (which PPS is, for a year or so) 
can be compiled in rather than as a separate module, but you can pass 
options to a module as you load it while you cannot do that with a 
builtin. It also makes it possible to tweak the source, recompile just 
that module, and test it on the fly rather than recompiling the entire 
kernel and rebooting.


With respect to interrupt latency, the PPS driver is the best you're 
going to get without a custom add-in card that provides input capture 
(timestamping). I considered going that route but making PCI or PCI-e 
cards essentially means using FPGAs which are expensive and fussy, and 
sort of overkill. A I2C or SPI based card for use with Raspberry Pi or 
other single-board computers is also a possibility. But instead I'm 
looking at a microcontroller based solution with no conventional OS that 
will act as a pure NTP server (no client) with built-in GPSDO. IMHO it's 
more elegant to eliminate the software PLL. That project is next on the 
plate after I finish a current non-time-nuts project also using 
Ethernet, to familiarize myself with the Ethernet hardware.


-- m. tharp

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

Re: [time-nuts] Year 2000?

[Michael Tharp]

On 11/21/2012 06:58 AM, Magnus Danielson wrote:

It was a common mode error to both servers. It's worth nothing that even
a high-ranked clock house like USNO can have these errors so trusting
the one and true server can fail greatly. NTP by it's design has methods
to handle these kind of errors given sufficient many refences, where as
for example PTP always trust its server. If USNO would have had multiple
(different) time-links to their servers they could have potentially
mittigated this before it hit the server time.


Unfortunately, default timekeeping on windows seems to be of the simple 
variety, where it sets the clock once a day from a single sample. It's 
really problematic considering Active Directory depends greatly on time 
synchronization to do its job -- I saw reports of domain controllers 
applying that time change to the year 2000 and needing to be restored 
from backup. I've seen some documentation that suggests that there is 
NTP-like functionality built into the server editions at least, but 
having looked at a build server whose clock was a few minutes off I see 
no such thing. Third-party NTP builds such as meinberg's of course get 
the job done with no fuss.


You're right though that anyone impacted by this has configuration 
problems to solve, even USNO servers are not to be fully trusted.


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

Re: [time-nuts] Accurate timestamping on computers (previously: For mywhole life timezones have been weird)

[Michael Tharp]

On 11/03/2012 05:05 AM, Sarah White wrote:

Seeing as I'm in the process of installing a hardware refclock (trimble
thunderbolt connected via serial port) for my NTP, it is highly
problematic and potentially error-prone for microsoft's OS to touch the
bios hardware clock AT ALL.


Just in case it isn't perfectly clear from the other replies, the 
hardware RTC is not used for timekeeping while the system is running. 
There are a number of other timers in your typical PC which are used for 
actual operational purposes, e.g. HPET and TSC. These tick fast enough 
(>10MHz) that the OS kernel can "discipline" them in software by 
altering the number of ticks considered to comprise a second. As far as 
I know none have a voltage-controlled oscillator but that would 
certainly be interesting :-)


The RTC's current purpose is to keep time while the system is off, as it 
can run for many years from a lithium coin cell, and to wake the system 
at a scheduled time if desired. Adjusting the RTC will have no impact 
whatsoever on the running system clock(s) and, as pointed out elsewhere, 
internally even Windows keeps time in UTC. That said, I'm all for 
storing UTC in the RTC for more practical reasons, e.g. dual-boot 
compatibility and avoiding shenanigans if the power is cut during the 
changeover window. Maybe someday they will be sufficiently motivated to 
cut their ties to the past.


-- m. tharp

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

Re: [time-nuts] RasberryPi, timing and GPS receivers

[Michael Tharp]

On 10/16/2012 06:28 PM, sh...@impsec.net wrote:

I'm a junior time-nut at best but it looks to me like jitter from the
USB Ethernet is acceptably low, based on ntpq -p anyway:


It's a minor problem at worst. There are many worse conflating factors 
and NTP adjusts very slowly anyway to deal with receiving time over the 
internet. Supporting a more precise protocol like PTP, or even better 
CERN's White Rabbit extensions to it, is another matter and at that 
point you're using all custom hardware including switches. Not good for 
the bank account.


That said, I have considered a project almost identical to what
George is describing -- a very simple Linux-powered board that consumes 
negligible power and whose sole purpose in life is to run a NTP server 
from GPS. My focus was on doing it from scratch as a single PCB (except 
the GPS module, for now), but it seems the choices for easily sourceable 
Linux-capable microprocessors that are in 1mm BGA, let alone non-BGA, 
can be counted on one hand. AM1707 was the chip that I would use for the 
"off the shelf microprocessor" approach.


It may actually be more effective -- and cool -- to use a FPGA and 
implement a microprocessor inside that instead! I have booted linux on a 
ORPSoC soft processor, but that was on a $300 dev board. Scaling it down 
to a cheap single-board computer would be challenging but not 
unthinkable. That particular SoC requires quite a lot of FPGA resources 
so something else would be required to avoid needing a $30 FPGA.


But my current plans, not fully baked nor on any sort of schedule, 
involve neither linux nor a conventional ntpd. I'm designing a low-cost 
GPSDO around an ARM microcontroller that keeps its own time and is 
capable of acting as a "dumb" NTP server -- it would respond to requests 
from clients but would not receive time from other nodes. The loop would 
be stabilized solely by GPS although the loop algorithms will probably 
be adopted from NTPns because they are quite similar to what the GPSDO 
itself needs to do. I was originally planning to only support an 
ovenized oscillator as the LO, but it would also be possible to use a 
tunable TXCO or perhaps a small OCXO that could reside on the board and 
not take up much space or power. Connect 3 of these to the network and 
you've got a great stratum 1 pool.


Right now I have a prototype GPSDO working although the loop algorithm 
is amateurish. I've been putting off working on it for a few weeks now, 
I need to sit down and study NTPns so I can implement a similar 
algorithm. The current one would be good enough for NTP but does not yet 
track time of day. The network components are not in the prototype, but 
I have written some sample code into another project that does have 
ethernet and it seems to work, so putting the two pieces together should 
result in a great NTP server.


Oh dear, now I've written quite a lot and probably raised some eyebrows. 
Better quit while I'm behind.


Happy ticking,
-- m. tharp

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

Re: [time-nuts] RasberryPi, timing and GPS receivers

[Michael Tharp]

On 10/16/2012 05:06 PM, x...@darksmile.net wrote:

My goal is to design a custom board for the Pi and mount a GPS receiver
on it. With this combination, I should be able to configure NTP for the
Pi and thus have the Pi act as a Stratum 1 NTP server.

The new RasberryPI has 512MB memory so it should be fine for running
just ntpd.

Question: What GPS timing module should I go with? No more Motorola
Oncore so what's best right now? Who sell modules? What are the price
ranges?


It's not a terrible idea, but the RPI has a USB ethernet transceiver so 
in addition to the latency/jitter of the ethernet it also has the 
latency/jitter of the USB. I've also heard of stability problems just 
keeping it running for weeks to months so you should integrate some kind 
of watchdog timer if you can. The actual GPS module doesn't matter much 
since NTP will smooth out even the worst GPS jitter. I have heard 
second-hand (or third-hand or fourth-...) that some have a significant 
persistent delay and that could be more of a problem. If you want to go 
for a timing-oriented receiver you can get a used Trimble Resolution T 
from ebay but they have a 2mm pitch header.


You will want to house the RPI and GPS receiver in a box where it will 
not be subject to wide temperature swings, insulated and shielded from 
drafts. It would also be interesting to upgrade the main oscillator to a 
temperature-compensated model so NTP doesn't have to work as hard to 
keep the frequency locked.


Personally I would recommend getting a more robust single-board 
computer, e.g. a PC Engines ALIX or Olimex olinuxino. RPI is cheap but 
hard to source, not open-source, and does not have good long-term 
prospects due to the microprocessor being used. Most of the attention is 
due to deliberate publicity by the manufacturer and not novelty or 
merit. If you must use the cheapest board then by all means do so, but 
just know there is better available for not much more.


Happy ticking,
-- m. tharp

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

Re: [time-nuts] 57600 baud rate with Basic etc

[Michael Tharp]

On 10/10/2012 11:49 AM, Bob Camp wrote:

No easy solution. Serial com is still with us because it's a lowest common
denominator. I'm sitting here coding it into a new product right now (once
the uber super compiler finishes a build). It's supported on just about
every chip set in the universe. I suspect it will outlive the cockroaches.


Basic serial has its merits, but it's regrettable that RS-232 came out 
on top. RS-422 (or full-duplex RS-485, not much difference) would have 
been a much better choice. Differential so it has good noise resistance, 
and it doesn't use weird voltages (-12V? come on...)


It all looks the same from the software side though. Bytes in, bytes out.

-- m. tharp

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

Re: [time-nuts] RFX GPSDO - Anybody played with one of these?

[Michael Tharp]

On 10/02/2012 10:37 PM, Jim Lux wrote:

Intriguing.. Can it handle the Doppler, etc., for a cubesat in LEO?
(7km/s)  The total Doppler isn't usually the issue (the GPS satellites
are moving faster, after all), but the receiver may not work for high
velocities, high altitudes?


GPS receivers that function "above 60,000 feet altitude and at 1,000 
knots velocity or greater" are classified as munitions under ITAR. This 
doesn't make them illegal to possess or use as far as I know, but 
exporting them from the US is troublesome so civilian receivers will 
cease functioning under those conditions. Whether that's 60k feet and 
1000 knots simultaneously or separately, is up for debate and probably 
depends on the manufacturer's interpretation.


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

Re: [time-nuts] GPSDO control loops and correcting quantization error

[Michael Tharp]

On 09/14/2012 05:31 PM, Chris Albertson wrote:

Michael: Actually implementing a 16 bit DAC to its 1-bit minimum
resolution will be headache enough. You will gain a real education in
good grounding practice, shielding, power supply stability and noise,
and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's
the name of that tune.


Probably true, luckily as others have mentioned the long-term stability 
of the DAC and its voltage source are less important.



I think the step size would be close to the same with the 32 bit DAC
but the reason you use it is so you can control just about any OCXO,
Rb or other things you drop in.  In other words I'd use the extra bits
to extend the voltage range.  But while in use, I doubt you'd ever
change the highest 16 or 18 bits

Also if you are building a general purpose controller for OCXOs and
Rb, remember that some Rb oscillators use RS-232 control to set the
frequqecy.  It might be good to build in an RS232 port.   The firmware
in the uP can always be changed but hard to add the DB9 connector
later.

One otherthing I was doing when I was working on a design like this
was to discipline both an XO and an Rb from the same GPS.  Almost like
building two controllers but you save some because you can use one uP
and one GPS interface.   Now that you have a disciplined Rb it can be
used for hold over in case the GPS goes away.   I thought it would be
unlikely for GPS to actually fail but allowing for hold over would
make the entire unit portable.


I had this idea as well, although not for disciplining the Rb (which 
unfortunately mine cannot, it's a less popular Efratom model clearly 
pulled from telecom application and has no external control that I can 
see) but just as a backup timing source for holdover. I've mentioned it 
here before, but the gist would be to estimate its frequency while GPS 
was working, then if GPS fails use the Rb instead either by dividing it 
by the last known frequency or by adding the error to the measurement 
loop. That said, I would like the holdover performance with just the 
OCXO to be as good as possible in its own right.


I'm planning to make a future version of this project available but this 
first revision is mainly an experimentation platform and wouldn't be of 
much use to someone who doesn't have the same equipment as me. Stay tuned...


-- m. tharp

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

[time-nuts] GPSDO control loops and correcting quantization error

[Michael Tharp]

Greetings nuts,

I've been working on a simple GPSDO as a starting point for further 
experimentation. I'm using a STM32 microcontroller running at 72MHz as 
the heart, with the input capture peripheral comparing the phase of the 
pulses-per-second and a 16 bit PWM DAC to drive the VFC. It's all 
working quite well from a functional standpoint although I'm sure the 
performance will be quite terrible by time-nuts standards, unfortunately 
I don't yet have the equipment to characterize precisely how terrible it 
is, but that will come later. So now that the basic functionality is 
there I've got a few questions about improving it.


First off a technical question. I'm using a Trimble Resolution SMT as 
the pulse-per-second source. It sends a supplemental timing packet that 
contains an estimate of the quantization error in its pulse output. But 
the manual isn't clear on whether that applies to the next pulse or to 
the previous one. I've seen people correct the delay by using a 
programmable delay line which seems like it would only be possible if 
the measurement was for the next pulse. But on the other hand there is a 
"pulse was not generated" alarm that definitely applies to the previous 
(non)-pulse which suggests that maybe other fields refer exclusively to 
the previous pulse. I can handle either way since the pulses are 
timestamped asynchronously and can be post-processed at any time but 
from some preliminary data collection it's not clear which way it's 
meant to go. Does anyone know for sure whether the quantization error is 
for the next or preceding pulse?


Secondly, a more general design question. Right now the feedback is done 
through a relatively fast PI controller. For example, here's a chart 
showing convergence at various integration coefficients:

http://partiallystapled.com/~gxti/circuits/2012/09/13-pid-ki.png
The Ki coefficient units are somewhat arbitrary due to the fixed-point 
math, but the X axis is seconds and the Y axis is number of counts at 
72MHz (13.89ns). Right now I'm using Ki=1 because it converges quickly 
enough and also don't oscillate, but these parameters are only 
particularly interesting on startup. Something much, much slower seems 
more suitable for continuous operation. But I'm thinking that the best 
solution might be to start out with fast convergence like this, then 
switch to slower parameters (for PI controller and smoothing) once some 
desired level of stability is reached. Any thoughts on this change of 
parameters, or PI tuning in general, or perhaps an entirely different 
control topology?


Finally, do people think a 16 bit DAC is adequate or should I consider 
building a 32-bit one? I looked at a few designs when putting this 
together but decided to keep it simple until things were up and running. 
There is some room for expansion if I want to replace the DAC or add a 
third oscillator input for holdover. In fact, this board seems to have 
more connectors than ICs:

http://partiallystapled.com/~gxti/trash/2012/09/08-serafine.jpg

Cheers,
-- m. tharp

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

Re: [time-nuts] Re; New Wrist watch

[Michael Tharp]

On 09/10/2012 06:36 PM, Bob Smither wrote:


May not be redundant for time nuts! I have an NTP client on my Android and it
shows the network time (Sprint in my case) is often as much as 2 seconds behind 
UTC.

Anyone else noticed this?


It may not really be using network time, or not using it properly. I had 
a first-gen Palm Pre that, despite having no fewer than 3 precise time 
sources at its disposal, would lose minutes per week and required a 
reboot to synchronize. Eventually a software update fixed it. Seems to 
be an ailment unique to smartphones.


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

Re: [time-nuts] REF osc distribution.

[Michael Tharp]

On 09/05/2012 12:46 PM, Bob Camp wrote:

Hi

There are a number of discrete transistor buffers that have very good
isolation and short term stability / phase noise performance. I'd take a
look at the one from the NIST papers and Bruce's more modern re-design.  All
are in the archives. http://tf.boulder.nist.gov/general/pdf/498.pdf is a
pretty good place to start.

Mostly what they do is to run a common emitter amplifier followed by several
common base amplifiers. They may or may not follow that with a buffer. Each
channel gets a separate string of amplifiers. All the common emitter amps
are driven in parallel by the reference source.

The transistors used are normally cheap stuff like the 2N3904. Except for
the power supply nothing in the circuit costs much. None of it is hard to
find.


For an integrated (op-amp) solution, how does OPA830 stack up? I'm 
trying one out for a GPSDO design to buffer the signal from the OCXO for 
50 ohm output, but I may also build a distribution amplifier at some point.


At $1.91 for single pieces on Digi-Key it's not terribly expensive, but 
something cheaper could probably get the job done. There are also dual 
and quad versions (OPA2830 and OPA4830).


-- m. tharp

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

Re: [time-nuts] newbie question Thunderbolt supply

[Michael Tharp]

On 08/27/2012 10:09 AM, Jerry wrote:

Are these thermal pads temp conductive or insulative?  If you want heat
dissipation why not use the readily available thermal grease used for
semiconductor mounting? Cheap and not really messy if applied correctly


A layer of Kapton (polyimide) tape would be electrically insulating but 
still conduct heat well enough for this application. You could then put 
a thermal pad under that and not have to worry about it being conductive 
or (I think) capacitative. I'd prefer the pad to the grease because the 
bottom of a PCB has lots of pointy bits that would keep the plane of the 
PCB spaced away from the plate, and thermal grease is not very effective 
as a filler material. It would also be springy enough to maintain 
contact with the bottom of the PCB.


I'm still not entirely sure this is a good idea though, seems like a 
low-temp oven for the whole tbolt would be better if you want thermal 
stability.


-- m. tharp

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

Re: [time-nuts] GPSD-Rb

[Michael Tharp]

On 08/22/2012 01:22 AM, Edgardo Molina wrote:

b. Is it possible to build a GPSDRb? I would like to know if it is reasonable 
to pursue the goal to discipline the 5065a with a TB which I also got recently.


Some Rbs have a "C-field" input that can technically be used to 
discipline it, but this is not the approach I am going to take with 
mine. A Rb oscillator is internally an OCXO that is disciplined to the 
Rb physics package, with the goal of holding a frequency over a long 
period of time with the only variance coming from deficiencies in the 
measurement circuitry. Using the C-field to discipline it is kind of 
throwing out the long-term stability characteristics of the Rb and using 
it as an expensive OCXO. It's more interesting to me as a holdover 
source for a conventional GPSDO.


The design I'm thinking of is to have a separate microcontroller clocked 
by the Rb that will generate a third pulse-per-second (the first two 
being the raw one from GPS and the divided-down local oscillator). As 
long as the GPS is locked the divider will not output pulses but will 
monitor the pulses from the local oscillator and use it to count the 
frequency of the Rb. Once lock is lost or holdover is manually engaged, 
then it stops counting and starts outputting pulse-per-second based on 
the last known average frequency it counted. The GPSDO would then 
continue normal disciplining based on the Rb pulses until GPS lock 
returns. Of course while locked the measured frequency would also be 
reported so that the Rb could be calibrated in situ.


-- m. tharp

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

Re: [time-nuts] : L1 GPS timing signal(s) into local time on computer(s)

[Michael Tharp]

On 08/21/2012 12:35 PM, Sarah White wrote:

Thanks Chris.

I always appreciate clear explanations. I'm assuming that the "fixed
location" requirement is important to note for purposes of compensating
for any dopler shift, as well as the distance the signal must first
travel before being decoded.

... I would presume that the fixed location used for above calculations
would be relative to the position of the antenna? I read somewhere that
even compensating for the length of the antenna cabling is important?


Yes, the antenna location is what's being measured. You will want to 
compensate for cable delay but this is simply a matter of subtracting 
however many nanoseconds it takes the signal to flow through the cable. 
It does not directly affect the process of doing fixes (whether for 
position or for time) because the pulses from all of the satellites flow 
in parallel once they're inside the cable.


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

Re: [time-nuts] Modern motherboard with RS232 port

[Michael Tharp]

On 08/19/2012 03:38 PM, Christopher Brown wrote:

Though I am a little surprised about residential power being
measured/billed in VA not KW/h in North America.  Pretty sure the US is
in North America, even Alaska in slightly more North America.  Never
seen a VA/h meter in the US.

Was guessing it was a CA thing, even though I had never run across any
mention of VA billing in CA, but am looking at Manitoba Hydro, NB power
and SaskPower billing rates right now in KW/h.

Ed, can you chime in here, where is power billed by VA (outside of some
commercial/industrial and private generation agreements)?

VA is used all over the place in electrical systems calculations and
equipment specs but have never seen billing on it.


It's also my understanding that homes are always billed by the watt. 
Even in industrial scale they charge a fee for poor power factor but 
they aren't billing by VA, according to Wikipedia at least.


Still, a good plug-in power meter is a great tool for any home. I would 
have one already but everything is already plugged into a battery backup 
with a watt-meter built in and I'm not terribly concerned about accuracy.


-- m. tharp


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

Re: [time-nuts] Embedded NTP servers?

[Michael Tharp]

On 08/19/2012 01:38 PM, Chris Albertson wrote:

NTP is not as easy as you think.  Just doing the cryptography to handle
authentication is more then I would want to write.  When a free open source
ntpd exists it will be really hard to get people to help work on
re-inventing it.  But your idea to use a GPSDO to drive the system clock is
good.  People have done that and it works. You basically unsolder a TTL
"can oscillator" and put a small connector in it's place.


This is specifically *not* a full ntp implementation. There's no client, 
no PLLs or clock correction, nothing but using 10MHz+PPS+NMEA to feed an 
internal clock and serving it out over ntp to more intelligent clients. 
I haven't written any code yet but from nosing around in wireshark it 
seems like the ntp part of the project wouldn't take more than an hour 
or two to write. The only tricky part is keeping a calendar so it knows 
when to insert a leap second.


I'm not initially interested in authentication, although I do have all 
my PCs at home running in authenticated broadcast mode. So I might add 
auth later so it can participate, but I would be satisfied without it.


-- m. tharp

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

[time-nuts] Embedded NTP servers?

[Michael Tharp]

Greetings nuts,

All this recent NTP discussion has me thinking about a dedicated NTP 
server again. The usual solution is to use commodity hardware of some 
persuasion (PC, mini-itx or even ARM) running ntpd, but I'm thinking we 
can do better. The only reason a full ntpd is needed is for its software 
PLLs that measure and compensate for deficiencies in the local 
oscillator. But if that local oscillator is replaced by a disciplined 
10MHz clock, and a coincident pulse-per-second and NMEA from the GPSDO 
fed in, then a reasonably fitted microcontroller should do the trick.


I happen to have a Ethernet-enabled widget I put together for another 
project as a kind of drop-in module, built on a PIC18F66J60 which has a 
built-in 10mbit Ethernet controller. The problem with it seems to be 
relatively poor and unpredictable packet servicing latency. Usually 
pings are 1.02ms but with some significant deviation. I imagine a lot of 
the deficiencies with this arrangement come from the vendor-supplied IP 
stack, which is not latency-optimized, but also the 10mbit link 
contributes some "quantization" type problems. Microchip also makes a 
100mbit-capable standalone controller, ENC624J600. I'd probably use that 
and pair it with any 72MHz ARM microcontroller. The micro would be 
clocked by a (multiplied) 10MHz disciplined input and the 
pulse-per-second would come in on a "input capture" channel that can 
timestamp the pulse relative to a local counter. And since ntp is such a 
simple protocol, it should be pretty easy to write a appropriate ntp 
server routine that just hands out the time from GPS, including leap 
second indications.


Thoughts? Has it been done before, preferably with open source? I'd love 
to make it myself but I have to finish the GPSDO first :-)


-- m. tharp

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

Re: [time-nuts] Trimble Resolution T

[Michael Tharp]

On 08/06/2012 12:57 PM, Miguel Barbosa Gonçalves wrote:

Hi!

I'm looking at the Resolution T from Trimble
(http://www.trimble.com/timing/resolution-t.aspx).

Does anyone here connected it successfully to a computer?

Are the voltages compatible with RS232 or do I need some converter?


It is 3.3v logic-level UART which is not RS-232 compatible. I have 
designed an interface board that should be compatible -- it was designed 
for the Resolution SMT carrier board, but both boards seem to have the 
same footprint, connector, pinout, etc. The Resolution SMT is available 
cheaply on ebay (from China of course) and has slightly better 
specifications.


You can also get logic-level UART cables from Sparkfun, adafruit, etc. 
but you will need a way to connect to the 2mm pitch header as well as a 
3.3V power supply, the interface board takes care of all of this.


The first batch of interface boards was mailed out early last week and I 
am eagerly awaiting reports of success. There's a second batch with at 
least 2 free boards on the way so shoot me an email off-list if you're 
interested, $20 USD plus shipping. More details here:


http://partiallystapled.com/pages/pps_piggy.html

-- m. tharp

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

Re: [time-nuts] Zero-Crossing Detector Design?

[Michael Tharp]

On 07/19/2012 07:36 PM, Al Wolfe wrote:

Chris,
The simplest zero crossing detector would be to feed your 1 volt, 10
mHz from the XL-DC into the input of an IC with schmidt trigger inputs.
You would need to provide a series coupling cap and probably some DC
bias from a pot to adjust symmetry of the output. I would also think
that if you ran the four or six inverters of a schmidt trigger inverter
chip in series that you would get a pretty good square wave out the end.


One circuit I was recommended when I was looking for ideas uses a 1M 
resistor to feed the output of the inverter back to the input to 
self-bias, like this:


http://partiallystapled.com/~gxti/circuits/2012/07/06-beanpole.png

I'm also trying a discrete approach based on the TADD-2 / T2-mini:

http://partiallystapled.com/~gxti/circuits/2012/07/06-tadpole.png

The latter has definitely been used successfully in timing applications 
but the simplicity of the inverter approach is very appealing, so I'm 
giving both a test, along with some other miscellaneous GPSDO 
components, before proceeding with a full GPSDO.


-- m. tharp

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

Re: [time-nuts] Trimble SMT board

[Michael Tharp]

On 06/25/2012 09:37 AM, Erno Peres wrote:


Hi David,

thanks a lot for the info, I have also the 1PPS output, but had the 
impression that it will also output TSIP or any other kind of MSG upon 
power-up... and you can configure the board as required of the need.it 
outputs  according to the TrimbleStudio SW is TEP format but any interruption 
of the  power / +3.3 V / then no any msg comes out..
I want to use for the Brook Shera boardso  the 1PPS is OK.
I did not chked out with the Motorola software or TAC32 but will do.

Rgds Ernie.
PS.  for what board / gpsdo / do you use  the SMT gps..


You can reconfigure when the receiver transmits packets, and what 
protocol it uses, in GPS Studio. I don't have it in front of me right 
now, but from memory: from the main receiver window (the one with the 
COM port drop-down), there should be a "Receiver" menu with a 
"Configure" entry. From there on the "Port" tab you can change the 
protocol set used. After checking the boxes you want (probably NMEA or 
TSIP at 9600 8-none-1) click 'Set', then if it still works 'Save 
Configuration' to make it permanent. Reconfiguring the ports is a little 
fidgety so you might need to power-cycle the board and try again a few 
times before it sticks. In your case since it's not transmitting at all 
there might be another setting you need to change to get it to broadcast 
on its own. Mine came preconfigured in "TEP" mode but it did broadcast 
every second, I've reconfigured it for TSIP.


-- m. tharp

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

Re: [time-nuts] GPS / GNSS front-end board

[Michael Tharp]

On 06/05/2012 03:31 PM, Attila Kinali wrote:

* The XC6SLX9 is<10USD more expensive than the SLX6. I think the added
   value of having twice as much "real estate" would justify the additional
   price.


Some vendors don't even stock the SLX6, including Digi-Key! Agreed 
though, it would be neat if a CPU capable of doing fixes could be fit 
onto the FPGA alongside. Might be impractical though, a DSP would 
probably be more appropriate. Still, from what I can tell a FPGA makes a 
decent PPS-level phase comparator. You can even gang them up with a 
phase-shifted clock to get finer resolution.



* Connect the enable pin of the OSC1 to a 2-pin header, so it can be
   disabled with a simple jumper. And put a SMA connector into the path
   between OSC1 and the LMK03806 (probably not mounted by default) in order
   to make using an external clock source easier.

I assume that you are running the ADCs in multiplexed mode and the FPGA
at 128MHz clock?

How about design tools for the FPGA? As far as i can tell, the ISE WebPack
does not support the Spartan 6 family.


WebPack does support XC6, or at least the mid-range parts and below. I 
have a XC6SLX45 dev board and have no problems generating bitstreams.


-- m. tharp

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

Re: [time-nuts] GPS / GNSS front-end board

[Michael Tharp]

On 06/05/2012 11:03 AM, Peter Monta wrote:

I've been working on a front-end board suitable for GPS and other GNSS
systems.  It might be of interest to time-nuts given the application
to timing receivers.


Very impressive. Since I discovered time-nuts this is exactly what I 
wanted to make, and you've gone and done all the hard stuff. If you're 
planning on doing a bulk run, count me in.


What is the function of the clock/PPS inputs? Of course I'm primarily 
interested in turning this type of frontend into a robust timing source, 
particularly if all of the GPSDO functionality can be fit into the 
existing FPGA.  This can be done either by clocking the GPS receiver 
from the disciplined clock (e.g. Trimble Thunderbolt), or by using 
independent clocks and estimating the resulting quantization error (most 
timing-oriented receiver-only modules). In a from-scratch design I don't 
think there's any reason not to use the disciplined clock, but there 
could be lurking correlation problems. In any case, I'm curious as to 
why these are piped into an ADC instead of being used to clock the 
system (10mhz) and as an async input to a hypothetical phase comparator 
in the FPGA (PPS).


I'm not entirely savvy as to what additions would be required to make 
this design more useful for an embedded timing system. A bus that could 
bring the data stream to a companion board with FPGA and/or MCU for 
doing fixes without having to pass through Ethernet would be very 
helpful. That way people with interesting ideas can just fab a board to 
stick on a header and do their thing without a full gigabit Ethernet 
stack, which essentially means a FPGA is required on the other side.


Disclaimer: I know very little about actually implementing a GPS 
receiver, and about RF in general, but I know a cool project when I see 
one and this has a lot of the elements needed for a fully open-source 
timing receiver. Looking forward to further developments, and if there's 
another list you're more active on do let me know.


-- m. tharp

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

Re: [time-nuts] DDS in GPSDO design?

[Michael Tharp]

On 05/27/2012 07:10 PM, Magnus Danielson wrote:

How far off? What Rb do you have?

Most Rb:s not having a EFC input should be possible to modify for EFC in
one way or another, since the C-field needs to be applied regardless.


I don't know how far off it is. It's an Efratom 102100-001, which 
there's very little information about. Most of what I know is from a 
time-nuts post from 2006 (!) -- the pictures from that thread can be 
found here: http://nixie.ramdac.be/


It's likely that it could use a tune-up because mine could not get a 
lock when I first powered it up. I did the smart thing and twiddled 
every single trim pot (after marking the original positions, bah) hoping 
to get the sweep frequency in the right place. It was only after I gave 
up and walked away for a few minutes that it locked. Now it locks in 
under 3 minutes every time but I'm sure the 10mhz output could use a trim.


The outputs available through the main connector are 10MHz out, vreg 
voltage, active-low lock indicator, Rb lamp voltage, and "xtal monitor" 
which sweeps over a large range while it's looking for a lock. That 
sounds nice, but even if it were pullable it would probably interfere 
with the ability to lock to Rb. There are several internal headers but I 
can't find any documentation on this particular model so their function 
is a mystery to me.


Probably the intelligent thing to do would be to look for a good 
pullable OCXO rather than designing around what I have. Wouldn't be much 
fun, of course.


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

Re: [time-nuts] DDS in GPSDO design?

[Michael Tharp]

On 05/27/2012 06:23 PM, Bruce Griffiths wrote:

The principal problem with conventional DDS implementations is phase
truncation spurs which can occur close to the desired carrier.
Virtually all commercial DDS chips produce such phase truncation spurs.

It is possible to eliminate such spurs if one implements a custom DDS
using an FPGA and an external DAC.
In this case the performance is limited by the DAC.


How specifically does the FPGA resolve the problem? I have a FPGA 
already for the phase comparator, it's just a "simple" matter of 
figuring out how big of a DAC to get and what data to feed it...



Another approach is to use a cascaded mix and divide technique
 to restrict the effective tuning
range of the DDS.
The amplitude of DDS generated spurs is thereby significantly reduced.


Great paper, this looks like it could be interesting as a standalone 
filter. It's just a little over my head (self-taught digital guy) but 
since I don't need to hit a home run on the first try, I'll keep it in mind.


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

[time-nuts] DDS in GPSDO design?

[Michael Tharp]

Greetings,

I've been pondering topologies for a custom GPSDO design and two obvious 
choices seem to present themselves. The first, and seemingly more 
popular by far, is to use a "pullable" oscillator as many OCXO and Rb 
oscillators are and discipline it using a slow but precise DAC. But 
unfortunately my Rb is not pullable so I would have to get another 
oscillator. So I have a very stable but off-spec local oscillator, which 
has to somehow be combined with the pulse-per-second from the GPS. If 
there's a palatable analog way to do this, I'd love to hear, because it 
would probably be simpler than the other idea.


The second obvious idea is to use the local oscillator to clock a 
frequency synthesizer (DDS). These can apparently tune a frequency very 
finely and depending on how much one spends will produce a pretty clean 
sine wave even at 10MHz. Since these also tend to require a FPGA it also 
fits nicely with the nanosecond-level phase comparator I've been toying 
with, and the whole mess (microcontroller, DDS, phase comp) can all be 
clocked from some multiple of the LO without worrying about unwanted 
phase correlation. Having the GPSDO be a black box that can transform 
any undisciplined 10MHz reference into a disciplined one is very appealing.


Does anyone have any comments or experience with DDS-based frequency 
references? Are they too jittery for this type of application? It will 
certainly require quite a lot of creative filtering -- one page I read 
mentioned the pitfalls of tempco of phase shift -- but that's just a 
good excuse to brush up on my analog design.


-- m. tharp

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

Re: [time-nuts] Serial port server .. any interest in a write up on using ?

[Michael Tharp]

On 05/22/2012 06:37 PM, Pete Lancashire wrote:

I've never though about using one to distribute the 1PPS for NTP. Its
a pity there isn't enough umph inside one of these
little Linux boxes to implement NTP.


Don't get too excited because this is many months out, but I'm working 
towards designing a single-board ARM linux computer to run a NTP server. 
It'll connect to a GPS receiver via UART and PPS, using a hardware timer 
peripheral in input capture mode to compensate the PPS for interrupt 
latency (maybe overkill), and the CPU can be clocked by your favorite 
GPSDO or OCXO. I've seen this done by hacking up x86 hardware, but 
purpose-built will do even better and will consume very ltitle power. 
Your OCXO on the other hand, well I can't do anything about that :)


I also need to look into whether there's specialty ethernet hardware 
needed to make an ideal PTP source, I barely know anything about it. 
Hopefully it's available for a reasonable cost. As it is the board 
should be < 40 USD, but I'm still working on the schematic and there's 
always room to bloat the project with more features.


But first I need to finish the Resolution SMT interface boards I've 
promised to make. Sent for 9 PCBs yesterday, should arrive in 2-3 weeks.


Here's to feature creep,
-- m. tharp

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

Re: [time-nuts] Buffering a PPS signal

[Michael Tharp]

On 05/18/2012 01:33 PM, Mark Sims wrote:


While you're at it,  add an ATMEGA328 processor and a 250 ps res/256 step delay 
line.   The processor reads the timing message,  picks off the sawtooth 
correction factor,  converts it to an 8-bit value that it output on a port to 
the delay line.  The 1PPS signal clocks the port into the delay line for 
sawtooth correction.   (This all assumes that the correction factor applies to 
the NEXT 1PPS that is output (the PPS correction is not documented...  the time 
field in the message  applies to the previous 1PPS pulse).


I don't need the sawtooth correction done in hardware because at least 
in my case the pulse is being fed into ntpd on a Rb-clocked computer, 
and ntpd can add the correction itself. But I'll definitely consider a 
bigger, better board that can do the correction internally, probably in 
a form more generic than this board which is just an interface to the 
Resolution SMT (and perhaps Resolution T, haven't checked if the 
mechanical aspects are the same).


-- m. tharp

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

Re: [time-nuts] Buffering a PPS signal

[Michael Tharp]

On 05/18/2012 08:24 AM, Bob Camp wrote:

Hi

For a 50 ohm buffer, you probably want something like 200 ohms in series
with each output (4 buffers) or 400 ohms (8 buffers).


Yep, I ended up choosing a quad buffer with 180 ohms on each pin which 
should yield 45 ohm source impedance and 27mA short-circuit current, 
while the part is specified for 32mA. Thanks for pointing me in the 
right direction.


-- m. tharp

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

[time-nuts] Buffering a PPS signal

[Michael Tharp]

Greetings,

As I mentioned briefly a few days ago I'm working on an interface board 
for the Trimble Resolution SMT carrier board to provide a convenient way 
to get power in and PPS/serial out. The PPS output is a 3.3v, 125 
microsecond long pulse and I'd like to buffer it with something that can 
drive a 50 ohm terminated line. What's the best way to go about doing 
this? I've looked at using a MOSFET driver like FAN3111ESX but most of 
these have a moderate (30-50ns) delay with a moderate temperature 
coefficient, but perhaps I'm expecting too much.


For people interested in buying the board, it will have USB and RS-232 
(with PPS on the Carrier Detect line) plus the 50 ohm PPS output on BNC. 
Physically, it's the same size and shape as the RSMT board itself and 
will fit directly on top. Total cost should be about 20 USD.


Current schematic is here, comments welcome:
http://partiallystapled.com/~gxti/circuits/2012/05/17-piggyv2.png

Cheers,
-- m. tharp

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

Re: [time-nuts] Trimble Resolution-T SMT caught behaving badly

[Michael Tharp]

On 05/14/2012 09:11 PM, Mark Sims wrote:


Attached is a Lady Heather screen dump of a Trimble Resolution-SMT timing 
receiver behaving badly.  The first quarter of the plot the unit was tracking 
all sats above 0 degrees/0 dBc.  The next quarter the masks were set to 30 
degrees/30 dBc.   Then at the half way point,  something strange happened...

The green plot is the sawtooth correction value.  It should be +/- 15 nS,  but 
was only running +10/-13 ns.  At the half way point the sawtooth started 
spiking down to -38.00 ns...  obviously some internal clipping limit.   It 
ran this way for a day,  then I reset the unit and all has been well since.

The purple plot is the unit's "local clock bias".  It is reported like the 
Tbolt's PPS value.It is a sawtooth that covers a 1000 usec (almost) range. It repeats 
over a 28 minute period.

The white plot is the "clock bias rate".  In comes in like the Tbolt OSC value. 
 Yellow is temperature.   Note how well those two plots track each other.   Suggests that 
some active temperature control might be useful.

One nice thing about the Resolution receiver is that it returns tracking info 
for all sats,  even those below the elevation/signal masks.  This lets you 
build a signal level map even when you have elevation and signal level masks 
set.   Also note the high signal levels.  On a Tbolt,  I never see signals past 
green... the receiver is 6 db more sensitive.


Thanks for your notes on this device. I just got mine in the mail today, 
along with a 40dB antenna. Unfortunately I don't yet have the cable to 
connect the two, so right now it's running from a short length of bare 
wire, indoors, and as such can't really get a decent fix :-) It has 
managed to lock onto 4 satellites though, so it seems to work well 
enough to give me something to look at until I get materials to make a 
cable.


I am planning on making a simple NTP server using the Resolution SMT as 
the PPS input and a Rb oscillator (or any other 10MHz clock) to clock 
the CPU on the computer. If people are interested in a friendly 
interface board to the device let me know. My initial interface board 
design puts the PPS on the Carrier Detect line at RS-232 levels as is 
typical for this sort of thing, but USB is also very easy to do.


Regarding the default protocol being TEP, I easily managed to 
reconfigure it for TSIP using GPS Studio. The current version (1.08.0) 
supports TEP, and using Tools -> Configurator you can reprogram the 
Resolution SMT to use TSIP or NMEA by default. There are several other 
parameters that can be reprogrammed per the manual, including the width 
of the PPS.


Cheers,
-- m. tharp

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