Back on the Vec(tra)

Some time ago I made a first OBD interface circuit for a Opel Vectra, and I even got some data back that I could at least interpret and check against the data displayed on the car’s dashboard. Now I quickly found out that there is more than meets the eye. There are a lot of different standards and I was not quite sure which one exactly is used in the Opel Vectra C. However, I did found out about the ELM327 and STN1110 IC who allow interchanging data over OBD in a more controlled way. Under the hood of both these devices is a PIC microcontroller so in fact there is not really anything special about the circuitry, there is just the firmware doing its magic abstracting things away for who over uses these IC’s. You can order the IC or you can pick up end-products for as low as € 20, and because it hides some of the more complex OBD protocol features it is really a good toy to get you going on OBD reading. There is also a datasheet that explains how developers should interact with the ELM327, really handy! I picked up one of these (which is obviously a Chinese clone of the real ELM327 interface):

The ELM327 based devices can be had in different types: USB, WiFi, BT, RS232… And once we have this off course we go back to our previous code and adopt it to our new interface, and after some experimenting I have a basic command line mode way of exchanging data running. Until now the tool allows for auto detecting the interface, connect to it and then ask the user which commands he would like to execute. The console then replies which whatever data is received.

Currently I’m also working on logging what ECU’s we have been talking with, creating a more user friendly form based user interface, make the software auto config the ELM327 for correct operation, save some user data on disk. Other stuff I would like to add is a monitor mode, some debug logging, set up the software to allow translations of texts.

Here is some of the console output I was able to create today:

Not connected
Scanning for serial ports
Stable Library
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
Scanning serial ports completed
Auto detecting ELM327 device
Connecting to serial port
Connected to /dev/ttyUSB0 @ 38400 baud/s
Enter command: ATH1

Enter command: AT@2

Enter command: AT@1
OBDII to RS232 Interpreter

Enter command: ATH1

Enter command: 0101
7E8 06 41 01 81 06 80 00

Enter command: 0105
7E8 03 41 05 3C

Enter command: 0104
7E8 03 41 04 00

Enter command: ATD

Enter command: ATDP
AUTO, ISO 15765-4 (CAN 11/500)

Enter command: 0151
7F 01 12

Enter command: 0902
7F 09 78
0: 49 02 01 57 30 4C
1: 30 5A 43 46 33 35 34
2: 31 90 90 90 90 90 31

Enter command: STOP
Not connected
Experimental: JNI_OnLoad called.
BUILD SUCCESSFUL (total time: 5 minutes 40 seconds)

The ELM327 allows AT commands to configure it, if a commands is received that does not begin with “AT” than the command is considered to be an OBD command in which the replies differ in layout as you may have noticed in the output above. Command ATH1 sets the ELM to display OBD packet headers from which we can retrieve address info. A bit later, the OBD command 0105 replies with “7E8 03 41 05 3C“. Because we’re talking about CAN replies here (11bit CAN, 500kbaud), 7E8 is the address of the replying ECU. 03 tell us that we’re receiving 3 byte’s of data. The first byte of data, 41, tell us it is a response to a mode 01 request (01 + 40, 40 is a constant number to differentiate replies from requests). The next byte 05 is a copy of the 05 OBD PID that is also found in our request. The final byte is where the actual data sits. 3C is a hex number (as all the others are), if we convert it to a decimal number we get 60. The formula for OBD mode 01 PID 05 states that we should take 40 from this decimal number in order to get the correct result, and so 60 – 40 equals 20, a possible temperature for a cold engine. In the next post I’ll hopefully be able to show a little more user interface and less OBD details, a presto!

Java 8 benchmarking on ARM and x86

In a previous test I saw already that Java 8 might bring some big improvements for ARM devices compared with previous Java versions. Now with newer versions available for both Java 7 and 8 I found it useful to redo these test and check if the same performance gain applies for x86 machines. Here are the results:



On ARM devices we can see that the newer builds for both Java 7 (OpenJDK) and 8 (Oracle) do not bring more performance compared to previous Java builds. On the other hand it confirms once again that Java 8 has some nice performance tweaks on board and lets hope these tweaks also find their way in the release build.

For x86 (32-bit) however there is no difference in performance when using Java 8. However, code-wise, Java 8 off course brings some new features, but that’s not the focus of these tests.