Thrashing Stinks

I’m continually amazed at the tunnel vision found in the engineers who create aftermarket engine management systems. I’m not saying they lack talent or are unskilled in their field at all, but the state of the art for EMSes (Engine Management Systems) is grossly behind the times. I’m not sure why. I decided to create a list of things I feel could greatly be improved, are lacking completely, or simply don’t make sense to me at all.

I encourage any of you reading this to comment if you have something insightful to offer. Please correct me where I am wrong, inform me of existing products that have a feature I’ve listed, explain why my idea(s) simply cannot possibly work, tell me I am ignorant and explain why, and by all means pat me on the back if you found this to be an interesting article.

I assume the reader has exposure to aftermarket engine management systems. I am not going to explain what an EMS is or what Air to Fuel Ratio are, for instance. I still encourage unsavvy readers to check out what I have to say.

Why is the EMS world the way it is?: A guess.

I said in the introduction, “I’m not sure why.” That doesn’t mean I have no theories.

Low Volume: Any car model-specific EMS is relegated to a very low sales volume. The company can either jack up the price to compensate or leave out a lot of functionality in order to get a product out the door (small number of staff, possibly 3 people).

Wheel Reinvention: Every EMS I am aware of was a project started from scratch. It is possible that is how it needs to be, but it contributes to the currently lagging state of the art in EMS products. The smart companies with more resources at least create a product (from scratch) that can be reused in many applications with some in-house tweaking (AEM comes to mind, scroll far down to Electronics).

Inertia: The downside to the “one adaptable piece of hardware, many car applications” approach is product intertia and stagnation. So much has been invested in the product’s bug-fix evolution and adaptation to many platforms that change of any sort becomes a negative thought.

Lack of Task-Specific Talent: Jim the hardware engineer shouldn’t be writing the user manual, performing quality assurance testing, designing the user interface, nor handling sales calls. Find the resources to allow each person to do his or her job with excellence and focus. Without it, every piece of the product suffers. The majority of EMS user interfaces are pretty bad and clearly not designed by someone with years of experience in that area. The overwhelming majority of EMS manuals are atrocious due to being written by people with no writing skills nor perspective (lacking 100ft view). No EMS should ever be released to market without a comprehensive and well-crafted manual.

Lack of Vision: It’s as if EMS development teams have zero creativity at all. Why are you not developing a product that every competitor is jealous of? Innovate. The world doesn’t need another tired EMS design with nothing new brought to the table. I’m almost convinced at this point that the same 10 people have made every EMS package on the planet.

Competition: See above — The world doesn’t need another tired EMS design with nothing new brought to the table. Yet they keep getting churned out. More competition is needed to light fires under asses.

Serial Ports vs. USB or IEEE1394/FireWire

It’s been years since a serial port was common on every laptop. It seems to me that if USB-to-serial adapters exist the technology is readily available to include USB directly into the EMS, yet I am not aware of a single one that offers anything other than a serial port.

“Use a USB to serial adapter.” is the support group response. Unfortunately, very few work properly with EMSes for some reason.

“Buy a PCMCIA serial adapter card if the USB ones don’t work.” or “Buy an old laptop off eBay that has a serial port.”

Basically, this is the (hands over ears), “LA LA LA LA I can’t hear you” approach.

I’m ignorant here, but apparently it is impossible rocket science to make data transfer or stream over a USB cable instead of a serial cable. Nobody at any EMS company knows how to do it, yet there are many USB data acquisition units available with ridiculously high sampling rates.

Firewire? Sure, anything but a serial port I can’t get on almost any laptop anymore.

Platform-Specific Interface Software: Why?

I’m not one of the many tens of thousands who bought a Mac in the last 2 years, but I’d be pissed off if I did.

Do you really have any need to make your user interface software 100% locked to a particular operating system? There are cross-platform interface frameworks that include everything you could possible need for an EMS UI, usually including 2D graphing widgets and 3D wireframe drawing (which any talented software developer could implement on his/her own if they were not present).

Hardcoded Constants

AKA You don’t know what I want better than I do.

For example, when you give the user a segmented RPM range (400,800,1200…) to work with, make RPM points configurable. That is, if there are 8 allowed data entry points between 400RPM and 12000RPM and you don’t let me adjust the 8 RPM points to suit 400-7200RPM, I’m not fond of you. You have crippled your product for my application by needlessly reducing my control granularity.

Gauge Screen

• Always offer an option to display a full screen of gauges with an absolute minimum of (if you have to be lazy and hardcode it): Timing, AFR, RPM, MAP, and perhaps others.
• I should be able to display an on-screen meter for any monitored data stream. Ideally, I should also be able to size any meter on my gauge screen as I see fit.
• The colors of this screen should be configurable (and saveable!)
• Each on-screen gauge should allow a data value threshold to be set for a configurable alarm. The alarm options should be visual (color change or flashing) or audible at a minimum.

This is not a worthwhile gauge offering (left side panel in image) - Hydra EMS product:

This GEMS (also AEM since AEM’s EMS is a GEMS derivative) dash configurator is excellent:

This too is excellent - EcuTek DeltaDash product. Image shows a custom-configured dash display by a user:

Communications Protocol

Publish data transmission protocol specs, folks. You have nothing to gain by keeping this information proprietary and everything to gain by releasing the information (namely 3rd party companies building dash displays and the like).

Data Logging

At a minimum:

• Data items to be logged should be configurable. “All or Nothing” is lame.
• Data logs should be at least exportable as CSV files. Requiring commercial software such as MS Excel is lame.

Data Analysis

Since we’re talking about the Ultimate EMS, it should include data analysis tools. The end user should be able to at least graph data in 2 dimensions with X and Y axis data sources configurable (not just RPM on the X axis).

The EcuTek DeltaDash (OBD-II-based logging and analysis) software gets it right and has had this functionality since 2003 for many Subarus.

That’s all for now, people. I welcome any input and further topics to explore in part 2 where I’ll say my 2 cents on Auto-Tuning Fuel with Closed Loop, Turbocharger Control, User Interface Preferences, Knock Determination, and a few other things.