Re: [time-nuts] NEO-7M various modes

[Denny Page]

See the -b and -n options to gpsctl. Also the -b option to gpsd.


> On Oct 28, 2017, at 15:12, jimlux  wrote:
> 
> Some emit NMEA sentences, others binary (ublox?) strings?

___
time-nuts mailing 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] NEO-7M various modes

[Mark Sims]

Lady Heather will also work with the Ublox modules and can be used to configure 
the units.   Heather can easily be compiled to run under Linux/macOS/freeBSD.

You might have the SNR and/or elevation mask filters set improperly for indoor 
operation.
___
time-nuts mailing 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] NEO-7M various modes

[jimlux]

On 10/28/17 3:24 PM, Wayne Holder wrote:

uBlox has a utility called u-center
 that's a free
download.  You can use it to configure the various output options (and
enable and disable different messages) and a then save this config back to
the module as the start up default.

Downloaded it, hooked up the modules, found that they won't quite get a 
fix indoors next to the window, but if I take it outside, it will. 
Oddly, the SNR on the SVs is good enough, but there's something 
preventing the fix from happening.


Maybe it's because it's a cold start, it needed to run for a while to 
acquire the almanac or something.







Wayne

On Sat, Oct 28, 2017 at 3:12 PM, jimlux  wrote:


I've got 4 NEO-7M-C modules hooked up to 7 beaglebone greens, side by
side, and they're not behaving the same..

I've got gpsd running, and I'm looking at the output of cgps and/or
gpsmon, as well as ppstest


Some emit NMEA sentences, others binary (ublox?) strings?

Some get a fix and start toggling the 1pps line, others don't.

Is there some command string one can send to them to put them into a known
state (cold reset?) - the one that's working the best (I.e. has a fix AND
toggles 1pps) seems to be putting out binary strings (when viewed with
gpsmon).


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


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



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

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

[Philip Gladstone]

I built a couple of NTP time servers around this board: 
https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware 
which supports IEEE1588. It also acts as a PTP source on the LAN. It is 
part of the IPv6 ntp pool and is currently serving about 1000 requests 
per minute. It uses a custom PCB to connect to a small display an the 
GPS board (it has support for a number of different GPS boards).


It just needs putting into a case to complete the project. Of course, 
the last 10% takes 90% of the time!


Philip


On 28/10/2017 15:58, Nick Sayer via time-nuts wrote:

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

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

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

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

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

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


On Oct 27, 2017, at 12:27 PM, Leo Bodnar  wrote:

Hi Nick,

Last year I have designed an NTP server with sub-microsecond turnaround 
accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
speed) that costs just £250 from stock.
Its holdover performance on signal loss is in the order of 4-5ms/day.
https://store.uputronics.com/index.php?route=product/product=60_70_id=92

If you can come up with a cheaper and higher performance alternative I am very 
interested in licensing your design.

When you come to testing I can highly recommend placing your prototypes in 
public NTP pool and asking the admins to add it to .ch zone - you are 
guaranteed to get full 110kpps traffic spikes that will help to flush out bugs.
Just a few devices collectively served 1.1 trillion packets in less than a year 
http://leobodnar.com/LeoNTP/ (and have been through the infamous snapchat 
incident.)

Jitter and holdover need to be tested on a controlled LAN segment - I can 
highly recommend contacting Denny Page on this list and sending him a unit to 
test.
He built sophisticated and highly tuned testing system that tracks timing 
jitter and offset down to dozens of nanoseconds accuracy.
Denny is vendor-neutral and provided honest and fair feedback while I was 
developing my unit.

Hope this helps!

Thanks
Leo

On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:


Date: Wed, 25 Oct 2017 17:53:46 -0700
From: Nick Sayer 

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

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

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

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

Anybody have any ideas or suggestions along these lines?



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

Re: [time-nuts] NEO-7M various modes

[Wayne Holder]

uBlox has a utility called u-center
 that's a free
download.  You can use it to configure the various output options (and
enable and disable different messages) and a then save this config back to
the module as the start up default.

Wayne

On Sat, Oct 28, 2017 at 3:12 PM, jimlux  wrote:

> I've got 4 NEO-7M-C modules hooked up to 7 beaglebone greens, side by
> side, and they're not behaving the same..
>
> I've got gpsd running, and I'm looking at the output of cgps and/or
> gpsmon, as well as ppstest
>
>
> Some emit NMEA sentences, others binary (ublox?) strings?
>
> Some get a fix and start toggling the 1pps line, others don't.
>
> Is there some command string one can send to them to put them into a known
> state (cold reset?) - the one that's working the best (I.e. has a fix AND
> toggles 1pps) seems to be putting out binary strings (when viewed with
> gpsmon).
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/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] NEO-7M various modes

[jimlux]

I've got 4 NEO-7M-C modules hooked up to 7 beaglebone greens, side by 
side, and they're not behaving the same..


I've got gpsd running, and I'm looking at the output of cgps and/or 
gpsmon, as well as ppstest



Some emit NMEA sentences, others binary (ublox?) strings?

Some get a fix and start toggling the 1pps line, others don't.

Is there some command string one can send to them to put them into a 
known state (cold reset?) - the one that's working the best (I.e. has a 
fix AND toggles 1pps) seems to be putting out binary strings (when 
viewed with gpsmon).



___
time-nuts mailing 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] chrony vs ntpd

[jimlux]

On 10/28/17 2:25 PM, djl wrote:

Would a step recovery diode be better?
for example 
http://www.mwrf.com/analog-semiconductors/designing-step-recovery-diode-based-comb-generator 



Maybe, but that's starting to increase the complexity.  I've used 
various and sundry harmonic mixers using SRDs (aka Sampling Phase 
Detectors)  The SRD has very fast transition times, so getting well up 
into microwave is easy.


For my application, I'm happy down at 15 MHz, and a reasonably fast rise 
time on a 1 microsecond pulse does it quite nicely.

___
time-nuts mailing 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] chrony vs ntpd

[djl]

Would a step recovery diode be better?
for example 
http://www.mwrf.com/analog-semiconductors/designing-step-recovery-diode-based-comb-generator

Don

On 2017-10-28 12:20, jimlux wrote:

On 10/28/17 10:34 AM, John Ackermann N8UR wrote:
Jim, I thought about using an RF-input sync pulse for alignment during 
the Solar Eclipse measurement experiment, but ended up running out of 
time to implement it.  But some very crude experiments indicated that 
it's not hard to generate an edge out of a PPS that creates a comb 
well past HF.  My idea was to do a divide-by-sixty to end up with 
pulse-per-minute rather than PPS.  The lower rate would be less 
annoying to filter out of the results.


I'm interested to hear if you end up doing this, and if so how.



Yes, a nice narrow pulse makes a nice comb.  I've done it for a single
shot wideband gain calibration across the band for my space HF
receiver (in ground test).

The tricky parts, I have found, are:
1) the rise and fall time have a big effect on the relative heights of
the comb vs freq - perfectly square gives you a nice sin(x)/x, but if
it starts to be not-square, then it rolls off faster.  I've been
thinking about how to do something that measures it

2) Amplitude of the pulse - that one seems pretty straightforward - a
good switch from a regulated voltage.

3) The effects of the antenna and receiver impedances - well - to a
certain extent, that's what I want to measure.   So the idea is that
if you inject a pulse through a known resistance into the
receiver/antenna combination (at the receiver input), and, I do this
at two or three different impedances, I should be able to back out the
impedance effects (with some TBD uncertainty).


So far, I've been experimenting with RF tone bursts from a 33622
function generator - Easy to detect, but I've not found a good way to
get a nice sharp marker - you can slide a matched filter along and get
a sort of pulse, but it's not what I want.

I'm starting to think that some sort of PN code might be the way to go
- It makes it easy to integrate over a longer time (e.g. many edges to
look at).





John


On 10/28/2017 12:04 PM, jimlux wrote:
Now that I have successfully connected my GPS receiver to my beagle 
and I'm getting pps ticks into the driver, etc. (thanks to info from 
several folks on this list!) the question arises of whether to use 
ntpd or chrony.


For my particular application, I'm more interested in synchronizing 
time on the local machine, not necessarily being a NTP server - all 
of my beagles have a GPS on them.  Of course, there may be times when 
a GPS doesn't work, or something else comes up where it would be 
useful for one of the machines to "get time" from somewhere else.


What I am doing is using the Beagle to capture RF samples (RTL-SDR) 
in a distributed array, with wireless connections among the nodes.  
The processing isn't necessarily real-time (maybe later..), for now, 
it's "trigger some seconds of capture at approximately the same time" 
and post process in matlab/octave.


There's all kinds of nondeterministic latency issues with the 
USB/RTL-SDR path, so I'm under no illusion that I can capture samples 
aligned to the 1pps.  However, what I *can* do is generate a "sync 
pulse" from the 1 pps and feed it into the RTL's RF input in some 
(TBD) way.
And the 1pps might give me a clever way to calibrate the frequency 
drift of the RTLSDR's clock.


Right now, I'm interested in HF signals (so the period is 30 ns at 
the top end, and 500 ns at the bottom end)




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


--
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304

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

Re: [time-nuts] chrony vs ntpd

[Hal Murray]

I don't know much about chrony.

jim...@earthlink.net said:
> Now that I have successfully connected my GPS receiver to my beagle and  I'm
> getting pps ticks into the driver, etc. (thanks to info from several  folks
> on this list!) the question arises of whether to use ntpd or chrony. 

If you are running on Linux, you can get easy access to the PPS info via 
something like:
  $ cat /sys/devices/virtual/pps/pps0/assert
  1509220576.90288#60013
  $ 
The stuff in front of the # is the time, the stuff after is the pulse count.

So you can setup something to collect the offset and see how well whatever 
you are using is working.

If you want to test the non-PPS mode, you can setup your ntpd/chronyd to not 
use it.  The same measuring software will continue to collect data.
 
-

On most OSes, there are 2 ways to use the PPS.  There is an API to read the 
info.  You can use that as a source of time to steer your clock with the same 
sort of logic that you would use if you are getting time from a NTP server.  
Usually it works better because of reduced jitter.  Or, you can set a mode 
bit in the kernel and it will make the adjustments while you sit back and 
watch.

On Linux, the kernel mode is not available if your kernel is built with the 
tickless scheduler.  You have to build your own kernel...


-- 
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] Sulzer 2.5 Re-listed

[Mogford, Richard H. (ARC-TH)]

I re-listed the Sulzer 2.5.  I had to edit the listing.

 

Richard

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

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

[Nick Sayer via time-nuts]

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

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

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

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

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

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

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

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

Re: [time-nuts] chrony vs ntpd

[jimlux]

On 10/28/17 10:34 AM, John Ackermann N8UR wrote:
Jim, I thought about using an RF-input sync pulse for alignment during 
the Solar Eclipse measurement experiment, but ended up running out of 
time to implement it.  But some very crude experiments indicated that 
it's not hard to generate an edge out of a PPS that creates a comb well 
past HF.  My idea was to do a divide-by-sixty to end up with 
pulse-per-minute rather than PPS.  The lower rate would be less annoying 
to filter out of the results.


I'm interested to hear if you end up doing this, and if so how.



Yes, a nice narrow pulse makes a nice comb.  I've done it for a single 
shot wideband gain calibration across the band for my space HF receiver 
(in ground test).


The tricky parts, I have found, are:
1) the rise and fall time have a big effect on the relative heights of 
the comb vs freq - perfectly square gives you a nice sin(x)/x, but if it 
starts to be not-square, then it rolls off faster.  I've been thinking 
about how to do something that measures it


2) Amplitude of the pulse - that one seems pretty straightforward - a 
good switch from a regulated voltage.


3) The effects of the antenna and receiver impedances - well - to a 
certain extent, that's what I want to measure.   So the idea is that if 
you inject a pulse through a known resistance into the receiver/antenna 
combination (at the receiver input), and, I do this at two or three 
different impedances, I should be able to back out the impedance effects 
(with some TBD uncertainty).



So far, I've been experimenting with RF tone bursts from a 33622 
function generator - Easy to detect, but I've not found a good way to 
get a nice sharp marker - you can slide a matched filter along and get a 
sort of pulse, but it's not what I want.


I'm starting to think that some sort of PN code might be the way to go - 
It makes it easy to integrate over a longer time (e.g. many edges to 
look at).






John


On 10/28/2017 12:04 PM, jimlux wrote:
Now that I have successfully connected my GPS receiver to my beagle 
and I'm getting pps ticks into the driver, etc. (thanks to info from 
several folks on this list!) the question arises of whether to use 
ntpd or chrony.


For my particular application, I'm more interested in synchronizing 
time on the local machine, not necessarily being a NTP server - all of 
my beagles have a GPS on them.  Of course, there may be times when a 
GPS doesn't work, or something else comes up where it would be useful 
for one of the machines to "get time" from somewhere else.


What I am doing is using the Beagle to capture RF samples (RTL-SDR) in 
a distributed array, with wireless connections among the nodes.  The 
processing isn't necessarily real-time (maybe later..), for now, it's 
"trigger some seconds of capture at approximately the same time" and 
post process in matlab/octave.


There's all kinds of nondeterministic latency issues with the 
USB/RTL-SDR path, so I'm under no illusion that I can capture samples 
aligned to the 1pps.  However, what I *can* do is generate a "sync 
pulse" from the 1 pps and feed it into the RTL's RF input in some 
(TBD) way.
And the 1pps might give me a clever way to calibrate the frequency 
drift of the RTLSDR's clock.


Right now, I'm interested in HF signals (so the period is 30 ns at the 
top end, and 500 ns at the bottom end)




___
time-nuts mailing 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] vectron to be acquired by MicroSemi

[Vlad]

For those of us who tend to use legacy, older products, perhaps spares
or surplus (time-nuts list members, and flight hardware designers
alike), this can present a problem.  (Because *we* are also faced with
pressure to dispose of all that old paper and records, either from
cohabitants or managers).  This is particularly the case when we're
building up a breadboard or demonstration - I've built an awful lot of
stuff at JPL using spare parts and components with date codes in the
60s and 70s - it's not like a 2-4 GHz directional coupler made in 1964
works any different from one made in 2014.

Of course, the lack of data sheets for *semiconductor* modules and
parts from the 1980s and 1990s is probably a boon in the long run,
although a pain in the short run.  Amplifiers, mixers, etc. are all a
LOT better today (in general) than they were 20-30 years ago.  (Of
course, I *do* still have a bunch of WJ parts sitting around for
breadboarding)



This is exactly my point of view. For example, I feel that Symmetricom 
was much "open" in terms to share the tech. documentation and some 
software.
Once, I was struggle to get response from Microsemi sending them direct 
requests about the product (SYNCPOINT PCIE-1000 card, p/n 089-00376-000 
Rev 3). And only fellow time-nuts make it happens that I am getting 
right person to talk. There was no public resources available on 
Microsemi WEB site. Long story short - I was happy to get the Linux 
drivers and software for that card. But I am still struggle for the the 
microcode update (I have some "beta" version). Of course the firmware 
could be different story and it is not for free. But at least it would 
be nice to have that confirmation.


Speaking about Vectron - its also not easy to get tech. docs for the old 
versions of OCXO.


--
WBW,

V.P.
___
time-nuts mailing 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] chrony vs ntpd

[John Ackermann N8UR]

Jim, I thought about using an RF-input sync pulse for alignment during 
the Solar Eclipse measurement experiment, but ended up running out of 
time to implement it.  But some very crude experiments indicated that 
it's not hard to generate an edge out of a PPS that creates a comb well 
past HF.  My idea was to do a divide-by-sixty to end up with 
pulse-per-minute rather than PPS.  The lower rate would be less annoying 
to filter out of the results.


I'm interested to hear if you end up doing this, and if so how.

John


On 10/28/2017 12:04 PM, jimlux wrote:
Now that I have successfully connected my GPS receiver to my beagle and 
I'm getting pps ticks into the driver, etc. (thanks to info from several 
folks on this list!) the question arises of whether to use ntpd or chrony.


For my particular application, I'm more interested in synchronizing time 
on the local machine, not necessarily being a NTP server - all of my 
beagles have a GPS on them.  Of course, there may be times when a GPS 
doesn't work, or something else comes up where it would be useful for 
one of the machines to "get time" from somewhere else.


What I am doing is using the Beagle to capture RF samples (RTL-SDR) in a 
distributed array, with wireless connections among the nodes.  The 
processing isn't necessarily real-time (maybe later..), for now, it's 
"trigger some seconds of capture at approximately the same time" and 
post process in matlab/octave.


There's all kinds of nondeterministic latency issues with the 
USB/RTL-SDR path, so I'm under no illusion that I can capture samples 
aligned to the 1pps.  However, what I *can* do is generate a "sync 
pulse" from the 1 pps and feed it into the RTL's RF input in some (TBD) 
way.
And the 1pps might give me a clever way to calibrate the frequency drift 
of the RTLSDR's clock.


Right now, I'm interested in HF signals (so the period is 30 ns at the 
top end, and 500 ns at the bottom end)




___
time-nuts mailing 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] Spice simulation of PSRR and phase noise

[Mark Sims]

And it's the only way to be sure...   never trust a simulation, particularly 
for such flighty and subtle things like noise.  Simulations can be useful for 
pointing you in the right direction for a design, but where the rubber meets 
the road there is nothing like real hardware to get to the true answer.



> The only other reasonably fast and accurate way I can 
think of is to build the bloody circuit and measure it using some 
expensive equipment.
___
time-nuts mailing 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] vectron to be acquired by MicroSemi

[Bob kb8tq]

Hi

To some extent, companies are acquired for their heritage / IP. That can
give a pretty strong push towards hanging on to all the old files and 
designs. Certainly that’s been the case with Vectron (and with McCoy, 
Piezo, Ovenair, Telequartz, Oscillatek, ….) through multiple passes at this. 

Bob

> On Oct 28, 2017, at 11:51 AM, jimlux  wrote:
> 
> On 10/28/17 6:19 AM, Bob kb8tq wrote:
>> Hi
>> In terms of what Vectron actually manufacturers, there isn’t a *lot* of 
>> overlap
>> with Microsemi. Compared to a a lot of possible matchups this one does not
>> have to many things to work out. They both do a bit in space and they both
>> do GPSDO’s. Past that, the other stuff is not in markets or technologies
>> that overlap.
> 
> one concern would be if there's a desire to consolidate or move manufacturing 
> - I'm thinking here of the Symmetricom CSAC vs MicroSemi CSAC story.
> 
> I'm in the space business for the most part, and there's great emphasis on 
> Heritage - we bought Part XYZ from Company ABC for the Ranger mission to the 
> moon and it worked in 1967, so lets just keep using it.  While I'm not a huge 
> fan of the value of heritage (I think it's often a "you can't go wrong buying 
> IBM" kind of strategy to reduce the number of questions in design reviews) - 
> when it does exist, it's "XYZ people" not "released drawing number in XYZ's 
> library" that gives you the desired product.
> 
> 
> The other concern about acquisitions in general (I don't know if that's an 
> issue here)  is that there tends to be a "cleaning out of old files and 
> websites" as part of the process - documentation, data sheets, etc. for "not 
> in the current product line" often disappears.
> 
> For those of us who tend to use legacy, older products, perhaps spares or 
> surplus (time-nuts list members, and flight hardware designers alike), this 
> can present a problem.  (Because *we* are also faced with pressure to dispose 
> of all that old paper and records, either from cohabitants or managers).  
> This is particularly the case when we're building up a breadboard or 
> demonstration - I've built an awful lot of stuff at JPL using spare parts and 
> components with date codes in the 60s and 70s - it's not like a 2-4 GHz 
> directional coupler made in 1964 works any different from one made in 2014.
> 
> Of course, the lack of data sheets for *semiconductor* modules and parts from 
> the 1980s and 1990s is probably a boon in the long run, although a pain in 
> the short run.  Amplifiers, mixers, etc. are all a LOT better today (in 
> general) than they were 20-30 years ago.  (Of course, I *do* still have a 
> bunch of WJ parts sitting around for breadboarding)
> 
> 
> ___
> time-nuts mailing 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] chrony vs ntpd

[jimlux]

Now that I have successfully connected my GPS receiver to my beagle and 
I'm getting pps ticks into the driver, etc. (thanks to info from several 
folks on this list!) the question arises of whether to use ntpd or chrony.


For my particular application, I'm more interested in synchronizing time 
on the local machine, not necessarily being a NTP server - all of my 
beagles have a GPS on them.  Of course, there may be times when a GPS 
doesn't work, or something else comes up where it would be useful for 
one of the machines to "get time" from somewhere else.


What I am doing is using the Beagle to capture RF samples (RTL-SDR) in a 
distributed array, with wireless connections among the nodes.  The 
processing isn't necessarily real-time (maybe later..), for now, it's 
"trigger some seconds of capture at approximately the same time" and 
post process in matlab/octave.


There's all kinds of nondeterministic latency issues with the 
USB/RTL-SDR path, so I'm under no illusion that I can capture samples 
aligned to the 1pps.  However, what I *can* do is generate a "sync 
pulse" from the 1 pps and feed it into the RTL's RF input in some (TBD) way.
And the 1pps might give me a clever way to calibrate the frequency drift 
of the RTLSDR's clock.


Right now, I'm interested in HF signals (so the period is 30 ns at the 
top end, and 500 ns at the bottom end)




___
time-nuts mailing 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] vectron to be acquired by MicroSemi

[jimlux]

On 10/28/17 6:19 AM, Bob kb8tq wrote:

Hi

In terms of what Vectron actually manufacturers, there isn’t a *lot* of overlap
with Microsemi. Compared to a a lot of possible matchups this one does not
have to many things to work out. They both do a bit in space and they both
do GPSDO’s. Past that, the other stuff is not in markets or technologies
that overlap.




one concern would be if there's a desire to consolidate or move 
manufacturing - I'm thinking here of the Symmetricom CSAC vs MicroSemi 
CSAC story.


I'm in the space business for the most part, and there's great emphasis 
on Heritage - we bought Part XYZ from Company ABC for the Ranger mission 
to the moon and it worked in 1967, so lets just keep using it.  While 
I'm not a huge fan of the value of heritage (I think it's often a "you 
can't go wrong buying IBM" kind of strategy to reduce the number of 
questions in design reviews) - when it does exist, it's "XYZ people" not 
"released drawing number in XYZ's library" that gives you the desired 
product.



The other concern about acquisitions in general (I don't know if that's 
an issue here)  is that there tends to be a "cleaning out of old files 
and websites" as part of the process - documentation, data sheets, etc. 
for "not in the current product line" often disappears.


For those of us who tend to use legacy, older products, perhaps spares 
or surplus (time-nuts list members, and flight hardware designers 
alike), this can present a problem.  (Because *we* are also faced with 
pressure to dispose of all that old paper and records, either from 
cohabitants or managers).  This is particularly the case when we're 
building up a breadboard or demonstration - I've built an awful lot of 
stuff at JPL using spare parts and components with date codes in the 60s 
and 70s - it's not like a 2-4 GHz directional coupler made in 1964 works 
any different from one made in 2014.


Of course, the lack of data sheets for *semiconductor* modules and parts 
from the 1980s and 1990s is probably a boon in the long run, although a 
pain in the short run.  Amplifiers, mixers, etc. are all a LOT better 
today (in general) than they were 20-30 years ago.  (Of course, I *do* 
still have a bunch of WJ parts sitting around for breadboarding)



___
time-nuts mailing 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] Spice simulation of PSRR and phase noise

[Bob kb8tq]

Hi

The “fun part” of harmonic balance is making sure you are not off in a corner
case where the results are not as good as they might otherwise be. Maybe not
as much an issue for a VCO as for some other structures. 

Bob

> On Oct 28, 2017, at 7:36 AM, Rafael Gajanec  wrote:
> 
> Hi Attila,
> 
> On 27-Oct-17 8:25 PM, Attila Kinali wrote:
>> Hi Rafael
>> 
>> On Sun, 22 Oct 2017 17:20:52 +0200
>> Rafael Gajanec  wrote:
>> 
>>> you haven't specified what sort of circuits would you like to simulate,
>> Simplified, they are differential amplifiers driven into saturation.
>> A bit more detailed, I am looking at ring oscillator stages and 
>> sine-to-square
>> conversion circuits and their behaviour regarding various key factors
>> (note: I am not sure what the key factors are, yet)
> Oscillator design - that's what I found HB simulation particularly useful 
> for. It gives you almost instant results, compared to the transient 
> simulation, say 10 seconds instead of 5 hours! Just imagine what it means if 
> you are trying to tune several parameters of an oscillator... The only other 
> reasonably fast and accurate way I can think of is to build the bloody 
> circuit and measure it using some expensive equipment.
>> 
>>> but maybe the answer is Harmonic Balance.
>> Hmm.. I didn't know about Harmonic Balance. I have some reading up to do.
>> Thanks!
>> 
>>> HSPICE from Synopsis and ADS from Keysight (which I use) also have the
>>> HB engine.
>> I am mostly using ngpsice, because it's very easy to script (I have a bunch
>> of perl scripts that feed simulations into a Grid Engine cluster, extract
>> data and analyzse it). Is there any big advantage of the commercial spice
>> engines that would make them worth considering? And would the license alow
>> to run hundreds of instances in parallel?
>> (Yes, I am doing crazy things :-)
> Attached are some results of a simple transient simulation using Hspice M 
> 2017.03, BBspice A/D 5.2.3 and ADS 2016.01. It's basically *V1 1 0 SIN 0 1 
> 1Meg *and then *.FOUR 1Meg V(1)* in Hspice, VspecTran in ADS and spectra 
> computed using postprocessor in BBspice and ADS. As you can see, there are 
> some differences... To be fair, possibly there are some simulator-specific 
> settings/methods that could improve the results and you should figure it out 
> yourself what's the way to get the best results from your spice. See 
> http://www.audio-perfection.com/spice-ltspice/distortion-measurements-with-ltspice.html
> 
> Commercial spice engines may have lower computational noise and shorter 
> simulation times. For example my out-dated BBspice (which is commercial too 
> by the way) crashed several times before I got some results, while it used 
> little RAM and only about 10-12% of available processor resources... I 
> intended to get you Pspice results of this simulation as well, but I gave up 
> after half an hour and about 1% of progress.
> 
>> 
>>  Attila Kinali
> 
> Best regards,
> Rafael Gajanec
> ___
> time-nuts mailing 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] Spice simulation of PSRR and phase noise

[Rafael Gajanec]

Hi Attila,

On 27-Oct-17 8:25 PM, Attila Kinali wrote:

Hi Rafael

On Sun, 22 Oct 2017 17:20:52 +0200
Rafael Gajanec  wrote:


you haven't specified what sort of circuits would you like to simulate,

Simplified, they are differential amplifiers driven into saturation.
A bit more detailed, I am looking at ring oscillator stages and sine-to-square
conversion circuits and their behaviour regarding various key factors
(note: I am not sure what the key factors are, yet)
Oscillator design - that's what I found HB simulation particularly 
useful for. It gives you almost instant results, compared to the 
transient simulation, say 10 seconds instead of 5 hours! Just imagine 
what it means if you are trying to tune several parameters of an 
oscillator... The only other reasonably fast and accurate way I can 
think of is to build the bloody circuit and measure it using some 
expensive equipment.



but maybe the answer is Harmonic Balance.

Hmm.. I didn't know about Harmonic Balance. I have some reading up to do.
Thanks!


HSPICE from Synopsis and ADS from Keysight (which I use) also have the
HB engine.

I am mostly using ngpsice, because it's very easy to script (I have a bunch
of perl scripts that feed simulations into a Grid Engine cluster, extract
data and analyzse it). Is there any big advantage of the commercial spice
engines that would make them worth considering? And would the license alow
to run hundreds of instances in parallel?
(Yes, I am doing crazy things :-)
Attached are some results of a simple transient simulation using Hspice 
M 2017.03, BBspice A/D 5.2.3 and ADS 2016.01. It's basically *V1 1 0 SIN 
0 1 1Meg *and then *.FOUR 1Meg V(1)* in Hspice, VspecTran in ADS and 
spectra computed using postprocessor in BBspice and ADS. As you can see, 
there are some differences... To be fair, possibly there are some 
simulator-specific settings/methods that could improve the results and 
you should figure it out yourself what's the way to get the best results 
from your spice. See 
http://www.audio-perfection.com/spice-ltspice/distortion-measurements-with-ltspice.html


Commercial spice engines may have lower computational noise and shorter 
simulation times. For example my out-dated BBspice (which is commercial 
too by the way) crashed several times before I got some results, while 
it used little RAM and only about 10-12% of available processor 
resources... I intended to get you Pspice results of this simulation as 
well, but I gave up after half an hour and about 1% of progress.




Attila Kinali


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

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

[Leo Bodnar]

> From: Attila Kinali 
> Can you tell a little bit how your device looks like on the inside?

GPS is a Ublox.  MCU is Cortex-M7 and does not run any OS - just main loop with 
prioritised interrupts.  Network stack is hand-made. 
I don't use saw-tooth correction in this device because +-11ns is not worth 
correcting for NTP application for such a budget device.
If you can build a test NTP client system that can detect sawtooth 10ns offset 
from the NTP server I'd like to know how you did it.

>> When you come to testing I can highly recommend placing your prototypes in 
>> public NTP pool and asking the admins to add it to .ch zone - you are 
>> guaranteed to get full 110kpps traffic spikes that will help to flush out 
>> bugs.
> 
> Why specifically the .ch zone? IIRC you are located in the uk.
> I am running an NTP server in the .ch pool and have not yet noticed any large 
> spikes. (ok, my monitoring is rather crude and if the spike is very short 
> lived, i wouldnt notice it)

Sorry, it was a typo - I meant Chinese zone (.cn)
Spikes usually happen around full or half-hour and last only few seconds but 
you often (about once a day) get true 100% fully saturated wire speed with 
packets coming in (and out) back to back.
The theory behind these spikes is interesting - most probably they are results 
of SNTP clients running from cron jobs. So, ironically, the more accurate time 
they receive from you, the more concentrated their behaviour becomes.

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

Re: [time-nuts] vectron to be acquired by MicroSemi

[Bob kb8tq]

Hi

In terms of what Vectron actually manufacturers, there isn’t a *lot* of overlap 
with Microsemi. Compared to a a lot of possible matchups this one does not
have to many things to work out. They both do a bit in space and they both
do GPSDO’s. Past that, the other stuff is not in markets or technologies 
that overlap.

Indeed Vectron re-sells various things. My guess is that some of those 
relationships will change a bit. I’d say it’s unlikely they will continue to 
resell 
Accubeat Rb’s once the deal gets done and the reorganization is complete. 

Looked at from the side of “how many vendors on the vendor list”, yes this
takes one off the list. Most companies are working to trim down that list 
rather than build it up. The ideal seems to be to have three giant outfits that
can each sell you 100% of your needs. You then have a run-off between the
three each week to decide who gets it all this time based only on price. 
(Yes, that may be a slight exaggeration, but not by much).

Certainly having a parent in the timing business will give them more ability 
to work with the rest of the company. Their prior parent (Knowles) was more
focused on the audio business. There’s not a lot of common customer base
between Vectron and the main part of Knowles. 

Since they are looking to close very quickly, I doubt they expect any real 
issues
as far as the various government  regulators. I’d bet at least a couple of 
beers 
that they have some *very* good guidance on that part of it by now. 

Bob

> On Oct 28, 2017, at 4:09 AM, tim...@timeok.it wrote:
> 
> 
>   Hi,
>   It has become a colossus.
>   And market competition?
>   Luciano.
>   www.timeok.it
> 
> 
>   Da "time-nuts" time-nuts-boun...@febo.com
>   A "Discussion of precise time and frequency measurement" time-nuts@febo.com
>   Cc
>   Data Fri, 27 Oct 2017 20:14:01 -0400
>   Oggetto Re: [time-nuts] vectron to be acquired by MicroSemi
>   Hi
> 
>   Not a lot of detail out there other than that the deal is expected to close 
> before the
>   end of December.
> 
>   Bob
> 
>> On Oct 27, 2017, at 6:42 PM, jimlux  wrote:
>> 
>> from a recent email blast - "I am pleased to inform you that Microsemi 
>> Corporation has agreed to acquire the high performance timing business of 
>> Vectron International, a Knowles company."
>> ___
>> time-nuts mailing 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] vectron to be acquired by MicroSemi

[tim...@timeok.it]

   Hi,
   It has become a colossus.
   And market competition?
   Luciano.
   www.timeok.it


   Da "time-nuts" time-nuts-boun...@febo.com
   A "Discussion of precise time and frequency measurement" time-nuts@febo.com
   Cc
   Data Fri, 27 Oct 2017 20:14:01 -0400
   Oggetto Re: [time-nuts] vectron to be acquired by MicroSemi
   Hi

   Not a lot of detail out there other than that the deal is expected to close 
before the
   end of December.

   Bob

   > On Oct 27, 2017, at 6:42 PM, jimlux  wrote:
   >
   > from a recent email blast - "I am pleased to inform you that Microsemi 
Corporation has agreed to acquire the high performance timing business of 
Vectron International, a Knowles company."
   > ___
   > time-nuts mailing 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.