Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a serial device running which I need to read data from(I have absolutely no control over the device itself) except reading its output; using hyper terminal in Windows I am able to detect a meaningful traffic and yesterday when I used cat (or my own little C program to read the data and print it to stdout) it worked fine.

Today, when I use cat/my program all I get is a sort-of corrupted data, yet hyper terminal still shows the data.

What could possibly be wrong? how could it have worked yesterday but not today?

The file I am/was reading is /dev/ttyUSB1

*Please note that I am never running BOTH my program and cat, only one of them at a time.

share|improve this question
up vote 2 down vote accepted

Someone on SO hinted in the right direction; the problem was with the baudrate, it was set to a different value than what I need.

To check the baudrate: stty -F /dev/ttyUSB1
To set the baudrate: stty -F /dev/ttyUSB1 57600 (57600 in my case is the baudrate my device needs)

It's working like a charm now.

share|improve this answer

Serial ports are especially weird beasts. You'll want to use an Old School terminal emulation program. I used to think tip was the best, but nobody seems to have the source for it any more. cu comes with UUCP, and it's a complete hassle to install and configure, don't even bother.

A quick google around tells me that people tend to use minicom these days. Here's a Stack Overflow question that seems like it has some bearing, at least on using minicom to talk to a USB serial device.

Let us know how this turns out. Update your question or leave a comment or something.

share|improve this answer
Solved, someone on SO hinted in the right direction; please see my answer – xci13 May 6 '13 at 1:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.