Graphical OBD MPGuino

Forum 2005-2010 (read only) General Exhibition
1

Finally,

Started to use the Arduino a couple of months ago with no former knowledge in coding. My goal was to display car ECU values on a small graphical LCD. Started of with the nice KS0108 Library that MEM here on the forum wrote and after a while that was under controll, thanks MEM.
Next step was to find a way to talk with the car ECU, ELM327 was the solution.
After some regular serial.print commands the car ECU responded with values that i was looking for, but my knowledge ended here and i had a hard time to display the values.

So, after a couple of days reading the code Magister and others at the ecomoder forum have created i figured it out.
Without the people that made the core of this code it would be hard for me to capture the reply that is given from ELM327 and to display it.
So what i did was to cut down big parts from the original code, parts that will read fault codes and other nice functions are removed so the code will fitt the ATmega168.
I am keeping the bootloader but need more memory so will be removing it soon, buying a AVR-ISP is on the list.
I did try to download the sanguino bootloader to a ATMega644P this weekend but never got it working. Maybe just wait for the ATMega328p that will pop right in the arduino or order a sanguino, time will tell.

Remember that this code is far from complete and that i am a rookie but proud of my progress...
I set the baud rate to 38400 and found that my car supports protocol 4 and 6. Protocol 4 contains some intresting valueus that can not be found in protocol 6 but the protocol update rate is really slow. Do not know if that is due to the code or just that can bus protocol 6 has a faster response rate?

Now i need to clean up the code, get more memory, add buttons to controll a menu, arrenge more graphical options, activate the fault code reading and so on.
Any ideas are welcome.

In the attached link below you can find the black box prototype build i have done, ELM327, KS0108 graphical LCD and a arduino. Trust me, there is no free space in that box now.

http://public.fotki.com/HULK77/ks0108/

Picture of the display showing speed, temprature and curve of the rpm. RPM is also shown in a value on the right side and the top right value is the peak value of the RPM.

Next prototype will not contain the complete ELM327 board supporting a computer connection. I will use another LCD and a arduino mini or smaller, all will be mounted in a smaller case.

I am using Arduino version 11 for this code and the GLCD Library found below.

http://www.arduino.cc/playground/Code/GLCDks0108

Original post at eco modder:

Sorry, no video. Phone picture will have to do for now.

2

Good job! Looks like all your hard work has paid off.

Look forward to seeing the video if you find some time to make one

3

:sunglasses: Thanks Mem,

My first code, hope i get better at the coding part in the future. But as they say, learn by trial and error.

By the way, could you explain why a horizontol line that is drawn from left to the right is not complete. As you can see in the picture the bottom lines have some white pixels in the middle. Is this due to pixels crossing from CSEL1 to CSEL2 of the Lcd chips?
Or is just me doing something wrong, are you seeing the same issue with your lcd?

http://public.fotki.com/HULK77/ks0108/dsc08643.html

4

What a fantastic project :slight_smile: I'm working on something similar for a motorcycle, your project is very inspiring.

I've recently started playing with a KS0108-display from Sure Electronics, and I had the same problem as you when drawing across the segments. I "solved" this by extending the enable-pulse, but at the cost of slower access. I'll try to insert a small delay when switching segment, that might help.

5

Great, thanks for the feedback.
I wonder if Mem will update the library to fix this issue if possible.

I am building a Sanguino now, need more memory and more digital/analog pins.
www.sanguino.cc
Problem with the KS0108 is that it requires most of the digital and analog pins of the Arduino and the library is about 8k
When i have completed the Sanguino i will add buttons to control a menu and a Accelerometer to measure the g-force.

Imagine adding brake force and acceleration g-force values...

What kind of protocol are used for a motorcycle?
Optimal protocol for a car is the high speed can bus, all other are slow and only lives you the opportunity of playing with one value at time if you want to have a fast update rate.
If you can collect the MAF value and rpm you can calculate both torque and horse power. :sunglasses:

6

Well, inserting a delay when selecting chip did not help, so I'm stuck with the long enable pulse for now. I've just modified the delay450ns function, later I'll try to shorten the delay after the pulse.

7

I am building a Sanguino now, need more memory and more digital/analog pins.

Same here. I switched from a 20x4 character display to this, and I've already run out of pins. So now I'm waiting for the 644 I've ordered. I'm cheap so I'm just going to build it on a breadboard, using a Freeduino for power supply and programming.

When i have completed the Sanguino i will add buttons to control a menu and a Accelerometer to measure the g-force.

Same here :slight_smile: I'll use the accelerometer to measure lean angles and G-forces, and also to activate the brake light.

What kind of protocol are used for a motorcycle?

A few bikes (BMW and Ducati that I know of) are using CAN-bus, but this is just a plain Suzuki and I'll use another AVR168 to collect data and transmit it to the display-unit using serial or I2C.

8

Add a turbo and see if you can keep the g force on the ground :wink: .

Could you explain the reason to why you will run the display and OBD process on different processors?
Will that really speed up the code execution or are you adding more technical candy ?

9

By the way, could you explain why a horizontol line that is drawn from left to the right is not complete

Hi Hulk, I missed that question you posted a while ago, and only just noticed it now.

I looks like its due to time it takes the panel to switch chips. I can reproduce it here and am looking at it in conjunction with the a solution for adjusting for the different delays required for different panels without having to throttle back the faster panels.

I would be interested in hearing how you guys think support for panels that required different delays should be handled

  • slow down the library to the lowest common denominator
  • provide a fast and slow compile time option
  • provide some tuning advice and let each user tweek his panel to find the best response
  • something else?
10

Could you explain the reason to why you will run the display and OBD process on different processors?
Will that really speed up the code execution or are you adding more technical candy ?

There are several reasons for this.

  • I want to separate data acquisition and presentation to make the system more flexible. If I want to add new functionality (like controlling all lights) later, it's easier to plug a new controller into the i2c-bus than adding more inputs/outputs to the display unit.
  • Simpler code.
  • By locating the controllers close to (or inside) the components I want to monitor or control, I can make the wiring loom simpler. If everything was connected directly to the display unit, there would be a lot of wires running to the handlebars.
  • I don't want to do everything at once :slight_smile:
11

I would be interested in hearing how you guys think support for panels that required different delays should be handled

I suggest making the duration of the enable signal a compile time option.

Btw great library :slight_smile: It's a shame that the Arduino only has 1Kb RAM, if it 2Kb or more you could do all drawing operations on a framebuffer in RAM and blit the changed parts to the LCD. This would speed up things a lot.

12

It's a shame that the Arduino only has 1Kb RAM, if it 2Kb or more you could do all drawing operations on a framebuffer in RAM and blit the changed parts to the LCD. This would speed up things a lot.

People are looking at porting the 2K ram ATmega328P to the arduino and that could suit your purpose. It has 32k program memory so lots of space for strings etc. Keep you eyes posted on the news thread.

I suggest making the duration of the enable signal a compile time option.

I am not sure adding the delay in enable is the right place for your chips? Have a read of this thread from post 25 onwards and let me know what you think
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1210427907/25

13

I am not sure adding the delay in enable is the right place for your chips? Have a read of this thread from post 25 onwards and let me know what you think
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1210427907/25

This is what I've done. I had to increase the 450ns delay to about 4.5 microseconds to get my LCD from Sure Electronics to work. There seems to be some variations between controllers here. The right controller works fine from about 2 microseconds, the left controller needs 4.5 microseconds.

The example where you modify Enable() does not change the width of the pulse, it adds a longer delay after the pulse. Also, at one point in the code you're generating an Enable pulse without calling Enable(), so modifying Enable() won't suffice.

My LCD needs a 4.5 microsecond pulse with a 4 microsecond delay to function properly.

14

I am building a Sanguino now, need more memory and more digital/analog pins.

You can save one analog pin by using only one pin for chip select. Comment out all occurrences of CSEL2 in the library, and feed CS2 on the LCD by the inverse of CS1. I used a 7400 for this, works fine.

(Btw. this does not affect the need for a longer enable pulse. It doesn't matter if I use the 7400 or the original method.)

15

This is what I've done. I had to increase the 450ns delay to about 4.5 microseconds to get my LCD from Sure Electronics to work. There seems to be some variations between controllers here. The right controller works fine from about 2 microseconds, the left controller needs 4.5 microseconds.

The example where you modify Enable() does not change the width of the pulse, it adds a longer delay after the pulse. Also, at one point in the code you're generating an Enable pulse without calling Enable(), so modifying Enable() won't suffice.

My LCD needs a 4.5 microsecond pulse with a 4 microsecond delay to function properly.

Not sure why you need such long delays but the code this library is based on did have very long delays for the low half of the pulse. I shortened that delay to meet with the specs in the Samsung ks0108 datasheet. This indicates an enable high and low pulse width of 450ns and this works on my panels that use the Samsung chips. I have measured the pulse widths on a 16mhz arduino and confirmed they are at least 450ns using an HP 165000C logic analyzer.

I can certainly increase the delays as a compile time option. If you need the on and off times both to be increased, does increasing the duration of delay450ns (I may rename it to something like enPulseDelay) to 4.5us work for you?

I will modify the library so the reads also call the enable method for consistency.

16

I can certainly increase the delays as a compile time option. If you need the on and off times both to be increased, does increasing the duration of delay450ns (I may rename it to something like enPulseDelay) to 4.5us work for you?

Yes, that's what I'm doing now. This works fine, although the framerate in the example sketch drops from 9fps to 5fps...

17

Mem,

I would say option:

  • provide some tuning advice and let each user tweek his panel to find the best response
    The option to customize each individual display panel and keep the library as fast as possible will suite everybody in my opinion.
    If you need a fast library and have the panel to support it it will be hard to use the optimal set up of the library if it was set to suite many panels but slow.
    I think you get my point ::slight_smile:

By the way Mem, i noticed that your library is not working with the new Arduino 0012, will it be available in the future?

18

skumlerud,

Was worried that you had some great idea that i had missed out on...

So i have my Sanguino completed :smiley:
Manage to short cut the pins on the AT Mega 644 so of to the store tomorrow again.
But before that i managed to do a regular blink sketch and test all the ports.
Then i used Arduino 0011 to compile the same sketch that works with the Arduino but got error:

In function 'byte elm_read(char*, byte)':
error: 'serialRead' was not declared in this scope In function 'void elm_write(char*)':
 In function 'int elm_init()':

So i did declare it just to see what the next error would be:

 In function 'byte elm_read(char*, byte)':
error: 'serialRead' cannot be used as a function In function 'void elm_write(char*)':
 In function 'int elm_init()':

So at this point of time my rookie skills are stoping me from progress. Maybe you will manage to find out what the problem is when your Sanguino is completed. Could it be that the Sanguino core files are missing something or maybe just a need of a new library. Checked the Sanguino core folder and it is containing all files that the regular Arduino core folder does, even some extra.
Well well, if you share your progress later i would be glad.
Thanks.

19

Hulk, I uploaded library code that works with 0012 on the 18th. Have you tried this version?

20

Mem,
Had not checked, maybe i should before asking...
Thanks