[taylors335]

that was my mind being BLOWN !!!

[widebody335]

I think it's kind of amusing that a lot of the posts and concerns are identical to what happened with the Bosch me7.

People beig concerned about novices blowing motors - dont protect them, if you are messing with this stuff you should know the risks and rewards

Tuners worried about it affecting their livelihood - sure it may affect it a tiny bit but the market won't be affected that much - there is a lot of value in the support and turnkey solution a real tuner offers. Also the open source development will further the platform for all - hobbyist and professional

Also regarding the flashing single snippets instead of a full read/write - now people are just getting ahead of themselves lol - lets start with a full read/write

Does anyone have the official Siemens PDF document on the msd 80/81? I know it's def out there - maybe we could all chip in to buy it and divide up chunks and create a 335wiki page or something?

Mono o2 sensor is definitely what everyone wants for single turbo. That's the main thing I'm interested in

[OpenFlash]

Originally Posted by widebody335

Mono o2 sensor is definitely what everyone wants for single turbo. That's the main thing I'm interested in

Not everyone. I, for one, would like to retain the resolution have (3 cylinders averaging per lambda sensor) instead of reducing it by half. Would make packaging easier to only have 1 sensor. But it would be a step in the wrong direction as far as fuel control is concerned. Hell, if we could get the DME to support it, we'd have 1 lambda sensor in each runner. Individual cylinder closed loop fuel control? Sign me up!

[3000GT MR]

Originally Posted by shiv@vishnu

Not everything. I, for one, would like to retain the resolution have (3 cylinders averaging per lambda sensor) instead of reducing it by half. Would make packaging easier to only have 1 sensor. But it would be a step in the wrong directly as far as fuel control is concerned. Hell, if we could get the DME to support it, we'd have 1 lambda sensor in each runner. Individual cylinder closed loop fuel control? Sign me up!

agreed. not all cylinders are created equal. some hotter than others. same goes for spark and fuel injection. the more the better.

[widebody335]

Yes 2 o2 is better for resolution and individual bank control is awesome and that's how it is on f1 cars and big Diesel engines - but lots of cars are running single o2 with no issues.

Also putting the o2 sensors in the manifold must lead to shorter o2 life - are they able to withstand those manifold temps?

Furthermore, u can make a nice cast log or compact manifold with 6-1 collector and the packaging will be much much simpler

It's awesome that we are able to even start these debates/discussions!! Can't wait to see what's in store. Maybe some launch control, some really nice data logging programs, 1000whp n54, etc

[CannonFodder]

Originally Posted by widebody335

Also putting the o2 sensors in the manifold must lead to shorter o2 life - are they able to withstand those manifold temps?

I would think pressure would be a larger issue then heat. Unless you have very high egts.. Look at the stock design. There is a reason bmw engineers put them post turbo.


Back on topic.

[OpenFlash]

Originally Posted by widebody335

Yes 2 o2 is better for resolution and individual bank control is awesome and that's how it is on f1 cars and big Diesel engines - but lots of cars are running single o2 with no issues.

Also putting the o2 sensors in the manifold must lead to shorter o2 life - are they able to withstand those manifold temps?

Furthermore, u can make a nice cast log or compact manifold with 6-1 collector and the packaging will be much much simpler

It's awesome that we are able to even start these debates/discussions!! Can't wait to see what's in store. Maybe some launch control, some really nice data logging programs, 1000whp n54, etc

Putting o2 sensors closer to the engine (where exhaust is hotter) will always reduce life. This is why we use thermal isolators in our single turbo manifolds to reduce o2 sensor temp/increase life to the point where this is a non-issue.


A 6-1 log cast manifold will certainly be the cheapest and easiest approach. But I think one reason these engines are holding together this well, at the 700+whp power level, is because of the sensor resolution (reducing fueling imbalances between cylinders) and exhaust back pressure/heat reduction from using a nice tubular header.

[AK 335i]

Originally Posted by shiv@vishnu

Putting o2 sensors closer to the engine (where exhaust is hotter) will always reduce life. This is why we use thermal isolators in our single turbo manifolds to reduce o2 sensor temp/increase life to the point where this is a non-issue.


A 6-1 log cast manifold will certainly be the cheapest and easiest approach. But I think one reason these engines are holding together this well, at the 700+whp power level, is because of the sensor resolution (reducing fueling imbalances between cylinders) and exhaust back pressure/heat reduction from using a nice tubular header.

we are doing this as well shoulda just shot ya a pm, didn't know if you guys did this or not. but we did just to be safe

[PrettyFlacko]

Wish I had skills like that

[StevenY.]

This is so cool, I just read through this entire thread. Glad I randomly stumbled upon this thread. So if I read correctly, when this is ready to release it will even be easy for people who have no knowledge in doing these types of things? If that's the case, it would be cool since I'm one of those people. Keep up the good work!

[3000GT MR]

Originally Posted by shiv@vishnu

Putting o2 sensors closer to the engine (where exhaust is hotter) will always reduce life. This is why we use thermal isolators in our single turbo manifolds to reduce o2 sensor temp/increase life to the point where this is a non-issue.


A 6-1 log cast manifold will certainly be the cheapest and easiest approach. But I think one reason these engines are holding together this well, at the 700+whp power level, is because of the sensor resolution (reducing fueling imbalances between cylinders) and exhaust back pressure/heat reduction from using a nice tubular header.

doesn't the timing have everything to do with sensor reading. for instance a cylinder misfire is indicated by knock,o2 reading and the timing sequence of revolution. if you remove one of those out of the equation the dme has no idea what cylinder to add/remove fuel from.

[widebody335]

Greater resolution is definitely better. Can't argue that, I'm just saying that a bunch of cars switch to single turbo and work fine.

Sorry to derail this thread a little, back on topic, ill start a new thread about the challenges and options for single turboing. The tune is just the most important piece of the puzzle which is why I mentioned it.

So how about that donation fund to help the project?

Also can you share details about the flash cable? And perhaps a damos/xdf?

And perhaps even a Siemens msd80/81 funktionsrahmen?

[widebody335]

Originally Posted by 3000GT MR

doesn't the timing have everything to do with sensor reading. for instance a cylinder misfire is indicated by knock,o2 reading and the timing sequence of revolution. if you remove one of those out of the equation the dme has no idea what cylinder to add/remove fuel from.

It has 2 sensors one for each bank - so if bank one goes lean it still doesn't know which exact cylinder in bank 1 runs lean. It just adds fuel for the entire bank. This is why shiv was saying 1 o2 sensor for each cylinder would be best since then you'd have individual cylinder control


Also of people that currently know nothing about tuning think they can load up a program and flash a file .... You can. But if you don't know what file you are flashing and what you are changing and why ... Disaster is certain. It takes sooo many hours to learn how to tune. For most people it's more worthwhile to just pay a tuner for their expertise.

Also what are people using for checksum correction

[BMWcurious]

Does MSD80/81 perform engine speed corrected time domain calculations on the O2 sensor signals to trim individual cylinders whose exhaust gas passes the same physical sensor?

[OpenFlash]

Originally Posted by BMWcurious

Does MSD80/81 perform engine speed corrected time domain calculations on the O2 sensor signals to trim individual cylinders whose exhaust gas passes the same physical sensor?

Not that I'm aware of. Seem that would be impossible with turbos upstream of the o2 sensors mixing everything up like a quosinart.

[BMWcurious]

Patent searches suggest it has been done with O2 sensors downstream of turbines as well, which surprised me also. I asked as I thought I'd read it in the context of MSD80 somewhere, if so it would be relevant to modification as there would be a load vs RPM map of transit time from exhaust valve closure to the start of O2 sensor sampling which would require modification to keep such a system working properly with higher loads, turbo change and many other significant changes affecting VE. I guess with your exploits you'd have come across any untoward effects if a system like this was active. German ECUs are just too complicated which is why I've always avoided them.

[guru_method]

Hey man, awesome that you are doing this.

What would it take for you to get into the 6AT TCU and be able to tune it?

[Rombinhood@OpenFlash]

Originally Posted by guru_method

Hey man, awesome that you are doing this.

What would it take for you to get into the 6AT TCU and be able to tune it?

Originally Posted by guru_method

Hey man, awesome that you are doing this.

What would it take for you to get into the 6AT TCU and be able to tune it?

I haven't looked into programming the TCU. But it seems as if it can be done without too much difficultly. Before I get involved with that I would like to make sure we have all the basic "flash tuner" functionality such as DME read/write capability, activations, data logging and a good GUI that allows experienced OS and novice shade-tree users to program comfortably. With some assistance from others I've just sorted out PID data-logging which was easier than expected. Depending on how much on-board memory that can be fitted on our flashing hardware, I'd like to support the option for full-time logging on a FIFO basis. Perhaps with the ability to flag start/stop commands for those time you want to record only a certain snippet of driving time. The data can be saved as a .csv file that can be configured to be read on any number of nice datalog viewers that I've seen people use. A lot of progress has been made over the past week and I should have something to show you guys soon. Again, a big thanks to those who have (and have offered) to help with this project!

Also, it was recently brought to my attention Josh Dinkel, ECU Engineer at Cobb Tuning, has claimed to initiate discussions of legal action within his company. He publicly stated that I have "stolen" his work . In my opinion, it is hypocritical for a reverse engineer to blame another reverse engineer for reverse engineering something that neither of them created. Unless Mr. Dinkel is a representative of Seimens VDO, I think he should be more careful of the accusations he makes. If his claim is that I have taken advantage of his map discovery work, let it be known that there are others with said knowledge and willingness to share it. And I have already thanked them for it. As an employ of a company that profits on closed tuning hardware, I understand Josh's dismay. But there is nothing that I can do about it. Progress will always take its course. As always, I appreciate all the support and encouragement I've received and look forward to further developments.

[Rombinhood@OpenFlash]

Originally Posted by A418t81

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?

I'm not a GUI guy myself but Shiv and Dave W. already have developed XML/XDF files for the open source map editing suites they have been using. Shiv uses TunerPro ad Dave W. uses OpenECU. I'll defer all GUI questions to them since they have both generously agreed to support that side of things. My role is primarily in hardware/firmware development.

[Rombinhood@OpenFlash]

Originally Posted by COBB Tuning

Despite open source options available in the Subaru world, people still love the Accessport for a reason (we just sold our 10,000th AP-SUB-001 and tens of thousands more for the other Subaru part numbers). You can't make a call to "open source" when things aren't working! I'll admit I'm disappointed to see our hard work copied, but imitation is the highest form of flattery I guess.

-Josh

I'm embarrassed to say that I haven't even seen this post (on 3rd page of this thread) until now. I must have missed it. Josh, I am happy for your company's success and I wish that it continues. You guys deserve it given your great efforts. But please do refrain from accusing me of stealing from you. I agree that imitation is the highest form of flattery but I have no intention of imitating your accessport, as fine of a product as it may be.

[COBB Tuning]

Originally Posted by RombinHood2

I'm embarrassed to say that I haven't even seen this post (on 3rd page of this thread) until now. I must have missed it. Josh, I am happy for your company's success and I wish that it continues. You guys deserve it given your great efforts. But please do refrain from accusing me of stealing from you. I agree that imitation is the highest form of flattery but I have no intention of imitating your accessport, as fine of a product as it may be.

I was simply referring to the fact that you stated you were "hacking" flash tunes for tables... It may be another company you're "hacking" but its still a shame that you are taking someone else's hard work. I was not accusing you, just pointing out what you stated in your own post.

-Josh

[guru_method]

Originally Posted by RombinHood2

I haven't looked into programming the TCU. But it seems as if it can be done without too much difficultly.

I believe that this will be a real breakthrough for the community. Dare I say... more important than the opensource.