Ferrari 550M Emtron KV12

It has been a while since I made a lengthy post about Engine Management Solutions.  

I recently finished an engine management install on John Tirell’s Ferrari 550.  John owns and operates Independent Ferrari Service in Easton MA.  The car had an outdated, and arguably obsolete ECU system installed in it already.  After discussing ultimately what they wanted to do with the car, it was clear it needed to be upgraded.  The key selling point being ECU/electronics support which Pavlotech professionally provides.  

Those who work on the Ferrari brand know that basically everything is doubled.  Two ECUs, two crank sensors, two cam sensors, two intake manifolds, two of everything….  The original installation mimicked the factory mentality (there were two ECUs), but added complicated regarding diagnostics, calibration, data logging, and more.  We replaced these with one Emtron KV12 unit.  

This seemed like an easy solution since the Emtron KV12 can drive 12 cylinders sequentially, but the setup was more involved than normal.  The V12 in this car has an odd V angle, so the firing angles were non-conventional.  There are “two” of many sensors such as TPS and MAP.  Luckily the Emtron allows you to assign these runtimes since it is capable of running more complicated systems like electric throttles (up to four synced electronically), multiple manifold pressure sensors, multiple mass air flow sensors, and more.  To keep with the “dual” engine mentality, the Emtron also has a built in bank trim function as well.  This package really shows off how flexible the Emtron ECU setup is.  

Once the “ABCs” (as John says often) were worked out, which included full fuel system characterization, the engine was running great and ready for surprisingly painless calibration!  

Everytime I use this ECU on any car, it is mind blowing.  Every time I put it on a “special” application.  It just kills it.  This install was no exception.  I calibrated the car on a hot dyno with minimal airflow with great success.  The next week the car was tested at Thompson Speedway to validate everything.

Validate we did as the car ran flawlessly all day.  The temps were much cooler than in the dyno and the calibration required NO adjustment whatsoever.   I can’t praise how well the charge temperature function of the Emtron works regarding compensating the fuel model.  Over and over all day, the car laid down perfect, safe, and completely repeatable results.  3 gears through the front straight basically dead on mixture (even with transients).  Zero fuel correction.  Part throttle conditions spot on.  Accel and decel fueling right on the money.  The car even ran low on fuel at one point, and it compensated for fuel starvation automatically via the fuel pressure differential calculation instantly.  This method provides instantaneous correction instead of waiting for closed loop lambda to compensate (if used).  

Additionally a completely new Motec CDL3 Dash Configuration was written to completely utilize the new complex data sets the Emtron now provides.  Multiple auto switching dash pages are enabled (warmup, race, practice) with massive amounts of live data available in the line sections for quick and easy diagnosis.  A comprehensive alarm strategy was also developed for a number of things.  On top of this Pavlotech also provided customized workspaces for I2, cloud file sharing, remote analysis, and more for the car/team.   

Besides all that, I have to say part of this project’s success has to go to John’s team/crew.  From my understanding using this car has been a long time coming.  No part of this car has been untouched by him and his team.  The normal expectations of “shaking” down a car on its first event were quite the opposite.  All that was needed was refueling!

Since then, John and his team have been using the car as often as possible.  Smashing super fast lap times at Ferrari nationals at Mid-Ohio, Limerock, and Watkins Glen!  

Thompson flyby

Mid Ohio Ferrari Nationals

Fuel Pressure Compensation

An injector flow rating is accompanied by a static fuel pressure value.  This may look something like 500ccs@43.5psi (300kpa).  This means the injector is rated for that flow at 43.5psi.  If you raise or lower the pressure then the flow will change.  There are some online calculators that can help you estimate the fuel flow – but generally if you want to run a different pressure you should have the fuel injector re-tested.  

Many ask what is fuel pressure differential measurement?  It is the measurement of the effective pressure.  Not only is it one of the most misunderstood functions of a properly functioning fuel system, but also seems to be disregarded, overlooked, or ignored frequently.  Essentially you want your fuel pressure differential to stay the same no matter what is happening so that your EFI system can properly estimate the fuel flow.  Maintaining the fuel pressure differential ensures the fuel flow stays the same.  This is true for boosted applications especially.  

The following are important :

Fuel Pressure – The raw measurement of rail pressure

Fuel Pressure Differential – The live effective pressure (should stay close to the fuel pressure spec to maintain flow)

Differential Fuel Pressure Offset – The amount the Fuel Pressure Differential changes (either positive or negative)

You must remember that when there is pressure inside the intake manifold, the fuel injection system must overcome the pressure to inject fuel into the engine at the specified flow.  This means that fuel pressure must rise with the intake manifold pressure to maintain specified flow.

Here is an example that explains what happens in a boosted engine without a rising rate fuel system (returnless).

500ccs@43.5psi injector rating

Static fuel pressure is set at 43.5psi

Intake manifold pressure = 20psi

Actual fuel pressure = 43.5psi

Fuel pressure differential = 23.5psi

Differential fuel pressure offset = -20psi

Actual fuel flow = 280ccs@23.5psi (estimated)


Fuel Pressure = 43.5psi—>>><<<— 20psi = MAP

Fuel Pressure Differential  = 23.5psi

Theoretically the injector would be flowing almost 50% less fuel than it is rated for in this situation!

Imagine what kind of spray pattern the injection system is producing with the fuel pressure that low.  How about how much it affects atomization/evaporation?  Also, the injector latency is affected by fuel pressure as well (similar to battery voltage compensation).  

Now a properly functioning rising rate fuel system.

500ccs@43.5psi injector rating

Static fuel pressure is set at 43.5psi

Intake manifold pressure = 20psi

Actual fuel pressure = 63psi

Fuel pressure differential = 43psi

Differential fuel pressure offset = 0.5psi

Actual fuel flow = 490ccs@43psi (estimated)


Fuel Pressure = 63.0psi—>>><<<— 20psi = MAP

Fuel Pressure Differential = 43psi

I added in -0.5psi of differential fuel pressure offset on purpose to demonstrate that is never perfect.  Some regulators work better than others though.  

Here is a plot of a rising rate fuel system functioning properly.  


This car had static pressure set at 300kpa (43.5psi), and was regulating manifold boost pressure at +200kpa.  The fuel pressure rose about 215kpa as you an see (subtract the static).  This makes the differential fuel pressure offset +15kpa (it is actually rising more than it should slightly).  If you look at the Diff Fuel Pressure reading (red in third column – Fuel Differential Pressure), you can see how flat this is.  This is showing the effective pressure is maintained, and therefore the fuel flow.  

Many modern cars come with returnless non-vacuum referenced fuel pressure regulated systems now.  This is for packaging and emissions/economy reasons.  Returning the fuel right inside the tank keeps the fuel cooler which prevents excessive evaporative emissions (and also keeping the fuel cooler raises the fuel density).  Many of these cars have variable speed fuel pumps as well, but generally this is more to keep the fuel cool (so it doesn’t bypass more than it has to to the return), and in most cases NOT designed to raise the pressure as many believe.  The fuel pressure is governed by the regulator, which in that case is set to a static pressure that cannot rise.  

The OEM overcomes this situation by planning the mapping around the situation and generally they oversize the fuel injectors to compensate.  Modern high flow injectors with good control systems are pretty good at negating effects on drivability and mixture.  Installing the larger injector lets the ECU command a larger pulse width to compensate the fuel flow dropping.  

Generally a stock vehicle with forced induction doesn’t produce massive amounts of intake manifold pressure, so say the differential fuel pressure offset on a stock turbocharged car is -12psi, it can be managed with extension of pulse width.  

However, when you start increasing the intake manifold pressure, the results can become catastrophic.  If a proper rising rate fuel pressure system is not part of your upgrade plan, then think again!

What Pavlotech blog post would be complete without plugging the amazing advantages of aftermarket EFI solutions though?  

Modern ECU systems like Emtron have the ability to take a fuel pressure input (which should be a mandatory on every installation) and calculate the Fuel Pressure Differential (and offset) on its own.  Not only are these runtimes loggable (as in the plot above), but the ECU can be set to adjust the fuel model with this information.  This makes the system capable of adjusting the Fuel Model to ensure the specified fuel is being metered as perfectly as possible.   


From the above example, you can see here the Fuel Model is correcting the fuel flow -2.5%.  This is because the differential fuel offset is slightly positive/higher than normal (it is rising slightly instead of true 1:1).  What this does is ensure the calculated fuel is as perfect as possible.

It also will correct for the opposite direction as well!  If your car has fuel starvation issues, or a fuel regulation issue (say it is not rising), the ECU will do its best to compensate the fuel flow to maintain the target mixture.


This is a very extreme example of fuel starvation on a car with a completely equipped Emtron  solution.  If you pay attention to the bottom two columns, you will see the fuel pressure dropping off almost completely (this car had a fuel pick-up issue), but the third column shows the ECU extending the pulse width to its maximum (20%) to attempt to compensate.  The second column shows the mixture leaning out (there was almost no fuel pressure…), however you can see the mixture returning to target even before it comes back to the specified pressure.  The injector on-time returns to normal as the fuel pressure comes back as well.    

This kind of compensation operates and adjusts continuously on the Emtron ECU when the Fuel Pressure input is included in the fuel model (highly recommended).  This instantaneous adjustment is much more functional than relying on typical closed loop mixture adjustments that many other ECUs use alone.  

Connecting functions – Closing the loop

Engine efficiency can be influenced by a number of factors now.  Not just manifold pressure, throttle position, temperatures, or other basic variables.  An engine with variable cam timing introduces significant dynamics to engine efficiency for example.  The OE ECU systems in modern cars can be very complicated in the nature of conventional mapping.  This is because of the way connected functions are layered throughout the efficiency model.  It makes deep re-calibration efforts on a factory solution extremely challenging sometimes.  It also validates the need for an aftermarket control system that has the flexibility necessary to achieve what is necessary in that situation.  On top of that, the “failure” mode for some of these functions must be thought out and planned for.  Mostly in order to meet emissions compliance at all times.  

Simplicity is a selling point for motorsport EFI solutions in the aspects that performance will be consistent and reliable.  However, now that these EFI solutions are supporting original functions like cam control, drive by wire, and more – some extra thought and effort regarding completing the calibration process isn’t a bad idea.

I had the pleasure of diagnosing a motorsport EFI system that had a control failure regarding VVT recently.  This particular car had a very aggressive system that had the ability to add a total of 100 degrees worth of extra overlap if needed (between the two cams).  The failure was from a wiring issue which was not allowing one of the camshafts to move to the commanded target.  Seems like a minor issue, but the effect it had on the engine performance was staggering.  At certain RPM points, the mapping was so far off the engine would misfire.  This was due to the mapping expecting a certain efficiency point the engine was nowhere near due to the position issue.  The system was calibrated with the camshaft control system functioning normally, which is typical when using these EFI systems.  While it was a simple problem to identify ultimately once data was reviewed, the way the problem was described initially had the team on a wild goose chase initially.  

The problem got me thinking it was a good idea to write more about developing calibrations that are dependent on these control systems ability to affect engine efficiency (similar to the OE).  While I approach every project with this kind of mentality (to truly offer a “completed” package), it is important to not over complicate as well.  Too many connected functions like an OEM ECU could arguably create situations where I, or someone else, wouldn’t be able to calibrate the package easily.  This could defeat the purpose of the aftermarket system that is potentially replacing the original EFI system.

The EMtron ECU has the ability to write multiple tables for many functions, offset them with other tables, connect them based on other runtimes, and more.  This ECU functionality is key to the concept.  It validates the need for proper control of these systems on more modern engines as well.  

The car chose to proof the concept in this case was a BMW E36 M3.  The engine is very simple but it does have a rudimentary cam switch function that affects engine efficiency.  When these BMW 24 valve engines came out, the first couple of years did not have any cam switch function at all.  This made the the power delivery of the engine very “peaky”.  It made the engine less flexible in the aspects of everyday use (especially with automatic transmission).  Adding the cam switch function allowed BMW to improve low end torque by advancing the intake camshaft in the medium engine speed range.  This is commonly referred to as BMWs VANOS system.  

The Emtron ECU also supports almost every BMW trigger configuration as a predefined setting for easy use.  This allows the VVT configuration to be used (instead of cam switch if preferred) which allows much more flexibility, even stepped positioning.

** Stepped positioning  (feature not used by the OEM on this platform) in this example was not used, as the total camshaft travel was not enough to provide an advantage.

What most people don’t know is how sloppy the actual cam position is vs the commanded switch function.  More specifically on 15 second dyno passes, the cam position is offset by almost two seconds vs the cam switch command itself.  


Top plot shows actual cam position

Center plot shows RPM

Third plot shows the switch function being commanded on (high) and off (low).  

To put it simply, it’s lazy to get to there, and lazy to return.  It is unlike other camshaft systems that have instantaneous operation that some may be thinking about.  This presents challenges to the calibration process regarding consistency due to the fact that the switch condition is affected by the transient acceleration of the engine, oil temperature, and other factors that influence the speed of which the cam actually moves.  

Two problems that needed to be solved by connecting functions.      

Have the calibration be set up for the different efficiency situations created by the cam position..  

Have the calibration switch/blend dependent on the actual cam position, not the commanded switch function.   This would make the calibration optimal under all camshaft positions, allow for more flexibility regarding the switch conditions (not just RPM dependent), and provide a failure mode just as the OE systems do.  Closing the loop.  

I ended up with two fuel maps, two ignition maps, fancier injector timing maps, and some tables that facilitate blending the tables together.  These were based on the actual camshaft position runtime.  Because this is a “simpler” engine with a limited range of camshaft travel, there was no need to add any breakpoints (meaning more tables) to the function.  


Cam position retarded.  You can see the peak VE (torque) comes at higher rpm.  


Cam position advanced.  You can see the VE is much higher and earlier in the RPM range.  You can also see the VE drop significantly at higher revs validating the need to advance the cam in the midrange, but ultimately retard it at higher RPM to achieve maximum torque, and peak HP.


Ignition with the cam retarded.  In the medium speed range, the engine reaches MBT at higher advance due to the efficiency change.  Exploring this situation greatly improved the response of the engine during transient conditions where the VVT was switching on and off (new conditions added based on engine load).  


Ignition with cam position advanced.  You can see MBT is reached in the medium speed range with less advance.  

** due to time constraints, the top end advance for MBT was not explored even though the efficiency drops significantly.  In any case the advance would be slightly and safely retarded in a “failure” event.  


This is the blend function for tables based on cam position (same for both ignition and fuel).  It uses the Emtron Z-Axis function that interpolates the blending of tables in between the breakpoints.  This effectively closes the loop on the map changes as the mapping is automatically switched and blended based on the live camshaft position.  The deadband added to the min/max travel of the cam position was validated with the dyno to ensure the best interpolation between the tables on this platform.   


Finally I had a few minutes to explore some “failure” modes and attempted to get the engine to idle with the cam advanced.  Retarding injector timing helps with fueling in high overlapped conditions which helped immensely here.  The result was actually a very clean idle with the wrong position.  The factory ECU for this car will not even run at idle if the cam is stuck advanced.  

Evaluating the calibration once everything was done was very easy.  I essentially enabled the connected functions described above, chose the optimal cam switching points (which were obvious based on looking at torque logs and the dyno plots), and had to make no changes whatsoever.


Actual cam position in the top plot.  

RPM in the second.  

Throttle in the third.  

Cam switch activation in the fourth.

Lambda in the fifth.

You can see that generally under load the mixture is on target (closed loop disabled here, low RPM needs to be cleaned up), especially during the transient event when the cam switches off and the position “trails” off back to the retarded position.  The areas of the log where the cam is moving is where the connected function is doing its job.  The higher RPM spot is where it is difficult to maintain consistent mixture and prevent knock on this platform.  Logging ignition advance with all of the functions working was much smoother than calibrating the conventional way.  This matched the torque curve of the engine which was also smoother and consistent regardless of transitional cam position conditions.  


There is also no noticeable change in torque during the transient period, which is common without a closed loop function on this application.  

So how much more difficulty was added?  Dialing in a couple more tables is not the end of the world as long as the calibrator understand the connected functions.  


325is EFI Installation

It’s been awhile since a lengthy post.  We have been busy this year completing and supporting various installs for the start of the season!

Dave’s 1987 BMW 325is project car.  


Dave’s car has had various configurations over the years.  A number of powertrains, and more.  Dave is a personal friend of mine, and last year we had some deep conversations about what his goals were for the car.  He wanted to install an advanced powertrain (BMW S54 engine from E46 M3), but also wanted to have enhanced motorsport functions on top of basic abilities to map the engine as well.  We decided to use an Emtron ECU system based on his needs.  

I can say that this car probably has one of the most “completed” road car calibration with a motorsport ECU system that I have ever heard of.  

Not only did we use every single component of the original engine (VANOS, electric throttle, idle speed valve, sensors, etc), but we even upgraded into high performance wide range o2 sensors the Emtron can natively control.  This electronics package overall truly modernizes this powertrain significantly.  

Here is a list of the calibration functions/strategies being employed on this build. Each section has used nearly all of the Emtron comprehensive flexibilities.  

Speed density fuel modeling

Closed loop wide range lambda sensors (one per 3 cylinders) with comprehensive trimming limits, lockouts, STFT/LTFT functions and more.

Closed loop idle speed valve control

Closed loop idle ignition control

Full drive by wire control with perfect function.  Throttle tracks target within 0.2% deadband regardless of varying mechanical geometry.  Full use of 3D tables for PID including feed forward.    

Full VANOS control with perfect closed loop function.  VVT targets faster than factory ECU as well as with more accuracy.  Original method of solenoid control is used as well (no regulation in deadband)  

Advanced air management using the idle speed valve as an “adder” at part throttle/tip in (same as factory).  The S54 uses an idle air distribution pipe that can support significant amount of engine load without opening the throttles.  When the DBW is not needed (at rest), the system has its PID function switched off to avoid over-regulation.  It is only used when needed.  The change over between the idle air management to the individual throttles is seamless, and fully configurable.  

Closed loop windowed knock detection with individual cylinder feedback using short term and long term gain functions

Transient ignition function

Overrunning fuel cut

Closed loop map blending (using Z-axis) based on a number of engine parameters (such as camshaft position)

Cold start function with warm up strategy

Integrated within the original wiring to ensure all gauges and warning lights (including check engine light) remain functional  

All sensors configured for error detection, with pre-programmed limp modes for major sensors, as well as active substitute value tables

Rear axle speed input

Gear detection

Launch control with comprehensive arming/disarming function

Gear dependent rev limiter

EFI relay control

Cooling fan control

Fuel pump control

Engine protection features

Comprehensive ECU data logging set

The result is a powertrain that has totally open live mapping, responds like a purpose built race engine (when needed), starts cold, runs clean, gets good fuel economy, and more!  The true definition of the lack of compromise when using a proper electronics solution!  

While this car is overkill regarding how in depth the calibration actually is (that point can be argued), it is a good example of how flexibility is important for any application.  This is exactly where the Emtron ECU system excels, and truly is the benchmark!  


EFI Install

Just finished up a fully complete Motorsport ECU/Dash/Expansion install with @ratchethead racing for a flawlessly prepped E36 M3.  This car has a US spec BMW S52 engine and wiring harness.

This car has nearly all of the features enabled that the Emtron system can offer.  It uses all of the factory inputs and outputs flawlessly, as well as the following additional inputs :

Twin wideband lambda sensors

Manifold pressure sensor

Fuel pressure sensor

Oil pressure sensor

Oil temperature sensor

Calibration switch (steering wheel mounted)

Fuel used reset switch (steering wheel mounted)

Ground speed limit switch (steering wheel mounted)

Traction control (dash mounted multi-position)

The extra inputs are ran to the ECU (rather than display and/or loggers) so they can be used for true speed density VE fuel modeling, load calculation, and calibration compensations.  The high input/output count of the Emtron KV8 ECU allows this.  Proper engine trips (failsafes, sensor fault detection with substitute values, etc) can also be configured.  All these auxiliary components now go to one place as well, instead of being wired to various components for data collection.

All factory plugs and sensors are used (besides narrow band lambda sensors) including the factory engine harness (Plug and play – first of its kind).  Harness additions are documented and clearly labeled for ease of use using Deutsche expansion plugs.   This system can easily be configured to add on electric throttle capability as well.  

The setup of additional sensor inputs along with a properly characterized fuel system allow the Emtron efficiency strategy to thrive.  A separate post is needed to elaborate on this system’s performance, consistency, flawless drivability, efficiency, and overall control.  Since this vehicle will be used for endurance racing, the Emtron true fuel consumption calculation will be a value tool.  

For data acquisition and display (besides the included onboard ECU logging), we enabled an advanced logging set to be received by an @AIM MXL Pista dashboard.  AIM supports a specialized Pavlotech/Emtron configuration that can receive over 60 customized ECU parameters. These can all be recorded, configured for display, and/or alarms.  Almost every sensor input and calculation from the ECU is available over the network which is just two wires going to the dashboard!  This further allowed us to create new alarm functions for fuel consumption that trip when 90% of the fuel capacity is used up, instead of watching a gauge that is inaccurate.  

On top of all of this, this car is now capable of motorsport traction control that is incomparable to any other system in this market.  The strategy uses the ECU’s internal G sensors to develop slip thresholds based on longitudinal and lateral load.  The configuration is highly comprehensive with full closed loop control.  There is also a dash mounted multi-position switch to control the traction systems sensitivity!

If you are ready for real, serious, and professional solutions for your competition vehicle, please contact @pavlotech soon to discuss your options!  


Map Switching


A frequent (and sometimes controversial) question comes up a lot since vehicle electrical systems continue to evolve .  What is map switching?  The short answer is the ability to change the ECU look up table reference points.  While that sounds complicated, this can be a very simple concept.  

A good example would be a car with electronic throttle control that has a “sport” switch that changes the sensitivity.  The ECU would have multiple look up tables for throttle targets which is then dependent on a switch (or something else) to actively change it.  Attached are examples of two electronic throttle target tables.  The axis for the look up tables are configured to follow RPM and pedal position.  You can see the relationship between the pedal and target throttle position is not linear in either map.  This is normal contrary to popular belief (especially if the application uses a very large throttle body or individual throttles), but regardless of that, each map has a different pedal to throttle curve which is what changes the throttle sensitivity.


With modern electronics, map switching can be configured to much more than simply change the throttle sensitivity of the engine.  While the examples I am showing you are utilizing the @emtron #emtune calibration software, some (if not many) of these functions can be configured in a modern factory ECU as well.  

Attached is an example of the CAL (calibration) slot control page in Emtune.  You can see there are 4 CAL slots on the top which correspond to multiple tables for various functions of the ECU.  You can change every important look up table of the calibration based on the position of the CAL slots at the top.  To add flexibility, Emtune lets you define however you want to control the slot change as well.  You can have a multi position switch telling the ECU what slot you want to be in, change slots based on an analog voltage, change slots based on speed, or change slots based on temperature.  The configuration is totally open so you can do almost anything you want.  They even give you a 3D table to configure this based on multiple axis.  


Emtune also has some advanced features that allow you to “blend” tables automatically in addition to the above mentioned CAL slot control.  This is called their Z-Axis function.  In one of the attachments the configuration is shown where, based on vehicle speed, a boost target table (in KPA) is automatically switched (and blended automatically when in between).  Z-Axis is available for almost any important map within the Emtron ECU systems.  


In addition to some of the reasons why map switching can be useful above, here is a quick list of common examples:

Drive by wire target

Fuel mixture table

Octane switch

Boost target switch

Launch mode enable

Ground speed limit enable

Logging enable

Valet mode

Torque limit switch

Map switching can be very useful in race series that base car classification on power to weight.  The car can be set up to run in a number of classes by changing parts, installing a restrictor plate (to limit engine power), or switching the calibration.  

Hopefully after reading all of this you can see how being able to switch calibrations could be useful in this instance.  Especially if the car has electronic throttle!  

While this subject can be highly controversial (due to making it easy to cheat), if used LEGITIMATELY it can yield impressive results further justifying investing in the proper electronics solutions.  

Attached is a dyno plot using running two different calibrations so the same car can be used in two separate racing classes that are based on power to weight.  The max power and detuned run were NOT back to back here (you can see the detune was several runs after the max run), so there was some heat soak.  Even still, the detuned plot shows essentially maximum torque available until the peak HP is “clamped” at roughly 6000rpm.  


This was done properly with a number of calibration changes that included throttle target tables, proper fueling changes, ignition correction, cam position, Emtune torque limiting tables, and more. Rather than simply installing a restrictor plate which usually relies on an automatic function to compensate for reduced airflow, each calibration slot is customized, consistent, and therefore reliable.  

Interested in learning more?  Feel free to contact @pavlotech to discuss the options!  


Emtron/Pavlotech AIM support

Thanks to, Pavlotech is excited to announce its collaboration with AIM Sportline for support on a very advanced ‪#‎logging‬ set available soon (available now if you contact Pavlotech)! This is one the most “completed” set of ECU parameters available in the entire software suite. 61 different ECU statuses can are available for logging and display configuration.

20 percentage channels

10 pressure channels

10 switch statuses

6 temperature channels

Various voltages


Position angles


Fuel consumption

So what does all that all mean? The user friendly AIM Race Studio software will now have a plethora of information available to any racer striving to lose seconds off their lap times. Comparing drivers, driver coaching, and more, will reach a new level of critique!

Regarding ‪#‎diagnosis‬, attached are some ‪#‎AIM‬ ‪#‎MXG‬ dash display examples, as well as multiple check pages. The check pages take advantage of the reported parameters for lightning quick diagnosis without the need to connect any hardware to a computer.

Have a more complicated problem? The dashboard will record enough information now to do full analysis. All of this is possible now without the need to actually connect to the ECU at all!

The logging set was also designed with customization in mind. Emtron Australias industry leading definable CAN streams allow full re-configuration. With a‪ #‎Pavlotech‬ dash support package, we can customize the Emtron CAN parameters for your needs completely. Careful research before hand on parameter scaling enables Pavlotech to actually re-define the new AIM pre-defined configuration.

Yet another example showcasing the advantage of ‪#‎Emtron‬ as compared to other ECU systems!

See the Ratchet Head Racing Team cars showcasing these fantastic features at major events near you soon!

Interested in what #Pavlotech can offer? Send us a message!


Autosport Labs Race Capture Pro

Lot’s going on over at ‪#‎pavlotech‬! Been a long time since a blog post so here is an update on some new things.

Over the past few months, I have been working closely with Autosport Labs and their new ‪#‎RaceCapturePro2‬ data logger. This is not your standard logger though as it has an open source concept that allows some serious customization. There are extra features like cell connectivity, bluetooth connected dash systems, live telemetry, sync with Ustream broadcasts, and more.

The feature being showcased in this blog is the the ‪#‎telemetry‬component. There is a cell radio inside the module with a live data connection through a GSM SIM card. Once properly configured, you can then log into their website and view live data (see pics) with minimal delay!

One of the new things the RCP2 can do is interface with a CAN bus network that allows a whole new world of information to be logged (and viewed over telemetry). CAN bus is a standardized automotive computer network that allows sharing of data between control systems with just a pair of wires. This is heavily used in the OEM environment, and recently exploded in the aftermarket industry regarding motorsport dash support, connected systems, and OE vehicle integration. The CAN stream configuration is user definable via a custom script in the RCP2 application.

I recently had the chance to fully test this at New Jersey Motorsports Parkthis past weekend with the Ratchet Head Racing Team Emtron Australian powered car at a Go Trans Am Racing – America’s Road Racing Seriesevent. With on the spot support from ‪#‎autosportlabs‬, I was able to configure many CAN parameters to be broadcasted over live telemetry. To the best of my knowledge, this is the most comprehensive example of utilizing this feature to date (regarding a high number of channels).

There are only 4 wires connected to the ethernet port of RCP2 module, and I was able to pick up the following channels for this test. These in addition to the already included lap timing, GPS tracking, acceleration sensors, and more.



Coolant temp

Air fuel ratio

Intake air temp

Brake position

Fuel level

DTC error (diagnostic trouble codes)


Keep in mind, anything the ‪#‎Emtron‬ can broadcast over the network can be picked up. I chose these mostly for testing purposes.

The RCP2 supports some familiar “gauges” as you can see in the screenshots, but also allows you to create virtual channels if you are not interested in using the gauge. This is why in the screenshots you can see some parameters labeled “2”. These also display the raw values.

One interesting parameter I was viewing was a “Fuel used” channel that reports in gallons used (Fuellevel2). The #Emtron has ‪#‎motorsport‬ math calculations that can be configured. Once the fuel system is accurately characterized in the ECU, the system has the capability of calculating fuel used as accurately as 0.01L.

So what can this be used for? Imagine driving a race car (especially during an endurance race) with someone in the pits watching your back the whole time! Peace of mind that is invaluable, especially in a car full of data components like the ‪#‎ratchethead‬ cars. Just drive the car and not worry the whole time about every temperature, pressure, fault, electrical system, etc.

With engineering watching, they can get in touch with drivers to notify them about things before they become issues. They can even start planning diagnostics if something is wrong.

The fuel used calculation the Emtron reports allows the crew to adjust fueling strategies as well during endurance races. Imagine all the possibilities.

Currently on the Autosport labs wiki page there are some example scripts that work with the Emtron “standard” logging CAN output, however this can be fully customized on both ends. Imagine adding channels for Oil temp, trans temp, diff temp, pressures, etc.

Contact Pavlotech for more information regarding sales and support of the RCP2 unit!

Any engine control systems that use electronic throttle must have strict position error detection for obvious reasons.  The OE system uses two separate sensors for pedal position, as well as two sensors for actual throttle position.  This ensures the ECU can validate and trust the inputs.  If there is an error in validating the position, the system can be set up to react a number of ways.  Shutting down the throttle system is the obvious answer to prevent unwanted acceleration (especially on track).  

With more complicated engines, the aftermarket ECU system must still rely on the same sensors for safety.  Diagnosing these types of errors can be complicated (even with a factory ECU), but if your installer develops a good troubleshooting logging set, these systems can be diagnosed quickly and easily.  

Attached is an example of a failing pedal position sensor using an #emtron #kv8 ECU.  


The top graph shows drive by wire target vs actual throttle position.  If the system is working properly, then these lines should draw on top of each other (except during quick changes).  Looks good as you can see.  

The second graph shows the difference between throttle position sensor 1, and throttle position sensor 2.  0% is normal at all times since there should be no difference between the two signals regardless of the actual throttle position.  With a closed throttle, both should read closed.  With an open throttle, both should read open (and in between). This is how the ECU validates the position.  The graph is blank, verifying there was no error over the entire logging session.  

The third graph shows the difference between pedal position sensor 1, and pedal position sensor 2.  The function here is the same as the throttle sensor comparison.  As you can see, there is a lot of activity in this section immediately reporting that there is some sort of issue.  

The error in comparison is only a few percent (circled values on the right), but the ECU is aware of this almost instantly.  This demonstrates (and inspires confidence in) the Emtron ECUs ability to automatically react to to potential problems.  

A proper ECU logging setup will also make diagnose very simple and painless.  The Emtron log viewer allows you to create new tabs for parameter display (see DBW tab section on top).  I was able to determine a potential issue within seconds of downloading the ECU log.  After collecting and reviewing this data, a plan for furthering diagnosis is easy.


Motorsport EFI – Part 3 – Repair Anxiety

Almost every time I have a conversation about engine tuning solutions, the factory ECU is brought up.  Factory ECU tuning has its place in the performance industry, but when really considering its ability to provide a solution for motorsports, the advantages of aftermarket ECU solutions cannot be ignored.

A great example would be a customer who wants to use a modern engine for racing.  When a manufacturer develops a new engine, emissions compliance must also be be met.  Emissions is the fundamental priority of ECU systems in newer vehicles.  In In most cases, this does not coincide with the tuning concepts for competition racing.  In fact, I could write another multi part blog about that subject by itself.  Besides all of that, this particular engine has modern features such as multiple electronic throttles and variable cam timing..  The car company this engine comes from also has complicated and proprietary diagnostic tools as well.  Generic OBD scanning tools don’t cut it for diagnosis, and there is no way to know how the engine will react on track if there is a fault or limp situation.  The cost of manufacturer proprietary hardware and software tools is also rarely considered when making cost comparisons as well.  Even then, the factory tools are designed to aid in repairing road going vehicles, not motorsports competition cars.  Will the tool even provide you with the data you need to fix your car?  Was the ECU software manipulated in some way to allow its use for motorsports competition?  Will this manipulation complicate normal race car service in the event of a problem?  All very valid questions if you really think about it.

Simple diagnosis

No special tools or hardware is needed to connect to the ECUs.  You can use any laptop and view logs, live data, faults, etc.  The newer the engine, the more valuable this is when the need comes to repair something.  With good engine management, you can not only view every single calculated value to determine if the value is erroneous, but also view the live sensor voltages as well.  In almost all cases, this is much more informative than what you will get out of a factory diagnostic tool.  This video shows a status page just for E-throttle information using a #emtron KV series ECU.  There are several tabs for every other engine function as well.   

Fault detection

Almost every sensor and actuator has programmable thresholds for faults.  This means you can maintain the safety of an OE system, but also customize it.  You can choose the substitute values yourself.  Higher level ECUs (#Emtron) even have “fault tables”.  Fault tables are lookup tables for those substitute values so they are active instead of a static number.  Most OE solutions don’t even do that.  

Check out this video that shows off all the runtimes and logging functions available for a dual drive by wire setup.