1 Replies - 9078 Views - Last Post: 24 January 2012 - 07:55 AM Rate Topic: -----

#1 fidi   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 1
  • Joined: 24-January 12

RS232 communication - random data sent after some time

Posted 24 January 2012 - 04:05 AM


I'm trying to send some data to serial port. I'm using Aten UC-232A USB to serial adapter and I've installed the supplied drivers for Win7 x64. I haven't found anyone who has had any similar problems with it. The other side of serial cable is connected to another laptop which has a serial port and I'm receiving data in Linux console. I believe the port is configured correctly on both sides (speed 9600, 8 data bits, 1 stop bit, no parity, no flow control).

I've tried some code examples and they all work fine, except:

Sometimes, data is sent correctly, for example, I'm sending characters ABCDEFGH. But usually, they get corrupted, like ACBDEGH, AC??CHEF etc. ...then, after some time, some random is data starts flowing! Mostly unknown characters and the flow doesn't stop.

I've no idea what is happening - I don't know if this is a programming error (most probably not?) or is there a problem with my USB-to-serial adapter or my system.. I could go buy another adapter with a different chipset (the FTDI one, not Prolific like this one). I have no idea what initiates that random flow of data. It happens randomly - sometimes not at all, sometimes almost instantly after I open the port.

Is This A Good Question/Topic? 0
  • +

Replies To: RS232 communication - random data sent after some time

#2 tlhIn`toq   User is offline

  • Xamarin Cert. Dev.
  • member icon

Reputation: 6537
  • View blog
  • Posts: 14,450
  • Joined: 02-June 10

Re: RS232 communication - random data sent after some time

Posted 24 January 2012 - 07:55 AM

With no code there isn't much for us to diagnose.
I have a couple of the Aten adapters and haven't run across such a problem.

From a diagnostic perspective it would help if we could see the actual bytes being sent and received. That way we aren't looking as character interpretations but actual bytes.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1