E36 BMW OBC Project
Inspired by the OpenOBC Project I've decided to fund an
project to replace the main logic board in the 18 button OBC
provided as an option on E36 BMW automobiles built from
The DVOBC project picks up where the OpenOBC project left off, and aims to provide a replacement for the main logic board in the factory 18 button OBC of E36 BMWs (1992-1999).
Provide functionality equivalent to the factory 18 button OBC logic board.
Create a modular architecture that allows the design to be flexible and expandable over time to support everything from diagnostics to data acquisition.
A fully assembled logic board option to satisfy a niche market need for this board to replace the factory 18 button OBC logic board.
Availablility: This product variant will be produced if a sufficient number of pre-orders occur.
A turn-key product that will utilize the same logic board as in the first variant, mated to a daughtercard unique to this variant that will host a sunlight readable, high resolution color TFT display with capacitive touchscreen interface, all housed in a custom case that will replace the factory OBC in its entirety.
Availability: This product variant is not currently slated for production but may be approved at a later date based on a variety of factors, including the success of the assembled logic board variant.
The processing core of the unit will consist of a high performance microcontroller incorporating 2MB of flash and 512K of SRAM. In addition, 1MB of external SRAM will be provided that can be used for either program memory or as a LCD frame buffer when deployed in conjunction with the turn-key product variant.
The board receives power from the vehicle harness and then passes that through an AEC compliant power supply fault detection and protection circuit which prevents under and over voltage, negative voltage and over-current conditions. All faults other than over-current are automatically reset. Over-current faults will be latched and require the unit be power-cycled. The over-current limit is set well below the harness branch circuit fuse rating so a current fault on the unit will not blow the vehicle's fuse.
The backup power bus will be implemented on the baseboard and the output provided to both the microcontroller for the purpose of maintaining the real time clock and nvram subsystems, as well as the expansion modules (EM) for future use by devices that require storage of non-volatile data. For example, GPS modules can leverage the backup power supply to store ephemeris data to reduce lock up time. The backup power bus will be provided by super capacitors. While the capacitors are initially more costly and have both a finite capacity and lifetime, they perform much more consistently than traditional batteries in wide temperature variations typical of the automotive environment.
The board will integrate 3 expansion modules (EM), each supporting third party hardware and software development. Each module will support a standard interface including power (3.3V regulated and fault protected 12V), SPI, and I2C functionality, as well as optional interfaces that are specific to each module position such as UARTs and USB OTG. Expansion modules may be leveraged to implement capabilities such as GPS data logging, Bluetooth connectivity, and specialized features such as Ethanol sensors or iBus support.
The X1070 and X1071 harness connections will leverage new connectors so the original connectors from the factory OBC board will not be required. A small modification will be made to one of the connectors to fit the keying of the harness connectors as the original connector is not available for sale in the aftermarket. Installation of the logic board option will only require desoldering of the OE keypad and display ribbon cables. Connections to the vehicle harness will be plug-and-play.
The hardware design will remain proprietary to prevent unauthorized duplication, at least until I achieve a return on my considerable investment in the project. However, specifications and documentation will be provided to registered developers as required to facilitate expansion module hardware development and related software development.
Access to a software load supporting the assembled logic board product variant will be provided via an open source model, but support for this software will be limited to registered developers.
More information about the developer program will be released when appropriate.
Will your project provide backward compatibility with the OpenOBC project board? In other words, if I have already wired up stuff to the OpenOBC, will I be able to simply swap the OpenOBC board with your board?
Simple answer: No. My design is completely different. However, I see my project not only meeting the original design goal of the OpenOBC project, which was to replace the functionality of the factory OBC logic board, but also providing additional functionality through the expansion module interfaces, so it's likely that whatever functionality you are utilizing could be provided via an expansion module.
Why did you not simply take the OpenOBC gerbers and produce PCBs from that existing design?
Several components were no longer available, and replacements were not pin-compatible, hence the PCB footprints had to change. That dictated a re-spin of the PCB.
Why did you not simply copy the basic design of the OpenOBC and generate a new board with new footprints for the obsoleted components?
First, my technical analysis of the OpenOBC project revealed several deviations from what I consider acceptable design practices so my design aims to correct these deviations. Second, I needed to improve the modularity and functionality of the board to expand the target market for the design as required to improve my return on investment, not only in terms of monetary value but the technology I develop for this board that I can leverage in future designs, thus reducing development costs on those projects. Finally, I did not want to imply any compatibility with or support for the OpenOBC boards that may be in the field.
Do you plan to sell bare PCBs that can be assembled by the end user?
No, primarily because the complexity of the design and the space constraints dictated by the dimensions of the original factory OBC logic board have required the use of some package types that are challenging to reliably assemble.
This option would also necessitate revealing the bill of materials and put my IP at risk.
Why are you producing the LCD option?
While market research has clearly indicated a demand for the assembled logic board variant, I believe the market for a turn-key solution is far larger and so the overall success of the product is more dependent on that option. As a result, I expect to develop a prototype that demonstrates the basic functionality of both variants before the logic board option is manufactured to ensure the same logic board can be used for both variants.
How can I buy or reserve one?
Once the prototype is complete my intention is to announce a preorder program for the boards that will remain open for a limited period of time, similar in concept to a Kickstarter campaign. If I obtain sufficient sales within that timeframe I will proceed with manufacturing and notify you of an estimated shipping date. If insufficient orders are realized I will abandon manufacturing efforts and refund the purchase price.
Project Status: ACTIVE
March 26, 2020
The last few weeks have seen significant progress on the project to the point that the baseboard placement is largely complete. Of course I reached a similar milestone some time ago and wound up ripping up significant portions of the schematics, but unless the requirements change significantly I expect this to closely resemble the final product -- to the point that I updated the picture at the top of the article.
Some of the significant changes:
- As you can see from the picture the SM slot is gone yet the board maintains three expansion slots. The location of these slots now conveniently aligns with a relief built into the factory OBC case rear cover so expansion cards should have considerable flexibility with respect to component height. You may also note that all jacks, the boot mode and power switches, and status LEDs are now usable / visible with all expansion modules populated. The MicroSD card slot has been moved from the SM to the baseboard and placed in the only available location on the top of the board that provides access to the side of the slot and thus the ability to swap cards without pulling the baseboard from the factory enclosure. These changes should make development on the board a lot easier.
- The original plan to migrate the supercapacitor-based backup power supply from the SM to the baseboard had to be scrapped due to a lack of space for a supercap of sufficient size. I tried to integrate smaller caps to save the earlier design choice but I quickly concluded the lower runtime would not justify the cost and complexity of the feature. This means the system will not have any backup power in the event the 12V input from the harness is disconnected but recall that the board will obtain its power from the HOT bus (which is on continuously, even when the vehicle is parked and the ignition is off) so this is less of a concern. The loss of the backup power supply was further mitigated by my discovery of a GPS module that stores ephemeris data in local nonvolatile memory automatically. In short, the design no longer requires a backup power supply, but that won't stop individual modules from incorporating their own smaller supplies if desired.
- In order to implement the turn-key product variant I originally planned to attach a LCD daughtercard to the baseboard with a common board-to-board connector over which I was free to define the interface. Although I knew the STM32F4 microcontroller supported a relatively new high speed LVDS-based serial display standard called DSI, I decided to use a common RGB parallel interface due to familiarity. Due to a recent need to leverage additional peripherals in the device and IO conflicts with the exceptional number of IOs required to support RGB I have decided to switch the interface to DSI. This limits the number of off-the-shelf displays I can use but there are several upsides. First, the connector size is significantly smaller and less expensive. Second, this frees a lot of GPIO I can use to eliminate the need for IO expanders, which while simple in concept do require more software development to leverage. Third, DSI can be turned back into RGB on the daughtercard using either off-the-shelf ICs or an FPGA and some freely available IP so this in no way boxes me into a corner should I ultimately decide to produce the turn-key variant.
- I integrated a small FPGA, the Lattice MachXO2, as required to implement a programmable reset controller. This device will take input from either the MCU or a physical button and reset all devices in a deterministic order and timeframe. This will minimize surge currents during reset operations which can cause glitches when devices drop below their undervoltage protection thresholds and produce noise detectable during EMC testing. This device may also serve an important role in controlling the boot mode pins and reset of the MCU during an OTA firmware update but research on the subject is not yet complete.
- The SRAM TSOP package has been replaced with a much smaller BGA package with a ball pitch roughly the same as the MCU. This increases component area and routing possibilities on the top layer and will not significantly impact the assembly validation process. I had planned to x-ray the MCU to ensure proper assembly so I'll just include the SRAM in this process.
Research has started on an optional GPS/Wifi/Accelerometer/Bluetooth (GWAB) module. Once that is complete the LCD daughtercard will be developed. I'll post another update once the GWAB module is complete.
March 8, 2020
After a lot of hair pulling, insurmountable mechanical issues have forced me to eliminate what I called the supplemental module (SM) and transfer its components to the baseboard. The problem is that I'm working with existing design constraints and have little flexibility if the baseboard is to fit into the existing case. Despite my best efforts, I was unable to put ten pounds of sand into a five pound bag.
The original justification for the SM was to make it easier to test, repair and replace certain components I deemed at high risk for failure in the vehicle. However, at the end of the day I was inclined to accept these consequences rather than restrict the user's ability to expand the system.
Elimination of one of the slots will give me a bit of breathing room, which I expect to use by centering the three expansion slots on the card and leveraging the newly-found space for the supercapacitor-based backup power supply and K-bus transceivers which will necessarily find a new home on the baseboard. The boot mode, run and power switches, as well as the 12V and USB jacks will also have to move. This in turn will cause the relocation of several other components. In other words, I have my work cut out for me.
I'll provide an update once placement of the new design is complete.
February 19, 2020
Schematics and preliminary placement of the baseboard and SM are complete, though the initial mating of the two boards in 3D has revealed some mechanical issues that need to be addressed though a substitution of components.
Research and testing revealed that the OpenOBC I/O interfaces were woefully inadequate for the automotive environment, and significant research has been put into the development of more robust and fault tolerant interfaces. While this has resulted in more complexity, a higher part count and some increase in BOM cost, I'm sure you'll agree that a slightly more expensive unit that works reliably is better than a cheaper one that fails when the bus voltage spikes due to those fancy HID ballasts you installed.
I have concluded that it will be necessary to add an OTA (over the air) firmware update capability through a bluetooth module connected to the primary microcontroller (MCU) through some logic, which may itself be implemented by a smaller MCU located on the expansion module (EM). This will allow the flash memory of the primary MCU to be programmed via bluetooth as compared to the more traditional wired methods which will necessitate removal of the unit from the dashboard for every update. Traditional wired programming methods will of course remain supported, as the bluetooth module will be sold separately.
The OTA capability will naturally require the development of an EM containing a bluetooth module before I wrap up the prototype design work by completing the LCD daughtercard. Space permitting I will likely add a GPS module and accelerometer to this EM as well. This will round out the basic featureset of the platform and finalize the EM mechanical and electrical interface standard that will be distributed to third party developers.
Questions / Comments
If you have any technical questions or comments about this project please contact me. However, please do not bother asking about the project status or when the prototype will be complete as this information will be posted above when appropriate.