Feeler: Open Source OBC Firmware

[Nomade30]

All back to normal. The last command you do might need a post sudo command. OBC is back and working with normal operation. One question I have is my temp doesn't do anything, but code does display the temp feature. Is this the same on your board? Will finally start coding tomorrow hopefully can get an average mileage saved.

[benemorius]

All back to normal. The last command you do might need a post sudo command. OBC is back and working with normal operation. One question I have is my temp doesn't do anything, but code does display the temp feature. Is this the same on your board? Will finally start coding tomorrow hopefully can get an average mileage saved.

Whoops. I forgot about that. Yes, it's the same on mine. The reason is that my temp button doesn't work so I had been using the code button instead. This behavior can be corrected around line 276 in OpenOBC.cpp. It will also be necessary to fill in the correct value for BUTTON_TEMP_MASK in ObcKeypad.h before the temp button will work.

[Nomade30]

I'll just leave this here. Also massive wheel spin.

[M3C]

I'll just leave this here. Also massive wheel spin.

WOW, so it is not accurate?

[Nomade30]

WOW, so it is not accurate?

I don't understand what you mean? The speed signal needs some smoothing but it's pretty close. It's 4 degrees here, pretty hard to get a good launch.

[M3C]

I don't understand what you mean? The speed signal needs some smoothing but it's pretty close. It's 4 degrees here, pretty hard to get a good launch.

This would be one of the very cool features, I am noticing now that this time is from a non M 3 series.

[Nomade30]

This would be one of the very cool features, I am noticing now that this time is from a non M 3 series.

I also have it setup to do any range. For those FI guys that want to do 60-130 MPH. Next feature I really want to implement is reading the check engine codes, but I cannot figure out the DS2 commands.

[M3C]

I guess there will be more time required and others who are familiar with this field to continue contributing until finalized.
Will this be ready in 6 month time?

[Nomade30]

I have no clue on timing for finished product. I will be starting school Monday and that's five classes of programming so I might be worn out to work on this, or this might be a breeze in the park after homework. This is by far one of the funnest projects I have worked on since starting college though.

[benemorius]

I also have it setup to do any range. For those FI guys that want to do 60-130 MPH. Next feature I really want to implement is reading the check engine codes, but I cannot figure out the DS2 commands.

I forgot to ask - you have an OBD-II DME, don't you? If so, you'll just be able to implement a new class based on one of the other modules since (I believe) that DME uses the same protocol. Unfortunately I don't have that DME so I haven't written any code for it and I don't know how to query it for check engine codes.

I think the ZKE class has the most functionality to look at, though not by much. It has methods for locking and unlocking the doors. It's hardly anything, but it does provide a good example of sending a command in a packet and receiving (though not yet parsing the information contained in) a reply packet. Actually it's a really simple protocol. A packet has an address, a length, a checksum, and one or more bytes of data. That's it. Often the data is just one byte - a command.

In order to gain the functionality of displaying check engine codes (also engine datalogging, etc.) it will be necessary for someone to hook up their openobc (or logic analyzer or whatever else) while running diagnostics with INPA or DIS in order to capture and analyze the packets and figure out which commands do what and how to read the data in the replies. I have plans to do this for all the modules I have in my vehicle in the coming months, but I don't have the OBD-II DME so it may be necessary for someone else to do this.

I guess there will be more time required and others who are familiar with this field to continue contributing until finalized.
Will this be ready in 6 month time?

I've been mistaken about time estimates several times already, but I'll go ahead and say that I'd be pretty surprised if something isn't ready within 6 months. The hold-up thus far has been the fact that with so few of us working on the project, Murphy had little trouble pulling us all away from it for one reason or another. With more people now starting to play around, it will be statistically less likely that everyone will become unavailable simultaneously.

[Nomade30]

I do have OBD2, so it should be easy to implement. Only thing I'm scared about is receiving DS2 back and understand the bytes correctly. Also I didn't grab the github correctly and changed somethings, so I think I'm gonna commit to separate repo.

[jdantuono]

What features would be readily available to us OBD-I guys?

[Morgion]

What features would be readily available to us OBD-I guys?

Seconding this, I'm also OBDI.

[jdantuono]

I'd really like to be able to connect an o2 sensor to one of the wires in the back and use one of the function buttons to read my AFR. =)

[Nomade30]

That's possible. I'm not an electrical engineer so I have no idea how it works.

But just an update I'm refactoring the code to make it a lot more simple, my current C++ teacher is also helping me understand somethings I'm confused about.

[benemorius]

What features would be readily available to us OBD-I guys?

Everything that INPA and DIS can do will be available. As for just how readily available that stuff is... well, that's more complicated. Doing actual diagnostic work as you would do with INPA or DIS - checking and clearing codes, verifying sensor data, etc. - that will be done no problem. It's datalogging and other everyday use cases where things get messy.

Communication with the OBD-I DME basically requires that you remain in constant communication with it and it hogs the bus preventing you from communicating with any other module concurrently. It throws a real big wrench into my vision for everything and was largely responsible for me getting pissed off and turning my attention elsewhere for a while.

I've thought about making a separate translator board to splice into the DME harness and emulate the newer protocol so it behaves nicely on the diagnostic bus, but that's not a very clean solution either and I haven't yet made a decision about it.

All this doesn't mean that OBD-I cars are completely out of luck. It just means that things won't be as seamless, and in addition to the existing shortcomings of OBD-I (less data available than OBD-II) there may be some additional restrictions that arise from the inability of the openobc to remain in constant simultaneous communication with the DME and all the other modules in the car.

I'd really like to be able to connect an o2 sensor to one of the wires in the back and use one of the function buttons to read my AFR. =)

This has been intended right from the start and I've included generic analog inputs to accomodate it. Unfortunately I don't have such an o2 sensor myself or I'd likely have done it already. If someone wants to buy me one I can gladly oblige, but of course I can't make any promises with regard to time.

[Mark185]

I'd really like to be able to connect an o2 sensor to one of the wires in the back and use one of the function buttons to read my AFR. =)

I have been away from this thread for some time now but it remains one of the more interesting things on Bfc. Excuse me if what I am about to describe is already understood but it sounds like you may want to connect a factory O2 sensor to the Open OBC.

I am an old analog EE and I can tell you that you can't simply connect a factory O2 sensor to the Open OBC without some serious signal conditioning in between. The factory O2 sensor is not even suitable for reading the AFR directly. It is designed to switch rapidly around the target AFR programmed in the engine computer (DME) to keep fuel trims 'tweaked' to maintain said target AFR. When the factory O2 sensors degrade, they start to switch more and more slowly and this has a negative impact on engine performance.

This unfortunately is not a good strategy for measuring AFR accurately and displaying it. Aftermarket wideband O2 sensors are designed to measure and display AFR accurately but they are not strictly compatible with the BMW engine controller (DME). Some wideband O2 sensors have a control box/signal conditioning unit that can be programmed to output a signal that mimics what the engine control computer is expecting. This type of sensor could be substituted for the factory sensor and used for Open OBC use and input to the engine ECU.

There is an additional wrinkle to this. OBD II inline six BMW engines have two O2 sensors with three cylinders feeding each one. The exhaust manifold is a two piece design with the split between cylinders 3-4. You have to choose which 3 cylinders you want to monitor or provide two inputs to the Open OBC and install two aftermarket wideband sensors. OBD I inline 6 engines have one O2 sensor located further downstream and would be somewhat easier to do this with. The V8 engines also have two sensors with one for each bank of 4 cylinders. The sensors I am referring to are all upstream from the catalytic converter. OBD II cars also have sensors after the cats to measure cat efficiency.

[jdantuono]

BUMP for UPDATES!

I have been away from this thread for some time now but it remains one of the more interesting things on Bfc. Excuse me if what I am about to describe is already understood but it sounds like you may want to connect a factory O2 sensor to the Open OBC.

I am an old analog EE and I can tell you that you can't simply connect a factory O2 sensor to the Open OBC without some serious signal conditioning in between. The factory O2 sensor is not even suitable for reading the AFR directly. It is designed to switch rapidly around the target AFR programmed in the engine computer (DME) to keep fuel trims 'tweaked' to maintain said target AFR. When the factory O2 sensors degrade, they start to switch more and more slowly and this has a negative impact on engine performance.

This unfortunately is not a good strategy for measuring AFR accurately and displaying it. Aftermarket wideband O2 sensors are designed to measure and display AFR accurately but they are not strictly compatible with the BMW engine controller (DME). Some wideband O2 sensors have a control box/signal conditioning unit that can be programmed to output a signal that mimics what the engine control computer is expecting. This type of sensor could be substituted for the factory sensor and used for Open OBC use and input to the engine ECU.

Thanks for your reply. How about using an output from a device such as this to display the AFR in real time?

[benemorius]

Thanks for your reply. How about using an output from a device such as this to display the AFR in real time?

Yes, it appears that you could use that. It has one narrow-band output for the DME and one wideband analog output which the OBC will easily read.

[Mark185]

BUMP for UPDATES!



Thanks for your reply. How about using an output from a device such as this to display the AFR in real time?

Yes that will work. I am amazed at how far the price has come down and capability has increased since wide band sensors first hit the market. I paid $700 for a very crude wide band O2 sensor 6 years ago that only had a simple analog 0-5V output and cheap LCD display.

[jdantuono]

Yes, it appears that you could use that. It has one narrow-band output for the DME and one wideband analog output which the OBC will easily read.

How long would it take and what exactly do you need to get this fabricated for the OBC?

[daandaman]

be wary that bmw has used sensors that do not output voltage but increase in resistance. The euro S50B32 engine has these. The LM1 is not able to simulate that signal to the DME!!! Find out what kind of sensor your car has first.

[jdantuono]

be wary that bmw has used sensors that do not output voltage but increase in resistance. The euro S50B32 engine has these. The LM1 is not able to simulate that signal to the DME!!! Find out what kind of sensor your car has first.

I don't need to simulate for the DME, I just want to use the OBC as an external AFR monitor display.

[daandaman]

c'mon guys, when can I get my openOBC

[jdantuono]

c'mon guys, when can I get my openOBC

Yeah! Bump!