will eventually be swapping to a standalone ecu for my supercharger install, and was wondering if I can code the openobc to read the data output from the ecu rs232 port. would seem a waste to not use it to its potential
its an Autronic sm4
below link has information on the data protocol. ill not pretend to have any experience interpreting such data, but assuming its possible, ill work on learning
http://www.ciscokids.com.au/technica...a%20Stream.pdf
Looks good.. is there a GitHub for the development of the project?
Sent from my Redmi Note 5 using Tapatalk
#E36-S54 #CSLWannabe
https://github.com/benemorius/openOBC-devboard.git
There are inputs on the current board but Im not sure if anyone has used them for RS232 yet.
Last edited by chikinhed; 02-28-2019 at 09:27 AM.
Can't wait to see the results. I regret not buying one when I had the option a few years ago.
Definitely interested in this
This sounds great.
Since Wifi/Bluetooth and SD Card support look to be in the mix, is there enough processing hp to do what's planned and also output tunes to the OEM Business CD and scroll MP3 tags?
Bonus points if it has full Bluetooth support for music and telephony.
If it has to be a mode and give up some other features running concurrently, that might be ok too.
The debate over the appropriate combination of features should be epic.
I mean, I'll probably pay $250 for a copy when it gets flushed out, but I would DEFINITELY get one if it could do this.
I'd wager there are as many or more folks that would pay this for a highly featured bluethooth/phone adapter as a tuning/track diagnostic tool.
Call me silly, but I'd really like both and an OEM dash. :-)
Just my $0.02...
Casey
The main reason I'm making the design modular is to allow users to pick the features they want and hence avoid the"debate over the appropriate combination of features". One size fits all products rarely make everyone happy, and I have neither the time nor the inclination to design one so I'm just not going there.
Mostly because I have no means of testing it (my E36 lacks a business CD) I have no plans to integrate iBus support on either the baseboard or what I'm calling the supplemental module (SM) that will integrate the K-line / L-Line transceivers and MicroSD card, though I have routed an extra UART to one of the expansion slots that could eventually be used by others to implement that feature via an expansion module equipped with another Kbus transceiver.
I also want to set expectations if I haven't already -- I have no plans for an extensive software development effort as would be required to implement the connectivity features you're requesting. Right now the only thing I'm planning to do vis a vis software is port as much of the OpenOBC software as possible to the new platform and implement a real time scheduler to eliminate the super-loop. The hardware will also be proprietary until such time as I have achieved my target ROI, assuming that happens at all, but the expansion module electrical interfaces will be sufficiently documented to permit third party hardware and software development.
Nice to see this is still alive. My board is still waiting export analysis, but the expert is so busy it's been well over a year.
I think this one will be finished before he even has time to start on it.
Anyways, I told an a friend of mine about this 'v2.0' project. He's also very good with electronics and has done some cool programming for the OpenOBC board (tire pressure display).
He advises to use NRF52 instead of the STM32, as the NFR52 has Bluetooth built in.
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/
STM32 is far more popular than the NFR52 and so there's a lot more working software out there. Sure, most of it is shitty C based on ST's horrible libraries and code generator, but since it works it can be used as a model for a proper software development effort. And based on my long experience, copying working code is a hell of a lot easier than figuring out how to diddle the bits yourself.
I also think that BT amounts to scope creep, at least for the baseboard. I want the baseboard to provide the functions of the OE logic board and serve as little more than a breakout board, while specialty features like BT are provided on an expansion module. The perk of doing BT on the expansion module is that it gets the antenna off the baseboard and that in turn simplifies layout on that board.
Makes sense.
All I need personally, is being able to read out all DME/SMG info. If only oil temp and pressure, I’m good.
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/
I recall reading several years back in the thread that DME access was painfully slow. Not sure why or if they ever resolved that issue. However, as I plan to use the same Kbus transceivers and port the existing software over to the new platform I expect the results (good or bad) will be consistent with the OpenOBC project.
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 current OpenOBC will receive 0-3v inputs. It would be nice if the new one would receive 0-5v inputs directly to simplify connecting various sensors.
Make it K + L line, so we can possibly display info/data of all modules.
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/
L line wont be needed.
For interfacing with the vehicle harness the baseboard will handle level shifting and input protection. Level shifting on expansion modules as required to implement parts requiring 5V IO will be the responsibility of the expansion module designer. In other words, only 3.3V IO will cross the module connectors to the baseboard.
On the subject of expansion modules, I'm providing the vehicle's 12V harness power (constrained via the power controller but otherwise unregulated) as well as precisely regulated 5V and 3.3V to each expansion module so devices requiring those voltages will not require additional regulation. If, however, a module is designed with an FPGA or something like that and, for example, the core requires 1.2V then the module will be responsible for generating 1.2V from an appropriate voltage (most likely 3.3V, but it could just as easily be 5V). Modules will also be responsible for ensuring their power requirements do not exceed the limits specified for the module interface.
I've read this thread multiple times and still haven't figured out if there was consensus reached on this subject. So my design will route two UARTs to the supplemental module (SM) for use by two independent Kbus transceivers similar to the OpenOBC design.
There are ISO9141 transceivers that support K and L line in the same package, but I can't tell if BMW's implementation of the L line is compatible with these transceivers, which explains why I decided to punt and go with the two Kbus transceivers to support K and L. This is also one of the reasons I decided to move the Kbus transceivers onto the SM. That way if things change I only have to respin the SM and not the considerably more expensive baseboard.
All engine parameters are on K line and plenty fast for a live display. The instrument cluster is the only module not on the K line. L would be a huge waste of time.
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/
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/
Bookmarks