Tuning... A History

[Power Hungry]

As they say... "Let's start from the beginning." This is something I've wanted to do for a while. Sort of a digital memoir, if you will. Hell, maybe I'll even write a book about it. I doubt it would sell, but it's interesting to keep a record of things so my kids and grandkids can say, "See? He wasn't an abject failure." It's sad, really, that I know so little about my grandparents and only just a bit more about my parents. Maybe we could revive the art of storytelling so that we don't lose ourselves to the sands of time. So let's begin.

Power Hungry Performance - A History of Tuning


Part 1 - Getting Into the Industry (or, Why I Cut My Hair to Work for Superchips)

It's 1997. I'm living in Orlando. I'm tired of breaking my back bent over an engine compartment changing spark plugs. I'm looking for a job that will be not only financially stable, but also challenging. I've looked into different computer-based markets, but I'm not very experienced with PC. I mean, I really understand programming and have experience with reverse engineering, but all I've done professionally on the PC is some FoxPRO RDBMS stuff and some light networking using LANTastic.

Yeah, this nasty a$$ COAX network stuff!


Anyway, I come across an ad in the paper for someone with "strong automotive knowledge as well as a solid computer background." Damn! Sign me up. I schedule an interview, and then head down to this little building on some side road in Longwood, FL. The sign says "Superchips". Never heard of them, but this was about to get interesting. I'm familiar with Hypertach at this point, but didn't know who Superchips was or what they did.

I head in and meet with Mike Short, the Manager of the company. He's an interesting guy. Easy to to talk to, in a way that many managers are not. The kind of guy you'd probably watch a ball game and have a beer with. We chat for a bit with him explaining what Superchips is, what they do, and what they would expect from me. Following this conversation, he introduces me to Craig Ancel, one of the engineers at the company who is going to give me a "test", just to see if I know my a$$ from my elbow. He's also very nice and is easy to talk to, although I'd say he's a little more on the geek side of things. The test goes like this:

Craig: Are you familiar with Hexadecimal?
Me: Yes.

Craig: Okay. We're going to open up a calibration and I need you to see if you can identify any patterns or maps in the data.
Me: Okay, no problem.

At this point, we open up an A9L calibration from a 1988 Ford Mustang. Anyone who has ever done tuning for Ford back in the '90s should be intimately familiar with this one. I've included a few screenshots of what I was looking at. For most folks, this wouldn't make much sense but I was completely comfortable with this.

Sample Screenshot of A9L Mustang Calibration (Click to Enlarge):


Among the jumbled up values, you can see a certain pattern unfolding in the middle of the screen at the 8th row. Setting the base address at this point and then resizing the map yields us the first spark (timing) table. This map is 10 data points wide and 8 data points high (10 x 8).

A9L Timing Table 1 (Click to Enlarge):


There is another spark map immediately following the first one. This one is for higher altitude adjustments.

A9L Timing Table 2 (Click to Enlarge):


And finally, a third spark map with this one being a little different. This is what Ford called a "Mean Best Timing" spark map and was often utilized as a sort of maximum limit for timing advance.

A9L Timing Table 3 (Click to Enlarge):


Moving further down the list, we started looking for fuel tables. These are a stoichiometric type value calculated against an optional Air-Fuel Ratio (AFR) of 14.64 to 1. As load increases, the AFR drops to help improve power output while under light load conditions, the AFR increased to help improve fuel economy.

Sample Screenshot of A9L Mustang Calibration Showing Fuel Table (Click to Enlarge):


A9L Fuel Table 1 (Click to Enlarge):


A9L Fuel Table 2 (Click to Enlarge):


A9L Startup Fuel Adder Table (Click to Enlarge):


As you can see, these are just a small sample of what I was asked to look for. After a few minutes of getting my head around the concepts, I was able to find these and several other maps and functions without any difficulty. Sufficiently satisfied with my capabilities and understanding of what I was looking at, the conversation went like this:

Craig: Wow! We've had several people come in for an interview and you're the first one who actually gets this.
Me:

Anyway, the rest of the interview progressed smoothly. Superchips was confident in my abilities and I was subsequently hired on as a calibration engineer. The only caveat was that I was asked to cut my hair. As Mike Short put it, "We like you and think you'll be a good fit. Just one thing... How do you feel about your hair?" I knew exactly what he was going for and I immediately replied, "If it gets me a job, I'll cut it off tonight!" and did exactly that.

Once hired, it was my responsibility over the next several years to continue calibration development and write custom tuning for our dealers as well as larger companies like Steeda, Vortech, Paxton. You wouldn't believe it, but we actually distributed files using our very own BBS system, which I had the "pleasure" of administrating. Regular activities involved helping to reverse engineer many of the vehicle platforms including the Mustang, Focus, T-Bird, Crown Vic, F-Series Gas, and especially the F-Series Power Stroke. I also worked on some GM stuff at the time, writing tunes for the C/K Series trucks as well as the LT1 and early LS1 platforms found in the Camaro and Corvette. I assisted in the development and implementation of many of the tuning standards still in use by many aftermarket Ford tuners today. Being heavily involved in the development of calibrations for the Ford Power Stroke, I wrote most of the very first tunes to ever hit the street, many of which are still out there in trucks. It still surprised me to see my Copyright footer in files that have been read from chips and PCMs, some of which have been programmed quite recently. As time progressed, I also began writing software, moving our DOS based utilities to Windows applications.

Over the many years I have been in this industry, I have utilized every possible source and avenue of information that I could. Countless hours spent scouring the internet, reading... downloading... archiving... cataloging. It is through these efforts that I have developed an understanding of the Ford EEC-IV and EEC-V Processors that I would say rivals the knowledge of the actual Ford Powertrain Development teams. I've stood on the shoulders of giants, as they say.

It's an interesting (albeit challenging) field working in Reverse Engineering because you not only have to eventually make something that works, but you have to do it almost blindfolded and handcuffed by tearing something apart and then trying to understand why it was put together the way it was. I was (and still am) grateful for any and all help I've received over the years, whether it be little secret tidbits of info that helped provide further insight into the inner workings of the factory calibrations and hardware, or just working with people within the motorsports industry who provided me with opportunities to further my knowledge. This has been a fantastic industry to be a part of, and while I've seen far too many businesses come and go, I've enjoyed the friendships I've made and seeing quality companies that have stood the test of time and are still here with us.

Over time, I've had access to a number of different tools. In the beginning, some where downright archaic and cumbersome. However, as time went by, the tools (both hardware and software) would continue to improve along with our understanding of how these systems worked. This all helped to provide enhanced performance, greater reliability, and improved customer satisfaction. It's fascinating to see where things are at now compared to what was available when I started.

For example, if you really want to see a dinosaur, this is my personal laptop that I've had for just over 20 years that I've used for tuning and development.

Toshiba Laptop (Click to Enlarge):


Toshiba Laptop... STILL running with MAP6 Editor open! (Click to Enlarge):


Combined with a Memory Emulator, these made for an EXTREMELY powerful tool.

RACELOGIC and Romulator Memory Emulators (Click to Enlarge):


The Racelogic emulator in the above picture allowed us to not only live tune a vehicle (making changes while the vehicle was running), but also included and active ROM-Watch which allowed us to see *in real time* exactly what memory the PCM was accessing at any given moment. Using this, we were able to locate which maps, functions, and parameters were being accessed as well as under which conditions (cold, warm, light load, heavy load, startup, etc.) they were being accessed. You could actually watch the markers move through a map or function as you accelerated or decelerated, and this was exceptionally important to creating an understanding of how the PCM functioned.

In 1997, these were the tools of the trade and they were EXPENSIVE. The RACELOGIC emulator was going for about $2500 at the time (if I remember correctly) and laptops were still regularly over $1000. The PCM adapters for the emulators were just modified chips, but unless you worked in the industry, you were very hard pressed to come by one as all the chips of that era were potted in resin and you had to nearly destroy them to uncover the circuit boards. Still, it was possible for someone outside the industry to build this type of setup if they were really serious about tuning. Having worked for Superchips, all this stuff was readily at hand so if something died, we'd just make more.

Nowadays, laptops are 1/3 the price and 20 times more powerful. What we used to do in DOS (no multitasking here, folks) we now do in Windows. Networking is wireless. I even remember the first time I had a drive that broke the 1 GB barrier. There is now an almost endless supply of development tools at our disposal. Our "server", which at one time was nothing more that a Pentium II - 233 with a 4 GB Hard Drive running Windows NT SBS, has evolved into a massive, 20 TB rack mount sever that lives in its own climate controlled room along with redundant Linux servers to not only handle our development data, but to also handle file distribution and many other services.

Power Hungry Servers (Click to Enlarge):


Anyway, this is just the first step along an incredible journey in which I have been so fortunate to have been a part of. I hope you have found this to be interesting and informative. In upcoming posts, I will be writing more about my time at Superchips, the years where I started and ran Diesel Power, the years I spent working for Edge, and then ultimately forming Power Hungry Performance and reinventing the best selling Power Stroke chip on the market, the Hydra! And if you have any questions, please feel free to ask.

Until next time... Keep the shiny side up.

[cleatus12r]

Keep on going, man!

[1023vaughn]

I hope slightly off topic replies are allowed.

Nowadays, laptops are 1/3 the price and 20 times more powerful. What we used to do in DOS (no multitasking here, folks) we now do in Windows. Networking is wireless. I even remember the first time I had a drive that broke the 1 GB barrier. There is now an almost endless supply of development tools at our disposal. Our "server", which at one time was nothing more that a Pentium II - 233 with a 4 GB Hard Drive running Windows NT SBS, has evolved into a massive, 20 TB rack mount sever that lives in its own climate controlled room along with redundant Linux servers to not only handle our development data, but to also handle file distribution and many other services.

Power Hungry Servers (Click to Enlarge):

I just wanted to share a bit from my old home lab before covid changed everything. This is a few years (4-5) after I started collecting junk PCs and retired enterprise:
Early Gear

Nearly final iteration
Front: (Right before it was retired and gear was getting migrated)
Last front 2019
Front 2018
Back (a year or so before the front image hardware)
Back of rack

Lastly I noticed some familiar faces
UPS and PDU

This gear is used solely for my educational purposes, development and speeding up my work day. It contains only about 15-20% my own scratch built software, and is used heavily for helping me develop better tools for work-flow, some new 1023 software and tools, and lots of security tools. The base is a 3-node windows Hyper-V fail-over cluster, with 2 redundant flash based v-sans (also windows based) and 2 redundant storage nodes (windows). 2+1 on/off site redundant storage with windows DFS etc. Lots of VMs, some include Windows and Linux Kernel dev, full stack web dev, databases and redundancy, pbx, email, game servers. I built my own email services from on old Hmail fork. Scratch dns, dhcp, http proxy, e2e messaging, "real-time" distributed filesystem replication (early stages), custom win service handlers for managing other software, in win32 and .NET and plenty GCC. Alot more that were based off other builds or libraries but its been a couple years since I needed to touch them. Home automation, security, remote tools, vpn, and probably 3-4 other vms I forget what they do and tons of other vms and software. At one point it was supporting nearly 150 devices and 1g/1g fiber which I dearly miss.

BTW Talking pricing and memory, raw storage in that rack is just over 100TB total, just under 1TB of DDR3 and just under 200 CPU cores just in that image. Living in northern VA at the time its mostly made from retired US government gear.

I have a bunch more modern gear coming in with new nodes to replace the old gear. I had to run 3 20amp circuits to that rack and each one of those R910s could easily pull over 1200VA from the wall, and the power bill was getting to expensive . Lots of 10g gear and can't wait to get the rack back up and get my whole lab back in order.

Over the many years I have been in this industry, I have utilized every possible source and avenue of information that I could. Countless hours spent scouring the internet, reading... downloading... archiving... cataloging.

I'm sure I have a good 20-30gb of archived data automotive and EEC.


To ask an on-topic question what was your original process of moving from "yeah that's a table" to "This is base ignition timing" starting out? I'm just curious at a high level how the work-flow started say at "SCT"? (We don't need to talk about disassembly etc)

Did you jump right into hardware "hacking" or was it more organized?

[Power Hungry]

Originally Posted by 1023vaughn

This gear is used solely for my educational purposes, development and speeding up my work day. It contains only about 15-20% my own scratch built software, and is used heavily for helping me develop better tools for work-flow, some new 1023 software and tools, and lots of security tools. The base is a 3-node windows Hyper-V fail-over cluster, with 2 redundant flash based v-sans (also windows based) and 2 redundant storage nodes (windows). 2+1 on/off site redundant storage with windows DFS etc. Lots of VMs, some include Windows and Linux Kernel dev, full stack web dev, databases and redundancy, pbx, email, game servers. I built my own email services from on old Hmail fork. Scratch dns, dhcp, http proxy, e2e messaging, "real-time" distributed filesystem replication (early stages), custom win service handlers for managing other software, in win32 and .NET and plenty GCC. Alot more that were based off other builds or libraries but its been a couple years since I needed to touch them. Home automation, security, remote tools, vpn, and probably 3-4 other vms I forget what they do and tons of other vms and software. At one point it was supporting nearly 150 devices and 1g/1g fiber which I dearly miss.

BTW Talking pricing and memory, raw storage in that rack is just over 100TB total, just under 1TB of DDR3 and just under 200 CPU cores just in that image. Living in northern VA at the time its mostly made from retired US government gear.

I have a bunch more modern gear coming in with new nodes to replace the old gear. I had to run 3 20amp circuits to that rack and each one of those R910s could easily pull over 1200VA from the wall, and the power bill was getting to expensive . Lots of 10g gear and can't wait to get the rack back up and get my whole lab back in order.

That is a really sexy setup.

It cool that it's built from retired units. I bet that saved a ton of money because to build that from scratch would be prohibitively expensive! All the stuff in our server rack is now new stuff, replaced and added to over the years as needed. I've debated dumping the Windows install on the 1 server and just migrating it to Linux, but it works well, never crashes, and I just don't feel like messing with it right now. The other 2 full stack Linux servers are great, with one being a redundant mirror of the main Linux server. They never give me a fuss and will run for years without ever needing a reboot. I'm really enjoying learning my way around Linux.

Originally Posted by 1023vaughn

I'm sure I have a good 20-30gb of archived data automotive and EEC.

Anything you want to throw on a drive and send my way?

Originally Posted by 1023vaughn

To ask an on-topic question what was your original process of moving from "yeah that's a table" to "This is base ignition timing" starting out? I'm just curious at a high level how the work-flow started say at "SCT"? (We don't need to talk about disassembly etc)

Did you jump right into hardware "hacking" or was it more organized?

Organized? Not a chance.

So, when I started at Superchips (not SCT... That is something entirely different) they were doing mostly gas tuning and just barely getting started on the Power Stroke. From a Ford aspect, it was basically Mustangs, Cougars, T-Birds, F-Series gassers, and the like. They did GM and Dodge as well, but I didn't do much GM and I didn't do any Dodge.

Anyway, as sad as this may sound, they only thing we were changing in the files in 1997 was timing, open loop fuel, and standard shift points. Rev and Speed limiters as well, if we could find them. But to be honest, that's still all that's really needed to make a decent tune nowadays and I find it interesting how much stuff can be changed unnecessarily with no real improvement in performance.

As I started working on breaking down calibrations even further, we started doing some really... um... "interesting" stuff. We would acquire a vehicle by putting ads on the website offering a free chip for anyone willing to let us test and tune on the dyno. We'd then get the vehicle strapped down and get the emulator plugged into the J3 port. We'd load the file for the vehicle, fire it up and start driving. All of this seems pretty ordinary, right? Yeah, well hold onto your hat. This is where it gets interesting.

While we're running the vehicle, we've got an NGS Scanner and a wideband hooked up to the exhaust. We're doing runs and checking to see how much a change to the timing table makes by flattening the table and then adding or subtracting values to the table. "Oh, look! Every HEX point is 1/2 Deg. of advance." We do the same thing with fuel tables to see how much AFR gets adjusted by adding and subtracting values to those tables. On to Shifts and Limiters. It's all seems pretty sane, until...

We started asking things like, "Where is the Traction Control?" or, "How do we firm up the shifts?" Of course, we don't know where any of that stuff is. We have to find it. Now if you remember, the emulator and software we used had live ROM-Watch so we could see what the PCM is accessing from memory. I'd be sitting in the passenger seat with a laptop running the emulator. Pat Stadjel (one of two other calibration engineers Superchips) would be in the driver's seat with the NGS. So we start going through memory looking for active points and then we'd either "00"them, "FF" them, or just start adding or subtracting values and see what happens. I mean, what could go wrong, Right? Fortunately, we had an "Undo" so that if we made a change that was unhappy we could revert right back to the previous values. In most cases, the worst that would happen was that the vehicle would stall, we'd drop to neutral, and then just fire it back up. The gas stuff was pretty forgiving like that since the throttles were still cable controlled and the chance of a runaway was basically non-existent. I'd make a change, Pat would hit the gas, and we'd see what the comes up on the dyno. Funzies!

Truth be told, this process, while sounding scary as hell on the surface, really worked quite well. We were able to determine things like global modifiers, PATS switches, WOT Shift RPMs, MAF tables, WOT Multipliers, Injector Flow Rates, and a bunch of other things. To date, I'm not aware of anyone experiencing any damage to their drivetrain except for maybe the loss of a bit of tread on the tires.

Having made great strides in calibration development by this point, Superchips' head engineer Steve Madole decided that I would be the guy that would head up the 7.3L calibration development. He handed me a disk with some base files on it, some very minimal documentation on a couple maps that they thought might be fuel tables, and told me to get on it.

Moving into the Power Stroke realm was something entirely different. Right off the bat, this my our first experience with dealing with a large number of 16 Bit values as most of the gas stuff at that time was still only using 8 Bit for the bulk of the stuff we were modifying. PW Modifier tables, SOI Offset tables, and a number of other things were 16 Bit and dealing with that stupid Intel "Little Endian" crap was a hard thing to wrap my head around. Especially since I was using an 8 Bit editor that didn't translate well into 16 Bit.

Forging ahead with the same "Search and Destroy" techniques I'd used on the gassers, zeroing, adding, or subtracting from values and table to see what changed, I'd occasionally get a runaway situation (basically full throttle) but that was easily remedied with the "Undo" function. Again, I had pretty good success with what we found. Enough so that Superchips "gold chip" quickly became the number one selling chip for the Power Stroke for well over 6 years. It's one of those things that I've always been proud of, even if it was only behind the scenes.

Now keep in mind that when I went into this, I still had NO IDEA what a Normalizer function was. I was going on the assumption that the X and Y axis on a table was static (much like the way GM does their tables. It was quite by accident that I found out when I changed a specific function on a Mustang, the timing curve quit changing. When I went and looked back at the timing table, I saw that the ROM-Watch was no longer jumping around the screen. This revelation completely changed my fundamental understanding of the EEC-IV/V PCMs and changed the way I tuned. I still had to go back into the older stuff (meaning we needed more test vehicles) and figure out which Normalizers went to which axis of which table. This was a pain, to say the least, but it at least gave us the ability to provide a considerable improvement over any earlier tuning we'd created. We were now able to control tables into much higher Load and RPM ranges (say, for a supercharged application) so that we had better resolution where we needed it. It really was quite a leap from where we were before.

Diesel tuning at the time was pretty straightforward. We had no problems making power. Where we had problems was getting rid of those annoying DTCs for stuff like Overboost and MAP Out of Range errors. It took a while to hunt those down, and even then we still didn't have a really good way to eliminate them so Superchips would include a "boost fooler" with every chip. This consisted of a 1/8" brass tube with a hole drilled in it which would be placed inline with the MAP sensor to keep it from seeing accurate boost. Sketchy, I know. But it worked.

This was how much of the tuning I did was handled in the late '90s. It was hard hacked. No decompilers or anything like that. Understanding Binary Shifts, realizing the way Strategy structures broke down into specific groups, understanding Hardware IDs, and even things like figuring out how to checksum the files to prevent P0605 code I had to figure out on my own. It was certainly a challenge, to say the least.

It wasn't until late '98 or early '99 that we got blessed with some actual documentation from a calibration disassembly. This was in the form of a 1992 T-Bird ROM Dump from the compiler.

CCAM0 ROM Listing Sample Page (click to enlarge)


Binary File Search for Gear Ratio 1 (click to enlarge)


Utilizing a search of existing binary files, we were able to locate something fairly unique in the file within a specific address range, and as such we were able to identify a file which was very close to the one that was related specifically to the documentation. As we didn't have any CCAM0xx based files, the nearest files were CCAQ0xx (X4Z1, X4Z2, etc.) calibrations that very nearly matched the documentation. They were only 20 (0x14) bytes off from the CCAM0xx file, and this shift could be easily identified by browsing through the binary and finding where it diverged from the source. This opened up a whole new world for us as we were now able to better understand the binary shifts, normalizers, modifiers, and many other components of the calibration modeling. Of course, this meant going back and redoing a number of gas calibrations as we now could look for new things based on binary file comparisons between our sample base and our working files. This also helped us to learn more about the naming conventions Ford used for the parameters, maps, and functions. Knowledge which carried us through the later gas and diesel applications.

This is how it went, and I honestly think that the experience helped to make me a better engineer. I was forced to problem solve. I was forced to work in HEX. I was forced to figure it out on my own, and only after I had a pretty solid understanding of what I was looking at did we receive any outside help. I'm grateful for that experience. It was an exciting time to be on the forefront of the tuning industry and being on of the people that was making things happen. It was something I took pride in and it was very personal to me.

I'm sure you realize, how tuning has changed over the years. HEX gave way to 3D Graphs. 8 and 16 Bit binaries progressed into 32 Bit Float values. OBD-II flash replaced the infamous J3 port. However, chips are still a solid market because the Power Stroke 7.3L simply will not die. It has a following that rivals many of the iconic vehicles of yesteryear. Mustangs... Camaros... Corvettes... Stuff like that. It is now 25 years after the first Power Stroke 7.3L hit the street and 17 years after the last one was sold, and they're still highly sought after by fans and enthusiasts.

I've been in this industry 23 years and I can't think of anything else I'd rather be doing. I love the challenges of discovering new things, creating new things, and helping to support an industry that is very near and dear to me.

Anyway, I hope this helps you to understand just how bass-ackwards things were in the beginning. If I hadn't been there, I wouldn't have believed it.

[1023vaughn]

That is a really sexy setup.

It cool that it's built from retired units. I bet that saved a ton of money because to build that from scratch would be prohibitively expensive! All the stuff in our server rack is now new stuff, replaced and added to over the years as needed. I've debated dumping the Windows install on the 1 server and just migrating it to Linux, but it works well, never crashes, and I just don't feel like messing with it right now. The other 2 full stack Linux servers are great, with one being a redundant mirror of the main Linux server. They never give me a fuss and will run for years without ever needing a reboot. I'm really enjoying learning my way around Linux.

Thank you. Its as long way from what I want and came a long way from where it started. I have built that entire equipment stack in the reverse order Linux hypervisors and windows VMs, for tons of reasons with my windows network I bit the bullet and when Hyper-v FC and built in that redundancy. To be fair though just the base OSs would be valued at about $200k last I did the numbers based on that hardware, so not really a production option as I got my keys through University . At the peak of the operation I could obtain 100% uptime even with in place Windows updates with CA updates and vms not miss a beat. But with used/old hardware you get the downtime of when one of your 64 main memory modules in a machine needs to be re-seated or just dies. But such is the home-lab life.

Anything you want to throw on a drive and send my way?

Possibly, but I wouldn't expect its anything you haven't already seen or been responsible for in one form or another.

As I started working on breaking down calibrations even further, we started doing some really... um... "interesting" stuff. We would acquire a vehicle by putting ads on the website offering a free chip for anyone willing to let us test and tune on the dyno. We'd then get the vehicle strapped down and get the emulator plugged into the J3 port. We'd load the file for the vehicle, fire it up and start driving. All of this seems pretty ordinary, right? Yeah, well hold onto your hat. This is where it gets interesting.

This is probably one of the coolest methods I have heard of and nowadays never have the ability to do in this market and be respected

Anyway, as sad as this may sound, they only thing we were changing in the files in 1997 was timing, open loop fuel, and standard shift points. Rev and Speed limiters as well, if we could find them. But to be honest, that's still all that's really needed to make a decent tune nowadays and I find it interesting how much stuff can be changed unnecessarily with no real improvement in performance.

Not sad, innovative lol. Over the years I have been humbled by this idea in a general sense. What really needs to be done to make a good running vehicle and make a customer happy.

Now keep in mind that when I went into this, I still had NO IDEA what a Normalizer function was. I was going on the assumption that the X and Y axis on a table was static (much like the way GM does their tables. It was quite by accident that I found out when I changed a specific function on a Mustang, the timing curve quit changing. When I went and looked back at the timing table, I saw that the ROM-Watch was no longer jumping around the screen. This revelation completely changed my fundamental understanding of the EEC-IV/V PCMs and changed the way I tuned. I still had to go back into the older stuff (meaning we needed more test vehicles) and figure out which Normalizers went to which axis of which table. This was a pain, to say the least, but it at least gave us the ability to provide a considerable improvement over any earlier tuning we'd created. We were now able to control tables into much higher Load and RPM ranges (say, for a supercharged application) so that we had better resolution where we needed it. It really was quite a leap from where we were before.

Aside from Scalars, EEC FN's have definitely taken me the most time to wrap my head around. I have notebooks of hand traced EEC assembly and lots of time spend understanding FN's and lookups. Scalars seem to come rather easy for me when looked up in code context, otherwise nearly impossible to understand. (All mostly because I have little motivation, and I'm too cheap to do it the hardware/real way)

so Superchips would include a "boost fooler" with every chip. This consisted of a 1/8" brass tube with a hole drilled in it which would be placed inline with the MAP sensor to keep it from seeing accurate boost. Sketchy, I know. But it worked.

By far what I spend most of my day diagnosing, MAP and MAP related devices.

This was how much of the tuning I did was handled in the late '90s. It was hard hacked. No decompilers or anything like that. Understanding Binary Shifts, realizing the way Strategy structures broke down into specific groups, understanding Hardware IDs, and even things like figuring out how to checksum the files to prevent P0605 code I had to figure out on my own. It was certainly a challenge, to say the least.

Yeah... Without a doubt I'm blessed to live in this information age.

This is how it went, and I honestly think that the experience helped to make me a better engineer. I was forced to problem solve. I was forced to work in HEX. I was forced to figure it out on my own, and only after I had a pretty solid understanding of what I was looking at did we receive any outside help. I'm grateful for that experience. It was an exciting time to be on the forefront of the tuning industry and being on of the people that was making things happen. It was something I took pride in and it was very personal to me.

This doesn't go unappreciated (I'm sure by a lot of people).

I'm sure you realize, how tuning has changed over the years. HEX gave way to 3D Graphs. 8 and 16 Bit binaries progressed into 32 Bit Float values. OBD-II flash replaced the infamous J3 port. However, chips are still a solid market because the Power Stroke 7.3L simply will not die. It has a following that rivals many of the iconic vehicles of yesteryear. Mustangs... Camaros... Corvettes... Stuff like that. It is now 25 years after the first Power Stroke 7.3L hit the street and 17 years after the last one was sold, and they're still highly sought after by fans and enthusiasts.

I've been in this industry 23 years and I can't think of anything else I'd rather be doing. I love the challenges of discovering new things, creating new things, and helping to support an industry that is very near and dear to me.

Anyway, I hope this helps you to understand just how bass-ackwards things were in the beginning. If I hadn't been there, I wouldn't have believed it.

Your products and so much more have helped keep my lights on, my EDU bills paid up, and funded lots of projects like the ones above. Not to mention all of the knowledge and experience I have now. I know its a privilege to spend 5-8 hrs/day in Minotaur producing 100+ of files per day, and really everything else I play with is purely for educational purposes. Some weeks tuning about 100 new Hydra chips per week. I'm still shocked every day by the growing number of just 7.3s we deal with.

Thank you also for entertaining my questions, and I hope it built the thread for others.

[1023vaughn]

Originally Posted by Power Hungry

CCAM0 ROM Listing Sample Page (click to enlarge)


Binary File Search for Gear Ratio 1 (click to enlarge)

:

Now I can't stop thinking about how fast defintions could be knocked out knowing information like this The gears are turning.

[cleatus12r]

Originally Posted by PowerHungry

In upcoming posts, I will be writing more about my time at Superchips, the years where I started and ran Diesel Power, the years I spent working for Edge, and then ultimately forming Power Hungry Performance

A few years ago I found an online resource where I was able to download a whole bunch of calibrations - many are "Modifications Copyright Diesel Power 2003". I couldn't tell you where it is now or if it still exists but I find it troubling how that stuff gets out there.