Some times serial port read giving converted values [ Junk values]

Question

configuring the serial port is given below

// open serial port
/*  O_RDWR means that the port is opened for both reading and writing
 *  O_NOCTTY means that no terminal will control the process opening the serial port
 */
fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY ); // /dev/ttyS1
if (fd <0)
    perror(MODEMDEVICE);

tcgetattr(fd,&SerialPortSettings); /* save current serial port settings */

/* Set Baud Rate */
cfsetospeed (&SerialPortSettings, (speed_t)B230400);
cfsetispeed (&SerialPortSettings, (speed_t)B230400);

SerialPortSettings.c_iflag &= ~IGNBRK;         // disable break processing
SerialPortSettings.c_lflag = 0;                // no signaling chars, no echo, no canonical processing
SerialPortSettings.c_oflag = 0;                // no remapping, no delays

/* Setting other Port Stuff */
SerialPortSettings.c_cflag     &=  ~PARENB;              /* No Parity            */
SerialPortSettings.c_cflag     &=  ~CSTOPB;              /* Stop bits = 1         */
SerialPortSettings.c_cflag     &=  ~CSIZE;               /* Clears the Mask       */
SerialPortSettings.c_cflag     |=  CS8;                  /* Set the data bits = 8 */

SerialPortSettings.c_cflag     &=  ~CRTSCTS;           /* Turn off hardware based flow control */
SerialPortSettings.c_cc[VMIN]   =  0;                  // read doesn't block // specifies the minimum number of characters that should be read before the read() call returns
SerialPortSettings.c_cc[VTIME]  =  10;                 // 1 seconds read timeout
SerialPortSettings.c_cflag     |=  CREAD | CLOCAL;     /* Turn on the receiver of the serial port */
SerialPortSettings.c_iflag &= ~(IXON | IXOFF | IXANY); /* Turn off software based flow control  */


tcsetattr ( fd, TCSANOW, &SerialPortSettings ); //TCSANOW tells to make the changes now without waiting

below given the expected output, which is coming 5 in 3-4 times

14-Jun-16 15:41:32.300 [RX] - :010400000036C5<CR><LF>
14-Jun-16 15:41:32.316 [TX] - :01046C00009FDA740049FF000085066AEB1E0F00003AFE00007B1F00040000000B000400000000000000003F8000002B4DDEB375E0EEA0000000044E1DD31400001F1E4D42312E302E300022D0837A33303030525300C6BB4187C05445542F414900AF6EFDFBFF937EA47A5F3D65BFA5<CR><LF>
14-Jun-16 15:41:32.341 [RX] - :01046C00009FDA740049FF000085066AEB1E0F00003AFE00007B1F00040000000B000400000000000000003F8000002B4DDEB375E0EEA0000000044E1DD31400001F1E4D42312E302E300022D0837A33303030525300C6BB4187C05445542F414900AF6EFDFBFF937EA47A5F3D65BFA5<CR><LF>

below is the output which I am getting 1 time in every 5 times

14-Jun-16 15:41:32.596 [RX] - :010400000036C5<CR><LF>
14-Jun-16 15:41:32.602 [TX] - :01046C00009FDA740049FF000085066AEB1E0F00003AFE00007B1F00040000000B000400000000000000003F8000002B4DDEB375E0EEA0000000044E1DD31400001F1E4D42312E302E300022D0837A33303030525300C6BB4187C05445542F414900AF6EFDFBFF937EA47A5F3D65BFA5<CR><LF>
14-Jun-16 15:41:32.608 [RX] - 2E<NAK>ê¢‚‚¢Ê2e<ENQ>‚‚‚Âª‚²²<LF>
U%**<ENQ>2<ENQ>‚‚‚š<LF>
eU<LF>
‚‚‚º<DC2><NAK>2<ENQ>‚‚¢‚‚‚‚‚‚‚<DC2><ENQ>‚‚¢‚‚‚‚‚‚‚‚‚‚‚‚‚‚‚‚š2…‚‚‚‚‚'<DC2>E"EUJjÓSS<DC4>¦TT(&LL˜˜00044E1DD31400001F1E4D42312E302E300022D0837A33303030525300C6BB4187C05445542F414900AF6EFDFBFF937EA47A5F3D65BFA5<CR><LF>

Can anyone help me, I am confused. Did I missed any configuration settings or ?

Since the data looks like lines of ASCII text, you would be better off using canonical mode (rather than the timed raw mode that you're using). Since you're using RS-485, is that "RX" an echo of the previous "TX"? Have you tried to suppress that echo (e.g. a handful of Linux serial port drivers have RS-485 mode to disable the receiver while transmitting)? See [Setting Terminal Modes Properly](http://www.chemie.fu-berlin.de/chemnet/use/info/libc/libc_12.html#SEC237) — sawdust, Jun 14 '16 at 19:10

score 1 · Answer 1 · answered Jun 14 '16 at 10:51

That looks like it can be anyone of the following issues:

Serial phase loss

The driver ( or HW transceiver ) is misinterpretting where the start bit of a serial transmission is, and as such is misinterpretting the data.

Framing error

The driver ( or HW transceiver ) is misunderstanding a single bit of the transmission. This can lead to serial phase loss. Measure rise-time and signal attenuation with an oscilloscope to understand if this is your issue.

Spurious noise

There is a noise on the transmission line for brief periods. This noise may only occur slightly before or during the corrupted serial data. If you have a logging oscilloscope, then you can record a longer waveform and analyze a longer transmission. If you don't have a logging oscilloscope, a hacky way to debug this is to modify the user-space or driver code to set a gpio high as soon as the buggy data is seen, you can then connect this gpio to the oscilloscopes trigger to freeze the frame when the error occurs. You can then use manual decoding techniques to understand if the waveform visible on the scope was correctly framed or not.

Driver error

There are a multitude of software issues that can have a driver stepping on itself and destroying the data.

Cabling issue

You didn't write what type of serial transmission this is, but grounding connections are very important, and you must pay attention to avoid ground loops.

Good luck!

Thanks vittorio88, I am using the RS485 Serial communication. What I need to do to work it properly. — tharunkumar, Jun 14 '16 at 11:23
On the software side, try the following things: Enable break processing; Lower baud-rate to 9600 or 38400; Other than this you need to look at the waveform with an oscilloscope. — vittorio88, Jun 14 '16 at 13:16
You've tried to list almost every possible source of bad read data but the most obvious -- the user's program. — sawdust, Jun 15 '16 at 18:56