[time-nuts] Timelab, two SR620s and losing samples
magnus at rubidium.dyndns.org
Sun Jan 17 01:24:32 EST 2016
On 01/16/2016 08:48 PM, Attila Kinali wrote:
> God kväll!
> On Sat, 16 Jan 2016 06:00:54 +0100
> Magnus Danielson <magnus at rubidium.dyndns.org> 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 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).
>> 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?
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
>> 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.
More information about the time-nuts