This Atlas FCU update incorporates per cylinder adjustment. This adjustment factor is global meaning it's going to look at the total fuel required for the cylinder and adjust by whatever percentage you add (not just a portion of the port fraction).
We have a fairly comprehensive update available for the Atlas along with a few perks to go along with it. Implementation of boost control is complete, and we just need to manufacture the bits to go with that now. We also had to modify code in 34 operating systems for functions: variable maximum injector driver on time and correcting GM's conversion of fuel flow rate for the fuel pump control ring. The variable max injector driver on time is likely not needed for most people, but somebody running grossly oversized DI injectors with a high pressure pump that isn't producing near enough to exercise them may benefit by restricting things at lower engine speeds when the DI injectors are acting like a firehose. The fuel flow correction will largely pertain to the DSX bucketed fuel pump system for the Camaro/CTS-V but was also going to be necessary for the C7 dual brushless bucket that's coming up. The core problem was loss of control beyond 64 g/s of fuel flow because of GM's choice in storing data. As a result, the integral correction would have to wind up causing two side effects: fuel pressure always lagging behind commanded, and over pressure when letting off the gas because the ECU had to wind the integral correction back down. This code modification allows control of the system up to 512 g/s of fuel flow which... well... nobody's going to hit anywhere near that unless you have five of the brushless pumps!
Atlas FCU updates:
Atlas UI updates:
If updating your Atlas, please be aware:
Click here to download the 20250627 FCU firmware.
Click here to download the 1.0.4.3 UI firmware.
Click here to download the TunerPro definitions for the 20250627 FCU firmware.
When the topic of port injection on top of direct injection comes up, there's no shortage of people willing to puke their "experience" onto you. Sure, experience can be useful, but physics and data are usually better as experience often leads to potentially poor opinions with no real backing. People tend to rely on "experience" as a shortcut to looking at data, and they wind up missing a lot while making poor conclusions.
"Without data, you're just another person with an opinion." - W. E. Deming
There's a marked different in knowing what to change versus knowing why to change it. This distinction really comes into play when it comes to DI systems because they carry a level of sophistication beyond conventional port injection; there are suddenly more variables to the system. You aren't just trying to get the whole shot of fuel in each ignition cycle, but rather you now have to get that shot in for a fraction of the cycle on top of timing it properly to the cycle (with port injection, during WOT, timing matters significantly less). "Time" is the metric that too many people consider when in reality it is a byproduct of more important variables earlier in the operating code.
Crank position is the unsung hero, especially when it comes to direct injection. You should be latently familiar with it because ignition timing is always in relation to crank position (specifically, top dead center between the compression stroke and power stroke). Before top dead center (BTDC) is historically where you make your power and is self explanatory... it means your event (whatever it may be) is happening before the piston reaches TDC.
0° -> Between compression and power strokes360° -> Between exhaust and intake strokes
This range is what is actually pertinent for direct injection. There are three primary metrics: start of injection (SOI), duration, and end of injection (EOI). We aren't going to discuss split pulses because generally it doesn't apply to this conversation. EOI is the end result of SOI and duration for GM ECMs not functioning in split pulse with one exception: GM does enforce an EOI 5° ahead of the spark timing meaning if your spark plug is going to fire at 20°BTDC, regardless of what you're trying to do, they're going to cut the DI pulse at 25° BTDC.
In general, you can inject fuel during the compression stroke, but it's going to run poorly and probably puke black smoke out the back. That means we should probably target an EOI no later than the inflection from intake to compression strokes... so... 180°. But isn't EOI a RESULT and not a driving factor? Well, yes, according to the way it is processed. We know how important EOI is, though, so we need to work backwards. SOI is the next consideration... we really don't want to inject during the exhaust stroke as that would be a bit pointless, so we should constrain our SOI to the inflection point between exhaust and intake strokes. Got it, 360°.
Quick sidebar... there's a level of leading those targets required just because there is still a physical travel time of fuel and inherent lag of things happening, so... give yourself a 3°-5° buffer. 5° translates to about 0.1 milliseconds at 6000rpm. Not significant, but also not zero.
Ok, we've got our SOI to be no sooner than 360° and EOI to be no later than 180°. Great! Wait... this means our duration is essentially clipped to 180º. This is neat, though, because it should translate to something you've probably heard people talk about which is that DI injectors need to fall into the 5.0ms-5.5ms range of on time when tuning with port injection on top. At 6000rpm, 5.0ms correlates to 180° of crank rotation! That 5.5 correlates to about 5454rpm, and those numbers wind up in the meat of your powerband. This is where there's a problem in the general "theory" people perpetuate, though, because they use this 5.0-5.5 number as an absolute regardless of engine speed when in reality, it is a dependent variable... a result. So step back and change your mindset to use crank position (and crank rotation).
180° of rotation at...7000rpm is 4.3ms
But... but... the milliseconds!
Crank rotation is what matters; time is just a byproduct. Read that until it sinks in.
The ECM knows the current airflow and injector characteristics along with the current required fuel mass. It takes this data and converts it to a time which is a little funny because ultimately everything is sequenced and scheduled off of current crankshaft position.
Alright, now we will assume you have confidence in this magic 180° number as well as ideal SOI and EOI for the DI shot. Now we need to talk about how this correlates on top of port injection. When you run pure port injection, there is absolute truth that the fuel in the intake port is displacing air that would otherwise enter the engine. There is no dispute there, and that's part of the reason that direct injection can make more power (you're putting the fuel in after the intake valve and not taking air's space in the intake tract). Unfortunately, DI fuel systems tend to tap out when making a lot of power... either the high side pump can't keep up or the injectors just aren't big enough to complete the shot during the intake stroke. You can opt to upgrade DI components at this point or move to port injection (what this discussion is about).
So now we're going to dump fuel through the intake port on top of the DI shot, but how do you know how to split that delivery? Well, historical systems will let you choose the fraction: this is the percentage of fuel that comes from the port system. When the ECM itself can't do this function, and you add a second computer controlling the port injectors, you end up having to just hack airflow out of the ECM and make up for it with this external device. You effectively have no direct control over the fraction and instead loosely set it by removing X% from the ECM and making up for it in the other device. The truth, though, is that the fraction is just a number. It's a byproduct of what the fuel system should be doing. When you have direct control over the fraction, the idea is to set it so that the DI system is achieving that 180° duration while the port system makes up the rest. There's zero merit to saying "The engine needs to run at X fraction".
There are those out there, though, who will insist that the fraction is an important number. It isn't. It's JUST a number... a number based on other more important factors (like DI on time). We opted to dispute this due to a claim that our Atlas™ port controller would cause problems because we don't allow "editing the fraction by rpm" which, again, just isn't what truly matters. So naturally, we beat the absolute shit out of our shop test car (2019 Camaro ZL1 1LE equipped with Atlas™). Again. This poor thing makes 72X whp nonstop and has been for 2000+ miles and 700+ pulls on the dyno. It's a great test car, though, because we don't have a ton of wild variables to the combo, and it loses high side pressure in the 3200-4800rpm range. It is brutally consistent.
We have three dyno pulls shown on this graph using our inhouse Mainline Prohub6000. Teal represents a max injection duration of 180° with a totally stock SOI calibration, red represents 120° max duration with optimized SOI (EOI ahead of 180º), and yellow is 180° max duration with optimized SOI. The discrepancy in power is happening during the aforementioned loss of high side pressure. I'm showing the unoptimized SOI run because chances are a lot of people out there want to use scenarios of their own laziness as an excuse for why more port fuel makes more power in certain conditions. High side pressure falls in both the teal and yellow graphs but does not in the red because of the larger port contribution through the trouble region.
In the teal pull, there's a marked difference in power and an obvious loss down low (35whp at the worst point at 4000rpm). This is largely due to the fact that injection was ending during the compression stroke (140° BTDC at the worst point). Again, this was with stock SOI tables which aren't ideal for how much fuel this thing is consuming. Power recovers by 4800rpm and is within the margin of error for typical dyno pulls (1%-1.5% roughly).
In the red pull, because the port was being activated while DI was clipped to 120°, the high side pressure didn't fall. On the surface, it might seem like high side pressure not falling is what mattered, and somebody would have stopped there to prove their point (confirmation bias is real).
In the yellow pull, I advanced SOI enough to get EOI ahead of that 180° mark. High side pressure fell like always, but you can clearly see the power didn't suffer. In fact... it performed BETTER than the 120° duration dyno pull. One could argue it's within margin of error here, and I'm fine with that too. Either way, the result is indisputable, and we can take away two important points: high side pressure isn't a determining factor and port fraction doesn't have the importance people want to give it.
With our Atlas™ controller, the file that's patched in HP Tuners starts your max duration at 180° as opposed to the 350° that it is set to stock. You can adjust this, and by all means... play with it. We use 180° because it's a clean and obvious number that correlates to something concrete: the intake stroke of the crankshaft. We all still need to be mindful of high side pressure to some degree (we don't want it crashing to 2 or 3 MPa), but it does become less of a primary concern when using port injection. Knowing that pressure is not going to keep up means that I might consider just commanding less pressure where I know it can't achieve it, and at the end of the day, this will still work great.
The moral of the story is... get your DI shot in during the intake stroke (with none happening during compression), and get your port contribution in there to make up the difference. Luckily for you, our Atlas™ controller does this automatically for you. While some might claim we're just selling port injection for dummies, the reality is we took a physics based approach to provide a controller that not only simplifies things for beginners but also uses such a robust algorithm and concept that it is still ideal for big power builds. Tell it the injector size, tune the car, and move on with your life. Let the port fraction be whatever the controller says it is at the end of the day and enjoy seamless port injection on top of your DI system.
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:
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.
After seeing the same questions asked repeatedly, we figured it was time to keep a record that could answer most (if not all) of the questions they have about Atlas, our upcoming GM port injection controller. You can be assured these answers are truthful and accurate as opposed to what you'll find floating around on the internet.
When will it be available?
We had been targeting a release in September of 2024, but unfortunately this may drift into October 2024 depending on how quickly a couple of aspects can be made production ready (mostly the UI and the deployment of the HP Tuners patch).
How much will it cost?
Currently, we anticipate that retail cost will start at $2000. We will offer a dual wideband option for $1500. These widebands are the AFX3 made by ECM, and they utilize CAN data to communicate with the controller. They use a custom configuration to our specifications to run them at very fast update rates along with transmitting diagnostic data to monitor the health and validity of the widebands. We will offer a cheaper wideband option for onboard Bosch sensors which will come at a later time. If you order before implementation is done, you would need to send the controller back to be reflashed at the board level to activate.
I want to get on the list! Can I preorder it?
No, we aren't doing preorders and we are not making a list. This will be first come, first served once we announce the release for sale. Preorders and lists just invite bad attitudes.
How does it work?
We can't quite share the details yet, but we only intercept two physical sensors: the crank sensor and the cam sensor. The only reason we have to intercept these is the update rate of crank position over CAN would be too slow to reliably synchronize the injection events at higher rpm.
So and so already gets info from the CAN network. You aren't doing anything new! Right?...
There is a marked difference between grabbing what's available on the main vehicle CAN bus... and creating your own CAN definitions based on memory variables. Tons of people out there tap into the main CAN bus and grab tons of basics like pedal position, throttle position, ethanol content, wheel speed, etc. We go much further so we can get data nobody else does. We also speed the network up to 160Hz which is twice as fast as the stock CAN networks.
Do I need widebands?
No, you don't need widebands. The system is extremely reliable, and because it is physics based, you aren't going to end up with massive drifts due to operating condition changes like ethanol content or fuel pressure. The controller has built in support for single or dual bank widebands if you want closed loop. In single wideband operation, all eight cylinders are trimmed based off of the wideband feedback. In dual operation, trimming is bank specific. If you opt for widebands, you can log them directly in HP Tuners without a ProLink.
Can I log the controller in HP Tuners?
Yes, the controller is supported in HP Tuners and will show up as a supported device in VCM Scanner. There are a number of parameters you can log. We are working on an in-car expansion device for the OBD2 port that will display data on the dash (we are debating whether we want this to be configurable).
What are you waiting for?!?!
There are a few things that need to happen to bring this product to fruition. It's really easy to just dump a product to market when you repurpose somebody else's architecture, software environment, and hardware. To do something truly right required doing every part of this from scratch.
Patent Application - This is the primary reason we can't talk about how it works in any useful detail. Once the US Patent Office confirms our application, we can begin to decipher just how and why our system is as sophisticated as we have eluded to.
Board Manufacturing - We've been tweaking some bits on the board, and we only do small runs at a time. We're waiting to submit a large production order until we know that a board doesn't need manual modifications after assembly.
GUI Completion - The controller relies on a web page interface to access, update, and edit anything. It will create it's own wifi network, and once you log in, you will do everything through a web page. Development of this couldn't happen until after the core firmware for control was complete. The board has two processors that each fulfill a job; one for the web interface and one for the actual control. Getting the two to communicate in real time as well as allowing one to reflash the other has been time consuming. This is one of those pitfalls of not operating in somebody else's software environment. We also just wanted complete wireless capability.
HPT Patch Deployment - This is another big one. The controller relies on an operating system patch from HP Tuners. We have been tweaking what this patch does, and we are presently waiting for an update after our latest round of data analysis. Once we give the go ahead, they will have to roll this code change out for every operating system and incorporate it into VCM Editor.
Who is involved? What are they doing?
DSX Tuning is responsible for the concept, integration, coordination, and ultimately the sale and support of the controller. We also manufacture the cases and wire harnesses. This was an idea that was first thought of in 2018, but it took a long time to gain the knowledge and confidence to execute the whole thing.
HP Tuners agreed to work with us to provide an option for deploying a code patch that allows us to modify and enhance the CAN structure in the factory ECU so the ECU can talk to the port controller and give it pertinent information in real time. This eliminated the need for tying into sensors, and this gives us access to far more information than what is available on a standard broadcast stream.
There are three others involved in this endeavor. First, we have the hardware provider who designed the board and has been working with the board house for mass production. Next we have a coder for the ESP32 who is responsible for the web interface, reflashing, and some CAN integration. Last is a firmware developer for the STM32 which is handling the actual control algorithm and the hardcore CAN integration.