DIY Electric Car Forums banner

Electronic ICE simulator to Fool Cars ECU

45K views 44 replies 12 participants last post by  Thaniel 
#1 ·
Hello all,

I've been thinking about this for sometime. I've not read about anyone doing this so makes me think it is really difficult a stupid idea or something really clever. If I have missed a post or thread regarding this topic this please direct my attention there.

Some of the newer car's throw codes when the car's engine has been removed and replaced with an electric motor. Have been thinking what if a electronic device similuated the engine outputs (crank sensor, o2 sensors etc) based on some inputs (vehicle speed, pedal position, electric motor RPM) to make the car's ECU that the engine was still there. Might also solve some issues with auto trans computers.

I've purchased some microcontrollers have started learning and playing with those. (My electrical knowlege is novice level.) From what I've tried so far it seems that it should be possible to do. So makes me think that it must have been done already or there is a reason it hasn't been done.

So looking for your expert advice and direction. Is there something out there that would do this "off the shelf" If not what hardware would you recommend one should use? What I think I have might work but open to new (better) Ideas.

Oh bit more information for the curious. I will be changing my EV from a '93 BMW E36 to an '99+ E46 (probably next year). With the more complex electronics the tach and several other instruments are driven by Can bus signals from the ECU instead of engine signals. Seems converting my electric motors RPM signals to imitate the ICE RPM would be easier then trying to interface with the can bus system. Then if I could imitate a few more signals I could keep the check engine light off.
 
See less See more
#2 ·
Some of the newer car's throw codes when the car's engine has been removed and replaced with an electric motor. Have been thinking what if a electronic device similuated the engine outputs (crank sensor, o2 sensors etc) based on some inputs (vehicle speed, pedal position, electric motor RPM) to make the car's ECU that the engine was still there. Might also solve some issues with auto trans computers.
...
Oh bit more information for the curious. I will be changing my EV from a '93 BMW E36 to an '99+ E46 (probably next year). With the more complex electronics the tach and several other instruments are driven by Can bus signals from the ECU instead of engine signals. Seems converting my electric motors RPM signals to imitate the ICE RPM would be easier then trying to interface with the can bus system. Then if I could imitate a few more signals I could keep the check engine light off.
There is a lot more to simulating sensor signals than you expect. And if you don't do it perfectly, the engine computer will raise error codes and may switch into 'limp home' mode that might impact the transmission.

An E46 will have a dual-VANOS engine, knock sensors, and multiple oxygen sensors. M52tu and later engines will have an electrically controlled thermostat and a throttle position over-ride (partial throttle-by-wire).

Each of these systems will have to be simulated, and some can be quite complex.

VANOS is one of the easier ones to simulate. It is a system that adjusts the camshaft angle relative to the timing chain sprocket. Each cam has a solenoid valve controlled by a PWM input signal, and a camshaft position sensor. You might be able to get away with not precisely modeling how the slowly the actuator moves in response to the input pulse duty cycle, but you must generate the sensor signal or the ECU will go into limp-home mode. That involves figuring out the levels of the original actuator and sensor signals, measuring the timing relative to the crank position, designing the interface electronics, and writing the software.


In comparison, writing the software for a CAN bus message exchange is easy. Not trivial, but far easier than designing the interface electronics and firmware for an engine signal simulator. You could probably find a handful of people that would help with a firmware-only CAN bus project, while a engine simulator would be a multi-discipline project that would apply only to a single engine and would interest very few other people.
 
#3 ·
Hi, Thank you for your reply. It intriques me that you feel connecting with the canbus would be easier. You wouldn't happen to have some knowlege in that area? Ditching the orignial ECU would would be the "cleanest" solution but from the research I've done so far seems even more difficult than simulating the ICE. I had actually wanted to go that route and started reading about can bus. I couldn't find any real solutions. Let me share more of what I've found and feel free to poke holes in it.

The main issue I've read with integrating to the can bus is that the messages that are sent to and from the modules are not known or published. And trying to capture them by sampling the bus is next to impossible (I haven't tried this. Just going by what others have said). The ABS, Dynamic Stability Control and Transmission (if using an auto) I think would be the hardes ones to set up comunication with.

Fooling the ECU by simulating the engine on the other hand. The signals for each sensor can be found in the Factory repair and service manuals. And also the conditions which will trip a code. The ECU is not really that picky as the engine is not really that precise. Vanos for example is just a hall effect pulse that advances or retards when the vanos solenoid recieves a 100-220 hz signal. how much does it retard. The solenoid controls only oil flow which moves the cam position and so it varries with engine temperature. So the ECU just keeps varying the signal and checking the cam sensor till it gets what it wants. Seems simple enough for a micro controller to do.

Yah the ECU has a lot of wires in and out (108 aproximately) but half are grounds and most are just sending out signals that are not checked (Coils and injectors for example) Some others can be handled by just leaving the parts to do their thing even without the engine (throttle pedal sensor and throttle plate control) though similuating them could be done too. Most of the temperature sensors can be replaced by a fixed resistor for what would be operating temperature (car doesn't know how long the engine is off so will think it's just shut off and restarted) From what I've read the Crank sensor, Cam sensors, O2 sensors and a few others should keep the codes off. (o2 sensor simulators are already on the market with no ECU feedback so that can't be too hard)

Just so you don't think I'm all talk I've already spent around $400 on 2 micro controler kits and spent hours with my son learing how to program them. We can make LED's flash on and off with the best of them :D (it has been fun so money well spent). But definately would consider another product or controller if better suited.

Thaniel

There is a lot more to simulating sensor signals than you expect. And if you don't do it perfectly, the engine computer will raise error codes and may switch into 'limp home' mode that might impact the transmission.

An E46 will have a dual-VANOS engine, knock sensors, and multiple oxygen sensors. M52tu and later engines will have an electrically controlled thermostat and a throttle position over-ride (partial throttle-by-wire).

Each of these systems will have to be simulated, and some can be quite complex.

VANOS is one of the easier ones to simulate. It is a system that adjusts the camshaft angle relative to the timing chain sprocket. Each cam has a solenoid valve controlled by a PWM input signal, and a camshaft position sensor. You might be able to get away with not precisely modeling how the slowly the actuator moves in response to the input pulse duty cycle, but you must generate the sensor signal or the ECU will go into limp-home mode. That involves figuring out the levels of the original actuator and sensor signals, measuring the timing relative to the crank position, designing the interface electronics, and writing the software.


In comparison, writing the software for a CAN bus message exchange is easy. Not trivial, but far easier than designing the interface electronics and firmware for an engine signal simulator. You could probably find a handful of people that would help with a firmware-only CAN bus project, while a engine simulator would be a multi-discipline project that would apply only to a single engine and would interest very few other people.
 
#8 · (Edited)
Thank you for your comments. Please continue to throw in your thoughts as it is very much appreciated. Sorry for the long post but want to ensure I'm conveying the right details.

So far my take aways are:
-Can bus might not be a bad as I've thought. But to progress much will need to have the car in hand to measure signals.

-While engine simulation may be possible most feel it's not worth the effort and why it hasn't been done (they may be right but I'm not ready to give up yet).

Here's a specific question I'm looking at. My EV motor will have an RPM sensor (Hall effect) on it that gives 4 pulses per rev (for RPM signal to the controller). What hardware/software would you suggest to translate that RPM signal to one like a 60-2 wheel hall effect signal? (doesn't have to be off the shelf. I'm willing to solder and program) I've used converters on other car projects to convert one RPM frequency to another. But so far haven't found anything pracitcal for converting to a RPM signal with 2 missng teeth. Yes I could mount a 60-2 tooth wheel on the EV motor and another sensor but I'd rather not do that if I can help it.

Thank you for the link. I need to read more but looks like you are successfully conecting into a vehicles Canbus? I started to read from the beginning of the tread your post is in and my head started to spin. (edit: reread the thread and halfway through realized I'd read it some time ago. Memory is the first thing to go. At this point I have no interest in hooking my EV's controller to the Vehicle's can bus. Just getting the vehicle happy to be without an ICE). I need to look more into what you've done as I like to read about sucesses. For awhile I can't do much sampling of the actual bus as my car is in the USA and I'm in Sweden.

My $.02: I agree that fooling the ECU won't be that hard, especially if the first experimental pass uses the original factory sensors / termination devices with a couple of discreet resistors. sine wave generator for the motor pulses, go until you get a error condition, back up a step.
This is basically my plan. Building a circuit and the test it and compare to the few factory specs I have for the signals. Once I get it to meet the basic specs install in the car and adjust from there. Figured I'd need something that could do logic so got some controllers designed for controlling little robots and such (was an educational kits for beginners). That's when I got the bright idea to ask some experts what should I really be using. All the EV conversions I've read I've never read about anyone doing this. Though some make the controler for the EV motor from scratch. Obviously very smart folks so makes me second guess my plan a bit.

The ECU is pretty tolerant of the exact response to some signals, but it does want to see a response.
Agreed

I don't know if you can ignore the injector and ignition signals and just use an O2 "sensor simulator".
That could be true. The front o2 sensor may require some active adjustment. Or like you say keep it in open loop mode. Now that I think more about it the rear 02 sensor is where I've seen the simulators used (people removing the catylist).

Anyway, back on point: you'll have to figure out the CAN bus messages, but that's not impossibly difficult.
Not sure I follow here. My thought is to simiulate the motor so I don't have to get into the can bus. The projects I've read about never got into the can bus but just let the check engine light be on (or removed it) and circumvented the systems that didn't work when the computer didn't recieve proper signals.
 
#5 ·
My $.02: I agree that fooling the ECU won't be that hard, especially if the first experimental pass uses the original factory sensors / termination devices with a couple of discreet resistors. sine wave generator for the motor pulses, go until you get a error condition, back up a step. Figure about 20 devices total. If you can keep the ECU in open loop, the job is much easier, since the ECU ignores some sensors and uses a look-up table for others.

From what I've heard, CANbus is the automotive equivalent of Ethernet with addresses and interrupts, and data packets. That is what I've heard, no guarantee of truth there.

That is the "fun" of prototypical experimentation, no BTDT.
 
#7 ·
From what I've heard, CANbus is the automotive equivalent of Ethernet with addresses and interrupts, and data packets. That is what I've heard, no guarantee of truth there.
Only the same as Ethernet in that it's a network. If you "just like Ethernet", it will take longer to get your head around it. The IDs weren't designed as addresses, but they ended up being used as addresses. You often have devices listening for multiple IDs, or ID ranges, while multiple devices listen on the same ID.

The tiny frames mean that most messages only carry one or two fixed-format values. Longer messages require something like ISO-TP, which has high latency.
 
#6 ·
The ECU is pretty tolerant of the exact response to some signals, but it does want to see a response.

The VANOS system is a good example. It will adjust the solenoid PWM duty cycle until it gets the cam advance it wants. It doesn't care if it's 20% or 80% duty cycle. But it requires a pulse every cycle from the cam position sensor, and will eventually want to see the proper advance. So you have to monitor the PWM well enough to notice it changing, and adjust the phase delay for the cam position output to match.

I don't know if you can ignore the injector and ignition signals and just use an O2 "sensor simulator". Some ECUs measure the response time between deliberately enriching the mixture and when the lambda sensor reports decreased oxygen, and use this delay to monitor performance. Sensors typically go bad by becoming coated with impermeable gunk (notably lead and silica), which results in a slower response.

Anyway, back on point: you'll have to figure out the CAN bus messages, but that's not impossibly difficult. I'm sure there are people that have done the opposite side -- gotten an "OBD2" engine to run in a pre-OBD2 body.

Monitoring CAN bus messages isn't difficult. You can even use a cheap ELM327, just be certain to get a serial port version so that you can increase the baud rate to have a better chance of not dropping frame.

Once you have captured the frames, decoding the undocumented ones involves a bit of guessing. But the guys that designed the messages weren't out to make it difficult. The fields are usually one or two full bytes, with values matching the OBD2 parameter scaling.
 
#11 ·
After a bunch of searching and reading So far the best source for Engine emulation examples I have found have been from folks bench testing stand alone ECU's (Like Megasquirt).

This is an example simulator http://jbperf.com/JimStim/index.html Seems to be built around the LM1815 chip http://www.ti.com/product/lm1815 But since the "jimstim" is for bench testing there are pots on the board to vary the RPM. I want to tie it to my EV's motors RPM. Also not sure eactly how the other signals outputs are controled.

It seems the building blocks are out there just need some knowlege on how to put them together. Being a novice at this stuff it's hard for me to figure it out :confused:

Thaniel
 
#12 ·
Thanks piotrsko. Have a suggestion for a hexidecimal converter? yes I need to pick up a 555 chip and play with it. Hoping to make a list of possible parts and probably pick them up when I come back to the states in July or order them all in one shipment to me here in Sweden (shipping to here is expensive when I find a company that will do it)
 
#17 ·
Thank you for the info. Sorry I can't do a better job of quoting but I'm on the road an I am terrible doing that with my iPad.

Would be great if someone with e46 would share their findings. At the very least what it took to get where they are.

I'm still trying to learn more about electronics and can bus. I think I'll buy a reader card and see what trouble I can cause. Figure it has to be useful some time.

Last night my son and I hooked up one micro controller to simulate me evs rpm output and feed to the other which is we are trying to make convert to th 60-2 output. We were making progress but ran out of tim. Have to do more later
 
#18 ·
Just for interest..

check out the embedded controllers that MicroRobotics have on their website.
Their high-level "Venom2" language is easy to program, and provides
objects like PulseWidthIn (which can measure the frequency of a pulse train), even
a CAN-bus object that can send/receive CAN messages

If you want to get something up-and running quickly, this is a great way to go

Richard
 
#19 ·
Just for interest..

check out the embedded controllers that MicroRobotics have on their website.
Their high-level "Venom2" language is easy to program, and provides
objects like PulseWidthIn (which can measure the frequency of a pulse train), even
a CAN-bus object that can send/receive CAN messages

If you want to get something up-and running quickly, this is a great way to go

Richard
Thank you for the link. Reading their pages now.
 
#20 ·
this thread spawned a vertical market for me.
I put out the word to all the Auto junkers to donate the ECU and other controllers from cars they send to the smelter.
I am also doing Pre Can bus mostly Smog computers.
Got my first lot today.

based on statistics fall and winter will be when the most major crashes happen, so I don't expect to get to many during the summer.

Hopefully I will snag the ECU you need info on and will set up a test bed for it.
 
#23 ·
Have to have pictures right? Well not a lot to show but a bunch of squiggly lines. But it feels like a success to get them to squiggle when I want :D

Based on an incomming pulse it now simulates the 60-2 output and 2 cam outputs. The 60-2 output varies based on the frequency of the input pulses. The cam outputs are set up to vary based on a set of variables as well. I just need to set it up to sense the incoming 100-220 Hz signals and set some variables. Add a few more signals to it as well. It all seems very doable. Just a lot of tweaking and programming adjustments. Wishing I could try it out on the car. Oh and a picture our work area.

Thaniel
 

Attachments

#24 ·
I find myself being swayed to the side of remove the ECU and just talk to the car with can bus. Here is my work so far in that area:
http://www.youtube.com/watch?v=FTOrUbbu_RU

I have the can bus shield recommended by Bjfreeman and an Ardruino Uno micro controller. Driving the RPM and temp guage of an E46. Seems like a very possible solution.
 
#25 ·
#26 ·
Interesting discussion here - and I'm on the verge of fighting this battle myself.

I think we must input a minimum amount of signals to keep the ECU happy and corresponding systems working properly.

The ECU in my '95 Eagle Talon is OBDII compliant. And does some minimal CAN communications. However, thats just for communicating information. Don't we still need to 'feed' signals into the ECU to keep it operating?

In my research, I have found (as have others here) that the open loop mode is the easiest to work with. Usually the O2 sensors are ignored. We don't need to run an engine, so the idle control motors, throttle position sensors, crank/cam sensors, injectors, fuel systems, etc...etc...are not required. Unless, of course, the crank sensor is used for RPM. Then we'll need to generate a signal for that - presumably based off our electric motor RPM.

So my question is : do we know what the minimum signals are in order to keep the ECU happy in open loop mode? And by happy, I mean, not throwing any CEL codes.

For now, I'm thinking fake signals for the following:
1. MAF signal to force open loop. Or fixed low engine temp instead.
2. RPM (crank position?)

Outside of that, I guess you could intercept and change the codes being passed through the bus between controllers. But, wouldn't it be easiest to just let the system handle itself?

Any ideas what other signals might need to be generated? I'll be doing some testing over the next few months....
 
#27 ·
Hi Old.DSMer. Glad to have your comments. I'll try to share what I've found out.

Yes there are definately 2 ways to go. Fake out the ECU or take out the ECU :) Removing the ECU and replacing it with a microcontroller to send out the correct signals over tha can bus was easier than I thought it would be. but both methods appear would work.

I think we must input a minimum amount of signals to keep the ECU happy and corresponding systems working properly.

The ECU in my '95 Eagle Talon is OBDII compliant. And does some minimal CAN communications. However, thats just for communicating information. Don't we still need to 'feed' signals into the ECU to keep it operating?
Would have to look into what the ECU actually does for your car. For example does it send the RPM, temperature and check engine light signal to the instrument cluster over the can bus or through seperate wires? What messages does it send to the "corresponding systems" and how. If by can bus then it is probably easier to remove the ecu and replace it with a micro controller that sends the right messages to the other systems. IF it is not comunicating over the can bus then I'd look at removing the ECU and sending the needed signals directly. In other words wire up the check engine light and RPM to your controller and maybe temp (depending on the controller).

So my question is : do we know what the minimum signals are in order to keep the ECU happy in open loop mode? And by happy, I mean, not throwing any CEL codes.
This will vary by car. The BMW needs Vanos signals (cam advance information) but other cars may not even have that feature. CEL codes can be set by many many many things. It is quite difficult to mimc all the signals needed. But not impossible. But things like the Evap system, MAF, Crank angle, TPS, Temperature would all be needed. Some cars are even smart enough to check to see if the temperature cycles from cold to warm like it should and if not throws the check engine light.


I guess you could intercept and change the codes being passed through the bus between controllers. But, wouldn't it be easiest to just let the system handle itself?
I'm not intercepting the messages. I am simulating the ECU messages and the ECU won't be in the car. My current set up sends the messages over the can bus that the ECU would send. RPM, Temperature, throttle position, Check engine light (status), over heat light (status), RPM injector pulse width (for MPG). As far as the other modules in the car can tell the ECU is still there. But now it's fully programmable and can react to inputs I choose. Actually much easier than trying to simiulate the engine signals and hoping not to make the ECU angry :). And turning the check engine light off or on is a simple as a line of code in the controllers program. [/QUOTE]

Any ideas what other signals might need to be generated?
My suggestion is to get a list of error codes for the ECU. This will list when the check engine light will come on. If keeping the ECU those systems are the ones that will need simulated.

Comments welcome. I think interfacing with newer cars can be simpler than we make it out to be.

Thaniel.
 
#28 ·
What we did was a hack into CAN BUS, sniff all the packets and reverse engineer them. Then ditch the ECU and build our own, which not only simulates original ECU, but also interfaces all our systems to the car's network, enabling all the systems to operate normally, i.e. the dashboard operating as usual (RPM, "fuel" (energy), etc).
It wasn't a one-day deal, required a lot of hours and development.
 
#29 ·
Thaniel and circuit, thanks for the replies.

I have an elm327 and I can get some info from the ECU. I'm probably going to have to do something like you guys did and tap into the bus where I can see all the data.

However, I think my first attempt will be forcing open loop with minimal signal input. Not sure I have the capabilities to replicate an ECU like you guys do! Also, my gauge cluster appears to be driven by separate signals, not CAN messages, so it will hopefully be easier for me to fake things. I found a wiring diagram for the ECU but have not yet located a list of codes. Gotta keep working on that one. Apparently there is "manufacturer specific" data communications - requiring "special" readers and diagnostic units. So I have to dig deep to find out (or hopefully find out) what it all means.

Thanks for posting all the earlier links and info. I'll definitely be doing more reading and learning.
 
#30 · (Edited)
Great work Thaniel! I read your posts here and the Bimmer forum with great interest and even greater respect for the effort you are putting in to figure this out. I currently own an E90 series and am considering converting it or an E46 series to EV.(Leaning towards the E46 plan at the moment.)

Any comments on how much alike an ECU replacemnt might be between these two series? I am a power electronics engineer with some amount of programming experience, but much more harware experience. How can I be of assistance in moving this information gathering forward? Better to gather more data or better to build the black box to try to test the implementation out?

P.S. Already have converted older EVs, but the ECU issue is holding me back on doing late model cars....
 
#45 ·
I currently own an E90 series and am considering converting it or an E46 series to EV.(Leaning towards the E46 plan at the moment.)

Any comments on how much alike an ECU replacemnt might be between these two series? I am a power electronics engineer with some amount of programming experience, but much more harware experience. How can I be of assistance in moving this information gathering forward? Better to gather more data or better to build the black box to try to test the implementation out?
Sorry Baldbruce for missing this post. I'd love to have some assistnace. I'm weak on the hardware side and tend to copy others where I can in that department. Drop me a PM or e-mail on your interests and what car's you have access to if you'd like to do some testing or add data etc. At this point I think we are ready for some in car testing. How close are you to doing a swap on a can bus car :D?

BMW does use the same can messages on many of it's cars. For example the E46 shares much of the same coding as the BMW mini and E38 not sure what else (and even some Landrovers made when BMW owned them from what I've been told). However the E90 I believe is on the newer can bus system. Perhaps it is more like the E65? Here is a link to some can codes I found for it. http://www.carx24.de/E65_Codes.xls

Would be easy enough to check what type of messages it has. And I'm pretty confident one could reverse engineer the can codes on another car. Let me know if you want help trying.

Thaniel
 
#32 ·
Some factory ECM can be heavily reprogrammed to turn off all OBDII testing. I do General Motors only, but I can do some really cool tricks using EFILive (cheap).

That being said...

Why are your worried about emulating?

First, turn the ignition to run ON position, but do not start the car.

Now tow it with somebody in it. Does the speedo, windows, and ABS work?

If so, why emulate it? Just turn the ign to RUN, put a relay on the ign wire to activate the electric motor controller, etc. Leave the ECM, BCM, Speedo, ABS, computers in it. Just remove the motor.

Without the ability to reprogram the ECM, trying to emulate might be harder than you think. It looks at the MAF signal and the EGR (if equipped), and baro pressure, and manifold pressure. If it doesn't agree with the pre-defined tables of operation, it "guesses" at which sensor input is causing it, and throws the appropriate code. ie - It might throw a bad MAF code when you actually have something else amiss.

So why emulate it, if the stuff you need works with power to ECM and no engine running yet? If the speedo comes from the wheel sensors or differential sensor, it usually operates without the engine RPM signal.
 
#36 ·
No, you need the PCM. You probably don't need the engine. Just unplug it at the bale connector. Most cars have a master connector to remove the engine. The service manual has the pinout for that connector if you want to feed RPM or a fake manifold vacuum signal to the PCM.

OK:

ECM: Engine Control Module.
PCM: Powertrain Control Module.

These are often used interchangably.

A PCM might also control the auto trans, but many that are called ECM's do it as well.

I like ECM. Because some cars have a separate TCM (Trans computer), and some don't. Calling it a PCM dictates it controls the trans.
 
#38 · (Edited)
2000 diesel F-250. the PCM controls all the powered functions as a supervisory function so apparently it won't kill the battery if something is left on or fails shorted. I suppose you could jumper all the control relays to ground, but I think that there are about 20 of those scattered everywhere.

If I was converting mine, I would leave the pcm there, disconnect just the engine harnesses, Pull the IDE, and not worry about the check engine light being on. Cruise control would be a pain, but that is because it is a diesel. All of the major inputs are generally analog except for rotating/ timed. Gassers are somewhat easier, but Ferd in it's wisdom makes the control systems interchange, so yours would be pretty much the same as mine. You do require a good series of wiring diagrams, chilton won't cut it.
 
#39 ·
Hi Thaniel
Along the lines of McRat, have you considered logging the engines sensors? (at least the ones required by the ECU of course)
i.e. Start the engine, drive up to speed, slow down and stop. Map these to your rpm and output the data that the ECU expects.
You are possibly too far advanced to take an alternative approach now, but it might be something to consider for others attempting this.
 
#44 ·
Sorry I lost track of this tread for some reason (e-mail updates not working for me?). I had looked all the possible error codes for the engine and then what data is needed to turn them off. For the engine I was looking at it was about a dozen or so sensors would need to be imitated. Logging the engine would be the best bet.

Since I started down the can bus side i've not looked back. It is so much easier to just tell the rest of the car the engine data via can (and check engine status) then trying to convince the ECU to report the values. The only difficult part is getting the can codes to start with. I'm thinking with the right procedure it could be simplified to a science and not that difficult.

I've created a post to show some of the completed work http://www.diyelectriccar.com/forums/showthread.php/my-can-bus-gauge-solution-bmw-84882.html

I'm confident it will work well in an EV. Once I get back to the states perhaps I can do some in car testing. Though it may be quite a few months before I can get time to convert my E36 to the E46 (E46 uses can).

Feel free to ask questions (i'll find the e-mail notification setting). I did all this so we all can benefit. Just as those that have passed on information have done for me.

Thaniel.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top