LS1 Ram log parameters

[Gampy]

Understood ... Thank ya sir!

[NSFW]

You can find ram addresses if you find a generic way of interpreting the code that handles the pid request in the DLC interrupt handler, but its true there isnt much extra there. Raw data eg 1 byte 0-255 is usually the analog ADC resolution. If you go say 3 bar map the analog resolution doesn't change, but the scaling to -100 to 300kpa does. if you read the map voltage pid you'll get the max precision which you can then scale on the pc side, same as the pcm does. dpids are about as good as you'll get. the packets get longer so fewer packets = less time lost in stopping and starting transmission but they dont get too long and you can get more data per packet more quickly. beyond that you can put the pcm in to 4x data speed and push a lot more data through again. None if this is to say you cant get more things if you go direct to ram but I dont think there is a huge amount of practical gain there.

Just to be clear, dpids can be a combination of regular PIDs and/or RAM addresses, so you can log equally fast either way.

RAM values are almost always 2-bytes though, so for things like temperatures where you don't need a lot of precision, it's helpful to use single-byte PID if there is one for the parameter you want.

I haven't tried logging at 4x yet, but I'm looking forward to trying it at some point. Probably not until the weather gets warmer though, that's something I can't do from the comfort of my desk.

[NSFW]

It would be helpful to approach this problem from the opposite direction:

RAM parameters are useful if they provide information that we can't get from a PID.
Columns in a log file are useful if they give insight into engine health, or insight that will help solve a problem.

What columns do we want in our logs to get insight into engine health?
What problems do we want to be able to troubleshoot with data logs?

[kur4o]

I was thinking if we log ram, the refresh rate might be faster, since we read ram. Usually pids are processed subroutines for each pid and the timer they run from is unknown. So some refresh delay can occur in pids even that, they are read at max speed.

Some undefaulted raw ad channels that are not used in code but are left over in pcm hardware. Usable for external sensors added.

Scalars used for tablelookup. For very accurate hystograms. Some interesting data that is not in pids.

Custom OS addons that are not available in any other form.

[NSFW]

PCM Logger is already all set up to log arbitrary RAM addresses as part of log profiles, so if anyone knows what RAM address they want to log, they can log it just by editing the Parameters.RAM.xml file and picking the parameter in the UI.

I was wondering if there were any parameters for existing features of the 7603 OS that I should try to look up.

The logger is now using a PCM feature that sends parameters at 10hz, so I don't think there will be any difference in logging speed with a RAM address vs a PID. It would be easy to test though if you want to compare.

[antus]

yeah im pretty sure bus speed is more limiting than processing speed between the raw ADC and a filtered value of some kind. Is there a pid in particular were interested in to see if we can figure out its internal timings?

[Boostedforlife]

Timing or knock would be two that I would think you would want as fast as possible. But I'm just guessing here hope it helps.