[time-nuts] TimeLab

KA2WEU at aol.com KA2WEU at aol.com
Sun Oct 9 19:02:22 UTC 2016


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.



More information about the Time-nuts_lists.febo.com mailing list