Feeler: Open Source OBC Firmware

[daandaman]

^^
Every car has an oil pressure sensor. And the idiot light that goes with it.

Pressure switch

[MParallel]

Pressure switch

Lol yeah..semantics

[Raddee]

Lol yeah..semantics

Well, big difference The switch just tells you "pressure is good" or "pressure is bad", not the exact amount.
There are some sensors that have a connection for both the oil warning light and an analog output to hook up to a gauge or OpenOBC but you'll have to fit them yourself.

[doktor b]

That's all I want from it, everything else is a bonus. Nice bonus would be ibus messages display.

A guy made the oil temp/pressure in an E31 OBC years ago and I believe was the inspiration for the OpenOBC/

this video is perfect. if i could get oil temp, press, and voltage on one screen, i'd buy this today.

Please note that it only works, of course, if you add the sensors to your car. I don't know of any E36s that have oil temp/pressure sensors stock (except maybe the M3?). The screens aren't really configurable so if you want to convert the inputs to actual readable values or show them in the order you'd like you'll need to modify the source code (i.e. I wanted to have my coolant and external temperatures on 1 screen, so I added a screen for that). My OpenOBC came with firmware preinstalled, but flashing firmware isn't really rocket science, just install a little program and hook it up through USB (editting source code and setting up the stuff to compile that is more complex).

i'm ok with installing appropriate sensors. and i'm aware that they will need installed.
my concern is writing the code (witchcraft) to make it all work.
i read the operator's manual for idiots. (excellent work, Daan), but trying to wrap my head around programming, for me anyway, is similar to catching a bullet with my teeth. (same result anyway)

what i'm not opposed to is buying the OpenOBC and having one of you witchdoctors program it to do my bidding, then adding sensors and rejoicing in my stealthy instrumentation.

[fusionr300zx]

This is awesome, wish I saw this before I ordered gauges, def would have been nice to leave the top down and not worry about someone stealing gauges out of my car.

[Raddee]

As promised, some pictures:

Combined coolant/external temperature reading:


WhatsApp notifications (clock showing the current/total notifications, browsable):


Some datalogs graphed in Excel:

[MParallel]

Well, big difference The switch just tells you "pressure is good" or "pressure is bad", not the exact amount.
There are some sensors that have a connection for both the oil warning light and an analog output to hook up to a gauge or OpenOBC but you'll have to fit them yourself.

Fair enough.

[daandaman]

As promised, some pictures:

Combined coolant/external temperature reading:


WhatsApp notifications (clock showing the current/total notifications, browsable):


Some datalogs graphed in Excel:

Holy shit. Please contact me at

d.c@live dot nl

[MParallel]

As promised, some pictures:

Combined coolant/external temperature reading:

Very nice!

H2O temp and OEL (ÖL) temp/pressure displayed at once would be awesome

[hakhawk]

unsure if itd be possible, but would be nice to have ability to show 3 different values on the screen, but to be able to switch choices, say with the 10,100,1000 buttons, so you can choose which 3 things you want to show, adding inputs for say afr, boost, etc.

so you can have ie.

oil, coolant, voltage

press button 10, changes to

afr, coolant, voltage

or press button 1000

oil, coolant, outside temp.

[MParallel]

Any new things? Now that my M3 is back on the road, it's time to get me an OpenOBC board. As long as oil pressure and temp are available (from the DME readout) I'm game.

[Raddee]

Getting readouts from the DME is what I'm focussing on right now. I haven't had any luck talking to my DME from OpenOBC; I think I have the protocol figured out but I'm still figuring out the wiring and stuff for the DS2-bus to get the signals to the right place. Also, my car is not an M3 and each DME seems quite specific, so I'll probably need a test subject after I get it working on my own car.

[daandaman]

Order it, wont take long before we have a decent firmware update

[brunp]

so, I still have the one OBC that I have yet to really play with and then another that I still have to solder together for a friend. I haven't touched the S/W and code in ages, but will definitely pull an update and reapply the firmware. I think it would be cool to add the oil temp retrofit to the OBC and then also modify the round cap, so it doesn't interfere with the OBD reads of the revs/minute.

Pual

[Nomade30]

Anyone know if the ECU handles the DS2 messages and I can just hook up the OBC to the K-line in order to get information? I'm gonna try and make a mount for it in my e30 and I have a lot more experience under my belt (specifically with communications through cars).

[Raddee]

Anyone know if the ECU handles the DS2 messages and I can just hook up the OBC to the K-line in order to get information? I'm gonna try and make a mount for it in my e30 and I have a lot more experience under my belt (specifically with communications through cars).

No, it will not work out of the box and will require software modifications. What type is your ECU?

[Nomade30]

No, it will not work out of the box and will require software modifications. What type is your ECU?

413. Why won't it work?

Iirc most messages are sent to the ecu rather than the body control module, correct me if I'm wrong as I haven't had a chance to research back into it again.

[Raddee]

413. Why won't it work?

Iirc most messages are sent to the ecu rather than the body control module, correct me if I'm wrong as I haven't had a chance to research back into it again.

The current software does not talk to the DME Only to the instrument cluster (and that's just for coolant temperature). There is code for DS2 communication but you'll have to write code that actually talks to your DME; which of course is possible if you have the C++ experience and knowledge of the protocol, but it's definately not a matter of changing a setting or simply hooking it up and have it displaying values.
I'm currently working on software that talks to the DME but for now thats just for DME's that I have at my disposal to test on (which is my own BMS43 and hopefully also MSS50 in the near future).

[Nomade30]

The current software does not talk to the DME Only to the instrument cluster (and that's just for coolant temperature). There is code for DS2 communication but you'll have to write code that actually talks to your DME; which of course is possible if you have the C++ experience and knowledge of the protocol, but it's definately not a matter of changing a setting or simply hooking it up and have it displaying values.
I'm currently working on software that talks to the DME but for now thats just for DME's that I have at my disposal to test on (which is my own BMS43 and hopefully also MSS50 in the near future).

If you look about half way through this thread, I did some coding on this project, and IIRC most of it was done via ZKE messages. Has anyone made more progress on the DS2 protocol? Probably gonna instead of trying to wire up my openobc unit, hook up a obd2 adapter and use my j2534 devices to communicate via DS2.

[Raddee]

If you look about half way through this thread, I did some coding on this project, and IIRC most of it was done via ZKE messages. Has anyone made more progress on the DS2 protocol? Probably gonna instead of trying to wire up my openobc unit, hook up a obd2 adapter and use my j2534 devices to communicate via DS2.

Aha, I see

From what I have seen, the protocol (and bus) for talking to the ZKE and instrument cluster is roughly the same in essence as the protocol for the DME. You can sniff the complete commands and replies out of Ediabas or using the Debug Trace feature in Test-O so from then it's just copying and figuring out what is what in the reply.
Btw, that is all assuming the DS2 bus in an E30 is the same as the E36, that goes beyond my knowledge.
I have had no luck yet getting my OpenOBC to talk to the DME though, but all the hardware should be there, just need to get the right signals to the right place.. Once I get that working its easier to gather more data to figure some stuff out.

[Raddee]

Project progress! Sadly the DME part took a bump because somehow a transceiver chip on my OpenOBC keeps breaking when I hook it up to my DME and we can't seem to get a hold of benemorius; so if anyone with a bit of electronics knowledge can assist with that, we'd be grateful, send me a message!

The good news is, next to Bluetooth, I now have a working TPMS hooked up:

[Castiel]

Wow. Just...wow. I love the 'Idiot's Guide' and sincerely appreciate all the work that's gone into this. Any more updates on what people are programming in or is this thread dead and I should go to the seller's forum? I'm buying one! Any pics of the cable you mate the OBC to your laptop with?

[chikinhed]

My only issue with the OpenOBC right now is that I have to disconnect it to use an OBD2 scanner. I've installed a switch to break the signal from the cluster but that didn't do it. I'm going to install another switch to break the connection at the 20 pin connector cap so that I can get access to the OBD2 port without pulling over and installing the cap. Too bad we can't have both.

Sent from my GTX3582R

[chikinhed]

This is probably a simple problem I'm having but I'm stuck. In the GCC command prompt screen I see:

C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3>

The Idiots Guide tells me to type in the firmware directory path. I placed the firmware in the C: drive folder:

cd c:\openOBC-devboard-2.0\openOBC-devboard-2.0\

So I end up with this:

C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3>cd c:\openOBC-devboard-2.0\openOBC-devboard-2.0\

I press 'enter' and get this:

The system cannot find the path specified.

Help!

[daandaman]

This is probably a simple problem I'm having but I'm stuck. In the GCC command prompt screen I see:

C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3>

The Idiots Guide tells me to type in the firmware directory path. I placed the firmware in the C: drive folder:

cd c:\openOBC-devboard-2.0\openOBC-devboard-2.0\

So I end up with this:

C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3>cd c:\openOBC-devboard-2.0\openOBC-devboard-2.0\

I press 'enter' and get this:

The system cannot find the path specified.

Help!

Chikin, from what i can tell you are having problems to navigate to the right folder within the command prompt? You could try to enter the same in windows command prompt (CMD in the start menu) just to see if that will work.