Especially at the current rate my urs6 is drinking fuel, is 18mpg about right for a urs6 driven by a 22 year old testosterone fueled male?
Announcement
Collapse
No announcement yet.
MRC Tuning no longer tuning 5 Cyl 20v Turbo engines... who to go to?
Collapse
X
-
The objective of my project is such that I do not have to tune these myself ever gain
And the only way to achieve this is by putting accessible and easy to use tools out there.
Then it'll be just like mapping another standalone ecu.
Comment
-
MRC Tuning no longer tuning 5 Cyl 20v Turbo engines... who to go to?
Originally posted by prj View PostThe objective of my project is such that I do not have to tune these myself ever gain
And the only way to achieve this is by putting accessible and easy to use tools out there.
Then it'll be just like mapping another standalone ecu.
Have alot of interess on this Option
Comment
-
That would be ideal to do an easy tune like a standalone. Specially for older cars tjat are not pushed toto the limit. Parts are more difficult to find and alternatives often require remap.1967 fiat 500 future project
1976 audi 100 coupe S
1989 vw corrado 16V
1989 audi 90 quattro 20V sport
1994 audi RS2 project
1994 audi RS2 parts car
1995 audi RS2 project
Comment
-
Originally posted by prj View PostBelieve or not, but it can't unless you have a giant flowbench and a known good MAF. And that doesn't help it any since they tend to go pop after RS2 power.
This thread has motivated me to work on plug and play solution again...
I am drawing the board right now... the problem is always to finish these projects.
Comment
-
Hardware is probably no problem - I got the designs pretty much sorted. It's just a couple chips for either side.
The main issue is writing all the software...
There are two boards (one for each side), they have a SPI bus between them, I want to allow analog WBO2 input, 8-way map switch, pass-through ECU comms through the daughterboard, meaning no ten million cables - just single USB to plug in, maybe flex fuel(?) and so on...
Then there is the whole question of writing the windows software to interface with it.
Comment
-
MRC Tubing no longer tuning 5 Cyl 20V
Originally posted by vti2 View PostHave alot of interess on this Option
hour and no telling how long it takes and then adding on the MAF issues?
Please keep us posted and thank you PRJ.
Comment
-
keep us posted, sounds like the thing to make our cars more future proof. don't mind paying serious money if needed (don't let our county's reputation fool you, as an S2 owner I am used to spending ).
Originally posted by robo View PostYou know how far is Estonia
Comment
-
The target price point is around 500 EUR. Any more than that is pointless, as you approach the hardware cost of plugin solutions.
That said, from my experience actually tuning the stock ECU is much easier than standalones, because a LOT of the things just work. Cold start, warmup, idle pid and so on.
The hard part is finding the correct maps and how to tune, but I am taking care of that...
If there is someone with embedded experience who doesn't mind looking over some hardware schematics, let me know. Software is not a problem for me, but designing hardware - I am an amateur at best.
There are two limitations to M2.3.2, which can not really be solved:
1. Dwell time. The way ignition works, is the chip that calculates timing and dwell is actually the same like the one in cars with a distributor. What the second chip does that calculates boost control and knock retard, is it acts as a solid state distributor. So even though the system is a COP style system, the dwell time is limited exactly the same, as it would be on a distributor based system.
There is a single ignition line from one MCU to the other. When it is pulled high, it starts to dwell the selected coil, and when it is pulled low it fires the spark.
The maximum dwell time per RPM in ms is as follows:
Code:1000 24.0 2000 12.0 3000 8.0 4000 6.0 5000 4.8 6000 4.0 7000 3.4 8000 3.0
But you can't really use some specific coils that require very long dwell times and charge kinda slowly....
2. RPM
Basically, the stock system is designed to run up to 10000rpm.
Unfortunately this is no longer the case when you add code to it. Specifically code that datalogs ten times more info than it normally does.
Surprisingly it is not the fuel/ign chip that does the majority of the map lookups that gives in first, but rather the boost/knock chip.
This is because the fuel/ign chip operates on a "best-effort" style system. It recalculates the parameters 100 times per second, and the background calculation of the fuel/ign can easily slow down to 50-60 times/sec at 8000 rpm or so without any ill effects.
However, the knock chip is real time. It has to process the knock from every single ignition event and it has to do that 5 times per 2 engine revolutions. As you saw with the dwell time in the first part, the time available to do this decreases very rapidly with rising RPM.
The only solution is reducing the logging speed to the level that the boost/knock chip can handle.
Up to 7200 rpm, there is no problem doing 10hz logging. But at 8000 rpm, you can't do much more than 4-5hz, because simply the processor is not powerful enough for this - it is so busy processing the knock, that it doesn't have time to do almost anything else.
So basically the design limit for the system where you can actually log something meaningful is approximately 8500 rpm. However anyone running over 8000 RPM most likely has a dry sump on their car and most likely the car is used exclusively for racing, so this ECU solution is useless to them anyway.
Just thought maybe it's a good idea to come clean on the physical limitations of the ECU.Last edited by prj; 13 March 2017, 13:37.
Comment
-
Nice! That dwell won't be a problem with tfsi coils, and they handle 3bar boost easily.
Audi UrS4 Avant 2.5 20vt - twincharged - Project
Audi 80q B4 Sedan 2.2 20vt - Daily user
BMW 320d Touring e91 M-Sport - Daily user
BMW 740iA e38 - Project
Comment
Comment