Hardware support for delayed aquisitions is needed about scopy HOT 7 CLOSED

Added new registers, renamed the old trigger offset registers to fifo_depth. Simulated the adc_trigger and it works correctly. Added the same mechanism to axi_logic_analyzer. Register map documentation available on wiki at https://wiki.analog.com/resources/fpga/docs/axi_adc_trigger#register_map and https://wiki.analog.com/resources/fpga/docs/axi_logic_analyzer#register_map

from scopy.

Driver support: analogdevicesinc/linux@fb2c429

from scopy.

We can implement this in a number of ways:

We can have another spinbox which would be called acquisition delay(or something like that) that would activate this. Basically offset the whole acquisition by the number of seconds specified in the spinbox
Advantage: Easily control how much data you are getting
Disadvantage: Another UI control, confusion on having 2 UI controls that seem to do the same thing (for the unexperienced, Position and Delay)

We can have a checkbox which would activate the acquisition delay. When moving your trigger to the left (increase amount of data before the trigger) exceeding the number of samples visible on the plot, the software starts adding in the acquisition delay. When the checkbox is not activated, the number of samples can be increased to the threshold Dan mentioned (500000 samples).
Advantage: Only one UI control for position
Disadvantage: UI control, that is kind of abstract (in my opinion) - only activate delayed acquisition after the soft threshold is reached

We can have no UI controls. Moving the position past the hard threshold automatically enables the acquisition delay. Basically you would always get as much data as possible, and when it is no longer possible to get data, you start putting in the acquisiton delay.
Advantage: Ease of use
Disadvantage: You might get too much data which you may not be interested in. It can be painful when exporting, analysing, etc. There is no way to control the amount of data. Might as well lower the threshold.

from scopy.

I think that the implementation specifics should not be visible to the user. The instrument could decide which approach to use and when.

from scopy.

Yes - lets emulate instruments.

Instruments don't always expose all the knobs to end users. End users just want to move the trigger position and get the results. Mihai could comment more as well.

from scopy.

Implemented with #452

from scopy.

Checked on on Scopy version: 01d69df (v1.0.1) and the feature is implemented.

from scopy.