[time-nuts] GPS Outage..

[Arthur Dent]

>kb8tq at n1k.org said: Pretty much all of our surplus
gizmos are cell tower surplus (like 99.99%).

True - I believe all the Trimble Thunderbolts came from
Andrew/Grayson/Geometrix WLS2A-24-G or similar Wireless
Location Sensors. I know I removed over 200 T-bolts from
these units personally.

-Arthur
___
time-nuts mailing 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 Outage..

[Bob Camp]

Hi

So in the context of the original post, exactly how many Loran-C disciplined 
cell phone systems were there? … errr .. none. 

The *only* systems that use any sort of external disciplining are GPS based. 

Self contained or “not disciplined” does not count in this case. 

Bob

> On Feb 26, 2016, at 7:19 PM, Magnus Danielson  
> wrote:
> 
> Bob,
> 
> Nope. Cell phones have been using land-lines for ages to sync up. It was with 
> the CDMA stuff that GPS phase was starting to be used to coordinate. GSM for 
> instance does not need GPS on the base-stations, it even goes to lengthy 
> extends to avoid it. CDMA didn't come into much use over here. GPS wasn't 
> even there when cell phones got started. It is only lately that GPS have 
> become a more integrated part of the system, but as GLONASS has become more 
> popular more base-stations support that too, in order to support AGNSS. 
> Landlines still provide an interesting backup and big efforts is invested on 
> the sync-networks.
> 
> Cheers,
> Magnus
> 
> On 02/26/2016 11:56 PM, Bob Camp wrote:
>> Hi
>> 
>> ….. ummm ….. errr …..
>> 
>> Cell phones since they first came out have *never ever* been setup to run on 
>> anything other than GPS. Retrofitting them to use something else would take 
>> a decade or more. We didn’t “destroy the backup”, there never was one. 
>> Pretty much all of our surplus gizmos are cell tower surplus (like 99.99%).
>> 
>> Bob
>> 
>>> On Feb 26, 2016, at 11:57 AM, Burt I. Weiner  wrote:
>>> 
>>> Maybe I'm misreading what you're saying, but no matter the cause, it points 
>>> out what can and does happen when you put all the mission critical eggs in 
>>> one basket.  That we don't have as reliable as possible a backup system, or 
>>> why we destroyed the one we had, is mind boggling.  This is a perfect 
>>> example of what happens when you have people who don't understand the 
>>> problem/s making the wrong final decisions in spite of having been warned.
>>> 
>>> It is my belief that if we are to be so reliant on these systems for so 
>>> many things, we need to have a functioning backup system in place.
>>> 
>>> Burt, K6OQK
>>> 
>>> 
>>> 
 Mark Sims wrote:
>> When is some organization going to explain what happened in February for 
>> almost two hours starting at 00:16 GMT?  That subject has gone silent.  
>> Rob, NC0B
> I heard back from NAVCEN.  They said it was a Trimble issue and that 
> Trimble would contact me (they didn't).   But that does not jive with 
> reports of failures in Motorola, Navman, etc receivers.
 
 I think we need to distinguish here.
 
 The January 26 issue was due to faulty data sent by the satellites,
 which caused GPS receivers to apply a wrong UTC correction which caused
 the UTC time to be off by 13.7 us.
 
 As explained by Luc Gaudin from http://naelcom.com (who obviously sell
 Trimble GPS receivers) the February 13 issue was indeed just a Trimble
 firmware problem. See:
 https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
 https://www.febo.com/pipermail/time-nuts/2016-February/096050.html
 
 Martin
>>> 
>>> Burt I. Weiner Associates
>>> Broadcast Technical Services
>>> Glendale, California  U.S.A.
>>> b...@att.net
>>> www.biwa.cc
>>> K6OQK
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to 
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing 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 Outage..

[Majdi S. Abbas]

On Fri, Feb 26, 2016 at 05:56:59PM -0500, Bob Camp wrote:
> Cell phones since they first came out have *never ever* been setup 
> to run on anything other than GPS. Retrofitting them to use something 
> else would take a decade or more. We didn’t “destroy the backup”, there 
> never was one. Pretty much all of our surplus gizmos are cell tower 
> surplus (like 99.99%). 

Bob,

It depends.  

We're used to thinking of those GPS and oscillator packages
as the only timing for a cell site, but that was not the case until
fairly recently.

In many of those sites, there was also transport gear that
would take line timing from a CO or other site upstream that 
typically had diverse reference clocks available.  It might even 
have provided a backup BITS T1 as a frequency reference to cell
equipment.

Even without a local transport node, prior to the last few
years (where things seem to be going Ethernet), most cellular equipment
was still taking TDM handoffs, and could revert to taking line timing
off its transport circuits, thereby indirectly getting it from 
practically anything upstream if its local reference failed.

Certainly, the surplus device pool is all GPS, but that's
because of the number of additional devices deployed, not necessarily
representative of the full footprint of LORAN and other methods that
used to be available as indirect backup references for the sites.

Of course, that's not going to be an option going forwards.
I, for one, welcome our new Ethernet overlords.

--msa
___
time-nuts mailing 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 Outage..

[Bob Camp]

HI

E-911 triangulation done on cell towers …

Bob

> On Feb 26, 2016, at 7:25 PM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> Pretty much all of our surplus gizmos are cell tower surplus (like 99.99%).
> 
> How many of them came from E-911 stations?
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] GPS Outage..

[Hal Murray]

kb...@n1k.org said:
> Pretty much all of our surplus gizmos are cell tower surplus (like 99.99%).

How many of them came from E-911 stations?


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

Re: [time-nuts] GPS Outage..

[Magnus Danielson]

Bob,

Nope. Cell phones have been using land-lines for ages to sync up. It was 
with the CDMA stuff that GPS phase was starting to be used to 
coordinate. GSM for instance does not need GPS on the base-stations, it 
even goes to lengthy extends to avoid it. CDMA didn't come into much use 
over here. GPS wasn't even there when cell phones got started. It is 
only lately that GPS have become a more integrated part of the system, 
but as GLONASS has become more popular more base-stations support that 
too, in order to support AGNSS. Landlines still provide an interesting 
backup and big efforts is invested on the sync-networks.


Cheers,
Magnus

On 02/26/2016 11:56 PM, Bob Camp wrote:

Hi

….. ummm ….. errr …..

Cell phones since they first came out have *never ever* been setup to run on 
anything other than GPS. Retrofitting them to use something else would take a 
decade or more. We didn’t “destroy the backup”, there never was one. Pretty 
much all of our surplus gizmos are cell tower surplus (like 99.99%).

Bob


On Feb 26, 2016, at 11:57 AM, Burt I. Weiner  wrote:

Maybe I'm misreading what you're saying, but no matter the cause, it points out 
what can and does happen when you put all the mission critical eggs in one 
basket.  That we don't have as reliable as possible a backup system, or why we 
destroyed the one we had, is mind boggling.  This is a perfect example of what 
happens when you have people who don't understand the problem/s making the 
wrong final decisions in spite of having been warned.

It is my belief that if we are to be so reliant on these systems for so many 
things, we need to have a functioning backup system in place.

Burt, K6OQK




Mark Sims wrote:

When is some organization going to explain what happened in February for almost 
two hours starting at 00:16 GMT?  That subject has gone silent.  Rob, NC0B

I heard back from NAVCEN.  They said it was a Trimble issue and that Trimble 
would contact me (they didn't).   But that does not jive with reports of 
failures in Motorola, Navman, etc receivers.


I think we need to distinguish here.

The January 26 issue was due to faulty data sent by the satellites,
which caused GPS receivers to apply a wrong UTC correction which caused
the UTC time to be off by 13.7 us.

As explained by Luc Gaudin from http://naelcom.com (who obviously sell
Trimble GPS receivers) the February 13 issue was indeed just a Trimble
firmware problem. See:
https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
https://www.febo.com/pipermail/time-nuts/2016-February/096050.html

Martin


Burt I. Weiner Associates
Broadcast Technical Services
Glendale, California  U.S.A.
b...@att.net
www.biwa.cc
K6OQK
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


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


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

Re: [time-nuts] GPS Outage..

[Alex Pummer]

Hi Burt,
you are more than right, but don't forget the bean counters! they have 
power over everything even logical thinking.

73
KJ6UHN
Alex

On 2/26/2016 8:57 AM, Burt I. Weiner wrote:
Maybe I'm misreading what you're saying, but no matter the cause, it 
points out what can and does happen when you put all the mission 
critical eggs in one basket.  That we don't have as reliable as 
possible a backup system, or why we destroyed the one we had, is mind 
boggling.  This is a perfect example of what happens when you have 
people who don't understand the problem/s making the wrong final 
decisions in spite of having been warned.


It is my belief that if we are to be so reliant on these systems for 
so many things, we need to have a functioning backup system in place.


Burt, K6OQK




Mark Sims wrote:
>> When is some organization going to explain what happened in 
February for almost two hours starting at 00:16 GMT?  That subject 
has gone silent.  Rob, NC0B
> I heard back from NAVCEN.  They said it was a Trimble issue and 
that Trimble would contact me (they didn't).   But that does not jive 
with reports of failures in Motorola, Navman, etc receivers.


I think we need to distinguish here.

The January 26 issue was due to faulty data sent by the satellites,
which caused GPS receivers to apply a wrong UTC correction which caused
the UTC time to be off by 13.7 us.

As explained by Luc Gaudin from http://naelcom.com (who obviously sell
Trimble GPS receivers) the February 13 issue was indeed just a Trimble
firmware problem. See:
https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
https://www.febo.com/pipermail/time-nuts/2016-February/096050.html

Martin


Burt I. Weiner Associates
Broadcast Technical Services
Glendale, California  U.S.A.
b...@att.net
www.biwa.cc
K6OQK
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to 
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

and follow the instructions there.


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7442 / Virus Database: 4537/11699 - Release Date: 
02/26/16


___
time-nuts mailing 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 Outage

[Magnus Danielson]

Hal,

On 02/26/2016 09:39 PM, Hal Murray wrote:


martin.burni...@burnicki.net said:

Strange that at least 3 independant firmware trees/development teams should
chose the same magic wk860.



I don't find it strange. If the next firmware version is based on the
previous version and none of the developers has stumbled across this
potential problem earlier ...


That sounds like poor software engineering.  Or poor engineering management.


It's easy to say, but as work progresses over the years, it is hard to 
revisit all aspects of the code and re-evaluate it. One has to adapt 
humbleness to the task, try to check as much as possible, but still 
accept that you can't find all the bugs. Often the need to finish new 
products on time comes before, flushing out all the new bugs.



The wk860 is supposed to represent the build time of the software so it will
work for 20 years from when it was built rather than 20 years from when the
10 bit week counter last rolled over or 20 years from when the constant was
last updated.


Indeed. Just not quite the full 20 years.


That magic constant has to be pulled out to a module where it is visible
rather than buried deep in some large module.  Then the recipe for releasing
software has to update it, either by having a step in the checklist where the
human does the edit or by running a script that does it.  (Yes, you have to
start by having a formal procedure for releasing software/firmware.)


That assumes one can foresee this to become a problem. Most doesn't 
consider it to be a recent problem. However, just updating the constant 
won't work for the type of products we have here, as the boxes we now 
see have problems was never updated. A battery-backed RTC clock would 
have helped, but the battery would probably fail around now. EEPROM 
updates in the boxes would have helped, but 20 years back EEPROMS 
wheren't too happy about many updates.


I think it is better to realize that the solution was good enough for 
the expected lifetime of the product.


I've made some design choices like this. Some of them have survived the 
complete re-writes and still not greatly failed the assumptions. Some 
have faired less well. Some of the design decisions I make can easily 
live for 20 years, and the one thing I've learned is that it is hard to 
balance longterm with practical design for the expected lifetime.


I think they did fairly well. For most systems, the remaining problem is 
showing the time as being exactly 1024 weeks off, but all other aspects 
working correctly. We can apply prior knowledge to correct the 1024 
weeks offset and keep these receivers running way beyond their designed 
lifetime. That's actually quite respectable in my book.


Best Regards,
Magnus
___
time-nuts mailing 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 Outage..

[Bob Camp]

Hi

….. ummm ….. errr …..

Cell phones since they first came out have *never ever* been setup to run on 
anything other than GPS. Retrofitting them to use something else would take a 
decade or more. We didn’t “destroy the backup”, there never was one. Pretty 
much all of our surplus gizmos are cell tower surplus (like 99.99%). 

Bob

> On Feb 26, 2016, at 11:57 AM, Burt I. Weiner  wrote:
> 
> Maybe I'm misreading what you're saying, but no matter the cause, it points 
> out what can and does happen when you put all the mission critical eggs in 
> one basket.  That we don't have as reliable as possible a backup system, or 
> why we destroyed the one we had, is mind boggling.  This is a perfect example 
> of what happens when you have people who don't understand the problem/s 
> making the wrong final decisions in spite of having been warned.
> 
> It is my belief that if we are to be so reliant on these systems for so many 
> things, we need to have a functioning backup system in place.
> 
> Burt, K6OQK
> 
> 
> 
>> Mark Sims wrote:
>> >> When is some organization going to explain what happened in February for 
>> >> almost two hours starting at 00:16 GMT?  That subject has gone silent.  
>> >> Rob, NC0B
>> > I heard back from NAVCEN.  They said it was a Trimble issue and that 
>> > Trimble would contact me (they didn't).   But that does not jive with 
>> > reports of failures in Motorola, Navman, etc receivers.
>> 
>> I think we need to distinguish here.
>> 
>> The January 26 issue was due to faulty data sent by the satellites,
>> which caused GPS receivers to apply a wrong UTC correction which caused
>> the UTC time to be off by 13.7 us.
>> 
>> As explained by Luc Gaudin from http://naelcom.com (who obviously sell
>> Trimble GPS receivers) the February 13 issue was indeed just a Trimble
>> firmware problem. See:
>> https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
>> https://www.febo.com/pipermail/time-nuts/2016-February/096050.html
>> 
>> Martin
> 
> Burt I. Weiner Associates
> Broadcast Technical Services
> Glendale, California  U.S.A.
> b...@att.net
> www.biwa.cc
> K6OQK 
> ___
> time-nuts mailing 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] MV89A / MTI-260 / HP10811 carrier board

[Tom Van Baak]

Gerhard Hoffmann wrote:
> I have never used PICs and given their life cycle it's a bad time to jump on 
> the train.
> Not now when I'm just converting everything to ARM.

Hi Gerhard,

The 12F-series that I use for the PIC dividers is very solid. These are sold by 
the billions. Not sure what train you're talking about. Don't confuse ARM and 
x86 chips du jour with something like an 8-pin 8-bit PIC. For more info on the 
PIC dividers see:
http://leapsecond.com/pic/picdiv.htm
http://leapsecond.com/pic/picdiv-list.htm

Thanks for posting the sample Xilinx code. That's intriguing. So if I started 
from scratch, what does it take to turn your firmware source code into a 
working chip? Are any of the chips as small or as cheap as a SMT or DIP PIC?

By contrast, the (pd10.asm) PIC code to generate a 10 ms wide 1PPS from 10 MHz 
is two macros and a loop:

DELAY_24996 MACRO   ; delay 24996 instructions
movlw   d'249'
callDelayW100
movlw   d'94'
callDelayW1
ENDM

DELAY_2474996   MACRO   ; delay 2474996 instructions
movlw   d'247'
callDelayW10k
movlw   d'49'
callDelayW100
movlw   d'93'
callDelayW1
ENDM

; Set output pins high for 10 ms = 25,000 Tcy at 10 MHz.
rise:   movlw   0xFF
movwf   GPIO
DELAY_24996
gotofall

; Set output pins low for 990 ms = 2,475,000 Tcy at 10 MHz.
fall:   movlw   0x00
movwf   GPIO
DELAY_2474996
gotorise

/tvb

- Original Message - 
From: "Gerhard Hoffmann" 
To: 
Sent: Thursday, February 25, 2016 5:30 PM
Subject: Re: [time-nuts] MV89A / MTI-260 / HP10811 carrier board


> Am 25.02.2016 um 22:23 schrieb Magnus Danielson:
>> Interesting. I would consider the PICDIV such as that of TADD-2, which 
>> has the benefit of producing a range of frequencies, so that a 
>> suitable can be selected as matching the needs. I've found it very 
>> useful property of the TADD-2, where I have my TADD-2s wired up to 
>> output one of each. I also wired them to output the buffered variant 
>> of the clock, which gives better measures compared to running the sine 
>> straight into the counters.
> 
> I have never used PICs and given their life cycle it's a bad time to 
> jump on the train.
> Not now when I'm just converting everything to ARM. OTOH I have used 
> Xilinx since they exist
> and this board is more or less a cleanup of things that are already there.
> 
> 
> This here is all it takes for 10 and 100 MHz oscillators:
> 
> --
> -- Company: Hoffmann RF & DSP
> -- Create Date:09:09:37 08/08/2012
> -- Module Name:pps1_generator - Behavioral
> -- Target Devices:   X2c64A-5VQ44
> -- Additional Comments:   Free firmware under BSD license
> --
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use ieee.numeric_std.all;
> 
> entity pps1_generator is
> Port(
> clk : in  STD_LOGIC;
> RunAt100MHz : in  STD_LOGIC;
> pps1_out: out STD_LOGIC;
> );
> end pps1_generator;
> 
> architecture Behavioral of pps1_generator is
> signal tctr   : integer range 0 to ;
> signal pw_ctr : integer range 0 to 19;
> signal cycle_done : boolean;
> signal pw_done: boolean;
> 
> function bool2sl(b : boolean) return std_logic is
> begin
> if b then return '1'; else return '0'; end if;
> end function bool2sl;
> 
> begin
> 
> u_div : process(clk) is
> begin
> if rising_edge(clk) then
> cycle_done <= (tctr = 0); -- pipeline the comparator
> 
> if cycle_done
> then
> if RunAt100MHz = '1' then
> tctr <= 1 - 2; -- divide by 100 Meg
> else
> tctr <= 1000 - 2; -- divide by 10 Meg
> end if;
> 
> else
> tctr <= tctr - 1;
> end if;
> 
> end if; -- rising_edge()
> end process u_div;
> 
> 
> -- produce the standard 20 usec pulsewidth
> u_pulsewidth : process(clk) is
> begin
> if rising_edge(clk) then
> if cycle_done then
> if RunAt100MHz = '1' then
> pw_ctr <= 1;
> else
> pw_ctr <= 1999;
> end if;
> 
> elsif pw_ctr /= 0 then
> pw_ctr <= pw_ctr - 1;
> end if;
> 
> pps1_out <= bool2sl(pw_ctr /= 0);
> 
> end if; -- rising_edge()
> end process u_pulsewidth;
> 
> end Behavioral;
> -
> 
> 
> 
> I have 

Re: [time-nuts] GPS Outage

[Tom Van Baak]

The official word, released a few minutes ago:


NOTICE ADVISORY TO NAVSTAR USERS (NANU) 2016016 NANU TYPE: GENERAL
*** GENERAL MESSAGE TO ALL GPS USERS ***
NAVCEN has determined that the event referenced by GPS NANU 2016012 was not a 
GPS time transfer anomaly but was a user equipment issue.  GPS users that 
continue to experience equipment problems are encouraged to contact their 
equipment manufacturer for assistance.
*** GENERAL MESSAGE TO ALL GPS USERS ***

   POC: CIVILIAN - NAVCEN AT 703-313-5900, HTTP://WWW.NAVCEN.USCG.GOV
   MILITARY - GPS OPERATIONS CENTER at HTTPS://GPS.AFSPC.AF.MIL/GPSOC, DSN 
560-2541,
   COMM 719-567-2541, gpsoperationscen...@us.af.mil, HTTPS://GPS.AFSPC.AF.MIL 
   MILITARY ALTERNATE - JOINT SPACE OPERATIONS CENTER, DSN276-3514, 
   COMM 805-606-3514, jspoccombat...@vandenberg.af.mil


Sources:
http://www.navcen.uscg.gov/?pageName=gpsAlmanacs
https://celestrak.com/GPS/NANU/2016/nanu.2016016.txt

/tvb


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

Re: [time-nuts] GPS Outage

[Hal Murray]

martin.burni...@burnicki.net said:
>> Strange that at least 3 independant firmware trees/development teams should
>> chose the same magic wk860.

> I don't find it strange. If the next firmware version is based on the
> previous version and none of the developers has stumbled across this
> potential problem earlier ... 

That sounds like poor software engineering.  Or poor engineering management.

The wk860 is supposed to represent the build time of the software so it will 
work for 20 years from when it was built rather than 20 years from when the 
10 bit week counter last rolled over or 20 years from when the constant was 
last updated.

That magic constant has to be pulled out to a module where it is visible 
rather than buried deep in some large module.  Then the recipe for releasing 
software has to update it, either by having a step in the checklist where the 
human does the edit or by running a script that does it.  (Yes, you have to 
start by having a formal procedure for releasing software/firmware.)


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

Re: [time-nuts] Z3815A front panel status indicator

[Artek Manuals]

On 2/26/2016 12:58 PM, Dickson Fu wrote:

Hi all,

A bit frustrated with my newly bought Z3815A. After power up, the "Block"
indicator stays lit and no other LED turns on except Power indicator. It
appears that GPS has never discipling.

I cannot find any user manual for Z3815A and other hp smartclock does not
have the same front panel design. Anyone knows the definition of the staus
indicator?

Active
Standby
Unlock
Block

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


Dickson

While not familiar specifically with the Z3815A, I believe that all of 
the Z38xx series use basically the same software to talk to them and 
most of the command strings are pretty common ... Before throwing the 
thing off the top of the Orchard Towers


1) Do you have a software program talking to RS232 port ( probably in 
the back). The program should allow you to reset the unit and then go 
through what is called a "SURVEY" to get it tracking

2) Describe the antenna setup you are using

Dave
NR1DX

--
Dave
manu...@artekmanuals.com
www.ArtekManuals.com

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

___
time-nuts mailing 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] Z3815A front panel status indicator

[Dickson Fu]

Hi all,

A bit frustrated with my newly bought Z3815A. After power up, the "Block"
indicator stays lit and no other LED turns on except Power indicator. It
appears that GPS has never discipling.

I cannot find any user manual for Z3815A and other hp smartclock does not
have the same front panel design. Anyone knows the definition of the staus
indicator?

Active
Standby
Unlock
Block

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

[time-nuts] GPS Outage..

[Burt I. Weiner]

Maybe I'm misreading what you're saying, but no matter the cause, it 
points out what can and does happen when you put all the mission 
critical eggs in one basket.  That we don't have as reliable as 
possible a backup system, or why we destroyed the one we had, is mind 
boggling.  This is a perfect example of what happens when you have 
people who don't understand the problem/s making the wrong final 
decisions in spite of having been warned.


It is my belief that if we are to be so reliant on these systems for 
so many things, we need to have a functioning backup system in place.


Burt, K6OQK




Mark Sims wrote:
>> When is some organization going to explain what happened in 
February for almost two hours starting at 00:16 GMT?  That subject 
has gone silent.  Rob, NC0B
> I heard back from NAVCEN.  They said it was a Trimble issue and 
that Trimble would contact me (they didn't).   But that does not 
jive with reports of failures in Motorola, Navman, etc receivers.


I think we need to distinguish here.

The January 26 issue was due to faulty data sent by the satellites,
which caused GPS receivers to apply a wrong UTC correction which caused
the UTC time to be off by 13.7 us.

As explained by Luc Gaudin from http://naelcom.com (who obviously sell
Trimble GPS receivers) the February 13 issue was indeed just a Trimble
firmware problem. See:
https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
https://www.febo.com/pipermail/time-nuts/2016-February/096050.html

Martin


Burt I. Weiner Associates
Broadcast Technical Services
Glendale, California  U.S.A.
b...@att.net
www.biwa.cc
K6OQK 


___
time-nuts mailing 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 Outage

[Magnus Danielson]

Hi,

On 02/26/2016 02:39 PM, jimlux wrote:

On 2/26/16 3:34 AM, Björn wrote:

"The product will not report the correct extended GPS week number
after the Feb,13th 2016.
After the rollover to week #860, the thunderbolt will not make
position for 2 hours, because the Ephemeris data on the GPS receiver
being consider incorrect.
The module will work fine after this 2 hours."

Have the Motorola Oncore/Navman/Jupiter receivers also been checked
for this condition?

Strange that at least 3 independant firmware trees/development teams
should chose the same magic wk860.


Actually not that weird.
They might all have inherited a published code snippet.  There's a
little table driven chunk of code to compute CRCs that pretty much
everybody uses, and it derives from some article published in the 70s or
early 80s for an 8 bit micro.


Indeed. I know of at least one GPS chip vendor that with their developer 
kit provided code. Some code inheritance might be proper, but some might 
be unintentional or not even valid license-wise. Very nice way to 
inherit bugs, as we know what they are... eventually.


Would still love to see some of that code. Somebody got a copy of the 
Marconi/Zarlink code?


Cheers,
Magnus
___
time-nuts mailing 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] MV89A / MTI-260 / HP10811 carrier board

[Magnus Danielson]

Dear Gerhard,

I think you missed my point by reacting to the technology choice rather 
than the function I was proposing.


BTW, I write VHDL, assembler and C code as my daytime work, dealing with 
timing.


Cheers,
Magnus

On 02/26/2016 02:30 AM, Gerhard Hoffmann wrote:

Am 25.02.2016 um 22:23 schrieb Magnus Danielson:

Interesting. I would consider the PICDIV such as that of TADD-2, which
has the benefit of producing a range of frequencies, so that a
suitable can be selected as matching the needs. I've found it very
useful property of the TADD-2, where I have my TADD-2s wired up to
output one of each. I also wired them to output the buffered variant
of the clock, which gives better measures compared to running the sine
straight into the counters.


I have never used PICs and given their life cycle it's a bad time to
jump on the train.
Not now when I'm just converting everything to ARM. OTOH I have used
Xilinx since they exist
and this board is more or less a cleanup of things that are already there.


This here is all it takes for 10 and 100 MHz oscillators:

--

-- Company: Hoffmann RF & DSP
-- Create Date:09:09:37 08/08/2012
-- Module Name:pps1_generator - Behavioral
-- Target Devices:   X2c64A-5VQ44
-- Additional Comments:   Free firmware under BSD license
--

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;

entity pps1_generator is
 Port(
 clk : in  STD_LOGIC;
 RunAt100MHz : in  STD_LOGIC;
 pps1_out: out STD_LOGIC;
 );
end pps1_generator;

architecture Behavioral of pps1_generator is
 signal tctr   : integer range 0 to ;
 signal pw_ctr : integer range 0 to 19;
 signal cycle_done : boolean;
 signal pw_done: boolean;

 function bool2sl(b : boolean) return std_logic is
 begin
 if b then return '1'; else return '0'; end if;
 end function bool2sl;

begin

 u_div : process(clk) is
 begin
 if rising_edge(clk) then
 cycle_done <= (tctr = 0); -- pipeline the comparator

 if cycle_done
 then
 if RunAt100MHz = '1' then
 tctr <= 1 - 2; -- divide by 100 Meg
 else
 tctr <= 1000 - 2; -- divide by 10 Meg
 end if;

 else
 tctr <= tctr - 1;
 end if;

 end if; -- rising_edge()
 end process u_div;


-- produce the standard 20 usec pulsewidth
 u_pulsewidth : process(clk) is
 begin
 if rising_edge(clk) then
 if cycle_done then
 if RunAt100MHz = '1' then
 pw_ctr <= 1;
 else
 pw_ctr <= 1999;
 end if;

 elsif pw_ctr /= 0 then
 pw_ctr <= pw_ctr - 1;
 end if;

 pps1_out <= bool2sl(pw_ctr /= 0);

 end if; -- rising_edge()
 end process u_pulsewidth;

end Behavioral;
-




I have also a version that fits into 2 chips, runs at Osc = 200 MHz and
produces a fixed 1/10/100/1000pps and another pps that can be shifted
against the first one in 5nsec steps over > 1 second.
It also provides control for a Micrel ECL chip that does the ps
interpolation
between the 5 ns steps.

It has a shift register interface that is controlled by a Beagle Bone Black
under Debian Linux, so network access is free.

Ideal for testing ranging systems and TICs / TDCs, but it still needs
some software.



The power-supply input didn't look all that clear. It would be handy
if a single input could be used.


It can run on  -5...-8V (for the opamps) and +12V for Morion and MTI;
the HP10811 needs 20V or so
for its heater. In this case the 12V is made from the 20V. I do not want
a switcher there.




I could probably have use for several of these boards.


Me too. I have recently decremented the number of available Lucent REF 0
plug-ins quite substantially.

(BTW: The Lucent REF 1 units with GPS are completely sold out for good,
I have asked.)

The idea is to lock 8 or 16   5 MHz MTI-260s to something long-time
stable and see
how far I get wrt phase noise when I combine the outputs.

Seems to be more promising than that promiscuous coupled resonator stuff
that was promoted recently. It is even somewhat tunable.

I like throwing repetitive hardware at problems when I get sth. in return.
Like my 220pv/sqrtHz preamp with 20 low noise opamps averaged.

regards, Gerhard, DK4XP


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to

Re: [time-nuts] GPS Outage

[Artek Manuals]

I have  an ONCORE and VP-ONCORE neither were affected by the week 860 
problem


Dave
NR1DX

On 2/26/2016 6:34 AM, Björn wrote:

"The product will not report the correct extended GPS week number after the 
Feb,13th 2016.
After the rollover to week #860, the thunderbolt will not make position for 2 
hours, because the Ephemeris data on the GPS receiver being consider incorrect.
The module will work fine after this 2 hours."

Have the Motorola Oncore/Navman/Jupiter receivers also been checked for this 
condition?

Strange that at least 3 independant firmware trees/development teams should 
chose the same magic wk860.

I guess that someone with both affected non-trimble receivers and a gps rf 
simulator would need to spend some time on this.

--
   Björn


Dave
manu...@artekmanuals.com
www.ArtekManuals.com

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

___
time-nuts mailing 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 Outage

[Martin Burnicki]

Björn wrote:
> "The product will not report the correct extended GPS week number after the 
> Feb,13th 2016.
> After the rollover to week #860, the thunderbolt will not make position for 2 
> hours, because the Ephemeris data on the GPS receiver being consider 
> incorrect.
> The module will work fine after this 2 hours."
> 
> Have the Motorola Oncore/Navman/Jupiter receivers also been checked for this 
> condition? 

Hm, if this is a bug in the Trimble firmware, why should Motorola or
other brands be affected?

I don't remember I have heard about *this* problem with other GPS
receiver models.

> Strange that at least 3 independant firmware trees/development teams should 
> chose the same magic wk860.

I don't find it strange. If the next firmware version is based on the
previous version and none of the developers has stumbled across this
potential problem earlier ...

Martin

___
time-nuts mailing 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 Outage

[jimlux]

On 2/26/16 3:34 AM, Björn wrote:

"The product will not report the correct extended GPS week number after the 
Feb,13th 2016.
After the rollover to week #860, the thunderbolt will not make position for 2 
hours, because the Ephemeris data on the GPS receiver being consider incorrect.
The module will work fine after this 2 hours."

Have the Motorola Oncore/Navman/Jupiter receivers also been checked for this 
condition?

Strange that at least 3 independant firmware trees/development teams should 
chose the same magic wk860.


Actually not that weird.
They might all have inherited a published code snippet.  There's a 
little table driven chunk of code to compute CRCs that pretty much 
everybody uses, and it derives from some article published in the 70s or 
early 80s for an 8 bit micro.



___
time-nuts mailing 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] Looking for OCXO

[Bob Camp]

Hi

If you put a filter on the output of the DIP (or other pkg) XO, you can demo a 
sine wave into a scope as well as a square wave. You will likely need a 
generator
to power the scopes if it is outdoors so consider that as well. Not all 
generators supply 
nice clean power ….

Bob


> On Feb 26, 2016, at 3:20 AM, Hal Murray  wrote:
> 
> 
> jdo...@gmail.com said:
>> I'm going to be taking some oscilloscopes to a hamfest this summer, and I
>> am going to have a truck full of stuff anyway, and would like to avoid
>> hauling  my signal generator to provide a demonstration of the scopes. Does
>> anybody  have a 50MHZ+ OCXO or other oscillator with a coax(sma/bnc) that
>> they would like  to part with? Something that doesn't meet time nuts
>> standards is perfectly  fine, just want something that is faster than the
>> built in calibrator on the  scopes. 
> 
> Do you have any of the standard 14 pin dip osc packages in your junk 
> collection?  You can probably run one off a pair of AA batteries.  The square 
> wave output would be good for showing what a scope can do.  Most of the not 
> high frequency osc packages have slow rise times.  You might want to run it 
> through a buffer.  A non terminated connection on a few feet of coax will 
> give you nice reflection spikes to look at.
> 
> The best scope demo toy I ever saw was a Tek giveaway.  It was a burst of 
> high frequency stuff with a low rep rate.  There are all sorts of 
> opportunities for aliasing with digital scopes.
> 
> The old skier avalanche beepers work pretty well too.  Their burst is 
> something like 455 kHz modulated at 2 kHz.  (I think they changed the 
> frequency 10 years ago.)
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] PRS10 C900 replacement

[Bob Camp]

Hi

Some form of base cooling is needed on all of these surplus telecom Rb’s 
to keep them from an early death. A great big heatsink could do it. A small
quiet fan and a small heatsink will do it. A somewhat larger fan and no heatsink
will also do the job. Any fan mount should consider the magnetic field 
sensitivity 
of the Rb. (Move the fan and watch the frequency …)

Bob

> On Feb 26, 2016, at 6:52 AM, davidh  wrote:
> 
> 
> 
> Hi All,
> 
> I used the TAP225K035SRW, from Mouser, and have the PRS10 running again. In 
> the process of pulling it apart I managed to break one of the glass 
> thermistors (Mouser replacement from US Sensor, part number 104JG1F). Doh.
> 
> Whether it was the lamp temperature change (thermistor) or mechanical 
> alignment now being a bit different, the frequency moved by about 300E-12 
> (measured by locking to my GPSDO 1PPS and comparing old to new "SF" values).
> 
> I've also added a cooling fan so the base plate is now below 40dC. I guess 
> that could also affect the frequency.
> 
> Cheers,
> 
> david
> 
> 
> On 20/01/2016 4:59 PM, Charles Steinmetz wrote:
>> david wrote:
>> 
>>> It's a 2.2uF cap, with a 0.125" lead spacing, and I'm looking for
>>> 125dC temp rating. I wondered if there were other characteristics such
>>> as ESR/ESL I need to keep in mind.
>> 
>> You're on the right track.  Get the highest temperature rating available
>> (which is probably 125C), buy only caps manufactured by one of the
>> known-good manufacturers, and select from a parts series the
>> manufacturer designates as "high reliability" (or equivalent).
>> 
>> If it is a solid tantalum, I like the Vishay 199D Series.  The AVX TAP
>> Series and the Kemet "T" Series ("UltraDip II") are also high quality.
>> (This list isn't exhaustive -- these are just the ones I've had occasion
>> to qualify.)
>> 
>> Best regards,
>> 
>> Charles
>> 
>> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] GPS Outage

[Björn]

"The product will not report the correct extended GPS week number after the 
Feb,13th 2016.
After the rollover to week #860, the thunderbolt will not make position for 2 
hours, because the Ephemeris data on the GPS receiver being consider incorrect.
The module will work fine after this 2 hours."

Have the Motorola Oncore/Navman/Jupiter receivers also been checked for this 
condition? 

Strange that at least 3 independant firmware trees/development teams should 
chose the same magic wk860.

I guess that someone with both affected non-trimble receivers and a gps rf 
simulator would need to spend some time on this.

--
      Björn

 Originalmeddelande Från: Martin Burnicki 
 Datum:2016-02-26  09:32  (GMT+01:00) 
Till: time-nuts@febo.com Rubrik: Re: [time-nuts] GPS 
Outage 
Mark Sims wrote:
>> When is some organization going to explain what happened in February for 
>> almost two hours starting at 00:16 GMT?  That subject has gone silent.  Rob, 
>> NC0B
> I heard back from NAVCEN.  They said it was a Trimble issue and that Trimble 
> would contact me (they didn't).   But that does not jive with reports of 
> failures in Motorola, Navman, etc receivers.

I think we need to distinguish here.

The January 26 issue was due to faulty data sent by the satellites,
which caused GPS receivers to apply a wrong UTC correction which caused
the UTC time to be off by 13.7 us.

As explained by Luc Gaudin from http://naelcom.com (who obviously sell
Trimble GPS receivers) the February 13 issue was indeed just a Trimble
firmware problem. See:
https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
https://www.febo.com/pipermail/time-nuts/2016-February/096050.html

Martin

___
time-nuts mailing 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] PRS10 C900 replacement

[davidh]

Hi All,

I used the TAP225K035SRW, from Mouser, and have the PRS10 running again. 
In the process of pulling it apart I managed to break one of the glass 
thermistors (Mouser replacement from US Sensor, part number 104JG1F). Doh.


Whether it was the lamp temperature change (thermistor) or mechanical 
alignment now being a bit different, the frequency moved by about 
300E-12 (measured by locking to my GPSDO 1PPS and comparing old to new 
"SF" values).


I've also added a cooling fan so the base plate is now below 40dC. I 
guess that could also affect the frequency.


Cheers,

david


On 20/01/2016 4:59 PM, Charles Steinmetz wrote:

david wrote:


It's a 2.2uF cap, with a 0.125" lead spacing, and I'm looking for
125dC temp rating. I wondered if there were other characteristics such
as ESR/ESL I need to keep in mind.


You're on the right track.  Get the highest temperature rating available
(which is probably 125C), buy only caps manufactured by one of the
known-good manufacturers, and select from a parts series the
manufacturer designates as "high reliability" (or equivalent).

If it is a solid tantalum, I like the Vishay 199D Series.  The AVX TAP
Series and the Kemet "T" Series ("UltraDip II") are also high quality.
(This list isn't exhaustive -- these are just the ones I've had occasion
to qualify.)

Best regards,

Charles





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

Re: [time-nuts] Looking for OCXO

[Dave Daniel]

Reed Dickinson sells a small oscilloscope calibrator that is well suited 
for checking 'scope operation "in the field", at hamfests or when 
stumbles across a seemingly nice 'scope in the local electronics store. 
It is a very nice, compact instrument. See


http://www.ebay.com/itm/CALIBRATOR-AND-TESTER-FOR-TEKTRONIX-OSCILLOSCOPES-NEW-WARRANTED-CALIBRATED-/131638462260?hash=item1ea6438734:g:ZqQAAOSw14xWLxEy

The price seems to have gone up substantially since I purchased mine.

I am not associated with Reed, but I am a satisfied customer.

DaveD

On 2/25/2016 5:46 PM, Nathan Johnson wrote:
I'm going to be taking some oscilloscopes to a hamfest this summer, 
and I am
going to have a truck full of stuff anyway, and would like to avoid 
hauling my
signal generator to provide a demonstration of the scopes. Does 
anybody have a
50MHZ+ OCXO or other oscillator with a coax(sma/bnc) that they would 
like to
part with? Something that doesn't meet time nuts standards is 
perfectly fine,
just want something that is faster than the built in calibrator on the 
scopes.

Nathan KK4REY

Sent using CloudMagic Email
[https://cloudmagic.com/k/d/mailapp?ct=pi=7.4.15=9.1=email_footer_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.


___
time-nuts mailing 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] Looking for OCXO

[Hal Murray]

jdo...@gmail.com said:
> I'm going to be taking some oscilloscopes to a hamfest this summer, and I
> am going to have a truck full of stuff anyway, and would like to avoid
> hauling  my signal generator to provide a demonstration of the scopes. Does
> anybody  have a 50MHZ+ OCXO or other oscillator with a coax(sma/bnc) that
> they would like  to part with? Something that doesn't meet time nuts
> standards is perfectly  fine, just want something that is faster than the
> built in calibrator on the  scopes. 

Do you have any of the standard 14 pin dip osc packages in your junk 
collection?  You can probably run one off a pair of AA batteries.  The square 
wave output would be good for showing what a scope can do.  Most of the not 
high frequency osc packages have slow rise times.  You might want to run it 
through a buffer.  A non terminated connection on a few feet of coax will 
give you nice reflection spikes to look at.

The best scope demo toy I ever saw was a Tek giveaway.  It was a burst of 
high frequency stuff with a low rep rate.  There are all sorts of 
opportunities for aliasing with digital scopes.

The old skier avalanche beepers work pretty well too.  Their burst is 
something like 455 kHz modulated at 2 kHz.  (I think they changed the 
frequency 10 years ago.)


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

Re: [time-nuts] GPS Outage

[Martin Burnicki]

Mark Sims wrote:
>> When is some organization going to explain what happened in February for 
>> almost two hours starting at 00:16 GMT?  That subject has gone silent.  Rob, 
>> NC0B
> I heard back from NAVCEN.  They said it was a Trimble issue and that Trimble 
> would contact me (they didn't).   But that does not jive with reports of 
> failures in Motorola, Navman, etc receivers.

I think we need to distinguish here.

The January 26 issue was due to faulty data sent by the satellites,
which caused GPS receivers to apply a wrong UTC correction which caused
the UTC time to be off by 13.7 us.

As explained by Luc Gaudin from http://naelcom.com (who obviously sell
Trimble GPS receivers) the February 13 issue was indeed just a Trimble
firmware problem. See:
https://www.febo.com/pipermail/time-nuts/2016-February/096042.html
https://www.febo.com/pipermail/time-nuts/2016-February/096050.html

Martin

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