SDS1204X-E scope freezing when collecting waveform

[bd139]

Mine always succeeds. I tried it up to 200.

But the moment you close the connection that's it.

Hence pointer fun.

[bd139]

I would prefer to gather quality info so Siglent can easily reproduce and fix the deficiency if there is one...

They have the info required:

1. The device that it's appearing on.
2. The software version
3. A test case that is reproducible by multiple people.

Now they need to:

1. Hook up a debugger to a scope
2. Run the same steps we have
3. Catch the crash in a debugger.
4. Work out what did it.

We can't do 3 and 4 because it's closed source.

Well we can but we can only speculate and use naughty disassembly tools and then wave our fists angrily.

Our bit is done.

[bdunham7]

Okay, so i have my trigger set a freq and im reading the waveform produced by a laser pulsing and some decay time.
Again maybe i dont understand this well enough but the scope is constantly being triggered on that freq. I am not stopping it and retriggering it every waveform capture.

(Unless its just doing that automatically and again im to new to know about it.)

OK, I have one of these scopes so walk me through exactly how you are setting it. 

The general idea is that there is a trigger event, then the scope performs one capture (one screen worth in the case of this model).  That trigger event can be simple or complex--if you press 'trigger setup' then 'trigger type' (left-most bottom button under screen) you'll see the available types.  The default is 'Edge' and unless you've changed it, that's what you are likely using. 

 If the scope is in 'Normal' mode, it will only perform a capture when there is a trigger.  'Auto' will perform a capture after a set interval if there is no trigger event--this is useful for setting the scope up initially, but captures like you are doing should always be done in the normal mode.  After the trigger event and capture, there is a short period before the scope can get its act together and be ready for another trigger.  It will ignore any trigger events during this retrigger time.  The holdoff setting increases this retrigger time to an arbitrary value that you select.  There are several reasons for doing this and it may or may not help with your issue.

[AnarchistWolf]

I have the trigger setting in edge-falling, it is also set to auto.

I will mess around with the normal trigger mode and holdoff delay (I appreciate the suggestion).

Ill update you once I run a few tests.

Best,
W

[AnarchistWolf]

Same problem occurs. I even set it to 500ms (Which is out of the range i need to work in). I did 50 captures and after it finished it froze the instrument.

[bdunham7]

Same problem occurs. I even set it to 500ms (Which is out of the range i need to work in). I did 50 captures and after it finished it froze the instrument.

What is out of range?  You're still using 200µs/div timebase, only with 500ms holdoff, right?  If it still freezes, then it is a software bug that is not related to scope workload.  I haven't tried your code and I won't have time/space, but since two others have confirmed it here, I suppose that is indeed the case.  The only suggestion I can think of other than reporting this to Siglent is to roll back the firmware to some earlier versions and see if they have the same issue.  I don't know how far back you can go with the firmware, I think it depends on how new the scope hardware is.

[bd139]

I don’t know why workload is even being discussed.

It’s defective software. Any remote procedure call should not hose the scope regardless of what you do.

[tautech]

Pokes tautech... 

Ouch !  Prune those fingernails please ! 

You all did just fine while I slept, and thank you all for the trouble to check this out. 

Sinisa, do you have enough info to take this to Siglent or Herbie since he has 2&4ch X-E's ?

[2N3055]

Pokes tautech... 

Ouch !  Prune those fingernails please ! 

You all did just fine while I slept, and thank you all for the trouble to check this out. 

Sinisa, do you have enough info to take this to Siglent or Herbie since he has 2&4ch X-E's ?

Yeah I think so..
BD139 is right, there is enough info to confirm something is fishy and to start investigation...

[tautech]

Pokes tautech... 

Ouch !  Prune those fingernails please ! 

You all did just fine while I slept, and thank you all for the trouble to check this out. 

Sinisa, do you have enough info to take this to Siglent or Herbie since he has 2&4ch X-E's ?

Yeah I think so..
BD139 is right, there is enough info to confirm something is fishy and to start investigation...

It's done ! 

@AnarchistWolf
I have a beta FW for you to try and report back with your findings, please PM me with your email address.

[bd139]

That’s pretty awesome. Fingers crossed 

[2N3055]

Pokes tautech... 

Ouch !  Prune those fingernails please ! 

You all did just fine while I slept, and thank you all for the trouble to check this out. 

Sinisa, do you have enough info to take this to Siglent or Herbie since he has 2&4ch X-E's ?

Yeah I think so..
BD139 is right, there is enough info to confirm something is fishy and to start investigation...

It's done ! 

@AnarchistWolf
I have a beta FW for you to try and report back with your findings, please PM me with your email address.

That was damn fast even for you... 

[tautech]

Pokes tautech... 

Ouch !  Prune those fingernails please ! 

You all did just fine while I slept, and thank you all for the trouble to check this out. 

Sinisa, do you have enough info to take this to Siglent or Herbie since he has 2&4ch X-E's ?

Yeah I think so..
BD139 is right, there is enough info to confirm something is fishy and to start investigation...

It's done ! 

@AnarchistWolf
I have a beta FW for you to try and report back with your findings, please PM me with your email address.

That was damn fast even for you... 

Well Siglent were watching all along it seems..... as I did nuthing ! 

That’s pretty awesome. Fingers crossed 

Yep, but don't worry I reminded them who did a lot of the work and they had a SDS1202X-E which requires the exact same fix !   

This is what dropped into our Inbox
Socket communication problem
We found a TCP socket communication problem discussion in below link of EEVblog
https://www.eevblog.com/forum/testgear/sds1204x-e-scope-freezing-when-collecting-waveform/

It maybe a bug for the socket. If we analyze correct, it will be solved in the new firmware.
Please send the attachment firmware to the customer. And feedback to me the result.

That's just gotta give you the smileys. 

[tv84]

This is what dropped into our Inbox
Socket communication problem
We found a TCP socket communication problem discussion in below link of EEVblog
https://www.eevblog.com/forum/testgear/sds1204x-e-scope-freezing-when-collecting-waveform/

It maybe a bug for the socket. If we analyze correct, it will be solved in the new firmware.
Please send the attachment firmware to the customer. And feedback to me the result.

That's just gotta give you the smileys. 

Siglent 1 - 0 A Brands

[bd139]

Will make sure we post this on the Keysight thread 

[AnarchistWolf]

I just got on (Stayed up till 3am trying to get some stupid code to work) so i apologize that i am late to the party 

But thats great! hopefully it fixes all my problems and my broken relationship (JK).

Thankyou all that helped and gave this post viability.

Best,
W

[Caliaxy]

Will make sure we post this on the Keysight thread 

Why? Releasing equipment with multiple bugs fixed through multiple firmware updates is not something their target customers envy

Siglent’s response time is impressive though. They work really hard to win our hearts and minds

[2N3055]

Will make sure we post this on the Keysight thread 

Why? Releasing equipment with multiple bugs fixed through multiple firmware updates is not something their target customers envy

Siglent’s response time is impressive though. They work really hard to win our hearts and minds

If you think Keysight has no bugs you are sorely mistaken.

I found a bug in MSOX3000T network stack where certain series of Internet routers would respond to scope with some weird packet during DHCP process where scope was trying to get IPv6 address while router had IPv6 protocol disabled.
Instead of scope ignoring it and not configuring IPv6, scope configured network stack into some weird state that it would hard reset the scope when trying communicate over network.
First time it happened it looked like something was wrong with memory on mainboard and that scope is done...
Response from Keysight was that they know the problem and they couldn't be bothered to fix it, or even to put in a config option to disable IPv6 for people that don't use it (99% or people on internal networks).

"
The lab team will look into if it’s technically feasible to add an option to Disable IPv6 on the scope, however it’s not a priority and will most likely not happen.
As far as how to proceed, we appreciate Your offer to capture router-scope traffic, however since our  labs team are busy with other priorities, we won’t be pursuing this further at this time. 
"

So yeah, Keysight has bugs and they are fixing them when it is their priority.. My fix was that I had to buy a separate router and add it to the network... Scope bug is still there.

Releasing equipment with multiple bugs fixed through multiple firmware updates is exactly what Keysight and R&S  and othe A brands do, like many others today...
The firmware release document for 3000T is 18 pages long... Read it to see how many bugs were there and how long it took to fix them.
In everybody's defence, scopes are so complicated today and they cannot have time to market of 10 years..

What matters is that bugs are fixed. And A tier manufacturers are not that perfect in that as many think.. At least not if you are not on multi million contract with them...

OTOH, on other occasion I mentioned that MSO 3000T was missing pulse count measurement on digital channels (it had it only on analog ones) and they added that measurement on next firmware (some 10 months later, when they pushed it for some other reason)...
So Keysight are not bad but far from perfect.

OTOH I find Siglent's effort to be first class and they are working harder than anybody else including many A brands...

[bd139]

I worked through a bug with HP back in the day. They were excellent.

Looks like Agilent kept the HP way…

[tautech]

I just got on (Stayed up till 3am trying to get some stupid code to work) so i apologize that i am late to the party 

But thats great! hopefully it fixes all my problems and my broken relationship (JK).

Thankyou all that helped and gave this post viability.

Best,
W

Just dragged my sorry butt outta the scratcher and sent you the rather large beta FW file and at 9MB could take a bit to reach you.
Please remember to pop us some feedback about it.

[nctnico]

This is what dropped into our Inbox
Socket communication problem
We found a TCP socket communication problem discussion in below link of EEVblog
https://www.eevblog.com/forum/testgear/sds1204x-e-scope-freezing-when-collecting-waveform/

It maybe a bug for the socket. If we analyze correct, it will be solved in the new firmware.
Please send the attachment firmware to the customer. And feedback to me the result.

That's just gotta give you the smileys. 

Siglent 1 - 0 A Brands

No. It would surprise me if a bug like this would escape testing in a product from an A brand. After all testing remote operation can be automated very easely. There is no reason to cheer about a beta firmware that is thrown over the hedge for a customer to test as well. It would be better to take a few days and make sure the bug is fixed without any regressions instead of using a customer as a firmware tester. If you look closely you'll notice that A brands are very reluctant to release beta firmware; they want released firmware to go through thourough testing.

[bd139]

This is what dropped into our Inbox
Socket communication problem
We found a TCP socket communication problem discussion in below link of EEVblog
https://www.eevblog.com/forum/testgear/sds1204x-e-scope-freezing-when-collecting-waveform/

It maybe a bug for the socket. If we analyze correct, it will be solved in the new firmware.
Please send the attachment firmware to the customer. And feedback to me the result.

That's just gotta give you the smileys. 

Siglent 1 - 0 A Brands

No. It would surprise me if a bug like this would escape testing in a product from an A brand. After all testing remote operation can be automated very easely. There is no reason to cheer about a beta firmware that is thrown over the hedge for a customer to test as well. It would be better to take a few days and make sure the bug is fixed without any regressions instead of using a customer as a firmware tester. If you look closely you'll notice that A brands are very reluctant to release beta firmware; they want released firmware to go through thourough testing.

I spent plenty of time doing test automation with A brand test gear. It was buggy as hell and difficult if not impossible to get fixed as half the firmware was in ROM. We’re talking 12 month turnaround.

Also there’s nothing to suggest this won’t have gone through full regression testing before general release. But on step one you always get the issue mitigated.

The turnaround here is commendable on all levels. .

[tv84]

No. It would surprise me if a bug like this would escape testing in a product from an A brand. After all testing remote operation can be automated very easely. There is no reason to cheer about a beta firmware that is thrown over the hedge for a customer to test as well. It would be better to take a few days and make sure the bug is fixed without any regressions instead of using a customer as a firmware tester. If you look closely you'll notice that A brands are very reluctant to release beta firmware; they want released firmware to go through thourough testing.

The software was not "thrown over the hedge for a customer to test as well". AFAIK the software was provided specifically to that customer since he was the one who reported the problem and is in a better position to finally check if that solves his problem (like any other betatester).

They could have find an issue BUT that doesn't mean it solved the whole client problem. So why issue a patch only in a next release, tested only by what Siglent QA was able to test, and find out that it didn't yet solve the whole original problem?

This action is perfectly correct IMO.

No QA department will be able to replicate all the cases a equipment can be used by its customers. You sure know that very well.

[2N3055]

No. It would surprise me if a bug like this would escape testing in a product from an A brand. After all testing remote operation can be automated very easely. There is no reason to cheer about a beta firmware that is thrown over the hedge for a customer to test as well. It would be better to take a few days and make sure the bug is fixed without any regressions instead of using a customer as a firmware tester. If you look closely you'll notice that A brands are very reluctant to release beta firmware; they want released firmware to go through thourough testing.

The software was not "thrown over the hedge for a customer to test as well". AFAIK the software was provided specifically to that customer since he was the one who reported the problem and is in a better position to finally check if that solves his problem (like any other betatester).

They could have find an issue BUT that doesn't mean it solved the whole client problem. So why issue a patch only in a next release, tested only by what Siglent QA was able to test, and find out that it didn't yet solve the whole original problem?

This action is perfectly correct IMO.

No QA department will be able to replicate all the cases a equipment can be used by its customers. You sure know that very well.

@TV84, exactly...
The way I understood, a debug FW was sent to customer to verify exact problem. FW with a fix will be published for general use after proper regression testing is done. That is exactly what Keysight (for instance) would do...

[MathWizard]

I have the hacked SDS1104x-e, and I have old BIOS, (TT did link me the bios before)

Yesterday I had 2 freeze ups, that required (I guess) a reboot. I've had them before, but not in ages (but I haven't used it much this last year)

While using 2 channels, on 500us /div, and the 700k or next highest memory depth

I also had the wifi dongle in, talking to my modem, which talks to my PC, and I use firefox to look at the scope. The firefox page updates pretty slow, and always stops and lags for a moment, a lot more than the scope sometimes does as it refreshes the screen.

I usually always have the wifi on when running, but I don't usually have the web interface running unless I want a screenshot.