Re: [time-nuts] Low cost GPS module for < 100ns timestamping error
On 5/4/14, 10:07 AM, Bob Camp wrote:
Hi
Well some of us still have RSX-11M (and RSTS/E) code floating around …..
B
As do I, but the stuff I'd actually reuse is pretty OS independent
(signal processing code in FORTRAN, and in reality, I'd most likely
rewrite it anyway.)
I suspect you'll probably not be wanting to port something OS
dependent to a SPARC to build a GPSDO... Then again this is time-nuts,
with the emphasis on "nuts".
These guys claim "IEEE-754 FPU". But this is not the board to use for a
Posix-like OS. For that you'd want disk controller, networking and so on.
The big advantage of this thing is that it has an Arduino compatible boot
loader and pinout so it drops into that environment which is VERY easy for
many people to use. It has a very short learning curve. You can't say
that about other embedded Sparc.
SPARC, ARM or AVR should not matter to people who are using the Arduino
IDE, All they see is the same C++ like environment and a small set of
library functions.
Not all SPARC V8s have FPU: the SPARC spec has a lot of flexibilty in
implmentation: a lot of "if you want X, then it has to do the following
things in the following way, but it's optional"
http://www.gaisler.com/index.php/products/processors/leon3
There's multiprocessor versions. Versions with and without cache, versions
with and without FPU, etc.
If you want a POSIX compliant OS, then RTEMS will definitely fit in
200kbytes. Don't know about all the other options. I've never heard of a
SunOS implementation on LEON, but there's a lot of weird stuff out there.
You do want to make sure that whatever you use is reasonably complete and
of a reasonably recent version (or at least one you're real familiar with).
There are a fair number of "one-off" ports of some OS or another to the
LEON, but which don't have any continuing support, bug fixes, or users to
contribute. Imagine a grad student doing their thesis on "An
implementation of RSX-11M supervisor mode on the LEON3-MP"... they get
enough done to demonstrate that it works, and they graduate, and who has a
bunch of RSX-11M software anyway.
Are these shipping yet?
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Hi
Well I do have those Sparc machines sitting over in the shed ….. I suspect hauling over the CRT monitor to go with it would be a bit of a pain. I doubt I would win the “low power GPSDO of the year” award with it.
————
Like it or not, once you get to 64 bit math, the “this versus that” hardware questions matter less and less on a GPSDO. The world is awash in CPU’s that will do what you need to do. The real issue is software / firmware. Since GPSDO’s were not a real big deal back in the 70’s and early 80’, there probably isn’t a lot of native GPSDO code for PDP-11’s or SPARC’s.
Bob
On May 4, 2014, at 1:34 PM, Jim Lux jimlux@earthlink.net wrote:
On 5/4/14, 10:07 AM, Bob Camp wrote:
Hi
Well some of us still have RSX-11M (and RSTS/E) code floating around …..
B
As do I, but the stuff I'd actually reuse is pretty OS independent (signal processing code in FORTRAN, and in reality, I'd most likely rewrite it anyway.)
I suspect you'll probably not be wanting to port something OS dependent to a SPARC to build a GPSDO... Then again this is time-nuts, with the emphasis on "nuts".
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On 5/4/14, 11:38 AM, Chris Albertson wrote:
These guys claim "IEEE-754 FPU". But this is not the board to use for a
Posix-like OS. For that you'd want disk controller, networking and so on.
Ah, so they did include the FPU: that's handy.
Actually, an in-ram file system, along with a decent threading model,
queues, and so forth, even with no disk and networking, is still useful.
The fact that you can test your code by compiling and running it in a
linux environment is quite helpful.
The big advantage of this thing is that it has an Arduino compatible boot
loader and pinout so it drops into that environment which is VERY easy for
many people to use. It has a very short learning curve. You can't say
that about other embedded Sparc.
Very much so.
SPARC, ARM or AVR should not matter to people who are using the Arduino
IDE, All they see is the same C++ like environment and a small set of
library functions.
And that's pretty cool.
But, since we have a bunch of GPS based precision navigation/orbit
determination code we're developing that runs on a SPARC V8, (so we've
dealt with all the potential numerical idiosyncracies), we might be able
to do an inexpensive port of Real Time Gipsy to this platform.
On 5/4/14, 11:44 AM, Bob Camp wrote:
Hi
Well I do have those Sparc machines sitting over in the shed ….. I
suspect hauling over the CRT monitor to go with it would be a bit of
a pain. I doubt I would win the “low power GPSDO of the year” award
with it.
————
Like it or not, once you get to 64 bit math, the “this versus that”
hardware questions matter less and less on a GPSDO. The world is
awash in CPU’s that will do what you need to do. The real issue is
software / firmware. Since GPSDO’s were not a real big deal back in
the 70’s and early 80’, there probably isn’t a lot of native GPSDO
code for PDP-11’s or SPARC’s.
One thing I've learned over the last few years is that while they're all
called SPARC, and have similar instruction sets and architectures,
they're not that identical. For the most part, as you say, you don't
care: you're writing in C or C++, and it's 32 bit math, so it's almost
processor independent.
In any case, there is native GPS receiver code for SPARCs, but it's
not from the 70s and 80s. It's from this year and last. And it's
probably not releasable in general. But at least it's an existence proof
that it can be done.
On 03/05/2014 18:41, Tom Van Baak (lab) wrote:
Tony, Chris, Bert,
Since all you want is a 10 ns time stamp / data logger you do not need a GPSDO, or OCXO, or VCXO.
The solution is cheap and very simple.
Your GPS receiver provides a 1PPS to the microprocessor. Use a plain XO or TCXO; the frequency does not need to be accurate, just stable to about 1e-9 (many $1 xtals do this). Each second your code [re]computes the drift between the clock and GPS. You may average over 10 to 100 seconds if you wish.
Even though your clock is off-time and off-frequency your software knows what the offset is. Therefore, you can simply adjust the time stamp reading by the current clock error.
This "software GPSDO" gives equal or actually slightly better performance than a real GPDSO but it is much simpler: no DAC, no EFC, no OCXO, no VCXO, no PLL.
/tvb (i5s)
Tom,
Yes - that is exactly what I intended. The problem though is maintaining
sufficient accuracy during periods when the GPS clock is unavailable or
unreliable (perhaps due to local interference), but I don't have any
handle on how long that may be or how often it occurs. Clearly there are
no absolute guarantees - eg. the GPS selective availability could be
turned on again in exceptional circumstances, so I accept that 100ns
accuracy can't be absolutely guaranteed.
The question then is, in the experience of users of GPS timing
references, for a decent but low cost receiver with a reasonably well
sited antenna and assuming there is no significant interference, how
long and how frequently is time synchronisation lost? If for example
it's only 2 or 3 seconds every few weeks, then there isn't much of a
problem. If 5 minute outages occur every few days then the holdover
performance of the local oscillator is much more critical.
What about in more difficult circumstances - eg. in urban environment
with an antenna that has a restricted view of the sky? Not that I expect
to operate in such circumstances but it would be interesting to get a
feel for how good or bad timing is maintained in less favourable situations.
Thanks, Tony H
The data loggers will be continuously powered, in fixed locations
and should have reasonably good views of the sky so the use of a low
cost GPS module should be feasible.
Hi Tony,
Ah, now you are asking a completely different question. When you started this thread you didn't mention anything about reliability of GPS signal. Now you are talking about lost signals, holdover duration, urban canyons, local interference. That totally changes the problem.
The first thing you need to do is replace fuzzy adjectives with hard numbers. In your paragraphs below you use words like "sufficient accuracy", "during periods", "decent", "low cost", "reasonably well", "no significant", etc. It is impossible to solve your problem until you create a specification using real numbers instead of words. This could be a $50 solution or a $500 solution or a $50,000 solution, depending on what those words mean.
If you implement holdover, the choice of oscillator and packaging is completely determined by the holdover spec you have to meet -- what's the worst case duration, what's the ambient temperature variation, and how many nanoseconds or microseconds of error can you tolerate during holdover.
Do you have any choice where these sensors will be placed? I mean, if there is restricted sky view or too much local interference what will you do. Can you accept or reject locations based on a 1-day or 2-week performance validation trial? How many sensors are being deployed? Is this a one-off project or something commercial?
I think it might be best to tell the group exactly what your project is; you may get many useful suggestions. Maybe GPS is not the most robust solution.
/tvb
Tom,
Yes - that is exactly what I intended. The problem though is maintaining
sufficient accuracy during periods when the GPS clock is unavailable or
unreliable (perhaps due to local interference), but I don't have any
handle on how long that may be or how often it occurs. Clearly there are
no absolute guarantees - eg. the GPS selective availability could be
turned on again in exceptional circumstances, so I accept that 100ns
accuracy can't be absolutely guaranteed.
The question then is, in the experience of users of GPS timing
references, for a decent but low cost receiver with a reasonably well
sited antenna and assuming there is no significant interference, how
long and how frequently is time synchronisation lost? If for example
it's only 2 or 3 seconds every few weeks, then there isn't much of a
problem. If 5 minute outages occur every few days then the holdover
performance of the local oscillator is much more critical.
What about in more difficult circumstances - eg. in urban environment
with an antenna that has a restricted view of the sky? Not that I expect
to operate in such circumstances but it would be interesting to get a
feel for how good or bad timing is maintained in less favourable situations.
Thanks, Tony H
On Mon, 05 May 2014 14:55:20 +0100
Tony tnuts@toneh.demon.co.uk wrote:
On 03/05/2014 18:41, Tom Van Baak (lab) wrote:
Tony, Chris, Bert,
Since all you want is a 10 ns time stamp / data logger you do not
need a GPSDO, or OCXO, or VCXO.
The solution is cheap and very simple.
Your GPS receiver provides a 1PPS to the microprocessor. Use a
plain XO or TCXO; the frequency does not need to be accurate, just
stable to about 1e-9 (many $1 xtals do this). Each second your code
[re]computes the drift between the clock and GPS. You may average
over 10 to 100 seconds if you wish.
Even though your clock is off-time and off-frequency your software
knows what the offset is. Therefore, you can simply adjust the time
stamp reading by the current clock error.
This "software GPSDO" gives equal or actually slightly better
performance than a real GPDSO but it is much simpler: no DAC, no
EFC, no OCXO, no VCXO, no PLL.
/tvb (i5s)
Tom,
Yes - that is exactly what I intended. The problem though is
maintaining sufficient accuracy during periods when the GPS clock is
unavailable or unreliable (perhaps due to local interference), but I
don't have any handle on how long that may be or how often it occurs.
Clearly there are no absolute guarantees - eg. the GPS selective
availability could be turned on again in exceptional circumstances,
so I accept that 100ns accuracy can't be absolutely guaranteed.
The question then is, in the experience of users of GPS timing
references, for a decent but low cost receiver with a reasonably well
sited antenna and assuming there is no significant interference, how
long and how frequently is time synchronisation lost? If for example
it's only 2 or 3 seconds every few weeks, then there isn't much of a
problem. If 5 minute outages occur every few days then the holdover
performance of the local oscillator is much more critical.
What about in more difficult circumstances - eg. in urban environment
with an antenna that has a restricted view of the sky? Not that I
expect to operate in such circumstances but it would be interesting
to get a feel for how good or bad timing is maintained in less
favourable situations.
Thanks, Tony H
The maintenance of time between loss of GPS is why so many time
references hit the surplus market. The hold over specs got to the point
where they had to go to a rubidium reference.
We should be up to our arm pits in Symetricoms, Trimble, etc, but I
presume the stuff got crushed. I snagged two "new old stock" GPSDO
(crystal based) from a cellular tech. At least the Chinese sold their
references on ebay.
Having second sourced products over the years, it is often easier just
to take a published spec for an item and start from there.
On Mon, May 5, 2014 at 6:55 AM, Tony tnuts@toneh.demon.co.uk wrote:
Yes - that is exactly what I intended. The problem though is maintaining
sufficient accuracy during periods when the GPS clock is unavailable or
unreliable (perhaps due to local interference), but I don't have any handle
on how long that may be or how often it occurs. Clearly there are no
absolute guarantees - eg. the GPS selective availability could be turned on
again in exceptional circumstances, so I accept that 100ns accuracy can't
be absolutely guaranteed.
I assumed you were making these measurements at a fixed location. You
don't loose GPS signal often. Onece you have the antenna in a location
that works it continues to work, most of the time. Drop outs are rare in a
fixed system after you gt it working. It's different in a moving vehicle.
The question then is, in the experience of users of GPS timing references,
for a decent but low cost receiver with a reasonably well sited antenna and
assuming there is no significant interference, how long and how frequently
is time synchronisation lost? If for example it's only 2 or 3 seconds every
few weeks, then there isn't much of a problem. If 5 minute outages occur
every few days then the holdover performance of the local oscillator is
much more critical.
As said above, once it works it pretty much continues to work. With a very
good antenna site (mine is on a 4 foot above the roof line with a 360
degree view of the sky) I've never had a loss of signal except as a test.
But then I don't look for them either.
If you do get a loss of signal then all that happens is my GPSDO controller
never updates the local oscillator. It sticks at the last setting. So the
drift depends on how good is the local oscillator. I have two. One is a
$15 crystal. It can run for "hours" before I can detect any drift (I my
case that is a few ns of phase drift) Certainly your example of 5 minutes
per day of GPS outage would be no problem at all even for a moderate
quality OCXO.
My other oscillator is a Rubidium. It is the $40 FE-5680 from eBay and it
can go for "days" with no GPS corrections (at the few ns level)
What about in more difficult circumstances - eg. in urban environment with
an antenna that has a restricted view of the sky? Not that I expect to
operate in such circumstances but it would be interesting to get a feel for
how good or bad timing is maintained in less favourable situations.
It all depends on the quality of the oscillator. But again you would
fiddle with the antenna until it worked as best it could then you don't se
much change in a fixed location system.
The other thing that "saves" you is that for timing at a fixed location the
GPS only needs ONE satellite. With any reasonable setup yo are likely to
have one sat visible at all times.
--
Chris Albertson
Redondo Beach, California
On 06/05/2014 02:24, Chris Albertson wrote:
On Mon, May 5, 2014 at 6:55 AM, Tony tnuts@toneh.demon.co.uk wrote:
Yes - that is exactly what I intended. The problem though is maintaining
sufficient accuracy during periods when the GPS clock is unavailable or
unreliable (perhaps due to local interference), but I don't have any handle
on how long that may be or how often it occurs. Clearly there are no
absolute guarantees - eg. the GPS selective availability could be turned on
again in exceptional circumstances, so I accept that 100ns accuracy can't
be absolutely guaranteed.
I assumed you were making these measurements at a fixed location. You
don't loose GPS signal often. Onece you have the antenna in a location
that works it continues to work, most of the time. Drop outs are rare in a
fixed system after you gt it working. It's different in a moving vehicle.
Thanks Chris - that's just the information I was looking for. Yes it would be at a fixed location; it wouldn't be a problem checking that it had good reception during installation.
The question then is, in the experience of users of GPS timing references,
for a decent but low cost receiver with a reasonably well sited antenna and
assuming there is no significant interference, how long and how frequently
is time synchronisation lost? If for example it's only 2 or 3 seconds every
few weeks, then there isn't much of a problem. If 5 minute outages occur
every few days then the holdover performance of the local oscillator is
much more critical.
As said above, once it works it pretty much continues to work. With a very
good antenna site (mine is on a 4 foot above the roof line with a 360
degree view of the sky) I've never had a loss of signal except as a test.
But then I don't look for them either.
If you do get a loss of signal then all that happens is my GPSDO controller
never updates the local oscillator. It sticks at the last setting. So the
drift depends on how good is the local oscillator. I have two. One is a
$15 crystal. It can run for "hours" before I can detect any drift (I my
case that is a few ns of phase drift) Certainly your example of 5 minutes
per day of GPS outage would be no problem at all even for a moderate
quality OCXO.
My other oscillator is a Rubidium. It is the $40 FE-5680 from eBay and it
can go for "days" with no GPS corrections (at the few ns level)
That's interesting. What model is the $15 oscillator? Is it an OXCO?
Unfortunately the power consumption of the OXCOs I've looked at are much
too high at < 1W. However this TCXO is both cheap and remarkably
comprehensively specified:
http://media.digikey.com/pdf/Data%20Sheets/NDK%20PDFs/NT2016SA-16.368000_MHZ-NTG1.pdf
Its a 16.368MHz oscillator for less than $2 and uses <1.5mA . Unusually
the data sheet specifies not only the max temperature stability at +/-
.5ppm from -10 to +70C, but also the max frequency/temperature slope at
+/- .05ppm/C . It also specifies short term stability at max 1ppb over .1s.
Quite a remarkable datasheet for a low cost part - I've not found any
other low cost oscillator with either of those specifications, and even
some (most?) of the OXCO don't specify the freq/temp slope. Having said
that, I can't find the same datasheet anywhere else - those on NDK's
website are less comprehensive. Perhaps those on Digikey's site are out
of date, NDK not wanting to guarantee those specs for such a low cost part.
I intend to try one and see how it performs in a box, with some
insulation, when moved into a sunny spot after being shaded for a while.
What about in more difficult circumstances - eg. in urban environment with
an antenna that has a restricted view of the sky? Not that I expect to
operate in such circumstances but it would be interesting to get a feel for
how good or bad timing is maintained in less favourable situations.
It all depends on the quality of the oscillator. But again you would
fiddle with the antenna until it worked as best it could then you don't se
much change in a fixed location system.
The other thing that "saves" you is that for timing at a fixed location the
GPS only needs ONE satellite. With any reasonable setup yo are likely to
have one sat visible at all times.
But isn't that only supported by 'timing' GPS modules that allow you to
specify the location? But they are rather more expensive than the common
navigation type modules - are there sub $15 modules that support that
single-satellite timing feature?
Thanks, Tony H