PCLink feature request - Auto-Save ECU Logs

[Pete_89t2]

Before I describe the feature, here's the use case I have in mind that this wish list feature would support:

- Assume the user needs to use ECU logging to capture lots of parameters at maximum sample rates (i.e., substantially higher than PCLink can capture with a connected laptop), though a laptop with PCLink running will be connected to the Link ECU during a road tuning or track session. Road tuning/track session duration is rather lengthy, let's say over 30 minutes.

- Given this requirement, a G4+ might get only about 10~15 minutes of ECU logging before the ECU log starts overwriting itself (FIFO buffered data); a G4X or G5 would get more ECU logging time, but for the purposes of this use case, lets say that time is still substantially less than the duration of the track or road tuning session duration.

- There's no passenger in the car available to safely operate PCLink on the laptop to manually store ECU logs before they fill up and start overwriting.

What I'm proposing is an "auto-save ECU logs" function that will automatically save the ECU log every XX minutes (XX = user selection), gives the ECU log a unique name (can be a simple auto naming convention & increment counter, e.g., ECU_Log_1, ECU_Log_2...etc.). This function would work as such as long as the PCLink/laptop is connected to the G4+/G4X/G5 ECU and the user has this "auto save" feature enabled.

Hope this one is in the easy to do category, and we see it happen in the next PCLink update!

[Vaughan]

One slight issue with this that I can foresee is that if you are logging a lot of data at a high rate there's a good chance that it will take longer to download than it will to create more data.

Could you log just the things you want in high resolution on the ECU and log the remainder of the lower resolution stuff with a PCLink log and then time sync the logs by having something like engine running time in both?

[Pete_89t2]

16 hours ago, Vaughan said:

One slight issue with this that I can foresee is that if you are logging a lot of data at a high rate there's a good chance that it will take longer to download than it will to create more data.

Could you log just the things you want in high resolution on the ECU and log the remainder of the lower resolution stuff with a PCLink log and then time sync the logs by having something like engine running time in both?

Understand that the download time could be lengthy, and that you can't log new data while the download is in progress, but that would be a worthwhile trade-off, at least for my use case. I also understand how to judiciously log the high-res data I need, but with the G4+ platform, I'm still finding that I run out of log capacity before a road tuning session is complete. What I'm trying to do now is use logs from literally every drive I take, under as many real world conditions as possible, so I can accurately characterize what the "normal" noise floor looks like in every RPM/MAP cell, using MegaLogViewer (MLV) to do histogram analysis of the log data, so I can set my knock control thresholds. Since I'm using MLV for data analysis, I need to keep the sample rates for every data element the same so the histogram analysis doesn't break or have any hiccups.

You might ask why I'm doing this as there are easier ways to tune knock control in a piston engine car - I'm tuning a rotary. All of the methods I know of for tuning knock control thresholds on a piston engine involve CAUSING some limited knock/ping, which is something you really NEVER want to do with a rotary. So instead I've taken a conservative tuning approach which has resulted in my boosted 13B-REW running rather well, hitting my power goals with zero knock/ping happening. Anyway, I'd like to use my G4+ knock control feature & dual wide band knock sensors to provide some extra protection for a potential bad tank of gas or anything else that might cause my conservative tune to knock/ping. The idea here is to thoroughly characterize the engine's noise floor without knock via MLV histogram analysis, and use that data to set my knock thresholds - if done right, with lots of good high-res data, this approach should result in a good knock safety net without excessive false alarms due to random spurious noise 

 

[Vaughan]

5 hours ago, Pete_89t2 said:

Understand that the download time could be lengthy, and that you can't log new data while the download is in progress, but that would be a worthwhile trade-off, at least for my use case. I also understand how to judiciously log the high-res data I need, but with the G4+ platform, I'm still finding that I run out of log capacity before a road tuning session is complete. What I'm trying to do now is use logs from literally every drive I take, under as many real world conditions as possible, so I can accurately characterize what the "normal" noise floor looks like in every RPM/MAP cell, using MegaLogViewer (MLV) to do histogram analysis of the log data, so I can set my knock control thresholds. Since I'm using MLV for data analysis, I need to keep the sample rates for every data element the same so the histogram analysis doesn't break or have any hiccups.

Even if this was a feature that was to be done it would not make it into G4+. If 100Hz was a fast enough logging rate then you could maybe setup an external logger over CAN.

5 hours ago, Pete_89t2 said:

You might ask why I'm doing this as there are easier ways to tune knock control in a piston engine car - I'm tuning a rotary. All of the methods I know of for tuning knock control thresholds on a piston engine involve CAUSING some limited knock/ping, which is something you really NEVER want to do with a rotary. So instead I've taken a conservative tuning approach which has resulted in my boosted 13B-REW running rather well, hitting my power goals with zero knock/ping happening. Anyway, I'd like to use my G4+ knock control feature & dual wide band knock sensors to provide some extra protection for a potential bad tank of gas or anything else that might cause my conservative tune to knock/ping. The idea here is to thoroughly characterize the engine's noise floor without knock via MLV histogram analysis, and use that data to set my knock thresholds - if done right, with lots of good high-res data, this approach should result in a good knock safety net without excessive false alarms due to random spurious noise 

G4X has normalised modes for knock control which make characterising knock a lot easier as it is based around current noise level relative to recent noise levels rather than absolute noise.

[Pete_89t2]

18 hours ago, Vaughan said:

G4X has normalised modes for knock control which make characterising knock a lot easier as it is based around current noise level relative to recent noise levels rather than absolute noise.

Hmm, I've been seriously thinking of upgrading to a G4X Fury for several reasons, and you may have just given me another reason. Question though - does the G4X "normalized" knock control mode still rely solely on in-band amplitude measurements to do its thing, or does the G4X/G5 employ some additional signal processing to capture/extract frequency or time domain details of the audio signal to help it discriminate between actual knock and random noise?

[Vaughan]

On 9/7/2024 at 2:36 AM, Pete_89t2 said:

Hmm, I've been seriously thinking of upgrading to a G4X Fury for several reasons, and you may have just given me another reason. Question though - does the G4X "normalized" knock control mode still rely solely on in-band amplitude measurements to do its thing, or does the G4X/G5 employ some additional signal processing to capture/extract frequency or time domain details of the audio signal to help it discriminate between actual knock and random noise?

It is still entirely based on the selected frequency band, both G4+ and G4X allow you to select an engine angle based window during which it listens for noise, the G4X normalised modes do work in the time domain in that they compare the most recent noise level against the average of the recent previous noise levels.