I’m running a capture with DigitalTriggerCaptureMode and use capture.wait to wait until the capture is done. Afterwards I export the captured data using capture.export_raw_data_csv.
I have set the ‘Trim pre-trigger data’ to 1us (as that seems to be the minimum supported) and I capture all 16 channels with 125MS/sec.
What I’m observing is that with the 125MS/s sample rate the CSV contains a lot of pre-trigger data (seconds) - while when using 1MS/s sample rate the CSV contains only the expected 1us of pre-trigger data.
I suspect that removing the pre-trigger data takes some time (at least when executing the same steps manually in the GUI it looks like that - there I see a small pop-up ‘Processing Session Data’)? but how to find out via the automation interface whether removing the pre-trigger data is still ongoing? To me it seems that capture.wait() does not wait for it?
Thanks,
Gerhard
@gerhardz Sorry for the late reply! Several of us were out of office last week due to the Labor Day holiday.
We have a known bug where if you save or export a capture right after finishing a capture where trim_data_seconds property is used, then the saved or exported file won’t be trimmed. This is because our software isn’t waiting for the trim operation to complete after the capture is complete before allowing the API function to return. This bug is on our backlog to fix, but we unfortunately haven’t been able to prioritize it due to other projects on our plate.
If you add a short sleep statement before saving or exporting (e.g. 1 second should work) then you should get the correct export or save file.