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.
• ( The attached is a bad example, but being able to search with ASCII strings would also be great )
Guest Jul 11, 2018
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 Jul 11, 2018
Is there any chance that this is implemented?
Guest Jul 11, 2018
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 Jul 11, 2018
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 Jul 11, 2018
This would be very useful It also doesn't seem to be complex so why It is not available 4 years later.
Grandfather Jul 11, 2018
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 Jul 11, 2018
I need it
John N Jul 11, 2018
+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 Jul 11, 2018
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 Jul 11, 2018
In addition, I would like to designate specific bit locations in my search pattern as a "don't care".
Guest Jul 27, 2018
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 Jul 30, 2018
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 Aug 16, 2018
If you also agree that this would be small effort why not updating planning so you don't forget.
Guest Oct 9, 2018
Have anything moved with this idea?
Tim Oct 10, 2018
We're making progress on a brand new UI for the software at the moment.
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).
Guest May 22, 2019
I am really disappointed that simple multiple byte search feature is still not even planned to be added.
It baffles me that Saleae thinks it is a good idea to increase price of product just to put all resources into new UI which will just look nicer instead of implementing features needed by engineers using their tool. In my opinion it is a huge mistake because we make our companies order this tool for features not for looks and for me it is the time to look for alternatives.
Disappointed Saleae customer
Joe Garrison May 22, 2019
Hey cool_kuba, appreciate the candid feedback.
Tim should not have emphasized the UI, that is a small part of an entirely new application. We know no one cares about the UI if the feature set is not useful and powerful.
We've been working on protocol analyzers and the associated search -- including sequence searching -- these past few weeks. Sequence search should be in the Alpha <2 weeks if nothing major goes wrong. Lot of moving parts right now.
All that said I do agree with the overall frustration and we are going as fast as possible to turn it around.
Is sequence-search the most important feature you need?