VW Touran Conversion

From openinverter.org wiki
(Redirected from Touran Conversion)
Jump to navigation Jump to search
Touran Charging in Bortnan

I started this conversion in November 2018 with a 2004 VW Touran 1.6 petrol. It uses the EM57 Nissan motor (found also in Leaf and eNV-200) with its original inverter. The motor is bolted to the original 6-speed gearbox which seems to handle the torque fine. Also Nissans original DC cable, DC contactors, BMS and ChaDeMo socket is used and integrated into the vehicle.

The conversion heavily uses the existing motor CAN bus. A custom board has been fitted into the original ECU enclosure which is a nice junction point of various signals like throttle pedal, vacuum sensor and so on. The board handles VW specific CAN messages, Nissan Leaf BMS CAN messages and the ChaDeMo protocol. Last but not least it controls the inverter.

Update 2024

The car now uses 8 VW MEB modules for a total capacity of 55 kWh. Its highway range is now about 300 km, charge power is 90 kW so 100 km can be added within 10 minutes under good conditions. Power output is about 110 kW and highway economy is 150 Wh/km in summer when driving 110 kph with cruise control.

Mechanical work

This bracket attaches Nissans mounting to VWs. The shown aluminium is too weak, I rebuilt it with steel later.
This covers the distance needed to avoid collision between inverter mount and transmission bell
Motor to transmission coupler
EM57 motor and 6-speed VW wedding successful

The obvious first step is to remove the combustion engine. There are various tutorials for that, I will only go into the specifics on EV conversion.

  • Unplug the engine harness from the ECU - this allows you to leave most connectors on the engine in place and just remove it with the complete harness - good for resale
  • Consider keeping the ECU to place your own logic inside its enclosure
  • Do not use force! You will reuse many connectors so don't destroy them
  • The only thing you can safely cut is the fuel pipes :)
  • Have someone empty the A/C - it's a vary unpleasant spray if you don't. It is also a potent climate gas, releasing it causes the same warming as driving 1000 km on petrol.

Transmission coupling plate

The Inverter mount collides with the transmission bell so I had to cover quite some distance to avoid it. To save on material I used box section profiles 4mm walls, 80x40mm. Bolted them together with a 100x50x40 U-profile and bolted all that to the motor. I had to make a little cutout for the drive shaft.

The bell housing plate started life as a 350x350mm 15mm plate that we cut to shape with a jigsaw. Afterwards it turned out I should have gone for 20mm as the whole assembly was shorter than the shaft coupler - forcing me to add another 5mm aluminium in between.

Shaft coupler

While the coupling plate is rather ham fisted the shaft coupler is not - because I wasn't in charge ;) At its core is a KTR Rotex GS38 jaw coupling. On one side is an assembly that embraces the spline extracted from the VW clutch on the other side it bolts onto a Nissan spline that used to be sold by New Electric but the stopped making it.

I didn't put much effort into aligning, just put the transmission on top of the motor, drew the hole marks as accurately as possible, drilled, tapped. Even took the whole thing apart inside the engine bay. Lets hope there is no backlash.

Throttle Pedal

The throttle pedal is analog, its signals are put onto the CAN bus by the ECU. I chose to remove the latter so I am reading the pedal directly. Here is its pin map:

Throttle pedal pin map
Pin # Color code Function
1 green/white 5V
2 yellow/green 5V
3 brown/blue GND
4 white/blue Throttle 1 0.75V-4.1V
5 green/blue GND
6 blue/black Throttle 2 0.38-2.05V

ECU connector

The ECU is connected to the vehicle with a 94-way connector. I have traced out a few signals.

Touran ECU with Rev 2 main board
Touran ECU with Rev 2 main board
Pin # Color code Function
7 white P4.4 (Enable DC/DC Converter)
11 - Throttle GND (Pin 5)
12 Throttle 2 out (Pin 6)
13 Throttle 5V (Pin 1)
33 Throttle GND (Pin 3)
34 Throttle 1 out (Pin 4)
35 Throttle 5V (Pin 2)
31 Vacuum sensor GND
37 Vacuum sensor 5V and P5.7*
53 P5.5 (I use it for fuel level signal A)
54 P5.2 (I use it for fuel level signal B)
55 gn P4.2 (Oil pressure simulation)
56 bk P4.1 (Enable DC/AC 230V converter)
76 P5.1 (I use it for DC switch switched GND)
77 rd/gr P4.6 (Vacuum pump switched GND)
78 gr/wt P4.5 (Type-2 plug connected)
80 P5.4 (I use it for CANL towards BMS, ISA shunt and CCS controller)
81 P5.3 (I use it for CANH)
83 Vaccum sensor signal
86 Ignition On - provides enough power to run the main board
87 While the ECU was connected, bridging this signal to 12V engaged the main 12V supply of the ECU. This behaviour could not be reproduced without ECU

I will use a revision 2 mainboard for interfacing those signals.

*Underneeth the car there is a 10-pole connector that used to plug in to some exhaust sensor controller. I call this "P5".

P5.7 is connected to the main board "VCU" 5V rail. I make use of this to power the VCU from the ChaDeMo charger.

In the front near the 12V battery there is another 6-pole connector that I call "P4".

Power steering

The power steering is electric and only draws power when you're actually steering. It still worked after engine and ECU were removed. Winner!

As soon as you produce CAN message 0x280 it expects rpm to be above about 600rpm, otherwise there is no power steering.

CAN bus

The car has various CAN buses but we only care about the motor CAN bus (500kbit/s). Here are some useful signals I found:

Some Touran CAN messages
COB Id Len Function Notes
0x1A0 1 Byte 1, Bit 3: Brake pedal switch Produced by whoever
0x280 Bytes 2 and 3: RPM*4 Produced by you, Controls the rpm gauge. Must be > 600 for power steering to work
0x284 6 Byte 0, 1: Counter 0-F in each

Byte 2-5: 0

20ms. Can also be 8 bytes long.
0x288 Byte 0: sequence 0x27, 0x46, 0x8F, 0xD7

Byte 1: Temp Gauge 4/3 x temp + 48

Produced by you, Controls temp gauge. Gain 4/3, offset 48
0x380 8 Byte 0: 0

Byte 1: 0x65

Byte 2: Throttle 0-0xFE

Byte 3-6: 0

Byte 7: Throttle delayed or filtered maybe + idle throttle as it's never 0

It's not actually that constant but apparently sufficient for DSC
0x38A Byte 1, Bit 0: Cruise on/off, Bit 1: Disable button, Bit 2: Set-, Bit 3: Set+
0x480 8 Byte 0: sequence 0x10, 0x68, 0x94, 0xC0

Byte 1, Bit 2: EPC, Bit 3: engine

Bytes 3,4: Consumption signal - incremental. Increasing by 28 per 10 ms results in 10l/h

Byte 5: 0

Byte 6, Bit 2: Cruise light, Bit 4: Message "Motorstörung Werkstatt!"

Byte 7: XOR of Bytes 0-6

Controls various indicator lights and fuel consumption display
0x488 8 Byte 0: Counter 0-F << 4 + 8

Byte 1-4: 21, 21, 7E, A6

Byte 5-6: 0

Byte 7: Counter 0-F << 4

0x572 Byte 0, Bit 3: Key switch in start position
0x580 8 Byte 0: 0x80 + counter 0-F

Byte 1, 2: 0

Byte 3: sequence 0x0f, 0x28, 0x7f, 0x28

Byte 4: sequence 0x1e, 0x10, 0x00, 0x10

Byte 5: sequence 0x70, 0x56, 0xf0, 0x56

Byte 6: sequence 0x0c, 0x48, 0xa7, 0x48

Byte 7: sequence 0x46, 0x90, 0x28, 0x90


More info here: https://wiki.openstreetmap.org/wiki/VW-CAN

Software here: https://github.com/jsphuebner/stm32-car

CAN bus tap

I wanted to tap into the CAN bus without cutting wires. The power steering assembly is connected via a 6-pole "VW" connector that has the CAN bus on it. The respective part numbers are 1J0973713 and 3B0973813. So I looped through the 4 signals irrelevant to me and directed the CAN bus towards the inverter. The Nissan wiring loom also has a CAN bus return that I then looped back to the power steering.

Battery Integration

Rear Battery Mounting

Update below!

As opposed to the original plans I currently only mounted one full Nissan Leaf pack in the fuel tank space. I used the existing 5 M8 holes that used to hold the fuel tank and part of the exhaust. In addition I drilled 3 holes into the seat carrying structure that exit exactly between the two battery bricks. Another 3 M10 screws fix the two bricks to the chassis there. So 8 bolts fix the mounting angles to the chassis.

Front Battery Mounting

The mounting angles are screwed into the battery brick with 2 M6 bolts each. There are 11 mounting angles, so 22 M6 screws fix the batteries to the mounting angles.

Positive and negative exit on the cars driver side. Positive passes through Nissans service disconnect jumper that also contains a 225A fuse. Next up the 2 poles connect to Nissans original DC switch gear in the exhaust tunnel and connect to the inverter using Nissans original DC cable.

I reused the original spaghetti wires and Nissans BMS (they call it LBC). It lives on top of the front battery brick. Its current sensor is bolted onto the positive DC switch in the exhaust tunnel. It also still monitors the safety disconnect. Its power supply and communication wires run to the fuel tank service hole under the rear seats. From here it connects to the motor CAN bus. It also runs at 500kbit/s and has no mutual object ids.

Fuel Gauge

Unfortunately the fuel gauge cannot be controlled via CAN bus. Instead there is a special fuel controller under the rear seats. It has a black ground cable, a red cable that used to enable the fuel pump and three smaller wires that used to connect to an analog pot inside the fuel tank. The instrument cluster is very picky about the correct resistance and will simply bottom out the gauge if out of range. Afterwards the instrument cluster must be restarted to forget the error.

Luckily the resistance is measured vs. GND, i.e. the two sense wires (the darker ones, the red is GND) must be pulled to GND via some resistance. I use a pair of BC547 NPN transistors that connect to a 17kHz PWM via a 20Hz low pass filter. Thus their "resistance" to ground can be controlled via the dutycycles of those PWMs. When the resistance on both is equal, about 500 Ohms, the fuel gauge is centered. if it goes lower on one it must become higher on the other one accordingly.

In VCU a base duty cycle of 34% is generated, with one channel falling 0.06% per % SoC and the other rising at the same rate.

Fast Charging

Nissans ChaDeMo socket just fits into the original fuel filler location

Update below!

I decided to use ChaDeMo for fast charging since the Nissan drive stack came with a ChaDeMo connector and ChaDeMo is pretty simple to implement. I had to twist the socket by 90° because that was the only way to fit it. I soldered a shielded Ethernet cable to the control lines and extended the power cables to reach the relay cluster in the exhaust tunnel. I used Nissans original charge port relays that I extracted from the PDM (the module on top of the drive stack). They come with a neat economizer circuit that I use as is.

This PCB contains a CAN repeater, simple relay economizer and drive inhibit logic

Next I had to go about implementing the protocol. The charger will supply the car with 12V and up to 2A. This current must suffice to operate the input relays.

Next up is drive away protection, I decided on a simple hardware logic: when the plug is inserted, the DC relays will not close or be opened if they are already closed. It is a bit dangerous to the relays because they may be forced to interrupt current e.g. if your HV cabin heater is still on at that time. ChaDeMo pulls a pin to GND when inserted. I use that to switch on a small PNP transistor which in turn switches an NC relay which in turn cuts 12V power supply to DC relays. You can see the small relay below the large caps.

Next up the "charge allow" signal. It must be pulled to ground to allow the charger to start. I misused one of the fuel gauge signals for the purpose. It switches on a PNP/NPN pair.

Finally the CAN part. I decided to implement the logical protocol on the existing VCU as it has a CAN interface which extends to the back of the car anyway (because of the BMS). It is powered up by the power that ChaDeMo delivers and detects the charge situation by checking the inverter voltage - it will be 0 because the inverter is not powered up.

Now comes the challenge of using the CAN bus for ChaDeMo. Luckily it is also 500kbit/s and there are no mutual IDs between ChaDeMo and the BMS. But we can't just connect it to the charge port as is because the charger adds additional termination and thus the bus would be terminated 3 times. Also it is not good practice to leave parts of the bus dangling about. So I build a CAN repeater that creates a new physical bus.

The VCU now talks to the BMS which constantly updates the charge current limit. That info is simply relayed to the ChaDeMo charger. If connection to the BMS is interrupted, the charge control signal is turned off.

Trap for young players: The 5V supply to the VCU seems to leak back into parts of the 12V system. So the vacuum pump, also controlled by the VCU turned on and depleted the 5V supply. So I added extra logic in firmware to keep vacuum pump off in charge mode.

DC/DC converter

Ampera DC-DC converter mounted on top of inverter

To keep the 12V system alive, you need to replace the alternator with something else: a DC/DC converter that converts our 380V to 13.8V. Luckily, most off-the-shelve switch mode power supplies work in that voltage range. I use a Meanwell SP-750-12. It is specified up to 370V DC but doesn't complain about 395V either. I replaced its cheap fan by a Papst one to keep the car silent. Also cranked up its voltage adjuster to maximum which is 13.9V.

I added an output relay, otherwise the supply will actually drain your 12V battery when off. The relay is switched on together with the main DC switch. I added another relay to the input, otherwise the DC/DC converter will start up via the precharge resistor and destroy it after a while.

Update: I installed a PTC cabin heater and the 63A of the Meanwell supply was no longer appropriate. So I installed an Ampera DC-DC converter capable of 150A. It is connected to CAN bus so the VCU can set its output voltage. The enable pin is simply connected to ignition 12V. I could do away with the two relays. The unit is bolted on top of the inverter and is air cooled through a small slot in the front grill. That means it does heat up quite a bit when running the heater during standstill.

I tapped into the CAN bus by pulling the round connector from Nissan's PDM (power deliver module, the one that normally sits on top of the inverter). So no that is no longer dangling around unused.

Update2: I fitted an Outlander OBC that also contains a DC-DC converter. I connected it to the car using Nissans rounds PDM connector. That way I can neatly route cables right to left via vacant cables in Nissans wiring loom (I knew why I didn't strip it back then!)


On this connector we find switched 12V, GND and the oil pressure signal (top right)

After powering up the engine I got two error messages: STOP low coolant and low oil level. The first can be solved by filling the reservoir with water. The second is solved by turning off oil sensor support in the instrument cluster.

I programmed the instrument cluster to ignore the missing sensor. You need a CAN OBD adapter with matching software. Then in adaptation channel 39 change value to 0 (=sensor not present). Found here: http://wiki.ross-tech.com/wiki/index.php/VW_Golf_(1K)_Instrument_Cluster

Also the oil pressure switch needs to be faked. Below about 800rpm no oil pressure must be reported. Above 800rpm it must be by pulling the signal to GND. Otherwise you get a "STOP!" message. There is a few seconds time to gracefully switch over. Oil pressure switch is on plug on the front left.

I have implemented the oil pressure faking in my custom ECU.

Update: The threshold for the "dynamic oil pressure warning" can be adjusted down to 0, apparently. In that case it could just be clamped to GND, I reckon.

Counter part of the shown connector has part number 3C0973837.

DSC light

A bit harder to fake was the messages for the ABS/DSC system. It seems all messages originally produced by the ECU need to be on the bus. That is Ids 0x280, 0x284, 0x288, 0x380, 0x480, 0x488, 0x580 and 0x588. So far it seems their content doesn't have to match exactly. See table above.

More connectors

There is another 6-pole connector whos counterpart has part number 1J0973833. Four of its pins end up inside the ECU so it is useful for getting "miscellaneous" signals out of it. I put the oil pressure simulation, DC/DC enable, AC inlet plug present signal and AC/DC enable signal on it.

There is another 10-pole connector underneath the car that has quite a few pins ending up in the ECU. It used to be connected to some kind of exhaust sensor. The mating plug has part number 6X0973815.

I will use it for DC switch, fuel tank fill level simulator, and CAN bus (towards Nissan LBC). I'm doing the latter because the current CAN bus layout gets disturbed by EMI.

Battery Upgrade to 55 kW ID.3 modules

MEB Battery Modules arranged for Touran fuel tank space

To further increase long range ability of the Touran I have fitted a new battery in the beginning of 2024. Coincidentally 8 modules easily fit into the former fuel tank space. While the Nissan module occupied about every millimeter the MEB pack still clears the subframe by 40mm.

The bolting points are the same as for the Nissan pack but I added a forth hole because the 3 holes from before were off-center. So the pack is now held on with 4 M10 bolts and 5 M8 bolts.

The MEB BMS modules are being reused and live outside the actual battery box in a separate BMS box that I bolted to the front. I was again lucky that there are no mutual CAN Ids between the BMS and the rest of the car. There is more bus traffic now as all battery voltages are transmitted in 100 ms intervals. This does not seem to cause issues.

ISA shunt in Touran pack

High level BMS functions such as SoC calculation and dynamic current limits must now be implemented in the VCU. I watched numerous Nyland videos to understand how VW runs this battery. Apparently the maximum temperature is 50°C and full 100 kW charge power is only available above around 25°C. I will probably limit charge power to 80 kW in general as I don't need to churn out marketing figures.

With the removal of the Nissan BMS I also loose the current sensor and I replaced it with an ISA shunt. This is actually a remarkable upgrade as the shunt has much higher resolution and also measures the current draw of the 230V AC inverter correctly. It also integrates the current for Coulomb counting. Furthermore it has 3 voltage inputs that I will be using for charge port voltage sensing.

As opposed to the Nissan pack the new box is designed to be waterproof. This makes me feel much more comfortable when driving in heavy rain.

While the pack was liquid cooled in the ID.3 it is now not being cooled at all or convection cooled at most. Summer time will have to show whether this is practical. The voltage drop under load is much lower than that of the Nissan pack so I expect much less heat. Since I usually drive very economical I don't expect much heat buildup during driving. It's the charging that will heat the pack up.

CCS charge port upgrade

Touran CCS port

Europe's charging network is growing rapidly but only if you have the right charge inlet. Unfortunately the complicated CCS standard has won the port battle. So I bought the CCS port from an MG ZS EV. Its power cables exit sideways which is very convenient in the confined wheel arch. I had to mirror the outlet direction because originally they exited towards the tail light. Fortunately inlet pins and power cables can be separated to allow for swapping them around.

The PE is solidly bolted to the chassis right next to the port. Unfortunately the port locking mechanism did not fit.

One advantage of CCS is the reduced number of signal wires. Only PP and CP need to be routed to the charge controller. In addition I also routed both charge pin temperature sensors resulting in 4 wires total. That said, with the charge port lock (that sits on the EVSE side for CHAdeMO) we'd be back at 8 wires.

For controlling the charging session I use the Fully_Open_CCS_Charge_Controller_(FOCCCI). It sits on top of the battery pack and is accessible via the fuel pump service opening just as the CHAdeMO controller was formerly. Internally it still uses the CHAdeMO CAN protocol to communicate with the VCU.

Nasty stuff

Charger pushing buttons

In summer 2022 I installed a Mitsubishi iMIew/Outlander charger in order to replace the external home-built boost mode charger that had repeatedly blown up. I quickly realized that this resulted in a duplicate CAN Id on the bus - both the charger and cruise control produce message 0x38A. So the charger randomly "pushed" buttons of cruise control. Cruise control data is sent redundant, i.e. an encoded version of the 4 button bits follows the bitmap version. Also the message contains two alive counters. I implemented checks for all this and found no drawbacks to this for over a year and around 5000 km or more (much day-to-day driving, a trip to France and various trips within Germany).

In summer 2023 my wife drove the car to work. While in a traffic jam the car would suddenly accelerate with full torque when coming off the brake pedal. Touching the brake pedal stopped it. Power-cycling finally "cured" it. Many months of investigation were fruitless. I now drove her to work as understandably she refused to drive the car herself. Finally, half a year later when I drove her to work suddenly cruise control was disabled. Then it finally dawned on me - The Mitsubishi 0x38A message contains temperature data and at the right temperatures the message would slip through the checks of the cruise control message and again trigger phantom button pushes on the stalk. The checks had made this unlikely but not impossible. In my case it disabled cruise control. In my wifes case it resumed cruise control.

As a consequence we had added a cruise control torque limit to the inverter. After finding the root cause I added a length check to the 0x38A message. The charger message is 8 bytes, the CC message is 4 bytes. That is a unique discriminator and eliminates the problem for good.

Android radio status web page resets VCU

With the above problem solved in fall 2023 the next one emerged. After working on the battery pack (cell tap wires had come loose) I found I had squished a signal cable between battery and chassis leading to a ground fault meaning the BMS wouldn't start up in drive mode. I fixed the issue and then the real problems started.

The car is fitted with an Android radio that displays a web page served by the ESP8266 module that sits on the VCU. The page constantly polls various values and displays them.

At random occasions the car would loose power, light up the ABS warning light and a second later would resume to drive normally. Naturally I thought this was somehow connected to the earlier issue with the squished signal wires. I started probing for voltage dips and took as much data as possible to track down the issue. I swapped out the CPU board which did not cure the issue. I swapped the ESP8266 and suddenly the problem no longer occurred. I jumped to the conclusion that the ESP board must have injected voltage dips onto the supply rail and thereby reset the STM32 as well. But on the next longer trip I found the reset issue was back. (spoiler: in reality the new module had super poor connectivity and hardly ever worked)

I only ever experienced the spurious resets while driving, never while charging (as indicated by an uptime counter). Which was odd, the car spends a lot more time charging than driving.

Again, months later I was charging and at the same time displaying the same status web page on my laptop that is normally shown on the Android radio. It sat on the secondary screen for hours while I was doing something else. And boom, suddenly I saw the charge power had dropped to 0 and the CPU had done a watchdog reset. The status page must be the culprit.

I set up an experiment on the bench where I bombarded the serial interface with commands. It was only a matter of seconds until the CPU locked up and was reset by the watchdog. It turned out the terminal was prone to "DOS attacks". If, while processing a command, the next command was already sent, this would overwrite the previous commands 0-termination character and cause functions depending on 0-termination to diverge. Turning off command reception during command processing cured this issue for good.

I never figured out why it took this problem 3 years to emerge and then return on a regular basis. Was it some update to web browser? I noticed it kept queueing up requests until they were answered. The connectivity was sometimes poor and when it did return many requests would be fired at the STM32 at once. Maybe earlier versions of the browser didn't queue up that excessively? Maybe connectivity issues had grown worse over time? I don't know.


What is puzzling about both these faults is how long they "slept" until finally emerging. The DOS problem has been sleeping in the software perhaps for 10 years. The CC problem was silent for 1 year. The debugging process also shows that events that precede an error aren't necessarily connected to it. Heuristically we assume a fault to likely be caused by the last change to the system.

Before tracking down the root cause of the faults I had greatly lost confidence in the car. What if the VCU reset occurred while sharply pulling out at an intersection? What if the car self-accelerated while standing close to the car in front of you? I guess you can imagine that this made me a very defensive driver! Finding the root cause has completely restored that confidence - at least for me.