Re: [time-nuts] Timelab and the 53220A - getting best results

[Bob Camp]

Hi

If the counter is the limiting factor, it should scale by 10 as the timebase 
scales by 10. Your data goes from 
90 ppt at 1 second to 9 ppt at 10 seconds. That is the expected outcome. 

Bob


> On Jun 2, 2016, at 8:57 PM, Nick Sayer via time-nuts  
> wrote:
> 
> Oh, the limitation is on the TimeLab side? I was blaming the TIA. :)
> 
> Since then, I have found an advanced gate setting that appears to add 500 ms 
> after start. The time intervals seem to be without that delay, so it works. 
> The resulting ADEV is unchanged (other than obviously truncated at low tau 
> and having a longer duration).
> 
> Looking at the phase and frequency data, I don't see anything wrong. The ADEV 
> plot is linear, and it arrives to the spec at around tau 10s or so... It's 
> just way steeper than I expect. An order of magnitude north of spec at tau 1s.
> 
> The only thing I can think of is that it's compounding the error because I'm 
> comparing two (of the same) oscillators to each other, but my understanding 
> is that I can only attempt to compensate for that by scaling by sqrt(2).
> 
> Sent from my iPhone
> 
>> On Jun 2, 2016, at 11:12 AM, John Miles  wrote:
>> 
>> One workaround for the 1-million point limitation on imported data is to use 
>> "Acquire->Acquire from live ASCII file" instead of "File->Import ASCII 
>> phase/frequency data."  Most of the same code is used for both cases, but 
>> unlike the static file-import version of the dialog, the live data importer 
>> will let you specify the expected duration yourself.  So you can give it a 
>> duration value that you know will be long enough to cover the whole data 
>> set.  
>> 
>> I'm not too familiar with the 532x0A counters myself, but 8.9E-11 at t=1s 
>> doesn't sound too unrealistic.  When in doubt, look at the 'f'requency 
>> and/or 'p'hase trends and residuals to sanity-check your data, rather than 
>> trying to puzzle out what's going wrong with the ADEV plot as many users 
>> seem to do.  First you should satisfy yourself that the data makes sense, is 
>> unwrapped and scaled properly, and doesn't contain glitches, large crystal 
>> jumps, obvious beatnotes or other interference, or unexpected amounts of 
>> drift.  
>> 
>> -- john, KE5FX
>> Miles Design LLC
>> 
>>> I’ve gotten a little further with this. If I capture 60 seconds worth of 
>>> time
>>> interval measurements (between two FE-5680As that are GPS disciplined, but
>>> with a long enough time constant that they’re basically free-running), I get
>>> 60,000 of them. So I imported at a sample interval of 1e-3 and got the right
>>> duration. There are a couple of problems, however. 1 is that even if I 
>>> attempt to
>>> log to a USB stick, it appears I can only log 1e6 samples before it stops. 
>>> That’s
>>> 16:40 or so, which isn’t very long. I haven’t figured out how to change the
>>> sample gate for time intervals (I’m assuming that a million samples is a 
>>> hard
>>> limit). Also, importing the interval samples into TimeLab still shows me a 
>>> graph
>>> that’s still much steeper than I would expect. The graph is linear, with 
>>> points at
>>> tau 1s = 8.9E-11, 10s = 9.47E-12, 100s = 1.5E-12 (by then, the ADEV graph is
>>> starting to flatten out a bit, which probably indicates the noise floor of 
>>> the
>>> 53220A near 1E-12), but the FEI datasheet shows a spec with points more like
>>> tau 1s = 1.5E-11, 10s = 4.5E-12 and 100s = 1.5E-12.
>> 
>> ___
>> 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] Timelab and the 53220A - getting best results

[Nick Sayer via time-nuts]

Oh, the limitation is on the TimeLab side? I was blaming the TIA. :)

Since then, I have found an advanced gate setting that appears to add 500 ms 
after start. The time intervals seem to be without that delay, so it works. The 
resulting ADEV is unchanged (other than obviously truncated at low tau and 
having a longer duration).

Looking at the phase and frequency data, I don't see anything wrong. The ADEV 
plot is linear, and it arrives to the spec at around tau 10s or so... It's just 
way steeper than I expect. An order of magnitude north of spec at tau 1s.

The only thing I can think of is that it's compounding the error because I'm 
comparing two (of the same) oscillators to each other, but my understanding is 
that I can only attempt to compensate for that by scaling by sqrt(2).

Sent from my iPhone

> On Jun 2, 2016, at 11:12 AM, John Miles  wrote:
> 
> One workaround for the 1-million point limitation on imported data is to use 
> "Acquire->Acquire from live ASCII file" instead of "File->Import ASCII 
> phase/frequency data."  Most of the same code is used for both cases, but 
> unlike the static file-import version of the dialog, the live data importer 
> will let you specify the expected duration yourself.  So you can give it a 
> duration value that you know will be long enough to cover the whole data set. 
>  
> 
> I'm not too familiar with the 532x0A counters myself, but 8.9E-11 at t=1s 
> doesn't sound too unrealistic.  When in doubt, look at the 'f'requency and/or 
> 'p'hase trends and residuals to sanity-check your data, rather than trying to 
> puzzle out what's going wrong with the ADEV plot as many users seem to do.  
> First you should satisfy yourself that the data makes sense, is unwrapped and 
> scaled properly, and doesn't contain glitches, large crystal jumps, obvious 
> beatnotes or other interference, or unexpected amounts of drift.  
> 
> -- john, KE5FX
> Miles Design LLC
> 
>> I’ve gotten a little further with this. If I capture 60 seconds worth of time
>> interval measurements (between two FE-5680As that are GPS disciplined, but
>> with a long enough time constant that they’re basically free-running), I get
>> 60,000 of them. So I imported at a sample interval of 1e-3 and got the right
>> duration. There are a couple of problems, however. 1 is that even if I 
>> attempt to
>> log to a USB stick, it appears I can only log 1e6 samples before it stops. 
>> That’s
>> 16:40 or so, which isn’t very long. I haven’t figured out how to change the
>> sample gate for time intervals (I’m assuming that a million samples is a hard
>> limit). Also, importing the interval samples into TimeLab still shows me a 
>> graph
>> that’s still much steeper than I would expect. The graph is linear, with 
>> points at
>> tau 1s = 8.9E-11, 10s = 9.47E-12, 100s = 1.5E-12 (by then, the ADEV graph is
>> starting to flatten out a bit, which probably indicates the noise floor of 
>> the
>> 53220A near 1E-12), but the FEI datasheet shows a spec with points more like
>> tau 1s = 1.5E-11, 10s = 4.5E-12 and 100s = 1.5E-12.
> 
> ___
> 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] Mystery hp Ovens For Sale

[paul swed]

How about that. There is a tube as you said.Pretty interesting. But I have
my sulzers for old technology. Good enuf as they say.
I have two HP xtals I can find no info on. Picked them up recently for
nothing.
They look pretty nice and I will at least check there frequency could be 1
MHz or 100KHz pretty large glass envelope. HP Part number g-170a-03.
My searches found nothing on the internet.
Regards
Paul
WB8TSL

On Thu, Jun 2, 2016 at 2:21 PM,  wrote:

> Paul.
>
> I actually paid the asking price of $100.00 each + tax and shipping!
>
> After seeing the non HP one I'm not interested in restoring it as it's
> just the oscillator.
>
> All the Rf buffering, AGC, oven control are external and missing.
>
> Plus it's most likely 100KHz or 1Mhz.
>
> If I end up junking it I'll post a PIX of the crystal once I dig down and
> find it.
>
> If anyone here wants it at the $100.00 let me know.
>
> If not in a week I'll take it all apart just to look, and scrap what I
> don't keep.
>
> Attached are some PIX of it.
>
> The 106B only requires +24VDC to run and no other external circuits as
> everything is built in.
>
> Cheers,
>
> Corby
> ___
> 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] picDIV board.

[Brooke Clarke]

Hi Dan:

I made a board for the TVB divider, but there was no interest.
http://www.prc68.com/I/PRC68COM.shtml#TVB

--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

 Original Message 
So, having a batch of PIC12F675's to play with the picDIV's with, but being lazy I decided to look for a dev board for 
the 8 pin PIC's. (Yeah, I know how lazy can you get! :) )  Just didn't feel like wiring up the programming header to a 
bread board, etc. Anyway, one appeared in google on OSH park and Tindie. Looks like the same guy.  So for anyone 
thinking about playing with the picDIV but feeling as lazy as I am, this might be a good option. It even includes some 
prototype area on the board!


From OSH park you get 3 boards for under $10.
https://oshpark.com/shared_projects/kXG6K5Xu

For those of you who don't know what a PIC DIV is:
http://www.leapsecond.com/pic/picdiv.htm

My guess is it would also work with a picPET and an FTDI cable. 
http://www.leapsecond.com/pic/picpet.htm

Dan



___
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] Ublox Neo-6M time error.

[Angus]

I noticed that in 'Messages View' window in u-center, UBX-NAV-TIMEGPS
gives Time of week, but UBX-TIM-TP gives Time of next pulse, 1 second
later. The hex in the messages also differs by 1000ms.
Putting the correction data and the time of the next pulse together
like that would suggest that it is for the next pulse, but I've not
checked it with a counter.

Angus.

On Thu, 2 Jun 2016 08:28:58 +, you wrote:

>The Ublox receivers do not have a message that outputs GPS time directly.  
>It's easiest to take the UTC time message and subtract the leapsecond offset 
>to get GPS time.   The itow value in the NAV_TIMEGPS message is milliseconds 
>past midnight of the start of the GPS week... probably not something you want 
>to be doing calculations from.  I use the TIMEUTC message.  I only use the 
>leapsecond offset from TIMEGPS.
>
>It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at the 
>beep, the time was...") , and just about everybody else sends it before the 
>pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
>thought (or lack of it) process that decided that was the way to do it.  And 
>don't get me started on the idiot receivers that send the sawtooth correction 
>message after the fact...
>--
>Despite re-checking I am still doubtful that my sums are right. I’ll do a few 
>more packets.  Is this what you are seeing Mark?   
>
>___
>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] Timelab and the 53220A - getting best results

[John Miles]

One workaround for the 1-million point limitation on imported data is to use 
"Acquire->Acquire from live ASCII file" instead of "File->Import ASCII 
phase/frequency data."  Most of the same code is used for both cases, but 
unlike the static file-import version of the dialog, the live data importer 
will let you specify the expected duration yourself.  So you can give it a 
duration value that you know will be long enough to cover the whole data set.  

I'm not too familiar with the 532x0A counters myself, but 8.9E-11 at t=1s 
doesn't sound too unrealistic.  When in doubt, look at the 'f'requency and/or 
'p'hase trends and residuals to sanity-check your data, rather than trying to 
puzzle out what's going wrong with the ADEV plot as many users seem to do.  
First you should satisfy yourself that the data makes sense, is unwrapped and 
scaled properly, and doesn't contain glitches, large crystal jumps, obvious 
beatnotes or other interference, or unexpected amounts of drift.  

-- john, KE5FX
Miles Design LLC

> I’ve gotten a little further with this. If I capture 60 seconds worth of time
> interval measurements (between two FE-5680As that are GPS disciplined, but
> with a long enough time constant that they’re basically free-running), I get
> 60,000 of them. So I imported at a sample interval of 1e-3 and got the right
> duration. There are a couple of problems, however. 1 is that even if I 
> attempt to
> log to a USB stick, it appears I can only log 1e6 samples before it stops. 
> That’s
> 16:40 or so, which isn’t very long. I haven’t figured out how to change the
> sample gate for time intervals (I’m assuming that a million samples is a hard
> limit). Also, importing the interval samples into TimeLab still shows me a 
> graph
> that’s still much steeper than I would expect. The graph is linear, with 
> points at
> tau 1s = 8.9E-11, 10s = 9.47E-12, 100s = 1.5E-12 (by then, the ADEV graph is
> starting to flatten out a bit, which probably indicates the noise floor of the
> 53220A near 1E-12), but the FEI datasheet shows a spec with points more like
> tau 1s = 1.5E-11, 10s = 4.5E-12 and 100s = 1.5E-12.
> 

___
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] Mystery hp Ovens For Sale

[paul swed]

Corby congratulations. Fun email to read.I suspect you made them quite the
reasonable offer. Enjoy.
Paul
WB8TSL

On Thu, Jun 2, 2016 at 11:58 AM,  wrote:

> Peter,
>
> Thanks for the heads up!
>
> I purchased both units and they arrived yesterday.
>
> I was worried for a moment as the HP106 assy. also had an HP107 part
> number on a label on the side.
>
> I realized that it was too big in diameter to fit a 107 but wonder why HP
> put that label on it???
>
> Carefully disassembled it and everything looked very nice inside
> including the giant Bliley 2.5Mhz XTAL.
>
> I had to clean off a bit of cadmium "fungus" off a few of the mechanical
> mounting parts.
>
> Also there are 3 of the old style white Vitromon capacitors in the
> oscillator section.
>
> These caps had tin whiskers "crowns" covering each end! They were removed
> easily with a small stiff brush.
>
> Now to apply some 24VDC and see if it fires up!
>
> The other unit has no identifying information, the two end caps come off
> by pushing three  locking slides over and pulling.
>
> Inside the adjustment end there is a small (7 or 9) pin electron tube!
> The oven end construction reminds me of a General Radio oven I one worked
> on.
>
> Built like a battleship!
>
> Anyone have any idea what it might come from. I'll try and post a PIX
> later.
>
> Might be 100Khz or 1Mhz.
>
> Cheers,
>
> Corby
>
> ___
> 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] Mystery hp Ovens For Sale

[cdelect]

Peter,

Thanks for the heads up!

I purchased both units and they arrived yesterday.

I was worried for a moment as the HP106 assy. also had an HP107 part
number on a label on the side.

I realized that it was too big in diameter to fit a 107 but wonder why HP
put that label on it???

Carefully disassembled it and everything looked very nice inside
including the giant Bliley 2.5Mhz XTAL.

I had to clean off a bit of cadmium "fungus" off a few of the mechanical
mounting parts.

Also there are 3 of the old style white Vitromon capacitors in the
oscillator section.

These caps had tin whiskers "crowns" covering each end! They were removed
easily with a small stiff brush.

Now to apply some 24VDC and see if it fires up!

The other unit has no identifying information, the two end caps come off
by pushing three  locking slides over and pulling.

Inside the adjustment end there is a small (7 or 9) pin electron tube!
The oven end construction reminds me of a General Radio oven I one worked
on.

Built like a battleship!

Anyone have any idea what it might come from. I'll try and post a PIX
later.

Might be 100Khz or 1Mhz.

Cheers,

Corby

___
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] Timelab and the 53220A - getting best results

[Nick Sayer via time-nuts]

I’ve gotten a little further with this. If I capture 60 seconds worth of time 
interval measurements (between two FE-5680As that are GPS disciplined, but with 
a long enough time constant that they’re basically free-running), I get 60,000 
of them. So I imported at a sample interval of 1e-3 and got the right duration. 
There are a couple of problems, however. 1 is that even if I attempt to log to 
a USB stick, it appears I can only log 1e6 samples before it stops. That’s 
16:40 or so, which isn’t very long. I haven’t figured out how to change the 
sample gate for time intervals (I’m assuming that a million samples is a hard 
limit). Also, importing the interval samples into TimeLab still shows me a 
graph that’s still much steeper than I would expect. The graph is linear, with 
points at tau 1s = 8.9E-11, 10s = 9.47E-12, 100s = 1.5E-12 (by then, the ADEV 
graph is starting to flatten out a bit, which probably indicates the noise 
floor of the 53220A near 1E-12), but the FEI datashe
 et shows a spec with points more like tau 1s = 1.5E-11, 10s = 4.5E-12 and 100s 
= 1.5E-12.

> On May 30, 2016, at 2:25 PM, Nick Sayer via time-nuts  
> wrote:
> 
> The 1 PPS outputs come directly from the GPS modules, so they’re not 
> interesting for me. I’m trying to evaluate the oscillators post-discipline.
> 
> I think the datasheet for the 53220A implies that no-dead-time measurement is 
> a value-add feature that the 53220A lacks. If I were going to upgrade, it 
> would be to a TimePod, but I can’t justify that today.
> 
> I have discovered the data logging feature, but the problem now is that it 
> doesn’t tell me what the sample time is. It appears the solution to that is 
> to simply divide the run time by the sample count. I’ve got a run going now 
> and am going to try that.
> 
> I could just go back to straight frequency counting, but then I have two 
> quantities - gate time and sample rate (where 1/sample rate > gate time). For 
> example, with a gate time of 0.5s, I get a sample time of around 0.75s or so 
> (caused by the over-the-network acquisition method used by TimeLab). Is that 
> reducing my acuity unduly?
> 
> 
>> On May 29, 2016, at 10:34 PM, Anders Wallin  
>> wrote:
>> 
>> A time-interval measurement between 1-PPS outputs of your two clocks is the 
>> most straightforward to interpret.
>> With the 20ps 53230A I get a noise-floor of about 1.8e-11/tau(s) for this 
>> measurement. 
>> I haven't tried the 100ps version, I suspect the hardware is identical and 
>> HPAK just de-rates the spec/firmware to 100ps in order to 'segment the 
>> market'.
>> 
>> In frequency counting mode things are tricky because it does some sort of 
>> omega-counting in default (CONT) mode.
>> This makes the effective bandwidth depend on the gate-time. (see 2nd image 
>> of 2nd link).
>> The pi-counting mode is called RCON and is undocumented AFAIK. I got 
>> 3e-11/tau(s) with a 1s gate time and here I would expect noise-floor 
>> measurements to fall on this same line independent of gate time (I haven't 
>> verified this).
>> 
>> http://www.anderswallin.net/2015/06/cont-vs-rcon-mode-on-the-53230a-frequency-counter/
>> http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
>> 
>> Anders
>> 
>> 
>> On Sat, May 28, 2016 at 7:11 PM, Nick Sayer via time-nuts 
>>  wrote:
>> So far, I’ve been configuring my 53220A for frequency measurements with a 
>> 500 msec gate time, and using the external reference and one input.
>> 
>> If instead I send the two devices into inputs A and B, and ask for the time 
>> interval between the two and give that to Timelab, my results look quite a 
>> bit worse.
>> 
>> At the moment, I’m doing that with a pair of 5680As. The ADEV at 100s is 
>> reasonably close to the spec at 1.83E-12, but the tau at 10s is what it’s 
>> *supposed* to be at 1s: 1.43E-11. At 1s, it’s 1.42E-10. The line is quite 
>> linear between those points, but the slope is way off the spec. The 
>> frequency difference graph supports this view - it shows a ±2E-10 “haze.”
>> 
>> I don’t have any reason to believe either oscillator is misbehaving to an 
>> extent that would explain this. I’m fairly sure I’m making some kind of 
>> fundamental newbie mistake and the test setup is introducing some sort of 
>> error, or I’m inside of the uncertainty of the 53220A and that’s why it’s 
>> showing poorly at low tau. My money is on the former. :)
>> 
>> The behavior I see suggests that how Timelab works with the 53220A is that 
>> it sends a command to obtain a single measurement over and over again. Thus, 
>> the network latency figures into the measurement timespan, I think. I’m sure 
>> there’s a way to record measurements in the 53220A internally and then 
>> export that file into Timelab, but I haven’t figured that out yet.
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to 

Re: [time-nuts] Ublox Neo-6M time error.

[Hal Murray]

david-tay...@blueyonder.co.uk said:
> I think that all the GPS devices I've used sent the time /after/ the PPS
> pulse.  I've never met one which sent it before. 

That makes sense for NMEA format messages which have fractional seconds in 
some of the message formats.  Mostly they are 0, but if filled in could tell 
you when the serial message started or ended.

That is the time labels the current second which started with the previous 
PPS.


-- 
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] Ublox Neo-6M time error.

[Mike Cook]

Hi Mark,

> Le 2 juin 2016 à 10:28, Mark Sims  a écrit :
> 
> The Ublox receivers do not have a message that outputs GPS time directly.  
> It's easiest to take the UTC time message and subtract the leapsecond offset 
> to get GPS time.   The itow value in the NAV_TIMEGPS message is milliseconds 
> past midnight of the start of the GPS week... probably not something you want 
> to be doing calculations from.  I use the TIMEUTC message.  I only use the 
> leapsecond offset from TIMEGPS.
> 

 Ok makes sense. BTW my calculations on other TIMEGPS messages using iTOW value 
confirm the strange finding I saw before:

09:02:08    B5 62 01 20 10 00 D0 0C 8A 16 5A 17 FD FF 6B 07  
  0010  11 07 0F 00 00 00 B3 4E  

Header  B5 62
ID  01 20
length  00 10   16
iTOW16 8A 0C D0 378146000 ms
fTOWFF FD 17 5A -ve some value
week07 6B   1:875
LeapS   11  17
flags   07  all bits valid
iAcc00 00 00 0F
CK_AB3
CK_B4E

Converting iTOW  : the above hex byte values have been changed to big endian .

4days 9h 2m 26s   from start of GPS week , that is Sunday midnight.
The seconds value make no sense in standard GPS time from the SV but as I 
saw before
can be MADE to make sense if you subtract current leap seconds.
 
4d 9h 2m 09s which is the NEXT second . 

09:02:09    24 47 50 52 4D 43 2C 30 39 30 32 30 39 2E 30 30  
$GPRMC,090209.00
  0010  2C 41 2C 34 38 34 37 2E 33 34 35 37 34 2C 4E 2C  
,A,4847.34574,N,
  0020  30 30 32 31 36 2E 32 39 37 38 32 2C 45 2C 30 2E  
00216.29782,E,0.
  0030  30 35 38 2C 2C 30 32 30 36 31 36 2C 2C 2C 41 2A  
058,,020616,,,A*
  0040  37 31 0D 0A  71

> It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at the 
> beep, the time was...") , and just about everybody else sends it before the 
> pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
> thought (or lack of it) process that decided that was the way to do it.  And 
> don't get me started on the idiot receivers that send the sawtooth correction 
> message after the fact...
> --
> Despite re-checking I am still doubtful that my sums are right. I’ll do a few 
> more packets.  Is this what you are seeing Mark?  
> 
> ___
> 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.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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] Ublox Neo-6M time error.

[David J Taylor]

From: Mark Sims
[]
It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at 
the beep, the time was...") , and just about everybody else sends it before 
the pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
thought (or lack of it) process that decided that was the way to do it.  And 
don't get me started on the idiot receivers that send the sawtooth 
correction message after the fact...

[]
___

I think that all the GPS devices I've used sent the time /after/ the PPS 
pulse.  I've never met one which sent it before.


David
--
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] Ublox Neo-6M time error.

[Mark Sims]

The Ublox receivers do not have a message that outputs GPS time directly.  It's 
easiest to take the UTC time message and subtract the leapsecond offset to get 
GPS time.   The itow value in the NAV_TIMEGPS message is milliseconds past 
midnight of the start of the GPS week... probably not something you want to be 
doing calculations from.  I use the TIMEUTC message.  I only use the leapsecond 
offset from TIMEGPS.

It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at the 
beep, the time was...") , and just about everybody else sends it before the 
pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
thought (or lack of it) process that decided that was the way to do it.  And 
don't get me started on the idiot receivers that send the sawtooth correction 
message after the fact...
--
Despite re-checking I am still doubtful that my sums are right. I’ll do a few 
more packets.  Is this what you are seeing Mark?

___
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] Commercial software defined radio for clock metrology

[Attila Kinali]

On Wed, 1 Jun 2016 16:00:39 +
"Sherman, Jeffrey A. (Fed)"  wrote:

> I'm not sure exact which ~15dB you're contemplating, but I'll hazard
> a guess. 

You measured an ADC noise floor of -140dBc/Hz. The TimePod has a spec'ed
noise floor of -170dBc/Hz(typ). That's a difference of ~30dB.

The different specs of the ADCs and the signal level account for a difference 
of about ~14dB. There is still a ~16dB difference that I cannot explain.

> We observe some non-idealities in the SDR (or our noise environment), 
> the effect of which scales with decimation factor. In principle, reducing
> the bandwidth through low-pass decimation---suppose by a factor of 100--
>-should increase the signal-to-noise by 20 dB. This result relies on a
> completely white-noise spectrum, ideal filters, and no round-off or
> quantization noise. For a decimation factor of 100, we observed an SNR
> improvement of about 11 dB instead of 20 dB. This deficit in "process gain"
> was another 3 dB worse at a decimation factor of 500. Some additional
> details are in Appendix B of the paper.

I would have guessed, that the TimePod is plagued by the same effects.
But maybe it has less spurs and thus can achieve a higher SNR gain
during decimation.


Attila Kinali

-- 
Reading can seriously damage your ignorance.
-- unknown
___
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] picDIV board.

[Tom Van Baak]

Hi Dan,

Thanks for the OSH park link. I hadn't seen that.

The prototype board I often use for picPET and picDIV chips is:
https://www.pololu.com/product/331

Also, don't forget about the TAPR T2-mini:
https://www.tapr.org/kits_t2-mini.html
https://www.tapr.org/images/TADD-2_Mini_Top_Scaled.jpg
http://www.tapr.org/~n8ur/T2_Mini_Manual.pdf

The T2-mini ships with the PD17 divider in the DIP8 socket. Many of the other 
PIC dividers are compatible with the T2-mini design.

/tvb

- Original Message - 
From: 
To: 
Sent: Wednesday, June 01, 2016 7:01 PM
Subject: [time-nuts] picDIV board.


So, having a batch of PIC12F675's to play with the picDIV's with, but 
being lazy I decided to look for a dev board for the 8 pin PIC's. 
(Yeah, I know how lazy can you get! :) ) Just didn't feel like wiring 
up the programming header to a bread board, etc. Anyway, one appeared 
in google on OSH park and Tindie. Looks like the same guy. So for 
anyone thinking about playing with the picDIV but feeling as lazy as I 
am, this might be a good option. It even includes some prototype area 
on the board! 

 From OSH park you get 3 boards for under $10. 
https://oshpark.com/shared_projects/kXG6K5Xu 

For those of you who don't know what a PIC DIV is: 
http://www.leapsecond.com/pic/picdiv.htm

My guess is it would also work with a picPET and an FTDI cable. 
http://www.leapsecond.com/pic/picpet.htm

Dan



___
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] Ublox Neo-6M time error.

[Mike Cook]

> Le 1 juin 2016 à 03:20, Mark Sims  a écrit :
> 
> I had two machines running Lady Heather with the singing chime clock mode 
> enabled (that plays a chant from the Missa Assumpta on the quarter hours).   
> 
> One machine was connected to a Ublox Neo-6M receiver and another to a Z3801A. 
>   I noticed that the two machines sang their jaunty monk tunes offset by 
> around one second.  Since a man with two singing GPS clocks never knows what 
> time it is,  I replaced the Z3801A with a Jupiter-T and the two clocks were 
> still out of sync.   Finally I tried  Motorola M12+ and UT receivers and the 
> same thing happened.  It looks like the Ublox time is ahead by a second 
> compared to all the other receivers.   I then specified a -1 second 
> "rollover" correction to the Ublox machine and the two clocks sang in perfect 
> harmony.   Has anybody noticed such behavior with other receivers?
> 
> BTW,  note that the Ublox binary time message has a "fractional nanoseconds 
> of the seconds field" (+/- 500,000 nanoseconds) correction that must be 
> applied to the hrs:min:secs values (which I am doing).  The fractional time 
> offset forms a sawtooth with around a 120 second period.  Attached is a 
> GIF... white is the nanosecond fractional time offset.  Magenta is the 
> receiver estimate of its time error (both in nanoseconds).  The Trimble 
> Resolution-T receivers report a similar "local clock bias" value, but they 
> don't seem to document what it actually is…

The manual states that all protocol messages are sent after the 1PPS time 
pulse. But it looks like the nav time message is an exception.
> 

I dumped the default data stream (just NMEA) with u-center. The first NMEA 
message being a GPRMC and the last being GPGGL.
>From your post I figured that you were referring to the NAV-TIMEGPS message so 
>I configured that in. The message showed up between the last NMEA message for 
>the second and the GPRMC at the top of the next second.

 15:42:31    24 47 50 52 4D 43 2C 31 35 34 32 33 31 2E 30 30  
$GPRMC,154231.00
  0010  2C 41 2C 34 38 34 37 2E 33 35 31 39 30 2C 4E 2C  
,A,4847.35190,N,
  0020  30 30 32 31 36 2E 33 30 34 31 38 2C 45 2C 30 2E  
00216.30418,E,0.
  0030  30 39 30 2C 2C 30 31 30 36 31 36 2C 2C 2C 41 2A  
090,,010616,,,A*
  0040  37 33 0D 0A  73
15:42:31    24 47 50 56 54 47 2C 2C 54 2C 2C 4D 2C 30 2E 30  
$GPVTG,,T,,M,0.0
  0010  39 30 2C 4E 2C 30 2E 31 36 36 2C 4B 2C 41 2A 32  
90,N,0.166,K,A*2
  0020  42 0D 0A B
15:42:31    24 47 50 47 47 41 2C 31 35 34 32 33 31 2E 30 30  
$GPGGA,154231.00
  0010  2C 34 38 34 37 2E 33 35 31 39 30 2C 4E 2C 30 30  
,4847.35190,N,00
  0020  32 31 36 2E 33 30 34 31 38 2C 45 2C 31 2C 30 39  
216.30418,E,1,09
  0030  2C 30 2E 39 31 2C 31 38 39 2E 33 2C 4D 2C 34 36  
,0.91,189.3,M,46
  0040  2E 32 2C 4D 2C 2C 2A 35 34 0D 0A .2,M,,*54
15:42:31    24 47 50 47 53 41 2C 41 2C 33 2C 32 36 2C 32 31  
$GPGSA,A,3,26,21
  0010  2C 30 35 2C 32 37 2C 31 36 2C 32 39 2C 32 35 2C  
,05,27,16,29,25,
  0020  33 31 2C 32 30 2C 2C 2C 2C 31 2E 36 34 2C 30 2E  
31,201.64,0.
  0030  39 31 2C 31 2E 33 36 2A 30 31 0D 0A  91,1.36*01
15:42:31    24 47 50 47 53 56 2C 34 2C 31 2C 31 33 2C 30 34  
$GPGSV,4,1,13,04
  0010  2C 38 35 2C 32 39 39 2C 33 33 2C 30 35 2C 31 35  
,85,299,33,05,15
  0020  2C 30 34 36 2C 33 38 2C 30 39 2C 30 34 2C 33 32  
,046,38,09,04,32
  0030  39 2C 2C 31 36 2C 33 35 2C 33 30 32 2C 33 37 2A  
9,,16,35,302,37*
  0040  37 43 0D 0A  7C
15:42:31    24 47 50 47 53 56 2C 34 2C 32 2C 31 33 2C 31 38  
$GPGSV,4,2,13,18
  0010  2C 30 36 2C 31 34 35 2C 31 34 2C 32 30 2C 32 33  
,06,145,14,20,23
  0020  2C 30 39 33 2C 31 37 2C 32 31 2C 36 33 2C 31 35  
,093,17,21,63,15
  0030  34 2C 32 30 2C 32 33 2C 30 34 2C 33 30 33 2C 2A  
4,20,23,04,303,*
  0040  37 39 0D 0A  79
15:42:31    24 47 50 47 53 56 2C 34 2C 33 2C 31 33 2C 32 35  
$GPGSV,4,3,13,25
  0010  2C 31 35 2C 31 32 34 2C 31 35 2C 32 36 2C 36 36  
,15,124,15,26,66
  0020  2C 32 39 37 2C 34 34 2C 32 37 2C 31 32 2C 32 35  
,297,44,27,12,25
  0030  38 2C 31 34 2C 32 39 2C 33 37 2C 30 36 37 2C 33  
8,14,29,37,067,3
  0040  39 2A 37 43 0D 0A9*7C
15:42:31    24 47 50 47 53 56 2C 34 2C 34 2C 31 33 2C 33 31  
$GPGSV,4,4,13,31
  0010  2C 33 39 2C 32 30 38 2C 32 30 2A 34 42 0D 0A ,39,208,20*4B
15:42:31    24 47 50 47 4C 4C 2C 34 38 34 37 2E 33 35 31 39  
$GPGLL,4847.3519
  0010  30 2C 4E 2C 30 30 32 31 36 2E 33 30 34 31 38 2C  
0,N,00216.30418,
  0020  45 2C 31 35 34 32 33 31 2E 30 30 2C 41 2C 41 2A  
E,154231.00,A,A*