I already have tools for analyzing CAN messages. However, there is a real benefit to having the device input signals, CAN bus analog signal shape and CAN messages all on the same device. Synchronizing the inputs/outputs and messages takes time and slows down the process. Also, 12V logic analyzers are rarer and more expensive so I need the scope for I/O even if I had a logic analyzer for the CAN bus. Basically, the scope is sometimes the best tool for the job. I'm not trying to find a new tool. I just want to improve the tool that I'm using. I want to see every trigger condition that is present in the buffer.
Is it practical to add this function to the scope, maybe not. Either way I'll learn something.
It's unclear what you want to do. Is the CAN Decode event table not good enough? You can also export this to .csv file then import into a spreadsheet for more detailed analysis on a computer. What about the waveform recording? This can record many separately triggered waveforms ("frames") into the memory buffer, and you can then go back and view each frame, I assume with decoding if desired. The manual describes waveform recording as capturing on an interval, but you need to interpret that as re-arming the trigger on that interval. Then, when the trigger fires (which could be some condition on the CAN bus), a waveform/frame is recorded. The trigger is re-armed after the delay which can be set as low as 10 ns (effectively nil for CAN).
No, the CAN Decode table is insufficient for two reasons. 1) The CAN decode doesn't work if you zoom out very far even though the sample rate is adequate or even the waveform is saved in memory 2) The event table shows all events, not just certain events.
The idea is to trigger off a very infrequent analog event, then look at how that analog event is related to selected CAN messages in time. So for instance nothing happens for 2 minutes, Ch1 goes high for 20ms, when was the last 0x18EAFFBE message? For SPI this is easy, you use the search function. The search function doesn't work for CAN. That's the problem.
As an aside I tried using PulseView and found it to be worse than using the scope. It just didn't work very well, missed frames, couldn't handle partial frames etc.
Please keep in mind I'm not asking for advice on how to use the scope, I just wanted to know if anybody was actively reversing the firmware.