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?

9

I tested but the answer is yes and no:

now the Logic does respect the visible window in export, great!

But the trim attribute is ignored now … This means the output is dependent on the visible zoom, and zoom is not that impacted by the trim attribute as the version before … so you kind of solved one part, but added a new bug by killing the effect of the trim parameter.

as there are no zoom access from api - this solution could be even worse as by mistake it could be lesser data in the export as wished.

Further I do not think that everybody expects the export to be the visible range - this must be an additional switch in the API, the GUI offers 3: all, visible , between markers. I guess in api visible and all must be available!

I might missing something but you not also updated the python package “saleae” it is still on 0.12.0, right?

10

@a.scheunemann It turns out the latest software update introduced a few more bugs that other users have recently reported. The latest update was quite a large overhaul.

You’re right however that the export should not default to the visible screen, especially during an automation script where the user does not have control over the zoom level. If this bug was in fact introduced, this was not intended and should be fixed. I haven’t had a chance to reproduce this yet, but we’ll get this on the backlog for investigation.

1 Like
11

@a.scheunemann To answer your question below:

I might missing something but you not also updated the python package “saleae” it is still on 0.12.0, right?

Are you referring to the Python automation package called logic2-automation referenced in our documentation below?

If so, the current version of our automation package is version 1.0.7 (PS I just noticed that we still refer to it as 1.0.6, we’ll get that updated).

12

sorry I just did “pip list” and got

  • logic2-automation 1.0.7
  • saleae 0.12.0

confused…

and yes I use “logic2-automation” for this part of the work.

I guess my confusion comes from the import …

from saleae import automation
13

@a.scheunemann Ah, I see the confusion now! The saleae 0.12.0 library shown in your list is from a community created Python automation wrapper (linked below for reference) for the older (no longer supported) Logic 1.x software. I assume it was installed on your PC some time ago. It has no connection to our current Automation API for the Logic 2 software.

14

more you do more you know… :wink:
Yeah my pip environment needs some skimming before I go life with my automation but that is the normal hustle I assume.