OBD MPGuino gauge

[tangomar]

is it compatible with kill-switch feature?

I mean, when I stop at a long (>30sec) red light I turn off the engine. I still would like to know what is the overall fuel usage from home to work (including the engine stops).

[cmags]

That should be fine. If you're at a light and stop the engine, then start it again when you go, the OBDuino will start back up when you start the engine, resuming your fuel consumption and distance from where you stopped.

The issue comes in when doing EOC, you'll be racking up miles on your car's ODO, but not in the OBDuino, so the trip distances will not match up, and your eco-tricks won't show up in your OBDuino-reported economy.

Maybe we can change the RPM->0 check to add a timeout so we can record our miles without the engine running for EOC? Or maybe we can only save when we have RPM->0 and speed->0?

[trebuchet03]

Originally Posted by cmags

Maybe we can change the RPM->0 check to add a timeout so we can record our miles without the engine running for EOC? Or maybe we can only save when we have RPM->0 and speed->0?

An RPM timeout would be better in my opinion... 120 or 180 seconds maybe?

I don't have a kill switch, I turn my key back slightly (in between run and off). It keeps the accessories and lights on and kills the engine and the speed sensor with it.

I really should put some time into the code

[dcb]

I know there's a lot of talk about saving the trips, but its all but a non-issue on a working guino. As long as the battery connection is there, the trips are there, and I hardly ever unplug the guino.

It is nice during development however. But once the device is fairly stable, it stays plugged in, so it doesn't really matter. Unless I'm missing something here.

[Magister]

Originally Posted by cmags

The issue comes in when doing EOC, you'll be racking up miles on your car's ODO, but not in the OBDuino, so the trip distances will not match up

No, I thought about it when I made the code. When you shutdown the engine, you have to re-put the key in the "ON" mode (else the ECU can not talk, obviously). So even with the engine off, the OBDuino will continue to accumulate distance because VSS will still answer. I tested it on down slopes, it works.

Tip 55:

EOC can be accomplished in non-hybrids as well simply by shifting to neutral and switching the key from "Run" to "Acc" (being careful not to switch to "Off" and cause the steering to lock). As soon as the engine stops, return the key to the "Run" position so the odometer continues to count distance traveled and you're ready for a re-start.

[cmags]

Even better. So you save the value, but re-load it as soon as we go into On, rather than wait until the RPMs go > 0. Very cool. I'll be prototyping this this weekend.

[gspong]

Originally Posted by cmags

The OBDuino and MPGuino are both coded specifically for Hitachi HD44780 LCD displays. I know that some OLED displays are built with the same controller, and should in theory work. If the VFD comes with the same controller, its probably good as well. However, I can say that the timing does seem to be a little touchy. I had some other "equivalent" displays that just wouldn't stay running right and the issue wouldn't go away until I purchased the "official" LCD. Definitely at your own risk, but if you have a HD44780 equivalent controller, then you should be good to try it out.

Noritake makes VFDs with an HD44780-compatible controller. I picked up a few surplus ones years ago, and a few are probably still in the closet at my parents'. If I ever get around to putting together an MPGuino, I could try one out and see.

[Magister]

(from an old message)

Originally Posted by jmilk

First off, I think ELM is the wrong way to go.

Yes and no, for version 1.0 at least it gave me the opportunity to develop all the higher level code of the OBDuino easily.
Also the ELM327 can interface with a lot of Windows softwares and 30$ + a few components is still better than a $100 interface.
I had to deal with ELM support and they are great and very responsive, their chip is nicely programmed, stable, and powerful too.
In fact, the only "no" is the price...

Originally Posted by jmilk

Instead, I would go with the MC2515/MC2551 combination.

Now that the code is very stable, I am looking at the MCP2515/2551. I am using a free CAN library that interface with the 2515 thru SPI, I adapted the code to use this instead of the ELM (with some #define). I designed a schematic interface (I'll post it in the project wiki) and started to built it. All I need now is a 2515 but MC sample is temporarily unavailable but everything else is ready

Originally Posted by jmilk

Advantages:
- Less than $5 in single quantities, less than $3 in 100+.
- Available in DIP (and smaller form factors)
- SPI instead of RS23x -- forget baudrates, AT-commands and all that junk + run full-speed.
- ELM still calls their (expensive!!) chips "experimental", while Microchip is already on the 2nd generation of production.
- MC isn't going anywhere... ELM?
Disadvantages:
- Slightly more code.

I have to agree, luckily enough for the "disadvantge" there is CAN library and MCP2515 SPI library available freely.

Originally Posted by jmilk

Secondly, I think the arduino/ATMega platform is fine; AVR's automotive chips with built-in CAN are interesting, but beyond the reach of a hobbyist as far as handling goes. If code size really becomes an issue, there's the option of the ATmega328 with 32K flash. Additional advantages of the Arduino platform are the bootloader and IDE; and the 168 and 328 are available in DIP forms.

Right, an AT90CAN could do the job but there is no "arduino" like for it.

Originally Posted by jmilk

For my CAN scenario, I'm looking at $10-$12 in parts excluding the PCB, LCD and connector. The whole thing, in single quantity, should come in under $30 -- that's less than the ELM chip alone.

Right, the OBDuino "CAN only" is an MPGuino + $10 of components (or less).

Originally Posted by jmilk

- Replace the "trip computer"
- Add instant mpg
- Add avg mpg last x minutes/miles, since last stop, since beginning of trip, today, this week, this month.
- Track/log mpg for different drivers.
(and a few more)

Well, there is 2 separate trips for the moment, but adding more just add a few bytes so it's possible to extend it

In resume, ISO can be done with a Freescale 33290 (untested) and CAN with MCP2515. For VPW/PWM for the moment the only solution is an ELM322/320.

[trebuchet03]

oKay, I'm jumping into the fray.

Today I got my 33920's, 510 ohm resistor, misc. filter caps, LCD (hopefully works), RJ45 socket (for OBD interface), voltage regulator... I'm going to use a thumbduino for the micro. Later, I'll get a $5 alarm clock, to harvest the tactile switches...

I'm going to focus on OBD->Laptop data logging... While not exactly novel, I can't find the metrics I want. Hopefully, my programming skills are close to what is necessary to follow the code I really can't complain about features if I'm not contributing


One question


The 2n3906... What is that doing? It's the only component I'm missing....

[Magister]

For OBD logging to a laptop, you'll have to enable the serial port and in the get_pid() function you'll have to do a serialWrite() with the info you want to export.

The transistor is used to drive the brightness as some LCD LED can take 100mA and the pins only output 20mA so if you plug the pin directly on the LCD, you will burn the pin output.