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] Rare HP clock

Somebody must have really wanted this thing—sold for over $800! Jeremy On Monday, October 3, 2016, wrote: > I have worked on these and the electronics is almost always working, or > easily repaired. > The mechanical can cause problems depending on how much "time" it has on >

Re: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?

Bob, I just looked at the clock I am not using and it is 1818-2295A, it is not convenient for me to check the other one as it is running and in a place where I would have to disconnect it to get it out. I could dump this ROM for you but it may take me a few days as I have other things on

Re: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?

Hi Bob et al: I have 4 of these, got some time ago. Here is the data from the ROM's: s/nRom no 2510A04059 hp1818-2295A 2335 2136A03167 hp1818-2295A 0844 this one white ceramic with lotsa gold; the eldest. 2702A04579$M$hp1818-2295A 2912 this one costcutting.

Re: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?

Hi Tom & Paul, Some progress with the HP 59309A clock debug. Built a ROM reader (Teensy++, a 28 pin WW socket, jumpers) and read out the HP 59309A U2 ROM. Compared the user manual to my readings, found three stuck output bits out of sixteen, and another few dozen assorted differences out of

Re: [time-nuts] Inexpensive Alternative to a 5120A

Hi > On Oct 9, 2016, at 6:18 PM, Chris Albertson wrote: > > Likely the lowest cost way to get into that is with a TV tuner USB > dongle. They cost about $20. People are able to get about 2.4 mega > samples per second. Except that you need about 30 mega samples

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

Re: [time-nuts] Inexpensive Alternative to a 5120A

Likely the lowest cost way to get into that is with a TV tuner USB dongle. They cost about $20. People are able to get about 2.4 mega samples per second. Not a lot of dynamic range but you can control that.Use a mixer to move the signal of interest into the range the tuner can handle.

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

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

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

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

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

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

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

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

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

Hi > On Oct 9, 2016, at 1:22 PM, Magnus Danielson > 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

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

Re: [time-nuts] TimeLab

FWIW, I have only tried timelab reading a live ascii log file. On Sunday, 9 October 2016, Magnus Danielson 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

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

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

Re: [time-nuts] TimeLab

Hi > On Oct 9, 2016, at 12:27 PM, Bob Stewart 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

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

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

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] Venus838LPx-T PPS stability measurements

As a control, I repeated the test with a GlobalTop PA6H module. Again, the reference is a Thunderbolt, so it’s not completely clear how much of the wander to attribute to the reference and how much to the DUT. The residual this time is on the order of 60ns - still surprisingly high. The DUT is

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

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

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

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] Prologix USB-GPIB Controller

How do you know the product you "paid more money" for is not a counterfeit? The best you can do is to go to a source that you trust, for some reason, and exercise a right of return. For instance, I have found counterfeit capacitors in products from HP (in power supplies). They looked like

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] Prologix USB-GPIB Controller

On 8 October 2016 at 02:13, Hal Murray wrote: > > They get counterfeited a *lot*. > > Is that true for relatively obscure things like the Prologix GPIB > controllers > that aren't high volume? > I would have thought the Prologix GPIB controllers no more obscure than the

Re: [time-nuts] Inexpensive Alternative to a 5120A

Hi Randal, On 2016-10-07 18:52:57, Cube Central wrote: Is there an alternative that someone could point me to that would cost only a couple hundred rather than (what I expect) is a couple thousand? How would I go about gathering the data needed for these nifty ADEV graphs I see floating

Re: [time-nuts] Frequency distribution design-basic-module v 4.1

Sorry for the broadcast. Jim, N1JR, I want to answer to your direct email about the distribution amplifier but there are some problem in your email basket. please verify. Luciano www.timeok.it From "time-nuts" time-nuts-boun...@febo.com To time-nuts@febo.com Cc Date