Basically, the software would have to know about the new features of ELM327 v1.2 to make use of them. ProScan 5 is the only one I tried and v1.2 didn't make a difference in that software. I don't know which, if any, fully support the new features.
The OBD 2007 software by GLM Software recently started supporting the higher baud rates of the ELM327 v1.2. I tried out the demo today in my 2006 Corolla but it was not as fast as I was expecting. I was getting maybe 4-5 readings per second with the serial port at 115kbps and the elm timeout at 50ms. I also tried it at 230kbps but it didn't seem to make any difference in speed.
I don't know why it can't just be faster. A baud rate of 115kbps should be able to keep up with a 50ms response delay (which should result in almost 20 reads per second).
Since the Toyota uses an ISo protocol that operates at 10400 Baud going to a much higher speed does not really buy much as the car bus is the bottle neck and not the speed of the communication between the scantool and the PC. What you are seeing demonstrates that in some cases the high speed is just a hype, now the speed does come in handy for protocols such as CAN but not for the other protocols.
Thanks for trying out OBD 2007. I would be very interested to hear your feedback about how OBD 2007 performed in your car computer.
A couple of points, about the Elm327 1.2 chip and OBD 2007ís support for those higher baud rates of the 1.2 chip. Paul was quite right, in that if your vehicle uses one of the older protocols such as ISO 9141-2, then you will not benefit from the faster baud rates that OBD 2007 supports, due to the fact that your vehicleís bus is only running at 10.4k baud. What you reported for your vehicle of a pid rate of 5 pids/second, is about what I would have expected for an ISO vehicle. There is a big difference between ISO and CAN Ė you can expect a pid rate of 22 pids/sec for 500k CAN.
However I disagree with Paulís next statement, that the higher speed of the Elm327 1.2 is just hype. Speed is particularly important when it comes to communicating with vehicles running the CAN protocol, especially if they are using the 29/500k CAN protocol, you now see appearing in late model vehicles. One of the limitations of the Elm327 chip is its small 256 byte buffer. It is very easy, for a late model vehicle to simply overwhelm this buffer and in turn produce a BUFFER FULL message. A buffer full response is an indication that the 256 byte internal buffer has overflowed, so the response that was meant to be processed has to be thrown away, because it is not complete.
We have done extensive testing with a customer in Kansas with a 2007 Honda Civic running the above protocol, which was giving BUFFER FULL messages with OBD 2007 on Service $06 (On Board Monitoring) responses from a scan tool based on a 1.1 chip, like your old chip.
The people at Scantool.net were kind enough to provide two ElmScan5s for this test. One was an ElmScan5 serial tool using a USB Serial adapter and the other was an ElmScan5 USB. Changing to either of the 1.2 chipped ElmScan5s and running at the default 38400 baud did NOT prevent the BUFFER FULL errors. However when OBD 2007 increased the baud rate to 500,000 baud, the BUFFER FULL errors were completely eliminated. The BUFFER FULL errors were present at any baud rate except for 500,000 baud, the speed of the CAN bus.
Attaining 500,000 baud is the next problem. All USB serial adapters I have tested fail at any baud rate above 230,400 baud. Those failures, you would think then rule out the ElmScan5 serial scan tool for late model CAN vehicles. However the fault is not with the scan tool, but with the USB serial adapter. If the serial port of the laptop is replaced with a high speed serial port, then the ElmScan5 serial scan tool will connect at 500,000 baud. Iíve no doubt there must be high speed USB serial adapters out there, but as yet I havenít come across one.
The ElmScan5 USB scan tool does not suffer from this problem and will connect at 500,000 baud every time, so it does become the Elm327 scan tool of choice, if your vehicle is prone to BUFFER FULL errors and must connect at 500,000.
Paulís OBD Pro scan tool evidently does not suffer from this problem because of his unique double buffering feature. OBD Pro is not based on an Elm327 chip, but just emulates the command set of the Elm327 chip. Iíd like to approach Paul and see if he is willing to provide an OBD Pro to test on the same vehicle.
I hope any one reading this will take the above into account, if they are thinking of purchasing a new vehicle or a scan tool. All vehicles manufactured since Jan 1st 2008 now run the CAN protocol and I expect most manufacturers will keep exploiting the CAN protocol and include even longer responses in the output of their Service $06 and Service $09 modes. After all there is nothing in the OBDII specification that states that a scan tool should only have a 256 byte buffer.