Buffered data with triggered logging?

[Map63Vette]

I had a question regarding triggered logging and where exactly the log starts. Is it possible to buffer data before the trigger so that when the trigger itself happens it can see "into the past" just a bit so as to catch what might have caused the trigger? My experience with this is more with stuff like security cameras where a motion even will trigger recording, but it will actually start the recording a set amount of time before the trigger itself actually happened.

Long story short, I'm interested in setting up an automatic trigger to log whenever I get a knock event. I have an indicator on my digital dash at the moment, but I'm not sure if it works and even if it does it tends to go away so quickly that I'm not sure I would even notice it if it did trigger. My thought was to set up automatic logging and have it trigger off of one of the knock parameters. I've generally tuned my engine to the point that I haven't noticed anything, but I can't really reliably stare at my dash safely while also trying to run my car hard enough to get in a knock zone. I figured if I set up auto logging it would be easier to see if anything does occur, then I could dig into where it was on the map and what might be causing it. Just figured it would be nice to see the lead up to the knock itself on the log and not have the first datapoint be when it's already knocking.

[ShirtUser]

I don't think there is any way to go back in time to start a log. But, you have some options.

First, have you seen my post with knock counters? viewtopic.php?p=596705#p596705

Those have been working really well for me. I have an indicator on my dash with the knock count, resettable by tapping it, and it goes red for 15 seconds if there was a knock recently.

TS doesn't log as quickly as the ECU is acting, so it's entirely possible for there to be a knock event that TS won't catch. Which is why the channel looks for not only the knock threshold, but also the knock retard. And I have mine setup to retard on the first event. With that, my knock counter doesn't miss anything.

Additionally, I have the entire background on the dash set to go red if there are more than 10 knock events within 5 seconds. So if I'm in the middle of a pull and lots of knocks are happening, I get a big red screen in my peripheral vision. The "knocksHigh" and "RecentKnocksHigh" combine to trigger that. I have a few other things that will trigger that big red screen as well. Like AFR high for too long.

You could also use a knock event as the trigger for a custom action that puts a marker in the log with a comment. Which would make it really easy to find the event in the log. Or, you can just search the log for anytime that the knockretard is greater than 0.


But, the bottom line is that logging has to already be running in order to capture an event. There is no sliding window cache that you can dump into a log file.

You could have a script setup to automatically cleanup old log files. So they don't use up too much space. And you could setup the log start/stop to only be logging when you care about it. For example, when TPS is above a certain threshold, or RPMs are non-idle, or boost is positive, or whatever makes sense to you.

[Reaper]

So a datalog/fault snapshot? Datalog constantly running in the background, but being overwritten constantly and save that datalog chunk upon an action/trigger? Pretty sure that'd kill your poor SD card pretty quick.

[Raymond_B]

I'd just setup full time logging triggered above a certain TPS, or RPM (I have mine start at RPM >500), or coolant temp. No need to get too fancy.

[Map63Vette]

I don't think there is any way to go back in time to start a log. But, you have some options.

First, have you seen my post with knock counters? viewtopic.php?p=596705#p596705

Those have been working really well for me. I have an indicator on my dash with the knock count, resettable by tapping it, and it goes red for 15 seconds if there was a knock recently.

TS doesn't log as quickly as the ECU is acting, so it's entirely possible for there to be a knock event that TS won't catch. Which is why the channel looks for not only the knock threshold, but also the knock retard. And I have mine setup to retard on the first event. With that, my knock counter doesn't miss anything.

Additionally, I have the entire background on the dash set to go red if there are more than 10 knock events within 5 seconds. So if I'm in the middle of a pull and lots of knocks are happening, I get a big red screen in my peripheral vision. The "knocksHigh" and "RecentKnocksHigh" combine to trigger that. I have a few other things that will trigger that big red screen as well. Like AFR high for too long.

You could also use a knock event as the trigger for a custom action that puts a marker in the log with a comment. Which would make it really easy to find the event in the log. Or, you can just search the log for anytime that the knockretard is greater than 0.


But, the bottom line is that logging has to already be running in order to capture an event. There is no sliding window cache that you can dump into a log file.

You could have a script setup to automatically cleanup old log files. So they don't use up too much space. And you could setup the log start/stop to only be logging when you care about it. For example, when TPS is above a certain threshold, or RPMs are non-idle, or boost is positive, or whatever makes sense to you.

I'll have to check that out. I had a similar idea where I had a gauge that watched knock retard and it was supposed to turn red whenever the value was greater than 1, but I think I went away from it in favor of watching some other knock channel once I actually got my module installed (I had the dash set up in advance of getting the module and didn't realize how many different knock variables existed). I had the same idea to do a full screen warning as well, but didn't dig into that one quite as much. I think with MS Ultra I can actually make a popup window happen with a trigger that would probably draw my attention and require a manual button press to go away as well, so certainly some options on the table there I'll have to look at.

So a datalog/fault snapshot? Datalog constantly running in the background, but being overwritten constantly and save that datalog chunk upon an action/trigger? Pretty sure that'd kill your poor SD card pretty quick.

Sort of. I'm not actually datalogging to an SD card on the MS. I have a Raspberry Pi constantly attached working as a digital dash. I guess technically I'd be writing to that SD card though, depending on how TS actually handles that. I was thinking more like a memory cache that is constantly overwritten compared to hard storage. I'm assuming the MS doesn't have memory onboard the same way a computer does, but the general idea would be that you could set up some amount of time that would always be cached in memory (like 1-5 seconds) and when the datalog gets "activated" by the trigger it would then transfer that memory cache to "hard" storage and continue logging from there.


All that said, the TPS threshold logging would likely catch any primary knock areas on the map, though I'd rather not dig through all of them looking to see if I had a knock event. Maybe I could make a script that would parse them as they are created and automatically delete them if it doesn't see any knock events in the logs, but that might get interesting. I don't think the log files are plaintext kind of format, so it could be difficult to set that up with simple programming skills.

Maybe an alternative would be more like a traditional check engine light. Kind of what ShiftUser was using with his full screen warning, but in a more "OEM" kind of way that would just let me know I've seen X amount of knock events in a given timeframe and it would latch on the failure. Doesn't help me to know where they happened though is the main thing.

[ShirtUser]

The built in CEL checks have one for the knock sensor "cel_status_knock". Not exactly what you're looking for, but good to know it's there.

This is what my knock counter looks like when there are no knocks:

knock_counter_0.JPG (15.06 KiB) Viewed 193 times

And here it is when knocks are detected and they were recent:

knock_counter_11.JPG (13.1 KiB) Viewed 193 times

I have it setup where the red background goes away after 15 seconds, leaving just the # of knocks. However, you could easily change it so that it stays red anytime the knock count is above 0. And then tapping on it would reset it back to zero and also clear the red background.

For finding the events, do you have MegaLogViewer? If so, it's super easy to find the knock events. Either search for anytime knock retard is above 0, or use the knock counter custom channels I linked to and search for anytime "knockDetectedNewCombined" is above 0.


Or, using the custom knock detection channels, create a custom action and trigger:

MarkLog.JPG (79.45 KiB) Viewed 193 times

logtrigger.JPG (109.27 KiB) Viewed 193 times

That will put a marker in the log file, which shows up as a vertical line in MegaLogViewer. Very easy to find and view the comment for the event.


I've spent many hours analyzing knock events, signals, response. It really is easy to find them in the log. As long as the log was running. TS logs are usually fast enough for most knock analysis, but for knock signal analysis and tuning you really need to use the SD logs.

For log parsing, you could setup a trigger that would execute a script anytime a knock is detected. The script could wait some reasonable amount of time, then copy the current log file to another directory (or email it yourself, or whatever). And have a scheduled task that cleans up log files older than whatever period you want. Like, older than a week or something.

Personally, it's much much easier for me to just look at the knock count on the dash. If it's more than 0, I make sure to review the log. And, I have all of the logs setup to sync to my cloud so I can review them from my desktop. The sync also cleans up old logs on the on-board computer so they don't accumulate. The advantage of this is that I have logs of all drives for reference. Which is really really useful for analysis where you want lots of data.


I suppose you could create some triggers where after X amount of seconds after the last knock event it stops the logs, then starts a new log. That way, you know any knock events are at the end of any log. But, again, it's so easy to find knock events in a log file, I don't see much advantage to that approach.

[Raymond_B]

I don't think there is any way to go back in time to start a log. But, you have some options.

First, have you seen my post with knock counters? viewtopic.php?p=596705#p596705

Those have been working really well for me. I have an indicator on my dash with the knock count, resettable by tapping it, and it goes red for 15 seconds if there was a knock recently.

TS doesn't log as quickly as the ECU is acting, so it's entirely possible for there to be a knock event that TS won't catch. Which is why the channel looks for not only the knock threshold, but also the knock retard. And I have mine setup to retard on the first event. With that, my knock counter doesn't miss anything.

Additionally, I have the entire background on the dash set to go red if there are more than 10 knock events within 5 seconds. So if I'm in the middle of a pull and lots of knocks are happening, I get a big red screen in my peripheral vision. The "knocksHigh" and "RecentKnocksHigh" combine to trigger that. I have a few other things that will trigger that big red screen as well. Like AFR high for too long.

You could also use a knock event as the trigger for a custom action that puts a marker in the log with a comment. Which would make it really easy to find the event in the log. Or, you can just search the log for anytime that the knockretard is greater than 0.


But, the bottom line is that logging has to already be running in order to capture an event. There is no sliding window cache that you can dump into a log file.

You could have a script setup to automatically cleanup old log files. So they don't use up too much space. And you could setup the log start/stop to only be logging when you care about it. For example, when TPS is above a certain threshold, or RPMs are non-idle, or boost is positive, or whatever makes sense to you.

I'll have to check that out. I had a similar idea where I had a gauge that watched knock retard and it was supposed to turn red whenever the value was greater than 1, but I think I went away from it in favor of watching some other knock channel once I actually got my module installed (I had the dash set up in advance of getting the module and didn't realize how many different knock variables existed). I had the same idea to do a full screen warning as well, but didn't dig into that one quite as much. I think with MS Ultra I can actually make a popup window happen with a trigger that would probably draw my attention and require a manual button press to go away as well, so certainly some options on the table there I'll have to look at.

So a datalog/fault snapshot? Datalog constantly running in the background, but being overwritten constantly and save that datalog chunk upon an action/trigger? Pretty sure that'd kill your poor SD card pretty quick.

Sort of. I'm not actually datalogging to an SD card on the MS. I have a Raspberry Pi constantly attached working as a digital dash. I guess technically I'd be writing to that SD card though, depending on how TS actually handles that. I was thinking more like a memory cache that is constantly overwritten compared to hard storage. I'm assuming the MS doesn't have memory onboard the same way a computer does, but the general idea would be that you could set up some amount of time that would always be cached in memory (like 1-5 seconds) and when the datalog gets "activated" by the trigger it would then transfer that memory cache to "hard" storage and continue logging from there.


All that said, the TPS threshold logging would likely catch any primary knock areas on the map, though I'd rather not dig through all of them looking to see if I had a knock event. Maybe I could make a script that would parse them as they are created and automatically delete them if it doesn't see any knock events in the logs, but that might get interesting. I don't think the log files are plaintext kind of format, so it could be difficult to set that up with simple programming skills.

Maybe an alternative would be more like a traditional check engine light. Kind of what ShiftUser was using with his full screen warning, but in a more "OEM" kind of way that would just let me know I've seen X amount of knock events in a given timeframe and it would latch on the failure. Doesn't help me to know where they happened though is the main thing.

When you say "digging through the logs" you mean looking at them in Megalogviewer? If so then you'd just do a quick filter for TPS > than whatever, or like mentioned look for knock events. Maybe I am misunderstanding what you're saying, but searching through the logs looking for events of almost any kind is really easy. Also remember you can open multiple log files at the same time and MLVHD will present them as one.

[Map63Vette]

The built in CEL checks have one for the knock sensor "cel_status_knock". Not exactly what you're looking for, but good to know it's there.

This is what my knock counter looks like when there are no knocks:
knock_counter_0.JPG

And here it is when knocks are detected and they were recent:
knock_counter_11.JPG

I have it setup where the red background goes away after 15 seconds, leaving just the # of knocks. However, you could easily change it so that it stays red anytime the knock count is above 0. And then tapping on it would reset it back to zero and also clear the red background.

For finding the events, do you have MegaLogViewer? If so, it's super easy to find the knock events. Either search for anytime knock retard is above 0, or use the knock counter custom channels I linked to and search for anytime "knockDetectedNewCombined" is above 0.


Or, using the custom knock detection channels, create a custom action and trigger:
MarkLog.JPG

logtrigger.JPG


That will put a marker in the log file, which shows up as a vertical line in MegaLogViewer. Very easy to find and view the comment for the event.


I've spent many hours analyzing knock events, signals, response. It really is easy to find them in the log. As long as the log was running. TS logs are usually fast enough for most knock analysis, but for knock signal analysis and tuning you really need to use the SD logs.

For log parsing, you could setup a trigger that would execute a script anytime a knock is detected. The script could wait some reasonable amount of time, then copy the current log file to another directory (or email it yourself, or whatever). And have a scheduled task that cleans up log files older than whatever period you want. Like, older than a week or something.

Personally, it's much much easier for me to just look at the knock count on the dash. If it's more than 0, I make sure to review the log. And, I have all of the logs setup to sync to my cloud so I can review them from my desktop. The sync also cleans up old logs on the on-board computer so they don't accumulate. The advantage of this is that I have logs of all drives for reference. Which is really really useful for analysis where you want lots of data.


I suppose you could create some triggers where after X amount of seconds after the last knock event it stops the logs, then starts a new log. That way, you know any knock events are at the end of any log. But, again, it's so easy to find knock events in a log file, I don't see much advantage to that approach.

I like the idea of that gauge, I might have to try to copy it to my dash in some way. Nice to see a track of the knocks and have that little extra warning when it happens.

When you say "digging through the logs" you mean looking at them in Megalogviewer? If so then you'd just do a quick filter for TPS > than whatever, or like mentioned look for knock events. Maybe I am misunderstanding what you're saying, but searching through the logs looking for events of almost any kind is really easy. Also remember you can open multiple log files at the same time and MLVHD will present them as one.

More just having all the different log files separate to look though, especially if there isn't anything relevant in there. I'm at the point now that I'm pretty happy with my tune and the car runs really nice, would just like to be able to catch any oddball events or more rare occurrences on logs in a more automatic way if possible. I actually kind of like looking through logs to understand how the car is working, but I'd rather not have a huge folder full of log files that might be anywhere from a couple of minutes to an hour long. I agree that MLV is great at actually finding events and has really nice flexibility on how to present the data, my thing was more just trying to have a rough "filter" to limit the amount of data that is present to start with. I run a cloud setup as well that my dash will sync to if I let my car sit in the driveway long enough to connect to the wifi. Makes tweaking tunes and dealing with logs easier for sure as I don't have to do it on a tiny low resolution screen with a foldup keyboard.

[Raymond_B]

I have an SD card on a little cheap Amazon ribbon cable extension under the seat that logs any time RPM > 500 which is basically all the time. It's set to overwrite, but with a big SD card it doesn't do it very often. So if I have something happen I choose the most recent log copy it over to the laptop and sync it with OneDrive. From there I can look at it on the laptop or my PC. I actually prefer SD card logging as the rate is configurable and have better resolution than logging to a laptop or other OS.

Anyway I get what you're saying, just some sort of error bucket kind of like security cameras have that keep 10 sec prior to a motion event or whatever.

[ShirtUser]

Given your objective of only capturing a short segment of data leading up to, during and after an event, I think this might be your best bet without going outside of the TS family:

1) Create a series of triggers that start the logging and then stop it after a specific time period (e.g. 5 minutes, 15 minutes, whatever) as long as there have been no events of interest within the last Y seconds. So you don't accidentally stop logging in the middle of a series of knocks or whatever you're looking for.

2) Create a trigger that goes off once an event of interest occurs with the same wait period as the log start/stop trigger, have it run an action...

3) Create an action that runs a script that does the following:
a) Waits Z seconds to make sure the log has finished closing
b) Takes the last definable # of log files in the datalog directory and does what you want to do with them to preserve them (email them, move to a different directory, etc). Keeping two is probably a good bet so you catch the log with the event, and the log before it in case something led up to it.

4) Create a Scheduled Task (Windows) or cron job (Linux) to clear out any log files in the datalog directory older than whatever time period you think is reasonable. Set it to run at whatever frequency you want.


I would create a custom channel (and accompanying datalog entry) to define what an event of interest is. Knocks, AFR's too high, or whatever you want. Then you can reference it in your custom triggers and have a single easy place to make changes to it. That's how I manage the dashboard's red background. It's one custom channel with all of the things that might make me want to stop immediately. And white text pops up over the red background with the specific problem (too many knocks, AFR too high to too long, boost too high, etc).


You could use the pop-up action in TS, but I'm not sure what that gets you beyond a nice dash display. But, whatever works for you.




Another option....

If you're running Linux, or WSL, and don't mind getting a little more into the weeds, you could try out this utility: https://github.com/karniv00l/mlg-converter

You could have a continuous log running in TS, and a log stop/start triggered X seconds after an event of interest. That same event could trigger a script to take the recently closed log, convert it to CSV using the above utility, and extract whatever timeframe you want from the resultant CSV using one of the time based columns.



You might even be able to convince Phil to add a CLI (or custom action) driven feature to TS so you can export to CSV with TS and go from there.

[Map63Vette]

Hmm, those are some very clever ideas. I'll have to look into that some more. I didn't realize what all you could make TS do with triggers and actions. I like the idea of an "inbox" folder that all logs get initially stored in, but anything that has something of interest gets automatically moved to a different folder. Then a simple cron job style script to dump the "inbox" every so often. That might be in my wheelhouse to put together one of these days. Thanks for the ideas!