another pretrigger choice

How about in Control panel adding a choice (Maybe a switch like after the Source option?) after the Pre Trigger for another option instead of only time? I use pre trigger often and many times I would like the trigger point to remain for example at 1 div from left side of screen regardless of switching the Time adjustment.
Perhaps a selection choice of time (already there) and divisions. (or percentage of horizontal)

How about in Control panel adding a choice (Maybe a switch like after the Source option?) after the Pre Trigger for another option instead of only time? I use pre trigger often and many times I would like the trigger point to remain for example at 1 div from left side of screen regardless of switching the Time adjustment. Perhaps a selection choice of time (already there) and divisions. (or percentage of horizontal)

Hi Dimensions,
Thanks for the suggestion. Just trying to understand it a bit better - currently the pre- or post trigger time is not limited by the number of divisions (for example you could have 10 divisions of time, and a pre-trigger - or post trigger time of 100 divisions), or by the trigger having to be on-screen (the trigger can be way off to the left or right of the screen, if you want). You seem to be after a mechanism to ignore the current screen time position, and force the trigger to be so many divisions to the right (or left) of the graph left hand edge? This goes against our wysiwyg philosophy, and increases the complexity of the control panel, but we are willing to think about it, depending on what other people think.

So we have these options to implement this idea:
1. The user can optionally set a number of divisions for the trigger position. The graph time scale is ignored, and a new 0 point is established the specified number of divisions to the right (or left) of the graph left hand edge when the next acquisition is started. This might lead to some confusion, as after receiving the next triggered frame, we would change the time axis to reflect the new 0 position, obliterating the current time axis settings. For example, say the time scale was in ms/div, and initially captured with a time range of -1 to +9ms. In the current implementation, if the user zooms on 8ms, to 10us/div, and triggers again, the system will capture a signal with 8ms of post trigger and display the waveform chunk centred around 8ms. (say 8ms +/- 5 divisions of 10 usec/div). With the alternate approach, and assuming a trigger position 1 division to the right of the left hand graph edge, the graph would change to display -10 to + 90 usec, losing the previous graph time relativity.
2. We add a new 'Lock trigger position' button. Once the user has the trigger where they want it, they push 'Lock trigger position' button, and the trigger stays physically locked to that position on the graph, percentage wise. So pushing the button with the trigger one division to the right of the left hand edge would mean the trigger (and zero position) would always stay one division to the right of the graph edge, even though time scales are changed.
3. We don't add a new option, as it goes against wysiwyg and confuses the user.

Which do you vote for - all user responses welcome!

Hi Dimensions, Thanks for the suggestion. Just trying to understand it a bit better - currently the pre- or post trigger time is not limited by the number of divisions (for example you could have 10 divisions of time, and a pre-trigger - or post trigger time of 100 divisions), or by the trigger having to be on-screen (the trigger can be way off to the left or right of the screen, if you want). You seem to be after a mechanism to ignore the current screen time position, and force the trigger to be so many divisions to the right (or left) of the graph left hand edge? This goes against our wysiwyg philosophy, and increases the complexity of the control panel, but we are willing to think about it, depending on what other people think. So we have these options to implement this idea: 1. The user can optionally set a number of divisions for the trigger position. The graph time scale is ignored, and a new 0 point is established the specified number of divisions to the right (or left) of the graph left hand edge when the next acquisition is started. This might lead to some confusion, as after receiving the next triggered frame, we would change the time axis to reflect the new 0 position, obliterating the current time axis settings. For example, say the time scale was in ms/div, and initially captured with a time range of -1 to +9ms. In the current implementation, if the user zooms on 8ms, to 10us/div, and triggers again, the system will capture a signal with 8ms of post trigger and display the waveform chunk centred around 8ms. (say 8ms +/- 5 divisions of 10 usec/div). With the alternate approach, and assuming a trigger position 1 division to the right of the left hand graph edge, the graph would change to display -10 to + 90 usec, losing the previous graph time relativity. 2. We add a new 'Lock trigger position' button. Once the user has the trigger where they want it, they push 'Lock trigger position' button, and the trigger stays physically locked to that position on the graph, percentage wise. So pushing the button with the trigger one division to the right of the left hand edge would mean the trigger (and zero position) would always stay one division to the right of the graph edge, even though time scales are changed. 3. We don't add a new option, as it goes against wysiwyg and confuses the user. Which do you vote for - all user responses welcome!

My vote is for #2. We add the option of 'Lock trigger position' button.

My vote is for #2. We add the option of 'Lock trigger position' button.

I vote for 2.

A very basic, common and (at least for me) welcome feature
on almost every scope I know.

Changing the time base should not alter the trigger (zooming around
trigger).

Zooming in by mouse should of course set the trigger to
a new calculated position. Otherwise this feature would not make sense.


To me, this feature would only make sense if the time base can
be altered by a a single-hotkey operation (e.g. left, right without shift, ctrl, etc...).

Right now, I programmed Autohotkey (www.autohotkey.com) to do this for me.
Would it be possible to add user defined hotkeys?

Bart, give us an inch and we will take an ell ;-)


Axel



P.S.:
Log, Log, Log ;-)

I vote for 2. A very basic, common and (at least for me) welcome feature on almost every scope I know. Changing the time base should not alter the trigger (zooming around trigger). Zooming in by mouse should of course set the trigger to a new calculated position. Otherwise this feature would not make sense. To me, this feature would only make sense if the time base can be altered by a a single-hotkey operation (e.g. left, right without shift, ctrl, etc...). Right now, I programmed Autohotkey (www.autohotkey.com) to do this for me. Would it be possible to add user defined hotkeys? Bart, give us an inch and we will take an ell ;-) Axel P.S.: Log, Log, Log ;-)