I would like to install a maxxecu in parallel with the OEM engine ECU

Hello. I have a little advice to ask you please. I would like to install a maxxecu in parallel with the engine ECU (in order to keep all the functions of the vehicle) the engine of the vehicle in question is a naturally aspirated engine (z22se that I want to switch to turbo) I would like to duplicate the signal from the tps position sensor and the crankshaft position sensor without adding a second sensor. Can the maxxecu be connected directly to these two sensors and send the output signals back to the original ECU?

You are better off running them in parallel (the maxx is almost certainly not capable of outputting the trigger and analog voltages/waveforms the factory ecu requires). You will need to tie the sensor grounds of the two ecus and pair the trigger and analog sense channels.

You will also want coolant and presumably intake air temperature and manifold pressure.

Does the factory ecu use a AFM?

It probably worthwhile digging into a make specific forum to see how the factory ecu will behave if it doesn't experience loads on injector outputs or if it needs AFM signal to provide the functionality you want.

You may find the Maxx can operate most or all of the functions you are looking for.

Hi, sorry for the delay. Thank you for answering me shared the signal from the sensors to 2 ECUs is it likely to weaken and therefore make it incorrect? Is it possible to retrieve the information from its sensors via the CAN BUS?

You need to confirm ecus in consideration can use CAN channels for main fuel and ignition model inputs.

You cannot get away from crank/cam signals coming in as analog channels to my knowledge.

I think maxx has a piggyback mode? Just checked in MTune, in Can tab, called CAN OBD2 INPUT.

Update – More context about my Z22SE / MaxxECU Sport / OEM GMPT-E16 setup

Hi everyone,

I created this thread a few years ago, but I realise now that my original post did not provide enough context about what I am actually trying to achieve.

The car is a 2003 Opel Vectra C with the Z22SE 2.2L engine, using the original GMPT-E16 ECU.

I now have a MaxxECU Sport GEN1, and my goal is for the MaxxECU to become the actual engine management ECU, controlling things such as:

• Fuel injection
• Ignition
• Engine sensors
• Potentially the electronic throttle
• Eventually other engine-related functions

My concern is mainly the vehicle integration side.

The GMPT-E16 is connected to the Vectra C CAN network and may be involved in communication with systems such as:

• CIM / immobiliser system
• Instrument cluster
• ABS / ESP
• Air conditioning
• Cooling fan control
• Other chassis/body functions that expect information from the engine ECU

MaxxECU = full engine control

GMPT-E16 = retained only if necessary for OEM CAN / vehicle integration

I am trying to determine whether that is realistically possible and whether it is the correct approach.

Crankshaft trigger

This is the main complication.

The Z22SE uses an internal crankshaft trigger and a two-wire VR sensor.

On the GMPT-E16:

• XC7 pin 23 = crank sensor wire A
• XC7 pin 26 = crank sensor wire B
• twisted pair

• H3 = Trigger
• H2 = Trigger Ground

Initially there was uncertainty about the Z22SE trigger pattern, but the recordings clearly showed that it was not a conventional 58X / 60-2 pattern.

I sent the recordings to Natanael Ceder at MaxxECU HQ in Sweden.

After analysing the data, MaxxECU created a custom firmware / experimental decoder specifically for this engine, called:

Trigger System: Development 83

Their recommended initial configuration is:

• Trigger System = Development 83
• Home Signal = NO
• Crank Polarity = Rising

If it works correctly, the engine should be capable of running initially with:

• wasted spark
• unsynchronised fuel

This is very important for my project because I would strongly prefer to use the original internal Z22SE crank trigger rather than installing an external trigger wheel.

Why I want to avoid an external trigger wheel

I investigated several external trigger options.

A custom 36-1 / 60-2 installation would require:

• a trigger wheel
• a very rigid sensor bracket
• very accurate positioning
• good concentricity
• enough clearance around the crank pulley

There is also very little space in front of the engine in the Vectra C.

The best commercially available option I found that appears reasonably adaptable is based on the GM L61 / Ecotec 7X setup, but by the time the parts are shipped to Martinique, the cost becomes significant.

Therefore, if Development 83 works reliably, keeping the original internal trigger is by far my preferred solution.

The main question: sharing the VR crank signal

If I keep the GMPT-E16 alive, ideally both ECUs would need engine speed information.

The obvious possibility would be:

Original VR crank sensor → GMPT-E16 + MaxxECU in parallel

However, I do not want to assume that this is electrically safe or reliable.

My concern is the interaction between the VR input circuits of the two ECUs.

I do not want a setup that appears to work at cranking or idle but becomes unreliable at higher RPM.

I have seen suggestions involving:

• direct parallel connection
• VR signal splitters
• isolation transformers
• active signal conditioners / buffers

So one of my main questions is:

Would you consider sharing a two-wire VR crank sensor between the OEM GMPT-E16 and the MaxxECU Sport acceptable, provided the input impedance and conditioning circuits are compatible?

And if not:

What would you consider the correct way to duplicate the VR signal reliably to two ECUs?

Alternative architecture

If sharing the crank signal is not a good solution, I see two main possibilities.

Option 1

Keep the GMPT-E16 fully operational on the vehicle CAN network with its own crank signal, and install a completely separate crank trigger and sensor for the MaxxECU.

This would preserve the OEM ECU behaviour but adds mechanical complexity and cost.

Option 2

Use the original crank sensor exclusively for the MaxxECU and progressively remove the GMPT-E16 from the engine-management architecture.

In that case, I would need to determine which CAN messages from the GMPT-E16 are required by the Vectra C and reproduce the necessary information.

I have a Kvaser CAN interface and CanKing, so I can log and analyse the vehicle CAN network.

The GMPT-E16 HSCAN connection in my wiring information is:

• XC8 pin 5 = HSCAN High
• XC8 pin 6 = HSCAN Low

• Engine RPM messages
• Coolant temperature
• Engine running status
• Air conditioning requests
• Cooling fan related communication
• Instrument cluster information
• ABS / ESP related engine data
• Rolling counters
• Checksums
• Message timing

Immobiliser

Just to clarify: I am not trying to bypass the vehicle immobiliser.

My goal is to understand the architecture and retain the OEM vehicle functions where necessary.

The Vectra C uses CAN communication between modules including the CIM and the engine ECU, so I need to understand what happens if the OEM ECU is no longer performing engine control.

What I am trying to determine

The main question is therefore not simply:

“Can I install a MaxxECU in piggyback?”

It is:

What is the cleanest and most reliable architecture for allowing the MaxxECU Sport to fully control the Z22SE engine while preserving the Vectra C systems that depend on the original GMPT-E16?

At the moment I am particularly interested in your opinion on:

1. Sharing the original VR crankshaft signal between both ECUs.
2. Whether a proper buffered / isolated VR splitter would be preferable.
3. Keeping the GMPT-E16 alive only for CAN and vehicle integration.
4. Whether removing the GMPT-E16 from the CAN network and reproducing its required CAN messages would ultimately be a cleaner solution.
5. Any other architecture you would recommend for this type of installation.

Thanks for taking the time to look at this.

Jean-Christophe

Martinique

This is something that should be approached with a real 'scope first to do anything with actual intention - even though Natanael may have gleaned a usable trigger for a Maxx, it doesn't mean that it's what the factory ECM is looking for. I've layered Maxx's on top of RBs with an optical CAS and it works very well however when you start asking to split raw VR sensors without knowing what the ECM is actually looking for voltages and triggering thresholds you're asking for a world of pain.

Once you actually know what you're trying to get the factory ECM to see, you can make a decision - you may even find that you can leverage Maxx's unsynchronized trigger pattern generator.

There should be no issue sharing the VR crank signal between the factory ECU and the Maxx ECU. You will need to ensure that the pull-up in the Maxx is disabled but that would be required for a non-piggyback installation anyway. Likewise the TPS signal should be fine to splice into the Maxx. The only real traps with piggy back installs is sharing a NTC temp sensor (air/coolant temp) as these rely on an internal pull up to 5V inside the ECU. To share these signals you'd need to ensure the pull-up resistor in the Maxx is disabled. This may make calibration a little tricky as the voltage the Maxx receives will be reliant on whatever pull-up the factory ECU uses.

You may find that hijacking the fuel and ignition outputs and using the Maxx to control these (which would really be essential if you want to go down this path) may result in DTC's depending how smart the stock ECU is. Often they will have open circuit/short to ground detection along with misfire detection and can get a bit upset if the Maxx is charged with fuel and ignition control. Likewise if you control the DBW with the Maxx you're definitely going to have a bit of a christmas tree of lights on the dash. In the perfect world you'd have access to some option to reflash the stock ecu and disable any DTCs that are logged. This is exactly how we've approached running a Haltech Nexus, Fueltech FT600 and a Holley Terminator X Max in our 2000 C5 Corvette.

I hope that helps.

For the coolant temp sensor there's an offset option built in for piggybacking - makes for an easy calibration.