Those sorts of differences were clearly expanded upon already:
There are scopes out there with no hardware serial trigger, but do have software serial decode, or the serial trigger only frames the packet and does not qualify/inspect the contents. Yet this thread is a mess of people not making that key separation which answers part of the question of the OP.
So why are you making so much effort to try and say they are all the same? Scopes without hardware serial triggers cant perform many debugging options that hardware triggers expose, it is a key separator that you seem to be trying to discount/hide/dismiss with faulty reasoning (such as bringing up the best case blind time when the OP is asking about protocol decode).
It is now obvious to me that it is not MY English that is the problem...
I said and done none of the things you say I did. Your conclusions are your hallucinations of what my sentences mean.
Read again and again until you understand.
A scope without hardware protocol triggers is exactly what is framed in the above quote. That would be things like the Picoscope and older Tektronix platforms (dunno about the current tek models).
If a scope such as the Picoscope has the decodes run in software, then it is the rate of that which produces the blind time for serial analysis. Serial decode was the OPs question.
This (as noted above by tggzzz) is almost identical to the many threads where people would ask about realtime update rate, then have particular members consistently misleadingly talk at length about blind time in segmented mode and say how its all the same thing. That the acquisitions can enter memory but none of that information reaches the screen/user/result, makes them part of the dead time for that analysis. You want to talk about dead time? then discuss it accurately and honestly rather than pushing your "side" as somehow universal and superior.
You keep repeating same thing WHICH is the reason for repetition..
And miss the point.
Let's define terms so you can finally see that we are both saying same thing in different way.
First, what is "real time serial decode (analysis)?
Is that when you are looking at the scope screen waiting for scope to show messages as they run over comm bus we are decoding?
You can have scenario where you have thousands of packets per second and a really fast scope that will render all of those (all 1000) to the screen in real time, keeping each on screen for 1 ms... That would be obviously useless b'cause I can't read that fast.
I might need to capture all of them because I wan't to reverse engineer what is going on in detail. This will need
one long capture with all of them, stop and then I have few hours of work to make sense of all that data. This is not real time.
Or I'm interested only in messages sent by only one of sensors... In which case I need the scope to only TRIGGER on certain messages (set by trigger condition) and ignore all the rest. And if my sensor of interest sends data only once a second (or when I press key or something) then I leave scope running, and wait for it to catch a message and show it to the screen. This is
interactive work, this is real time, but only if message rate is slow enough for a slow human operator.
3rd scenario is same as 2nd but although we are capturing only one type of data packet, there are still 10-20 a second... We are not interested in anything else, but poor human is too slow.. In this case we
set trigger and capture some to segments. And again look at the data in offline mode.
Scenario 1 is perfect for Picoscopes. And many of Saelae type USB analyisers.
It is not good for short memory scopes.
Scenario 2 is perfect for fast hardware trigger/decode scopes. But most modern hardware trigger/ software decode scopes will be fast enough to keep the pace with human.. If it is too fast for human it will be too fast for them.
Scenario 3 is good for both hardware trig/decode and hardware trig/ soft decode scopes, because triggers run in hardware in both but segmented capture postpones all processing until predefined number of segments (packets) is captured, negating any blind time difference in decoding. On soft decode scope you might have a short pause after capture is done for scope to decode while hardware one will show data much faster. But neither will miss any packets..
There is also marginal scenario between 2 and 3 where some people will be able to read messages faster or slower, and where some will prefer full hardware trigger/decode scope because they will be able to show things faster..