At minimum provide a counter to trigger on the nth event. For example on the 5th rising edge. At best provide if then else triggering across multiple channels.
My two cents here:
to trigger on certain protocol events. For instance, if one selects I2C, to trigger at a START or STOP conditions.
This, in my opinion, is one of the most important features needed to solve complex issues. For simple checking the edge triggering is good enough, but when you are handling intermittent issues, for example, it's almost impossible to collect the data at the time the problem happens. Adding advanced triggering support would take the Logic to a whole new level of usability.
On top of all the ideas given, I could propose something that would probably be easier and would still be a great help:
If the trigger can free-run with a set time window and only stop when the user manually tells it to stop, one could keep recording until the issue happens, and then stop with enough recording time to go back and check whatever happened just before that. It's the same idea as recording without the trigger, but it should keep recording (and discarding the old data) until the user stops.
Absolutely, this is where other product have the advantage. You have ONE edge and multiple HI LO values on other channels. A count and edge on all channels or at least more than one would be super.
Also to be able to trigger on any voltage in the analog input range please.
This is really important to include pattern trigger, sequential pattern (4 is enough for starters) and ORed pattern trigger (trigger in pattern [A or B], [A or BC], [AB or CD] . For a start a pair of one/two pattern sequences would be enough.
This would really be useful! I am a full supporter of this. It really helps when figuring out unknown signals, especially when you want to trigger on one channel (say sync on video signals) and view the actual data sent on another pin.
Also the ability to trigger on a combination of signals
You won't be notified about changes to this idea.