SDS2202X-E FPGA bug or broken?

[RoV]

Yesterday, while I was trying to use the scope to tune an Efratom LPRO-100 rubidium oscillator using a GPS, I have found a weird behavior. I had the scope in normal sync mode, rising front on the channel getting the slow PPS signal (1 Hz, 5 us duration); the other channel was connected to the 10 MHz output of the oscillator. I saw false syncs, signals with discontinuous phases and other weird things that let me think the scope was broken. Then I realized that it happened only above a certain horizontal speed setting: at low speeds like 500 us/div or slower (using then zoom to see the detail I needed) all was working correctly, letting me suppose it may be a firmware or FPGA problem. No problem at all in "single" mode, only in "normal".
I have tried applying trigger holdoff, even close to 1 s, without any improvement.
I have the latest downloadable firmware 1.1.19R5 with FPGA 2019-08-12 (however, I can't find any FPGA update), hardware version 00-01.

I could replicate the problem today using my Siglent SDG2042X, and I discovered that it happens even in single channel mode. I have posted a video here:
     https://youtu.be/-re2NW7mH-k
where you can see the result of applying short pulses (1,2 or 5 us duration, 100 ns rise time) with 1 s PRF and normal sync mode, rising front, at half level. In this case all is ok for 200 us/div or less, while for 100 us/div or more it starts acquiring out of sync or showing a flat line. If I change the pulse duration, it even mixes the old and new duration, so the impression is that there is a bad pointer in the acquisition memory. If I increase the PRF above 10 Hz, the problem seems to disappear.
I'd like to know if someone else can see the same behavior, in which case it is almost surely an FPGA bug, or if my unit is faulty and should be returned (still under warranty period).
I have tried to turn it off and on, to start from default, to invoke autocal, but nothing...
The unit isn't hacked. I have purchased the MSO option, but the digital probe wasn't connected to the scope.
Maybe I'm wrong in some way... I'd appreciate your hints.

Thank you very much,
Roberto
RoV IW3IPD

[tautech]

Interesting.
What is the result when Holdoff is increased to say 0.5s ?

I can get one out later and check for the same behavior.

[RoV]

What is the result when Holdoff is increased to say 0.5s ?

No change at all, even with 0.95 s holdoff 

[tautech]

10 Hz is the BW limit where an Edge trigger will reliably catch a pulse regardless if either Normal or Peak Detect acquisition has been selected.
For LF pulses a Pulse trigger from the Trigger menu is required.

Actually, just Normal triggering will work fine at LF.

[RoV]

10 Hz is the BW limit where an Edge trigger will reliably catch a pulse regardless if either Normal or Peak Detect acquisition has been selected.
For LF pulses a Pulse trigger from the Trigger menu is required.

I have tried pulse trigger, but the result is exactly the same. It shouldn't be BW related, because the pulse risetime was ~100 ns, only the repetition rate was slow.
But did you manage to replicate the behavior?

[tautech]

10 Hz is the BW limit where an Edge trigger will reliably catch a pulse regardless if either Normal or Peak Detect acquisition has been selected.
For LF pulses a Pulse trigger from the Trigger menu is required.

I have tried pulse trigger, but the result is exactly the same. It shouldn't be BW related, because the pulse risetime was ~100 ns, only the repetition rate was slow.
But did you manage to replicate the behavior?

Yes exactly the same with SDS1104X-E......same UI and features. Signal source SDG1032X.
SDS1104X-E was on the bench and SDS2202X-E is NIB but I can get it out if needs be.

Normal triggering was the most reliable and it keeps the pulse on the display with only the Ready/Trig indicator changing each second. As these DSO's don't have a trigger LED the Ready/Trig indicator is all you have to see that it's all working correctly in Normal trigger mode.

Ran it for some hours with infinite persistence engaged and statistics showed a count of 15k when I turned it off after dinner.

[RoV]

But did you manage to replicate the behavior?

Yes exactly the same with SDS1104X-E......same UI and features. Signal source SDG1032X.
...
Normal triggering was the most reliable and it keeps the pulse on the display ...

Sorry, but I can't understand from your answer if you obtained my same _bad_ result or if it worked successfully in your case.
If it is a firmware bug, I would find very unlikely that it can be found also on a different scope using a different firmware.

Thank you for your support,
RoV

[RoV]

Interesting news...
I have tried several options and discovered that the problem disappears, even at fast horizontal settings, if I set "Acq Mode" to "slow" (Acquire button, second page). This function is not even mentioned in the user manual... the context help in the instrument says you can disable display hardware acceleration with "slow", in contrast with the standard "fast".
Obviously I'm not happy to leave the instrument in slow mode, but at least I have a solution.

I am now much more convinced that it is likely a firmware bug, but I would be happy to hear from other 2202X-E owners.

RoV

[nctnico]

Interesting news...
I have tried several options and discovered that the problem disappears, even at fast horizontal settings, if I set "Acq Mode" to "slow" (Acquire button, second page). This function is not even mentioned in the user manual... the context help in the instrument says you can disable display hardware acceleration with "slow", in contrast with the standard "fast".
Obviously I'm not happy to leave the instrument in slow mode, but at least I have a solution.

This is an interesting effect. Likely there is a bug in how the history buffering is handled. What would be a good test is to feed a pulse which becomes wider each time (you can probably use manual trigger on the function generator) and see if you actually get the most recent pulse on screen or a  random record from the history buffer.

[rf-loop]

Yesterday, while I was trying to use the scope to tune an Efratom LPRO-100 rubidium oscillator using a GPS, I have found a weird behavior. I had the scope in normal sync mode, rising front on the channel getting the slow PPS signal (1 Hz, 5 us duration); the other channel was connected to the 10 MHz output of the oscillator. I saw false syncs, signals with discontinuous phases and other weird things that let me think the scope was broken. Then I realized that it happened only above a certain horizontal speed setting: at low speeds like 500 us/div or slower (using then zoom to see the detail I needed) all was working correctly, letting me suppose it may be a firmware or FPGA problem. No problem at all in "single" mode, only in "normal".
I have tried applying trigger holdoff, even close to 1 s, without any improvement.
I have the latest downloadable firmware 1.1.19R5 with FPGA 2019-08-12 (however, I can't find any FPGA update), hardware version 00-01.

I could replicate the problem today using my Siglent SDG2042X, and I discovered that it happens even in single channel mode. I have posted a video here:
     https://youtu.be/-re2NW7mH-k
where you can see the result of applying short pulses (1,2 or 5 us duration, 100 ns rise time) with 1 s PRF and normal sync mode, rising front, at half level. In this case all is ok for 200 us/div or less, while for 100 us/div or more it starts acquiring out of sync or showing a flat line. If I change the pulse duration, it even mixes the old and new duration, so the impression is that there is a bad pointer in the acquisition memory. If I increase the PRF above 10 Hz, the problem seems to disappear.
I'd like to know if someone else can see the same behavior, in which case it is almost surely an FPGA bug, or if my unit is faulty and should be returned (still under warranty period).
I have tried to turn it off and on, to start from default, to invoke autocal, but nothing...
The unit isn't hacked. I have purchased the MSO option, but the digital probe wasn't connected to the scope.
Maybe I'm wrong in some way... I'd appreciate your hints.

Thank you very much,
Roberto
RoV IW3IPD

When I look your youtube first 15 seconds tell there is problem IF and only IF your trigger is set for
"Normal". If it is normal no need go further. In this point we know it do not work as can expect.
(later in video exist other mystery but lets first jump over it)

As can see in video,  it triger also without pulse at all... just like in Auto trigger mode. But @RoV  tell it is using "normal sync" and I think sync mean here trigger. (normally in world of oscilloscopes we do not talk sync, we talk trigger)

If it is in Trigger Normal mode. It must not trig without signal meet user defined trig condition, here rising edge and level as it is, 1.92V.  Signal is 5V so it is ok.

You have there history in this scope. Why you do not look history and look there what happen. Just when it trig to pulse and immediately if you see it trig straight line press stop or history button and search history what just happen. Open also table for look time intervals in history. Then search these every single acquisition time stamps so you can see one capture where is this pulse and after then some time and it start capture just like "auto trig" after some waiting time... what you can also detect in history.

If it works normally and trigger mode is "Normal" you must see only this pulse and not at all this straight line.

So, for make sure all is as default, do  full factory default.
After then set trigger rising edge. Level 2.5V and trigger mode "Normal"
scope for Set 2V/Div. Set time scale for 1us/div.
Take 1s period  1us wide pulses, level 0 - 5V using coaxial cable from your SDG to scope input.

If all you see just pulse alone and it updates 1s period (you can detect it with eyes if you look noise pixels) all is ok. Also if you after 20 second stop it and look history you find there all 20 separate pulses and time  stamp table tell period is 1s and there is just 20 traces in history and nothing else.  If you see pulse  and also you straight 0V level line over display. Trigger do not work right way, due to some reason. In this case you can see history have pulse and then perhaps lot of captures what are just these straight libnes, every capture separately.  History feature is good tool when user is familiar with it.

When you run scope in fast mode these are overlaid in screen but in slow mode there can be only one acquisition (capture) in one TFT update. So in this mode it works as conventional ancient digital storage scope, DSO.  Slow mode is DSO mode and fast mode is DPO mode what Siglent call as SPO mode.

[nctnico]

@rf-loop: that still doesn't explain why pulses with the wrong width are appearing randomly.

Edit: I watched the video from the OP again and it definitely is a bug. After he changes the pulse width to 2us the 1us pulses are still popping up randomly. This is not acceptable behaviour for an oscilloscope.

[rf-loop]

@rf-loop: that still doesn't explain why pulses with the wrong width are appearing randomly.

Edit: I watched the video from the OP again and it definitely is a bug. After he changes the pulse width to 2us the 1us pulses are still popping up randomly. This is not acceptable behaviour for an oscilloscope.

Better practice is divide messy problem to different parts. I was handling this first part, as I told. First need be sure how settings are and test with perfectly known setup and other things and find confirmation it trig in Normal trig mode without visible pulse, as can see it happen.

Whole next thing is then this mystery with pulse width. Btw, do you absolutely know it is made by scope. No, you do not know. Also I do not know, before more facts and less believes and religion. In problem solving everything need suspect including also negation tests and all other normal practices, including also thinking path cutting and rerouting - if you have any real hardcore experience about common problem solving.
Also it is good practice to read before comment.

In this point we know it do not work as can expect.
(later in video exist other mystery but lets first jump over it)

This was just for avoid mixing and messing things together but go in good order step after step....  Looks like you think there was no reason for this what I wrote.

 

[nctnico]

@rf-loop: that still doesn't explain why pulses with the wrong width are appearing randomly.

Edit: I watched the video from the OP again and it definitely is a bug. After he changes the pulse width to 2us the 1us pulses are still popping up randomly. This is not acceptable behaviour for an oscilloscope.

Better practice is divide messy problem to different parts. I was handling this first part, as I told. First need be sure how settings are and test with perfectly known setup and other things and find confirmation it trig in Normal trig mode without visible pulse, as can see it happen.

Watch the video again and you'll see. In the first part (where the OP changes the pulse to 2us) there is no reason for the oscilloscope to start mixing 1us and 2us pulses. The oscilloscope is probably in auto trigger mode so it shows a flat line and a pulse in an alternating fashion but again: where does the 1us pulse comes from if there are only 2us pulses at the input?

I assume you have a Siglent scope and a pulse generator so try to re-create this setup yourself with the test I described earlier (using incrementally wider pulses so each measurement can be identified).

[RoV]

Watch the video again and you'll see. In the first part (where the OP changes the pulse to 2us) there is no reason for the oscilloscope to start mixing 1us and 2us pulses. The oscilloscope is probably in auto trigger mode so it shows a flat line and a pulse in an alternating fashion but again: where does the 1us pulse comes from if there are only 2us pulses at the input?

No no, it was in normal trigger mode! Trigger arrived at 1 s pace, as the input pulses: when a flat line is displayed, it's because the scope is showing a wrong memory portion, I think. In fact, with an x-axis setting a bit slower, the pulse tends to appear in the wrong place, instead of giving a flat line.
As I told, all of this disappears above 200 us/div, or if I put the scope in slow mode.

I have also discovered that if the scope is in dual trace mode, with chA with the pulse triggered as usual and chB e.g. with a 10 MHz sinusoid, if I turn off chB, chA shows for a few pulses a mess of mix of previous chA and chB contents, similarly to what happens for the same channel when I change the pulse length.

I suppose it's a bug that will be fixed with a future update and not a defect of my scope 

[rf-loop]

@rf-loop: that still doesn't explain why pulses with the wrong width are appearing randomly.

Edit: I watched the video from the OP again and it definitely is a bug. After he changes the pulse width to 2us the 1us pulses are still popping up randomly. This is not acceptable behaviour for an oscilloscope.

Better practice is divide messy problem to different parts. I was handling this first part, as I told. First need be sure how settings are and test with perfectly known setup and other things and find confirmation it trig in Normal trig mode without visible pulse, as can see it happen.

Watch the video again and you'll see. In the first part (where the OP changes the pulse to 2us) there is no reason for the oscilloscope to start mixing 1us and 2us pulses. The oscilloscope is probably in auto trigger mode so it shows a flat line and a pulse in an alternating fashion but again: where does the 1us pulse comes from if there are only 2us pulses at the input?

I assume you have a Siglent scope and a pulse generator so try to re-create this setup yourself with the test I described earlier (using incrementally wider pulses so each measurement can be identified).

Read OP first message. Carafully. This is why I ask he test again with SURE trigger Normal mode and overall in known state.
This need eliminate first.

Of course I know other part of video. This is not now question. I ask from OP not from you but... troll is troll. And as I said, very weird  behavior is there in rest part of video... but now FIRST this trigger thing. Do it need bend using iron wire.
But first need be sure before he do further analysis that trigger sure works. Because there  can also be bug. This is why I ask from OP because you can believe what ever you believe but OP have this scope and can answer something real, you can only believe and dream.

[rf-loop]

Watch the video again and you'll see. In the first part (where the OP changes the pulse to 2us) there is no reason for the oscilloscope to start mixing 1us and 2us pulses. The oscilloscope is probably in auto trigger mode so it shows a flat line and a pulse in an alternating fashion but again: where does the 1us pulse comes from if there are only 2us pulses at the input?

No no, it was in normal trigger mode! Trigger arrived at 1 s pace, as the input pulses: when a flat line is displayed, it's because the scope is showing a wrong memory portion, I think. In fact, with an x-axis setting a bit slower, the pulse tends to appear in the wrong place, instead of giving a flat line.
As I told, all of this disappears above 200 us/div, or if I put the scope in slow mode.

I have also discovered that if the scope is in dual trace mode, with chA with the pulse triggered as usual and chB e.g. with a 10 MHz sinusoid, if I turn off chB, chA shows for a few pulses a mess of mix of previous chA and chB contents, similarly to what happens for the same channel when I change the pulse length.

I suppose it's a bug that will be fixed with a future update and not a defect of my scope 

Ok. If this what can see happen in video first 15 second and trigger mode is "normal"  it looks like it make false acquisition. Now is it possible you can get this same so that it can look using history, so you can look every capture and see some capture is this puklse and some capture is just trace without anything what can trig... and also what is time interval when it do these straight line acquisition. And what is time cap after pulse to first straight line where is nolt any event what meet trigger condition.
There is no any wrong place in memory...
Somehow it do extra capture when it need capture only these pulses.

We need get some data how this error can repeat in Siglent so they can analyze it. But first need isolate this problem so that other reasons than bug / bugs are eliminated out. So all need suspect.

Please do as I recommend previously. And tell what is result, exactly. Do it still fails this Normal mode trig. Donot mess with other tests mixed with this for go to forward in good order step after step.
Do it for both channels, separately, first other, then other.  (!)And also please do perfect self calibration before these very simple tests.

I do not have just this model so I can not try repeat this. If (when) it is bug, it can repeat with any same model with same FW version.

[nctnico]

Watch the video again and you'll see. In the first part (where the OP changes the pulse to 2us) there is no reason for the oscilloscope to start mixing 1us and 2us pulses. The oscilloscope is probably in auto trigger mode so it shows a flat line and a pulse in an alternating fashion but again: where does the 1us pulse comes from if there are only 2us pulses at the input?

No no, it was in normal trigger mode! Trigger arrived at 1 s pace, as the input pulses: when a flat line is displayed, it's because the scope is showing a wrong memory portion, I think. In fact, with an x-axis setting a bit slower, the pulse tends to appear in the wrong place, instead of giving a flat line.
As I told, all of this disappears above 200 us/div, or if I put the scope in slow mode.

I have also discovered that if the scope is in dual trace mode, with chA with the pulse triggered as usual and chB e.g. with a 10 MHz sinusoid, if I turn off chB, chA shows for a few pulses a mess of mix of previous chA and chB contents, similarly to what happens for the same channel when I change the pulse length.

That looks like either a bug in the firmware of hardware defect to me. There is no other explaination for this behaviour if your scope was in normal trigger mode during the first part of the video where you switch from 1us pulses to 2us pulses.

I suppose it's a bug that will be fixed with a future update and not a defect of my scope 

It would be nice if somebody with the same scope and same firmware version can try to reproduce the same effect. A defect in the hardware (address lines of the memory) is not outside the realm of possibilities though but the way modern DDR memory works is very picky about having all the address lines connected and in the right order as well. If it is a hardware defect it is an extremely rare one; and it should also mess up other measurements but it could be obscured by how the memory is divided in segments.

[RoV]

So, for make sure all is as default, do  full factory default.
After then set trigger rising edge. Level 2.5V and trigger mode "Normal"
scope for Set 2V/Div. Set time scale for 1us/div.
Take 1s period  1us wide pulses, level 0 - 5V using coaxial cable from your SDG to scope input.

rf-loop, I have followed the sequence accurately: default button, then self-cal, trigger and scope set as indicated (I'm now realizing from acquired pictures I used 2 us/div instead of one, but it's the same).
I have acquired 10 seconds using my watch, and in fact I found 10 frames in history. They are exactly alternated one pulse/ one flat line. The history list is very strange, because it shows one second every two frames, for a total of five seconds  , while I really acquired ten!!! The intermediate frames show a time which in my opinion is nonsense, because it is not an intermediate time.

I have acquired other 10 seconds at 50 us/div to show an example of pulse triggered, but shown off-center: in this case it is frame 4/10, clearly one in which timing info is nonsense.

Thank you for your interest

[RoV]

If I do the same after setting "acq mode" to "slow", it works correctly: 10 frames in 10 seconds, all with the pulse and all tagged correctly

[rf-loop]

This is highest priority bug.  Nearly as fatal bug.
Nearly infinitely impossible to believe this is your scope failure or other individual reason.
Because it looks like FW bug it can also assume it come repaired with some next FW update.
These trigger time stamps are just "absurd". Something is badly messed up.
How much it affect in other time scales etc...

If you like you can run in slow mode long capture... so that time scale is enough short for get lot of these second interval pulses. (do it exist with more fast intervals it is not clear for me). After it run some hundreds of seconds it can look if there in history is any captures without pulse. Because slow mode can trig/capture only less than 40ms interval. But fast mode with your setup it can capture, very rough guessing,  least faster than 500us interval. 

Sad I have not this model for test and document this for make Bug note to Siglent but I will still inform this to Sigflent so that they least read this thread and can test it.
But you have done it now with fully known state, so they can try repeat it. Of course now is also possible this is already internally known bug and included to "to do" list for some next FW. But this is bad bug it need make sure they know this.

Good finding! 

[rf-loop]

One note.

There was previous FW version, 1.1.19R2.

1.1.19R2. version changelog have this:

12. Fixed the bug: Normal trigger can show more-than-one trigger event on the display at one time.

There is also some other things they have "repaired"

I do not recommend, but I can tell that if I have this scope I will try downgrade it to previous version and look same test, if anything have changed. Just because I am interested about everything on this Tellus. Perhaps in last version they have somehow messed this older fix or generated new error in last FW spaghetti.. Just: 

[RoV]

If you like you can run in slow mode long capture... so that time scale is enough short for get lot of these second interval pulses. (do it exist with more fast intervals it is not clear for me). After it run some hundreds of seconds it can look if there in history is any captures without pulse. Because slow mode can trig/capture only less than 40ms interval. But fast mode with your setup it can capture, very rough guessing,  least faster than 500us interval. 

I have tried 500 ns/div and long capture (several hundreds frames) in both fast and slow mode. All frames ok in slow mode and all alternated good/bad in fast mode (with the absurd time tags).
In fast mode and single channel mode (regardless it is A or B) the problems happens for all x settings 100 us/div or faster, doesn't happen for 200 us/div or slower. If I slow down the PRF, same behavior; if I make it faster, things start changing at 10 Hz, in which case also 100 us/div work ok, but again the problem appears at 50 us/div. A quite strange bug...

Unfortunately still no one tried to replicate the problem with his/her 2202X-E.
Do you think Siglent is reading the thread, to include the bug in their to-do list?

[FrancisM]

Hi Roberto,

I'm the owner of an SDS2352X-E and SDS2104X+.
I just tried to replicate your findings.
Sending a 1µs pulse every second out of the 2104 gives the same results as yours on my 2352.
And of course, the 2104 displays the pulse perfectly in normal mode.




BTW Roberto, never got a frozen front end ?
Have a look at this thread from reply 2 :
https://www.eevblog.com/forum/testgear/siglent-sds2352x-e-scopes/

All the best,
Francis

[kcbrown]

I'm likewise unable to replicate this on my SDS-2104X+.   1 us/div timebase, 1 us pulse width, 1 Hz repeat rate, normal trigger.  I've tried it with 20k points buffer and 2M points buffer, with no difference in the results.

[RoV]

Hi FrancisM,

so now we know for sure that it's a bug affecting both the 2202X-E and 2352X-E... let's hope they fix it soon!

Regarding the frozen front end: no, never experienced in an year of usage. What I find a little disturbing of the interface is the fact that the encoders suffer from frequent false steps (I turn one step, but nothing happens and I have to turn another step, specially for V/div).

Thank you,
Roberto