Feeler: Open Source OBC Firmware

[busterhax]

Well if it would be possible read out the error memory directly from (all) modules. Not sure if that was possible at all.

From the cluster you could have all kinds of info like display revs, km/h, temp.

Well the latter is all on K line from the ecu

[chikinhed]

The current OpenOBC shows rpm, injector duty cycle, coolant temp, fuel quantity, km/h, adjustable L/100 km, 0-100 km/h triggered by accelerometer and all the regular functions.

[dwonda]

As I said earlier, the first cut will be a baseboard plus a supplemental module that will essentially provide the functionality of the OpenOBC. As far as expansion modules are concerned the survey indicated CAN Bus was a priority so that will probably be next, followed by a "data acquisition" module supporting a GPS and accelerometer. I may also try to stick a Bluetooth radio on that board as well but mechanical or RF constraints may require a separate module for each radio. Of course, nothing is cast in stone yet so if anyone has any wants/needs or general feedback, now is the time to talk.

One update is that I've gone through a few iterations of the power supply section for the board, which will now leverage a highly integrated part that provides under, over and reverse voltage protection as well as inrush and steady state current limiting with a fault output. This will ensure the board is provided power within known constraints regardless of the state of the vehicle bus. This in combination with power sequencing will ensure power is always in a known state, and that should help to eliminate possible power-up glitches that can be very hard to troubleshoot.

The bluetooth and GPS ideas are very appealing to me. Currently I have a rather clunky/messy setup with using an external GPS which connects to the Track Addict app on my phone via bluetooth, I do this because it can update at 10hz vs my phone which is 2hz I believe, giving me far better resolution on my position/path. If the OBC could accomplish what my external GPS unit does I would be thrilled. BUT I realize that probably isn't realistic, and my app probably would not support whatever GPS module that could be used anyways.

[dwvcfii]

Just a quick update. Schematics are basically done and I'm now compiling them and eliminating errors. After that's done I'll build all of the footprints and integrate 3D models for all of the parts. Then will come the task of layout. In short, I'm making slow but steady process.

I've done a lot of rework of various subsections of the system over the last few weeks as time has become available. The latest change is the use of a keypad scanning IC that not only relieves the MCU (and hence, software) of the burden to scan the keypad, debounce the switches, etc. but it also has extra IO that is being used as an IOExpander. It also consolidates IO requiring interrupts into a single interrupt signal, thus providing some relief to the limited interrupt lines available in the STM32 architecture (and most MCUs for that matter). This design change will eliminate the second DRV777 output driver IC and consolidate control of the keypad LEDs on the Code, Limit, and Timer buttons so this IC is now a "one stop shop" for the OE keypad interface. The device talks I2C so that should make it relatively easy to access and simplify driver work.

As far as GPS is concerned, assuming I am involved in the GPS module design I will plan to support an external antenna to be mounted somewhere under the dash but in a clear view of the sky. This will be required as the position of an integrated GPS module patch antenna would be suboptimal when installed in the OBC. As far as position update rate is concerned, that will be a function of the specific GPS module selected. All of the units I have investigated (however briefly) support 10Hz updates. Capturing that data and sending it over BT is simple in principle but the challenge will be developing protocol / data formats to support more than just GPS data over the BT interface. I will not be developing those formats or writing code to implement them. At least for now that work will need to be done by the community.

[Ed Hardwood]

Can't wait! Been wanting one for years now!

[MParallel]

Good to know it’s still in progress.

[dwvcfii]

Yea, I'm still working on it. It's a bigger project than originally expected, but I think the end result will be more robust and reliable than the OpenOBC and the factory OBC as I'm attempting to build it to current standards that govern automotive electronics.

I just started layout of the baseboard. After I position all the components and before I start routing I have to design and build the SM so I can ensure that they'll fit from a mechanical perspective. Once that's done I may also design one or two of the expansion modules I think most people will want to ensure that the electrical interface to the expansion modules works as expected. Then I'll send the boards out for manufacturing.

I haven't had a lot of time to work on the project over the last few months but I have more free time than usual in July so I should be able to dedicate more time to the project over the next few weeks.

Some big changes made since I last spoke:

1) The MCU package has been changed from an LQFP (30mm square) to a BGA (13mm square) due to board constraints. I hate using BGAs for prototyping and small runs, mostly because it increases the cost and complexity of the board design and assembly processes, but that's the way the cookie crumbles.
2) The barrel jack has been replaced with a microfit Molex connector, again due to board constraints.
3) The 5V rail has been removed from the board to reduce complexity and cost. 5V was only used on the OpenOBC to supply USB VBUS and that is outside the scope of the project as previously disclosed. 12V and 3.3V will continue to be provided to the expansion modules so if module developers need to create a 5V rail (or any other voltage) they can generate it from either of those voltages.
4) I've migrated the USB Micro B jack used for debugging to a USB type C. Of course the MCU doesn't support USB 3.0, but rather connects to the jack in the compatibility mode as defined in the USB standard. I did this mostly because type C jacks are bidirectional and are designed to have a significantly longer lifespan than the Micro B.

Again, if anyone has any requests, comments, or questions about the design, now is the time to ask as nothing is yet cast in stone.

[Brian1960]

Pie in the sky of course but I always wish the lcd could be upgraded and still plug in to the original radio.
Better graphics powered by your gizmo for the new navigation integration and album cover art etc as a bonus.
Bypass/replace the original video module if possible.
SD card for better audio quality.
Atsc tv tuner integration.

[ZiMMie]

Lol album art in tiny display. Hahahaba..

I say keep any audio components out of it.

Sent from my Redmi Note 5 using Tapatalk

[MParallel]

ibus support. Not all BMW radio's support ID3/CD text over ibus, others do. It would be nice if the unit would accept ibus messages and display song names/phone numbers (from carphone) on the OBC.

Like so:

[Brian1960]

Lol album art in tiny display. Hahahaba..

I say keep any audio components out of it.

Sent from my Redmi Note 5 using Tapatalk

Actually I bought a "cheap" Chinese Joying unit for my 2001 325i and it actually looked quite cool to have the animated album art displaying on the monitor as you listened and drove.

Had it for over 3 years now and not one problem with it.

Just how big does the display have to be to enjoy it?

[dwvcfii]

As I've previously stated a few pages back...

1) ibus support is outside of the scope of the work I plan to do on the project, mostly because I don't have the means to test it.
2) ibus support could be added to the system via an expansion module, however I will not be the guy to build it or write the associated software for it.
3) As for replacement of the LCD, that is planned through a subsequent module that will be attached to the board I'm building now. That will of course require a new custom enclosure that will fit into the existing space in the dashboard for the OBC. I will not be building a new LCD / driver board to fit in the factory OBC enclosure as I see absolutely no practical benefit to doing so, particularly because a custom LCD designed to fit in place of the existing single line character display in such low quantity would be cost prohibitive.

[Brian1960]

Actually I bought a "cheap" Chinese Joying unit for my 2001 325i and it actually looked quite cool to have the animated album art displaying on the monitor as you listened and drove.

Had it for over 3 years now and not one problem with it.

Just how big does the display have to be to enjoy it?

(EDIT) It has become painfully obvious that I have been out to lunch on what this project is, and is not for.

When I saw a new lcd mentioned earler in this thread it sparked my interest and I got it mixed up with something I saw on older youtube videos.

Something along the lines of this https://www.youtube.com/watch?v=3XwGw7J4MzI or something similar.

I will sheephishly bow out of this thread now .

[dwvcfii]

The new LCD project (or sub-project) will involve a new color TFT touchscreen designed strictly for diagnostics or anything else we might display via the OBC wrapped in a new enclosure. The ultimate goal will be a total replacement of the factory OBC without any dependency on its aging and impossible-to-source components. This project has never been, and will never be, a replacement for an audio headunit like that depicted in the video. Not sure how you ever got that idea.

[MParallel]

I take it that was directed at me. I never asked this in the first place. It only shows an iBus text being displayed on a CD43 headunit.

I'd like the OpenOBC to be able to display ibus text. Not replace a headunit.

[dwvcfii]

I generally don't quote if I'm replying to the post directly above, and that was the case here. My most recent post prior to this was responding to Brian1960.

MParallel -- your feature request for ibus support will be supportABLE, though not directly supportED by the initial baseboard design. ibus support could be added through a custom module as I have previously indicated.

Frankly, I'd add a third k-bus transceiver to the SM but I'm limited on UARTs, am already routing two UARTs to the SM for the two k-bus transceivers to deal with the K and L lines, and adding another UART, while possible, would involve yet more hardware sitting on a SPI bus instead, and that adds complexity and design risk.

Of course, given my choice to make the SM a separate module, should it be later determined that the L line does not need its own transceiver and will work with an ISO9141 transceiver that integrates L line support, I can just re-spin the SM to repurpose one of the UARTs and transceivers for ibus support and provided the needed board-to-cable connectors to route the signals to the radio.

[Brian1960]

http://projects.tevs.eu/OpenBM/

I believe the above is actually what I was confusing this with.

[Surfin]

Any idea on when the openPCB should be available again?

[dwvcfii]

Any idea on when the openPCB should be available again?

If you're referring to the OpenOBC project, the answer is never. That project is dead because the original developer(s) no longer respond to inquiries and several components on the board are no longer available.

My project, which shares the primary goal of the OpenOBC project (replacement of the 18 button factory OBC logic board) is still early in development. I am not making any promises with regard to availability. In fact, as I have indicated previously, all I've agreed to do is fund the development of a prototype. Once I have a working prototype I'll consider doing a production run based on demand.

[dwvcfii]

I've finished preliminary component positioning of the baseboard, mostly for validating the mechanical aspects of the design and it looks like this:

dvobc_2019_08_3d_prelim_pos_complete.png

The supplemental module and LCD daughtercard electrical and mechanical designs are next.

As my project is now officially deviating from the OpenOBC project I've decided to create a project page on my own website and plan to keep that up to date from now on. Please follow the project here:

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

I will of course continue to respond on this site to PMs about my project but for the fastest response please contact me via my website. See the project page for my contact information.

[clabs]

Doug

I was one of the first adopters of the Open OBC but mine has sadly developed a fault.

Thanks for picking this up again and definitely interested in a new and updated version.

Thanks also for all your hard work.

Best from the UK.

Mark

[dwonda]

Looking forward to seeing the prototype!

[dwvcfii]

Doug

I was one of the first adopters of the Open OBC but mine has sadly developed a fault.

Thanks for picking this up again and definitely interested in a new and updated version.

Thanks also for all your hard work.

Best from the UK.

Mark

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.

[dwonda]

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.

So far the only error I have got on mine is an occasional "watchdog alert".

[dwvcfii]

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.