Standalone ECU Implementation: Difference between revisions

From X1/9 Wiki
Jump to navigation Jump to search
m (added links)
mNo edit summary
Line 57: Line 57:




== 1. CANBUS Implementation. (incomplete, indefinitely)  ==
== CANBUS Implementation. (incomplete, indefinitely)  ==
'''Edit: While I was able to figure out quite a few parameters by logging the car's C CAN network - it ultimately proved to be unnecessary. Somehow, some way, Fiat changed very little in this regard when adapting the 500 to the US market, despite it having an entirely different ECU. As such, there is no need for me to know...pretty much any of this, though I guess being overprepared is better than underprepared. Regardless, I will list the parameters I know of below, even though I do not know enough of them to create an ECU translator that will satisfy every module on the car.'''  
'''Edit: While I was able to figure out quite a few parameters by logging the car's C CAN network - it ultimately proved to be unnecessary. Somehow, some way, Fiat changed very little in this regard when adapting the 500 to the US market, despite it having an entirely different ECU. As such, there is no need for me to know...pretty much any of this, though I guess being overprepared is better than underprepared. Regardless, I will list the parameters I know of below, even though I do not know enough of them to create an ECU translator that will satisfy every module on the car.'''  



Revision as of 06:39, 8 July 2023

This is a project. One which, I'm fairly certain has not been done (or perhaps not documented) before. It's in very early stages- currently, the overwhelming majority of my progress has been acquiring data, which will be shared below. I am an electronics moron. Perhaps you should take what you see below with a grain of salt.

EDIT: I DID IT! It actually works...

As these cars age, our reliance upon Mopar for electronics/computer support must end, otherwise ownership of these cars into the far future is simply not feasible. Additionally, content discussed below can be useful for standalone ecu implementation for engine swap applications.

Standalone ECU Implementation - The Electronics

For this project, I decided to use an ECUMasters EMU Black. There wasn't much in the way of choice admittedly - as of now, there are only two standalone ECUs on the market, that I am aware of, that have Plug and Play support for the Fiat 500. One of them being a model from SCS Delta, and of course, the EMU Black (and Classic).

The plug and play adapter is indeed plug and play...for the car it is designed for, which is the Euro/Global market spec that uses a Bosch ME7.9.10. Our US spec cars, which use a Marelli8GMx, have quite a lot of differences under the hood, with changes to the: EVAP system, diverter valve, Oxygen sensor(s), the inclusion of MultiAir (and thus the power and gnd to the four, high current solenoids), and a couple other systems.

The different requirements of the US spec car, along with the use of an entirely unrelated ECU family, meant that Fiat had to change the pinout of the factory harness. Thankfully, however, the connector is the same - a variant of the TE284617. This means that, for the most part, the *cars own* harness can be easily repined. I hoped that there would be a way to modify the pinout of the PnP adapter itself, but this proved near impossible given the design.

As it stands, and without me (or someone) making a PnP adapter, modification to the cars wiring harnesses is very difficult to avoid. Personally, I didn't have the time to come up with a solution to that, and decided the harness would just be a casualty of attempting to pioneer something like this.


There are a few main things which stand out as incompatibilities (beyond simply repining).

  • The Lambda sensor (Upstream Wideband Oxygen Sensor) is a part of the C2 connector on the T-jet model, whereas it is on the C1 connector for USA spec cars. A jumper of some form could be used, but you are at the mercy of the pinout of the PnP adapter - and it is possible the PnP adapter is made for a narrow band sensor (some documentation points to this). I suggest wiring the Lambda sensor directly to the EMU Black itself, in this instance. Ecumasters provides pretty good documentation on this, so I won't elaborate here. I do not know anything about the OEM sensor, so especially if your car has some miles on it, I highly reccomend getting a new Bosch LSU4.9 sensor. These can be found for many applications nowadays. I used one from my 2006 BMW 330i, with the N52 engine - the sensor retails for around $100 (Bosch PN 0 258 017 098). You will need to buy a LSU4.9 connector online, as you must retain the connector end of the LSU4.9 sensor, as it contains a calibration resistor strip - so do not cut the sensor wiring as a method of connecting it to the EMU.
  • The diverter valve is wired differently on the T-jet model. However, this proves to be a non issue for one major reason: since Multiair being removed or made passive is a needed part of this swap, you don't really end up needing electronic control anyway. Since the engine will now be traditionally throttled, you can simply buy a pneumatic diverter valve and hook a single hose straight to the inlet manifold. No valves, no solenoids, no wires. Just air, and it works great provided the correct spring is used.
  • The starter interlock relay, which is a physical means of preventing the engagement of the starter if the clutch has not triggered the downstop switch, is switched on the high side by the Marelli ECU, and seemingly on the low side by the Bosch ecu (and thus this PnP adapter). This can be resolved in two ways- one, the interlock function can be removed, by powering the relay any time the ignition switch is on, or, an additional relay can be added which serves to switch the OEM interlock relay on the high side. Alternatively, the oem interlock relay could be replaced entirely by the aforementioned external one- but that would likely involve further modification of existing wiring.
  • The wiring of the brake, clutch, and reverse switches is a little messed up, at least it seems that way. In the US spec car, all three of the aforementioned switches operate at 12v. I thought that perhaps this is just because they were floating, but neither of the pulldown options made a difference for me. The EMU Black can support up to 12v on the analog inputs- though it will not read anything over 5v. The switch inputs, which are used by default, are not designed to be given power at all - they are supposed to be switched by closing a circuit to GND. Failure to repin this could lead to damage of your ECU. My short term solution for the reverse switch was to re-wire the reverse switch to go GND > REV SW > EMU Switch Input rather than the factory configuration 12V > REV SW > EMU Switch Input. This works just fine. For the brake pedal switch, I connected the signal wire (which, remember, operates at 12v) to a free analog input. I currently do not have a clutch switch input - but given I don't have control of the Interlock relay yet anyway, I guess it isn't critical. The EMU reads 5V on an analog input for any voltage 5-12v. Additionally, sending 12v does create a slight deviation of the EMUs sensing circuitry voltage, which I am not really happy with. My long term solution will likely be to make a MUX switch and use one analog input for all 3 inputs.
  • The After Run Coolant pump is switched by grounding a single wire in the C1 (body side) connector. Grounding this pin completes the circuit through the coil side of the relay (low side switching), which is hot at all times, to allow the pump to run whenever the ECU requests. One of the EMU's AUX outputs should be used in this case, as those are for low side switching. In order to run this pump after shutdown with the EMU Black, the delayed shut-down function should be enabled, with logic (using Virtual Parameter Outputs, and Parametric Outputs) to control the run conditions, and thus when to keep the ECU awake. At some point, I will attach screenshots of how to do this, but it's not too difficult IMO. There are more complex things to deal with. This pin
  • The ECU/EMU power input pins are a bit..wrong. As the PnP adapter comes, the high current capacity, ignition switched supply from the body harness is connected to the 12V ignition pin on the EMU black, which is not used as a main power feed in the EMU - it is simply an ignition status input to tell the ECU to turn on/wake up, and thus the pin on the EMU is small. Additionally, the cars 12V ignition signal (used to wake up the factory ecu) is connected to the EMUs main power feed, which is also just wrong. To avoid this mess, I have used the cars 12V ignition switched signal, bypassed the PnP adapter, and routed that directly to pin G18 (ign 12v) on the EMU. For the main power feed, I again bypassed the EMU Black and got the power directly from the batteries ve+ terminal. You should absolutely use a fuse as close to the battery terminal as possible if you choose to go this route. I am sure there are other solutions, perhaps some more elegant, but this is what I did. If you find something better, please share, and Ill be sure to update this page.


Wiring Diagrams, Pinouts, etc

Be wary that the 500 Abarth Plug and Play adapter manual you can find online through ECUMasters is not up to date - it is for the older version of the PnP adapter made for the EMU Classic. While some things are the same, or very close, there are a few differences. The documentation which comes with the PnP adapter for the EMU black should be correct and up to date.

Additionally: do NOT blindly connect wires to where you think they should go based on a diagram. There are discrepancies in the EMU documentation as I mentioned above, and there are also errors in fiats own wiring diagram - at least in the service manual I have. I guess it wouldn't be a fiat if the documentation was correct.

Please use the following as nothing more than a general guide. Always check, double check, and triple check every connection before proceeding. I am not responsible for damage to your car, yourself, or the EMU black, all of which are very possible. The following spreadsheet needs some polishing, and some edits, which I will be doing in the future as I have time. The rows highlighted are those which you should look at with the most skepticism, as there is either a discrepancy, or incompatibility requiring work beyond simply moving a wire around.

For now, I must approve anyone who tries to access this document. Once I have a higher level of confidence in its correctness, it will be open to all, but for now I would like to ensure I talk to and warn each person who would like to use it.

https://docs.google.com/spreadsheets/d/1OC6R-kx5jToImxXRtPxPB29olWXmCCdy5MaccLEAFsg/edit?usp=sharing

Also useful - the EMU Black pinout , for the components which need to be wired directly to the EMU. EMU Black Pinout (from ECUMasters site)







CANBUS Implementation. (incomplete, indefinitely)

Edit: While I was able to figure out quite a few parameters by logging the car's C CAN network - it ultimately proved to be unnecessary. Somehow, some way, Fiat changed very little in this regard when adapting the 500 to the US market, despite it having an entirely different ECU. As such, there is no need for me to know...pretty much any of this, though I guess being overprepared is better than underprepared. Regardless, I will list the parameters I know of below, even though I do not know enough of them to create an ECU translator that will satisfy every module on the car.



In order for a modern (lol, kinda) vehicle like the "New" 500 to function relatively normally, communication from the ECU over CANBus is vital. The instrument panel, ABS, electronic power steering, and even the BCM for controlling such minute things as the door locks, all receive vital information from the ECU over CAN. While the idea of implementing this communication in a custom application seems daunting, for the most part, it is thankfully not.

Reverse engineering CANBus comms is very time consuming, and at times, can be difficult or impossible to fully understand the contents. Thankfully, that does not always matter.

Below, the various messages and processes immediately related to the ECU will be broken up into sections, and my findings shared.


The Immobilizer

The Immobilizer function is the cause of headache for many, especially those looking to swap a stock multiair engine into another vehicle such as the X1/9. Thankfully, doing the opposite - implementing a standalone ECU with the stock BCM - is far easier, as the ECU itself is what handles most of the immobilizer function.

The process is quite simple, and is as follows.

Shortly after the ignition is switched on, once every node on the bus has woken, the ECU/PCM sends a message to the BCM with a status bit, four bits of generated data, and two bits of...something.

The BCM then takes in this data, applies some translation/adjustment to it using an internal code, and then replies to the ECU with the result of this translation/adjustment.

The ECU knows what changes the BCM should apply to this data, and thus it knows what response it should receive. The ECU then checks that the response received is what is expected- that the BCM is the one "married" to the ECU, and if it is, the ECUS own fuel cutoff immobilizer is disabled.

The ECU then sends one final message to the BCM, nothing more than a status bit (bit 0), telling the BCM that verification was successful.


Annotation of a recorded exchange is below.


•key is switched on•
ECU sends

0x0010A001 (message ID) , 05 A4 34 18 89 0A 2C ( where 05 is the status bit, A4 34 18 89 are the 'challenge' for the ECU, and 0A 2C are...something)


the bcm replies:

0x0010A000 (message ID) , AB 16 C1 00 00 00 00 ( where AB 16 C1 is the BCMs 'reply' to the ECUS challenge)


after successful verification, the ecu sends a final reply, likely disabling the Immobilizer light on the cluster, among other things:

0x0010A001 (message ID) , 06 00 00 00 00 00 00 ( where 06 is the status bit indicating successful verification)


•immobilizer exchange complete, engine start permitted•


So we can gather, the first (status) bit of 05 seems to indicate the immo is enabled, and is sending a challenge, and that a status of 06 indicates the ecus immo is satisfied. What is not known, is if sending the BCM the status bit 06 without previously sending a challenge will result in no complaints from the BCM. This will be tested soon.