2 1/16 gauge ECM data display

[mikew]

I'm gearing my ALDL Gauge to work with your ALDLdroid, it can operate stand alone or as a bluetooth connection for ALDLdroid (function as a standard bluetooth to ALDL interface, got that working at 8192, might look into 160 also).

With 2" of gauge face to work with there's not much real-estate for displaying data, a parameter or two at a time. So I can see your ALDLdroid being used when I want to see a bunch of stuff at once.

And then's there's logging; although it would be reasonable to implement, once again using ALDLdroid solves a lot of problems (like ease of getting logs to a PC, etc).

So I'm kind of excited to see them work together!

[3400tZ]

I see what you mean, you want the gauge to act as a proxy, right ? So the gauge is connected to the ECM and ALDLdroid is connected to the gauge using Bluetooth. If ALDLdroid is getting the same exact data stream as the ECM from the gauge, I really don't see why it wouldn't work :) That's not a bad idea at all to have both working at the same time!

[mikew]

I got the basics working today.

In standalone mode the gauge requests data from the ECM, which means it has the mode request and data stream info in the Arduino sketch (I'm only doing mode 1 requests).

But when when the bluetooth is paired, I used TunerPro in testing today, the gauge lets the external software submit the requests. That way you can do other things like mode 10, etc.

At some point I might implement a microSD card so you can put an ADX file on it instead of hard coding the ALDL info into the sketch, but for now I'm just going to set it up for my specific installation.

[3400tZ]

Sounds good, sounds like you have done quite a bit already :)

I think it's better to do config at compile time for such project, instead of loading file from an SD card. From experience, it was so slow streaming a file from a SD card and then you still have to write a parser :D Of course, its not as sexy to do a compile time config but give better (faster loading and stuff) results IMO.

[mikew]

Well, here's a prototype of my ALDL Gauge:



It's not real data, just experimenting with visuals and packaging.

The colors are a little over saturated making them hard to distinguish, but the "sweep" changes from green to yellow to red depending on the RPM.

The Arduino NANO, HC-05 Bluetooth, display "sandwich" and another board for input and power conditioning will all easily fit in the gauge case. I will have an external rotary encoder that has a momentary push switch too for changing what is displayed on the gauge.

Now to modify my existing ALDL logging code so that it works with the new display.

Here's some pictures of the OLED text display / RGB LED Sweep sandwich. This ring on the last image is a 2" gauge bezel, for size comparison.

photo 1.JPG.jpegphoto 2.JPG.jpegphoto 3.JPG.jpeg

[3400tZ]

Looks sweet! It's cool that you can use the Flora stuff for your project... 2.5KB of SRAM is not enough for mine :/ I want to see once you have yours installed into the gauge casing now! You should create a bit bucket (or GitHub) account and use GIT to have version control on your code. It would also allow easier sharing with everyone :)

[mikew]

Ended up using an Arduino Nano instead of the Flora because I didn't want to deal with 3.3v / 5v level shifting.

I might run out of memory too.... The Adafruit OLED library reserves a 1k buffer for building the screen images! Too big! If I can't find a different library the Nano won't cut it and I will have a tough time shoving everything in the case.

By the way, have you seen this: http://jkdevices.com/arduino-megamini

You can get an optional Accelerometer/Gyro/Compass (MPU-9150) chip on-board too.

[3400tZ]

Yeah that library is using so much RAM, I noticed that too. With the OLED, CAN , GPS, Accelerometer and Compass libraries, I think I'm at almost 3k SRAM.

Pretty cool about the megamini! I wonder if it fit in a gauge, it looks like it might be a bit too big still ?

Personally, I know my prototype is not going to fit in a gauge anyway tho. I got my Arduino Mega 2560 this week and I've ordered the ultimate GPS w/ 10Hz updates and the accelerometer+compass from Adafruit. Still waiting for my CAN bus shield from Sparkfun and the Leoshield as well. So no progress is gonna be made on this project this weekend but I should receive most of my stuff, if not all, next week!

[mikew]

Mega is what I've used on my other projects too. 8k of memory and 3 hardware serial ports are real handy.

The Arduino-MegaMini is 3" long and the Teensy++ 2.0 is 2", neither will fit in the 2 1/16" x 1 5/8" gauge case.

I'm not optimistic about getting everything in the case at this point...unless I put two Nano's in the case (they should fit) one for ALDL communications and one for display. Is that just getting carried away?

[3400tZ]

Maybe the easiest thing to do is just to optimize that library for the display. It shouldn't need that much RAM... :) If you don't want much else then the display and ECM communication tho, it might be OK.

[Six_Shooter]

You guys have to start thinking less Arduino and more custom PCB.

Arduino and Teensy++ 2/3.0 are great for prototyping/proof of concept, but when it comes to actually producing something, even as a one off for yourself to fit in a specific form factor, custom PCB is the way the to go.

[3400tZ]

I don't mind having the "brain" of the gauge external for now.

But yeah, Chris, if you feel like getting the ball rolling on a PCB with the atmega2650, power supply circuit, CAN controller, CAN transceiver, GPS module, Accelerometer module, etc, please go for it :D

[Six_Shooter]

I don't mind having the "brain" of the gauge external for now.

But yeah, Chris, if you feel like getting the ball rolling on a PCB with the atmega2650, power supply circuit, CAN controller, CAN transceiver, GPS module, Accelerometer module, etc, please go for it :D

I'll wait until you have final prototype, so that all known components will be accounted for, and then can see what parts can be stripped out...

In most cases the main processor can be swapped out for a smaller physical one with less IO, or a smaller foot print, such as going to an SMD device that uses a smaller pin pitch can save a LOT of space, and then there are a bunch of components that's present on an Uno or similar Arduino that can be eliminated from a final design, saving on space. Then there's usually components on the shields that are extra and not needed, when a uniform design is achieved.

[3400tZ]

It would be based on the Mega CPU, that's already SMD. But yeah, there is way too many I/O's on it. Downgrading the numbers of pins on the processor will be fine as long as it doesn't require rewriting the whole code. I would like to keep the Arduino bootloader on the processor so the Arduino stuff can still be used.

Today I got my 100nF capacitor so I did the hardware debouncing for the push button. Works much better now :)

[Six_Shooter]

Sometimes some of the code needs changes when going to a more efficient IC, by more efficient, I mean a size of EPROM, RAM, and IO that matches the application, but usually it's just pin re-assignments, which if you do the set-up correctly is a few minute process to change the pin assignments, with going down only a few lines from the top. ;)

The boot loader can be programmed to the Atmel ICs, and then used just like an Arduino, but sometimes that space used by the bootloader is much better used for the code, and then use an ICSP connector to program the IC instead. Once I get a few of my projects a little farther along to the point where I will be making the custom PCB, etc, the ICSP header is my planned way of going about the programming. Obviously there might be some projects that would benefit from the USB connectivity, but most of the ones I have planned don't need that convenience.