# Electronic ICE simulator to Fool Cars ECU



## DJBecker (Nov 3, 2010)

Thaniel said:


> 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.


----------



## Thaniel (May 25, 2008)

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  (it has been fun so money well spent). But definately would consider another product or controller if better suited.

Thaniel



DJBecker said:


> 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).
> 
> ...


----------



## bjfreeman (Dec 7, 2011)

you instrument cluster is refereed as a instrument panel unit (IPU) BMW may call it something else.
The Can bus message have a format. The are chips that actually decode this. there are thread on This on the forum.
This one address what you are thinking about.
http://www.diyelectriccar.com/forums/showpost.php?p=299121&postcount=108


----------



## piotrsko (Dec 9, 2007)

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.


----------



## DJBecker (Nov 3, 2010)

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.


----------



## DJBecker (Nov 3, 2010)

piotrsko said:


> 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.


----------



## Thaniel (May 25, 2008)

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.



bjfreeman said:


> This one address what you are thinking about.
> http://www.diyelectriccar.com/forums/showpost.php?p=299121&postcount=108


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. 



piotrsko said:


> 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.



DJBecker said:


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


Agreed



DJBecker said:


> 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).



DJBecker said:


> 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.


----------



## Zak650 (Sep 20, 2008)

Since there are companies and people interested in chipping ECUs for performance gains and smog bypass, maybe these same people are interested in Ev chips for our needs.


----------



## piotrsko (Dec 9, 2007)

Thaniel said:


> 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.
> 
> ...


The Canbus hasn't been explored for the hobby level since it hasn't been out long enough to require backyard fixes on vehicles with no resale values. Most everybody gets to the "get it done" phase and since we aren't dealing with emissions any more on a fairly Neanderthal system, One tends to say "enough already". People are just now learning OBD2. I'm sure, however that this forum has the appropriate engineers familiar with the systems lurking just ready for comment and flaming.


----------



## Thaniel (May 25, 2008)

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 

Thaniel


----------



## Thaniel (May 25, 2008)

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)


----------



## bjfreeman (Dec 7, 2011)

depending on how much you want to go, 
here is a ODB2, yes it is a CANbus reader but so is ODB2.
http://www.sparkfun.com/products/10039
code is provided


----------



## bjfreeman (Dec 7, 2011)

I suggest you first get a ODB2 reader, then pull each wire and see what error codes you get.
then based on that decide the design your going to use to compensate for the code.
also see what codes disappear you may have to replicate.


----------



## DJBecker (Nov 3, 2010)

Thaniel said:


> 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).


Coincidentally, I ran into a new guy at work whose former colleagues had this challenge. They had lots of BMW experience, and decided that emulating BMW's engine ECU was the easiest approach. They apparently didn't have too much difficulty figuring out the messages.

He is finding out if they would be willing to share their findings. 



Thaniel said:


> 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?


That's straight-forward to do if you can program a microcontroller.

Set one timer up as an input capture to measure the period of the QRPM (quarter RPM) signal. Divide the measured period count by 15 to use as the period for a second timer channel, and set up an output channel to generate a 25% duty cycle signal. In the overflow/reset interrupt handler for the second timer, keep a count so that you can do the missing tooth in software.

Some sophisticated microcontrollers can be configured do much of the work in hardware. You can set up a /15 clock prescaler on the measurement timer channel, which would let you transfer the capture count directly to the second timer period register. And the missing tooth reference could be done with a DMA from a circular buffer that reconfigures the output timer every cycle. But you'll spend days getting the configuration exactly right. It's much easier to do everything but the timing critical parts (input capture and output signal) in software.


----------



## bjfreeman (Dec 7, 2011)

Thaniel said:


> 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.


I have partnerships with a couple of auto Repair shops that I supply Vehicle Diagnostics, with reports to give customers.
when they get a new vehicle that my system does not handle, it spits out the Canbus stream on a micro SD that they give me to analyse.
then I give them an micro SD they plug in to update the software.


> 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 people that use Arduino have generated many projects around CanBus ODB2, that can get you started. I gave you a link to one such project.
They also have done small motor control projects.

I use a ARM that has the Canbus built into the Board and Micro.

Since I built my converted MotorCoarch ICE to Canbus, in 1999, do to the motor is some 15Feet from the Throttle and the mechanical linkage were failing, I have continued to use CanBus in my HEV conversion starting in 2002. 

Some controllers in DIY EV, monitor the throttle directly to keep the projects inexpensive. only few actually use canbus in the same topology of fly-by-wire.

The CANbus projects I have started, are for the DIY that wants to tinker, I sell the Kits or they can scrounge the parts. I also sell a more advance version based on more powerful micro.


----------



## Thaniel (May 25, 2008)

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


----------



## electricmini (Oct 21, 2008)

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


----------



## Thaniel (May 25, 2008)

electricmini said:


> 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
> ...


Thank you for the link. Reading their pages now.


----------



## bjfreeman (Dec 7, 2011)

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.


----------



## Thaniel (May 25, 2008)

Success... Well the beginnings anyway. We had one controller feed a pulse stream signal to the other and then based on that input send the 60-2 output. And then after some more time managed to get our multi core controller to do it all. So I think we are making progress. Here's a little more detail for those interested.

Finished my trop to Germany and got back to Sweden where my temporary home is. My son and I spent some more time with our micro controlers. We had bought 2 (From parallax). One was a basic one that came in a kit for beginners to learn. The other was more advanced and has 8 processors and I thought would be good for this application. So we started with the simple one and then moved to the complicated one.

Unfortunately despite being made by the same place the more complicated controller programs in a different language. The simple controler is programmed in basic which was quite easy (I've done some programing in the past in several languages). The complicated one programs in a much more cryptic nonstandard language. Not quite assembly but something between assembly and a high level language. We had spent some time with it but I had become disqusted with the cryptic language and was about ready to push it to the side or see if I could return it. I really hated it. But then we got the idea that maybe we could run another language on it. After some searching we found that yes someone had developed a compiler for a more basic style code. SAVED. So we spent time learning the new nuances and getting it sending and recieving pulses. More to come.




DJBecker said:


> Some sophisticated microcontrollers can be configured do much of the work in hardware. You can set up a /15 clock prescaler on the measurement timer channel, which would let you transfer the capture count directly to the second timer period register. And the missing tooth reference could be done with a DMA from a circular buffer that reconfigures the output timer every cycle. But you'll spend days getting the configuration exactly right. It's much easier to do everything but the timing critical parts (input capture and output signal) in software.


Not sure I follow everything you've said (novice remember ). But if I understood what you said we are trying it. What we have done is set up the controller to time the input pulses then use that to send the 60-2 pulses the right speed. My concern was while the controller is sensing the input pulses there would delay the output pulses. With only 4 input pulses and 60 ouput this seems likely. With the multi core controller this is solved by having one of the cores sense the input while another spits out the output. So the output will stay consistant. This seems like it would work and so far on the bench it looks like it is.



electricmini said:


> Just for interest..
> 
> check out the embedded controllers that MicroRobotics have on their website.


After a while of looking I turned it over to my assistant. He says the controlers we have are similar. Ours doesn't do CAN but that's ok because if I go the CAN route I don't think we'll need our controller.



bjfreeman said:


> 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.
> ...


I'll cross my fingers you get one that you could experiement with and help me understand it. I'm still interested in Can bus and will try some after I get some equiptment (may be a few months).


----------



## bjfreeman (Dec 7, 2011)

Thaniel said:


> Not sure I follow everything you've said (novice remember ). But if I understood what you said we are trying it. What we have done is set up the controller to time the input pulses then use that to send the 60-2 pulses the right speed. My concern was while the controller is sensing the input pulses there would delay the output pulses. With only 4 input pulses and 60 ouput this seems likely. With the multi core controller this is solved by having one of the cores sense the input while another spits out the output. So the output will stay consistant. This seems like it would work and so far on the bench it looks like it is.


My approach is to use one with multiple timer, DSP, lots of digital pins, as well as CAN, micro SD. and 186 mhz.
it uses C with a crosscompiler.the light version is free. you can also use the GNU C complier. it is the STM32F4. They have a whole libraty of code including motor control.
they have a Proto board they sell for about $20 at mouser.


> I'll cross my fingers you get one that you could experiement with and help me understand it. I'm still interested in Can bus and will try some after I get some equiptment (may be a few months).


I will pm you if I get one.


----------



## Thaniel (May 25, 2008)

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  

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


----------



## Thaniel (May 25, 2008)

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.


----------



## Thaniel (May 25, 2008)

Think I've gotten about as far as I can go without a car. Here is a video of some more work

http://www.youtube.com/watch?v=UqB4xqDC14c

And a link to some gory details I posted on another forum

http://forums.bimmerforums.com/forum/showthread.php?t=1887229&goto=newpost

Next year when I'm back at my house I'll give it a try on a complete car.


----------



## Old.DSMer (May 18, 2012)

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....


----------



## Thaniel (May 25, 2008)

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.



Old.DSMer said:


> 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).



Old.DSMer said:


> 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.




Old.DSMer said:


> 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]



Old.DSMer said:


> 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.


----------



## circuit (Jan 16, 2012)

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.


----------



## Old.DSMer (May 18, 2012)

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.


----------



## Baldbruce (Aug 1, 2011)

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....


----------



## Zak650 (Sep 20, 2008)

It seems like the cleanest thing to do would be to replace the circuit board in the ecu with a breadboard and re-attach the input headers if what is needed for spoofing the rest of the car can still fit in the ecu's box.


----------



## McRat (Jul 10, 2012)

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.


----------



## piotrsko (Dec 9, 2007)

Ah, but anything with the newer style "sweep" gages need a working ECM for proper buss inputs to the gauge cluster computer. I cant even listen to the radio, open the doors or window on my F 250 without a working PCM.


----------



## McRat (Jul 10, 2012)

piotrsko said:


> Ah, but anything with the newer style "sweep" gages need a working ECM for proper buss inputs to the gauge cluster computer. I cant even listen to the radio, open the doors or window on my F 250 without a working PCM.


What does your truck do if you turn the IGN to the ON position but do not start the engine?

Everything on my cars/trucks work.


----------



## piotrsko (Dec 9, 2007)

unplug the PCM: nothing

pcm installed: normal truck, idiot lights on, etc.


----------



## McRat (Jul 10, 2012)

piotrsko said:


> unplug the PCM: nothing
> 
> pcm installed: normal truck, idiot lights on, etc.


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.


----------



## agazdziak (Sep 24, 2012)

piotrsko said:


> Ah, but anything with the newer style "sweep" gages need a working ECM for proper buss inputs to the gauge cluster computer. I cant even listen to the radio, open the doors or window on my F 250 without a working PCM.


What year is your F250? I will be starting a conversion of a newer vehicle soon - possibly a 2008ish E250 or similar. Not sure what to do about the existing vehicle electronics - it would be nice to use as much of the stock systems as possible.

Systems such as power locks or wipers - do those need the ECU or a similar system to operate or are they much simpler?


----------



## piotrsko (Dec 9, 2007)

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.


----------



## wjones (Mar 4, 2012)

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.


----------



## Old.DSMer (May 18, 2012)

Hi wjones,

I had planned on doing something similar in my conversion. After some scouring of the dealer service manuals, I've decided against it.

Sensors I'd have to deal with (as would most other ICE ECUs):
1. Intake Air Temp (IAT)
2. Intake Air Pressure (IAP)
3. Mass Air Flow (MAF)
4. Crank Angle Position Sensor (CPS)
5. Camshaft Angle Sensor (CAS)
6. Manifold Air Pressure (MAP)
7. 2 oxygen sensors (O2)
8. Coolant Temp Sensor
9. TPS
10. RPM

All these would be related back to the TPS and RPM. Trying to emulate closed-loop operation would be quite involved. Especially considering timing adjustments and variations between the CPS and CAS signals. On top of all that, the ECU with throw a CEL if the O2 values don't fall within standard fuel maps.

Forcing open-loop operation can be achieved by keeping the coolant temp below standard operating temperature. However, my ECU is smart enough to know "how long" the engine runs and if it doesn't detect a change in temp within a certain period of time, it will also throw a CEL.

My current focus is to build a road-worthy and reliable EV. So for me, cutting the CEL wire and re-connecting to my Soliton-1 error light is going to be the solution. I will still keep the ECU reading the speed, TPS, and RPM signals - so all the ABS and Air Bag systems work properly. But all the rest of the sensors will be throwing CELs constantly. My system is not CAN-based, but the modules communicate with a "proprietary" (modified CAN). So far, I have not been able to source that information and have turned my focus back to the actual conversion.

I do admire and appreciate the efforts going into this project though! And I suspect this ground-breaking work will be a staple requirement in modern conversions!


----------



## Baldbruce (Aug 1, 2011)

Most late model cars are far more complicated than just spoofing even just these 10 parameters! The dash in an E46 or the newer E90 series are completely run by a computer. There are up to three seperate comunication busses in the car with the primary one between the DMECU, the instrument panel CU and 4 other CUs done in CANbus. Instrument CU has indicators and symbols all over the place and most are LED or LCD based. No "just cut a wire and splice it into your warning light" is even possible here. My E46 manual has 483 pages of wiring diagrams! BMW may have been ahead of their time in switching to so many computers talking to each other in a car, but all the other OEMs have already followed suit. Makes sense from their perspective since they have made a system that allows for complete model plug and play options and saves them cost and time on the wiring system.

This is an issue with all late model cars that remains to be solved. We will get zero help from the OEMs becasue they have no desire to disclose their propietary CAN bus coding. Will be interesting if any secondary market support develops for these like it has for the chip tuners.....


----------



## wjones (Mar 4, 2012)

@Baldbruce
You are right, there are multiple CU's to attempt to decode, and the dash, body, climate... CU's may be best split to another thread.
If we try to break down the big picture and focus on the ICE,as we go, we will learn what is required for the other CU's

This will become more difficult as the sensors move from analogue to addressed

If the ICE is of an era based on analogue or 1bit digital sensors then it may not be too bad.

If the ICE was up to temperature and driving along a flat road at consistent altitude on a 20degC day, at any given speed the sensors would be relatively constant.
Therefore running through the list...



Old.DSMer said:


> Sensors I'd have to deal with (as would most other ICE ECUs):
> 1. Intake Air Temp (IAT)
> 2. Intake Air Pressure (IAP)
> 3. Mass Air Flow (MAF)
> ...



The IAT and IAP will be fixed values.
MAF - relative to RPM, (based on engine capacity * rpm /2 for 4 stroke)
CPS and CAS - relative to RPM, unless there is an active camshaft like the VANOS. Nevertheless at a fixed speed the CPS and CAS should be values relative to RPM.
MAP - depending on where it is located, if it is on the atmospheric side of the butterfly then it would be ambient air pressure - Fixed value
O2 sensors - again at a fixed speed the ECU will be expecting our logged values
Where it becomes difficult is if the ECU is monitoring the change in RPM and is expecting large variations from the O2 sensors
Coolant Temp Sensor - Fixed value
TPS - This will likely be the driving variable if the ICE is fly by wire, but again at our fixed speed it will have a value relative to RPM
RPM - will be the key value in our lookup table for sending logged data to the ECU

By removing the fixed value sensors from the equation, leaves only a few to datalog.



Baldbruce said:


> ... Will be interesting if any secondary market support develops for these like it has for the chip tuners.....


*
That's US! Let's see if we can crack it!* 

Start from the first principals of the ICE only.
How does the ICE work manually.
What does the ECU need to see.
What does the ECU need to send to make the ICE function.

Let's hope there is no closed loop interaction to the gearbox or torque sensors to start with.


----------



## Old.DSMer (May 18, 2012)

@Baldbruce,
Definitely agree with you. Any modern vehicles on CAN will have to be fully integrated. Way over my head 

@wjones,
You are correct - the sensors could be logged at various RPM levels and TPS positions. Then those values could be fed back to the ECU once the EV conversion is done. However, in my case (since its a turbo), the MAP sensor is not a fixed value. Neither are the O2 sensors (constantly changing based on RPM, TPS, and changes in those). Most 02 sensors constantly fluctuate depending on the PWM signal sent to the injectors (controlling Air/Fuel ratio). And also, my ECU monitors engine temp changes - so I'd have to do something with that as well. This is especially true in closed loop operation. Open loop is easier - but the ECU will only allow open loop for a certain period of time before it throws errors.

Definitely doable for one given state change of the engine, but time consuming. Separate data would need to be collected for different acceleration rates (or changes in TPS). And programming is not my forte...so fortunately (and hopefully), I can make a simpler solution work.

I'll be watching progress on this CAN interface though - its going to benefit so many converters out there!


----------



## Thaniel (May 25, 2008)

wjones said:


> 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.


 
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.


----------



## Thaniel (May 25, 2008)

Baldbruce said:


> 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 ?

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


----------

