When zoomed in there is the option (per channel) to go to the next edge, which is a useful timesaver because you dont have to zoom out, scroll and zoom in.
However, recording on multiple channels I have the use-case that I want to go to the first edge on ‘any’ channel (so the first edge after wherever I am now).
Is there a shortcut for this?
This is the single channel ‘next edge’:
@Mark This is unfortunately not possible at the moment. Can you share more about your particular use-case? You might be the first person to ask for this capability, and we’d love to learn more about your need for it!
This is something I could use a lot, for example where I am watching multiple related edges (multiple interrupt lines for example), but don’t know what order they may fire.
My work around is to mouse over the skip button for each channel of interest and note which shows the shortest interval.
@timreyes A typical use-case for me is investigating a system that usually replies to a command, but fails to do so in a certain case. In cases like this, I don’t exactly know what the next data is, it could be the next command or it could be the reply (or any of the other signals probed), since I am looking for anomalies, not ‘normal’ patterns.
One example would be an ‘3GPP TS 27.007’ compatible modem.
(Basically, the ‘AT\r\n’ ‘OK\r\n’ command/reply thing 
)
Thanks for describing those use cases @P.Jaquiery and @Mark !
@Mark - In the use case you described, does the reply to a command typically happen on the same channel as the command, another known channel, or could the reply come from a range of known channels? I wanted to understand in more detail how your use case fits into your feature request for wanting to go to the first edge on any channel.
It would be connected as a serial port (so normal RX/TX lines), so in ‘normal’ cases it will be on a known channel.
However in a recent investigation the probes were placed on testpads near the device, and extra probes were placed on another place deeper in the system, because there were some unexpected glitches. In those cases it was not known if the first edge would be seen on the device side or on the other probes.
This could be solved by this feature
if this feature existed:
Yes I do know that the simple “or” solution it is possible to miss an edge if one input channel go up and another down inside the same sample window, but in real life this is extremely unlikely, but if that must be detect too, then vote for
Thanks again everyone for your input! I’ve discussed this with the software team here and we put this on our internal backlog for now.
In parallel, I have posted this on our ideas site below with some added notes from this forum post:
