Searching through decoded protocols for multiple bytes patterns

Searching through decoded protocols for multiple bytes patterns
When searching through the decoded patterns, I'd like to be able to search for multi-byte patterns. I.E. when I've decoded a channel for Async Serial, and I enter 0xFB10 as a search term, it finds all cases where 0xFB then 0x10 occurred chronologically/sequentially. In the attached example, I would expect all the search terms below to return the waveform epoch.
• 0xFB
• 0xFB10
• 0x100032
• ( The attached is a bad example, but being able to search with ASCII strings would also be great )

  • Trevor
  • Jul 11 2018
  • Guest commented
    11 Jul 21:19

    We're still working on improving real-time view at the moment, and other scope-like features for our product. Because of that, this feature is still further out in our development pipeline.

  • Guest commented
    11 Jul 21:19

    Hello Mark,

    Is there any chance that this is implemented?

  • Guest commented
    11 Jul 21:19

    I was monitoring idea list from time to time and I am quite surprised that this idea is not yet planned even though ideas with much lower vote count were started.
    There is already search for single bytes so extending this feature to find sequences of bytes in decoded protocols shouldn't be difficult and looks like many people would benefit from having it.
    Could you please consider adding it to your list?

  • Mark Garrison commented
    11 Jul 21:19

    I agree, I wish it was done much earlier. We do have a placeholder on the roadmap for protocol search improvements, but it's still too far out to promise when it will be done. (it's about ~10 features out) Right now we're focusing on real time view (beta out now), data processing performance, and the analog graphs. After that should be trigger on protocol, but that's further out and subject to change.

  • Guest commented
    11 Jul 21:19

    This would be very useful It also doesn't seem to be complex so why It is not available 4 years later.

  • Grandfather commented
    11 Jul 21:19

    To expand on "search with ASCII": being able to enter an ASCII string as shown in the decoded data would be king. Entering:

    '212' B ,

    as shown for three successive characters to find that sequence would make my current task MUCH easier. To make parsing the search string sane spaces should be used as separators and would need to be quoted (' ') or entered as hex (0x20) or numeric ('32') characters. Single quote characters could be quoted (''') or entered as hex or numeric values (quoted is much the best option, but none of the options will be obvious).

  • Ruy commented
    11 Jul 21:19

    I need it

  • John N commented
    11 Jul 21:19

    +1 for arbitrary (multi-byte) search function - I picture this as similar to searching text with regular expressions, but without needing to export the data first

  • Ed2 commented
    11 Jul 21:20

    yes I assumed searching for 0x41,0x42,0x43 would work and it did not.
    I propose comma separated values A,B,C or 0x41,B,0x43
    a smart search to find ascii hex decimal binary -- want extra credit add wild carding bytes like 0x41,*,0x42 or double comma 0x41,,0x43 for don't care bytes.

  • Jarret commented
    11 Jul 21:20

    In addition, I would like to designate specific bit locations in my search pattern as a "don't care".

  • Guest commented
    27 Jul 09:37

    It makes sense that real-time view implementation takes a lot of time but this feature is orthogonal and seems to be quite trial since single byte search is already implemented. Could you please provide timeline for this feature?

    Unlike real-time view this would speed up my debugging so I would like to know if should start looking for alternatives to your SW.

  • Guest commented
    30 Jul 23:23

    I agree, this feature is definitely something that could be worked on in parallel with real-time view, and I certainly see the value-add of this feature. Although this is something we certainly want to get added, we just haven't committed this on to the roadmap with an official timeline just yet.

  • Guest commented
    16 Aug 10:38

    If you also agree that this would be small effort why not updating planning so you don't forget.

  • Guest commented
    09 Oct 07:49

    Have anything moved with this idea?

  • Guest commented
    10 Oct 17:13

    We're making progress on a brand new UI for the software at the moment.
    https://support.saleae.com/logic-software/alpha-release

    Once that's released, the protocol search system will be one of the first systems we will update since we are not too happy with how it's implemented in the current software. This idea won't be forgotten! We just can't move this over to the Planned stage just yet since we don't have a release date in mind.

    Also, you're right, we could add the new search system to the current software, but we have decided to wait to implement it into the new UI so we don't duplicate our efforts (especially since our new UI will be much easier to work with development-wise).