November 2012 - Page 3 of 6

November 22, 2012May 15, 2014

Algorithmic Composer

algorithmic composition tutorials using Max and Pd

http://algorithmiccomposer.com

November 22, 2012June 20, 2014

Markov Chains in Max

from algorithmiccomposer.com

http://algorithmiccomposer.com/2010/05/algorithmic-composition-markov-chains-in-max-msp.html

November 22, 2012June 24, 2014

Slow data

notes

Examples of slow data streams.

bicycle wheel sensor that triggers once per rotation
The data stream from an OBD-II scanner which can only be polled every 300ms or slower
a traffic sensor on a quiet street

There aren’t enough data points to use typically smoothing methods like moving average or logarithmic smoothing. Here are 2 ideas for increasing data points using repetition:

feed the data into the right inlet of an [f] object to set its value. The left inlet receives the output of a [metro] set at the desired stream rate. Then the output of the [f] object can be smoothed using conventional methods.
convert data to a signal using [sig~] then smooth using [slider~] or [rampsmooth~] then convert back to float using the right outlet of [number~]

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, 2012February 7, 2013

Max OBD sensor project

Preliminary files are in:

/Automax

rpm3- reads rpm/speed from obd bluetooth

This patch demonstrates two methods of polling. For RPM and vehicle speed, the request codes and polling are linked and controlled by a single metro object which splits the polling time between the two codes.

The engine load is a simpler setup – with separate metros to do writing and reading.

If the polling speed is set too fast, the OBD port will crash and you have to reset everything. So on the 2001 Acura you can’t poll faster than 300 ms. – but on the 2006 Jetta you can poll at 100 ms. – which is much more realistic for doing engine simulation stuff…

waveguide engine2e-1 – gets rpm and sends to engine speed

November 21, 2012June 24, 2014

Max bicycle speed / engine example patch

notes:

I’m trying to organize the examples for measuring wheel speed. These patches need to be consolidated – and have the extraneous stuff stripped out. For example, just need a wii-mote detector without all the envelope stuff.

max teaching examples/tz examples

bicycle2.maxpat – need to clean up

wheelspeed.maxpat

waveguide engine3c bike.maxpat

notes: wheelspeed2.maxpat has some experiments with smoothing by converting to signal in order to get more data points.

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