Post by Grzegorz DanilukThank you very much for all your advices.
The device I'm going to 'talk to' is cesium clock with rs-232 interface. So
it is not possible to simply change the interface to differential one.
Connection cable can be short and the transmission speed can be slow. The
most important thing for me is to ensure the long term communication. Not to
lose any data is very important when periodically monitoring cesium
parameters. We are speaking here about months and years of continous
operation. That is why I'm afraid of something 'strange' happens to my
rs-232 interface and communication. Maybe I'm too afraid of strange magic,
but still, is it possible that my rs-232 could change its transmission
parameters as a result of e.g. nearby elecrical interference ? Or, in
general, what bad thing could happen to me in such scenario.
I've had to connect medical vital-sign monitors to ruggedized mobile
computers over RS-232 and write the software for data collection. In
my case, communication was packet-based and each packet had a 2-byte
CRC16 field appended to the end, which made it rather easy to detect
corrupt data. The goal was to have reliable communication for a period
of a few weeks; the time between equipment inspections.
The only real problem I ran into was that certain power events, such
as attaching an external power supply to the computer or turning off
the display, would cause the serial port buffer to overflow and
corrupt one or two packets. This seems to be a peculiarity with the
computers that we're using, since there was no actual data overflow,
just corruption. I've tested everything using regular desktop machines
and never had this problem before. For our purposes, the loss of a
single packet is no big deal.
The point is that the reliability of the connection depends on the
equipment you are using. Use a shielded cable that's as short as
possible. A ferrite bead on the cable might help eliminate
high-frequency noise. Keep the cable away from power cables or
supplies. The lowest usable baud rate should be less prone to
corruption. Beyond that, there really isn't much you can do to prevent
errors at a physical level.
Obviously, be sure to configure your UART correctly (i.e. baud rate,
bits per byte, parity bits, stop bits, and so on). I've never seen a
UART reconfigure itself due to electrical interference, but it is
possible for you to start getting framing errors if the clock
synchronization is off. Here I don't really have any advice for you,
except to test everything as much as you can in its final
configuration.
Avoiding buffer overruns is the responsibility of the software that
you're using, but it can be affected by the OS. Consider the setup of
your system. If you expect a high load on the CPU, be sure to give
higher priority to the program that's reading data from the serial
port. If the program is kept in the run queue for too long, you may
start losing bytes (depending on how fast they are arriving and the
size of the receive buffer). If you're doing some processing of the
data as it arrives, consider running that code in a separate thread
from the one that's reading the serial port. How to design reliable
software depends on the protocol you're using.
Test everything... If it runs fine for a week, it'll probably be ok
for a month. However, I think that expecting the link to work for
several years without a single corrupt bit is asking too much (if that
is your goal). In general, when dealing with RS-232 the best you can
do is detect an error using parity bits or checksum/crc values at the
protocol level. Correcting errors after they happen could be
difficult.
When it comes to changing the interface type, you might consider using
a serial-to-usb adapter. I've used those successfully with an early
prototype of our system, but we later removed them to have a more
secure physical connection. This may or may not be good advice for
you. I'm just throwing it out there in case you start seeing corrupt
data with a regular RS-232 connection. Adding a high-quality USB
adapter (I used Tripp Lite Keyspan) means an additional buffer for
sending and receiving data. It also means more hardware that can fail,
which is why I say that it may not be a good option for you. Also, I
was doing this on Windows and have no idea whether FreeBSD supports
such setup.
- Max