Data is backlogged and captures are stopped

We are working on an in-vehicle application that is started as a service on a Windows PC at ignition.

The application monitors external events (on CAN, signal values changes, faults et) Captures are started by a manual trigger and when the external event occurs, the capture is stopped, saved, closed and another capture is started). Practically we are interested in saving captures in case of external events that cover 25s before and 5s after the event (configurable).

Our current configuration is composed of 16 analogous channels, sample rate is 12500000.

The PC where this application is running (a mini PC in-vehicle) has 32G RAM, i7 CPU with 12 Cores.

Unfortunately, we are having huge performance issues, we are unable to work with captures in these conditions. At the second capture, the data is rapidly backlogged, and the capture is eventually stopped. From the external application we could identify that the capture was stopped but this is not an option as we cannot reliably ensure the coverage of data.

Do you have any advice on how we could work with Salea under these conditions? Is there any way to ensure a consistent behavior in which captures are continuously saved and no data is lost? How can we make sure Logic2 is able to monitor and save captures even in case of big data, large captures?

@maria.sebu Sorry for the trouble with that. Your PC specifications look good. A 30s capture (16 analog channels, 12.5 MS/s per channel) will use approximately 16GB of RAM (rough estimate).

You mentioned the following note, and I’d like to explore that observation a bit more:

At the second capture, the data is rapidly backlogged, and the capture is eventually stopped.

In particular, you’ve noted that the backlogging starts occurring at the second capture. First, can you confirm that the backlogging issue you are running into is the one that we describe in the support article below? I would also like to know if the workarounds described in the support article help out.

If so, my hunch is that your previously stopped capture’s data is still in the middle of being processed when you start your 2nd capture. It may be worth testing delaying the start of the 2nd capture to see if this is contributing to the backlogging you are seeing.