[time-nuts] TimeLab
djl
djl at montana.com
Sun Oct 9 17:36:23 EDT 2016
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,
> magnus at 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
> <magnus at 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
> <magnus at 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 <kb8tq at n1k.org>
>>>>>> To: Bob Stewart <bob at evoria.net>; Discussion of precise time and
> frequency measurement <time-nuts at 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 <bob at 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 <kb8tq at n1k.org>
>>>>>>> To: Discussion of precise time and frequency measurement
> <time-nuts at 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
> <magnus at 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 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
--
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304
More information about the time-nuts
mailing list