I’ve tried to replicate the issues reported by TheDefpom and here are my findings:
Bug: Bus Decoding doesn’t follow timebase changes while trigger state is “Ready”
Changing the timebase while the scope is not stopped and the trigger is ‘Ready’ does indeed redraw the traces, but not the (parallel) bus decoding. We do not recognize this on a continuously triggered signal, as the decoding will fit the timebase on the next valid trigger. It also works as it should in Stop mode. A minor bug in my book, but a bug nonetheless.
Bug: Channel height setting is not preserved in Zoom mode
When entering Zoom mode, the digital Channel Height is always automatically set to “Middle”, no matter what it has been set before. We can change Channel Height back to “Low” while in Zoom mode and it stays that way after returning to normal mode.
However, I did not observe any mismatch between legend and traces after altering the Channel Height on an SDS2kX series scope, so this phenomenon must be specific to the SDS2k firmware.
As far as the X-series is concerned, this is again not a show-stopper, but for that matter:
Bug: Channel Height menu items
The Channel Height Menu offers three settings: Low, Middle High.
First of all, I would change “Middle” to “Medium”, since we’re talking about a height and not a position here.
Secondly, I think the assignment is wrong. If we select “Low”, we get high traces, and we get tiny ones if we switch to “High”. That’s counter-intuitive.
Flaw: Roll Mode with digital channels
Now for the time bases slower than 20ms/div. This scope has the habit to automatically switch to roll mode for time bases of 50ms/div or slower. In some cases this is handy, in most others it is rather annoying. Roll mode is not a triggered operation, so it’s all the more funny that the scope changes trigger to analog channel 1 and starts showing the yellow trigger level indicator when it enters roll mode of all things.
At the same time, digital channels are turned off. This should be okay, as probably not many of us urgently want to watch digital signals in slow untriggered roll mode anyway. The cure is simple: just switch the scope back to y-t mode and the digital channels as well as the trigger will be back to how it was before. The scope now stays in y-t mode until next time we cross the 20-50ms/div border, which is indeed a bit annoying. Since roll mode doesn’t work with digital channels anyway, it should be permanently disabled as long as digital channels are active.
As a side note, with firmware P38.7 roll mode only works as described in the manual (and as we are used to it) when in auto trigger mode. In normal or single trigger mode, roll mode is actually triggered. This might be useful for some rare applications and that’s why I’m willing to look at it as a feature rather than a bug, but this behavior has to be documented in the user manual.
Bug: Exiting Roll mode switches trigger to Auto
This is clearly a bug and I’ve reported this already.
? Disabling individual digital channels
I could not replicate that on an X-series scope. So maybe once again an SDS2k specific issue?
? Glitches
I cannot replicate any of the glitch issues. When looking at the screenshots, e.g. in Reply #223, I don’t see anything unexpected. A fundamental rule for getting a stable picture on a scope is finding a stable trigger condition that is unique within one acquisition. However, this data pattern has no such unambiguous trigger condition. Triggering on D0 will give the worst possible result, as the trigger condition is met several dozen times within the signal packet. Triggering on D2 should already give significantly better results and the best approach would be a pattern trigger on D0 AND D2 HIGH, but even this is not unique, as it appears again right after the D0 burst. So depending on the timebase, this might still lead to unstable triggering and consequently various superimposed traces from different acquisitions.
So either find another signal for the trigger, that clearly indicates the start of the signal packet, or use single trigger mode in the first place, even when the signal packet is repetitive.
I could not find a situation where the memory size was changed by the scope itself, other than that it’s currently not capable to utilize the full memory depth with digital channels, so the maximum is limited to 14/28Mpts (normal/interleaved) in this situation.
Since it all comes down to a proper trigger condition, I also weren’t able to replicate glitches at certain timebase and/or memory depth settings. I don’t think this should come as an surprise, as the actual memory depth used for a single acquisition at e.g. 100µs/div on digital channels is just 700kPts. So with this timebase it does not matter what memory depth is configured, as long as it’s more than 700k. With digital channels enabled, the scope doesn’t support history, so in contrast to using analog channels only, we have here the rather unique situation where the scope actually uses less memory than what is set in the Acquire menu.
My only explanation would be that despite all that, the configured memory depth still affects the timing somehow, maybe the trigger re-arm time. Since the trigger rate and phase relative to the input signal packets will have a huge impact on trigger stability with ambiguous trigger conditions, this could explain why some combinations appear more stable than others.
Home
Help
Search
Login
Register
