Uwe Klein wrote:
> Martin Burnicki wrote:
>
>> So the behaviour should depend on the implementation of an individual
>> converter type. BTW, similar problems arise with serial-to-LAN converters
>> which redirect a serial data stream using IP packets.
>
> I have used the standard pl2303 type converters
> and their bastard brethren ( to make an
> existing RS485 based daisychained system "USB ready" )
>
> communication to this system was a fast chitchat @38400 Baud:
>
> every second {
> foreach slot_used {
> send <STX><BoxAddr><SlotAddr><payload message with linefeed>,
> wait for response including linefeed,
> send <ETX> // to deselect the current slot
> }
> }
>
> ~30 slots used.
> I never had any latency problems.
Some times ago we had made some tests with some serial-to-USB converters
which are connected to the PC via USB and provide a serial port to which
serial devices can be connected. We have been using our GPS receivers which
send a serial time string once per second as soon as possible after a
second changeover. The jitter of the serial output is 1 bit time depending
on the baud rate, i.e. ~52 microseconds @ 19200.
Some of the tested devices introduced a very low latency whereas others
indroduced a much higher latency. So this depends in fact on the maybe the
chip set and in any case the driver/firmware used for the converter.
> Thus my guess is that these latency may lie in the firmware running
> on the sirf chipset.
Of course, if the firmware already inserts some latency then the
serial-to-USB converter is not to blame and can not eliminate it.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
