[time-nuts] Timelab, two SR620s and losing samples
attila at kinali.ch
Sat Jan 16 14:48:08 EST 2016
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 :-)
> 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.
> 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?
> 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.
> 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?
> 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.
> > 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.
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).
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
More information about the time-nuts