[time-nuts] timelab(http://www.miles.io/timelab/readme.htm) and HP3132a
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
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
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
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
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
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
On Mon, Mar 27, 2017 at 2:48 PM, Bob Bowneswrote: > 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
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
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
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
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
On Tue, Feb 21, 2017 at 5:26 PM, Bob Stewartwrote: > 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
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
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
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
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 Simswrote: > 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
On 21 February 2017 at 23:35, Mark Simswrote: > ... > 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
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
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, > 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, 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
> 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
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
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
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
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
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
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
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
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
> 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
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
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
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
On Sun, Oct 9, 2016 at 9:07 PM, Tom Van Baakwrote: > 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
> 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
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
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
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
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
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
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 Danielsonwrote: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 Danielsonwrote: 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
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
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 Danielsonwrote: 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
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 Danielsonwrote: > 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
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
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
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
> 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
> 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
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, jimluxwrote: > > 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
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
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 Sayerwrote: > > 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
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 Campwrote: > > 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
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
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 Mileswrote: > > 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
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
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
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
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
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)
> 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
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
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
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
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
> 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
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
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
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 Danielsonwrote: 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
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
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
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
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
Guete Morge! On Sun, 17 Jan 2016 07:24:32 +0100 Magnus Danielsonwrote: > >> 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
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
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
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
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
God kväll! On Sat, 16 Jan 2016 06:00:54 +0100 Magnus Danielsonwrote: > > 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
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
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)
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)
> -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...?
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...?
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.