[time-nuts] timelab（http://www.miles.io/timelab/readme.htm） and HP3132a

[weijiazhen]

I want to use software timelab（http://www.miles.io/timelab/readme.htm） and 
HP3132a to test 2 rubidium 10MHz ADEV, I don't know how to use TI mode (time 
interval), please help me how to operate.
I have 2 10MHz channels, 1 and 2, software Acquire---HP 
53131A/53132A/53181A---start measurement, but test ADEV is wrong. The curves of 
each measurement vary greatly.

wei
___
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] Timelab file needed

[Bob Stewart]

Does anyone have a timelab file for a KS-24361?  My KS has a much worse 1s ADEV 
(and on down the line) than I would have expected, and I'd like to see what 
others are getting.
Bob

AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
___
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, GPIB-USB-B in a VM

[paul swed]

Pretty sure the GPIB-enets been unsupported for about 10 years.
I have one and liked it. But when NI didn't move it forward with the
operating systems it became a pain in the butt needing a windows 98 machine.
This talk of using VMs is interesting indeed. I have used both KVM and
VMware.
Regards
Paul
WB8TSL

On Mon, Mar 27, 2017 at 11:49 PM, Bob Bownes <bow...@gmail.com> wrote:

>
> Yup, I'm using VBox. Kinda have to on account it $DAY_JOB. ;)
>
> In any case, it appears, in the USB case, to be an Issue with the
> GPIB-USB-B as when I swapped it out with a GPIB-USB-HS, it all comes right
> up.
>
> I'm suspicious of the GPIB-ENET, and am wondering if I've been bitten by a
> No Longer Supported by NI issue. Bah.
>
> In any case, there is a nice 8 hour adev running on an old 10811 that's
> been on the bench for a while. Will swap that one out for one marked 'bad
> phase noise' in the am and see how they match up.
>
> > On Mar 27, 2017, at 21:20, Bob Stewart <b...@evoria.net> wrote:
> >
> > I don't know how they're done in VMWare, but in VirtualBox, you have to
> setup the USB configuration for the VM before you start it.  You just click
> the machine, settings, then USB, then add a device, then select from what's
> available.  Which means you have to have it plugged in and enumerated first.
> >
> > Bob
> >
> >
> >  From: Bob Bownes <bow...@gmail.com>
> > To: Discussion of precise time and frequency measurement <
> time-nuts@febo.com>
> > Sent: Monday, March 27, 2017 8:03 PM
> > Subject: Re: [time-nuts] Timelab, GPIB-USB-B in a VM
> >
> > John,
> >
> > Thanks for the reply.
> >
> > I'm obviously missing something as I can't see the GPIB-USB-B or the
> > ethernet connected GPIB-ENET.
> >
> > It's really as simple as going to aquire->HP5371/5372 and the interfaces
> > should be in the list, correct?
> >
> > Thanks,
> > Bob
> >
> >
> >> On Mon, Mar 27, 2017 at 6:42 PM, John Miles <j...@miles.io> wrote:
> >>
> >> Try running the 32-bit version (timelab.exe) instead of timelab64.exe,
> >> even if the VM supports 64-bit execution.  That can sometimes help with
> >> compatibility.
> >>
> >> -- john, KE5FX
> >> Miles Design LLC
> >>
> >>> -Original Message-
> >>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob
> >>> Bownes
> >>> Sent: Monday, March 27, 2017 2:49 PM
> >>> To: Discussion of precise time and frequency measurement
> >>> Subject: [time-nuts] Timelab, GPIB-USB-B in a VM
> >>>
> >>> So I'm trying to run timelab in a windows 7 VM with a GPIB-USB-B
> >> interface.
> >>>
> >>> Anyone ever tried such a thing?
> >>>
> >>> The NI explorer sees the interface but nothing else does.
> >>>
> >>> Pointers welcome!
> >>>
> >>> Data on a bunch of oscillators as soon as I get it to work...:)
> >>>
> >>> Thanks,
> >>> Bob
> >>> ___
> >>> time-nuts mailing list -- time-nuts@febo.com
> >>> To unsubscribe, go to https://www.febo.com/cgi-
> >>> bin/mailman/listinfo/time-nuts
> >>> and follow the instructions there.
> >>
> >> ___
> >> time-nuts mailing list -- time-nuts@febo.com
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
> >
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
> ___
> 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, GPIB-USB-B in a VM

[Bob Bownes]

Yup, I'm using VBox. Kinda have to on account it $DAY_JOB. ;)

In any case, it appears, in the USB case, to be an Issue with the GPIB-USB-B as 
when I swapped it out with a GPIB-USB-HS, it all comes right up. 

I'm suspicious of the GPIB-ENET, and am wondering if I've been bitten by a No 
Longer Supported by NI issue. Bah. 

In any case, there is a nice 8 hour adev running on an old 10811 that's been on 
the bench for a while. Will swap that one out for one marked 'bad phase noise' 
in the am and see how they match up. 

> On Mar 27, 2017, at 21:20, Bob Stewart <b...@evoria.net> wrote:
> 
> I don't know how they're done in VMWare, but in VirtualBox, you have to setup 
> the USB configuration for the VM before you start it.  You just click the 
> machine, settings, then USB, then add a device, then select from what's 
> available.  Which means you have to have it plugged in and enumerated first.
> 
> Bob 
> 
> 
>  From: Bob Bownes <bow...@gmail.com>
> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
> Sent: Monday, March 27, 2017 8:03 PM
> Subject: Re: [time-nuts] Timelab, GPIB-USB-B in a VM
> 
> John,
> 
> Thanks for the reply.
> 
> I'm obviously missing something as I can't see the GPIB-USB-B or the
> ethernet connected GPIB-ENET.
> 
> It's really as simple as going to aquire->HP5371/5372 and the interfaces
> should be in the list, correct?
> 
> Thanks,
> Bob
> 
> 
>> On Mon, Mar 27, 2017 at 6:42 PM, John Miles <j...@miles.io> wrote:
>> 
>> Try running the 32-bit version (timelab.exe) instead of timelab64.exe,
>> even if the VM supports 64-bit execution.  That can sometimes help with
>> compatibility.
>> 
>> -- john, KE5FX
>> Miles Design LLC
>> 
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob
>>> Bownes
>>> Sent: Monday, March 27, 2017 2:49 PM
>>> To: Discussion of precise time and frequency measurement
>>> Subject: [time-nuts] Timelab, GPIB-USB-B in a VM
>>> 
>>> So I'm trying to run timelab in a windows 7 VM with a GPIB-USB-B
>> interface.
>>> 
>>> Anyone ever tried such a thing?
>>> 
>>> The NI explorer sees the interface but nothing else does.
>>> 
>>> Pointers welcome!
>>> 
>>> Data on a bunch of oscillators as soon as I get it to work...:)
>>> 
>>> Thanks,
>>> Bob
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-
>>> bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
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, GPIB-USB-B in a VM

[Bob Stewart]

I don't know how they're done in VMWare, but in VirtualBox, you have to setup 
the USB configuration for the VM before you start it.  You just click the 
machine, settings, then USB, then add a device, then select from what's 
available.  Which means you have to have it plugged in and enumerated first.

Bob 


  From: Bob Bownes <bow...@gmail.com>
 To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
 Sent: Monday, March 27, 2017 8:03 PM
 Subject: Re: [time-nuts] Timelab, GPIB-USB-B in a VM
   
John,

Thanks for the reply.

I'm obviously missing something as I can't see the GPIB-USB-B or the
ethernet connected GPIB-ENET.

It's really as simple as going to aquire->HP5371/5372 and the interfaces
should be in the list, correct?

Thanks,
Bob


On Mon, Mar 27, 2017 at 6:42 PM, John Miles <j...@miles.io> wrote:

> Try running the 32-bit version (timelab.exe) instead of timelab64.exe,
> even if the VM supports 64-bit execution.  That can sometimes help with
> compatibility.
>
> -- john, KE5FX
> Miles Design LLC
>
> > -Original Message-
> > From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob
> > Bownes
> > Sent: Monday, March 27, 2017 2:49 PM
> > To: Discussion of precise time and frequency measurement
> > Subject: [time-nuts] Timelab, GPIB-USB-B in a VM
> >
> > So I'm trying to run timelab in a windows 7 VM with a GPIB-USB-B
> interface.
> >
> > Anyone ever tried such a thing?
> >
> > The NI explorer sees the interface but nothing else does.
> >
> > Pointers welcome!
> >
> > Data on a bunch of oscillators as soon as I get it to work...:)
> >
> > Thanks,
> > Bob
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-
> > bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


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

Re: [time-nuts] Timelab, GPIB-USB-B in a VM

[Bob Bownes]

John,

Thanks for the reply.

I'm obviously missing something as I can't see the GPIB-USB-B or the
ethernet connected GPIB-ENET.

It's really as simple as going to aquire->HP5371/5372 and the interfaces
should be in the list, correct?

Thanks,
Bob


On Mon, Mar 27, 2017 at 6:42 PM, John Miles <j...@miles.io> wrote:

> Try running the 32-bit version (timelab.exe) instead of timelab64.exe,
> even if the VM supports 64-bit execution.  That can sometimes help with
> compatibility.
>
> -- john, KE5FX
> Miles Design LLC
>
> > -Original Message-
> > From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob
> > Bownes
> > Sent: Monday, March 27, 2017 2:49 PM
> > To: Discussion of precise time and frequency measurement
> > Subject: [time-nuts] Timelab, GPIB-USB-B in a VM
> >
> > So I'm trying to run timelab in a windows 7 VM with a GPIB-USB-B
> interface.
> >
> > Anyone ever tried such a thing?
> >
> > The NI explorer sees the interface but nothing else does.
> >
> > Pointers welcome!
> >
> > Data on a bunch of oscillators as soon as I get it to work...:)
> >
> > Thanks,
> > Bob
> > ___
> > 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, GPIB-USB-B in a VM

[Tim Lister]

On Mon, Mar 27, 2017 at 2:48 PM, Bob Bownes  wrote:
> So I'm trying to run timelab in a windows 7 VM with a GPIB-USB-B interface.
>
> Anyone ever tried such a thing?
>
> The NI explorer sees the interface but nothing else does.
>
> Pointers welcome!

I believe you have to configure the Virtual Machine hosting software
to allow USB passthrough to the host OS. I cam across this recently in
a Youtube video (https://www.youtube.com/watch?v=xJ0Mfuj0KUQ) which
was getting an ADF4351 board's Windows software working under Linux -
unfortunately I don't have a stream pointer as to how far in it was
but I think it was towards the early-middle

>
> Data on a bunch of oscillators as soon as I get it to work...:)
>
> Thanks,
> Bob

Cheers,
Tim
___
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, GPIB-USB-B in a VM

[John Miles]

Try running the 32-bit version (timelab.exe) instead of timelab64.exe, even if 
the VM supports 64-bit execution.  That can sometimes help with compatibility.

-- john, KE5FX
Miles Design LLC

> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob
> Bownes
> Sent: Monday, March 27, 2017 2:49 PM
> To: Discussion of precise time and frequency measurement
> Subject: [time-nuts] Timelab, GPIB-USB-B in a VM
> 
> So I'm trying to run timelab in a windows 7 VM with a GPIB-USB-B interface.
> 
> Anyone ever tried such a thing?
> 
> The NI explorer sees the interface but nothing else does.
> 
> Pointers welcome!
> 
> Data on a bunch of oscillators as soon as I get it to work...:)
> 
> Thanks,
> Bob
> ___
> 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] Timelab, GPIB-USB-B in a VM

[Bob Bownes]

So I'm trying to run timelab in a windows 7 VM with a GPIB-USB-B interface.

Anyone ever tried such a thing?

The NI explorer sees the interface but nothing else does.

Pointers welcome!

Data on a bunch of oscillators as soon as I get it to work...:)

Thanks,
Bob
___
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] Timelab file wanted

[Bob Stewart]

Hi Guys,
Does anyone have a multi-day (at least 5 days) timelab file comparing the 1PPS 
from a GPSDO to a Cesium standard, with a run of the mill rooftop antenna using 
at least an HP 5370A quality TIC?  I'm running a 7 day test like this, and I'd 
like to have something to compare to.  If you have one, could you send me a 
copy off-list?

thanks,
Bob Stewart ---   bob at evoria dot net
 
-
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
___
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 question

[Bob Stewart]

Hi Andrew,
Thanks for the heads up.  That seems to have done the trick!  If you don't 
mind, I'm sending you a query about something else off-list.
Bob 
-
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Andrew Rodland <and...@cleverdomain.org>
 To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com> 
 Sent: Friday, February 24, 2017 12:18 AM
 Subject: Re: [time-nuts] Timelab question
   
On Tue, Feb 21, 2017 at 5:26 PM, Bob Stewart <b...@evoria.net> wrote:
> Thanks, John.  That will certainly get it to work as I expect it to.  I doubt 
> I'm the only one who's lost a dataset due to being distracted and hitting the 
> enter key to clear the dialog box.
>
> Wine is just a mess as far as Timelab is concerned.  Most of the time it 
> doesn't display the plot area.  I've pretty much given up on it.

This, at least, is easily fixed; use "winetricks gdiplus" to replace
Wine's GDI+ implementation with Microsoft's (the native DLL). Then all
the stuff that didn't draw before will work just fine. It does have a
few other little issues, but on the whole it works remarkably well for
me.


   
___
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 question

[Andrew Rodland]

On Tue, Feb 21, 2017 at 5:26 PM, Bob Stewart  wrote:
> Thanks, John.  That will certainly get it to work as I expect it to.  I doubt 
> I'm the only one who's lost a dataset due to being distracted and hitting the 
> enter key to clear the dialog box.
>
> Wine is just a mess as far as Timelab is concerned.  Most of the time it 
> doesn't display the plot area.  I've pretty much given up on it.

This, at least, is easily fixed; use "winetricks gdiplus" to replace
Wine's GDI+ implementation with Microsoft's (the native DLL). Then all
the stuff that didn't draw before will work just fine. It does have a
few other little issues, but on the whole it works remarkably well for
me.
___
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] Timelab question

[Mark Sims]

Yes, it should.  Heather can input from a serial/USB connection or TCP/IP.   
Your GPIB interface needs to stream data in a "talk-only" mode.

Currently my TIC reader can handle either time interval (period) data or time 
stamps.   It knows about TICC data with channel identifiers on the values and 
HP 5313x format (commas in the numbers, embedded statistics, and us / d flags), 
 or generic (untagged)  data.  I'm not currently handling data from more than 
one input device at a time or frequency data as input. 

 I need to add some code to handle potential phase wraps for time intervals / 
time stamps.  Also maybe support frequency input.

 Heather can process up to 4 channels of data and simultaneously calculates 
ADEV/HDEV/MDEV/TDEV for each channel.  You can switch the display / plots 
between the 4 adevs for a selected channel or a selected adev type for all four 
channels.

--

> Any chance that Lady Heather would support the HP5370A/B ? Does she support
HPIB in some way (or using the BeagleBone brain transplant and tcp).
___
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] Timelab question

[Mark Sims]

There are apparently companies out there that specialize in low volume 
semi-custom enclosures.  They are a lot like the cheap PCB manufacturers that 
we are now blessed with in their economies of scale.   I think the guy 
mentioned the price for this power supply enclosure was around $35 (BTW, it's a 
really nifty power supply.  There is a long thread on EEVBLOG covering its 
development.  It uses and Arduino Due for the processor.)

https://www.crowdsupply.com/envox/eez-h24005
___
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] Timelab question

[Mark Sims]

A nasty bug crawled into my ear last night and muttered something like:

"Put the TICC counter circuit, a 1/5/10/15 Mhz PICDIV divider, input squarer, 
terminator relay, etc on a module.Make a motherboard that 4-8 of those 
modules can plug into along with an ATMEGA processor.  Output the data via good 
ole RS-232 ... everybody can probably find a USB-Serial converter that works 
with their system... they may not be able to find a driver for a specific / 
custom USB device like an Ardunio USB port".  Oh, and put some footprints for a 
quality reference OCXO and some power regulators on the motherboard.

That damn little critter in my ear keeps burrowing deeper and closer to my 
frontal builditbellum...  I'm off to the store to see if I can find some bug 
spray before it gets there.

---

> For my own use, I'm also going to do a couple of 2U rack enclosures -- 
one to hold two TICCs operating independently, and another for the 
"megaTICC" -- four units slaved together to make an 8 channel counter
___
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 question

[Paul Alfille]

Any chance that Lady Heather would support the HP5370A/B ? Does she support
HPIB in some way (or using the BeagleBone brain transplant and tcp).

Paul Alfille K1PHA

On Tue, Feb 21, 2017 at 6:35 PM, Mark Sims  wrote:

> At one time Timelab worked well for me under Wine.  It's been years since
> I tried it.
>
> I recently got in a TAPR TICC and am in the process of adding time
> interval counter support to Lady Heather.   It's not even remotely as nifty
> as Timelab (and never will be),  but it does run under Windows / Linux /
> macOS and FreeBSD.  It can calculate and plot ADEV/HDEV/MDEV/TDEV.  The
> code supports up to 4 simultaneous channels of TICC data (but the TICC is
> currently a 2 channel device).
>
> Besides the TICC it should work (single channel) with HP53xxx counters and
> counters that output time stamps or time intervals in "talk only" mode.
> There is the possibility of supporting more than one counter device...
> Heather can now handle up to 10 com devices and TCP/IP links.
>
> I plan to package up my TICC and a couple of TADD-2 Mini dividers with a
> RPI-3 and the 7" touchscreen display and an Osciiloquartz 8663 DOXCO to
> make a small ADEV analyzer box.
>
> --
>
> > Wine is just a mess as far as Timelab is concerned.  Most of the time it
> doesn't display the plot area.  I've pretty much given up on it.
> ___
> 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 question

[Peter Vince]

On 21 February 2017 at 23:35, Mark Sims  wrote:

> ...
> I plan to package up my TICC and a couple of TADD-2 Mini dividers with a
> RPI-3 and the 7" touchscreen display and an Osciiloquartz 8663 DOXCO to
> make a small ADEV analyzer box.
>

Wow!  If you can persuade John and TAPR to produce that, I would be there
with my chequebook before the ink had dried on the web-page! :-)

 Peter
___
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] Timelab question

[Mark Sims]

At one time Timelab worked well for me under Wine.  It's been years since I 
tried it.

I recently got in a TAPR TICC and am in the process of adding time interval 
counter support to Lady Heather.   It's not even remotely as nifty as Timelab 
(and never will be),  but it does run under Windows / Linux / macOS and 
FreeBSD.  It can calculate and plot ADEV/HDEV/MDEV/TDEV.  The code supports up 
to 4 simultaneous channels of TICC data (but the TICC is currently a 2 channel 
device).  

Besides the TICC it should work (single channel) with HP53xxx counters and 
counters that output time stamps or time intervals in "talk only" mode. There 
is the possibility of supporting more than one counter device...  Heather can 
now handle up to 10 com devices and TCP/IP links.

I plan to package up my TICC and a couple of TADD-2 Mini dividers with a RPI-3 
and the 7" touchscreen display and an Osciiloquartz 8663 DOXCO to make a small 
ADEV analyzer box.

--

> Wine is just a mess as far as Timelab is concerned.  Most of the time it 
> doesn't display the plot area.  I've pretty much given up on it.
___
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 question

[Bob Stewart]

Thanks, John.  That will certainly get it to work as I expect it to.  I doubt 
I'm the only one who's lost a dataset due to being distracted and hitting the 
enter key to clear the dialog box.

Wine is just a mess as far as Timelab is concerned.  Most of the time it 
doesn't display the plot area.  I've pretty much given up on it.
Bob 


  From: John Miles <j...@miles.io>
 To: 'Bob Stewart' <b...@evoria.net>; 'Discussion of precise time and frequency 
measurement' <time-nuts@febo.com> 
 Sent: Tuesday, February 21, 2017 3:56 PM
 Subject: RE: [time-nuts] Timelab question
   
> John,
> I apologize.  I was mistaken in my question.  Under wine it behaves poorly,
> but that's to be expected.  Under XP in a Virtual box, it works as you say.  
> The
> same in a real Win 10 box.  The problem is actually that I was expecting the
> "No" box to be checked, and to require the user to change it to "Yes" if he
> really wanted to exit.  So, if I press the Enter key to get rid of the dialog 
> box,
> the program exits.

I see what you mean.  I've got a couple of other minor tweak requests lined up 
for the next beta, so I'll add MB_DEFBUTTON2 to those prompts to keep that from 
happening.

If Wine is interpreting a second Escape keypress as 'Yes', then that's 
definitely a bug on their part.  Worth reporting to them if it still happens in 
the current version.

-- john
Miles Design LLC


   
___
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 question

[John Miles]

> John,
> I apologize.  I was mistaken in my question.  Under wine it behaves poorly,
> but that's to be expected.  Under XP in a Virtual box, it works as you say.  
> The
> same in a real Win 10 box.  The problem is actually that I was expecting the
> "No" box to be checked, and to require the user to change it to "Yes" if he
> really wanted to exit.  So, if I press the Enter key to get rid of the dialog 
> box,
> the program exits.

I see what you mean.  I've got a couple of other minor tweak requests lined up 
for the next beta, so I'll add MB_DEFBUTTON2 to those prompts to keep that from 
happening.

If Wine is interpreting a second Escape keypress as 'Yes', then that's 
definitely a bug on their part.  Worth reporting to them if it still happens in 
the current version.

-- john
Miles Design LLC

___
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 question

[Bob Stewart]

John,
I apologize.  I was mistaken in my question.  Under wine it behaves poorly, but 
that's to be expected.  Under XP in a Virtual box, it works as you say.  The 
same in a real Win 10 box.  The problem is actually that I was expecting the 
"No" box to be checked, and to require the user to change it to "Yes" if he 
really wanted to exit.  So, if I press the Enter key to get rid of the dialog 
box, the program exits.  

Bob 

  From: John Miles <j...@miles.io>
 To: 'Discussion of precise time and frequency measurement' 
<time-nuts@febo.com> 
 Sent: Tuesday, February 21, 2017 12:39 AM
 Subject: Re: [time-nuts] Timelab question
   
> Is there a way to change the escape key in Timelab so that it doesn't default
> to "yes"?  I love Timelab, but this is driving me nuts.  I hit the escape key 
> and
> it asks me if I really want to exit.  No, I don't!  So, I hit the escape key 
> and
> yes, it does exit.
> Bob

Hmm.  I can't repro this on Win7 x64 -- what version of Windows are you running?

If I hit Escape followed by Enter, it does exit, since 'Yes' is the default 
choice.  But hitting Escape twice doesn't do anything (and shouldn't).

-- john
Miles Design LLC

___
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 question

[John Miles]

> Is there a way to change the escape key in Timelab so that it doesn't default
> to "yes"?  I love Timelab, but this is driving me nuts.  I hit the escape key 
> and
> it asks me if I really want to exit.  No, I don't!  So, I hit the escape key 
> and
> yes, it does exit.
> Bob

Hmm.  I can't repro this on Win7 x64 -- what version of Windows are you running?

If I hit Escape followed by Enter, it does exit, since 'Yes' is the default 
choice.  But hitting Escape twice doesn't do anything (and shouldn't).

-- john
Miles Design LLC

___
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] Timelab question

[Bob Stewart]

Is there a way to change the escape key in Timelab so that it doesn't default 
to "yes"?  I love Timelab, but this is driving me nuts.  I hit the escape key 
and it asks me if I really want to exit.  No, I don't!  So, I hit the escape 
key and yes, it does exit.
Bob
___
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

[Magnus Danielson]

Hi Tom,

On 10/09/2016 10:07 PM, Tom Van Baak wrote:

Hi Magnus,

I run into this all the time. Some thoughts...

1) My *work-around* is to adjust the REF 1PPS by tens of microseconds, or even 
500 ms. That avoids running into sign changes and skipped samples when a TIC 
gets near zero. This works really well for stable clocks where 500 ms drift is 
next to impossible.


Well, that is one option. However, as I care about where my zero line 
is, it's annoying to operate in TimeLab.


The main problem I try to illustrate is the shift from tau = 1 s to
tau = 2 s, which can be a dominant case (say 50% of all samples) while 
the through zero is annoying, but is more in the neighborhood of below 1 
% of all samples.



2) My *solution* is to use time-stamping counters (TSC) instead of time interval counters (TIC). With 
time-stamping you avoid all the hassles of a TIC. There is no worry about CH1 vs. CH2, there are no sign 
changes, there are no missed samples, it doesn't matter if the sources are fast or slow, or ahead of behind. 
There is no concept of "start" or "stop", but only "when".

For high-end TSC, I use a CNT-90 (or equiv) and for low-end I use my little 
picPET. It gets even more useful if you have multiple, synchronized time 
stamping counters.


If all the counters we lay out hands on where capable of it, then no 
question about it. I made the distinct case that we are not always 
fortunate to have such counter available, and still want to make decent 
enought measurements. I wanted to both explain the problem, show the 
wiring setup and then propose minor software changes to make it much 
easier to use.


If I where to use any counter in my private setup, then things would 
quickly become much simpler. I intentionally stepped out of that case 
and illustrated the hurdles of a fairly common clock.



3) The problems you are running into get far worse the less accurate and less 
stable the sources are (such as mains, mechanical, vintage quartz, and pendulum 
clocks). So that's why I developed the picPET time-stamping counter. It's 400 
ns resolution is not good enough for you. Even the new 10 ns version isn't good 
enough for your needs.

But a fellow time nut is working on a 100 ps version which will do both time 
stamping and time interval. That, finally, will solve the problems everyone has 
with TIC's. However, I still use hp 53131A/53132A a lot in my lab and simply 
avoid the TIC problem using #1 above.


I intentionally steered clear from build another devise. Naturally, if a 
sufficiently good and price-worthy one would be easily available, it 
would remove much of the worries. Until then, lest than ideal hardware 
and then try to use some additional signals and some software to make 
things behave sufficiently good.



4) TimeLab already has support for some time stamping counters -- under Acquire 
click on Timestamp instead of Phase or Frequency.


I know, but it does not really help with the given conditions.

Think of the cases where a guy just got his first TIC like HP5335A or 
HP53131A, or for that matter, one is laying around unused and can be put 
into use. I found that the PM6654C to be quite accurate for some 
measurements, even if I have better counters available.


What I try to achieve is more practical measures rather than more 
ultimate measures. Where good enough has cleared of some issues, but 
give good enough details and read-outs. I can then run my highly 
specialized rig separately.



Alternatively you can write simple tools that translate time stamp data to phase 
difference data or frequency data and then use TimeLab the way you usually do. The trick 
is to use the "Live ASCII file"input option. Also use fflush() in your C code 
(or equiv). That way you retain the real-time display feature that TimeLab provides.


Translating externally to TimeLab is certainly a possibility, but I 
propose these improvements into TimeLab as I think they are not all that 
complex and I think many will benefit from them. Giftwrapping of 
commonly reoccurring problems.


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] TimeLab

[Magnus Danielson]

Hi Tom,

On 10/10/2016 11:49 AM, Tom Van Baak wrote:

Hi Magnus, two questions for you:


I can shift the phase of the DUT intentionally, but if so I want to be
able to compensate that shift in the software. Now, such a shift should
be kept separate from the calibration factors which fills a different
purpose.


If you can shift the DUT phase, you're all set. No need for most of the most of 
the discussion going on, right? What is the frequency error or stability of the 
DUT? A 500 ms shift should provide days to years of time before you'd hit the 
TIC zero.


Go back and read my original posting as well as fairly early follow-up 
posting.


I have a locked system, I can move the phase in this case, but I need 
the assistance of the post-processing to get the zero offset values 
presented properly, and I heavily use the real-time display.


Similarly, I propose improved processing through simple shift of sign 
and phase-unwrapping focused around zero.


Notice that there can be different offsets of different origins, and one 
want to set them independently for ease of use.


For the case at hand, any through zero sample skip is a rare case but 
the negative sample skip dominates.



The trick that I then apply is to use a stop signal of higher frequency,
but who's rising edge matches that of the PPS on the PPS occurence, and
then let my DUT signal PPS be the start signal, as that will then
defined the tau-rate. With a 100 Hz signal I now have 10 ms period and
then from the last stop-time I have 990 ms for the counter to re-arm the
start-channel, and thus hide the dead-time. This is the picket fence
approach rather than having alternate counters to cover up each others
dead-time.


I've tried this. In general the picket fence method has no effect on you 
hitting the awkward region near 0 ns where the TIC waffles between - and +. In 
fact, a 100 Hz picket fence just means you will run into the TIC dead zone 100 
times more often, but the effect the dead zone will be 100x less. To me this 
suggests that 2 Hz is all that is necessary, as PHK and I have mentioned. I 
almost hesitate to call 2 Hz a picket fence.


As I said, the through-zero problems are much less of an issue.
The 100 Hz was free and available, 2 Hz or 10 Hz would also do the 
trick, so don't hang up on the frequency as it is more to illustrate the 
setup I did.



Or are we missing something? Is there some advantage to 10 Hz or 100 Hz over 2 
Hz? It seems to me they all solve the problem where the counter start/stop 
accidentally gets turned into stop/start near the 0 ns region, which leads to 
sampling every 2 seconds instead of every 1 second for a while.


As long as you have an integer multiple, you're all fine. It's really 
what is handy which is important and preferably the period should be 
shorter than the dead-time, but as long as the software can compensate 
for multiple skipped periods we don't care about that either.


Remember, I'm measuring phase and trying to measure deviation from 
"absolute phase". I want my view to be as unbiased as possible.

This is different from just trying to make stability measures.

I'm trying to illustrate the measurement challenges and then propose 
some enhancements to TimeLab that will help immensely to provide good 
values. Much of this thread ended up covering gazillions of other cases, 
including "use this counter instead".


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] TimeLab

[Tom Van Baak]

Hi Magnus, two questions for you:

> I can shift the phase of the DUT intentionally, but if so I want to be 
> able to compensate that shift in the software. Now, such a shift should 
> be kept separate from the calibration factors which fills a different 
> purpose.

If you can shift the DUT phase, you're all set. No need for most of the most of 
the discussion going on, right? What is the frequency error or stability of the 
DUT? A 500 ms shift should provide days to years of time before you'd hit the 
TIC zero.

> The trick that I then apply is to use a stop signal of higher frequency, 
> but who's rising edge matches that of the PPS on the PPS occurence, and 
> then let my DUT signal PPS be the start signal, as that will then 
> defined the tau-rate. With a 100 Hz signal I now have 10 ms period and 
> then from the last stop-time I have 990 ms for the counter to re-arm the 
> start-channel, and thus hide the dead-time. This is the picket fence 
> approach rather than having alternate counters to cover up each others 
> dead-time.

I've tried this. In general the picket fence method has no effect on you 
hitting the awkward region near 0 ns where the TIC waffles between - and +. In 
fact, a 100 Hz picket fence just means you will run into the TIC dead zone 100 
times more often, but the effect the dead zone will be 100x less. To me this 
suggests that 2 Hz is all that is necessary, as PHK and I have mentioned. I 
almost hesitate to call 2 Hz a picket fence.

Or are we missing something? Is there some advantage to 10 Hz or 100 Hz over 2 
Hz? It seems to me they all solve the problem where the counter start/stop 
accidentally gets turned into stop/start near the 0 ns region, which leads to 
sampling every 2 seconds instead of every 1 second for a while.

/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] TimeLab

[Poul-Henning Kamp]

In message <74DC70F096704AF8958028919BE7688A@pc52>, "Tom Van Baak" writes:

>The key to your dual counter proposal is the half-period delay.
>Consider these variations:

Yes, running 2Hz STOP will also work, with the footnote that you
still need to resolve the 2Hz ambiguity, which admittedly is easier.



-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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

[Tom Van Baak]

Poul-Henning,

The key to your dual counter proposal is the half-period delay. Consider these 
variations:

1) Use the GPIB "change-flank-on-the-fly" trick I mentioned yesterday. Only one 
counter is necessary. The symmetrical (50.00% duty cycle) output of the 
PPSDIV is useful here too.

2)  Use one counter with 2PPS instead of 1PPS as the stop channel REF. That way 
the TI readings will always be a number ranging from 0 to 500 ms, or depending 
on the counter, something more like -20 ns to 500ms-20ns. Regardless, the 
software that is processing the raw TI data can resolve the 0.5 s wrapping. The 
main feature is that every 1PPS from DUT gets measured. That is, you eliminate 
the case that we're all trying to avoid where the sample rate jumps from one 
per second to one per 2 seconds as you enter the region where the TI is too 
close to 0.

With a 10 MHz reference, anyone with a TADD-2 (board or mini) can set the input 
jumper from 10 MHz to 5 MHz. Then the "1PPS" output becomes 2PPS.

3) Looking at my various PICDIV I see there's a way to program a 5/10 MHz -> 
1PPS divider so that the user can step the phase of the output by, say 
+/-500.000 000 ms. So the idea is that the PC program reading the TI data from 
the counter stays content as long as the TI readings are within a range of say 
200 ms to 800 ms. If the TI values slowly drift outside that range it tells the 
PICDIV to advance or retard the divider once by exactly 0.500 000 000 s.

The beauty of this approach is that:
- you only need one counter,
- the counter may run in talk-only mode (no need for GPIB),
- the counter never operates anywhere near the TI = 0 point,
- no DUT readings are ever lost,
- your software (or TimeLab) can easily resolve the wrapping when it sees the 
500 ms phase jumps,
- the PICDIV advance/retard pins can be driven by a PC serial port DTR/RTS 
lines,
- the output of the program that gets TI readings and issues the occasional 
step commands to the PIC can output wrapped phase, or unwrapped phase, or 
timestamps as the user wishes. TimeLab accepts all three.

/tvb

- Original Message - 
From: "Poul-Henning Kamp" <p...@phk.freebsd.dk>
To: "Discussion of precise time and frequency measurement" 
<time-nuts@febo.com>; "Magnus Danielson" <mag...@rubidium.dyndns.org>
Cc: <mag...@rubidium.se>
Sent: Sunday, October 09, 2016 11:22 PM
Subject: Re: [time-nuts] TimeLab


> 
> In message <0f6c1eb7-18cb-06e3-48dd-6cd618f19...@rubidium.dyndns.org>, Magnus 
> D
> anielson writes:
> 
>>This is why the two-counter setup is so messy, you have to have software 
>>that will sync up and query them alternatively.
> 
> It is not that bad messy.
> 
> Counter A  Start=DUT, Stop=REF
> 
> Counter B  Start=DUT, Stop=REF + half period [1]
> 
> Now you know that at least one counter will always measure a DUT flank.
> 
> The crucial detail is that you also know that the counters will not
> spit out their result at the same time, so timestamping the
> measurements on the computer will definitively sort them into
> order[2].
> 
> I always run separate programs/scripts for each counter outputting
> into separate files, but that's a matter of temperatment.
> 
> You end up with a reliable sequence with three possible scenarios:
> 
> {AB}* fine...
> 
> {AB}*B{AB}*  lost one from A
> 
> {AB}*A{AB}*  lost one from B
> 
> And it is trivial to insert markers for the missing measurements.
> 
> In addition you end up with two entirely separate series of
> measurements which you can compare for sanity, and if they look
> good, you combine them and reduce your noise by sqrt(2)
> 
> Poul-Henning
> 
> [1] PPSDIV gives nice symmetrical PPS, just trigger opposite flank.
> 
> [2] Obviously: Do not use a computer running a weather model for this
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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

[Poul-Henning Kamp]

In message <0f6c1eb7-18cb-06e3-48dd-6cd618f19...@rubidium.dyndns.org>, Magnus D
anielson writes:

>This is why the two-counter setup is so messy, you have to have software 
>that will sync up and query them alternatively.

It is not that bad messy.

Counter A  Start=DUT, Stop=REF

Counter B  Start=DUT, Stop=REF + half period [1]

Now you know that at least one counter will always measure a DUT flank.

The crucial detail is that you also know that the counters will not
spit out their result at the same time, so timestamping the
measurements on the computer will definitively sort them into
order[2].

I always run separate programs/scripts for each counter outputting
into separate files, but that's a matter of temperatment.

You end up with a reliable sequence with three possible scenarios:

{AB}* fine...

{AB}*B{AB}*  lost one from A

{AB}*A{AB}*  lost one from B

And it is trivial to insert markers for the missing measurements.

In addition you end up with two entirely separate series of
measurements which you can compare for sanity, and if they look
good, you combine them and reduce your noise by sqrt(2)

Poul-Henning

[1] PPSDIV gives nice symmetrical PPS, just trigger opposite flank.

[2] Obviously: Do not use a computer running a weather model for this

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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

[Hal Murray]

t...@leapsecond.com said:
> No, not narrow pulses. Do not use the trailing edge of a 1PPS. This is more
> about 1 Hz from a stable frequency standard, not 1PPS from a noisy GPS
> receiver. 

I think we are discussing two different things.

Your setup would work if the pulse-under-test is drifting.  Mine won't.

I was trying to inquire about the stability of the pulse width.  If your 
reference pulse is known to be stable and is wide enough, you can use the 
trailing edge to stop a TIC and the normal/leading edge of your 
to-be-measured pulse to start the TIC.  That's just a hack to displace an 
edge far enough so that there is no sign reversal on the time between two 
pulses when one of them wanders around.  It doesn't require any extra gear.

Your suggestion requires a wide pulse and some software.  None of my GPSDOs 
have a wide pulse.  I assume one of your PIC options would do what is needed 
if run from the 10 MHz which my GPSDOs do put out.  (Do you have a 15 MHz 
option?)



-- 
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] TimeLab

[Tom Van Baak]

> I'd guess it would work well for narrow pulses from GPSDOs but might be 
> complicated if you are looking at a typical low cost GPS unit.

Hi Hal,

No, not narrow pulses. Do not use the trailing edge of a 1PPS. This is more 
about 1 Hz from a stable frequency standard, not 1PPS from a noisy GPS receiver.

For this scheme to work you need a 1 Hz square wave. The idea is that you have 
two different stop edges to choose from, 0.5 second apart. Or, at least the 
edges have to wider than the deadtime of the TI counter, as well as the h/w and 
s/w delays in changing trigger edge over GPIB. 900 ms and 100 ms might work; 
but 0. and 0.0001 is not helpful. 500 ms is a simple, safe bet.

It shouldn't be hard to get the rising edge and the trailing edge of a 1 Hz 
square wave equal to a couple of ns. This is especially true if the source of 
your 1PPS signal is a 10 MHz oscillator plus 10^7 square wave divider (like a 
TADD or picDIV).

If you dig deeper it could be that depending on your divider that the rising 
edge jitter is slight different than the falling edge jitter. Easy to measure 
and live with. It could also be that there is a small phase bias between the 
rising edge and the falling edge; either due to the driver, the cables, or the 
counter itself. This too can be measured. And unlike NTP, this asymmetrical 
bias could be subtracted from the raw data for that extra ns or two of accuracy.

Maybe I'm not explaining this 1 Hz either-edge method well. Let's wait until 
Magnus replies and then maybe I'll have to show you raw data to help explain 
the idea.

/tvb

- Original Message - 
From: "Hal Murray" <hmur...@megapathdsl.net>
To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com>
Cc: <hmur...@megapathdsl.net>
Sent: Sunday, October 09, 2016 3:00 PM
Subject: Re: [time-nuts] TimeLab


> 
> t...@leapsecond.com said:
>> 1) My *work-around* is to adjust the REF 1PPS by tens of microseconds, or
>> even 500 ms. That avoids running into sign changes and skipped samples when
>> a TIC gets near zero. This works really well for stable clocks where 500 ms
>> drift is next to impossible. 
> 
> How well does using the other edge of the pulse work?
> 
> I'd guess it would work well for narrow pulses from GPSDOs but might be 
> complicated if you are looking at a typical low cost GPS unit.
> 
> I have a scope with one probe on the PPS from a TBolt and another on the PPS 
> from a Sparkfun Venus board.  The start of the Venus PPS jumps around by 
> 50-200 ns p-p relative to the TBolt, but the trailing edge is solid relative 
> to the leading edge - at least at the ns level.  The infinite persistence 
> band is about 1 ns wide.  That's about the same as the leading edge, and 
> pushing things on a Rigol DS1102E.  After a longer wait, it's now 2 ns wide.  
> I'll guess that's the crystal changing temperature.  I don't see a crystal on 
> the board so I assume it's inside the big chip.  Or maybe the crystal in my 
> scope warmed up.
> 
> The Sparkfun/Venus PPS is 4 ms wide.
> 
> 
> 
> 
> Another option is to use a scope.  :)
> 
> I haven't done it, but I'm pretty sure I could grab the data and rearm the 
> scope within a second.  It's not too hard to scan the data and find a level 
> crossing point.  I'll write some sample code if anybody is interested.
> 
> 
> 
> -- 
> 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] TimeLab

[Hal Murray]

t...@leapsecond.com said:
> 1) My *work-around* is to adjust the REF 1PPS by tens of microseconds, or
> even 500 ms. That avoids running into sign changes and skipped samples when
> a TIC gets near zero. This works really well for stable clocks where 500 ms
> drift is next to impossible. 

How well does using the other edge of the pulse work?

I'd guess it would work well for narrow pulses from GPSDOs but might be 
complicated if you are looking at a typical low cost GPS unit.

I have a scope with one probe on the PPS from a TBolt and another on the PPS 
from a Sparkfun Venus board.  The start of the Venus PPS jumps around by 
50-200 ns p-p relative to the TBolt, but the trailing edge is solid relative 
to the leading edge - at least at the ns level.  The infinite persistence 
band is about 1 ns wide.  That's about the same as the leading edge, and 
pushing things on a Rigol DS1102E.  After a longer wait, it's now 2 ns wide.  
I'll guess that's the crystal changing temperature.  I don't see a crystal on 
the board so I assume it's inside the big chip.  Or maybe the crystal in my 
scope warmed up.

The Sparkfun/Venus PPS is 4 ms wide.




Another option is to use a scope.  :)

I haven't done it, but I'm pretty sure I could grab the data and rearm the 
scope within a second.  It's not too hard to scan the data and find a level 
crossing point.  I'll write some sample code if anybody is interested.



-- 
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] TimeLab

[djl]

That's easy, Magnus. Do not use a Fluke counter :-)
Don

On 2016-10-09 13:02, KA2WEU--- via time-nuts wrote:

You guys never give up, happy Sunday


In a message dated 10/9/2016 2:46:02 P.M. Eastern Daylight Time,
mag...@rubidium.se writes:

Hi,

Agree. However, one need to make sure that the counter  triggering 
never

flukes a measurement.

There is a few things  missing to make it work much much better.

Cheers,
Magnus

On  10/09/2016 08:35 PM, Bob Camp wrote:

Hi

I understand  the “keep it simple” concept, even if I rarely practice 
it

:)


 I would indeed like to get time tagging of phase measurements better

integrated with some of these
tools. The whole “was that a dropout in  the signal or a counter 
issue”

thing is rarely handled in a
very good  fashion. It also just happens to be a pretty good addition 
to

a comb  measurement system

as well.

 Bob



On Oct 9, 2016, at 1:33 PM, Magnus Danielson

<mag...@rubidium.dyndns.org> wrote:


Hi  Bob,

There is so many things that could be done  differently if we started
with a clean sheet. I was intentionally not going  down that road but 
more

thinking about practical setups with the stuff we  have, or very small
additions.


Cheers,
 Magnus

On 10/09/2016 07:26 PM, Bob Camp  wrote:

Hi



 On Oct 9, 2016, at 1:22 PM, Magnus Danielson

<mag...@rubidium.dyndns.org>  wrote:


Hi Bob and  Bob,

This is why the two-counter setup  is so messy, you have to have
software that will sync up and query them  alternatively. You also need 
to make

sure you get the counters to trigger.  Besides, another issue is that
difference in the two counters read-outs will  cause a false signal,
so calibration
and compensation becomes important to  remove that.


That’s why I believe the time  tagger + counter is the better 
solution
rather than multiple counters. Let it  give you the global information 
and
then use it to sort out what you see from  the counter. Yes, a full 
blown
multi channel time tagger with picosecond  resolution would be better 
still.

That’s going to cost more than  $5….


 Bob



Using a picket  fence type of triggering approach is cheaper and
easier to maintain. Some mild  software support for the processing and 
it will
work like a charm. Calibration  for true zero offset is needed, but 
relatively

easy to implement, you want  that anyway.


 Cheers,
Magnus

On  10/09/2016 07:02 PM, Bob Stewart wrote:

Hi  Bob,
I had actually thought about making a server for  the Prologix
Ethernet adapters, but I gave up when I considered the issue of  two 
processes
trying to claim the same device.  I've experimented with  using a C 
program to
capture multiple GPIB ports to a live file.  But, I  can't figure out 
how to
get the "live" part to work when running Timelab on a  Windows client 
in a

Virtual Box under a Linux server that is collecting the  data.  I think
Santa may have to bring me another GPIB adapter this  Christmas.


 Bob
 -
 AE6RV.com

GFS GPSDO  list:
 groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp <kb...@n1k.org>
To:  Bob Stewart <b...@evoria.net>; Discussion of precise time and

frequency  measurement <time-nuts@febo.com>

Sent: Sunday,  October 9, 2016 11:50 AM
Subject: Re: [time-nuts]  TimeLab

 Hi

On Oct 9, 2016, at  12:27 PM, Bob Stewart <b...@evoria.net>  
wrote:


Hi  Bob,
Is it actually possible to address two  devices on one GPIB 
adapter
with Timelab?  I admit to not reading the  documentation carefully, but 
I've
not been able to do this directly.  The  only way I could think of 
doing it
was to use some software to send the data  to a file and then use 
Timelab
to pull the data from the file.  Maybe NI  software allows you to 
configure

this?


That was my poorly  stated point :) … you would have to add the

ability to identify and address  multiple devices.


 Bob



 Bob
 
-

 AE6RV.com

GFS GPSDO  list:
 groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp <kb...@n1k.org>
 To: Discussion of precise time and frequency measurement

<time-nuts@febo.com>

Sent: Sunday, October  9, 2016 8:42 AM
Subject: Re: [time-nuts]  TimeLab

 Hi

Given that *some*  of us have more than errr … one counter  :)

There are several  setups that involve two or three counters to

resolve some of these issues.  Having
multiple serial ports or multiple devices  on a GPIB isn’t that 
big

a problem. Addressing multiple  devices
(setting up the addresses in TimeLab) is  an added step. Coming 
up

with standard setups would be  the
first step. Getting them documented to the  degree that they 
could

be run without a lot of hassle would  be

the next  step.

Another fairly  simple addition (rather than a full blown 
counter)

would be some sort of MCU  to time tag
the input(s). It’s a function that is  well within the 
capabilities

of a multit

Re: [time-nuts] TimeLab

[Tom Van Baak]

Hi Adrian,

> The dead zone random jumps can not be unwrapped by any software

Correct, the dead zones are real. But it is *not* true that the jumps cannot be 
unwrapped by any software. Let me explain...

When I collect data from an instrument, from thermometer to TIC, over RS-232 or 
GPIB or USB or LAN, I log the data to a file and prefix every line with a 9 
decimal place MJD timestamp. This not only allows me to know when 
(historically) the data was collected, but by subtracting timestamp pairs, it 
also tells me how long each measurement took.

For frequency measurements, this allows you to determine counter dead time. For 
time interval measurements, this allows you to immediately detect when the 
counter goes into the dreaded too-close-to-zero sample skip mode. That is, when 
start/stop acts more like stop/start resulting in one reading every 2 seconds 
instead of every 1 second.

Right, it is impossible to retroactively re-measure the lost samples -- but by 
knowing when the sample rate is 1 sps vs. 2 sps you can reconstruct a valid 
phase data stream with constant tau, even with simple 2 sample interpolation. 
The result is that this repaired/fixed data is then perfectly usable for phase 
and frequency strip charts, as well as ADEV plots, and even FFT. Without this 
fix, all these plots can behave very badly because the universal assumption of 
some fixed tau0 has been violated.

The PC MJD (or equiv) timestamp does not need to be absolutely accurate. That 
is, you don't need NTP or anything like that. Just 0.1 or 0.01 second 
resolution is all you need. So this works on any microcontroller, or computer 
running any operating system, with or without internet connection.

If you don't like MJD, even something like the old unix clock() function is 
enough to disambiguate 2 sps from 1 sps. But the key point is never just 
blindly log plain serial data and then cry later. Always time-stamp or 
time-interval it as it is being read and written to a log file.

/tvb

- Original Message - 
From: "Adrian" <rfn...@arcor.de>
To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com>
Sent: Sunday, October 09, 2016 9:34 AM
Subject: Re: [time-nuts] TimeLab


Hi Magnus,

unfortunately, you can't measure 0 delay between two signals with a counter.
With a 53131A, there is 500ps of LSB jitter and jitter from the measured
signal as well as from the reference signal.
When both signals are exactly in phase, the counter will randomly jump
between 0 and 1 second (assuming you are measuring 1pps signals).
In order to avoid this dead zone, you must add a sufficiently large
phase offset between both signals.
And, keep the acquisition time small enough to avoid phase wraps due to
drift between both sources.
The dead zone random jumps can not be unwrapped by any software.

Cheers,
Adrian

___
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

[Adrian Godwin]

On Sun, Oct 9, 2016 at 9:07 PM, Tom Van Baak  wrote:

> 3) The problems you are running into get far worse the less accurate and
> less stable the sources are (such as mains, mechanical, vintage quartz, and
> pendulum clocks). So that's why I developed the picPET time-stamping
> counter. It's 400 ns resolution is not good enough for you. Even the new 10
> ns version isn't good enough for your needs.
>
>
10ns ?
___
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

[Tom Van Baak]

> I didn't want to go into depth on counter design, a topic which I could 
> spew out much more text on, but this is not focused on the counters 
> themselves, but how we use them to get practical and useful data. I 
> would appreciate if we could stick to that topic, as I think it is a 
> relevant one. Practical obstacles and how we handle them. Here we have a 
> given counter, how do we utilize it best to get good measurements.
> Also, I could dig up many counters that may solve this or that issue, 
> but for the given situation I'm stuck with this counter.

Ok. Yes, the 53131A/53132A (and many other) counters get awkward when your 
signals get too near zero. There are issues of signs, of start / stop 
ambiguity, and missed samples due to cycle slipping. You want to avoid this. 
TimeLab cannot make up for random lost cycles, nor should hacks to that effect 
be in TimeLab, or Stable32, etc.

So here's another trick when making long-term 1PPS measurements. Start with a 
clean 50% 1 Hz signal for your REF input instead of a typical short ~10 us 1PPS 
signal. As you monitor the data, when the TI numbers start to get close to zero 
-- you simply change the trigger edge of the REF input channel. Now you are 
triggering at the half-point of the REF/PPS instead of the zero-point of the 
REF/PPS. Later on, when the TI numbers once again drift toward zero, you flip 
the trigger edge again.

This requires GPIB control of the counter, not its talk-only mode. You have a 
quarter to a half a second to send the GPIB command; very possible. When done 
right, your raw TI readings will always be in the range of, say, 0.25 s and 
0.75 s. Your phase unwrap code will handle the 0.5 second "wraps", with no loss 
of precision, no loss of samples, no loss of phase.

This effectively turns a 53131A/53132A into a TSC for ~1 Hz data. What you end 
up with is a clean set of data, with no missed samples. The occasional moments 
when the trigger edge is flipped are obvious within the data stream itself so 
your little tool that translates raw GPIB data from the TIC to clean phase or 
time-stamping data for TimeLab can handle the half second cycle slips with no 
external information. Just configure TimeLab to read Phase Difference, or 
Timestamp data, via live ASCII file, and you're all set.

/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] TimeLab

[Tom Van Baak]

Hi Magnus,

I run into this all the time. Some thoughts...

1) My *work-around* is to adjust the REF 1PPS by tens of microseconds, or even 
500 ms. That avoids running into sign changes and skipped samples when a TIC 
gets near zero. This works really well for stable clocks where 500 ms drift is 
next to impossible.

2) My *solution* is to use time-stamping counters (TSC) instead of time 
interval counters (TIC). With time-stamping you avoid all the hassles of a TIC. 
There is no worry about CH1 vs. CH2, there are no sign changes, there are no 
missed samples, it doesn't matter if the sources are fast or slow, or ahead of 
behind. There is no concept of "start" or "stop", but only "when".

For high-end TSC, I use a CNT-90 (or equiv) and for low-end I use my little 
picPET. It gets even more useful if you have multiple, synchronized time 
stamping counters.

3) The problems you are running into get far worse the less accurate and less 
stable the sources are (such as mains, mechanical, vintage quartz, and pendulum 
clocks). So that's why I developed the picPET time-stamping counter. It's 400 
ns resolution is not good enough for you. Even the new 10 ns version isn't good 
enough for your needs.

But a fellow time nut is working on a 100 ps version which will do both time 
stamping and time interval. That, finally, will solve the problems everyone has 
with TIC's. However, I still use hp 53131A/53132A a lot in my lab and simply 
avoid the TIC problem using #1 above.

4) TimeLab already has support for some time stamping counters -- under Acquire 
click on Timestamp instead of Phase or Frequency.

Alternatively you can write simple tools that translate time stamp data to 
phase difference data or frequency data and then use TimeLab the way you 
usually do. The trick is to use the "Live ASCII file"input option. Also use 
fflush() in your C code (or equiv). That way you retain the real-time display 
feature that TimeLab provides.

/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] TimeLab

[KA2WEU--- via time-nuts]

You guys never give up, happy Sunday 
 
 
In a message dated 10/9/2016 2:46:02 P.M. Eastern Daylight Time,  
mag...@rubidium.se writes:

Hi,

Agree. However, one need to make sure that the counter  triggering never 
flukes a measurement.

There is a few things  missing to make it work much much better.

Cheers,
Magnus

On  10/09/2016 08:35 PM, Bob Camp wrote:
> Hi
>
> I understand  the “keep it simple” concept, even if I rarely practice it 
:)
>
>  I would indeed like to get time tagging of phase measurements better  
integrated with some of these
> tools. The whole “was that a dropout in  the signal or a counter issue” 
thing is rarely handled in a
> very good  fashion. It also just happens to be a pretty good addition to 
a comb  measurement system
> as well.
>
>  Bob
>
>
>> On Oct 9, 2016, at 1:33 PM, Magnus Danielson  
<mag...@rubidium.dyndns.org> wrote:
>>
>> Hi  Bob,
>>
>> There is so many things that could be done  differently if we started 
with a clean sheet. I was intentionally not going  down that road but more 
thinking about practical setups with the stuff we  have, or very small 
additions.
>>
>> Cheers,
>>  Magnus
>>
>> On 10/09/2016 07:26 PM, Bob Camp  wrote:
>>> Hi
>>>
>>>
>>>>  On Oct 9, 2016, at 1:22 PM, Magnus Danielson  
<mag...@rubidium.dyndns.org>  wrote:
>>>>
>>>> Hi Bob and  Bob,
>>>>
>>>> This is why the two-counter setup  is so messy, you have to have 
software that will sync up and query them  alternatively. You also need to make 
sure you get the counters to trigger.  Besides, another issue is that 
difference in the two counters read-outs will  cause a false signal, so 
calibration 
and compensation becomes important to  remove that.
>>>
>>> That’s why I believe the time  tagger + counter is the better solution 
rather than multiple counters. Let it  give you the global information and 
then use it to sort out what you see from  the counter. Yes, a full blown 
multi channel time tagger with picosecond  resolution would be better still. 
That’s going to cost more than  $5….
>>>
>>>  Bob
>>>
>>>>
>>>> Using a picket  fence type of triggering approach is cheaper and 
easier to maintain. Some mild  software support for the processing and it will 
work like a charm. Calibration  for true zero offset is needed, but relatively 
easy to implement, you want  that anyway.
>>>>
>>>>  Cheers,
>>>> Magnus
>>>>
>>>> On  10/09/2016 07:02 PM, Bob Stewart wrote:
>>>>> Hi  Bob,
>>>>> I had actually thought about making a server for  the Prologix 
Ethernet adapters, but I gave up when I considered the issue of  two processes 
trying to claim the same device.  I've experimented with  using a C program to 
capture multiple GPIB ports to a live file.  But, I  can't figure out how to 
get the "live" part to work when running Timelab on a  Windows client in a 
Virtual Box under a Linux server that is collecting the  data.  I think 
Santa may have to bring me another GPIB adapter this  Christmas.
>>>>>
>>>>>  Bob
>>>>>  -----
>>>>>  AE6RV.com
>>>>>
>>>>> GFS GPSDO  list:
>>>>>  groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>>>>>
>>>>>   From: Bob Camp <kb...@n1k.org>
>>>>> To:  Bob Stewart <b...@evoria.net>; Discussion of precise time and 
frequency  measurement <time-nuts@febo.com>
>>>>> Sent: Sunday,  October 9, 2016 11:50 AM
>>>>> Subject: Re: [time-nuts]  TimeLab
>>>>>
>>>>>  Hi
>>>>>
>>>>>> On Oct 9, 2016, at  12:27 PM, Bob Stewart <b...@evoria.net>  wrote:
>>>>>>
>>>>>> Hi  Bob,
>>>>>> Is it actually possible to address two  devices on one GPIB adapter 
with Timelab?  I admit to not reading the  documentation carefully, but I've 
not been able to do this directly.  The  only way I could think of doing it 
was to use some software to send the data  to a file and then use Timelab 
to pull the data from the file.  Maybe NI  software allows you to configure  
this?
>>>>>
>>>>> That was my poorly  stated point :) … you would have to add the 
ability to identify and address  multiple devices.
>>>>>
>>>>>  Bob
>>>>>
>>>>>>
>>>>>>  Bob
>>>>>>  -
>>>>>>  AE6RV.com

Re: [time-nuts] TimeLab

[Magnus Danielson]

Hi,

Agree. However, one need to make sure that the counter triggering never 
flukes a measurement.


There is a few things missing to make it work much much better.

Cheers,
Magnus

On 10/09/2016 08:35 PM, Bob Camp wrote:

Hi

I understand the “keep it simple” concept, even if I rarely practice it :)

I would indeed like to get time tagging of phase measurements better integrated 
with some of these
tools. The whole “was that a dropout in the signal or a counter issue” thing is 
rarely handled in a
very good fashion. It also just happens to be a pretty good addition to a comb 
measurement system
as well.

Bob



On Oct 9, 2016, at 1:33 PM, Magnus Danielson <mag...@rubidium.dyndns.org> wrote:

Hi Bob,

There is so many things that could be done differently if we started with a 
clean sheet. I was intentionally not going down that road but more thinking 
about practical setups with the stuff we have, or very small additions.

Cheers,
Magnus

On 10/09/2016 07:26 PM, Bob Camp wrote:

Hi



On Oct 9, 2016, at 1:22 PM, Magnus Danielson <mag...@rubidium.dyndns.org> wrote:

Hi Bob and Bob,

This is why the two-counter setup is so messy, you have to have software that 
will sync up and query them alternatively. You also need to make sure you get 
the counters to trigger. Besides, another issue is that difference in the two 
counters read-outs will cause a false signal, so calibration and compensation 
becomes important to remove that.


That’s why I believe the time tagger + counter is the better solution rather 
than multiple counters. Let it give you the global information and then use it 
to sort out what you see from the counter. Yes, a full blown multi channel time 
tagger with picosecond resolution would be better still. That’s going to cost 
more than $5….

Bob



Using a picket fence type of triggering approach is cheaper and easier to 
maintain. Some mild software support for the processing and it will work like a 
charm. Calibration for true zero offset is needed, but relatively easy to 
implement, you want that anyway.

Cheers,
Magnus

On 10/09/2016 07:02 PM, Bob Stewart wrote:

Hi Bob,
I had actually thought about making a server for the Prologix Ethernet adapters, but I 
gave up when I considered the issue of two processes trying to claim the same device.  
I've experimented with using a C program to capture multiple GPIB ports to a live file.  
But, I can't figure out how to get the "live" part to work when running Timelab 
on a Windows client in a Virtual Box under a Linux server that is collecting the data.  I 
think Santa may have to bring me another GPIB adapter this Christmas.

Bob
-
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

From: Bob Camp <kb...@n1k.org>
To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com>
Sent: Sunday, October 9, 2016 11:50 AM
Subject: Re: [time-nuts] TimeLab

Hi


On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@evoria.net> wrote:

Hi Bob,
Is it actually possible to address two devices on one GPIB adapter with 
Timelab?  I admit to not reading the documentation carefully, but I've not been 
able to do this directly.  The only way I could think of doing it was to use 
some software to send the data to a file and then use Timelab to pull the data 
from the file.  Maybe NI software allows you to configure this?


That was my poorly stated point :) … you would have to add the ability to 
identify and address multiple devices.

Bob



Bob
-
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

From: Bob Camp <kb...@n1k.org>
To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
Sent: Sunday, October 9, 2016 8:42 AM
Subject: Re: [time-nuts] TimeLab

Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to resolve some of 
these issues. Having
multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up with standard 
setups would be the
first step. Getting them documented to the degree that they could be run 
without a lot of hassle would be
the next step.

Another fairly simple addition (rather than a full blown counter) would be some 
sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of a 
multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a standard 
message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
seconds count.The final data field is
a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
If there is a

Re: [time-nuts] TimeLab

[Bob Camp]

Hi

I understand the “keep it simple” concept, even if I rarely practice it :)

I would indeed like to get time tagging of phase measurements better integrated 
with some of these 
tools. The whole “was that a dropout in the signal or a counter issue” thing is 
rarely handled in a 
very good fashion. It also just happens to be a pretty good addition to a comb 
measurement system 
as well.

Bob 


> On Oct 9, 2016, at 1:33 PM, Magnus Danielson <mag...@rubidium.dyndns.org> 
> wrote:
> 
> Hi Bob,
> 
> There is so many things that could be done differently if we started with a 
> clean sheet. I was intentionally not going down that road but more thinking 
> about practical setups with the stuff we have, or very small additions.
> 
> Cheers,
> Magnus
> 
> On 10/09/2016 07:26 PM, Bob Camp wrote:
>> Hi
>> 
>> 
>>> On Oct 9, 2016, at 1:22 PM, Magnus Danielson <mag...@rubidium.dyndns.org> 
>>> wrote:
>>> 
>>> Hi Bob and Bob,
>>> 
>>> This is why the two-counter setup is so messy, you have to have software 
>>> that will sync up and query them alternatively. You also need to make sure 
>>> you get the counters to trigger. Besides, another issue is that difference 
>>> in the two counters read-outs will cause a false signal, so calibration and 
>>> compensation becomes important to remove that.
>> 
>> That’s why I believe the time tagger + counter is the better solution rather 
>> than multiple counters. Let it give you the global information and then use 
>> it to sort out what you see from the counter. Yes, a full blown multi 
>> channel time tagger with picosecond resolution would be better still. That’s 
>> going to cost more than $5….
>> 
>> Bob
>> 
>>> 
>>> Using a picket fence type of triggering approach is cheaper and easier to 
>>> maintain. Some mild software support for the processing and it will work 
>>> like a charm. Calibration for true zero offset is needed, but relatively 
>>> easy to implement, you want that anyway.
>>> 
>>> Cheers,
>>> Magnus
>>> 
>>> On 10/09/2016 07:02 PM, Bob Stewart wrote:
>>>> Hi Bob,
>>>> I had actually thought about making a server for the Prologix Ethernet 
>>>> adapters, but I gave up when I considered the issue of two processes 
>>>> trying to claim the same device.  I've experimented with using a C program 
>>>> to capture multiple GPIB ports to a live file.  But, I can't figure out 
>>>> how to get the "live" part to work when running Timelab on a Windows 
>>>> client in a Virtual Box under a Linux server that is collecting the data.  
>>>> I think Santa may have to bring me another GPIB adapter this Christmas.
>>>> 
>>>> Bob
>>>> -
>>>> AE6RV.com
>>>> 
>>>> GFS GPSDO list:
>>>> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>>>> 
>>>> From: Bob Camp <kb...@n1k.org>
>>>> To: Bob Stewart <b...@evoria.net>; Discussion of precise time and 
>>>> frequency measurement <time-nuts@febo.com>
>>>> Sent: Sunday, October 9, 2016 11:50 AM
>>>> Subject: Re: [time-nuts] TimeLab
>>>> 
>>>> Hi
>>>> 
>>>>> On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@evoria.net> wrote:
>>>>> 
>>>>> Hi Bob,
>>>>> Is it actually possible to address two devices on one GPIB adapter with 
>>>>> Timelab?  I admit to not reading the documentation carefully, but I've 
>>>>> not been able to do this directly.  The only way I could think of doing 
>>>>> it was to use some software to send the data to a file and then use 
>>>>> Timelab to pull the data from the file.  Maybe NI software allows you to 
>>>>> configure this?
>>>> 
>>>> That was my poorly stated point :) … you would have to add the ability to 
>>>> identify and address multiple devices.
>>>> 
>>>> Bob
>>>> 
>>>>> 
>>>>> Bob
>>>>> -
>>>>> AE6RV.com
>>>>> 
>>>>> GFS GPSDO list:
>>>>> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>>>>> 
>>>>> From: Bob Camp <kb...@n1k.org>
>>>>> To: Discussion of precise time and frequency measurement 
>>>>&

Re: [time-nuts] TimeLab

[Magnus Danielson]

Hi Bob,

There is so many things that could be done differently if we started 
with a clean sheet. I was intentionally not going down that road but 
more thinking about practical setups with the stuff we have, or very 
small additions.


Cheers,
Magnus

On 10/09/2016 07:26 PM, Bob Camp wrote:

Hi



On Oct 9, 2016, at 1:22 PM, Magnus Danielson <mag...@rubidium.dyndns.org> wrote:

Hi Bob and Bob,

This is why the two-counter setup is so messy, you have to have software that 
will sync up and query them alternatively. You also need to make sure you get 
the counters to trigger. Besides, another issue is that difference in the two 
counters read-outs will cause a false signal, so calibration and compensation 
becomes important to remove that.


That’s why I believe the time tagger + counter is the better solution rather 
than multiple counters. Let it give you the global information and then use it 
to sort out what you see from the counter. Yes, a full blown multi channel time 
tagger with picosecond resolution would be better still. That’s going to cost 
more than $5….

Bob



Using a picket fence type of triggering approach is cheaper and easier to 
maintain. Some mild software support for the processing and it will work like a 
charm. Calibration for true zero offset is needed, but relatively easy to 
implement, you want that anyway.

Cheers,
Magnus

On 10/09/2016 07:02 PM, Bob Stewart wrote:

Hi Bob,
I had actually thought about making a server for the Prologix Ethernet adapters, but I 
gave up when I considered the issue of two processes trying to claim the same device.  
I've experimented with using a C program to capture multiple GPIB ports to a live file.  
But, I can't figure out how to get the "live" part to work when running Timelab 
on a Windows client in a Virtual Box under a Linux server that is collecting the data.  I 
think Santa may have to bring me another GPIB adapter this Christmas.

Bob
-
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

 From: Bob Camp <kb...@n1k.org>
To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com>
Sent: Sunday, October 9, 2016 11:50 AM
Subject: Re: [time-nuts] TimeLab

Hi


On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@evoria.net> wrote:

Hi Bob,
Is it actually possible to address two devices on one GPIB adapter with 
Timelab?  I admit to not reading the documentation carefully, but I've not been 
able to do this directly.  The only way I could think of doing it was to use 
some software to send the data to a file and then use Timelab to pull the data 
from the file.  Maybe NI software allows you to configure this?


That was my poorly stated point :) … you would have to add the ability to 
identify and address multiple devices.

Bob



Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

 From: Bob Camp <kb...@n1k.org>
To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
Sent: Sunday, October 9, 2016 8:42 AM
Subject: Re: [time-nuts] TimeLab

Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to resolve some of 
these issues. Having
multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up with standard 
setups would be the
first step. Getting them documented to the degree that they could be run 
without a lot of hassle would be
the next step.

Another fairly simple addition (rather than a full blown counter) would be some 
sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of a 
multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a standard 
message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
seconds count.The final data field is
a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
If there is a next generation version that is
incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds after 
typing that definition I can see
a few problems with it. Any structural similarity to NMEA is purely 
intentional. That’s why it needs a bit of
thought and work before you standardize on it. It still would be a cheap 
solution and maybe easier to integrate
into the software than multiple counters. You do indeed have all the same setup 
and documentation issues.

In any of the above cases, the only intent of the added hardware is to get a 
number that is good to 10’s of ns.
Anything past that is great. Once you know where all the edges really are, 
sorting out the phase data becomes
mu

Re: [time-nuts] TimeLab

[Magnus Danielson]

Hi Adrian,

I know. I avoided discussing that detail in my initial postings.
For the purpose, the 500 ps resolution of the HP53131A is sufficient, or 
else I would have used another counter for the purpose.


I can shift the phase of the DUT intentionally, but if so I want to be 
able to compensate that shift in the software. Now, such a shift should 
be kept separate from the calibration factors which fills a different 
purpose.


Cheers,
Magnus

On 10/09/2016 06:34 PM, Adrian wrote:

Hi Magnus,

unfortunately, you can't measure 0 delay between two signals with a counter.
With a 53131A, there is 500ps of LSB jitter and jitter from the measured
signal as well as from the reference signal.
When both signals are exactly in phase, the counter will randomly jump
between 0 and 1 second (assuming you are measuring 1pps signals).
In order to avoid this dead zone, you must add a sufficiently large
phase offset between both signals.
And, keep the acquisition time small enough to avoid phase wraps due to
drift between both sources.
The dead zone random jumps can not be unwrapped by any software.

Cheers,
Adrian


Magnus Danielson schrieb:

Hi,

Well, yes. You can do some fancy stuff with additional hardware, but I
think with already a handful of relatively simple software fixes and
some basic setup conditions, a sufficiently robust method emerges.

I could not sign-swap the measurements in TimeLab when I tried.
I don't seem to be able to force the unwrapped phase to be +/- half
cycle.
I don't seem to be able to offset my readings. I have two sources of
offset, one is the additional delay of cables, and the other is the
offset due to wrong cycle (I hope this one can be baked into
alternative phase-unwrapping mode). I would prefer if I could hit
calibration to establish the zero-level. Typically I use a BNC barrel
and well, it does add smoe more delay

What I propose should be doable with a simple counter like 5335A,
53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal
(TADD-2 can be useful if the GPSDO does not output proper signal), you
can do the picket fence and resolve things, it is just that there is a
few things to aid in the post-processing to make values useful.

I further hint about a few things which makes easier to analyze is the
improved support for zooming.

Oh, I do care about phase variations and absolute phase measures. I do
such measures a lot. ADEV and TDEV is not all the things I measure,
especially when considering systematic effects.

Cheers,
Magnus

On 10/09/2016 03:42 PM, Bob Camp wrote:

Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to
resolve some of these issues. Having
multiple serial ports or multiple devices on a GPIB isn’t that big a
problem. Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up
with standard setups would be the
first step. Getting them documented to the degree that they could be
run without a lot of hassle would be
the next step.

Another fairly simple addition (rather than a full blown counter)
would be some sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of
a multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a
standard message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32
bit?) seconds count.The final data field is
a time in nanoseconds within the second, *two byte check sum is last,
cr/lf). If there is a next generation version that is
incompatible, the 1 after timeouts changes to a 2.) Yes, even 10
seconds after typing that definition I can see
a few problems with it. Any structural similarity to NMEA is purely
intentional. That’s why it needs a bit of
thought and work before you standardize on it. It still would be a
cheap solution and maybe easier to integrate
into the software than multiple counters. You do indeed have all the
same setup and documentation issues.

In any of the above cases, the only intent of the added hardware is
to get a number that is good to 10’s of ns.
Anything past that is great. Once you know where all the edges really
are, sorting out the phase data becomes
much easier.

Bob


On Oct 9, 2016, at 7:32 AM, Magnus Danielson
 wrote:

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out
better or if it is room for improvements. I was considering writing
this directly to John, but I gather that it might be of general
concern for many, so I thought it be a good topic for the list.

In one setup I have, I need to measure the offset of the PPS as I
upset the system under test. The counter I'm using is a HP53131A,
and I use the time-interval measure. I have a reference GPS (several
actually) which can output PPS, 10 MHz, IRIG-B004 etc. In itself
nothing strange.

In the ideal world of things, I would hook the 

Re: [time-nuts] TimeLab

[Bob Camp]

Hi


> On Oct 9, 2016, at 1:22 PM, Magnus Danielson <mag...@rubidium.dyndns.org> 
> wrote:
> 
> Hi Bob and Bob,
> 
> This is why the two-counter setup is so messy, you have to have software that 
> will sync up and query them alternatively. You also need to make sure you get 
> the counters to trigger. Besides, another issue is that difference in the two 
> counters read-outs will cause a false signal, so calibration and compensation 
> becomes important to remove that.

That’s why I believe the time tagger + counter is the better solution rather 
than multiple counters. Let it give you the global information and then use it 
to sort out what you see from the counter. Yes, a full blown multi channel time 
tagger with picosecond resolution would be better still. That’s going to cost 
more than $5….

Bob

> 
> Using a picket fence type of triggering approach is cheaper and easier to 
> maintain. Some mild software support for the processing and it will work like 
> a charm. Calibration for true zero offset is needed, but relatively easy to 
> implement, you want that anyway.
> 
> Cheers,
> Magnus
> 
> On 10/09/2016 07:02 PM, Bob Stewart wrote:
>> Hi Bob,
>> I had actually thought about making a server for the Prologix Ethernet 
>> adapters, but I gave up when I considered the issue of two processes trying 
>> to claim the same device.  I've experimented with using a C program to 
>> capture multiple GPIB ports to a live file.  But, I can't figure out how to 
>> get the "live" part to work when running Timelab on a Windows client in a 
>> Virtual Box under a Linux server that is collecting the data.  I think Santa 
>> may have to bring me another GPIB adapter this Christmas.
>> 
>> Bob
>> -
>> AE6RV.com
>> 
>> GFS GPSDO list:
>> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>> 
>>  From: Bob Camp <kb...@n1k.org>
>> To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
>> measurement <time-nuts@febo.com>
>> Sent: Sunday, October 9, 2016 11:50 AM
>> Subject: Re: [time-nuts] TimeLab
>> 
>> Hi
>> 
>>> On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@evoria.net> wrote:
>>> 
>>> Hi Bob,
>>> Is it actually possible to address two devices on one GPIB adapter with 
>>> Timelab?  I admit to not reading the documentation carefully, but I've not 
>>> been able to do this directly.  The only way I could think of doing it was 
>>> to use some software to send the data to a file and then use Timelab to 
>>> pull the data from the file.  Maybe NI software allows you to configure 
>>> this?
>> 
>> That was my poorly stated point :) … you would have to add the ability to 
>> identify and address multiple devices.
>> 
>> Bob
>> 
>>> 
>>> Bob
>>>  -
>>> AE6RV.com
>>> 
>>> GFS GPSDO list:
>>> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>>> 
>>>  From: Bob Camp <kb...@n1k.org>
>>> To: Discussion of precise time and frequency measurement 
>>> <time-nuts@febo.com>
>>> Sent: Sunday, October 9, 2016 8:42 AM
>>> Subject: Re: [time-nuts] TimeLab
>>> 
>>> Hi
>>> 
>>> Given that *some* of us have more than errr … one counter :)
>>> 
>>> There are several setups that involve two or three counters to resolve some 
>>> of these issues. Having
>>> multiple serial ports or multiple devices on a GPIB isn’t that big a 
>>> problem. Addressing multiple devices
>>> (setting up the addresses in TimeLab) is an added step. Coming up with 
>>> standard setups would be the
>>> first step. Getting them documented to the degree that they could be run 
>>> without a lot of hassle would be
>>> the next step.
>>> 
>>> Another fairly simple addition (rather than a full blown counter) would be 
>>> some sort of MCU to time tag
>>> the input(s). It’s a function that is well within the capabilities of a 
>>> multitude of cheap demo cards. Rather than
>>> defining a specific card, it is probably better to just define a standard 
>>> message (115200 K baud, 8N1, starts
>>> with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
>>> seconds count.The final data field is
>>> a time in nanoseconds within the second, *two byte check sum is last, 
>>> cr/lf). If there is a next generatio

Re: [time-nuts] TimeLab

[Magnus Danielson]

Hi Bob and Bob,

This is why the two-counter setup is so messy, you have to have software 
that will sync up and query them alternatively. You also need to make 
sure you get the counters to trigger. Besides, another issue is that 
difference in the two counters read-outs will cause a false signal, so 
calibration and compensation becomes important to remove that.


Using a picket fence type of triggering approach is cheaper and easier 
to maintain. Some mild software support for the processing and it will 
work like a charm. Calibration for true zero offset is needed, but 
relatively easy to implement, you want that anyway.


Cheers,
Magnus

On 10/09/2016 07:02 PM, Bob Stewart wrote:

Hi Bob,
I had actually thought about making a server for the Prologix Ethernet adapters, but I 
gave up when I considered the issue of two processes trying to claim the same device.  
I've experimented with using a C program to capture multiple GPIB ports to a live file.  
But, I can't figure out how to get the "live" part to work when running Timelab 
on a Windows client in a Virtual Box under a Linux server that is collecting the data.  I 
think Santa may have to bring me another GPIB adapter this Christmas.

Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp <kb...@n1k.org>
 To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com>
 Sent: Sunday, October 9, 2016 11:50 AM
 Subject: Re: [time-nuts] TimeLab

Hi


On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@evoria.net> wrote:

Hi Bob,
Is it actually possible to address two devices on one GPIB adapter with 
Timelab?  I admit to not reading the documentation carefully, but I've not been 
able to do this directly.  The only way I could think of doing it was to use 
some software to send the data to a file and then use Timelab to pull the data 
from the file.  Maybe NI software allows you to configure this?


That was my poorly stated point :) … you would have to add the ability to 
identify and address multiple devices.

Bob



Bob
  -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp <kb...@n1k.org>
To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
Sent: Sunday, October 9, 2016 8:42 AM
Subject: Re: [time-nuts] TimeLab

Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to resolve some of 
these issues. Having
multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up with standard 
setups would be the
first step. Getting them documented to the degree that they could be run 
without a lot of hassle would be
the next step.

Another fairly simple addition (rather than a full blown counter) would be some 
sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of a 
multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a standard 
message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
seconds count.The final data field is
a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
If there is a next generation version that is
incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds after 
typing that definition I can see
a few problems with it. Any structural similarity to NMEA is purely 
intentional. That’s why it needs a bit of
thought and work before you standardize on it. It still would be a cheap 
solution and maybe easier to integrate
into the software than multiple counters. You do indeed have all the same setup 
and documentation issues.

In any of the above cases, the only intent of the added hardware is to get a 
number that is good to 10’s of ns.
Anything past that is great. Once you know where all the edges really are, 
sorting out the phase data becomes
much easier.

Bob


On Oct 9, 2016, at 7:32 AM, Magnus Danielson <mag...@rubidium.dyndns.org> wrote:

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out better or if it 
is room for improvements. I was considering writing this directly to John, but 
I gather that it might be of general concern for many, so I thought it be a 
good topic for the list.

In one setup I have, I need to measure the offset of the PPS as I upset the 
system under test. The counter I'm using is a HP53131A, and I use the 
time-interval measure. I have a reference GPS (several actually) which can 
output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.

In the ideal world of things, I would hook t

Re: [time-nuts] TimeLab

[Scott Stobbe]

FWIW, I have only tried timelab reading a live ascii log file.

On Sunday, 9 October 2016, Magnus Danielson <mag...@rubidium.dyndns.org>
wrote:

> Which removes the real-time processing benefit of using TimeLab in the
> first place.
>
> What I propose is not too complex to do.
>
> Cheers,
> Magnus
>
> On 10/09/2016 06:19 PM, Bob Stewart wrote:
>
>> Don't forget the possibility of saving the data to a file and
>> pre-processing the file before sending it to Timelab.
>> Bob
>>  -
>> AE6RV.com
>>
>> GFS GPSDO list:
>> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
>>
>>   From: Magnus Danielson <mag...@rubidium.dyndns.org>
>>  To: time-nuts@febo.com
>> Cc: mag...@rubidium.se
>>  Sent: Sunday, October 9, 2016 10:48 AM
>>  Subject: Re: [time-nuts] TimeLab
>>
>> Hi,
>>
>> Well, yes. You can do some fancy stuff with additional hardware, but I
>> think with already a handful of relatively simple software fixes and
>> some basic setup conditions, a sufficiently robust method emerges.
>>
>> I could not sign-swap the measurements in TimeLab when I tried.
>> I don't seem to be able to force the unwrapped phase to be +/- half cycle.
>> I don't seem to be able to offset my readings. I have two sources of
>> offset, one is the additional delay of cables, and the other is the
>> offset due to wrong cycle (I hope this one can be baked into alternative
>> phase-unwrapping mode). I would prefer if I could hit calibration to
>> establish the zero-level. Typically I use a BNC barrel and well, it does
>> add smoe more delay
>>
>> What I propose should be doable with a simple counter like 5335A,
>> 53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal
>> (TADD-2 can be useful if the GPSDO does not output proper signal), you
>> can do the picket fence and resolve things, it is just that there is a
>> few things to aid in the post-processing to make values useful.
>>
>> I further hint about a few things which makes easier to analyze is the
>> improved support for zooming.
>>
>> Oh, I do care about phase variations and absolute phase measures. I do
>> such measures a lot. ADEV and TDEV is not all the things I measure,
>> especially when considering systematic effects.
>>
>> Cheers,
>> Magnus
>>
>> On 10/09/2016 03:42 PM, Bob Camp wrote:
>>
>>> Hi
>>>
>>> Given that *some* of us have more than errr … one counter :)
>>>
>>> There are several setups that involve two or three counters to resolve
>>> some of these issues. Having
>>> multiple serial ports or multiple devices on a GPIB isn’t that big a
>>> problem. Addressing multiple devices
>>> (setting up the addresses in TimeLab) is an added step. Coming up with
>>> standard setups would be the
>>> first step. Getting them documented to the degree that they could be run
>>> without a lot of hassle would be
>>> the next step.
>>>
>>> Another fairly simple addition (rather than a full blown counter) would
>>> be some sort of MCU to time tag
>>> the input(s). It’s a function that is well within the capabilities of a
>>> multitude of cheap demo cards. Rather than
>>> defining a specific card, it is probably better to just define a
>>> standard message (115200 K baud, 8N1, starts
>>> with “$timenuts$,1,”, next is the channel number, after that the (32
>>> bit?) seconds count.The final data field is
>>> a time in nanoseconds within the second, *two byte check sum is last,
>>> cr/lf). If there is a next generation version that is
>>> incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds
>>> after typing that definition I can see
>>> a few problems with it. Any structural similarity to NMEA is purely
>>> intentional. That’s why it needs a bit of
>>> thought and work before you standardize on it. It still would be a cheap
>>> solution and maybe easier to integrate
>>> into the software than multiple counters. You do indeed have all the
>>> same setup and documentation issues.
>>>
>>> In any of the above cases, the only intent of the added hardware is to
>>> get a number that is good to 10’s of ns.
>>> Anything past that is great. Once you know where all the edges really
>>> are, sorting out the phase data becomes
>>> much easier.
>>>
>>> Bob
>>>
>>> On Oct 9, 2016, at 7:32 AM, Magnus Danielson <m

Re: [time-nuts] TimeLab

[Adrian]

Hi Magnus,

unfortunately, you can't measure 0 delay between two signals with a counter.
With a 53131A, there is 500ps of LSB jitter and jitter from the measured
signal as well as from the reference signal.
When both signals are exactly in phase, the counter will randomly jump
between 0 and 1 second (assuming you are measuring 1pps signals).
In order to avoid this dead zone, you must add a sufficiently large
phase offset between both signals.
And, keep the acquisition time small enough to avoid phase wraps due to
drift between both sources.
The dead zone random jumps can not be unwrapped by any software.

Cheers,
Adrian


Magnus Danielson schrieb:
> Hi,
>
> Well, yes. You can do some fancy stuff with additional hardware, but I
> think with already a handful of relatively simple software fixes and
> some basic setup conditions, a sufficiently robust method emerges.
>
> I could not sign-swap the measurements in TimeLab when I tried.
> I don't seem to be able to force the unwrapped phase to be +/- half
> cycle.
> I don't seem to be able to offset my readings. I have two sources of
> offset, one is the additional delay of cables, and the other is the
> offset due to wrong cycle (I hope this one can be baked into
> alternative phase-unwrapping mode). I would prefer if I could hit
> calibration to establish the zero-level. Typically I use a BNC barrel
> and well, it does add smoe more delay
>
> What I propose should be doable with a simple counter like 5335A,
> 53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal
> (TADD-2 can be useful if the GPSDO does not output proper signal), you
> can do the picket fence and resolve things, it is just that there is a
> few things to aid in the post-processing to make values useful.
>
> I further hint about a few things which makes easier to analyze is the
> improved support for zooming.
>
> Oh, I do care about phase variations and absolute phase measures. I do
> such measures a lot. ADEV and TDEV is not all the things I measure,
> especially when considering systematic effects.
>
> Cheers,
> Magnus
>
> On 10/09/2016 03:42 PM, Bob Camp wrote:
>> Hi
>>
>> Given that *some* of us have more than errr … one counter :)
>>
>> There are several setups that involve two or three counters to
>> resolve some of these issues. Having
>> multiple serial ports or multiple devices on a GPIB isn’t that big a
>> problem. Addressing multiple devices
>> (setting up the addresses in TimeLab) is an added step. Coming up
>> with standard setups would be the
>> first step. Getting them documented to the degree that they could be
>> run without a lot of hassle would be
>> the next step.
>>
>> Another fairly simple addition (rather than a full blown counter)
>> would be some sort of MCU to time tag
>> the input(s). It’s a function that is well within the capabilities of
>> a multitude of cheap demo cards. Rather than
>> defining a specific card, it is probably better to just define a
>> standard message (115200 K baud, 8N1, starts
>> with “$timenuts$,1,”, next is the channel number, after that the (32
>> bit?) seconds count.The final data field is
>> a time in nanoseconds within the second, *two byte check sum is last,
>> cr/lf). If there is a next generation version that is
>> incompatible, the 1 after timeouts changes to a 2.) Yes, even 10
>> seconds after typing that definition I can see
>> a few problems with it. Any structural similarity to NMEA is purely
>> intentional. That’s why it needs a bit of
>> thought and work before you standardize on it. It still would be a
>> cheap solution and maybe easier to integrate
>> into the software than multiple counters. You do indeed have all the
>> same setup and documentation issues.
>>
>> In any of the above cases, the only intent of the added hardware is
>> to get a number that is good to 10’s of ns.
>> Anything past that is great. Once you know where all the edges really
>> are, sorting out the phase data becomes
>> much easier.
>>
>> Bob
>>
>>> On Oct 9, 2016, at 7:32 AM, Magnus Danielson
>>>  wrote:
>>>
>>> Fellow time-nuts,
>>>
>>> I don't know if it is me who is lazy to not figure TimeLab out
>>> better or if it is room for improvements. I was considering writing
>>> this directly to John, but I gather that it might be of general
>>> concern for many, so I thought it be a good topic for the list.
>>>
>>> In one setup I have, I need to measure the offset of the PPS as I
>>> upset the system under test. The counter I'm using is a HP53131A,
>>> and I use the time-interval measure. I have a reference GPS (several
>>> actually) which can output PPS, 10 MHz, IRIG-B004 etc. In itself
>>> nothing strange.
>>>
>>> In the ideal world of things, I would hook the DUT PPS to the Start
>>> (Ch1) and the reference PPS to the Stop (Ch2) channels. This would
>>> give me the propper Time Error (DUT - Ref) so a positive number
>>> tells me the DUT is ahead of the reference and a negative number
>>> tells me that the DUT 

Re: [time-nuts] TimeLab

[Bob Stewart]

Hi Bob,
I had actually thought about making a server for the Prologix Ethernet 
adapters, but I gave up when I considered the issue of two processes trying to 
claim the same device.  I've experimented with using a C program to capture 
multiple GPIB ports to a live file.  But, I can't figure out how to get the 
"live" part to work when running Timelab on a Windows client in a Virtual Box 
under a Linux server that is collecting the data.  I think Santa may have to 
bring me another GPIB adapter this Christmas.

Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp <kb...@n1k.org>
 To: Bob Stewart <b...@evoria.net>; Discussion of precise time and frequency 
measurement <time-nuts@febo.com> 
 Sent: Sunday, October 9, 2016 11:50 AM
 Subject: Re: [time-nuts] TimeLab
   
Hi

> On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@evoria.net> wrote:
> 
> Hi Bob,
> Is it actually possible to address two devices on one GPIB adapter with 
> Timelab?  I admit to not reading the documentation carefully, but I've not 
> been able to do this directly.  The only way I could think of doing it was to 
> use some software to send the data to a file and then use Timelab to pull the 
> data from the file.  Maybe NI software allows you to configure this?

That was my poorly stated point :) … you would have to add the ability to 
identify and address multiple devices.

Bob

> 
> Bob
>  -
> AE6RV.com
> 
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
> 
>      From: Bob Camp <kb...@n1k.org>
> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
> Sent: Sunday, October 9, 2016 8:42 AM
> Subject: Re: [time-nuts] TimeLab
> 
> Hi
> 
> Given that *some* of us have more than errr … one counter :)
> 
> There are several setups that involve two or three counters to resolve some 
> of these issues. Having 
> multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
> Addressing multiple devices
> (setting up the addresses in TimeLab) is an added step. Coming up with 
> standard setups would be the 
> first step. Getting them documented to the degree that they could be run 
> without a lot of hassle would be
> the next step. 
> 
> Another fairly simple addition (rather than a full blown counter) would be 
> some sort of MCU to time tag
> the input(s). It’s a function that is well within the capabilities of a 
> multitude of cheap demo cards. Rather than
> defining a specific card, it is probably better to just define a standard 
> message (115200 K baud, 8N1, starts
> with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
> seconds count.The final data field is 
> a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
> If there is a next generation version that is 
> incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds 
> after typing that definition I can see
> a few problems with it. Any structural similarity to NMEA is purely 
> intentional. That’s why it needs a bit of 
> thought and work before you standardize on it. It still would be a cheap 
> solution and maybe easier to integrate 
> into the software than multiple counters. You do indeed have all the same 
> setup and documentation issues. 
> 
> In any of the above cases, the only intent of the added hardware is to get a 
> number that is good to 10’s of ns. 
> Anything past that is great. Once you know where all the edges really are, 
> sorting out the phase data becomes
> much easier. 
> 
> Bob
> 
>> On Oct 9, 2016, at 7:32 AM, Magnus Danielson <mag...@rubidium.dyndns.org> 
>> wrote:
>> 
>> Fellow time-nuts,
>> 
>> I don't know if it is me who is lazy to not figure TimeLab out better or if 
>> it is room for improvements. I was considering writing this directly to 
>> John, but I gather that it might be of general concern for many, so I 
>> thought it be a good topic for the list.
>> 
>> In one setup I have, I need to measure the offset of the PPS as I upset the 
>> system under test. The counter I'm using is a HP53131A, and I use the 
>> time-interval measure. I have a reference GPS (several actually) which can 
>> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
>> 
>> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1) 
>> and the reference PPS to the Stop (Ch2) channels. This would give me the 
>> propper Time Error (DUT - Ref) so a positive number tells me the DUT is 
>> ahead of the referen

Re: [time-nuts] TimeLab

[Bob Camp]

Hi

> On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@evoria.net> wrote:
> 
> Hi Bob,
> Is it actually possible to address two devices on one GPIB adapter with 
> Timelab?  I admit to not reading the documentation carefully, but I've not 
> been able to do this directly.  The only way I could think of doing it was to 
> use some software to send the data to a file and then use Timelab to pull the 
> data from the file.  Maybe NI software allows you to configure this?

That was my poorly stated point :) … you would have to add the ability to 
identify and address multiple devices.

Bob

> 
> Bob
>  -
> AE6RV.com
> 
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
> 
>  From: Bob Camp <kb...@n1k.org>
> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
> Sent: Sunday, October 9, 2016 8:42 AM
> Subject: Re: [time-nuts] TimeLab
> 
> Hi
> 
> Given that *some* of us have more than errr … one counter :)
> 
> There are several setups that involve two or three counters to resolve some 
> of these issues. Having 
> multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
> Addressing multiple devices
> (setting up the addresses in TimeLab) is an added step. Coming up with 
> standard setups would be the 
> first step. Getting them documented to the degree that they could be run 
> without a lot of hassle would be
> the next step. 
> 
> Another fairly simple addition (rather than a full blown counter) would be 
> some sort of MCU to time tag
> the input(s). It’s a function that is well within the capabilities of a 
> multitude of cheap demo cards. Rather than
> defining a specific card, it is probably better to just define a standard 
> message (115200 K baud, 8N1, starts
> with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
> seconds count.The final data field is 
> a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
> If there is a next generation version that is 
> incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds 
> after typing that definition I can see
> a few problems with it. Any structural similarity to NMEA is purely 
> intentional. That’s why it needs a bit of 
> thought and work before you standardize on it. It still would be a cheap 
> solution and maybe easier to integrate 
> into the software than multiple counters. You do indeed have all the same 
> setup and documentation issues. 
> 
> In any of the above cases, the only intent of the added hardware is to get a 
> number that is good to 10’s of ns. 
> Anything past that is great. Once you know where all the edges really are, 
> sorting out the phase data becomes
> much easier. 
> 
> Bob
> 
>> On Oct 9, 2016, at 7:32 AM, Magnus Danielson <mag...@rubidium.dyndns.org> 
>> wrote:
>> 
>> Fellow time-nuts,
>> 
>> I don't know if it is me who is lazy to not figure TimeLab out better or if 
>> it is room for improvements. I was considering writing this directly to 
>> John, but I gather that it might be of general concern for many, so I 
>> thought it be a good topic for the list.
>> 
>> In one setup I have, I need to measure the offset of the PPS as I upset the 
>> system under test. The counter I'm using is a HP53131A, and I use the 
>> time-interval measure. I have a reference GPS (several actually) which can 
>> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
>> 
>> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1) 
>> and the reference PPS to the Stop (Ch2) channels. This would give me the 
>> propper Time Error (DUT - Ref) so a positive number tells me the DUT is 
>> ahead of the reference and a negative number tells me that the DUT is behind 
>> the reference.
>> 
>> Now, as I do that, depending on their relative timing I might skip samples, 
>> since the counter expects trigger conditions. While TimeLab can correct for 
>> the period offset, it can't reproduce missed samples.
>> I always get suspicious when the time in the program and the time in real 
>> world does not match up.
>> 
>> I could intentionally shift the PPS output of my DUT to any suitable number, 
>> which would be one way to solve this, if I would tell TimeLab to withdraw 
>> say 100 ms. I might want to do that easily afterhand rather than in the 
>> setup window.
>> 
>> To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with 
>> a stable rising edge aligned to the PPS to within about 2 ns. Good enough 
>> f

Re: [time-nuts] TimeLab

[Bob Stewart]

Hi Bob,
Is it actually possible to address two devices on one GPIB adapter with 
Timelab?  I admit to not reading the documentation carefully, but I've not been 
able to do this directly.  The only way I could think of doing it was to use 
some software to send the data to a file and then use Timelab to pull the data 
from the file.  Maybe NI software allows you to configure this?

Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp <kb...@n1k.org>
 To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
 Sent: Sunday, October 9, 2016 8:42 AM
 Subject: Re: [time-nuts] TimeLab
   
Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to resolve some of 
these issues. Having 
multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up with standard 
setups would be the 
first step. Getting them documented to the degree that they could be run 
without a lot of hassle would be
the next step. 

Another fairly simple addition (rather than a full blown counter) would be some 
sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of a 
multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a standard 
message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
seconds count.The final data field is 
a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
If there is a next generation version that is 
incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds after 
typing that definition I can see
a few problems with it. Any structural similarity to NMEA is purely 
intentional. That’s why it needs a bit of 
thought and work before you standardize on it. It still would be a cheap 
solution and maybe easier to integrate 
into the software than multiple counters. You do indeed have all the same setup 
and documentation issues. 

In any of the above cases, the only intent of the added hardware is to get a 
number that is good to 10’s of ns. 
Anything past that is great. Once you know where all the edges really are, 
sorting out the phase data becomes
much easier. 

Bob

> On Oct 9, 2016, at 7:32 AM, Magnus Danielson <mag...@rubidium.dyndns.org> 
> wrote:
> 
> Fellow time-nuts,
> 
> I don't know if it is me who is lazy to not figure TimeLab out better or if 
> it is room for improvements. I was considering writing this directly to John, 
> but I gather that it might be of general concern for many, so I thought it be 
> a good topic for the list.
> 
> In one setup I have, I need to measure the offset of the PPS as I upset the 
> system under test. The counter I'm using is a HP53131A, and I use the 
> time-interval measure. I have a reference GPS (several actually) which can 
> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
> 
> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1) and 
> the reference PPS to the Stop (Ch2) channels. This would give me the propper 
> Time Error (DUT - Ref) so a positive number tells me the DUT is ahead of the 
> reference and a negative number tells me that the DUT is behind the reference.
> 
> Now, as I do that, depending on their relative timing I might skip samples, 
> since the counter expects trigger conditions. While TimeLab can correct for 
> the period offset, it can't reproduce missed samples.
> I always get suspicious when the time in the program and the time in real 
> world does not match up.
> 
> I could intentionally shift the PPS output of my DUT to any suitable number, 
> which would be one way to solve this, if I would tell TimeLab to withdraw say 
> 100 ms. I might want to do that easily afterhand rather than in the setup 
> window.
> 
> To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with a 
> stable rising edge aligned to the PPS to within about 2 ns. Good enough for 
> my purpose. However, for the trigger to only produce meaningful results, I 
> will need to swap inputs, so that the PPS from DUT is on Start/Ch1 and the 
> IRIG-B is on Stop/Ch2. This way I get my triggers right. However, my readings 
> have opposite sign. I might have forgotten about the way to correct for it.
> 
> However, TimeLab seems unable to unwrap the phase properly, so if I have the 
> condition where I would get a negative value of say -100 ns then the counter 
> will measure 9,999,900 ns, so I have to force a positive value as I start the 
> measurement and then have it trace into the negative. I would ve

Re: [time-nuts] TimeLab

[Magnus Danielson]

Which removes the real-time processing benefit of using TimeLab in the 
first place.


What I propose is not too complex to do.

Cheers,
Magnus

On 10/09/2016 06:19 PM, Bob Stewart wrote:

Don't forget the possibility of saving the data to a file and pre-processing 
the file before sending it to Timelab.
Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Magnus Danielson <mag...@rubidium.dyndns.org>
 To: time-nuts@febo.com
Cc: mag...@rubidium.se
 Sent: Sunday, October 9, 2016 10:48 AM
 Subject: Re: [time-nuts] TimeLab

Hi,

Well, yes. You can do some fancy stuff with additional hardware, but I
think with already a handful of relatively simple software fixes and
some basic setup conditions, a sufficiently robust method emerges.

I could not sign-swap the measurements in TimeLab when I tried.
I don't seem to be able to force the unwrapped phase to be +/- half cycle.
I don't seem to be able to offset my readings. I have two sources of
offset, one is the additional delay of cables, and the other is the
offset due to wrong cycle (I hope this one can be baked into alternative
phase-unwrapping mode). I would prefer if I could hit calibration to
establish the zero-level. Typically I use a BNC barrel and well, it does
add smoe more delay

What I propose should be doable with a simple counter like 5335A,
53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal
(TADD-2 can be useful if the GPSDO does not output proper signal), you
can do the picket fence and resolve things, it is just that there is a
few things to aid in the post-processing to make values useful.

I further hint about a few things which makes easier to analyze is the
improved support for zooming.

Oh, I do care about phase variations and absolute phase measures. I do
such measures a lot. ADEV and TDEV is not all the things I measure,
especially when considering systematic effects.

Cheers,
Magnus

On 10/09/2016 03:42 PM, Bob Camp wrote:

Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to resolve some of 
these issues. Having
multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up with standard 
setups would be the
first step. Getting them documented to the degree that they could be run 
without a lot of hassle would be
the next step.

Another fairly simple addition (rather than a full blown counter) would be some 
sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of a 
multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a standard 
message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
seconds count.The final data field is
a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
If there is a next generation version that is
incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds after 
typing that definition I can see
a few problems with it. Any structural similarity to NMEA is purely 
intentional. That’s why it needs a bit of
thought and work before you standardize on it. It still would be a cheap 
solution and maybe easier to integrate
into the software than multiple counters. You do indeed have all the same setup 
and documentation issues.

In any of the above cases, the only intent of the added hardware is to get a 
number that is good to 10’s of ns.
Anything past that is great. Once you know where all the edges really are, 
sorting out the phase data becomes
much easier.

Bob


On Oct 9, 2016, at 7:32 AM, Magnus Danielson <mag...@rubidium.dyndns.org> wrote:

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out better or if it 
is room for improvements. I was considering writing this directly to John, but 
I gather that it might be of general concern for many, so I thought it be a 
good topic for the list.

In one setup I have, I need to measure the offset of the PPS as I upset the 
system under test. The counter I'm using is a HP53131A, and I use the 
time-interval measure. I have a reference GPS (several actually) which can 
output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.

In the ideal world of things, I would hook the DUT PPS to the Start (Ch1) and 
the reference PPS to the Stop (Ch2) channels. This would give me the propper 
Time Error (DUT - Ref) so a positive number tells me the DUT is ahead of the 
reference and a negative number tells me that the DUT is behind the reference.

Now, as I do that, depending on their relative timing I might skip samples, 
since the counter expects trigger conditions. While TimeLab can correct for the 
period offset, it can't reproduce missed samples.
I always ge

Re: [time-nuts] TimeLab

[Magnus Danielson]

Hi Alex,

It all comes down to arming of counters, and how that behaves in the 
time-interval case. I've done a long post on this before, so here is the 
quick explanation:


For a time-interval counter you measure the elapsed time from the start 
trigger to the stop trigger. This means that the stop trigger can only 
be armed for triggering after the start-trigger, and vice versa naturally.


Consider two PPS signals, let's say that the start trigger signal occurs 
and 100 ns later the stop trigger occurs. Great, so for each PPS event 
we get a single read-out. The start triggers, the stop is armed and then 
100 ns later triggers, arming the start trigger again. For each PPS 
event 100 ns elapses from the start to the stop.


Now, consider what happens when the start signal (our DUT) for some 
reason drifts so it occurs 100 ns after the stop signal (our reference). 
As the start signal occurs, it arms the stop channel, but it takes 
900 ns before the stop signal occurs, and then that arms the start 
signal, which happens 100 ns later. However, the trouble is if the time 
difference is smaller, then there is no time to arm the start channel 
again, and you miss the event, and now it takes 1000100 ns for the 
trigger. In that situation you miss out on the measurement and is only 
achieving 2 s tau measures rather than 1 s tau measures.


Why would the counter not be able to re-arm the start channel again?
Well, most counters have actually a third state in there, in which after 
the stop channel it actually triggers the processor to grab the 
measurement from the hardware, do the calculations update the display 
and output it over GPIB and only after that arm the start channel again. 
During that time it can't make another measurement and is hence called 
the dead-time. The dead-time can be several ms.


The trick that I then apply is to use a stop signal of higher frequency, 
but who's rising edge matches that of the PPS on the PPS occurence, and 
then let my DUT signal PPS be the start signal, as that will then 
defined the tau-rate. With a 100 Hz signal I now have 10 ms period and 
then from the last stop-time I have 990 ms for the counter to re-arm the 
start-channel, and thus hide the dead-time. This is the picket fence 
approach rather than having alternate counters to cover up each others 
dead-time.


As I move between positive and negative offset, I maintain the 1 sample 
per second readout rate that I want. However, I need my phase-wrapping 
to support me and I also need to reverse the values of my read-outs for 
them to have the same meaning.


Cheers,
Magnus

On 10/09/2016 06:01 PM, Alexander Pummer wrote:

Hello Magnus,

I am a totally unerducated time nut better, to say; not time nut, just
an old RF ingenieur,  and so I have trouble to understand how could a
counter stop to count before it started to count. I case you would have
a circuit, which would tell you which pulse came at first and start the
counter regardless of which of the two pulse came first and the same way
stop the counter regardless pulse came last, you could count out the
time difference with the interval counter independently from the
sequence the pulses,

Or you could use two counters and reverse the inputs at the second
counter, thus one counter would show the positive error and the other
the negative error.

73
KJ6UHN
Alex



On 10/9/2016 4:32 AM, Magnus Danielson wrote:

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out better
or if it is room for improvements. I was considering writing this
directly to John, but I gather that it might be of general concern for
many, so I thought it be a good topic for the list.

In one setup I have, I need to measure the offset of the PPS as I
upset the system under test. The counter I'm using is a HP53131A, and
I use the time-interval measure. I have a reference GPS (several
actually) which can output PPS, 10 MHz, IRIG-B004 etc. In itself
nothing strange.

In the ideal world of things, I would hook the DUT PPS to the Start
(Ch1) and the reference PPS to the Stop (Ch2) channels. This would
give me the propper Time Error (DUT - Ref) so a positive number tells
me the DUT is ahead of the reference and a negative number tells me
that the DUT is behind the reference.

Now, as I do that, depending on their relative timing I might skip
samples, since the counter expects trigger conditions. While TimeLab
can correct for the period offset, it can't reproduce missed samples.
I always get suspicious when the time in the program and the time in
real world does not match up.

I could intentionally shift the PPS output of my DUT to any suitable
number, which would be one way to solve this, if I would tell TimeLab
to withdraw say 100 ms. I might want to do that easily afterhand
rather than in the setup window.

To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal
with a stable rising edge aligned to the PPS to within about 2 ns.
Good enough for my 

Re: [time-nuts] TimeLab

[Bob Camp]

Hi

At least from what I have seen from a limited selection of counter models, no 
two models quite behave the same way. 
In some cases early firmware on a given model works different than late 
firmware or the A version is a bit different than the B. 
A solution that seems to work for one gets into a weird corner case on another. 
By tagging the data, you have a
“universal” solution that takes care of all the counters, no matter how weird 
they happen to behave. 

I’m in no way claiming that the software is prefect. My real point is that you 
will quickly hit the strangeness of the counters and
that a time tag approach will take care of a whole bunch of things at once. If 
we are going to put in a “want list”, I think it’s well
worth considering. 

Bob


> On Oct 9, 2016, at 11:48 AM, Magnus Danielson  
> wrote:
> 
> Hi,
> 
> Well, yes. You can do some fancy stuff with additional hardware, but I think 
> with already a handful of relatively simple software fixes and some basic 
> setup conditions, a sufficiently robust method emerges.
> 
> I could not sign-swap the measurements in TimeLab when I tried.
> I don't seem to be able to force the unwrapped phase to be +/- half cycle.
> I don't seem to be able to offset my readings. I have two sources of offset, 
> one is the additional delay of cables, and the other is the offset due to 
> wrong cycle (I hope this one can be baked into alternative phase-unwrapping 
> mode). I would prefer if I could hit calibration to establish the zero-level. 
> Typically I use a BNC barrel and well, it does add smoe more delay
> 
> What I propose should be doable with a simple counter like 5335A, 53131/2A or 
> similar. If you have a locked say 100 Hz or 1 kHz signal (TADD-2 can be 
> useful if the GPSDO does not output proper signal), you can do the picket 
> fence and resolve things, it is just that there is a few things to aid in the 
> post-processing to make values useful.
> 
> I further hint about a few things which makes easier to analyze is the 
> improved support for zooming.
> 
> Oh, I do care about phase variations and absolute phase measures. I do such 
> measures a lot. ADEV and TDEV is not all the things I measure, especially 
> when considering systematic effects.
> 
> Cheers,
> Magnus
> 
> On 10/09/2016 03:42 PM, Bob Camp wrote:
>> Hi
>> 
>> Given that *some* of us have more than errr … one counter :)
>> 
>> There are several setups that involve two or three counters to resolve some 
>> of these issues. Having
>> multiple serial ports or multiple devices on a GPIB isn’t that big a 
>> problem. Addressing multiple devices
>> (setting up the addresses in TimeLab) is an added step. Coming up with 
>> standard setups would be the
>> first step. Getting them documented to the degree that they could be run 
>> without a lot of hassle would be
>> the next step.
>> 
>> Another fairly simple addition (rather than a full blown counter) would be 
>> some sort of MCU to time tag
>> the input(s). It’s a function that is well within the capabilities of a 
>> multitude of cheap demo cards. Rather than
>> defining a specific card, it is probably better to just define a standard 
>> message (115200 K baud, 8N1, starts
>> with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
>> seconds count.The final data field is
>> a time in nanoseconds within the second, *two byte check sum is last, 
>> cr/lf). If there is a next generation version that is
>> incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds 
>> after typing that definition I can see
>> a few problems with it. Any structural similarity to NMEA is purely 
>> intentional. That’s why it needs a bit of
>> thought and work before you standardize on it. It still would be a cheap 
>> solution and maybe easier to integrate
>> into the software than multiple counters. You do indeed have all the same 
>> setup and documentation issues.
>> 
>> In any of the above cases, the only intent of the added hardware is to get a 
>> number that is good to 10’s of ns.
>> Anything past that is great. Once you know where all the edges really are, 
>> sorting out the phase data becomes
>> much easier.
>> 
>> Bob
>> 
>>> On Oct 9, 2016, at 7:32 AM, Magnus Danielson  
>>> wrote:
>>> 
>>> Fellow time-nuts,
>>> 
>>> I don't know if it is me who is lazy to not figure TimeLab out better or if 
>>> it is room for improvements. I was considering writing this directly to 
>>> John, but I gather that it might be of general concern for many, so I 
>>> thought it be a good topic for the list.
>>> 
>>> In one setup I have, I need to measure the offset of the PPS as I upset the 
>>> system under test. The counter I'm using is a HP53131A, and I use the 
>>> time-interval measure. I have a reference GPS (several actually) which can 
>>> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
>>> 
>>> In the ideal world of things, I would hook the DUT PPS to 

Re: [time-nuts] TimeLab

[Bob Stewart]

Don't forget the possibility of saving the data to a file and pre-processing 
the file before sending it to Timelab.
Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Magnus Danielson <mag...@rubidium.dyndns.org>
 To: time-nuts@febo.com 
Cc: mag...@rubidium.se
 Sent: Sunday, October 9, 2016 10:48 AM
 Subject: Re: [time-nuts] TimeLab
   
Hi,

Well, yes. You can do some fancy stuff with additional hardware, but I 
think with already a handful of relatively simple software fixes and 
some basic setup conditions, a sufficiently robust method emerges.

I could not sign-swap the measurements in TimeLab when I tried.
I don't seem to be able to force the unwrapped phase to be +/- half cycle.
I don't seem to be able to offset my readings. I have two sources of 
offset, one is the additional delay of cables, and the other is the 
offset due to wrong cycle (I hope this one can be baked into alternative 
phase-unwrapping mode). I would prefer if I could hit calibration to 
establish the zero-level. Typically I use a BNC barrel and well, it does 
add smoe more delay

What I propose should be doable with a simple counter like 5335A, 
53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal 
(TADD-2 can be useful if the GPSDO does not output proper signal), you 
can do the picket fence and resolve things, it is just that there is a 
few things to aid in the post-processing to make values useful.

I further hint about a few things which makes easier to analyze is the 
improved support for zooming.

Oh, I do care about phase variations and absolute phase measures. I do 
such measures a lot. ADEV and TDEV is not all the things I measure, 
especially when considering systematic effects.

Cheers,
Magnus

On 10/09/2016 03:42 PM, Bob Camp wrote:
> Hi
>
> Given that *some* of us have more than errr … one counter :)
>
> There are several setups that involve two or three counters to resolve some 
> of these issues. Having
> multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
> Addressing multiple devices
> (setting up the addresses in TimeLab) is an added step. Coming up with 
> standard setups would be the
> first step. Getting them documented to the degree that they could be run 
> without a lot of hassle would be
> the next step.
>
> Another fairly simple addition (rather than a full blown counter) would be 
> some sort of MCU to time tag
> the input(s). It’s a function that is well within the capabilities of a 
> multitude of cheap demo cards. Rather than
> defining a specific card, it is probably better to just define a standard 
> message (115200 K baud, 8N1, starts
> with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
> seconds count.The final data field is
> a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
> If there is a next generation version that is
> incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds 
> after typing that definition I can see
> a few problems with it. Any structural similarity to NMEA is purely 
> intentional. That’s why it needs a bit of
> thought and work before you standardize on it. It still would be a cheap 
> solution and maybe easier to integrate
> into the software than multiple counters. You do indeed have all the same 
> setup and documentation issues.
>
> In any of the above cases, the only intent of the added hardware is to get a 
> number that is good to 10’s of ns.
> Anything past that is great. Once you know where all the edges really are, 
> sorting out the phase data becomes
> much easier.
>
> Bob
>
>> On Oct 9, 2016, at 7:32 AM, Magnus Danielson <mag...@rubidium.dyndns.org> 
>> wrote:
>>
>> Fellow time-nuts,
>>
>> I don't know if it is me who is lazy to not figure TimeLab out better or if 
>> it is room for improvements. I was considering writing this directly to 
>> John, but I gather that it might be of general concern for many, so I 
>> thought it be a good topic for the list.
>>
>> In one setup I have, I need to measure the offset of the PPS as I upset the 
>> system under test. The counter I'm using is a HP53131A, and I use the 
>> time-interval measure. I have a reference GPS (several actually) which can 
>> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
>>
>> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1) 
>> and the reference PPS to the Stop (Ch2) channels. This would give me the 
>> propper Time Error (DUT - Ref) so a positive number tells me the DUT is 
>> ahead of the reference and a negative number tells me that the DUT is behind 
>> the reference.
>&

Re: [time-nuts] TimeLab

[Bob Stewart]

The problem with two counters is that they will never read exactly the same.  
What would be better is if the TICs were able to steer the first incoming 
signal to start and the next to stop, and then apply a sign based on where the 
first pulse came from.  Of course, then you have the problem of deciding 
whether you started the counter at the right point in time, or merely have 
things backward as a result of being too crafty with your hardware.
Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Alexander Pummer <alex...@ieee.org>
 To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
 Sent: Sunday, October 9, 2016 11:01 AM
 Subject: Re: [time-nuts] TimeLab
   
Hello Magnus,

I am a totally unerducated time nut better, to say; not time nut, just 
an old RF ingenieur,  and so I have trouble to understand how could a 
counter stop to count before it started to count. I case you would have 
a circuit, which would tell you which pulse came at first and start the 
counter regardless of which of the two pulse came first and the same way 
stop the counter regardless pulse came last, you could count out the 
time difference with the interval counter independently from the 
sequence the pulses,

Or you could use two counters and reverse the inputs at the second 
counter, thus one counter would show the positive error and the other 
the negative error.

73
KJ6UHN
Alex



On 10/9/2016 4:32 AM, Magnus Danielson wrote:
> Fellow time-nuts,
>
> I don't know if it is me who is lazy to not figure TimeLab out better 
> or if it is room for improvements. I was considering writing this 
> directly to John, but I gather that it might be of general concern for 
> many, so I thought it be a good topic for the list.
>
> In one setup I have, I need to measure the offset of the PPS as I 
> upset the system under test. The counter I'm using is a HP53131A, and 
> I use the time-interval measure. I have a reference GPS (several 
> actually) which can output PPS, 10 MHz, IRIG-B004 etc. In itself 
> nothing strange.
>
> In the ideal world of things, I would hook the DUT PPS to the Start 
> (Ch1) and the reference PPS to the Stop (Ch2) channels. This would 
> give me the propper Time Error (DUT - Ref) so a positive number tells 
> me the DUT is ahead of the reference and a negative number tells me 
> that the DUT is behind the reference.
>
> Now, as I do that, depending on their relative timing I might skip 
> samples, since the counter expects trigger conditions. While TimeLab 
> can correct for the period offset, it can't reproduce missed samples.
> I always get suspicious when the time in the program and the time in 
> real world does not match up.
>
> I could intentionally shift the PPS output of my DUT to any suitable 
> number, which would be one way to solve this, if I would tell TimeLab 
> to withdraw say 100 ms. I might want to do that easily afterhand 
> rather than in the setup window.
>
> To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal 
> with a stable rising edge aligned to the PPS to within about 2 ns. 
> Good enough for my purpose. However, for the trigger to only produce 
> meaningful results, I will need to swap inputs, so that the PPS from 
> DUT is on Start/Ch1 and the IRIG-B is on Stop/Ch2. This way I get my 
> triggers right. However, my readings have opposite sign. I might have 
> forgotten about the way to correct for it.
>
> However, TimeLab seems unable to unwrap the phase properly, so if I 
> have the condition where I would get a negative value of say -100 ns 
> then the counter will measure 9,999,900 ns, so I have to force a 
> positive value as I start the measurement and then have it trace into 
> the negative. I would very much like to see that TimeLab would 
> phase-unwrap into +/- period/2 from first sample. That would be much 
> more useful.
>
> I would also like to have the ability to set an offset from which the 
> current zoom window use as 0, really a form variant of the 0-base but 
> letting me either set the value or it be the first value of the zoom. 
> I have use for both of these. I often find myself fighting the offset 
> issues. In a similar fashion, I have been unable to change the 
> vertical zoom, if I don't care about clipping the signal then it 
> forces me to zoom in further than I like to. The autoscale fights me 
> many times in a fashion I don't like.
>
> OK, so there is a brain-dump of the last couple of weeks on and off 
> measurement experiences. While a few things might be fixed in the 
> usage, I wonder if there is not room for improvements in the tool. I 
> thought it better to describe what I do and why, so that the context 
> is given

Re: [time-nuts] TimeLab

[Alexander Pummer]

Hello Magnus,

I am a totally unerducated time nut better, to say; not time nut, just 
an old RF ingenieur,  and so I have trouble to understand how could a 
counter stop to count before it started to count. I case you would have 
a circuit, which would tell you which pulse came at first and start the 
counter regardless of which of the two pulse came first and the same way 
stop the counter regardless pulse came last, you could count out the 
time difference with the interval counter independently from the 
sequence the pulses,


Or you could use two counters and reverse the inputs at the second 
counter, thus one counter would show the positive error and the other 
the negative error.


73
KJ6UHN
Alex



On 10/9/2016 4:32 AM, Magnus Danielson wrote:

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out better 
or if it is room for improvements. I was considering writing this 
directly to John, but I gather that it might be of general concern for 
many, so I thought it be a good topic for the list.


In one setup I have, I need to measure the offset of the PPS as I 
upset the system under test. The counter I'm using is a HP53131A, and 
I use the time-interval measure. I have a reference GPS (several 
actually) which can output PPS, 10 MHz, IRIG-B004 etc. In itself 
nothing strange.


In the ideal world of things, I would hook the DUT PPS to the Start 
(Ch1) and the reference PPS to the Stop (Ch2) channels. This would 
give me the propper Time Error (DUT - Ref) so a positive number tells 
me the DUT is ahead of the reference and a negative number tells me 
that the DUT is behind the reference.


Now, as I do that, depending on their relative timing I might skip 
samples, since the counter expects trigger conditions. While TimeLab 
can correct for the period offset, it can't reproduce missed samples.
I always get suspicious when the time in the program and the time in 
real world does not match up.


I could intentionally shift the PPS output of my DUT to any suitable 
number, which would be one way to solve this, if I would tell TimeLab 
to withdraw say 100 ms. I might want to do that easily afterhand 
rather than in the setup window.


To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal 
with a stable rising edge aligned to the PPS to within about 2 ns. 
Good enough for my purpose. However, for the trigger to only produce 
meaningful results, I will need to swap inputs, so that the PPS from 
DUT is on Start/Ch1 and the IRIG-B is on Stop/Ch2. This way I get my 
triggers right. However, my readings have opposite sign. I might have 
forgotten about the way to correct for it.


However, TimeLab seems unable to unwrap the phase properly, so if I 
have the condition where I would get a negative value of say -100 ns 
then the counter will measure 9,999,900 ns, so I have to force a 
positive value as I start the measurement and then have it trace into 
the negative. I would very much like to see that TimeLab would 
phase-unwrap into +/- period/2 from first sample. That would be much 
more useful.


I would also like to have the ability to set an offset from which the 
current zoom window use as 0, really a form variant of the 0-base but 
letting me either set the value or it be the first value of the zoom. 
I have use for both of these. I often find myself fighting the offset 
issues. In a similar fashion, I have been unable to change the 
vertical zoom, if I don't care about clipping the signal then it 
forces me to zoom in further than I like to. The autoscale fights me 
many times in a fashion I don't like.


OK, so there is a brain-dump of the last couple of weeks on and off 
measurement experiences. While a few things might be fixed in the 
usage, I wonder if there is not room for improvements in the tool. I 
thought it better to describe what I do and why, so that the context 
is given.


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.


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7797 / Virus Database: 4656/13173 - Release Date: 
10/08/16


___
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

[Magnus Danielson]

Hi,

Well, yes. You can do some fancy stuff with additional hardware, but I 
think with already a handful of relatively simple software fixes and 
some basic setup conditions, a sufficiently robust method emerges.


I could not sign-swap the measurements in TimeLab when I tried.
I don't seem to be able to force the unwrapped phase to be +/- half cycle.
I don't seem to be able to offset my readings. I have two sources of 
offset, one is the additional delay of cables, and the other is the 
offset due to wrong cycle (I hope this one can be baked into alternative 
phase-unwrapping mode). I would prefer if I could hit calibration to 
establish the zero-level. Typically I use a BNC barrel and well, it does 
add smoe more delay


What I propose should be doable with a simple counter like 5335A, 
53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal 
(TADD-2 can be useful if the GPSDO does not output proper signal), you 
can do the picket fence and resolve things, it is just that there is a 
few things to aid in the post-processing to make values useful.


I further hint about a few things which makes easier to analyze is the 
improved support for zooming.


Oh, I do care about phase variations and absolute phase measures. I do 
such measures a lot. ADEV and TDEV is not all the things I measure, 
especially when considering systematic effects.


Cheers,
Magnus

On 10/09/2016 03:42 PM, Bob Camp wrote:

Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to resolve some of 
these issues. Having
multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up with standard 
setups would be the
first step. Getting them documented to the degree that they could be run 
without a lot of hassle would be
the next step.

Another fairly simple addition (rather than a full blown counter) would be some 
sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of a 
multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a standard 
message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
seconds count.The final data field is
a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
If there is a next generation version that is
incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds after 
typing that definition I can see
a few problems with it. Any structural similarity to NMEA is purely 
intentional. That’s why it needs a bit of
thought and work before you standardize on it. It still would be a cheap 
solution and maybe easier to integrate
into the software than multiple counters. You do indeed have all the same setup 
and documentation issues.

In any of the above cases, the only intent of the added hardware is to get a 
number that is good to 10’s of ns.
Anything past that is great. Once you know where all the edges really are, 
sorting out the phase data becomes
much easier.

Bob


On Oct 9, 2016, at 7:32 AM, Magnus Danielson  wrote:

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out better or if it 
is room for improvements. I was considering writing this directly to John, but 
I gather that it might be of general concern for many, so I thought it be a 
good topic for the list.

In one setup I have, I need to measure the offset of the PPS as I upset the 
system under test. The counter I'm using is a HP53131A, and I use the 
time-interval measure. I have a reference GPS (several actually) which can 
output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.

In the ideal world of things, I would hook the DUT PPS to the Start (Ch1) and 
the reference PPS to the Stop (Ch2) channels. This would give me the propper 
Time Error (DUT - Ref) so a positive number tells me the DUT is ahead of the 
reference and a negative number tells me that the DUT is behind the reference.

Now, as I do that, depending on their relative timing I might skip samples, 
since the counter expects trigger conditions. While TimeLab can correct for the 
period offset, it can't reproduce missed samples.
I always get suspicious when the time in the program and the time in real world 
does not match up.

I could intentionally shift the PPS output of my DUT to any suitable number, 
which would be one way to solve this, if I would tell TimeLab to withdraw say 
100 ms. I might want to do that easily afterhand rather than in the setup 
window.

To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with a 
stable rising edge aligned to the PPS to within about 2 ns. Good enough for my 
purpose. However, for the trigger to only produce meaningful results, I will 
need to swap inputs, so that the PPS from DUT is on 

Re: [time-nuts] TimeLab

[Bob Camp]

Hi

Given that *some* of us have more than errr … one counter :)

There are several setups that involve two or three counters to resolve some of 
these issues. Having 
multiple serial ports or multiple devices on a GPIB isn’t that big a problem. 
Addressing multiple devices
(setting up the addresses in TimeLab) is an added step. Coming up with standard 
setups would be the 
first step. Getting them documented to the degree that they could be run 
without a lot of hassle would be
the next step. 

Another fairly simple addition (rather than a full blown counter) would be some 
sort of MCU to time tag
the input(s). It’s a function that is well within the capabilities of a 
multitude of cheap demo cards. Rather than
defining a specific card, it is probably better to just define a standard 
message (115200 K baud, 8N1, starts
with “$timenuts$,1,”, next is the channel number, after that the (32 bit?) 
seconds count.The final data field is 
a time in nanoseconds within the second, *two byte check sum is last, cr/lf). 
If there is a next generation version that is 
incompatible, the 1 after timeouts changes to a 2.) Yes, even 10 seconds after 
typing that definition I can see
a few problems with it. Any structural similarity to NMEA is purely 
intentional. That’s why it needs a bit of 
thought and work before you standardize on it. It still would be a cheap 
solution and maybe easier to integrate 
into the software than multiple counters. You do indeed have all the same setup 
and documentation issues. 

In any of the above cases, the only intent of the added hardware is to get a 
number that is good to 10’s of ns. 
Anything past that is great. Once you know where all the edges really are, 
sorting out the phase data becomes
much easier. 

Bob

> On Oct 9, 2016, at 7:32 AM, Magnus Danielson  
> wrote:
> 
> Fellow time-nuts,
> 
> I don't know if it is me who is lazy to not figure TimeLab out better or if 
> it is room for improvements. I was considering writing this directly to John, 
> but I gather that it might be of general concern for many, so I thought it be 
> a good topic for the list.
> 
> In one setup I have, I need to measure the offset of the PPS as I upset the 
> system under test. The counter I'm using is a HP53131A, and I use the 
> time-interval measure. I have a reference GPS (several actually) which can 
> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
> 
> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1) and 
> the reference PPS to the Stop (Ch2) channels. This would give me the propper 
> Time Error (DUT - Ref) so a positive number tells me the DUT is ahead of the 
> reference and a negative number tells me that the DUT is behind the reference.
> 
> Now, as I do that, depending on their relative timing I might skip samples, 
> since the counter expects trigger conditions. While TimeLab can correct for 
> the period offset, it can't reproduce missed samples.
> I always get suspicious when the time in the program and the time in real 
> world does not match up.
> 
> I could intentionally shift the PPS output of my DUT to any suitable number, 
> which would be one way to solve this, if I would tell TimeLab to withdraw say 
> 100 ms. I might want to do that easily afterhand rather than in the setup 
> window.
> 
> To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with a 
> stable rising edge aligned to the PPS to within about 2 ns. Good enough for 
> my purpose. However, for the trigger to only produce meaningful results, I 
> will need to swap inputs, so that the PPS from DUT is on Start/Ch1 and the 
> IRIG-B is on Stop/Ch2. This way I get my triggers right. However, my readings 
> have opposite sign. I might have forgotten about the way to correct for it.
> 
> However, TimeLab seems unable to unwrap the phase properly, so if I have the 
> condition where I would get a negative value of say -100 ns then the counter 
> will measure 9,999,900 ns, so I have to force a positive value as I start the 
> measurement and then have it trace into the negative. I would very much like 
> to see that TimeLab would phase-unwrap into +/- period/2 from first sample. 
> That would be much more useful.
> 
> I would also like to have the ability to set an offset from which the current 
> zoom window use as 0, really a form variant of the 0-base but letting me 
> either set the value or it be the first value of the zoom. I have use for 
> both of these. I often find myself fighting the offset issues. In a similar 
> fashion, I have been unable to change the vertical zoom, if I don't care 
> about clipping the signal then it forces me to zoom in further than I like 
> to. The autoscale fights me many times in a fashion I don't like.
> 
> OK, so there is a brain-dump of the last couple of weeks on and off 
> measurement experiences. While a few things might be fixed in the usage, I 
> wonder if there is not room for improvements in 

Re: [time-nuts] TimeLab

[Magnus Danielson]

Dear Azelio,

Indeed. I know that. Some counters have +/- TI trigger, such that 
regardless which of the channels which is first after arming, it 
triggers and then the other, and it will resolve the time ambiguity.

No wonder a coax delay is often used to aid triggering.

I didn't want to go into depth on counter design, a topic which I could 
spew out much more text on, but this is not focused on the counters 
themselves, but how we use them to get practical and useful data. I 
would appreciate if we could stick to that topic, as I think it is a 
relevant one. Practical obstacles and how we handle them. Here we have a 
given counter, how do we utilize it best to get good measurements.
Also, I could dig up many counters that may solve this or that issue, 
but for the given situation I'm stuck with this counter.


Cheers,
Magnus

On 10/09/2016 02:27 PM, Azelio Boriani wrote:

In the real world of TICs is not possible to implement a stop pulse
that occurs before its start pulse. When a regular start-stop (stop
pulse after start, positive delay) is followed by a negative delay
(stop pulse before the start) the sample is lost because the start has
not yet occurred. The only way is to intentionally delay the stop so
that it will never occur before the start. The delay must be known and
very stable, of course.

On Sun, Oct 9, 2016 at 1:32 PM, Magnus Danielson
 wrote:

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out better or if
it is room for improvements. I was considering writing this directly to
John, but I gather that it might be of general concern for many, so I
thought it be a good topic for the list.

In one setup I have, I need to measure the offset of the PPS as I upset the
system under test. The counter I'm using is a HP53131A, and I use the
time-interval measure. I have a reference GPS (several actually) which can
output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.

In the ideal world of things, I would hook the DUT PPS to the Start (Ch1)
and the reference PPS to the Stop (Ch2) channels. This would give me the
propper Time Error (DUT - Ref) so a positive number tells me the DUT is
ahead of the reference and a negative number tells me that the DUT is behind
the reference.

Now, as I do that, depending on their relative timing I might skip samples,
since the counter expects trigger conditions. While TimeLab can correct for
the period offset, it can't reproduce missed samples.
I always get suspicious when the time in the program and the time in real
world does not match up.

I could intentionally shift the PPS output of my DUT to any suitable number,
which would be one way to solve this, if I would tell TimeLab to withdraw
say 100 ms. I might want to do that easily afterhand rather than in the
setup window.

To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with
a stable rising edge aligned to the PPS to within about 2 ns. Good enough
for my purpose. However, for the trigger to only produce meaningful results,
I will need to swap inputs, so that the PPS from DUT is on Start/Ch1 and the
IRIG-B is on Stop/Ch2. This way I get my triggers right. However, my
readings have opposite sign. I might have forgotten about the way to correct
for it.

However, TimeLab seems unable to unwrap the phase properly, so if I have the
condition where I would get a negative value of say -100 ns then the counter
will measure 9,999,900 ns, so I have to force a positive value as I start
the measurement and then have it trace into the negative. I would very much
like to see that TimeLab would phase-unwrap into +/- period/2 from first
sample. That would be much more useful.

I would also like to have the ability to set an offset from which the
current zoom window use as 0, really a form variant of the 0-base but
letting me either set the value or it be the first value of the zoom. I have
use for both of these. I often find myself fighting the offset issues. In a
similar fashion, I have been unable to change the vertical zoom, if I don't
care about clipping the signal then it forces me to zoom in further than I
like to. The autoscale fights me many times in a fashion I don't like.

OK, so there is a brain-dump of the last couple of weeks on and off
measurement experiences. While a few things might be fixed in the usage, I
wonder if there is not room for improvements in the tool. I thought it
better to describe what I do and why, so that the context is given.

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.


___
time-nuts 

Re: [time-nuts] TimeLab

[Azelio Boriani]

In the real world of TICs is not possible to implement a stop pulse
that occurs before its start pulse. When a regular start-stop (stop
pulse after start, positive delay) is followed by a negative delay
(stop pulse before the start) the sample is lost because the start has
not yet occurred. The only way is to intentionally delay the stop so
that it will never occur before the start. The delay must be known and
very stable, of course.

On Sun, Oct 9, 2016 at 1:32 PM, Magnus Danielson
 wrote:
> Fellow time-nuts,
>
> I don't know if it is me who is lazy to not figure TimeLab out better or if
> it is room for improvements. I was considering writing this directly to
> John, but I gather that it might be of general concern for many, so I
> thought it be a good topic for the list.
>
> In one setup I have, I need to measure the offset of the PPS as I upset the
> system under test. The counter I'm using is a HP53131A, and I use the
> time-interval measure. I have a reference GPS (several actually) which can
> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
>
> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1)
> and the reference PPS to the Stop (Ch2) channels. This would give me the
> propper Time Error (DUT - Ref) so a positive number tells me the DUT is
> ahead of the reference and a negative number tells me that the DUT is behind
> the reference.
>
> Now, as I do that, depending on their relative timing I might skip samples,
> since the counter expects trigger conditions. While TimeLab can correct for
> the period offset, it can't reproduce missed samples.
> I always get suspicious when the time in the program and the time in real
> world does not match up.
>
> I could intentionally shift the PPS output of my DUT to any suitable number,
> which would be one way to solve this, if I would tell TimeLab to withdraw
> say 100 ms. I might want to do that easily afterhand rather than in the
> setup window.
>
> To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with
> a stable rising edge aligned to the PPS to within about 2 ns. Good enough
> for my purpose. However, for the trigger to only produce meaningful results,
> I will need to swap inputs, so that the PPS from DUT is on Start/Ch1 and the
> IRIG-B is on Stop/Ch2. This way I get my triggers right. However, my
> readings have opposite sign. I might have forgotten about the way to correct
> for it.
>
> However, TimeLab seems unable to unwrap the phase properly, so if I have the
> condition where I would get a negative value of say -100 ns then the counter
> will measure 9,999,900 ns, so I have to force a positive value as I start
> the measurement and then have it trace into the negative. I would very much
> like to see that TimeLab would phase-unwrap into +/- period/2 from first
> sample. That would be much more useful.
>
> I would also like to have the ability to set an offset from which the
> current zoom window use as 0, really a form variant of the 0-base but
> letting me either set the value or it be the first value of the zoom. I have
> use for both of these. I often find myself fighting the offset issues. In a
> similar fashion, I have been unable to change the vertical zoom, if I don't
> care about clipping the signal then it forces me to zoom in further than I
> like to. The autoscale fights me many times in a fashion I don't like.
>
> OK, so there is a brain-dump of the last couple of weeks on and off
> measurement experiences. While a few things might be fixed in the usage, I
> wonder if there is not room for improvements in the tool. I thought it
> better to describe what I do and why, so that the context is given.
>
> 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.

[time-nuts] TimeLab

[Magnus Danielson]

Fellow time-nuts,

I don't know if it is me who is lazy to not figure TimeLab out better or 
if it is room for improvements. I was considering writing this directly 
to John, but I gather that it might be of general concern for many, so I 
thought it be a good topic for the list.


In one setup I have, I need to measure the offset of the PPS as I upset 
the system under test. The counter I'm using is a HP53131A, and I use 
the time-interval measure. I have a reference GPS (several actually) 
which can output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.


In the ideal world of things, I would hook the DUT PPS to the Start 
(Ch1) and the reference PPS to the Stop (Ch2) channels. This would give 
me the propper Time Error (DUT - Ref) so a positive number tells me the 
DUT is ahead of the reference and a negative number tells me that the 
DUT is behind the reference.


Now, as I do that, depending on their relative timing I might skip 
samples, since the counter expects trigger conditions. While TimeLab can 
correct for the period offset, it can't reproduce missed samples.
I always get suspicious when the time in the program and the time in 
real world does not match up.


I could intentionally shift the PPS output of my DUT to any suitable 
number, which would be one way to solve this, if I would tell TimeLab to 
withdraw say 100 ms. I might want to do that easily afterhand rather 
than in the setup window.


To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal 
with a stable rising edge aligned to the PPS to within about 2 ns. Good 
enough for my purpose. However, for the trigger to only produce 
meaningful results, I will need to swap inputs, so that the PPS from DUT 
is on Start/Ch1 and the IRIG-B is on Stop/Ch2. This way I get my 
triggers right. However, my readings have opposite sign. I might have 
forgotten about the way to correct for it.


However, TimeLab seems unable to unwrap the phase properly, so if I have 
the condition where I would get a negative value of say -100 ns then the 
counter will measure 9,999,900 ns, so I have to force a positive value 
as I start the measurement and then have it trace into the negative. I 
would very much like to see that TimeLab would phase-unwrap into +/- 
period/2 from first sample. That would be much more useful.


I would also like to have the ability to set an offset from which the 
current zoom window use as 0, really a form variant of the 0-base but 
letting me either set the value or it be the first value of the zoom. I 
have use for both of these. I often find myself fighting the offset 
issues. In a similar fashion, I have been unable to change the vertical 
zoom, if I don't care about clipping the signal then it forces me to 
zoom in further than I like to. The autoscale fights me many times in a 
fashion I don't like.


OK, so there is a brain-dump of the last couple of weeks on and off 
measurement experiences. While a few things might be fixed in the usage, 
I wonder if there is not room for improvements in the tool. I thought it 
better to describe what I do and why, so that the context is given.


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] timelab question

[jimlux]

On 9/8/16 5:10 PM, John Miles wrote:

I've got a file with counter values that are latched once per second,
with the count read from the latch every half second.  So, generally,
there are two identical values, then two different identical values,
etc.  But, of course, the routine that does the every half second
reading isn't perfect.. it could run fast or slow.

I want to process the count values in timelab, and I was wondering if it
knows to eliminate the duplicates, or if I write some code to strip the
dupes.


That's a pretty scary problem to have.  Are these frequency counts or TI 
readings?  You wouldn't normally see two identical TI readings in a row, but if 
they're frequency counts, how do you know for sure you're eliminating a 
duplicate reading, as opposed to one that just happened to be the same as the 
last?

There's nothing that TimeLab can do to help with this scenario, I'm afraid.  
Stable32 may be able to remove duplicate TI readings, but otherwise, yes, you'd 
need to write some kind of script to preprocess the sample file.



latched counts from a free running counter, so difference between 
successive different values is basically "frequency"...


Timelab worked perfectly after fooling around with my file parser that 
generates the data files.



___
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 question

[jimlux]

On 9/8/16 4:41 PM, Bob Camp wrote:

Hi

I think you are stuck with writing some code. I would want to make sure that in 
the odd
case two latched values were identical, they didn’t get tossed  (3 or 4 identical 
in a row => 2 not 1) ….



since they are latched counts from a free running counter, not 
frequencies, if I do a uniq first, then compute deltas between 
successive samples. (the counter is big enough to not rollover)



___
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 question

[John Miles]

> That's a pretty scary problem to have.  Are these frequency counts or TI
> readings?  You wouldn't normally see two identical TI readings in a row,

Actually, that's not even safe to assume for TI readings, depending on how your 
triggering works.  It would make sense to do whatever it takes to fix this at 
the source. 

-- john, KE5FX
Miles Design LLC


___
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 question

[John Miles]

> I've got a file with counter values that are latched once per second,
> with the count read from the latch every half second.  So, generally,
> there are two identical values, then two different identical values,
> etc.  But, of course, the routine that does the every half second
> reading isn't perfect.. it could run fast or slow.
> 
> I want to process the count values in timelab, and I was wondering if it
> knows to eliminate the duplicates, or if I write some code to strip the
> dupes.

That's a pretty scary problem to have.  Are these frequency counts or TI 
readings?  You wouldn't normally see two identical TI readings in a row, but if 
they're frequency counts, how do you know for sure you're eliminating a 
duplicate reading, as opposed to one that just happened to be the same as the 
last?

There's nothing that TimeLab can do to help with this scenario, I'm afraid.  
Stable32 may be able to remove duplicate TI readings, but otherwise, yes, you'd 
need to write some kind of script to preprocess the sample file.  

-- john, KE5FX
Miles Design LLC


___
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 question

[Bob Camp]

Hi

I think you are stuck with writing some code. I would want to make sure that in 
the odd
case two latched values were identical, they didn’t get tossed  (3 or 4 
identical in a row => 2 not 1) ….

Bob

> On Sep 8, 2016, at 6:13 PM, jimlux  wrote:
> 
> I've got a file with counter values that are latched once per second, with 
> the count read from the latch every half second.  So, generally, there are 
> two identical values, then two different identical values, etc.  But, of 
> course, the routine that does the every half second reading isn't perfect.. 
> it could run fast or slow.
> 
> I want to process the count values in timelab, and I was wondering if it 
> knows to eliminate the duplicates, or if I write some code to strip the dupes.
> 
> ___
> 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] timelab question

[jimlux]

I've got a file with counter values that are latched once per second, 
with the count read from the latch every half second.  So, generally, 
there are two identical values, then two different identical values, 
etc.  But, of course, the routine that does the every half second 
reading isn't perfect.. it could run fast or slow.


I want to process the count values in timelab, and I was wondering if it 
knows to eliminate the duplicates, or if I write some code to strip the 
dupes.


___
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

[Bob Camp]

HI

Yes, at 1 second vs 10 seconds the data suggests that the counter is the limit. 
Unfortunately
you can’t make a judgement between 10 an 100 seconds. Certainly at 100 seconds 
and beyond,
the counter is doing just fine. 

Bottom line: This is why people mess with single and dual mixer setups or SDR 
like gizmos.

Bob


> On Jun 3, 2016, at 3:07 AM, Nick Sayer  wrote:
> 
> So what’s going on is that the TIA is “Mr. Magoo” and isn’t seeing 
> sufficiently well to evaluate these oscillators?
> 
> I can believe that.
> 
> I might just have to stop there, then. I can’t justify an upgrade today.
> 
>> On Jun 2, 2016, at 7:24 PM, Bob Camp  wrote:
>> 
>> 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 

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

[Nick Sayer via time-nuts]

So what’s going on is that the TIA is “Mr. Magoo” and isn’t seeing sufficiently 
well to evaluate these oscillators?

I can believe that.

I might just have to stop there, then. I can’t justify an upgrade today.

> On Jun 2, 2016, at 7:24 PM, Bob Camp  wrote:
> 
> 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

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

[Nick Sayer via time-nuts]

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 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

[Anders Wallin]

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 <
time-nuts@febo.com> 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
> 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] Timelab and the 53220A - getting best results

[Nick Sayer via time-nuts]

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 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab bug (was: Framework for simulation of oscillators)

[John Miles]

> Here it takes slightly less 3 minutes, but stops at 10M samples.

> Memory consumption of Timelab stays below 350MB the whole time

> and drops to 98MB after it finished.

> 

> OS is windows XP pro

> 

> How many samples did you get? It should have been 14926518 (ie slightly

> less than 15M) 

 

D'oh, sorry, I misunderstood -- I thought you were saying it locked up.
Yes, the normal file-import process stops at 10M samples because that's the
arbitrary maximum value allowed for the Trace Duration property in the
file-import dialog.  I'll go ahead and raise the limit to 100M points for
the 64-bit version.

 

For now, you can work around the 10M-point import limit by using
Acquire->Acquire from live ASCII file instead of File->Import
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
(10 days in this case.)  

 

To use the live-ASCII acquisition option on a static file, uncheck "Auto"
and check "Include existing file contents" before hitting the Start
Measurement button.  When the file finishes loading, it will sit there
waiting for more data to be appended to the file.  At that point you can hit
the space bar to stop the acquisition, and it will readjust the duration to
correspond to the actual number of points it read.

 



 

 

-- john, KE5FX

Miles Design LLC

 

___
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, two SR620s and losing samples

[Adrian Godwin]

If you have RS232 connections, won't you have one for each device ? Whereas
with GPIB, you'll (probably) only have one bus. The GPIB bus will arbitrate
and avoid both instruments talking at the same time (this might not be true
in talk-only mode since there's no target address involved) but it doesn't
provide two completely separate channels.


On Sun, Jan 17, 2016 at 1:01 PM, Magnus Danielson <
mag...@rubidium.dyndns.org> wrote:

> Poul-Henning,
>
> On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote:
>
>> 
>> In message <569b8b2e.5070...@rubidium.dyndns.org>, Magnus Danielson
>> writes:
>>
>> I think you should develop that line of thought, to detail why it helps
> on GPIB and why not on serial.
>

 It's really very simple:  RS-232 sends blind, you don't even need to
 know if there is a receiver or what it does.  If the receiver cannot
 keep op, data is simply lost.

 GPIB handshakes every byte, so the actions of the receiving end affects
 the transmitting end - in particular if the receiver cannot keep up.

>>>
>>> OK, you where thinking about the flow-control.
>>>
>>> You can have RS-232 wired up to do flow-control (hardware-flow-control),
>>>
>>
>> But the important point is you don't have to do that, all you need
>> is two wires:  GND-GND and TXD->RXD
>>
>> With GPIB that option does not exist, sender and receiver are always
>> in lock-step.
>>
>> Therefore, talk-only mode is a big advantage in terms of decoupling
>> on RS-232 and makes almost no difference on GPIB.
>>
>>
> If we can assume the consumption is fast enough to keep track, yes.
> If it's not, flow control for this situation helps the border case
> somewhat, but if you are too slow, you are screwed anyway.
>
> In the case that Attila describes, the flow-control helps over the various
> borders, especially as scheduling plays tricks with us. Running virtual
> applications like that does not help to get a grip of control over how data
> is transfered and when. If it where only to get it straight into an app
> really talking to the serial ports, sure, but I do not trust the
> virtualization to handle it all to well.
>
> Not that hardware flow-control would in itself help much, but anyway.
>
> Regardless, if the TimeLab needs to send commands back to the counter over
> the virtualization border, then getting things scheduled properly in time
> isn't really guaranteed.
>
> 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] Timelab, two SR620s and losing samples

[Poul-Henning Kamp]

In message <00d801d15170$f91c6630$eb553290$@miles.io>, "John Miles" writes:

>By timing issues,
>I wasn't referring to layer-1 handshaking, but rather the interplay
>between the GPIB software application, the network or bus connectivity
>between the app and GPIB controller, the controller itself and its
>firmware, and an addressable counter that returns each measurement
>only in response to a command from the app.

If your measurements are timing sensitive at or below milliseconds,
you should *always* pace them with an external trigger.  They didn't
add that input just to take up space.

If you insist on pacing via the GPIB, the protocol has a primitive
for that, TRG, which is usually hardwired to the external trigger
circuitry in quality instruments.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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, two SR620s and losing samples

[Poul-Henning Kamp]

In message <569bcebe.20...@erols.com>, Chuck Harris writes:

>Talk-only mode is by intention, an exclusive mode, where
>there is one talker, and one listener on the bus.

Wrong.

There can *always* be multiple listeners on GPIB, this is
why it has a three wire handshake.

The slowest listener sets the pace, individually for each byte.

>GPIB is half duplex.

Correct.

>You have to turn the line around to tell it 
>give-me-the-next-sample.

Wrong.

There is no requirement to turn the line around (= send commands)
between measurements.  EOI is only indicative, it does not require
an UNTALK+TALK sequence.

Most instruments can be commanded to measure and spew data at you
in "talk-only" fashion.

> Talk-only avoids that.

Talk-only is one way to avoid that.


As I said from the start:  Talk-Only doesn't really make that much
difference, the three-wire handshake is sufficient to cause trouble.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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, two SR620s and losing samples

[Magnus Danielson]

John,

On 01/17/2016 10:49 PM, John Miles wrote:

Therefore, talk-only mode is a big advantage in terms of decoupling
on RS-232 and makes almost no difference on GPIB.


That's not the case when it comes to counters.  By timing issues, I wasn't 
referring to layer-1 handshaking, but rather the interplay between the GPIB 
software application, the network or bus connectivity between the app and GPIB 
controller, the controller itself and its firmware, and an addressable counter 
that returns each measurement only in response to a command from the app.  The 
difference in performance between a talk-only connection and a two-way 
conversation can be substantial.  Yes, everything runs in lockstep, but the sum 
of the delays and latencies in each of those stages can easily exceed 0.1 
second.  In Attila's case there are also VM crossings in both directions to 
worry about.

The counter, unlike any of the other participants in the conversation, is working on a 
deadline.  Everything in a counter tends to happen in the "foreground," so to 
speak.  If the counter takes too long to interpret and execute a GPIB command, it may 
fail to rearm itself in time for the next trigger.  That's never a problem in talk-only 
mode, at least not at rates we're concerned with here, because the counter never has to 
do anything but send out data.


It was time that we started to talk about this total picture.

Add that some GPIB interfaces uses USB-to-serial chips and then 
serial-CPU-GPIB. Many instruments uses a GPIB chip having the low-level 
logic to off-load the CPU. The SR620 for instance uses the TMS9914 GPIB 
controller chip, which does much of the hand-shaking, but does not 
offload the CPU much in regards to FIFO-buffering, which is typical of 
its age. Still, much of the lower level stuff gets the boost it needs.
The SR620 has maybe not the powerhouse processor, so that should be a 
limitation by itself. Interestingly the SR620 uses a Z80 as a IO 
processor to draw on XY scopes.


There is more handshake in the GPIB than pure flow-control, but I've not 
seen it used and honestly I haven't tried it myself. It seems like the 
support is there and documented for many instruments. Shouldn't we try 
to use that to aid the ping-pong between instruments?


Building up the system, we should think about how the system maintain 
its properties, data flow, arm-trigger mechanisms.


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] Timelab, two SR620s and losing samples

[John Miles]

> Therefore, talk-only mode is a big advantage in terms of decoupling
> on RS-232 and makes almost no difference on GPIB.

That's not the case when it comes to counters.  By timing issues, I wasn't 
referring to layer-1 handshaking, but rather the interplay between the GPIB 
software application, the network or bus connectivity between the app and GPIB 
controller, the controller itself and its firmware, and an addressable counter 
that returns each measurement only in response to a command from the app.  The 
difference in performance between a talk-only connection and a two-way 
conversation can be substantial.  Yes, everything runs in lockstep, but the sum 
of the delays and latencies in each of those stages can easily exceed 0.1 
second.  In Attila's case there are also VM crossings in both directions to 
worry about.

The counter, unlike any of the other participants in the conversation, is 
working on a deadline.  Everything in a counter tends to happen in the 
"foreground," so to speak.  If the counter takes too long to interpret and 
execute a GPIB command, it may fail to rearm itself in time for the next 
trigger.  That's never a problem in talk-only mode, at least not at rates we're 
concerned with here, because the counter never has to do anything but send out 
data.

-- john, KE5FX
Miles Design LLC


___
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, two SR620s and losing samples

[Hal Murray]

mag...@rubidium.dyndns.org said:
> OK, you where thinking about the flow-control.
> You can have RS-232 wired up to do flow-control (hardware-flow-control),
> where as flow-control is a standard property of GPIB. On the other hand,
> flow-control in itself only assures the data-transfer but not that  triggers
> is not missed in the overall system. 

GPIB is half duplex.  You have to turn the line around to tell it 
give-me-the-next-sample.  Talk-only avoids that.

In some sense, it's similar to flow control, but it's more likely to be 
implemented in software or wait for software to tell it to send data or ...

With talk-only, the OS buffer can handle many lines in case the scheduler is 
not cooperating.


-- 
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] Timelab, two SR620s and losing samples

[Chuck Harris]

Talk-only mode is by intention, an exclusive mode, where
there is one talker, and one listener on the bus.  There
can be exceptions where there are more than one listener,
but that tends to be unusual.

Addressed mode can have one or more instrument on the
bus.  Although addressed mode is fully orchestrated by
the controller, the controller can easily interleave
things in a way that can cause unintended latency in a
critical instrument.

-Chuck Harris

Magnus Danielson wrote:

Poul-Henning,

On 01/17/2016 12:52 PM, Poul-Henning Kamp wrote:


In message <569b61cf.3030...@rubidium.dyndns.org>, Magnus Danielson writes:


This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.


Agree, to some degree. It's not a guarantee.

I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.


It's really very simple:  RS-232 sends blind, you don't even need to
know if there is a receiver or what it does.  If the receiver cannot
keep op, data is simply lost.

GPIB handshakes every byte, so the actions of the receiving end affects
the transmitting end - in particular if the receiver cannot keep up.


___
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, two SR620s and losing samples

[Magnus Danielson]

God morgon!

On 01/16/2016 08:48 PM, Attila Kinali wrote:

God kväll!

On Sat, 16 Jan 2016 06:00:54 +0100
Magnus Danielson  wrote:


The two SR620s are both connected to an FS725 Rb frequency standard
(mostly because we have them around and nobody else uses them :-)


It's being used, by you! ;-)


There is another one lying around, nobody uses... and a CNT 91 :-)


Make sure to put that CNT-91 to use. :)
I have found that it's graph view is handy, especially when you don't 
have TimeLab around.



Have you tried swapping "role" of the SR620?


Yes, I've done that. Both SR620's lose some samples, but only one of
them loses significantly more than the other.


OK. So, the dropping follows the counter rather than the role?


Have you tried grabbing data in the Linux environment?


Nope. I couldn't find any tool for linux that worked.
I also tried to run Timelabs in Wine, but that segfaults on start.
Do you have any recommendation for a tool?


You don't need anything fancy. A small program to talk to the serial 
port should do it. If you could use talk only, I would just pipe it to a 
file and compare them later.


I really wish TimeLab existed directly on Linux. Last time I tried 
running it under Wine, it worked but didn't draw things properly for me.



Consider that the virtual box thing might not have the cleverest method
to handle data from multiple serial devices.


Yes. But I have done similar things, even more demanding stuff in the past
and they all worked. If anything was amis, then it was usually the USB
stack of Windows itself that screwed up.


Would not surprise me.


Have you tried swapping the serial-to-USB adaptors?


Yes, but I only have one type of adaptor at my disposal
(but at least a dozen of them).


OK.


Have you tried grabbing data on two independent PCs, just to avoid
issues in the USB handling? (Yes, never mind it won't correlate, just
check that you get the same amount of data)


Not yet. I'll do that on monday.


OK.


Have you tried feeding timelab two streams generated on the linux side?


What do you mean by that?


If you generate data that looks like real data and then mock the serial 
ports to make TimeLab beleive it is real counters, you can now see if 
the dataflow themselves causes issues over the Linux/Windows border and 
into TimeLab.



Essentially, from the counters to TimeLab you have a weak link, and you
need to consider all parts of it to identify which of them that is the
weak link.


I am currently leaning onto some kind of ground loop problem with the PC
in between. Though I am not sure. What I see is, that if only one of the
SR620s is running/connected, then the excursions with the "1s" size samples
are gone. So, currently I'm running only one of the SR620s (the one that
loses less samples) and capture only one pair of nodes at a time.


I'm considering that somewhere in that chain, the existence of two live 
streams is the issue. It could even be the TimeLab/counter interaction 
as hinted by John.



Another curious thing I see that I couldn't make sense of is, that from
time to time, on both of the SR620s, I see time differences of 1s (yes,
one full second). Given that the FPGAs produce a pulse every 50us, this
shouldn't be possible, unless the crystal oscillator stops.

Any idea what I might have done wrong or what the cause is?


It's not a consequence of the TI +/--mode such that the stop trigger
gets in early and you get a negative value reported because it takes
(start-time) - (stop-time) but allowing the stop-time to be the first?
Check the raw data.


It should not be. The pulses from the different nodes are within 2ns.
Even if one wanders away momentarily, it won't be able to go farther
than <3ns (the VCXO that generates the clock on each nodes is an ASVTX-09
which cannot be de-tuned more than a couple ppm, combined with a cycle
length of 50us after which the node is corrected into the right direction).
The trigger pulse comes a full 20us before the measured pulses come, so
that should not be the problem. I have to check what the raw data says.


I was hinting at a possible raw-data issue which in the pre-processing 
turned out a bit different. I realize now that dropping samples could 
possibly have the pre-processing react similarly.



Due to the problems I had with the SR620s and what the group at the TU Vienna
experienced (I am currently using their equipment), we started to ponder
whether we should build our own, multi-input TICs. Especially considering
that we are about to design some ASICs which we expect to be synced up
better than 100ps (somewhere around 20-50ps, limited by the delay uncertainty
of the cables).


Well, building your own TIC would naturally be interesting, but adds 
another aspect in that you will have to verifiy them extensively. It 
will be another factor of uncertainty to consider.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com

Re: [time-nuts] Timelab, two SR620s and losing samples

[Magnus Danielson]

John,

On 01/16/2016 10:33 PM, John Miles wrote:

Agreed with Magnus that there are a lot of possible variables in your setup 
that need to be ruled out.

Are you using the SR620 driver in TimeLab, or did you find a way to get it to 
emit data continuously via the RS232 port for use with the talk-only driver?  
I've seen occasional instances where a counter has ignored every other trigger 
when used in addressable mode by TimeLab.  It's not always readily 
reproducible, but the counter drivers in the current beta at 
http://www.miles.io/timelab/beta.htm seem to be a bit less prone to that 
behavior.  If you aren't already using the beta, try that.

It's always safest to use counters in talk-only mode when possible, since that 
rules out any timing problems that might arise in a two-way GPIB or serial 
conversation where each individual reading is requested by the software as done 
by the 5313xA, Philips, DTS2070-series, and SR620 drivers.  Some of those 
counters can be used in both talk-only and addressable modes, but I don't 
believe that's true of the SR620, unfortunately.  All of the programming 
examples in the SR620 manual work by requesting each reading individually.


I think it is the AUTM command that should be used, as it lets you swap 
between automatically start a new measurement (AUTM1) or let it start 
after computer receives measurement (AUTM0).


I have not tried it, I just pulled the manual from the shelf.

Come to think of it, in principle I could duplicate this as I have two 
SR620 lying around, but I think I better grab that second RF section in 
the boot of my car, bring it in and put it into the rack which needs 
rebuilding.


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] Timelab, two SR620s and losing samples

[Poul-Henning Kamp]

In message <569b3b7e.6090...@rubidium.dyndns.org>, Magnus Danielson writes:

>> It's always safest to use counters in talk-only mode when possible,
>>since that rules out any timing problems that might arise in a
>>two-way GPIB [...]

This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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, two SR620s and losing samples

[Magnus Danielson]

Dear Poul-Henning,

On 01/17/2016 10:08 AM, Poul-Henning Kamp wrote:


In message <569b3b7e.6090...@rubidium.dyndns.org>, Magnus Danielson writes:


It's always safest to use counters in talk-only mode when possible,
since that rules out any timing problems that might arise in a
two-way GPIB [...]


This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.



Agree, to some degree. It's not a guarantee.

I think you should develop that line of thought, to detail why it helps 
on GPIB and why not on serial.


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] Timelab, two SR620s and losing samples

[Attila Kinali]

Moin John,

On Sat, 16 Jan 2016 13:33:54 -0800
"John Miles"  wrote:

> Agreed with Magnus that there are a lot of possible variables in your setup 
> that need to be ruled out.  

Yes, too many. And it isn't really helping that I hardly understand what
I am doing.


> Are you using the SR620 driver in TimeLab, or did you find a way to get
> it to emit data continuously via the RS232 port for use with the talk-only
> driver?

I am using TimeLab and start two acquisitions. That part seems to work
quite nicely.

> I've seen occasional instances where a counter has ignored every other
> trigger when used in addressable mode by TimeLab.  It's not always readily 
> reproducible, but the counter drivers in the current beta at 
> http://www.miles.io/timelab/beta.htm seem to be a bit less prone to that 
> behavior.  If you aren't already using the beta, try that.

Thanks! I'll try that tomorrow.

> 
> It's always safest to use counters in talk-only mode when possible, since 
> that rules out any timing problems that might arise in a two-way GPIB or 
> serial conversation where each individual reading is requested by the 
> software as done by the 5313xA, Philips, DTS2070-series, and SR620 drivers.  
> Some of those counters can be used in both talk-only and addressable modes, 
> but I don't believe that's true of the SR620, unfortunately.  All of the 
> programming examples in the SR620 manual work by requesting each reading 
> individually. 

Hmm.. I have set TimeLab to do samples every 0.1 seconds, and have an
external trigger with the same interval (SR620 setting ist Ext +/- Time).
Could it be that TimeLab just samples a little slower than the 0.1s,
so that it misses a measurement once in a while and has to wait until
the next trigger arrives?


Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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, two SR620s and losing samples

[Attila Kinali]

Guete Morge!

On Sun, 17 Jan 2016 07:24:32 +0100
Magnus Danielson  wrote:

> >> Have you tried swapping "role" of the SR620?
> >
> > Yes, I've done that. Both SR620's lose some samples, but only one of
> > them loses significantly more than the other.
> 
> OK. So, the dropping follows the counter rather than the role?

Yes.
 
> >> Have you tried grabbing data in the Linux environment?
> >
> > Nope. I couldn't find any tool for linux that worked.
> > I also tried to run Timelabs in Wine, but that segfaults on start.
> > Do you have any recommendation for a tool?
> 
> You don't need anything fancy. A small program to talk to the serial 
> port should do it. If you could use talk only, I would just pipe it to a 
> file and compare them later.

Hmm.. good idea.

> I really wish TimeLab existed directly on Linux. Last time I tried 
> running it under Wine, it worked but didn't draw things properly for me.

It's like Lady Heather, it needs to be ported to Qt ;-)
 
> >> Have you tried feeding timelab two streams generated on the linux side?
> >
> > What do you mean by that?
> 
> If you generate data that looks like real data and then mock the serial 
> ports to make TimeLab beleive it is real counters, you can now see if 
> the dataflow themselves causes issues over the Linux/Windows border and 
> into TimeLab.

Ah.. unfortunately this would need a bit more fiddling and tool building
than I have time for. I'm only here for another week and have to spend
most of the time learning how to do ASICs.
 
> > Due to the problems I had with the SR620s and what the group at the TU 
> > Vienna
> > experienced (I am currently using their equipment), we started to ponder
> > whether we should build our own, multi-input TICs. Especially considering
> > that we are about to design some ASICs which we expect to be synced up
> > better than 100ps (somewhere around 20-50ps, limited by the delay 
> > uncertainty
> > of the cables).
> 
> Well, building your own TIC would naturally be interesting, but adds 
> another aspect in that you will have to verifiy them extensively. It 
> will be another factor of uncertainty to consider.

Yes. It wouldn't be something that is done fast. I expect it to take
at least half a year with a couple of highly motivated people as a team.
A year would be probably more realistic. And after that, comes a whole
lot of verification and qualification. But that could probably be done
together with PTB or CERN.


Attila Kinali
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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, two SR620s and losing samples

[Magnus Danielson]

Poul-Henning,

On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote:


In message <569b8b2e.5070...@rubidium.dyndns.org>, Magnus Danielson writes:


I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.


It's really very simple:  RS-232 sends blind, you don't even need to
know if there is a receiver or what it does.  If the receiver cannot
keep op, data is simply lost.

GPIB handshakes every byte, so the actions of the receiving end affects
the transmitting end - in particular if the receiver cannot keep up.


OK, you where thinking about the flow-control.

You can have RS-232 wired up to do flow-control (hardware-flow-control),


But the important point is you don't have to do that, all you need
is two wires:  GND-GND and TXD->RXD

With GPIB that option does not exist, sender and receiver are always
in lock-step.

Therefore, talk-only mode is a big advantage in terms of decoupling
on RS-232 and makes almost no difference on GPIB.



If we can assume the consumption is fast enough to keep track, yes.
If it's not, flow control for this situation helps the border case 
somewhat, but if you are too slow, you are screwed anyway.


In the case that Attila describes, the flow-control helps over the 
various borders, especially as scheduling plays tricks with us. Running 
virtual applications like that does not help to get a grip of control 
over how data is transfered and when. If it where only to get it 
straight into an app really talking to the serial ports, sure, but I do 
not trust the virtualization to handle it all to well.


Not that hardware flow-control would in itself help much, but anyway.

Regardless, if the TimeLab needs to send commands back to the counter 
over the virtualization border, then getting things scheduled properly 
in time isn't really guaranteed.


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] Timelab, two SR620s and losing samples

[Magnus Danielson]

Poul-Henning,

On 01/17/2016 12:52 PM, Poul-Henning Kamp wrote:


In message <569b61cf.3030...@rubidium.dyndns.org>, Magnus Danielson writes:


This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.


Agree, to some degree. It's not a guarantee.

I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.


It's really very simple:  RS-232 sends blind, you don't even need to
know if there is a receiver or what it does.  If the receiver cannot
keep op, data is simply lost.

GPIB handshakes every byte, so the actions of the receiving end affects
the transmitting end - in particular if the receiver cannot keep up.



OK, you where thinking about the flow-control.

You can have RS-232 wired up to do flow-control (hardware-flow-control), 
where as flow-control is a standard property of GPIB. On the other hand, 
flow-control in itself only assures the data-transfer but not that 
triggers is not missed in the overall system.


I just didn't want to mind-read you on this one.

So, I don't see how flow-control would severely break in GPIB doing 
addressed mode compared to talk-only mode, it's an orthogonal feature of 
both.


It is however to some degree easier to control the real-time flow from 
only one instrument in talk-only mode compared to addressed mode. 
However, it should be possible to achieve it also in addressed mode, but 
you then need to think through the signaling interaction. Also, as both 
counters is triggered, the trigger interaction needs to be analyzed and 
the dataflow understood in the system context.


The SR620 does not recommend the AUTM1 mode for serial interface, as the 
synchronization between program and data-readout does not become as 
easy. Similarly, the SR620 does not support the binary mode for serial 
interface, but for GPIB, giving almost a ten-fold increase in 
sample-rate (150 vs 1400 samples per second).


Anyway, flow-control to ensure integrity of byte-flow should always be 
used. That will help if we can trigger both counters at the same time 
and guarantee that they are idle before next arming pulse.


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] Timelab, two SR620s and losing samples

[Poul-Henning Kamp]

In message <569b8b2e.5070...@rubidium.dyndns.org>, Magnus Danielson writes:

>>> I think you should develop that line of thought, to detail why it helps
>>> on GPIB and why not on serial.
>>
>> It's really very simple:  RS-232 sends blind, you don't even need to
>> know if there is a receiver or what it does.  If the receiver cannot
>> keep op, data is simply lost.
>>
>> GPIB handshakes every byte, so the actions of the receiving end affects
>> the transmitting end - in particular if the receiver cannot keep up.
>
>OK, you where thinking about the flow-control.
>
>You can have RS-232 wired up to do flow-control (hardware-flow-control), 

But the important point is you don't have to do that, all you need
is two wires:  GND-GND and TXD->RXD

With GPIB that option does not exist, sender and receiver are always
in lock-step.

Therefore, talk-only mode is a big advantage in terms of decoupling
on RS-232 and makes almost no difference on GPIB.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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, two SR620s and losing samples

[Magnus Danielson]

Attila,

On 01/14/2016 03:38 PM, Attila Kinali wrote:

Moin,

I have here a setup with four (FPGA) nodes that produce synchronized pulses
with a 20kHz rate. I have two SR620s two measure those pulses.

Because the SR620s are not fast enought to capture all pulses, and because
i want them to be synchronized, I set up one of the nodes to generate an
additional pulse every 100ms (10Hz rate) 20us before the "main" pulse,
and feed that to the two EXT trigger inputs of the SR620s.

The two SR620s are both connected to an FS725 Rb frequency standard
(mostly because we have them around and nobody else uses them :-)


It's being used, by you! ;-)


Now, I use Timelab (running on Windows XP, in a virtualbox on a linux system),
using two serial-to-USB converters (FT232), which are passed as raw USB
devices into windows. Capturing both SR620s together in timelab, I see
one of the SR620s "producing" less samples than the other.
Quite considerably less (it looks like 1-3% less or so).

I have already checked and rechecked the trigger settings, the trigger
voltages etc, but I cannot find why one produces less samples than the other.
I have changed cables, swapped nodes. But it's still the same SR620 that
loses samples.


Have you tried swapping "role" of the SR620?
Have you tried grabbing data in the Linux environment?
Consider that the virtual box thing might not have the cleverest method 
to handle data from multiple serial devices.

Have you tried swapping the serial-to-USB adaptors?
Have you tried grabbing data on two independent PCs, just to avoid 
issues in the USB handling? (Yes, never mind it won't correlate, just 
check that you get the same amount of data)

Have you tried feeding timelab two streams generated on the linux side?

Essentially, from the counters to TimeLab you have a weak link, and you 
need to consider all parts of it to identify which of them that is the 
weak link.



Another curious thing I see that I couldn't make sense of is, that from
time to time, on both of the SR620s, I see time differences of 1s (yes,
one full second). Given that the FPGAs produce a pulse every 50us, this
shouldn't be possible, unless the crystal oscillator stops.

Any idea what I might have done wrong or what the cause is?


It's not a consequence of the TI +/--mode such that the stop trigger 
gets in early and you get a negative value reported because it takes 
(start-time) - (stop-time) but allowing the stop-time to be the first?

Check the raw data.

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] Timelab, two SR620s and losing samples

[Attila Kinali]

God kväll!

On Sat, 16 Jan 2016 06:00:54 +0100
Magnus Danielson  wrote:

> > The two SR620s are both connected to an FS725 Rb frequency standard
> > (mostly because we have them around and nobody else uses them :-)
> 
> It's being used, by you! ;-)

There is another one lying around, nobody uses... and a CNT 91 :-)
 
> 
> Have you tried swapping "role" of the SR620?

Yes, I've done that. Both SR620's lose some samples, but only one of
them loses significantly more than the other.

> Have you tried grabbing data in the Linux environment?

Nope. I couldn't find any tool for linux that worked.
I also tried to run Timelabs in Wine, but that segfaults on start.
Do you have any recommendation for a tool?

> Consider that the virtual box thing might not have the cleverest method 
> to handle data from multiple serial devices.

Yes. But I have done similar things, even more demanding stuff in the past
and they all worked. If anything was amis, then it was usually the USB
stack of Windows itself that screwed up.

> Have you tried swapping the serial-to-USB adaptors?

Yes, but I only have one type of adaptor at my disposal
(but at least a dozen of them).

> Have you tried grabbing data on two independent PCs, just to avoid 
> issues in the USB handling? (Yes, never mind it won't correlate, just 
> check that you get the same amount of data)

Not yet. I'll do that on monday.


> Have you tried feeding timelab two streams generated on the linux side?

What do you mean by that?

> Essentially, from the counters to TimeLab you have a weak link, and you 
> need to consider all parts of it to identify which of them that is the 
> weak link.

I am currently leaning onto some kind of ground loop problem with the PC
in between. Though I am not sure. What I see is, that if only one of the
SR620s is running/connected, then the excursions with the "1s" size samples
are gone. So, currently I'm running only one of the SR620s (the one that
loses less samples) and capture only one pair of nodes at a time.


> > Another curious thing I see that I couldn't make sense of is, that from
> > time to time, on both of the SR620s, I see time differences of 1s (yes,
> > one full second). Given that the FPGAs produce a pulse every 50us, this
> > shouldn't be possible, unless the crystal oscillator stops.
> >
> > Any idea what I might have done wrong or what the cause is?
> 
> It's not a consequence of the TI +/--mode such that the stop trigger 
> gets in early and you get a negative value reported because it takes 
> (start-time) - (stop-time) but allowing the stop-time to be the first?
> Check the raw data.

It should not be. The pulses from the different nodes are within 2ns.
Even if one wanders away momentarily, it won't be able to go farther
than <3ns (the VCXO that generates the clock on each nodes is an ASVTX-09
which cannot be de-tuned more than a couple ppm, combined with a cycle
length of 50us after which the node is corrected into the right direction).
The trigger pulse comes a full 20us before the measured pulses come, so
that should not be the problem. I have to check what the raw data says.


Due to the problems I had with the SR620s and what the group at the TU Vienna
experienced (I am currently using their equipment), we started to ponder
whether we should build our own, multi-input TICs. Especially considering
that we are about to design some ASICs which we expect to be synced up
better than 100ps (somewhere around 20-50ps, limited by the delay uncertainty
of the cables).

Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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, two SR620s and losing samples

[John Miles]

Agreed with Magnus that there are a lot of possible variables in your setup 
that need to be ruled out.  

Are you using the SR620 driver in TimeLab, or did you find a way to get it to 
emit data continuously via the RS232 port for use with the talk-only driver?  
I've seen occasional instances where a counter has ignored every other trigger 
when used in addressable mode by TimeLab.  It's not always readily 
reproducible, but the counter drivers in the current beta at 
http://www.miles.io/timelab/beta.htm seem to be a bit less prone to that 
behavior.  If you aren't already using the beta, try that.

It's always safest to use counters in talk-only mode when possible, since that 
rules out any timing problems that might arise in a two-way GPIB or serial 
conversation where each individual reading is requested by the software as done 
by the 5313xA, Philips, DTS2070-series, and SR620 drivers.  Some of those 
counters can be used in both talk-only and addressable modes, but I don't 
believe that's true of the SR620, unfortunately.  All of the programming 
examples in the SR620 manual work by requesting each reading individually. 

-- john, KE5FX
Miles Design LLC

> > I have here a setup with four (FPGA) nodes that produce synchronized pulses
> > with a 20kHz rate. I have two SR620s two measure those pulses.
> >

___
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] Timelab, two SR620s and losing samples

[Attila Kinali]

Moin,

I have here a setup with four (FPGA) nodes that produce synchronized pulses
with a 20kHz rate. I have two SR620s two measure those pulses.

Because the SR620s are not fast enought to capture all pulses, and because
i want them to be synchronized, I set up one of the nodes to generate an
additional pulse every 100ms (10Hz rate) 20us before the "main" pulse,
and feed that to the two EXT trigger inputs of the SR620s.

The two SR620s are both connected to an FS725 Rb frequency standard
(mostly because we have them around and nobody else uses them :-)

Now, I use Timelab (running on Windows XP, in a virtualbox on a linux system),
using two serial-to-USB converters (FT232), which are passed as raw USB
devices into windows. Capturing both SR620s together in timelab, I see
one of the SR620s "producing" less samples than the other.
Quite considerably less (it looks like 1-3% less or so).

I have already checked and rechecked the trigger settings, the trigger
voltages etc, but I cannot find why one produces less samples than the other.
I have changed cables, swapped nodes. But it's still the same SR620 that
loses samples.

Another curious thing I see that I couldn't make sense of is, that from
time to time, on both of the SR620s, I see time differences of 1s (yes,
one full second). Given that the FPGAs produce a pulse every 50us, this
shouldn't be possible, unless the crystal oscillator stops.


Any idea what I might have done wrong or what the cause is?

Attila Kinali


-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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 Query (likely noob error)

[Jason Ball]

Thanks John.

Definite Noob issue.   It helps to have the counter in the correct mode as
well ;)

All working as it should be now.

Cheers
Jason.


On Sat, Oct 24, 2015 at 7:54 PM, John Miles <j...@miles.io> wrote:

>
> > -Original Message-
> > From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Jason
> Ball
> > Sent: Friday, October 23, 2015 10:38 PM
> > To: Discussion of precise time and frequency measurement
> > Subject: [time-nuts] Timelab Query (likely noob error)
> >
> > Hi all,
> >
> > I'm afraid this may be a noob question as I've undoubtedly done something
> > wrong, either that or I have some phenominal time sources... more likely
> > I've made an error in an assumption or two.   This should to my mind be
> > within the capabilities of the counter I have, but right now I'm starting
> > to wonder.
> >
> > The problem is I'm seeing a 10s tau of 9.29E-18 which to my limited
> > understanding is highly doubtful.
> >
> > So what have I done wrong ?
> >
>
> Hi, Jason --
>
> Let's take a look at the .tim file (email it to j...@miles.io) --
> probably just a missing/inappropriate scale factor.
>
> -- john, KE5FX
> Miles Design LLC
>
> ___
> 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.
>



-- 
--
Teach your kids Science, or somebody else will :/

ja...@ball.net
vk2...@google.com <vk2f...@google.com>
callsign: vk2vjb
___
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 Query (likely noob error)

[John Miles]

> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Jason Ball
> Sent: Friday, October 23, 2015 10:38 PM
> To: Discussion of precise time and frequency measurement
> Subject: [time-nuts] Timelab Query (likely noob error)
> 
> Hi all,
> 
> I'm afraid this may be a noob question as I've undoubtedly done something
> wrong, either that or I have some phenominal time sources... more likely
> I've made an error in an assumption or two.   This should to my mind be
> within the capabilities of the counter I have, but right now I'm starting
> to wonder.
> 
> The problem is I'm seeing a 10s tau of 9.29E-18 which to my limited
> understanding is highly doubtful.
> 
> So what have I done wrong ?
> 

Hi, Jason --

Let's take a look at the .tim file (email it to j...@miles.io) -- probably just 
a missing/inappropriate scale factor.

-- john, KE5FX
Miles Design LLC

___
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] TimeLab and the N cornered hat...?

[Nick Sayer via time-nuts]

I’m running the latest beta, and I’ve found the spot in Edit > Trace details 
where you tell it the two sources that contribute to a particular dataset. I’d 
expect that having done that and loaded two traces A-B and B-C that I’d be able 
to elect to show the N cornered hat and see something different in the ADEV 
window, but it’s not doing anything. What am I missing?
___
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 N cornered hat...?

[John Miles]

If you're only loading two files, that's definitely not going to work since a 
3-cornered hat requires 3 plots.  In your example, there must be a third plot 
representing A-C, so that each of the three sources will contribute to two 
different plots.  

Apart from that, check for mismatched file parameters.  The way it's currently 
set up, all of the following conditions have to be met before Trace->Show 
separated variances (Ctrl-h) will work:

- A deviation measurement must be selected (ADEV, MDEV, TDEV, HDEV)
- Overlay mode must be enabled with Display->Overlay (o)
- At least three plots must be loaded
- All participating plots need to have visibility turned on (Display->Toggle 
visibility (v))
- All participating plots must have valid Source A and Source B labels
- The source labels must be spelled consistently between all of the 
participating plots
- All participating plots need to have trace history set to 1 (Edit->Trace 
properties (e)->Trace History)
- All participating plots need to have been acquired with the same xDEV bin 
density
- All participating plots need to have exactly the same sample interval (tau 
zero)

The last condition is especially easy to miss if your plots came from a counter 
with "Use incoming data to configure measurement" checked.  It may have 
measured the sampling interval a bit differently in one or more of the plots. 

If you've already checked these points and it still isn't rendering the hat 
traces, zip up the .tim files and send them to john (at) miles.io, and I'll 
have a look.

-- john, KE5FX
Miles Design LLC


> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Nick Sayer
> via time-nuts
> Sent: Sunday, September 27, 2015 8:25 AM
> To: Discussion of precise time and frequency measurement
> Subject: [time-nuts] TimeLab and the N cornered hat...?
> 
> I’m running the latest beta, and I’ve found the spot in Edit > Trace details 
> where
> you tell it the two sources that contribute to a particular dataset. I’d 
> expect that
> having done that and loaded two traces A-B and B-C that I’d be able to elect 
> to
> show the N cornered hat and see something different in the ADEV window, but
> it’s not doing anything. What am I missing?
> ___
> 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.