# Thread: Creating software for ELM327 -- Maximum refresh rate?

1. ## Creating software for ELM327 -- Maximum refresh rate?

Hey,

I was hoping someone could help me calculate the max theoretical refresh rate for ELM327 devices, assuming the ECU keeps up with requests. ELM327v 1.4 supports a maximum bit rate of 500kbaud. I'm sending OBD requests over CAN. So in the worst case scenario to request a single PID I'm using 8 data bytes. According to this awesome site:

This corresponds to a message length of 111 bits after the rest of the frame bits are put in... And it says the max transfer rate is about 290kbps on a 500kbaud bus. Dividing the two,

290000 bps / 111 bits = 2612 messages per second. For a single request and response, there's two messages; so to figure out the response rate, divide by two; 1306 responses per second. There's also the '>' ready response indicator from the ELM that's sent back (I'm assuming echoes are off), other misc characters, internal processing the ELM needs to do, and bus arbitration delays (though I think that's accounted for in that site). So using a FoS of 2, I'm halving the response rate to 650 responses/second.

I've never heard of anyone getting rates like this with an ELM devices; videos and stuff I see on youtube typically show a refresh rate of like, less than 10Hz. My own experiments have been able to get rates down to 20-30Hz as being the max rate that my device supports. Even at this rate I get erroneous data fairly often. Are these awesomely high refresh rates attainable? Also, I'm assuming my ECU is not the limiting factor here as others have been able to log the same car at a refresh rate of ~1000Hz with a direct CAN to USB device.

2. iirc, there are two baud rates we are talking about here. The speed of your connection with the scantool, and the scantool's connection speed with the car. The scantool's connection with the car is purely protocol based, meaning, it'll have a set limit depending upon the protocol you use. From my observations doing obd-II stuff, I see pretty much what you are seeing 20-30 responses per second. Other don't even get that many. however when I listen to the bus traffic in 33.3kbps SW CAN mode, I see many more messages per second than just 30. I think your ECU is going to be the limiting factor when doing obd-ii stuff.

You didn't really tell us what software you are creating obd-II? CAN bus stuff?

my 2 cents...

3. I'm using Qt/C++ to talk to the ECU. I'm using a serial port library called QextSerialPort and it supports interrupt events, so I send a request, then send the next one as soon as the little '>' ELM prompt appears. The connection from my computer to the OBD cable is 500kbaud, and I'm sending service requests over the car's high speed 500kbaud CANbus (pins 6 & 14?) on the OBD port.

By SW CAN mode you mean monitoring only? I should try that and see if I can pick up messages faster than ~30Hz. I'm also going to see if multiple requests (still single request frame) would allow for a decent speed increase. I've tested my software on a Touareg, Impreza, and a 3, all with similar results in terms of refresh rate.

4. Originally Posted by preet
I'm using Qt/C++ to talk to the ECU. I'm using a serial port library called QextSerialPort and it supports interrupt events, so I send a request, then send the next one as soon as the little '>' ELM prompt appears. The connection from my computer to the OBD cable is 500kbaud, and I'm sending service requests over the car's high speed 500kbaud CANbus (pins 6 & 14?) on the OBD port.
Interesting. What are you talking to the ECU for? I've written a Qt/C++ thingy to talk to the car as well. I use QextSerialPort for parts of it.

By SW CAN mode you mean monitoring only? I should try that and see if I can pick up messages faster than ~30Hz. I'm also going to see if multiple requests (still single request frame) would allow for a decent speed increase. I've tested my software on a Touareg, Impreza, and a 3, all with similar results in terms of refresh rate.
I both read and write to the SW CAN. I don't expect replies for anything I'm sending though (generally body control messages) --at least, I don't currently care if anything replies to my messages. Are you writing messages to a specific module and expecting a reply back?

5. I'm creating a carputer front end. Here's a really old version:

I want to implement logging and gauges for my system.

I'm only talking to the ECU module through the OBD port and I do expect replies back. The way I'm doing it right now is with a request queue and I assume the replies from the ECU match up; so if I send requests 1, 2, 3, I expect to get responses that correspond to 1, 2 ,3 in the same order. This isn't the greatest implementation but I thought it'd be okay for some prelim testing.

Pretty bummed about the speed though; another forum member here was able to log with some insane speeds with a different device: http://www.mp3car.com/engine-managem...adapter-2.html

6. The other guy claimed he was getting 100 responses per second using multiframe responses. Have you tried turning on multiframe? It also appears you are using OEM specific diagnostic messages. Have you checked to see if the values you want aren't just broadcasted as part of normal bus messages between modules?

I like your software. I like that it runs on Linux. Have you ever thought of developing it to work on a system like MeeGo? I'm guessing you did it using Qt Quick? If so, check out meego-ux-components, a qml component library that also works on ubuntu. I'm also wondering if nobdy would make your life easier. You can sometimes get more bang for your buck by collaborating with existing open source projects and contributing to larger ecosystems .

7. 1600 CAN messages per second on a 2009 Prius via OBDLink:

https://www.scantool.net/forum/index.php?topic=4745.0

8. Originally Posted by Vitaliy
1600 CAN messages per second on a 2009 Prius via OBDLink:

https://www.scantool.net/forum/index.php?topic=4745.0
This is just raw monitoring with periodic queries right?

9. Right.

10. Interesting projects. Probably the scan rate is a function of several things, the CAN utilization and bandwidth, ECU latency, and the ELM latency. Without network sniffers on the CAN, or a CPU monitor in the ECU it's difficult to determine the bottleneck. My guess it is in the ECU - it has to work on priority processing, just like UNIX. It's foreground tasks are controlling the engine and systems (mixture, throttle, timing etc.) Then at the lower priorities are tasks handling OBD2 requests and other communications, these would be like the "nice" processes in LINUX. I was wondering what was the requirement for such a fast scan rate you're trying for?

My view of ODB2 is that it doesn't have spec requirements for any minimum scan rates, so you basically get whatever is available. It was originally designed, and still the main purpose is for emissions regulations and data. So all sensor information that we get is just an extra bonus and not guaranteed to have any speed or performance. I think for such high scan rates the protocol needs to be re-worked or enhanced. The method of one PID request followed by the response is too slow and inefficient for fast scans, though good for interactive ad-hoc type queries (I think this is the original design goal of the protocol). To get such fast data throughput, the protocol would need to handle multiple PIDS per request. This eliminates the latency overhead in the request/response cycle (If you are familiar with X-Windows in UNIX and wonder why it is such a slow windowing tool, it is because of the protocol being so "chatty"). So, for example if you had a dashboard page with 20 PIDS displayed, you send a single request for the 20 pids in a list, and get a single response back with all of them. The performance cost of this request cycle is only a little more than a single PID request with 20x (or more) throughput. Of course this is way beyond OBD2 specs as they exist now, but would be a good extension of the protocol.

Just as some background, a while back I wrote my own tool, using Excel and VBA. Windows and VBA is slow by LINUX standards, but plenty fast for OBD2, and ECU's as we are discussing. It works great, and have been using it for months, I'm adding things to it all the time, but my complaint is the same here, the scan rate. As a note to message sequencing, I don't think OBD2 guarantees sequencing of all requests, though for practical purposes they seem to arrive in the request order. This is why the OBD headers always contain the Mode (with 0x40 or'd), and the multi packet messages (VIN for example) have sequence tags. I did the same in my system for simplicity (assumption that everything arrives in sequence) but I think I may need in future to add checking.
Just my 2 cents on the topic, hope it is useful.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•