One serial problem I should remember

August 1, 2006

I hate RS-232 serial connections, because something always goes wrong whenever I have to deal with them and then I have to figure out how to make the things work. Needless to say, there are next to no common diagnostic tools for troubleshooting serial communication problems.

In this case the problem was a mysterious inability to type anything to the remote device when I could receive the remote device's output fine. For my future reference, this can be caused by having hardware flow control on when the remote device doesn't support this.

(Don't ask why something in this day and age doesn't support hardware flow control. (And the device in question does seem to be from this age, since its manual is copyright 2005.))

Also for my future reference:

  • setting odd or even parity when the device expects none mostly just garbles output from the device, while my input is echoed back fine.
  • setting space parity is generally OK, but setting mark parity or the wrong bit count clonks into things hard, with garbled output and no input.

Once I club it suitably, minicom turns out to be a reasonably good environment for experimenting with this, although I still like the minimalism of cu for a lot of routine serial communication. (Like cu, minicom appears to have a few problems with exiting promptly when I ask it to.)

Written on 01 August 2006.
« The limitations of Unix atime
In praise of installing from Live CDs »

Page tools: View Source.
Search:
Login: Password:

Last modified: Tue Aug 1 15:49:42 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.