Export_raw_data_binary control range

1

Hi I am using the “from saleae import automation” in python
and I make a trigger capture and using some time triming this works very nice but wehn I export raw data binary the record is from all the time back. what can I do to the capture, in order to get a pre post trigger timewindow only in the export

        capture_config = automation.CaptureConfiguration(
                capture_mode=automation.DigitalTriggerCaptureMode(
                  trigger_type = self.triggerType, 
                   trigger_channel_index =self.triggerChannel,
                   trim_data_seconds = self.preTriggerTime, 
                   after_trigger_seconds = self.postTriggerTime
                ),buffer_size_megabytes=None )
2

@a.scheunemann Sorry for the trouble with that! I suspect a race condition is occurring where the export is occurring before the capture has completely finished trimming.

This issue was reported in another thread below:

Similar to the workaround posted in the forum post above, can you try adding a delay before exporting to see if that helps?

3

Thanks for your answer, I need extend on my case then to differentiate my problem:

I am talking about bin export, not CSV would be way to large file and not sal because I need to process it in matlab and I will also need some anlog channels.

I tryed the sleep delay before exporting ,the result is the same so I added a estimation of buffer size to reduce the file size by huge amount but the feature that the GUI can do exporting the visible range to bin seems not supported from automations api. This is pity as the trigger setup works really well with pre and post trigger time.

any chance that I can hack it in to make the server demand Logic to export the visible part of the record or somthing else like setting markers and then export between markers, or even better that it gets fixed soon.

Else I will need to use the buffer estimation safe to file then run script to find the trigger time and cut the start time and then safe again before running the processing scripts - can be done but is unnecessary overhead I like to get around.

4

@a.scheunemann I think I understand the issue better now, thank you for the additional explanation!

Unfortunately, our export_raw_data_binary() function does not provide a parameter for specifying the visible screen or timing markers to specify a specific time region to export.

Since you are using the Digital Trigger Capture mode, is there any chance you can utilize the trim_data_seconds to trim the capture after it completes (keeping only a portion of the end of the capture), and before you export your data? The downside of this however, is that you would lose any captured data that you trim out.

5

the trim_data_secounds does work for the visible screen then it is not respected in the export.
even though if looking at the documentation :

"trim_data_seconds: Seconds of data at end of capture to keep. If unspecified, all data will be kept.

after_trigger_seconds: Seconds of data to record after triggering"

the wording “at end of capture” is confusing against “after triggering” I wrapped the code so that I can set a:
preTrigger_time_sec and postTrigger_time_sec because it is much more intuitive in my opinion

regardless the attributes are in use they do the right thing to the view but the export is exporting the buffer and and the buffer is not cropped to the visible screen or the trim_data_secounds attribute in export.

6

@a.scheunemann Strange… we are fixing a known bug soon with trimming captures (more information below):

Specifically, data is not completely deleted after a trigger, and it’s possible the export in your case is being affected because of this.

I’ll update again here once that software is released (I expect it will be ready later this week), and we’d be curious to see how the new version works out for your script.

7

interesting looking forward to the development, and yes bugs are always strange :wink:

8

@a.scheunemann The next software update has been released which fixes the issue with remnant data after trimming. Can you test this version out to see if that solves the issue on your end?