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.

Frequently Asked Questions

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 both single and dual widebands as an add-on priced at $500 and $1000 respectively. 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.

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.

There had been a few instances of people discussing swapping gearsets in E92a equipped GM vehicles and being unable to correct rev matching or eliminate errors related to incorrect gear ratios. The tables to correct this behavior exist, but unfortunately were not mapped in the editor aside from one single table that was used for torque multiplication calculations. We located the relevant tables peopled needed and had HP Tuners graciously roll out the addition of these to all E92a operating systems. Update to 5.1.1662 or later for access.

There are two tables labeled Trans Gear Ratios (ECM 20090) and Trans Gear Ratios For Speed Matching (ECM 20265). The first is used for torque calculations while the second is pertinent to the rev matching feature. Set both of these to whatever your new gearset is.

The next tables to edit are Trans Gear Ratios Min/Max (ECM 20261/20262). You can take the easy route here and set the min table to 95% of your new ratios and the max table to 105%, or you can calculate the percentage difference from your original gearset in the tune and apply that difference to the new ratios. The +/- 5% method will be fine, though.

The last table affects clutch slip detection, and this one is important. This table is located under the Transmission -> Diagnostics table and is called Gear N/V Ratio Limit (ECM 20855). For this table, 9th refers to reverse. The factory uses 8% over as the value for second through seventh gear as well as reverse with a much larger value in first gear (your takeoff gear). You can set the first gear ratio to ~50% over whatever your actual gear ratio is and set the rest to 8% over, or you can use the same method of calculating the stock ratio and applying to your new gearset ratios.

Enjoy!

GM has advanced their fuel pump control over the years for the better, moving away from relying on a traditional mechanical regulator to control pressure and making environmental assumptions about operating conditions. Lucky for us, newer vehicles all use an actual fuel pressure sensor now so the ECM can calculate effective injector pressure in real time. If you're already lost, I'd suggest heading back to the archive and finding the "Fuel Pressure Explained" entry.

Unfortunately, there's no shortage of misinformation/assumptions/confusion about how GM handles this control. This article aims to de-mystify the process in the hopes that tuners out there (yes, you, even though you don't want to admit you didn't know this) can properly get everything working.

We will start with the basics which begins with the communication between the ECM and the FSCM (newer vehicles don't even have a FSCM anymore but rather a slave pump driver, and the FSCM logic has been moved into the ECM itself). These modules communicate over CAN (a whole other topic) to transmit data back and forth. For what we are concerned with, only a few parameters really matter. The ECM transmits to the FSCM two important values which are fuel flow rate and requested pressure. The FSCM, in response, sends back gauge fuel pressure (there's a catch to this... the FSCM measures absolute pressure, not gauge, and uses barometric pressure received over CAN to convert to gauge pressure). The ECM consequently uses this to then calculate injector delta pressure, and the rest is history.

Now let's break down the information sent from the ECM. We will start with fuel flow rate. This is a calculation based on the ECM's air flow measurement/calculation as well as commanded air/fuel ratio. This value is important because the ECM uses it to determine which fuel mode to operate in (Low Flow, Normal Flow, or High Flow). It also serves as a starting point for the FSCM's feed forward control of pump duty cycle, aka how hard to drive the pump before the trimming loop fine tunes it. For reference, this is table [FSCM] 6997 in the FSCM calibration.

The next important piece of information that the ECM sends to the FSCM is the requested fuel pressure. These values are completely based on the current operating mode for fuel flow, so it would be wise to educate yourself on how low/normal/high are triggered based on fuel flow rate! This value also happens to be the other base component of the feed forward table for the base pump duty cycle. For those with a DSX C7 aux pump, special attention should be paid here because this is how the CAN controller determines when to activate the aux pump. If you're savvy enough to play with flow modes, you can activate the aux pump at the perfect point when the stock in-tank pump begins to fall off.

The FSCM now has all the information it needs, and all it has to do is run the pump and send back pressure, right? Close. Reading and reporting pressure is pretty basic, so we won't dwell on that too much. Instead, we are going to consider a couple of specific tables that the FSCM uses for its own sanity check before it really decides what to do with the fuel pump.

The most important table that is almost always neglected by the less informed is [FSCM] 6994 - Maximum Desired Pressure. For a few vehicles (namely fifth gen Camaros and the SS Sedans), this table is crippling when trying to use an aux pump if it is not addressed. No matter what you do, the FSCM is going to fight to drop fuel pressure even if you're asking for 500kPa... unless you raise this table. When the FSCM gets a request for the ECM, the first thing it does is check against this table, and if this table has a lower value, it will trump the ECM request. As a followup to this table, [FSCM] 6995 - Regulation Pressure should be raised as well for good measure. Once you fix these, you'll notice that suddenly you can actually reach the pressure you're asking for. As a rule of thumb, DSX Tuning does not recommend raising these tables beyond 600kPa (and we don't recommend requesting more than 500kPa of pressure as the pumps just don't like to operate there except for C6 ZR1 brushless pumps).

There's a lesser known table that can also impact how the fuel pressure responds to an aux pump kicking on. A lot of people will notice a huge over correction as the FSCM tries to bring fuel pressure down to where it should be. It will undershoot, then come back up. You can compensate for this with [FSCM] 6999 - Minimum Fuel Pump DC. This table takes some playing with, and we don't have a set recommendation for where to end up. Sometimes you need to do the heavy lifting yourself.

As far as DTCs are concerned, the big one to disable is P2635. This is considered a nuisance code, though there is a common misconception about what triggers it. It is not based on actual pressure vs expected pressure but rather actual pump duty cycle vs expected pump duty cycle. With an aux pump, the FSCM has no idea that some extra source of fuel supply exists, so this code can trigger. We recommend simply setting it to No Error Reported.

If you made it this far, congratulations... you should now be equipped to properly make a GM active fuel system comply with your expectations.

We also have a template for HPT available that will set the fuel pump settings to the way they need to be simply by running it. Please note that the applicator will have an error because it contains everything for both ZR1 and non-ZR1 which means one application won't have the same value as another. Ignore the error. Download here.