Products > Test Equipment

Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

<< < (177/206) > >>

Performa01:

--- Quote from: Slartibartfast on December 04, 2023, 09:54:34 pm ---Be that as it may, however, "copy the settings to the trigger" does not make too much sense, IMHO. Even if I couldn't see the edge I want to trigger on beforehand, I'd still know the two digital logic levels, and can choose the trigger level from that. And then of course you're right saying that some glitches may necessitate tweaking the trigger level a bit. But this is also why I prefer to choose levels independently: In order to find some rogue glitches I'd need exactly such a threshold as I avoided to use for the decoder, to avoid upsetting it by the same glitches.

--- End quote ---
We are talking about serial triggers here, not a simple edge trigger. Of course you can use edge/pulse/timeout triggers, maybe in conjunction with holdoff, to get a stable capture of the serial data stream, but then you get all packets, even though you might only be interested in very specific ones, e.g. with certain addresses and/or certain characters in the payload.

For this to work, the serial triggers need to be able to decode the data stream, hence also need the correct settings. There is no “trigger level” for serial triggers, just signal assignments to the input channels, separate threshold levels for each channel, polarity, idle level, baud rate, command bit inclusion and the like. On the other hand, if you turn the trigger level knob, nothing will happen at all.

There can be different concepts. Siglent uses the most obvious one: triggers and decoders are completely independent modules. Triggers are implemented in hardware, because of the speed requirements, whereas decoding is done in software because of the flexibility. Of course, we could just have one single setting that is used by both modules, but where to place them?

Some people don’t care for serial trigger and just want to see every single packet – and use some edge/pulse/timeout trigger for that. They want to find the protocol settings in the serial decoder of course.
Some other people don’t need to decode anything, they just want to trigger on a specific serial packet and watch the related signals at that point in time. These folks only need to set up the trigger and of course expect to be able to do this in the trigger settings. Btw, there have been times (long ago) where serial triggers have been free, whereas serial decoders were paid options. At about 2017, Siglent were the first to provide basic triggers and decoders (UART, SPI, I2C, CAN, LIN) for free…

Back to topic: We could have different places for accessing the serial settings and still use a common data set for them. Then any change in the decoder would immediately affect the trigger as well – and vice versa. Most of the time, this would be the wanted behavior, But since trigger and decoders can be used independently, even on different serial buses at the same time, we don’t want to limit the user (user shall be master and not slave of the machine) and consequently allow individual settings for the individual modules.

With the possibility to copy the decoder settings into the trigger as well as the trigger settings into the decoder just with a single touch, we have the best of both worlds.


--- Quote from: Slartibartfast on December 04, 2023, 09:54:34 pm ---Apart from trying out I have never used that copying function. In addition to making limited sense (as I wrote above), I'm also far faster just rotating the trigger level knob versus clicking through menus to reach that copying function.

--- End quote ---
I hope that you’ve realized by now that there is no “trigger level” for serial triggers and the trigger level knob has no function at all. But you can save the hassle to retype a bunch of settings. Imagine SPI as a popular example:

4 different Signals -> 4 different channels, 4 threshold levels, clock phase and CS type -> 10 settings.

That’s much more hassle than just remembering a single threshold level and then turning a knob.



--- Quote from: Slartibartfast on December 04, 2023, 09:54:34 pm ---
--- Quote ---There is no internal/external switch – don’t know where this error in the manual comes from, since to the best of my knowledge it has never worked any different to what it does now.

--- End quote ---

I beg to differ. I have a fairly clear memory of having played with that menu entry. Maybe you never used it because you found out early what you're describing here?

--- End quote ---
Yes, I found it out immediately – and quite honestly, this is something I set once in my lifetime and then forget about it – as long as I don’t need to do a demonstration like in my last post, but this has been the first time in my long career as Siglent DSO power user….

Slartibartfast:
Seems I have come across another bug. It may be related to decoding again, at least up to now I only observed it in that context.

I noticed some peculiar behaviour, as shown in screenshot A (A to D attached in that sequence). I had been listening on some UART line, where the traffic is under my control. At 115200-8N1, I noticed some decoded data being shown, where its associated voltage trace shows no activity (right half of the screenshot). Strange?

Now, I turned the timebase knob one tick to the right (shot B). The trigger LED flickers for a moment, as if the scope retriggers, however this is not the case. There was no activity on the bus while I turned the knob, which I also confirmed using a second scope attached at the same time. Now, I turned the timebase knob one tick back (i.e. to the left), restoring the previous timebase setting (shot C). But - what's that: Suddenly there is activity on the trace where previously was none. The puzzle deepens.

Looking carefully, comparing the left half of shot A and C, you'll notice it's a completely different trace! So I manually decoded the trace shown in shot A, and knowing what truely was on the bus, I immediately knew what was happening: I got the data that was sent before, caught with the previous trigger, which should be obsolete at the time when shot A was taken.

Repeating the exercise with 'single' trigger (shot D), I looked at the previous data packet, and got exactly what was shown in the trace in shot A, but is very different from what the decoder track shows there.

So it's an update problem. There are two data packets, 15ms apart. The scope triggers on the first, shows the trace, possibly starts decoding, then triggers again, decodes the new data and shows it in the decode track, but fails to update the voltage trace. Operating the timebase does not re-trigger (as remarked before; the trigger LED should not flicker, which is a minor bug), but it causes both the decode trace and the voltage trace to update, so after that they are consistent with each other.

The failure to update the trace is a serious bug, and possibly a hard-to-find one for the firmware engineers, unfortunately, as it may be a race condition between concurrent threads.

Cheers  Peter

PS.: Like before, this was with firmware version 1.5.2r3, which I believe to be the most recent one.

PPS.: In case it isn't obvious from what I wrote: The failure to update as described is absolutely repeatable, however I have not established how sensitive it is to which circumstances.

Slartibartfast:

--- Quote from: Performa01 on December 05, 2023, 10:56:54 am ---Some people don’t care for serial trigger and just want to see every single packet – and use some edge/pulse/timeout trigger for that. They want to find the protocol settings in the serial decoder of course.
--- End quote ---

Yep, that's me, up to now.

I have not needed protocol triggers up to now. I may need them in the future of course, and from what you describe it seems I have underestimated the usefulness of the 'copy' function. I should like to read up on it.


--- Quote ---
--- Quote from: Slartibartfast on December 04, 2023, 09:54:34 pm ---Apart from trying out I have never used that copying function. In addition to making limited sense (as I wrote above), I'm also far faster just rotating the trigger level knob versus clicking through menus to reach that copying function.

--- End quote ---
I hope that you’ve realized by now that there is no “trigger level” for serial triggers and the trigger level knob has no function at all.

--- End quote ---

No need to realise now, I've known for the last, like, 20 years, that protocol triggers don't have a trigger level. It's really that obvious.  :horse:


--- Quote ---
--- Quote from: Slartibartfast on December 04, 2023, 09:54:34 pm ---
--- Quote ---There is no internal/external switch – don’t know where this error in the manual comes from, since to the best of my knowledge it has never worked any different to what it does now.

--- End quote ---

I beg to differ. I have a fairly clear memory of having played with that menu entry. Maybe you never used it because you found out early what you're describing here?

--- End quote ---
Yes, I found it out immediately – and quite honestly, this is something I set once in my lifetime and then forget about it.

--- End quote ---

Then I wish you good luck. I also thought, when I set the screenshot-storage directory roughly a year ago, I might never need to touch that setting again. Well, the update to 1.52r3 reset that directory to factory setting. Seems the firmware engineers do not ask you whether you'd like to never touch a certain setting again.

Of course you can still refuse to never set it again.

Cheers  Peter

PS.: I do not know if you ever worked in an environment where collegues use the same scopes, and change settings to your disliking? Do you "set once in my lifetime and then forget about it" there too?

cte:
I think I found a bug in sequence mode, when used in conjunction with specific zoom levels and/or timebase.

I have an SDS2104X Plus with Firmware Version 1.5.2R3, CPLD Version 05 and Hardware Version 05-05

Steps to reproduce:

* Apply signal on Channel 1 + 2. I had both channels at 5V/div with 10:1 divider (probably not relevant for bug reproduction).
* Set timebase to 500µs/div.
* Turn on sequence mode.
* Now turn on zoom mode and zoom to 20µs/div.The signals are not drawn to the screen anymore, instead it's endlessly showing "Processing..." in the lower right of the screen. User interface responds sluggish, but you can recover by changing the zoom level away from 20µs/div.


Demonstration video:


Maybe someone can try to reproduce this?

3.141529:
A feature request:

What I want to do is measure how long a signal remains high or low over a set period. I have a circuit with a busy signal and I'd like to know the amount of time it spends busy over a period of time. Currently I can work it out manually in one of two ways using measurements:


* I can measure the Area@DC of the busy signal and divide by the amplitude
* I can measure the +Width of the busy signal, select Statistics and multiply the mean by the count
Both of which are somewhat tedious. It would be nice if simple measurements were added that would give the cumulative + or -Width values.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod