[time-nuts] Suggestions on getting 24 MHz?

[Perry Sandeen via time-nuts]

Esteemed List Members,
I have four new Midland glass encased 3.00 MHz HC 6 case style available.  
Each one was given a S/N and were ordered for Hallicrafters circa.  Ovenized 
they would be excellent although I don't now what oven temp was specified.  
Best guess is 85 C.
I can send world wide.
If interested please send and email directly to me at sandeenpa at yahoo dot 
com  (Please do not reply on the list.)
Regards,
Perrier
___
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] TCVCXO Adjustment

[Adrian Godwin]

Could you use the "pips" instead of a PPS signal, again comparing them some
weeks apart to give a long reference time ?

https://en.wikipedia.org/wiki/Greenwich_Time_Signal

If your local radio broadcaster doesn't play something like them, they
could probably be generated with a web application.


On Sat, Apr 14, 2018 at 12:13 AM, Wayne Holder 
wrote:

> Again, thanks for all the great feedback and suggestions.
>
> > Are you familiar with these devices which I just found this week?
> > https://tentaclesync.com/products
>
> Yes, that's one of the lower cost commercial units available.  Another is
> the NanoLockiIt by Ambient
>  recording_acn_nl_nanolockit_miniature_timecode_synchronizer.html>,
> which is company that's been making timecode products for many years.
> Compared to more traditional prices for timecode generators, these are
> relatively inexpensive at about $300.  However you need at least two, or
> more generators to be useful, so that adds up pretty fast for an amateur
> videographer, or starving film school student.  In contrast,  BOM for the
> design I'm working on is less than $30 (the TCVCXO being, by far, the
> most expensive part.)
>
> My plan is to also write a desktop application, probably in Java to make it
> portable, that the person building the devices could use to perform the
> initial calibration and also setup various options.  So, the NTP-based
> solution is attractive in that it doesn't require any additional hardware.
> I'm a Mac user so, after a bit of reading the NTP implementation on the
> Mac, I tried a few experiments.  Typing "ntpq -p" in the terminal
> app produced this response:
>
>  remote   refid  st t when poll reach   delay   offset
> jitter
>
> 
> ==
>
> *usdal2-ntp-001. .GPSs.   1 u  428 1024  377   51.1311.944
> 1.153
>
> and typing  "ntpq -c rl" printed out:
>
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
>
> version="ntpd 4.2.8p6@1.3265 Fri Feb  5 17:38:17 UTC 2016 (124.60.2~39)",
>
> processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2,
>
> precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125,
>
> reftime=de7ba9c1.937e5f86  Fri, Apr 13 2018 15:12:17.576,
>
> clock=de7badf7.39f8d36a  Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10,
>
> mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.00,
>
> clk_jitter=0.745, clk_wander=0.001
>
> I believe that the "precision" of -20 value on the 4th line is supposed to
> be interpreted as 2^-20 seconds which, if my math is correct, works out to
> be a precision of about 1 PPM. Is that correct?  If so, it would seem like
> I should be able to use my system's internal clock to perform a "tweak" in
> around 10,000 seconds, or a little less than 3 hours.  Does this seem
> correct, or have I missed something?
>
> Alternately, if I included a GPS receiver in the design, the whole process
> could be done within the device, which would probably be the easiest
> approach to calibration for the person building one.  This would increase
> the cost and make the device larger, but users could then maintain
> calibration by periodically keeping them plugged in for a few hours.  Or,
> perhaps I could just design a 2nd board for a GPS "calibrator" module that
> could be plugged into the timecode generators to calibrate them.  Hmm...
> lots to think about.
>
> Wayne
> ___
> 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] femtosecond jitter

[Bruce Griffiths]

Thus a DDMTD using NB7V52's as the mixers should have useful performance

Bruce 
> On 14 April 2018 at 03:54 John Larkin  wrote:
> 
> 
> If you walk the differential data and clock inputs of an NB7V52  CML 
> flipflop across one another in time, the equivalent jitter is below 20 
> fs RMS. That's what we're measuring, but our test rig may well dominate 
> the jitter, so the flop is probably better.
> 
> We're using this to test the jitter of some of our timing products, with 
> 1/10 the noise floor and 1e-4 times the cost of other ways to do it.
> 
> https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1
> 
> https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1
> 
> https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1
> 
> 
> -- 
> ** arb
> 
> John Larkin, President
> Highland Technology, Inc
> 18 Otis Street
> San Francisco, CA 94103
> 
> phone 415 551-1700   fax 551-5129
> jjlar...@highlandtechnology.com
> http://www.highlandtechnology.com
> 
> This is a Highland Technology confidential communication
> 
> ___
> 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] getting accurate timing on RTL-SDR output

[Mark Sims]

Note that on a lot of GPS devices that only one edge of the 1PPS pulse is 
stable and the other edge can jitter a bit.

Also, you might want to try programming the PPS to a 50% duty cycle (but having 
an asymmetrical PPS pulse might have some advantages for post processing).

The receiver with the best 1PPS stability  that I have tested is the Furuno 
GT-8736.  Its typical span is under +/- 4ns from nominal. 
___
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] TCVCXO Adjustment

[Hal Murray]

wayne.hol...@gmail.com said:
> I believe that the "precision" of -20 value on the 4th line is supposed to
> be interpreted as 2^-20 seconds which, if my math is correct, works out to
> be a precision of about 1 PPM. Is that correct?

That's the time between ticks or the time it takes to read the clock.  It 
doesn't tell you anything about how correct the clock is.


-- 
These are my opinions.  I hate spam.



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

Re: [time-nuts] TCVCXO Adjustment

[Bob kb8tq]

Hi

With NTP (or any other timing system) you really need 3 or more sources to sort
things out. If you only have one source, eventually everything will converge on 
it. 
That’s not to say that it will be correct, you simply will be 100% locked to 
it. 

GPS modules are a “sub $20” sort of thing these days. You aren’t after super 
duper
precision. Simply drop one on your board and run it all the time ….

The alternative is to plug a USB GPS into the mac and do a bit of code to 
compare
things. If you want to pass the gizmo around to your friends …. that can be 
done. Pretty
good ones are “sub $10” delivered. 

Bob

> On Apr 13, 2018, at 7:13 PM, Wayne Holder  wrote:
> 
> Again, thanks for all the great feedback and suggestions.
> 
>> Are you familiar with these devices which I just found this week?
>> https://tentaclesync.com/products
> 
> Yes, that's one of the lower cost commercial units available.  Another is
> the NanoLockiIt by Ambient
> ,
> which is company that's been making timecode products for many years.
> Compared to more traditional prices for timecode generators, these are
> relatively inexpensive at about $300.  However you need at least two, or
> more generators to be useful, so that adds up pretty fast for an amateur
> videographer, or starving film school student.  In contrast,  BOM for the
> design I'm working on is less than $30 (the TCVCXO being, by far, the
> most expensive part.)
> 
> My plan is to also write a desktop application, probably in Java to make it
> portable, that the person building the devices could use to perform the
> initial calibration and also setup various options.  So, the NTP-based
> solution is attractive in that it doesn't require any additional hardware.
> I'm a Mac user so, after a bit of reading the NTP implementation on the
> Mac, I tried a few experiments.  Typing "ntpq -p" in the terminal
> app produced this response:
> 
> remote   refid  st t when poll reach   delay   offset
> jitter
> 
> ==
> 
> *usdal2-ntp-001. .GPSs.   1 u  428 1024  377   51.1311.944
> 1.153
> 
> and typing  "ntpq -c rl" printed out:
> 
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> 
> version="ntpd 4.2.8p6@1.3265 Fri Feb  5 17:38:17 UTC 2016 (124.60.2~39)",
> 
> processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2,
> 
> precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125,
> 
> reftime=de7ba9c1.937e5f86  Fri, Apr 13 2018 15:12:17.576,
> 
> clock=de7badf7.39f8d36a  Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10,
> 
> mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.00,
> 
> clk_jitter=0.745, clk_wander=0.001
> 
> I believe that the "precision" of -20 value on the 4th line is supposed to
> be interpreted as 2^-20 seconds which, if my math is correct, works out to
> be a precision of about 1 PPM. Is that correct?  If so, it would seem like
> I should be able to use my system's internal clock to perform a "tweak" in
> around 10,000 seconds, or a little less than 3 hours.  Does this seem
> correct, or have I missed something?
> 
> Alternately, if I included a GPS receiver in the design, the whole process
> could be done within the device, which would probably be the easiest
> approach to calibration for the person building one.  This would increase
> the cost and make the device larger, but users could then maintain
> calibration by periodically keeping them plugged in for a few hours.  Or,
> perhaps I could just design a 2nd board for a GPS "calibrator" module that
> could be plugged into the timecode generators to calibrate them.  Hmm...
> lots to think about.
> 
> Wayne
> ___
> 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] WWVB information

[Tom Van Baak]

So Doug's Spectracom WWVB receiver shows a green lock status. I didn't believe 
it, but he sent a photo. I then tried it here and the same thing happens to me. 
It's very suspicious because we know these old carrier phase WWVB receivers 
don't work with the enhanced WWVB broadcast format.

Instead of trusting the green light I measured the 5 MHz output of the 
WWVB-disciplined receiver using a hp 53132A. Here's an example of 1 second 
readings with no antenna (no lock):
431.22296  Hz
431.22650  Hz
431.22709  Hz
431.209453 Hz
431.21235  Hz
STD DEV: 0.007968 Hz

You see a free-running undisciplined OCXO. Not very accurate but very stable.

Then I connected the WWVB antenna. Within seconds the green lock light came on. 
The readings looked like:
494.676217 Hz
514.45065  Hz
466.61447  Hz
463.27949  Hz
471.40319  Hz
STD DEV: 15.853246 Hz

You see that the OCXO has been steered closer to 5 MHz, but the stability is 
horrible.

Lastly, just to check the system was working, I applied a 60 kHz carrier near 
the antenna using a hp 3325B. The readings look like:
499.9693  Hz
500.0199  Hz
500.0202  Hz
499.9693  Hz
499.9998  Hz
STD DEV: 0.02355 Hz

In this case very accurate and quite stable.

ADEV plot of all three runs is attached.

So my conclusion is the green lock light is false. The Spectracom really isn't 
locking to the carrier. It's trying hard, but the new phase encoding keeps this 
from happening. Someone can take a look at the block diagram or schematic and 
explain why the circuit gets fooled into thinking there is lock when there 
really isn't. Look for Spectracom 8161 or 8164 on ko4bb's manual site.

The one mystery is why this false green only started a week ago for Doug. If 
any of you have Spectracom WWVB receivers, fire then up and see what happens. I 
think I'll keep mine going for a few days or months and see if the false green 
ever goes out.

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

Re: [time-nuts] TCVCXO Adjustment

[Wayne Holder]

Again, thanks for all the great feedback and suggestions.

> Are you familiar with these devices which I just found this week?
> https://tentaclesync.com/products

Yes, that's one of the lower cost commercial units available.  Another is
the NanoLockiIt by Ambient
,
which is company that's been making timecode products for many years.
Compared to more traditional prices for timecode generators, these are
relatively inexpensive at about $300.  However you need at least two, or
more generators to be useful, so that adds up pretty fast for an amateur
videographer, or starving film school student.  In contrast,  BOM for the
design I'm working on is less than $30 (the TCVCXO being, by far, the
most expensive part.)

My plan is to also write a desktop application, probably in Java to make it
portable, that the person building the devices could use to perform the
initial calibration and also setup various options.  So, the NTP-based
solution is attractive in that it doesn't require any additional hardware.
I'm a Mac user so, after a bit of reading the NTP implementation on the
Mac, I tried a few experiments.  Typing "ntpq -p" in the terminal
app produced this response:

 remote   refid  st t when poll reach   delay   offset
jitter

==

*usdal2-ntp-001. .GPSs.   1 u  428 1024  377   51.1311.944
1.153

and typing  "ntpq -c rl" printed out:

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,

version="ntpd 4.2.8p6@1.3265 Fri Feb  5 17:38:17 UTC 2016 (124.60.2~39)",

processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2,

precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125,

reftime=de7ba9c1.937e5f86  Fri, Apr 13 2018 15:12:17.576,

clock=de7badf7.39f8d36a  Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10,

mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.00,

clk_jitter=0.745, clk_wander=0.001

I believe that the "precision" of -20 value on the 4th line is supposed to
be interpreted as 2^-20 seconds which, if my math is correct, works out to
be a precision of about 1 PPM. Is that correct?  If so, it would seem like
I should be able to use my system's internal clock to perform a "tweak" in
around 10,000 seconds, or a little less than 3 hours.  Does this seem
correct, or have I missed something?

Alternately, if I included a GPS receiver in the design, the whole process
could be done within the device, which would probably be the easiest
approach to calibration for the person building one.  This would increase
the cost and make the device larger, but users could then maintain
calibration by periodically keeping them plugged in for a few hours.  Or,
perhaps I could just design a 2nd board for a GPS "calibrator" module that
could be plugged into the timecode generators to calibrate them.  Hmm...
lots to think about.

Wayne
___
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] Ultralink

[Hal Murray]

j...@febo.com said:
> The modular cable connecting the receiver to the decoder is wired  straight
> through, not reversed as most telephone cables are.  My fear is  that
> someone (like me) might at one point have used a reverse cable and  thus put
> reverse polarity on the board; I don't see any reverse power  protection. 

Many thanks for that comment.  I hadn't checked that before.

My cable was reversed.  A new/correct one arrived today.  The meter is 
working.  With a bit of practice, I'll bet I could read the data pattern off 
the wiggles.

But after an hour, the LCD still shows time-since-power-up rather than date 
and time.


-- 
These are my opinions.  I hate spam.



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

Re: [time-nuts] WWVB information

[paul swed]

Hal when I was building de-psk-ers and such I have to say I did not see the
imbalance. It looked pretty solid in timing.
The fact that at each minute for the first number of seconds the phase is
actually fixed just before the preamble is useful.
It clears out any possible buildup if it existed.
Also unless I used a number of tricks like de-psk-rs and fixed carrier
insertion none of my spectracoms. True Times would decode time. I am east
cost US so quite far away from wwvb. I believe simple tricks by others far
closer actually do work.
Regards
Paul
WB8TSL

On Fri, Apr 13, 2018 at 5:26 PM, Hal Murray  wrote:

> The month recently changed from 3 to 4.  A while ago, the bottom digit of
> the
> year changed from 8 to 7.  I think the out-of-phase time is shorter for a
> 0
> than for a 1.  Would a few more 0 bits be enough to push it into sync?
>
> Is there "goodness" parameter that you can monitor?  It might be
> interesting
> to see if that correlates with day, hour, minute encoding?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] getting accurate timing on RTL-SDR output

[jimlux]

On 4/13/18 1:47 PM, Magnus Danielson wrote:

Hi Jim,

On 04/13/2018 06:52 PM, Jim Lux wrote:

I'm building a phased array receiver (actually, an interferometer) using
RTL-SDR pods, where the elements are isolated from each other - there's
a common WiFi network connection, and each node has a BeagleBone Green,
a uBlox OEM-7M-C, and the RTL-SDR V3 (which works down to HF, since it
has an internal bypass around the RF front end).

In general, I have the RTL-SDR set up to capture at 1 Megasample/second.
I fire off a capture, record it to a file in the BeagleBone's flash,
then retrieve it from my host computer using scp over the network.

What I'm trying to do is capture data from all the nodes at
(approximately) the same time, then be able to line it all up in post
processing. The GPS (or NTP) is good enough to get them all to start
recording within a few tenths of a second.

So now the challenge is to "line em up".  An obvious approach is to
transmit an inband pilot tone with some sync pattern, received by all,
and I'm working on that too.

But right now, I have the idea of capacitively coupling the 1pps pulse
from the GPS to the antenna input - the fast rising and falling edge are
broad band and show up in the sampled data.

The attached pulses1.png shows the integrated power in 1 ms chunks (i.e.
I sum the power from 1000 samples for each chunk) and it's easy to see
the GPS edges.  And it's easy to create a estimate of the coarse timing
(to 1 millisecond) - shown as the red trace.

But then, I want to get better.  So for the 20 edges in my 10 second
example, I plotted  (drift1.png) the raw I/Q output of the RTL.  The
pulse isn't too huge (maybe 10 DN out of the ADC's -128 to +128 range),
but is visible. Bottom trace is the first, and they're stacked up
0, 0.1, 1.0, 1.1, 2.0, 2.1, etc.

And you can see, no surprise, that the sample clock in the RTL isn't
dead on - over the 10 seconds, it looks like it drifts about 30- 50
microseconds - that is, the RTL clock is slow by 3-5 ppm.

SO here's the question for the time-nuts hive-mind...
What's a good (or not so good) way to develop an estimator of the
timing/frequency error. Post processing minutes of data is just fine..

I'm not sure what the actual "waveform" that is being sampled is (and it
will be perturbed by the quantization of the ADC, and probably not be
the same depending on where the RTL is tuned).  That is there's some
sort of LPF in the front of the RTL, the edge is AC coupled, and then it
goes into some sort of digital down converter in the RTL running at 28.8
MHz sample rate.

But it seems that there might be some way to "stack" a series of samples
and optimize some parameters to estimate the instantaneous time error-
given that the frequency vs time varies fairly slowly (over a minute or
so).  It's fairly obvious from the plot that if one looked at the
"single" sample when the edge comes in, not only does the time shift
with each pulse, but the phase rotates as well (totally expected)

this is one of those things where you could probably lay a ruler on it
and estimate it by eye pretty well, but I'd like an automated algorithm.

It would be nice to be able to estimate the timing to, say, a few
nanoseconds over a minute or so ( - that would allow a phase estimation
of 1/10th of a wavelength of a 20 MHz signal (e.g. Jupiter's RF noise,
or WWVH's transmissions)


Ideas???


Cross-correlate. Hug your Fourier transform as you do it.

Assume that you have a rough idea where the pulse occurs for each SDR.
FFT with a suitable window function each record.
Using one as reference, you then multiply the complex response with the
reference conjugated response.
Ether compare in the frequency domain or do inverse FFT and search the > 
time-domain for peak response.



That's the sort of strategy I'm looking at.. find a set of samples where 
the transient occurs, zero pad it out (so that when I do peak picking 
later, I've effectively got interpolation), then run the correlation


ifft(fft(a).*conj(fft(b))) in matlab





This is how modern GPS receivers to quick lockup of phase, and it works
very well. Using an FFT library i could code it in relative little C
code and setup my classic channel decoder this way.

Now, use this to compare your SDR clocks compared to the reference. As
they drift over time the windown need to shift, but you can keep track
of the number of samples shifts to keep full track of it. This should
give you enough phase and frequency information. Toss in a least square
or Kalman if you think it would help.

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



___
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] getting accurate timing on RTL-SDR output

[jimlux]

On 4/13/18 1:39 PM, Achim Gratz wrote:

Jim Lux writes:

So now the challenge is to "line em up".  An obvious approach is to
transmit an inband pilot tone with some sync pattern, received by all,
and I'm working on that too.


A maybe not-so obvious approach would be to use RTL-SDR that have been
modified for direct sampling (usually via the Q branch) and inject your
timing pulse there.  That would limit the disturbance of the actual
signal while still relatively easy to extract from the data stream.


That's where it's being injected.. I'm using the RTL-SDR V.3, which has 
the RF input fed right to the Q input.






But right now, I have the idea of capacitively coupling the 1pps pulse
from the GPS to the antenna input - the fast rising and falling edge
are broad band and show up in the sampled data.


The trouble is that you are going to impair the already low dynamic
range.  The ENOB on the I/Q ADC is around 7bit only.


Well, so far, after DDC, it's coming out about 1/5th of the dynamic 
range, and I can always adjust the size of the capacitor.







And you can see, no surprise, that the sample clock in the RTL isn't
dead on - over the 10 seconds, it looks like it drifts about 30- 50
microseconds - that is, the RTL clock is slow by 3-5 ppm.


Not all of these are created equal.  Several manufacturers claim to
factory calibrate their TCXO to better than 0.5ppm.  I have currently
two RTL-SDR that certainly are within 1ppm.  These things get quite hot,
so it definitely takes some time before they stabilize even if they do
have a TCXO in them.


Could well be.. I just turned it on, waited for the beagle to boot, 
captured the data, and moved on.







SO here's the question for the time-nuts hive-mind...
What's a good (or not so good) way to develop an estimator of the
timing/frequency error. Post processing minutes of data is just fine..


There is a program called rtl_test that just checks how many samples it
gets in a certain amount of time.  Let it run for a few hours on a PC
with a GPS-disciplined PC clock and it'll give you a pretty accurate
estimate of the mean sampling clock deviation.

The other method is to tune to a signal of known frequency and check
what it reads as.  There is a program floating around that uses a GSM
station for that purpose.


I'm not so concerned about the frequency measurement - that's "easy".. 
What I'm interested is figuring out the precise timing (in absolute 
terms) of the samples.



___
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] getting accurate timing on RTL-SDR output

[Dana Whitlow]

Hi Jim,

Good for you!  I love to hear about backyard radio astronomy projects.

With your sample rate your GPS PPS spikes should be in the neighborhood
of 1 uS duration.  It's hard to say just how accurately you can glean the
timing
from that, but then I suspect that you're mainly interested in effectively
comparing
the outputs of the two receivers, not so much in absolute timing.  Try your
best
to keep the two receivers identical.

Dana


On Fri, Apr 13, 2018 at 2:15 PM, jimlux  wrote:

> On 4/13/18 10:33 AM, Dana Whitlow wrote:
>
>> Jim,
>>
>> I'm curious:In what RF bandwidth will you be recording?
>>
>
> 1 MHz for now.. the RTL-SDR isn't a super flexible device - there are
> apparently good and bad rates - it does a DDC with 28.8 MHz I/Q NCO (with
> who knows what kind of performance), and then filter and decimate. There's
> a set of taps published for a FIR filter in the thing.
>
> Ultimately, it comes out as 8 bit I and 8 bit Q, so I figure if I do some
> more decimation on the 1MHz stream, I can get a few more effective bits.
>
> It will run at 2 MHz sample rate without dropping samples.. I could
> probably modify the rtl utility to run at a higher rate and do a first
> software filter/downsample to get the data rate down..
>
> I'm really only interested in fairly narrow detection bandwidth.
>
> For telescope use, Jupiter is pretty bright.
> For "phase array to listen to HF signals" 20kHz is probably plenty (it's
> not like I'm going to be developing a 3D CWSkimmer, yet)
>
> Mostly it's because I'm managing a project at JPL where we're flying an
> interferometer to look at CMEs from the Sun
> http://adsabs.harvard.edu/abs/2017EGUGA..19.5580L
> and I'm intrigued by whether I can do it in the backyard..
>
>
>
>
>
>> My first thought would be to search for a cross-correlation peak
>> between the two antenna outputs, but quickly realized that this
>> does not tell you anything about the timing differences between
>> the two receivers.   I think you need to determine that independently
>> (else why bother with the interferometry in the first place?)
>>
>
> That's a clever idea..
>
> Each node has its own GPS receiver, but they should all (within the
> tolerance of the receiver) be "ticking" at the same time.
>
>
>
>
>
>> The receive bandwidth in conjunction with your S/N on the PPS
>> spikes will conspire to limit your timing accuracy, although you
>> can improve on that by averaging over a few minutes as you
>> plan.
>>
>> Dana
>>
>>
>>
>>
>> On Fri, Apr 13, 2018 at 11:52 AM, Jim Lux  wrote:
>>
>> I'm building a phased array receiver (actually, an interferometer) using
>>> RTL-SDR pods, where the elements are isolated from each other - there's a
>>> common WiFi network connection, and each node has a BeagleBone Green, a
>>> uBlox OEM-7M-C, and the RTL-SDR V3 (which works down to HF, since it has
>>> an
>>> internal bypass around the RF front end).
>>>
>>> In general, I have the RTL-SDR set up to capture at 1 Megasample/second.
>>> I
>>> fire off a capture, record it to a file in the BeagleBone's flash, then
>>> retrieve it from my host computer using scp over the network.
>>>
>>> What I'm trying to do is capture data from all the nodes at
>>> (approximately) the same time, then be able to line it all up in post
>>> processing. The GPS (or NTP) is good enough to get them all to start
>>> recording within a few tenths of a second.
>>>
>>> So now the challenge is to "line em up".  An obvious approach is to
>>> transmit an inband pilot tone with some sync pattern, received by all,
>>> and
>>> I'm working on that too.
>>>
>>> But right now, I have the idea of capacitively coupling the 1pps pulse
>>> from the GPS to the antenna input - the fast rising and falling edge are
>>> broad band and show up in the sampled data.
>>>
>>> The attached pulses1.png shows the integrated power in 1 ms chunks (i.e.
>>> I
>>> sum the power from 1000 samples for each chunk) and it's easy to see the
>>> GPS edges.  And it's easy to create a estimate of the coarse timing (to 1
>>> millisecond) - shown as the red trace.
>>>
>>> But then, I want to get better.  So for the 20 edges in my 10 second
>>> example, I plotted  (drift1.png) the raw I/Q output of the RTL.  The
>>> pulse
>>> isn't too huge (maybe 10 DN out of the ADC's -128 to +128 range), but is
>>> visible. Bottom trace is the first, and they're stacked up
>>> 0, 0.1, 1.0, 1.1, 2.0, 2.1, etc.
>>>
>>> And you can see, no surprise, that the sample clock in the RTL isn't dead
>>> on - over the 10 seconds, it looks like it drifts about 30- 50
>>> microseconds
>>> - that is, the RTL clock is slow by 3-5 ppm.
>>>
>>> SO here's the question for the time-nuts hive-mind...
>>> What's a good (or not so good) way to develop an estimator of the
>>> timing/frequency error. Post processing minutes of data is just fine..
>>>
>>> I'm not sure what the actual "waveform" that is being sampled is (and it
>>> will be perturbed by the 

Re: [time-nuts] WWVB information

[Hal Murray]

The month recently changed from 3 to 4.  A while ago, the bottom digit of the 
year changed from 8 to 7.  I think the out-of-phase time is shorter for a 0 
than for a 1.  Would a few more 0 bits be enough to push it into sync?

Is there "goodness" parameter that you can monitor?  It might be interesting 
to see if that correlates with day, hour, minute encoding?


-- 
These are my opinions.  I hate spam.



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

Re: [time-nuts] getting accurate timing on RTL-SDR output

[Magnus Danielson]

Hi Jim,

On 04/13/2018 06:52 PM, Jim Lux wrote:
> I'm building a phased array receiver (actually, an interferometer) using
> RTL-SDR pods, where the elements are isolated from each other - there's
> a common WiFi network connection, and each node has a BeagleBone Green,
> a uBlox OEM-7M-C, and the RTL-SDR V3 (which works down to HF, since it
> has an internal bypass around the RF front end).
> 
> In general, I have the RTL-SDR set up to capture at 1 Megasample/second.
> I fire off a capture, record it to a file in the BeagleBone's flash,
> then retrieve it from my host computer using scp over the network.
> 
> What I'm trying to do is capture data from all the nodes at
> (approximately) the same time, then be able to line it all up in post
> processing. The GPS (or NTP) is good enough to get them all to start
> recording within a few tenths of a second.
> 
> So now the challenge is to "line em up".  An obvious approach is to
> transmit an inband pilot tone with some sync pattern, received by all,
> and I'm working on that too.
> 
> But right now, I have the idea of capacitively coupling the 1pps pulse
> from the GPS to the antenna input - the fast rising and falling edge are
> broad band and show up in the sampled data.
> 
> The attached pulses1.png shows the integrated power in 1 ms chunks (i.e.
> I sum the power from 1000 samples for each chunk) and it's easy to see
> the GPS edges.  And it's easy to create a estimate of the coarse timing
> (to 1 millisecond) - shown as the red trace.
> 
> But then, I want to get better.  So for the 20 edges in my 10 second
> example, I plotted  (drift1.png) the raw I/Q output of the RTL.  The
> pulse isn't too huge (maybe 10 DN out of the ADC's -128 to +128 range),
> but is visible. Bottom trace is the first, and they're stacked up
> 0, 0.1, 1.0, 1.1, 2.0, 2.1, etc.
> 
> And you can see, no surprise, that the sample clock in the RTL isn't
> dead on - over the 10 seconds, it looks like it drifts about 30- 50
> microseconds - that is, the RTL clock is slow by 3-5 ppm.
> 
> SO here's the question for the time-nuts hive-mind...
> What's a good (or not so good) way to develop an estimator of the
> timing/frequency error. Post processing minutes of data is just fine..
> 
> I'm not sure what the actual "waveform" that is being sampled is (and it
> will be perturbed by the quantization of the ADC, and probably not be
> the same depending on where the RTL is tuned).  That is there's some
> sort of LPF in the front of the RTL, the edge is AC coupled, and then it
> goes into some sort of digital down converter in the RTL running at 28.8
> MHz sample rate.
> 
> But it seems that there might be some way to "stack" a series of samples
> and optimize some parameters to estimate the instantaneous time error-
> given that the frequency vs time varies fairly slowly (over a minute or
> so).  It's fairly obvious from the plot that if one looked at the
> "single" sample when the edge comes in, not only does the time shift
> with each pulse, but the phase rotates as well (totally expected)
> 
> this is one of those things where you could probably lay a ruler on it
> and estimate it by eye pretty well, but I'd like an automated algorithm.
> 
> It would be nice to be able to estimate the timing to, say, a few
> nanoseconds over a minute or so ( - that would allow a phase estimation
> of 1/10th of a wavelength of a 20 MHz signal (e.g. Jupiter's RF noise,
> or WWVH's transmissions)
> 
> 
> Ideas???

Cross-correlate. Hug your Fourier transform as you do it.

Assume that you have a rough idea where the pulse occurs for each SDR.
FFT with a suitable window function each record.
Using one as reference, you then multiply the complex response with the
reference conjugated response.
Ether compare in the frequency domain or do inverse FFT and search the
time-domain for peak response.

This is how modern GPS receivers to quick lockup of phase, and it works
very well. Using an FFT library i could code it in relative little C
code and setup my classic channel decoder this way.

Now, use this to compare your SDR clocks compared to the reference. As
they drift over time the windown need to shift, but you can keep track
of the number of samples shifts to keep full track of it. This should
give you enough phase and frequency information. Toss in a least square
or Kalman if you think it would help.

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

Re: [time-nuts] getting accurate timing on RTL-SDR output

[Achim Gratz]

Jim Lux writes:
> So now the challenge is to "line em up".  An obvious approach is to
> transmit an inband pilot tone with some sync pattern, received by all,
> and I'm working on that too.

A maybe not-so obvious approach would be to use RTL-SDR that have been
modified for direct sampling (usually via the Q branch) and inject your
timing pulse there.  That would limit the disturbance of the actual
signal while still relatively easy to extract from the data stream.

> But right now, I have the idea of capacitively coupling the 1pps pulse
> from the GPS to the antenna input - the fast rising and falling edge
> are broad band and show up in the sampled data.

The trouble is that you are going to impair the already low dynamic
range.  The ENOB on the I/Q ADC is around 7bit only.

> And you can see, no surprise, that the sample clock in the RTL isn't
> dead on - over the 10 seconds, it looks like it drifts about 30- 50
> microseconds - that is, the RTL clock is slow by 3-5 ppm.

Not all of these are created equal.  Several manufacturers claim to
factory calibrate their TCXO to better than 0.5ppm.  I have currently
two RTL-SDR that certainly are within 1ppm.  These things get quite hot,
so it definitely takes some time before they stabilize even if they do
have a TCXO in them.

> SO here's the question for the time-nuts hive-mind...
> What's a good (or not so good) way to develop an estimator of the
> timing/frequency error. Post processing minutes of data is just fine..

There is a program called rtl_test that just checks how many samples it
gets in a certain amount of time.  Let it run for a few hours on a PC
with a GPS-disciplined PC clock and it'll give you a pretty accurate
estimate of the mean sampling clock deviation.

The other method is to tune to a signal of known frequency and check
what it reads as.  There is a program floating around that uses a GSM
station for that purpose.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
___
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] TCVCXO Adjustment

[Bob kb8tq]

Hi

If you have a GPS on your local lan, just use it for the calibration. There’s 
no need for NTP
to get involved.

If you are running NTP over a normal home setup going to the internet, then you 
will be doing
very well to get low ms with NTP. 

Going back to the original post, the request is for a method to calibrate a 
newly assembled board. 
Since we are talking about a generalized calibration procedure, simply saying 
“use NTP” without 
mentioning setting up a LAN / GPS NTP empire seems to be a bit misleading. That 
is a very 
unique system that the vast majority of the world would not be using. 

Bob

> On Apr 13, 2018, at 2:18 PM, David J Taylor via time-nuts 
>  wrote:
> 
> Hi
> 
> NTP will give you “millisecond" level accuracy / stability. If you want to 
> set an
> oscillator to 0.1 ppm, you will need to run for over 10,000 seconds. It is not
> uncommon to have things out in the 10 ms range. That would put you at
> 100,000 seconds. In more common units, a couple of hours to > 1 day
> would be needed.
> 
> Keep in mind, this is for a single observation. If you need to make three or 
> four
> tweaks to get things set, the numbers would go up a bit.
> 
> The earlier mentioned GPS approach with a $10 USB dongle would do it a *lot*
> faster. More or less, you could expect a bit better than a 1000:1 speed
> improvement.
> 
> Bob
> ==
> 
> With respect, NTP using a GPS/PPS clock can give tens of microseconds or 
> better, even on a Raspberry Pi.  For example:
> 
> http://www.satsignal.eu/mrtg/raspi1_ntp.html
> 
> (The slight downward slope back over time is an artefact of MRTG with small 
> integers.)
> 
> Cheers,
> Davis
> -- 
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv 
> ___
> 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] getting accurate timing on RTL-SDR output

[jimlux]

On 4/13/18 10:33 AM, Dana Whitlow wrote:

Jim,

I'm curious:In what RF bandwidth will you be recording?


1 MHz for now.. the RTL-SDR isn't a super flexible device - there are 
apparently good and bad rates - it does a DDC with 28.8 MHz I/Q NCO 
(with who knows what kind of performance), and then filter and decimate. 
There's a set of taps published for a FIR filter in the thing.


Ultimately, it comes out as 8 bit I and 8 bit Q, so I figure if I do 
some more decimation on the 1MHz stream, I can get a few more effective 
bits.


It will run at 2 MHz sample rate without dropping samples.. I could 
probably modify the rtl utility to run at a higher rate and do a first 
software filter/downsample to get the data rate down..


I'm really only interested in fairly narrow detection bandwidth.

For telescope use, Jupiter is pretty bright.
For "phase array to listen to HF signals" 20kHz is probably plenty (it's 
not like I'm going to be developing a 3D CWSkimmer, yet)


Mostly it's because I'm managing a project at JPL where we're flying an 
interferometer to look at CMEs from the Sun

http://adsabs.harvard.edu/abs/2017EGUGA..19.5580L
and I'm intrigued by whether I can do it in the backyard..






My first thought would be to search for a cross-correlation peak
between the two antenna outputs, but quickly realized that this
does not tell you anything about the timing differences between
the two receivers.   I think you need to determine that independently
(else why bother with the interferometry in the first place?)


That's a clever idea..

Each node has its own GPS receiver, but they should all (within the 
tolerance of the receiver) be "ticking" at the same time.






The receive bandwidth in conjunction with your S/N on the PPS
spikes will conspire to limit your timing accuracy, although you
can improve on that by averaging over a few minutes as you
plan.

Dana




On Fri, Apr 13, 2018 at 11:52 AM, Jim Lux  wrote:


I'm building a phased array receiver (actually, an interferometer) using
RTL-SDR pods, where the elements are isolated from each other - there's a
common WiFi network connection, and each node has a BeagleBone Green, a
uBlox OEM-7M-C, and the RTL-SDR V3 (which works down to HF, since it has an
internal bypass around the RF front end).

In general, I have the RTL-SDR set up to capture at 1 Megasample/second. I
fire off a capture, record it to a file in the BeagleBone's flash, then
retrieve it from my host computer using scp over the network.

What I'm trying to do is capture data from all the nodes at
(approximately) the same time, then be able to line it all up in post
processing. The GPS (or NTP) is good enough to get them all to start
recording within a few tenths of a second.

So now the challenge is to "line em up".  An obvious approach is to
transmit an inband pilot tone with some sync pattern, received by all, and
I'm working on that too.

But right now, I have the idea of capacitively coupling the 1pps pulse
from the GPS to the antenna input - the fast rising and falling edge are
broad band and show up in the sampled data.

The attached pulses1.png shows the integrated power in 1 ms chunks (i.e. I
sum the power from 1000 samples for each chunk) and it's easy to see the
GPS edges.  And it's easy to create a estimate of the coarse timing (to 1
millisecond) - shown as the red trace.

But then, I want to get better.  So for the 20 edges in my 10 second
example, I plotted  (drift1.png) the raw I/Q output of the RTL.  The pulse
isn't too huge (maybe 10 DN out of the ADC's -128 to +128 range), but is
visible. Bottom trace is the first, and they're stacked up
0, 0.1, 1.0, 1.1, 2.0, 2.1, etc.

And you can see, no surprise, that the sample clock in the RTL isn't dead
on - over the 10 seconds, it looks like it drifts about 30- 50 microseconds
- that is, the RTL clock is slow by 3-5 ppm.

SO here's the question for the time-nuts hive-mind...
What's a good (or not so good) way to develop an estimator of the
timing/frequency error. Post processing minutes of data is just fine..

I'm not sure what the actual "waveform" that is being sampled is (and it
will be perturbed by the quantization of the ADC, and probably not be the
same depending on where the RTL is tuned).  That is there's some sort of
LPF in the front of the RTL, the edge is AC coupled, and then it goes into
some sort of digital down converter in the RTL running at 28.8 MHz sample
rate.

But it seems that there might be some way to "stack" a series of samples
and optimize some parameters to estimate the instantaneous time error-
given that the frequency vs time varies fairly slowly (over a minute or
so).  It's fairly obvious from the plot that if one looked at the "single"
sample when the edge comes in, not only does the time shift with each
pulse, but the phase rotates as well (totally expected)

this is one of those things where you could probably lay a ruler on it and
estimate it by eye pretty well, but I'd like 

Re: [time-nuts] WWVB information

[ziggy9+time-nuts]

My 8161/8164 will indicate lock as well, and I suppose they may be
'locked'. But the phase stability is so poor they may as well not be. I
guess it averages out close enough to zero within the time constant to
turn the LED on. It's not new behavior for my units. Phase tracking
receivers are still broken.


On 04/12/2018 11:07 PM, Tom Van Baak wrote:
> I've been talking with Doug to better understand why his Spectracom WWVB 
> receiver shows the green lock indicator. This receiver should not work given 
> the enhanced WWVB modulation we've had since 2012. Fortunately he has chosen 
> not to touch anything while we ponder this.
>
> Meanwhile I pulled out some Spectracom gear (8164) and was able to repro his 
> green lock! But the 10 MHz output is very unstable so I'm pretty sure it is 
> not locking at all. Looking at the schematic the green indicator seems 
> primitive. So "lock" may not really mean it has robustly locked to the 
> carrier. More details to follow.
>
> If any of you have Spectracom WWVB 816x or 817x receivers you might want to 
> try them too.
>
> /tvb
>
> - Original Message - 
> From: "Martin VE3OAT" 
> To: 
> Cc: "Doug Millar" 
> Sent: Thursday, April 12, 2018 5:12 PM
> Subject: Re: [time-nuts] WWVB information
>
>
>> Hi, Doug,
>> How is your 8161 doing now?  Still synced properly?  Should I bring my 
>> 8164 up from the basement?  I was so disappointed when WWVB changed 
>> their modulation.  Thanks for any encouragement.
>> 73,
>> ... MartinVE3OAT
>>
>>
>> On Wed, 11 Apr 2018 16:28:41 Doug Millar wrote :
>>
>>> Hi, My Spectracom 8161 comparator and 8171A clock are chugging
>>> right along in sync with the proper time. I have only looked at
>>> the digital LED output and it is within one second of my other
>>> WWVB  clocks.  Seems like magic. It came in synch about two
>>> weeks ago and stayed there. I haven't changed anything in my
>>> lab or moved the units. Antenna is still the same.
>>> Pictures available. Doug K6JEY
>> ___
>> 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] TCVCXO Adjustment

[David J Taylor via time-nuts]

Hi

NTP will give you “millisecond" level accuracy / stability. If you want to 
set an
oscillator to 0.1 ppm, you will need to run for over 10,000 seconds. It is 
not

uncommon to have things out in the 10 ms range. That would put you at
100,000 seconds. In more common units, a couple of hours to > 1 day
would be needed.

Keep in mind, this is for a single observation. If you need to make three or 
four

tweaks to get things set, the numbers would go up a bit.

The earlier mentioned GPS approach with a $10 USB dongle would do it a *lot*
faster. More or less, you could expect a bit better than a 1000:1 speed
improvement.

Bob
==

With respect, NTP using a GPS/PPS clock can give tens of microseconds or 
better, even on a Raspberry Pi.  For example:


 http://www.satsignal.eu/mrtg/raspi1_ntp.html

(The slight downward slope back over time is an artefact of MRTG with small 
integers.)


Cheers,
Davis
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
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] getting accurate timing on RTL-SDR output

[Dana Whitlow]

Jim,

I'm curious:In what RF bandwidth will you be recording?

My first thought would be to search for a cross-correlation peak
between the two antenna outputs, but quickly realized that this
does not tell you anything about the timing differences between
the two receivers.   I think you need to determine that independently
(else why bother with the interferometry in the first place?)

The receive bandwidth in conjunction with your S/N on the PPS
spikes will conspire to limit your timing accuracy, although you
can improve on that by averaging over a few minutes as you
plan.

Dana




On Fri, Apr 13, 2018 at 11:52 AM, Jim Lux  wrote:

> I'm building a phased array receiver (actually, an interferometer) using
> RTL-SDR pods, where the elements are isolated from each other - there's a
> common WiFi network connection, and each node has a BeagleBone Green, a
> uBlox OEM-7M-C, and the RTL-SDR V3 (which works down to HF, since it has an
> internal bypass around the RF front end).
>
> In general, I have the RTL-SDR set up to capture at 1 Megasample/second. I
> fire off a capture, record it to a file in the BeagleBone's flash, then
> retrieve it from my host computer using scp over the network.
>
> What I'm trying to do is capture data from all the nodes at
> (approximately) the same time, then be able to line it all up in post
> processing. The GPS (or NTP) is good enough to get them all to start
> recording within a few tenths of a second.
>
> So now the challenge is to "line em up".  An obvious approach is to
> transmit an inband pilot tone with some sync pattern, received by all, and
> I'm working on that too.
>
> But right now, I have the idea of capacitively coupling the 1pps pulse
> from the GPS to the antenna input - the fast rising and falling edge are
> broad band and show up in the sampled data.
>
> The attached pulses1.png shows the integrated power in 1 ms chunks (i.e. I
> sum the power from 1000 samples for each chunk) and it's easy to see the
> GPS edges.  And it's easy to create a estimate of the coarse timing (to 1
> millisecond) - shown as the red trace.
>
> But then, I want to get better.  So for the 20 edges in my 10 second
> example, I plotted  (drift1.png) the raw I/Q output of the RTL.  The pulse
> isn't too huge (maybe 10 DN out of the ADC's -128 to +128 range), but is
> visible. Bottom trace is the first, and they're stacked up
> 0, 0.1, 1.0, 1.1, 2.0, 2.1, etc.
>
> And you can see, no surprise, that the sample clock in the RTL isn't dead
> on - over the 10 seconds, it looks like it drifts about 30- 50 microseconds
> - that is, the RTL clock is slow by 3-5 ppm.
>
> SO here's the question for the time-nuts hive-mind...
> What's a good (or not so good) way to develop an estimator of the
> timing/frequency error. Post processing minutes of data is just fine..
>
> I'm not sure what the actual "waveform" that is being sampled is (and it
> will be perturbed by the quantization of the ADC, and probably not be the
> same depending on where the RTL is tuned).  That is there's some sort of
> LPF in the front of the RTL, the edge is AC coupled, and then it goes into
> some sort of digital down converter in the RTL running at 28.8 MHz sample
> rate.
>
> But it seems that there might be some way to "stack" a series of samples
> and optimize some parameters to estimate the instantaneous time error-
> given that the frequency vs time varies fairly slowly (over a minute or
> so).  It's fairly obvious from the plot that if one looked at the "single"
> sample when the edge comes in, not only does the time shift with each
> pulse, but the phase rotates as well (totally expected)
>
> this is one of those things where you could probably lay a ruler on it and
> estimate it by eye pretty well, but I'd like an automated algorithm.
>
> It would be nice to be able to estimate the timing to, say, a few
> nanoseconds over a minute or so ( - that would allow a phase estimation of
> 1/10th of a wavelength of a 20 MHz signal (e.g. Jupiter's RF noise, or
> WWVH's transmissions)
>
>
> Ideas???
>
>
>
>
> ___
> 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] femtosecond jitter

[John Larkin]

If you walk the differential data and clock inputs of an NB7V52  CML 
flipflop across one another in time, the equivalent jitter is below 20 
fs RMS. That's what we're measuring, but our test rig may well dominate 
the jitter, so the flop is probably better.


We're using this to test the jitter of some of our timing products, with 
1/10 the noise floor and 1e-4 times the cost of other ways to do it.


https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1

https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1

https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1


--
** arb

John Larkin, President
Highland Technology, Inc
18 Otis Street
San Francisco, CA 94103

phone 415 551-1700   fax 551-5129
jjlar...@highlandtechnology.com
http://www.highlandtechnology.com

This is a Highland Technology confidential communication

___
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] Pulsars, clocks, and time nuts (Jim Palfreyman)

[Dana Whitlow]

Tom's discussion about pulsars brought back some memories...

Many pulsars exhibit skipped pulses.  And one curiosity that I didn't see
mentioned in Tom's discussion is that some pulsars even exhibit behavior
reminiscent of the "sawtooth jitter" so evident in the PPS outputs of most
GPS receivers.  See figures 12-11 & 12-12 in "An Introduction to Radio
Astronomy" (2nd edition) by Burke and Graham-Smith.  The first ed also
contains the basic plot (as figure 12-8 in this case), but whose explanation
is not as up-to-date).

For a deeper treatment of pulsars, also see
  https://www.cv.nrao.edu/course/astr534/PDFnew.shtml
by Condon and Ransom (both of NRAO).

The above two references are the best Radio Astronomy tomes I've yet seen..

Pulsar timing has been (and still is) a very big deal in radio astronomy,
as it
is key to verification of certain points of Einstein's General Theory of
Relativity.

Here are two web sites in which audio recordings of various pulsar
sounds (made with larger radio telescopes) are presented.

https://www.youtube.com/watch?v=uHEVo-LkDrQ
(You may ignore the video part, even though it's "cute", but the
audio portion is a fine example of the pulse to pulse variations
exhibited by many pulsars, all wrapped up in one pulsar)

http://www.jb.man.ac.uk/pulsar/Education/Sounds/0329_stack.mp4
(I think this is the best overall site, giving quality recordings of a
fair number of different pulsars)

Dana






On Fri, Apr 13, 2018 at 2:54 AM, Tom Van Baak  wrote:

> Amazing news... 1.2.3.
>
> 1) Many of you know that pulsars are weird astronomical sources of
> periodic signals. Some are so accurate that they rival atomic clocks for
> stability! True, but I don't have a 100 foot antenna at home so I'll take
> their word for it. Plus, you have to account for a myriad of PhD-level
> corrections: from earth's rotation to general relativity. And, like quartz
> or rubidium clocks, pulsars drift (as they gradually slow down). Precision
> timing is not easy. If you poke around the web you can find numerous
> articles describing their detection and measurement and exploring their use
> as reference clocks, both here and potentially for deep-space timekeeping.
>
> 2) If you do a lot of clock measurement at home then you know the dark
> side of working with precision clocks. There are signal quality issues,
> measurement resolution issues, reference stability limitations, offset,
> drift, phase jumps, frequency jumps, missed or extra cycles, glitches, etc.
> For example, quartz oscillators (depending on make / model / luck) can
> exhibit frequency jumps; i.e., without warning they just change frequency
> without your permission. Ok, maybe not by a lot, but enough to notice;
> perhaps enough to cause trouble to any naive GPSDO PID algorithm that
> assumes steady state from the oscillator you thought was stable.
>
> 3) Now the exciting part! Fellow time-nut Jim Palfreyman studies pulsars.
> You've seen postings from him now and then over the years. It turns out Jim
> is the first person to catch a pulsar in the act of a frequency jump. After
> 3 years of continuous searching! This is really cool. Just amazing. You
> can't get more time nutty than this. And it just got published in Nature.
> It's a perfect never-give-up, i-eat-nanoseconds-for-breakfast, time nut
> thing to do. I am so impressed.
>
> To quote Jim:
>
> On December 12, 2016, at approximately 9:36pm at night, my phone
> goes off with a text message telling me that Vela had glitched. The
> automated process I had set up wasn't completely reliable - radio
> frequency interference (RFI) had been known to set it off in error.
>
> So sceptically I logged in, and ran the test again. It was genuine!
> The excitement was incredible and I stayed up all night analysing the
> data.
>
> What surfaced was quite surprising and not what was expected. Right
> as the glitch occurred, the pulsar missed a beat. It didn't pulse.
>
> Here is a very readable description of his discovery:
>
> http://theconversation.com/captured-radio-telescope-
> records-a-rare-glitch-in-a-pulsars-regular-pulsing-beat-94815
>
> And also the official Nature article with all the juicy, peer-reviewed
> details:
>
> https://rdcu.be/LfP0
>
> So congratulations to Jim. I will think of him next time my 10811A quartz
> oscillator does a frequency jump or next time my 60 Hz mains frequency
> monitor skips a cycle...
>
> If you have comments or questions feel free to send them to Jim directly
> (see Cc: address). Perhaps he can summarize the questions and his answers
> in a posting to time-nuts soon.
>
> /tvb
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to 

Re: [time-nuts] TCVCXO Adjustment

[Adrian Godwin]

Hi Wayne,

I didn't mean that you should use the PPS signal from a consumer GPS rx
(though you might do that). I was thinking that you'd instead track the
difference between TCXO-maintained time and GPS time over long periods -
weeks or months - and use those to adjust the TCXO.

This would only work if the TCXO was constantly maintaining a clock, which
I'd thought would be the case. If it's in a USB stick that might not be
true and so it wouldn't work as you wouldn't get the long baseline
measurement needed to compare with GPS time.

PCs are a bit of a problem. They may well have the sound chip on USB and
they also have a considerable amount of latency due to buffering in the DAC
and filtering. They're also, somewhat surprisingly, a pain in the neck for
application writing. They might have plenty of development tools, but
you'll find you have to constantly modify it to meet the current operating
system specs, produce Mac, Linux and Windows variants, multiple languages,
etc etc.  Unless you're in that business and can get some of that effort
back through sales, it's a mess.

-adrian




On Fri, Apr 13, 2018 at 3:30 AM, Wayne Holder 
wrote:

> First, thanks for all the comments and suggestions,  It's given me a lot to
> think about and research.
>
> Based on the feedback I've received, I've started to investigate using the
> NTP
> server approach suggested by Chris Caudle.  I also found this NIST Paper
>  to be very useful, as
> it
> gave me some insight into the measurement period needed to achieve a given
> accuracy in the DUT given a certain level of deviation in the reference
> used.  But, I think further reading will be required before I can reduce
> this approach to a plan.  I anyone knows of additional info on using NTP to
> calibrate precision oscillators, I'd appreciate hearing about it.
>
> The basic unit of measurement for Longitudinal Timecode is the video frame
> rate, or approximately 30 fps, depending on the video medium in use.
> Current commercial Timecode Generators make claims like having a drift
> of only 1 frame over 24 hours, so that's been my target for my design.
>  Based
> on my math, I think a drift of only 1/30th of a second in 24 hours is
> perhaps +/-0.5 PPP, or so, but someone please correct me if I'm wrong.
>   Another solution used with older, less accurate timecode generators is to
> periodically resync (or "Jam Sync") the different timecode generators to
> the master timecode generator thoughout the day but, while I'm not a video
> production expert, I think think this is a less desirable solution.
>
> Using a GPS, as suggestion by Adrian Godwin, is also an option, as the PPS
> signal could be used as a calibration reference.   Cheap, consumer GPS
> modules have gotten quite cheap and, based on my own experience
> using various uBlox modules, some can even function fairly well indoors
> under some conditions.  However, I seem to recall some discussion here some
> time back about the relative reliability of the PPS signal in some
> situations.  I'll have to dig back though the archives and see if I can
> learn anything from those threads.
>
> To provide some additional details on my project for those that
> are interested, the current plan is to build everything into a USB Stick
> form factor.  The USB connection would be used to configure internal
> options (frame rate, etc.), charge the internal Li-Poly battery and
> also, potentially, perform the calibration.  The time code signal would
> be output from a 3.5mm phone connector, so the suggestion to connect this
> to the audio input of the computer doing the calibration also makes sense,
> as this would take USB latency out of the picture (assuming that the sound
> interface in the PC is not just implemented via a chip on the USB bus.)
>
> Wayne
> ___
> 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] TCVCXO Adjustment

[Bob kb8tq]

Hi

NTP will give you “millisecond" level accuracy / stability. If you want to set 
an 
oscillator to 0.1 ppm, you will need to run for over 10,000 seconds. It is not 
uncommon to have things out in the 10 ms range. That would put you at 
100,000 seconds. In more common units, a couple of hours to > 1 day
would be needed. 

Keep in mind, this is for a single observation. If you need to make three or 
four
tweaks to get things set, the numbers would go up a bit. 

The earlier mentioned GPS approach with a $10 USB dongle would do it a *lot*
faster. More or less, you could expect a bit better than a 1000:1 speed 
improvement. 

Bob

> On Apr 12, 2018, at 10:30 PM, Wayne Holder  wrote:
> 
> First, thanks for all the comments and suggestions,  It's given me a lot to
> think about and research.
> 
> Based on the feedback I've received, I've started to investigate using the NTP
> server approach suggested by Chris Caudle.  I also found this NIST Paper
>  to be very useful, as it
> gave me some insight into the measurement period needed to achieve a given
> accuracy in the DUT given a certain level of deviation in the reference
> used.  But, I think further reading will be required before I can reduce
> this approach to a plan.  I anyone knows of additional info on using NTP to
> calibrate precision oscillators, I'd appreciate hearing about it.
> 
> The basic unit of measurement for Longitudinal Timecode is the video frame
> rate, or approximately 30 fps, depending on the video medium in use.
> Current commercial Timecode Generators make claims like having a drift
> of only 1 frame over 24 hours, so that's been my target for my design.   Based
> on my math, I think a drift of only 1/30th of a second in 24 hours is
> perhaps +/-0.5 PPP, or so, but someone please correct me if I'm wrong.
>  Another solution used with older, less accurate timecode generators is to
> periodically resync (or "Jam Sync") the different timecode generators to
> the master timecode generator thoughout the day but, while I'm not a video
> production expert, I think think this is a less desirable solution.
> 
> Using a GPS, as suggestion by Adrian Godwin, is also an option, as the PPS
> signal could be used as a calibration reference.   Cheap, consumer GPS
> modules have gotten quite cheap and, based on my own experience
> using various uBlox modules, some can even function fairly well indoors
> under some conditions.  However, I seem to recall some discussion here some
> time back about the relative reliability of the PPS signal in some
> situations.  I'll have to dig back though the archives and see if I can
> learn anything from those threads.
> 
> To provide some additional details on my project for those that
> are interested, the current plan is to build everything into a USB Stick
> form factor.  The USB connection would be used to configure internal
> options (frame rate, etc.), charge the internal Li-Poly battery and
> also, potentially, perform the calibration.  The time code signal would
> be output from a 3.5mm phone connector, so the suggestion to connect this
> to the audio input of the computer doing the calibration also makes sense,
> as this would take USB latency out of the picture (assuming that the sound
> interface in the PC is not just implemented via a chip on the USB bus.)
> 
> Wayne
> ___
> 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] Pulsars, clocks, and time nuts (Jim Palfreyman)

[Tom Van Baak]

Amazing news... 1.2.3.

1) Many of you know that pulsars are weird astronomical sources of periodic 
signals. Some are so accurate that they rival atomic clocks for stability! 
True, but I don't have a 100 foot antenna at home so I'll take their word for 
it. Plus, you have to account for a myriad of PhD-level corrections: from 
earth's rotation to general relativity. And, like quartz or rubidium clocks, 
pulsars drift (as they gradually slow down). Precision timing is not easy. If 
you poke around the web you can find numerous articles describing their 
detection and measurement and exploring their use as reference clocks, both 
here and potentially for deep-space timekeeping.

2) If you do a lot of clock measurement at home then you know the dark side of 
working with precision clocks. There are signal quality issues, measurement 
resolution issues, reference stability limitations, offset, drift, phase jumps, 
frequency jumps, missed or extra cycles, glitches, etc. For example, quartz 
oscillators (depending on make / model / luck) can exhibit frequency jumps; 
i.e., without warning they just change frequency without your permission. Ok, 
maybe not by a lot, but enough to notice; perhaps enough to cause trouble to 
any naive GPSDO PID algorithm that assumes steady state from the oscillator you 
thought was stable.

3) Now the exciting part! Fellow time-nut Jim Palfreyman studies pulsars. 
You've seen postings from him now and then over the years. It turns out Jim is 
the first person to catch a pulsar in the act of a frequency jump. After 3 
years of continuous searching! This is really cool. Just amazing. You can't get 
more time nutty than this. And it just got published in Nature. It's a perfect 
never-give-up, i-eat-nanoseconds-for-breakfast, time nut thing to do. I am so 
impressed.

To quote Jim:

On December 12, 2016, at approximately 9:36pm at night, my phone
goes off with a text message telling me that Vela had glitched. The
automated process I had set up wasn't completely reliable - radio
frequency interference (RFI) had been known to set it off in error.

So sceptically I logged in, and ran the test again. It was genuine!
The excitement was incredible and I stayed up all night analysing the data.

What surfaced was quite surprising and not what was expected. Right
as the glitch occurred, the pulsar missed a beat. It didn't pulse.

Here is a very readable description of his discovery:

http://theconversation.com/captured-radio-telescope-records-a-rare-glitch-in-a-pulsars-regular-pulsing-beat-94815

And also the official Nature article with all the juicy, peer-reviewed details:

https://rdcu.be/LfP0

So congratulations to Jim. I will think of him next time my 10811A quartz 
oscillator does a frequency jump or next time my 60 Hz mains frequency monitor 
skips a cycle...

If you have comments or questions feel free to send them to Jim directly (see 
Cc: address). Perhaps he can summarize the questions and his answers in a 
posting to time-nuts soon.

/tvb

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