Manually set start / end points of analyzer decoding

Voters 18

T
K
A
T
M
+ 11 voters
R
S
M
S
P
F
C
C
M

A
+ 1 anonymous

Open
Subscribe

T	tjcrone

In 1.x it was possible to manually set the start point of an analysis with a marker (see support.saleae.com/user-guide/using-logic/using-protocol-analyzers). In 2.x the only way to define the analysis range or start point is by trimming data (which can be done with markers). It would be useful to allow users to set the analysis range or the start point of decoding without requiring that users trim data. This is a great feature in the current stable version which should be included in 2.x when possible.

28-07-2020 -

Activity Newest / Oldest

Tim

discuss.saleae.com/t/welcome-to-logic-2-community/7/11
"Folks, this software is great! I used PulseView before, and this is much better, thank you!

One limitation of PulseView is also present in Logic 2 (or I could not find out how to do):

I have two signals (MOSI and SCK). I wish to decode these as SPI. All great. However, I have some “garbage” at the beginning of the SCK line, and it ruins the SPI decoder.

I know I can delete everything before the cursor, which partially solves my problem. But what can I do if I don’t want to delete these data. Just I wish the SPI decoder to start “later” (let’s say from my marker)?

Thank you"

Tim

(#83247)
"Will there be a function to parse data from my calibrated position in the future? After I upgraded the software from version 1.2.29 to version 2.4.10, I found that this function is not available in the new version. In this case, when the waveform I captured is wrong, all the subsequent data will be wrong, so I have to capture the data again. If I have this function, I can parse the data from the wrong place, so that I don't have to re-crawl the data."

Tim

(#81919)
"Still missing an option to start a decoder at a specific marker. This is especially important when working with SPI-like data that does not operate in multiples of 8."

Tim

(#80838)
"The protocol parsing of SPI data in our custom plugin apparently has a bug and decodes some packets wrong. But sometimes, the fact that a chunk of bytes is decoded wrong snowballs and causes more data that follows it to be decoded incorrectly. That is why I was requesting this feature – so I can remove that offending data, without which the rest of the parsing should go well. This is only a workaround, but sometimes, such workarounds are needed especially if it’s an important log or if we are time constrained (which we almost always are). If there’s a way I can ask the SPI parsing or the plugin parsing to restart at a given marker (with no protocol processing before that marker), that may do the trick also.
---
Yes, that would be very helpful. That way, in a large log, we can restrict the protocol decoding to only relevant parts."

Mathieu

I think this feature is a must have where you can get multiple serial protocols running one after the other on the same circuits. My example would be with RFID transponders, where the MCU configures a basestation using SPI or LIN, then communicates across the basestation with BPLM encoding, and the transponder responds back with manchester encoding. all on the same circuit!

Tim

See another request here:
discuss.saleae.com/t/reset-starting-sample-for-async-serial/707

Steve

I agree. In my example where I used this feature, there was a glitch that caused the analyzer to start too soon. I wouldn't want to trim off that glitch because it was meaningful, too, but to see the decode I needed to re-run the analysis starting after the glitch.