Actually I don’t recall that Elm Electronics ever made expansive claims about the v1.2 chip being faster than its predecessor. The two main features of the Elm v1.2 were Adaptive Timing and support for Higher Baud rates. Neither of those features necessarily mean faster throughput or pid rate (pids/sec). I suppose some people could perceive both those features as meaning more speed, but that would be misunderstanding both of those features.
Just for your info let’s examine each feature and why they were introduced. Adaptive timing was a clever piece of engineering that overcame a very conservative default setting of the Elm timeout value without user intervention. The Elm timeout value defaults to 200ms and still does even in the v1.3 chip. This figure comes from the original Elm320. Back in those days OBDII implementations were not always as they should be and some vehicles had difficulty connecting if the timeout was set too fast, so Elm took the conservative approach and went with 200ms. Most modern vehicles can handle a timeout value of 50-100ms. So unless the software you were using gave you the opportunity to adjust the timeout value, you were stuck with 200ms and slow responses. The v1.2 chip eliminated that problem by introducing Adaptive Timing, the Elm chip learned what timeout the ECU could tolerate and automatically reduced the timeout value. You may or may not have seen improvements in response speed on your vehicle. You haven’t told us what software you were using or if that software allowed you to optimise that setting. If the settings were optimised then I doubt you would have seen any gain in speed. Of course that is not the complete story, all responses have priorities, so depending on what the ECU is doing, some responses may be slow at one time and faster at another. I think you can probably appreciate, that diagnostics is not primary function of the ECU.
Using adaptive timing or optimising the Elm timeout will usually result in maximum pid rates of approximately 4-5 pids/sec for non CAN vehicles and approximately 18-20 pids/sec for late model CAN vehicles for a scan tool equipped with an Elm 327 v1.2. These figures are approximate because there will always be differences from one manufacturer to another – some do it better than others.
The second feature that the v1.2 introduced was support for Higher Baud rates. I think it was this feature that most people incorrectly considered was going to give them a speed improvement. Non CAN vehicles, gain virtually nothing from a scan tool running at a higher baud rate. The old protocols are slow, so that the original baud rates of 9600 or 38,400 were fine – going to a higher baud rate for those vehicles really doesn’t give you anything, for the old protocols only push out short messages and of course they come out slowly in comparison to the CAN protocol.
CAN vehicles do benefit from faster baud rates – most CAN bus equipped vehicles operate at 500k, so ideally, so should the scan tool. CAN messages, especially Service 06 can be long responses, which can easily overwhelm the small 256 byte buffer of the Elm chip resulting in BUFFER FULL errors as reported by the Elm chip. The software developer has no control of the Elm buffer, therefore if a BUFFER FULL error is contained within a response, that response has to be discarded because the complete response was not received and obviously a partial response is not of any value. If the software is communicating at 500K baud, the same speed as the bus, then it is possible to eliminate BUFFER FULL errors. However, again that is not the end of the story, the only Elm327 v1.2 chipped scan tools that can run at 500k are USB scan tools. Serial scan tools usually require a USB serial cable adapter to connect to a modern laptop, not many of those USB serial cable adapters are capable of running at anything over 230.4k, so BUFFER FULL errors will still occur when using a USB serial cable adapter. The problem is not with the serial scan tool, as serial scan tools can be connected to special high speed serial ports at 500k, but those types of high speed port are not all that common.
So what does the v1.3 chip bring – speed and more speed and the elimination of BUFFER FULL errors at lower baud rates. The new developments of the v1.3 chip are primarily aimed at the CAN protocol, not the older protocols. There are some new features that the older protocols can take advantage of, but the improvements in speed are only marginal for non CAN vehicles. Naturally enough as the CAN protocol is now the universal protocol (all vehicles from Jan 1st 2008) the development of the Elm chip is biased towards the CAN protocol.
I’ll leave it to others to create your video, as I would much prefer you took our OBD 2007 software for a test drive and see the figures for yourself. Our evaluation copy of OBD 2007 is fully functional, limited only by our 7 day activation license. As a conservative figure, OBD 2007 and a v1.3 chipped scan tool will
double the speed for CAN vehicles to around 40 pids/sec. We have had beta testers report speeds of 65 pids/sec on a 2007 Honda Civic and stunning 98 pids/sec on a 2007 Subaru. Both those figures have been confirmed from their respective OBD 2007 log files. The large variations in speed are obviously as a result of the manufacturer’s expertise with the CAN bus. The lowest pid rate of any CAN vehicle I have tested was 38 pids/sec.
From a practical point of view, the fact that BUFFER FULL errors have been eliminated at lower baud rates now means that users don’t necessarily have to throw away their existing serial scan tools when they purchase a CAN vehicle and just as importantly slower Bluetooth scan tools are now suitable for CAN vehicles.
If you want to check for yourself and read up all the new features of the Elm 327 v1.3, there is a newly updated datasheet on the Elm Electronics website
www.elmelectronics.com
Regards
Graham McKechnie
GLM Software
http://www.glmsoftware.com
. I was also hoping for a video, no offence to your software but I am looking for the differences in chip speeds, not your software 
Linear Mode
