Re: [time-nuts] Racal 9475 Rubidium

[Nick Sayer via time-nuts]

> On May 2, 2018, at 7:13 PM, Roger Tilsley  wrote:
> 
> 
> 
> In my experience, FRK modules produce their best performance when operated  
> from a supply voltage between 27 V and 28 V, selected for individual units 
> but 27.6 V is a good starting figure. 

Would there be any value to designing a 24 -> 27.5 volt boost converter that 
one could use to power it from a more conventional supply? How much current 
would it need?
___
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] Setting correct date on Trimble Thunderbolt receiver

[Nick Sayer via time-nuts]

In general, I believe whether you can work around the 1024 week problem and if 
so, how, tends to be a receiver-by-receiver thing (or at least 
manufacturer-by-manufacturer).

I’m most familiar with the SkyTraq Venus838, and those have a sliding window 
system where you set a “reference date” and the receiver will always assume 
that date is inside the window. At least once every 1024 weeks, you’re supposed 
to set that to the current date (it’s a binary command and they have software 
that will do this for you), and then you’ll get another 1024 weeks without 
having to do anything.

My GPSDOs don’t have a TX path from the controller to the receiver, but you can 
talk to the receiver directly with the diagnostic connector and update the 
reference date that way. My GPS Clocks will set the reference date once a year 
(if the current year != the reference date year, then it is set, and this check 
is made once an hour. Having the date correct matters for DST decisions).

> On Mar 26, 2018, at 5:03 PM, David C. Partridge 
>  wrote:
> 
> AFAIK you can't set the correct date any more - this is the 1024 week 
> rollover problem.
> 
> Lady Heather does correct the displayed date, as it knows that the reported 
> date is wrong..
> 
> David
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of 
> donandarl...@gmail.com
> Sent: 26 March 2018 22:18
> To: time-nuts@febo.com
> Subject: [time-nuts] Setting correct date on Trimble Thunderbolt receiver
> 
> Hello all,
> I am new to the board and have just received a Trimble Thunderbolt GPS 
> receiver today.
> All is working correctly except the date shows Aug 10 1998.
> How do set the proper date on this?
> I am running TBoltMon to access the unit.
> Any help would be appreciated.
> Thanks,
> Don W9BHI
> ___
> time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] ECS ECOC-2522 (was GPS Talking Clock)

[Nick Sayer via time-nuts]

I’ve built two GPSDO units now with this OCXO. For the first one, I fed the DAC 
(AD5680) from the oscillator’s reference output. This resulted in a very poor 
(compared to expected) short term ADEV result (1-2 E-11). There was a lot of 
noise (something like 5 mV P-P) on the reference output. Also, rather oddly, 
the reference voltage was something like 2.8v. The datasheet doesn’t say what 
the expected voltage is, but if you were to use that as your DAC reference, 
you’d be throwing away the top 20% or so of the tuning range.

For the second unit, I built it with the same circuit I use for the CW OH300, 
which lacks a reference output. There, instead, I use an NCP51460 precision 
regulator for a reference. There, I achieved a short term ADEV much closer to 
expectations. It’s just under 6E-12 at tau 1-5s. ECS claims it ought to be 
closer to 3, but it’s entirely possible that my reference (Thunderbolt) and/or 
counter (53220A) are contributing error, or that my design has some other noise 
contribution I haven’t yet found. Still, it’s at least in the ball park. And 
the oscillator hasn’t even yet been running for 24 hours, so it may get better 
with some time (I’m a little skeptical about wear-in helping low-tau ADEV 
though. Doesn’t that usually operate on longer term drift instead?).

In both cases, the reference was bypassed with a 10 µF and 0.1 µF chip cap 
adjacent to the DAC. Both power supplies had similarly low levels of noise and 
ripple. The worst that you could say about either was the amount of blowback 
from the oscillator itself was far higher than the input noise.

Of course, sample size here is 1 each, so it’s possible that the first one was 
just a dud. But the theory that the noise on the reference is FMing the output 
fits the observations.


> On Feb 18, 2018, at 7:54 AM, Nick Sayer via time-nuts <time-nuts@febo.com> 
> wrote:
> 
> No they don’t. I wrote and asked them and they sent me back some sample data. 
> They were a pretty pleasant surprise.
> 
> 
> 
>> On Feb 18, 2018, at 6:04 AM, Bob kb8tq <kb...@n1k.org> wrote:
>> 
>> Hi
>> 
>> 
>>> On Feb 17, 2018, at 11:01 PM, Nick Sayer via time-nuts <time-nuts@febo.com> 
>>> wrote:
>>> 
>>> It’s been a while since I’ve posted here, but I’ve had a bunch of irons in 
>>> the fire. I’m working on adapting my GPSDO to the ECS ECOC-2522, which the 
>>> manufacturer claims has a short term ADEV in the low -12s, but I haven’t 
>>> gotten it doing that well yet.
>> 
>> At least on this data sheet: 
>> 
>> https://www.ecsxtal.com/store/pdf/ECOC-2522.pdf
>> 
>> They don’t say much of anything at all about ADEV. OCXO’s in the little 
>> packages are rarely super stars when it comes to ADEV.
>> 
>> Bob
>> 
>> 
>> 
>>> 
>>> But one thing that is ready (well, electronically it is - I’m still working 
>>> on the laser cut case for it) is my GPS Talking Clock.
>>> 
>>> The story is that I called the USNO time number at midnight on New Year’s 
>>> Day, but the wife noted that it was the wrong time zone. That got me 
>>> thinking, and I wound up designing a GPS driven simulacrum.
>>> 
>>> It’s an ATXmega32E5 with the usual Venus838 timing module and a µSD card 
>>> slot. The card is loaded with audio samples that the 32E5 plays back 
>>> through its DAC. I got double-buffered DMA to work to feed the DAC, so 
>>> audio playback is a largely background task. I just have to fill the buffer 
>>> with the next block from the file every ~30 ms or so. The ticks and beeps 
>>> are generated from an on board 1 kHz source and are turned on by a PPS ISR, 
>>> so they’re as accurate as possible. The whole thing is basically as 
>>> accurate as an aural clock can be - the latency induced by the speed of 
>>> sound has far more impact than anything else.
>>> 
>>> While the audio is turned off, the clock can also do Westminster Quarters 
>>> (or any other chime you wish to load in).
>>> 
>>> The µSD card is FAT formatted and the audio sample files are easy to make 
>>> with ‘sox’ (raw, 1 channel, 8 kHz, 16 bit little-endian, unsigned), so 
>>> there’s no reason you can’t substitute my voice with your own, or make your 
>>> own chimes.
>>> 
>>> It’s available at https://www.tindie.com/products/nsayer/gps-talking-clock/
>>> 
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to 
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Need a Watch Recommendation

[Nick Sayer via time-nuts]

Lots of folks have chimed in on this thread, but I will just add that the Apple 
watch is an NTP client. I’m extremely happy with mine, but the reasons I am are 
far, far wider than its accuracy (which I can only judge by eye, which is an 
extraordinary low bar for a Time Nut).

> On Mar 4, 2018, at 10:38 PM, Don Murray via time-nuts  
> wrote:
> 
> Hello Time Nuts...
> 
> 
>  
> After 6 years of no troubles, in sync with WWV any
> hour of the day, flawless transfer between
> standard and daylight time my Stauer Titanium
> Atomic wristwatch bite the dust a year ago.
>  
> Since then, Stauer has sent me three replacements,
> each with some type of problem.  
>  
> So it looks as if I am in need of a new wristwatch,
> which will give me some kind of time accuracy.
>  
> So, Time Nuts...  any suggestions or recommendations?
>  
> TNX
>  
> 73
> Don
> W4WJ
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

[time-nuts] GPS Talking Clock

[Nick Sayer via time-nuts]

It’s been a while since I’ve posted here, but I’ve had a bunch of irons in the 
fire. I’m working on adapting my GPSDO to the ECS ECOC-2522, which the 
manufacturer claims has a short term ADEV in the low -12s, but I haven’t gotten 
it doing that well yet.

But one thing that is ready (well, electronically it is - I’m still working on 
the laser cut case for it) is my GPS Talking Clock.

The story is that I called the USNO time number at midnight on New Year’s Day, 
but the wife noted that it was the wrong time zone. That got me thinking, and I 
wound up designing a GPS driven simulacrum.

It’s an ATXmega32E5 with the usual Venus838 timing module and a µSD card slot. 
The card is loaded with audio samples that the 32E5 plays back through its DAC. 
I got double-buffered DMA to work to feed the DAC, so audio playback is a 
largely background task. I just have to fill the buffer with the next block 
from the file every ~30 ms or so. The ticks and beeps are generated from an on 
board 1 kHz source and are turned on by a PPS ISR, so they’re as accurate as 
possible. The whole thing is basically as accurate as an aural clock can be - 
the latency induced by the speed of sound has far more impact than anything 
else.

While the audio is turned off, the clock can also do Westminster Quarters (or 
any other chime you wish to load in).

The µSD card is FAT formatted and the audio sample files are easy to make with 
‘sox’ (raw, 1 channel, 8 kHz, 16 bit little-endian, unsigned), so there’s no 
reason you can’t substitute my voice with your own, or make your own chimes.

It’s available at https://www.tindie.com/products/nsayer/gps-talking-clock/

___
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] Designing an embedded precision GPS time

[Nick Sayer via time-nuts]

At the moment, my plan is to not support hold-over at all. If GPS doesn’t have 
a fix and I’m not getting PPS pulses, I intend to either jump immediately to 
stratum 16 or just not respond.

> On Oct 31, 2017, at 1:03 PM, Attila Kinali  wrote:
> 
> Hoi Leo,
> 
> On Sat, 28 Oct 2017 11:14:08 +0100
> Leo Bodnar  wrote:
> 
>>> From: Attila Kinali 
>>> Can you tell a little bit how your device looks like on the inside?
>> 
>> GPS is a Ublox.  MCU is Cortex-M7 and does not run any OS - just main loop 
>> with prioritised interrupts.  Network stack is hand-made. 
>> I don't use saw-tooth correction in this device because +-11ns is not worth 
>> correcting for NTP application for such a budget device.
>> If you can build a test NTP client system that can detect sawtooth 10ns 
>> offset from the NTP server I'd like to know how you did it.
> 
> True. An NTP server does not need to measure time better than 100ns or so.
> 10ns is probably more than good enough. But then, this raises the question
> what your performance metric is that you optimize for?
> 
> If it is hold-over, then this will be limited by the TCXO and how well
> you can measure its frequency, which in turn depends on how well you
> can measure the PPS pulse. You say that your device is typically within
> 4-5ms in 24h of hold-over. That translates to frequency uncertainty
> of approximately 5e-8. That's not that good.
> To put this into perspective have a look at the two attached plots.
> These are the PPM values that ntp reports for a standard server (HP DL380G7).
> The first plot shows the long term variation of all the data I currently have.
> The three jumps coincide with days when we restarted ntpd. As you can see,
> the long term variation of the crystal frequency is well below 0.5ppm. The
> second plot zooms in into one of the day with large variations. The worst
> of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens
> instantaneous, then this would result in a hold over performance of ~0.9ms
> in 24h. Yes, this is not a fair comparison. The sever is in a room where
> temperature is pretty much constant (sorry, I don't have any data on that,
> but assume less than 5°C  variation within a day). And it's not true hold
> over performance, but a guestimation from the ntp provided loop data. But
> even if we add a factor of 10, this simple, unstabilized, unsophisticated
> PC comes pretty close to the performance your device claims. And that's not
> even a PC with a good crystal (I have measurements of others, that showed
> variation of less  than 2ppb over months in rooms without air conditioning).
> 
> Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver,
> put everything in a metal box and just use normal ntpd, i'd expect to
> have a hold over performance of better than 100ms/24h (assuming 1ppm
> stability of the crystal), probably in the order of 10ms/24h and it would
> have no problems handling a humongous number of clients, thanks to the
> fast CPU (1.4GHz) and the Gbit/s ethernet interface.
> 
> So, why does a simple PC with ntp do such a good job? The secret
> lies in the measurement: Very much simplified, ntp measures the
> frequency in 1000s intervals. Measurement uncertainty is reported to be
> better than 100us per reference server. Ie the uncertainty is in
> better than 1e-7 (compare with the estimated 5e-8 from above).
> Add to that averaging over multiple reference severs (4 in this case)
> and a sophisticated clock parameter estimation and the uncertainty
> goes down quite a bit.
> 
> To summarize: If you want to improve your ntp devices hold over performance
> you have to improve the frequency measurement and use a better clock modeling.
> Ie, use a timing GPS receiver and its sawtooth correction, and model the
> clocks frequency change over time.
> 
> 
>   Attila Kinali
> -- 
> It is upon moral qualities that a society is ultimately founded. All 
> the prosperity and technological sophistication in the world is of no 
> use without that foundation.
> -- Miss Matheson, The Diamond Age, Neil Stephenson
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

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

[Nick Sayer via time-nuts]

I think my test rig is likely to be a pair of units connected with a crossover 
cable, with test firmware on one to act as a fake client, and using spare GPIOs 
on test points to measure latency and the like with a scope. I don’t have the 
wherewithal to try and gauge the timing of switches, and of course the function 
of switches makes monitoring unicast traffic by third parties “impossible” 
(yes, you can play games with the switch table, but that’s more trouble than 
it’s worth).




> On Oct 29, 2017, at 5:27 AM, Scott McGrath  wrote:
> 
> With 1588 switch architecture counts as well because you have two major 
> classes of switch,  blocking and non blocking plus buffering etc.
> 
> Most 'enterprise' switches once the flow is set up directly forward frames 
> from the ingress port to the egress port each of which also tends to have a 
> fairly deep buffer so RTT Is non deterministic on a normal network
> 
> Most SOHO  switches use shared ring buffers so their performance is even worse
> 
> 
> 
>> On Oct 29, 2017, at 6:29 AM, Leo Bodnar  wrote:
>> 
> 
>> From: Nick Sayer 
>> I believe I’m going to start with one of my GPS module breakouts and an E70 
>> XPlained development board. From a hardware perspective, I expect that to be 
>> reasonably close to what the final hardware will be (the one thing I would 
>> guess would change would be perhaps swapping out the PHY chip for one that’s 
>> capable of doing PHY level timestamping, if that’s necessary and possible).
> 
> Hi Nick,
> 
> Note that PTP/IEEE1588 compliant hardware and NTP use different points in the 
> packet as reference timestamps. Timestamping transmitted packets in hardware 
> is useless for NTP.  I suspect you know that already.
> 
>> But my plan at the moment is to first try to get something that even answers 
>> the phone, see how terrible it is, and then see what has to be done to make 
>> it truly worthy.
> 
> You will find it trivial to get basic functionality working and reasonably 
> challenging to get it to work reliably under heavy load and edge cases.  
> "Heavy load" is not an abstract scenario since even on a lightly loaded 
> network there is a probability of several clients requesting time 
> simultaneously and network switch stacking NTP packets back to back.
> 
> If you are making an open source thing you might want to use Laureline NTP 
> http://partiallystapled.com/pages/laureline-gps-ntp-server.html as a starting 
> point or as a performance yardstick.  I have never seen one so can't comment 
> on how well it works but if done properly it should be reasonably solid and 
> agile.  I think the guy who designed it also sells them commercially but from 
> what I can see the design is also available for others to use.
> 
> Leo
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

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

[Nick Sayer via time-nuts]

That looks and sounds very, very much like what I want to do.

Thank you very much for your testing suggestions. When it comes time, I had 
indeed planned on adding it to the NTP pool if for no other reason than to 
contribute to the cause (but also for testing).

I believe I’m going to start with one of my GPS module breakouts and an E70 
XPlained development board. From a hardware perspective, I expect that to be 
reasonably close to what the final hardware will be (the one thing I would 
guess would change would be perhaps swapping out the PHY chip for one that’s 
capable of doing PHY level timestamping, if that’s necessary and possible).

But my plan at the moment is to first try to get something that even answers 
the phone, see how terrible it is, and then see what has to be done to make it 
truly worthy.

Those interested can follow the hackaday project. This whole thing is going to 
be open hardware and GPLed firmware (again, assuming I succeed). 

https://hackaday.io/project/27873-embedded-gps-ntp-server

> On Oct 27, 2017, at 12:27 PM, Leo Bodnar  wrote:
> 
> Hi Nick,
> 
> Last year I have designed an NTP server with sub-microsecond turnaround 
> accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
> speed) that costs just £250 from stock.
> Its holdover performance on signal loss is in the order of 4-5ms/day.
> https://store.uputronics.com/index.php?route=product/product=60_70_id=92
> 
> If you can come up with a cheaper and higher performance alternative I am 
> very interested in licensing your design.
> 
> When you come to testing I can highly recommend placing your prototypes in 
> public NTP pool and asking the admins to add it to .ch zone - you are 
> guaranteed to get full 110kpps traffic spikes that will help to flush out 
> bugs.
> Just a few devices collectively served 1.1 trillion packets in less than a 
> year http://leobodnar.com/LeoNTP/ (and have been through the infamous 
> snapchat incident.)
> 
> Jitter and holdover need to be tested on a controlled LAN segment - I can 
> highly recommend contacting Denny Page on this list and sending him a unit to 
> test.  
> He built sophisticated and highly tuned testing system that tracks timing 
> jitter and offset down to dozens of nanoseconds accuracy.  
> Denny is vendor-neutral and provided honest and fair feedback while I was 
> developing my unit.
> 
> Hope this helps!
> 
> Thanks
> Leo
> 
> On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:
> 
>> Date: Wed, 25 Oct 2017 17:53:46 -0700
>> From: Nick Sayer 
>> 
>> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned 
>> a lot in a relatively short time, and I really like the result.
>> 
>> I am considering a new project based on its cousin, the ATSAME70. The E70 
>> has an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 
>> has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and 
>> Atmel Start (the software development framework I’ve been using) purports to 
>> have a ready-to-use IP stack (alas, no IPv6, but it’s a starting point at 
>> least).
>> 
>> Where I am going with this is I am considering designing a precision 
>> embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got 
>> piles of up to a GPIO and USART and the Ethernet port would provide NTP/PTP. 
>> The idea behind making it an embedded system would be to try and make it as 
>> accurate as it reasonably can be with the hope that (at least on the local 
>> segment) it would wind up being more accurate than a Pi Zero doing the same 
>> thing. At the very least, you’d expect such a thing to be a whole lot less 
>> hassle to set up, given decent firmware.
>> 
>> This may be a fool’s errand, certainly, but looking at it from here, I would 
>> think that such a design might offer accuracy in the microsecond range, but 
>> that’s just a tremendously uninformed guess at this point (and what does 
>> that accuracy mean to a peer that might itself be incapable of better than 2 
>> orders of magnitude coarser?).
>> 
>> Anybody have any ideas or suggestions along these lines?
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

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

[Nick Sayer via time-nuts]

I’ve just completed a project (off topic) with the ATSAMS70 chip and learned a 
lot in a relatively short time, and I really like the result.

I am considering a new project based on its cousin, the ATSAME70. The E70 has 
an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
(USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
Start (the software development framework I’ve been using) purports to have a 
ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).

Where I am going with this is I am considering designing a precision embedded 
NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up to 
a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea behind 
making it an embedded system would be to try and make it as accurate as it 
reasonably can be with the hope that (at least on the local segment) it would 
wind up being more accurate than a Pi Zero doing the same thing. At the very 
least, you’d expect such a thing to be a whole lot less hassle to set up, given 
decent firmware.

This may be a fool’s errand, certainly, but looking at it from here, I would 
think that such a design might offer accuracy in the microsecond range, but 
that’s just a tremendously uninformed guess at this point (and what does that 
accuracy mean to a peer that might itself be incapable of better than 2 orders 
of magnitude coarser?).

Anybody have any ideas or suggestions along these lines?
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] inexpensive, black box, GPS or NTP based TTL time capture?

[Nick Sayer via time-nuts]

FWIW, I’ve documented the whole R-Pi GPS NTP thing at 
https://hackaday.io/project/15137

As a disclaimer I will also say that I’m not even remotely the first. But 
what’s kind of nice is that I have a R-Pi desk clock display board that plays 
really well with a bolt-on GPS cap. In fact, I’ve got two of them in the NTP 
pool right now.

Sent from my iPhone

> On Oct 21, 2017, at 7:50 AM, ROY PHILLIPS  wrote:
> 
> 
> Original message
> From : hmur...@megapathdsl.net
> Date : 21/10/2017 - 7:49 am (GMTDT)
> To : g...@rellim.com
> Cc : time-nuts@febo.com, hmur...@megapathdsl.net
> Subject : Re: [time-nuts] inexpensive, black box, GPS or NTP based TTL time 
> capture?
> 
 For under a $100 you could get a Raspberry Pi, a GPS HAT, and
 connect your input to a GPIO pin.  Configure ntpd to log the real
 PPS and the input as another 'PPS'.
> 
>>> Is there an option to log all individual PPS events?
> 
>>   # ppswatch /dev/pps0
> 
> That's a way to log stuff, but I don't think it comes under "Configure ntpd".
> 
> I remember some option to log lots of stuff, but I don't remember the 
> details.  It could have been in a driver.  I couldn't find it in the man page 
> for the PPS driver.
> 
> [amazon]
>> Looks like $96 to me.  You can save some if you buy in bulk,
> 
> You can save $7 if you get the starter package that has only Pi, SD card, 
> power, and case.  (Many starter packages include stuff you probably don't 
> need and that raises the price.  But maybe one has a HDMI adapter.  I didn't 
> look.)
> 
> Beware of using normal USB cables and/or normal USB power supplies.  The Pi 
> is not happy with low voltage.  The drop in a USB cable can be significant.  
> The setups intended for use with Pis normally have 5.1 or 5.25 volts and 
> heavier gage wire in the cable.
> 
> 
> [display, kbd, mouse...]
>> Yeah, just for setup.  Shall we include the price of the desk it sits and
>> the building it is in?
> 
> I'm willing to assume somebody has a table and a roof.
> 
> The display and such are not a problem if you have a PC you can borrow them 
> from.  (You probably need a HDMI adapter.)  But that doesn't work if all you 
> have is a laptop or smart phone.
> 
> I think most of my friends have PCs but I wouldn't be surprised if some of 
> them had a laptop and no PC.
> 
> If your PC is old enough, the keyboard and mouse may be PS2 rather than USB.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Fw: Skytraq / GPS Almanac

[Nick Sayer via time-nuts]

I don’t have any SkyTraq navigation modules, but I power cycled a couple of my 
clocks (with the timing modules) and they came back up as they usually do, so I 
can tentatively confirm that in survey-and-hold mode they don’t appear to have 
any problems getting a fix. TBD is vetting the results to insure there’s no 
loss of accuracy, but I haven’t seen any weirdness from any of my GPSDOs at 
least. 

Sent from my iPhone

> On Sep 27, 2017, at 4:59 AM, Azelio Boriani  wrote:
> 
> Maybe this can be useful:
> 
> 
> 
>> On Wed, Sep 27, 2017 at 5:58 AM, Scott Newell  
>> wrote:
>> At 05:20 PM 9/26/2017, Tom Van Baak wrote:
>>> 
>>> An interesting note from Said, below...
>>> I've sent a couple of queries out to GPS professionals.
>>> Feel free to comment if you have concrete information that would help.
>>> Also, if during the past week any of you were logging almanacs or
>>> continuously recording the 50 bps raw data from any GPS/SV, please let me
>>> know.
>> 
>> 
>> I have ublox LEA-6T data logged from 18:30 on 8-26 through 05:30 on 9-18. It
>> includes the RXM-SFRB subframe buffer messages. Would that be of any help,
>> or did I shut it off too early?
>> 
>> --
>> newell N5TNL
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

[time-nuts] Book review: "How We Got To Now."

[Nick Sayer via time-nuts]

I happened to be at Powell's bookstore in Portland the day after the eclipse 
and came across this book and wound up buying it. It's attraction to me was the 
same that I felt growing up watching the documentaries hosted by James Burke - 
Connections and The Day The Universe Changed.

Both Burke and Steven Johnson (the author) have the same playbook - showing how 
disparate inventions and innovations drive change in surprising ways. Johnson's 
book divides into six topics: Glass, Cold, Sound, Clean, Time and Light. His 
overarching theme is what he calls the Hummingbird Effect.

How did a hummingbird evolve? There was no niche for hummingbirds until the 
symbiosis of flowering plants and bees came about, and that symbiosis created 
an opening for a bird if it could exploit the availability of nectar intended 
by the flower as a bribe for the bees. 

One anecdote is how the development of chlorinated drinking water led to 
swimming pools and to the rapid diminishment of ladies swimming fashions 
compared to what they were at the beginning of the 20th Century. 

But it's the chapter on Time that is relevant to us here. It is a whirlwind 
examination of the history of measurement of time and what our increasing 
penchant and ability to measure it accurately has meant for us as a species 
and, in fact, for the definition of time itself. 

I dare say that most of what is there will be familiar to most Time Nuts, but 
having so much of it concentrated into a single volume is not only a great deal 
of fun to read, but also can serve as an indoctrination tool to others.

But it's not just the Time chapter. The chapter on Clean ends in a TI cleanroom 
where advanced semiconductors are made. A place where the water is too clean to 
drink and the workers wear protective suits not to protect themselves from the 
environment, but vice-versa. The Sound chapter touches on SIGSALY, the first 
digital audio transmission system.

Anyway, if you haven't come across this book, I think it's worth a look - 
particularly if you're a fan of the work of James Burke. 

Sent from my iPhone
___
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 Thunderbolt no longer determines thecorrect date

[Nick Sayer via time-nuts]

FWIW, the SkyTraq receivers have the notion of a “UTC reference date” which 
allows the 1024 week window to roll forward indefinitely as long as you update 
that value once in a while. I’ve written code in my GPS Clock to update the 
reference date once a year as well as update the default GPS-UTC delta whenever 
it’s wrong (this fixes the “off by 2 seconds for a minute or two” problem). 
This latter issue is an interesting one - If you supply SkyTraq modules with 
backup power, then on *power up* it will copy the GPS-UTC delta to flash, as 
long as the memory of what it was at shut down remains preserved.

The UTC reference date also allows the clock to workaround the Y2K issue in the 
NMEA sentences - you can query the reference date and use a 100 year rolling 
window similarly for that. As long as you power the clock up and give it 
reception at least once every 19 years or so, it should calculate the correct 
date as long as GPS remains available (this only really matters for the clock 
because it’s how DST decisions are made - it doesn’t actually display the date).

I haven’t done this for my GPSDOs because the controller isn’t wired to speak 
to the GPS receiver. But you can use the diagnostic port and SkyTraq’s GNSS 
viewer software to do this if you care to. The only use the GPSDO makes of the 
time/date is time-stamping the logs.

> On Jul 27, 2017, at 7:01 PM, Tom Van Baak  wrote:
> 
>> Well quite an unpleasant surprise. So after the 30th do the TBolts stop
> 
> Paul,
> 
> This topic has been covered a number of times over the years. Some time-nuts 
> have even run TBolt's under GPS simulators to verify that the 10 MHz and 1PPS 
> outputs will be fine. So apparently the only effect is that the date & time 
> (in binary TSIP messages) are off by 1024 weeks. This rollover-related effect 
> is by now a "common" issue with many GPS receivers.
> 
> The current version of Mark's Lady Heather program has code to detect this 
> and fix it so you're good to go for the next 19.6 years.
> 
> /tvb
> 
> - Original Message - 
> From: "paul swed" 
> To: "Discussion of precise time and frequency measurement" 
> 
> Sent: Thursday, July 27, 2017 5:36 PM
> Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines thecorrect 
> date
> 
> 
>> Well quite an unpleasant surprise. So after the 30th do the TBolts stop
>> working or is it a case of just the wrong date? I know my Hp3801s been
>> working just fine and its old. Is the TBolt the same issue. Wrong date but
>> still locks thats all I care about actually.
>> With to respect of some sort of a hack I can see that being fairly
>> difficult.
>> Regards
>> Paul
>> WB8TSL
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

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

[Nick Sayer via time-nuts]

The GPS-UTC delta is part of the set of data GPS sends down from the 
satellites. My GPS clocks will show the time two seconds fast for some amount 
of time ranging from 0 to 12 minutes after first-fix because the periodicity of 
that particular message is 12 minutes. My guess is that 2 seconds means that 
the firmware was written some time before the leap second before the most 
recent one, and that in the absence of that message, the firmware uses a 
compile-time default delta that gets overridden when the real value arrives.

What kinda sucks is that there’s no indication in the NMEA sentences that this 
“infill” data is being used. You just get the wrong time and then suddenly it 
corrects to the right time.

It’s conceivable that SkyTraq could update the firmware with a new “default” 
delta, but that would only last until the next leap second.

It’d be nice if they updated some non-volatile memory whenever a leap second 
occurred. Then you’d only see the error once when a new chip is brought up for 
the first time. The data is stored in battery-backed storage, so as long as you 
don’t *cold* start, you’ll have the correct time. This observation prompted me 
to change my mind and add a super-cap Vbatt circuit going forward (so it can 
tolerate up to around 45 minutes of power loss without having to cold-start).

The SkyTraq receiver correctly reports (positive) leap second as they occur as 
23:59:60.


> On May 16, 2017, at 3:29 AM, Tim Shoppa  wrote:
> 
> Since future leap seconds aren't known very far in advance, how wise is it
> to even claim to handle any possible leap second or time scale conversion,
> in a firmware-controlled device that cannot download future leap second
> information from the Internet?
> 
> The GPS itself presumably knows how to handle leap seconds at the moment
> with possibly minor glitches.
> 
> If you can connect to the Internet, then I think you're good for maybe the
> next few decades until the current concepts of "web" and "URL" and
> "internet" become as hopelessly outdated as Telex addresses. I think the
> URL concept probably has at least a decade left in it, and that's
> considerably longer than the couple-times-a-year possibility of a leap
> second, so leap second file downloads from IETF would seem to make sense if
> you claim to handle such conversions.
> 
> The "future-proofing" of your time conversion is not a new issue. When I
> read century-old articles about gear ratios for converting solar to
> sidereal time (*) , they note that you should not try to get too many
> digits of precision because they knew that the length of the solar day had
> real and unpredictable variances even back then. One author notes that if
> you want your gear ratio to work well for the next 100 years, you should
> use the ratio appropriate for 50 years into the future, not today.
> 
> Now admittedly, microcontrollers generally don't last as long as a set of
> gears :-)
> 
> Tim
> 
> On Sat, May 13, 2017 at 9:58 PM, Mark Sims  wrote:
> 
>> Converting GPS seconds to Gregorian date/time on the Arduino will be an
>> arduous task.  You take GPS seconds and add it to the GPS starring epoch to
>> get a Julian date.  Then add in the number of leap seconds as a fraction of
>> a day to get UTC and possibly add in a time zone offset for local time.
>> Don't forget to do daylight savings time conversion...  Then convert the
>> result to Gregorian date/time for display.
>> 
>> The problem is the Arduino floating point library is single precision only
>> and does not have the resolution needed to handle the numbers involved.
>> Doing it with integer arithmetic (long longs) opens up a whole new can of
>> worms.
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

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

[Nick Sayer via time-nuts]

I wouldn’t expect floating point to enter into it.

Add the leap second correction in, then take seconds modulo 86400 and you get 
the second-within-the-day. Divide seconds by 86400 and you get the day number.

With the day number, it’s quite straightforward to figure out gregorian date 
given a 0 date in modern times (GPS’ epoch is in 1980). You do have to figure 
out externally what 1024 week GPS cycle you’re in. You can start with a 
firmware default and increment an EEPROM value every zero-crossing. As long as 
the user gets a fix at least once every 1024 weeks, you’ll be good.

You figure out the year by subtracting 365 or 366 and incrementing the year 
number until the day is less than either 366 or 365. Picking which of those is 
tricky, but it’s not particularly onerous. You figure out the month by 
comparing the remaining days to a list of day-of-year-for-month values (again, 
being careful to increment by 1 during leap years if the month is > 2). 
Subtract that out, add 1, and the remainder is the day-of-month.

Turning a second-within-the-day value into H:M:S is child’s play. The only 
nuance left is 23:59:60 when a leap second occurs.

All of that is enough to go from GPS second number to the NMEA UTC output.

Going from NMEA UTC output to DST corrected local time is actually an exercise 
I’ve done for my GPS clock. You can take a look at my C code for that on 
GitHub: https://github.com/nsayer/GPS_clock

Now, going to Sidereal time, *that’s* a floating-point bitch.


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

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

Re: [time-nuts] A good GPS-Receiver with 1PPS output...

[Nick Sayer via time-nuts]

I use it in all 3 of my GPSDO designs and it works pretty much ideally so far 
as I can tell.

> On May 12, 2017, at 9:56 AM, Bryan _  wrote:
> 
> How well would the Venus work as a receiver for a GPSDO project using the 
> 1pps output?
> 
> 
> -=Bryan=-
> 

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

[time-nuts] Raspberry Pi Sidereal clock display

[Nick Sayer via time-nuts]

A while ago, I took my GPS clock board 
(https://hackaday.io/project/18501-gps-clock) and sort of rearranged it to 
instead be a Raspberry Pi Zero clock display. I turned it into a product on 
Tindie for folks who can more easily get NTP over WiFi or Ethernet than GPS. 
Recently, someone asked me about a Sidereal GPS clock, but that’s problematic 
because the PPS interrupts are GPS time, which isn’t synchronized at all with 
sidereal time. Also, the traditional method of converting to sidereal time 
involves lots of floating point math, and little bitty microcontrollers aren’t 
at home doing that.

Instead, I wrote an alternative driver program for my Pi Zero clock board, so 
now it can be a sidereal clock display. If you run the daemon with no 
arguments, you get Greenwich Mean Sidereal Time, but if you specify your 
longitude, you get local mean sidereal time.

In principle, I believe you could design an alternate clock board with two 
independent displays with different SPI chip select lines and display local 
civil time and local MST simultaneously. I haven’t contemplated going down that 
road (yet).

The code is in the Pi Zero clock repo at https://github.com/nsayer/SPI_Clock/, 
and the clock hardware project is at 
https://hackaday.io/project/20156-raspberry-pi-zero-w-desk-clock
___
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] Bay Area Maker Faire '17

[Nick Sayer via time-nuts]

Anybody else going to Bay Area Maker Faire next weekend? I’ll have a booth 
there (heavy on clocks and GPS) and would love to meet anyone going.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] A good GPS-Receiver with 1PPS output...

[Nick Sayer via time-nuts]

https://www.tindie.com/products/nsayer/skytraq-venus838lpx-t-timing-gps-module-breakout/
 


> On May 11, 2017, at 5:36 PM, djl  wrote:
> 
> Can't find this on Tindie???
> 
> On 2017-05-10 09:03, Mark Sims wrote:
>> The GPS with the lowest PPS jitter/sawtooth is the Venus timing
>> receiver... around 6 ns.   Nick Sayer sells one on Tindie for $50.  It
>> is mounted on a board that has the same pinouts as the Adafruit
>> Ultimate GPS.  Also Navspark sells one for more $.
>> Lady Heather talks to the Venus receivers.
>> ___
>> 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.
> 
> -- 
> Dr. Don Latham
> PO Box 404, Frenchtown, MT, 59834
> VOX: 406-626-4304
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] WTB: GPSDO

[Nick Sayer via time-nuts]

The splitters I’m using do have a 200Ω load on them. I know this because PA6H 
modules recognize an external antenna and use it.

> On Mar 22, 2017, at 3:20 PM, Chris Caudle <ch...@chriscaudle.org> wrote:
> 
> On Wed, March 22, 2017 3:52 pm, Nick Sayer via time-nuts wrote:
>> My thunderbolt *insists* on being on the DC Pass port. If you put it on a
>> DC Block port (yes, something *else* is on the DC pass port and supplying
>> DC for the antenna and splitter at the time - other connected devices work
>> just fine) it's deaf.
> 
> You need a DC load so that the GPS receiver thinks there is an active
> antenna attached. I think that is just a quirk of the Thunderbolts, that
> rather than just flagging an alarm and continuing to run, it gives up and
> won't even try to run.
> -- 
> Chris Caudle
> 
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] WTB: GPSDO

[Nick Sayer via time-nuts]

> On Mar 22, 2017, at 12:40 AM, Thomas Petig  wrote:
> 
> 
> The special GNSS splitters forward DC only from one port and provide
> some 200 Ohm DC termination together with the DC-block on the other
> ports to keep the receiver happy, i.e., it seems current consumption and
> therefore believes the antenna is ok. Some have an amplifier to
> compensate for the loss of the splitter, but it is not necessary if the
> antenna delivers enough.
> 

Just a little side query… For those using one of these sorts of splitters with 
a Thunderbolt, have you seen anything odd?

My thunderbolt *insists* on being on the DC Pass port. If you put it on a DC 
Block port (yes, something *else* is on the DC pass port and supplying DC for 
the antenna and splitter at the time - other connected devices work just fine) 
it’s deaf. I’ve worked around it by giving the pass port to the TBolt and 
running everything else on a block port, so it’s not a deal-breaker or 
anything, but it’s a bit awkward and otherwise unexplainable. 
___
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] Best Chance GPS module

[Nick Sayer via time-nuts]

Ok. It wasn’t totally clear from your earlier message what you were looking at, 
but just be aware that the LED pin is just a “blinkenlichten” pin that means 
almost nothing. You have to actually separately look at the PPS pin to see what 
it’s doing. There’s (almost) no connection between the activity on the two pins.


> On Mar 19, 2017, at 2:13 AM, David J Taylor <david-tay...@blueyonder.co.uk> 
> wrote:
> 
>> On Dec 1, 2016, at 7:44 AM, David J Taylor <david-tay...@blueyonder.co.uk> 
>> wrote:
>> 
>> 
>> Venus838LPX-T.   Seems to go into a non-locked state for a proportion of the 
>> time but still emits a PPS signal, which increasingly deviates from true 
>> UTC.  That's using a 25 mm square 28 dB active patch antenna, similar to the 
>> antennas on other similarly located GPS receivers.  This was indoors, on the 
>> top floor of a two-storey building, with just the power fed to it, watching 
>> the LED flash.
>> 
>> Maybe I was unlucky?  I wonder what experience others have?
> 
> From: Nick Sayer via time-nuts
> 
> Was the LED on the PPS pin or on the FIX pin?
> 
> The FIX pin is nothing like the PPS output. Frankly, I’m not 100% sure what 
> the rules are for it. When things are working properly, it blinks at 0.5 Hz, 
> but the leading and trailing edges are something like 120-150 msec after the 
> second. It’s very, very loose. My own interpretation is that the controller 
> flips the bit when it’s got nothing better to do.
> 
> I’ve not witnessed the actual PPS pin being toggled when GPS isn’t available, 
> but it’s not a failure mode I’ve expended a lot of effort to examine.
> ===
> 
> Nick,
> 
> I had to dig out the module to check, but as far as I can tell the LED is 
> connected to pin 7 on the chip, listed as GPIO0/LED on the data sheet. 
> Nominally, navigation status.
> 
> The PPS output which I was monitoring comes from the PPS pin (40) on the chip 
> - GPIO3/P1PPS1
> 
> Cheers,
> David
> -- 
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv 

___
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] Best Chance GPS module

[Nick Sayer via time-nuts]

Was the LED on the PPS pin or on the FIX pin?

The FIX pin is nothing like the PPS output. Frankly, I’m not 100% sure what the 
rules are for it. When things are working properly, it blinks at 0.5 Hz, but 
the leading and trailing edges are something like 120-150 msec after the 
second. It’s very, very loose. My own interpretation is that the controller 
flips the bit when it’s got nothing better to do.

I’ve not witnessed the actual PPS pin being toggled when GPS isn’t available, 
but it’s not a failure mode I’ve expended a lot of effort to examine.

> On Dec 1, 2016, at 7:44 AM, David J Taylor  
> wrote:
> 
> 
> Venus838LPX-T.   Seems to go into a non-locked state for a proportion of the 
> time but still emits a PPS signal, which increasingly deviates from true UTC. 
>  That's using a 25 mm square 28 dB active patch antenna, similar to the 
> antennas on other similarly located GPS receivers.  This was indoors, on the 
> top floor of a two-storey building, with just the power fed to it, watching 
> the LED flash.
> 
> Maybe I was unlucky?  I wonder what experience others have?


___
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 Phone time display accuracy...?

[Nick Sayer via time-nuts]

The time on mine is quite good, but I believe that’s because I have an Apple 
watch. If you pair an iOS device to an Apple Watch, I believe it suddenly 
“tries much harder” to keep its own clock in sync so that it can serve good 
time sync to the watch.

Apple has made grandiose claims about the accuracy of the watch, but human 
granularity for time is around 100 ms-ish anyway, so the bar is awfully high.

___
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] New project: Raspberry Pi Zero W NTP clock

[Nick Sayer via time-nuts]

I’ve made a variation on my GPS clock that uses the new Pi Zero W (in truth, it 
could use an ordinary Pi Zero with some other network connectivity. The W’s 
built-in WiFi just simplifies things a bit) to drive the same LED display. The 
local time would ostensibly be synced by NTP in the usual manner (or whatever 
manner you like) and a daemon simply writes the time to the display. When I 
film the prototype in 240 fps slow motion, I see the tenth-of-a-second digit 
change within a frame of a GPS clock, so it’s at least an order of magnitude 
more accurate than its granularity, which is certainly good enough for a 
timepiece for humans.

I did it because sometimes it’s easier to get WiFi than GPS, and the Pi 
solution was a lot easier than microcontroller alternatives, while still being 
around the same cost and with sufficient accuracy.

https://hackaday.io/project/20156-raspberry-pi-zero-w-desk-clock
___
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] OT: Eagle PC CAD now Autodesk, $500/year

[Nick Sayer via time-nuts]

I think the alternative with the greatest momentum at the moment is KiCAD.

I haven’t tried KiCAD yet. The problem I have is that I have a ton of libraries 
and projects I’d have to convert. I suspect that there is automation to perform 
the import (or soon will be), but it’s basically NRE that I’m not looking 
forward to. That doesn’t really change with whatever option I pick, other than 
sticking with EAGLE. I’m not yet 100% convinced Autodesk won’t reverse course 
on this, unless they really *do* want EAGLE to die the death of a thousand cuts.

> On Jan 19, 2017, at 7:52 PM, Richard (Rick) Karlquist  
> wrote:
> 
> Off topic, but probably a lot of disgrunted Eagle users on this list.
> Its official, you will now have to pay $500 per year for a
> professional license from Autodesk.  The spin meistering of the
> announcement would make George Orwell proud.  I don't see any way they
> can keep me from just using the license I currently own, at least
> on the OS's it supports.  (Parenthetically, like many users, I
> am also digging in my heels in terms of staying at Windows 7).
> 
> Still, the question arises:  are there any affordable alternatives?
> Don't have to be entirely free.  I am looking for any trends out
> there as to what tool will attract a critical mass of users in
> the future.  There is strength in numbers.
> 
> Comments?
> 
> Rick N6RK
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] New stuff in my Tindie store

[Nick Sayer via time-nuts]

> On Dec 26, 2016, at 7:40 PM, Nick Sayer via time-nuts <time-nuts@febo.com> 
> wrote:
> 
> 
> The second one will be up next week, and it’s a simple GPS clock.

The listing for the clock is live now: 
https://www.tindie.com/products/nsayer/gps-clock/
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] A Leap Second is coming

[Nick Sayer via time-nuts]

Here's what I got:

https://youtu.be/nGMFzhNFrb4

It worked as I expected. 4:00:00 PM was two seconds long. 

Sent from my iPhone

> On Dec 30, 2016, at 11:49 AM, Nick Sayer via time-nuts <time-nuts@febo.com> 
> wrote:
> 
> I'm going to definitely observe my GPS clock to check its behavior. It 
> *should* repeat second zero (in my case of 4PM PST). Not the most exactingly 
> accurate depiction, but it's the best I can do with the architecture. 
> 
> Sent from my iPhone
> 
>> On Dec 29, 2016, at 12:22 AM, David J Taylor <david-tay...@blueyonder.co.uk> 
>> wrote:
>> 
>> Is everybody setup to watch it and collect lots of data?
>> 
>> Anybody have a list of tools/toys for collecting data?
>> 
>> An old favorite:
>> www.cl.cam.ac.uk/~mgk25/time/leap/test/timelog.c
>> =
>> 
>> Some tools here, to see which NTP servers are announcing the event:
>> 
>> http://www.satsignal.eu/software/net.htm#NTPLeapTrace
>> 
>> Perhaps they may be of use to someone?
>> 
>> Cheers,
>> David
>> -- 
>> SatSignal Software - Quality software written to your requirements
>> Web: http://www.satsignal.eu
>> Email: david-tay...@blueyonder.co.uk
>> Twitter: @gm8arv
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] A Leap Second is coming

[Nick Sayer via time-nuts]

I'm going to definitely observe my GPS clock to check its behavior. It *should* 
repeat second zero (in my case of 4PM PST). Not the most exactingly accurate 
depiction, but it's the best I can do with the architecture. 

Sent from my iPhone

> On Dec 29, 2016, at 12:22 AM, David J Taylor  
> wrote:
> 
> Is everybody setup to watch it and collect lots of data?
> 
> Anybody have a list of tools/toys for collecting data?
> 
> An old favorite:
> www.cl.cam.ac.uk/~mgk25/time/leap/test/timelog.c
> =
> 
> Some tools here, to see which NTP servers are announcing the event:
> 
> http://www.satsignal.eu/software/net.htm#NTPLeapTrace
> 
> Perhaps they may be of use to someone?
> 
> Cheers,
> David
> -- 
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] New stuff in my Tindie store

[Nick Sayer via time-nuts]

> On Dec 26, 2016, at 9:22 PM, Mark Sims  wrote:
> 
> Ahhh, the subtle wonders of time zones and DST changes...  Heather lets you 
> set your time zone offset down to the second, and does not range limit the 
> offset.  If you want UTC +987:65:43 it's yours!   There are a surprising 
> number of places on with weirdo time zones.   

It’s not so much that the code can’t do the right thing… it’s making the 
two-button, 7 digit UI not *suck* just to support oddball cases for people who 
aren’t actually purchasing the product. :)

> 
> I tried to find a manageable, self contained way to automatically calculate 
> the time zone from lat/lon, but that's a losing battle.  Even getting it off 
> the net is rather problematic.  I’ve thought about implementing a last-ditch 
> emergency back-up plan of basing it on (longitude/15) but decided that was 
> too un-time-nutty.   

Yeah. Just the database of the connect-the-dot timezone lines for North America 
alone would probably blow the firmware budget for my hardware.

> 
> Heather has standard DST rules for USA, Europe, Australia, and New Zealand 
> (assuming it hasn't yet gone the way of Atlantis).  But since DST rules can 
> change with the stroke a a politician's pen, you can specify a custom rule.  
> The one current DST limitation is the time must change at an hour…  that 
> would be easy enough to change.

I drew the line above NZ, but if more than a handful of people from there 
actually want to buy one, I’ll happily add it. Same goes for anywhere else. And 
the firmware is open and the board has an ISP header on it, so updating it 
yourself is also an option.

> 
> 
> 
>> The Pacific Ocean is large and very spread out.  So the Chatham Islands, 
> though part of New Zealand are 45 minutes ahead of New Zealand time.  
> That is a real nasty and unusual time change. Plus NZ daylight time 
> being GMT +13
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] New stuff in my Tindie store

[Nick Sayer via time-nuts]

I thought of a WiFi+NTP variant, but I haven’t played with the various ESP 
WiFi modules that are in vogue for Arduino and the like. From what I know about 
those, it’d probably be easiest to ditch the board’s ATTiny841 and just add 
support for the bit-banged SPI display controller directly to the ESP itself.

That said, you could probably add that same support - or even support for 
*proper* SPI - to the Pi as well. I’m using the MAX6951 for this, and I like it 
a *lot*.

> On Dec 26, 2016, at 8:55 PM, Mark Sims  wrote:
> 
> Simple ain't for time nuts...  I'm taking Heather, a PI, and the PI touch 
> screen and making a GPS disciplined alarm clock.   I hate the alarm clock 
> that I have since to change the time or alarm you have to hold a button and 
> let the time cycle around until it gets to where you want it.  If you go too 
> far,  you have to do it all over again.  It takes a couple of minutes to 
> change a time.  Luckily, I seldom use an alarm clock.  
> 
> I'll probably power it through a USB power bank so it has a few hours of 
> battery back-up.  I only need 15 seconds of backup since the house has an 
> automatic standby generator.  I'll probably run it off one of the $5 Sirf-III 
> GPS modules... those things can track GPS down in darkest bowels of Heather's 
> dungeons.
> 
> Heather has the GPS, time zone, DST, alarms, clock display (analog and/or 
> digital), etc already in there.  The next version can run  keyboard scripts 
> if you press F1 .. F10 so you can set common alarm times and configs in the 
> scripts and call them up from the on-screen touch keyboard.  Plus it can sing 
> the quarter hours,  crow at sunrise/sunset,  sound church bells at solar 
> noon, etc.
> 
> With a net connection / NTP, you don't even need a GPS.  Heather v5 can run a 
> clock display off the CPU clock... but where's the fun in that?  Plus, my 
> bedroom doesn't have the net / wi-fi.
> 
> 
> 
>> The second one will be up next week, and it’s a simple GPS clock
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] New stuff in my Tindie store

[Nick Sayer via time-nuts]

The last time I checked, the population of New Zealand was about the same as 
the population of Los Angeles. I don’t have any data to suggest that the 
proportion of New Zealanders in the market for a GPS clock is markedly 
different than elsewhere. When developing new products, I tend to make certain 
assumptions about market sizes in deciding what priority to apply to feature 
sets.

That said, it *is* open source firmware.

As for the +13 timezones, if you turn off DST, then +13 is the same as -11 for 
the purpose of this clock (it doesn’t display the date). The clock doesn’t 
currently support non-hour (that is, half- or quarter-hour) zones, again 
because it wasn’t a priority.

If a Tongan wants to *actually* buy one, then maybe I’ll roll some custom 
firmware for him or her. :)


> On Dec 26, 2016, at 8:27 PM, Will Kimber <zl1...@gmx.com> wrote:
> 
> Hi Nick,
> 
> 
> Sorry to rain on your parade.  A good idea BUT ... 
> 
> As a new (45 years) New Zealander may I make a couple of suggestions that 
> folks back where I come from and others across the pond forget.
> 
> The Pacific Ocean is large and very spread out.  So the Chatham Islands, 
> though part of New Zealand are 45 minutes ahead of New Zealand time.  That is 
> a real nasty and unusual time change. Plus NZ daylight time being GMT +13
> Next are the Islands making up Tonga.  To keep the day consistent with New 
> Zealand, Australia, other Pacific Islands & Asia went to G.M.T. +13 as its 
> timezone  a few years back.
> 
> Cheers,
> Will
>  
> On 12/27/2016 04:40 PM, Nick Sayer via time-nuts wrote:
>> I’ve finally added the power supply I’ve designed for the Thunderbolt. It’s 
>> a combined switching+linear design. It’s been running my own Thunderbolt for 
>> a while now. There’s a schematic on the store page and it can come with or 
>> without a 15W primary supply. 
>> https://www.tindie.com/products/nsayer/thunderbolt-power-board/ 
>> <https://www.tindie.com/products/nsayer/thunderbolt-power-board/>
>> 
>> The second one will be up next week, and it’s a simple GPS clock. It has 7 
>> seg LEDs for hour, minute, second and tenth of a second (the later is 
>> interpolated from the PPS). My educated guess is that the tenths are 
>> accurate to around 200 µs or so (the zeroeth is probably much better). It 
>> has support for +/- 12 hours of timezones, 12- or 24-hour time display (with 
>> AM and PM LEDs) and DST for US, EU or Australia (or off). It can come as a 
>> board-only “quick kit” (surface mount components all done and programmed, 
>> through-hole left for you to do), a “quick kit” with a laser cut wood and 
>> acrylic case and plug-in power supply, or assembled (in the case, with the 
>> power supply). It has an SMA jack for an external antenna (that is not 
>> included). 3.3V is supplied for active antennas. Board-only quick kit will 
>> be $59.99, assembled $99.99. I’m just waiting for the inventory of boards to 
>> come in before I activate that store listing. But for now, there’s the 
>> Hackaday project page: 
 https://hackaday.io/project/18501-gps-clock 
<https://hackaday.io/project/18501-gps-clock>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@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.
> 

___
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] New stuff in my Tindie store

[Nick Sayer via time-nuts]

I’ve finally added the power supply I’ve designed for the Thunderbolt. It’s a 
combined switching+linear design. It’s been running my own Thunderbolt for a 
while now. There’s a schematic on the store page and it can come with or 
without a 15W primary supply. 
https://www.tindie.com/products/nsayer/thunderbolt-power-board/

The second one will be up next week, and it’s a simple GPS clock. It has 7 seg 
LEDs for hour, minute, second and tenth of a second (the later is interpolated 
from the PPS). My educated guess is that the tenths are accurate to around 200 
µs or so (the zeroeth is probably much better). It has support for +/- 12 hours 
of timezones, 12- or 24-hour time display (with AM and PM LEDs) and DST for US, 
EU or Australia (or off). It can come as a board-only “quick kit” (surface 
mount components all done and programmed, through-hole left for you to do), a 
“quick kit” with a laser cut wood and acrylic case and plug-in power supply, or 
assembled (in the case, with the power supply). It has an SMA jack for an 
external antenna (that is not included). 3.3V is supplied for active antennas. 
Board-only quick kit will be $59.99, assembled $99.99. I’m just waiting for the 
inventory of boards to come in before I activate that store listing. But for 
now, there’s the Hackaday project page: htt
 ps://hackaday.io/project/18501-gps-clock
___
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] Best replacement for Trimble Bullet antenna

[Nick Sayer via time-nuts]

At work I have access to an industrial one that (I am told) uses lasers to 
harden a liquid... something. I'm not a plastic expert. We use that stuff for 
outdoor enclosures and it is UHF transparent, at least to some degree (it would 
have to be given our use case). I used it once to make a couple of wall mount 
J1772 fake inlets to hold our car charging plugs. Those have survived outdoors 
without any issues. At some point in need to repaint them, as the native color 
is battleship grey, and the white paint is starting to wear off.

If Tupperware made something conical, I'd chose that in a hurry. It may not 
have a great deal of UV staying power, but "microwave safe" implies good RF 
performance. I've used that solution to quickly weatherproof home brew stuff 
before. 

Even if whatever the cap is made of isn't perfectly RF clear, I've certainly 
got S/N margin for some attenuation, even if it isn't uniform. I would posit 
that as long as it's performance doesn't alter over time scales shorter than a 
few minutes that the impact would be immeasurable - certainly compared to the 
ionosphere's.

I probably won't bother, though, as we don't seem to have bird trouble and it 
doesn't snow here in Silicon Valley. If it were an unattended installation, 
that might change things. 


Sent from my iPhone

> On Nov 23, 2016, at 5:07 AM, Bob Camp <kb...@n1k.org> wrote:
> 
> Hi
> 
> Ummm …. e …. radio transparent plastic. You want to avoid making a 
> lens that distorts the paths over the antenna so it’s not just an issue of 
> transparent. 
> You also want it to be “clear” (non distorting). You need it to be stable in 
> terms of UV,
> humidity and temperature. The guys who made the antenna didn’t have it quite 
> so tough, 
> they could design the cover as part of what determined the pattern of the 
> antenna.  
> 
> The short list of what your low cost printer will handle:
> 
> PLA
> ABS
> PETG
> 
> If it is really low cost, it will only handle the first one. All are a bit of 
> a 
> disaster at 1.5 GHz. PLA likely will not hold up outdoors, let alone do well 
> at RF.
> The other two are poor at RF. 
> 
> The longer list on a higher priced printer:
> 
> Nylon
> Polycarbonate
> HIPS
> Flexable’s 
> 
> The last two are out right from the start. One dissolves in water, the other 
> has no structural integrity. Nylon is hydroscopic 
> and not all that great at 1.5 GHz. For what ever reason the polycarbonate 
> that they sell also is a bit hydroscopic. It also is 
> quite challenging to print unless you have a very fancy printer. 
> 
> Certainly not an easy thing to do.
> 
> Bob
> 
>> On Nov 23, 2016, at 1:05 AM, Nick Sayer via time-nuts <time-nuts@febo.com> 
>> wrote:
>> 
>> 
>>> On Nov 22, 2016, at 9:39 PM, Dennis Lloyd <dll...@musi-tronics.com> wrote:
>>> 
>>> Your problem will be Birds and Debris, it is flat and you will have 
>>> interruptions and phase shifts.
>>> 
>>> Did you not understand why we use pointed antennas for timing and fixed 
>>> installations.
>> 
>> No, I guess I didn’t.
>> 
>> That said, our cats seem to be doing a good job discouraging any birds, and 
>> I can see the antenna mornings when I go out to the car and there’s been no 
>> debris problem I’ve been able to detect.
>> 
>> If it were required, I’d suspect it would be fairly easy to 3D print a 
>> pointy hat from radio-transparent plastic.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 

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

Re: [time-nuts] Best replacement for Trimble Bullet antenna

[Nick Sayer via time-nuts]

> On Nov 22, 2016, at 9:39 PM, Dennis Lloyd  wrote:
> 
> Your problem will be Birds and Debris, it is flat and you will have 
> interruptions and phase shifts.
> 
> Did you not understand why we use pointed antennas for timing and fixed 
> installations.

No, I guess I didn’t.

That said, our cats seem to be doing a good job discouraging any birds, and I 
can see the antenna mornings when I go out to the car and there’s been no 
debris problem I’ve been able to detect.

If it were required, I’d suspect it would be fairly easy to 3D print a pointy 
hat from radio-transparent plastic.

___
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] Best replacement for Trimble Bullet antenna

[Nick Sayer via time-nuts]

I bought a Gilsson marine antenna and an 8 port amplified splitter on eBay. The 
antenna is mounted on the roof of my garage, where it has visibility easily 
down to 20 degrees except to the North where there is an obstruction (but that 
doesn’t matter). The coax is 10 meters of whatever came with the antenna. My 
reception with this setup is as close to ideal as I’ve ever heard of. At the 
moment, gpsmon on my NTP server shows 5 satellites with 50+ SNR, another 5 with 
40+ and one at 22 (7 degrees elevation).



> On Nov 22, 2016, at 10:58 AM, Russ Ramirez  wrote:
> 
> I have a used version of the subject antenna, which is still quite
> operational. However, I recently needed either a way to tie into reception
> from this antenna or purchase additional antennas. Given the cost of active
> patch antennas, I tried one from Adafruit.
> 
> While comparing reception on a Trimble Thunderbolt to an integrated GPS
> module (used for time and PPS on a WSPR transmitter) is not apples to
> apples, I did notice how many more fixes the latter receiver obtains. For
> example, when the Thunderbolt has fixes on 6 birds, the YIC51612 (MediaTek)
> receiver module will have 10. I am sure the criteria is not the same for
> what constitutes a fix in both cases, but I also observed the following.
> 
> By simply using a 0.1 uF SMD MLCC cap to couple into the Trimble Bullet,
> i.e. the Thunderbolt still powers the amp with +5v, but the signal has a
> path to my other GPS receiver, the bullet antenna underperformed by a
> significant amount. What's possibly worse is that the patch antenna is on a
> window sill, whereas the bullet antenna is on the roof with a clear view of
> the sky.
> 
> I have not tried the Adafruit patch with the Thunderbolt yet as I will have
> to reduce the LNA voltage from 5 to 3.3 before trying the second test.
> 
> The general question I wanted to ask though is what others use/like as roof
> mounted antennas? Are some of the 'Marine' antennas better?
> 
> Russ
> K0WFS
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Man with too many clocks.

[Nick Sayer via time-nuts]

I’m going to try and describe my thoughts, but it may not come out as “right” 
as some others here can do. Still…

One problem you’re going to run into if you go down the road of attempting to 
PLL one thing to another is that you have to find a balance between phase 
control and frequency stability.

You’re going to always be reacting to the phase drift of your disciplined 
device. Your “knob” for doing so is to adjust (probably in steps) the 
frequency. If your PLL is very “twitchy,” then you’re going to move that knob 
very quickly and firmly, resulting in very tight phase control, but a frequency 
that, at least over a short term, will jump around a bit.

By contrast, if you are very reluctant to move the “knob,” then you’re going to 
move it so slowly that by the time you have a meaningful effect on the phase, 
the phase will have drifted quite a bit. That said, your movement of the 
frequency knob will be so slow that the frequency stability would be much 
better, at least over the short term.

In essence, this is choosing the PLL time constant. How you do so depends on 
the behavior of your device as well as the stability you desire from the output.

> On Nov 3, 2016, at 5:20 AM, Peter Reilley  wrote:
> 
> I am the proverbial man with too many clocks and I don't know what time it is.
> To correct this situation I have decided to calibrate everything.
> 
> I have a HP 5370B, a HP 6370A, and a HP 5328A all with the TCXO option.   I 
> also
> have some TCXO modules.   I figured that I would calibrate them against my 
> Trimble
> Resolution T GPS receiver.
> 
> I put the 1 PPS signal in one channel of my scope and one of the 10 MHz TCXO
> signals in the other channel and look at the phase relationship. The TCXO's 
> are
> already close enough that I should not be out by more than a fraction of a 
> waveform.
> I understand that I have to deal with the 1 PPS without sawtooth correction.
> 
> I expected to see the 10 MHz signal bounce around but not move more than 1/2
> of a wave length.   Instead I see the 10 MHz waveform appear steady for a few 
> seconds
> then jump a significant portion of the wave.   The jump is too much to be 
> confident
> that I have not slipped one cycle.
> 
> Can I do what I am trying to do or am I missing something?
> 
> Pete.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] WWV receivers?

[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 <albertson.ch...@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-nuts@febo.com <mailto:time-nuts@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 <p...@phk.freebsd.dk 
> > <mailto:p...@phk.freebsd.dk>> wrote:
> >
> > 
> > In message <5a002554-8d90-4c75-95da-21db45d61...@kfu.com 
> > <mailto:5a002554-8d90-4c75-95da-21db45d61...@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
> > p...@freebsd.org | TCP/IP since RFC 956
> > FreeBSD committer   | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by incompetence.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@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-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] WWV receivers?

[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 <p...@phk.freebsd.dk> wrote:
> 
> 
> In message <5a002554-8d90-4c75-95da-21db45d61...@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
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

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

Re: [time-nuts] WWV receivers?

[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  wrote:
> 
> 
> tsho...@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-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Anybody want a Thunderbolt power supply?

[Nick Sayer via time-nuts]

>>>>>> Bob
>>>>>> 
>>>>>>> On Oct 21, 2016, at 11:06 PM, Scott Stobbe <scott.j.sto...@gmail.com 
>>>>>>> <mailto:scott.j.sto...@gmail.com>
>> <javascript:;>
>>>>>> <javascript:;>> wrote:
>>>>>>> 
>>>>>>> Interesting, I would have thought that the +12V input would be
>>>> extremely
>>>>>>> well regulated since its shared with the oven heater, I*R drops are
>>>> going
>>>>>>> to show up every where, if your looking for uV levels of stability.
>>>>>>> Just a connector has milliohms of contact resistance, let alone
>> routing
>>>>>> and
>>>>>>> cables...
>>>>>>> 
>>>>>>> On Friday, 21 October 2016, Bob Camp <kb...@n1k.org 
>>>>>>> <mailto:kb...@n1k.org> <javascript:;>
>> <javascript:;>>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi
>>>>>>>> 
>>>>>>>>> On Oct 21, 2016, at 7:44 PM, Scott Stobbe <
>> scott.j.sto...@gmail.com <mailto:scott.j.sto...@gmail.com> <javascript:;>
>>>>>> <javascript:;>
>>>>>>>> <javascript:;>> wrote:
>>>>>>>>> 
>>>>>>>>> A little more data on the 7912.
>>>>>>>>> 
>>>>>>>>> The first plot shows the tempCo of the 7912 measured with ambient
>>>>>>>>> temperature swings "7912_TempCo.png". Which is -150 ppm/degC.
>>>>>>>>> 
>>>>>>>>> The second plot is off a 7912 logged for an hour or so,
>>>>>> "7912_1PLC.png",
>>>>>>>>> nothing too interesting here. However the environmental temperature
>>>>>> swing
>>>>>>>>> of about 1 degC/hour is pretty conservative for a DUT sitting in
>> free
>>>>>>>> air.
>>>>>>>>> 
>>>>>>>>> Finally, an allan devation plot looking at the normalized stability
>>>> of
>>>>>> a
>>>>>>>>> 7912 regulator "7912_AllanDeviation.png". Interestingly here, is,
>> how
>>>>>>>> quick
>>>>>>>>> a 15 mK/min temperature swing shoots above the 1/f floor, it's a
>>>> matter
>>>>>>>> of
>>>>>>>>> seconds.
>>>>>>>>> 
>>>>>>>>> Now if your PSRR is 1 ppb/V or better, then all of this is
>>>> comfortably
>>>>>>>>> below the intrinsic noise of a thunderbolt.
>>>>>>>> 
>>>>>>>> The main point is that the internal tempco of the TBolt it’s self is
>>>>>> much
>>>>>>>> larger than
>>>>>>>> the issues surrounding the power supply pins. The +12 is the only
>> one
>>>>>> that
>>>>>>>> is
>>>>>>>> sensitive enough to voltage (change in frequency vs voltage) to
>>>>>> contribute
>>>>>>>> to any
>>>>>>>> significant way to the overall stability.
>>>>>>>> 
>>>>>>>> Bob
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, Oct 21, 2016 at 12:20 AM, Scott Stobbe <
>>>>>> scott.j.sto...@gmail.com <mailto:scott.j.sto...@gmail.com> 
>>>>>> <javascript:;> <javascript:;>
>>>>>>>> <javascript:;>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Nick had mention that the -12V rail on the thunderbolt has the
>>>> poorest
>>>>>>>>>> PSRR with respect to frequency output, so I first took a look at
>> the
>>>>>>>>>> venerable 7912.
>>>>>>>>>> 
>>>>>>>>>> The first data-set was taken with a -13.5 VDC input. Attached is
>> the
>>>>>> 0.1
>>>>>>>>>> Hz to 10 Hz noise of an essentially quiescently loaded 7912, only
>> a
>>>>>> 10k
>>>>>>>>>> resistor

Re: [time-nuts] Anybody want a Thunderbolt power supply?

[Nick Sayer via time-nuts]

Well, because it's easily an order of magnitude more expensive than a 7912. $5 
instead of 50¢ (Q:1).

If it *matters*, then fine, but I am sensitive to cost efficiency in addition 
to efficacy.

If you put the board in a box in a stable temperature environment (which I'd 
kind of assume you'd do if you cared about temperature stability generally), 
then how far do you really have to go?

Sent from my iPhone

> On Oct 21, 2016, at 1:59 AM, Attila Kinali  wrote:
> 
> On Fri, 21 Oct 2016 00:20:43 -0400
> Scott Stobbe  wrote:
> 
>> The bad side of a 7912 is in long-term stability and tempCo, the sample I
>> tested had at least a 150 ppm/degC tempCo, which is going to put a serious
>> lump/bump in the 10s tau to gps crossover point on an allan deviation plot.
> 
> If the Thunderbolt ist most sensitive to the -12V input, why not use
> something like the LT3090? Its temperature coefficient is quite low
> in the order of a few ppm/°C around room temperature. Using a metal
> film resistor that should keep the output variations low as well.
> As added bonus, you get a very low output noise.
> 
> And while you are at it, use three LT3090 for the positive supplies :-)
> 
>Attila Kinali
> -- 
> Malek's Law:
>Any simple idea will be worded in the most complicated way.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] KSC big clock

[Nick Sayer via time-nuts]

This may be obvious, but anyone making such a device today would be well 
advised to use LED strips instead. We just upgraded the lighting in my wife’s 
office/craft room with an LED panel light. It’s around 4’x1’x1” and puts out 
4000 lumens - quite bright and enough to fill the entire room with task level 
lighting. You could certainly make the equivalent of a T8 bulb out of modern 
high output LEDs and they’d be able to be switched on and off solid-state and 
they wouldn’t suffer from frequent switching. Heck, you could probably 
multiplex them the same way you multiplex smaller LED displays and it would 
still work.

> On Oct 20, 2016, at 2:51 AM, Blair Lade  wrote:
> 
> The KSC clock might just use fluroscent tubes in a 7 segment display 
> configuration.Pretty easy to do, just put a set of relay contacts inplace of 
> the starter in the circuit, close the contact, fluro turns off, current flows 
> through heater / filiment keeping them warm.Open the contact, fluro 
> lights..Drive relays off bcd to seven segment decoders, etcWhile it's a bit 
> nasty on the fluro tubes when in the off condition, they are cheap..and the 
> duty cycle isnt all that bad.In actual practise, the relays suffer more than 
> the tubes, and they are cheap too!
> Blair South Australia
> 
> 
> Sent from Samsung tablet.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Anybody want a Thunderbolt power supply?

[Nick Sayer via time-nuts]

Just an update. I’ve built the second prototype board (I skipped over the first 
design), and it’s powering my tbolt right now.

The design calls for 15v in (though it would also work with 13.8v). The +12 
output comes from a D2PAK 7812. For +5, there is an AP1509 buck converter to 
make around 6.5 volts, then a DPAK 7805. For -12, there is an MC34063 
configured as an inverter to make around -13.75 volts and then a DPAK 7912.

Steady-state, the system appears to be working just fine. The AP1509’s inductor 
and the D2PAK 7812 are just warm to the touch.

I checked for noise and ripple on the outputs and it’s somewhere around ±2 mV 
or so generally. From what I can see on the scope, there’s no ripple - it’s all 
high frequency noise. I am not absolutely certain that the noise measurement 
represents real noise or the limits of my measuring ability. I’m just using the 
scope probes the scope came with, and 2 mV/div is its lowest range.

I haven’t compared the noise with the ex laptop supply that I was using before, 
but I’d have to believe it’s cleaner. I don’t really have a way to check the 
oscillator’s before and after ADEV. My only other reference is an FE5680A, and 
I think the thunderbolt’s going to be far better at lower tau (where this all 
matters).

I know also that ±2 mV is still one and perhaps two orders of magnitude higher 
than some have called for. But before I attempt to reduce the noise further, 
I’d like to know that there are real gains to be had. Would someone with a 
Thunderbolt and better output noise measuring wherewithal be willing to take a 
prototype and compare it with something that does have µV levels of noise and 
ripple so I can get an idea of what there is to gain? If you like, you can make 
such comparisons public - no secrets here.

> On Aug 30, 2016, at 10:37 PM, Nick Sayer  wrote:
> 
> 
>> On Aug 30, 2016, at 8:48 PM, Cube Central  wrote:
>> 
>> I would be interested, I think.  Planning ahead for if the one I have for my 
>> Thunderbolt fails, I guess.  Are there different models or would a photo of 
>> the input ports on mine be useful?
> 
> Actually, what I had in mind is to just put a SIP4 header on the board for 
> the output and people could wire the “last mile” themselves. The input is a 
> 2.1mm barrel connector. You use whatever 15W 12VDC wall wart is handy and 
> plug it right in.
> 
> What it really amounts to is that you get +12 volts directly from the input, 
> then there’s a buck converter to drop the +12 down to +5 and an inverter to 
> generate -12 from the +12. Those 3 voltages, plus a ground go to the SIP4.
> 
> So it’s just two switching power supplies to turn a +12 volt only supply into 
> the three-way that the Thunderbolt wants.
> 
> It’d be good for around 1500 mA @ 5V and around 50 mA @ -12 (the +12 spec is 
> whatever is left from the source supply’s power spec) - more than enough for 
> a Thunderbolt. Probably enough for a hard disk or a smallish PC.
___
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

[Nick Sayer via time-nuts]

"Whereas other clocks fall victim to relativistic effects at high speeds, 
cesium clocks do not. The frequency remains the same, and so the time remains 
accurate.”

Well, to the wearer, it probably does. :)

It’s ironic they said that given that they flew cesium clocks in the 
Hafele–Keating experiment to demonstrate exactly those relativistic effects.

> On Oct 17, 2016, at 6:45 PM, Jim Palfreyman  wrote:
> 
> Well I think there's a mistake or two here...
> 
> https://www.inverse.com/article/20497-john-patterson-atomic-ce
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Moving GPSDO

[Nick Sayer via time-nuts]

Speaking for my GPSDOs specifically, you can’t disable the survey mode with the 
Venus838 receiver (well, you can, but it requires you to talk to the module 
with SkyTraq’s software, which requires disabling the GPSDO’s controller - 
possible to do, but annoying). I haven’t attempted to see what it would do if 
it were moved after the survey is completed (if you move during the survey, 
then the survey will fail and repeat).

The older GPSDOs that had PA6H receivers were navigation receivers that didn’t 
have a survey mode.

In either case, without a surveyed position, PPS stability will suffer if/when 
the constellation degrades due to poor reception, which can happen if, say, the 
unit is in a moving vehicle in interesting terrain. Poor PPS stability will 
have an impact on the PLL, obviously.

> On Oct 16, 2016, at 9:19 PM, Joseph Gray  wrote:
> 
> I'm curious to know how accurately a GPSDO will keep its 10 MHz output
> while moving. No initial survey to set a position would be done. I
> don't care about the UTC time.
> 
> Joe Gray
> W5JG
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] For those that insist on using switching power supplies

[Nick Sayer via time-nuts]

> On Oct 14, 2016, at 11:34 AM, Cube Central <cubecent...@gmail.com> wrote:
> 
> Nick, thanks for your detailed reply.  Would you happen to have a photo of 
> the "spring looking things?"  I am not entirely sure I have one of those 
> included with the kit that came with the scope.

I don’t have a picture, but the Internet does: 
http://i.stack.imgur.com/PSo3N.jpg

> What size of capacitor would you suggest?

Well, I use mostly 0805 MLCCs on my boards, not counting the occasional polymer 
or electrolytic.

> I happen to have the exact same dummy load that you do.  I have added on a 
> fan for higher current/longer use.
> 
> Thanks for the help, I look forward to trying out some of the measurements 
> that I've seen posted elsewhere ( such as this link: 
> http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab-apple-is.html ) 
> 
> Cheers!
> 
>   -Randal R.
>   (at CubeCentral)
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Nick Sayer 
> via time-nuts
> Sent: Friday, 14 October, 2016 12:17
> To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
> Subject: Re: [time-nuts] For those that insist on using switching power 
> supplies
> 
> Set your scope for AC coupling. Set your scope probe for 1x rather than 10x. 
> Use the absolutely shortest scope grounding you can. That’s what those spring 
> looking things that came with it are for. I typically use the spring gizmo 
> and probe on an SMD cap. The ground wire with an alligator clip will just 
> pick up far more noise than you’ll be measuring. This is how I was able to 
> measure the noise and ripple of the SC189Z switcher feeding the OCXO in my 
> GPSDO. I got measurements of ~4 mV P-P that way. Be careful you don’t get the 
> probe and ground reversed - your scope won’t likely have an isolated ground 
> from your DUT and that would therefore be bad.
> 
> You’re going to want to check the supply’s performance under load. For that, 
> you’ll may want to get yourself a dummy load. I got one from Tindie for 
> testing my Pi Power design: 
> https://www.tindie.com/products/arachnidlabs/reload-2/
> 
> 
> 
>> On Oct 14, 2016, at 11:00 AM, Cube Central <cubecent...@gmail.com> wrote:
>> 
>> How would one go about testing power supplies and seeing how noisy they are? 
>>  I have the standard suite of tools, an oscilloscope and a little 
>> (dangerous) know-how.  I am just not sure what to look for or how to safely 
>> hook it up to test.
>> 
>> Thanks in advance for any tips!  
>> 
>>  -Randal R.
>>  (at CubeCentral)
>> 
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Chris 
>> Albertson
>> Sent: Friday, 14 October, 2016 02:29
>> To: Discussion of precise time and frequency measurement 
>> <time-nuts@febo.com>
>> Subject: Re: [time-nuts] For those that insist on using switching 
>> power supplies
>> 
>> On Thu, Oct 13, 2016 at 6:05 AM, Van Horn, David 
>> <david.vanh...@backcountryaccess.com> wrote:
>>> To be fair here, phone chargers have almost no requirement to be quiet 
>>> other than conducted and radiated emissions limits.
>>> It's charging a battery.
>> 
>> Not only that but,  the 5 volts comping out of the larger is almost 
>> certainly the input to another DC/DC power supply and NOT used directly.
>> You can't charge a Lithium battery with the 5 volts the charger outputs.
>> 
>> If you don't know about LiPo batteries, they need a constant current power 
>> source and then as they get close to charged the charger switches to 
>> constant voltage (VERY roughly) at about 4V per cell.
>> 
>> I have a project right here on my desk as I type.  I'm using the output of a 
>> generic USB hub.  The circuit is  a cap from 5V to GND and
>> then a low dropout regulator to get 3.3 volts.I don't care to much
>> if there is huge ripple on the 5.0 volts coming in as long as it stays above 
>> the LDO limit.
>> 
>> Also it looks like they tested the USB chargers with no load.  A typical 
>> load might have a say, 0.01uf cap to short the noise to ground.  So in use 
>> the power might be better?
>> 
>> It was no surprise the counterfeit chargers were horrible.  The 
>> manufacturers are by definition of "counterfeit" being dishonest slim balls. 
>> Why would he care about anything other then that he can fool
>> some people into buying his product.   There are third party chargers
>> that are not trying to copy a well known bra

Re: [time-nuts] For those that insist on using switching power supplies

[Nick Sayer via time-nuts]

Set your scope for AC coupling. Set your scope probe for 1x rather than 10x. 
Use the absolutely shortest scope grounding you can. That’s what those spring 
looking things that came with it are for. I typically use the spring gizmo and 
probe on an SMD cap. The ground wire with an alligator clip will just pick up 
far more noise than you’ll be measuring. This is how I was able to measure the 
noise and ripple of the SC189Z switcher feeding the OCXO in my GPSDO. I got 
measurements of ~4 mV P-P that way. Be careful you don’t get the probe and 
ground reversed - your scope won’t likely have an isolated ground from your DUT 
and that would therefore be bad.

You’re going to want to check the supply’s performance under load. For that, 
you’ll may want to get yourself a dummy load. I got one from Tindie for testing 
my Pi Power design: https://www.tindie.com/products/arachnidlabs/reload-2/



> On Oct 14, 2016, at 11:00 AM, Cube Central  wrote:
> 
> How would one go about testing power supplies and seeing how noisy they are?  
> I have the standard suite of tools, an oscilloscope and a little (dangerous) 
> know-how.  I am just not sure what to look for or how to safely hook it up to 
> test.
> 
> Thanks in advance for any tips!  
> 
>   -Randal R.
>   (at CubeCentral)
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Chris 
> Albertson
> Sent: Friday, 14 October, 2016 02:29
> To: Discussion of precise time and frequency measurement 
> Subject: Re: [time-nuts] For those that insist on using switching power 
> supplies
> 
> On Thu, Oct 13, 2016 at 6:05 AM, Van Horn, David 
>  wrote:
>> To be fair here, phone chargers have almost no requirement to be quiet other 
>> than conducted and radiated emissions limits.
>> It's charging a battery.
> 
> Not only that but,  the 5 volts comping out of the larger is almost certainly 
> the input to another DC/DC power supply and NOT used directly.
> You can't charge a Lithium battery with the 5 volts the charger outputs.
> 
> If you don't know about LiPo batteries, they need a constant current power 
> source and then as they get close to charged the charger switches to constant 
> voltage (VERY roughly) at about 4V per cell.
> 
> I have a project right here on my desk as I type.  I'm using the output of a 
> generic USB hub.  The circuit is  a cap from 5V to GND and
> then a low dropout regulator to get 3.3 volts.I don't care to much
> if there is huge ripple on the 5.0 volts coming in as long as it stays above 
> the LDO limit.
> 
> Also it looks like they tested the USB chargers with no load.  A typical load 
> might have a say, 0.01uf cap to short the noise to ground.  So in use the 
> power might be better?
> 
> It was no surprise the counterfeit chargers were horrible.  The manufacturers 
> are by definition of "counterfeit" being dishonest slim balls. Why would he 
> care about anything other then that he can fool
> some people into buying his product.   There are third party chargers
> that are not trying to copy a well known brand, these are usually much better
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts 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] For those that insist on using switching power supplies

[Nick Sayer via time-nuts]

> On Oct 13, 2016, at 6:05 AM, Van Horn, David 
>  wrote:
> 
> To be fair here, phone chargers have almost no requirement to be quiet other 
> than conducted and radiated emissions limits.
> It’s charging a battery.

Not quite. They power the device in question *while* they’re charging the 
battery. Now, I’ll admit that powering a phone is a much lower bar than 
powering, say, an audio amplifier, but I’d also say that some of the devices on 
that page were pumping out way more garbage than even any digital system should 
have to put up with.


> 
> As a designer of some fairly quiet SMPS systems, this feels like “look how 
> bad a family car this tractor is".

Well, there’s some of that, but the worst offenders were counterfeit devices 
that were pumping out unreasonable levels. To your analogy, they were the outer 
shell of a family car with a the engine from an Edsel installed in it without a 
muffler or any emissions controls fed from an open bucket of gasoline sitting 
on the passenger’s seat.

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

Re: [time-nuts] New PPB rated TCXO

[Nick Sayer via time-nuts]

The video linked on that page is particularly interesting (if you take it on 
face value that they're not faking it. ;) ).

Sent from my iPhone

> On Oct 10, 2016, at 8:03 AM, Robert LaJeunesse  wrote:
> 
> For general group information, as SiTime datasheet is not open to the public 
> (yet?).
> 
> https://www.sitime.com/products/precision-super-tcxo
> 
> Actually a MEMS oscillator, comparison video against quartz TCXO is 
> interesting.
> 
> Claimed Key Features:
> - 30x better dynamic performance for macro cells, small cells, syncE and 
> optical networks
> - 3e-11 Allan Deviation (ADEV)
> - 0.2 ps/mv PSNR, eliminating dedicated LDO
> - No activity dips or microjumps
> - 10x better dynamic stability, replacing OCXOs in IEEE 1588 applications
> - 1 to 5 ppb/°C frequency over temperature slope
> - -40°C to +105°C operation uniquely enables fan-less outdoor equipment 
> - 20x greater vibration resistance ensures continuous system operation
> 
> Frequency range 1MHz to 220MHz (via 2 product types) so some form of 
> synthesizer/divider is inherent.
> 
> Bob L.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Venus838LPx-T PPS stability measurements

[Nick Sayer via time-nuts]

As a control, I repeated the test with a GlobalTop PA6H module.


Again, the reference is a Thunderbolt, so it’s not completely clear how much of 
the wander to attribute to the reference and how much to the DUT. The residual 
this time is on the order of 60ns - still surprisingly high. The DUT is an 
AdaFruit ultimate GPS module with its PPS pin directly connected to the TIA’s 
input.

Removed from this dataset were two brief periods where the phase showed E+38 
errors - probably missing PPS pulses. I’ve noticed that there are 
sidereal-daily periods where the PA6H would lose its tiny little mind briefly. 
On the plus side, the module has the good taste to indicate this by dropping 
from 3D fix to 2D for the duration. My GPSDOs were able to use that to drop 
down one “mode” level and reestablish a good lock more quickly.

If you zoom in to the data, there are hanging bridges to be found:



And more critically, there is no sawtooth correction data that could be had to 
avoid them. GlobalTop’s sales literature claims that timing firmware is 
available, but I don’t have any information about availability or the potential 
to upgrade existing modules.

Still, the ADEV is nearly the same as the Venus838. Slightly better at lower 
tau, likely because it lacks the extreme excursions I found on that module.

Just in case the graphs don’t come through this time, I’ll save them to 
http://www.kfu.com/~nsayer/PA6H-graphs.zip

___
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] Venus838LPx-T PPS stability measurements

[Nick Sayer via time-nuts]

Buh…

No graphs?

Um… “I’m a little teapot, short and stout…” :)

I’ll link it here instead:

http://www.kfu.com/~nsayer/Venus838LPx-T_graphs.zip

> On Oct 7, 2016, at 7:46 AM, Nick Sayer via time-nuts <time-nuts@febo.com> 
> wrote:
> 
> This is a bit overdue, but I finally got around to making at least an attempt 
> to measure the stability of the Venus838LPx-T timing module’s PPS stability.
> 
> The results are a bit of a mixed bag.
> 
> The module under test is one built into one of my OH300 GPSDOs. It’s inside 
> of a closed chassis, mounted about a half inch away from an OCXO, sitting on 
> my workbench inside an unconditioned garage. My guess is that over the course 
> of the test the ambient temperature varied by perhaps 15°F. The PPS output of 
> the module - as well as being fed into the controller and PLL - is fed into a 
> buffer before being presented on the diagnostic port. From there, it went 
> straight into input 1 of my 53220A. Input 2 came from the PPS output of a 
> Thunderbolt. The 53220A’s 10 MHz reference comes also from that same 
> Thunderbolt. No effort has been made to apply the sawtooth corrections 
> indicated by the PSTI,00 sentences. Both receivers are fed from the same 
> antenna and splitter. Reception is nearly ideal, with the Thunderbolt having 
> 7 or 8 satellites at all times, most of them with S:N > 45.
> 
> The first surprise is that although both PPS signals are ostensibly synced 
> with GPS, there’s a 135 ns residual between the two. The residual (after ~15 
> hours or so) has a ~2E-13 slope. This graph is the phase difference with that 
> residual removed.
> 
> 
> 
> There are three variances visible. Firstly, there’s about a ±6ns “fuzz” 
> around the center on almost all samples. That can be explained by the 
> quantization error indicated in the NMEA output. Plotting those errors shows 
> a similar fuzz with a range of ±6 ns. Secondly, there’s a much slower wander 
> that’s mostly confined to a ±10 ns corridor. I attribute this to GPS itself. 
> How much of the wandering is due to which receiver is something I haven’t 
> attempted to figure out. Running this test with an undisciplined rubidium 
> oscillator might help, but the short term stability of the 5680A isn’t very 
> good, so I didn’t want to make it the first test standard.
> 
> The third variance is more serious. Periodically the variance is much larger 
> - sometimes ±25ns or even more. These variances are not accounted for in the 
> sawtooth correction values. The only good thing that can be said about them 
> is that they’re fairly well balanced and can be easily averaged out.
> 
> If you take a closer look at one, they sometimes appear adjacent to hanging 
> bridges:
> 
> 
> 
> This isn’t always the case, but it’s often enough to potentially be more than 
> coincidence.
> 
> All that said, I believe the resulting ADEV is in line with expectations for 
> a GPS receiver:
> 
> 
> 
> 
> I’ve made an inquiry with SkyTraq to ask about the excessive excursions. I’ll 
> report back what their answer is. Given that the excursions are easily 
> averaged away, and given how inexpensive these modules are, I’m not bent out 
> of shape about it. And if it’s something SkyTraq can figure out how to update 
> in the firmware to report in their QE messages (so that it can be corrected 
> for externally), I won’t mind at all.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

[time-nuts] Venus838LPx-T PPS stability measurements

[Nick Sayer via time-nuts]

This is a bit overdue, but I finally got around to making at least an attempt 
to measure the stability of the Venus838LPx-T timing module’s PPS stability.

The results are a bit of a mixed bag.

The module under test is one built into one of my OH300 GPSDOs. It’s inside of 
a closed chassis, mounted about a half inch away from an OCXO, sitting on my 
workbench inside an unconditioned garage. My guess is that over the course of 
the test the ambient temperature varied by perhaps 15°F. The PPS output of the 
module - as well as being fed into the controller and PLL - is fed into a 
buffer before being presented on the diagnostic port. From there, it went 
straight into input 1 of my 53220A. Input 2 came from the PPS output of a 
Thunderbolt. The 53220A’s 10 MHz reference comes also from that same 
Thunderbolt. No effort has been made to apply the sawtooth corrections 
indicated by the PSTI,00 sentences. Both receivers are fed from the same 
antenna and splitter. Reception is nearly ideal, with the Thunderbolt having 7 
or 8 satellites at all times, most of them with S:N > 45.

The first surprise is that although both PPS signals are ostensibly synced with 
GPS, there’s a 135 ns residual between the two. The residual (after ~15 hours 
or so) has a ~2E-13 slope. This graph is the phase difference with that 
residual removed.



There are three variances visible. Firstly, there’s about a ±6ns “fuzz” around 
the center on almost all samples. That can be explained by the quantization 
error indicated in the NMEA output. Plotting those errors shows a similar fuzz 
with a range of ±6 ns. Secondly, there’s a much slower wander that’s mostly 
confined to a ±10 ns corridor. I attribute this to GPS itself. How much of the 
wandering is due to which receiver is something I haven’t attempted to figure 
out. Running this test with an undisciplined rubidium oscillator might help, 
but the short term stability of the 5680A isn’t very good, so I didn’t want to 
make it the first test standard.

The third variance is more serious. Periodically the variance is much larger - 
sometimes ±25ns or even more. These variances are not accounted for in the 
sawtooth correction values. The only good thing that can be said about them is 
that they’re fairly well balanced and can be easily averaged out.

If you take a closer look at one, they sometimes appear adjacent to hanging 
bridges:



This isn’t always the case, but it’s often enough to potentially be more than 
coincidence.

All that said, I believe the resulting ADEV is in line with expectations for a 
GPS receiver:




I’ve made an inquiry with SkyTraq to ask about the excessive excursions. I’ll 
report back what their answer is. Given that the excursions are easily averaged 
away, and given how inexpensive these modules are, I’m not bent out of shape 
about it. And if it’s something SkyTraq can figure out how to update in the 
firmware to report in their QE messages (so that it can be corrected for 
externally), I won’t mind at all.

___
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] Need Time Help

[Nick Sayer via time-nuts]

To be fair, this is at least partly because asking a relatively simple question 
here routinely turns into a dissertation defense.

> On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> 
> Hi
> 
> That’s very typical in a lot of forums. The OP tosses up a question and then 
> pretty much vanishes. 
> My observation is that roughly 80% of the “I have a question” threads work 
> that way. 
> I’ve never been able to figure out if it is an expectation that all answers 
> will arrive in an hour or two 
> or if the OP is simply reading along and sees no reason to providing more 
> information to the group.
> Either way, I’m pretty sure that the focus of the answers is not all that 
> great a week after the last input.  
> 
> Bob

___
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] ADC sample voting algorithm?

[Nick Sayer via time-nuts]

> On Oct 5, 2016, at 5:00 PM, Bob Camp  wrote:
> 
> Hi
> 
> What does the signal you are sampling look like? 

The last time I actually looked (it was a while ago), it looked reasonable as 
closely as I could look, but the ADC resolution is something like 1mV per LSB, 
and I’m not sure I looked that closely.

> 
> Does it (maybe) have a bit of noise on it?
> 
> If it is the output of a “normal” TDC, then the answer is to sample once.

I dunno about a “normal” one… This one is the one I got from Jim Harman. The 
phase difference between the divided-by-10 output and PPS goes through a diode, 
JFET and then an RC (with a much higher discharge resistor).

As long as you sample at least 1 µs after the PPS (and it takes at least that 
long to get into the ISR anyway), it *ought* to be stable for dozens of µs.

That’s kind of why I’m going down the road of multiple samples - to see if 
there’s anything to it.


___
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] ADC sample voting algorithm?

[Nick Sayer via time-nuts]

> On Oct 5, 2016, at 4:52 PM, Bob Stewart <b...@evoria.net> wrote:
> 
> Hi Nick,
> 
> Are you applying sawtooth correction to your phase measurement? 

Yes, these are post-correction observations. I have some confidence that my 
corrections are scaled appropriately for the ADC values because of their 
stability “most” of the time (meanwhile, the uncorrected values are bouncing 
around inside a 12 ns corridor).

> If not, are you merely seeing a hanging bridge that dissolves into at a 
> normal sort of tick-tock movement?
> 
> Bob
> 
> From: Nick Sayer via time-nuts <time-nuts@febo.com>
> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
> Sent: Wednesday, October 5, 2016 6:45 PM
> Subject: [time-nuts] ADC sample voting algorithm?
> 
> This is tangentially on topic, I suppose. It’s for my GPSDO.
> 
> I notice periodically that the phase measurements seem “noisy.” You can see 
> that over the course of several seconds the value doesn’t change, then it 
> jumps a bunch and then comes right back.
> 
> My theory at the moment is that sampling the ADC multiple times in a row 
> might help, but then what’s the best way to (quickly) pick which sample to 
> use?
> 
> The mean would allow a bad sample undue influence.
> 
> At the moment, I’ve coded taking 3 samples, averaging them and picking the 
> sample that is closest to the mean. If I’m right, and two of the samples 
> happen to be very close to each other and a third is an outlier, then that 
> seems like it would eliminate it.
> 
> I guess what I want is the mode, but with 3 samples, that’s going to be 
> poorly defined (if at all).
> 
> Anyone have any suggestions (besides a larger sample size)?
> ___
> time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@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.
> 
> 

___
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] ADC sample voting algorithm?

[Nick Sayer via time-nuts]

This is tangentially on topic, I suppose. It’s for my GPSDO.

I notice periodically that the phase measurements seem “noisy.” You can see 
that over the course of several seconds the value doesn’t change, then it jumps 
a bunch and then comes right back.

My theory at the moment is that sampling the ADC multiple times in a row might 
help, but then what’s the best way to (quickly) pick which sample to use?

The mean would allow a bad sample undue influence.

At the moment, I’ve coded taking 3 samples, averaging them and picking the 
sample that is closest to the mean. If I’m right, and two of the samples happen 
to be very close to each other and a third is an outlier, then that seems like 
it would eliminate it.

I guess what I want is the mode, but with 3 samples, that’s going to be poorly 
defined (if at all).

Anyone have any suggestions (besides a larger sample size)?
___
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] Lady Heather on MacOS X

[Nick Sayer via time-nuts]

Sorry if this is old hat, but I don’t remember seeing it go by.

I just went through the exercise of getting Lady Heather working on MacOS X.

It’s not a Quartz port - you have to install and run XQuartz for it to work.

One patch to heather.ch was needed:

Right below the include of fcntl.h:

#ifndef SOCK_NONBLOCK
#define SOCK_NONBLOCK O_NONBLOCK
#endif

And then this Makefile:

CFLAGS+= -I/opt/X11/include -D__linux__ -Wno-write-strings
LFLAGS+= -L/opt/X11/lib 

all: heather

heather.o: heather.cpp heather.ch heathfnt.ch makefile
g++ $(CFLAGS) -c heather.cpp

heathmsc.o: heathmsc.cpp heather.ch heathfnt.ch makefile
g++ $(CFLAGS) -c heathmsc.cpp

heathui.o: heathui.cpp heather.ch heathfnt.ch makefile
g++ $(CFLAGS) -c heathui.cpp

heathgps.o: heathgps.cpp heather.ch heathfnt.ch makefile
g++ $(CFLAGS) -c heathgps.cpp

heather: heather.o heathmsc.o heathui.o heathgps.o
g++ $(LFLAGS) heather.o heathui.o heathgps.o heathmsc.o -o heather -lm 
-lX11

clean:
rm heather.o heathui.o heathgps.o heathmsc.o heather


___
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] Schematic needed

[Nick Sayer via time-nuts]

I don’t know about that particular one, but I designed an equivalent board and 
was selling it on Tindie a little while ago. I replaced it with a full-on GPS 
discipline board that powers and trims the 5680 from GPS. But if all you want 
is the power part of it, I still have the design for the simpler breakout 
board. It takes anything from 18-24 VDC in (I like to use surplus laptop power 
supplies) at 30W+ and makes the +15 and +5 supplies with two buck converters. 
It also has a self biased inverter and clock fan-out chip on board to give you 
four independent square wave outputs. I kinda think the GPS version is nicer, 
though.

> On Oct 2, 2016, at 1:21 AM, Joseph Gray  wrote:
> 
> Can someone send me the schematic for this:
> 
> https://www.febo.com/pipermail/time-nuts/2012-January/062616.html
> 
> I looked through the list archives but didn't find the schematic
> posted anywhere.
> 
> 
> Joe Gray
> W5JG
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] A new take on the all-hardware GPSDO concept

[Nick Sayer via time-nuts]

At the risk of inviting everyone to say “I told you so,” I’ll report here my 
experimental results from trying this concept out.

Since there was a great deal of doubt about the outcome, I hedged my bet a bit 
and designed for the DOT050V rather than the OH300. If it worked out for the 
TCXO, then I could try with the more expensive one.

The results aren’t very good.

With a short TC loop filter, the PLL does lock up, but obviously the jitter of 
the Venus’ 10 MHz output comes through.

With a longer TC, the PLL never locks - or at least if it does lock, it’s 
locking significantly off frequency.

That’s with a 10 µF cap and varied resistors between 10k and 1M. The best I got 
was at 200k - a TC of 2s. That resulted in this video. Unlike other videos I’ve 
made comparing two GPSDOs, this one is not a time-lapse. The reference is an 
OH300 based GPSDO.

https://www.youtube.com/watch?v=hiHRp0dCJ64 


A time constant of 10s (1M resistor) just doesn’t work at all.

But the real nail in the coffin here is that the price of the PLL chip is still 
more expensive than the microcontroller and all of the components it replaces.

In the end, I’m glad I tried, but I don’t think I’m going to invest any more 
time in the design. I could try configuring the venus for a 10 kHz output and 
see if it’s better able to phase lock with a divided TCXO output, but I don’t 
think I have any reason to believe that would be more likely to succeed.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] A new take on the all-hardware GPSDO concept

[Nick Sayer via time-nuts]

> On Sep 16, 2016, at 1:13 PM, Lars Walenius  wrote:
> 
> 
> 
> My experience with the Venus838-T is only 2 weeks but disappointing. This can 
> also be guessed from the datasheet ADEV curve, that I guess is sawtooth 
> corrected values as it starts at 3E-9 at 1s, but is only 1E-11 at 1000s a 
> factor 10 worse than I get with the LEA-6T with the same antenna and setup. 
> If anyone have ADEV-MDEV curves to share I would be glad to see what can be 
> achieved with the venus838-T. My conclusion is also that sawtooth correction 
> is useless on my 838-T.

Are you talking about the PPS output or the frequency output (10 MHz by 
default)?

I haven’t attempted to get ADEV plots of the PPS output mainly because I’m not 
sure the best experimental setup. 

I could (try to) capture time differences between the PPS output of a 
thunderbolt and the PPS output of the Venus, but would taking the ADEV of that 
give correct results?

> 
> Lars
> 
> 
>> Nick wrote:
> 
>> Jim Miller's 10 kHz GPSDO that’s been referenced here has either solved this 
>> problem, or the 10 kHz output of the >Jupiter is substantially better than 
>> the Venus’ 10 MHz output, or the design doesn’t give the results time-nuts 
>> expect >from a GPSDO. Which of those applies?
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] A new take on the all-hardware GPSDO concept

[Nick Sayer via time-nuts]

> On Sep 12, 2016, at 1:27 PM, Charles Steinmetz  wrote:
> 
> Tim wrote:
> 
>> You know Nick, the loop time constant typically used with the HMC1031 loop
>> filter is typically 5 milliseconds. I'm sure some bigger R's and C's can
>> used for a longer time constant, and I'm sure that'll help clean up the
>> awful 10MHz output of the Venus838LPx-T. But it is hardly what I'd call a
>> "GPSDO".
> 
> One point that may not be obvious to people thinking of designing GPSDOs is 
> this:  The requirement for a very long time constant control loop (hundreds 
> to thousands of seconds) has nothing to do with the frequency of the 
> reference signal from the GPS (that is, it is not due to the reference being 
> a 1PPS signal).  Rather, it is determined by the tau at which the stability 
> of the GPS signal becomes better than the stability of the local oscillator 
> (generally an OCXO).  Unless the designer chooses a very bad local 
> oscillator, this will be in the region of tau = 100-10kS (maybe only 20-50S 
> if using a TCXO instead of an OCXO).
> 
> The stability of any higher-frequency signal from a GPS that does not have a 
> disciplined, high-stability LO (e.g., 10kHz in the case of the obsolete 
> Navman Jupiter GPS receivers, or 10MHz in the case of the Venus) will be no 
> better than the stability of the PPS, so the high-stability local oscillator 
> you add will still need to be disciplined with the same slow loop you would 
> use with PPS discipline if you want the sort of results time-nuts expect from 
> a GPSDO.

Ok. Is it the case that the loop filter bandwidth is related to the time 
constant? Are there methods for minimizing the loop filter bandwidth that might 
be useful here? I would hazard a guess that obtaining >100s of TC equivalent in 
pure hardware would be at best difficult. At the same time, it seems like 
having a microcontroller act as an averager in software between an ADC and a 
DAC would be just silly.

Jim Miller's 10 kHz GPSDO that’s been referenced here has either solved this 
problem, or the 10 kHz output of the Jupiter is substantially better than the 
Venus’ 10 MHz output, or the design doesn’t give the results time-nuts expect 
from a GPSDO. Which of those applies?

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

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

Re: [time-nuts] A new take on the all-hardware GPSDO concept

[Nick Sayer via time-nuts]

> On Sep 12, 2016, at 1:01 PM, Bob Camp <kb...@n1k.org> wrote:
> 
> Hi
> 
> The noise performance of the HMC1031 close in is pretty horrible. It’s 
> actually *worse* than the GPS signal noise. In a normal GPSDO the idea is to 
> use an oscillator that is cleaner at 0.01 to 10 Hz than the GPS. 

I don’t see where you get that.

To generate the phase noise figures (8,9,11,12) they used a Crystek CVHD-950. I 
don’t think it necessarily follows that a better quality OCXO can’t do better 
than that, does it?

> 
> Bob
> 
> 
>> On Sep 12, 2016, at 2:41 PM, Nick Sayer via time-nuts <time-nuts@febo.com> 
>> wrote:
>> 
>> I was talking with someone at AD about a question I had about one of their 
>> TinyDACs when they mentioned their HMC1031 chip. It looks like the ideal 
>> building block for a clean-up oscillator.
>> 
>> It struck me just a touch later that the Venus838LPx-T has by default a 10 
>> MHz output that’s phase locked to GPS time. It’s not good quality, but I 
>> wonder if it’s good enough to be the reference for this particular chip. 
>> They do talk about the ability to be driven by a “noisy” or "jittery” 
>> reference.
>> 
>> I think I’m going to take a crack at an OH300 GPSDO based on this design 
>> concept. Actually, first I’m going to actually try to quantify the jitter on 
>> the 10 MHz output from the Venus. From the HMC1031 datasheet it appears that 
>> if it’s not confined to a ±3 ns corridor that the lock indicator may not 
>> work (or work well). That would be a bummer.
>> 
>> I can foresee a GPSDO with the miniDIN 4 jack presenting the PPS and serial 
>> I/O from the GPS module and two LEDs on the front - the “FIX” LED from the 
>> GPS module and the lock LED from the PLL along with two BNC jacks. It would 
>> have some downsides. For one, I believe in the absence of GPS reception, it 
>> wouldn’t be able to properly hold-over at all. But it’ll be interesting to 
>> see if it can work as well as the micro-controller driven variant does.
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 

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

[time-nuts] A new take on the all-hardware GPSDO concept

[Nick Sayer via time-nuts]

I was talking with someone at AD about a question I had about one of their 
TinyDACs when they mentioned their HMC1031 chip. It looks like the ideal 
building block for a clean-up oscillator.

It struck me just a touch later that the Venus838LPx-T has by default a 10 MHz 
output that’s phase locked to GPS time. It’s not good quality, but I wonder if 
it’s good enough to be the reference for this particular chip. They do talk 
about the ability to be driven by a “noisy” or "jittery” reference.

I think I’m going to take a crack at an OH300 GPSDO based on this design 
concept. Actually, first I’m going to actually try to quantify the jitter on 
the 10 MHz output from the Venus. From the HMC1031 datasheet it appears that if 
it’s not confined to a ±3 ns corridor that the lock indicator may not work (or 
work well). That would be a bummer.

I can foresee a GPSDO with the miniDIN 4 jack presenting the PPS and serial I/O 
from the GPS module and two LEDs on the front - the “FIX” LED from the GPS 
module and the lock LED from the PLL along with two BNC jacks. It would have 
some downsides. For one, I believe in the absence of GPS reception, it wouldn’t 
be able to properly hold-over at all. But it’ll be interesting to see if it can 
work as well as the micro-controller driven variant does.
___
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] ke5fx.com - something's up

[Nick Sayer via time-nuts]

I tried to look for Lady Heather docs today, but it appears like the ke5fx 
domain is… funky.

The name servers are NS1.PENDINGRENEWALDELETION.COM and there are other 
indications that maybe the domain lapsed…?
___
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] Anybody want a Thunderbolt power supply?

[Nick Sayer via time-nuts]

When I began the design process, I assumed - as would be reasonable - that ~30 
mV P-P of noise and ripple were acceptable for input power supplies, and that 
before they were used for a precision purpose within the device that there 
would be further filtering if for no other reason that you’d think they’d want 
to limit coupled interference on the power lines. My assumption, given the 
extremely low draw on the -12 line was that they were using the -12 line just 
for the RS-232 level shifter (and that they were too lazy to use a MAX232 like 
everybody else).

Now that I’ve posted and had my assumptions disabused, I’ll need to go back to 
the drawing board for another attempt. The price point won’t likely be $25 
anymore, but the question was whether anyone wanted a Tbolt power supply, and 
if I offer anything at all, I intend for it to be reasonably useful for its 
intended purpose. Like all the things I make for sale, it will be open 
hardware, which will afford everyone here more than enough opportunity for 
Monday morning quarterbacking. :)


> On Aug 31, 2016, at 4:02 PM, Charles Steinmetz  wrote:
> 
> Bob wrote:
> 
>> I don't mean to cause offense, but is everything you don't like crap?  The 
>> reality is that whatever the market will bear is what determines what comes 
>> to market.  If you can find high quality goods on ebay that can be modified 
>> to fit your needs, then you win.  There is a substantial market that either 
>> cannot do those mods or would rather spend their time elsewhere.  So, what 
>> they're willing to pay is going to determine what's available for sale.
> 
> No, but I often view things that don't do the job they need to do as crap, 
> especially if they are offered in such a way as to suggest that they are, in 
> fact, useful for the intended purpose.  So, let's take the proposed power 
> supply -- a switching regulator to develop +5v and -12v supplies from an 
> existing +12v supply, with noise of 35mVp-p, offered specifically as a power 
> supply solution for Tbolt GPSDOs.  If the offering said explicitly that a 
> Tbolt can't provide its best performance with the product because of its high 
> noise level, then I might be on the fence about whether it was "crap."  But 
> if it were offered as a power supply for Tbolts with no mention of what I 
> consider to be a large departure from acceptable performance for the intended 
> use, then yes, I'd probably consider it "crap."
> 
> The issue is that many users do not know what the relevant needs are. Rightly 
> or wrongly, they are relying on suppliers to do that job for them.  So, 
> offering something for a particular use carries the implication that it is 
> really useful for that purpose.  If a seller tells a time-nut that a power 
> supply is designed to run a Tbolt, an implicit representation has been made 
> that it will work in that role as a time-nut would expect it to.  But IMO, 
> the proposed product would not do so because of the high noise level.
> 
> So, what distinguishes this from packages that have been sold to time-nuts in 
> the past that included power supplies that also did not work in that role as 
> a time-nut would expect?  In those cases, due largely to this list, there was 
> widespread discussion of the issue and equally widespread knowledge that for 
> time-nuts-quality results, the PS that came with the package needed to be 
> replaced with something better.  So at this point, if someone offers a PS to 
> time nuts for use with Tbolts, it would be natural to assume that the seller 
> was familiar with that history and was offering the "something better."  So 
> today, if that is *not* the case, it should be stated explicitly.
> 
> Best regards,
> 
> Charles
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Anybody want a Thunderbolt power supply?

[Nick Sayer via time-nuts]

> On Aug 30, 2016, at 9:26 PM, Mark Sims  wrote:
> 
> The -12V is used to drive the RS-232 signals... it also eventually gets to 
> the EFC dac so it can swing below ground.   Also, the +12V gets to the DAC.   
> Pay close attention to generating noise on these lines.

I’ve designed a prototype. I’ll provide noise and ripple measurements when I 
get the first boards back. I’m going to shoot for <= 35 mV P-P. If you need 
better than that, then it probably turns into a hybrid switching+linear system, 
which would be more expensive. It’s been a while since I looked, but I believe 
that’s what I was able to achieve with the supplies for the FE-5680A GPS 
discipline board.

> 
> Also, when I did Lady Heather's temperature control PID (with great help from 
> Warren Sarkison) I did some  measurements on the effects of temperature on 
> the system with only the tbolt under temperature control and also with both 
> the power supply (the brick supplied with the original TAPR orders) and the 
> tbolt temperature stabilized.  It seems about 1/4 to 1/3  of the temperature 
> sensitivity of the system could be attributed to the power supply and the 
> rest came from the oscillator/tbolt.  Some attention to the tempco of the 
> power supply would be a good thing.

I’ve not made any efforts along those lines to start with. For one, the input 
is +12 V and is simply passed through as the +12 volt output (there is a TVS 
and cap on the input, however). Given that the Thunderbolt that I have on loan 
came with what I can only guess was once a laptop power supply, I started off 
thinking the bar was pretty low.

If you want the hybrid approach, then adding the temperature compensation to 
the linear regulators would clearly be the way to go.

___
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] Anybody want a Thunderbolt power supply?

[Nick Sayer via time-nuts]

A little board to generate -12 and +5 from a 15 watt 12 VDC input wouldn’t be 
too hard to design. If I put one out for $25, would anyone like one?
___
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 - probably a stupid question.

[Nick Sayer via time-nuts]

Well, on a practical level, if you update the EFC that frequently then the DAC 
change glitches will dominate the actual output even if you’re not actually 
moving the needle much. 


> On Aug 17, 2016, at 2:53 PM, Bob kb8tq <kb...@n1k.org> wrote:
> 
> Hi
> 
> You can update the EFC a billion times a second.  Update rate and bandwidth 
> are not the same thing. If you want good ADEV, the loop better not have a 
> bandwidth greater than 0.01 Hz. GPS ADEV is pretty awful at 1 and 10 seconds. 
> It is starts to be good past a few thousand seconds. Yes, older modules are a 
> bit worse than newer ones. Also sawtooth correction can make things a bit 
> better.
> 
> Bob
> 
> Sent from my iPad
> 
>> On Aug 17, 2016, at 2:51 PM, Nick Sayer via time-nuts <time-nuts@febo.com> 
>> wrote:
>> 
>> Updating the EFC more quickly reduces the ADEV, though. I find that the 
>> fiddly part of tuning a GPSDO design is balancing the ADEV against phase 
>> control. If you want keep an iron fist on the phase, you can only do so by 
>> constantly swatting around the frequency.
>> 
>> I won't say that getting more frequent phase feedback is a bad thing, but if 
>> you're trying to get the PLL time constant to be longer rather than shorter 
>> that it won't help a lot. 
>> 
>> Sent from my iPhone
>> 
>>> On Aug 17, 2016, at 9:57 AM, Peter Reilley <preilley_...@comcast.net> wrote:
>>> 
>>> You can get crystal oscillators that have a frequency control signal and 
>>> are more
>>> stable than the run of the mill oscillators.   Changing the GPS oscillator 
>>> would
>>> require modifying a very tightly populated circuit board.   Perhaps not 
>>> possible.
>>> 
>>> What about some of the SDR (software defined radio) projects that aim to
>>> implement GPS functionality?   If you used the GPS chipping rate (1.023 MHz)
>>> to dicipline the 10 MHz oscillator then you are less sensitive to crystal 
>>> instabilities.
>>> You are updating the crystal one million times a second rather than once 
>>> per second.
>>> This is assuming that the chipping rate of the transmitter is just as good 
>>> as the
>>> 1 PPS signal.   This info from here;
>>> https://www.e-education.psu.edu/geog862/node/1753
>>> and here;
>>> https://en.wikipedia.org/wiki/GPS_signals
>>> 
>>> Even using the 50 bits/sec data rate of the GPS signal would allow updating 
>>> the
>>> GPSDO faster than the 1 PPS signal.
>>> 
>>> Pete.
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to 
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.

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

Re: [time-nuts] Venus838LPx-T preliminary testing

[Nick Sayer via time-nuts]

I had an opportunity to examine the P1PS2 pin’s output from the Venus838LPx-T. 
By default it’s a 10 MHz output nominally phase locked to GPS time. It didn’t 
take more than a second of looking at it on the scope to discover that it’s 
jittery as hell. My guess is that they’re synchronizing its leading edge once a 
second (or once in a while?) and letting it free-run from there and then 
correcting it with a sledgehammer at the next opportunity.

Certainly it’s not usable as a frequency standard on its own. However, for 
those who had been using James Miller’s GPSDO design with the 10 kHz output 
from a Jupiter, there might be something here. I wonder if simply adding a 
cleanup oscillator to the default output might yield results that were good 
enough. If not, you likely can configure the output to be 10 kHz instead of 10 
MHz and then it would be a drop-in replacement. I’ve not (yet) investigated 
configuring this module for non-default behavior.

I think I’ll stick with the design I’ve got, but these modules might represent 
an alternative to the Jupiter.
___
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] Heathkit clock available

[Nick Sayer via time-nuts]

> On Aug 10, 2016, at 4:01 PM, David <davidwh...@gmail.com> wrote:
> 
> On Wed, 10 Aug 2016 16:55:39 -0400, you wrote:
> 
>> On 8/10/2016 11:31 AM, Nick Sayer via time-nuts wrote:
>>> Frankly, I don’t know why they didn’t make it a GPS clock. That would truly 
>>> be a worthy successor to the GC-1000. Well, I do suspect I know why
> and it’s not flattering. :)
>> 
>> As I recall ( At 70 my memory is not quite as accurate as it used to be) 
>> by the time GPS was a main stream reality Heath was well on it's way to 
>> getting out of the KIT business and was more focused on the educational 
>> market
> 
> That is how I remember it.  The first consumer level handheld GPS
> receivers I ran across were the single channel Magellan units after
> 1989 and Heathkit was all but dead by then although they did not
> officially stop producing kits until 1992.  The Heathkit outlet store
> was not far from where I lived then and I tracked the progress of
> Heathkit by observing its condition.
> 
> Given the cost of the GPS receivers, I can see why a GPS clock did not
> become available for some time after that when increasing integration
> allowed inexpensive GPS receivers.

What I meant by my remark was that I was surprised that the *new* Heathkit did 
not put out a GPS clock instead of what they did.


___
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] Heathkit clock available

[Nick Sayer via time-nuts]

Frankly, I don’t know why they didn’t make it a GPS clock. That would truly be 
a worthy successor to the GC-1000. Well, I do suspect I know why… and it’s not 
flattering. :)

Heck, if I thought I’d sell more than a handful, I’d make a desk-side GPS alarm 
clock and put it on Tindie. I’m actually fairly confident I could match their 
price. My problem is that I have no 3D modeling skills, so I don’t know what 
I’d do for a case for it. My usual trick of putting PCBs on the outside of 
extruded aluminum tubes (thanks go to Dave Jones for that) doesn’t seem like it 
would be apropos for this.

But for sure a GPS module, a handful of buttons, 7 7-seg LEDs (I’d display a 10 
Hz digit), a little phototransistor dimming circuit and an ATMega… $99 retail? 
Certainly doable.


> On Aug 9, 2016, at 11:03 PM, Bill Hawkins  wrote:
> 
> The GC-1000 was the Most Accurate Clock. This new GC-1006 is Most
> Reliable without mentioning accuracy.
> 
> The ad says that the standby oscillator can be calibrated by pushing
> some buttons on the back. Wondering how they do that almost makes me
> want to buy a simple clock that is $100 per pound. Perhaps there is a
> motor that turns a tuning capacitor to make the standby oscillator match
> the line frequency. More likely software changes the number of counts of
> some inexpensive XO per cycle.
> 
> I have an alarm clock with 2" seven segment LEDS that I can read without
> glasses. Its backup oscillator is LC, and somewhat faster than the line.
> It has carried me through the short outages I've experienced.
> 
> There's not enough info on what's behind the Santa Cruz rebirth of
> Heathkit. If I thought they were solid, I'd buy a kit to help prime the
> pump, so to speak. As it is, I'll be looking for neon-colored seven
> segment arrays a bit taller than those in the GC-1006.
> 
> No doubt, there are many schemes for disciplining 60 (or 50) Hz
> oscillators with 1 PPS.
> 
> TIA for any helpful comments.
> 
> Bill Hawkins
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Venus838LPx-T preliminary testing

[Nick Sayer via time-nuts]

I don’t know if I’d go that far. It’s more than conceivable that the 822A runs 
the same firmware as the 838 and therefore the actual functionality quoted in 
the datasheet is met.

Frankly, that’s the high order bit here - not what the label on the chip says, 
but whether it performs the way the datasheet claims. I don’t know because I 
don’t have one, but at least one poster here has said that the PPS jitter at 
least is the same.

You’ll recall when I pointed out that the NS-T had a different module, I *did* 
say that just because it wasn’t the same module that didn’t necessarily imply 
it didn’t have identical functionality.

> On Aug 10, 2016, at 7:52 AM, Mark Sims  wrote:
> 
> And it does NOT say they DON'T use the '838.  No where do they mention an 
> '822.  They do mention an '838 and the data-sheet they link to is for the 
> '838.   Their listing seems to meet the legal definitions of deceptive 
> advertising and bait-and-swith sales.   If they were in the US, they would 
> soon be having a not-so-nice conversation with the Texas attorney general.
> 
> 
> --
> 
> 
>> To be fair to Navspark, the publicity says « NS-T is functionally equivalent 
>> to Venus838LPx-T but in NavSpark form factor. » It does not say that it uses 
>> that chip.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Venus838LPx-T preliminary testing

[Nick Sayer via time-nuts]

And with that, the first run is out of stock. But don’t worry, I’ve placed an 
order for more modules and boards. Should be back in stock within a couple 
weeks, and the stock will run quite a bit deeper than the first batch did.

> On Aug 9, 2016, at 10:15 AM, Mark Sims  wrote:
> 
> Just checked mine... it's an 822A.  They sell it as an '838...  bastards...  
> I just ordered one of yours.  My RS-232 GPS breakout board already has a 
> connector with Adafruit pinouts on it, so makes life easy.
> 

___
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] Venus838LPx-T preliminary testing

[Nick Sayer via time-nuts]

If you're talking about the NS-T, the picture on their store suggests it may 
not be the exact same module. Their picture shows a Venus822A.

That doesn't necessarily imply that it doesn't have the same behavior, of 
course. 

Sent from my iPhone

> On Aug 8, 2016, at 9:53 PM, Mark Sims  wrote:
> 
> I measured the message end-time offset on the Navspark version (USB, virtual 
> 115,200 baud) at 153.8 msecs,  standard deviation of 7.1 msecs...  I don't 
> know how the real serial port version would compare.
> 
> 
> The Adafruit was 460 msecs, 50 msec standard deviation.
> 
> 
> -
> 
> 
>> I've been able to set the fudge value to 235 ms and actually get a "*" 
>> instead of an "x" from that line of ntpq.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Venus838LPx-T preliminary testing

[Nick Sayer via time-nuts]

> On Aug 8, 2016, at 7:26 PM, Clay Autery  wrote:
> 
> Wow... fast turn-around...
> 
> I might grab one of these for my NTP project for my home network...
> 
> Reckon they’d integrate with the Rasberry-Pi and other similar?

Absolutely. In fact, the prototype has replaced the PA6H on my Pi Zero public 
NTP server.

The Pi doesn’t have any use for the sawtooth correction, of course, but one 
thing I’ve noticed from the substitution is that the serial timestamp message 
latency seems *much* more regular than with the PA6H. I’ve been able to set the 
fudge value to 235 ms and actually get a “*” instead of an “x” from that line 
of ntpq.
___
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] Venus838LPx-T preliminary testing

[Nick Sayer via time-nuts]

> On Aug 5, 2016, at 8:13 PM, Nick Sayer via time-nuts <time-nuts@febo.com> 
> wrote:
> 
> 
> I’m going to make a breakout board for these and list them on Tindie next 
> week, for those who wish to play with them.

As promised, the breakout boards are now available.

https://www.tindie.com/products/nsayer/skytraq-venus838lpx-t-timing-gps-module-breakout/


___
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] Heathkit clock available

[Nick Sayer via time-nuts]

I just got an email announcing this:

https://shop.heathkit.com/shop/product/most-reliable-clock-tm-gc-1006-26

They bill it as a "most reliable" clock. From the description it appears to be 
an AC line disciplined clock with battery backup.

I only mention it here because of the periodic discussion of AC line discipline 
and because I suspect I'm not the only one who remembers the old Heathkit 
fondly.


Sent from my iPhone
___
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] Venus838LPx-T preliminary testing

[Nick Sayer via time-nuts]

I got the first breakout boards back today. There’s an error on them I had to 
workaround, but having done that I was able to observe it getting first-fix 
(with good reception, TTFF is remarkably good, FWIW), then performing the 2000 
point survey and generating quantization error messages.

I’ve collected an hour’s worth of quantization error data (as reported by the 
unit) and attached it here, for those who wish to analyze it. It’s very, very 
jittery, but confined to a ±6 ns corridor. I was able to see what appeared to 
possibly be very, very brief hanging-bridge-like anomalies, but overall it 
looks just really noisy to me.

After the survey, the GGA position reported has not changed, which is as I’d 
expect. I don’t know if the unit periodically validates the position solution 
to insure it hasn’t been moved.

I don’t have matching PPS jitter data to go along with this. It’ll be 
interesting to attempt to correlate the two to get a picture of post-correction 
PPS stability, if I can.

I’m going to make a breakout board for these and list them on Tindie next week, 
for those who wish to play with them.

-0.5
0.4
-2.7
1.0
-0.3
-6.1
-2.0
5.6
6.0
2.7
4.5
4.8
1.8
-3.3
0.7
5.9
-1.4
2.8
-3.0
-0.7
1.2
1.7
4.0
-5.4
5.5
4.7
5.3
4.7
3.1
1.3
4.0
3.4
-2.9
-5.7
-2.5
-5.9
0.6
-1.0
-1.6
5.4
-0.8
-5.9
-2.2
1.4
1.9
3.4
-5.1
1.6
1.4
1.6
-1.8
-5.9
-3.8
4.5
5.2
-1.4
-2.1
-1.1
1.2
1.2
3.5
-2.1
-2.6
-3.2
6.1
2.5
-0.3
-4.0
2.5
1.4
-1.3
-3.9
4.5
-0.9
4.8
3.8
-1.1
3.9
-3.2
2.7
0.4
-3.9
-4.3
2.9
-1.7
2.6
-3.6
0.8
-5.1
-1.6
2.9
-3.5
0.4
-4.0
1.3
2.1
-2.6
-2.3
1.2
0.3
2.0
5.7
-2.6
-2.0
3.2
1.5
3.1
4.1
6.0
-5.9
-3.6
-4.7
-1.4
-1.5
-1.2
-4.0
-3.9
-5.0
-6.0
-5.6
6.1
5.6
-5.8
5.0
5.3
4.5
5.2
-6.1
4.2
-0.6
-2.8
-0.7
-2.5
4.7
1.9
2.0
-1.7
-4.7
4.4
0.1
-0.9
-2.4
-5.5
1.9
-3.1
6.1
1.7
-3.0
4.0
-3.4
3.0
-0.1
-3.7
3.6
-2.9
3.9
-3.2
4.6
-0.3
-3.9
-5.7
0.9
-3.3
4.8
-1.1
6.0
1.8
-2.1
4.6
-1.1
-5.6
3.7
-1.7
2.9
-2.3
5.0
-1.7
1.4
-3.5
5.0
3.7
-3.3
4.9
3.4
1.3
-3.6
4.6
-1.9
-0.6
2.9
-1.0
-5.7
-3.0
-5.3
-1.7
-3.5
-3.1
2.8
1.0
-4.7
-2.7
-5.0
6.0
4.6
1.6
-2.2
-4.0
-3.0
-5.5
3.3
0.5
-1.7
-1.0
-1.3
-0.0
-0.0
-0.2
-3.7
-4.1
-2.8
-0.9
0.2
1.3
1.3
2.0
1.4
1.4
2.1
3.4
4.6
0.2
1.7
0.2
1.4
5.0
4.4
2.9
3.2
2.3
-0.2
2.2
1.6
2.1
2.0
-0.2
0.2
-1.0
-1.3
6.1
-3.5
5.8
2.7
2.2
5.6
-5.0
-5.0
-5.4
-5.2
-1.2
2.9
5.7
-4.5
-2.2
-1.1
-0.0
-2.4
0.5
2.3
-1.9
-5.2
-6.0
-3.4
-5.8
-4.9
-1.9
-1.2
0.6
6.0
-3.1
-6.0
-3.1
-2.7
-0.8
0.9
0.6
0.4
0.5
2.1
3.0
3.7
3.5
3.2
3.3
1.3
-2.4
4.2
6.1
-5.4
5.6
2.5
2.4
1.4
-1.0
-4.3
5.6
2.9
1.1
-0.7
-4.7
4.7
-0.9
-1.8
-1.3
-5.8
3.1
-0.8
-3.0
-3.9
-6.0
-5.8
-5.0
-4.8
-3.5
0.2
3.5
-5.8
-2.9
2.1
-5.2
-0.9
4.2
-2.1
3.6
-3.4
2.6
-2.7
4.4
-1.2
-5.3
-1.3
5.6
0.5
-1.1
-3.9
4.6
1.8
-0.8
-3.0
5.8
1.8
-2.8
-3.8
-6.0
5.2
3.7
3.7
2.1
2.5
2.4
0.6
-0.3
0.8
1.5
0.2
-0.7
-0.5
0.8
1.2
-1.3
-2.7
-0.3
3.4
-3.2
-1.7
1.4
3.2
-4.9
0.6
4.7
-3.4
2.0
-5.8
-3.0
0.1
4.0
-0.5
-1.1
-3.9
2.2
5.2
-0.0
6.0
-0.8
2.5
2.8
-6.0
-2.8
1.9
2.0
2.2
5.7
4.5
-5.2
-5.5
5.9
2.8
6.0
5.9
4.4
-3.7
-1.7
6.0
3.9
-5.3
5.9
5.7
5.4
4.0
1.6
-2.1
5.4
4.3
1.0
-1.7
-5.8
3.2
-0.8
-5.8
2.9
-1.3
2.5
-3.1
2.6
-2.7
3.0
-2.5
3.9
-6.0
-2.8
0.3
4.3
6.0
4.2
-1.8
2.0
4.5
4.9
4.6
4.6
4.5
5.9
-4.7
-3.7
-2.3
-0.6
0.3
1.4
3.2
4.6
-5.9
-5.0
-4.2
-4.5
-3.5
-2.6
-2.9
-4.1
-5.2
-4.2
-2.1
-0.8
4.4
-5.7
-1.1
1.3
-5.4
2.3
4.8
-0.1
4.7
-4.6
-2.2
2.6
4.3
-4.1
-0.1
3.2
-4.8
5.8
5.4
-1.1
-1.9
3.3
-3.5
2.9
-3.6
4.8
0.3
-4.5
3.4
0.6
-1.5
1.9
3.7
-5.5
0.0
5.2
-2.2
-1.6
-0.1
2.6
3.7
3.6
3.1
3.5
2.4
4.0
3.6
2.6
2.5
1.0
2.3
0.8
-2.5
-6.0
4.6
-4.7
-4.2
-4.9
5.7
4.1
2.2
-0.7
-3.5
4.9
1.6
-0.8
4.9
-4.0
4.7
4.0
1.5
5.9
0.8
-3.2
1.4
5.5
4.2
0.8
2.6
-1.1
-5.1
6.1
1.8
2.8
-1.0
4.4
-0.5
-4.9
1.4
-3.3
3.8
-1.1
-5.3
2.5
-2.7
3.2
-0.8
5.4
0.6
-5.8
-0.9
4.3
-2.4
1.0
4.0
-2.9
1.6
3.5
6.0
-2.4
3.3
-4.1
-5.8
-0.8
5.4
-2.5
-0.1
5.7
0.4
-3.4
4.3
-4.0
0.2
5.6
-1.6
1.7
4.8
-3.3
-1.2
3.5
-3.7
0.1
3.8
-4.9
-0.6
2.0
4.2
-4.8
-0.9
2.9
5.7
-5.3
-2.5
1.7
-5.5
1.9
-1.6
1.7
4.3
-5.4
-3.2
-1.5
-0.8
-1.2
0.1
1.7
2.5
3.0
4.9
4.4
3.4
3.2
5.0
-5.8
-1.6
1.6
4.7
-0.5
5.5
-5.9
-5.6
5.9
-5.7
-2.2
0.8
0.2
2.3
-1.7
-5.7
-2.2
-3.4
2.7
-3.4
0.2
1.7
4.2
-4.7
-1.9
1.3
3.5
4.3
4.9
-3.7
-3.7
-0.0
-0.1
-0.4
-1.9
-5.9
4.2
-5.5
-1.6
2.9
3.5
3.3
3.1
3.3
6.0
5.3
3.0
-5.6
-3.5
-5.3
-4.0
-5.3
-2.8
1.6
2.5
4.0
-5.8
5.7
4.6
5.8
-4.9
-5.4
5.4
-1.8
-2.0
2.6
5.5
3.2
-1.8
-5.2
-5.9
5.6
-3.9
-1.5
-2.7
-5.5
5.9
5.7
-6.0
-6.0
4.8
-1.7
-2.2
1.1
1.7
2.4
1.2
-1.5
-2.8
-5.3
4.3
3.5
1.7
0.3
-0.7
-2.2
-3.4
-1.2
-3.1
-5.1
-5.5
-6.0
4.2
3.6
4.3
-6.0
-2.4
2.5
-5.3
-1.4
3.2
0.1
2.6
-3.4
1.6
-4.0
2.0
4.9
-5.1
0.7
5.6
0.7
4.4
-4.3
4.3
2.5
-0.5
0.3
3.7
4.9
-4.0
-0.9
2.7
-2.0
-0.7
-2.1
1.3
3.6
-5.7
2.2
2.0
-3.3
0.9
4.0
5.2
-4.4
-2.2
0.7
0.9
1.6
2.5
3.6
5.6
-6.1
-6.0
5.2
4.4
3.1
2.7
2.3
2.1
2.4
4.3
-5.5
-5.6
-5.3
-5.1
5.2
5.9
2.5
3.0
-3.1
3.1
-2.7
-0.5
4.8
-2.3
0.8
-1.2
-5.0
1.0
4.9
4.8
4.3
5.4
2.4
-2.5
0.1
2.4
-2.0
5.2
-4.2
1.4
-5.8
-4.9
-6.0
-5.6
5.0
0.6
-2.2
3.5
5.5
2.3
-0.9
5.7
4.9
5.8
-2.4
2.8
2.5
0.9
-2.4
6.0
3.1
1.8
0.0
-3.7
5.4
2.1
-2.4
3.6
-0.9
-4.5
-5.9
3.5
-0.2
-5.4
0.3
-6.1
0.5
-4.8
0.6

[time-nuts] Best choice for GPS active antenna voltage?

[Nick Sayer via time-nuts]

In designing boards with the Venus838LPx-T module, I must supply external 
antenna power myself. This is in contrast to the PA6H I’ve been using which 
internally supplies 3.3v active antenna power (and measures it for loading to 
switch between the internal and external antenna. The Venue module does not 
have an internal antenna).

I therefore have the opportunity to select between 3.3v and 5v power to feed 
the external antenna. I could in principle do something more exotic, but I 
can’t imagine another option that would be better.

So far, 3.3v has worked with all of the antennae I’ve used, but the sample size 
is two (four if you count active GPS splitters in the mix).

In perusing the list, it sounds to me like modern antennae expect 3.3v, but I 
thought I’d explicitly ask rather than assume.
___
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] Adafruit Ultimate GPS timing message arrival times

[Nick Sayer via time-nuts]

> On Aug 1, 2016, at 9:33 AM, Chris Albertson  wrote:
> 
> 
> 
> In fact that would be a good experiment:  Put two clocks up on a large
> computer monitor and make one always tick some random number of
> milliseconds away from system time and the other always thick on the
> system time.  Then you click on the one you think is correct.  Can you
> do better than a 50/50 guess. Keep incl=reasing the error until the
> guesses are about 90% correct.   I bet you find you eyes are really
> bad.   You ears are a little better and you might notice 40 mS by
> listening to the "tick" sound
> 

I’ve done something akin to this with my Crazy Clock movements.

The Vetinari clock works by stealing 100 ms from a fraction of the ticks until 
it’s gathered up enough to do a “double tick.” I wrote the firmware and I can’t 
tell which seconds are 100 ms off.

There’s also the “Whacky” firmware. It ticks on a random tenth of a second 
within each second. In practice, it’s far more subtle than I thought it would 
be. It’s only really obvious when it picks values far apart from their 
neighbors.

___
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] Adafruit Ultimate GPS timing message arrival times

[Nick Sayer via time-nuts]

I’ve used the PA6H so far for all of my GPSDOs. The two reasons I am 
considering the Venus838LPx-T to replace it are that it has a sawtooth 
correction message and it has a survey and static solution mode to allow it to 
tolerate poorer reception.

I’m driven to want to experiment with a static mode GPS receiver from this page 
on Atilla Kinali’s blog: 
https://attila.kinali.ch/blog/2016/02/07/gps-disciplined-oscillator, which 
references some e-mail here from some time ago. My take-away was that 
navigation mode receivers could achieve good results as long as they had ideal 
reception, but with poor reception they would do much worse than a receiver in 
static mode that’s done a good survey.

As for the sawtooth correction, I’m less convinced that it’s required given 
that I’m using averaging on the phase detector output. I can’t detect hanging 
bridges with the current setup, but since I haven’t actually looked for them, 
ignorance is bliss. Tom, if you still have the data, can you speak to whether 
you saw anything of the sort? In any event, it’s a box I’d like to check if for 
no other reason than to learn something.

> On Jul 30, 2016, at 2:32 PM, Tom Van Baak  wrote:
> 
> Hi Brooke,
> 
> That's a reasonable assumption. I haven't ever tried mine at 10 Hz. But note 
> that fast update rates is more meant for navigation and positioning than it 
> is for timing.
> 
> Just in case we have some newcomers to the thread I'd like to point out that 
> this recent series of measurements of RS232 / NMEA have no bearing at all on 
> the quality of the timing output. Timing NMEA is more of a curiosity; 
> something to measure at the hundreds or tens of millisecond level. As anyone 
> knows, the real timing output of these receiver is the 1PPS pulse itself, 
> which is good to the tens of nanoseconds level. So a factor of a million 
> different.
> 
> I actually like the Adafruit GPS receiver, and would recommend it to anyone. 
> I use it for projects around the house more than any other receiver. It's so 
> simple to use -- no configuration needed, no sawtooth correction needed, no 
> survey required, fast acquisition, works fixed or mobile, sensitive antenna 
> included on board, small and low power, just give it 5 volts and out comes a 
> UTC 1PPS.
> 
> Its 1PPS output is superb. Attached is the ADEV/MDEV of the raw 1PPS of the 
> Adafruit GPS board.
> 
> /tvb
> 
> - Original Message - 
> From: "Brooke Clarke" 
> To: "Discussion of precise time and frequency measurement" 
> 
> Sent: Saturday, July 30, 2016 1:50 PM
> Subject: Re: [time-nuts] Adafruit Ultimate GPS timing message arrival times
> 
> 
>> Hi Mark:
>> 
>> Isn't this the receiver that hears a very large number of GNSS satellites 
>> and also has a 10 Hz update rate?
>> If so, I'd expect that there would a large variation in message lengths.  
>> How stable  is the 10 PPS or 1 PPS output?
>> 
>> -- 
>> Have Fun,
>> 
>> Brooke Clarke
>> http://www.PRC68.com
>> http://www.end2partygovernment.com/2012Issues.html
>> The lesser of evils is still evil.
>> 
>>  Original Message 
>>> A couple of people have asked about the poor message arrival time 
>>> performance of the popular Adafruit Ultimate GPS receiver.   I modified 
>>> Lady Heather to analyze the message arrival times using a histogram instead 
>>> of a simple average.  When I looked at the histogram data (.01 msec 
>>> resolution), I was rather shocked...  With an hour of data,  most receivers 
>>> have maybe a couple dozen bins hit,  with the peak bin several hundred 
>>> counts above the next lower peak.   The Adafruit had over 1800 bins hit, 
>>> with the peak bin having six hits. Attached is the histogram...  you 
>>> probably don't want to use this receiver to drive a clock based upon 
>>> message arrival times...
>>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Venus838LPx-T opinions?

[Nick Sayer via time-nuts]

The NMEA STI,00 message gives a sawtooth correction. I believe what Mark was 
saying was that there was no *binary* message that said so… maybe? I dunno. But 
the datasheet clearly talks about PPS quantization error compensation:


STI,00 – 1 PPS timing report

An output message, id 0x0, contains information of 1 PPS timing mode, 1 PPS 
survey length and 1PPS quantization error.

Structure:
$PSTI,00,x,xx,xx *hh


Example: $PSTI,00,1,1985,-12.4*1E

Here there’s a table that I’ll try to interpolate because pasting it failed…

the 1 is the PPS timing mode. 0 = PVT, 1 = Survey mode, 2 = Static mode
1985 is the survey length
-12.4 is the PPS quantization error
1E is, of course, the checksum.



> On Jul 22, 2016, at 11:40 PM, Charles Steinmetz  wrote:
> 
> Mark wrote:
> 
>> Oh, and besides the lack of a binary message with satellite position/signal 
>> levels,  there is none that reports the sawtooth error.
> 
> How in the world can they call it a "timing receiver" if it doesn't even 
> support sawtooth correction??  Good grief.
> 
> Also, I see they claim 6nS accuracy.  That is pretty much exactly 1/2 cycle 
> of the main clock frequency, so +/- 6nS should be the expected theoretical 
> best possible error envelope WRT the quantization error, *assuming the 
> receiver's timing solution is always perfect.*  Are we supposed to believe 
> they achieve that accuracy in practice, despite all of the well-known sources 
> of error in GPS timing solutions??
> 
> Best regards,
> 
> Charles
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Venus838LPx-T opinions?

[Nick Sayer via time-nuts]

Looks like the bare modules are available for $25 (FOB Taiwan) each MQ:4. 
Eminently reasonable. I am probably going to get 4 to start with and make an 
LGA breakout board for myself and do some experimenting with them.

The tough part for me is going to be upgrading the controller to the 
ATMega328PB to get enough flash space to add the sawtooth compensation handling 
stuff. But even if I completely ignore the NMEA output of the module, it'll be 
worth it to get timing firmware with survey capabilities. I'm quite excited. 

Sent from my iPhone

> On Jul 22, 2016, at 3:21 PM, Nick Sayer via time-nuts <time-nuts@febo.com> 
> wrote:
> 
> Anybody played with one of these? 
> http://www.skytraq.com.tw/products/products-Timing%20Module.html
> 
> It looks promising for GPSDO designers. It has a survey mode (looks to be 
> automatic) and one of the NMEA messages reports quantization error.
> 
> The downsides I’ve identified so far are that it’s an LGA69, so that’ll be… 
> exciting… And I don’t have any pricing, availability or minimum order 
> information at the moment.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

[time-nuts] Venus838LPx-T opinions?

[Nick Sayer via time-nuts]

Anybody played with one of these? 
http://www.skytraq.com.tw/products/products-Timing%20Module.html

It looks promising for GPSDO designers. It has a survey mode (looks to be 
automatic) and one of the NMEA messages reports quantization error.

The downsides I’ve identified so far are that it’s an LGA69, so that’ll be… 
exciting… And I don’t have any pricing, availability or minimum order 
information at the moment.
___
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] NCOCXO anyone?

[Nick Sayer via time-nuts]

Oh my. That’s a bit more than I was originally considering… What I had in mind 
was adding a DAC front end to an OCXO so that you could tune the EFC with 
serial commands rather than analog and calling that a product.

A simple version of what you seem to be describing, however, *sounds* to me 
something like this:

The microcontroller has the same phase discriminator system the GPSDO has, 
except that instead of the reference signal coming from a PPS, it comes from an 
input reference. The microcontroller can get a phase difference reading between 
the oscillator output and the reference and in software can tune the oscillator 
DAC output to arrange for a certain rate-of-change, adjustable via serial 
commands.

Does that sound about right?

Perhaps a more traditional PLL approach - using the 4046 PC2 output with an RC 
and simply allowing the controller to sample that makes some sense (calibrating 
it may be painful). I’ll have to do some more thinking about it. :)

> On Jul 21, 2016, at 3:39 PM, Tom Van Baak <t...@leapsecond.com> wrote:
> 
> Hi Nick,
> 
> There may be several threads in the time-nuts archives related to your 
> question. The greater concept is a phase microstepper (aka microphase 
> stepper). Imagine a small board that takes =10 MHz in and puts ~10 MHz out. 
> Using RS232 (or SPI or I2C) you control the phase, or even the phase over 
> time, which is to say, the frequency offset. Maybe do it with analog (EFC). 
> Maybe do it with digital (DDS).
> 
> There are highly-prized commercial instruments that do this. But no amateur 
> has tried yet. You should be the first. If you think about what we do with 
> steering oscillators -- for GPSDO, or for dual-mixers, or for home time 
> scales, or even sidereal or mars time -- having a device that cleanly steers 
> phase and frequency with simple RS232 would be very useful. For example, it 
> would allow anyone to steer a Rb or Cs standard, even though many of these 
> lab instruments do not have analog EFC or digital tuning options.
> 
> The possibility of this at the amateur level occurred to me when I played 
> with Bert's 9913:
> 
> http://leapsecond.com/pages/ad9913/
> 
> Read especially about the "programmable modulus mode" which can be used to 
> avoid truncation errors and achieve perfect long-term phase; kind of like the 
> difference between PLL and FLL in a GPSDO's 1PPS.
> 
> Look also at how the amazing FE-405 oscillator works:
> 
> http://leapsecond.com/pages/fe405/
> 
> And the idea of [mis]using a DDS as a high-resolution phase measurement 
> technique was confirmed with the PicoPak project:
> 
> http://www.wriley.com/PicoPak%20App%20Notes%20Links.htm
> 
> So, yes, please take the bait and play with all aspects of your NCOCXO idea.
> 
> /tvb
> 
> - Original Message - 
> From: "Nick Sayer via time-nuts" <time-nuts@febo.com>
> To: "Chris Arnold via time-nuts" <time-nuts@febo.com>
> Sent: Thursday, July 21, 2016 10:05 AM
> Subject: [time-nuts] NCOCXO anyone?
> 
> 
>> Would anyone see any value in a board that had an OH300 with a serial 
>> interface for tuning?
>> 
>> I had a thought perhaps to make one starting with my GPSDO and just ditching 
>> the GPS part and possibly adding an RS-232 level converter.  I could 
>> conceivably bring it all out to a DB9 and emulate an FE-5680 (obviously it's 
>> long term stability would be poorer without some discipline) or just make my 
>> own protocol up. 
>> 
>> Sent from my iPhone
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

[time-nuts] NCOCXO anyone?

[Nick Sayer via time-nuts]

Would anyone see any value in a board that had an OH300 with a serial interface 
for tuning?

I had a thought perhaps to make one starting with my GPSDO and just ditching 
the GPS part and possibly adding an RS-232 level converter.  I could 
conceivably bring it all out to a DB9 and emulate an FE-5680 (obviously it's 
long term stability would be poorer without some discipline) or just make my 
own protocol up. 

Sent from my iPhone
___
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] Leap second to be introduced at midnight UTC December 31 this year

[Nick Sayer via time-nuts]

> On Jul 20, 2016, at 12:25 AM, Tom Van Baak  wrote:
> 
> Hi Gary,
> 
>> 2.1 A positive or negative leap-second should be the last second of a UTC 
>> month,
>> but first preference should be given to the end of December and June,
>> and second preference to the end of March and September.
> 
> Sounds correct. The point is to never to hardcode a "preference". You code 
> against a spec. And the spec is simple:
> 
> "A positive or negative leap-second should be the last second of a UTC month"
> 

Even that’s weasel-worded. If they mean it, they should say it *will* or it 
*must* be the last second of a UTC month.

Words have meanings. :D

___
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] How does sawtooth compensation work?

[Nick Sayer via time-nuts]

So now that I’ve said that out loud, I’ve gone back and taken a thousand points 
from log and plotted them in excel.



PastedGraphic-1.pdf
Description: Adobe PDF document



Looks a *lot* more like sawtooth than noise. Hmm. I might have to reconsider.


> On Jul 18, 2016, at 8:06 PM, Nick Sayer via time-nuts <time-nuts@febo.com> 
> wrote:
> 
> 
>> On Jul 18, 2016, at 3:55 PM, Hal Murray <hmur...@megapathdsl.net> wrote:
>> 
>>> The systems gravitate towards PLL time constants that average it all away. 
>> 
>> You are overlooking hanging bridges.
> 
> 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.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] How does sawtooth compensation work?

[Nick Sayer via time-nuts]

> On Jul 18, 2016, at 3:55 PM, Hal Murray  wrote:
> 
>> The systems gravitate towards PLL time constants that average it all away. 
> 
> You are overlooking hanging bridges.

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.
___
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] How does sawtooth compensation work?

[Nick Sayer via time-nuts]

> On Jul 18, 2016, at 4:20 PM, Bob Camp  wrote:
> 
> On a receiver with sawtooth correction, you have a manufacturer specific 
> message that gives
> you information on the state of the receiver. It is defined as either 
> applying to the next pps
> or to the pps that just came out. There is a field that may give you 
> picosecond resolution 
> (as opposed to accuracy) data on the proper location of the PPS edge. 
> Depending on how
> you evaluate the correction, it can get the jitter down below 1 ns (again, 
> jitter as opposed
> to accuracy). 
> 
> A device that uses the sawtooth data shoves it into the control loop along 
> with the measured 
> early / late information on the PPS. 

Thanks. That’s what I figured. Thanks to you and everyone for confirming that.


___
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] How does sawtooth compensation work?

[Nick Sayer via time-nuts]

I've read Tom's page about sawtooth PPS jitter and I believe I understand where 
it comes from.My current GPSDOs ignore the phenomenon. Certainly at the 
moment, I'm satisfied with that.  The systems gravitate towards PLL time 
constants that average it all away. 

What I'd like to understand is how sawtooth compensation works with receivers 
that support it. Is it that I expect an NMEA sentence with a nanosecond offset 
value that I add to any phase difference observation that I get?

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

Re: [time-nuts] GPS for Nixie Clock

[Nick Sayer via time-nuts]

A visual clock has uses other than to be readable by humans.

I made a GPS clock once with 100 ms display resolution once for the purpose of 
timestamping photographs accurately. Photographs can have far, far shorter 
shutter speeds (or the digital equivalent) than human POV flicker rates.


> On Jul 15, 2016, at 8:19 AM, Chris Albertson  
> wrote:
> 
> For the NIXIE clock use case the jitter on the 1PPS hardly matters
> because we have worse problems, like human perception.  When a clock
> digit changes there is at least a 50ms time for the human eye/brain to
> notice.   I think for a visual clock display a good goals is to make
> it ONLY one order of magnitude better then human perception can
> detect.   We can accept a few milliseconds.
> 
> But of cours if we insist on perfection we will have to phase lock our
> own oscillator to UTC and account of the delay in our tube drivers
> 
> But do remember that our eyes do not notice the dark screen between
> frames at the cinema.  Assuming a film projector, the shutter is
> closed 24 times per second but we perceive a bright screen.  If we
> watched a movie of a clock, we'd think the second have moves smoothly
> even if we knew it was updated 24 times per second.   Errors on the
> order of 50ms are not detectable by eye by most people.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Jul 15, 2016 at 5:05 AM, Bob Camp  wrote:
>> Hi
>> 
>> Ok, I guess we need to go into this again:
>> 
>>   All of the output signals generated by one of these cheap GPS modules
>>   come from the internal TCXO on the module. All the signals.
>> 
>>   None of the TCXO’s on any of these modules are tuned to match the GPS.
>>   None of them, zero, not any.
>> 
>>   All of the output signals from all of these modules are matched up to GPS
>>   by guessing which clock edge to use.
>> 
>>   The result for all of these modules and all of their output signals is a 
>> signal
>>   with a *lot* of jitter.
>> 
>>   All GPS based systems are limited by the noise of the GPS signal. It is
>>   really dirty at short time intervals. The shorter the interval, the more 
>> noise
>>   it has. Any signal that directly tracks GPS will be *very* dirty.
>> 
>>  The only way to clean up GPS to make it useful as a frequency source is
>>  with a very narrowband loop.
>> 
>>   If you are implementing a < 0.01 Hz wide loop, it is no harder to do at 1 
>> Hz
>>   than 10 KHz or 100 MHz. In many respects it is easier to do at 1 Hz.
>> 
>>   If the objective is a time *display* that is read with a human eye, 
>> anything
>>   under 1 ms is not of much use. Your eye can’t detect it. Getting to 1 ns
>>   is a different task than getting to 1 ms. A Hydrogen Maser flywheel is
>>   not needed as part of a basic wall clock design.
>> 
>> Lots of variables, but also lots of basic facts.
>> 
>> Bob
>> 
>> 
>>> On Jul 15, 2016, at 1:19 AM, John Swenson  wrote:
>>> 
>>> Why I was even thinking about it at all was that one of the models I looked 
>>> at said the 10KHz was more accurate than the 1PPS, so I was kind of 
>>> thinking about that. If the Ubloxes have 1PPS which are just as good then 
>>> there is no reason to think about a 10KHz.
>>> 
>>> John S.
>>> 
>>> On 7/14/2016 9:45 PM, Chris Albertson wrote:
 On Thu, Jul 14, 2016 at 1:34 AM, Hal Murray  
 wrote:
 
> If you are building a PLL, it's a lot easier to filter a 10KHz signal 
> than a
> 1 Hz signal.
 
 You are correct.  But this guy is building a nixie tube clock.  The
 clock should increment the seconds at the tick of the UTC second.
 There really is no way to do this without using the PPS.  The serial
 data is not aligned with the UTC "tick"
 GPS receivers work just like the old telephone time service "At the
 tone the time will be..." and then comes the leading edge of the 1PPS.
 
 If he were building a frequency standard then, yes the 10KHz signal
 would be the best one to use.
 
>>> 
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to 
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] GPS disciplined Mars clock

[Nick Sayer via time-nuts]

I’ve often wondered how much sense it makes to speak of the rotational period 
of a gaseous planet. The different layers of the atmosphere potentially can 
have different rotational periods, and we can’t observe the actually rocky (or 
diamond, if you believe Arthur C. Clark) body at the center.

I looked into writing firmware for the Crazy Clock for the other planets 
besides Mars. Mercury and Venus have extraordinarily long day lengths, so the 
math doesn’t work out, and the remaining planets are gaseous.

> On Jul 9, 2016, at 9:23 AM, Mark Sims  wrote:
> 
> Do you have any equations for calculating Jovian (or Pluto) time and date 
> from UTC / GPS / TAI time?   Lady Heather does not want to slight any of our 
> other potential planetary overlords (but could whip their bloated gaseous 
> asses in a fight)
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Divide by 3

[Nick Sayer via time-nuts]

https://www.digikey.com/product-detail/en/on-semiconductor/MC74VHC1G86DTT1G/MC74VHC1G86DTT1GOSCT-ND/2705092
https://www.digikey.com/product-detail/en/nxp-semiconductors/74HC74D,653/568-1490-1-ND/763395


> On Jul 6, 2016, at 8:39 PM, Charles Steinmetz  wrote:
> 
> Nick wrote:
> 
>> I got the boards back, and Charles’ version with just two D FFs and a single 
>> XOR works perfectly. It works even without the delay line he indicated
> 
> I have never needed the delay in practice, either (I use mostly NC7SZ, 74AC, 
> and 74HC logic).  Modern logic is vastly more forgiving WRT setup and hold 
> times compared to the bad old days.  I showed the delay just in case someone 
> built it without and it didn't work.
> 
> What specific chips did you use?
> 
> Best regards,
> 
> Charles
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Divide by 3

[Nick Sayer via time-nuts]

> On Jun 8, 2016, at 9:59 AM, Charles Steinmetz  wrote:
> 
> Nick wrote:
> 
>> I’m contemplating trying my GPS board with an FE-405B. That’s a different 
>> kettle of fish, but at the end of that, if I’m successful, one of the goals 
>> would be to be able to use it for the external reference of my 53220A. 
>> Unfortunately, 15 MHz isn’t one of the options - only 1, 5 and 10.
>> 
>> So I did some googling and found a divide-by-3 circuit using flip-flops, and 
>> then designed a board for it
> 
> You can achieve substantially lower jitter (phase noise) with a regenerative 
> divider, which also allows you to divide by 3/2 for a 10MHz output.  I've 
> built several like that, and they work extremely well.
> 
> There are simpler divide-by-three logic circuits (generally, the simpler the 
> circuit the closer to an exact 50% duty cycle and the lower the jitter).  See 
> the attached image for one approach.
> 

I got the boards back, and Charles’ version with just two D FFs and a single 
XOR works perfectly. It works even without the delay line he indicated (sample 
size 1, FWIW). The version with the three D FFs and 3 NORs works just fine too, 
but of course it’s not as small as Charles’.


___
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] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nick Sayer via time-nuts]

> 
> For more precise stuff timing, I have a Thunderbolt and other goodies.
> (Speaking of which, I really need to figure out how to use the
> Thunderbolt as an external clock source for my Arduinos.)
> 

I don’t think you can do it for an Arduino without hardware changes. The CLKI 
pin is shared with XTAL1. But you can clock almost any AVR from an external 
clock source as long as the Vcc vs frequency “safe operating area” is respected 
(see the datasheet for your particular device). Note that if you fuse the 
device for an external clock source of any kind, that source must be present 
during (non-HV) programming as well as operation.

I use a DC blocking cap and self-biased inverter nowadays as an input 
conditioner for external clock inputs. It allows me to accept sine as well as 
square inputs if necessary. My principle use for this is my Crazy Clock 
calibrator, which I clock from one of my GPSDOs. It’s not 100% reliable, and 
I’m not sure why. Every once in a while, the AVR will lock up, even with the 
watchdog turned on. The square wave on CLKI looks *perfect*. I can only guess 
that there’s a glitch every once in a while that screws something up, but I 
haven’t figured it out yet.
___
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] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nick Sayer via time-nuts]

> On Jun 27, 2016, at 1:34 PM, Nick Sayer  wrote:
> 
> 
> In the firmware, the timer that has the input capture ability is set to 
> free-run at the system clock frequency. The ICP interrupt reports back the 
> timer delta from the last interrupt. Nominally, you’d expect 16,384 counts. I 
> calculate the delta and accumulate that for 10 seconds before reporting the 
> result on the LCD.

Correction…

Nominally, you’d expect 10,000,000 / 16,384 counts.
___
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] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nick Sayer via time-nuts]

I went through this exercise some time ago with my Crazy Clock.

The Crazy Clock is itself an ATTiny45 clocked with a 32 kHz crystal. I desired 
to determine the accuracy of the oscillator. I wound up making a purpose-built 
frequency counter.

First, the device under test gets special firmware that copies the system clock 
to a pin. The best I could do there is set up a timer to toggle an output on 
overflow and have it overflow constantly. The result is 16.384 kHz nominal.

The counter is a “backpack” on a 2x16 LCD display (I make a lot of those). The 
controller is an ATTiny84. 6 of its pins go to the LCD (some shared with the 
programming interface). The system clock is derived from an external input, 
which for me is supplied by a GPSDO. The board has a self-biased inverter and 
DC blocking cap on the input.

The crazy clock interface is a 1.8v LDO to supply power and an input line that 
goes to the 16.384 kHz output from the DUT. That sample line goes to the ICP 
pin on the controller.

In the firmware, the timer that has the input capture ability is set to 
free-run at the system clock frequency. The ICP interrupt reports back the 
timer delta from the last interrupt. Nominally, you’d expect 16,384 counts. I 
calculate the delta and accumulate that for 10 seconds before reporting the 
result on the LCD.

The LCD shows the actual delta, what that means in ppm and the two byte 
calibration value I write into the DUT’s EEPROM. The DUT’s *normal* flash code 
has the ability to trim the system clock by the factor stored in the EERPOM 
(signed value in 100 ppb units).

I never made this whole thing public, because it seemed to me at the time to be 
a very specialized item useful to nobody else. But I can cobble together my 
schematics and firmware. The way I wrote the code, it ought to be easy to have 
it work for other frequencies (both reference and DUT).

> On Jun 27, 2016, at 8:22 AM, Pete Stephenson  wrote:
> 
> Hi all,
> 
> I have a few Maxim DS3231 temperature-compensated real-time clock
> chips I use for various embedded hobby projects. They're specced to
> have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
> a standard, reputable vendor, while a few are from somewhat more
> dubious internet sellers. While all the chips work and seem to
> maintain reasonable time over a period of a few weeks, it's possible
> that some don't meet spec and I'd like to test them and make sure they
> do what they're supposed to.
> 
> Here's what I've been doing manually, and what I hope to accomplish
> using a microcontroller. Any tips are very welcome.
> 
> = Manual Approach =
> 
> I've manually tested a few of the chips using a digital storage
> oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
> set things up:
> 
> 1. Enable the 32kHz output on the DS3231 and wire it appropriately.
> (The 32kHz output shows up on the oscilloscope.)
> 
> 2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
> expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
> so the pulse train seems to move slowly to the left or right
> (depending on the chip) on the scope.
> 
> 3. Wait until the rising edge of one of the 32kHz pulses is (visually)
> lined up with an arbitrary line on the scope's graticule, then start a
> timer.
> 
> 4. Wait until the rising edge of the next pulse drifts to the same
> line on the graticule -- that is, it has drifted by one cycle -- and
> then stop the timer.
> 
> If I'm particularly motivated, I'll watch the scope for longer and
> count the time it takes for the clock to drift two or three cycles.
> 
> As an example, one of the clocks drifts by one cycle in 120 seconds.
> 
> I then calculate the stability as follows:
> 
> Stability = (1 cycle / 120 seconds) / (32768 Hz)
> = (1 cycle / 120 seconds) / (1 second / 32768 cycles)
> = 2.54*10^(-7)
> = 0.254 ppm.
> 
> Is this right so far? If so, that clock seems to be well-outperforming
> the specs.
> 
> I've tested a few chips at a few different temperatures (e.g in the
> freezer, in direct sunlight, etc.) and they seem to drift faster for a
> minute until the chip measures and corrects for the temperature
> change, at which case the drift returns to the normal value.
> 
> = Automated Approach =
> 
> The manual approach is handy, but only measures short-term drift and
> is subject to errors. I'd like to automate the measurements using a
> microcontroller (I'm familiar with AVRs, mainly the ATmega328 and
> ATtiny85 using the Arduino IDE, for what it's worth).
> 
> My plan was to have the microcontroller count the number of cycles of
> the 32kHz clock over a period of time, say 1000 seconds. If all was
> perfect, it'd count exactly 32768000 cycles during this time.
> 
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and
> handling an interrupt on an ATmega328 running at 16MHz 

Re: [time-nuts] OT stuffing boards: was GPS interface/prototyping

[Nick Sayer via time-nuts]

> On Jun 23, 2016, at 6:28 PM, Jay Grizzard  
> wrote:
> 
> On Thu, Jun 23, 2016 at 11:28:00PM +, Mark Sims wrote:
>> A usable re-flow oven can be had for $300.
> 
> Do you (or anyone) have suggestions for usable reflow ovens in this price
> range? 

I sell a reflow oven conversion kit on Tindie, FWIW.

https://www.tindie.com/products/nsayer/toast-r-reflow-power-board-kit/
https://www.tindie.com/products/nsayer/toast-r-reflow-controller/

It’s two separate pieces because I really wanted to divide the problem between 
the dangerous power handling bits, and all the rest, which is low voltage and 
safe to fool with. The intent is that you gut the toaster oven’s native 
controls and install the power board inside. You connect a 3 wire LV cable to 
the control port and bring that out to the controller. The control is 
opto-isolated triacs, so effectively an LED acts as a proxy for the elements.

I’ve been using them with the same toaster oven ever since the very beginning. 
The toaster isn’t agile enough for RoHS paste, but that could probably be fixed 
by better insulation or perhaps hacking in an extra heating element.
___
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.