[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

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

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

> 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

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

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-

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

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 so

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

gt; 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 ru

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

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

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

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 th

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

Re: [time-nuts] Timelab question

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

Re: [time-nuts] Timelab question

On Tue, Feb 21, 2017 at 5:26 PM, Bob Stewart wrote: > Thanks, John. That will certainly get it to work as I expect it to. I doubt > I'm the only one who's lost a dataset due to being distracted and hitting the > enter key to clear the dialog box. > > Wine is just a mess as

[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

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

[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

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 Sims wrote: > At one time Timelab worked well for me under Wine. It's

Re: [time-nuts] Timelab question

On 21 February 2017 at 23:35, Mark Sims wrote: > ... > I plan to package up my TICC and a couple of TADD-2 Mini dividers with a > RPI-3 and the 7" touchscreen display and an Osciiloquartz 8663 DOXCO to > make a small ADEV analyzer box. > Wow! If you can persuade John and

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

Re: [time-nuts] Timelab question

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

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

Re: [time-nuts] Timelab question

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

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

[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

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

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

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

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

Re: [time-nuts] TimeLab

ccepts 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

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

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

Re: [time-nuts] TimeLab

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

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

Re: [time-nuts] TimeLab

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

Re: [time-nuts] TimeLab

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

Re: [time-nuts] TimeLab

On Sun, Oct 9, 2016 at 9:07 PM, Tom Van Baak wrote: > 3) The problems you are running into get far worse the less accurate and > less stable the sources are (such as mains, mechanical, vintage quartz, and > pendulum clocks). So that's why I developed the picPET time-stamping

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 >

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

Re: [time-nuts] TimeLab

adapter this Christmas. >>>>> >>>>> Bob >>>>> ----- >>>>> AE6RV.com >>>>> >>>>> GFS GPSDO list: >>>>> groups.yahoo.com/n

Re: [time-nuts] TimeLab

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

Re: [time-nuts] TimeLab

tmas. >>>> >>>> Bob >>>> - >>>> AE6RV.com >>>> >>>> GFS GPSDO list: >>>> groups.yahoo.com/neo/groups/GFS-GPSDOs/info >>>> >&

Re: [time-nuts] TimeLab

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...@evori

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

Re: [time-nuts] TimeLab

d have to add the ability to >> identify and address multiple devices. >> >> Bob >> >>> >>> Bob >>> - >>> AE6RV.com >>> >>> GFS GPSDO list: >>&g

Re: [time-nuts] TimeLab

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 r

Re: [time-nuts] TimeLab

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

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

Re: [time-nuts] TimeLab

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

Re: [time-nuts] TimeLab

quency 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

Re: [time-nuts] TimeLab

e 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. Havi

Re: [time-nuts] TimeLab

: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

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

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

Re: [time-nuts] TimeLab

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

Re: [time-nuts] TimeLab

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

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

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

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

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

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

[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

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

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,

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

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

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, jimlux wrote: > > I've got a file with

[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

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

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 Camp wrote: > > Hi > > If the

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

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

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

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

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,

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

[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

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)

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

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

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

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

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,

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

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

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 Danielson wrote: The two SR620s are both connected to an FS725 Rb frequency standard (mostly because we have them around and nobody else uses them :-)

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

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

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

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

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

Guete Morge! On Sun, 17 Jan 2016 07:24:32 +0100 Magnus Danielson wrote: > >> Have you tried swapping "role" of the SR620? > > > > Yes, I've done that. Both SR620's lose some samples, but only one of > > them loses significantly more than the other. > > OK. So, the

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

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,

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

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

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

God kväll! On Sat, 16 Jan 2016 06:00:54 +0100 Magnus Danielson wrote: > > The two SR620s are both connected to an FS725 Rb frequency standard > > (mostly because we have them around and nobody else uses them :-) > > It's being used, by you! ;-) There is another one

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

[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

Re: [time-nuts] Timelab Query (likely noob error)

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 afr

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

[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

Re: [time-nuts] TimeLab and the N cornered hat...?

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

  1   2   >