OBD MPGuino gauge

[jmilk]

Originally Posted by dcb

Easy cowboy Elm has been decided for 1.0, it is universal, easy to implement, and being through hole it is very "kit"able. We are going to work on the price AFTER getting something out there.

for the post elm obd version, we hope to be as low cost as possible, but have not abandoned the arduino platform yet. ishiyakazuo is looking into a software only (duino + a couple transistors) ISO implementation. Maybe you want to sort out the bare bones CAN details? It would be good if there is a bare minimum through hole couple transistors software only CAN version as well, as far as price and assembly go.

Agreed. Elm is a good starting point. I'll probably skip 1.0 myself.

As far as bare-bones CAN, I'm not convinced it's a good idea. Hardware alone wouldn't just be "a couple of transistors", but rather quite a number of discretes (at least two Zeners, Cs, Rs, probably an op-amp). You'll need to worry about slew-rate, shielding the Arduino from transients and all that good stuff, and -- more importantly -- shield the car's CANbus from the Arduino. Just imagine what might happen if EMI within the Arduino is amplified and makes it to the CANbus, or if a transient melts your termination and shorts the bus... the CAN operates on a shared medium, and might well disable the car if choked.

And that's the next point... collision detection, arbitration, bitstuffing and phase-locking are all non-trivial problems that have folks much smarter than us scratching their heads. I don't think a 16 Mhz 168 is fast enough to handle 500kbs... even at 20 MHz you only have 40 cycles per bit to decode what's coming across the wire, and if that's enough, the uP is then fully utilized.

Logically, then, you might be looking for a second uP to handle the UI, and there you are out another $3-$4, along with the discretes... you might as well go with an available and proven solution.

Reading ahead (while I'm writing this) it appears ishiyakazuo was going the AT90-route. He is correct on the combined cost of MC+mega**8 solution vs. the AT90. Do keep in mind that the prototyping cost of the MC solution is considerably lower -- breadboard, RBBB, two DIP chips, done. No mussing with adapters or break-out boards. Ditto for reproducibility -- heck, you can wire-wrap this baby or stick it on a proto-shield.

I don't think we'll need 64K -- a large portion of the 12K-or-so in use now comes from the libraries you linked in. 32K should be plenty to do what you're attempting to accomplish here. I do have two precious ATmega328s here (thanks for the samples), and it's a perfect drop-in replacement for the 168. I'll pull the code and check the baseline this weekend.

BTW, good call on the Altoids tins The custom PCB to populate a la carte is certainly a very well "kit"able option. I'm curious to see how the differential bus compares to, say, an RS485, where many solid interfaces are available.

[dcb]

Originally Posted by jmilk

I don't think a 16 Mhz 168 is fast enough to handle 500kbs...

The elm runs at 4.00 mhz.

[ishiyakazuo]

Originally Posted by dcb

Also worth noting that the atmega32 for arduino probably isn't very far off either and it should just be a drop in replacement for the atmega168. I know a few folks have already got it working. It has 2Kram and 32kflash, 1Keprom and is a buck or two more.

I meant to mention going this route, actually.

Originally Posted by jmilk

As far as bare-bones CAN, I'm not convinced it's a good idea. Hardware alone wouldn't just be "a couple of transistors", but rather quite a number of discretes (at least two Zeners, Cs, Rs, probably an op-amp). You'll need to worry about slew-rate, shielding the Arduino from transients and all that good stuff, and -- more importantly -- shield the car's CANbus from the Arduino. Just imagine what might happen if EMI within the Arduino is amplified and makes it to the CANbus, or if a transient melts your termination and shorts the bus... the CAN operates on a shared medium, and might well disable the car if choked.

I think there was a misunderstanding somewhere. We were talking about "a couple of transistors" for the ISO-9141 bus, which is fairly low speed and is basically RS-232 at different levels and at a strange 10400 baud rate.
For CAN, we'd use one of the following hookups:
- ELM 327 with its recommended schematic
- The Microchip parts you proposed
- AT90CAN parts with hardware CAN support

Originally Posted by jmilk

And that's the next point... collision detection, arbitration, bitstuffing and phase-locking are all non-trivial problems that have folks much smarter than us scratching their heads. I don't think a 16 Mhz 168 is fast enough to handle 500kbs... even at 20 MHz you only have 40 cycles per bit to decode what's coming across the wire, and if that's enough, the uP is then fully utilized.

Logically, then, you might be looking for a second uP to handle the UI, and there you are out another $3-$4, along with the discretes... you might as well go with an available and proven solution.

No one was ever suggesting we should implement CAN in software It's hard enough with a dedicated PHY, from what Yoshi said.

Originally Posted by jmilk

Reading ahead (while I'm writing this) it appears ishiyakazuo was going the AT90-route. He is correct on the combined cost of MC+mega**8 solution vs. the AT90. Do keep in mind that the prototyping cost of the MC solution is considerably lower -- breadboard, RBBB, two DIP chips, done. No mussing with adapters or break-out boards. Ditto for reproducibility -- heck, you can wire-wrap this baby or stick it on a proto-shield.

Agreed. Plus it's much quicker to get everyone the same setup.

Originally Posted by jmilk

I don't think we'll need 64K -- a large portion of the 12K-or-so in use now comes from the libraries you linked in. 32K should be plenty to do what you're attempting to accomplish here. I do have two precious ATmega328s here (thanks for the samples), and it's a perfect drop-in replacement for the 168. I'll pull the code and check the baseline this weekend.

BTW, good call on the Altoids tins The custom PCB to populate a la carte is certainly a very well "kit"able option. I'm curious to see how the differential bus compares to, say, an RS485, where many solid interfaces are available.

The only reason I was talking about AT90CAN64 vs AT90CAN32 is because the 64 is less than a buck more, and is more widely available. (And let's face it, extra flash never hurt anyone... unless you're terribly obsessed with power consumption.) I'll also be picking up some ATMega328s.

[ishiyakazuo]

Originally Posted by dcb

The elm runs at 4.00 mhz.

Actually, it has a 4x PLL in it, so it could also be running at 16MHz...
But also worth noting is that the PIC that the ELM uses (PIC16F2x80) has hardware PWM and CAN as well, so CPU speed may be a non-issue (it's just shuffling data between the serial port and hardware peripherals, with the exception of VPW, which isn't too difficult due to its very broad definition of "10.4kbps" (it could be significantly more or less, depending on how good your bit timings are).

[dcb]

Originally Posted by ishiyakazuo

No one was ever suggesting we should implement CAN in software

I was, just putting it out there

[ishiyakazuo]

Originally Posted by dcb

I was, just putting it out there

Oh, sorry, missed that.
Yeah, probably not a good idea, for the reasons jmilk detailed. If the chip doesn't have a CAN hardware block, it's probably nigh impossible to do with anything cheap (you could write it in straight ASM, and maybe have a shot with a 50MHz ARM7, but at that point you've already blown past the cost of a dedicated CAN part).

[jmilk]

Originally Posted by ishiyakazuo

But also worth noting is that the PIC that the ELM uses (PIC16F2x80) has hardware PWM and CAN as well, so CPU speed may be a non-issue

18F2480, right? Hardware CAN... that'll do it. And it's also my problem with ELM... they're re-selling a $5 chip for $30. That's a $25 license fee for what amounts to bit-shuffling software that shields a tad of the complexity of the underlying bus... and you're pretty much stuck with the firmware, because they don't provide upgrades.

Originally Posted by ishiyakazuo

The only reason I was talking about AT90CAN64 vs AT90CAN32 is because the 64 is less than a buck more, and is more widely available. (And let's face it, extra flash never hurt anyone... unless you're terribly obsessed with power consumption.) I'll also be picking up some ATMega328s.

There's no appreciable difference in power-consumption for flash memory based on capacity. IIRC, flash only actively powers the page currently read-from/written-to, so page count is immaterial. RAM's different, but too small to matter here. Clock speed and operating voltage are just about proportional to power-consumption, however -- even so, I don't think the maximum consumption of fully clocked AT90 (0.15W at 5V/16MHz) would matter in the grand scheme of things (the LCD uses 10x that); and an ATmega328P uses even less... theoretically, it's 0.05W at 5V/20MHz).

[Magister]

Note also that you must be CAN compliant to plug something on your CAN bus, unfortunatly the AtMega is not qualified for C&S CAN Conformance like the AT90CAN.

Also the ELM327/Arduino can be used as a "scantool" interface and be used with dozens of software running on laptop/palm/etc. using a simple 3-wires null modem cable.

The ELM327 v1.3 can easily retrieve 30-80 PIDs per second, which is more than enough. And it implements the basic ISO/VPW/PWM protocol but also the CAN protocol 11 bit and 29 bit, 250k, 500k, header filtering, etc

I agree the solution can move to the AT90CAN** for a 2.0 version, but it needs a PCB and all.

BTW we also use the MC 2551 with the ELM327.
For the code we actually use less than 10k for ISO, my ELM proto is about 12k, we still have space to play with.

[ishiyakazuo]

Originally Posted by jmilk

There's no appreciable difference in power-consumption for flash memory based on capacity. IIRC, flash only actively powers the page currently read-from/written-to, so page count is immaterial. RAM's different, but too small to matter here. Clock speed and operating voltage are just about proportional to power-consumption, however -- even so, I don't think the maximum consumption of fully clocked AT90 (0.15W at 5V/16MHz) would matter in the grand scheme of things (the LCD uses 10x that); and an ATmega328P uses even less... theoretically, it's 0.05W at 5V/20MHz).

Like I said, you'd have to be absolutely nuts to worry about the difference in power usage of the extra flash I think as size increases, the controller is slightly more complex, which adds a VERY miniscule amount to the power usage (we're talking uW here). It was basically meant to be a joke.

The ATmega328P would use less, but then you have to use the extra Microchip part, which might even things up a bit.

I didn't look at the LCD power ratings, but do backlights use that much still? I guess 1.5W isn't that bad when hooked up to a car battery, but I'm a little surprised -- I just wrapped a project a few months back with an ARM7 @ 48MHz with USB, an FPGA and a 2x16 LCD (non-backlit) and the entire setup amounted to about 1W off of a +5v supply.

[ishiyakazuo]

Originally Posted by dcb

FYI, if you are in a hurry, the currently recommended display is made by newhaven display in elgin. I've asked nicely and they have let me stop in to pick up a couple models. You can get everything else from ratshack.

I was looking on Mouser for some other things and noticed this:
Alternate LCD?
It's the same display but with only one set of interface holes.
They also have this one which is the same thing but a little smaller (nice if fitting in your project box is tight).
This other one is yet cheaper but the connector is on the side (in my opinion, the most awkward).
I'm thinking when I lay out my Altoiduino board for this project, I'll try to put the LCD connectors on both the top and bottom so you can use either, and if there's extra space, I'll throw the side connector on too, but routing a handful of pins to two places is bad enough -- 3 is a real pain.

[jmilk]

Originally Posted by ishiyakazuo

I didn't look at the LCD power ratings, but do backlights use that much still? I guess 1.5W isn't that bad when hooked up to a car battery, but I'm a little surprised -- I just wrapped a project a few months back with an ARM7 @ 48MHz with USB, an FPGA and a 2x16 LCD (non-backlit) and the entire setup amounted to about 1W off of a +5v supply.

Pretty close, depending on size and backlight. I have a box of white-lit 4x20 here that draw up to 320mA at 3.4V. That's a 1.6W at 5V, and we provide a 0.5W heating element. If you don't like the heat or the 1/2W R, you can always PWM them over a TIP120 with 10k to base at max 60% duty-cycle (which is an analogWrite ~160). The 10k limits IB to 0.5mA, which the darlington multiplies by 1,000 to 500mA Ic. LEDs tend to be pretty proportional in their relationship between duty-cycle and I. Good idea to reduce Arduino's PWM scaler tho, as the 400Hz default still does 15ms...

ok, but I'm rambling.

[jmilk]

dcb, you're in the Chi'burbs? I'm far NW currently, thankfully not quite Rockford.

Originally Posted by Magister

Note also that you must be CAN compliant to plug something on your CAN bus, unfortunatly the AtMega is not qualified for C&S CAN Conformance like the AT90CAN.

Your PC isn't "CAN compliant" either, but you can connect it to your car through an appropriate interface. The MC2515/MC2551 combination forms the interface to the ATmega (or any other SPI-capable uP you like). "Compliance" isn't really a deciding factor as much as "conformance". You can be conformant without being compliant... in the end, things will work just fine, but you don't get the pretty stamp from the standards body.

[ishiyakazuo]

Originally Posted by jmilk

dcb, you're in the Chi'burbs? I'm far NW currently, thankfully not quite Rockford.

That's amazing. What is it about Chicagoland driving that makes this project appeal so much?
If there's enough of us in the area, might be nice to meet up to do some kind of pooling of resources someday.

[jmilk]

Originally Posted by ishiyakazuo

That's amazing. What is it about Chicagoland driving that makes this project appeal so much?
If there's enough of us in the area, might be nice to meet up to do some kind of pooling of resources someday.

Another FIB, just noticed your location. Frankly, I think it's the flat terrain eco-driving in its purest form.

I've lived in this area 15 years. NW up and down I-90, then a few years W on I-88 and now back far NW on 90. Worked downtown a few years... Metra gets great gas mileage.

Could anyone who lives closer to Elgin explain the strange phenomenon I dubbed "Elgin Zone"? Speed limit west of Elgin is 65, and everyone sticks close to it. Speed limit east of Elgin is 55, and everyone seems to go 75+. What gives? Remember the Kennedy Funnel? Eight toll-lanes two 2+1 lanes and daily parking lots...

[jmilk]

Have you seen this?

[dcb]

Sure, lets hook up. I have to say I'm reminded a little of a Johnny Mullet post re: ohio gathering

Originally Posted by Johnny Mullet

I cleared it with my wife and she said, and I quote..................

"You can have your Nerd-fest 2008 if you like."

I would have loved to get to the renewable energy fair in Oregon, IL, but the timing didn't work out.

[ishiyakazuo]

Originally Posted by jmilk

Another FIB, just noticed your location. Frankly, I think it's the flat terrain eco-driving in its purest form.

I've lived in this area 15 years. NW up and down I-90, then a few years W on I-88 and now back far NW on 90. Worked downtown a few years... Metra gets great gas mileage.

Could anyone who lives closer to Elgin explain the strange phenomenon I dubbed "Elgin Zone"? Speed limit west of Elgin is 65, and everyone sticks close to it. Speed limit east of Elgin is 55, and everyone seems to go 75+. What gives? Remember the Kennedy Funnel? Eight toll-lanes two 2+1 lanes and daily parking lots...

I've been in the 'burbs my whole life. Metra does get amazing mileage My office is right by one of the stations, so I'm looking to get a house on the same train line when I move next.

The Elgin Zone phenomenon is so true, but if I had to hazard a guess about why it happens, it probably has to do with population density -- west of Elgin, the density drops tremendously. With more people, people think they can get away with more.

[jmilk]

I just got a nice little box from Microchip Thailand. Three each MCP2515 and MCP2551 in DIP. Getting ready for vacation, so I don't know how much time I'll have 'till October, but I'll try to get a couple of my RBBBs to talk to each other over CAN on protoboards this week. Wheee!

[ishiyakazuo]

Originally Posted by jmilk

I just got a nice little box from Microchip Thailand. Three each MCP2515 and MCP2551 in DIP. Getting ready for vacation, so I don't know how much time I'll have 'till October, but I'll try to get a couple of my RBBBs to talk to each other over CAN on protoboards this week. Wheee!

Cool, hope it works out well
According to Yoshi, there's a lot to work on as far as getting the protocol working with a car though. It does seem a little heavier of a protocol than, say, ISO.

[Magister]

I made a little interface (see http://opengauge.org/~obduino/diagram/CANduino.gif ) and plugged it on my Arduino, it works

I modified the code to work with the ELM327, init has some problems it seems, but as I don't check error, it went through...

I can see the RPM on my display, pretty cool, but *argh* VSS is not supported by my ECU it seems?!!??! so I can not display speed or calculate consumption. MAF is working at least!

Time to investigate... I should be able to upload a fake application on the duino and with a null cable talk directly from a laptop to the ELM327 as it will go through the MAX232 of the duino board, and I could test some dos/windows application.