obd Archives - reactive music

February 19, 2013December 31, 2013

Car engine enhancement with Max and OBD-II

Much of our driving experience is wrapped up in sounds that happen when you press the pedal to the metal. Like Superman emerging from a phone booth, this 2006 Jetta seems different. The project connects RPM data from an OBD2 diagnostic sensor with the input of the car radio. Via synthesizers.

[update 11/2013 – source code is available at https://github.com/tkzic/automax – this version features

V8 engine
Jet engine
Spaceship
Star Trek TOS transporter button
Korg nano-control Midi controller interface]

This project uses the RPM data from an automobile OBD-II port to control the engine speed of an engine simulation from Andy Farnell’s book “Designing Sound”

Here’s the patch that polls and translates OBD-II data

patch is tkzic/automax/rpm4.maxpat

Here’s a Max version of the Farnell car engine simulation:

patch is tkzic/automax/waveguide_engine2e-1.maxpat

November 21, 2012June 13, 2014

Observations on using OBD-II port polling speed

There are limits to the polling speed you can use with Max…

With the 2001 Acura, can’t go much faster than 300ms. polling/sending rate
With 2006 Jetta, you can poll at 100ms or less.

This is probably due to changes made in OBD-II protocol in 2002 specification.

November 21, 2012June 24, 2014

OBD – speeding up data requests – part 2

notes

AT commands which may help speed things up…

AT0, AT1 and AT2 [ Adaptive Timing control ]

When receiving responses from a vehicle, the ELM327 has traditionally waited the time set by the AT ST hh setting for a response. To ensure that the IC would work with a wide variety of vehicles, the default value was set to a conservative (slow) value. Although it was adjustable, many people did not have the equipment or experience to determine a better value.

The Adaptive Timing feature automatically sets the timeout value for you, to a value that is based on the actual response times that your vehicle is responding in. As conditions such as bus loading, etc. change, the algorithm learns from them, and makes appropriate adjustments. Note that it always uses your AT ST hh setting as the maximum setting, and will never choose one which is longer.

There are three adaptive timing settings that are available for use. By default, Adaptive Timing option 1 (AT1) is enabled, and is the recommended setting. AT0 is used to disable Adaptive timing (so the timeout

is always as set by AT ST), while AT2 is a more aggressive version of AT1 (the effect is more noticeable for very slow connections – you may not see much difference with faster OBD systems). The J1939 protocol does not support Adaptive Timing – it uses fixed timeouts as set in the standard.

BRD hh [ try Baud Rate Divisor hh ]

This command is used to change the RS232 baud rate divisor to the hex value provided by hh, while under computer control. It is not intended for casual experimenting – if you wish to change the baud rate from a terminal program, you should use PP 0C.

Since some interface circuits are not able to operate at high data rates, the BRD command uses a sequence of sends and receives to test the interface, with any failure resulting in a fallback to the previous baud rate. This allows several baud rates to be tested and a reliable one chosen for the communications. The entire process is described in detail in the ‘Using Higher RS232 Baud Rates’ section, on pages 59 and 60.

If successful, the actual baud rate (in kbps) will be 4000 divided by the divisor (hh).

Repeated commands

One other feature of the ELM327 is the ability to repeat any command (AT or OBD) when only a single carriage return character is received. If you have sent a command (for example, 01 0C to obtain the rpm), you do not have to resend the entire command in order to resend it to the vehicle – simply send a carriage return character, and the ELM327 will repeat the command for you. The memory buffer only remembers the one command – there is no provision in the current ELM327 to provide storage for any more.

S0 and S1 [ printing of Spaces off or on ]

These commands control whether or not space characters are inserted in the ECU response.

The ELM327 normally reports ECU responses as a series of hex characters that are separated by space characters (to improve readability), but messages can be transferred much more quickly if every third byte (the space) is removed. While this makes the message less readable for humans, it can provide significant improvements for computer processing of the data. By default, spaces are on (S1), and space characters are inserted in every response.

November 21, 2012June 15, 2014

OBD – speeding up data requests

Version 1.3 of the ELM327 introduced a way to speed up the retrieval of information, if you know how many responses to expect. By telling the ELM327 how many lines of data to receive, it knows when it is finished, so does not have to go through the final timeout, waiting for data that is not coming. Simply add a single hex digit after the OBD request bytes – the value of the digit providing the maximum number of responses to obtain, and the ELM327 does the rest. For example, if you know that there is only one response coming for the engine temperature request that was previously discussed, you can now send:

>01 05 1

and the ELM327 will return immediately after obtaining only one response. This may save a considerable amount of time, as the default time for the AT ST timer is 200 msec. (The ELM327 still sets the timer after sending the request, but that is only in case the single response does not arrive.)

Some protocols (like J1850 PWM) require an acknowledgement from the ELM327 for every message sent. If you provide a number for the responses that is too small, the ELM327 will return to the prompt too early, and you may cause bus

congestion while the ECU tries several times to resend the messages that were not acknowledged. For this reason, you must know how many responses to expect before using this feature.

As an example, consider a request for the vehicle identification number (VIN). This number is 17 digits long, and typically takes 5 lines of data to be represented. It is obtained with mode 09, PID 02, and should be requested with:

>09 02

or with:

>09 02 5

if you know that there are five lines of data coming. If you should mistakenly send 09 02 1, you might cause problems.

This ability to specify the number of responses was really added with the programmer in mind. An interface routine can determine how many responses to expect for a specific request, and then store that information for use with subsequent requests. That number can then be added to the requests and the response time can be optimized. For an individual trying to obtain a few trouble codes, the savings are not really worth the trouble, and it’s easiest to use the old way to make a request.

We offer one additional warning when trying to optimize the speed at which you obtain information from vehicles. Prior to the APR2002 release of the J1979 standard, sending J1850 requests more frequently than every 100 msec was forbidden. With the APR2002 update, scan tools were allowed to send the next request without delay if it was determined that all the responses to the previous request had been received. Vehicles made prior to this time may not be able to tolerate requests at too fast a rate, so use caution with them.

November 20, 2012June 22, 2014