[time-nuts] Timelab, two SR620s and losing samples
magnus at rubidium.dyndns.org
Mon Jan 18 01:49:31 EST 2016
On 01/17/2016 10:49 PM, John Miles wrote:
>> Therefore, talk-only mode is a big advantage in terms of decoupling
>> on RS-232 and makes almost no difference on GPIB.
> That's not the case when it comes to counters. By timing issues, I wasn't referring to layer-1 handshaking, but rather the interplay between the GPIB software application, the network or bus connectivity between the app and GPIB controller, the controller itself and its firmware, and an addressable counter that returns each measurement only in response to a command from the app. The difference in performance between a talk-only connection and a two-way conversation can be substantial. Yes, everything runs in lockstep, but the sum of the delays and latencies in each of those stages can easily exceed 0.1 second. In Attila's case there are also VM crossings in both directions to worry about.
> The counter, unlike any of the other participants in the conversation, is working on a deadline. Everything in a counter tends to happen in the "foreground," so to speak. If the counter takes too long to interpret and execute a GPIB command, it may fail to rearm itself in time for the next trigger. That's never a problem in talk-only mode, at least not at rates we're concerned with here, because the counter never has to do anything but send out data.
It was time that we started to talk about this total picture.
Add that some GPIB interfaces uses USB-to-serial chips and then
serial-CPU-GPIB. Many instruments uses a GPIB chip having the low-level
logic to off-load the CPU. The SR620 for instance uses the TMS9914 GPIB
controller chip, which does much of the hand-shaking, but does not
offload the CPU much in regards to FIFO-buffering, which is typical of
its age. Still, much of the lower level stuff gets the boost it needs.
The SR620 has maybe not the powerhouse processor, so that should be a
limitation by itself. Interestingly the SR620 uses a Z80 as a IO
processor to draw on XY scopes.
There is more handshake in the GPIB than pure flow-control, but I've not
seen it used and honestly I haven't tried it myself. It seems like the
support is there and documented for many instruments. Shouldn't we try
to use that to aid the ping-pong between instruments?
Building up the system, we should think about how the system maintain
its properties, data flow, arm-trigger mechanisms.
More information about the time-nuts