reliability of RS-232 connection

m4rtin · 10-24-2011, 05:12 AM

I have a device connected directly(without any RS232-to-USB converters) to serial port on my PC(DE9 socket, RS-232 serial protocol) with ~1m cable. If I copy chunks of configuration lines into terminal(I use minicom and C-Kermit), there will be mistakes (sometimes some characters missing, space characters added etc). Hardware flow control and software flow control doesn't help either. Cable is not near to possible interference sources. There will be mistakes even if I copy in ~100 line parts. However, if I copy line-by-line, I have had never any issues.
Why do errors(some characters missing, space characters added etc) appear in case of chunks of configuration lines are pasted into terminal?

btmiller · 10-24-2011, 06:10 AM

Make sure that the connection is set up on the host end the way the device expects it to be (i.e. number of data bits, stop bits, parity, and flow control settings match between the PC and the device). If that fails, the only thing I could think of would be a bad cable ... maybe you could try a different cable and see if that clears up the problem.

michaelk · 10-24-2011, 06:57 AM

What do you mean by copy chunks of configuration lines into terminal?
What baud rate are you using?

m4rtin · 10-24-2011, 08:31 AM

Quote:

Originally Posted by btmiller

Make sure that the connection is set up on the host end the way the device expects it to be (i.e. number of data bits, stop bits, parity, and flow control settings match between the PC and the device). If that fails, the only thing I could think of would be a bad cable ... maybe you could try a different cable and see if that clears up the problem.

Device expects 9600Bd 8N1. I have already tried with another cable.

Quote:

Originally Posted by michaelk

What do you mean by copy chunks of configuration lines into terminal?
What baud rate are you using?

Baud rate is 9600 Bd.
I mean if I copy for example 1000 configuration lines(one line is one command) from the text file into clipboard and then paste those lines to minicom window. Example of the part of very short(16 lines) configuration file(Cisco switch):

Code:

interface FastEthernet1/0/40
 description test
 switchport access vlan 630
 switchport mode access
 switchport nonegotiate
 switchport port-security maximum 100
 switchport port-security
 switchport port-security aging time 5
 switchport port-security aging type inactivity
 logging event trunk-status
 logging event subif-link-status
 load-interval 30
 no cdp enable
 spanning-tree portfast
 spanning-tree bpdufilter enable
end

I think it's related to inner workings of RS-232.. As far as I know, there isn't error correction code implemented in RS-232.. Maybe somebody here has experienced similar behavior when pasting lot of configuration to a device at once

michaelk · 10-24-2011, 09:06 AM

Its not a matter of the workings of the RS-232 protocol but how minicom works. AFAIK it is not designed to do this i.e the capability to accept chunks of data via copy/paste

Instead use the ASCII file transfer function

salasi · 10-24-2011, 09:48 AM

(sorry, this was submitted earlier, but something didn't work)

Quote:

Originally Posted by m4rtin

(sometimes some characters missing, space characters added etc).

The usual cause for anything like this is buffer over-runs. Also possible are data clock mis-matches (ie, inexact baud rates, which should never happen, except in development, but that's no guarantee that it doesn't), incorrect rising/falling edges, incorrect spec compliance (voltage levels are quite widely specified, and it is sometimes cheaper to run right to the very edge of what is allowable, even though that reduces noise margins).

Assuming developed products (as opposed to products in development), there is probably a 95% chance of it being buffer problems, and while they are likely to be caused by the interface itself, there is also the possibility that if, eg, an OS does not respond to characters being present as quickly as happened when the system was originally tested, that could also cause loss of characters.

These usually get worse at higher data rates, so, if there is any flexibility to use lower data rates, that can be worthwhile.

start/stop/parity errors would normally cause wholesale data corruption, so it would be unlikely that these are the issue here, as you would be unlikely to even get the smaller chunks of data through uncorrupted.

Quote:

Originally Posted by m4rtin

Hardware flow control and software flow control doesn't help either. Cable is not near to possible interference sources.

You can configure hw flow control in many ways; if you were to count all of the combinations at one end (with the full set of connections, and it is not clear that all will be present or even used correctly) there are probably close on 100 you could use; obviously that squared when you count both ends. Out of those, the majority will not work, and in some cases, only one will work reliably although several may well look to work, if looked at superficially and at a low or unsustained data rates.

SW flow control really ought to always work (if supported at both ends), but it does limit the data that you can send, because if your (explicitly) transmitted data can include ^S/^Q, then that obviously can't work reliably, either.

It probably isn't (external) interference, if you know that you away from other sources of electrical noise and with short cables; it could be failure to connect both ends to the same ground potential. Note that screened cables can prove unhelpful here; while they do reduce noise, they also slow the edges of the data - this is almost certainly irrelevant with such a short connection, but can be a factor with medium length connections.