Feeler: Open Source OBC Firmware

[dwonda]

The watchdog alert is usually a software issue though it can be ultimately caused by defective or malfunctioning hardware. In any case the software is hanging so the watchdog doesn't get serviced (fed, as we say) and the the watchdog timer expires and causes a hardware / software reset. These can be a PITA to fix.

Ya usually I only get it it if I have my stock ecu plug on in the engine bay, my other plug I removed the pins from. Still every blue moon it will come on, but it isn't a big deal, I just have to press the check button and it goes away.

[clabs]

I would like to know the fault that developed, assuming you can characterize it and it's different than the K-bus transceiver issues previously discussed on this thread. I am doing my best to make my version of the hardware more deterministic and resilient and I would like to know if there are any known faults with the OpenOBC of which I am not aware so I can address them.

Doug

My unit developed a fault where the Code, Limit and Timer button lights were illuminated all the time and I was unable to start the car because I had apparently set a code (I never have). The car started fine with the OBC unplugged. I tried reflashing the unit but it made no difference.

When I inspected the PCB I noticed a tiny burn mark on U7 DRV777 integrated motor + relay driver. I had this replaced (too small for my old eyes) and it worked fine again - until I switched my headlights on. My car is a garage queen and very seldom goes out at night, that is why I remember this minor detail. This brought back memories of how it blew the first time. Turned out I had a faulty ballast unit on one of my aftermarket Xenon headlight bulbs.

I am assuming it is the same component again though there are no burn marks on the chip this time. I have since returned the car to factory halogen bulbs but annoyingly cannot find anyone to swap the chip out for me at the moment.

Not sure if this helps at all and admit it is not terribly scientific until I get U7 changed but maybe you can see a correlation?

Cheers, Mark

[dwvcfii]

A failure of the DRV777 resulted in a short to ground or the power rail (12V) so that's what is driving both the keypad LED indicators as well as the EWS enable signals and why the vehicle won't start (because EWS is perceived as being active by the DME, i.e. it's like you have a code set).

While this is the first DRV777 failure I recall reading (though maybe I missed it...this is a LONG thread), I'm not surprised it failed given the fact that its maximum input voltage is 16V and it's quite possible that the vehicle bus voltage routinely exceeds that, however briefly, when high current or inductive loads like your headlights are switched on or off. My design limits voltage to 16V, but I'll still probably eliminate the DRV777 for more appropriate discrete FETs that are better designed to tolerate the automotive environment.

Thanks for your commentary. It's been helpful.

[clabs]

Doug - thank you for your reply and explanation.

I don't recall seeing another failure of DRV777 in this VERY long thread but given the limited voltage of that device I guess it is quite possible that my faulty headlight ballast was causing a surge on the bus.

I have bought a couple of replacement DRV777s but having looked at the board and components again, I really don't feel confident in replacing them myself in such a confined space. I will report back as soon as I do find someone to replace them. In the meantime, it does seem prudent to 'up' this aspect of your new build.

Thank you for all the hard work I know you must be putting in on this project - it is much appreciated and I look forward to seeing where it leads to.

Best, Mark

[MParallel]

Is the OpenOBC dead or people still actively develop for it?

[chikinhed]

I’m still really happy with mine. I had been using it to display fuel ethanol % and fuel temperature but the ethanol% had 0% reading ~30%. I assumed that the issue was in the coding (but I was wrong). I ended up installing a Zeitronix ECA-1 ethanol content analyses and I have the exact same inaccuracy. Zeitronix suggested that it may be a grounding issue but I haven’t had a chance to troubleshoot yet. Car is in the body shop for a couple of months. I will troubleshoot with the Zeitronix unit then and switch back to the openOBC when it’s working.

[Surfin]

Is the OpenOBC dead or people still actively develop for it?

I think it´s dead, I tried contact to buy one almost 6 months ago, still no answer and still out of stock...

[MParallel]

I think it´s dead, I tried contact to buy one almost 6 months ago, still no answer and still out of stock...

Yeah the owner of OpenLab has a long standing history about being impossible to contact.

Wonder about the guy who was doing a v2.0

[dwonda]

Yeah the owner of OpenLab has a long standing history about being impossible to contact.

Wonder about the guy who was doing a v2.0

That’s what’s I’m wondering about.

[chikinhed]

Is the parts list and the file for the board still available?

[Surfin]

Is the parts list and the file for the board still available?

Yes, here: https://openlabs.co/OSHW/openOBC-devboard

If going to make a PCB, maybe would be interesting to make some extra to reduce individual price (unless you make it yourself), probably I would get one depending on price.

[dwvcfii]

That’s what’s I’m wondering about.

I'm still here and still working on v2.0, albeit slowly as my spare time is extremely limited.

See the project page for updates.

https://www.dvatp.com/tech/dvobc_project

[dwonda]

I'm still here and still working on v2.0, albeit slowly as my spare time is extremely limited.

See the project page for updates.

https://www.dvatp.com/tech/dvobc_project

Ah okay, I didn't know there was a project page, thanks for the link. But also I probably won't remember to check on that page in the future so please post here with new developments here.

Many thanks!

[Ed Hardwood]

Can't wait! I should have ordered in 2014 when I had the chance

[dwvcfii]

I don't want to do blow-by-blow updates on this thread as it's long enough and my project is quite different from the OpenOBC, but I have made significant progress on the board in the last few weeks with more to come over the next 4-6 weeks. Head over to my project page for more details....

https://www.dvatp.com/tech/dvobc_project

[MParallel]

Cool man.

Hope yours can do the OpenOBC failed so hard in: live ecu data (think INPA) being displayed.

[dwvcfii]

Cool man.

Hope yours can do the OpenOBC failed so hard in: live ecu data (think INPA) being displayed.

IIRC, the main issue with talking with the DME is the exceedingly slow baud rate (bandwidth of the connection) and the transaction time (the time it takes between making a request and getting a response). I'm not sure this is a problem that can be solved as it is likely just a limitation of 30+ year old tech.

For what it's worth I am planning to integrate the same K-bus transceivers as on the OpenOBC so my product will have the same capabilities or limitations of the OpenOBC in this regard.

[MParallel]

On the OpenOBC the “U8” chip kept frying.

A programmer I know tried 3 times and it fried 3 times. This is the chip needed for K-line info.

L line would be sweet, but most E36 modules (luckely) talk K.

[dwvcfii]

I was aware the DRV777 drivers were frying and I know why. I do not recall hearing that the K-bus transceivers were unreliable. I'll add that to my list of design validation tasks.

[MParallel]

I was aware the DRV777 drivers were frying and I know why. I do not recall hearing that the K-bus transceivers were unreliable. I'll to my list of design validation tasks.

Appreciated.

I'd ba a happy chap with just oil temp. Everything else is a bonus. It's just a damn shame BMW didn't utilize the SMG's geardisplay (where normally the oil temp gauge is) to double up as an oil temp display. The LCD characters are right there!

Then what would be sweet to be is the SMG's module data, which is also K-bus communicated. Info like system presssure, gearbox temp, etc.

If the OpenOBC didn't have it's flaws, we'd have it all by now.

[dwvcfii]

Appreciated.

I'd ba a happy chap with just oil temp. Everything else is a bonus. It's just a damn shame BMW didn't utilize the SMG's geardisplay (where normally the oil temp gauge is) to double up as an oil temp display. The LCD characters are right there!

Then what would be sweet to be is the SMG's module data, which is also K-bus communicated. Info like system presssure, gearbox temp, etc.

If the OpenOBC didn't have it's flaws, we'd have it all by now.

Last night I was contemplating yet another compromise in this design and getting the K bus transceivers off the baseboard again. The original justification for what I called the "supplemental module" was to allow me to swap those parts easily without forcing users to buy another baseboard when the footprint for a newer / better part turned out to be different, but if the parts are downright unreliable or there is some reason why they tend to blow up due to surges on the K/L lines or during programming I'd rather be in a position to swap out an expansion module than force users to send the baseboard back for rework.

The issue now is with only three expansion slots and a GPS / Bluetooth / Accelerometer module installed, if I create another more or less mandatory module to incorporate the K-bus transceivers that will leave exactly one spare slot for a random application. In any case, I'll revisit the topic when I'm done with development on the GPS module.

[MParallel]

I would think that most people would love the K-line functionality as this allows for almost all modules to be read. Even for only the DME. I can't see the need for a GPS/BT module on the OBC.

[dwvcfii]

The primary purpose of bluetooth support is to allow OTA firmware updates. Meaning, you won't have to pull the unit out of the dash, split the case and attach a cable to update the firmware. Since the firmware will be continuously updated bluetooth support promises to make ongoing development and testing much easier, and that will lead to faster development of features and bug fixes.

The expansion card (what I'm calling GWAB for GPS/Wifi/Accelerometer/Bluetooth) will be optional, however, so if you don't want it you won't have to buy it. But lacking the GWAB module you will be required to crack open the case to update the firmware. The second reason bluetooth support makes sense here is for real-time data acquisition to a phone or tablet. If you don't have the GWAB, any data stored will have to be obtained the old fashioned way (crack the case, pull out the sd card and transfer the files manually).

I will wind up writing the code to make BT and OTA updates work as I would drive myself crazy if I had to attach a cable every time I wanted to update it in the vehicle, but I am not promising to write any software to send data to the phone. That will be for the community to do if they want it badly enough. That's not to say I won't EVENTUALLY develop that capability, but I'm not doing it on anyone's timeline but my own.

[MParallel]

Ok makes sense. What about incorporating a port on the back for updates, so you plug a cable in without splitting the case.

[dwvcfii]

I have integrated a USB C port in the design that will provide two logical ports on the attached PC -- one that connects to the console of the microcontroller and the other to the JTAG chain on the baseboard -- the latter being a way to program the board even if it is in a bare-metal (or "bricked") state.

One of the major changes I made to the OpenOBC design is that there is now an effective "firewall" between the outside world and the sensitive core electronics on the board in the form of extensive IO protection. The issue here is that the USB port is on the protected side of the board and, despite integration of ESD protection on the USB interface, allowing such a connection outside of an ESD safe environment would risk damage to the board. If you intend to be an active developer and are willing to accept the risk, more power to you, but for the average person OTA updates will be the safest and most convenient method to keep the OBC up to date in the vehicle.