If I'm going to re-implement someone else's design, you're getting the software tweaked only as needed to work with whatever design changes were necessary to get that product out the door. The margins on that product (which is strictly marketed toward the cheap DIYer) will be too little for me to justify dedication of my company's resources to a software development effort. Hence my point about the software being tweaked only as needed and then open-sourced for the community to maintain.
Whether the product achieves liftoff or not will be baked in the cake -- as I won't go into production unless X number of people commit to buying the thing. As for fitment, etc. if I do decide to offer option #2 the prototype will be all you'll need to see to address any concerns.
Sounds good, I would have to actually install it in a car to truly be relieved of any concerns but I'll take your word for it. I'd also say that you ultimately define what the margins are per unit, past that I think it's largely unknown. With option 2 it sounds like there will need to be some software work done, either as a UI or something else to program it with. The pricing does interest me, the E36 group is pretty mixed, like someone else mentioned earlier it seems like you've got the real cheap owners, then you have the ones with money to blow, some of those are strictly going for an OEM look and some don't care. Would be great if you could bridge the gap between the two.
What I like most about the openOBC is the OEM look. Anything not stock looking would be a no-go for me.
In my opinion benemorius did a great job with the design of the openOBC but the major problem is the software. If someone would come up with an improved code which finally makes use of the hardware and all the possible features I would be more than happy and definetly willing to pay for it...
Ideally the faceplate of the custom case would look quite similar to the existing unit and I would cut class (i.e. make a custom LCD) sized to maximize coverage so that the border around the glass was about the same as it is now on the top of the existing display. In other words it would look as OE as possible. However, custom LCDs only make sense in high volume applications as the NRE is quite expensive. The best I could do would be a high aspect ratio display that would likely fill most of the faceplate area. Any open area could be used for buttons or data jacks.
The perk of using a color display would be that it could utilize color to attract attention where necessary, i.e. oil pressure warnings would be in red, but during normal operation the entire interface could be displayed in BMW orange.
Last edited by dwvcfii; 10-12-2018 at 09:53 AM.
Option #2 cannot by its very definition have the OE look (i.e. it will not have physical buttons) but I can say that the bezel that surrounds the LCD would use design cues from the existing unit and the display would have a matte finish to match the other displays in the vehicle. Then software could be written to mimic the existing LCD font text, etc. to give it an OE-like appearance to satisfy the OE purists (like me). The options are nearly limitless with a display.
I can say I'm honestly interested.
Can I ask what the state of the project is in?
I'd also be interested. I just have one request. Can a terminated canbus transceiver be added in to the CAN Input.
Sent from my Redmi Note 5 using Tapatalk
#E36-S54 #CSLWannabe
What do you need CAN bus for?
I have an s54 motor. I'd like to view certain motor information which are available thru canbus. Digital oil/coolant temp, ignition angles, vanos information etc.
Sent from my Redmi Note 5 using Tapatalk
#E36-S54 #CSLWannabe
Ah, okay. Yes. CANbus is easily done via an external transceiver or by swapping the existing microcontroller for one of the variants that has CANbus built in.
I have to find the time to walk through the thread again to look at some of the outlier features that were requested previously, but if anyone is willing to highlight any other features above and beyond the OE unit that you'd like to see that will certainly factor into the re-spin design effort.
The microcontroller support It (forgot what pins I'm on mobile). There is also a library for it. It will need just a transceiver and termination. (120ohms).
Sent from my Redmi Note 5 using Tapatalk
Last edited by ZiMMie; 10-13-2018 at 03:20 PM.
#E36-S54 #CSLWannabe
Odd that the original developer didn't appear to implement any termination, but this was for an E36 and CAN bus was probably brought out of the device just because it was there. In any case, termination is only needed at the far ends of the bus. Not sure where this device fits in the context of an E36/S54's CAN bus but selectable termination is probably the best solution. I'll look into adding that.
Edit: Looking at it more closely I realized he just broke out the IOs to the on-board CAN peripheral and did not provide a transceiver, so that will have to be added too. No big deal.
Last edited by dwvcfii; 10-15-2018 at 06:16 PM.
Let me know what information you will need.
Sent from my Redmi Note 5 using Tapatalk
#E36-S54 #CSLWannabe
I decided that a survey would be a lot more efficient way to collect the data I need to proceed with a prototype vs a bunch of responses here. Please visit this url and fill out the survey:
https://aileronlabs.typeform.com/to/bTAe0r
The sooner you respond and share this with others to get their feedback, the sooner we'll be out of limbo and have a plan to move forward (or not, as the case may be).
Thanks for your feedback.
Just wanted to let you know that the survey is running and collecting data.
So far the responses seem to favor the bare logic board option. I'm also a bit surprised at the feature requests which favor some features like GPS and CANBus, neither of which were implemented in the OpenOBC, and this leads me to believe the market is really looking for an updated and improved version of the OpenOBC, not a mere copy.
Please keep spreading the word about the survey. The more people that respond the more likely I am to proceed with the effort.
Agreed. 2 sounds nice, but too modern. The single line can still display plenty of characters or even scroll. I prefer OEM looks. As long as it can display any data directly from the DME, I’m happy chap. Hell, just oil temp/pressure displayed and I’m cool. It’s just that darn chip that fries.
Oh and being able to display SMG data would be super nice, like hydraulic pressure, gearbox speed/temp sensor, etc.
1998 BMW M3 3.2 Cabrio Alpinweiί III on Schwarz German spec 1 of 12
SMG SRA PDC AUC OBC GSM HK UURS IHKA FGR MFL
IG: https://www.instagram.com/iflok/
So far the survey results seem to agree with you.
That said, I can't help but think we'd all be a lot better off with option 2, as it would make it possible to present a lot more data a lot more usefully and, of course, allow me to build a product that isn't based on a diminishing supply of beat up cores with worn out buttons and scratched displays, or new units costing $750 that no one in their right mind would buy only to hack up to install a custom logic board. I think the LCD unit would open the market to people who are just regular E36 owners who want to modernize their vehicle. It's still a small market overall, but at least it's sustainable. And for those that don't care about how sustainable this is for the developer, consider for a moment why you can't buy the boards or even get in contact with the developer anymore.
It's been almost two weeks since I posted the survey and the submissions appear to have trickled to a stop so I figured I'd report the results.
15 people submitted the survey. A majority of those surveyed want the bare logic board option. Based on the feature priority it's also pretty clear that the S54 transplant and HPDE guys are probably driving most of the demand, and that demand is focused around supporting CAN bus and other OBD features, and control or access to various external devices (fans, pumps, or even flex fuel sensors). About two thirds of those surveyed want stuff like GPS and about half want the accelerometer, presumably for data logging on the street and the track.
The average maximum price people were willing to pay for the bare logic board option was $230. That is within the realm of reason to cover basic hardware costs and the adaptation of the OpenOBC firmware, though I think $250 + shipping is likely to be the final price in quantities less than 100.
Some people were willing to pay as high as $700 for the touchscreen product and with full software development costs that would not be out of the realm of reason but unfortunately the average was only $400 which is probably enough to cover only basic hardware costs and some preliminary software development. I am still a proponent of this product but the demand for it at present is low. I'm sure I could turn a few heads with what I have envisioned for this version of the product and that would increase demand substantially, but right now, without any prototype to wow people, there is little demand for the LCD version.
Based on these results I can justify further investigation into a new version of the bare logic board in the form of a design audit. I will not, however, commit to anything more than that at this time. If there is anything specific that you would like to see in the new design that was not mentioned on the survey, now is the time to propose it.
Thankfully, full touch display, just doesn’t suit the E36 interior.
Most important would be able to display all types of Bus data m/i/p and RxD/TxD data.
ps I missed out on the servey.
Last edited by MParallel; 10-27-2018 at 02:33 PM.
1998 BMW M3 3.2 Cabrio Alpinweiί III on Schwarz German spec 1 of 12
SMG SRA PDC AUC OBC GSM HK UURS IHKA FGR MFL
IG: https://www.instagram.com/iflok/
Sounds good, I'd buy it...
2002 530IS 5 speed, Sapphire Black/Sand, M-Tech sport package, premium package, ESS Twin Screw supercharger, Southbend high performance clutch, Performance Gearing 3.15 LSD.....1999 M3 Cosmos Black/Black, Active Autowerks intercooled supercharger, H&R suspension and a bunch of other stuff....
Well guys, the good news is I have decided to proceed with construction of a prototype of a product to replace the OpenOBC. The overall design concept and project strategy have been developed, the schematics are almost complete and I've thrown together a preliminary mechanical design (see attached).
I've introduced many changes out of necessity, economics, good engineering practices, and of course, convenience and personal preferences. The most obvious change as you can see is the move to a modular architecture consisting of a baseboard identical in size to the OpenOBC board coupled with mezzanine modules that are a kind of hybrid between two standards -- the physical form factor is based loosely on the MiniPCIe standard, mostly to leverage the plentiful supply of inexpensive card edge connectors, and the electrical interface is loosely based on the MikroBus standard.
Three of the mezzanine slots are intended to have nearly identical electrical interfaces, consistent with the available MCU peripherals. One of the slots will be unique and serve as an extension of the baseboard. I intend to put the Kbus and possibly the CANBus transceivers on this module for a couple reasons:
- They are the most likely component to be damaged (as a few have discovered with the OpenOBC) and so placing them on a module will make it easier to replace them without any soldering.
- I'm not convinced that the existing parts are the best parts for the job, thus I'd like the option of replacing them as I gain some personal experience with the Kbus. We appear to be lucky in that the transceiver used on the OpenOBC is still available as a RoHS part (the non-RoHS parts were discontinued) but I'm not sure they will be available forever, and by keeping them on the module we'll be able to replace them without re-spinning the baseboard.
I've made other changes including a new MCU based on the STM32 platform (another ARM part), a redesigned power section, and a dual port USB transceiver that will serve as both a JTAG/SWD programming interface as well as the console for the part. This last feature will eliminate the need to buy a separate programmer and associated adapter cables as required for development and updates -- saving approximately $50.
As the design is not yet cast in stone, if you have any questions or feedback I'd like to hear it.
Bookmarks