2 1/16 gauge ECM data display

[Jim85IROC]

This is great stuff! Prior to reading this thread, I'd never even heard of the Arduino stuff. Now I've got an Uno, a couple LCDs, and a "starter" pack on the way. To get re-acquainted with coding (I'm almost 15 years out of college, and haven't used it since then), I'm going to follow some of the simple tutorials to make lights blink, etc, and then build a little display to show coolant temp, fuel level, battery voltage, oil pressure, etc, right from the sensors. After I accomplish that, I want to follow in the footsteps that you guys are taking and start grabbing some of the OBD II data so I can display that as well. My end goal is to simplify the instrumentation in my IROC when I do my LS swap by having a 2.8" TFT between the speedo & tach (like a lot of the newer vehicles utilize) to display sensor data as well as OBD II data.

One question for you guys... how are you interfacing to the OBD port? Are you using some sort of ELM327 device, or are you connecting directly to the OBD port?

[3400tZ]

For ODB1, there is a circuit that need to be build (or a cable that need to be purchased). For ODB2, as you said, with an ELM327 adapter, its very easy. I would say its probably the easier beside ALDL and MegaSquirt (Megasquirt CAN being the hardest :P). That adapter can be Bluetooth or USB. If you wouldn't have already bought your Arduino stuff, I would have told you to look at http://arduinodev.com/hardware/, he got a good collection of Arduino kit for ODB2. He got a pretty clean ODB2 Arduino library that you can look at here (and still use with whatever Arduino you bought). Also, he has this ODB2 emulator which seems pretty damn cool, no ECM bench test needed for testing from what I've understood, the emulator will emulate the whole ECM, not only the sensor like the JimStim does when we use it for ALDL or MegaSquirt. I might have to buy one at some point :)

[Jim85IROC]

For ODB1, there is a circuit that need to be build (or a cable that need to be purchased). For ODB2, as you said, with an ELM327 adapter, its very easy. I would say its probably the easier beside ALDL and MegaSquirt (Megasquirt CAN being the hardest :P). That adapter can be Bluetooth or USB. If you wouldn't have already bought your Arduino stuff, I would have told you to look at http://arduinodev.com/hardware/, he got a good collection of Arduino kit for ODB2. He got a pretty clean ODB2 Arduino library that you can look at here (and still use with whatever Arduino you bought). Also, he has this ODB2 emulator which seems pretty damn cool, no ECM bench test needed for testing from what I've understood, the emulator will emulate the whole ECM, not only the sensor like the JimStim does when we use it for ALDL or MegaSquirt. I might have to buy one at some point :)

I found that arduinodev.com site, and I like that setup. I'm not sure yet if I prefer that setup or this one from sparkfun: https://www.sparkfun.com/tutorials/294

The sparkfun version seems to have a fair number of people who are unable to get it to work, plus I think I like the cleaner 4-wire installation of the arduinodev version. After I get familiar with the Arduino, I'm going to dive in. I made some LEDs blink tonight. :twirls-finger:

[3400tZ]

My experience with SparkFun is that their products are great but the documentation sucks! It's usually example code written by costumer that couldn't find any example code. I try to buy from elsewhere whenever possible. Adafruit has awesome tutorials, no OBD2 related products unfortunately but a bunch of other great stuff.

Arduinodev definitely seems to be good stuff but I haven't deal with that guy yet.

[Jim85IROC]

Yeah, when the time comes, I suspect that I'll give the arduinodev guy a try. For now I'm going to stick with getting meaningful data from a temp sensor, oil pressure sender, fuel level sender, etc, and pushing that to a TFT through a halfway decent looking GUI. It looks like that will actually be harder than getting the OBD II data.

[3400tZ]

So I've made some progress on this. I received my CAN bus shield and I'm now pulling data from the CAN bus of the MS with an Arduino Uno. It's a different Uno then the one my display is on as I'm running out of RAM to run everything otherwise. I've got an Arduino Mega but I'm still waiting on my leoshield. I've also ordered a GPS and accelerometer from Adafruit that I should receive sometime next week.

Code for the CAN stuff is here: https://gist.github.com/sebgiroux/7575688 if somebody is curious. That would be the first full MS can bus arduino example on the net I assume as I couldn't find anything else (and its not that easy to do!). It's going to be merged with the rest once I got the Mega setup as I said.

I've also received my cheap gauges that I wanted to use to install the screen in. Turned out those gauges don't have removable bezel so I had to saw the damn thing :/ I will figure out a way to put it back together, I might buy a plastic welder, or just hot glue the bezel back on or something...

I'm pretty happy with the result of the screen behind the tinted face tho, looks pretty good. I will add a black thing to hide the PCB of the screen.

[3400tZ]

Today, I've added a buzzer that will eventually be used for when alarm values are reached. It will make a perfect alarm as its super annoying and for only 1.50$ :)

On my other Uno currently running the CAN bus shield, I started coding the data logging on SD card stuff but I'm already running out of RAM, lameeeeee. Just loading the SD library use half the Uno RAM and the CAN library use like 1/4 so I end up with very little for the main sketch.

And waiting for ordered hardware to arrive sucks! And I'm always realizing I need something else I didn't thought about until now. This should move much faster once I have the hardware prototype done.

[3400tZ]

So, is it just me or it looks like the SparkFun CAN bus shield doesn't have the CD (card detect) pin for the SD card connected to anything ? See https://www.sparkfun.com/datasheets/...shield-v12.pdf

I want to start/stop data logging as the SD card is inserted/removed. I was looking for the best way to do that and it looks like using the CD pin and an interrupt would be best, but for some reason, they didn't connect the pin (WHY?!). The only other way I see to do this is doing polling in the main loop but that's an ugly solution and not to mention that it will slow down everything else. I'm really starting to hate SparkFun more and more...

I will start with what I have but looks like Adafruit board will be a better option down the road.

I really cannot wait to have the hardware prototype all figured out, this is getting annoying (and expensive!). :D

[Six_Shooter]

I think a better solution would be to have a button that starts and stops datalogging.

I know personally I would HATE to have to insert and eject the SD card whenever I would want to start and stop a datalog. I would rather leave the SD card in place and just press a button.

I don't see a CD pin anywhere on that schematic. Wrong schematic?

[3400tZ]

Well, what is the difference between pushing a button or a card ? :P I personally want a clean look for the gauge (can't have 15 buttons on a 2 1/16 gauge anyway) so I'm trying to avoid having buttons for everything.

But I like your reply because it shows that everybody has different needs/interests. I want that project to go in that exact direction. Like you were saying earlier in this thread I think, you bought a similar device that wasn't doing what you wanted it to do and you was stuck with whatever you bought because it was impossible to customize it. I want both the code and hardware for this project to be super flexible so people can really have it the way they want. For example, one advantage of having the card always in like you're proposing is that you could create different data logging trigger events. For example, start data logging when TPS > 25% and stop when TPS < 15% or something... That's isn't something I'm interested in but I'm sure it could be the case for some people. In that case, you obviously need the card to be in all the time.

For that particular SD card discussion, I think the firmware doesn't even care about the hardware for button or card detection. It will just monitor a pin and will start/stop the data logging when the pin is LOW/HIGH.

I think it's very important that the code of this project is very modular and easily tweak-able but it does mean that anybody that want to build their own gauge will have to do a bit of coding / hardware but they will also end up with the exact product they want if they put the effort into it.

My version of the project probably is going to be overkill for most people. To be honest, I think it is overkill as well but I want to go all out. So it is going to include the following:

- ECU monitoring of whatever parameters chosen at compile time
- Data logging on SD card
- Data logs info (free space on SD card, number of data logs, etc)
- Quarter mile time (with 60', 1/8 E.T. and MPH, 1/4 E.T. and MPH)
- 0-60 times
- Alarm when specific values reached (w/ buzzer)
- Switching between pages of the gauge using a key fob
- Temperature sensor
- Humidity sensor
- Altitude sensor
- Real-time clock so the data log file name use the current date
- GPS data (w/ data logging)
- Triple axis accelerometer
- Compass

All into a 2 1/16 gauge (with external box).

The good news is that all can be disabled at compile time so you end up with just what you need. What you decide to use can be tweaked for you need as said above.

[3400tZ]

I don't see a CD pin anywhere on that schematic. Wrong schematic?

It is the right schematic. It's probably CD1 and CD2 (the holder seems to have two little tabs thingy). They are both connected to ground.

[Six_Shooter]

I see those pins now, I wasn't looking at the external connections (traces) but the pin names in each device.

You hit the nail on the head, leave the card in and have the ability to trigger whenever, including the software detectable ones like you suggest.

There's less likely chance that you will damage a button, or lose it, by pressing it to start/stop a datalog there there is when you insert/remove an SD card. ;)

I always found it annoying when I had to perform similar operations with other devices, such as (and this will date me a little) cassette players in cars, for many years you had to insert the cassette to listen to it, which is fine, but then to go back to radio, you had to eject the cassette, instead of just hitting a source button. ;)

With the source code being open, that does change things a little. :)

[3400tZ]

Exactly!

For some reason, with Arduino, most people just put all their code into one .ino file and that's it. This is definitely not the way I want to go for this project. I want everything to be organized and each module into their own .cpp file. In the end, it will probably require a bit more RAM and flash to do it this way (and maybe that's why people don't use OOP as much with Arduino ?) but the code is going to be soooo much cleaner.

Here is what I have in mind:

ECU comms (choose one)
- ALDL 8192 baud
- ALDL 160 baud
- MegaSquirt Serial
- MegaSquirt CAN
- OBD 2

Display pages (choose 0 or more):
- ECU monitoring pages (can be enabled as many time as wanted)
- 0-60 time
- Quarter mile time
- SD card info (if SD card data logging enabled)
- Weather (Temperature/Humidity/Altitude)
- G-force and compass
- GPS data

Optional modules (choose 0 or more):
- SD card data logging
- RTC (to properly name data logs files)
- Data logging trigger (if data logging enabled)
- Alarms (w/ buzzer)

[3400tZ]

Just realized this is already getting out of control a bit . I bought more stuff tonight, and I think I'm at about 500$ into this already Of course I will end up with A LOT of spare parts after I'm done but still a bit crazy. I just bought a Due, I want to use the Mega but I might give the Due a try at some point. In the end, it's cheaper then the Mega (doesn't matter for me now that I've bought both :P) and it has more hardware then this project will ever need (I hope).

Now, I need to stop buying stuff, receive everything and start the real coding!

[3400tZ]

I've renamed this project "DIY ECM Gauge" which seems to fit better with where I want to go with this then "MS CAN Gauge" :)

So repo is now at https://bitbucket.org/SebGiroux/diyecmgauge

(Still on hold on the project, waiting for a bunch of stuff to arrive still)