Re: [time-nuts] Traveling to the US west coast

[Pete Stephenson]

Interestingly enough, I've moved from. Switzerland (where I've met Atilla) and 
am now in the Bay Area. It's be great to meet up again. 

Even if Attila doesn't make it to the SF area, I'd be interested in getting 
some local time nuts together. 

Cheers! 
-Pete

On Fri, May 18, 2018, at 6:36 PM, Jerry Hancock wrote:
> Are you going to be in San Francisco area?  Maybe we could get a time-
> nuts breakfast together with a couple of us.
> 
> Regards,
> 
> Jerry
> 
> 
> 
> > On May 17, 2018, at 11:25 PM, Attila Kinali <att...@kinali.ch> wrote:
> > 
> > Hi,
> > 
> > Some of you might already know, I will fly to the US west coast
> > to attend IFCS. Afterwards, I will be in Seattle for a couple of
> > days (from 25th to 31st). If you are in the area and want to meet up,
> > please drop me an email (off-list).
> > 
> > 
> > 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.


-- 
Pete 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.

Re: [time-nuts] Suggest time-and-tech related locations in Switzerland

[Pete Stephenson]

Also worth mentioning is the Swiss standards organization, METAS, in Bern. 
Their time and frequency group has a few atomic clocks, a maser, and some other 
shiny things they use for realizing UTC(CH), as well as a few research projects 
related to the subject. While not formally open to the public, they do tours on 
request.

On Thu, Mar 15, 2018, at 9:18 AM, Bernd Neubig wrote:
> Hi Dave,
> the center of the Swiss watch & crystal industry is the small town of 
> Grenchen, location of many famous watch makers including the SMH group 
> which includes Microcrystal, previously also Oscilloquartz, and the 
> following wathc brands:
>  Prestige and Luxury:
> Breguet (CH)
> Blancpain (CH)
> Glashütte Original (D)
> Jaquet Droz (CH)
> Léon Hatot (CH)
> Harry Winston (USA)
> Omega (CH)
> Upper price segment:
> Longines (CH)
> Rado (CH)
> Union Glashütte (D)
> Middle price segment:
> Tissot (CH)
> Calvin Klein (CH)
> Balmain (CH)
> Certina (CH)
> Mido (CH)
> Hamilton (CH)
> Base segment:
> Swatch (CH)
> Flik Flak (CH)
> Private Label:
> Endura (CH)
> 
> A few km away is Neuchatel (Neuenburg), a center of time and frequency 
> companies.
> I am not familiar with museums in that area, but I am sure there are 
> some. I think someone else on the list will have more details.
> The whole area is the so-called "Swiss Jura". 
> The area of time & frequency companies and institutes extends into 
> France up to Besancon.
> Neuchatel and Besancon are the locations where the EFTF (European Time 
> and Frequency Forum) started and is taking place in one of both every 
> two years.
> 
> Best regards
> Bernd
> DK1AG
> 
> 
> 
> -Ursprüngliche Nachricht-
> Von: time-nuts [mailto:time-nuts-boun...@febo.com] Im Auftrag von David Witten
> Gesendet: Dienstag, 13. März 2018 22:59
> An: time-nuts@febo.com
> Betreff: [time-nuts] Suggest time-and-tech related locations in Switzerland
> 
> My wife and I are traveling to Switzerland for the last week in May.  I 
> have never been there before.
> 
> I would appreciate suggestions for time / tech sites of interest to visit.
> 
> We plan to fly to Zurich, but travel immediately to Geneva and then work 
> our way back to Zurich by train, stopping (at least) in Bern.
> 
> I would like to see what I can at CERN, I plan to attend the Ham meeting 
> in in Friedrichshafen June 1 - 3.
> 
> Dave
> ___
> 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.


-- 
Pete 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.

Re: [time-nuts] Frequency deviations in Europe affect clocks

[Pete Stephenson]

On Wed, Mar 7, 2018, at 9:28 PM, Mark Sims wrote:
> A more detailed explanation of what is happening:
> 
> https://arstechnica.com/tech-policy/2018/03/ovens-across-europe-display-the-wrong-time-due-to-a-serbia-kosovo-grid-dispute/

This explains why my oven clock and the time/temperature display on the 
building outside my apartment in Switzerland are six minutes slow since 
January. It was a great mystery to me. 

Fortunately the Swiss rail system doesn't, as far as I know, use powerline 
frequency for timekeeping, even at remote stations, so all the railway clocks 
are still running properly. 

-- 
Pete 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.

Re: [time-nuts] Need a Watch Recommendation

[Pete Stephenson]

On 3/5/2018 7:38 AM, Don Murray via time-nuts wrote:

> So, Time Nuts...  any suggestions or recommendations?

For non-formal, day-to-day wear, I've been partial to Casio G-Shock
watches for a long time. They're rugged, reliable, and have the basic
features one might want: stopwatch, countdown timer, a few user-settable
alarms, etc. without too many bells and whistles.

Watches with "Multi-Band 6" have long wave time signal receiving
capability and can receive signals from WWVB, MSF, DCF77, and
transmitters in China and Japan.

They also make watches that have GPS receivers, and hybrid GPS and long
wave receivers for redundancy.

I've worn a GWM850-1, which is a Multi-Band 6 watch, for a long time and
it's served me well. Unfortunately, Casio doesn't make that specific
model anymore, but there's lots of other similar models available. Mine
tries to set itself every night starting at midnight and trying again
hourly until it either succeeds at setting the time or it fails after
4:00am. It also charges its internal battery from a solar panel formed
into the watch face, so one never (modulo the battery eventually
degrading) needs to change it. I've found that even with liberal use of
the EL backlight, the battery never gets below the "medium" level during
winter when the watch rarely sees the sun, and then fully charges up
again in springtime.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Suggestion for a timing GPS receiver (Trimble / Ublox / other?)

[Pete Stephenson]

On 1/22/2018 4:38 PM, Paride Legovini via time-nuts wrote:
> Dear fellow nuts,
> 
> I plan to build a decent GPS/GNSS-based Stratum 1 NTP server, and I'm
> looking for a good and possibly affordable timing GPS receiver.

As others have pointed out, NTP over the internet isn't usually more
accurate than several tens of microseconds, so you have a lot of
flexibility in the receiver you choose.

If you need something that's simple to interface, has RS-232 polarity
signals, and is generally plug-and-play, the Garmin GPS 18x LVC is a
good choice. It's robust, compact, and easy to wire to whatever device
you want: in my case, I use a USB-A male plug connected to a USB port on
my time server to provide the required 5V power and have the serial and
PPS lines connected to the server's hardware serial port.

It's not strictly a timing receiver with a position hold mode, but it
does produce a PPS output +/- 1 microsecond, and can do "position
averaging" so it doesn't drift around more than a few meters when
stationary.

It can output data in either NMEA format or the Garmin binary format,
which is well-documented and supported by GPSd. Garmin's made the
receiver for many years and has generally worked out the kinks with a
bunch of firmware updates over the years.

Another alternative is the rather older Motorola Oncore UT+ receivers
one can get on eBay for about $15 USD. No longer supported by the
manufacturer and with hardware of unknown age, it might not be the best
choice for critical systems. Still, they're true timing receivers with
sawtooth correction, are easy to power with 5V, output TTL serial (so a
MAX(3)232 can easily convert the data to RS-232 polarity) and a PPS
signal, and are well-supported by NTPd. The Oncore driver for NTPd is a
bit chatty in terms of what it logs every second, but that's easy enough
to deal with. They're cheap enough to get a few to play with.

Cheers!
-Pete

-- 
Pete 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] BIPM looking for a physicist for their time metrology group

[Pete Stephenson]

Details here: https://www.bipm.org/utils/en/pdf/vacancy_time_physicist2018.pdf

Looks like a fun position for any time-nuts looking to do this sort of thing 
professionally.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] current crop of GPS receivers for Rpi/Beaglebone for NTP server/etc

[Pete Stephenson]

On Mon, Oct 16, 2017, at 03:45 PM, jimlux wrote:
> I have beagles, but others have pis.
> 
> There seem to be dozens of GPS receivers out there in a variety of form 
> factors.
> 
> What's the current "best" inexpensive choice for run of the mill 
> time-setting/1pps  that's a "catalog" item
> 
> Plenty of online "how-to" from 2013 and 2014, but we here on the list 
> know that the "cheap GPS" receiver business is a very moving target - 4 
> years is a long time.

It's a bit old-school, but I have an Oncore UT+ attached to my Pi 2
Model B timing server at home. A simple MOSFET-based level shifter[1]
converts the serial and PPS signal from the 5V the Oncore outputs to the
3.3V the Pi requires and is sufficiently fast to not make a significant
difference in timing (I can't see any delay, even with my oscilloscope
turned down to 5ns per div). I also built a little interface board with
a supercapacitor-based backup for the Oncore's RAM that holds the level
shifter. 

The Oncore driver for NTP is a bit chatty, so I have it save logs to a
small ramdisk[2][3][4] with the log being rotated every two days. Works
well.

I suppose using a 3.3V unit would be nice, but I had a bunch of Oncores
lying around that needed use, so why not? :)

Cheers!
-Pete

[1] <https://www.adafruit.com/product/757>
[2] The line in fstab is, omitting quotes, "tmpfs /tmp  tmpfs
defaults,noatime,nosuid,size=100M 0 0"
[3] The entry in the ntp.conf file is "logfile /tmp/ntp.log", which was
done after making the change detailed at [4]
[4] <http://lists.ntp.org/pipermail/hackers/2010-November/005004.html>

-- 
Pete 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.

Re: [time-nuts] A look inside the DS3231

[Pete Stephenson]

On Sun, Jul 30, 2017, at 03:37 PM, Mark Sims wrote:
> A friend of mine is an engineer for one of the biggest manufacturers  of
> clock chips and has worked quite a bit on their clock chips and is quite
> familiar with the issues of building consistent ultra low power
> oscillators in a production product.   Getting nanowatt (and now
> sub-nanowatt) level oscillators to do their thing consistently is not
> easy.   Getting them to do it with customer supplied crystals is a big
> thing.   Variations by the crystal maker regularly cause previously
> working products to stop working.  Also they are notoriously sensitive to
> PCB layout issues.  Older, higher power clock chips don't have nearly as
> many problems as the newer ultra low power designs.   Competition to see
> who can make the lowest power clock chips seems to be one of the biggest
> drivers for new clock chip designs.

What's the motivation for this, other than "because we can"? Aren't
existing RTC chips capable of running 10+ years from a lithium coin cell
already, to the point where the cell's self-discharge is the limiting
factor?

Is there some application where exceptionally low power use for a clock
chip would be of interest?

I ask as an interested amateur not familiar with the subtleties of such
designs.

Cheers!
-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.

Re: [time-nuts] Thunderbolt rollover glitch

[Pete Stephenson]

On Sun, Jul 30, 2017, at 04:49 AM, Mark Sims wrote:
> It looks like it took three hours for the effects of the rollover glitch
> to mostly settle out.
> 
> BTW,  if you only use Lady Heather with a Thunderbolt,  you can force the
> rollover state from the command line or heather.cfg file by using the /ro
> command line option.  If you do that you won't have invalid dates for the
> 10-15 seconds it takes for Heather's automatic rollover corrector to kick
> in.   If you have /ro in the heather.cfg file and wish to temporarily
> cancel it to play with another receiver that does not have a rollover
> issue,  you can start Heather with /ro=0 

I saw a very similar glitch.

Out of curiosity, have you done anything particular to keep the
oscillator so stable? Mine seems a bit more noisy: if I set my display
to 2ppt/div as you have, things are off the scale. I typically see a
span of ~1000-1500 ppt with an RMS of ~100-200 ppt.

To be fair, I'm just using an old Cisco power supply from the eBay
vendor that sold me the Thunderbolt, and my Thunderbolt is sitting on a
block of foam on the floor in a room at the apartment with no particular
temperature control.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] A look inside the DS3231

[Pete Stephenson]

On Sun, Jul 30, 2017, at 11:15 AM, Attila Kinali wrote:
> On Sat, 29 Jul 2017 20:32:30 +0200
> Pete Stephenson <p...@heypete.com> wrote:
> 
> > - There's several square grids of circles-in-squares circuit elements. I
> > have no idea what these are.
> 
> If you look closely, these are actually suqares-in-squares.
> I am not sure, but my guess would be that these are the
> capacitor banks for the correction of the oscillator frequency.

True, the larger ones are squares-in-squares, but the smaller ones to
the left look like circles-in-octagons, but I find it hard to see the
details of the smaller features.

Either way, I should probably stare less through microscope eyepieces.
It seems to stress the eyes a bit.

> > - I find it remarkable that this circuit can operate on less than a
> > microamp during normal usage, including temperature conversion.
> 
> That's not so remarkable. If you make the transistors long, then
> you get very low leakage. Couple that with small clock frequency
> and you use very little current. Modern ICs only use so much current
> because they have so many transistors, which are also optimized
> for being fast, rather then low leakage. 

Good point! I admit the details of optimizing transistors for different
purposes is beyond my ken, and I appreciate the insight.

> > The DS3231 has on-board temperature monitoring to correct the crystal
> > frequency: is this something where they would have bothered putting a
> > separate sensor next to the crystal itself, or are the die and the
> > crystal are close enough and in the same package that they could use an
> > on-die sensor like a diode and call that "good enough"?
> 
> My guess would be that it's a PN-junction or a bandgap temperature
> sensor somewhere on the chip. Adding another part increases the cost
> of production quite considerably.

Indeed. At first glance, I was surprised not to see tiny discrete
capacitors within the chip package itself, as I assumed (incorrectly)
that getting sufficient capacitance to steer a crystal a little would
require larger capacitors than could be easily put on a die, but then I
remembered that each LSB in the aging register only changes the
frequency by 0.1ppm at 25C, so that wouldn't need a large amount of
capacitance. 

As you say, minimizing part count keeps the price down and makes the
design simpler.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] A look inside the DS3231

[Pete Stephenson]

On Thu, Jul 27, 2017, at 09:46 PM, Trent Piepho wrote:
> Looks like it still says "DALLAS SEMICONDUCTOR" to the left of Maxim.
> Maybe Maxim only wanted to change the mask enough to find some empty
> space to sign it?

It does indeed say "DALLAS SEMICONDUCTOR".

I managed to get some high-quality photos using the microscope's
on-board camera and have updated the photo album at
https://imgur.com/a/0zudj with the newest ones (they're the
all-rectangular photos below the two circular photos). There's some
high-resolution composite images.

Some things I found interesting:
- There's a section just above the "Maxim" part that has several
snippets of text ("17A3", "16A3", etc.). In normal light, each of these
bits of text is a different color, where the colors correspond to
different layers of the chip. Each bit of text has a different depth of
focus, indicating they're physically closer or further from the lens.
Does anyone know what material the colors might correspond to?

- There's several square grids of circles-in-squares circuit elements. I
have no idea what these are.

- I find it remarkable that this circuit can operate on less than a
microamp during normal usage, including temperature conversion.

The DS3231 has on-board temperature monitoring to correct the crystal
frequency: is this something where they would have bothered putting a
separate sensor next to the crystal itself, or are the die and the
crystal are close enough and in the same package that they could use an
on-die sensor like a diode and call that "good enough"?

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] A look inside the DS3231

[Pete Stephenson]

On Thu, Jul 27, 2017, at 09:31 PM, Pete Stephenson wrote:
[snip]
> Anyway, the photos are available at http://imgur.com/a/0zudj -- I will
> add more photos from the petrographic microscope tomorrow. I focused
> mainly on the markings on the die that indicated it was, in fact, a
> Maxim chip but if there's any other region of the chip that you'd like
> images of, please let me know and I'd be happy to take some more
> pictures.

Hi all,

Just a quick update: I was able to look at the DS3231 at work at the
quality of the (very expensive) Zeiss microscope is dramatically better
than my $20 USB microscope at home. No surprise.

Unfortunately, due to the ancient Canon camera attached to the
microscope not being compatible with Windows 7 or Linux, I was unable to
get any high-quality photos at this time. The camera is normally used in
tethered mode with no CF card, with the camera connected to the user's
laptop. Most of my colleagues use Macs, which evidently do work with it
but I wasn't able to ask any of them today before they all left. I've
ordered a CF-to-SD adapter that should allow me to take photos without
any issues, but it will be a few weeks until it arrives. Once it's
arrived, I'll take some more photos of the chip and let people know.

I've taken a few photos with my smartphone through the microscope's
eyepiece, but they turned out quite poorly as you can see below. When
viewed directly via the eyepiece, the appearance of the chip is quite
stunning.

On a related note, the reflected differential interference contrast
(DIC) filters on the microscope make looking at multi-layer chips
dramatically more clear and interesting. Compare
http://imgur.com/7nuTooL , which was taken with with no optical
filtering using standard reflected light illumination and
http://imgur.com/P6HL9MB which was taken of a different area of the chip
using reflected DIC. The colors are different, of course, but the
contrast between elements of the chip is much improved.

If anyone has any chips they'd like me to examine under the microscope,
let me know and I'd be happy to do so.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] A look inside the DS3231

[Pete Stephenson]

Graham,

That's very true!

Still, my past experience with copied chips typically involves a
particular type of RS-232-to-TTL serial converter, the MAX3232. I've
found that nearly all of the ones from unauthorized distributors (e.g.
auction site vendors) are fake, even though the package is marked as
being MAX3232. After a few weeks the chips would fail in a way that
they'd pass high currents and get extremely hot.

I did a write-up on those chips at
<https://blog.heypete.com/2016/09/11/investigating-fake-max3232-ttl-to-rs-232-chips/>
and, after decapuslating them, discovered they were completely different
chips on the inside that were made to function the same way as the
MAX3232 (i.e., they converted RS-232 signals to TTL serial, operated on
the same voltages, had the same pinout, etc.).

In regards to the DS3231, I was concerned that the chip was also a fake
that functioned in the same way as the DS3231, presented the same
registers to the user, etc., but was actually a different design on the
inside. It appears that this is not the case, and in addition to
functioning as advertised, it also is legitimate. If it is a clone, it's
a goood one, but I don't think it is.

Cheers!
-Pete

-- 
Pete Stephenson

On Thu, Jul 27, 2017, at 10:34 PM, Graham / KE9H wrote:
> Pete:
> 
> If you are concerned about someone copying a chip, you can not rely on
> the
> original manufacturers' markings on the die.
> 
> I have experience where the counterfeiter just photocopied the chip
> layout,
> including the original manufacturers marks, and copyright symbol and
> notice
> from the original die.
> 
> So, when they copied the die, they really just copied it. Didn't change a
> thing. It was not like they redesigned it, or were selling their own
> design
> with equivalent functionality.
> 
> --- Graham / KE9H
> 
> ==
> 
> 
> 
> On Thu, Jul 27, 2017 at 2:31 PM, Pete Stephenson <p...@heypete.com>
> wrote:
> 
> > Hi all,
> >
> > A few days ago I reported the results from letting a DS3231 RTC run for
> > a year, and how the chip kept time well within the published specs.
> >
> > Since I had acquired several DS3231s from dubious sources (Asian vendors
> > on a major auction site) as part of an RTC module that fits on the
> > Raspberry Pi's header pins, I was doubtful of the authenticity of the
> > chips. I decided to sacrifice one in the name of science and decapped it
> > at home using alternating heat (a lighter) and cold (a glass of cold
> > water) to embrittle the epoxy casing, then sanded down the back of the
> > chip on fine-grain sandpaper to expose what I hoped was the back of the
> > internals (so as not to damage the die itself).
> >
> > Other than inadvertently sanding through half of the crystal's housing,
> > thus breaking one of the forks of the crystal, this was a success. (I
> > was prepared to decap one in acid had my attempt at physically removing
> > the epoxy package failed.) I slightly scratched the die itself while
> > separating it from the epoxy, but the die itself is clearly visible.
> > Based on a sample size of one and the markings on the die itself, it
> > appears the chip is authentic. The markings on the outside of the epoxy
> > package look a bit dubious and not like typical Maxim laser-markings, so
> > it's possible the chip was re-labeled at some point. I'll contact Maxim
> > to see if they can look up the lot information.
> >
> > I used my 2 megapixel USB microscope to take some images throughout the
> > process that you might find interesting. The microscope has limited
> > resolution, particularly at high magnification, so some of the photos
> > may not be perfectly clear. I have access to a Zeiss petrographic
> > microscope at my work and will see if I can get some better images
> > tomorrow. I'll try to get high-quality images of the whole chip and
> > stitch them together into a larger composite.
> >
> > Anyway, the photos are available at http://imgur.com/a/0zudj -- I will
> > add more photos from the petrographic microscope tomorrow. I focused
> > mainly on the markings on the die that indicated it was, in fact, a
> > Maxim chip but if there's any other region of the chip that you'd like
> > images of, please let me know and I'd be happy to take some more
> > pictures.
> >
> > I hope you find this as interesting as I did.
> >
> > Cheers!
> > -Pete
> >
> > --
> > Pete 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 instruct

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

[Pete Stephenson]

I seem to recall several people (tvb?) doing tests and determining that
the 10 MHz and PPS outputs will continue to function as normal, since
the Thunderbolt will continue to track and lock onto the satellites.

The only difference is it'd think the date and time were N weeks in the
past, where N is whatever offset they used. This can be corrected in
software, as Lady Heather does, or perhaps with some in-line device that
re-writes the serial data as it comes out of the Thunderbolt (I've been
tempted to make such a thing myself, but real-world commitments have
gotten in the way).

Cheers!
-Pete

-- 
Pete Stephenson

On Fri, Jul 28, 2017, at 02:36 AM, paul swed wrote:
> 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
> 
> On Thu, Jul 27, 2017 at 8:01 PM, Attila Kinali <att...@kinali.ch> wrote:
> 
> > On Thu, 27 Jul 2017 17:49:14 -0500
> > Didier Juges <shali...@gmail.com> wrote:
> >
> > > I cannot imagine a work around since the problem stems from the GPS
> > service
> > > only identifying the current date within a particular 1024 weeks epoch
> > > unless the government changes the amount of data that is sent over the
> > GPS
> > > system. Somebody has to use other method to determine the epoch and add
> > the
> > > corresponding offset.
> >
> > There is: There is a 13bit week number in message type 10. This gives
> > a 157 year span instead of the ~19 years of the 10bit week number.
> > This has been part of the GPS standard since IS-GPS-200D which was
> > released in 2004. As such I am a little bit surprised that the u-blox
> > receivers still don't support this message (the LEA-5 family was released
> > in 2007 IIRC). But you can use the UBX RXM-SFRBX  messages to get the
> > raw GPS messages and decode them yourself.
> >
> >
> > Attila Kinali
> >
> > --
> > You know, the very powerful and the very stupid have one thing in common.
> > They don't alters their views to fit the facts, they alter the facts to
> > fit the views, which can be uncomfortable if you happen to be one of the
> > facts that needs altering.  -- The Doctor
> > ___
> > 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 look inside the DS3231

[Pete Stephenson]

On Thu, Jul 27, 2017, at 09:31 PM, Pete Stephenson wrote:
[...]
> Based on a sample size of one and the markings on the die itself, it
> appears the chip is authentic. The markings on the outside of the epoxy
> package look a bit dubious and not like typical Maxim laser-markings, so
> it's possible the chip was re-labeled at some point. I'll contact Maxim
> to see if they can look up the lot information.
[...]

Hi all,

Quick follow-up: I contacted Maxim to see if the chips were authentic,
and their very pleasant customer support people verified that the
markings and appearance of the chip are consistent with their records
for that year and lot number. That's a good thing.

They also reminded me that they only offer a warranty/guarantee on
products purchased either directly from them or from authorized
resellers. Asian auction-site vendors are not authorized resellers, so
please don't use products from such sources for Serious Business(tm).

Cheers!
-Pete

-- 
Pete 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] A look inside the DS3231

[Pete Stephenson]

Hi all,

A few days ago I reported the results from letting a DS3231 RTC run for
a year, and how the chip kept time well within the published specs.

Since I had acquired several DS3231s from dubious sources (Asian vendors
on a major auction site) as part of an RTC module that fits on the
Raspberry Pi's header pins, I was doubtful of the authenticity of the
chips. I decided to sacrifice one in the name of science and decapped it
at home using alternating heat (a lighter) and cold (a glass of cold
water) to embrittle the epoxy casing, then sanded down the back of the
chip on fine-grain sandpaper to expose what I hoped was the back of the
internals (so as not to damage the die itself).

Other than inadvertently sanding through half of the crystal's housing,
thus breaking one of the forks of the crystal, this was a success. (I
was prepared to decap one in acid had my attempt at physically removing
the epoxy package failed.) I slightly scratched the die itself while
separating it from the epoxy, but the die itself is clearly visible.
Based on a sample size of one and the markings on the die itself, it
appears the chip is authentic. The markings on the outside of the epoxy
package look a bit dubious and not like typical Maxim laser-markings, so
it's possible the chip was re-labeled at some point. I'll contact Maxim
to see if they can look up the lot information.

I used my 2 megapixel USB microscope to take some images throughout the
process that you might find interesting. The microscope has limited
resolution, particularly at high magnification, so some of the photos
may not be perfectly clear. I have access to a Zeiss petrographic
microscope at my work and will see if I can get some better images
tomorrow. I'll try to get high-quality images of the whole chip and
stitch them together into a larger composite.

Anyway, the photos are available at http://imgur.com/a/0zudj -- I will
add more photos from the petrographic microscope tomorrow. I focused
mainly on the markings on the die that indicated it was, in fact, a
Maxim chip but if there's any other region of the chip that you'd like
images of, please let me know and I'd be happy to take some more
pictures.

I hope you find this as interesting as I did.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] DS3231 drift over a year

[Pete Stephenson]

Hi Brooke,

No. I did not perform any software fine-tuning. My earlier tests using
my Arduino/Thunderbolt-based testing setup indicated its short-term
drift was <1ppm, so it didn't think it'd be worthwhile. After over a
year of testing, I'm even more impressed.

In addition, I forgot to mention that the DS3231 in question was in an
indoor environment but not one with particularly stable temperatures: in
winter, indoor temperatures dropped to around 15C, while in summer it'd
get up to 30C, with direct sunlight from the window shining directly on
the Raspberry Pi enclosure holding the device for several hours each
morning.

Cheers!
-Pete

-- 
Pete Stephenson

On Fri, Jul 14, 2017, at 06:56 PM, Brooke Clarke wrote:
> Hi Pete:
> 
> AFAICR the DS3231 has a software fine tune.  Did  you set that before the
> test?
> 
> -- 
> Have Fun,
> 
> Brooke Clarke
> http://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> 
>  Original Message 
> > Hi all,
> >
> > I use some DS3231 temperature-compensated real-time clocks with some
> > Raspberry Pis, particularly those that might not always have internet
> > access. About a year ago I wrote some code [1] to characterize the
> > behavior of these particular chips using my Thunderbolt as a reference,
> > using the Arduino/atmega328 as a glorified counter.
> >
> > As a somewhat longer-term test, I set the time on one of the DS3231s to
> > the correct time using GPS-synced NTP on one of the Pis, then set the
> > whole thing on the shelf for a bit over a year and forgot about it. If
> > relevant, the only power source was the CR2032 battery.
> >
> > I checked it today, and the clock had drifted 16 seconds since June 6th
> > of 2016 to now. That works out to around 0.5 ppm drift over that time.
> > The chip is specced to +/- 2ppm. Not bad for a cheap module of
> > potentially dubious provenance from eBay. For those who are curious, I'd
> > be happy to provide a link to the specific item I purchased; contact me
> > off-list for details.
> >
> > Cheers!
> > -Pete
> >
> > [1] https://github.com/heypete/Frequency_Counter_32kHz
> >
> 
> ___
> 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] DS3231 drift over a year

[Pete Stephenson]

Hi all,

I use some DS3231 temperature-compensated real-time clocks with some
Raspberry Pis, particularly those that might not always have internet
access. About a year ago I wrote some code [1] to characterize the
behavior of these particular chips using my Thunderbolt as a reference,
using the Arduino/atmega328 as a glorified counter.

As a somewhat longer-term test, I set the time on one of the DS3231s to
the correct time using GPS-synced NTP on one of the Pis, then set the
whole thing on the shelf for a bit over a year and forgot about it. If
relevant, the only power source was the CR2032 battery.

I checked it today, and the clock had drifted 16 seconds since June 6th
of 2016 to now. That works out to around 0.5 ppm drift over that time.
The chip is specced to +/- 2ppm. Not bad for a cheap module of
potentially dubious provenance from eBay. For those who are curious, I'd
be happy to provide a link to the specific item I purchased; contact me
off-list for details.

Cheers!
-Pete

[1] https://github.com/heypete/Frequency_Counter_32kHz

-- 
Pete 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.

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

[Pete Stephenson]

On Tue, May 9, 2017, at 09:52 PM, Ulf Kylenfall via time-nuts wrote:
>  
> Gentlemen.
> I am sure this has been asked before...
> I am looking to purchase a GPS receiver modulethat supplies a good/stable
> 1PPS outputwith as little (internally) generated jitter as possible.

How much jitter is tolerable? What's your budget?

The u-blox NEO-M8T is cheap (a PCB-mounted version is available for USD
$75, see [1]) and according to its brochure[2] it has +/-11ns jitter
with an absolute accuracy of 21ns. That's pretty good.

On that particular board, the PPS line is wired to an LED indicator
light so some light soldering would be needed to run a wire off of that
line to your HP 105B. Alternatively, the shop owner is happy to redesign
the board in whatever wiring configuration you need if you're willing to
buy 10 of the modified board. Keep in mind the connectors on the board
are 1.25mm, so you'd need to be sure you have appropriate connectors,
but those are cheap and readily available on eBay and the like.

Cheers!
-Pete

[1] 
[2]

___
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] u-blox NEO-M8T GPS initial tracking test

[Pete Stephenson]

On Sat, Feb 11, 2017 at 4:31 AM, MLewis <mlewis...@rogers.com> wrote:
> With this NEO-M8T, I've even turned off everything but min=4/max=8 for GPS &
> GLO, and it won't accept any configuration for Galileo, let alone enable.
> And that's with the required NEMA of 4.1.

What firmware version are you using?

Are you sure it's an authentic u-blox receiver? There's a bunch of
fakes out there that identify as u-blox but lack some functionality.

> But someone emailed me that I'm just banging my head against the wall as the
> M8 timing firmware won't config Galileo.
>
> They and others have had success configuring & enabling Galileo by changing
> the firmware to  UBX_M8_301 (from January 2016), although that is
> specifically identified as "It should not be used for Timing, Dead Reckoning
> or High Precision GNSS products."

I recently purchased an M8T and the UBX-MON-VER message shows the
firmware version as "EXT CORE 3.01 (41)". What version are you
running?

Galileo works fine on mine, with a few caveats:

1. There's only particular combinations of signals that can be
received simultaneously. For example, GPS, GLONASS, and Galileo will
work together, as will GPS, Galileo, and BeiDou, but GPS, GLONASS, and
BeiDou won't work together. See the user guide for the specific
combinations. Trying to enable invalid combinations will result in it
automatically reverting to the last working combination.

2. WAAS and EGNOS only seem to work with GPS. You can enable other,
non-GPS signals, but only GPS will have the corrections applied. The
other, non-GPS signals will be marked as "ready" but won't turn green
and be used in the calculations.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Version 5 wrong leap second

[Pete Stephenson]

On Sun, Jan 1, 2017 at 1:28 AM, Bill Beam  wrote:
> My LH v5.00 showed leap second as 00:00:60 on a Tbolt. Not good
>
> Previous June 2015 LH v3.10 correctly showed 23:59:60
>
> If interested, I have screen captures.

Now that you mention it, so did mine...
___
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] Temperature weirdness with Thunderbolt & Lady Heather 5

[Pete Stephenson]

On 12/16/2016 1:54 PM, wb6bnq wrote:
> Hi Pete,
> 
> Are you really at an altitude of 645 meters ?

Yes. That's the result of multiple surveys over a week a year or two
ago. I'm pretty sure the altitude hasn't changed since then. :)

I think Lady Heather shows the altitude as that above the WGS84 geoid
rather than above sea level, right? I'm trying to resolve some
discrepancies in reported altitude between my handheld Garmin eTrex 20,
Oncore UT+, and Thunderbolt (the Oncore and Thunderbolt share a split
signal from the same antenna).

> Also, it seems that your oscillator gain (currently at -5 Hz/v) may not
> be set right ?

That's the default for the Thunderbolt. I've tried tuning it a bit to
other values but it runs reasonably well at that value so I stick with it.

> Have you checked the power supply voltages and observed them on an
> oscilloscope to see if they are relatively clean and free of spurious
> junk ?

I've checked them with a multimeter and, while not dead-on at +5, +12,
and -12V, they're within the acceptable range mentioned in the
Thunderbolt manual. I have an oscilloscope and will probe them later
today when I get home from work.

> The available number of SATS  is quite low and could be a matter of
> concern.

The antenna is in a poor location, facing to the northwest. It's the
best I can do in this apartment, and the number of satellites seen is
typical for this location.

What's interesting is that the weird transients would occur at least
once every few hours over the last two days, but when I switched to
using a hardware serial port (as opposed to a genuine FTDI USB-to-serial
adapter connected to a hub) there hasn't been anything for the last 7
hours. I made no other changes to the setup.

The adapter had been working fine with no issues for at least a year and
I was using it for other devices as well with no problems. I had turned
off the Thunderbolt for a few months to save electricity (with my PhD
studies nearing a close I needed to focus and take time off from amateur
radio stuff) and just turned it on again in preparation for the leap second.

It's possible this may have simply been a communication error between
the Thunderbolt and the computer. I'll do more tests to find out.

Cheers!
-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.

Re: [time-nuts] Temperature weirdness with Thunderbolt & Lady Heather 5

[Pete Stephenson]

On 12/15/2016 8:35 AM, Mike Cook wrote:
> Hi Peter,
>  I also have a T-Bolt monitored by LH5 but am not seeing any glitches like 
> yours. No clear idea what may be the root cause, but from your screen dump 
> all the metrics are affected so it is not likely to be just a failing temp 
> sensor. Maybe something global such as power cleanliness. 

Hi Mike,

Indeed, that may be an issue. It uses some power supply from the Chinese
eBay vendor; the power supply looks to have been taken from some sort of
Cisco hardware and repurposed for the Thunderbolt.

I'll check it out later to see if anything weird is going on, but
finding odd transient issues is always fun.

Cheers!
-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] Temperature weirdness with Thunderbolt & Lady Heather 5

[Pete Stephenson]

Hi all,

I have a Thunderbolt and am running Lady Heather 5. I've been seeing
odd drops of ~0.7 degrees Celsius that slowly recover over around 10
minutes or so. This has happened 19 times in the last 36 hours.

Here's an image of what's happening:
http://imgur.com/a/LAvmU

The temperature in the room is not precisely controlled, but is
reasonably stable over a period of a few hours. There was no external
events (e.g. opening a window, a fan being turned on, etc.) that
correspond to those temperature drops.

Any idea what might be causing this?

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Satellite TV messed up, how is GPS time

[Pete Stephenson]

On Nov 4, 2016 19:45, "Bill Hawkins"  wrote:
>
> Satellite TV (Dish, Direct, etc) has been having trouble for 10 hours or
> so, sometimes losing some channels and occasionally all of them.
>
> Fox News is consistently down, so it could have a human cause, but Space
> Weather says we have unusual solar activity.
>
> I no longer have GPS time receivers, so I wonder how GPS is doing.

GPS timekeeping seems to be working fine here in Switzerland.

My situation here today was coincidentally similar to yours: a local
failure with some cableco equipment left me without TV or internet for a
few hours, so the GPS receivers were the only things keeping my network in
sync. No need for holdover, fortunately.

Cheers!
-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.

Re: [time-nuts] Need Time Help

[Pete Stephenson]

On 10/4/2016 6:41 AM, Larry Hower wrote:
> Hello to the List:

Hi and welcome!

> After a long and bitter struggle with XP and WIN 10, I am writing to ask
> for some help in solving some problems we have been having in our attempt
> to establish a very accurate time reference for use in EME activities.

You have a much higher budget for amateur radio gear than I do if you're
doing EME. I'm envious. :)

> We are hoping to achieve less than 5ms deviation, although anything below
> 15ms will be adequate for now.

This should be quite feasible, even with Windows.

That said, is such precision really necessary? I know that JT65 and JT9
both require "good" time sync, but is millisecond-level precision
needed? I've had good results for terrestrial contacts with time
differences ranging from 0.0 to 1.0 seconds. EME might require tighter
sync, of course.

> Specifically, we want to use a universal reference that will enable amateur
> radio operators in different parts of the world to start and stop their
> transmissions within a few milliseconds of a specific time. For example, I
> transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.

GPS should be that "universal" (really, planetary) reference.

> 1. We are using desktops and laptops in separate locations running XP or
> Win 10.
> 
> 2. We have used MS clock tools, including use of Boulder time servers,
> tried both host name and IP address, without reaching the goal.

No surprise. The built in Microsoft timekeeping software is "good
enough" for typical computing purposes (within a second or two) but
isn't really sufficient for your purposes.

Desktops will be easy, assuming they have a serial port or a serial
header on the computer itself. If the desktop only has a serial header,
a cheap adapter like

will connect the header to a standard serial connector.

Laptops might be harder. Using NTP software to a good NTP server on the
internet should get you within a few milliseconds. Synced to a good NTP
server on the LAN with the server using GPS+PPS should get you within a
millisecond.

> 3. We have set up some Serial GPS units with PPS and some USB GPS receivers
> (no PPS) and can get to about 0.2 sec but it is not trusted or close enough.
> 
> 4. We have set up a network time server with similar results.
> 
> 5. Deviation is measured using WSJT-X

> We believe that SDR processing can insert a delay of varying length,
> depending on the software, bandwidth, etc. Our SDR tests seem to have a
> delay of as much as 0.5 sec. And with sometimes variable results. We will
> see how SDRs can be used after we resolve the current issues.

This isn't really surprising. If the SDRs are connected via USB, there's
additional delays and jitter inherent in that connection.

> *Some time related hardware details*
> 
> *1. Global Star 4 USB and Serial Connections*
> 
> http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
> 
> We have 4 of these. Two are older models with serial connections. We have
> serial ports on some computers (XP and a new high-end laptop running WIN
> 10) so we are able to activate the PPS option. Two of the GStar are newer
> models with USB connections which are not able to use the PPS option.
> 
> We have tried NEMATime and NEMATime 2 software on this hardware without
> reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
> sec. Drifts.  Deviation is measured using WSJT-X.

The BU-353-S4 lacks a PPS line to precisely signal the start of each
second. (At least the specific one I have for mapping doesn't have that
option.) Although you may get somewhat better precision using the SiRF
binary stream, your deviation is about what I'd expect for a USB
receiver with NMEA output.

Simply put, without PPS you probably won't get closer than 250ms unless
you're quite lucky. Doubly so if you're using PPS-over-USB.

> *2. TimeNet NTP Device*
> 
> http://www.veracityglobal.com/products/networked-video-integ
> ration-devices/timenet.aspx
> 
> We have one of these TimNet units and it has been set up at 2 different
> locations on differing computers according to user instructions. We are
> using the TimNet software as DL'd recently from their web site. We get GPS
> “lock” and Time “lock” shown in the user panel but we do not have faith
> that this is carried into the system clock. Occasionally the "lock"
> indicators go blank but the time seems to be updated when the software is
> strted again (the updated is operation is show at the correct time.  We
> think the app needs some work. Deviation is measured using WSJT-X.  See
> later details.

I wonder if you'll get better results using Meinberg's Windows port of
NTPd:  -- you should
be able to configure it to query your TimNet device and get reasonably
good precision.

Re: [time-nuts] GPSDO - probably a stupid question.

[Pete Stephenson]

On Aug 17, 2016 09:04, "Peter Reilley"  wrote:
>
> As a neophyte, I was wondering: rather that trying to discipline an
external
> oscillator to create a GPSDO and produce a precise 10 MHz why not
discipline the oscillator
> of the GPS receiver itself?   This could be done with a varactor diode
across crystal of the
> receiver's oscillator.   Of course there are the same problems with
trying to servo this
> oscillator as there are trying to servo an external oscillator but there
are fewer parts.

It's a very good idea, and is precisely what the Trimble Thunderbolt does
with its 10MHz OCXO that it uses both as a system clock and a 10MHz output.

Cheers!
-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.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

I ended up doing just this and it worked out nicely. Using the timer
hardware as a counter freed up the CPU for other tasks and could run
in the background so I wouldn't miss any ticks. It turns out that
using the built-in timer hardware was a lot easier than using external
"jellybean" logic to accomplish the same thing, even if it took a bit
of reading to better understand it.

I whipped up a quick-and-dirty Arduino sketch that I've made available
at https://github.com/heypete/Frequency_Counter_32kHz/ for anyone
who's interested.

I make no claims to its quality, but I've tested it with runs from 10
seconds to 20,000 seconds and it seems to produce the expected results
on both a standard Arduino Uno and a bare 16MHz ATmega328P. Any
suggestions or improvements would be welcome.

Also, thanks to everyone for your assistance. It was a fun learning
experience and excursion outside the standard Arduino commands into
the mysterious depths of the datasheet and hardware registers.

Cheers!
-Pete

On Wed, Jun 29, 2016 at 6:49 AM, Scott Stobbe <scott.j.sto...@gmail.com> wrote:
> For pulse counting, the timer hardware is the way to go. Setup a 16-bit
> timer clocked off your DUT. Then input capture on your PPS edge. This
> leaves you plenty of processor time for string formatting and other tasks
> you may wish to perform.
>
> If you do the decimation as post-processing on your PC (i.e. log cycle
> count every PPS), you can use a zero-phase moving average filter, which may
> provide more visual insight over just a single data point every 1000s.
>
> On Tue, Jun 28, 2016 at 3:48 PM, Hal Murray <hmur...@megapathdsl.net> wrote:
>
>>
>> p...@heypete.com said:
>> > I have seen those, but I have little experience with PICs and the Wife
>> > Acceptance Factor of buying more stuff for a one-off measurement is low.
>>
>> The PIC family is very similar to AVRs.  The picPET and friends are 8 pin
>> DIPs so the Wife is unlikely to notice the additional clutter.
>>
>>
>> >> The PPS input on a PC may be be useful.
>> > Indeed. I normally use it for NTP.
>>
>> Than you want a second serial port for things like this.
>>
>> Or maybe you can use the parallel port if your system is old enough to have
>> one.  I haven't tried it, but I think Linux has a module that supports it.

-- 
Pete 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.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

On Tue, Jun 28, 2016 at 12:14 AM, Van Horn, David
<david.vanh...@backcountryaccess.com> wrote:
>
>
> p...@heypete.com said:
>> 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 takes about 5.125 microseconds[1]
>
> Huh?
>
> Instruction cycle time is 62.5nS for almost all instructions at that clock.
> That’s a pretty long ISR by my standards.

According to the "How long does it take to execute an ISR?" part of
http://www.gammon.com.au/interrupts, it takes 82 cycles total to
service an external interrupt (i.e. one triggered by an interrupt
pin), including the time needed to enter the ISR and to leave it after
it's done whatever you needed it to do. At 62.5nS for each clock
cycle, that's 5.125uS just to process the interrupt. That doesn't
include the time needed to execute whatever code you want it to do.

> 1: Reserve a couple of registers for handling data inside ISRs, avoiding push 
> and pop.
> 2: Reserve a register for holding SREG during the ISR.
>
> ISR:in STEMP,SREG
> At this point you can fearlessly trash SREG and ITEMP and ITEMP2
> Do Stuff using ITEMP and ITEMP2.
> Do as little as practical in the ISR, letting the non-isr code do the 
> heavy lifting.
> Out SREG,STEMP
> RETI
>
> Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 
> bit operations.
> Keep data you need FAST in registers in the low page, rather than in RAM.

Thanks! I think that may be a bit beyond my ken for the time being,
but I'll definitely keep it in mind for when I know more.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

On Mon, Jun 27, 2016 at 10:51 PM, Hal Murray <hmur...@megapathdsl.net> wrote:
>
> I assume you are doing this for fun.  That means you get to do whatever you
> think will be fun.

Indeed, this is strictly for fun. I have strange values for "fun".

> The DS3231 is pretty crappy by time nuts standards.  If you can also measure
> the temperature, you should be able to make neat graphs.  If you watch it as
> the temperature ramps up slowly, you should see a sawtooth pattern.  The
> crystal will track the normal freq/temp curve until the temperature changes
> enough for the correction logic to add in another step.

Oh, I know the DS3231 isn't terribly great. The datasheet calling it
an "Extremely Accurate...RTC/TCXO/Crystal" makes me laugh, as it's
tooting its own horn.

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.)

Still, the DS3231 is a reasonably accurate RTC, inexpensively priced,
is easy to interface with my Raspberry Pis, Arduinos, etc., and
provides a handy 32kHz output. It also has an internal temperature
sensor that it checks every 64 seconds, the output of which is also
accessible. Your idea of plotting the temperature vs. frequency is a
good one; I'll add it to the project list.

> Have you looked at tvb's PICPET and friends?
>   http://www.leapsecond.com/pic/picpet.htm
>   http://www.leapsecond.com/pic/picdiv.htm
>
> I think he has one that turns 32KHz into PPS.  You could feed that PPS into a
> picPET running off your Thunderbolt.

I have seen those, but I have little experience with PICs and the Wife
Acceptance Factor of buying more stuff for a one-off measurement is
low.

> If you have a spare counter, you can run that in frequency mode and feed that
> to a PC.

Alas, I'm ashamed to say I have no frequency counter at all.

> Where are you going to collect the data?

My plan was to have the ATmega328 simply output the data over a serial
connection so I can put it in a spreadsheet or something.

> The PPS input on a PC may be be useful.

Indeed. I normally use it for NTP.

Thanks for the advice!

Cheers!
-Pete

>
> p...@heypete.com said:
>> 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 takes about 5.125 microseconds[1]
> ...
>
> Use one of the counters to divide things down to a rate that is easier to
> handle.
>
>
>
> --
> 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.



-- 
Pete 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.

Re: [time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

Hi Nigel,

Using the internal timer as a divide-by-256 counter is a clever way of
doing things. Thanks!

I'm not familiar with using the timers as an input, so it looks like I
need to do some light, relaxing reading of the datasheet. From what I
can tell, using timer2 as an input ("asynchronously clocked") requires
that the microcontroller run on its internal RC oscillator rather than
the standard crystal/ceramic resonator since it shares the pins for
the timer input with the crystal.

I think I have some divide-by-n counters in discrete logic lying
around somewhere. As a quick test, I might just use those to divide
down the 32kHz signal by 10 and use a pin interrupt to count the
number of overflows. At the end of 1000 seconds (or whatever), I could
read the counter state. It's likely not as precise as using the
internal timer on the ATmega, and I'd need to make sure I read the
counter state quickly before any pins change, but it should get me
close.

Cheers!
-Pete

On Mon, Jun 27, 2016 at 9:46 PM, Nigel Vander Houwen
<timenuts-nige...@nigelvh.com> wrote:
> Pete,
>
> Instead of doing this in an ISR, feed the 32KHz into one of the timer/counter 
> inputs, and clock the timer off of that (probably TIMER2), then just have an 
> ISR for the overflow vector. So, when your X bit timer overflows, you can 
> just add that to your total, when you reach your 1000s (or whatever interval 
> you prefer, simply grab the current timer/counter value, add it to what 
> you’ve stored from the overflows, and you have your counts without all the 
> CPU load of an ISR for every cycle of 32KHz.
>
> Nigel
>
>> On Jun 27, 2016, at 08:22, Pete Stephenson <p...@heypete.com> 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

[time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Pete Stephenson]

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 takes about
5.125 microseconds[1] plus whatever's done in the interrupt routine
(e.g. incrementing the PPS counter). Would it make sense to use
interrupts for both the PPS counter and the 32kHz counter? Even if the
CPU is doing something, it knows an interrupt is pending so it
wouldn't miss any counts (assuming it could handle the interrupt
before the next one comes in). Alternatively, I could use a tight loop
to see if the pin for the 32kHz signal goes high and just use
interrupts for the PPS pulse. Time-sensitive code on microcontrollers
straddles the edge of my knowledge, so any advice would be
appreciated.

Seem reasonable? Any tips on doing this better?

Cheers!
-Pete

[1] http://www.gammon.com.au/interrupts
-- 
Pete 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.

Re: [time-nuts] How to achieve best results from U-Blox survey-in

[Pete Stephenson]

On Sun, May 8, 2016 at 7:25 PM, Bob Stewart <b...@evoria.net> wrote:
> Yes, disable all except GPS sats.  Also, turn off SBAS, set your max and min 
> number of sats (defaults are probably what you want), and the satellite 
> elevation mask.  The elevation mask defaults to 5, but can you really see 
> that low?

Hi Bob,

Out of curiosity, why would one turn off SBAS? My first instinct is
that SBAS support could only improve the accuracy of one's fix, as it
supplies additional correction information that improves on the normal
GPS signal. I would (perhaps naively) think that enabling SBAS during
the surveying would improve the results.

Of course, I could very well be mistaken and would be happy to be
corrected by those more knowledgeable.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Oncore battery

[Pete Stephenson]

I have several 5V Oncore UT+ receivers of the type that did not
include a rechargeable on-board battery, but didn't want to bother
with lithium primary batteries or rechargeable batteries and their
associated holders so I opted to use supercapacitors. Specifically, I
use the Panasonic EEC-F5R5U105 supercap with a capacitance of 1F and a
max voltage rating of 5.5V.

Charging is easy: I simply run 5V power through a diode and a resistor
sized to prevent exceeding the diode's current limit and the capacitor
charges in about 20-30 minutes. The diode prevents the supercap from
discharging through the resistor when the power fails.

I use a 1N4148 small signal diode rather than a 1N400x-series diode
because the 1N4148 has a smaller reverse leakage current. A 240 ohm
resistor keeps the peak current to 20mA (the diode can handle up to
200mA forward current) and the capacitor is charged up in about 20
minutes after power-on. Adjust the values for your specific needs.
Once charged, it maintains the Oncore's RAM for several weeks with no
power.

On Mon, Apr 25, 2016 at 12:25 PM, Azelio Boriani
<azelio.bori...@gmail.com> wrote:
> Panasonic ML621 or equivalent. Alternatively you can use the battery
> pin (pin 6): remove the onboard battery and use en external primary
> cell (CR2032 or equivalent). See pages 15 to 21 of the M12M user
> manual.
> <http://www.ilotus.com.sg/~ilotus/sites/all/themes/zeropoint/pdf/m12m/M12M%20-%20User%20Guide%20%28Ver%201.0.0%29.pdf>
>
> On Mon, Apr 25, 2016 at 2:11 AM, Joseph Gray <jg...@zianet.com> wrote:
>> Can anyone recommend a rechargeable lithium coin cell that is a direct
>> replacement for the ones that come on some Oncore receivers? Something
>> I can order from Mouser or Digikey, if possible.
>>
>> 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.



-- 
Pete 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.

Re: [time-nuts] RG6 or LMR400 for GPS Antenna (Symmetricom 58532A and T-bolt)

[Pete Stephenson]

On Wed, Apr 20, 2016 at 10:41 PM, Ryan Stasel <rsta...@uoregon.edu> wrote:
> All,
>
> I’m going to be installing a “permanent” antenna at home, and will need a run 
> of about 100ft to get from my workstation, to the mast I’ll be mounting the 
> antenna on (Symmetricom 58532A). I’ve seen some indication that both the 
> antenna and the Trimble Thunderbolt won’t have any issues with running over 
> 75ohm cable, but thought I’d ask the “experts” whether I’d be better off with 
> some RG6 Quad-shield, or LMR400 (I’ve got a local source that doesn’t know 
> what LMR400 is, or what it’s worth)?
>
> Obviously I’d prefer to run and crimp RG6, but if I’d be better off with 
> LMR400, I’d rather run that now than go back into the crawlspace again. =)

I'm hardly an expert, but according to the Times Microwave calculator
at <http://www.timesmicrowave.com/calculator/>, RG6 (of unspecified
type, presumably double not quad-shielded) at 1542MHz will have a loss
of 12dB over a 100ft length. LMR400 will have a loss of 5.2dB over
that same length.

The datasheet for your specific cable should show the loss figures.

The 58532A has an amplifier with a gain of >30dB, so it should work
well even at moderate cable lengths.

Keep in mind that the Thunderbolt Starter kit came with a Trimble
Bullet antenna (similar gain to the 58532A) and 75 feet of RG6; it'll
almost certainly work fine with 100ft of cable: the manual for the
Thunderbolt recommends RG-59 cable (presumably because it's cheap and
common) and states "The maximum practical cable run is just over 100
feet." A graph in the manual shows RG-59 losing 15dB over 100ft,

To be safe, you could always test it by connecting the 100ft of cable
to the antenna and putting it outside in a more convenient location
that has a similar view as your mast and seeing how the Thunderbolt
likes it.

Also, keep in mind that the 58516A splitter can have between +3 and -3
dB of gain depending on your luck as to how it was made. The manual
says that for relatively lossy RG-213 cable and the worst case
performance of the 58516A, you should be fine with up to 174 feet of
cable with no line amplifier.

> Also, if it helps, I’ll probably have a Symmetricom/HP 58516A at/near the 
> T-bolt so I can experiment with other GPS(DO)s as well (especially one of the 
> JRMiller boards I bought and built (but never finished) ages ago). Which 
> brings the question, will the T-bolt provide the oomph needed to power that 
> splitter and the antenna over that length of cable?

Short answer: Yes.

Longer answer: The Thunderbolt manual says it can supply 5V at up to
45mA. The 58532A antenna draws a max of 27mA (with 20mA being
typical). The 58516A splitter manual draws it uses 10mA. Worst case
usage is 37mA, which is within the limits for the Thunderbolt.

Considering both conductors, 100ft of LMR400 has a DC resistance of
0.304 ohms, so the voltage drop would only be 0.01V over that length.
That's well within specs for the antenna (5V +/- 0.5V) and the
splitter (4.5 to 30V).

The specs for Belden 1189AP quad-shield RG6/U cable with a copper-clad
steel center conductor and aluminum braid lists the total resistance
for both conductors to be 3.28 ohms over 100 feet. That's a worst-case
voltage drop of 0.12V over that distance, again within spec for both
devices.

In short, LMR400 would be a better choice in terms of both signal
attenuation and DC resistance, but the difference is more or less
academic and either cable should work fine.

Cheers!
-Pete

-- 
Pete 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] Can a Symmetricom 58532A antenna and ham radio transmitters coexist?

[Pete Stephenson]

Hi all,

I recently acquired a pair of Symmetricom 58532A antennas and so far
they work great with my setup (antenna --> Symmetricom 58535A splitter
--> [1] Thunderbolt and [2] other receivers that I swap out
occasionally).

I'm also an amateur radio operator and am looking to mount the 58532A
on a roof-mounted mast to get better coverage (right now it's outside
a window). Would the presence of nearby (either on the mast or within
20m of the mast) HF (3.5-30MHz) , VHF (~145MHz), and UHF (~430MHz)
transmitters cause any issues? My transmit power is typically around
5-20W on HF with peaks up to 100W and 1-5W on VHF/UHF. The HF antenna
is a simple wire dipole, not a high-gain directional antenna.

Naturally, I'd like to avoid damaging my GPS antenna or any of the
downstream devices.

Since the 58532A is currently mounted relatively close to the
splitter, I'm using LMR100A coax (it's lossy, but the short lengths
mean it's not an issue; the window mount makes the thinness of the
cable important) but for the longer run from the mast I'd used LMR240
or LMR400 as needed. I use the same type of cable for the HF radio.
Those cables are well-shielded (braid-on-foil) with >90dB shielding
attenuation, so I don't think signal leakage from or ingress into the
cables will be a big deal.

The datasheet for the 58532A specifies the out-of-band signal
attenuation is around 60dB at +/- 50MHz.

Many thanks in advance for the help.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Lightning 1, tbolt 0.

[Pete Stephenson]

On Apr 1, 2016 00:10, "Mark Sims"  wrote:
>
> On the subject of RS-232 converter chips...  I have had problems running
MAX3232's at 3.6V.   Sometimes they work, sometimes they don't.  Sometimes
they get freaky hot.   The general symptom seems to be no -6V output.

Are the MAX3232's genuine? I've had those issues with counterfeit ones but
the genuine Maxim ones have been rock solid for me.

Also, are the caps correctly sized? The advertised requirement for 0.1uF
caps is only for a particular voltage that I don't recall. Different
voltages in the range of acceptable voltages require different
capacitances; check the data sheet.

Cheers!
-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.

Re: [time-nuts] Next step up from basic GPS/PPS timekeeping

[Pete Stephenson]

On Wed, Feb 24, 2016 at 3:22 PM, Neil Green <nc...@hotmail.co.uk> wrote:
> I currently operate a stratum 1 NTP server in the NTP pool using a U-Blox 
> Max-7Q GPS module with PPS attached to, variously, a Raspberry Pi via GPIO or 
> a Celeron mini PC via serial DB-9. The machine does nothing but serve time to 
> the pool. Operating systems of choice are Debian or FreeBSD.
>
>
> What would be my next step up be, hardware-wise, in terms of improving 
> precision, stability, etc? A GPSDO? Budget is limited as far as these things 
> go - about £150 UK/$210 US.

For what purpose?

In my experience, NTP is able to sync other systems to within 10-100
microseconds of an NTP server on a LAN. The vagaries of the internet
mean that it's unlikely for NTP clients to sync any closer than a few
tens of milliseconds.

The Pi is a decent system, but its ethernet port is connected via USB,
so accuracy isn't as good as it would be on a different, non-USB
system. It's quite satisfactory for serving time to the internet using
NTP.

A GPSDO is handy if you need better precision (but the Pi and the
internet can't deliver that better precision, so this is not a major
advantage for NTP) or holdover in case of issues with GPS. Many also
emit a stable reference frequency: this is useful for providing a
common reference for test equipment like frequency counters, or for
radio/microwave systems that need very high stability. If you don't
have such needs, a GPSDO will be of limited use.

> I appreciate this is basic stuff compared to the usual discussions but this 
> doesn't seem the right question to ask on the NTP lists. Any help 
> appreciated. Thanks.

Welcome, and thanks for providing a server in the NTP pool.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Thunderbolt "osc age alarm", where to get replacement oscillator?

[Pete Stephenson]

On Sun, Nov 15, 2015 at 3:13 AM, Mark Sims <hol...@hotmail.com> wrote:
> My bet is was just a power glitch or a corrupted message that raised the 
> alarm and that your unit is OK.  If the error reoccurs then you may have a 
> hardware problem.

After some further poking and prodding, I think you're right: I had
powered-off the unit for a few months and had plugged it back in. The
alarm lit up on the first time it was back on. The serial-to-Bluetooth
connection probably didn't help, though I've only ever seen it lose a
packet here or there and had never seen it flip a bit in
mid-transmission.

Power-cycling the Tbolt fixed the problem and I verified that
everything is working ok over both wired and wireless connections.

Thanks to all for the help. Fortunately, it looks like a false alarm.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Thunderbolt "osc age alarm", where to get replacement oscillator?

[Pete Stephenson]

On Sat, Nov 14, 2015 at 12:00 AM, Bob Camp <kb...@n1k.org> wrote:
> Hi
>
> First thing to check is that it really *is* at limit. There apparently are a 
> few odd things
> that can trigger the alarm.

What sort of odd things might cause that?

It was weird: yesterday LH highlighted the DAC value which was around
0.38V (I didn't write down the number, alas) and the "osc age alarm",
both of which were red.

I did a factory reset for good measure and things cleared up. The DAC
value is now around 0.42V and the alarms are off and everything is
green. The OSC plot in LH tracks the DAC value, so it appears that the
Thunderbolt is able to control the oscillator reasonably well.

What's the max range that the DAC can produce? +/- a volt? Two?

> The OCXO’s out of the TBolt are sold on the auction sites from time to time. 
> They
> seem to go for < $40 delivered. The footprint on the OCXO is pretty standard. 
> You
> can tune the parameters on the TBolt. There are a lot of other choices. About 
> the only
> real limit is the 10 MHz frequency.

Cool. I see a bunch of Trimble and non-Trimble oscillators for sale on
eBay but would hate to get the wrong one. Does it need to be the exact
same model number, or are they usually all compatible (assuming that
they are 10MHz and use the same voltage for the oven and other
electronics?

Cheers!
-Pete

-- 
Pete 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] Thunderbolt "osc age alarm", where to get replacement oscillator?

[Pete Stephenson]

Hi all,

Lady Heather just reported that my Thunderbolt's "osc age alarm" just activated.

The manual tells me this means that the oscillator control voltage is
at a rail and that the oscillator should be replaced. It says this
shouldn't be needed during the first 12 years of service, but mine is
~17 years old, so its time may have come.

Where can I find a suitable replacement oscillator? Is there a
recommended part number? If the original part is no longer available,
what is a good substitute?

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] syncronized clocks

[Pete Stephenson]

ernal
> clock? Since I am not building logic circuits to do the counting, I think
> it is imperative that I have a good cpu clock.

As for the external clock, it depends on the micro. AVR micros like
the attiny85, atmega328, etc. can use external clocks for better
stability.

> http://navspark.mybigcommerce.com/ns-t-precision-timing-mode-gps-receiver/
>
> It is really cheap, and it claims 6 nsec (1-sigma) timing accuracy, but yet
> I would still need a more expensive gear to test it.

Shiny. That's not a GPSDO, in that it only provides an accurate PPS
signal when it has reception (there's no holdover capability), but it
seems pretty cool. I like that it emits both PPS and a
user-configurable frequency output -- that'd be really handy as a
compact, internal frequency reference for ham radios.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] syncronized clocks

[Pete Stephenson]

ddition to 1PPS. However, they tend
to be intended for telecom use and so require a little bit of tweaking
to work well with other equipment: for example, the Thunderbolt's 1PPS
signal is intended to connect to a device with 50 ohm impedance using
coaxial cable. If the device it's connected to doesn't present a 50
ohm impedance, the 1PPS signal will "ring".

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] A few questions about Tboltmon

[Pete Stephenson]

The GPS satellites are not geosynchronous; they move with an orbital period
of 12 hours, so their position in the sky is constantly changing. However,
they return to the same position in the sky (modulo repositioning) twice
per day.

It sounds like your Thunderbolt has a saved location that differs from your
own location, so its calculations regarding timing are erroneous. Based on
its (incorrect) location it thinks there are certain satellites overhead
and will only look for those. Since it is not at that location that choice
of satellites is not a good one and won't match well with what is overhead
at your location.

You should do a factory reset to clear the saved location and reset
everything to defaults. This should cause the Thunderbolt to do a
self-survey (this takes a bit less than an hour) to accurately determine
its location. Once that's done everything should just work.

Cheers!
-Pete
On Aug 6, 2015 6:15 AM, Chris Waldrup kd4...@gmail.com wrote:

 Hi,


 I got my new Thunderbolt up and running this past weekend but I have a few
 questions. I understand Lady Heather is a better program, and I have
 downloaded it. However right now I am trying to get things right with
 Tboltmon first. I had used it with my previous GPSDO, a Starloc II. I hate
 to say but the Starlic just worked, so I didn't pay much attention to
 Tboltmon other than to see that I was seeing satellites. Please forgive me
 if some of the questions may sound simplistic, but I'm sort of new to being
 a time nut.
 The Thunderbolt is brand new in package. I purchased a Power One open
 frame supply from EBay that was also new old stock. Before connecting it to
 the Thunderbolt, I went ahead and ordered new electrolytic caps from Mouser
 and spent last Friday night recapping the Power One box. I measured the
 outputs with a DMM to make sure I had 5 V, -12 V and 12 V.
 Noticing that in my old antenna location I could now only see 1-2
 satellites (trees have grown a bit) I moved the antenna to the roof of my
 house, attached to a plumbing vent pipe, with a completely open view of the
 sky here on top of a mountain in Tennessee.


 Here's what I am noticing:
 To start with I simply turned on the Thunderbolt on Saturday morning
 without doing a warm or cold reset. Within a few minutes, I was seeing six
 or seven satellites, with the SV boxes lit up green with various numbers
 which I assume are satellite ID numbers. When I woke up Sunday I was down
 to seeing only two satellites. The numbers listed were different than the
 ones I saw before I went to bed Saturday.  But when I unplugged the AC
 power from the Thunderbolt and plugged it back in, I was back to six
 satellites.
  I had thought that the GPS satellites I am able to see from my location
 are fixed 24/7. Do they move and different satellites come into view with
 rotation of the earth?
 I did a warm reset when I got up at 4:45 this morning and when I got home,
 four satellites were still green on Tboltmon. About an hour ago I went
 ahead and did a cold reset.
 I now have 6 satellites where the SV is green, and one with a yellow SV
 with a value of 7.0.
 All critical alarms are green, and all minor alarms are green except
 position questionable which is yellow. That has been yellow since Saturday.
 Under the Disciplining status, Mode is (0) Normal and Activity is (0)
 Phase Locking.
 The Timing Outputs are all over the place and have been since Saturday.
 Twenty minutes ago I got:
 PPS  -106588.28 ns GPS
 10 MHz  166.08 ppb


 So far today I have gotten the following ppb readings:
 -41.48
 374.30
 0.48
 0.70


 Should the Timing output variance concern me?


 Thanks in advance for any help or advice.


 Chris
 KD4PBJ
 Monteagle, TN



 —
 Sent from Mailbox
 ___
 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 wrist watch

[Pete Stephenson]

On Tue, Jul 7, 2015 at 12:45 AM, D W watsondani...@gmail.com wrote:
 With my new found interest in time nuttiness I thought I should upgrade to a 
 decently accurate watch. I had some features I was looking for and settled on 
 a Casio Wave Ceptor. My second choice was an Eco Drive, but the Casio had the 
 right mix of features at a good price.

 As I was sitting outside reading the manual after buying it, I laid it flat 
 on the table and started a manual sync to WWVB. The UI is pretty intuitive 
 for having so few buttons and indicators. It quickly told me that it had 
 found a stable signal, and about six minutes later it was synced. Pretty cool.

 Anyone know what the drift is like in this watch if it can't find the signal 
 for several days/weeks? I would hope that actual performance is a little 
 better than the +/- 15 sec per month stated in the manual. I should trap it 
 in a faraday bag for a while to test it...

I have a similar watch (the G-Shock GWM850-1 [1]) and have found it to
keep within one second (compared visually to synchronized railway
clocks in the UK and Switzerland) after 2 weeks of no signal.

For reference, I take off the watch when showering but otherwise wear
it continuously so the temperature of the watch is fairly consistent.

They're pretty solid watches, though I find it to be a bit finicky
when signal is marginal during the day: after locking to the signal it
will switch between L1 (the lowest signal strength) and L3 (the
highest) with a period of 20-30 seconds, which means it never syncs.
At night it's much better, and typically syncs after only two minutes.
Still, considering the whole thing fits on one's wrist and runs on a
solar-charged battery, it's remarkably advanced and I recommend it.

Cheers!
-Pete

[1] http://www.casio.com/products/Watches/G-Shock/GWM850-1/

-- 
Pete 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.

Re: [time-nuts] Motorola Oncore UT+ firmware upgrade backup power questions

[Pete Stephenson]

The Oncore driver can load certain parameters (e.g. the fixed
location, mode of operation, and -- I think -- the current estimated
time) into the Oncore receiver's RAM, but doesn't do anything to the
firmware on flash.

Cheers!
-Pete

On Sun, Jun 21, 2015 at 1:06 AM, Hal Murray hmur...@megapathdsl.net wrote:

 gign...@gmail.com said:
 I didnt see this well answered - the device loads firmware at each start
 cycle.  If i am not mistaken you can even use ntp.

 I just scanned the ntp source code for the Oncore driver.  I didn't see any
 hints of loading firmware.  There is code to read the firmware version.

 --
 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.



-- 
Pete 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.

Re: [time-nuts] Lady Heather Doppler

[Pete Stephenson]

On Wed, Jun 17, 2015 at 7:06 AM, Bryan _ bpl...@outlook.com wrote:
 All:

 Excuse the newbie question. but what is the meaning of the doppler reading in 
 the satellite view. Curious as to what it represents. What is considered a 
 good value when a satellite is being monitored. etc, I have seen values range 
 from - to +. there doesn't seem to be a correlation to doppler 
 readings and signal strength. I have seen both negative and positive numbers.

I believe it's the doppler shift of the frequency used to transmit the
GPS signal. Positive values, I think, represent when the satellite is
moving toward the receiver, while negative values means it's moving
away.  If I'm incorrect, I welcome any corrections. I'm unclear on the
units or scale of the reported number: I think it's kilohertz, but
confirmation by more knowledgeable people would be welcome.

Does anyone have any more details on the Code and Clock Bias
columns and what they represent? Similarly, what is the Bias Rate
(not seen with the Thunderbolt, but Lady Heather reports the bias rate
when using a Resolution T)?

Thanks!
-Pete

-- 
Pete 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.

Re: [time-nuts] PPS for NTP Server - How Close Is Good Enough?

[Pete Stephenson]

On Wed, Jun 10, 2015 at 6:30 AM, Ed Armstrong eds_equipm...@verizon.net wrote:
 Hi, this is my first post ever to a mailing list, so if I'm doing anything
 wrong please be gentle with your corrections :-)

Welcome!

[snip]

 My next step was to find out where the even second pulse entered the output
 circuitry. I then broke the trace taking the even second into the output
 circuitry, and ran a piece of 30gauge wire wrapping wire from the via at
 test point 33 to the via at the input to the output circuitry. The wire fit
 so perfectly it felt like the vias were made for just this purpose :-) Now
 I've got a very nice PPS signal available both at the front jack and at the
 backplane connector in the rear of the unit.

Very clever.

 OK, here is the actual question. Do you think it is OK to consider a pulse
 which arise 250 ns early to be close enough? And no, I am not forgetting
 about that 3 ns, there is about 3 ns of delay added by the output circuitry.

Depends on your needs, of course. For NTP, 250ns will be essentially
unnoticeable. For other purposes, it might be an issue, but not for
NTP.

NTP typically works on the micro- and millisecond level. Any offset or
jitter on the nanosecond level will be lost in the noise, so to speak:
the interrupt latency of the Pi will far exceed any nanosecond-level
offset.

Cheers!
-Pete

-- 
Pete 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] METAS tour report (was Tour of METAS (Swiss Federal Institute of Metrology) time lab: any questions or requests?)

[Pete Stephenson]

On 5/7/2015 11:38 AM, Pete Stephenson wrote:
 I recently inquired about taking a tour of the METAS time lab[1] and
 they said they'd be willing to show me around.
 
 Is there anything in particular that fellow time-nuts would be
 interested in me asking them about or (if possible) photographing?

Hi all,

On Friday I toured the METAS Time  Frequency lab with two others:
Patrick, a colleague from work and Atilla, a fellow time-nut.

I'd like to report a bit about what we learned today that may be of
interest to other time-nuts.

UTC(CH) is composed of an ensemble of four commercial HP 5071A cesium
clocks and an active hydrogen maser.

METAS changed the definition of UTC(CH) several years ago. Details
regarding the old and new systems were presented at a conference in
2006. The only archive I can find of the conference paper is, for some
reason, available at a US military website[1]. I've mirrored the paper
at my site[2].

I'll quickly summarize the two systems below:

= Old Definition of UTC(CH) =

UTC(CH) had previously been defined as a computed paper clock named
UTC(CH.P) which was the weighted average of the four HP 5071As and the
maser. This paper clock was steered monthly to track UTC.

In the old system, the maser (the reference clock) drives a micro phase
stepper and the output of the stepper is steered to the paper clock to
form UTC(CH.R), the hardware real-time realization of UTC(CH). UTC(CH.R)
is connected to the distribution hardware.

Using a paper clock had two main advantages:
- It's more stable than any of the individual clocks in the ensemble.
- It is tolerant of hardware failure of the non-reference clocks. For
example, if the ensemble normally has N clocks and one fails, it
continues to work with N-1 clocks.

However, there are several disadvantages: UTC(CH.P) was computed for
only a single epoch each day so time measurements made at other epochs
can only be related to UTC(CH.P) via interpolation. Also, if the
reference clock fails the whole system is disrupted.

= New Definition of UTC(CH) =

In the new system, UTC(CH) is defined in real-time without interpolation
instead of being computed for a single instant each day.

UTC(CH) is now defined as a hardware master clock named UTC(CH.RT).

To quote the paper, The UTC(CH.RT) hardware definition of UTC(CH) is
chosen from one of two independent master clocks: UTC(CH.A) and
UTC(CH.B). Each is the output from a DDS synthesizer, used as a
MicroPhase Stepper (MPS). Each is driven by one of the free-running
atomic clocks, and steered to track the paper time scale UTC(CH.P).

Auto-sense Fault Switches (AFS) are used to choose UTC(CH.RT) between
the A/B master clocks. The hardware redundancy between UTC(CH.A) and
UTC(CH.B) has two advantages. One is reliability: if one master clock
fails, switching to the backup master clock is instantaneous. The second
is continuity of service: if some maintenance of one master clock
becomes necessary, for example for the purpose of calibration, it is
possible to switch to the other master clock at one’s convenience
without interruption of service.

Typically clock A is the hydrogen maser and clock B is an HP 5071A. In
addition to both being reference clocks for UTC(CH.RT), both contribute
to the paper time scale.

= Clock Vault =

In addition to the maser and four HP 5071A clocks, there are several
other clocks that are used for various purposes but which do not
contribute to UTC(CH): a passive hydrogen maser, several rack-mountable
quartz oscillators, and at least one rubidium oscillator. All the clocks
are kept in a single thermally-regulated clock vault in the basement at
METAS.

While it won't be used to contribute to UTC(CH), a continuous-beam
cesium fountain is being constructed in the room next to that containing
the UTC(CH) clocks. Details of this clock are available at [3] with a
mirror at [4].

Although the Swiss are well-known for their fine watches and other
timekeeping devices, METAS is a rather small national time lab (compared
to, say, PTB, NIST, or USNO) with comparatively limited resources.

Their primary function is to provide a service to customers or users
rather than advance the state of the art of timekeeping: for example,
they provide NTP service to the public and UTC-traceable calibration
service to paying customers.

In the past they were the time source for the long-wave time signal
radio station HBG, but that service was discontinued in 2011. They are
doing some interesting research in regards to time and frequency, but
that is not their main focus.

= Questions  Answers =

Several fellow time-nuts had sent me questions that they wanted me to
ask METAS. Here's the questions and answers, paraphrased from my
shorthand notes:

1. Q: How does METAS generate UTC(CH)?

A: With four HP5071As and a hydrogen maser that contribute to a paper
clock. See above, [1], or [2].

2. Q: How is the Swiss time scale linked to the rest of the world? GPS?
Two-way satellite

[time-nuts] Trimble Thunderbolt firmware chip information

[Pete Stephenson]

Hi all,

Does anyone happen to have a copy of the latest firmware image file
(version 3.0, I think) for the Trimble Thunderbolt (not the
Thunderbolt-E, but the original Thunderbolt)?

I contacted Trimble and they were unwilling to provide me a copy
because the device is no longer in the warranty/service period, which
seemed strange because they had firmware for other unsupported
products like the Resolution-T available on their website.

Additionally, does anyone have any details about the Trimble-branded
CPU chip in the Thunderbolt? In particular, I'm interested in knowing
what instruction set it uses.

Thank you.
-Pete

-- 
Pete 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.

Re: [time-nuts] Small time server for mobile use.

[Pete Stephenson]

On Tue, May 12, 2015 at 7:11 PM, Mark Spencer m...@alignedsolutions.com wrote:
 Hi sorry for a possibly OT post.
 Has anyone had practical experience with small commercially available time 
 servers / ntp servers suitable for mobile  use in a vehicle.

I don't know about any commercially-available products, but it sounds
like it'd be pretty straightforward to do with a Raspberry Pi or
something similar if you don't mind a little bit of DIY.

What constraints do you have on budget, size, power requirements, and cooling?

  The use case is I am in need of an accurate (ie.  within 100 ms) time source 
 for several pc's in moving vehicle.Being able to run directly off a 13.8 
 or 28 VDC  source would be a major plus but AC power is also available.

The Pi runs on 5V DC. DC-DC buck converters that can convert 7-35V to
5V DC are cheap, efficient, and widely available. Shouldn't be a
problem.

 Hold over if there are gaps in GPS coverage is also a major plus.

How long would you need holdover? Seconds or minutes (e.g. driving
through a tunnel)? Hours? Days? Would the computers in the vehicle be
subject to large temperature shifts?

A Pi should be able to handle +/- 100ms of holdover in the
minutes-to-hours range using NTP.

 We already have a GPS with a 1 pps output, but an integrated box with it's 
 own GPS would be best.

A tiny integrated module like the Adafruit Ultimate GPS breakout[1] is
cheap, handy, and emits a 1PPS signal. It's also extremely small and
can be purchased in hat form[2] that mounts directly to the Pi.

Cheers!
-Pete

[1] https://www.adafruit.com/products/746
[2] https://www.adafruit.com/products/2324

-- 
Pete Stephenson

On Tue, May 12, 2015 at 7:11 PM, Mark Spencer m...@alignedsolutions.com wrote:
 Hi sorry for a possibly OT post.
 Has anyone had practical experience with small commercially available time 
 servers / ntp servers suitable for mobile  use in a vehicle.

  The use case is I am in need of an accurate (ie.  within 100 ms) time source 
 for several pc's in moving vehicle.Being able to run directly off a 13.8 
 or 28 VDC  source would be a major plus but AC power is also available.

 Hold over if there are gaps in GPS coverage is also a major plus.

 We already have a GPS with a 1 pps output, but an integrated box with it's 
 own GPS would be best.

 Yes I am aware I could feed a 1 pps signal into a laptop and use that as a 
 time server and I may end up going that route.

 There is a small Ethernet LAN in the vehicle.  The pc's currently get their 
 time via a wireless connection to various NTP servers.   I need to be able to 
 ensure accurate time on the PC's if there is no wireless coverage.


 This is for a one off project so piecing together various parts is an option 
 but a single box COTS solution would be nice.  I've found a few candidates 
 via web searches but would welcome any feed back.

 Thanks in advance

 Mark Spencer
 ___
 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.



-- 
Pete 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] Tour of METAS (Swiss Federal Institute of Metrology) time lab: any questions or requests?

[Pete Stephenson]

Hi all,

I recently inquired about taking a tour of the METAS time lab[1] and
they said they'd be willing to show me around.

Is there anything in particular that fellow time-nuts would be
interested in me asking them about or (if possible) photographing?

Cheers!
-Pete

[1] http://www.metas.ch/metas/en/home/fabe/zeit-und-frequenz.html

-- 
Pete 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.

Re: [time-nuts] Tour of METAS (Swiss Federal Institute of Metrology) time lab: any questions or requests?

[Pete Stephenson]

On 5/7/2015 1:22 PM, Bob Camp wrote:
 Hi
 
 I guess on a general level:
 
 1) How do they generate the Swiss version of UTC (fleet of hydrogen masers 
 run into to a .. :)

According to their website they use an ensemble of commercial cesium
clocks (they show some photos of HP 5071As) and a hydrogen maser. I'll
be sure to ask them for details.

 2) How do they link that version of UTC with the rest of the world? (BIH etc)

I'm not familiar with that particular acronym (BIH), but I am curious
how they link their version of UTC.

 Not so much a picture of this or that. More a tour of an entire process. 

Right.

Cheers!
-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.

Re: [time-nuts] GPS week rollover

[Pete Stephenson]

On Wed, May 6, 2015 at 3:39 PM, Tom Van Baak t...@leapsecond.com wrote:
 Hi Pete,

Hi Tom,

 Yes, we are very fortunate that a fellow time-nut took the time to test a 
 TBolt with a GPS simulator:
 https://www.febo.com/pipermail/time-nuts/2014-September/086664.html

That's the link I included in my message. :)

I'm quite grateful for Matthias's work with the GPS simulator, but I
was unclear about a few details. For example, he doesn't mention if
tested the Tbolt as it transitioned over the overflow point itself (to
tell if the Tbolt will maintain continuity and keep working as
expected) or if he tested it by setting the date on the simulator to
dates before and after the overflow point. Similarly, it's unclear if
manually priming the Tbolt with the current date/time will allow it to
determine the correct epoch or if it will simply use the 1997-2017
epoch baked into the firmware regardless of user input.

 He also reported that the 1 PPS and the 10 MHz were undisturbed by the 
 rollover. Yes, the date/time gets set back but Mark Sims updated Lady Heather 
 to compensate. So as far as we know, all is well with that GPSDO in 2017 and 
 2019 and beyond.

Excellent, particularly regarding 1 PPS and 10 MHz outputs. It'd be
nice if the unit itself would output the correct date rather than
needing to rely on external software to interpret and correct the
output.

 Note also that the TBolt handles rollover in a deterministic way and thus 
 lends itself to epoch correction (since it's based on GPS time).

Excellent.

 The problem with the TymServe is that, unless they release the source code 
 for the broken algorithm, its handling of epochs is not deterministic (since 
 it's based on the count of leap seconds and can hop forward or back 1024 
 weeks without warning).

Ouch. No fun at all.

Hopefully more modern receivers are more clueful about handling
rollovers. At minimum, they should accept user input telling them what
the current epoch is.

Cheers!
-Pete

 - Original Message -
 From: Pete Stephenson p...@heypete.com
 To: Discussion of precise time and frequency measurement 
 time-nuts@febo.com
 Sent: Wednesday, May 06, 2015 5:19 AM
 Subject: Re: [time-nuts] GPS week rollover


 On Wed, May 6, 2015 at 6:48 AM, Mark Sims hol...@hotmail.com wrote:
 Well,  a big one will be in 2017 when all our Tbolts roll over.I have 
 included some code in the next version of Lady Heather to compensate.  If 
 it detects a year from the unit before 2015,  it converts the date/time to 
 Julian,  adds 1024 weeks worth of seconds,  and then converts the date/time 
 back to Gregorian.  You can also specify a user defined rollover adjustment 
 (in seconds).  One issue that I have seen is the Tbolt occasionally 
 spitting out a bogo-year and triggering a false/premature rollover...  
 still trying to track that down.

 People using Tbolts for things like NTP servers will have to implement a 
 similar fix...

 I assume the Tbolt rollover will be problematic for those who start
 their Tbolt completely cold (no time, almanac, or ephemeris) and
 without any non-GPS input, but how will the Tbolt behave in situations
 where the user initializes the Tbolt with the then-correct
 post-rollover date and time? For example, one might use Tboltmon and a
 wristwatch to set the approximate time on the unit and then let it
 figure out the precise time from GPS.

 Also, will the rollover cause time-of-day problems for running Tbolts?
 That is, would they ride through the rollover and continue to
 provide the correct date and time as expected (that is, they recognize
 that a rollover occurred and keep working normally so long as they're
 not cold-reset) or would they immediately jump back to December 14,
 1997 (the Thunderbolt zero date)? According to
 https://www.febo.com/pipermail/time-nuts/2014-September/086664.html
 it looks like they'll output the incorrect date as they cross over the
 rollover point. That's not good.

 --
 Pete 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.



-- 
Pete 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.

Re: [time-nuts] GPS week rollover

[Pete Stephenson]

On Wed, May 6, 2015 at 6:48 AM, Mark Sims hol...@hotmail.com wrote:
 Well,  a big one will be in 2017 when all our Tbolts roll over.I have 
 included some code in the next version of Lady Heather to compensate.  If it 
 detects a year from the unit before 2015,  it converts the date/time to 
 Julian,  adds 1024 weeks worth of seconds,  and then converts the date/time 
 back to Gregorian.  You can also specify a user defined rollover adjustment 
 (in seconds).  One issue that I have seen is the Tbolt occasionally spitting 
 out a bogo-year and triggering a false/premature rollover...  still trying to 
 track that down.

 People using Tbolts for things like NTP servers will have to implement a 
 similar fix...

I assume the Tbolt rollover will be problematic for those who start
their Tbolt completely cold (no time, almanac, or ephemeris) and
without any non-GPS input, but how will the Tbolt behave in situations
where the user initializes the Tbolt with the then-correct
post-rollover date and time? For example, one might use Tboltmon and a
wristwatch to set the approximate time on the unit and then let it
figure out the precise time from GPS.

Also, will the rollover cause time-of-day problems for running Tbolts?
That is, would they ride through the rollover and continue to
provide the correct date and time as expected (that is, they recognize
that a rollover occurred and keep working normally so long as they're
not cold-reset) or would they immediately jump back to December 14,
1997 (the Thunderbolt zero date)? According to
https://www.febo.com/pipermail/time-nuts/2014-September/086664.html
it looks like they'll output the incorrect date as they cross over the
rollover point. That's not good.

-- 
Pete 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.

Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix

[Pete Stephenson]

On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper acoo...@keck.hawaii.edu wrote:
 We also ran into the TS2100 1995 bug this weekend.  For us the consequences 
 are a bit more severe...  The telescopes will not point to the right location 
 in the sky without accurate time!

Ouch. I have some friends who work at the Subaru telescope. I'll check
in to see if they're affected.

 For now we have configured a temporary fix...  We set up two units, 
 previously our primary and hot spare.  The first unit is set to use GPS, 
 which of course has the correct time but the wrong date.  The first unit is 
 sending a 1PPS signal to a second unit which is set to 1PPS input mode with a 
 manually set date and time.  We now have all of the IRIG and NTP capability 
 we need and the correct date.

Out of curiosity, is there no way to prime the device with the
current date/time (e.g. from a wristwatch) so it can interpret the GPS
week information correctly? I recall that several other devices have
that ability.

Is there a list of other common time-nut devices that are susceptible
to similar issues? Lots of time-nuts use surplus equipment that's no
longer supported and it'd not be fun to have them stop working.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Tuning a Trimble Thunderbolt

[Pete Stephenson]

On Thu, Apr 23, 2015 at 12:33 AM, Bob Camp kb...@n1k.org wrote:
 Hi

 Looking at that screen shot, something is *very* wrong with your GPS 
 reception. Your GPS
 is 10X worse than it should be.

You're right. The interference from the nearby Oncore UT+ seems to
have been the problem. Since I moved the antennas further apart the
signal strength for satellites in view of the Tbolt is 35-45 dBc and
it can routinely view 6-7 satellites simultaneously -- this is
essentially the same performance as when the Oncore is powered off and
the antenna removed, so I'm happy.

After moving the antennas further apart and doing a standard
2000-point site survey the 100-200ns phase offset spikes that occurred
when satellites were added/removed from the solution dropped to
5-10ns. The oscillator offset also decreased. I'm now doing a longer
precision survey to hopefully smooth those out more and get a better
average position over a few satellite orbits.

 I would bet that the amp on the “Oncore” antenna is oscillating. It may do it
 intermittently. The frequency may swing back and forth through the GPS band. 
 It
 may be the source of your GPS problem.

Interesting. I have a second identical Oncore UT+ and antenna and will
do some more tests to see if one of them is just being noisy, if it's
a fault of the Oncore module itself, or the antenna.

Many thanks to everyone on the list for the insight and assistance.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Tuning a Trimble Thunderbolt

[Pete Stephenson]

On Thu, Apr 23, 2015 at 3:16 AM, Arthur Dent golgarfrinc...@gmail.com wrote:
 wb6bnq  wrote:
 “I am a little confused.  In your screen shot the overdetermined clock
 says you are at precisely 46.00 North by 7.0 East at 547
 Meters.”

 I think I have the answer. I know when I was selling Tbolts I would
 PhotoShop out every digit after the decimal point so the displayed
 JPEG wouldn’t show my location. If Lat. was exactly 46.00  then
 it would show that, not just 46.(blank).

Precisely.

My apologies for the confusion: perhaps I shouldn't have used a black
rectangle on a black background to obfuscate the location.

The reported altitude at my location (which is just a few km outside
downtown Bern) is plausible. After additional surveys it shows as
being closer to 620m.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Tuning a Trimble Thunderbolt

[Pete Stephenson]

On Tue, Apr 21, 2015 at 1:23 PM, Bob Camp kb...@n1k.org wrote:
 Hi

 inevitably on these devices, there is a marketing brochure that hits the high 
 points
 in the specification. That information is public and intended to get “buzz” 
 going on
 the product. Once an OEM gets serious about the product, (the TBolt is 
 targeted
 at OEM’s) a detailed specification gets written. It may be in the form of 
 detailed
 specs or in the form of a test regime / service scenario the unit is expected 
 to
 perform in. That document is rarely available to the public.

D'oh.

 How are you measuring the holdover performance? You mention that you have
 no counter and no other standards.

When one uses Lady Heather to switch the Tbolt to manual holdover,
Lady Heather continues to monitor the offset between the oscillator
and GPS. No doubt this method isn't nearly as good as using a counter
or some other standard, but it's what I have.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Tuning a Trimble Thunderbolt

[Pete Stephenson]

On Wed, Apr 22, 2015 at 1:47 PM, Bob Camp kb...@n1k.org wrote:
 Hi

 Backing up a bit to “getting a TBolt running”.

 1) instal Lady Heather and get it connected to the TBolt
 2)  does it fire up and find any sats?

Yes. It had been working consistently for several days prior to my
first message.

 3) are the power supplies holding regulation?

Yes.

 4) nail down the antenna in the best fixed location you can find

Done.

 5) run the auto-calibration feature in LH

Done. This changed the gain from -5.0Hz/V to -3.132Hz/V and changed
the initial voltage to 0.347V. I switched the time constant and
damping values back to their defaults of 100 seconds and 1.200,
respectively.

 6) run a 48 hour survey with LH and write the location to ee memory

Done. The location matches the averaged location surveyed from my
Motorola Oncore UT+ (the antenna for which was about 10cm away from
that for the Tbolt, some no-name mushroom-type antenna) and a handheld
Garmin eTrex 20 (with GPS+GLONASS+WAAS) within a few meters. It also
matches with Google Maps.

In the attached screenshot you can clearly see the field of view from
the antenna's current location over the last ~20 hours.

Interestingly, the Oncore antenna (a cheap patch antenna from eBay)
seems to be causing some intermittent issues with the Tbolt: if the
antennas are too close there appears to be some sort of interference
emitted by the Oncore antenna that makes it difficult for the Tbolt to
lock onto the GPS signal and the Tbolt goes into holdover. Oddly, this
is not consistent: the Tbolt and Oncore had coexisted for a few days
with no problems but today some of the problems started up again.

The same issue occured if the Oncore antenna was too close to my
Garmin GPS 18x LVC. I have since moved the Oncore antenna further away
(it's now about 50cm) and signal reception for the Tbolt is much
better. Weird, but distance seems to resolve the issue, so not really
a problem anymore.

 7) Then check the EFC voltage, it should be fairly close to 0V, and not over 
 2.5
 If you are  2.5, that’s probably a broken unit.

Doesn't seem to be a problem.

 8) Now start watching the EFC voltage for a few days and see that it’s 
 leveling
 out and not spiking. Again spikes = something broke.

See the attached screenshot. There's a few small EFC voltage spikes
when the unit enters or leaves holdover, but otherwise it seems
reasonably smooth in my (admittedly untrained) view.

 Until that’s all done, I would not dig to deep into the workings of the 
 gizmo. It
 needs to be set up first.

Other than the intermittent issues with the Oncore antenna, everything
seems to be working reasonably well -- there's no obvious failures
that I can spot.

Cheers!
-Pete

 Bob


 On Apr 21, 2015, at 4:30 AM, Pete Stephenson p...@heypete.com wrote:

 On Tue, Apr 21, 2015 at 4:25 AM, Charles Steinmetz
 csteinm...@yandex.com wrote:
 Pete wrote:

 On a related note, is it possible to extract any data regarding the
 training from the unit?

 Not as far as the time-nuts community knows, no (other than looking at the
 DAC voltage and temperature reporting during holdover and attempting to
 reverse engineer the prediction algorithm by correlating those with the
 long-term DAC voltage -- good luck).

 Finishing my PhD is enough work already. I don't think I'll try
 reverse-engineering the prediction algorithm quite yet. Perhaps later
 in my Copious Free Time(tm)?

 Are the training parameters saved periodically to non-volatile memory,
 or are they purely stored in RAM and so will be lost if powered down?
 If the latter, does the RAM have any provisions for backup power

 I doubt it -- mine always act as if they are training from zero if they have
 been powered down.  Because of the lack of precise retrace of quartz
 crystals, I don't think you'd want old (pre-power-down) data, anyway.  Some
 crystals will even come up drifting in the opposite direction after being
 powered down, and they all take some time (days, at least) to settle down
 after any disturbance (including power interruptions, however brief).

 Ok. It'd be nice if there was some way to keep the crystal going
 through power interruptions, even if the oven itself cooled off. I
 suspect Trimble (correctly) assumed that the vast majority of these
 units were to be installed in cell sites with reliable power so that
 wouldn't be an issue.

 Alas, the location for the antenna is suboptimal: in the best location
 available to me (an outdoor balcony) I have a clear view of the
 southern sky from 150-300 degrees (az) and from horizon to zenith with
 only a few low-elevation obstructions. However, this is only
 accessible in warm months
 *   *   *
 The surveyed position is within about 10 meters of the actual location
 according to Google Maps and local building information.

 That's a problem.  Every meter is approximately 3.3nS, so 10m introduces a
 +/- 33nS error in the raw data (as much as 33nS closer to some satellites
 and 33nS farther from

Re: [time-nuts] Tuning a Trimble Thunderbolt

[Pete Stephenson]

On Tue, Apr 21, 2015 at 12:08 AM, Bob Camp kb...@n1k.org wrote:
 Hi

 Expecting that unit to meet holdover after only being locked for 12 hours is 
 not
 a reasonable thing.

So it would seem.

Perhaps I was being a bit optimistic for out-of-the-box performance:
the brochure listed the holdover specs but said nothing about how long
one needed to let it run before it was able to meet those specs. The
user guide hinted at it when it said that a 24 hour training period
was the minimum for good results (which I assumed to mean will meet
the published specs) but earlier tests after 24 hours of being locked
to GPS didn't meet the spec either.

Obviously it needs more time to stabilize and train. Hopefully my
daughter doesn't eat it in the interim.

 Let it run for a week. Let it lock up for at least 4 or 5 days and get a good 
 survey
 on the location. It should run  +/- 5ns one sigma with a good survey.

Will do. I'm doing the 48 hour survey now with LH.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Tuning a Trimble Thunderbolt

[Pete Stephenson]

On Tue, Apr 21, 2015 at 4:25 AM, Charles Steinmetz
csteinm...@yandex.com wrote:
 Pete wrote:

 On a related note, is it possible to extract any data regarding the
 training from the unit?

 Not as far as the time-nuts community knows, no (other than looking at the
 DAC voltage and temperature reporting during holdover and attempting to
 reverse engineer the prediction algorithm by correlating those with the
 long-term DAC voltage -- good luck).

Finishing my PhD is enough work already. I don't think I'll try
reverse-engineering the prediction algorithm quite yet. Perhaps later
in my Copious Free Time(tm)?

 Are the training parameters saved periodically to non-volatile memory,
 or are they purely stored in RAM and so will be lost if powered down?
 If the latter, does the RAM have any provisions for backup power

 I doubt it -- mine always act as if they are training from zero if they have
 been powered down.  Because of the lack of precise retrace of quartz
 crystals, I don't think you'd want old (pre-power-down) data, anyway.  Some
 crystals will even come up drifting in the opposite direction after being
 powered down, and they all take some time (days, at least) to settle down
 after any disturbance (including power interruptions, however brief).

Ok. It'd be nice if there was some way to keep the crystal going
through power interruptions, even if the oven itself cooled off. I
suspect Trimble (correctly) assumed that the vast majority of these
units were to be installed in cell sites with reliable power so that
wouldn't be an issue.

 Alas, the location for the antenna is suboptimal: in the best location
 available to me (an outdoor balcony) I have a clear view of the
 southern sky from 150-300 degrees (az) and from horizon to zenith with
 only a few low-elevation obstructions. However, this is only
 accessible in warm months
  *   *   *
 The surveyed position is within about 10 meters of the actual location
 according to Google Maps and local building information.

 That's a problem.  Every meter is approximately 3.3nS, so 10m introduces a
 +/- 33nS error in the raw data (as much as 33nS closer to some satellites
 and 33nS farther from others).  Add in the uncertainty due to noise, and you
 get easily hundreds on nS of error in the computed solution.

Indeed. I'm running a 48-hour survey with Lady Heather now to see if
that can improve things a bit more.

 Unfortunately, you are unlikely to do any better than this with the antenna
 location you described.  Time to buy a house, with no tall trees nearby.
 (You may already have heard that time-nuttiness can be expensive  ;-)

I won't be looking for a house for at least a few years, but when I do
the skyview is definitely one of the criteria, as is the friendliness
of the community to radio masts.

Cheers!
-Pete

-- 
Pete 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.

Re: [time-nuts] Tuning a Trimble Thunderbolt

[Pete Stephenson]

 is within about 10 meters of the actual location
according to Google Maps and local building information.

Roof access is, unfortunately, not permitted by the apartment management.

 Find a good location for the antenna, find a good, out-of-the-way location
 for the Tbolt, and shield it from drafts (a simple cardboard box is a huge
 improvement).  [Check the archives for other solutions.  I have posted about
 my experiences with cast aluminum boxes, thermal mass, and thermal
 capacitance, and many others have posted lots and lots of other ideas.]
 Then, let it run for 3 or 4 months without playing with it.  Don't change
 any parameters, don't go into manual holdover, don't do ANYthing.  THEN see
 how it works.  Until then, you're just chasing your tail tracking the
 crystal as it settles down.

Interesting. I'll see if I can dig up a box. With all the baby stuff
around the house I'm sure to find something suitable.

The not playing with it for a few months will be the tough part. :)

Thanks again for the help.

Cheers!
-Pete

 Best regards,

 Charles

[1] Interestingly, the 18x rarely loses lock, even on satellites in
the southern sky. Since it is reporting a position a few tens of
meters away from its actual location (when used outside the apartment
it computes much more accurate locations), I assume it's because it's
tracking the signals reflected off of a conveniently located building
to the north that allows a partial, reflected view of the southern
sky. Less than ideal, yes, but it works well enough for NTP.

-- 
Pete 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] Tuning a Trimble Thunderbolt

[Pete Stephenson]

Hi all,

I recently acquired a 2004-era Trimble Thunderbolt with firmware 3.00
from eBay. It looks essentially identical to the one sold in the
TAPR/Time Nuts 2009 group buy[1]. A sticker says it's the Rev E
(it's not a Thunderbolt E, just revision E of the original
Thunderbolt).

I don't use it for anything critical, just local timekeeping and hobby
stuff (I'm beginning to get into ham radio, so a good frequency
reference will be handy). I've been really impressed with it, but I'm
interested in tuning it for even better performance. The list archives
here have been useful, as have other outside resources[2], but I have
a few questions for the gurus here if that's not too much trouble.

I don't have a time-interval counter or local reference clock; all my
data is from Lady Heather. The Thunderbolt is resting in the shade on
a foam block on a table in my living room, which is not actively
temperature-controlled but is well-insulated and typically within a
few degrees of 20C. It's been running for about a week with
uninterrupted GPS signal, though I typically enable manual holdover
for a few hours a day for testing.

The default tuning parameters keep the phase and frequency error
within the published specifications[3] of +/- 20 ns (1 sigma) and
~10^-12 over the course of a day, respectively, so long as the
receiver is locked to the GPS signal. However, when using the default
parameters it doesn't meet the holdover specifications of +/- 1 us
over 2 hours with a maximum of +/- 15C temperature change: it will
drift at least 20 us over 2 hours in holdover.

1. Is there some preferred, step-by-step method for manual tuning?

I'm familiar with the Ziegler–Nichols method for tuning PID
controllers and that method works reasonably well for adjusting PID
controllers used for temperature control in the lab at my workplace.
Is there some method that's comparable? As a general example, would
Adjust time constant until the phase error starts to oscillate but
frequency error is stable and low. Reduce damping value until phase
error stabilizes. be sensible?

I ask because although Lady Heather's autotune function works well
at setting the gain and DAC values, the time constant (500 seconds)
and damping constant (1.00) is hard-coded into the source and want to
know how to adjust those parameters for my particular Thunderbolt.

2. Is it typical for an oscillator in holdover to drift in a
non-linear way? For example, with a bit of tuning my Thunderbolt
drifted to a PPS offset of 1 us after 126 minutes. However, at 160
minutes the offset was 2 us, at 190 minutes it was 3 us, and so on.
After about five and a half hours (330 minutes) the offset was 11 us.
Can this non-linearity be corrected through the judicious choice of
tuning parameters or some other means?

3. Although my attempts at tuning have improved the holdover
performance over the default parameters, I'm nowhere near the
performance reported by [4]. That document says the units under test
were standard Thunderbolts (not Thunderbolt E's) and were on for three
days and had a training period of two hours prior to the test. My
Thunderbolt has been on for a week and had been locked to the GPS
signal for at least 12 hours prior to the test.

Lady Heather shows N/A for the Kalman filter (the PV, static, and
altitude filters are on). This appears to be normal, as screenshots
from others [2] show the same thing. Is this expected? Is there still
some internal Kalman filter?

3. Is it normal for there to be spikes in the phase and frequency
error when the number of satellites being tracked changes? I observe
changes of ~100ns and 100-200ppt whenever there's a change in the
number of satellites. Can this be smoothed out?

Many thanks. I apologize if I'm duplicating an earlier discussion, but
my search-fu didn't turn up answers to these questions in the list
archives. If this has been discussed before, pointers to the earlier
discussion would be most appreciated.

Cheers!
-Pete
Bern, Switzerland

[1] http://www.leapsecond.com/pages/tapr-tbolt/
[2] 
http://www.ko4bb.com/dokuwiki/doku.php?id=precision_timing:thunderbolt_damping
[3] http://trl.trimble.com/docushare/dsweb/Get/Document-10015/
[4] 
http://www.w8bapdstar.info/library/PrecisionClocking/Trimble%20Thunderbolt/Thunderbolt%20Holdover%20Document-8428.pdf

-- 
Pete 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.

Re: [time-nuts] Z3810AS PPS to a Raspberry Pi

[Pete Stephenson]

On 3/23/2015 5:20 PM, Dan Watson wrote:
 The solution I came up with is very simple but works well. I
 capacitively couple the signal into a MOSFET which triggers a
 monostable 555 circuit. This generates a nice clean ~100ms pulse that
 I send to the PI, and an LED. Because who doesn't like blinking
 LEDs?

 I laid out a small PCB and ordered a few boards so that I can drop it
 right onto the GPIO header of the Pi. I have attached a picture of
 the board, as well as a capture of the input and output waveforms.

Looks nice: your surface-mount soldering looks great.

 The blue trace is the PPS signal from the GPSDO on the gate of the
 MOSFET, and the yellow trace is the output of the 555. After a couple
 days of settling, NTP stats on the Pi seem comparable to other GPSs
 I've tried, but I'll have to collect more data to really be sure of
 the performance. I think this circuit could also be used to translate
 PPS signals from other items of equipment to proper logic pulses.
 Lots more experimenting to do...

I've been looking at doing something similar once my Thunderbolt arrives.

Out of curiosity, how much does the 555 timer delay the PPS signal? Is
it consistent? What's the rise time?

 Anyway, if anyone is interested in more information about the circuit
 or board let me know. And comments are welcome.

I'd definitely be interested in the board. Any chance of modifying it
for through-hole components? My SMT soldering skills are pretty bad. If
you can send me the schematic I'd be happy to try modifying it for
through-hole components.

Cheers!
-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.

Re: [time-nuts] Motorola Oncore UT+ firmware upgrade backup power questions

[Pete Stephenson]

On 3/15/2015 8:46 PM, Chris Albertson wrote:
 I have one of these UT+ receivers.  Backup is not a big deal.  How long
 will the power be off?  Certainly not for days and weeks.  The backup
 battery only has to last a few seconds or maybe an hours or two.  The real
 problem with batteries is not how much energy they store but shelf life.
 You have to change the 2032 over five to eight years or so just because of
 shelf life.   So some people are using super capacitors because these can
 handle the few hours or few days of backup power and have a much longer
 working lifetime r maybe 20 years or more.F

True, it's not a huge deal. The receiver would be in position-hold mode
anyway, so I would have NTPd configured to send the receiver its known
position and a few other configuration options. Everything else is
easily retrievable from the GPS signal given a few minutes.

Backups of several years are overkill for me, particularly because the
ephemeris and almanac are only good for so long. Backup power in the
minutes-to-hours range would be perfectly fine for me.

My question was prompted mainly because I was seeking clarity as to the
proper use of pin #1: I didn't want to connect a non-rechargeable
battery if pin #1 was only intended for rechargeable batteries, as that
might cause damage. If that were the case I could use a supercapacitor,
but I wanted to be sure the pin (a) could supply power, which the manual
didn't mention, and (b) was current-limiting, otherwise the
supercapacitor would draw enormous currents and possibly cause damage.

Fortunately, it seems that a coin-cell battery will work perfectly. Once
the boards arrive I'll do some tests with the supercapacitor.

Many thanks to all for your help.

Cheers!
-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.

Re: [time-nuts] ***SPAM*** Motorola Oncore UT+ firmware upgrade backup power questions

[Pete Stephenson]

On Sat, Mar 14, 2015 at 12:56 PM, Mike Cook michael.c...@sfr.fr wrote:


 If true, what is the maximum current that can be
 safely supplied by the pin? As above, is it safe to use a
 non-rechargeable battery like a CR2032?

 I have a couple of UT+ receivers which were not equipped with batteries and 
 I used a CR2032 for backup without any issue. They were disconnected 
 sometimes for considerable periods on a number  of occasions and the saved 
 data was always accessible on power up.  I don’t know how long a battery 
 like that lasts. I have one, powered off, still with the battery in circuit 
 that I pulled in 12/2010. Hmmm. might be worth powering it on to see.


   Well, I dug it out and checked the voltage across the CR2032. Down to 
 2.8volts after 4yrs 3mths. Connected up the receiver ad powered up.
 It came up in position hold mode with the coordinates that were stored in 
 2010. 1PPS is on but I am only seeing 2 sats and am not to sync’d to UTC. I 
 think the almanac may be no good. I’ll leave it a while and see if t recovers.

 Anyway. Using a CR2032 is OK, at least with my hardware and you get backup 
 for at least 4 years.

Fantastic. Just what I wanted to hear. Thanks for checking.

Also, my apologies for sending a blank reply to the list a moment ago.

-- 
Pete 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] Motorola Oncore UT+ firmware upgrade backup power questions

[Pete Stephenson]

Hi all,

After a few years of using a Garmin GPS 18x LVC for timekeeping, my
budget now allows for some upgrades and I had a small field day on eBay:
I acquired a Trimble Thunderbolt, two Trimble Resolution Ts, and two
Motorola Oncore UT+s (seconds purchased for spares and testing).

The documentation for the Trimbles is clear, but I had several questions
regarding the Oncores that I was unable to find clear answers to online.
I would be very much obliged if the folks here might be able to help.

1. Is it possible to upgrade the firmware on the Oncore UT+? If so,
where can one acquire the latest firmware (3.2, I believe) files and how
would go one about installing it? Is this something WinOncore can do? I
ask because the receivers on eBay are of varying vintage and may not be
fully upgraded.

Since Motorola exited the GPS business a relatively long time ago,
firmware updates and directions have proven difficult (impossible so
far) for me to find.

2. The two Oncores I purchased were not factory-equipped with a
rechargeable battery. The user guide says that one can apply Externally
applied backup power ( +5V) to pin #1 in order to maintain data in RAM
in case the main power is interrupted.

Can one use a common non-rechargeable coin-cell battery like a CR2032 to
provide this backup power, or does it need to be a rechargeable battery?
Will a CR2032 or the Oncore itself be damaged if such a cell is used?

3. Tom says at
http://lists.ntp.org/pipermail/questions/2012-October/034001.html that
in addition to being an input for external backup power, pin #1 on the
Oncore provides current-limited 5V for battery/supercapacitor charging.

Is this true for Oncore receivers that were not factory-equipped with a
rechargeable battery? If true, what is the maximum current that can be
safely supplied by the pin? As above, is it safe to use a
non-rechargeable battery like a CR2032?

If pin #1 can supply power and I wanted to charge a supercapacitor from
that pin, would I also need to include a current-limiting resistor to
prevent the Oncore from sourcing too much current?

I could find nothing in the user guide that says that pin #1 can be used
for charging a battery.
http://www.synergy-gps.com/images/stories/ShopTalk/9backup_battery_considerations.pdf
is unclear on whether or not pin #1 can be used for charging batteries,
or if it's safe to use non-rechargeable cells like a CR2032 coin-cell
battery.
4. The user manual and the battery backup considerations document says
that the Oncore UT+ draws 5-100 uA (15uA typical) from the backup power
source. Is this a constant draw, even when the main 5V power is being
supplied to the unit, or does the unit only draw current from the
battery when the main power is interrupted?

I'd measure it directly, but none of my multimeters are able to
accurately measure microamperes.

Thank you all for your time and assistance. If any other time-nuts
happen to make it to Bern, Switzerland in the next few years, please let
me know and drinks are on me.

Cheers!
-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.