[time-nuts] Timelab, two SR620s and losing samples
artgodwin at gmail.com
Sun Jan 17 22:57:57 UTC 2016
If you have RS232 connections, won't you have one for each device ? Whereas
with GPIB, you'll (probably) only have one bus. The GPIB bus will arbitrate
and avoid both instruments talking at the same time (this might not be true
in talk-only mode since there's no target address involved) but it doesn't
provide two completely separate channels.
On Sun, Jan 17, 2016 at 1:01 PM, Magnus Danielson <
magnus at rubidium.dyndns.org> wrote:
> On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote:
>> In message <569B8B2E.5070604 at rubidium.dyndns.org>, Magnus Danielson
>> I think you should develop that line of thought, to detail why it helps
>>>>> on GPIB and why not on serial.
>>>> It's really very simple: RS-232 sends blind, you don't even need to
>>>> know if there is a receiver or what it does. If the receiver cannot
>>>> keep op, data is simply lost.
>>>> GPIB handshakes every byte, so the actions of the receiving end affects
>>>> the transmitting end - in particular if the receiver cannot keep up.
>>> OK, you where thinking about the flow-control.
>>> You can have RS-232 wired up to do flow-control (hardware-flow-control),
>> But the important point is you don't have to do that, all you need
>> is two wires: GND-GND and TXD->RXD
>> With GPIB that option does not exist, sender and receiver are always
>> in lock-step.
>> Therefore, talk-only mode is a big advantage in terms of decoupling
>> on RS-232 and makes almost no difference on GPIB.
> If we can assume the consumption is fast enough to keep track, yes.
> If it's not, flow control for this situation helps the border case
> somewhat, but if you are too slow, you are screwed anyway.
> In the case that Attila describes, the flow-control helps over the various
> borders, especially as scheduling plays tricks with us. Running virtual
> applications like that does not help to get a grip of control over how data
> is transfered and when. If it where only to get it straight into an app
> really talking to the serial ports, sure, but I do not trust the
> virtualization to handle it all to well.
> Not that hardware flow-control would in itself help much, but anyway.
> Regardless, if the TimeLab needs to send commands back to the counter over
> the virtualization border, then getting things scheduled properly in time
> isn't really guaranteed.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
More information about the Time-nuts_lists.febo.com