Siglent SDS2000X HD, missing Features and Bugs

[Martin72]

Hi,

Wanted:

Showing the parallel data in ASCII*:

https://www.eevblog.com/forum/testgear/new-scope-demoboard-from-batronix/msg5175123/#msg5175123

SDS2000Xplus do not have it - And neither does my HD...
I think this is a useful feature that might be easy to implement.

*)If that is enough to arrive at a directly readable result.

[Ulrich.G]

*)If that is enough to arrive at a directly readable result.

When the characters are inside the first 128 chars of the ASCII table, otherwise you might need the right charset for encoding it properly.

[blurpy]

*)If that is enough to arrive at a directly readable result.

When the characters are inside the first 128 chars of the ASCII table, otherwise you might need the right charset for encoding it properly.

Supporting different charsets would also be nice, but it's a good start to get the same ASCII decode for parallel as is already available for serial.

[Martin72]

A wanted nice to have:

https://www.eevblog.com/forum/testgear/siglent-sds3000x-hd-and-upgraded-sds1000x-hd/msg5187762/#msg5187762

I find this color coding of the logic channels(3rd pic) very successful, that would also be something for the 2000X HD.

[Martin72]

I think I've found a tiny bug...
The color selection of the traces, a fantastic feature not only in this price range, has a small bug.
If you change the saving of the image from normal to inverted, the color of the changed regular channel is "taken over", but the math channel is not, it gets its original color.
Please change, thank you!

[KungFuJosh]

Isn't that two bugs? Shouldn't it instead be two inverted colors?

[Martin72]

Hi,

Only the background or better everything on the screen except the traces should be inverted.
At least that's how I know it from Lecroy scopes.

[Martin72]

I had previously worked with the Bodeplot for another topic here.
What I still think is suboptimal is the obvious "encapsulation" of this function from the rest of the system.
I just wanted to make a change in the channel menu - I can't, everything that has nothing to do with the Bode function is deactivated.
You first have to get out of the function again (including this annoying "recalling"), then you can adjust and then call up the Bodeplot again.
This is quite inconvenient.
And the unit for the amplitude of the internal generator is still unchangeable (Vpp).

[hpw]

Only the background or better everything on the screen except the traces should be inverted.
At least that's how I know it from Lecroy scopes.

It is always an issue as for documentation or printing. For printing Monochrome should be the option. Otherwise 

[rf-loop]

I had previously worked with the Bodeplot for another topic here.
What I still think is suboptimal is the obvious "encapsulation" of this function from the rest of the system.

There is so many things...  it is like whole other system than oscilloscope..  BodePlot OR Oscilloscope  (even it still in background do timedomain acquistions).
But "recalling" back to oscilloscope mode takes long time... imho.. too long.

I just wanted to make a change in the channel menu - I can't, everything that has nothing to do with the Bode function is deactivated.
You first have to get out of the function again (including this annoying "recalling"), then you can adjust and then call up the Bodeplot again.

This improvement to BodePlot is asked many times over years.
Something like this:
BodePlot function On.
If [Channel Gain:Hold] AND BodePlot [Operation:Off] AND [Display:TimeDomain] (because for adjust there need see level for proper adjust).
There need enable input channels vertical adjustments without shutting off whole BodePlot. Also in this condition AWG need be free for manual frequency set for example find DUT peak... this need come even more clear if using FRA for example high Q resonators...
In all cases when [Channel Gain:Hold] there need keep care that signals top peaks do not clip but top peaks are near ADC full scale for get best dynamic range.
(sidenote: [Channel Gain:Hold] state is nice to use in some cases because it give more speed and many times only small disadvantage in dynamic range)

At the core of FRA's operation is a primary table (all other things (what you see) are secondary, based to this primary non visible table.

Naturally, IF [Channel Gain:Auto] then V/div is totally under FRA control, no need enable channels manual adjustments.


But then there's also the request that sometime in the future we can get an improved BodePlot in some other way.

Example:  Phase normalize function so that with current setup for test, use can first run phase cal specially if working higher frequencies
Also max 500 (or 750) steps is not enough... even when it still can be even when it can be up to 275 204 396 points/decade (119.9995MHz to 120MHz with 501pts )
One other thing what least I hope is rejected dynamic range fast scalar sweep (SNA) because this can be really fast. (there is really many cases we do not need phase)

(and many other smaller or bigger improvements and bugfixes)


 

[Ulrich.G]

Just noticed, that the remaining time for the temporary ARINC decoder licence, which came with the firmware update 1.2.2.5, is still at 30 days. So its never expiring? I doubt that Siglent made this intentionaly.

[2N3055]

Just noticed, that the remaining time for the temporary ARINC decoder licence, which came with the firmware update 1.2.2.5, is still at 30 days. So its never expiring? I doubt that Siglent made this intentionaly.

Do you use it?
Maybe it is not counting scope on time but hours of use of decoder.

[Ulrich.G]

Do you use it?
Maybe it is not counting scope on time but hours of use of decoder.

No, and most likely I never will. But your assumption was right - I switched it on for bus 1 - the licence counter decremented to 29.

Thank you.

[Grandchuck]

Hi.  What am I doing wrong?  Ch1 signal sin 2Khz 1Vpp, Ch2 signal sin 1 kHz 1Vpp.  Math: Ch1xCh2.

[CustomEngineerer]

From your screenshot it looks like you are doing Math: Ch1xCh1, not Ch1xCh2.

[KungFuJosh]

Yeah, math is setup wrong. You need to select the channels you want to use, but you left it default to CH1, CH1.

You should also check your inputs. Are you running high or low impedance? Both channels are set to 10X 1M. If you run 50Ω direct from the AWG, that's how it should be set.

I recreated your experiment on my SDS2504XP, with the SDG2122X:

[Grandchuck]

Yup!  Thanks guys!  Lovin this scope so far.

[Grandchuck]

I am back to report another minor issue.  Could be my thick skull again, but it seems that shut down and power up messes with settings that it should not.  Case in point ... SPI decoding ... the protocol settings (the thresholds) get changed and decoding no longer works after a restart.  Easy enough to fix once one realizes what is happening.

Then I tried saving the setup when decoding was working.  Powered the scope back up and loaded the saved file and the situation was a bit worse because two of the probe settings got changed from X10 to X1 and, once again, the thresholds were wrong.  Again, easy to fix once one realizes what is going on.

[Martin72]

Hi Grandchuck,

The Siglent scopes still have problems with probe sensing.
This causes, among other things, this effect with the incorrectly adjusted thresholds after the restart.
If you have other (non-auto-sense) probes, try it out, then you won't have this (and other) effect.

[Grandchuck]

Thanks Martin and thanks for alerting us about the Batronix board.  It helps to learn this fine instrument.

[tautech]

I am back to report another minor issue.  Could be my thick skull again, but it seems that shut down and power up messes with settings that it should not.  Case in point ... SPI decoding ... the protocol settings (the thresholds) get changed and decoding no longer works after a restart.  Easy enough to fix once one realizes what is happening.

Then I tried saving the setup when decoding was working.  Powered the scope back up and loaded the saved file and the situation was a bit worse because two of the probe settings got changed from X10 to X1 and, once again, the thresholds were wrong.  Again, easy to fix once one realizes what is going on.

Siglent know about this and have shared a bug ID for it on their forum.

[tautech]

Siglent know about this and have shared a bug ID for it on their forum.

Is that a public forum or just for dealers etc.? If it's the former -- where to find it?

Private beta tester forum. Membership by invite only and access only given to the products you are working on.
I can see lots but not all.

[Grandchuck]

I am seeing some trigger instabilities when decoding UART signals.  Screen captures:
  Expected: triggers on falling edge of C1.  This is what is expected.
  DecodeBut: late in the data frame.  The trigger is later than expected.
  JunkDecode: trigger is late.  The trigger is late and the decoding is junk.
  NoDecode: did not trigger in time?  No decoding.

The captures are at 9.6 kbit/s.  At 38.4 kbit/s, there seem to be fewer errors.

[tautech]

I am seeing some trigger instabilities when decoding UART signals.  Screen captures:
  Expected: triggers on falling edge of C1.  This is what is expected.
  DecodeBut: late in the data frame.  The trigger is later than expected.
  JunkDecode: trigger is late.  The trigger is late and the decoding is junk.
  NoDecode: did not trigger in time?  No decoding.

The captures are at 9.6 kbit/s.  At 38.4 kbit/s, there seem to be fewer errors.

Yep, clear retriggering within packets.
Remedy = add Trigger Holdoff of a little larger value than the largest packet width.

[Performa01]

I am seeing some trigger instabilities when decoding UART signals.  Screen captures:
  Expected: triggers on falling edge of C1.  This is what is expected.

Falling edge trigger is a bit ambigous with so many falling edges, don't you think?

Modern oscilloscopes have a bunch of powerful triggers for a reason. In your case use a postiive pulse trigger with time the minimum pulse width little greater than one character duration, e.g. about >1 ms at 9k6 should reliably trigger at the start of each packet, regardless of its length.