Data conversion

Minor update on the ELM327 OBD scan tool:

A GUI has been added that is auto used when a graphical environment is available, otherwise the program will fall back to console usage. GUI does not contain any usefull controls yet. Users can also force console interface by adding the application launch parameter “-c”. I’ve scanned some of the more convenient PID codes on the Vectra and here and there I’ve also implemented data conversion to make it easy readable. Here is some console output:

PIDS_01_20_SUPPORTED: 01,04,05,0B,0C,0D,0F,10,1C,20,
ERROR: subfunction not supported
ENGINE_LOAD: 0%
ENGINE_COOLANT_TEMP: 25°C
ERROR: subfunction not supported
INTAKE_MANIFOLD_ABSOLUTE_PRESSURE: 100kPa
ENGINE_RPM: 0rpm
VEHICLE_SPEED: 0km/h
ERROR: subfunction not supported
INTAKE_AIR_SENSOR: 30°C
MAF_SENSOR: 0g/s
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
PIDS_21_40_SUPPORTED: 21,23,40,
DISTANCE_SINCE_ERROR_INDICATED: 2660km
FUEL_RAIL_PRESSURE_CT_VACUUM: 0kPa
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
PIDS_41_60_SUPPORTED: 60,
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
PIDS_61_80_SUPPORTED:
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported

The program also comes with auto auto incremented version numbers, this is made through Ant Build tasks. The program version can be checked in a About form.
Furthermore I found more interesting reads:

http://www.canbushack.com/blog/index.php?title=scanning-for-diagnostic-data&more=1&c=1&tb=1&pb=1

https://pcmhacking.net/forums/viewtopic.php?f=3&t=3224&start=350

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:

run:
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
=========================================
READY
Enter command: ATH1
ATH1
OK

Enter command: AT@2
AT@2
?

Enter command: AT@1
AT@1
OBDII to RS232 Interpreter

Enter command: ATH1
ATH1
OK

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

Enter command: 0105
0105
7E8 03 41 05 3C

Enter command: 0104
0104
7E8 03 41 04 00

Enter command: ATD
ATD
OK

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

Enter command: 0151
0151
7F 01 12

Enter command: 0902
0902
7F 09 78
014
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!

Using OpenCV in Eclipse under Linux

For OpenCV 2.4.6.1 …
Installing and using Eclipse under Linux is pretty much straight forward when using the windows tutorial for Eclipse and OpenCV build tutorial for Linux. Here is a fast run through both combined which should get you going in half an hour, depending on you internet connection and cpu power.

– First make sure you have Eclipse installed. This can be done easily from Ubuntu’s Software Center or through the Eclipse website.

– Install all required libraries to download and build OpenCV:
apt-get install cmake -f
apt-get install libgtk2.0-dev -f
apt-get install libdc1394-22 -f
apt-get install libjpeg-dev -f
apt-get install libpng-dev -f
apt-get install libtiff-dev -f
apt-get install libjasper-dev -f
apt-get install libavcodec-dev -f
apt-get install libavformat-dev -f
apt-get install libswscale-dev -f
apt-get install python-dev -f
apt-get install python-numpy -f
apt-get install git -f

– next, clone the OpenCV 2.4.6.1 files from the online repository:
mkdir opencv
cd opencv
git clone https://github.com/Itseez/opencv.git

– then, build OpenCV from source:
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local ../opencv/

– after building has been completed, install:
make
sudo make install

– now lets configure Eclipse:
Now, open Eclipse and select Window -> Preferences from the menu.
Next, navigate to Java -> Build Path -> User Libraries and click New …
Enter the library name: OpenCV-2.4.6.1
Then click Add External JARs…
and browse to the bin folder under the opencv release directory created above (for example /home/homeUser/opencv/release/bin)
Next extend the opencv-300.jar dropdown menu, navigate to Native library location and press Edit…
Now navigate to the lib folder under the opencv release directory created above (ex: /home/homeUser/opencv/release/lib)

– with Eclipse configured we can now test the library:
Create a new Java program.
During creation, when the wizard asks for Java Settings, choose the Libraries tab and select Add Library…
Select OpenCV-2.4.6.1 and finish the wizard.
Now create a new package and inside this package a new class called Hello
Enter following code:

import org.opencv.core.Core;
import org.opencv.core.CvType;
import org.opencv.core.Mat;

public class Hello
{
   public static void main( String[] args )
   {
      System.loadLibrary( Core.NATIVE_LIBRARY_NAME );
      Mat mat = Mat.eye( 3, 3, CvType.CV_8UC1 );
      System.out.println( "mat = " + mat.dump() );
   }
}

And run your code. You should see a 3 by 3 matrix output, more or less looking like this:

mat = [ 1, 0, 0;
0, 1, 0;
0, 0, 1]

Well done, enjoy the coding!
references:
http://docs.opencv.org/trunk/doc/tutorials/introduction/java_eclipse/java_eclipse.html#java-eclipse
http://docs.opencv.org/doc/tutorials/introduction/linux_install/linux_install.html#required-packages

DC motor control (reverse engineering that old toy pt.2)

Since I had the electronics worked out the last time it was now time take this thing one step further and add some control to it. I first made sure the software in the Arduino controlling the DC motors was able to listen to its serial port for incomming commands and afterwards control the motors according to the command that it received. I made sure I had a second Arduino board available and by using XBee modules I could now send commands from my pc wireless over the ZigBee network to my remote Arduino controlling the DC motors.

Next I found myself a XBOX 360 controller and because it has dual joysticks it can control both DC motors, one joystick for each motor. This one I hooked up to my laptop and next I wrote a small interfacing program in Java that translates the XBOX360 code into commands that are being accepted by my Arduino program controlling the motors.

The result:

Sketch:

sketch_final

Java benchmarking

Raspberry-Pi is compact and has aside of that other benefits which makes it a really cool tool to play around with. Unfortunately the processing power is limited compared to current day computers and so I hit the performance limit pretty early. But it seems now that Oracle has released a pre-release test version of Java 8 which comes with ARM performance tweaks. And so I was very curious to check out the differences between all Java versions I’ve been using past few months. I used Hwbot Prime to test the difference in computational power between OpenJDK6, OpenJDK7 and Oracle’s JDK8 (pre-release). Here are the results:

As you can see from the above chart, there is nearly no difference in using OpenJDK 6 or 7, but because of the ARM tweaks found in JDK 8 from Oracle we see a huge performance boost there, roughly 2,5 times higher performance. Off course these results should be taken with a grain of salt. This is a pure computational test, this will not say anything about process threading, MySQL performance or IO performance.. But it’s a nice indication that things are getting better.

Finishing the project

Last few week I had to spend quit a bit more time on the project as I wanted to make sure the basic functionality was there. I changed some parts of the code, did some performance testing, tuned the code a little bit and yesterday I put it into a state I think is good enough to show. Here is more or less an overview of the software architecture:

It’s more or less the same as the drawing you saw before. One of the differences is that the console application is now an application on its own plus the server IO back-end is more or less programmed as a service which automatically loads at boot. This way security rules can be applied, although they have not be implemented at this stage. The console app talks to the back-end server through TCP/IP and uses the same classes and methods as the front-end website when interacting with the XBee network. Regarding the front-end webserver, in the end I remained using the Jetty webserver. Altough it is still not performing very well, it does with it is supposed to do and I can’t find a solution which can be used as easily as the current one. Loading web pages still takes some time, but since this is more a research project than a product design I think concluding that “the functionality is doing what we hoped for” is good enough. Below you’ll find a screenshot of the analog values page which got a small interface update since my last screenshot of it. Notice the labels that get displayed when hovering one of the samples.

New in the front-end website is this “Command line” page which does exactly what you think it will do: allow the user to send commands to the XBee network. The back-end server has been upgraded to maintain a list of connected devices (with a timeout value of 1 hour) and so we can query the connected devices at all time. A dropdown box is filled with all connected devices and list of all available AT commands is also displayed as a dropdown box. The parameter box can be filled in optionally. In the picture below you see a demonstration of using the front-end ‘command line’. In the previous form submit we selected a node, selected the D1 command and filled in no parameters. After hitting the submit button the D1 command is send to the node which will then reply with its configuration value of the D1 register. Next the page loads as the one seen in the picture below and displays the value of the D1 register. As you see the value is 5 which means the D1 register is configured as digital high output. Next I filled in 4 in the parameter field, the dropdown boxes automatically select the same command from before when the pages loads and so when I would now push the submit button the D1 command with parameter 4 would be send to the remote XBee node which will then be configured as digital low output. To make a long story short, the led that was connected to the remote XBee on pin D1 was once lighted on but has now been turned of through our front-end website.

At this moments I’m finalizing my report which should be finished on friday, with next week my final presentation about what I’ve been doing past few months. Wish me luck because if all goes well I can call myself Professional Bachelor in ICT from then on!!

system architecture

Below I’ve added a quick drawing which shows you more or less the current status of the project. At this moment I’m still running on Windows but I received the Raspberry-Pi last week so we can soon start with porting all the code to the Raspbian operating system. That I can hopefully start with next week, so far the administrative website can display IO data that has been stored in the MySQL database but my next goal is to let the individual services talk to each other so that the admin can send XBee commands from the admin website. That will be the goal for this week.

XBee data collecting

So, before I take a few days of vacation to explore the city with some of my friends, a few words about my XBee project. Last week I made a XBee API coordinator node which collected IO sampels from remote XBee devices in AT mode. The analog data was generated by connecting a potentiometer to the AD0 port, with one end tied to Vcc (3.3V) and the other end to ground. Afterwards I collected all the data in a imaginary database by writing all data into a textfile. Data packages I save in the ‘database’ look more or less like this:

4-apr-2013 16:11:43#0008#ZNET_IO_SAMPLE_RESPONSE#0x40,0x2e#0x00,0x13,0xa2,0x00,0x40,0x79,0x5a,0xff#

Last week I also set up a TomCat webserver on which I’m running a .JSP website. When requesting the web page I’m at this moment reading from the text file that is used as database, and afterwards I sort all data in a Treemap<String, TreeSet>. Then, I use the RGraph library which shows the analog sample in a nice interactive graph. A dropdown list lets you select the data from each individual network node, as you can see from the picture below:

Early XBee tests

And so I received some tools to play around with: 3 XBee modules + breakout board, 2 breadboards and 2 Arduino Uno micro-controller boards. I didn’t get enough electrical wires yet to put all at good use, but as far now I’m only trying some basic configuration commands with only one XBee module. You can see the setup below: 3,3V and GND supply voltages are taken from the Arduino board while Arduino’s pin 0 (RX) is connected to XBee’s RX pin and Arduino’s pin 1 (TX) is connected to XBee’s TX pin. This way we can use the Arduino board as a USB to RS232 converter (straight connection), if you would use Arduino in the normal way you would have to make cross connections.

To talk to the XBee module I first tried Putty and Digi’s X-CTU software, afterwards I wrote my own Java software to send commands and receive data through a console application. So far everything seems to be going great, let’s hope we can keep on going like this.

after hours coding

post-IT-study chronicles

Java