[cupertinosteve]

I really like the "possible" model going forward.

I do not think there should be any "filtering" of capabilities to protect anyone.

If we take the Linux analogy - you got Centos, RedHat, Oracle and others offering support and tools for the same branch of code.

If you want source code level access for whatever reason, get Centos.

If you need help, consider the pay-for options that other companies would offer - their value add is their expertise, tools and other investments on top of the source code.

Individuals then can decide their path.

[pinky_and_me]

Great work! I've been researching what I need to do to get WinOLS running and now I don't have to do that

Did I understand correctly that ROM was protected with encryption and there might have been some hacking to get the keys? If so, would that suggest that BMW proprietary code was reverse-engineered and in turn prevent this from being publicly available?

[klipseracer]

Originally Posted by RombinHood2

We have yet to decide on a hardware platform. There are a few to chose from each with their own strengths and cons. Given that we have the ability to start fresh, I'm of the mind to do something really nice with the hardware. I'm investigating a few options right now.

The GUI will be supported by someone who is good at that. Definitely not me. Possibly a tuner since only a tuner would be able to provide the necessary support and spearhead the necessary updates.

So this is where the 'fork' would be in the code in terms of managing the flashing software. You say, 'open source' but would there be even a basic ability to flash the dme available publicly such as github or something like that? I just don't want to see a great project become crippled by proprietary software so early in the stage, with little or nothing to continue the original opensource idea from.

Don't get me wrong, I think it would be great if vishnu or any other tuner took over some of the graphical tuning stuff as its most relevant to them, but I'd also like to see at least a truly open source side of all of that.

[themyst]

Originally Posted by shiv@vishnu

The advantage of open source tuning isn't only the ability to get access to more maps/tables but also to have a much lower cost of entry for those who just want to by a tool for flashing to use off-the-shelf map. For example, when open source was introduced to the Mitsu/Suby world, the cost to flash your car dropped to $150. Before that, you had to pay $750 for a Ecutek or Cobb flash. Needless to say, in the Mitsu/Suby world, just about everyone replaced their Ecutek/Cobb devices with open source hardware. This is what is appealing about open source tuning for the vast majority of people. For the small minority of tune-saavy tuners, the ability to identify new tables, define new functions, etc,. is what is exciting.

Shiv

We're on the same page. I can't wait for the the alpha/beta software to come out. Looks like it will still be a while away though to have the tables available in ATP/ATR.

Question for the OP, is there a way to datalog what addresses in the DME are being read at a reasonable resolution?

[shonuff]

Originally Posted by RombinHood2

Some Open Source updates:
-K-line support is now available for all early build MSD80 equipped cars!
-Recovery mode in case of loss comms during flash process is also functional
-Initial full DME read takes 55 minutes (on either K-line or CAN supported DMEs)
-Full writes take 11 minutes (on either K-line or CAN supported DMEs)

I cant wait to see the source for this... !!! Great news for the community. Thanks for taking this initiative.

[Constant.S]

Oh wow, this is great news! Hope this project stays alive!!!!

[Tiago@VRSF]

Very interested. Looks like good progress so far.

[Rombinhood@OpenFlash]

Good news my friends! With some assistance from Shiv@vishnu and Dave W., I have accumulated what appears to be a comprehensive list of definitions for the IJE0S DME software. This means addresses, conversions and axis data. I still have to work out the definitions for the other software versions but that shouldn't take very long now that we are at this point. Here is what we have so far for the IJEOS:

Timing failsafe
Timing main
Timing open loop
Timing spool
Timing IAT correction factor
Timing total correction
Knock filter 1
Knock filter 2
Knock load limit 1
Knock load limit 2
Knock RPM range 1
Knock RPM range 2
advance limiter 1
advance limiter 2
EGT nox set point
fuel bank 1
fuel bank 2
fuel min cat protection
fuel spool
fuel floor
fuel pressure target
fuel scalar 1
fuel scalar 2
Injector voltage comp
Load to Tq limit 1
Load to Tq limit 2
Load to Tq limit 3
max tq
max tq rpm
maf nanny
Torque request High
Torque request Low
Boost Control
WGDC Base
Spool Mode RPM
Boost ceiling
Coolant temp comp
Air intake temp comp
MAP sensor max voltage
Max Throttle Angle
Threshold for throttle closure
Max throttle angle at WOT
Throttle angle aggression in overload
WGDC spool
WGDC Derivative factor
WGDC Position
WGDC Proportional gain
WGDC Integral gain
Derivative gain
WGDC Adder
Load target 1
Load target 2
Load target offset for overboost
Speed limiter
Master speed limiter
Torque limiter
Boost limit
Limiter of turbo pressure
Misfire bank 1 and 2 toggles
Cat conversion bank 1 and 2 switches
Master speed limit switch
Tq reduction by ignition adv switch
Tq safety path switch
Tq safety path hard
Tq safety path soft
Lean spool switch

I have also been given ROM dumps for the following software versions: IJC0S, I890S, I8A0S, IGD0S, I480S, ICJ1S

I've been told that this list of software versions should cover most N54s users. Now it's just a matter of disassembling them which shouldn't take too long.

Again, big thanks to Dave W. and shiv@vishnu for generously donating this data. And thanks to everyone else who has been so supportive of my little project. The open source community is great!

[themyst]

Originally Posted by RombinHood2

Good news my friends! With some assistance from Shiv@vishnu and Dave W., I have accumulated what appears to be a comprehensive list of definitions for the IJE0S DME software. This means addresses, conversions and axis data. I still have to work out the definitions for the other software versions but that shouldn't take very long now that we are at this point. Here is what we have so far for the IJEOS:

Timing failsafe
Timing main
Timing open loop
Timing spool
Timing IAT correction factor
Timing total correction
Knock filter 1
Knock filter 2
Knock load limit 1
Knock load limit 2
Knock RPM range 1
Knock RPM range 2
advance limiter 1
advance limiter 2
EGT nox set point
fuel bank 1
fuel bank 2
fuel min cat protection
fuel spool
fuel floor
fuel pressure target
fuel scalar 1
fuel scalar 2
Injector voltage comp
Load to Tq limit 1
Load to Tq limit 2
Load to Tq limit 3
max tq
max tq rpm
maf nanny
Torque request High
Torque request Low
Boost Control
WGDC Base
Spool Mode RPM
Boost ceiling
Coolant temp comp
Air intake temp comp
MAP sensor max voltage
Max Throttle Angle
Threshold for throttle closure
Max throttle angle at WOT
Throttle angle aggression in overload
WGDC spool
WGDC Derivative factor
WGDC Position
WGDC Proportional gain
WGDC Integral gain
Derivative gain
WGDC Adder
Load target 1
Load target 2
Load target offset for overboost
Speed limiter
Master speed limiter
Torque limiter
Boost limit
Limiter of turbo pressure
Misfire bank 1 and 2 toggles
Cat conversion bank 1 and 2 switches
Master speed limit switch
Tq reduction by ignition adv switch
Tq safety path switch
Tq safety path hard
Tq safety path soft
Lean spool switch

I have also been given ROM dumps for the following software versions: IJC0S, I890S, I8A0S, IGD0S, I480S, ICJ1S

I've been told that this list of software versions should cover most N54s users. Now it's just a matter of disassembling them which shouldn't take too long.

Again, big thanks to Dave W. and shiv@vishnu for generously donating this data. And thanks to everyone else who has been so supportive of my little project. The open source community is great!

IJE0S ftw.

[klipseracer]

So at what point does this actually become open source?

[OpenFlash]

Originally Posted by RombinHood2

Good news my friends! With some assistance from Shiv@vishnu and Dave W., I have accumulated what appears to be a comprehensive list of definitions for the IJE0S DME software. This means addresses, conversions and axis data. I still have to work out the definitions for the other software versions but that shouldn't take very long now that we are at this point. Here is what we have so far for the IJEOS:

Timing failsafe
Timing main
Timing open loop
Timing spool
Timing IAT correction factor
Timing total correction
Knock filter 1
Knock filter 2
Knock load limit 1
Knock load limit 2
Knock RPM range 1
Knock RPM range 2
advance limiter 1
advance limiter 2
EGT nox set point
fuel bank 1
fuel bank 2
fuel min cat protection
fuel spool
fuel floor
fuel pressure target
fuel scalar 1
fuel scalar 2
Injector voltage comp
Load to Tq limit 1
Load to Tq limit 2
Load to Tq limit 3
max tq
max tq rpm
maf nanny
Torque request High
Torque request Low
Boost Control
WGDC Base
Spool Mode RPM
Boost ceiling
Coolant temp comp
Air intake temp comp
MAP sensor max voltage
Max Throttle Angle
Threshold for throttle closure
Max throttle angle at WOT
Throttle angle aggression in overload
WGDC spool
WGDC Derivative factor
WGDC Position
WGDC Proportional gain
WGDC Integral gain
Derivative gain
WGDC Adder
Load target 1
Load target 2
Load target offset for overboost
Speed limiter
Master speed limiter
Torque limiter
Boost limit
Limiter of turbo pressure
Misfire bank 1 and 2 toggles
Cat conversion bank 1 and 2 switches
Master speed limit switch
Tq reduction by ignition adv switch
Tq safety path switch
Tq safety path hard
Tq safety path soft
Lean spool switch

I have also been given ROM dumps for the following software versions: IJC0S, I890S, I8A0S, IGD0S, I480S, ICJ1S

I've been told that this list of software versions should cover most N54s users. Now it's just a matter of disassembling them which shouldn't take too long.

Again, big thanks to Dave W. and shiv@vishnu for generously donating this data. And thanks to everyone else who has been so supportive of my little project. The open source community is great!

Glad you got what you need to bet the ball rolling. Always happy to help a project like this.

Looking forward to seeing your next step

Cheers,
shiv

[V8bait]

Originally Posted by shiv@vishnu

Lol... it's okay. Fair question. We currently flash DME's, using our own in-house open source tuning system. We charge $100 and each flash we do takes 1.5 hours to read/write. This makes it a very unscalable business model. Which is fine since we do it more as a courtesy than anything else for our Procede customers.

Helping in the development of an open-source at-home flashing system will certainly improve the quality of tunes and provide our customers with more flexibility. The mail-your-dme-to-us solution was always considered to be an inexpensive stop-gap solution until something better came along. And something better, by the looks of it, is coming along. For us, we spent the last year defining all the necessary tables in an open source environment while everyone else was using the closed system that Cobb defined for them. To sit on all this open source data for our own use really doesn't help anyone (not even ourself). And releasing it to the public along with whatever Rombinhood is cooking up just sounds so much more interesting. And having already seen this open source transition in the Evo and Suby markets, I know it's inevitable. We might as well be riding the wave instead of being drowned by it

I'm meeting up with Rombinhood tomorrow night to discuss ideas on how to launch his product so that it is useable for everyone and not just for the few lunatic fringe hackers looking to get access to new tables that haven't been edited before.

Shiv

Not a procede user, but I do have to say my faith in Shiv just got a nice bump after reading this.

If you need any more dumps let me know. My ECU was listed already so I don't think it would be useful. TunerPro XDF's would be awesome!

[A418t81]

Originally Posted by shiv@vishnu

Glad you got what you need to bet the ball rolling. Always happy to help a project like this.

Looking forward to seeing your next step

Cheers,
shiv

I appreciate your contributions to the project, Shiv. You have certainly sped things up considerably. Hats off to you, sir

Rombinhood, are you planning on releasing some sort of GUI that is similar to the OpenECU suite with XML definitions, etc?

[Transport3r]

Great sounding progress so far!

How do you find out which DME software version is on there?

[OpenFlash]

Originally Posted by Transport3r

Great sounding progress so far!

How do you find out which DME software version is on there?

If you look at the ROM in ASCII format you will see it written early in file. You'll see it imbedded a few times in the following string (in bold): 0044CC0IJE0SITA3S0044CC0IJE0SITA3S0044CC0IJE0SITA3S

Cheers,
shiv

[bv1]

Are you guys planning to disassemble other modules as well such as the transmission control unit for the AT or DCT? would the process be similar?

[widebody335]

Hey just registered but been lurkin for a while. Just wanted to say this is very cool to see. I come from the Audi s4 b5 world and a similar thing happened on a nefariousmotorsports.com forum for the Bosch me7. Some people used winols but people preferred to do it right so tunerpro was adopted as the software to use. People collaborated on translatig some German documents and xdf damos' were created. The s4 platform has shot forward as a result.

Also I want to give props to shiv for helping the project and not trying to stifle it. In the s4 world tuners tried to sabotage the project early on with misinformation and in the end it just made them look petty and insecure

I don't know anything about Siemens msd 80/81 but I'm sure the general concepts carry over.

What cable are you flashing with? For audis we use the kwp2000 protocol over obd2 port. If the ecu is bricked we use a bench flasher and bootpin - does this work on BMW?

[BoostNinja]

This reminds me of my talon and dsmlink back in the day. I never though I would see this in the bmw world. I've had my fingers crossed for years that Jim Conforti was going to release "shark editor" or whatever it was going to be called but I think that project died, or he was paid not to release it! lol

[WilliamS]

Ive been gone 4 months and come back to this! This is exactly what Ive wanted from day 1. If anyone here is familiar with EFI live you understand why this software must exist!

[Boosted-M]

Awesome work guys and cannot wait to test some of this out on my IJEOS..!!!

What about the tactrix cable??

http://www.tactrix.com/index.php?option=com_content&view=category&layout= blog&id=36&Itemid=58

[Rombinhood@OpenFlash]

Originally Posted by widebody335

Hey just registered but been lurkin for a while. Just wanted to say this is very cool to see. I come from the Audi s4 b5 world and a similar thing happened on a nefariousmotorsports.com forum for the Bosch me7. Some people used winols but people preferred to do it right so tunerpro was adopted as the software to use. People collaborated on translatig some German documents and xdf damos' were created. The s4 platform has shot forward as a result.

Also I want to give props to shiv for helping the project and not trying to stifle it. In the s4 world tuners tried to sabotage the project early on with misinformation and in the end it just made them look petty and insecure

I don't know anything about Siemens msd 80/81 but I'm sure the general concepts carry over.

What cable are you flashing with? For audis we use the kwp2000 protocol over obd2 port. If the ecu is bricked we use a bench flasher and bootpin - does this work on BMW?

I'm happy to hear this thread got to get out of lurker mode It's great to see others excited about these developments. I've missed a few episodes of Game of Thrones trying to work out these rom files. But that is why there is DVR... so that this important work can be done!

Only early MSD80 (MY2007?) use kpw2000/k-line communication. After that, BMW adopted CAN protocol since it's so much more elegant. I have written code that first attempts to achieve CAN communication by default but then switches to K-line if communication is not established. I'm currently using my own cable that I brewed up from a cheap off-the-shelf obd2 diagnostic cable. I have yet to brick a DME and I've tried some rather risky things (low voltage, inconsistent voltage, unplugging the cable during a write process, and so forth). There are some surprisingly solid safety mechanisms in place that have made my job easier than it could have been

[335okc]

Originally Posted by RombinHood2

I'm happy to hear this thread got to get out of lurker mode It's great to see others excited about these developments. I've missed a few episodes of Game of Thrones trying to work out these rom files. But that is why there is DVR... so that this important work can be done!

Only early MSD80 (MY2007?) use kpw2000/k-line communication. After that, BMW adopted CAN protocol since it's so much more elegant. I have written code that first attempts to achieve CAN communication by default but then switches to K-line if communication is not established. I'm currently using my own cable that I brewed up from a cheap off-the-shelf obd2 diagnostic cable. I have yet to brick a DME and I've tried some rather risky things (low voltage, inconsistent voltage, unplugging the cable during a write process, and so forth). There are some surprisingly solid safety mechanisms in place that have made my job easier than it could have been

good to see real progress! what exactly did you do to modify the cheap obd2 cable? i suspecti have what you have lol.