Introduction to Atlas™
For those who have been wondering how our port controller works, we hope this provides the insight you've been searching for! Due to a number of outside factors, we've had to shield how things really work. While we're pretty well in the clear at this point, we won't go into the extreme detail, but we wanted to provide a look at how things function along with the explanation why this port system is going to simplify everything about how you add port injection.
First and foremost, we've got a log for display:
Sample Log from Atlas™ Controller
A few things to note when viewing this log:
- You'll notice two channels in the channel list titled "New Air-Fuel Ratio" and "New Equivalence Ratio". These are the actual final targeted values from the controller, so when creating a graph display, use these if you want to see them. Why? Well, we have a modifier table that enriches the target fuel ratio based on port contribution. We calculate the port contribution in real time, and we can command extra fuel as the port fraction increases. This enrichment is reflected in the two values mentioned.
- "Actual Lambda B1" and "Actual Lambda B2" are respective wideband values from the exhaust. This car, for whatever reason, is consistently richer on bank 2, which the narrowbands corroborate.
- Since this car is using dual widebands, we do per bank closed loop fuel control. The correction factors in the channel list are per bank, but they only apply to the actual port fuel contribution. We cannot change what the ECU is doing, and the only authority we have over fueling is what the port system does. This correction value will look really large at very small port fractions as a result. If you want an idea of the OVERALL error that the controller is compensating for, subtract 1 from the correction value and multiply by the port fraction.
Math Parameters:
Bank 1 Error - ([12128]-1)*100*[12190]
Bank 2 Error - ([12129]-1)*100*[12190]
These normalized values will convert the port correction into a more "global" correction for overall fueling.
Make sure you update to the latest HP Tuners Beta to view the log. Our controller is recognized as a supported device by the HPT MPVI3, so when you want to add channels, you'll simply scroll down to our device under the list and grab whatever you want.
The controller's function is ultimately pretty simple. The patched operating system outputs a lot of information on a constant schedule (6ms update rate). We take all of that information to paint a picture of the total airflow the engine is consuming along with the total amount of fuel the ECU is supplying through the DI system. When the DI system can't keep up, there's a delta (which we calculate in real time). We simply fuel that delta using the same physics based function that GM's ECMs have been using for years. This is why accurate and reliable injector information is crucial to the controller's function, and this is why we can't emphasize enough the "garbage in, garbage out" saying if you want predictable fueling. The beauty of the system is we don't even need to know ethanol content (we do get it from main CAN, but it's literally only for the upcoming boost control strategy). If your fuel pressure changes, if your MAP value changes, if you're running pure MAF, if you're running pure SD, if your ethanol content changes, if the temperature changes, if the barometric pressure changes... none of that matters due to the physics based calculation for fueling. We track both MAP and absolute fuel pressure so we can calculate delta pressure, and we do it wholly over CAN (along with all of our data). The only things we truly need are cam and crank signals. We actually had a way to do fully synchronized sequential injection without those, but the 6ms update rate was a bit limiting at higher RPM and would require too much estimation of engine position.
So... what's actually triggering the controller? I suspect this is where a lot of people are going to throw a fit due to being fixed in their old ways. If you examine the log and pay attention to injection duration, you'll see it caps out at 180°. This value is user adjustable (and has been since tuning became available), and through a lot of testing on our end (and abuse of our poor test car), we found 180° was the middle value of the bell curve in terms of power production. When applying the patch, this value will default to 180°. Ultimately, you can change it to whatever you want, and you may actually need to based on cam specs.
If you have ever tried to just firehose a DI system because of being new to it or just having no clue what you're doing, you'll know that E92s clip the injectors at about 48% IDC. A full engine cycle is 720°, and roughly 48% of that is 350°. This should ring a bell for those who have poked around aimlessly in a cal file to see what's there. This is the value we drop to 180°. If you reduce the engine cycle down to a very basic level, you've got four events: intake, compression, power, and exhaust. Each stage of the piston's movement lasts 180°. Direct injection absolutely cannot spray during power and shouldn't during exhaust (within reason). You can spray during compression, but it's not a great idea. You're left with spraying during the intake stroke which is what's intended to happen anyway (you want your DI shot injected while the cylinder is filling). You know how everyone talks about this magic 5.0ms to 5.5ms injector time? Well, 5.5ms happens to be 180° worth of crank rotation at 5454rpm, and 5.0ms happens to be 180° worth of crank rotation at 6000rpm. People tend to get really tied up in this injector time independent of engine speed, though. The meta needs to shift towards considering direct injection time as a function of crank rotation. If you do this, suddenly DI systems make a lot more sense!
It is pretty simple to think about now... the DI system is allowed to do whatever it wants until it reaches this defined maximum, at which point the port system begins to roll in (while keeping track of its own contribution and adjusting as necessary based on the fraction). But wait... this means the pulsewidth is about 7ms at 4300! Again, it helps to stop thinking of time as your metric and switch to crank rotation. You want as much of a DI pulse as you can get during the intake stroke before you attempt to inject anything else. As a quick note, the controller does not need to know what you use as the programmed maximum duration; we know it automatically. ;)
At this point, you're probably going to bring up the fact that the high side pressure has dropped at this lower RPM range and might want to argue about that. Again, you have to go back to the injection duration as a function of crank rotation. While yes, the high side pressure did drop (as this car has a stock cam), the reality is that running more port fuel to bring the high side pressure up isn't going to net you any gain. You're ultimately going to get the same amount of overall fuel, and the actual mass of your DI shot isn't going to actually be any greater (it may actually be lower). If your pressure goes up, that only happened because your on time was shorter, so you didn't really get anything more out of the event. Now if your pressure drops TOO low, sure, you're going to run into other issues like a potential CEL because of the extreme difference between commanded and actual or maybe pressure would fall so low that it breaks up, although that would be an extreme case that would indicate bigger issues exist. The moral of the story is to not be hung up on this, but if you really want to, you can run a lower threshold to keep pressure up (you might just be penalized on power at higher rpm). There are some creative ways to make the duration adjustable, and perhaps HPT can even change that scalar to a RPM based table, but that really just shouldn't be needed.
When you consider how the system works, you'll suddenly realize that it's designed to always provide the "right" fraction given the operating conditions. On regular gasoline, where your stoich value is higher, the port system will automatically back off and run a lower fraction because the 180° worth of on time might actually provide all (or almost all) of what you need. You aren't forcing your fueling to be clipped by the same percentage regardless of stoich ratio or boost. Since we work off of what the ECM is actually doing, you aren't required to hack up your airflow models either. You can dial in your MAF and VE with realistic numbers and have believable data to see what's really happening. You don't have to tell a 1000hp combo that it's only moving 400 g/s of airflow, you won't wind up with a weird hump in your MAF curve, and you won't have a VE surface that brings back memories of Excitebike. The waterfall benefit here is that your torque calculation isn't destroyed and won't require you to cheat it back into compliance. The ECU will continue to appropriately calculate torque (again... producing BELIEVABLE numbers) which will keep your automatic transmission happy (and helps with rev match logic for manuals, too).
We have a number of other quality of life things built in that we won't go into excruciating detail on, but you can experience fuel cut, shift under full torque management, and not have to worry about partial cylinder cut off events because we catch them all and respond appropriately. Closed loop isn't really required, but for those who want it, it is available and robust. The biggest takeaway is that it just works. You just tune the ECM like nothing ever changed because Atlas™ does all the heavy lifting.
