Feeler: Open Source OBC Firmware

[m2pc]

Thanks guys, it's nice to finally be getting somewhere with this project. I should have the expansion board drawn and ready for production any day now as well. Stay tuned!

[Saloon]

Subscription bump!

[m2pc]

Another update!

I just finished drawing the board layouts for the "A" and "B" expansion boards. These plug directly on top of the main openOBC board to provide additional expansion.

The "A" board, with GPS, 3-axis accelerometer, analog inputs, and 8 high current outputs, suitable for directly driving relays and small solenoids:


The "B" board, for the adventurous type, is strictly a plated through, 0.1" centered solder breadboard:


Once I verify each of these, I will order boards and continue the process!

[Mark185]

Outstanding progress on this! I have not visited this thread in a long time and I am very impressed with where the developers have taken this project.

I am very interested in the expansion capability you are designing. Are the analog inputs on the expansion board buffered or filtered in any way or just pass through signals to the PIC microprocessor analog inputs? I ask because it can be risky to pass automotive analog sensor signals directly to a microprocessor without analog low pass filtering and some kind of voltage clamp to protect against spikes.

Can there be more than one expansion board with different types of analog inputs? For example, with a turbo or supercharged engine, it would be desirable to have Exhaust Gas Temp monitoring. I am thinking this would have to be an additional expansion board for several reasons. Most folks will not want it and the additional signal conditioning circuits would probably not fit on the existing expansion board.

[JerCotter7]

What's the accelerometer for? Gonna hook it up to show lateral g's?

[m2pc]

Outstanding progress on this! I have not visited this thread in a long time and I am very impressed with where the developers have taken this project.

I am very interested in the expansion capability you are designing. Are the analog inputs on the expansion board buffered or filtered in any way or just pass through signals to the PIC microprocessor analog inputs? I ask because it can be risky to pass automotive analog sensor signals directly to a microprocessor without analog low pass filtering and some kind of voltage clamp to protect against spikes.

Very good points. Currently I'm routing 4 A/D inputs directly from the PIC to the I/O header on the expansion board. IIRC the PIC does have some sort of input protection/filtering built-in; I'll check the datasheet to be sure and I'll see if I can diode clamp these, and filter to ground using a bypass cap if needed. Most of these will be resistive dividers to allow for various sensors. Most sensors are either 0-5V or 0-12V or varying resistances.

Can there be more than one expansion board with different types of analog inputs? For example, with a turbo or supercharged engine, it would be desirable to have Exhaust Gas Temp monitoring. I am thinking this would have to be an additional expansion board for several reasons. Most folks will not want it and the additional signal conditioning circuits would probably not fit on the existing expansion board.

Currently I'm designing 2 expansion boards: One ("A") with GPS, Accelerometer, 8 500mA output drivers, and 4 A/D inputs as well as a CAN bus interface for even further external connectivity. The second ("B") board is strictly a breadboard for prototyping/custom circuitry.

Maybe we need a "C" board that removes either the GPS or the Accelerometer and focuses more on I/O expansion, with filtered, op-amp buffered A/D inputs with configurable offsets, etc. Since there is an SPI bus on the expansion card, we could even include some DigiPots to drive the input adjustment from the software side.

EDIT: I just checked the datasheet and all the PIC I/O pins are diode clamped internally to VCC and GND. Just for extra measure, I'll update my design to include a series resistor and a pair of extra Schottky diodes between the PIC's power rails. This should provide current limiting, plus clamp any transients to within 0.3V of the rails.

[Mark185]

All good ideas in your response to my questions but this really is interesting to me:

"Maybe we need a "C" board that removes either the GPS or the Accelerometer and focuses more on I/O expansion, with filtered, op-amp buffered A/D inputs with configurable offsets, etc. Since there is an SPI bus on the expansion card, we could even include some DigiPots to drive the input adjustment from the software side."

I have been playing with concepts for stand alone data acquisition for my Celica All Trac Turbo which is an OBD 1 system. (Using an AVR Butterfly as basic development platform because it is cheap but capable and a free C compiler is available.) The Celica has a modified turbo engine and I want to monitor EGT, boost pressure, oil press, oil temp, water temp, inlet temp, and other parameters. I don't think I would attempt to use the complete Open OBC design but would be interested in adapting an expansion board for this vehicle.

I am also very interested in using the Open OBC to modify the computer in my 97 328iC. I do not plan forced induction on that car and would not have as much interest in additional instrumentation for it. Your base design is a good fit for my interest on the bimmer.

[m2pc]

All good ideas in your response to my questions but this really is interesting to me:

"Maybe we need a "C" board that removes either the GPS or the Accelerometer and focuses more on I/O expansion, with filtered, op-amp buffered A/D inputs with configurable offsets, etc. Since there is an SPI bus on the expansion card, we could even include some DigiPots to drive the input adjustment from the software side."

I have been playing with concepts for stand alone data acquisition for my Celica All Trac Turbo which is an OBD 1 system. (Using an AVR Butterfly as basic development platform because it is cheap but capable and a free C compiler is available.) The Celica has a modified turbo engine and I want to monitor EGT, boost pressure, oil press, oil temp, water temp, inlet temp, and other parameters. I don't think I would attempt to use the complete Open OBC design but would be interested in adapting an expansion board for this vehicle.

I am also very interested in using the Open OBC to modify the computer in my 97 328iC. I do not plan forced induction on that car and would not have as much interest in additional instrumentation for it. Your base design is a good fit for my interest on the bimmer.

I don't see why you couldn't adapt the expansion board to your AVR project. As long as you have +5V and +3.3V along with SPI bus and some address lines, it would work.

Yes, the basic openOBC design is ideal for people who want a bit more out of the stock unit without a lot of expansion. Just being able to read and reset OBD-II trouble codes would be a huge plus, which is the goal of the system.

[kingsly]

Your board drawings look fantastic! Poking my head in from the E39 side of things... what are the odds we can port this project to our OBC's?

The software is probably the same, but the hardware is a totally different animal.

[kingsly]

Your board drawings look fantastic! Poking my head in from the E39 side of things... what are the odds we can port this project to our OBC's?

The software is probably the same, but the hardware is a totally different animal.

[m2pc]

Your board drawings look fantastic! Poking my head in from the E39 side of things... what are the odds we can port this project to our OBC's?

The software is probably the same, but the hardware is a totally different animal.

Doesn't the E39 have an integrated "MID" in the cluster and nota separate OBC unit? If so, those can be addressed via the I-bus from a remotely mounted device. I've seen a lot of iPod interfaces do this to display song titles, etc.

The E31 is similar; the OBC is just a display fed from the I-bus.

Other OBCs that could be used would be the 7 and 11 button E36 variants.

Update: New version "A" design, with diodes between power rails and series resistors protecting all A/D inputs:

[kingsly]

Yeah we've got a MID pulling info from god-knows-where. All the info can be displayed in the instrument panel display too, pretty cool having the mpg in the dash and dte or whatever below the spedo simultaneously. It would be even cooler to access live engine data or accelerometer info. And even even cooler to drive a third display positioned to reflect off the windshield and act as a HUD.

Sounds like it might even be slightly simpler since we can just tap into the I-bus? I'd happily donate my car to science if you think it could be done! : )

[m2pc]

Yeah we've got a MID pulling info from god-knows-where. All the info can be displayed in the instrument panel display too, pretty cool having the mpg in the dash and dte or whatever below the spedo simultaneously. It would be even cooler to access live engine data or accelerometer info. And even even cooler to drive a third display positioned to reflect off the windshield and act as a HUD.

Sounds like it might even be slightly simpler since we can just tap into the I-bus? I'd happily donate my car to science if you think it could be done! : )

iBus interfacing is actually very simple. Here's an example that uses a handful of components: http://e34.org/forums/posts/142176

It would be a matter of adding these circuits and reworking the openOBC main board. Then, instead of driving the main (integrated) OBC display and reading its keyboard buttons, it would send commands over the iBus to the various displays in the car, and read buttons from the steering wheel and NAV console.

So we'd have a "headless" openOBC board with expansion board tucked away somewhere in your E39 performing all these functions. The tough part will be how to get things like a) Vehicle speed, b) Fuel consumption, c) Fuel tank level, d) Ambient temperature, etc, etc. These signals are present in the OEM connectors in the E36; I have no idea where these are in an E39. Maybe the vehicle diagnostic bus of the E39 has these, but again no idea as I have not researched it.

For starters though, I'd like to focus on getting the E36 version working 100%, then branching out into other models is possible.

One last thought on the iBus; some E36 head units (CD43 for example) are connected to the iBus and can be addressed. So the stereo is a 2nd display option in the E36 for openOBC with an iBus interface!

[kingsly]

Yeah get the E36 one going first and then we can look at other models. I am very excited about the prospects of this project!

[m2pc]

Update: I spent about 4 hours over the past week tracing out every wire and component and verifying the design of the main board and the "A" expansion board.

I found a few problems, but nothing major. Mainly ground plane issues but easily fixed.

I'll be ordering real PCBs by the end of this week!

[vandy]

I don't understand half of the words in this thread, but it looks like good, hard work. I'm impressed!

[m2pc]

Update: Boards have been ordered. I ordered a set of 10 main boards and 10 expansion "A" boards to start. Exciting times!

Boards will be delivered by next Wednesday (1/19) by noon.

[Bryson]

Could the software be modified to accept the error signal to replace the e31 MID? It would be great to have all this functionality and have an option for replacing the shitty, rare e31 MID.

[m2pc]

Could the software be modified to accept the error signal to replace the e31 MID? It would be great to have all this functionality and have an option for replacing the shitty, rare e31 MID.

The E31 MID is a different animal than the E36 OBC from what I've read. Rather than tie all the sensors and inputs into the MID itself, the E31 MID gets all this info over the vehicle's data bus. It may be possible, but without access to an E31 and and E31 MID, it's going to be difficult.

But yes, anything is possible. Right now my focus is to get the E36 version completed, then we can move to other platforms/variations.

[Smitherines]

Subbed!!!

[m2pc]

Parts are on order from DigiKey to make 1 real prototype. Cost is around $50 for the parts, plus around $60 for the PC boards, not including the GPS and accelerometer which I already have. Not too bad for a single quantity.

I'll be populating 1 main board and 1 expansion "A" board once the boards arrive from the PCB house on Wednesday.

Once that is proved, I will continue with the software side of things.

[Mpowered02]

Parts are on order from DigiKey to make 1 real prototype. Cost is around $50 for the parts, plus around $60 for the PC boards, not including the GPS and accelerometer which I already have. Not too bad for a single quantity.

I'll be populating 1 main board and 1 expansion "A" board once the boards arrive from the PCB house on Wednesday.

Once that is proved, I will continue with the software side of things.

Loving the progress and anxiously awaiting the end result.
Quick question though...kinda unrelated to the OpenOBC discussion, but maybe not. Is it possible to modify or reprogram the OBC or Check Control Module so that it can properly monitor the lighting circuits running LED's and Xenons instead of regular incandescent and halogen bulbs? I figure you electrical gurus would have A better chance with this than I...

[m2pc]

Update: The boards arrived today!!!



and

Loving the progress and anxiously awaiting the end result.
Quick question though...kinda unrelated to the OpenOBC discussion, but maybe not. Is it possible to modify or reprogram the OBC or Check Control Module so that it can properly monitor the lighting circuits running LED's and Xenons instead of regular incandescent and halogen bulbs? I figure you electrical gurus would have A better chance with this than I...

Thanks, it's been a fun project thus far! As far as the Check Control Module goes, to have it not throw errors for LED and HID bulbs, you'd need to crack the CCM open and swap out a few resistors to allow it to sense lower current draw and not trigger a fault condition.

One thing the openOBC will do, however, is allow you to selectively DISABLE certain CCM messages from being displayed. For example, if you know your HIDs cause the LBF frequently, you can disable just the LBF message.

Rats, parts shipment delayed until tomorrow. I'll have some pics of the populated boards up ASAP as I continue my testing.

[digitalsolo]

This is really slick, glad to see you making some progress!

[Dricebrug]

You have no idea how glad it makes it to see this actually happening.

You just caught me at bad time for help. Gimme a few digital classes and then I'll be of assistance.