[help needed] Self-diagnostics todo/dreams

[AndreyB]

I am just back from a Lemons race and as usual there was a lot of "we have swapped all sensors and the ECU but the car would not rev above 3500" kind of stories. Also there were plenty of "the car would not start" stories

This makes me wonder - what kind of self-diagnostics is possible with mostly firmware, without much extra hardware?
Obviously sensors showing wrong stuff should throw out a code. A misfire could be detected based on shaft position sensor unevenness, probably even loss of compression in some cylinders could be diagnosed.

Alternator not providing charge would be detected by low voltage at high rpm?
Can we diagnose anything by sensing the voltage drop/lack of voltage drop while cranking?

What else?

[acab]

You need feedback from coils\injectors\sensors. Only via hardware

[kb1gtt]

-- RPM min and max acceleration, AKA can't go from 1kRPM to 10kRPM in one crank wheel pulse, it has to be noise
-- Temperature should start at a point and follow a tolerance graph to the existing temperature, if not the sensor could be bad, or the thermostat could be bad, ect.
-- Short term voltage dips when spark or fuel pulses could indicate a weak battery or bad wire connection
-- On board temperature sensors could warn before injectors shut down ect,
-- Could calculate min power requirements based on things like accelermoter data. Basically you know min fuel required to go up a hill at blah MPH at Blah degrees inclination. If you are using more than you know something is wrong.
-- Can predict O2's based on RPM AIT and VE, then could also predict based on MAP and RPM. if they don't match you could warn, or put in limp home mode
-- Can predict fuel, then use long term fuel trim to determine if you are using more fuel than required. If you get above about 10% you know something is wrong
-- Could look at MAP over time/RPM and if you see the wave does not look correct you could determine that there is a bad valve, blow by, backfire, ect.
-- Could measure GND voltage at the battery, if you measure more than blah mV, you know there is an issue with the GND conductor.
-- Could add a serial kill switch, basically if someone steals my car, I call my cell phone and kill it remotely.
-- Could compare MAP vs TPS and RPM, if the MAP does not fall with in tolerance, it could indicate carbon build or plugged air filter or some kind of restriction.
-- Could use http://en.wikipedia.org/wiki/Kalman_filter on the various signals, basically if you know what to expect you can filter to find what you are looking for.

I can think of many more if we add some stuff like GPS, more pressure sensors, or more temperature sensors. I think all of the above can be done without additional hardware.

[kb1gtt]

-- continuous logging, such that if an "event" is noticed you can capture some prior data. For example, if your event is that the crank went from 10kRPM to 0 RPM instantly, it can capture that last minute or so of data. Then some kind of mechanism to establish what determines an event. Perhaps noise spikes in the crank, or knock detection could trigger an event.
-- Power limiting for things like wheel spin, AKA ABS but backwards, so ABS for going forward preventing excessive wheel spin when on tarmac.

[Nobody]

.

[kb1gtt]

-- Timed difference from 2X knock sensors can determine which cyl pinged.

[Nobody]

.

[kb1gtt]

-- knock should look for an increased amplitude in a specific crank window around TDC.
-- knock should establish the minimum and max noise floor, by looking at the signal during non knock events. AKA how much noise is the water pump, valves, oil pump, ect making, Your knock could or should be above this noise floor.
-- knock should log the peak time, peak crank angle, peak amplitude and established noise floor when it knocked.
-- based on the above log, a lower priority longer term prediction can be preformed to determine what cyl knocked.
-- Based on the amplitude relative to the max noise floor and angle relative to the spark event, timing can be backed off. This would be a PID or similar control loop. Basically if you have a large knock amplitude back off by blah degrees. If knock happened before the spark event or very close to the spark event, spark retard probably isn't going to help, so toss a warning or do something different like open EGT to slow down the flame front. If engine is warm, back it off more than if it's cold, ect. If we have at least some basic knock configuration options, that's better than nothing.

I agree that knock can be a tricky one to tune, and deal with "correctly", especially when people generally don't agree on what "correctly" is. However something is better than nothing. Even if it only tosses a warning light it could prevent those alternator problem. You know when the connecting rod knocks your alternator off.

-- A diagnostics mode would be handy. Something that allows you to set the ECU to this mode. Then with the car at 0 RPM you can tap the engine with a screw driver or small hammer of some sort, then you can see the ping on the LCD or laptop. This would allow you to verify the basic circuit is functioning correctly.
-- diag mode could also be a logic analyzer such that the LCD can show you the crank sensor input, and allow you to look at it for noise. Also it would be handy if you can look at this signal and compare to a scope. Hall sensors often round the corners for a variety of reasons. Then MCU's often trigger around .7V. This means what you see and expect on a scope, may not match what you see and expect from the software. Comparing the two would allow some really handy diagnostics.
-- diag mode could also allow for a fuel bench setup, basically pull the fuel rail and squirt into a beaker, then measure the delivered fuel to verify that all is working good.
-- diag mode could allow overriding of sensors. For example, if you know your coolant sensor is buggered, and you know it's about 100C, diag mode or something could allow an override to have it hard set for 100C. This allows you to run a race instead of being hosed and having to sit out until you have the replacement sensor.
-- diag mode could allow the disabling of sensors. Basically if you broke your O2, switch to a setup that doesn't use it.
-- diag mode could allow soft simulations of the crank angle sensor, such that you can look at the various engine RPM scenarios with the engine off. Basically pull the injector relay, then "run" the engine, such that you can check spark with a timing light, and check fuel injector pulses with a scope, ect. It's one thing to see them on the dev console, it's another to see them with a scope and see if they match.

Hmmm, I see lots of parameters that are a one time thing. Basically I see an engine setup being done like this. You first get it all setup and wired, then you enter the ECU into config mode either via PC or via LCD. In config mode you are prompted for what you want to do like calibrate individual sensors, or calibrate a series of sensors. Each sensor could prompt you to do things like go WOT, then it could take a reading, then it could prompt you to go idle throttle, and it could take another reading, then have you verify if you are OK with the readings and such. If you say yes, it stores them to long term memory. The it moves on to the next config parameter like coolant temperature, crank angle wheel, ect.

After Config mode you go to tuning mode. At this point we assume all is working and you are trying to adjust your tables for your desired performance. Here you tune your spark and fuel tables,

Then after you are done with Tuning mode, you go to normal operation mode, where the LCD might show some information like RPM, or warning messages.

If something goes wrong you can enter diag mode which allows several unique features.

Can these modes be done via TS? Perhaps a version of the Dev Console could get some of these features if they can't be done with TS.

Just my 11.53 Chilean Peso

[Vanquizor]

Of all the ideas talked about here the one for noise filtering or monitoring on the crank signal is the most valuable to me. I am yet to install an aftermarket ECU that I didn't have to chase signal noise on and inevitably there is no convenient way to monitor it. Its start the motor, run a log, open a log, try and find the noise.

On the other hand if there was some indication of noise level- possibly a count of things that were too short to be a tooth (based on rpm) or # of missing teeth.
To determine what constitutes noise vs a normal trigger consider a very fast sportbike accelerates 3000rpm/sec-I'm sure all our current projects rev slower than that so anything outside of 3000rpm different from the last trigger must be an error. Also it wouldn't hurt to keep the filter adjustable just in case someone tries to use this on a jet ski or to better define the filter for our slower revving cars.

[AndreyB]

Of all the ideas talked about here the one for noise filtering or monitoring on the crank signal is the most valuable to me.

It's something I am already working on.

Currently it just counts the events and makes sure there is the right ratio - say it makes sure that for each 2 events on the primary wire it has exactly 8 events on the secondary wire. It also keeps track of how often there is a mismatch and it has is happened 6 times out of 10 last revolution it would print out an error message and light up the orange LED.

Another thing which I've added to the list yesterday and which I will probably implement soon is issue #80 - it would be calculating 'duty cycle' of each trigger signal to make sure it matches the expected value. Again, if it would not be right too often there will be an indication.