Re: [time-nuts] Lost GPS lock or 1PPS recently?
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
Hi
I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
through all the various gyrations is not that good on a ~1 second basis.
====
One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing another may be happy
with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of towers built. People started
using those systems and they became congested. Others started streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back …. not at all easy.
Are there other systems that have issues with sync? Of course there are. There also are a lot
of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
that all out requires a deep dive into the timing of each individual system / implementation. No
two systems do things quite the same way. Unless you want to deal with the numbers and the
implementation details, simply moaning and groaning isn’t going anywhere.
Bob
On Sep 8, 2018, at 3:23 AM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Bob,
I agree that eloran needs to be analyzed with regard to it's
usefulness for each potential application. You are also 100% correct
that timing requirements get tighter and tighter as technology
advances. In some ways the question isn't whether eloran can
match GPS but rather would it suffice in a pinch were GPS to go down?
I think the 50ns accuracy is actually "as received" not "as
transmitted".
The link below is an analysis of eloran in Great Britain. The
receiver/transmitter distance was 300 miles.
I've attached a screen capture of one of the pages that compares
eloran with GPS in case anyone is interested. This is where it
appears that the 50ns is received as opposed to at the transmitter.
Best,
Bob Martin
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
Hi
I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
through all the various gyrations is not that good on a ~1 second basis.
====
One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing another may be happy
with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of towers built. People started
using those systems and they became congested. Others started streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back …. not at all easy.
Are there other systems that have issues with sync? Of course there are. There also are a lot
of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
that all out requires a deep dive into the timing of each individual system / implementation. No
two systems do things quite the same way. Unless you want to deal with the numbers and the
implementation details, simply moaning and groaning isn’t going anywhere.
Bob
On Sep 8, 2018, at 3:23 AM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hi
The gotcha is the differential corrections. That’s not the way these systems are set up to work. They
function with no external input other than the timing signal its self. Providing bandwidth to do correction
signaling just isn’t part of the overall system design. If you wanted to use bandwidth, you would go
with 1588. Then you have a backup and no fiddling with anything else.
Indeed with an area wide 1588, you can do it all without even a GPS primary. Simply agree on a
“something” as the master source. The man with one watch always knows what time it is ….
The 250 ns "without correction" is the number that directly compares to the ~10 ns number for GPS.
Stretch out the distances to “USA” sort of stuff and it does not improve things at all.
Bob
On Sep 8, 2018, at 1:40 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I agree that eloran needs to be analyzed with regard to it's
usefulness for each potential application. You are also 100% correct that timing requirements get tighter and tighter as technology advances. In some ways the question isn't whether eloran can
match GPS but rather would it suffice in a pinch were GPS to go down?
I think the 50ns accuracy is actually "as received" not "as transmitted".
The link below is an analysis of eloran in Great Britain. The receiver/transmitter distance was 300 miles.
I've attached a screen capture of one of the pages that compares
eloran with GPS in case anyone is interested. This is where it
appears that the 50ns is received as opposed to at the transmitter.
Best,
Bob Martin
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
Hi
I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
through all the various gyrations is not that good on a ~1 second basis.
One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing another may be happy
with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of towers built. People started
using those systems and they became congested. Others started streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back …. not at all easy.
Are there other systems that have issues with sync? Of course there are. There also are a lot
of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
that all out requires a deep dive into the timing of each individual system / implementation. No
two systems do things quite the same way. Unless you want to deal with the numbers and the
implementation details, simply moaning and groaning isn’t going anywhere.
Bob
On Sep 8, 2018, at 3:23 AM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
<Capture.JPG>_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Bob,
I believe that information is transmitted with the eloran signal.
Way back when, I remember there was an added pulse called the LDC
pulse. I had to modify that pulse with each transmission based on
an input to the transmit timing unit from the computer.
I found the following on it:
http://www-personal.umich.edu/~tmikulsk/loran/ref/eloran_ldc.pdf
Also, the article referenced previously on The Great Britain
system mentions that the differential corrections are sent on the
LDC pulse.
To be honest, I don't know if this addresses your "gotcha".
Best,
Bob Martin
On 9/8/2018 12:38 PM, Bob kb8tq wrote:
Hi
The gotcha is the differential corrections. That’s not the way these systems are set up to work. They
function with no external input other than the timing signal its self. Providing bandwidth to do correction
signaling just isn’t part of the overall system design. If you wanted to use bandwidth, you would go
with 1588. Then you have a backup and no fiddling with anything else.
Indeed with an area wide 1588, you can do it all without even a GPS primary. Simply agree on a
“something” as the master source. The man with one watch always knows what time it is ….
The 250 ns "without correction" is the number that directly compares to the ~10 ns number for GPS.
Stretch out the distances to “USA” sort of stuff and it does not improve things at all.
Bob
On Sep 8, 2018, at 1:40 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I agree that eloran needs to be analyzed with regard to it's
usefulness for each potential application. You are also 100% correct that timing requirements get tighter and tighter as technology advances. In some ways the question isn't whether eloran can
match GPS but rather would it suffice in a pinch were GPS to go down?
I think the 50ns accuracy is actually "as received" not "as transmitted".
The link below is an analysis of eloran in Great Britain. The receiver/transmitter distance was 300 miles.
I've attached a screen capture of one of the pages that compares
eloran with GPS in case anyone is interested. This is where it
appears that the 50ns is received as opposed to at the transmitter.
Best,
Bob Martin
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
Hi
I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
through all the various gyrations is not that good on a ~1 second basis.
One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing another may be happy
with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of towers built. People started
using those systems and they became congested. Others started streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back …. not at all easy.
Are there other systems that have issues with sync? Of course there are. There also are a lot
of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
that all out requires a deep dive into the timing of each individual system / implementation. No
two systems do things quite the same way. Unless you want to deal with the numbers and the
implementation details, simply moaning and groaning isn’t going anywhere.
Bob
On Sep 8, 2018, at 3:23 AM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
<Capture.JPG>_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hi
The differential approach to eLoran involves running two local receivers. You look at the time of arrival on one
and use it to “calibrate" the time of arrival on the other. Put another way - you look at the difference between the
two arrival times. They can both “wander” over a 250 ns range, as long as they stay within 50 ns of each other
they meet the “differential spec”.
For disciplining a local reference, you really need an absolute number. The fact that both are wandering over a
pretty big range does matter if you are looking at a stable local source (and trying to make it more stable). What
would / does work is having a very accurate standard at one of the locations and using the difference measure
to “distribute” that source. That gets into bandwidth.
Since the difference information is very local, there really isn’t a practical way to distribute it on the eLoran signal.
As you pile on more correction stations, your data bandwidth goes up. There are a very limited number of bits
available on the eLoran signal.
Another way to look at it: If you have a standard sitting in your basement, and don’t have a buddy in town with a
better standard. Does a difference measure to his house do you any good?
Bob
On Sep 8, 2018, at 2:58 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I believe that information is transmitted with the eloran signal. Way back when, I remember there was an added pulse called the LDC pulse. I had to modify that pulse with each transmission based on
an input to the transmit timing unit from the computer.
I found the following on it:
http://www-personal.umich.edu/~tmikulsk/loran/ref/eloran_ldc.pdf
Also, the article referenced previously on The Great Britain
system mentions that the differential corrections are sent on the LDC pulse.
To be honest, I don't know if this addresses your "gotcha".
Best,
Bob Martin
On 9/8/2018 12:38 PM, Bob kb8tq wrote:
Hi
The gotcha is the differential corrections. That’s not the way these systems are set up to work. They
function with no external input other than the timing signal its self. Providing bandwidth to do correction
signaling just isn’t part of the overall system design. If you wanted to use bandwidth, you would go
with 1588. Then you have a backup and no fiddling with anything else.
Indeed with an area wide 1588, you can do it all without even a GPS primary. Simply agree on a
“something” as the master source. The man with one watch always knows what time it is ….
The 250 ns "without correction" is the number that directly compares to the ~10 ns number for GPS.
Stretch out the distances to “USA” sort of stuff and it does not improve things at all.
Bob
On Sep 8, 2018, at 1:40 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I agree that eloran needs to be analyzed with regard to it's
usefulness for each potential application. You are also 100% correct that timing requirements get tighter and tighter as technology advances. In some ways the question isn't whether eloran can
match GPS but rather would it suffice in a pinch were GPS to go down?
I think the 50ns accuracy is actually "as received" not "as transmitted".
The link below is an analysis of eloran in Great Britain. The receiver/transmitter distance was 300 miles.
I've attached a screen capture of one of the pages that compares
eloran with GPS in case anyone is interested. This is where it
appears that the 50ns is received as opposed to at the transmitter.
Best,
Bob Martin
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
Hi
I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
through all the various gyrations is not that good on a ~1 second basis.
One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing another may be happy
with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of towers built. People started
using those systems and they became congested. Others started streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back …. not at all easy.
Are there other systems that have issues with sync? Of course there are. There also are a lot
of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
that all out requires a deep dive into the timing of each individual system / implementation. No
two systems do things quite the same way. Unless you want to deal with the numbers and the
implementation details, simply moaning and groaning isn’t going anywhere.
Bob
On Sep 8, 2018, at 3:23 AM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
<Capture.JPG>_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Bob,
That seems pretty conclusive to me but wait there's more..
By adding a letter to the name they are attempting to address the
very issue you've raised.
https://rntfnd.org/wp-content/uploads/eDLoran-Reelektronica-Paper.pdf
I'm sure after a few more prefix letters are added to Loran it
will work for everyone!
Time for a new house to flip or dead horse to flog,
Bob Martin
On 9/8/2018 2:44 PM, Bob kb8tq wrote:
Hi
The differential approach to eLoran involves running two local receivers. You look at the time of arrival on one
and use it to “calibrate" the time of arrival on the other. Put another way - you look at the difference between the
two arrival times. They can both “wander” over a 250 ns range, as long as they stay within 50 ns of each other
they meet the “differential spec”.
For disciplining a local reference, you really need an absolute number. The fact that both are wandering over a
pretty big range does matter if you are looking at a stable local source (and trying to make it more stable). What
would / does work is having a very accurate standard at one of the locations and using the difference measure
to “distribute” that source. That gets into bandwidth.
Since the difference information is very local, there really isn’t a practical way to distribute it on the eLoran signal.
As you pile on more correction stations, your data bandwidth goes up. There are a very limited number of bits
available on the eLoran signal.
Another way to look at it: If you have a standard sitting in your basement, and don’t have a buddy in town with a
better standard. Does a difference measure to his house do you any good?
Bob
On Sep 8, 2018, at 2:58 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I believe that information is transmitted with the eloran signal. Way back when, I remember there was an added pulse called the LDC pulse. I had to modify that pulse with each transmission based on
an input to the transmit timing unit from the computer.
I found the following on it:
http://www-personal.umich.edu/~tmikulsk/loran/ref/eloran_ldc.pdf
Also, the article referenced previously on The Great Britain
system mentions that the differential corrections are sent on the LDC pulse.
To be honest, I don't know if this addresses your "gotcha".
Best,
Bob Martin
On 9/8/2018 12:38 PM, Bob kb8tq wrote:
Hi
The gotcha is the differential corrections. That’s not the way these systems are set up to work. They
function with no external input other than the timing signal its self. Providing bandwidth to do correction
signaling just isn’t part of the overall system design. If you wanted to use bandwidth, you would go
with 1588. Then you have a backup and no fiddling with anything else.
Indeed with an area wide 1588, you can do it all without even a GPS primary. Simply agree on a
“something” as the master source. The man with one watch always knows what time it is ….
The 250 ns "without correction" is the number that directly compares to the ~10 ns number for GPS.
Stretch out the distances to “USA” sort of stuff and it does not improve things at all.
Bob
On Sep 8, 2018, at 1:40 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I agree that eloran needs to be analyzed with regard to it's
usefulness for each potential application. You are also 100% correct that timing requirements get tighter and tighter as technology advances. In some ways the question isn't whether eloran can
match GPS but rather would it suffice in a pinch were GPS to go down?
I think the 50ns accuracy is actually "as received" not "as transmitted".
The link below is an analysis of eloran in Great Britain. The receiver/transmitter distance was 300 miles.
I've attached a screen capture of one of the pages that compares
eloran with GPS in case anyone is interested. This is where it
appears that the 50ns is received as opposed to at the transmitter.
Best,
Bob Martin
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
Hi
I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
through all the various gyrations is not that good on a ~1 second basis.
One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing another may be happy
with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of towers built. People started
using those systems and they became congested. Others started streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back …. not at all easy.
Are there other systems that have issues with sync? Of course there are. There also are a lot
of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
that all out requires a deep dive into the timing of each individual system / implementation. No
two systems do things quite the same way. Unless you want to deal with the numbers and the
implementation details, simply moaning and groaning isn’t going anywhere.
Bob
On Sep 8, 2018, at 3:23 AM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
<Capture.JPG>_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hi
Yup, and over something the size of a harbor, that works ok. It was done with the “old”
Loran in a similar fashion and a couple of other ways as well. Expanding any of it to
cover a country is a very different thing …..
I spent a lot of years trying to sell the designers of these systems on backup solutions.
Not because I’m some kind of end of the world type. I figured selling them four boxes for
every tower was at least twice as good as selling them two boxes. I was far from the only
one making that pitch. None of us got a bite in 30 years of trying ….
Bob
On Sep 8, 2018, at 5:16 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
That seems pretty conclusive to me but wait there's more..
By adding a letter to the name they are attempting to address the very issue you've raised.
https://rntfnd.org/wp-content/uploads/eDLoran-Reelektronica-Paper.pdf
I'm sure after a few more prefix letters are added to Loran it will work for everyone!
Time for a new house to flip or dead horse to flog,
Bob Martin
On 9/8/2018 2:44 PM, Bob kb8tq wrote:
Hi
The differential approach to eLoran involves running two local receivers. You look at the time of arrival on one
and use it to “calibrate" the time of arrival on the other. Put another way - you look at the difference between the
two arrival times. They can both “wander” over a 250 ns range, as long as they stay within 50 ns of each other
they meet the “differential spec”.
For disciplining a local reference, you really need an absolute number. The fact that both are wandering over a
pretty big range does matter if you are looking at a stable local source (and trying to make it more stable). What
would / does work is having a very accurate standard at one of the locations and using the difference measure
to “distribute” that source. That gets into bandwidth.
Since the difference information is very local, there really isn’t a practical way to distribute it on the eLoran signal.
As you pile on more correction stations, your data bandwidth goes up. There are a very limited number of bits
available on the eLoran signal.
Another way to look at it: If you have a standard sitting in your basement, and don’t have a buddy in town with a
better standard. Does a difference measure to his house do you any good?
Bob
On Sep 8, 2018, at 2:58 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I believe that information is transmitted with the eloran signal. Way back when, I remember there was an added pulse called the LDC pulse. I had to modify that pulse with each transmission based on
an input to the transmit timing unit from the computer.
I found the following on it:
http://www-personal.umich.edu/~tmikulsk/loran/ref/eloran_ldc.pdf
Also, the article referenced previously on The Great Britain
system mentions that the differential corrections are sent on the LDC pulse.
To be honest, I don't know if this addresses your "gotcha".
Best,
Bob Martin
On 9/8/2018 12:38 PM, Bob kb8tq wrote:
Hi
The gotcha is the differential corrections. That’s not the way these systems are set up to work. They
function with no external input other than the timing signal its self. Providing bandwidth to do correction
signaling just isn’t part of the overall system design. If you wanted to use bandwidth, you would go
with 1588. Then you have a backup and no fiddling with anything else.
Indeed with an area wide 1588, you can do it all without even a GPS primary. Simply agree on a
“something” as the master source. The man with one watch always knows what time it is ….
The 250 ns "without correction" is the number that directly compares to the ~10 ns number for GPS.
Stretch out the distances to “USA” sort of stuff and it does not improve things at all.
Bob
On Sep 8, 2018, at 1:40 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I agree that eloran needs to be analyzed with regard to it's
usefulness for each potential application. You are also 100% correct that timing requirements get tighter and tighter as technology advances. In some ways the question isn't whether eloran can
match GPS but rather would it suffice in a pinch were GPS to go down?
I think the 50ns accuracy is actually "as received" not "as transmitted".
The link below is an analysis of eloran in Great Britain. The receiver/transmitter distance was 300 miles.
I've attached a screen capture of one of the pages that compares
eloran with GPS in case anyone is interested. This is where it
appears that the 50ns is received as opposed to at the transmitter.
Best,
Bob Martin
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
Hi
I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
through all the various gyrations is not that good on a ~1 second basis.
One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing another may be happy
with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of towers built. People started
using those systems and they became congested. Others started streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back …. not at all easy.
Are there other systems that have issues with sync? Of course there are. There also are a lot
of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
that all out requires a deep dive into the timing of each individual system / implementation. No
two systems do things quite the same way. Unless you want to deal with the numbers and the
implementation details, simply moaning and groaning isn’t going anywhere.
Bob
On Sep 8, 2018, at 3:23 AM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@n1k.org said:
You are not trying to run a cell system when checking your local oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
<Capture.JPG>_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hello to the group I won't quote figures here but did indeed help UrsaNav
do testing. Hey 90 days with a HP 5071 that was a sweet deal at the cost of
some power.
They do send corrective data in the signal from reference sites and that
helps propagation corrections in the receive software.
It was impressive and even in buildings no less. Its been a while so thats
why I don't want to quote figures.
I sort of thought all of this would have been resolved by now. But nope not
until the S.. hits the fan and finger pointing starts.
I do know the other satellite system lightspeed? is trying to become an
alternate.
Regards
Paul
WB8TSL
On Sat, Sep 8, 2018 at 5:55 PM, Bob kb8tq kb8tq@n1k.org wrote:
Hi
Yup, and over something the size of a harbor, that works ok. It was done
with the “old”
Loran in a similar fashion and a couple of other ways as well. Expanding
any of it to
cover a country is a very different thing …..
I spent a lot of years trying to sell the designers of these systems on
backup solutions.
Not because I’m some kind of end of the world type. I figured selling them
four boxes for
every tower was at least twice as good as selling them two boxes. I was
far from the only
one making that pitch. None of us got a bite in 30 years of trying ….
Bob
On Sep 8, 2018, at 5:16 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
That seems pretty conclusive to me but wait there's more..
By adding a letter to the name they are attempting to address the very
issue you've raised.
https://rntfnd.org/wp-content/uploads/eDLoran-Reelektronica-Paper.pdf
I'm sure after a few more prefix letters are added to Loran it will work
for everyone!
Time for a new house to flip or dead horse to flog,
Bob Martin
On 9/8/2018 2:44 PM, Bob kb8tq wrote:
Hi
The differential approach to eLoran involves running two local
receivers. You look at the time of arrival on one
and use it to “calibrate" the time of arrival on the other. Put another
way - you look at the difference between the
two arrival times. They can both “wander” over a 250 ns range, as long
as they stay within 50 ns of each other
they meet the “differential spec”.
For disciplining a local reference, you really need an absolute number.
The fact that both are wandering over a
pretty big range does matter if you are looking at a stable local
source (and trying to make it more stable). What
would / does work is having a very accurate standard at one of the
locations and using the difference measure
to “distribute” that source. That gets into bandwidth.
Since the difference information is very local, there really isn’t a
practical way to distribute it on the eLoran signal.
As you pile on more correction stations, your data bandwidth goes up.
There are a very limited number of bits
available on the eLoran signal.
Another way to look at it: If you have a standard sitting in your
basement, and don’t have a buddy in town with a
better standard. Does a difference measure to his house do you any good?
Bob
On Sep 8, 2018, at 2:58 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I believe that information is transmitted with the eloran signal. Way
back when, I remember there was an added pulse called the LDC pulse. I had
to modify that pulse with each transmission based on
an input to the transmit timing unit from the computer.
I found the following on it:
http://www-personal.umich.edu/~tmikulsk/loran/ref/eloran_ldc.pdf
Also, the article referenced previously on The Great Britain
system mentions that the differential corrections are sent on the LDC
pulse.
To be honest, I don't know if this addresses your "gotcha".
Best,
Bob Martin
On 9/8/2018 12:38 PM, Bob kb8tq wrote:
Hi
The gotcha is the differential corrections. That’s not the way these
systems are set up to work. They
function with no external input other than the timing signal its
self. Providing bandwidth to do correction
signaling just isn’t part of the overall system design. If you
wanted to use bandwidth, you would go
with 1588. Then you have a backup and no fiddling with anything else.
Indeed with an area wide 1588, you can do it all without even a GPS
primary. Simply agree on a
“something” as the master source. The man with one watch always
knows what time it is ….
The 250 ns "without correction" is the number that directly compares
to the ~10 ns number for GPS.
Stretch out the distances to “USA” sort of stuff and it does not
improve things at all.
Bob
On Sep 8, 2018, at 1:40 PM, Bob Martin aphid1@comcast.net wrote:
Bob,
I agree that eloran needs to be analyzed with regard to it's
usefulness for each potential application. You are also 100% correct
that timing requirements get tighter and tighter as technology advances.
In some ways the question isn't whether eloran can
match GPS but rather would it suffice in a pinch were GPS to go down?
I think the 50ns accuracy is actually "as received" not "as
transmitted".
The link below is an analysis of eloran in Great Britain. The
receiver/transmitter distance was 300 miles.
of-High-Accuracy-eLoran-Time-Frequency-and-Phase-2015.pdf
I've attached a screen capture of one of the pages that compares
eloran with GPS in case anyone is interested. This is where it
appears that the 50ns is received as opposed to at the transmitter.
Best,
Bob Martin
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
Hi
I believe the 50 ns is the “as transmitted” signal from the tower.
The “as received” signal after going
through all the various gyrations is not that good on a ~1 second
basis.
====
One of the gotchas here is that we lump “systems” into one giant
bag. That’s not a good way
to analyze things. One system may be quite happy with 10 ms timing
another may be happy
with 10 us and yet another may die completely at 1 us and only run
right at 100 ns. All of that
is on a 2 second basis for CDMA (they time every other second).
By far the biggest / baddest / most venerable system out the that
uses GPS timing is the
cell tower system. They started out back in the 80’s with a 10us
max timing / 1 us running
spec on CDMA. AFIK they were the first major system to adopt GPS
time as their reference
(rather than UTC).
This worked out fine for a few decades while companies got a lot of
towers built. People started
using those systems and they became congested. Others started
streaming video over them
and they ran out of bandwidth. Upgrades followed. There have been a
lot of them. Much of what
we TimeNuts buy on the surplus market comes to us as a result of
older systems being scrapped
out.
The latest set of upgrades does / will / is getting them into the
sub 1 us range at the end of holdover.
In normal operation they are spec’d at 100 ns worst case. To do
that, you need a timing source in
the roughly 10 ns range. No you don’t see those GPSDO’s on the
surplus market. You will see
them someday ….
Again, they went this way a decade ago. Rolling that all back ….
not at all easy.
Are there other systems that have issues with sync? Of course there
are. There also are a lot
of instances where miss-configuration ( or junk implementation) is
a much bigger issue. Sorting
that all out requires a deep dive into the timing of each
individual system / implementation. No
two systems do things quite the same way. Unless you want to deal
with the numbers and the
implementation details, simply moaning and groaning isn’t going
anywhere.
wrote:
oscillator
against LORAN.
The eLoran committee said 50 ns. Is that good enough for cell
towers?
Too bad it isn't up so we could collect some data.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
<Capture.JPG>_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On 9/8/18 4:52 PM, paul swed wrote:
Hello to the group I won't quote figures here but did indeed help UrsaNav
do testing. Hey 90 days with a HP 5071 that was a sweet deal at the cost of
some power.
They do send corrective data in the signal from reference sites and that
helps propagation corrections in the receive software.
It was impressive and even in buildings no less. Its been a while so thats
why I don't want to quote figures.
I sort of thought all of this would have been resolved by now. But nope not
until the S.. hits the fan and finger pointing starts.
I do know the other satellite system lightspeed? is trying to become an
alternate.
Regards
Paul
WB8TSL
But here's the problem - if "the network" is wiped out, how do you send
the correction information?
I suppose you could have a low rate network (i.e. not "the internet")
and for the most part, the propagation corrections (whether using 60kHz,
Loran, Omega, or GPS) can be done with "climatology" - time of day and
time of year.
BUT - if we're talking about a Carrington event or similar, a series of
high altitude nuclear bursts - the propagation is going to be totally
anomalous anyway.
If we're talking about a evil-doer taking down GPS AND "the network"
together, but not perturbing the ionosphere, there may be other things
to worry about - the network carrying "time" is also carrying all those
high value transactions, phone calls, etc. and that's probably a bigger
business disruption than losing network sync.
So I think GPS actually works pretty well - it will provide good sync
for any non-global disaster. Likewise, a "campus" network will be able
to stay synchronized, because they've got wired connections.
In a local disaster (hurricane, earthquake) it's likely that business
has been disrupted by the disaster sufficiently that time sync is less
important.