Basic Datalog - What To Put In It?? Your thoughts!

[jharvey]

and the other for the potential second inject / ignition board.

I'm not aware of any plans for any such board.

We do seem to have a number of things that have been talked about but not planned yet, like ion sensing, ect. I know it's been talked about using two units for more cyls, and it's been talked about sending the signals from one board to the other to make this work. Many of these plans are on hold because we are trying to focus on getting it going, before shooting for the moon. I was trying to point out that because this ECU is the communications ECU, it may have to relay information from other devices.

I like the 99.99% list Ben posted. I'd say that's a good starting point for getting it working, then later on, extras can be worked into things.

[Fred]

When talking about paired ECUs, they would be totally independent, but with the same tune on them. Thus, they'd have a datalog of their own each.

The other stuff (ion etc) is by definition extra and supurfluous and thus not required in a basic datalog.

This is only a discussion on the basic type, not the full type which by definition has everything...

Fred.

[BenFenner]

Not sure, but might want to add EGT (Exhaust gas temperature) to my list. It's not as common as you'd think/hope, but still pretty basic.

But now why not add knock sensor info too? =/

[jbelanger]

Battery voltage would have to be on the list.

Jean

[thebigmacd]

I must apologize ahead of time as I haven't paid enough attention to what core features are actually intended to exist, and as such I may have stuff in my list that aren't going to be used in the foreseeable future.

I tend to break datalog requirements into three levels:
(0) I/O values (converted into engineering units at the pc level)
(1) Internal variables used for modelling the engine
(2) Higher-level data used for modelling the entire automobile system

So my layer "0" requirements would be as follows:
I would suggest having a single bit denoting Bank 0 or Bank 1 for future multi-bank support. This would allow easy extension by interleaving transmission of bank 0 and bank 1 values if needed.

Values:
TMR - Timer
RPM - Engine Speed
IPW - Injector Pulsewidth
IGA - Ignition Advance
TPS - Throttle Position
IVP - Idle Valve Position
MAP - Manifold Air Pressure
MAF - Mass Air Flow
BAR - Barometric Air Pressure
MAT - Manifold Air Temperature
AMB - Ambient Air Temperature**
EGT - Exhaust Gas Temperature
EGM - Exhaust Gas Mixture
BAT - Battery Voltage
KCK - Knock Count/Intensity
** I find this important to have reserved, although optional W.R.T. actually installing it. If not installed I would have it default to MAT.

Flags:
ESF - Engine or Sensor Fault**
BNK - Bank 0 or 1
SYN - Wheel synched
RUN - Engine in run mode
PMP - Fuel pump on
FN1 - Fan 1 on
FN2 - Fan 2 on
WUP - Warmup***

** This would be set when the rev limit is hit, engine overheats, sensor fails, etc. Basically an indication of "limp mode" or "redline". It would have to be programmable to ignore sensors that are intentionally omitted and always use some default value. If this is integrated as an output it could be used for both safety and visual diagnostics.

***Is warmup going to be a defined binary state or more of a fuzzy state? I prefer to leave it out and treat it in the ECU as a fuzzy state, since most setups will modulate the idle speed as engine temps change.

Outside of the scope of this packet (level 1):
Internal variables such as Exhaust Gas Correction, Acceleration Correction

[thebigmacd]

As an aside, I think it is VERY important to define the specific behaviour of each field that we include.

For example, if in the basic datalog packet we have a field for "knock count" but in the future the firmware has support for multiple-bank or even multiple-cylinder knock counts, there needs to be a predefined behaviour for this single field.

In this case I would suggest that the core "knock count" field be defined as the "knock count of the bank or cylinder with the highest knock count", as opposed to an average, or just one of the sensors.

Or in the case of "ambient temperature" that I included, if the sensor is not present, there needs to be a definition for what value will be in this field. In this case I would define it as "ambient temperature, OR manifold air temperature if ambient sensor is not installed or fails".

The nice thing about having defined behaviours is that if someone with a tuning software version that only has core datalog support, they will still get the most important information from more advanced firmware. It also does dual-duty as defining the actual behaviour of the firmware, and perhaps even simplifying the operating of automated tuning algorithms (since the data would be presented in a format that is valid even if sensors fail or the system is more complex than the algorithm was originally designed for).

[AbeFM]

Good lord you guys are prolific.

In addition to the below:

Values:
TMR - Timer
RPM - Engine Speed
IPW - Injector Pulsewidth
IGA - Ignition Advance
TPS - Throttle Position
IVP - Idle Valve Position
MAP - Manifold Air Pressure
MAF - Mass Air Flow
BAR - Barometric Air Pressure
MAT - Manifold Air Temperature
AMB - Ambient Air Temperature**
EGT - Exhaust Gas Temperature
EGM - Exhaust Gas Mixture
BAT - Battery Voltage
KCK - Knock Count/Intensity
** I find this important to have reserved, although optional W.R.T. actually installing it. If not installed I would have it default to MAT.

Flags:
ESF - Engine or Sensor Fault**
BNK - Bank 0 or 1
SYN - Wheel synched
RUN - Engine in run mode
PMP - Fuel pump on
FN1 - Fan 1 on
FN2 - Fan 2 on
WUP - Warmup***

I'd like to suggest a couple:
If KnockCount has a threshold, we could record count. Otherwise, I'd want to see the highest intensity of the tallest peak in the recording period. On a FULL datalog, perhaps the relative timing of this knock.

Two that I didn't see which I would like:
H2O Pressure - if someone has a water injection system, and loses pressure, I'd like to see the error light come on pretty fast

Amber and Red alerts: A CEL is a great idea, and without getting too complicated, I think "hit redline" and "No Oil" are two different levels, should be treated as such.

O2C - O2 Mixture Correction: It's nice to tell at a glance if you're at your target AFR because of corrections, or because of the map. Maybe an overall correction, just called Final Fuel Corrections (but hard to tell if this is baro, warm up, etc).

Also, Injector Duty Cycle might be more data than is needed, but a flag to say "you're over (user preset)% duty cycle)


My initial concern was that this list was too long. I love to idea of making a request for streaming data and getting what I asked for in streaming format (including 2-3 variables to be user defined in firmware). Now I'm thinking, if I want "burst mode" data, I could define a shorter streaming list, with much of the above removed. I also like the idea of timing error, but not sure how to do it.

Oh!!! One or two "phase angles" for variable valve timing. Real time feedback on that would be AWESOME.

[WTDeuce]

Id like to see EGT as well, if its planned to be onboard. Its VERY useful for tuning, as is knock info.

[AbeFM]

I do all sorts of lean burn (and picked up at least 20% gas mileage) which I wouldn't do without my EGT guage. I'd love to have the computer watch it.

[Fred]

Any of you guys work for microsoft? :-p I should start an EGT fanboy bashing thread as it would be wrong to pollute this one. All I will say is that if some values are configurable then it will probably take one of those places. If someone starts the other thread I'll indulge in the discussion :-)

Great work on all the ideas, some good stuff that I hadn't thought of in there!

Fred.