# Conversions and ECUs



## gdirwin (Apr 7, 2009)

I just went through this for my 2001 REV4 (Toyota RAV4) - I originally planned to keep the ECU and fake out all sensors. This car has many things which hook into the ECU, including Airbags, ABS brakes, Air Conditioning, tachometer etc... so keeping the ECU is a must (IMO).

I started by measuring resistances of all sensors, and noting what trouble code I got if I left a sensor open (using an OBDII USB ELM327 device that connects to your laptop - less than $50). I quickly gave up - some sensors (such as temperature etc... are simple and have only 1 or 2 wires and are simple resistors - some (such as MAF mass air flow and oxygen sensors) had 4 or even 5 wires and were too hard to deal with. I will disconnect the trouble light and hook it up to an output from the controller - if I read the ODBII trouble codes I will get a few that will always be there. Maybe later I can spend time to remove a few...

One area where a lot of others have spent effort is to get the stock tach to work - the ECU can be bypassed if you send signals directly to the dash. 

In my case I found it easier to keep the stock wiring - there is a sensor connected near the front of the crankshaft (crankshaft position sensor) that sends out a signal every time a metal tooth in a wheel passes - I plan to get a 36 toothed wheel and connect it to the 2nd output shaft of the motor (welded to the Air Conditioning pulley) and will use the stock CPS/CKP sensor - the ECM is still in the loop.

I got lots of help from others here - this is a great forum!

Hope this helps...


----------



## Dave Koller (Nov 15, 2008)

http://www.diyelectriccar.com/forums/showthread.php/getting-rid-pcm-saturn-30356.html

Fooling the ECU (PCM, ECM, or whatever) is a pain as most have found - on my Saturn the Airbags are NOT on the PCM - but one can take a lot of the OUTPUT of the PCM and bypass those to make things work.. I have everything working past the PCM but have kept it for the speedometer and odometer as decribed in an older thread of mine (see above) till I build that circuit to pick up the VSS of the transaxle ... 

Some newer cars have a network that can be hacked with your own embeded processor... BUT... well you get the idea....


----------



## pgrovetom (Oct 6, 2009)

Thanks

I'm not sure what year the first car began using a micro-controller to manage, coordinate or report driver data ( tachometer, speedometer etc) and provide diagnostics. I do know that I looked at my 2004 Corvette ECU and related schematics and it was frightening. I have an engineering and computer science background and long ago wrote software and designed the hardware in a number of telecom system projects. Its one thing to fake fixed resistances and quite another to simulate dynamic conditions. It appears my Corvette ECU system is involved in just about every system in the car. There are ones that concern me like the active suspension, traction control, brakes, airbags etc.. If the ECU only reported to the dashboard, it would be possible to disconnect and intercept and try and fake the EV equivalents. 

But if the airbags, brakes, suspension etc.. somehow need the ECU to operate correctly, that is bad. My intuition tells me the auto system designers would not design the car such that a major safety system like the airbags, suspension or brakes would rely on the ECU. The reliability requirement for a life saving system like an air bag or brakes cannot depend on the ECU. 

Is this something every EV conversion just works through or are there techniques for testing ECU pervasiveness prior to choosing a car as a donor. 

It would be very ugly to go through the conversion process and learn late in the game that something critical like ABS brakes, airbags, active suspension, transmission etc.. required the ECU and faking it isn't possible. This is why most general EV recommendations for selecting a donor suggest an older car. The very old car's ECU is less involved or doesn't exist but newer cars have nicer interiors and lots of desirable things but ECUs that are very involved!

I've done a lot of online reading and downloading and have yet to come across a real discussion of dealing with ECUs. That's somewhat baffling or maybe its not been a big issue beyond the instruments. But I can imagine everything from auto alarms to power seats, air bags, heater, air, radio, ABS brakes, lighting, steering, steering wheel lock, blinkers, horn, windshield washers and on and on somehow hooked into the ECU. I guess as long as they can't be disabled by the ECU and only report to it, then its ok. 

I wonder if anyone has ever checked into an ECU ( or whatever its called in different vehicles) and found its reset input and brought it into the car so it can be disabled safely while driving or rolling once its pushed. Then one could at a standstill or rolling while driving, hold the ECU in reset and see what systems won't work. The engine will probably die which in turn will kill the vacuum pump and everything relying on the engine rotation. The +12v system will operate on the battery for a while so anything running on the 12V system should be ok unless the ECU somehow has some control over it. It would be weird if the ECU was reset and the horn went off, brakes locked up, wipers started, radio died, seats went to full forward, transmission locked up... just kidding.

Is there anyone out there who has a good understanding of the design rules around ECUs in the newest cars? I do know that in a Telecom System design, the main control CPU would never be given critical control without duplication to protect against failures. The processor that monitors for problems or sets options but isn't service effecting isn't always duplicated. The auto industry must have a design philosophy around the ECU. For example, if it failed while you were driving at 70MPH in the rain, it cannot be allowed to interfere with stopping the car safely, I would think. That would be good and mean the problem is contained to faking out displays and such.

any thoughts?

Tom


----------



## Dave Koller (Nov 15, 2008)

And there you go! I found (in my 99 Saturn) the PCM does not tangle with the critical systems! But can report them back to you I would suggest getting (involves paying or borrowing) a good shop manual with electrical diagrams of your car FIRST - then see what controls what! You and I have worked in similar systems and hardwire to sensors is more like it.. PCM's fail!

So that leaves what? Bypassing is better than failure lol! KISS (keep it simple) - er - maybe it's not BEFORE the PCM but it has to be after !


----------



## pgrovetom (Oct 6, 2009)

I guess the problem can be broken into two categories:

Things that the ECU pr PCM control and those they monitor

1) If the computer control something, then it has the potential of causing functional problems which in turn is alos divided into two sub-categories
a) Controlling things unrelated to an EV application like ICE engine valve
b) Controls something necessary on an EV application like clutch, transmission, comfort feature etc..

and

2) It monitors and somehow reports conditions ( RPM, Speed, Temperature etc..) or reports diagnostics

I am looking at the schematic of my 2004 Corvette PCM which I found on a Corvette Forum
http://forums.corvetteforum.com/c5-tech/2443138-ecu-wiring-diagram.html 
and it shows inputs and outputs of PCM. Since control is a result of an output, I'll look at the outputs. They do not use a normal convention for outputs versus inputs so I'll have to follow them.

PCM outputs:
1) Torque delivered signal to the ABS system (could be an issue for brakes)
2) A/C Status output and A/C request signal (could be an A/C issue)
3) ALT TERM L delivered to the starting charging system ( probably ok)
4) Engine speed out to Tach ( could be simulated in EV motor or not used)
5) Evap Vent Can Control to evap emission vent solenoid (not needed ICE)
6) 2-3SS (or1-4 lamp control) Instrument light control could be fooled
7) Engine cool fan rly @&3 control ( not needed ICE )
8) Fuel pump relay control ( not needed ICE)
9) Evap Can purge Valve Cntrl ( not need ICE)
10) Air pump relay control ( Not sure of air pump?)
11) Air Solenoid Relay Control ( ??)
12) Trans Fluid Press Cntrl High (could impact transmission but also faked)
13) Trans Fluid Press Cntrl Low (need to understand why/when hi/lo)
14) TCC cntrl solenoid ( auto transmission only)
15) TCC enable ckt ( auto transmission only)
16) A/C Clutch RLY Ctrl ( Appears control fuel pump - why A/C?)
17) Reverse inhibit solenoid Cntrl ( Auto transmission only)
18) MIL Cntrl - Dashboard malfunction light ( Easy to fake )
19) TR Shift Sol A ( Auto transmission only)
20) Tr Temp Sen Sig (( Auto transmission only)

as I continue to scan the PCM schematic, I don't see many issues as most controls are related to the engine or automatic transmission and in general don't seem a big issue for an EV. The electrical interface for the dashboard controls is obvious and can be simulated. There must another control computer for the non-engine components. Anybody have any thoughts?

Tom


----------



## danimal (Apr 24, 2009)

I see many cars come into our shop with multiple codes, sometimes as many as 10 or 15. Most are not going to keep the vehicle for running. There are some "critical inputs" such as rpm that you would need but most other things would only cause a check engine light to illuminate. You would need to start disconnecting sensors and wiring to see what things would be critical. And any car with a CAN bus might need more of the inputs so other modules would still operate. Most Toyotas and Lexus vehicles will turn off ABS and traction control for something as simple as an oxegen sensor code in the PCM... That would be a tough signal to duplicate to keep ABS/TC. But most other cars are not that picky. Bottom line is that every car is different and it would just take time to see what it needs.


----------



## pgrovetom (Oct 6, 2009)

Thanks.. What you describe for Toyotas and Lexus is exactly what makes me nervous. The signals I see appear to be logic levels that drive in fairly straightforward ways. The CANbus is a full protocol not unlike Ethernet so duplicating it would be extraordinarily difficult. Even if one found a CABbus protocol stack and controller, understanding the underlying messages would be quite difficult unless the manufacturer documented it well. I doubt they would as an automobile is a proprietary system and by controlling the message structure and definition, they prevent reverse engineering and sophisticated aftermarket parts. I would love to see the overall architecture of PCM and similar devices hanging on a CANbus with a general description of how its done. I have zero experience with cars but lots with communication systems and I could envision a recent auto having many microcontrollers all interacting on a CANbus. Since the PCM is the ICE controller, one would have to hope it didn't send messages to comfort systems, transmission, rear end etc.. If it behaved like the Toyota and Lexus but using messaging, it could be a mess to unravel. I guess the older the car the better is true.


----------



## Dave Koller (Nov 15, 2008)

http://www.embedsystems.com/hardware/bus/canbus.htm

Don't know if it is helpful but there are a lot of canbus "hacks " out there - that is if you even have it on your car !!


----------



## pgrovetom (Oct 6, 2009)

I did some reading and found what I was afraid of. First I read up on the CAN bus ( comes in many flavors) and most cars after 2003 use it. New cars typically can have 10 or more modules that communicate on the bus. The ECU/PCM is just one of them, albeit an important one. One example showed the engine control unit, a right and left door module, seat modules, airbag module and dash module. The bus is a two wire CSMA bus that is based on the old OSI model. The messaging is proprietary with some minimal cooperation. I already knew the engine control unit can kill the engine but didn't care much as I would be removing it. I was concerned about systems that would remain. The earlier post mentioned Toyotas and Lexus can disable the ABS. I came across an article called "Active Safety Control". It discussed how airbags first had to have seat sensors to measure weight to protect children. That meant the seat module needed to report to the airbag module. That means the airbags can be disabled. Then I read about ABS being disabled across modules and now Mercedes implements a collision prevention system that actually applies the brakes if your car gets to close to another. Previously they just lit a light but it said the trend is toward active safety which means the CANbus modules talk and can disable ABS, apply brakes etc.. If the information that does this comes from the ECU, then removing the ICE and disabling the ECU could say apply the brakes, disable the airbags etc.. So it looks like over time its getting worse and worse and using cars up to about 2003 should be fairly easy to work around these glitches. Using a 2009 expensive car ( which would be silly anyway) would be a real challenge potentially.


----------



## oates1324 (Oct 13, 2009)

Hello, 

I am fascinated (and scared) by this thread. If the EV lovers all around the world don't come up with some semi-universal, somewhat magical way to fool the onboard computer systems then we have a real issue. No car past 2003? That means that ten years from now we could possibly still be converting our old 1980-1990's cars and the whole world will begin to equate EV with obsolete vehicles - not good.


----------



## Dave Koller (Nov 15, 2008)

oates1324 said:


> Hello,
> 
> I am fascinated (and scared) by this thread. If the EV lovers all around the world don't come up with some semi-universal, somewhat magical way to fool the onboard computer systems then we have a real issue. No car past 2003? That means that ten years from now we could possibly still be converting our old 1980-1990's cars and the whole world will begin to equate EV with obsolete vehicles - not good.


Well, believe me it will not happen - CANbus or any system in the future has, and always will have people like us to hack them .. So catastrophic failure of an ECM (or what ever!) in a modern car will cause you to have an accident ? I doubt it! We ( this forum and others) will find every way around CONTROL.. Proprietary rights are hacked, for a better word, into on a daily basis - the world is full of people eager to make a profit from anything. They used to give us "speed chips" to increase our "mileage" - well you get the idea. Right now you can look at a CANbus and simulate the data stream BUT lets continue and see if it is really needed. Example is even on my 99 Saturn - the speedometer is fed from the VSS into the PCM and converted to pulses fed to the ACTUAL speedometer head in the dash. I really is a pain but NOT that hard to do the same with logic circuits. If I can do it MANY others can do it better and for a profit! So you will always have a way around the cars computer, or encription, or even fiber-optic buss of the future.. I think the problem here is we all try to "fool" the PCM - *Go around it and fool the thing it controls much easier! 


*


----------



## pgrovetom (Oct 6, 2009)

> Well, believe me it will not happen - CANbus or any system in the future has, and always will have people like us to hack them .. So catastrophic failure of an ECM (or what ever!) in a modern car will cause you to have an accident ? I doubt it! We ( this forum and others) will find every way around CONTROL.. Proprietary rights are hacked, for a better word, into on a daily basis - the world is full of people eager to make a profit from anything. They used to give us "speed chips" to increase our "mileage" - well you get the idea. Right now you can look at a CANbus and simulate the data stream BUT lets continue and see if it is really needed. Example is even on my 99 Saturn - the speedometer is fed from the VSS into the PCM and converted to pulses fed to the ACTUAL speedometer head in the dash. I really is a pain but NOT that hard to do the same with logic circuits. If I can do it MANY others can do it better and for a profit! So you will always have a way around the cars computer, or encription, or even fiber-optic buss of the future.. I think the problem here is we all try to "fool" the PCM - *Go around it and fool the thing it controls much easier! *


This is a bit optimistic and could get someone into an expensive problem if they just assumed anything could be "fooled". I've worked 30 years on very large Telecom systems where this concept of having modules ( cards usually in telecom systems)is the norm. The protocols used internal to a system are not typically based on a standard such as CANbus but the underlying messaging protocol can be extraordinarily difficult for even a new software engineer or after the designer has left to pick up and modify or evolve. That is a problem inside a company where all the resources are available and just one person left and the documentation is not well done. 

I agree that philosophically, any system design that allows a failure to result in a dangerous condition ( brake lockup, steering control loss, ABS shutdown, airbag disable, lights shutdown, windshield wiper disable etc.. ) seems absurd. In the telecom world and many others, any single small failure ( e.g. CAN bus opens or shorts, one module begins babbling on CAN bus causing it to become useless etc..) that can cause catastrophic failure such that in the auto case would lead to a crash or safety device failure is either duplicated for redundancy or the mechanism to cause the problem has some kind of key like mechanism. An failure or even glitch that could cause a driver traveling at 70MPH in the rain at night with others in the car to crash would be avoided in a big way. Can you imagine a glich on the CANbus to cause a module to shut off the lights, honk the horn, turn off the ABS, shut off the wipers etc.. I'm just kidding but at 70MPH in the rain, the driver needs to see, the brakes need to work and even loud noises or weird car behavior could cause an accident. That being said, I've personally seen individual engineers working at the depths of a design lose sight of this mandated goal and leave something at risk unknowingly. 

Based on my reading, this distributed module architecture in cars based on some variant of the CAN bus ( Controller Area Network - originally developed by Bosch manufacturing process control such as a multi-robotic line or auto modules etc..) began to appear in the 90's mostly with more expensive advanced European cars such as Mercedes, Audi, BMWs etc... By 2003 it had become pervasive with about 5 flavors or variants of the CAN bus and auto manufacturers. Only the OBDII diagnostic interface, a CAN bus port, has been reasonably well standardized across many suppliers. That is because auto mechanics need a single device to get the diagnostic codes from most vehicles. 

Because the modules inside the car are proprietary to say GM, they forked and developed their own GMLAN offshoot or FlexRay also an offshoot driven by a consortium. Its a bit like the wild wild west and getting more complex and varied every year. Believe it or not, the Intel Atom processor which is the same as found in laptops is used in auto module applications. I only mention that because a typical car with say 10 modules has the performance of 10 laptops all connected on an Ethernet like CAN bus. Hacking into and finding and fooling a module via its CANbus given every auto manufacturer is proprietary and keep changing with each model. A very high end new Mercedes, Lexus or comparable expensive car will have a computer network far more complex than found in the Space Shuttle. 

With 10's of car manufacturers, 10 years of computer network models and each having 5-20 models of varying type and feature complexity, it would take a very serious and dedicated expert software/HW engineer(s) just to track down and understand one modules messaging interface. 

So, No, don't count on being able to choose any car of any year and expect somebody has or will resolve a problem buried in the CAN bus multi-processor of that car. It won't happen. It may happen on a few popular models but all bets would be off the following year for that model without the same team unraveling what changed and why. This is no trivial problem.

I'd be very leery choosing a donor after about 2004/2005 unless I had confidence that someone else had found a way to avoid issues. I think I would summarize it something like this:

Hope the concept of not allowing critical systems to be controlled easily is followed by most auto designers

Hope that the actual device like the ABS brake controller can have some simple static control signal intercepted as it goes to a dumb device can be found and easily disabled or fooled.

Hope that complex multi-module features such as collision avoidance, active handling/traction control etc don't involve multiple modules communicating to function in a way that is needed in the EV after conversion. 

Hope that the state registering authority ( like DMV) or insurance companies doesn't realize that modifying one of these systems could impact the safety and require it be proven it hasn't. Today, they already require an independent verification that the car is really electric and should be allowed to be exempt from smog rules. 

If the DMV thought an EV convert might have disabled a safety feature demanded by law like the airbag systems etc.. they could prevent EV conversions from being re-registered without testing to prove they work. That would be nearly impossible for an EV enthusiast and no junior college program in their right mind would take on the responsibility of assuring to the DMV that an EV conversion didn't impact safety. They would be liable. Today they only have to verify an EV is really an EV which brings no liability. 

For me, I'm going to stick with donors up to about 2003 and avoid ones I believe or see in the manual are sophisticated and risky. There are lots of great donors pre-2004 and so this won't be a big issue for some time. I just hope the government or auto insurance folks don't get weird about how an EV conversion might impact safety and do something funky.


----------



## dimitri (May 16, 2008)

You make it too complicated. There is no need to hack CANbus, its just a messaging protocol, let it do its job. All you need is the engine sensors, and even those aren't all critical, just 2 or 3 that need to be simulated. All sensors in modern cars are the same as they been 10 years ago, most resistive / analogue, some pulse based.

I studied my 2003 Mazda schematics and compared to later models from recent years, NOTHING HAS CHANGED as far as engine sensors go. I could care less about CANbus for conversion purposes, just leave it alone.

Most non-critical sensors can be cutoff and there will be CEL codes thrown by ECU, so what? Just cut off the CEL light and use it for EV purposes.

These modules are designed with safety in mind, so safety systems don't actually depend on ECU even if they communicate with it.

Just get a shop manual for your car and study it, every ECU pin, inputs / outputs, troubleshooting procedures, you will realize that its not a rocket science.

At first my auto tranny refused to switch when I cut off all engine sensors, then after I simulated proper RPM and coolant temp signals, all came to life. 3000 EV miles so far, no problems


----------



## danimal (Apr 24, 2009)

Even if most of the sensor inputs are removed from the PCM, the CAN communication will still be occurring. But certain modules will not receive information they need to work. If this occurs, they simply turn on there respective light and don't try to manage the system. So maybe your ABS system won't work... but you still have brakes. You can actually remove a module from the bus and other modules still communicate just fine. But as these systems become more integrated, it will get harder no doubt. If your not converting a Lexus or such, you should be able create enough needed signals to do just fine.

I believe there was a thread somewhere about deciphering a CAN bus signal for a Mazda that you may want to look up.


----------



## Dave Koller (Nov 15, 2008)

[h3]CANbus ISO standards[/h3]
International Standard Organization (ISO) defines many standards for CANbus. ISO 11519 (CAN 2.0A) and ISO 11898 (CAN 2.0B) are the standards for road vehicle communication. ISO 11992 is standard for interchanging information between towing and towed vehicles. ISO 15745 standard targets industrial automation and integration systems. ISO 16845 is for CANbus diagnostics.[h3]CANbus SAE Standards[/h3]
SAE is the society of automotive engineers. SAE also defines CANbus standards. These include J1939 and J2411 CANbus standards. J1939 defines specifications equipment used in construction, agriculture, forestry, and fire and rescue services). J2411 is for single wire CAN or SWC. One problem with CANbus standards was that they did not contain application layer tasks. To cater this higher layer protocols were created. DeviceNet and CANopen® are such protocols.


On the link I sent you - standards - government control - So the only thing we have to follow is their standards. They can write it and address it in any language but it all comes down to the above... Like FCC standards - we CAN all find them - as dimitri says - "There is no need to hack CANbus, its just a messaging protocol, let it do its job. All you need is the engine sensors, and even those aren't all critical, just 2 or 3 that need to be simulated. All sensors in modern cars are the same as they been 10 years ago, most resistive / analogue, some pulse based."

He is right! And I will continue, in my meager way, to bypass everything for now... And if I ever get a "blown engine" 2010 Whatchamacallit - I WILL figure a way to get it going or I will no longer call myself a DIY kinda guy!

Your points are all valid - but this is the reason for this forum - We can do anything!!


----------



## pgrovetom (Oct 6, 2009)

> You make it too complicated. There is no need to hack CANbus


I don't think you understand. New cars with 10 or more Atom class computers or large PLDs cooperating via messaging over the CAN bus, reading sensors of all sorts, turning things on, off or adjusting based on what they see on their sensors and what they learn via a message from other modules is complicated. My point is just that if one discovered you couldn't fool the ECU because it needed to see a dynamic signal or one in a feedback loop, or couldn't fake the output signal going to a system like brake ABS or Airbags or transmission, it is possible to run into an expensive problem.

The vast majority of EV conversions have been the less sophisticated and older cars. As you say, most of the sensors are resistive or contacts easy to fool. Most things controlled are done with an on off logic signal driver also easy to force on or off. As the auto designers get fancier and fancier with features like "Active Safety" and "traction control" or "active handling", its not going to be so easy. You may be right that up until fairly recently, its been fairly easy to fool things. Its not rocket science that these systems are getting more complicated quickly.




> its just a messaging protocol, let it do its job.


Yes its a messaging protocol but its the module CPUs cooperating, reporting, participating in control loops and the result of that I'm talking about, not the protocol itself, its the implications of 10 modules in your engine, dashboard, seats, doors, airbags, transmission, brakes all cooperating to perform some kind of active control that will lead to difficulties as more and more "active" systems are used. Up until recently, only the expensive sophisticated cars had systems like this.




> All you need is the engine sensors, and even those aren't all critical, just 2 or 3 that need to be simulated.


In some cases this is true but its getting worse.




> All sensors in modern cars are the same as they been 10 years ago, most resistive / analogue, some pulse based.


Sensors that are incorporated in a feedback loop cannot be simulated because the value is dynamic. Its not common but will become more and more so just because it "was easy" doesn't mean it won't get difficult.



> I studied my 2003 Mazda schematics and compared to later models from recent years, NOTHING HAS CHANGED as far as engine sensors go. I could care less about CANbus for conversion purposes, just leave it alone.


All engineers, mechanical, electrical and software engineers almost always leave the design components the same unless there is some compelling reason to change them. Its more work for them, testing, QA, purchasing, manufacturing etc.. So yes mos things are stable. That is until marketing asks engineering to add the new active safety feature the competition has. Then things change in many ways. The trend is toward active sensors and feedback loops that loop through a device. The CPU might be sending a pulse width modulated signal into a device to control it and reading an analog output to monitor the control. Then the PWM is changed based the analog value. That is common and extremely difficult to simulate because the control is inside the software inside the module.




> Most non-critical sensors can be cutoff and there will be CEL codes thrown by ECU, so what? Just cut off the CEL light and use it for EV purposes.


True but it only takes one killer problem to disable the entire EV. Just because most are non-critical and no big deal, I'm only trying to point out that the trend due to the capability these interconnected smart modules is toward difficult to fool problems.



> These modules are designed with safety in mind, so safety systems don't actually depend on ECU even if they communicate with it.


Of course they are designed with safety in mind. The entire CANbus module network origin was based on safety and diagnostics. Now active control features such as airbag disable, brake application etc.. are being added. The basic concept of active safety is that computers can act quickly if they see some unsafe condition and protect the driver from things like falling asleep, attention diverted to cell phone/kids etc.. That means the computer system looks at conditions any where and from any module that suggest a potential safety condition and act "for the driver". My traction control looks at engine sensors, an accelerometer, wheel sensors etc.. and shuts the throttle down. So the ICE engine conditions will likely be one input to some software along wth others in a decision process to actively control something on the car. Mercedes is applying brakes and many are checking the weight on the passenger seat and disabling the airbag in active system and they will dream up many.



> Just get a shop manual for your car and study it, every ECU pin, inputs / outputs, troubleshooting procedures, you will realize that its not a rocket science.


If that CPU SW is involved in a feedback loop that uses those sensors and outputs, it will need as you say "rocket science". Do you kow what a feedback control loop is?



> At first my auto tranny refused to switch when I cut off all engine sensors, then after I simulated proper RPM and coolant temp signals, all came to life. 3000 EV miles so far, no problems


This is exactly the kind of control I'm talking about. What if the designers had taken the data to decide on transmission switching from some feedback loop in the ICE engine management that you couldn't simulate? That kind of thin will happen and I'm just trying to point it out so someone who gets a 2010 car cheap and jumps in to convert it, this is going to begin to be a bip problem just as new cars are not like the 1960's cars I grew up on as a teenager where all you needed was battery, spark and gas.


----------



## dimitri (May 16, 2008)

What is your overall point in one sentence? Are you trying to scare people from converting new cars? I know for a fact that several 2009 cars been converted successfully. All that theory you describe is true only if one was changing everything in a car, but we don't, we just swap one rotating shaft with another. RPM signal is what tells all other CPUs in the car that engine is a alive, that is all there is to it. Fake RPM signal and you are all set. No one cares if oxygen sensors or air flow sensors go haywire, the car is happy if RPM signal is present, period.

All that fancy stuff you point to does not get touched by conversion, so why worry about it?

You present lots of "what ifs", but what have you actually done to prove any of this one way or another?

I read all 1000+ pages of shop manual for Mazda , which gives answers to all the things you worry about. Why don't you read a shop manual and then come back with specific details we can discuss?


----------



## danimal (Apr 24, 2009)

You have to remember that there is a big difference between an entry level mazda and say a Lexus. Every vehicle will have different needs. It's not about scaring people, it's about making sure your conversion will meet your expectations is it not? A minimalist might remove everything install there own gauges for a basic conversion. the other end of the spectrum would be someone who wants to integrate all systems and gauges for a "stock look". A 2004 Lexus RX300 will deactivate ABS/Traction control if the PCM detects an oxygen sensor code, I have seen it happen on many occasions.
So what are your options, go without ABS/TC, or possibly hack the CAN.
You will not be able to reproduce an oxygen sensor signal that the pcm can control and test. Or don't start with a fancy "high end" car to start with. Every car will have different needs and every driver will have different wants. But as these systems start becoming more mainstream, even a entry level Mazda might come stock with traction control.


----------



## dimitri (May 16, 2008)

danimal said:


> A 2004 Lexus RX300 will deactivate ABS/Traction control if the PCM detects an oxygen sensor code, I have seen it happen on many occasions.


This is just retarded, why would they do that? Why disable important safety feature when O2 sensor fails?

One can get into accident caused by disabled ABS because O2 sensor is acting up? This grounds for a lawsuit against Lexus.... for hiring retarded engineers.

I see your points, there are some tradeoffs during conversion, its granted. If you don't want to deal with tradeoffs, then don't convert luxury car, go buy Chevy Volt or Nissan Leaf or whatever.

I just don't get all these theoretical "what ifs" which aren't backed up by specific real life details. Sounds like scare tactics to me


----------



## Dave Koller (Nov 15, 2008)

danimal said:


> So what are your options, go without ABS/TC, or possibly hack the CAN.
> You will not be able to reproduce an oxygen sensor signal that the pcm can control and test. Or don't start with a fancy "high end" car to start with. Every car will have different needs and every driver will have different wants. But as these systems start becoming more mainstream, even a entry level Mazda might come stock with traction control.


You may not be able to reproduce an oxygen sensor - but race car drivers do it all the time... They make "dummys" to fool the PCM when they have no rear catalytic converter.. they make performance chips to increase H.P. and in general - using the SAE standards "talk" to the CANbus everyday in small car shops all across our nation. Someone had to "Hack" those standards to get the testers to talk! It isn't even a hack - you just have to get the right person and it is not that expensive... I live in the Northwoods and one phone call to my "car guy" (40 years in the business) says IT IS ALL HACKABLE.... The only thing propriitory might be in the software ... and the "talking" is still in the language of the CANbus... and his handheld computers listen to the "langauge" daily... and sometimes -- answers it....


----------



## danimal (Apr 24, 2009)

dimitri said:


> This is just retarded, why would they do that? Why disable important safety feature when O2 sensor fails?
> 
> After being in the automotive Field for over 20 years you almost have to quit asking "why did they do that?" or you would blow your brains out.
> I would assume that if the traction control needed to increase wheel speed, but the pcm is detecting an engine malfunction, it may not be able to control traction. Better to turn off traction control, alert you that it is not working, so they don't get sued.


----------



## pgrovetom (Oct 6, 2009)

> This is just retarded, why would they do that? Why disable important safety feature when O2 sensor fails?


It is retarded but you have to remember that it isn't one person with years of common sense that designs these things. For the same reason Windows Vista has so many stupid features and bizarre problems is there is a large team working on it. I would guess that a car with 10 processors in modules probably has a team of 20 or more software and hardware and mechanical engineers working on it for many months. Maintaining simple common sense across these module teams can easily be overlooked. Or after the design is nearing completion, marketing insists on some safety feature late in the game and some changes get made in the code in 5 modules and it can have retarded effects. I've seen it 100 times. 

I bet in the 60's and 70's, there was one experienced pair of HW and Mechanical engineers and no software at all with a few others and one person with common sense arranged everything electrical. The entire system was easy to understand and easy to prevent weird problems. When you build a car with 10 software modules all talking to one another trying to coordinate everything in software, you can get some strange results. Then throw marketing demands into the formula and you get safety getting worse.

This is exactly why the Space Shuttle still runs on a 1970's processor based on the IBM360 mainframe and they don't touch the software unless its critical. They just leave bugs and teach astronauts to work around them. NASA is smart and scared to death of letting the shuttle evolve into a multiprocessor system like autos with some CAN like bus tying everything together. They know they would lose a space shuttle far more often because of this exact problem of not seeing small issues across a team of developers and the difficulty testing it in flight. Can you see somebody set a new car up with the capability of disabling or creating weird signals on every module input and then looking for resulting problems.

With 200 inputs across 10 modules, the number of permutations is huge. How do you test the impact of an open connection on a sensor while a car is driving under every condition. If you never have been involved in multiprocessor system design you would probably not get it. But if you played on a complex ball team and watched trying to coordinate new players coming in and a defense and offense, its gets pretty crazy to manage. Just imagine if everyone was writing software and sending messages to other modules that needed to interpret everything correctly reality of new cars.

That is also why I would worry the DMV or insurance companies might begin to look  at this as they do smog exemption on EVs. Somebody earlier said I was making it too complicated. I'm not, its the auto designers using 10 microprocessors and software on an Ethernet bus to run a car that used to be run with switches and relays - and worked just fine...


----------



## EV-propulsion.com (Jun 1, 2009)

I personally side with dimitri- you are not changing very many systems- just the rotational power source, leave the rest alone. There may be some crazy items that affect other systems but there arent many (like the O2/traction control issue). Besides, an O2 signal is not impossible to duplicate if necessary.There is always a workaround and generally not to complicated-and we love challenges anyhow! But really, what is the absolute worst issue- no traction control?-brush up on your driving skills and you won't need it-we have all been driving cars without it for how many years?


----------



## danimal (Apr 24, 2009)

> Dave Koller said:
> 
> 
> > You may not be able to reproduce an oxygen sensor - but race car drivers do it all the time... They make "dummys" to fool the PCM when they have no rear catalytic converter..
> ...


Sure they do... for Mustangs, Camaros and such. Try calling them up and asking them to make ONE for your EV conversion. You would probably have a better chance of Teseract building you a controller for a go cart.



> using the SAE standards "talk" to the CANbus everyday in small car shops all across our nation. Someone had to "Hack" those standards to get the testers to talk! It isn't even a hack - you just have to get the right person and it is not that expensive... I live in the Northwoods and one phone call to my "car guy" (40 years in the business) says IT IS ALL HACKABLE.... The only thing propriitory might be in the software ... and the "talking" is still in the language of the CANbus... and his handheld computers listen to the "langauge" daily... and sometimes -- answers it....


Well,sort of. A handheld diagnostic scanner communicates with the PCM which in turn communicates with the CAN. You do have limited "bi-directional control" to run some test, and activate some outputs and view most inputs and outputs. Mine cost 4 grand and they run as high as 10.

But this little item is what I want Santa to bring me this year.

http://www.gridconnect.com/diagkitpro.html


----------



## Dave Koller (Nov 15, 2008)

danimal said:


> Sure they do... for Mustangs, Camaros and such. Try calling them up and asking them to make ONE for your EV conversion. You would probably have a better chance of Teseract building you a controller for a go cart.
> 
> 
> 
> ...


Yep you ARE 100% right - but the point of all this argument and bickering is that - everything CAN be hacked.... even the program you refer to - as my friend uses one in his shop. My friend has that and diagnostic scanners in his shop, and said you might have overpaid for yours.. I try not to drop all the letters after my name - but I have worked quite some time with embedded processors and you are right, modern PCM's are hard-pressed to find "outboard" memory chips for enhancement reasons - but as dimitri says it is more the sensors we need to fool and at the moment they seem easy ...
http://www.lsxtv.com/forum/lsx-wiring-dummies-257.html
http://www.034motorsport.com/index.php?cPath=22
http://www.strikeengine.com/performance_chip.html

Examples of ways around the Stock PCM - My ONLY point here is EVERYTHING is POSSIBLE when it come to these cars NEW or old ... 
And if they can "drop- in" a performance wire harness ( for a price) it means SOMEONE - SOMEWHERE - has knowledge they have gained to make it possible - So lets MAKE it Possible instead of WORRYING about it NOT being possible - this is a [email protected]!#$ DIY site NOT an "I can't do it cause I won't try" site...


----------



## EV-propulsion.com (Jun 1, 2009)

Right on Dave! I think you just put this thread to bed!
mike
EV-propulsion.com


----------



## SimonRafferty (Apr 13, 2009)

This is a problem I've been pondering recently!
I'm soon going to start converting a 2020 Polaris General XP1000 - which uses a Bosch M17 ECU (common in small cars & bikes).
My initial thought was ro replace the ECU, read all the sensors that feed it and spoof the CANBUS signals to the other bits of the car.
Having poured over the schematics, everything connects to the ECU. There's a total of 108 pins on the connectors, though probably only 60% are used. Most are esay - but some talk to the ECU via some kind of coded signal (serial) that isn't CAN.
I bought an ECU and was in the process of designing a new PCB with a couple of Arduinos to deal with it all - than had a brainwave!
Most (but not all) things operate with the ignition switched on but the engine not running. I figure on interrupting the CAN signal as it goes into the ECU. Use an Arduino (Teensy 4 as they are lightning fast) with two CANBUS Transceivers to read the signals generated by the ECU and pass a filtered set on to the other transceiver sitting on the main CANBUS. Initially, it can pass on everything in both directions.

As I figure out the PID's for the things I'm interested in, I'll filter them out and generate my own. Things like RPM & Road speed which are used to drive the PAS, I can generate. I'm sure the ABS will use some CAN signalling - but not sure what as yet.

I can generate most of the PIDs used by the instuments (already figured out most of them, just injecting signals into the OBD port), including the check engine & warning lights. 

I've seen people do exacly this with the instrument pack alone on other vehicles. No reason it wouldn't work on the ECU itself.

This approach seems to me, the easiest. Time will tell if it works! The beauty of it is I can try it before I take out the original engine & only need to cut 2 wires in the ECU loom.


----------

