slow serial communication

[curejr]

I need to send data to a hardware (OBD car device) using the serial port.
The com port has to be configured to 5 bps 8N1 using no flow control. Using
some examples that I took on the NET I wrote a test program. To test it I connected
a loopback device on the com port and I ran the program. My program seem to be
working but there's something that I don't understand. Sending one byte at 5 bps
should take 2 seconds (1 start bit + 8 bits + 1 stop bit = 10 bits). Since the byte
sent is also received at the same time I was expecting that both operations (sending
and receiving) should take 2 or 3 seconds.

Here's the result that I'm getting from my test program :

[10:39:30.933] Send buffer is [0x33]
[10:39:30.933] Before Send
[10:39:30.934] After Send
[10:39:30.934] Before Receive
[10:39:40.915] After Receive
[10:39:40.915] 1 byte(s) received
[10:39:40.915] Receive buffer is [0x33]

Like you can see it took 10 seconds to do both operations. I verified and the byte
is sent immediately after the send operation (at 10:39:30.934). Can someone help me
to understand why it's taking so long to send and receive one byte ?

By the way I ran the program on my laptop using Knoppix 5.1.1.

Let me know if I posted this question in the wrong forum or if I should post it somewhere
else to get more help.

tks

[Harry Kuhman]

...... configured to 5 bps 8N1 using no flow control. ...... Since the byte
sent is also received at the same time I was expecting that both operations (sending
and receiving) should take 2 or 3 seconds..

Boy, I've never worked with anything lower than 110 baud, didn't know that you could configure any serial ports for slower than that. Glad to hear that you can though. I'm not sure why you say say the byte sent is received at the same time. Of course, the byte sent is indeed received by the OBD equipment when it is sent, but it looks to me like you have to send some command bytes and then the OBD equipment get around to responding, so from the computer's prospective it sends, waits, and then receives data. And clearly with any equipment running at 5bps, speed isn't much of a priority. I'm hard pressed to understand why it's running that slow, even in a potentially electrically noisy automotive environment, and I wonder if it isn't even deliberately talking slow to look like it's doing more than it really is. From what you posted, it looks to me like it's working exactly as intended.

[curejr]

The reason why I'm saying that the byte is received at the same time is because I tested my program with a loopback device. To be more precise I put a wire between the RxD and TxD pin of the com port. This is why I'm saying that the byte sent is received at the same time. The reason of using 5 bps is for a slow initialization of the communication between the scantool and the ECU. It's part of the ISO9141 protocol which I'm not familiar with it. I know that the ECU should reply with a sync byte (0x55) and after the speed has to be changed from 5 bps to 10400 bps. I do agree with you that my program seems to be working as intended but my problem is really the 10 seconds delay. I really don't understand it and I think this will be an issue as I go futher in my project since there will be a delay of 8 seconds (10 seconds - 2 seconds for sending the byte) between the time the ECU sends the sync byte and the time I will receive it.

thanks for your reply!

[Harry Kuhman]

Interesting (but pretty strange) that the speed changes from 5 bps to 10400 bps during operation. But unless you just happen to come across someone else here using this same OBD equipment, I don't think that you are going to get any helpful feedback here. The Linux side of this seems to be working fine. It's the OBD equipment that is strange, but unless there is some way to tell it to operate differently, it seems like it's going to operate with the quarks that you have already told us about. Maybe you can find a forum somewhere where the users talk about OBD and related equipment that would be of more help.

[curejr]

I haven't used any OBD equipment yet. I just wrote a C program that send and receive a byte at 5 bps and tested it with a loopback device. The program that I'm writing will be used with an OBD device later but not yet. I need to make sure my program behave as expected first before to connect it to the OBD device. This is why I'm trying to figure out why it's taking so long to do both operations. Like I said I was expecting to be able to do both in less than 3 seconds. I'm thinking there might be something wrong with Linux or with the program that I wrote. I do agree with you that I should not expect any help in this forum about my OBD device.

thanks again!

[Harry Kuhman]

Well, now I understand better what you are saying, and I agree, it makes no sense. I don't know how the delay is being introduced if it's not from actual OBD equipment. Perhaps it's either a buffering issue or an API issue that trying to prevent the application from getting overwhelmed from too many inbound interrupts. You may even want to look at writing your own low level serial I/O routines rather than using whatever C is using. If you don't yet have the OBD equipment to talk to, you might try hooking up to another computer, just to avoid any potential loopback issues, but from what you have written I rather expect that you'll find that if you send the bytes that you expect to see coming out of the OBD equipment from another computer, you'll also see a long delay before your C program registers the input.

I wasn't too concerned about where this was posted before. It's not really a networking question, it's more of a serial communications question, somewhat related but not the same. I'm starting to think that you might get more reads and a better chance for good feedback if this is moved to the General forum, since it now seems to be more of a programming question. You may also want to post a block of your C code that shows how you are doing the serial read, just in case someone can suggest a better way that will avoid the delay. I'll move the thread for you.