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

[Fred]

We may also want "up time" for two other processors as well. One for the ion sensor board,

Outside scope.

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

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

The core idea is a lowish budget highish performance fully featured high I/O single chip solution.

We are well on target to achieving that IMO.

This is a log that describes what is happening in THIS ECU, not any others.

• The red area is the total available set of data on board.
• The green area is the set of things that almost all engines have.
• The purple area is the set of things that almost everyone wants.
• The blue shaded area is probably what we are trying to achieve with this cut down log.

I guess it is debatable with respect which area to choose. You could argue that you want all fields all engines have, BUT, you don't want half of them. You could also argue that you want all fields that everyone wants, but many people don't have them. Finally, you could argue that you want the super set of both of those, however it will be large and slow which defeats the purpose.

I think the suggestions above are by and large good ones. Later I'll do a list and some explanations etc :-)

Fred.

[BenFenner]

Fred, I think you'd save yourself a lot of time and effort if you'd explain better what you're after from the start. It seems like you're interested in what would be useful information to the driver of a car. Or is it the tuner of an engine? If it's the driver, then RPM and maybe a few other sparse things are useful. If it's the tuner, then they are going to want everything. If you want the information for just a typical dyno tuning session (tuning VE and igntion timing tables only) then that's another subset of information altogether. You need to hammer out a goal first, then I'm sure we can come to a quick consensus.

(Do you want the information useful for a first start?)

[compnut21]

(5:26:12 AM) compnut21: maybe an error bit?
(5:26:31 AM) compnut21: like if the ems tried to do something, but it didnt respond right, it sat set a bit flag
(5:26:41 AM) compnut21: misfires
(5:26:45 AM) compnut21: clt/iat short
(5:26:48 AM) compnut21: ect
(5:44:50 AM) FredAtRHE: you were supposed to post those thoughts lol.
(5:44:59 AM) FredAtRHE: clt iat values will easily report a short
(5:45:07 AM) FredAtRHE: this is for logging and display on a dash
(5:45:10 AM) FredAtRHE: primarily
(5:45:19 AM) compnut21: so a bit for cel then
(5:45:24 AM) compnut21: everyone loves a cel
(5:45:41 AM) compnut21: expecially a programmable and useful one
(5:45:50 AM) FredAtRHE: post
(5:45:54 AM) compnut21: not OH GOD, YOUR CAT ISNT AS EFFICIENT.
(5:45:55 AM) compnut21: k
(5:46:02 AM) FredAtRHE: lol

happy fred?

[Chen]

Brake and clutch pedal must monitoring too.
it`s good for datalog and telemetry and also this flag can be used for "launch-control", "full thortle shift" and another things.

Those types of features would be done internal to the EMS though, it would be easy to add them as flags in the log, sure, but I can't see why you want that on your dash for example

The data we are talking about here is a smallish subset of the full amount available.

Fred.

Sorry, i`m dont understand that.
if it`s for dash, i`m think driver needs only: boost, rpm, speed, coolant temp, AFR.
my english is bad, i`m russian

[BenFenner]

After talking with Fred, it seems his goal is to lay down a base-line for display/logging information that potential firmware makers can rely on to always be there, and always be the same format/protocol.

With that in mind, might I suggest the following:

TPS (throttle position sensor)
RPM (revolutions per second)
MAP (manifold absolute pressure)
IAT (intake air temperature)
CLT (coolant temperature)
IT (ignition timing)
PW (injector pulse width)
AFR (air/fuel ratio)
EGOC (exhaust gas oxygen correction)
IACV (idle air control valve DC %)


99.99% of engines are going to have all of the above, and it doesn't take any more than that to keep an engine running well. If we need to get into engine start stuff, then the list gets longer I think. Have I missed anything important?

[slacker.cam]

How about this for an idea....

If time wasn't an issue then it would, in my mind anyway, be best to send pretty much everything we can as that's simple to code for and will keep pretty much everyone happy. But time is an issue if we want to datalog this for analysis later on, so how about giving every variable that we may ever want to send a code and include these codes in a header packet which tells the datalogger what variables to expect and in what order to expect them.

One better may be to have the ecu accept some form of handshake where the datalogger/pc/whatever will tell the ecu what variables it wants to be sent and in what order. If the ecu doesn't receive any handshake then it should just spit out a generic datalog packet with the basic stuff as the people above have already suggested.

Somewhere i have the Autronic datalog packet structure which i can dig out if you want? What i can tell you is that its totally fixed, it sends the same stuff every time and is not configurable.

Out of curiosity what do you expect the maximum rate for datalog transmission to be?

[Fred]

Good to see you putting your thoughts out there young Cam! :-)

One better may be to have the ecu accept some form of handshake where the datalogger/pc/whatever will tell the ecu what variables it wants to be sent and in what order.

I intend to offer several modes of data logging :-) Handshake = request/response I guess.

1. Basic fixed - Request/Response
2. Basic fixed - Async continunous
3. Configurable - Request (with definition)/Response
4. Configurable - Request (definition from flash)/Response
5. Configurable - Async continuous (definition from flash)

The key thing here is that the configurable one will include ALL possible fields. The fields are grouped into types such that a whole block can be excluded based on a single bit in the meta mask. Then for each included block there will be another mask that excludes particular fields on a bit by bit basis. In this way you could have a tiny UBER fast datalog by excluding most blocks and some fields from the remaining one, OR, absolutely everything available and anywhere in between.

If the ecu doesn't receive any handshake then it should just spit out a generic datalog packet with the basic stuff as the people above have already suggested.

This is the async modes above. They would be configurable to be on or not though as the EMS will perform slightly better not logging.

Somewhere i have the Autronic datalog packet structure which i can dig out if you want? What i can tell you is that its totally fixed, it sends the same stuff every time and is not configurable.

Yes, please do, I'd be interested to see exactly what a commercial offering sends out :-) Doing fixed makes sense for a lot of reasons. MS is the same. I've thought of a way to do it configurably though, so why not? The trouble with fixed is you have to strike a compromise between fast and complete. With configurable you get just what you need and maximise the bandwidth.

I've also got parallel send/receive working (or I think I do) so we should be able to max the 115200bps connection out in async mode. Divide by 9 to get bytes per second. The look at the header overhead for your packet size. Finally, consider some % dead time that will occur because of the engine running side task ;-)

Out of curiosity what do you expect the maximum rate for datalog transmission to be?

Packet size dependent, I think our dead rate should be quite low so something around 70 - 80% of the link speed at a wild guess.

Fred.

[deviousKA]

Are the datalog values going to be prepared specifically for the packet, or is it going to simply pluck
ram bytes and send them out?

(If the latter) You could setup the datalog protocol so that you can request any assortment of RAM bytes in any
order.

For example,

Random request sequence:

D1 'request character
0001 'RPM MSB
D1 'request character
0002 'RPM LSB
D1 'request character
0007 'INJ PW MSB
D1 'request character
0008 'INJ PW LSB
D1 'request character
0011 'Throttle position
E0 'Termination character

With the request character used to place the following two byte address in a a stream collection. The termination character used to enable "streaming mode" Where the collection of request addresses are read and sent out at a fixed output rate determined by the microcontroller. Have a another command to stop streaming.

The response from the microcontroller could look something like this,

Repeating response:

FF 'Packet start Character
05 'Numbers of bytes in packet (must match request)
34 'Byte 1, RPM MSB
42 'Byte 2, RPM LSB
72 'Byte 3, INJ PW MSB
FA 'Byte 4, INJ PW LSB
A2 'Byte 5, Throttle position

Not using a repeating TX command to request data, and instead using a packet start character to filter constantly
1-way streaming data may offer better performance also?

If the protocol was designed where any ram location could be streamed in any order like this, it may never need to be updated, and would make a handy debug tool.

[deviousKA]

NM, a day late and a dollar short

Thats all probably beyond the scope of this thread. I am interested in writing some PC software for FreeEMS sometime and a simple fixed protocol (to start with) is good with me anyways.

[Fred]

Are the datalog values going to be prepared specifically for the packet, or is it going to simply pluck ram bytes and send them out?

It'll be as above where it assembles either a fixed set (to be determined by this thread) or a configured set based on config. What I didn't say above is that the ordering would be fixed, only presence or not presence of things would be possible. I see no valid reason for wanting it in a different order. You have it as a block on the pc side anyway, so parse it to how you want it from there right?

Not using a repeating TX command to request data, and instead using a packet start character to filter constantly 1-way streaming data may offer better performance also?

Yes, sure will, hence the asyncronous mode mentioned where by you enable continuous logging and it pumps them out as fast as possible.

If the protocol was designed where any ram location could be streamed in any order like this, it may never need to be updated, and would make a handy debug tool.

Well, I would have to limit the range and size, but I don't mind putting a function to return random blocks of ram. Never expect to be able to write them like that though. Not going to happen.

I'm not sure how much use random blocks are though. What do they represent for a particular version of the firmware? Not so easy to just know that really.

Fred.