What additional information this slow fade out give to user? Or do you mean it is cosmetically more "nice".
Fast acquisition and image daata processing is bit time critical process. I do not accept if example persistence on slows wfm/s speed. If we need keep track for every acquisition age it is bit hard. If there is example 100000 wfm/s there is roughly 4000 acquisitions in each TFT image what are renewed every 40ms with new set of 4000 acquisitions. This is still quite easy case but when we work with random undefined signals scope can not design just for one case, sontinuous repetitive signal. Before this fade out gradattion is good we need time stamp every single acquisition and after time start decay intensity individually for every acquisition. If we now want 5 second persistence and after then say example 5s fade out. Total time for every acquisition is 10s and in "worst" case there is now 1000000 acquisition in ageing queye.
More important, though, is the "FIFO" behavior you described earlier.
Right now, the scope behaves like it has infinite persistence, and someone pushed "Clear Persistence" every 5 seconds.
Hmm... this almost sounds like something one would do with a GPU. Maybe in the SDS3000?
Another bug to report: serial protocol decode (well, at least UART decode) seems to stop working when digital channels are enabled. Note, this happens even when the protocol decode input is set to one of the analog channels; simply having the digital channels on screen messes up the protocol decoder.
The protocol decoder seems to work only when the beginning of the serial frame is visible on screen, even when the Zoom feature is used (ie, the acquisition hardware has captured enough samples to perform the decode, but only some are shown on screen).
In the second image, I scrolled the zoom area so that the start bit of the first character is off to the left of the screen. The decoded data is blank, even though there are several valid characters displayed.
rf-loop had earlier reported that the scope must trigger on the data for the index shown in list mode to be accurate, but he explicitly mentioned that the decode still works in this condition (on an SDS1000X). This lets you capture a bunch of data, then zoom in and scroll around to read the contents. It seems to not be the case for an SDS2000X, as soon as you scroll so that the beginning of the data is off-screen, decode disappears.
The difference between rf-loops and yours are the trigger settings vs the edge of the first bit. Is it different with a falling edge trigger?
@tautech: Thank you for reporting to Siglent. Hopefully they'll get the issue solved. In the meantime, the scope seems to do most basic stuff just fine. I'll keep exploring the fancier features and let you know if I came across something weird.
If I may, a 'minor annoyance' is that the scope re-arms itself too quickly in auto mode. During these tests with the serial decoder, I had an arduino output a burst of characters once a second. With the trigger set to auto, I would often not see anything on screen, even though the scope indicated it was triggered. I had to switch to Normal mode before I could get the display to show me something. I would have preferred if Auto trigger mode held data on screen for a little longer, before re-arming the trigger.
After posting I noticed I was triggering on rising edge
The difference between rf-loops and yours are the trigger settings vs the edge of the first bit. Is it different with a falling edge trigger?After posting I noticed I was triggering on rising edge. Behavior remains the same with falling edge triggering as well - as soon as I zoom and pan the left edge of the data off screen, the decoded output changes to a flat blue line (which means line idle, I think). One more difference is that the baud rate I used on my tests is 115200 baud. I re-tested at 9600 baud with the same results.
@rf-loop: Understood. It seems like my 2204X does not behave the same way.
@tautech: Thank you for reporting to Siglent. Hopefully they'll get the issue solved. In the meantime, the scope seems to do most basic stuff just fine. I'll keep exploring the fancier features and let you know if I came across something weird.
If I may, a 'minor annoyance' is that the scope re-arms itself too quickly in auto mode. During these tests with the serial decoder, I had an arduino output a burst of characters once a second. With the trigger set to auto, I would often not see anything on screen, even though the scope indicated it was triggered. I had to switch to Normal mode before I could get the display to show me something. I would have preferred if Auto trigger mode held data on screen for a little longer, before re-arming the trigger.
As with any perceived problem it's great if you can post some supporting screenshots that we can point Tech support to.
It's so much easier then to duplicate your findings as there's much info in a screenshot that then doesn't need mention.
QuoteAfter posting I noticed I was triggering on rising edge
Scope default holdoff need be short, other way we read thousends of negative comments how slow this scope reeact when touch probe to some potential before anything see on the screen. But user can adjust it when really need. (example if you try look AM modulated signal so that you want trig to modualtion freq, this is fast and practical way to adjust holdoff so that get stabile trig.
Have you tried set trigger mode BUS and then set all trig paramaters for UART?
This is what I expected to see. I found that I had to set the waveform generator frequency as high as 8 Hz before auto and normal trigger modes showed the same thing on screen. This means that the re-arm time in auto trigger mode is something less than 0.125 seconds. I think this is too short - it ought to be at least a half second so that the waveforms shown on screen in auto trigger mode can actually be seen. After all, that's the whole point of auto trigger mode - to explore around without knowing what sort of signals to look for.
On many oscilloscopes the auto trigger re-arm time is very short so you can immediately see what is going on. Tektronix does things a little bit different though. When in auto trigger mode it will wait for half a second before going back to auto trigger mode after it has triggered on something in a signal.
This is what I expected to see. I found that I had to set the waveform generator frequency as high as 8 Hz before auto and normal trigger modes showed the same thing on screen. This means that the re-arm time in auto trigger mode is something less than 0.125 seconds. I think this is too short - it ought to be at least a half second so that the waveforms shown on screen in auto trigger mode can actually be seen. After all, that's the whole point of auto trigger mode - to explore around without knowing what sort of signals to look for.I think you can debate forever about this and not reach any concensus. On many oscilloscopes the auto trigger re-arm time is very short so you can immediately see what is going on. Tektronix does things a little bit different though. When in auto trigger mode it will wait for half a second before going back to auto trigger mode after it has triggered on something in a signal. This can be handy but it can also be a nuisance if you just want to check a level and get the noise from attaching the probe on screen instead. Another work around is a dedicated force-trigger button. This way you don't need to switch between auto/normal mode. You can just hit a button to get a trace on the screen when in normal trigger mode.