EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Elasia on April 26, 2020, 03:56:59 pm
-
Hi all
I am making this thread for those of us who have this nice new scope to report bugs and any feature requests in so they have a clean thread that can be followed by Tau & Siglent
Please keep this thread topic on bugs and feature requests only!
----
Starting this off with a bug Martin72 found and I can confirm
And another strange thing concerning saving screenshots on stick:
Example, you took the stick into the port, taking a screenshot, it will be "named" with 1, what makes sense, because it is the first.
Next shots will be 2,3,4, etc...
So far so good.
But this will going only when you leave the stick connected.
If you put the stick out ( because you want to transfer the pic to pc) and then back, the first pic will be overwrite without a request.
Tomorrow I´ll examine it more exactly.
Hmm...Maybe it´s time for a dedicated bug and missing features thread.
I can confirm this happens if you reboot the scope, so i think its clear its keeping the value in ram and not looking at the usb stick at all before writing nor does it ask to overwrite the prior picture / give opportunity to rename the file
-
Hi and thanks for starting.
Bug:
- When you start bode plot, the internal awg turns automatically on ( which makes sense..), but if you deactivate it, the awg remains on.
(More to come in the next days, must search in the siglent thread)
Wanted Features:
- All math/decoding functions could be displaying exclusive, this means, channels are hideable - Actually only FFT can be displayed exclusive on the screen.
- Bitrate displaying in the decoding table
- More math traces if possible, 4channel = 4 math traces
- New mathfunction digital filters, highpass, lowpass, bandpass, etc. - Or the possibility to create them via the formula editor.
- Splitscreen function, every channel could have it´s own grid area ( if it´s possible)
- More Information in the math channel "box", actually it´s only named with trace nr. and value - better: trace nr, function name, from which channel :
[attachimg=1]
[attachimg=3]
- Free choosable trace colours for channels, mathfunctions, Decodings
More to come…. ;)
-
Bug:
FFT Marker Table:
- Even when the switch for "Show Table" is on, the table is not shown unless you toggle the switch. Same for "Show Delta".
- When switching off the "Show Frequency", the "Delta" column is incorrectly labeled as "Abs.Freq" (screenshot)
[attachimg=1 width=600]
-
Wanted feature:
- manually assign markers to detected peaks. The automatic marker functions are not clever enough to always set marker #1 to the "correct" peak (the peak corresponding to the carrier).
-
Wanted feature:
- manually assign markers to detected peaks. The automatic marker functions are not clever enough to always set marker #1 to the "correct" peak (the peak corresponding to the carrier).
:o
X-E models can do this.
Marker Control> select marker>Frequency> press multifuncion control and edit value with virtual keyboard or manually with the encoder.
No 2kX Plus here ATM so someone needs to check this ^
-
Wanted feature:
- manually assign markers to detected peaks. The automatic marker functions are not clever enough to always set marker #1 to the "correct" peak (the peak corresponding to the carrier).
:o
X-E models can do this.
Marker Control> select marker>Frequency> press multifuncion control and edit value with virtual keyboard or manually with the encoder.
No 2kX Plus here ATM so someone needs to check this ^
Oh yes! I found it. It seems it's in the same menu "Marker Control". It's a bit clumsy to operate when the markers are all on (you need to disable them one by one). An additional menu item "Disable All Markers" would be very nice.
[attachimg=1 width=600]
-
An additional menu item "Disable All Markers" would be very nice.
Please properly explore your scope before asking for stuff that's already there.
Math menu>Tools = OFF.
-
Please properly explore your scope before asking for stuff that's already there.
Sure but it also depends on how obviously the stuff is, in the menus, in the user manual.
-
An additional menu item "Disable All Markers" would be very nice.
Please properly explore your scope before asking for stuff that's already there.
Math menu>Tools = OFF.
Not what I meant.
That disables the marker function completely. But to set them manually, one by one, they have to be switched off before, individually, and if you ever used the e.g. "set to harmonics" function, all 8 markers will be on. Same if you reset the search threshold. But most of the time you don't need all 8, you need two, maybe three.
-
To be added (because it should be already present) :
1) For the internal generator, when using the rotary encoder to change output frequency
add the ability to choose any digit corresponding to frequency increment.
(For now, increment is always moving the second digit, so impossible to move slowly
the output frequency using the knob).
Bug :
2) Remove the display artifact that appear in some time base and menu situation.
(As reported by others on main thread).
Frex
-
Bug :
2) Remove the display artifact that appear in some time base and menu situation.
(As reported by others on main thread).
It's on all time base settings when the menu is open. Best visible with e.g. sine or rectangle triangle waveform.
[attachimg=1 width=500]
[attachimg=2 width=500]
-
Missing feature:
Searchable PDF manual... should be an easy one if Tau could poke them to reexport the manual
-
Missing feature:
Searchable PDF manual... should be an easy one if Tau could poke them to reexport the manual
Already being done by this ex-member:
Hello. I tried it too. My siglenteu.com file is 34.9MB in size. But you are right, if you enter the word peak it will not be found. I will investigate it further and report it to Siglent if necessary.
-
Hello,
1) New bug, confirmed by other users.
On Bode plot, in some situation (50 points/decade for me) there is a wrong measurement
that show spike in Bode response.
In the test setup, no DUT is used, generator directly connected to input and output channel,
then Bode make output/input plot.
Problem occur in both fixed level and vary level mode.
Example below :
(http://oneaudio.net/Pict/BodeBad1.png)
The used setup :
(http://oneaudio.net/Pict/BodeBadconfig.png)
2) Internal generator missing obvious function :
Now, there is another things to say about the internal generator.
I already had a complaint about the inability to set fine frequency
adjustment by using the rotary knob, but i used a little the generator
and we can say this can really not replace even a very low cost stand alone one.
There is now way to modulate the generated waveform !
No modulation at all.
(Even very low price DDS generator can do this).
I think this would be a good improvement to add this feature.
Frex
-
1) New bug, confirmed by other users.
I can confirm it too.
Done Bode today, the spike occurs here too - regardless if you choose the minimum points or more.
And it´s change the frequency, first time it was at 100hz, second time at 1khz.
Or "never"...
Additionally:
Regardless of the choosen amount of points, the system performance in general is slowing down massively (e.g. if you want to save screenshot or if you want to deactivate the bode function or change menu settings while it´s active.).
And:
When you start bode plot, the internal awg turns automatically on ( which makes sense..), but if you deactivate it, the awg remains on.
And not only the awg, the channel settings bode plot are using will remain also, after deactivating bode function, the awg should turn off also and the channels should remain their former settings.
Finally, display settings on bode plot: When you change the vertical scaling to 1dB and start bode plotting, it changes the scaling to 0.5dB.
Measurements:
Sometimes, I couldn´t add a second measure value for one channel, e.g. I got rms and want to add risetime, I could select it but when you turn out of the menu, the value is not displayed.
Only when I´m clearing all parameters, then I could add it.
This behaviour wasn´t all the time given and it only happens in advanced mode.
-
Serial decoding settings (signals->channels) are lost after power cycle. For example I set SPI with SCK to D0, MISO to D1, MOSI to D2, CS to D3. After power off - on, SCK changes to C1, MISO is disabled, MOSI is disabled and CS is also set to C1.
-
Do you have changed the power on state to "last" ?
-
Do you have changed the power on state to "last" ?
I cannot find the power on state option
-
Do you have changed the power on state to "last" ?
I cannot find the power on state option
I take this back, I can fully confirm what he has said is true
It does not reload the protocol signal address back into the bus parameters; or rather what it should say it is haphazard.. mine works sometimes.. others just one.. others neither and im doing CAN on D0/D1
Save/recall does not work either, in fact it can fully reproduce the error as described without a shutdown
-
There is no way to enter 'X' (don't care) in the serial decode trigger, it only accepts 0 and 1 in binary input mode, 0 to F in HEX... but no 'X'
[attachimg=1]
-
There is no way to enter 'X' (don't care) in the serial decode trigger, it only accepts 0 and 1 in binary input mode, 0 to F in HEX... but no 'X'
(Attachment Link)
Fixed in firmware 1.3.5R5. Siglent added 'X' key below 'F'
-
Firmware 1.3.5R5 and below:
The serial trigger on data value is reset to all '1' (i.e. 8-bit SPI is reset to 11111111) after reboot
-
Hi and thanks for starting.
Bug:
- When you start bode plot, the internal awg turns automatically on ( which makes sense..), but if you deactivate it, the awg remains on.
(More to come in the next days, must search in the siglent thread)
Wanted Features:
- All math/decoding functions could be displaying exclusive, this means, channels are hideable - Actually only FFT can be displayed exclusive on the screen. Done!
- Bitrate displaying in the decoding table
- More math traces if possible, 4channel = 4 math traces
- New mathfunction digital filters, highpass, lowpass, bandpass, etc. - Or the possibility to create them via the formula editor.
- Splitscreen function, every channel could have it´s own grid area ( if it´s possible)
- More Information in the math channel "box", actually it´s only named with trace nr. and value - better: trace nr, function name, from which channel Done !
- Free choosable trace colours for channels, mathfunctions, Decodings
More to come…. ;)
2 wanted features done in the first fw update - real nice. :D
A little wish concerning the channel info box: Instead of e.g. "DC1M" now it´s displaying "D1M" which is somekind of irritating, maybe this could be corrected.
-
Hi,
Bug:
Advanced Measurements Menu :
Sometimes you couldn´t add another measure, you choose it from the menu but if you return to the the screen, it won´t be displayed.
Everytime: You want to choose or change the source, it remains the same before.
Only if you delete all maeasurements, the "new" choosen one will be displayed proper.
Saving/USB Stick Problem :
Putting a stick which already got a siglent directory onto it and press print, message appears that the pic 12 (e.g) has been stored.
I took several "prints" until pic 17, remove the stick and put it into pc - NO pics were saved…
Took another stick witout siglent directory, the pics will be stored beginning with nr 18...….
And this time, there are on the stick.
-
Hello,
If we take a look on the Bode plot function on the MSO5000 competitor with 100point/decade (posted these days),
we can really ask why it's sssooooo slow on the SDS2104X-Plus !!
The difference is HUGE.
So, there is still a highway for Siglent to improve the firmware IHMO.
Frex
-
Hi !
This was my first Impression too (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3078525/#msg3078525)……. ;)
But nevertheless, the speed in general should be optimized, especially the general system slowdown.
-
Hi
I missed the functionality to copy FFT settings from F1 to F2. I like to see it in the same way as with channel settings from one to another.
Or have I overseen it?
-
Zoom out mode options
While the attached screenshot does work, it would be nice if the preview bar could be hidden and also option of a small slider with no preview
Also further allow this mode to be set as a preference when working with memory depth and reflect that status on the time base display with the zoomed in time base. While it does work, it is a bit convoluted and not native as in just use the horizontal control to see more on stopped/triggered data which is much more natural
-
I have a question.
I have an SDS2204X plus and just to be sure I wanted to upgrade to the latest firmware version zo I downloaded the 1.3.5R5 file and did the upgrade process.
After the upgrade the FPGA version did go from a date in 2019-xx-xx to 2020-01-08, but the reported Software Version stayed at 1.3.5R3.
See also screenshots. Can somebody verify what their numbers are after the upgrade? So perhaps the number is just wrong and the update is performed, but I'm also unable to find the option to Hide the analog trace, I can only put it off, but then the depending function traces will fail. I assume that the idea of the new Hide option is to only hide it on screen, so the dependent function trace still works.
Can anybody elaborate on that, so I can verify if the version is just reporting a wrong number or still the old version is on the scope although I tried to update to 1.3.5R5 a few times.
-
Hi,
I got the R5 displayed - You could easily detecting having the new firmware by checking the channel info boxes.
In your second pic, "AC 1M" is displayed, with the new firmware it would be reduced to "A 1M" (which is a bug in my opinion).
-
I have a question.
I have an SDS2204X plus and just to be sure I wanted to upgrade to the latest firmware version zo I downloaded the 1.3.5R5 file and did the upgrade process.
After the upgrade the FPGA version did go from a date in 2019-xx-xx to 2020-01-08, but the reported Software Version stayed at 1.3.5R3.
Welcome to the forum.
Version should be 5R5. :-//
Here is the EU official download site:
https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds2000x-plus (https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds2000x-plus)
The scope should reboot after FW installation, did it ?
Oh, and when the new version is installed and after ~20 minutes runtime, run the Self Cal.
-
Missing feature:
Manually control of the memorysize (https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3093942/#msg3093942).
Regardless of the (dis-)advantages, if possible, they should implement it.
-
Oh, and when the new version is installed and after ~20 minutes runtime, run the Self Cal.
Damn, now I know what I´ve forgotten... 8)
-
The mess is getting bigger!
I upgraded the scope with the 'SDS2000X Plus_1.3.5R5.ADS' file via the web interface. I saw in the system info that the FPGA version went from 2019-xx-xx to something in 2020 and didn't pay further noticed, the scope worked after the update it was late the first day with the scope and I went to bed. The next day I noticed that the instrument part of the web interface did not work. The other parts did work I could send the SCPI command SCOPEID and it returned a number.
One of the last things I did was the upgrade, so I looked a bit better at the system info and noticed that the software version was 1.3.5R3 while I had uploaded the 1.3.5R5 file. I though perhaps only the FPGA part is upgraded via the web interface upgrade, so I did again an upgrade, but now via the USB stick. After this "upgrade" the instrument control of the web interface did work again. But the version number in the system info still was 1.3.5R3, thus I put here the question, because I also could not find the new "Hide" option that was part of the latest release.
Somebody here made the remark about the "AC 1M" in my screenshot, which should be "A 1M", Thus after the upgrade my version was still 1.3.5R3 and thus there was not a wrong number reported, the upgrade was only partial, the FPGA part was upgraded.
So I thought I just try it again with an USB stick. The R5 file loaded again all went normal and then there was the reboot button and I rebooted the scope. But the scope comes now up with the Siglent logo and then hangs, it does not respond to any key, also not the on/off switch. I removed the power supply and tried it a few times, all in vain.
The strange part is, that some parts of the web interface do work. It does respond to a ping, so some processes are started, but it hangs somewhere. My hardware version is reported as 02.00, is that a common version or do I have a different hardware version that is now giving problems?
-
Somebody here made the remark about the "AC 1M" in my screenshot
The "somebody" was me, no long time ago... ;)
What I can say in general is, that I was probably one of the first customers bought the scope in january this year.
Hardware revision was 2.0, software R3.
As the next upgrade came up, R5, I did the upgrade via usb stick and got no issues.
Everything works fine here.
-
The mess is getting bigger!
I upgraded the scope with the 'SDS2000X Plus_1.3.5R5.ADS' file via the web interface. I saw in the system info that the FPGA version went from 2019-xx-xx to something in 2020 and didn't pay further noticed, the scope worked after the update it was late the first day with the scope and I went to bed. The next day I noticed that the instrument part of the web interface did not work. The other parts did work I could send the SCPI command SCOPEID and it returned a number.
One of the last things I did was the upgrade, so I looked a bit better at the system info and noticed that the software version was 1.3.5R3 while I had uploaded the 1.3.5R5 file. I though perhaps only the FPGA part is upgraded via the web interface upgrade, so I did again an upgrade, but now via the USB stick. After this "upgrade" the instrument control of the web interface did work again. But the version number in the system info still was 1.3.5R3, thus I put here the question, because I also could not find the new "Hide" option that was part of the latest release.
Somebody here made the remark about the "AC 1M" in my screenshot, which should be "A 1M", Thus after the upgrade my version was still 1.3.5R3 and thus there was not a wrong number reported, the upgrade was only partial, the FPGA part was upgraded.
So I thought I just try it again with an USB stick. The R5 file loaded again all went normal and then there was the reboot button and I rebooted the scope. But the scope comes now up with the Siglent logo and then hangs, it does not respond to any key, also not the on/off switch. I removed the power supply and tried it a few times, all in vain.
The strange part is, that some parts of the web interface do work. It does respond to a ping, so some processes are started, but it hangs somewhere. My hardware version is reported as 02.00, is that a common version or do I have a different hardware version that is now giving problems?
Thank you for the informative write up. :-+
I have seen this just once before and a recovery package is now available from Siglent but........they are monitoring boot failures for these models very closely as it's apparently very unusual.
I have the recovery package but it is too large to email but I can get a download link for it from Siglent.
They require your SN# so that problems like this can be traced back to possible early firmware problems.
Please PM me your SN# and I'll take your problem to Siglent and should get an answer in a few hours when they arrive at work.
-
I've send an PM with the serial number and the serial number can also be seen at a screenshot of my first post. It would be nice if the scope can be "unbricked" and that it does actually upgrade to version 1.3.5R5 with which the whole thing started.
-
This some sort of bad flash writing? Sounds almost like the file system got completely filled up or the writes are bombing out elsewhere
I'd be curious what the internal uart console is reporting.. if you do ever open it up and connect to the uart port, boot while connected to that and paste the result here
Edit: further that it is allowing LAN access tells me you do have the linux kernel booting and this is more than likely something went wrong with the file system somewhere for reasons unknown
-
Have you tried to flash again the R3 version?
Try to do it. If it works check all things and then try again with R5.
-
Before you try to reflash R3
Do this and see if you can get into telnet, if you can and you get to the shell prompt
Run
df -k
Paste the results here
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3006340/?topicseen#msg3006340 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3006340/?topicseen#msg3006340)
-
Was also my thinking that there is perhaps a bad flash or something.
First the "upgrade" via instrument control of the web interface and after that the instrument control part of the web interface was no longer working. Then an upgrade via USB and the interface control part was there again, but I noticed an old version number reported. Since I had a strong suspicion that I did not have the 1.3.5R5 options, again an upgrade attempt via USB and then it was bricked. So a whole sequence of strange things related to the upgrade stuff.
-
I can ping and some parts of the web interface are working, but telnet does not work. I already tried that to see if that process was started or not. Thus I can not do the df -k command
I had telnet working before things went bad.
-
I've send an PM with the serial number and the serial number can also be seen at a screenshot of my first post. It would be nice if the scope can be "unbricked" and that it does actually upgrade to version 1.3.5R5 with which the whole thing started.
Received, thanks.
The recovery package installs the latest FW version and fixes the operating system automatically.
As mentioned, I have seen this once before in a SDS2104X Plus belonging to a member in OZ. His scope was fixed immediately with the recovery package.
-
Have you tried to flash again the R3 version?
Try to do it. If it works check all things and then try again with R5.
If it was possible to do any reflash, I could give it a try, but at the moment no reflash of any version is possible
-
I can ping and some parts of the web interface are working, but telnet does not work. I already tried that to see if that process was started or not. Tus I can not do the df -k command
Well that sucks... what was in the file? just "telnetd" right? just make sure you have no enter new line following it.. the contents should be exactly "telnetd"
If it is correct... then what a pain in the ass... means you have to hardware into the serial console by taking the backshell off to see what its really hanging on, which if you need to send it in you might not want to bother with either
Only thing you can do is wait for tau to get you that link if you cant get a shell
-
Yep the line was correct, since I already had telnet working, before it ...
In my time zone it is midnight, so time to do other things ...
-
Only thing you can do is wait for tau to get you that link ............
We'll have jvenema all fixed before you know it. ;)
BTW, the Aussie one that did this had a low SN from last years production too.
-
Only thing you can do is wait for tau to get you that link ............
We'll have jvenema all fixed before you know it. ;)
BTW, the Aussie one that did this had a low SN from last years production too.
Did they leave extra junk in the partition causing it to not copy over everything? It's exactly what happened to my SSA i had to clean up when i did that myself
-
Only thing you can do is wait for tau to get you that link ............
We'll have jvenema all fixed before you know it. ;)
BTW, the Aussie one that did this had a low SN from last years production too.
Did they leave extra junk in the partition causing it to not copy over everything? It's exactly what happened to my SSA i had to clean up when i did that myself
Dunno, way past my programming knowledge. :palm:
I guess they have SSA/SVA recovery packages too but I haven't got them in my folder yet. :popcorn:
-
:-+ :-+ :-+ :-+
The scope is working again! Just a breeze, two files on FAT32 USB reboot wait a minute and it is up and running. Further I have the impression a new firmware release is coming up. Look at screenshot, also the web interface is a bit different. Once in instrument control mode the left navigation stuff disappears and the only way back is via the history buttons of the browser. No big deal, don't know if it is intended or a bug.
But anyway I'm happy at the moment and hope there is no issue with a next upgrade.
Thanx for the help here!!!!
:-+ :-+ :-+ :-+
-
:-+ :-+ :-+ :-+
The scope is working again! Just a breeze, two files on FAT32 USB reboot wait a minute and it is up and running. Further I have the impression a new firmware release is coming up.
Them is always fixing little things. ;)
Look at screenshot, also the web interface is a bit different. Once in instrument control mode the left navigation stuff disappears and the only way back is via the history buttons of the browser. No big deal, don't know if it is intended or a bug.
Esc (Escape) IIRC pops you back to the Welcome page and/or gets you back from full screen mode.
Enjoy. ;D
-
The AWG is gone from the options, I noticed. And I see the table bug with the FFT is gone :-+ :-+
Also the C is back in "AC1M"
The esc key does bring me back from full screen, but not back from the instrument control screen to the home screen, but as said no big issue here.
-
The esc key does bring me back from full screen, but not back from the instrument control screen to the home screen, but as said no big issue here.
Then try your browser Back button, that should get you to the Welcome page.
-
Well into OT. Time to move on...
-
Well into OT. Time to move on...
Not at all.
Webrowser navigation shortcuts are not mentioned in the manual at all so it's a missing feature. ;)
-
Has anybody else noticed that Video Sync as a trigger option is not working as expected ?
I've set the trigger to PAL, on line 1 field 1, but it seems that at different timebases triggering happens at either field 1 or field 2 randomly; and sometimes on both field 1 and field 2.
-
Has anybody else noticed that Video Sync as a trigger option is not working as expected ?
I've set the trigger to PAL, on line 1 field 1, but it seems that at different timebases triggering happens at either field 1 or field 2 randomly; and sometimes on both field 1 and field 2.
Does increasing Holdoff help ?
-
There is no option for holdoff when Video is the trigger type, unless I'm completely blind and just not seeing it!
-
There is no option for holdoff when Video is the trigger type, unless I'm completely blind and just not seeing it!
Check the Trigger menu scroll bar on the edge of the display is to the bottom to see all the menu.
A mouse with a scroll wheel makes this easy.
-
Definitely no hold off.
I just think its a bug, that video trigger doesn't get field selection correct. On my Tektronix it works as expected.
-
Wrong source mentioned in function dialog. I have the AWG output connected to channel 3 and added function 1, with as operation the eres, just as an example.
I've selected C3 as source but it is displayed as RES.
C1 becomes C
C2 becomes Z
C3 -> RES
C4 -> F
With Z1-Z4 or an F selected as input it is displayed as @@@
The functionali itself looks ok.
Note that because of a boot problem which needed an recover from a boot USB, I'm on an alpha or Beta version of 1.3.5R6 of the software.
While we are on the subject of ERES, does the additional resolution add up to the 10 bits resolution if that is selected, or is it always in addition to the 8 bits. And why is it so slow, other scopes, do it on the fly, like the 10 bits mode on the SDS2000X plus does. So why is there a lag? And the selection of the mode is perhaps not the most user friendly in the sense, that if you want to use it, you want as much resolution as possible and you know the needed bandwidth. Why not have a mode that you specify the bandwidth that is needed for the measurement and that then based on that you get the best resolution. When doing e.g. an audio measurement a bandwidth of 100kHz is more than enough, so let it then calculate what it can do from there.
I think this also touches the discussion about memory depth and history etc. The sample rate can be high and there is memory, but not always it is used in the most practical manner given the possible use cases.
Is there some documentation about the *.ref file format?
-
Related to my issue with video triggering, I was disappointed that the source for video trigger could only be analogue channels 1 to 4. So ...
Feature request : Allow selecting external trigger source as one of the sources for video triggering.
-
Bug:
Power on state is partly setting to defaults instead of last used, example given:
When awg is active and a waveform selected, then turning the scope off, turn it on - the awg remains off and the selected waveform has changed to "DC".
Wanted features:
Decoding: Bitrate displaying and search function adding (last is really useful).
Further it would be nice when decoding of ir-codes (like RC-5, RECS80, NEC ir..) could be added - Afaik none scope got this and therefore it would be a unique feature to have on siglent scopes only.
-
Bug:
Power on state is partly setting to defaults instead of last used, example given:
When awg is active and a waveform selected, then turning the scope off, turn it on - the awg remains off and the selected waveform has changed to "DC".
Wanted features:
Decoding: Bitrate displaying and search function adding (last is really useful).
Further it would be nice when decoding of ir-codes (like RC-5, RECS80, NEC ir..) could be added - Afaik none scope got this and therefore it would be unique feature.
AWG should be in the OFF mode after reboot for safety reasons, but yes, other settings should not change.
-
Do any of the bugs and feature requests in this thread actually make their way to Siglent?
If not, what is the best route to use so that Bugs/Features do come to their attention?
-
AWG should be in the OFF mode after reboot for safety reasons.
Ah, ok..
But the bodeplot thing must be a bug ( activate bode, awg turns on (of course), but deactivate bode, awg remains on and the last channel settings bode used will remain, instead returning to last user settings).
-
Do any of the bugs and feature requests in this thread actually make their way to Siglent?
If not, what is the best route to use so that Bugs/Features do come to their attention?
Yep, Siglent, some of their beta testers and distributors have been members here for some years.
Members start these threads although issues could also be posted here:
https://www.eevblog.com/forum/testgear/siglent-technical-support-join-in-eevblog/ (https://www.eevblog.com/forum/testgear/siglent-technical-support-join-in-eevblog/)
-
:-+ Great.
-
Because of a boot failure I received an repair image for on an USB stick and are thus on a Alpha or Beta release of 1.3.5R6.
I noticed that the Table in the FFT function has a wrong header if "Show Delta" is on and "Show Frequency" is off.
See screen shot.
[attachimg=1]
Further I noticed that the Bode plot never stops it goes over and over and over again. I do not know if that is itended behaviour, but it doesn't do any averaging it just writes over the last bode plot, so I see no use of it, so why not stop after one parse. Further as many others have notices there are sometimes strange dips or peaks in the bode plot.
-
Beta release of 1.3.5R6.
Aha....they fixed the info boxes :D :-+
-
Further I noticed that the Bode plot never stops it goes over and over and over again. I do not know if that is itended behaviour, but it doesn't do any averaging it just writes over the last bode plot, so I see no use of it, so why not stop after one parse. Further as many others have notices there are sometimes strange dips or peaks in the bode plot.
I can see severe reasons...
And if you want one sweep, why not stop it after it have done it. Of course if there is severe reason users can ask if Siglent can some day implement also single sweep to BP. Perhaps useful in cases when sweep is very long time and user can go to coffee break and leave scope for finish sweep.
But there is lot of things when it need run continuously...
SFRA can seriously use example for adjusting, fine adjusting many kind of filters, example some receiver narrow IF filters etc etc. Some higher order filters can be quite complex to adjust. How you do it if it average or stop after one shot. It is better to leave your hands free for some times very sensitive and complex tuning work what you need fully concentrate and not interrupted for repetitive handle scope. It need sweep and repeat without interrupting.
AFAI Siglent is working for improve it but it is not of course in highest priority in any "need to do" list.. Some dips can also avoid if setup BP system so that it do not switch automatically between scope main voltage bands.
There is also old thread about SFRA but based to SDS1004X-E. Functionally not big basic differences in SDS2kXPlus. I think this BodePlot ( aka SFRA) thread is perhaps useful to read. (https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/msg2453655/#msg2453655)
I believe it is also doing internally some averaging (but not quite useless trace average). Together fact it is internally based to 3 frequency selective receiver(s) for DUT outputs so it have also lot of attenuation out of swept current frequency. It is quite complex system and Generator stepping control and receiver timing is bit critical. And receiver front have these voltage band selection relays. But also same time there is other things stepping. In some frequency points during wide sweeps it also switch receiver RBW. Just like example spectrum analyzer Resolution Band Width but not visible for user.
-
I can see the use, if you are adjusting things and keep your hands free.
In my case I just want the bode plot of an existing circuit as is. And the point is, often the first parse is oke and the chance of getting strange dips and peaks seems to increase with the iterations. So I want it to stop after a single parse and still be able to walk away and grab some tea.
I had it a few times that the start of the bode plot was oke, I went away to have a drink, because even a single sweep takes time and when I'm back it is busy with a 2nd or 3th iteration and I have a glitch at the start of the bode plot and I have to wait till some iteration that I have no glitch.
I only need a single sweep without a glitch. I will read your link, to see if there if I can find something to lower the chance of having a glitch. But to me an option to either stop after a single sweep or run it continuously seems a valid thing.
Further if I do a sweep in REW via a sound card the sweep takes 10-20 seconds, the same here will take considerably longer. I know REW can not scale up to higher frequencies (but the resolution is much higher), but still in the same range the difference in time is huge. But given the time it takes, it is normal to walk away from it.
-
I can see the use, if you are adjusting things and keep your hands free.
In my case I just want the bode plot of an existing circuit as is. And the point is, often the first parse is oke and the chance of getting strange dips and peaks seems to increase with the iterations. So I want it to stop after a single parse and still be able to walk away and grab some tea.
I had it a few times that the start of the bode plot was oke, I went away to have a drink, because even a single sweep takes time and when I'm back it is busy with a 2nd or 3th iteration and I have a glitch at the start of the bode plot and I have to wait till some iteration that I have no glitch.
I only need a single sweep without a glitch. I will read your link, to see if there if I can find something to lower the chance of having a glitch. But to me an option to either stop after a single sweep or run it continuously seems a valid thing.
Further if I do a sweep in REW via a sound card the sweep takes 10-20 seconds, the same here will take considerably longer. I know REW can not scale up to higher frequencies (but the resolution is much higher), but still in the same range the difference in time is huge. But given the time it takes, it is normal to walk away from it.
Have you looked if it switch voltage band during sweep and specially around where glitch exist.
Im thousands of km far away my workbench so I can not try anything. Also I do not remember all due to fact my memory best before date is expired. Previously I have suspected least some spikes are from scope front end Voltage band change (you can hear these relays).
I recommend least try shut off Channel Gain Auto and find and set suitable signal amplitude and scope V/div setting and run with Auto Gain off. Also afterwards vertical scales and position can change. ( all traces drawing are based to freq, amp, phase table where values can also exceed display vertical area) It produce data table when it sweep independent of your display settings what you use in runtime. Disclaimer: My all experience with Siglent SFRA is with SDS1x04X-E's.
(explanation and picture 3a in this msg tell bit more about this data table what it use for drawing.
https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/msg2453667/#msg2453667 (https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/msg2453667/#msg2453667)
-
I read true the thread you recommended and the plan was to try without the auto thing on. I heard indeed the relais, but I do not remember if those switching moments coincide with the dips or peaks, I will give it a try, but it seems logical that it can have such an effect.
Another thing to look at closely is the table. I put it on and it was populated. in successive runs the table part was on the screen, but no values were put in it while making the bode plot. I will pay more attention to this in the next measurements to see what is happening there, perhaps I must just put on a switch somewhere.
-
The table bug is real. I've reported it earlier already.
-
New bug:
Fail to load arb waveform files.. appears to be file mismanagement
cp /usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.bin /usr/bin/siglent/usr/usr/positive_pulseDC1000ppm.bin
cp: can't stat '/usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.bin': No such file or directory
rm -f /usr/bin/siglent/usr/usr/positive_pulseDC1000ppm.info
rm -f /usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.info
I/O warning : failed to load external entity "/usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.info"
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
-
Bug:
Same like using the bode plot, the power analyzing function won´t switch back to the prior user settings after deactivating.
-
Trigger Bug:
Signal on C1 has slow slope AND
C1 = DC Trigger Edge Alternating AND Measure (C1,V4, ...) active, C1 trigger only on rising Slope
C1 = DC Trigger Edge Alternating AND Measure (C1,V4, ...) AND Noise reject active, C1 trigger only on falling Slope
C1 = DC Trigger Edge Alternating AND Measure (C1,V4, ...) AND Zone on (Zone 1,2 off) active, C1 trigger on both Edge (alternating)
-
Bug:
Measures....
For example, the first 2 (simple mode) should displaying values from ch.1, you set it up, it will be displayed.
The next 2 should displaying values from say ch.2, you the choose value for 3 and then you change the channel - ALL values are now on the channel you´ve selected.
-
A couple of bugs noticed on software version 1.3.5R5:
AWG Noise generator periodic with previous Sine frequency
When using the noise output it is obviously a pseudorandom sample buffer that is repeated. However the repetition period depends upon the frequency of a previously selected Sine frequency. E.g. if a 1kHz Sine was previously output, the noise will be periodic with 1ms and will be visibly stepped due to too few samples being available. Or if a 1MHz Sine was previously output, the noise will be periodic with 1us and will be visibly undersampled and non-white due to not using the full 16k sample buffer. The optimum seems to be around 10kHz (125MS/s / 16kS = 7.8kHz) where the full noise buffer is used and therefore the noise is most "white".
Suggested solutions:
- Make noise generator true pseudorandom based on a mathematic generator instead of repeating a sample buffer (best solution).
- Introduce a "Noise period" setting to make this behaviour visible and not dependant on other generators. (Might be useful to increase periodicity for low frequency measurements.)
- Make periodicity fixed to optimum frequency where the full sample buffer is used and the noise is most "white"
Scope locks up when touch is disabled and confirmation is required
If disabling touch and pressing either "Auto Setup" or "Default" the scope locks up and reboot is required.
Suggested solutions:
- Make it possible to re-enable touch, even when a confirmation dialog is present.
- Make it possible to "Continue" or "Cancel" with button presses.
- Re-define the "Touch" button to something useful ;) (e.g. "Force trig", "AWG Single pulse" etc.)
Wishes for improvements:
Better AWG functionality
- Manually trigged arbitrary waveform (non-periodic). Preferably with a button (The "Touch" button is a candidate. Or the AWG button)
- Manually trigged pulses and pulse bursts. (e.g. 1-8 pulses with selective delay)
- Modulation. Minimum: Sine AM/FM etc. Preferred: Math based.
Improved Bode Analysis
- Faster Bode plots. It is very slow...
- Wider plot area. Why the big black borders?
- Amplitude Unit: Impedance. Showing the complex impedance of the DUT in series with a resistive load.
Hoping for making a great scope even better 8)
-
Latest firmware is V1.3.5R10
https://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS2000XP_1.3.5R10_EN.zip
Some reported bugs not addressed yet. :(
-
In the AWG you see only 6 digits after the separator (1.000 000 M) but you can enter 7 valid digits. (1.000 000 2 M e.g.)
Unfortunately I can not measure more. Here the valid digits should be shown.
For FFT it would be nice to have more F-digits in the Peak List when you use a small span (e.g. center 1 MHz, span 10 kHz.
Should be configurable, for frequency measurement as well.
-
In Analysis/Counter menu you can choose the channel to be measured.
But this works only with the triggered channel, not with the others.
-
New bug:
Fail to load arb waveform files.. appears to be file mismanagement
cp /usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.bin /usr/bin/siglent/usr/usr/positive_pulseDC1000ppm.bin
cp: can't stat '/usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.bin': No such file or directory
rm -f /usr/bin/siglent/usr/usr/positive_pulseDC1000ppm.info
rm -f /usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.info
I/O warning : failed to load external entity "/usr/bin/siglent/usr/mass_storage/U-disk0/positive_pulseDC1000ppm.info"
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
I/O error : Read-only file system
Once the issue will be fixed in a new FW release, it would be nice if the interpolation mode could be made selectable between Linear (the actual / default)
and 0-order hold.
-
Improved Bode Analysis
- Faster Bode plots. It is very slow...
Do you want more crap BP.
This performance is very difficult to do faster with this working principle.
There is many things... Nearly all speeding costs performance.
I believe you have noted that if you reduce whole available dynamic range, if you do not need, works bit more fast than in default mode. Turn ALC off and it give bit more speed. But then result is less available dynamic range. And in this mode you need manually find right SFRA receiver (Scope input channel where come signal from DUT) input level setting. With external generator of course reference channel is perhaps from generator other channel what is tracking other channel. I have not used BodePlot II with SDS2kXplus but other Siglent model. Also there is some thread here in forum what handle basics of BodePlot II. (today we can just talk BodePlot because version 1 is far behind in history even when it still exist in some older reviews like waste in ocean.
If understand more how this Siglent BP works then less can wonder how slow it is.
First part is understand that in this mode it is not working at all like oscilloscope even it uses oscilloscope HW.
Level and phase. Level is measured using selective receiver with frequency proportional adjusted RBW (resolution band width) and this receiver sweeps synchronized with generator what is step sweeping controlled by BodePlot. Every single time it step to new frequency point it need start from beginning to find right level and measure it. And all max three receiver channel need do it simultaneously and individually. Sequential individual steps may have even lot over 100dB difference. Receiver may just set and listen under 500uv signal and then next step it may be even 10V/div. Every step need do automatic level control and there is no predict what is next step value. Also during sweep it listen only narrow frequency band just like radio receiver but without being radio, not like oscilloscope xt mode listen whole wide band.
Now, specially lower frequencies. For take enough long capture for do FFT for this frequency everyone understand it takes time. And this time it take also in next step... every step. It need capture enough data for FFT. Also as have seen during wide freq span sweep during sweep it change samplerate. There is lot of things and finally then designer make some compromise between time and performance.
If someone build different HW it can be superfast depending its working principle. But there is now this HW and it need do good performance with it. In every single step it need do or be readu to do lot of things.
So, how long it take sample 10Hz for get enough data for phase and for level. Absolute minimum is 100ms. If we can do optimal trig and do not need anything but exactly one full cycle. How you know in real time you have get full true cycle. In practice you need capture bit more. Then measure it. Then ask generator do next frequency, wait bit and after then capture again now example 10.02Hz.. again over 100ms. If we have these kind of steps 500 like is max in BP. It is alone 50 second. And as told there is also other things like take more samples what is ideally in theory enough. So we are easy near or around 100s class. Just for do simple linear BP from 10Hz to 20Hz. (these numberas are now imagined because I have not possible now do any tests, checks.
I do not know but when I have looked some dynamic performance down to very low signals it looks also nearly clear that get one bode plot result data pair it perhaps do some other things than just one time capture this step signal. Perhaps it also do some averaging or something... least in SDS1000X-E
Yes, some speed is perhaps possible but I believe quite marginally until reduce performance with hard hand.
It is easy to think BodePlot is some simple small thing. It is not - except if someone do just crap checkbox feature for shamelessly print on shining sales brochures.
No one must push Siglent to reduce this BP dynamic or other performace. Even they can add some more slow enhanced performance mode for get more deep dynamics and accuracy.
[/list]
-
Improved Bode Analysis
- Faster Bode plots. It is very slow...
Do you want more crap BP.
Agree, it's (BP) much to slow, not practical for lab work. However, it's a scope and not a do-it-all instrument.
It's fun to play with tho, and maybe useful for introductory educational purposes like showing different filter types (LP, HP, BP), or showing SRF of large capacitors.
The implementation is fine and it works nicely with the internal or external (SDG 2042X) AWG, it's just too slow.
Anyway, Siglent might will consider improving the BP speed, maybe improved algorithms and/or hardware in future scopes.
Best
-
Improved Bode Analysis
- Faster Bode plots. It is very slow...
Do you want more crap BP.
Agree, it's (BP) much to slow, not practical for lab work. However, it's a scope and not a do-it-all instrument.
Yes. But it also depends what things user is doing with it. Of course it is still not at all dedicated SFRA isntrument like was example R&S SWOB etc.
But also, it is not totally hopeless if example look and adjust IF typical radio IF filter. Sweeping example 450kHz to 460kHz is not hopeless slow in practice. Or if need select xtals for nth order DIY pass band filter.
It is quite seriously made if look what kind of BP some others have done in this kind on price class scopes.
For random use and for some hobbyist it can still do lot. It is not toy.
It is slow and if it can some amount speed it is, imho, quite marginal amount exept if Siglent add there fast mode with reduced performance just as they can in theory also add more slow mode for even better performance. If we need do some filter work problem with dynamics is that there is not usable whole range. Duo to fact that filter need drive using some specified level. If level is example 0dBm then dynamic range ends quite soon when goes to example good IF filter stop band where -60dBc or -70dBc is nearly nothing... and tools for least -110...-120dBc are "bit different" than low price oscilloscope BP.
But still first time I see Siglent Bode Plot version II it must say I was bit amazed this performance. They have done it seriously. Even when some things can improve and correct and need some finishing etc.
-
Even when some things can improve and correct and need some finishing etc.
Like turning off the internal AWG and returning to the user-settings of the channels after use.
-
But still first time I see Siglent Bode Plot version II it must say I was bit amazed this performance. They have done it seriously. Even when some things can improve and correct and need some finishing etc.
Yes the BP implementation is impressive if you discount the speed. I think the concept of dynamically changing the 2nd channel gain to achieve better dynamic range is a clever and useful. For certain uses, like a narrow band filter you mention, the speed is probably acceptable, but not for general purpose use.
I have no serious criticisms of this DSO, or we should call data acquisition system. It's quite an instrument for the price, so hat's off to the Siglent design team :-+
Here's an example of the Open Loop Bode Plot simulation of a complex electro-mechanical piezo element Closed Loop control system capable of nanometer level positioning I've developed. I included tap-in points in the control PCB to allow Bode Plots, so may give this a try sometime when I have some available time.
The system works beautifully and behaves as simulated, and uses bearings that have no mechanical noise, no backlash, no stiction, nor moving mechanical surfaces (Flexures).
Here's the PCB and Piezo Stage (Physik Instrumente P601K), simulated Open Loop Bode Plot, and simulated Closed Loop step response, and Closed Loop Bode Plot.
Best,
-
Here's a couple Bode Plots of a simple RC Low Pass and High Pass filter (R =1K, C=0.01uF) using the SDG2042X AWG "enabled" to 120MHz. These are the correct responses and even show the series resonance (~6.4MHz in LP) of the leaded capacitor (L ~ 62nH) in the setup, very nice displays IMO.
However, this took awhile to do, much longer than I would tolerate in a lab where my time was valued, I'm retired now, so time is cheap :-\
One thing I noted while making these plots is it's difficult to get the SDS2042X Plus to recognize the Print button.
Best,
[attachimg=1][attachimg=2]
-
I'm retired now, so time is cheap
And I´m using it at home, so the was time cheap also... 8)
Nevertheless, of course it could getting faster - As long as nothing else will be affected in a negative way.
Better slow and cool as fast and "crap".
-
Here's a couple Bode Plots of a simple RC Low Pass and High Pass filter ...
However, this took awhile to do, much longer than I would tolerate in a lab where my time was valued,...
Yes it takes time.
There is freq scale log and start from 10Hz to 120MHz.
I do not remember how long it takes and also I can not see what amount of data points you have used, if max 500 it takes time.
As we can see it use lot of time in inder 1kHz specially long time between 10Hz to 100Hz.
I have many times thinking, is it always necessary to use so much time there in low freq, how important this resolution is in these cases around 10Hz. What are freq steps there.
If user can define resolution steps it can perhaps do lot of faster. Yes user can set amount of steps but not how it is shared over sweep span.
Reason, explanation, for long time can see in these two images. Thinking this it can ask how much can ask more fast BodePlot.
One image can see current step is bit over 1kHz.
What more it tell: 10 bits, 1Mpts, 10ms/div, 10Msa/s.
Sampling itself one shot for this one individual BP data takes 100ms. time
Then other image tell bit more
Perhaps this is sweep starting point.
50ms/div, 1Mpts, 2Msa/s.
Sampling itself one shot for this one individual BP data takes 500ms. time
And this sampling alone is not whole time what one step take. There need wait generator after command, then fill pretrig buffer and wait trig. Look level and do front end level ajustment (if ALC is on) if need and start processing for result and after all is ready then command Generator to do next step.
But, is it optimal for time. Perhaps I do not need lot of datapoints between some very low frequencies but still want more resolution on other part of whole sweep.
1MHz datapoint is muck more fast to do than 10Hz data point.
Selecting between log and lin sweep is also question. Some times lin is technoically ok but user select log because.... eyes like. Some toimes I have thinked that perhaps in some cases is more wise to do linear sweep and then afterwards change it to log scale.
It need ask, do I need same amount of BP data points between 10-100Hz as I need between 10MHz to 100MHz. If user have freedom to set how steps are shared over sweep he can optimize sweep time perhaps better for just his need in one test.
Here in image I can see is used Ch1 for reference and CH2 for DUT out. These BP what I have tested, user have full freedom to select reference channels and select also what receive signal from DUT.
In some cases it is useful to select other than manufacturer set default.
Example user can select Ch1 for reference and then Ch3 for DUT out. In this case both channels use different ADC so both can use max interleaved speed. But also there can be other reasons for select... example one like more yellow or green BP then he can select Ch2 as reference channel. And if DUT have one or two or even three outputs then select input channels as like set colors for these.
Always in these cases need care that reference channel timing is perfect related to DUT out channels so that phase have even some meaning. Phase accuracy is... not easy case at all when we go out from "audio" freq range. There need calibrate cables and channels time difference and if work with generator 2 channel mode, one for ref and one for DUT in, also need care generator phase error.
One channel mode is other way difficult when we go out from "audio" LF freq range. Signal split to Ref and DUT need do right way and then also care phase calibration using right kind of dummy thru in place of DUT.
But, we have programmable level figure for sweep span in BP (during sweep it follow user defined level table), why we can not have programmable step interval where user can define how many steps it use in user defined slices in whole sweep. Yes it is not easy... but with this user can do some optimize for sweep time just for his need in some test case. He can put more fine steps in important positions and then less to some other positions.
Did you really need 50 data points between 10 and 100Hz. (if 500 was in use)
But perhaps 50 is not even enough between 10 to 100MHz in some cases.
It is also good to remember, what ever it plot to screen real base to all is the Table what BP produce. Display is just only post image from The Table and example if user select manually scale so that part of bode is lot of out from display still all is there in The Table what can then later display moving display position in table or changing displayed scale.
BP is whole "machine" other than oscilloscope and before is fully familiar with it, it need work, it need lot of work for find all things built in.
It was one evening when I do some work with this BP II (other scope model)
Then hit some produced some harmonics etc in DUT.
I have measured DUT out level with HP Power meter quite accurately and in separate freq points.
Then I look Siglent BodePlot and think what a crap shit they have done... lot of errors related my measurements with instruments what are enough reliable way checked they are in specs.
Thank god I have SA. With SA I look this DUT out in same setup used with BP.
SA show nicely this test signal from DUT output. But what... also its level is totally off. After some seconds SA was tuned to wide span and it was clear that reason or other my DUT produce totally high amount of harmonics and non harmonics. Game over, this was clear. Of course know that power meter used is wide band.
Then like child I think all my old "bode plots" in my life and with various methods using analog scopes etc...
Why this Siglent bode plot did not see whole level but it see nearly like SA see this test carrier level out from DUT. But is is oscilloscope BodePlot....
Well, inside some minutes I know this BodePlot is frequency selective. It listen only frequency what he have ask generator send. Yes of course it is not very narrow resolution band width. Later investigations also show that RBW is not fixed. It depends frequency. It have several width steps.
I have been tens of years fan for reading HP Journals (until "Lady Agilent" destroy HP) and I have been in situation where I have get these for read also when I was young.
If this BP is made by old HP in history there is perhaps very deep explanation how it works and what is inside it, how it produce final data from signals, including least bloc level working principle and math how it compute result etc etc and something about how it set default parameters and so on.
From Siglent. Just (nearly) Nothing.
Information level nearly like image where see button and in image can see it is labeled "Start" and then perfect User Reference Manual tell.. Push this for start.
Example for some lab (hobby or what ever) use it is important to know in some cases how this BP do. Example some knowledge about this frequency selectivity, even least tell it is.
Because DUT can be lot of more than just passive RLC circuit and if dut generate something during sweep there is not any indication about it. It is good that user know that this BP is swept tuned freq selective.
Now it is in level "Use if you like it and try find how it works"
Long time ago R&S SWOB have whole manual about theory and practice with all details and not even this level how HP explain they instruments. Yes they was expensive but it need remember volumes...
today instruments are low price but it can not explain why manuals and information is so poor.. because now also volumes are much higher so price of good and deep manuals etc is funded from more small sources but bit it looks more like "who cares" state than price is reason. Of course one reason is this continuous new products and hurry to push unfinished products to markets. No one can then keep manuals updated specially if manuals are very deep even with theory paragraphs deeply integrated with used FW and circuits.
-
rf-loop
FYI I have been emailing mawyatt and told him to have a study of your great investigations of SDS1104X-E BP II:
https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/ (https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/)
Also, slowing his BP result is that he only has SDS2102X Plus as the 4ch models were on BO when he needed one so he has no ability to assign BP channels to the other ADC.
-
Also, slowing his BP result is that he only has SDS2102X Plus as the 4ch models were on BO when he needed one so he has no ability to assign BP channels to the other ADC.
I stand corrected. :)
-
rf-loop,
But, we have programmable level figure for sweep span in BP (during sweep it follow user defined level table), why we can not have programmable step interval where user can define how many steps it use in user defined slices in whole sweep. Yes it is not easy... but with this user can do some optimize for sweep time just for his need in some test case. He can put more fine steps in important positions and then less to some other positions.
A user defined "Resolution Table" should help, so one can "put the emphasis" where it's needed. Some defaults within the table (under decade sweep) could be "period related" where the number of points is related to the waveform period within the decade span, and within a user specified Capture time per decade. The number of sample points within the decade would be X*(Capture time per decade)/(Period Ref per decade + compute time), where X is a scaling factor.
For example, the 10-100Hz decade would have a "period reference of 1/10" and with a specified Capture Time per decade of say 2 seconds (could be user defined or default) and a compute time of 0.1 seconds then the number of samples taken in 10-100Hz would be 10. For 100-1K decade it would be 18, for 1K-100K 20 and so on. Note the upper limit is set by the compute time as max number of samples per decade is Capture Time per decade/Compute Time. X could be simple linear scaled or power scaled (X, X^2, X^3).
Anyway, lots of options and variations on this theme possible.
Regarding the old HP, yes they were destroyed by the Agilent split. Those days HP and Tektronix equipment and manuals were engineering masterpieces, both have now fallen to the short term management mentality designed to put $ in the pockets of the executives and shareholders at the expense of long term viability.
Keysight may have a chance to recover some of the old HP magic in certain areas, it will take time tho. I recall at the IEEE MTT conference in ~2009 a Keysight VP discussing a new AWG chip they had developed, they set up a demo for me. I was blown away by the performance, up to 16GSPS, well over 90dBc SFDR, and a 1KHz offset of -168dBm phase noise at 1GHz with a 0dBm signal reference!! And this from a DDS based signal which can frequency hop anywhere within the output frequency range within a single waveform cycle. Talk about a frequency agile ultra low noise LO source for a fast frequency hopping narrow band receiver/transmitter for all sorts of applications ::), now you know where they got the idea ;) The core AWG chip is called Griffin (mythological creature), I have a couple chips from ~10 years ago and have taken ultra-high resolution images for them (proprietary). Here's an extremely low resolution small crop of the creature "Griffin" from the very large Griffin chip, the solder balls are ~40um in diameter I recall. Another chip was in development with even better performance.
So maybe Keysight can recover this old HP magic is certain instrument areas, but I never considered them to lead in the scope arena, that was the old Tektronix grounds. If you are of my age you may remember the remarkable Tektronix 1GHz real time scope from 1969, it took HP almost 20 years to duplicate that scope's performance!!
However, I don't expect we'll see the wonderful old manuals from those days, just a PDF Operating Manual is all that seems to be available, and maybe a Service Manual that basically says replace the PCB :P
Best,
-
rf-loop
FYI I have been emailing mawyatt and told him to have a study of your great investigations of SDS1104X-E BP II:
https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/ (https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/)
Also, slowing his BP result is that he only has SDS2102X Plus as the 4ch models were on BO when he needed one so he has no ability to assign BP channels to the other ADC.
I need to spend some reviewing this, looks quite interesting.
Obviously lots of effort from rf-loop went into measuring and compiling all this on the Bode Plot II. :-+
Maybe Siglent might consider using this as a baseline for a Bode Plot II App note??
Best,
-
Also, slowing his BP result is that he only has SDS2102X Plus as the 4ch models were on BO when he needed one so he has no ability to assign BP channels to the other ADC.
I stand corrected. :)
Yeah I needed the DSO to do some work on an advanced Piezo Electric controller I'd developed, it's going to be used in a university research project, so had to "settle" for the 2 channel version, maybe Siglent will let me trade it in on the 4 channel SDS2104X Plus when they are in stock ::) Think my chances are somewhat akin to a "Snowballs chance is a very hot place >:D ".
Anyway, I can't say enough good things about this DSO and want to thank everyone on here, especially Rob at tautech for pointing out Siglent and the SDS2104X Plus :-+
Best,
-
Also, slowing his BP result is that he only has SDS2102X Plus as the 4ch models were on BO when he needed one so he has no ability to assign BP channels to the other ADC.
I stand corrected. :)
Yeah I needed the DSO to do some work on an advanced Piezo Electric controller I'd developed, it's going to be used in a university research project, so had to "settle" for the 2 channel version, maybe Siglent will let me trade it in on the 4 channel SDS2104X Plus when they are in stock ::) Think my chances are somewhat akin to a "Snowballs chance is a very hot place >:D ".
Anyway, I can't say enough good things about this DSO and want to thank everyone on here, especially Rob at tautech for pointing out Siglent and the SDS2104X Plus :-+
Best,
If they are wise, perhaps they can least give some nice opportunity for you for some kind of nice deal....least I hope.
-
Also, slowing his BP result is that he only has SDS2102X Plus as the 4ch models were on BO when he needed one so he has no ability to assign BP channels to the other ADC.
I stand corrected. :)
Yeah I needed the DSO to do some work on an advanced Piezo Electric controller I'd developed, it's going to be used in a university research project, so had to "settle" for the 2 channel version, maybe Siglent will let me trade it in on the 4 channel SDS2104X Plus when they are in stock ::) Think my chances are somewhat akin to a "Snowballs chance is a very hot place >:D ".
Anyway, I can't say enough good things about this DSO and want to thank everyone on here, especially Rob at tautech for pointing out Siglent and the SDS2104X Plus :-+
Best,
If they are wise, perhaps they can least give some nice opportunity for you for some kind of nice deal....least I hope.
Saelig supplied mawyatt's equipment so let's hope they might have another home for his SDS2102X Plus when he is ready for an upgrade. :)
-
BUG REPORT: If readout probes are connected when powering on, probe readout function only works once on boot. Subsequent disconnects and connects don't register
SD2104X Plus firmware 1.3.5R10
Cal Test CT3288ARA/P6501R probe; my readout pin measures 10.7K to BNC shield.
If I power up with the probe with readout pin connected to any channel on boot I see: "Probe detected: channel x", where x is correct channel. Probe disconnecting and reconnecting never again yields a probe detect message on any of the channels (not just the channel that had the probe attached to start with).
If I power up without any probes connected, then the "probe detected: channel x" and "probe disconnected: channel x" messages all work as you'd expect; every time you connect or disconnect a probe the message appears.
So it seems that if you have a readout-enabled probe connected at boot that the readout only ever works that first time during the boot process and is dead ever after. @Tautech confirmed the same behaviour.
This seems like it must be a bug.
-
Maybe a bug, maybe something one simply should not do
When the resolution is set to 10 bit, serial decoding fails.
Edit: It might be that the issue is also related to a menu vs. actual setting inconsistence. Using the same test set-up again and deliberately adjusting the threshold for SCL and SDA again, there is not difference between 8 and 10 bit mode. I can however set the threshold for SDA to an value, where 8 bit decodes fine, but 10 bit not. That value is here about 2.5V.
-
Interesting, I'll recreate this later in the evening with my STB-3 board.
-
I should add: sds2104x+, Firmware 1.3.5R10
Here an example of a wrong decode. The trigger on address 0x28 works right, and the decoded information should be: Address 0x28 read, first data byte 0x20
-
sds2104x+, Firmware 1.3.5R10
topic: unwieldy settings setup of trigger mode parameters
In all trigger modes which requuire the entry of levels, two menus have to be openened separately:
a) the trigger menu, b) a little window for the vertical levels.
This seems confusing to me, and in fact it required some time to find the level settings window (I had to read the instructions). It would be consistent to have all settings for a certain trigger mode in one dialog element.
Note: I recall faintly that there was a level setting in the trigger menu with the previous firmware 1.3.5R7.
-
SPI Decode Issue (or idiosyncrasy):
Hoping this is on the user side of the screen, as they say....
I can only get a reliable SPI decode when the timescale is above a particular threshold (appears decode-size dependent).
I need to be >=100uS/div (for 8 ,16 bit) and >=200uS/div (for 32-bit) for reliable decoding.
Configuration:
SDS2104X Plus
Firmware 1.3.5R10
8-bit (or 10-bit) Vertical Scale mode
CS, CLK, MOSI thresholds all set to 2.0V (MISO inactive)
Analog channels used for inputs
CLK rising edge, CS active low
Signals driven directly from Total Phase SPI generator (no PCB or other circuits involved)
Issue repeated with:
8-bit, 16-bit, and 32-bit messages
Every possible acquisition length
Both SPI triggering and edge triggering (on CS)
Failure always occurs on last nibble or byte.
Also appears to fail with odd values and not even values.
It is not intermittent. It either works every time or fails every time, based on timescale.
The only valid decodes are with such large timescales that the signals are visually impossible to recognize.
My inexpensive "brand" name scope at work does not have this decode limitation.
Now, if this is really the scope (and not me), maybe somebody could explain the technical reason why this is so.
It is very counter-intuitive actually. I would expect more horizontal resolution to equate to a better measurement.
Most definitely (at least vertically), I've seen more accurate automatic voltage measurements with greater vertical resolution (on other 'scopes anyway).
Maybe the worst aspect of this "issue?" is that the scope does not alert one of the bad data. If it is simply a function of timescale, then the firmware should not present any data at all - which would just serve to mislead the user. It should display a message that decoding is not possible at the current resolution (or something to that effect).
This is not for a hobby and I'm terrified of taking bad data for a customer.
I've attached good and bad plots at 8, 16, and 32-bit decodes (those ending in "00" are bad).
Just look at the last byte decoded in each - and look at the timescale.
Anybody else see this? Please tell me this is not normal operation and that I have a setting incorrect.
I don't see any mention in the user manual of timescale dependent decoding (but I may have overlooked it - in which case my apologies for posting).
-
Same scope type & firmware version.
I can confirm that I get no decoding wit a timebase < 200µs/div. What I did not see are error in the last byte. I tested with a BME680 sensor, at which due to sampling noise the value of the last byte varies, so I have odd and even numbers.
It triggers fine on e.g. MOSI data, but it shows not the decoded data. If I capture at say 200µs/div and then expand the view to lets say 50µs/div, the data is shown fine.
It's independent from the aquisition memory size. And decodes well both in 8 and 10 bit mode.
If it decodes data, I can expand it in the zoom window, and that works most of the time.
-
It seems it depends on the CS transition to be in the capture window. If that is given, I can go to smaller time base values, like 50µs/div shown below.
Edit: Using clk-timeout as CS, I can go beyond that limit. See the second screen shot.
Edit2: Nevertheless, it looks as if the oscilloscope is not the preferred instrument for logic protocols. That's more the job for a logic analyzer. Even a 10 USD Saleae clone is easier to use, left alone the size of the probes.
-
I just recieved this scope and am checking out its features (still learnng) but I wanted to check whether this is a bug or a fault [attachimg=2]. I get large gliches on channels 1 and 2 when i use 10 bit mode (channels 3 and 4 doesn't seem to suffer). It's fine in 8 bit mode and I've looked and it does iindeed increase the resolution (based on zooming in as discribed in another part of this forum (which is awesome. by the way)). The rise time also seems slow and suggests a 100kHz (not 100MHz) BW but I guess that is just the scope probe test waveform.
[attach=1][attachimg=4]
(I seem to be having problems attaching images and can't get a preview so appologies if these images are rubbish (I'm new to this forum).
SW is 1.3.5R7 so maybe I been to update?
-
The spikes should not be there. It looks like a fault. The 1KHz probe calibration output has a slow rise/fall time. You can use the AWG for faster signals. You should have a 30 days test period with a new device.
b.t.w.: Which firmware version is installed? I do not expect the spikes to be firmware related, but the information might help. You get that via Utility->System Setting->System Status.
-
10-bit mode is a software enhancement, so if it is working in 8-bit mode, it should be bug in the firmware, but I did not see anyone reporting a similar effect...
or it could be a bad chunk of memory that is used in 10-bit mode filtering
-
Thanks for the rapid response. FW is 1.3.5R7.
I guessed it was probably a fault as it only affects Ch1 and 2.
I tries the AWG and the TC now looks more like 30ns.
I guess I'll have to send it back :(
-
Maybe I should try updating the firmware first?
I couldn't find any reference to 1.3.5R7 (only R5 amd R10) so maybe nobody else uses it (so might be an unreported bug)? Upgrading FW won't invalidate any warranty (in the UK) will it?
-
I had version 1.3.5R7 initially too, but not such spikes. But updating the FW should not hurt.
-
Thanks for the rapid response. FW is 1.3.5R7.
I guessed it was probably a fault as it only affects Ch1 and 2.
I tries the AWG and the TC now looks more like 30ns.
I guess I'll have to send it back :(
Yes, it looks like a faulty unit
-
Upgrading the FW to R10 made no difference. still faulty :(
-
Last resort: try running a self calibration. But I don't expect it to help much.
-
Upgrading the FW to R10 made no difference. still faulty :(
Don't discount it could be local RFI.
Seen this before with other new Siglent DSO's and customers have contacted me believing their scope was faulty.
10 bit res will only exacerbate the problem.
Try a BNC cable connection for better shielding to the AWG and see if the spikes are still present at the same amplitude and if they are start turning OFF any possible local RFI sources. Anything SMPS based should be considered prime candidates as the culprit. Even LED ceiling downlights can be an issue or a phone charger in another room.
Happy hunting Sherlock ! :)
-
Upgrading the FW to R10 made no difference. still faulty :(
Don't discount it could be local RFI.
The poster changed to CH3/4, where he did not see the issue. Still he could have changed something else in between.
-
If this would be RFI, the spikes would appear centered around the trace, which they are not.
If you have an other scope check the calibration signal....
Almost sure a faulty unit, I had similar faults on a Rigol DS2000.
-
SDS2104x+, 1.3.5R10
Continued my testing with UART decoding. As with SPI it is very inconvenient, that for a serial trigger all settings (RX, TX, baud rate, ..) has to be repeated. But that may be unavoidable, since trigger is independent from decoding.(yes: copy to trigger!)
What seems strange is the display of the decoded data. if:
- some decoded data is displayed and
- then a new event captures new data
a) The decoded date shown is erratic. It shows some unrelated decoding. b) if I move the horizontal position, decoding disappears, until c) I push the trigger setup and then the decode button again. see the three screenshots for the three steps.
This looks like a bug.
Edit: At step c) pushing a channel button also forces the display of decoded data
-
Upgrading the FW to R10 made no difference. still faulty :(
Don't discount it could be local RFI.
The poster changed to CH3/4, where he did not see the issue. Still he could have changed something else in between.
Yes exactly and as Kev has just got this scope he is still finding his way around it.
When in doubt press the Default button and reset the scope then if the problem persists investigate why.
Sometimes the probes reference lead forms the perfect RF loop and it need be removed to check it has no influence on the displayed waveform....easy if only connected to the 1 KHz probe compensation output.
Screenshots to USB using the Print button with menus visible are required to see what settings might be can always help us.
-
roberthh
Look at your trigger positions WRT the zoom window.
Align these and I believe your results will be better.
Hint
Press the H Pos control to set trigger to 0s
-
roberthh
Look at your trigger positions WRT the zoom window.
Align these and I believe your results will be better.
Hint
Press the H Pos control to set trigger to 0s
Kind of. After triggering, it shows indeed the data at the trigger position. If the Zoom window is at the trigger position, not only the zero position, the trigger data point is indeed at the trigger point, but it does very often not match the signal pattern. And when I move the zoom window, the decoded data completely disappears. Until I push for instance a channel button.
Below is a screen shot immediately after the trigger. Trigger point is at 0 for both windows. The trigger is at the trigger data (0x34), but the decoded data and the trace do not match. Therefore is added the cursors. It shows that the trace data block is 22 characters (115200 baud, 8 + 1+ 1 bit), the decoded data string has 17 bytes.
I can't help but for me this inconsistency in display is at least confusing.
-
roberthh
Look at your trigger positions WRT the zoom window.
Align these and I believe your results will be better.
Hint
Press the H Pos control to set trigger to 0s
Kind of. After triggering, it shows indeed the data at the trigger position. If the Zoom window is at the trigger position, not only the zero position, the trigger data point is indeed at the trigger point, but it does very often not match the signal pattern. And when I move the zoom window, the decoded data completely disappears. Until I push for instance a channel button.
Below is a screen shot immediately after the trigger. Trigger point is at 0 for both windows. The trigger is at the trigger data (0x34), but the decoded data and the trace do not match. Therefore is added the cursors. It shows that the trace data block is 22 characters (115200 baud, 8 + 1+ 1 bit), the decoded data string has 17 bytes.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1086608)
I can't help but for me this inconsistency in display is at least confusing.
Much better. :)
See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.
-
See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.
Not really. The data it triggers on is not at the start of the packet. And the data at the trigger point there is indeed the intended data. But the trace and the decoded data do not match. It's just that the final screen update of the decoded data is missing. As soon as I expand the zoom or push e.g. a track button, the decoded data is updated and displayed fine. Another example below.
-
See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.
Not really. The data it triggers on is not at the start of the packet. And the data at the trigger point there is indeed the intended data. But the trace and the decoded data do not match. It's just that the final screen update of the decoded data is missing. As soon as I expand the zoom or push e.g. a track button, the decoded data is updated and displayed fine. Another example below.
what is the value of decoding threshold?
-
I should say that I consider this a good scope. The core feature, handling analog data, looks flawless. What we are discussing here are the "extra" features and GUI aspects. Not that these should not work, but the most important task for an oscilloscope is visualizing analog data.
-
what is the value of decoding threshold?
The test device runs at 3.3V. The decoding threshold is set to ~1.6 V, right in the middle. And that's not the problem, because the data is decoded properly, once the decoded data and the trace align. And the trigger is also always at the right place.
-
I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)
Here is how to replicate - it's very simple.
Get some data in the result list (the number of visible lines from 2 to 7 set up does not matter).
Use the down arrow (or drag the scroll handle) at right side of result list to obscure item #1.
Now, it is not possible via the up arrow or the handle to make the 1st item in the list appear again.
items 2-8 can be seen via scrolling, however.
To see item #1 appear again:
Press "Decode" hard button
Press "Result List" on spring up menu
Press/highlight "Scroll" box
Turn universal knob to scroll thru the list (which will show item #1 if you scroll all the way up).
-OR- (and this is strange)
While holding down the up arrow with one finger, press the Zoom hard button.
This also will expose the 1st item.
That is just plain ridiculous of course.
So the most reasonable workaround is to always leave the DECODE LIST soft menu up while decoding so you can scroll up down as needed. But of course that chews up real precious real estate (~15% of screen - I measured)
I've attached photos of the bug with 3 decode lines set up.
In one picture I'm holding down the up arrow but can't go higher than item #2.
In the other picture I've utilized the DECODE LIST menu to bring the scroll focus to the universal knob.
I'm sure there are those who will say "just use the zoom feature to get your decodes and forget the list".
What's the point of the list, then?
Besides, for the work I need to perform, I only have a handful of commands sent at a time.
It is *much* easier to read a list then to zoom in and scroll around (especially with the weak rotational velocity performance on the zoom horiz. roll).
Also, considering how the decoding performs best with large timescales (timebases), the values are not legible directly (since octagons are too small at large timescales).
Again, my apologies if this has been posted before.
Seems like a very simple fix for Siglent.
-
See where H Pos pointer in unzoomed window is after the start of the packet which is consistent with the UART trigger setting. If the selected UART trigger bit doesn't match the zoom window H Pos trigger position bit then indeed it is a bug. Magnify the zoomed window further for confirmation of the result.
Not really. The data it triggers on is not at the start of the packet. And the data at the trigger point there is indeed the intended data. But the trace and the decoded data do not match. It's just that the final screen update of the decoded data is missing. As soon as I expand the zoom or push e.g. a track button, the decoded data is updated and displayed fine. Another example below.
STOP it first and then magnify to check the trigger bit setting matches the displayed bit. They should match.
TK found a decode bug in the X-E where the trigger setting did not match the displayed bit.
This might be the same bug IDK yet. :popcorn:
-
It seems it depends on the CS transition to be in the capture window. If that is given, I can go to smaller time base values, like 50µs/div shown below.
Edit: Using clk-timeout as CS, I can go beyond that limit. See the second screen shot.
Edit2: Nevertheless, it looks as if the oscilloscope is not the preferred instrument for logic protocols. That's more the job for a logic analyzer. Even a 10 USD Saleae clone is easier to use, left alone the size of the probes.
Thank you roberthh for also looking at this.
For what it is worth:
I repeated my test with CS transition low and high both on the screen.
Also tried with CLK Timeout as CS Type.
Set the timebase to 50us/div.
Still got the same decode error.
It the attached picture, the last bytes (line 7 in list) should be "EEFF", not "EE00".
Oh well. This is just a feature I will not be able to use until firmware is corrected. It simply can't be trusted.
-
Ya'll find them bugs now.
I got my 2352X-E on the way...
Cmon guys... Find those bugs. :-+
And let Tautech know.... Bugs are bad ! >:(
-
STOP it first and then magnify to check the trigger bit setting matches the displayed bit. They should match.
I agree that you can do something after acquiring like pushing STOP to make the screen consistent. But my expectation was, that the screen IS consistent when a measurement has done. I made a short python script which produces the error. It runs here on a ESP32 with micropython, but that may not be mandatory. The trigger is set to serial trigger on the data value 0x34 (Ascii letter 4), Normal trigger mode. The mismatch does not happen on every combination of timebase and Mem Depth. Some suitable settings:
Timebase Mem Depth
5 ms/div 20M
2 ms/div 20M
10 ms/div 2M
Here's the script
import sys
import time
import random
nmsg = "1234" + "abcdefghijklmnopqrstuvwxyz"*2
nlen = len(nmsg)
def run():
while True:
ch = sys.stdin.read(1)
if ch == "q":
break
for i in range(20):
print(nmsg[:random.randint(0, nlen)])
time.sleep(0.005)
for i in range(10):
print("1234567890")
time.sleep(0.005)
run()
-
I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)
I'll repeat that for the SPI. On UART decode I do not see this phenomenon.
About the previous not on decodinge the last byte wrong:
a) At which level did you set the decoding of the MISO line? It should be about Level/2.
b) I see that the MISO and MOSI line start floating after the message. Did you try to pull them up or down to have them fast at a well defined level?
-
Just to round off the story of my glitch "problem", they seem to be single pixel wide and if i try and zoom in on them they don't exist (or at least they move around to a different position. My conclusion it that they are not ADC or front end sampling errors (so not a fault as such) and are somehow related to a bug in graphical interface (yellow and Magenta?) or the 10 bit interpolator (but that's strange because it only affects Ch1 and 2). If I change from vector to dot mode they are no longer noticable (so not distracting) so I can live with that. I wonder if it is a SW bug and nobody else has experienced it because you all use dot mode (I read in another thread that it is preferred). Below are some pictures with persistance turned on in vector and then dot mode, and you can see it is only on ch1 and ch2 and the magnitude seems to be a function of the voltage on the channel. Interestig but not a real problem I now think. Maybe its a brand new feature only on the very latest scopes which is why nobody else has seen it (or maybe I'm just too fussy :)). Im now SW 1.3.5R10, Uboot OS 5.0, FPGA version 2020-04-26, CPLD version 03, HW version 2.0.
Thanks to everyone for the advice, help.
-
@kev_in_cornwall: I think it's a bug specific to your instrument, and I would return it. It is visible bot in vector and dot mode, and it definitely should not be there. A new device must not have such problems. I have inverted your pictures with gimp, such that the wrong spikes are better visible.
-
I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)
.................
Get some data in the result list (the number of visible lines from 2 to 7 set up does not matter).
Use the down arrow (or drag the scroll handle) at right side of result list to obscure item #1.
Now, it is not possible via the up arrow or the handle to make the 1st item in the list appear again.
items 2-8 can be seen via scrolling, however.
..................
I confirm this bug here. It seems not to be possible to move in the list to item 1 with either the 'up' arrow or the scroll bar. When the first line has been selected with the scroll dial, moving down with the 'down' arrow directly jumps to line 3. Looks like a simple offset 0 or 1 error for the first element when displaying the list.
Edit: The same problem happens with UART, I2C and CAN decode. So it looks like a generic but marginal issue. If the list contains only two elements, you cannot move with the arrows at all, unless you used the Scroll dial to go to line 1 first.
-
After dealing with the device for a few days, I see some possible improvements:
Software:
1. Help Page: Enlarge the (or create a) cancel button. The small X in the
upper right corner is hard to hit with big fingers, and hard to
see on the Browser screen.
2. Allow the selection of the items in the menu column on the right side with the
universal dial. If you open that menu, the universal dial should allow
to move the selection up/down, and when you push it, that element is selected
for changing. Changing the trace intensity is already in the display tab.
3. An acceleration behavior of move buttons (e.g. horizontal, long lists, etc.
when the button is turned. Moving is rather slow.
4. AWG: Bursts, setting and triggering manual and by SCPI command.
5. Speed up UART Decoding, which is very slow for large memory depth settings.
6. Use mouse wheel for universal dial turns
Allow using the mouse wheel for changing the value when the focus in in a
field which is changeable with the universal dial. Using a (rf) mouse is very
convenient
7. Put all elements for a specific setting in one menu.
For instance window or runt trigger has the level and channel/timing
entries in two different menus, which have to be opened separately.
8. Option to increase vertical space. The title bar could for instance be
switchable via the display or utility button or collapse into a small button
in the left or right upper edge. It could be hidden when enabling Zoom.
Enabling/disabling the side bar menu could be by pushing the time/date
area which has no active purpose so far. Whether this information is needed
is questionable. There are other sources of time/date, and the LAN status
can be displayed in the LAN config menu.
Edit: Maybe only a "Full Screen" (toggle) button for the trace area. That would
interfere less with the actual layout.
9. Continuous move in history list. Moving the the history list with the up/down
arrows or the scroll bar should scroll the content continuously instead of
page by page.
10. Configure the timeout of auto trigger mode
Hardware:
1. Reduce the Fan noise. It's nod bad, but could be less.
2. AWG: It's not understandable why the rise/fall time of the arbitrary signals
is ~7 ns min, while the square signal's rise/fall time is at 24 ns. Add a
square wave arb template (and fix waveform import).
3. Where is WiFi?
Almost every piece of Electronics from 1USD devices on has WiFi? That's not
luxury, it's base level standard.
-
I believe a bug is present in at least the SPI decode "result list" (and possibly other serial decode lists?)
I'll repeat that for the SPI. On UART decode I do not see this phenomenon.
About the previous not on decodinge the last byte wrong:
a) At which level did you set the decoding of the MISO line? It should be about Level/2.
b) I see that the MISO and MOSI line start floating after the message. Did you try to pull them up or down to have them fast at a well defined level?
Good questions.
a) MISO is disabled under Decode -> Protocol Signals -> MISO
This is valid use for write-only devices such as displays.
b) I tried pullups on both CS and MOSI and verified the signals were held high when not actively driven.
Still had same errors.
Actually, since CS has a monotonic falling/start and rising/end the 'scope should have no issue detecting the valid decode window.
My Total Phase SPI generator is simply getting off the bus when not actively driving data as I would expect.
The thresholds for CS, MOSI, and CLK are all set to 50%.
-
Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).
Start of 32bit write cycle
[attach=1]
If have done exessive tests on SDS2504X+ with no problems at all:
-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data
I have done a couple of screenshot, if someone is interested i may post them here.
-
Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).
Start of 32bit write cycle
(Attachment Link)
If have done exessive tests on SDS2504X+ with no problems at all:
-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data
I have done a couple of screenshot, if someone is interested i may post them here.
That's great news!
Do you recall what timebase the decodes were performed at?
-
Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).
Start of 32bit write cycle
(Attachment Link)
If have done exessive tests on SDS2504X+ with no problems at all:
-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data
I have done a couple of screenshot, if someone is interested i may post them here.
That's great news!
Do you recall what timebase the decodes were performed at?
Between 10us/div for a single 32bit register over 200us/div for a complete scan over 3 chips with 6 registers up to 500ms/div for long memory tests.
-
Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).
Start of 32bit write cycle
(Attachment Link)
If have done exessive tests on SDS2504X+ with no problems at all:
-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data
I have done a couple of screenshot, if someone is interested i may post them here.
Here are two captures. 500kHz bitrate.
See the last byte in decode list.
One picture shows the correct byte decode, the other is an incorrect byte decode (that's 8 sequential incorrect 'bit' decodes actually).
Only difference is 50us vs 100us timebase (I changed timebase after decode to see signals better, but decode list didn't change).
Threshold and edge select are shown on the screen. *EDIT* MOSI also set to 2V threshold.
MOSI is perfectly stable at the threshold chose during rising edge of CLK. CLK edge is perfect.
-
@Cobra514: Could it be the same problem that I have seen in the UARt decode. Which was, that the decode pattern and the signal trace did not match. Try Single trigger, or push Stop after the device has triggered. Or push the screen to hide the side menu, or push a channel button. Anything that forces a screen redraw.
-
@Cobra514: Could it be the same problem that I have seen in the UARt decode. Which was, that the decode pattern and the signal trace did not match. Try Single trigger, or push Stop after the device has triggered. Or push the screen to hide the side menu, or push a channel button. Anything that forces a screen redraw.
Yes I was thinking the same. I have tried run-normal-stop and single trigger....and bringing up side menu and removing.
It's funny. I am looking at single byte messages failing now.
Only odd values, however (since it seems to miss last bit).
So 00,22,44,66, etc work fine....while 11,33,55,77, etc all fail (again, only at timebases <100us/div).
11 will decode as 10; 33 will decode as 32; 55 will decode as 54, etc...
-
Yes I was thinking the same. I have tried run-normal-stop and single trigger....and bringing up side menu and removing.
It's funny. I am looking at single byte messages failing now.
Only odd values, however (since it seems to miss last bit).
So 00,22,44,66, etc work fine....while 11,33,55,77, etc all fail (again, only at timebases <100us/div).
11 will decode as 10; 33 will decode as 32; 55 will decode as 54, etc...
I had that effect of wrong or no decoding at small timebase settings when the high/low transition of CS was not in the captured trace. In my test object, the CS transition was far off the signal. I changed the CS setting in the scope from the signal level to clock timeout. That allowed proper decoding.
-
Please check the signal integrity of your generator. Bit counter starts with first active SCLK edge after chip select or timeout interval if set. Active edges of SCLK must fall on stable level of MOSI/MISO (Cursors). At very high bitrates the scope need at least 2 ADC-Sample clocks between edges of SCLK and MOSI/MISO (Nyquist).
Start of 32bit write cycle
(Attachment Link)
If have done exessive tests on SDS2504X+ with no problems at all:
-Analog Inputs 8bit
-Analog Inputs 10 bit
-Digital Inputs
-Decoding on short memory
-Decoding with long memory (more than 3000 decodes in list)
-Decoding on zoomed area
-Triggering on decoded data
I have done a couple of screenshot, if someone is interested i may post them here.
Here are two captures. 500kHz bitrate.
See the last byte in decode list.
One picture shows the correct byte decode, the other is an incorrect byte decode (that's 8 sequential incorrect 'bit' decodes actually).
Only difference is 50us vs 100us timebase (I changed timebase after decode to see signals better, but decode list didn't change).
Threshold and edge select are shown on the screen. *EDIT* MOSI also set to 2V threshold.
MOSI is perfectly stable at the threshold chose during rising edge of CLK. CLK edge is perfect.
Please repeat this test with aqquire/peak-detect and display/color-grading on. That would reveal every ns-glitch which eventually confuses decoding.
-
@Cobra514: Looking at the pictures of your first series, the ones that decode right have the CS low/high slope in the captured trace, the one that fail do not have it. What is the CS type setting in the Protocol Signals tab? For a low level CS it has to be ~CS (or CLK Timeout, if the CS transition is too far off or if there is no CS). Due to the CLK synchronous nature w/o timeout the decoder cannot tell from CLK and Data alone where a data item starts. So it needs some other indication.
If the CS setting changes the decoding, still the question arises about the difference between odd/even numbers.
-
I have a new SDS2104X Plus out now after installing option promotion codes from the factory and ready for Decode tests to examine the reported faults.
One thing I see in all screenshots except those from DL2XY are trigger errors; trigger position within the packet and edge selection errors. Simple mistakes they are as are trigger positions off the display when there are tools in this scope to keep the trigger on the display regardless of the timebase setting.
Big day and tired now but some examples of Decode later................
-
I have a new SDS2104X Plus out now after installing option promotion codes from the factory and ready for Decode tests to examine the reported faults.
One thing I see in all screenshots except those from DL2XY are trigger errors; trigger position within the packet and edge selection errors. Simple mistakes they are as are trigger positions off the display when there are tools in this scope to keep the trigger on the display regardless of the timebase setting.
Big day and tired now but some examples of Decode later................
If you trigger on data then the trigger position is in the packet at the end of the respective data element. That's fine. If you capture a sample and then zoom into it, the trigger position may move out of the visible window. Still the visible parts of all traces (including the decoded data) must show the same part of the data.
Edit: Even when the trigger point is outside the captured data, decoding can be done for protocols which can resync, like UART, I2C. Even SPI, if the data resync specifier is a CS transition within the captured data. In my tests that also worked fine with UARTm CAN.
-
SDS2104x-plus, 1.3.5R10
BUG: Inconsistency between displayed and used settings.
Trying to do a simple test with UART decode I trapped over a pitfall, which I would consider a BUG. Setting the protocol signals, the menu showed fine C1, threshold 1.57V. But it decoded wrong. It turned out, that the threshold was wrong. Even if the menu said 1.57V, the value used for decode was 0. It only came right after I had reset it again to 1.57V. This is a problem which occurs at many places, that the settings shown in the menu do not reflect the actual settings used for the measurement.
I did not test yet how easy of difficult it is to repeat the error may not be easy to repeat. One may have to change between protocols or go through a power cycle.
P.S.: At first I thought it was a problem in decoding a custom baud rate, but it was not.
@cobra514: when setting the protocol signals, try to set the threshold level again by varying it a little bit.
Edit: It might be that the issue I have seen with 8/10 bit setting and I2C decode is also related to this topic. Using the same test set-up again and deliberately adjusting the threshold for SCL and SDA again, there is not difference between 8 and 10 bit mode. I can however set the threshold for SDA to an value, where 8 bit decodes fine, but 10 bit not. This level was around 2.5 V in my set-up.
-
Even if the menu said 1.57V, the value used for decode was 0.
If real, this type of bug is a real PITA. One looses confidence... :palm:
-
These are the screenshots of my tests.
DUT is a UHF data receiver unit. It has 3 PLL IC`s (MAX2871) connectet to MCU via SPI. Each PLL has 6 write only register (32bit).
The signal is the initialization sequence requiered: R5 to R0 PLL1 (CS1),R5 to R0 PLL2 (CS2) and R5 to R0 PLL3 (CS3). For testing i repeatet this sequence at 10ms intervall.
The least 3 bits of 32bit words are defining the register address.
One scan, digital input, triggered on data (CS2,R3)
[attach=1]
Long memory test, digital input, only CS2 decoded, triggered on data (R3),
[attach=2]
Zoomed to R3, digital input
[attach=3]
Analog input, triggered on CLK timeout, 3 PLL's* 6 registers
[attach=4]
Zoomed to R3
[attach=5]
18 full scans
[attach=6]
Analog inputs with CS, trigger on data (R3 CS2), one full scan.
[attach=7]
-
@Cobra514: Looking at the pictures of your first series, the ones that decode right have the CS low/high slope in the captured trace, the one that fail do not have it. What is the CS type setting in the Protocol Signals tab? For a low level CS it has to be ~CS (or CLK Timeout, if the CS transition is too far off or if there is no CS). Due to the CLK synchronous nature w/o timeout the decoder cannot tell from CLK and Data alone where a data item starts. So it needs some other indication.
If the CS setting changes the decoding, still the question arises about the difference between odd/even numbers.
Hi roberthh. Yes, good question. The reason the CS low/high transition is not visible in some of the pictures is simply due to timebase difference. But it is present in all of the tests. After I send a command with my SPI generator, it raises the CS line to prepare it to do a high/low transition.
My generator is set up for ~CS (active low) and per the Siglent User Manual: "The ~CS signal needs a complete falling edge on the screen to be regarded as active."
So therefore I was careful to ensure that the complete falling (and subsequent rising) edge of ~CS is on the screen during the decode.
There should be no problem here.
-
@DL2XY - Thank you for taking some time to post.
Probably the closest conditions shown there to one of the conditions I have tried would be xxxxpng_5, where the analog channels are used AND the timebase is under 50uS/div AND performing 32-bit decodes.
I actually would not see an issue with decodes as well with the condition you have posted there.
In my situation, I only see a failure on the decode of the last nibble sent and decoded. I see in your plot that there is subsequent SPI data.
In other words, if I send (n) 32-bit messages, (n-1) of them will be correct and the (nth) will be decoded incorrectly (for timebase <100us only as well).
Not sure what it means, but for 8-bit decodes I usually miss the last bit of the LSB. For 32-bit decodes I sometimes miss the entire last nibble and decode "0" regardless of value.
-
Siglent scopes are bad at keeping serial trigger and decode information after reboot, so every time you reboot, you need to check the serial trigger and decoding settings like channels assigned to signals and the thresholds
-
@Cobra514: Looking at the pictures of your first series, the ones that decode right have the CS low/high slope in the captured trace, the one that fail do not have it. What is the CS type setting in the Protocol Signals tab? For a low level CS it has to be ~CS (or CLK Timeout, if the CS transition is too far off or if there is no CS). Due to the CLK synchronous nature w/o timeout the decoder cannot tell from CLK and Data alone where a data item starts. So it needs some other indication.
If the CS setting changes the decoding, still the question arises about the difference between odd/even numbers.
Did you make tests with clk-timeout as CS setting?
Hi roberthh. Yes, good question. The reason the CS low/high transition is not visible in some of the pictures is simply due to timebase difference. But it is present in all of the tests. After I send a command with my SPI generator, it raises the CS line to prepare it to do a high/low transition.
My generator is set up for ~CS (active low) and per the Siglent User Manual: "The ~CS signal needs a complete falling edge on the screen to be regarded as active."
So therefore I was careful to ensure that the complete falling (and subsequent rising) edge of ~CS is on the screen during the decode.
There should be no problem here.
-
@cobra514: when setting the protocol signals, try to set the threshold level again by varying it a little bit.
Yes, thank you - I did try that. I actually highlighted the threshold "box" and used the universal knob to vary threshold all the way from GND up to the top of the signal. My findings were consistent except when at the vary top or bottom of the signal.
-
Siglent scopes are bad at keeping serial trigger and decode information after reboot, so every time you reboot, you need to check the serial trigger and decoding settings like channels assigned to signals and the thresholds
That is not a problem as long as it is visible. The issue I have seen was that the menu for (here I2C signals) showed different values than the actual setting, until I changed deliberately each and every entry in that menu again, irrespective of what was already shown.
-
@roberthh
My apologies, you mentioned this before. Yes, I did try the clk timeout as well.
I attached 2 pictures of subsequent transmissions (seconds apart) using clk timeout. Both performed with the same data sent. One OK, One failed decode (last bit).
Both performed at the same timebase as well in this case.
Each time I click send on my generator I get randomly AC or AD (AD is correct).
I tried the "history" feature as well in this one.
...and if you look closely, the rising edge of ~CS is visible at the left hand side of screen in both screens (since this was a minor difference noted before).
The two patterns are identical save for some mV level noise. The decodes are different.
*EDIT* As expected, for timebase >100us/div the decode worked perfectly for me every time
-
@Cobra514 Hi. I used a micro to simulate a SPI with similar wave than yours. Clock and data transition at exactly the same time. The result: The last bits are decoded wrong. Instead a 0x33 it shows 0x30, instead of 0x37 it shows 0x30 too. Since a sequence of 1 bits is decoded as 0, that explains why 0xff gets 0x00. My simple USB based logic analyzer works well.
BUT: That was all with a pattern, where the quiet levels of Clk and Data is high. If I change it to Clk & data low when inactive, all decodes well.
Edit: It is the miso line which makes the difference.
Edit 2: It is sufficient that the miso line is low for a short while only. It worked with a 40 ns low state. I could not test further with the little micro I used for pattern generation.
In any case, the active phase of clock was the falling one. And I do not see a setting to cater for a low of high quiet state of the bus. Attached:
spi_high_033.png: Wrong decoding
spi_low_033.png: Proper decoding
LA2016_0033.png: Decoding with the USB LA
spi_datalow_0013.png. Proper decoding with data returning to 0
spi_data_pulse_0017.png: Proper decoding with a 50 ns low miso pulse at the end
-
@roberthh,
That is very good work, indeed. Impressive.
For once I am not the only one seeing this :phew:
Seems it should be capable of decoding either way.
When I free up again, I might have to try all the options for CPOL, CPHA, and SS (active high and low).
-
Maybe the problem results from incorrect decoder settings. You are decoding 8-bit wise but the bitstream is one 32-bit block!
The transfer ends with the rising transition of CS, so if you put out 32 bits while CS is active you should decode it as a 32 bit word.
-
@Cobra514 Hi. I used a micro to simulate a SPI with similar wave than yours. Clock and data transition at exactly the same time. The result: The last bits are decoded wrong. Instead a 0x33 it shows 0x30, instead of 0x37 it shows 0x30 too. Since a sequence of 1 bits is decoded as 0, that explains why 0xff gets 0x00. My simple USB based logic analyzer works well.
BUT: That was all with a pattern, where the quiet levels of Clk and Data is high. If I change it to Clk & data low when inactive, all decodes well.
Edit: It is the miso line which makes the difference.
Edit 2: It is sufficient that the miso line is low for a short while only. It worked with a 40 ns low state. I could not test further with the little micro I used for pattern generation.
In any case, the active phase of clock was the falling one. And I do not see a setting to cater for a low of high quiet state of the bus. Attached:
spi_high_033.png: Wrong decoding
spi_low_033.png: Proper decoding
LA2016_0033.png: Decoding with the USB LA
spi_datalow_0013.png. Proper decoding with data returning to 0
spi_data_pulse_0017.png: Proper decoding with a 50 ns low miso pulse at the end
How did you simulate the SPI signals? Bit banging? The signals do not seem to be the same on the different capture examples
-
Maybe the problem results from incorrect decoder settings. You are decoding 8-bit wise but the bitstream is one 32-bit block!
The transfer ends with the rising transition of CS, so if you put out 32 bits while CS is active you should decode it as a 32 bit word.
No. That's not the problem.
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
it is not both rising and falling edges, it has to do with clock polarity and phase and SPI has 4 modes based on the combination of these 2 parameters[attachimg=1]
-
Maybe the problem results from incorrect decoder settings. You are decoding 8-bit wise but the bitstream is one 32-bit block!
The transfer ends with the rising transition of CS, so if you put out 32 bits while CS is active you should decode it as a 32 bit word.
No. That's not the problem.
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
What is the SPI decoding setting on the scope, including threshold levels for all signals?
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
it is not both rising and falling edges, it has to do with clock polarity and phase and SPI has 4 modes based on the combination of these 2 parameters (Attachment Link)
Right, thank you for that however if we study the screenshots edge alignment of all 3 traces they don't make sense. :-//
CS has no relation to the real CLK other than it's active for way in excess of the packet and the start of CLK is after the start of MOSI.
Certainly conditions that are most unusual.
Garbage in = garbage out.
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
it is not both rising and falling edges, it has to do with clock polarity and phase and SPI has 4 modes based on the combination of these 2 parameters (Attachment Link)
Right, thank you for that however if we study the screenshots edge alignment of all 3 traces they don't make sense. :-//
CS has no relation to the real CLK other than it's active for way in excess of the packet and the start of CLK is after the start of MOSI.
Certainly conditions that are most unusual.
CS has no relation to when the CLK / MOSI / MISO signals start toggling. You set CS and you can wait as long as you want to start transmitting.
When the sampling occurs with CLK going low to high, the MOSI line needs to toggle before the first clock toggle, so it is correct that MOSI moves first
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
What are the blue arrows on the top? It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0. You can also see that the white rectangle indicating decoded packet ends on the 7th clock
EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
What are the blue arrows on the top? It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0. You can also see that the white rectangle indicating decoded packet ends on the 7th clock
EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high
The dark blue arrow is merely indicating the trigger. In that shot I had it detect a SPI pattern (so it needs to see some activity before it triggers.
I have similar plots for the exact same data (and error) where the trigger is at the falling edge of CLK (because I set the trigger for falling edge of CLK).
Last bit is not 0. This is set for MSB. Look again.
By the way. If I set the timebase to 100us/div or higher, it decodes correctly.
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
What are the blue arrows on the top? It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0. You can also see that the white rectangle indicating decoded packet ends on the 7th clock
EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high
The dark blue arrow is merely indicating the trigger. In that shot I had it detect a SPI pattern (so it needs to see some activity before it triggers.
I have similar plots for the exact same data (and error) where the trigger is at the falling edge of CLK (because I set the trigger for falling edge of CLK).
Last bit is not 0. This is set for MSB. Look again.
By the way. If I set the timebase to 100us/div or higher, it decodes correctly.
I can see what you mean. I don't like how Siglent serial decoding works, but this bug is the most bizarre one I saw in any scope. BTW, how are you generating the SPI signals? Is there a pull-up on the MOSI line?
-
See failed decode attached. Note on upper right of screen that "Data Length" = 8 is selected.
Doesn't get much simpler than this...
A single byte (0x11) sent and (0x10) decoded.
MOSI does end in a high state, however.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1088648)
Yes but and a big but, what protocol has both rising and falling edges ?
CS = active low
MOSI = active low
CLK = active high
:-//
What are the blue arrows on the top? It looks like decoding is ending sampling on the second blue arrow, and it is the 7th clock, missing the last clock toggle where bit is 1, but as decode stopped, it shows 0. You can also see that the white rectangle indicating decoded packet ends on the 7th clock
EDIT: I don't think the blue arrows are limiting the decoding, but it is clearly sampling on clock edge low to high, and the last bit is 0 when the 8th clock starts to transition low to high
The dark blue arrow is merely indicating the trigger. In that shot I had it detect a SPI pattern (so it needs to see some activity before it triggers.
I have similar plots for the exact same data (and error) where the trigger is at the falling edge of CLK (because I set the trigger for falling edge of CLK).
Last bit is not 0. This is set for MSB. Look again.
By the way. If I set the timebase to 100us/div or higher, it decodes correctly.
I can see what you mean. I don't like how Siglent serial decoding works, but this bug is the most bizarre one I saw in any scope. BTW, how are you generating the SPI signals? Is there a pull-up on the MOSI line?
Covered in previous posts. I know - there are many.
-
I'm simply going to move on from this decode topic.
I have spent too much time on this and have other more important tasks to work on.
Thanks to everybody who looked into it.
Hopefully just something I'm doing on my end here...
...and I can always just use the timebase workaround (although there are times I'd rather not).
-
@Cobra514 Hi. I used a micro to simulate a SPI with similar wave than yours. Clock and data transition at exactly the same time. The result: The last bits are decoded wrong. Instead a 0x33 it shows 0x30, instead of 0x37 it shows 0x30 too. Since a sequence of 1 bits is decoded as 0, that explains why 0xff gets 0x00. My simple USB based logic analyzer works well.
BUT: That was all with a pattern, where the quiet levels of Clk and Data is high. If I change it to Clk & data low when inactive, all decodes well.
Edit: It is the miso line which makes the difference.
Edit 2: It is sufficient that the miso line is low for a short while only. It worked with a 40 ns low state. I could not test further with the little micro I used for pattern generation.
In any case, the active phase of clock was the falling one. And I do not see a setting to cater for a low of high quiet state of the bus. Attached:
spi_high_033.png: Wrong decoding
spi_low_033.png: Proper decoding
LA2016_0033.png: Decoding with the USB LA
spi_datalow_0013.png. Proper decoding with data returning to 0
spi_data_pulse_0017.png: Proper decoding with a 50 ns low miso pulse at the end
How did you simulate the SPI signals? Bit banging? The signals do not seem to be the same on the different capture examples
Yes, by bit banging. The micro has a SPI engine, but I used bit banging to have full control over all signals. So I can shift the CS slopes in relation to the data, levels of data and clock lines, etc...
-
If I have read the Siglent SDS2000x Plus manual correctly, the internal Waveform Generator has no sweep function.
Can someone please confirm this.
Thanks.
-
Maybe the problem results from incorrect decoder settings. You are decoding 8-bit wise but the bitstream is one 32-bit block!
The transfer ends with the rising transition of CS, so if you put out 32 bits while CS is active you should decode it as a 32 bit word.
No, it's not. I can always decode a message as 8 bit quantities. And this issue is the same for messages of 1, 3, or 5 bytes length. It is related to the miso or mosi level after the end of the transfer. The SPI papers do not require a specific level of the data lines outside the message window. So it should decode properly with any level.
And, b.t.w., simple USB logic analyzers with public domain software can handle that signal pattern properly. So I would consider that as a topic for improvement by Siglent, politely spoken.
-
If I have read the Siglent SDS2000x Plus manual correctly, the internal Waveform Generator has no sweep function.
Can someone please confirm this.
Thanks.
The user interface to the internal waveform generator is pretty simple. No sweep, no modulation, just simple settings. You can however control it through SCPI commands, changing frequency or amplitude in steps. Similar is obviously done doing the Bode plots. The speed of setting changes is however limited by the time it takes to send a command. So you cannot do something like AM or FM modulation.
-
If I have read the Siglent SDS2000x Plus manual correctly, the internal Waveform Generator has no sweep function.
Can someone please confirm this.
Thanks.
The user interface to the internal waveform generator is pretty simple. No sweep, no modulation, just simple settings. You can however control it through SCPI commands, changing frequency or amplitude in steps. Similar is obviously done doing the Bode plots. The speed of setting changes is however limited by the time it takes to send a command. So you cannot do something like AM or FM modulation.
Ok, thanks
-
@Cobra514 and others: I should add that this habit of decoding the last byte wrong if the value is odd does extend to the previous bytes. In fact it fails at a trailing sequence of 1 bits of any length, up to the full message.
-
My last post on topic SPI decode bug: There is no bug.
At least if signals are SPI conform and setup is correct.
There are four possible mode on SPI, defined by combinations of clock polarity (CPOL) and clock phase (CPHA).
Siglent only supports the setting of polarity, there is no setting for phase.
The user has to choose clock polarity on both CPOL and CPHA of the signal:
CPOL CPHA EDGE
--------------------
0 0 Rise
0 1 Fall
1 0 Fall
1 1 Rise
If you choose the wrong setting you are sampling data bits at its transitions. Unfortunal this may work, for example if the probes are slightly different compensated, but this would be higly instable.
Here are proofs of all 4 possible modes:
CPOL=0, CPHA=0 , Clock rising
[attachimg=1]
CPOL=1, CPHA=0 , Clock falling
[attachimg=2]
CPOL=0, CPHA=1 , Clock falling
[attachimg=3]
CPOL=1, CPHA=1 , Clock rising
[attachimg=4]
If you are not sure wich mode your signal is, you may look at clock idle level for CPOL and wich clock transition hits data in settled state.
Hope that helps
PS: can someone tell me how to get the pics in the right place ?! :palm:
-
My last post on topic SPI decode bug: There is no bug.
Thanks for your efforts. :)
PS: can someone tell me how to get the pics in the right place ?!
Yes the within text image insertion no longer works and instead you need insert the thumbnail image URL into where you want them and its URL address between image flags.
I post first then edit replacing placeholders (1,2,3,4...a,b,c, etc) with the image URL within the image flags ([ img]image url[ /img])
Edit works better for this than Modify as in Edit you still have access to image URL's. ;)
-
My last post on topic SPI decode bug: There is no bug.
At least if signals are SPI conform and setup is correct.
There are four possible mode on SPI, defined by combinations of clock polarity (CPOL) and clock phase (CPHA).
Siglent only supports the setting of polarity, there is no setting for phase.
The user has to choose clock polarity on both CPOL and CPHA of the signal:
CPOL CPHA EDGE
--------------------
0 0 Rise
0 1 Fall
1 0 Fall
1 1 Rise
If you choose the wrong setting you are sampling data bits at its transitions. Unfortunal this may work, for example if the probes are slightly different compensated, but this would be higly instable.
Here are proofs of all 4 possible modes:
CPOL=0, CPHA=0 , Clock rising
(Attachment Link)
CPOL=1, CPHA=0 , Clock falling
(Attachment Link)
CPOL=0, CPHA=1 , Clock falling
(Attachment Link)
CPOL=1, CPHA=1 , Clock rising
(Attachment Link)
If you are not sure wich mode your signal is, you may look at clock idle level for CPOL and wich clock transition hits data in settled state.
Hope that helps
PS: can someone tell me how to get the pics in the right place ?! :palm:
I'm sorry, but I disagree. In the examples of @cobra514 and mine the sampling was in the stable clock phase of the data. We took care of that aspect. The difference between working an failing is the level of the data line miso or mosi at the end of the transmission. If the data line is low, all works fine. If the data line is high after the end of transmission, there is the problem with the trailing run of 1 bits. Upfront from the last 0 bit in the data bit sequence, everything is decoded well. For a proper decoding, the high/low transition of the data line has to be in the capture window. It may be later that the SS deassertion.
In your examples the data line is low after the transmission. Therefore you do not see the error. The SPI standard has no requirements for the data line level outside the transmission. For MOSI, it is undefined (xxxx), for MISO the slave must set the line to high-Z. So it may have any level. And in the pictures of @Cobra514 you see it floating. So please repeat your test with a high level data line set-up.
Other SPI decoders do NOT have this issue. It is just the one in the scope.
Obviously, if you choose a wrong polarity/phase setting, you may get other errors. But we are not talking about these. And the Siglent decoder does not care about the four clock/polarity options. It simply asks for the Rising/falling edge. Which is the important difference.
Edit: I attached two screen shots. The data is four bytes 00 00 00 ff. Pretty simple. Clock phase/polarity problem do not apply with that data.
The difference it the level of the data line at the end of the data.
-
Obviously, if you choose a wrong polarity/phase setting, you may get other errors. But we are not talking about these. And the Siglent decoder does not care about the four clock/polarity options. It simply asks for the Rising/falling edge. Which is the important difference.
Edit: I attached two screen shots. The data is four bytes 00 00 00 ff. Pretty simple. Clock phase/polarity problem do not apply with that data.
The difference it the level of the data line at the end of the data.
Yet without setting a protocol trigger your trigger settings can corrupt results.....as can Holdoff if it's not long enough to prevent retriggering until after a packet.
Look here, a Normal trigger on ch2 rising.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1089362)
Reassign it to something more meaningful at the start of the packet and see if the result is better.
-
There's no reason why the trigger settings should influence the decoder, though. The scope captured all relevant data, it should be able to decode without error in this case.
-
My last post on topic SPI decode bug: There is no bug.
At least if signals are SPI conform and setup is correct.
There are four possible mode on SPI, defined by combinations of clock polarity (CPOL) and clock phase (CPHA).
Siglent only supports the setting of polarity, there is no setting for phase.
The user has to choose clock polarity on both CPOL and CPHA of the signal:
CPOL CPHA EDGE
--------------------
0 0 Rise
0 1 Fall
1 0 Fall
1 1 Rise
If you choose the wrong setting you are sampling data bits at its transitions. Unfortunal this may work, for example if the probes are slightly different compensated, but this would be higly instable.
Here are proofs of all 4 possible modes:
CPOL=0, CPHA=0 , Clock rising
(Attachment Link)
CPOL=1, CPHA=0 , Clock falling
(Attachment Link)
CPOL=0, CPHA=1 , Clock falling
(Attachment Link)
CPOL=1, CPHA=1 , Clock rising
(Attachment Link)
If you are not sure wich mode your signal is, you may look at clock idle level for CPOL and wich clock transition hits data in settled state.
Hope that helps
PS: can someone tell me how to get the pics in the right place ?! :palm:
I'm sorry, but I disagree. In the examples of @cobra514 and mine the sampling was in the stable clock phase of the data. We took care of that aspect. The difference between working an failing is the level of the data line miso or mosi at the end of the transmission. If the data line is low, all works fine. If the data line is high after the end of transmission, there is the problem with the trailing run of 1 bits. Upfront from the last 0 bit in the data bit sequence, everything is decoded well. For a proper decoding, the high/low transition of the data line has to be in the capture window. It may be later that the SS deassertion.
In your examples the data line is low after the transmission. Therefore you do not see the error. The SPI standard has no requirements for the data line level outside the transmission. For MOSI, it is undefined (xxxx), for MISO the slave must set the line to high-Z. So it may have any level. And in the pictures of @Cobra514 you see it floating. So please repeat your test with a high level data line set-up.
Other SPI decoders do NOT have this issue. It is just the one in the scope.
Obviously, if you choose a wrong polarity/phase setting, you may get other errors. But we are not talking about these. And the Siglent decoder does not care about the four clock/polarity options. It simply asks for the Rising/falling edge. Which is the important difference.
Edit: I attached two screen shots. The data is four bytes 00 00 00 ff. Pretty simple. Clock phase/polarity problem do not apply with that data.
The difference it the level of the data line at the end of the data.
first byte only has 7 clock transitions
-
@tautech: No, Sir. I started the patterns manually, one by one. So there is no re-trigger or display of the wrong data (as it was in the UART case). It is just that single data frame that came along. And whatever the trigger is, the data must be decoded right. The difference is the level of that data line after the transmission. It can get be permanent low, or just for a short pulse. 50 ns is enough. It is not the setting of the instrument that makes the difference, it is the structure of the data.
Just because you think another trigger would make the difference, two more screen shots. The data sent is 0x55 0x00 0xff 0xff in both cases. Trigger is on the 0x55. And for the data high one the device is in stop mode. The decoded data shows 00 00 at the end instead of ff ff. The data pattern is easy enough so you can decode it manually. Whatever the clock/phase setting is, these trailing 16 bits should not all decode as 0.
-
first byte only has 7 clock transitions
No, data is just sampled on falling edge in that case, not rising.
-
first byte only has 7 clock transitions
a) I'm counting 8 falling clock transitions. It is bit-bang programmed, so all bytes are the same.
b) And we are talking about the last bits, which are decoded wrong.
c) setting the data line to 0 at the end causes proper decoding. No change in the clock.
d) using other SPI implementations give the same result. trailing data level high -> wrong decoding
-
@tautech: No, Sir. I started the patterns manually, one by one. So there is no re-trigger or display of the wrong data (as it was in the UART case). It is just that single data frame that came along. And whatever the trigger is, the data must be decoded right. The difference is the level of that data line after the transmission. It can get be permanent low, or just for a short pulse. 50 ns is enough. It is not the setting of the instrument that makes the difference, it is the structure of the data.
Just because you think another trigger would make the difference, two more screen shots. The data sent is 0x55 0x00 0xff 0xff in both cases. Trigger is on the 0x55. And for the data high one the device is in stop mode. The decoded data shows 00 00 at the end instead of ff ff. The data pattern is easy enough so you can decode it manually. Whatever the clock/phase setting is, these trailing 16 bits should not all decode as 0.
in the first case with data ending high, if it decodes correctly when you change the timebase to 100us, then it is a bug
-
Nevertheless, I´ve reported this in the general Siglent support thread.
When it´s not a bug, they should explain on how to do it right or correct it.
Martin
-
Here I have an SPI capture with Keysight 1000X scope. I generated the SPI signal with STM32 microcontroller. It goes from 0x75 to 0x76 to 0x77 and leaves the MOSI signal in the last state, high or low. It decodes correctly the values in all the cases... so it is almost sure the behavior on the Siglent is a BUG[attachimg=1]
-
@tautech: No, Sir. I started the patterns manually, one by one. So there is no re-trigger or display of the wrong data (as it was in the UART case). It is just that single data frame that came along. And whatever the trigger is, the data must be decoded right. The difference is the level of that data line after the transmission. It can get be permanent low, or just for a short pulse. 50 ns is enough. It is not the setting of the instrument that makes the difference, it is the structure of the data.
Just because you think another trigger would make the difference, two more screen shots. The data sent is 0x55 0x00 0xff 0xff in both cases. Trigger is on the 0x55. And for the data high one the device is in stop mode. The decoded data shows 00 00 at the end instead of ff ff. The data pattern is easy enough so you can decode it manually. Whatever the clock/phase setting is, these trailing 16 bits should not all decode as 0.
in the first case with data ending high, if it decodes correctly when you change the timebase to 100us, then it is a bug
I decodes wrong with any timebase setting, that captures the full event.
-
SDS2104x-plus, Firmware 1.3.5R10
Topic: Controlling the AWG with SCPI command
Maybe someone could explain the intention of the SCPI commaArbnds with regards to the AWG. I tried a few. Most work as expected, like Basicwave (mostly, some glitches), Output, Storlist (huge list!).
What does not seem to work is ArBWaVe. What did I do:
1. Switch output on with: c1:outp on
result: Output is on, TE shows AWG menu
2. Switch basic waveform to Arb: c1:BSWV WVTP,ARB
result: Menu shows Wave Type Arb.., Arb type stair-up, And that is visible in the trace
3. Try to change the arbtype with: c1:ARWV NAME,PPULSE
A short glitch, then still stair-up.
Assuming, that the TE might have changed the Waveform for a short moment, I
a) selected manually Trapezia as the waveform
b) set the slope trigger such that is triggers on the trapezia waveform, but not on the ppulse waveform
c) set the waveform manually back to PPulse (no trigger)
d) send the SCPI command: c1:ARWV index,7
Result: Triggered with a surprising pattern. A mix of trying to switch to trapezia and then again falling
back to Ppulse. Screen shot below.
I could repeat that a few times. After a while, the TE did not respond any more at all to the
ARWV command.
Another strange effect:
Sending the command "C1:ARWV index,47" or "C1:ARWV index,25" breaks the SCPI interface. No command accepted any more, not even *idn?, until I disconnected and reconnected, or even had to reboot the TE. Sometimes it causes the TE GUI to completely freeze. No touch, no button press, no nothing, although the waveform update still worked. I had to power cycle the TE to revive it.
-
Finally i was able to reproduce the issue by manipulating the output of the SPI_Master component of a PSOC3 uC and to track down the cause.
First: You can do anything you want with MOSI / MISO level as long as you do it outside CS active window, decode will be correct.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1089850;image)
If you hold MOSI / MISO high after last bit inside CS window, the decode algorithm fails.
It looks like it depends on "return to zero' within time window between last falling clock and rising CS to get the last bit evaluated.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1089854;image)
In the real (hardware) world this time window is used to transfer the content of the shift register to the final data buffer.
Since the behaviour of MOSI / MISO at the end of CS is not explicitly defined in SPI you may or may not get problems with real world chips appling such maipulated signals.
I personally would prefer an instrument alerting me in case of possible inconsistence than one what pretending everything is fine.
-
@DL2XY
First: You can do anything you want with MOSI / MISO level as long as you do it outside CS active window, decode will be correct.
In your example you have a falling data pulse after the last valid data bit, assuming you had decoded on the rising slope. So it decodes right. You can have the falling slope on data even outside the CS window, as long as it is inside the captured trace. And a low pulse may be very short. I tested it down to 50 ns, limited by my micro for signal generation.
-
@DL2XY
First: You can do anything you want with MOSI / MISO level as long as you do it outside CS active window, decode will be correct.
In your example you have a falling data pulse after the last valid data bit, assuming you had decoded on the rising slope. So it decodes right. You can have the falling slope on data even outside the CS window, as long as it is inside the captured trace. And a low pulse may be very short. I tested it down to 50 ns, limited by my micro for signal generation.
Yes, the siglent decoder needs a return to zero, regardless of if it is in CS window or not.
What i ment is: In every implementation of SPI master i have seen so far the MOSI is reset to zero before raising CS.
This might be, depending on implementation of the receiver chip, vital for transfering shift-register to data register.
Your bitbang implemention does not do this, and the siglent decoder gets irritated.
-
@DL2XY. It started from the observation of the board member @Cobra514, where his device left the miso line floating. And I have also a device, which leaves the MOSI line at the last state. Since, as you said, the status of MOSI and MISO is undefined after the last bit, it can be either level.
Besides that, the decoding must only depend on the level of the data line at the active clock transition inside the SS window, not on anything else.
-
Looks like this BUG is being carried by Siglent for a long time. Look at this old post about the SDS1104X-E. If you look at the signals, it should decode to 05 A5 A5 A5, but it is decoded as A5 A5 A5 A0.
https://www.eevblog.com/forum/testgear/impressive-keysight-1000x-series-(edux1002g-modded)-spi-triggering-rate/msg2421777/#msg2421777 (https://www.eevblog.com/forum/testgear/impressive-keysight-1000x-series-(edux1002g-modded)-spi-triggering-rate/msg2421777/#msg2421777)
-
@TK Except that the sd2000x+ decodes that as A5A5A5A4.
1 bit progress. Not very promising, if a bug has not been fixed for so long. But maybe no one addressed that.
Edit: Looking at that linked data again, the decoding is right. The most-left pattern is indeed A0. The setting seems indeed to be LSB, not MSB
-
@TK Except that the sd2000x+ decodes that as A5A5A5A4. 1 bit progress. Not very promising, if a bug has not been fixed for so long. But maybe no one addressed that.
Edit: Looking at that linked data again, the decoding is right. The most-left pattern is indeed A0. The setting seems indeed to be LSB, not MSB
You are right, it is LSB
-
@DL2XY
First: You can do anything you want with MOSI / MISO level as long as you do it outside CS active window, decode will be correct.
In your example you have a falling data pulse after the last valid data bit, assuming you had decoded on the rising slope. So it decodes right. You can have the falling slope on data even outside the CS window, as long as it is inside the captured trace. And a low pulse may be very short. I tested it down to 50 ns, limited by my micro for signal generation.
Yes, the siglent decoder needs a return to zero, regardless of if it is in CS window or not.
What i ment is: In every implementation of SPI master i have seen so far the MOSI is reset to zero before raising CS.
This might be, depending on implementation of the receiver chip, vital for transfering shift-register to data register.
Your bitbang implemention does not do this, and the siglent decoder gets irritated.
FWIW:
I am using a Total Phase SPI generator that has been in production for years. No issues ever with other 'scope manufacturers.
To be sure, I just tested my exact patterns as was failing, but with a cheap "brand" name 'scope - and it decodes perfect.
BTW, I too have another generator on my bench that defaults to low. Never tried, but suspect the Siglent would work on that one.
So that's 50/50 here for how it is implemented in my limited sample set LoL.
Even if one particular implementation were to be more common - that does not mean there is not a problem here.
If returning to LOW happens to be more common though, that *may* explain why Siglent employees did not catch it in testing (who knows how they generated the test vectors).
Either way - it is a bug - as the Mot. SPI standard allows for either from my interpretation.
-
SDS2104x-plus, Firmware 1.3.5R10
Topic: Controlling the AWG with SCPI command
Maybe someone could explain the intention of the SCPI commaArbnds with regards to the AWG. I tried a few. Most work as expected, like Basicwave (mostly, some glitches), Output, Storlist (huge list!).
What does not seem to work is ArBWaVe. What did I do:
1. Switch output on with: c1:outp on
result: Output is on, TE shows AWG menu
2. Switch basic waveform to Arb: c1:BSWV WVTP,ARB
result: Menu shows Wave Type Arb.., Arb type stair-up, And that is visible in the trace
3. Try to change the arbtype with: c1:ARWV NAME,PPULSE
A short glitch, then still stair-up.
Assuming, that the TE might have changed the Waveform for a short moment, I
a) selected manually Trapezia as the waveform
b) set the slope trigger such that is triggers on the trapezia waveform, but not on the ppulse waveform
c) set the waveform manually back to PPulse (no trigger)
d) send the SCPI command: c1:ARWV index,7
Result: Triggered with a surprising pattern. A mix of trying to switch to trapezia and then again falling
back to Ppulse. Screen shot below.
I could repeat that a few times. After a while, the TE did not respond any more at all to the
ARWV command.
Another strange effect:
Sending the command "C1:ARWV index,47" or "C1:ARWV index,25" breaks the SCPI interface. No command accepted any more, not even *idn?, until I disconnected and reconnected, or even had to reboot the TE. Sometimes it causes the TE GUI to completely freeze. No touch, no button press, no nothing, although the waveform update still worked. I had to power cycle the TE to revive it.
I have not looked into this, but I can say I have duplicated essentially the same on my end.
Screenshot attached.
*EDIT* For what it's worth, I'm using NI VISA over USB
*EDIT #2* I did a bit of research on this. Here are a few things I found:
1) The SDS Series Programming Guide notes that the index #s for the waveforms shown in the document are "just an example". One needs to query the device to figure out the actual index mapping for a specific model. That was aggravating (because documenting that for users is so expensive? - it's a table that takes up 1/3 of a [digital] page).
2) Going through the Arb Type menus I counted 45 types + 2 under the "Stored" tab. Consistent with the datasheet.
I queried and got index values ranging from 2 (StairUp) to 46 (Acot).
@roberthh: this is a guess, but maybe that is why you had a lockup on index 47? I did as well. I did not have a freeze on index 25, however (which is a valid index - Logrise tripuls). But I only tried once. Even if that is the case, that is terribly poor error trapping on the part of Siglent.
2a) So in the manual, one can disregard index 0 (Sine) and index 1 (Noise) and 47 (Square). These waveforms are located under BaSic_WaVe for our model.
2b) Additionally, index 37 in the manual (Harris) is actually BlackmanH internally and index 38 (Bartlett) is actually Bartlett-Hann.
3) I am not able to send *ANY* ARB waveform type changes via commands (only locally on the TE). I tried both "name" and "index" ARbWaVe syntax variations. I also tried both "long" and "short" form commands.
I believe consistent with @roberthh's findings, I usually just get a glitch that looks like the generator is attempting to switch, then it reverts back to current waveform. I tried many waveform types.
I am able to send BaSic_WaVe commands, however.
Maybe I'm not sending commands properly, but I am taking them right out of the Siglent manual.
I tried turning off the output via commands in-between switching waveforms to no avail.
I also performed a few power cycles and set the TE to "DEFAULT" settings upon boot before attempting commands, just to make sure I was not in some incompatible mode.
Either there is another bug here - or I missed something in the manual regarding programming ARB.
Maybe there are some subtle peculiarities to programming this device that elude me.
Seems it shouldn't be so difficult.
-
@roberthh: this is a guess, but maybe that is why you had a lockup on index 47? I did as well. I did not have a freeze on index 25, however (which is a valid index - Logrise). But I only tried once. Even if that is the case, that is terribly poor error trapping on the part of Siglent.
2a) So in the manual, one can disregard index 0 (Sine) and index 1 (Noise) and 47 (Square). These waveforms are located under BaSic_WaVe for our model.
2b) Additionally, index 37 in the manual (Harris) is actually BlackmanH internally and index 38 (Bartlett) is actually Bartlett-Hann.
The freeze happens not all the time. You may have to repeat that ARWV command several times until it happens. Looks like an internal memory corruption.
About 47 (not 42):
I recall that I had tried to load a waveform called square.csv to the TE, generated with Easywave. If I now enter:
"ARWV name, square"
and then
"ARWV?"
I get
"C1:ARWV NAME,square.bin"
as response. Which is strange The output still shows the StairUp pattern. And at the command, the output shortly stops. The trigger I use the to show that effect is: negative pulse for >= 1 ms. Easier than the slope trigger I used before.
The manual tells that the waveform table is just a sample, and one should use the STL? command to get the list of installed waveforms. This list is pretty long and shows 198 waveforms. It is the same as in the manual. And I choose 47 (square), because I wanted to see if that square has a better rise time than the basic waveform.
Edit: Trying to load a waveform mywave,csv from USB results in mywave.csv being shown in the menu, without any change to the signal.
And: Any index > 45 freezes the TE.
Besides that, here is a pretty-print of that list.
2,StairUp 52,RoundHalf 102,LFPulse 152,Duty16
3,StairDn 53,RoundsPM 103,Tens1 153,Duty18
4,StairUD 54,BlaseiWave 104,Tens2 154,Duty20
5,Ppulse 55,DampedOsc 105,Tens3 155,Duty22
6,Npulse 56,SwingOsc 106,Airy 156,Duty24
7,Trapezia 57,Discharge 107,Besselj 157,Duty26
8,Upramp 58,Pahcur 108,Bessely 158,Duty28
9,Dnramp 59,Combin 109,Dirichlet 159,Duty30
10,ExpFal 60,SCR 110,Erf 160,Duty32
11,ExpRise 61,Butterworth 111,Erfc 161,Duty34
12,LogFall 62,Chebyshev1 112,ErfcInv 162,Duty36
13,LogRise 63,Chebyshev2 113,ErfInv 163,Duty38
14,Sqrt 64,TV 114,Laguerre 164,Duty40
15,Root3 65,Voice 115,Legend 165,Duty42
16,X^2 66,Surge 116,Versiera 166,Duty44
17,X^3 67,Radar 117,Weibull 167,Duty46
18,Sinc 68,Ripple 118,LogNormal 168,Duty48
19,Gaussian 69,Gamma 119,Laplace 169,Duty50
20,Dlorentz 70,StepResp 120,Maxwell 170,Duty52
21,Haversine 71,BandLimited 121,Rayleigh 171,Duty54
22,Lorentz 72,CPulse 122,Cauchy 172,Duty56
23,Gauspuls 73,CWPulse 123,CosH 173,Duty58
24,Gmonopuls 74,GateVibr 124,CosInt 174,Duty60
25,Tripuls 75,LFMPulse 125,CotH 175,Duty62
26,Cardiac 76,MCNoise 126,CscH 176,Duty64
27,Quake 77,AM 127,SecH 177,Duty66
28,Chirp 78,FM 128,SinH 178,Duty68
29,Twotone 79,PFM 129,SinInt 179,Duty70
30,SNR 80,PM 130,TanH 180,Duty72
31,Hamming 81,PWM 131,ACosH 181,Duty74
32,Hanning 82,EOG 132,ASecH 182,Duty76
33,kaiser 83,EEG 133,ASinH 183,Duty78
34,Blackman 84,EMG 134,ATanH 184,Duty80
35,Gausswin 85,Pulseilogram 135,ACsch 185,Duty82
36,Triangle 86,ResSpeed 136,ACoth 186,Duty84
37,BlackmanH 87,ECG1 137,Bartlett 187,Duty86
38,Bartlett-Hann 88,ECG2 138,BohmanWin 188,Duty88
39,Tan 89,ECG3 139,ChebWin 189,Duty90
40,Cot 90,ECG4 140,FlattopWin 190,Duty92
41,Sec 91,ECG5 141,ParzenWin 191,Duty94
42,Csc 92,ECG6 142,TaylorWin 192,Duty96
43,Asin 93,ECG7 143,TukeyWin 193,Duty98
44,Acos 94,ECG8 144,Duty01 194,Duty99
45,Atan 95,ECG9 145,Duty02 195,demo1_375
46,Acot 96,ECG10 146,Duty04 196,demo1_16k
47,Square 97,ECG11 147,Duty06 197,demo2_3k
48,SineTra 98,ECG12 148,Duty08 198,demo2_16k
49,SineVer 99,ECG13 149,Duty10
50,AmpALT 100,ECG14 150,Duty12
51,AttALT 101,ECG15 151,Duty14
-
sds2104x+, 1.3.5R10
I just noticed a strong microphonic effect on the inputs. Not really a problem on a quiet table, and also pretty common to that kind of design, but string. Reading in the forum, that seems to apply to quite a few vendors, even the "big" names.
-
The manual tells that the waveform table is just a sample, and one should use the STL? command to get the list of installed waveforms. This list is pretty long and shows 198 waveforms. It is the same as in the manual. And I choose 47 (square), because I wanted to see if that square has a better rise time than the basic waveform.
Very nice work and reporting @roberthh. Nice table formatting :-)
Yes, I do get a big list as well from STL?. Too big.
My first guess is that the table was a copy/paste from some other (higher model) firmware (because we don't have access to all those waveforms in the table).
So I did some detective work....
First I checked the "flagship" 5000 series manual. It also states only 45 arb waveforms.
Then I jumped to the SDG6000X Waveform Generator features. Sure enough - it has 196 waveforms!
Note that the STL? list ends at location 198....but it starts at location 2....so the total is 196 waveforms. Probably not a coincidence.
My guess is that the table is a copy/paste from some other TE (like a dedicated function generator).
Since the User Manual states that there are 45 built-in and 2 custom arb waveforms, I believe the table that STL? returns is misleading (they show more than we have access to).
I get valid index/name queries from index 2 thru index 46 (for a total of 45 arb waveforms).
For me, queries of 0 or 1 are ignored (but 'scope remains operational), from 2 to 46 queries work fine, and queries above 46 cause the TE to lockup - requiring a power cycle to recover - *BAD*. That's bad coding practice, but I suppose I can give them a pass on considering it a bug.
Seems the firmware is attempting to keep us restricted to 45 arb waveforms, it's just that the invalid command trapping works below the lower boundary (2) and locks up above the upper boundary (46).
But I can live with the subset of the STL? table, since I was only expecting a total of 45 arb waveforms anyway.
Nevertheless, it is safe to say that the implementation of the STL? command is a BUG.
(for reporting an incorrect list of waveforms for our model)
-
@cobra514 Thanks for the analysis of the waveform list and usage. For me, the AWG topic may rest until eventually Siglent fixes it. With AWG, I count six bugs:
1. Not being able to load own waveforms form USB
2. When trying to select a waveform by index > 46 though SCPI commands, the TE stalls. Clearly a missing check for wrong values.
3. No reasonable activity when trying lo load a waveform from a channel. Art least the channel should be selected. But the only thing that happens is switching off the output.
4. Not being able to select a Waveform with a SCPI command. The TE shortly switches to the requested waveform, and then back to the one set in the Menu. That could be a GUI bug.
5. The List reported by the STL? command is wrong. It contains waveforms not present
6. No support through EasyWave. There is not even a version assigned to that TE. The existing EasyWave versions allow to extract a channel pattern from the TE, but you cannot send a waveform.
Again, that all is nothing that would stop one using the TE with success and pleasure, but especially #1 - #4 should be fixed.
-
SDS2104x+, 1.3.5R10
FFT function, Linear vertical scale setting
a) Setting scale by keypad is weird
b) changing the scaling for the input channel sets back the FFT scaling to default values
ad a) When you are using the Unit Vrms for the vertical scale, the default setting for Scale and Ref Level is 100V and 500V. Setting that to a lower level is strange. You cannot set the Scale via keypad to 1V. It you try, you get 10V. You can enter 100mV, in which case you get 1V. Then you can dial down. You can set the ref Level to 1V.
ad b) When you change the V/div setting of the related input channel, the FFT Scale and Ref Level is set back to 100V / 500V. That's annoying.
You might ask why I used the linear scale in FFT: Just to see linear changes in the spectrum of a signal. For that it's useful.
Edit: It's not understandable why the default setting for FFT Scale and Ref Level is set as the works case, instead of just taking the actual numbers of the respective input channel. These should match.
-
Not really a bug, and it may just be me. I usually look at tiny (couple of mV) signals from amplifiers of variable offset from 1 unit to another. I would like to adjust the offset at say 20 mV/div sensitivity and then zoom down the 1mV/div. Problem : the offset is not kept when changing sensitivity.
-
Not really a bug, and it may just be me. I usually look at tiny (couple of mV) signals from amplifiers of variable offset from 1 unit to another. I would like to adjust the offset at say 20 mV/div sensitivity and then zoom down the 1mV/div. Problem : the offset is not kept when changing sensitivity.
In the Utility menu you have choices to set vertical or horizontal traces to a fixed position so when zooming in they do not move.
-
SDS2104X, 1.3.5R10.
Topic: Unexpected high event count when measuring
This is just a strange observation during measurement which is somewhat irritating.
Set-up:
Input signal 0.5 Hz suqre wave with 50% Duty cycle at 3.3Vpp, trigger at 1.V
Trigger: Auto-Trigger,
Horizontal: 500 ms/div, Roll enabled (this is a slow signal)
Measurement enabled for period.
The value for the period is fine, only the measurement count increases by 2 about twice per second, in total 4 per second. Which is kind of surprising for a 0.5 Hz signal. I could understand if it increments once per second, because at that rate a new edges comes in. Setting the Horizontal scale to 1s/div changes that to about 8/sec increment. Edit: With a burst of 100 cycles it counted 378 periods and 485 falling slopes.
When switching off roll mode, the counting of events is reasonable.
Edit: Another observation:
In roll mode, no input signal at all, all items from the Miscellaneous tab seem to increase by ~ 2 per second.
In Auto mode the increase every sweep.
That looks strange if there is no signal. But the count item seems to count measurement cycles, not the indicated items. E.g. even if the count increases, the number of edges stays 0. Still, that behavior is different between the miscellaneous items and the items from the other tabs.
-
There is a new firmware now. 1.3.7R5.
Works so far. A few results:
- The Display options are fine. Changing the colors for the channels may be useful. I have doubts whether it was worth the coding effort.
- Bode Plot seems to be a little bit faster. On a second attempt to run Bode plots it completely failed. Reason: Sequence sampling was enabled. That may have been a phenomenon before too.
- I could not tell how to set the serial trigger as source for counting (topic 7). That was already mentioned for version 1.3.5R5.
- Zooming in roll-stop mode works
- AWG waveform loading works now. Choosing an Wavorm by e.g. Index 47 still freezes the device. I did not test the other AWG bugs.
- The bug of not being able to scroll to the first element of a list seems to be gone (was not mentioned in the change log) Note: Not fixed. It is still not possibel going to the first element using the scroll bar.
- Pushing the lower right corner opens LAN setting (not mentioned in the change log)
No more test right now. I have no source for the new protocol decoders, so I cannot test them. They are as usual enabled for a trial period, but not available for purchase yet.
-
A few more results:
- Setting the ARWV with "C1:ARWV index, number" works. (not mentioned in the change log) Setting the waveform by name fails.
- The List returned by STL? is still wrong.
- The generated waveform does not have to be 16384 points, it can be fewer. Tested with 4096
- The SPI decode failure seems to be fixed. Decoding works even when the data line stays high. (not mentioned in the change log)
-
not mentioned in the change log
It seems, they like telling not everything - A "nice" game for users to find out... :P
-
- The Display options are fine. Changing the colors for the channels may be useful. I have doubts whether it was worth the coding effort.
Example my eyes (and mind) are very allergic when I see some non harmonized or "ugly" colors mixes on the screen.
But more seriously, humans eyes are different. Also age makes some changes what may affect also what colors are better for visibility.
Why only traces. All, everything on screen must have free adjustable colors.
It was old time one R&S bit better Spectrum analyzer have this feature. When get all adjusted for just my taste and eyes it was very nice to use and look... even if need use extremely long periods, also if need work in bit dim lab it is very important to have colors what do not destroy eyes dark sensitivity and what support good eyes accommodation and focus. Most users are young peoples and eyes are much more adaptive. Young peoples do not understand this at all, they simply do not have experience using older eyes - nearly same as try explain milk color to born blind people.
Of course then one important group are peoples whoi have some anomaly in color visibility and differentiation.
I want that I can adjust every single item on display. Period. And it do not need difficult programming at all. One of simplest things in scope FW.
ugh...
-
@rf-loop My eyes get old too, but the problem is more with contrast & reflections
About the firmware:
+ the protocol decoding speed seems to be improved a lot. Especially UART was sometimes extremly slow. Now it
is more snappy.
- loading AWG waveforms is a little bit rough. Sometimes I have to retry it a few times. Simply pushing at the file name works sometimes, sometimes not.
- The title "stored" waveform is misleading. Imported waveform are not stored beyond the time of using them. If you switch to another waveform and want to use the loaded waveform again, you have to re-load it. And the Channel option still does not work. It just switches off the AWG.
- There is no setting for using the counter for trigger events. I would have expected it in the counter source section. I have no clue what the change log tries to tell me.
Last not least: No update of the documentation or the programming manual. Will come, I hope.
-
SDS2104X, 1.3.7R5.
Web Server remote it doesn't work for me.
(http://[attachimg=1])
-
That worked for me, using both Firefox@Linux, Chrome@Linux and Edge@Windows. Did you check the LAN settings on the device? Did you set a password?
-
I set a static IP and the oscilloscope connects to the network as you can see in the screenshot, but I can't see the oscilloscope screen, 4 buttons work.
(http://[attachimg=1])
Ok, work on InternetExplorer but not with latest Chrome...
-
Can you issue SCPI commands like *IDN?
-
All works perfectly on Internet Explorer but something is with my Chrome browser.
-
My colleagues at work don´t use any serial trigger, they always use the edge trigger for decoding(We use SPI)...
-
Done the upgrade today, will test some things later.
But first of all, this let the sun goes up in my heart.... :)
BTW., what means "floating" in the menu style ?
-
Done the upgrade today, will test some things later.
But first of all, this let sun go up in my heart.... :)
BTW., what means "floating" in the menu style ?
It means menu will not resize screen but will go over the waveform...
-
Thank you sinisa, plus reading things could be helpful:
Supported floating menu so that the waveform is not compressed horizontally when the right-side menu is displayed: Display | Menu Style
::) ;D
-
Thank you sinisa, plus reading things could be helpful:
Supported floating menu so that the waveform is not compressed horizontally when the right-side menu is displayed: Display | Menu Style
::) ;D
^-^
-
+ A more steady screen appearance. You can always have the interesting parts of the trace still visible.
- Lists will be overlay-ed too. So you do not see the rightmost colum(s)
-
Hi,
Maybe a bug too or the problem is appx 50cm in front of the scope:
Measure:
For example I want to measure the rms on channel 1 and the width on channel 2.
So I choose rms and choose channel 1 as the source.
Then I choose width and choose channel 2 as the source.
So I was used to do this on lecroy scopes and it seems logically to me.
But not on the siglent:
Doing this will cause that everything will be measured from one channel.
Shortform:
Measure rms, select channel 1 - rms from channel 1 is displaying, then choosing width and select channel 2 as the source for it - rms will change to channel 2 too.... ???
-
Choose the channel first, then the measure.
-
Thanks, read it in the manual seconds later....will try it at next time I´m on my scope.
Nevertheless, it irritates me.
It should no matters in which order I´m choosing the measurement selection.
It´s the same thing when I want to hide the channel.
On lecroy scopes, I press the channel button twice and then it´s hiding ( btw., "completely" hiding without any notice on the screen).
On the siglent I must turn on the channel menu, scrolling to the very end and then I can choose the hiding function - lame thing... :P
Plus the channel is somekind of still there as a notice on the screen.
Both would be nice to polish in future fw upgrade.
-
Thanks, read it in the manual seconds later....will try it at next time I´m on my scope.
Nevertheless, it irritates me.
It should no matters in which order I´m choosing the measurement selection.
It´s the same thing when I want to hide the channel.
On lecroy scopes, I press the channel button twice and then it´s hiding ( btw., "completely" hiding without any notice on the screen).
On the siglent I must turn on the channel menu, scrolling to the very end and then I can choose the hiding function - lame thing... :P
Plus the channel is somekind of still there as a notice on the screen.
Both would be nice to polish in future fw upgrade.
In Siglent there is NOT function to hide whole channel at all. You can turn channel on and off of course. But then, when channel is on you can turn off channel trace draw off from display. Without displayed waveform trace, in background channel is still fully functional.
What is reason for hide whole channel totally (LeCroy thing. What it mean is not fully clear for me), fast thinking I can not find any real reason. But I can find reasons for turn channel trace draw off from screen when channel is still fully working in background - just without trace display draw.
Always when we get new instrument it need time to adapt and time for learn it and same time need learn away some things from other instrument.
It was hard time when in some situation in history I use Hewlett-Packard analog scopes and Tektronix analog scopes randomly mixed or some times even parallel. It was nightmare due to so different "UI" logic and same or even worse when use HP Spectrum analyzers with R&S spectrum analyzers until use so much that both are in "muscle memory". You need two isolated area in brain and fast switch between them ;)
-
Ya'll find them bugs now.
I got my 2352X-E on the way...
Cmon guys... Find those bugs. :-+
And let Tautech know.... Bugs are bad ! >:(
How similar is the code between X-E and X Plus? Are bugs found in one likely to be found in the other? Are fixes and improvements in one likely to make it into the other?
I recently read that the 2K and the 5K and 6K series share the same foundation code - is this true and are the 2K X-E and the 2K X Plus both considered to be part of the same 2K series?
-
Ya'll find them bugs now.
I got my 2352X-E on the way...
Cmon guys... Find those bugs. :-+
And let Tautech know.... Bugs are bad ! >:(
How similar is the code between X-E and X Plus? Are bugs found in one likely to be found in the other? Are fixes and improvements in one likely to make it into the other?
I recently read that the 2K and the 5K and 6K series share the same foundation code - is this true and are the 2K X-E and the 2K X Plus both considered to be part of the same 2K series?
Not similar at all.
Traditional scope vs different UI and feature set of the 5KX and 2KX Plus models.
2KX-E is similar in every way to SDS1104/1204X-E.
-
On lecroy scopes, I press the channel button twice and then it´s hiding ( btw., "completely" hiding without any notice on the screen).
Same thing here. If you push the channel button while the channel is "on", it it switched off (not hidden). And in the channel menu the on/off switch is at the top.
About the assignment of measuring items to channels: That is irritating. I had made a post about a similar behavior earlier.
-
Thanks, read it in the manual seconds later....will try it at next time I´m on my scope.
Nevertheless, it irritates me.
It should no matters in which order I´m choosing the measurement selection.
It´s the same thing when I want to hide the channel.
On lecroy scopes, I press the channel button twice and then it´s hiding ( btw., "completely" hiding without any notice on the screen).
On the siglent I must turn on the channel menu, scrolling to the very end and then I can choose the hiding function - lame thing... :P
Plus the channel is somekind of still there as a notice on the screen.
Both would be nice to polish in future fw upgrade.
In Siglent there is NOT function to hide whole channel at all. You can turn channel on and off of course. But then, when channel is on you can turn off channel trace draw off from display. Without displayed waveform trace, in background channel is still fully functional.
What is reason for hide whole channel totally (LeCroy thing. What it mean is not fully clear for me), fast thinking I can not find any real reason. But I can find reasons for turn channel trace draw off from screen when channel is still fully working in background - just without trace display draw.
Always when we get new instrument it need time to adapt and time for learn it and same time need learn away some things from other instrument.
It was hard time when in some situation in history I use Hewlett-Packard analog scopes and Tektronix analog scopes randomly mixed or some times even parallel. It was nightmare due to so different "UI" logic and same or even worse when use HP Spectrum analyzers with R&S spectrum analyzers until use so much that both are in "muscle memory". You need two isolated area in brain and fast switch between them ;)
Easy of channel management is relative to the UI inputs you choose to use with the scope.
Some little examples
Hidden or Visible is only accessible with the touch display or a mouse. Period. Same for SDS5kX or 2kX Plus.
By far the easiest is to use a mouse whether the channel menu is visible or not.
If the channel menu was the last menu used its tab remains available at the top right of the display and a touch or click opens it again and a scroll with the mouse wheel takes you to the menu foot where the less used features like Hidden/Visible reside.
Some screenshots for study and discussion.....interesting that you can't capture the channel popup above the channel tab in a screenshot. :-//
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1110438)
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1110442)
-
If you push the channel button while the channel is "on", it it switched off (not hidden). And in the channel menu the on/off switch is at the top.
This is normal for Siglents multiplexed control DSO's.
Press channel button to bring that channel to the front (active to controls) and another press turns it OFF.
Tap the channel tab has the same effect of bring the channel to the front and also activating a sub menu where you can also select OFF for that channel.
-
This is normal for Siglents multiplexed control DSO's.
Press channel button to bring that channel to the front (active to controls) and another press turns it OFF.
Tap the channel tab has the same effect of bring the channel to the front and also activating a sub menu where you can also select OFF for that channel.
No problem with that. That's how I would expect it. I just wanted to explain to @martin_72 how to switch channels on/off easily w/o scrolling through the menu.
-
SDS2104x+, 1.3.7R5, Test of the SENT decoder
This post replaces the previous one on this topic. To some extend I could tell when it works. A Python simulator for SENT messages is attached. It is made for an ESP32 with micropython firmware. A suitable binary image is here: https://github.com/robert-hh/Shared-Stuff/blob/master/firmware_ESP32_RMT_IDLE_SPIRAM.bin
Test of the SENT decoder.
The test of the SENT decoder were made using a Python protocol simulator
based on a ESP32 module. That simulator was expanded to support as many as possible
message types. Tests were made with a tick time of 5 µs. The simulator can
change the tick time in steps of 0.1 µs.
General impression:
The protocol decoder seems to be work in progress. Some basic functions are there,
but also quite a few inconsistencies and some unexpected behavior.
There is also no documentation yet about the decoder. So I had to guess about
the intentions.
Protocol decoder:
1. Protocol signal
After booting, the protocol signal level was always at about 8V. The state before
shutdown is non memorized. That's the case for both the decoder and the trigger
sections. That may be a common behavior of the oszilloscope and more an inconvence
than a serious problem. For automated testing I would anyhow expect the use
of scripts which set all test parameters again.
2. Protocol config & decode
a) Protocol timing
SENT is designed as timing tolerant. The standard calls a tolerance range of 25%. The
protocol config has a setting for both a CLK and a tolerance. For CLK I assumes it is the
duration of the basic protocol tick. So for a setting of 5µs I expected a range of
3.75 to 6.25 µs tick time, which would be accepted as decodable and valid messages.-
That is NOT the case. With a message tick time of exactly 5µs and the CLK set to 5µs,
the decoder flags a length error and decodes data wrong. Only with real tick settings
between 5.1µs and 5.2µs both no error was flagged and the decoded data was right. For
message tick times between 5.3µs and 5.8µs no error was flagged, but the data decoding
was wrong.
b) Display of decoded data
- The CRC display seems to be unfinished. You can select between two CRC Formats.
But both are displayed the same, and especially there is no difference in the display
between a correct and incorrect CRC. I tried all 16 values for a given data frame,
and besides the value they all look the same (same color.
- When moving such a burst of frames horizontally, the decoding sometimes switches
to completely wrong values. Increasing the horizontal scale fixes that.
Inmy test this happened only at aquisition memory depths if 20M and 200M.
When reducing the acquisition size to 2M i could not reproduce that error.
- Changing the horizontal time/div affects the ability to decode.
Which is puzzling, since the captured data does not change. So it looks as if
the decoding is based on the decimated display points and not on the captured data.-
- The Short Serial data is NOT decoded if only 16 frames are sent. If a 17th frame
follows, the data is decoded. In that case, also triggering on serial data works.
As far as I understand, Short Serial Data requires 16 data frames.
But no joy unless there is another data frame following the first 16.
- Same for the 12 bit and 16 bit variants of Enhanced Serial Data. The coding as
displayed in the decoded list for frames is right, but the decoded values are
not shown, unless a 19th data frame follows the 18 frames required for the
Enhanced Serial Data Message.
3. Serial trigger
- There are inconsistencies between the protocol config menu for serial trigger and
protocol decode. Some like the CRC are named different, some like idle level
do not exist. Different names may be an (avoidable) inconvenience, but the
omission of the idle level setting may be a problem.
- Triggering on the start condition of slow serial channels works, both for
frames with idle level low & high.
- Triggering on the ID value of slow serial frames works only with a trailing frame.
- Triggering on data works for slow serial works only, if the ID's also match.
When the ID is set to don't care, data trigger fails. In any case, triggering
on data requires a trailing frame.
-
What is reason for hide whole channel totally (LeCroy thing. What it mean is not fully clear for me), fast thinking I can not find any real reason. But I can find reasons for turn channel trace draw off from screen when channel is still fully working in background - just without trace display draw.
As I´ve written, I´m used to get the channel "hiding" by pressing only the channel button twice - It´s much more comfortable than open a menu, scrolling and choosing hide yes/no.
Just simply push the button twice.
Don´t get me wrong, hiding the channel in general is an fantastic thing and I´m glad siglent realized this with the first fw-update.
But somehow I find the way lecroy do a little bit more comfortable to handle and I think, it´s only a matter of the software, so it could be modifying to this way.
When I´m the only one who think this was a nice polish, well I could live with the actual version, no problem. ;)
Martin
-
What is reason for hide whole channel totally (LeCroy thing. What it mean is not fully clear for me), fast thinking I can not find any real reason. But I can find reasons for turn channel trace draw off from screen when channel is still fully working in background - just without trace display draw.
As I´ve written, I´m used to get the channel "hiding" by pressing only the channel button twice - It´s much more comfortable than open a menu, scrolling and choosing hide yes/no.
Just simply push the button twice.
Don´t get me wrong, hiding the channel in general is an fantastic thing and I´m glad siglent realized this with the first fw-update.
But somehow I find the way lecroy do a little bit more comfortable to handle and I think, it´s only a matter of the software, so it could be modifying to this way.
When I´m the only one who think this was a nice polish, well I could live with the actual version, no problem. ;)
Martin
Now I understand what you mean. My language is finglish.
It is true this trace display on/off can be better. But it need carefully think how to do it because channel selection button have also other designed function.
In order you push channel select button adjust also in which order traces are overlaid in display when it is important in some cases. Now if button is pressed two times inside some time short period it can turn trace on/off but it need then remove its effect from traces overlay priority register so that it stay untouched but it must not do more slow when use these buttons for make overlay priority order. If you fast (o with long period) have pushed 1342, this is trace overlay priority in reverse order. Now if you want hide trace 3. first you push 3 priority order is then 1423. But if next push come inside short time it turns this action for shut off ch3 trace and then it need cancel it effect in priority so that order is again 1(3)42. (3 trace off) And sime vice versa if you want then turn it back on.
This trace display overlay priority is sometimes important also, as also hiding trace some times so both need work well without extra hassle.
Of course it can do easy but right way and we hope Siglent do it.
-
SDS2104x+
Irritating display, Just a minor glitch?
When testing the Manchester decoder, which b.t.w. works, I got the screen short below, which is confusing. It shows a single Pulse, successfully decoded a Manchester encoded message.
Scope in Normal mode. Trigger set to rising edge. What happened:
There was that single pulse followed by the Manchester encoded data, which by change had about the same length. Both are in the history, but the trace shows the first captured event, and the Protocol decoder the second one.
I do not really agree that this is the right way of doing things, because the screen shows two traces from different sections of time. I came across that earlier in a comment about UART decoding.
Edit: In that state, moving the trace a little bit sideways brings up the proper data pulse train.
b.t.w.: Attached is the little python script for creating this Manchester encoded bit stream. Again the Platform is an ESP32 with Micropython firmware from micropython.org. A firmware image which supports the idle keyword for RMT is here: https://github.com/robert-hh/Shared-Stuff/blob/master/firmware_ESP32_RMT_IDLE_SPIRAM.bin
-
Of course it can do easy but right way and we hope Siglent do it.
Indirectly they did it on the WS3024(SDS3K), so it would be nice when the 2K+/5K (also?) are having it too.
Here pics from it, nr. 1 both channel on, a measure value selected for each.
Second picture shows that channel one is "off", nothing on the screen, no channelbox, even the channel button doesn´t lit - But still the value for ch 1 will be displayed.
Same when using math.
Picture 3 shows a nice to have with very low priority: Displaying the bitrate when decoding.
Picture 4 I´ve forgot to print, it would show a very nice feature:
Searchfunction in decoding....
If it´s possible to make, it would be cool we could have it someday for the 2K+ too.
But like the bitrate, it´s not urgent to have it.
-
A feature request.
When using the Universal control to adjust a channel's deskew value, it would be nice if pressing the control would reset the deskew value to zero.
-
If you push the channel button while the channel is "on", it it switched off (not hidden). And in the channel menu the on/off switch is at the top.
Not exactly if I undestaand right your msg.
It depends what channel button is currently also active (button led on)
So it can not simply say that pushing channel button while it(channel) is on, it is switched off.
Pushing working channel button when button light is ON then this channel shut totally off.
Pushing working channel button when button light is OFF then this channel is set for highest display priority (and vertical adjustments activated)
Pushing not working channel button turn this channel working, turn button led on, set highest display priority and activate this channel adjustments.
If take random example. There is 4 channel on and button 3 have light and diplay priority is (right highest) 1423
Then you want priority 4231 what to do. Just push buttons in order 4231 and no channels turns off. Only in this particular case if this Ch3 button led is on and you want priority order 3421 and for avoid turn off channel, it need first push 4 or 2 or 1 (for move light to other button than 3) and then 3421. This is very logical.
But now if one want mix also turn trace display on/off (and leave channel working) it is pehaps bit messy if display priority, channel on/off, trace display on/off need all take to these channel buttons.
Of course there is available short-long push and slow-fast repeating pushes. But... just imho... I can imagine also what kind of barking it may generate when every user have some imagine how just he think it need work because he is adated to principle how some other instrument UI works. Vice versa. If someone is fully adapted for use Siglent UI and if Siglent do not change logic in every turn repeatedly then user have soon this all in his muxcle memory and later he ranting some other instrument do not work as he is learned and adapted. If one use Siglent then learn to use Siglent. So simple. If one use Rigol then learn to Rigol and so on... long list. Who follow who... No one can make global universal deal that all use same standardized UI logic and so on... So use your shoes and walk your own roads. Some like some not.
But this do NOT mean things are ok and must not improve in usability, hands and fingers ergonomy, visual ergonomy etc..
Just one opinion how it perhaps can do without doing any significant change how it is now.
If I take one example and this is how I do it now so that it do not change anything what is there now.
If one push channel button just one LONG press. If light is on or off and channel is working... trace display is turned off. If button was not active (light off) then it is also after this. All, priority order etc stay just as they was.
There is possible one thing what need think carefully and perhaps simulate in real life before final solution.. (long press, fast double push etc things and timing). If just this channel what trace user want hide is selected active (led on) perhaps it is wise to shut off this activation so that hidden trace channel can not adjust or shut off until it is visible so. also led off (because it is not nice if it is used for trigger and accidentally turn it off or accidentally adjust its vertical things when hidden)
Of course on screen there is visible this channel label and info about trace on off as it is now.
-
A feature request.
When using the Universal control to adjust a channel's deskew value, it would be nice if pressing the control would reset the deskew value to zero.
+1
-
Still waiting day when there is simple one wonderful and miraculous button and it need be real hardware button and without delay.
This mysterious secret button name is "Trig"
Nearly every scope I have used in my life have been this simple button.
This loved child have many names... aka "force trig" or "manual trig" or what ever...
Every single person who have even bit experience working with scopes know this. But for Siglent engineers it is like in some mystery from other unknown universe. |O :-DD
So, please. You do not even need pay it yourself. Customers pay it.
-
Sent Protocol:
Attached is an updated simulator for the SENT protocol. The change: Include the proper CRC for enhanced serial messages. Lacking sample messages or a specification I could not tell yet, whether the CRC for Simple Serial Messages is right.
-
This mysterious secret button name is "Trig"
Nearly every scope I have used in my life have been this simple button.
This loved child have many names... aka "force trig" or "manual trig" or what ever...
One challenge would be the lack of buttons. Obviously it can be a touch button. But also could the Stop/Run button act as Trig button when the scope is waiting for a trigger. So it would trigger then, capture one sweep and stop, showing that sweep.
One other thing that drives me crazy is the very short Auto trigger timeout, making Auto trigger practically useless for events slower repeating more rare that about every 10 ms. That timeout should be configurable.
-
One other thing that drives me crazy is the very short Auto trigger timeout, making Auto trigger practically useless for events slower repeating more rare that about every 10 ms. That timeout should be configurable.
Do you mean trigger Holdoff ?
Its range is: By time：8 ns ～ 30 s (8 ns step) By event：1 ~ 108
We also have available 2 Zone triggers.
-
One other thing that drives me crazy is the very short Auto trigger timeout, making Auto trigger practically useless for events slower repeating more rare that about every 10 ms. That timeout should be configurable.
Do you mean trigger Holdoff ?
Its range is: By time：8 ns ～ 30 s (8 ns step) By event：1 ~ 108
We also have available 2 Zone triggers.
No, he means trigger repeat frequency when in Auto trigger mode, when there is no trigger on input..
Keysight has some kind of adaptive interval, changing with timebase. It is quite clever, but not perfect all the time. I also wish manufacturers would give us configuration of that parameter...
-
Yes, I mean trigger holdoff. And that does not help. The time a trigger event stays visible in Auto mode is simply too short.
-
Yes, I mean trigger holdoff. And that does not help. The time a trigger event stays visible in Auto mode is simply too short.
That is not it.
Holdoff is used to ignore valid trigger events in normal trigger mode (not auto) because you want to have trigger events sparser than what they are occuring naturally.. It is fastest time between actual triggers.
Auto mode creates false trigger events when there are none. It will be defined as timeout from previous trigger event. That will define how long you will have previous capture on the screen in Auto mode.. If valid trigger even happens it will update immediately.
It gets confusing, Tektronix scopes have different behaviour and frequency of auto, to the point that there was false claim that Keysight Auto is buggy, just because it had different frequency and behaviour fro what they were used on Tek....
-
Yes, I mean trigger holdoff. And that does not help. The time a trigger event stays visible in Auto mode is simply too short.
Repetitive trigger events or single events ?
Maybe Normal or Single trigger modes would be better suited to your needs.
We need remember the trigger suite of our scopes is our most powerful tool and mastering its use for complex needs is where we should spend a good amount of time learning to properly do so.
This is where I have found the STB3 or a AWG useful with their ranges of complex waveforms to experiment on with trigger settings.
Driving the rest of the scope is easy by comparison however there are other tricks we can use like Zoom mode (auto or dedicated) to capture extended waveform records and then work within the capture in the zoomed window.
Anyways, this is not bugs discussion so should be in the SDS2000X Plus main thread:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/ (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/)
-
I'm talking about repetitive but not frequent events. And I worked with quite a few Oscilloscope types and makes in the past, cheap ones and expensive ones, including all the "Big names", to consider this Auto trigger behavior as something at least strange. Or should I call it Auto Non-Trigger. It allows you to see that there is some signal on the channel, but you cannot tell whether a certain trigger setting is suitable, simple because it disappears immediately. It works for fast repetitive signals, but not for slow repetition rates.
For that reason I am using Normal or Single trigger mode. But wouldn't it be nice to have a more useful Auto trigger mode?
And, b.t.w., the title of this thread is: "Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests"
So let's call is a feature requests.
-
I'm talking about repetitive but not frequent events. And I worked with quite a few Oscilloscope types and makes in the past, cheap ones and expensive ones, including all the "Big names", to consider this Auto trigger behavior as something at least strange. Or should I call it Auto Non-Trigger. It allows you to see that there is some signal on the channel, but you cannot tell whether a certain trigger setting is suitable, simple because it disappears immediately. It works for fast repetitive signals, but not for slow repetition rates.
For that reason I am using Normal or Single trigger mode. But wouldn't it be nice to have a more useful Auto trigger mode?
And, b.t.w., the title of this thread is: "Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests"
So let's call is a feature requests.
You need write this up in depth. Screenshot examples that can be replicated and description of settings used so any of us can replicate what you see.
Put it all in a PDF if necessary.
-
A screen shot of a non-trigger event is hardly useful. And in Auto mode there is hardly anything to capture because the screen changes during capture time. But I describe the set-up.
a) Signal source: The built-in AWG with pulse wave type, pulse width 200µs.
b) Oscilloscope in Auto mode. Trigger rising edge.
Acquire depth 2M, 1ms/div,
- repeating the signal every 50ms or faster: fine
- repeating the signal between every 100ms and 200ms. Most events are displayed at the trigger position, some not.
- repeating the signal at 350ms or more rarely: Signal is hardly ever visible. Sometimes it appear on the screen, but not triggered.
I withdraw my comment about the holdoff time setting not being effective at all. Setting holdhoff such that
holdoff_time < period < holdoff_time + 200ms
holdoff starting at last trigger,
I get a stable signal. That repeats for integer multiples of the period time. So if you know the signal, you can make the device trigger stable in Auto mode. If not, you have a harder time.
-
So if you know the signal, you can make the device trigger stable in Auto mode. If not, you have a harder time.
This is where adding some Persistence is useful. ;)
-
I revert my comment about holdoff again. That worked for 3Hz but not for 2 Hz or less.
And yes, persistence helps to see if anything happens. But still Auto trigegr behaves like non-trigger.
-
I revert my comment about holdoff again. That worked for 3Hz but not for 2 Hz or less.
And yes, persistence helps to see if anything happens. But still Auto trigegr behaves like non-trigger.
Consult the datasheet. ;)
Hint; different trigger coupling type selections should help you.
There might also be tips in the Help menus, try them. IIRC long press of any button gets you into Help.
-
Manual "says" :
Auto: An internal timer triggers after a preset timeout period if no trigger has been found so that the oscilloscope continously updates whether a trigger happens or not.
Auto trigger is suitable for unknown signals or DC signals.
Note:
In Auto mode, if the signal satisfies the trigger conditions but cannot trigger the oscilloscope stably, it may be that the interval between two trigger events exceeds the timeout period.
Try Normal mode in this case
-
Thank you both both of you for your feedback. I'll stick with normal mode with this oscilloscope.
Other devices worke better auto mode. But these do not have the sequence and history properties. So they could align an event to the trigger when it happened in a time window a large as the acquisition depth. That was not limited to the capture size for the window.
-
This is why I'm saying that timeout time of Auto mode should be user configurable in same manner like hold off..
-
Thank you both both of you for your feedback. I'll stick with normal mode with this oscilloscope.
Other devices worke better auto mode. But these do not have the sequence and history properties. So they could align an event to the trigger when it happened in a time window a large as the acquisition depth. That was not limited to the capture size for the window.
My opinion is opposite but also same, depending.... Many other scopes takes too long time before they start acquisition after last valid trigger event. And these many other scopes also do not have any adjustment for set this waiting time. I personally have used nearly 60 years enormous amount of oscilloscopes including toy class and mostly professional scopes up to state of art models.
Honestly I have never meet any real problem related to this auto trig mode timing. If it have been too short in some case, I really know how to use and setup scope for do my works. And vice versa if it have been too long. When use mixed set of different scopes it is natural that some scopes work different and every scope or what ever instrument - use need know it. Human have brain for it.
Of course it is "nice to have" if this trigger event waiting time is adjustable in scope. What is right place for this adjustment? Where in menu system? What is default value? What are min and max limits? Now if user set it for some value he just need, then next time he use scope it is just wrong.
In Siglent this time is bit more short than in many others but least I have heard ranting when noobs use scope and they start measure some DC and then they are barking because scope is so slow... and his DMM is more fast.
It is so simple. If this time is too short and specially if signal under test is variable so that trigger event repeating is just around this time some times bit slower aor some times bit faster there is exactly one and fast solution. Push one button. Trig Normal what is main mode in oscilloscope when user know what he is doing and what is signal under test. But because scope is for analyze "unknown" signals it is good its default is Trig Auto. Just after then User can see what is signal he can set trigger and continue with Normal mode. Even its name tell, it IS Normal. But "many kind of peoples" like Auto mode and then they have made this practice as "Normal". Training...training...training... and finally Normal is Normal and Trig Auto is not normal. Is is "Normal" for "probing randomly - without any further thinking this - and that"
Final :)
* Siglent, Please add "Trig Auto" mode trigger waiting time adjustable or least selectable fast and slow (fast as it is now and slow as old Tek)
* For users, Normal = Trig Normal If your "normal" is "Trig Auto". Think carefully why you have stopped learning curve for this level.
More wishes.
* Please finally wake up and add manual [Trig] aka [Force Trig] button.
Not so seriously but more seriously... development need develop...
-
@rf-loop,
I agree with you that Auto/Normal is very confusing to beginners. Or even sometimes to some that used single scope from single brand for many years, and they switch to other brand and they think something is broken..
I would like to reiterate on your points.
1. Force trigger button (Manual trigger) - I also don't understand how some manufacturers don't get it that is most needed and basic function. It's a scope, not a TV. It needs Force trigger button, a physical one. That is how you make it show something when in Normal mode and it's not triggering. So you press Force to see if you're not triggering, or you are triggering and trace is off the screen...
2. With that said, PLEASE, scope NEEDS physical trigg'ed light that blinks when you're triggering, so you can see something blinking with your peripheral vision. SDS2000x+ actually has it (Yeeeee), but there are some quite expensive scopes that don't have it. I'm looking at you Keysight, DSOX3000T doesn't have Trigg'ed light. I connected a LED with a resistor to the Trig out BNC to see something. If you made a stupid decision to not put light, then at least make LED in Run (or Single) blink (or switch it off for 50ms) when it triggers. Make something, anything, blink when it triggers. Please.
3. To answer to RF-loop, place to put Auto trig timeout would be in the same menu where you select Normal/Auto and make it Normal/Auto/User timeout.
4. I was even thinking, scope could calculate short term trigger frequency (if there is existing trigger) and make Auto timeout larger than that, slowing it down adaptively to make it automatically Normal trigger if there are trigger events existing. And if it timeouts once, start auto triggering faster, until there is trigger event....And then again slow down,
I agree with you that Normal mode is , well, normal, but many users do consider Auto default mode. That is aggravated by the fact that most scopes come with Auto as default, because they want scope to show at least something on the screen, even nonsense, so users don't think it doesn't work...
Most people simply scope around the circuit, just to see what's there. And they expect (wrongly, I agree) it to behave like a multimeter that will autorange and switch modes. Picoscopes even have autoranging for vertical channels, to make it behave just like multimeter. To me it's actually kinda confusing. I expect scopes NOT to behave like that. But, I did use it few times and I could see it being useful if something was made for the scale numbers would be bigger and more visible, so you can easily see the scale..
-
Most people simply scope around the circuit, just to see what's there. And they expect (wrongly, I agree) it to behave like a multimeter that will autorange and switch modes. Picoscopes even have autoranging for vertical channels, to make it behave just like multimeter. To me it's actually kinda confusing. I expect scopes NOT to behave like that. But, I did use it few times and I could see it being useful if something was made for the scale numbers would be bigger and more visible, so you can easily see the scale..
That's an interesting concept and if we consider using the Autoset feature capabilities autoranging could be added into the UI as a user selectable option for vertical attenuation.
Coarse, Fine, Autorange
:popcorn:
-
@all
SDS-2104x-PLUS firmware 1.3.7R5
I tried to use the bode-plot feature of the scope for the first time
and discovered some oddities.
I used the internal AWG connected its output to an 50 Ohm resisitive
splitter and fed its output to ch1 and ch2 via 2 BNC-cables of equal
length.
So the DUT is just one of the cables.
Sweep is from 25.5 to 30 MHz.
I expected two straight lines. One for phase and one for amplitude.
I got them, see bode-good.jpg. But more often I got something like
bode-bad.jpg in different variations.
Same behavior shows up with an external SDG6052x AWG instead of
the internal one.
Appended is another plot made with the external AWG, SDG6052x.
Here a steep HP-filter with an fg of 1.8 MHz got plotted.
To save time the measurement was stopped as there were enough amplitude jumps in the passband visible.
The HP-characteristic is visible but also these strange jumps.
Is it me or the scope(+ built in /external AWG) doing something wrong?
-
Did you set the input from the generator to the scope to 50 Ohm. Otherwise you'll see any kind of resonance from the cable.
-
I recall having seen similar figures when acquiring was set to sequence mode on.
-
About Auto-Trigger and other triggers, just to beat that (dead) Pony again.
I made a few tests on the frequency of the sweeps in Auto-Trigger mode depending on Memory depth and time base. So here is the first table, Trig frequency in relation to Mem depth and Window size. The column Sweep Time/period tells, how much of the "real" time id covered by the traces.
Mem depth Window size Trig frequency Sweep time/period
@ 100µs/div
20k 20k 805 80,5%
200k 200k 642 64,2%
2M 2M 215 21,5%
20M 2M 215 21,5%
200M 2M 215 21,5%
Next table: Trigger frequency depending on the time base setting both for standard acquisition modes and sequence mode, taken with 20k memory depth.
20k Aquiring dept
Timebase sec/div Trig freq sweep time/period Trig freq sweep time/period
Standard Acq Sequenc Acq
10E-09 22222 0,2% 303000 3,0%
100E-09 21790 2,2% 333000 33,3%
1E-06 8900 8,9% 82000 82,0%
10E-06 4329 43,3% 8700 87,0%
100E-06 805 80,5% 889 88,9%
1E-03 30,6 30,6% 89 89,0%
10E-03 8,7 87,0% 8,9 89,0%
100E-03 0,88 88,0% 0,89 89,0%
The trigger frequency was taken from the Trig Out signal and determined with a counter and PC logic analyzer. Interesting is, that the real time coverage gets pretty low for small time/div values.
What was also kind of unexpected to see was, that for low time/div rates the sweeps come in bursts with a period of about 30 ms. See the attached picture,
-
roberth, thank you.
The scope indeed was in sequence mode.
Silly me :palm:
Aquisition set to normal mode and it worked like a charm ..
-
You're welcome. I knew it since I made the same mistake before.
Nevertheless it would be an improvement if the firmware disables sequence mode upon entering the Bode Plot feature.
-
I already phoned the same wish to Batronix.
And I hope tautech will write it to Siglent as well.
-
I have owned my 2104X-plus for 3 weeks now and found some problems (Latest Firmware: 1.3.7R5)
Problem 1:
Single shot in combination with zone trigger:
When I tested a square wave output in an embedded system, I noticed a voltage drop in the signal maybe every five
seconds. I wanted to have a closer look on this and enabled the zone trigger. Everything worked perfect at least in normal
trigger mode. As soon I switched to single shot no signal could be acquired. Switching back to normal mode everything was
OK again and I got new pictures every 5 seconds.
Can anybody confirm this or do I make a mistake here ?
Find attached a screenshot of the signal
Problem 2:
After shutting-down the scope and rebooting not all settings are restored
I moved the position of decoder signal up and enabled the result list. After rebooting at least these settings weren't restored.
I also have some wishes for the scope:
-------------------------------------------
- Filter functions
- Support for a WLAN USB-stick
- adding a library for the labels which you can enable for the channels. Find attached a (bad) photo of my Rigol MSO 5000 in office
-
I have owned my 2104X-plus for 3 weeks now and found some problems:
Problem 1:
Single shot in combination with zone trigger:
When I tested a square wave output in an embedded system, I noticed a voltage drop in the signal maybe every five
seconds. I wanted to have a closer look on this and enabled the zone trigger. Everything worked perfect at least in normal
trigger mode. As soon I switched to single shot no signal could be acquired. Switching back to normal mode everything was
OK again and I got new pictures every 5 seconds.
Can anybody confirm this or do I make a mistake here ?
Find attached a screenshot of the signal
Problem 2:
After shutting-down the scope and rebooting not all settings are restored
I moved the position of decoder signal up and enabled the result list. After rebooting at least these settings weren't restored.
I also have some wishes for the scope:
-------------------------------------------
- Filter functions
- Support for a WLAN USB-stick
- adding a library for the labels which you can enable for the channels. Find attached a (bad) photo of my Rigol MSO 5000 in office
Please Edit your post to include the firmware version.
-
Please Edit your post to include the firmware version.
Looking at the screen picture's display of the channel it looks like 1.3.7R5.
-
Please Edit your post to include the firmware version.
Looking at the screen picture's display of the channel it looks like 1.3.7R5.
Maybe so but we must train some to include the FW version always. ;)
-
Indeed firmware is revision 1.3.7R5. I wrote this already I think.
An automatism should switch to normal mode if bode plot gets selected.
I believe this will be easy to realize in a further firmware revision.
Another point I have found is, the second channel of the SDG is forgotten to be switched
on at bode plot. One has to do that manually, then all is fine.
In normal mode and bode plot all works very fine now, good dynamic range, fine resolution.
Did some fine measuerments already.
This is the plot of an 9th order elliptic high pass filter.
[attach=2]
The SDS2104X-Plus is a very good instrument of great complexity and therefore
it is normal/natrual that there are some quirks, but we know that these will be fixed
by Siglent in a time that can be experienced.
This gives me the good feeling to have not bet on the wrong horse.
I also own an SDG6054x and an SSA3021x and I am very satisfied about
what measurement power /accuracy I have got for my money.
-
SDS2204 revision 1.3.7R5 + SDG6052.
Bode Plot:
Target IP is not persistive. Editing is cumberstone, first you have to clear the whole field with backspace, switch to Symbol and type in the whole IP character by character.
Entering Bodeplot switches the associated input channels to AC and Fine Adjust. It does not restore input settings after leaving Bode Plot.
Dispite of sope upgrade to 500Mhz, max. Frequency is limited to 120 MHz. This make Bodeplot unusable for HAM Radio applications in 2m and 70cm Bands.
-
@dl2xy
"Dispite of sope upgrade to 500Mhz, max. Frequency is limited to 120 MHz. This make Bodeplot unusable for HAM Radio applications in 2m and 70cm Bands."
This sadly is true. I have to confirm Bode plot is limitited to a range of up to 120 MHz with my also 'upgraded' SDS2104x PLUS. (firmware 1.3.7R5)
Higher frequencies are then the business of a vector analyzer ..
Anyhow I am happy I have got this feature surrounded by a very good 500 MHz scope as well.
The all in one box (for nearly no money) remains a dream (for now ..).
73
-
@ kaldit,
That's exactly what I did, except I only have the SDG2042X. The SDG upgraded to 120MHz, the SDS is upgraded to 350MHz for now, I'll upgrade to 500MHZ later when I need the extra BW. The SSA upgraded to 3.2GHz and VNA enabled. I'm new to Siglent, and at first a little concerned about going with an unknown brand to me (only used HP/Agilent/KS, Tek, Fluke and R&S gear before retiring) but every one of these instruments has exceeded my expectations.
BTW this reminds me if folks are interested, need to put together (for the Bode Plot) an interesting active filter that creates a 3rd Order Butterworth Low Pass with 3 equal value resistors and 3 equal value capacitors, swapping the resistors and capacitors converts to a 3rd Order Butterworth High Pass, all based upon the polynomial S^3 + 2*S^2 +2*S +1.
Good choices,
Best,
Edit: Just upgraded the SDS to 500MHz with the kind help from tv84. Did a quick BW measurement, the 500MHz is a fib!!!! It's ~615MHz :o :-+
Mike
-
SDS2104x-plus, 1.3.7R5, Manchester Decoder
On additional note about that decoder, which I forgot. It works mostly right. Just the last byte of a message will not be decoded, unless at least one trailing bit follows. It may not be a real issue if all practical applications send a few trailing bits after the last data bit. But the trailing bit is not needed for decoding.
Edit: It depends on the value of the last bit sent, whether the last byte will be decoded well.
But: Other decoder products like in the Saleae Logic software of the KingstVIS software do not have that limitation in decoding.
-
I originally posted the message below in a new thread (Siglent SDS2104X Plus, major last minute concern); Martin72 kindly suggested I might do better here. I have since learned that Siglent has indicated they will implement decode search at some point.
I have now read all the messages in this thread and I'm still concerned, even with the assurance of that feature's future arrival. For my use the logic analyzer section of this scope is at least as important as the analog section. I don't have experience working with the various protocols I'll face, so I'm in trouble if the (correctly configured) instrument doesn't trigger & decode correctly when fed a proper signal.
I've seen reports of decodes failing on the Siglent while succeeding on other brands, and folks far more knowledgeable than me arguing as to whether or not this or that is a bug. Some seem to feel that one shouldn't expect the LA to function as well as it would in dedicated product.
Can I count on the LA to be a solid product, one that works as reliably as a dedicated unit? Can I count on Siglent to fix decoding/triggering bugs in the LA?
As a fallback, is there some way I can get the scope to stream data to the PC so I can handle it with something like sigrok/PusleView?
<Original Post>
Having assured myself that I can adapt to (or even learn to love) the 'Siglent/PicoScope' sample buffering strategy, I was ready to pull the trigger, but...I just read that the scope can't search decoded data? Is this true? Searching for 'search' in the manual isn't reassuring.
This seems a glaring omission. It never occurred to me Siglent would go to the effort to support these wonderful triggers and decodes, yet provide no way to examine the decoded data!
If the search hasn't been expanded to include this very necessary (for me) feature by now, must I assume it never will be? I guess I must.
I certainly don't want to export files to my PC just to search my data! Are there work-arounds - perhaps I can stream to something like sigrok/PulseView? While not a perfect solution, I guess I could live with that.
-
Hello,
Maybe it will be more effective than my requests to Rigol ....
It would be really great to do like R&S concerning the pass/fail test, namely to add the elapsed time.
It would be very very practical in some cases for me :)
If Siglent adds this little cherry on the cake, they will have my eternal respect :-*
(https://i.postimg.cc/1ttDnJnC/elapsed.jpg) (https://postimages.org/)
-
Hello,
Maybe it will be more effective than my requests to Rigol ....
It would be really great to do like R&S concerning the pass/fail test, namely to add the elapsed time.
It would be very very practical in some cases for me :)
If Siglent adds this little cherry on the cake, they will have my eternal respect :-*
While doing that it would be pretty much trivial to add statistics:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1125592;image)
[attachimg=1]
-
I originally posted this in the "General Siglent Support Thread" but thought this might be a better place for it.
I just recently got a new SDS2104X Plus scope, firmware version 1.3.7R5. The very first project I wanted to use it on has a serial data link which I hooked up to with the intention of decoding it with the logic analyzer UART decode function.
As it turns out this data link is using 125000 baud 9N1 serial settings, but the UART decode configuration only allows a maximum data length of 8. Everything else was configurable to match my situation except for the data length.
Would it be possible for Siglent to add 9-bit data length in a future firmware release?
-
Add fine tune timebase ability, please. A very useful option when you get used R&S and Keysight. Since "pressing the timebase knob" is already used to switch windows in "zoom mode", it would be possible to add a "Coarse" checkbox to the OSD menu, as it is done for vertical adjustment.
Also, I join the request to make "9 bits" for UART decoding, the 9-bit format is not so rarely used.
Max.
-
@rf-loop
This mysterious secret button name is "Trig"
Nearly every scope I have used in my life have been this simple button.
This loved child have many names... aka "force trig" or "manual trig" or what ever...
I just noticed that, when in single trigger state waiting for a trigger, pushing the "single" button again forces a sweep, and the device goes to stop mode.
So it's kind of what you liked to see.
-
Since the SDS5000X and the SDS2000X+ share the same software and this thread has much more attention, I dare to re-post my feature requests here:
- It would be great if not only the threshold for measurements was selectable but also the polarity. While it's nice that e.g. there is a positive and negative duty cycle measurement (which is missing even in some 1st brand scopes), there is e.g. no polarity selection for frequency. One might argue that polarity doesn't matter for frequency but this isn't generally true. E.g. a square wave created with a low side driver and a pullup will have a steeper and more stable falling edge. There are also mechanical systems measured with hall sensors where only the accuracy of one edge is well defined.
In a nutshell, I'd suggest to make polarity (or polarities) parameter(s) of all the horizontal measurement instead of using separate measurements to select polarity. This would also make the delay measurements much more manageable.
- I wonder if there is any chance to mimic the LeCroy way of zooming into a detail (by dragging a rectangle around the part of the signal you want to see). While you can get used to anything I guess, after more of a decade of using the LeCroy way of zooming, the Siglent way feels off.
-
@rf-loop
This mysterious secret button name is "Trig"
Nearly every scope I have used in my life have been this simple button.
This loved child have many names... aka "force trig" or "manual trig" or what ever...
I just noticed that, when in single trigger state waiting for a trigger, pushing the "single" button again forces a sweep, and the device goes to stop mode.
So it's kind of what you liked to see.
Of course I know this. Double push "single" in Siglent is partially as "force trig" but it is not same what is usual manual trig force button in many scopes, digitals and analogs. Of course I can be wrong and still need learn something after 60 years with oscilloscopes. I am never ready made.
-
I wonder if there is any chance to mimic the LeCroy way of zooming into a detail (by dragging a rectangle around the part of the signal you want to see). While you can get used to anything I guess, after more of a decade of using the LeCroy way of zooming, the Siglent way feels off.
That sounds good and is an intuitive approach for a touch supported device. It also happens to me quite often that Zoom starts a too much zoomed level, and I have to dial back a lot.
-
Double push "single" in Siglent is partially as "force trig" but it is not same what is usual manual trig force button in many scopes, digitals and analogs.
Of course it's not the same. It requires too many pushes to be convenient. The scope then changes to stop mode, so you have to set the device back to single mode. And there is nothing compatible in Normal mode.
-
Feature:
THD/SHD viewing in FFT mode in % (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3373222/#msg3373222)
Would be a very nice thing to have, makes it easier when you musn´t do this manually...
(At work, I shift the groundwave to "0dB" and then counting the harmonics and calculate the value in %)
Should be relatively easy to implement it in the software.
-
Just got a SDS2104X+ and have been trying out the Bode plot facility. That is actually better in some respects than my other scope (RTM3k) which is limited to the internal gen at 25MHz max. Not that you can use it that much higher as probes start giving increasingly erratic results at higher frequencies. It is quite a bit slower than the R&S though.
But one thing that is irritating is the 'Operation' switch. I can't see the point of having it run continuously; a simple 'Run' button (or even make use of the trigger Run button) would make things much more user friendly.
-
Hello,
Maybe it will be more effective than my requests to Rigol ....
It would be really great to do like R&S concerning the pass/fail test, namely to add the elapsed time.
It would be very very practical in some cases for me :)
If Siglent adds this little cherry on the cake, they will have my eternal respect :-*
(https://i.postimg.cc/1ttDnJnC/elapsed.jpg) (https://postimages.org/)
Not familiar with the pass/fail tests, but a timestamp on the fails would be really useful.
-
SDS2104XP - 1.3.7R5
I couldn't find it anywhere, so: I want to be able to disable the pop-up confirmation boxes. For example, for default or auto setup, I want it to happen as soon as I hit the button, no pop-up needed.
Here's a silly thing that should be adjusted. If two channels have labels, only one will be visible if the channels line up. The labels should be offset. Images attached.
Thanks,
Josh
-
"I installed a skylight in my apartment yesterday... The people who live above me are furious." - Steven Wright
I haven't watch Mr. Wright in ages. Thanks for reminding me to head to YouTube and enjoy a performance or two!
-
Bug: moving the waveform around on the screen (vertically or horizontally), regardless of how many other things are being displayed, should be buttery smooth and fluid, and the same is true for changing the timebase and volts/div. It would be an excuse if the scope continued to capture and process data while these operations were being performed, but the plain fact is that when you're performing these operations, the scope seems to stop everything in its tracks, at least from what I can tell. It nukes the history buffer, it stops all triggering (as determined by monitoring the trigger output), and seems to stop all other processing. This means there is no excuse in the slightest for these operations to be anything other than instantaneous and buttery smooth, because these operations seem to have the CPU all to themselves while one is moving the controls. The scope should resume operation some small (from the point of view of the user) but significant (from the point of view of the scope) amount of time after one stops moving the knobs, e.g. a tenth of a second later or something, so that responsiveness remains maximized while the user is moving the controls. It may be that the scope already behaves this way but that the amount of time allowed before processing is resumed is too small, in which case this feature request is just a request to increase that "dead time".
Feature request: single-shot captures should always use the entirety of the scope's memory, irrespective of the timebase setting. The reason is that hitting the "single" button will nuke the history, thus automatically eliminating any reason to not use that memory, and hitting "normal" or "auto" afterwards will likewise nuke the single frame that was captured via "single", thus eliminating any reason for limiting the memory size of the single capture. As such, the act of performing a single capture under the current implementation guarantees that all of the memory not needed for the time window represented by the display will be completely unused. In light of this, it is clearly appropriate for the scope to begin sampling immediately upon the "single" button being pressed and for the sampling to continue after the trigger fires until half of the memory is used for pre-trigger data and half of the memory is used for post-trigger data (or, when the amount of time between the "single" button being pressed and the time the trigger fires is less than half the time represented by all available memory at the current sampling rate, then the remaining memory not used by pre-trigger data would be filled with post-trigger data).
Feature request: with the scope stopped, serial decoding enabled, and while zoomed into a section of the capture (whether or not in zoom mode), and with the decode list enabled, make it possible for a press of the multifunction knob to move the view to the currently selected list entry. Right now, pressing the knob does nothing, and it clearly would be useful to be able to instantaneously move to the currently selected list item. As a general rule, if you have a list of events that derive from the capture and you're zoomed into the capture, selecting a list item in the above manner should always take you to the location of the event represented by the list item. So this isn't necessarily going to be limited to serial decoding events -- it could be anything at all.
Feature request: right now, the maximum trigger rate is primarily determined by the time window represented by the screen (as determined by the timebase settings). The more time the screen represents, the longer the minimum amount of time between trigger events seen by the scope. The end result is that the more time one wants to capture, the longer the amount of time between captures. The lower bound on the time between captures is thus the time represented by the display, and it appears that the trigger is not re-armed until the amount of time represented by the screen has elapsed. But this needn't be the case at all, and shouldn't be the case. Rather, the amount of time before the trigger is re-armed should be the amount of time between the current trigger location and the right edge of the screen. Meaning, the closer to the right edge of the screen you move the trigger point, the more quickly it should re-arm the trigger. Once the time passes the right edge of the screen, the current memory buffer should be saved and the trigger should be re-armed. While this could result in back-to-back captures containing overlapping time regions, it could (if the amount of time between trigger location and the right edge of the screen is small enough) greatly increase the trigger event rate without changing the basic principle of operation that says that the size of the capture is defined by the time width of the screen.
-
Feature request: right now, the maximum trigger rate is primarily determined by the time window represented by the screen (as determined by the timebase settings). The more time the screen represents, the longer the minimum amount of time between trigger events seen by the scope. The end result is that the more time one wants to capture, the longer the amount of time between captures. The lower bound on the time between captures is thus the time represented by the display, and it appears that the trigger is not re-armed until the amount of time represented by the screen has elapsed. But this needn't be the case at all, and shouldn't be the case. Rather, the amount of time before the trigger is re-armed should be the amount of time between the current trigger location and the right edge of the screen. Meaning, the closer to the right edge of the screen you move the trigger point, the more quickly it should re-arm the trigger. Once the time passes the right edge of the screen, the current memory buffer should be saved and the trigger should be re-armed. While this could result in back-to-back captures containing overlapping time regions, it could (if the amount of time between trigger location and the right edge of the screen is small enough) greatly increase the trigger event rate without changing the basic principle of operation that says that the size of the capture is defined by the time width of the screen.
Let's think about this one, shall we...
It is not a analog scope. Retrigger time on digital scope is pretty much nil. Keysight 3000T actually triggers at 20MHz trigger rate without problems. At certain short timebase, retrigger time is about 200ns in segmented mode. They don't even publish this.. Their spec is very conservative here.. In normal displayed mode it is much slower... When looking at trigger out, you will notice that it keeps triggering even while sweep is in progress.. And it is useless for normal scope operation, there are some other uses for this, but for classic scope operation it is not useful.
But...
Digital scope triggering rate is defined by very short time needed for triggering FSM to be primed for new trigger (that can be made very quick) and by time needed for captured data is measured and prepared for display engine, and then with time display engine is ready for new data.
That is the reason that segmented captures are faster, you need to wait for the display.
And when you're displaying data, it has to process all the pixels and data points, those before and after trigger point, whatever should be on the screen.
Overlapping triggered data doesn't make sense, and there are no scopes that do that. That is a waste of memory.
That is why you have long memory scopes, just grab 120 events at the same time and look at that... That guarantees zero (0) retrigger time.
Every time when we have an idea how to solve something, we need to remember hammer and a nail principle.
Usually, what seems like a good idea at the time, someone else solved already, by using different approach, and if many people before us thought about same problem, usually there is a better and more elegant solution...
For instance, for your first request, I would rather that, when I press Single, it doesn't grab a full memory (which on slower time bases can be quite some time too), but to rather not delete history buffers. I didn't know it did that, it shouldn't delete history..
Scope shouldn't start anything immediately in single mode. It has to wait for trigger. You use Single to capture important trigger event and then stop.
When setting time base and trigger position you setup how long the capture should be, sample rate and trigger position. And scope will get exactly that. If you set up trigger position at half the screen it will be 50/50% pre and post.
And if they fix that Single works with history buffers you could set set each Single capture to be fraction of the memory, so you could get, say, 10 or 20 events and then analyse and compare them.
Much more useful than grabbing all the memory all the time, even when I need something else. If I want long capture, I just set it for long capture. If you want to look at detail, just zoom in to it.
If zoom mode is awkward to use, than we should pester Siglent to make zoom mode nice and easy to use.
I have a Picoscope that handles memory same as Siglent and LeCroy.
The way that zoom is implemented in GUI, combined with large screen and arbitrary number and layout of viewport windows makes it fantastic to use.
Using deterministic full captures and zoom viewports is superior way to deal with the problem. Only problem is if zoom implementation in GUI is not optimal.
I apologize if I didn't explain this in a way that is understandable. If need be, I can grab a few screenshots to illustrate what I mean here..
Regards and Happy holidays to all..
-
It is not a analog scope. Retrigger time on digital scope is pretty much nil. Keysight 3000T actually triggers at 20MHz trigger rate without problems. At certain short timebase, retrigger time is about 200ns in segmented mode. They don't even publish this.. Their spec is very conservative here.. In normal displayed mode it is much slower... When looking at trigger out, you will notice that it keeps triggering even while sweep is in progress.. And it is useless for normal scope operation, there are some other uses for this, but for classic scope operation it is not useful.
But...
Digital scope triggering rate is defined by very short time needed for triggering FSM to be primed for new trigger (that can be made very quick) and by time needed for captured data is measured and prepared for display engine, and then with time display engine is ready for new data.
That is the reason that segmented captures are faster, you need to wait for the display.
And when you're displaying data, it has to process all the pixels and data points, those before and after trigger point, whatever should be on the screen.
Overlapping triggered data doesn't make sense, and there are no scopes that do that. That is a waste of memory.
That is why you have long memory scopes, just grab 120 events at the same time and look at that... That guarantees zero (0) retrigger time.
I mentioned the approach I did because I presumed that the truly superior way of doing it would be something that would require so much in the way of software changes that it wouldn't be reasonably feasible for Siglent to do. Namely, that the truly proper way of doing it would be to make the capture (I define "capture" here as meaning a single contiguous set of recorded samples, while a "segment" is a capture plus a trigger point) be variable size, with the minimum size being that of the time width represented by the display and the maximum size being that of the entirety of memory, and the point at which a capture ends is when the time between the last trigger event and the current time exceeds the time distance between the trigger location on the screen and the right edge of the display (if memory is exhausted and the entirety of memory represents a single capture, then you'll have to prune your current capture from the left hand side in order to free it for current samples). You record all of the trigger events that occurred within that capture and that, along with the capture itself, is what you store. Operationally, since the memory acts as a circular buffer, you would need to be able to prune the oldest capture from its left side in order to free memory for the current capture (and it's entirely possible that the oldest capture is the current capture -- the principle of pruning would remain the same). If the oldest capture contains just a single trigger point then you obviously free up that entire capture for use in the current one.
What the user sees after stopping the scope and going into the history would then depend on his timebase and offset settings. He could change his timebase in order to see more or less of the capture, and playing the history forward would shift his view within the larger capture so that each trigger point would be centered on the trigger location he's selected (center screen by default). If memory contains multiple disjoint captures (as would be the case when the distance between two trigger points exceeds the time between the trigger location and the right edge of the screen at the time the later trigger event fired), then moving from the last trigger point in the previous capture to the first trigger point in the next capture would, of course, show up on the display appropriately as one would expect. The end result is that replaying the history would, by default, look very much like it does now, but with greater ability to examine the waveform associated with multiple closely-spaced trigger events. Zooming out relative to the originally specified timebase would become feasible depending on whether or not multiple trigger events are represented within the currently viewed capture.
This approach has at least a couple of advantages over Siglent's current approach. The waveform update rate can now remain at the maximum the scope is capable of or the rate at which trigger events actually occurs, whichever is smaller. The scope can now potentially store many more history "segments" than it currently can because each "segment" is just a pointer to a trigger event within a capture and there can be many such pointers for a given capture. Of course, these pointers also take up memory, but clearly a pointer takes up much less memory than even the smallest of captures. And actually, whether or not you need to store the trigger locations depends on whether or not the trigger locations can be reconstructed from the capture data. If they can be reconstructed then you can do that at history viewing time. But whether they can be reconstructed depends on the capture sample rate relative to the scope's native sample rate -- the trigger system always operates at the latter rate irrespective of the former rate.
The problem that I'm trying to solve here is one that other oscilloscopes solve by arranging their capture update rate to match that of what's displayed on the screen while arranging for the final capture to occupy the entirety of memory, so that when the scope stops you can, depending on the sample rate and the amount of time represented by the screen, get much more in the way of capture to examine than just what the screen shows. The Siglent always gets you captures that are limited to the screen's time width, irrespective of how much memory is available. Instead of using the additional memory for additional off-screen capture time, the Siglent uses the rest of memory for additional historical segments. I rather like Siglent's general approach here, but see no good reason that the capture rate must be capped by the amount of time represented by the screen. What I'm proposing is a way of getting both a heightened waveform rate and a larger capture, all the while remaining faithful to Siglent's "what you see is all you get" approach to capture management.
As regards the trigger delay, here's the thing: if you want the trigger to be delayed by some amount before it can fire again, there is already a direct way to accomplish that: the trigger holdoff value. Given the availability of that value, I see no good reason to impose another arbitrary limitation on when the trigger can fire again, assuming you don't prematurely run out of some resource (like memory) as a consequence of allowing it to fire too quickly. The history should be a reflection of when the trigger conditions were met and nothing else. If you want to space out the trigger events, you impose a holdoff time.
For instance, for your first request, I would rather that, when I press Single, it doesn't grab a full memory (which on slower time bases can be quite some time too), but to rather not delete history buffers. I didn't know it did that, it shouldn't delete history..
There turn out to be multiple things that cause the history to get nuked. Just moving the waveform up or down will do that, as will shifting the trigger point.
Scope shouldn't start anything immediately in single mode. It has to wait for trigger.
Yes, but if it doesn't even bother to start capturing data before it detects the trigger then you'll get no data prior to the trigger point. No, if you want data preceding the trigger, you have no choice but to start recording samples immediately when the "single" button is pressed, and you stop recording only after the requisite amount of time past the trigger event. And it can't be any other way, obviously, because the scope simply doesn't know at what point the trigger will fire once you hit the "single" button.
You use Single to capture important trigger event and then stop.
When setting time base and trigger position you setup how long the capture should be, sample rate and trigger position. And scope will get exactly that. If you set up trigger position at half the screen it will be 50/50% pre and post.
And if doing so didn't nuke your history, then it would be perfectly reasonable to do that. But if Siglent insists upon nuking your history and not even retaining your single capture once you start normal or auto triggering, then it's clearly better for them to use the entirety of memory for the capture than it is for them to leave the memory unused. But I agree with your general assessment here. See below.
And if they fix that Single works with history buffers you could set set each Single capture to be fraction of the memory, so you could get, say, 10 or 20 events and then analyse and compare them.
Much more useful than grabbing all the memory all the time, even when I need something else. If I want long capture, I just set it for long capture. If you want to look at detail, just zoom in to it.
If zoom mode is awkward to use, than we should pester Siglent to make zoom mode nice and easy to use.
I completely agree. It is certainly better for them to retain the segments across multiple invocations of the trigger buttons (whether "auto", "normal", or "single"), and let the user decide for himself what to do next. As you say, you can manually arrange to use the entirety of memory for a single capture if you so choose -- it's just a question of setting the appropriate timebase and memory depth.
-
Uh, so much text in the last posts... :D
So what is now the bug in short form ?
-
There turn out to be multiple things that cause the history to get nuked. Just moving the waveform up or down will do that, as will shifting the trigger point.
Do I understand correctly that merely adjusting the position of the displayed waveform nukes history?
-
No, I keep repeating scope already can do that in superior way with no redundant (overlapping)data.
You capture the lot, full 100 ms of it, and use search to find all of the points that you would usually trigger on.
Also I nowhere mentioned trigger delay. If you fit whole event in a screen, by using proper timebase for it, you can set trigger point in reference to where in capture buffer it will be. So on a trigger event you get 20ms of data, 10 before and 10 after the trigger.. It is all visible on the screen and clearly defined. No need for mental acrobatics...
You have to decouple in your mind sampled data buffer and viewpoint (zoom). Once you have buffer you can zoom in and traverse anywhere in the buffer..
Also scopes do all kinds of tricks managing the memory, both in hardware and in software, and between separate buffers, not necessarily in same memory space or even physical chips . To make it deterministic and as fast as possible, not all kind of buffoonery is realistically possible.
Zoom mode should be designed to be as efficient and ergonomic as possible. Maybe a bit more control of screen use.
History mode should be made to better retain useful data.
Some data should not be retained in history, maybe, user might not want to keep old data after they changed some settings, because it makes old captures not something comparable with new ones. Or it can be left to user to choose.
Enhance history/segemented buffer handling analysis.
Enhance search.
Etc etc.
No need to invent arcane contraptions to fix usability problems stemming from some features not being fully or most elegantly implemented. Most logical, easiest correct way is to fix/upgrade those to full potential of architecture. Otherwise you end up with spaghetti monster that is confusing and does nothing right.
-
There turn out to be multiple things that cause the history to get nuked. Just moving the waveform up or down will do that, as will shifting the trigger point.
Do I understand correctly that merely adjusting the position of the displayed waveform nukes history?
You do indeed.
-
No, I keep repeating scope already can do that in superior way with no redundant (overlapping)data.
Sure, it can. But the downside is that, firstly, the waveform update rate is now limited by the time width of the capture and, secondly, you now need two independent trigger identification implementations in order to see all of the trigger events one of which (search) only has access to decimated data and thus could easily fail to see trigger events that were actually present. That you need two completely different trigger detection implementations is, in part, why the search is a very small subset of the trigger set -- it requires that much additional effort to implement. The only real upside to having a trigger event search is that it makes it possible for you to look for trigger events that differ in their characteristics from the trigger setup that resulted in the capture.
You capture the lot, full 100 ms of it, and use search to find all of the points that you would usually trigger on.
That's not necessarily good enough. Search only has access to decimated data. The trigger mechanism has access to the full sample rate of the scope at all times. The two are not comparable except by chance.
Also I nowhere mentioned trigger delay. If you fit whole event in a screen, by using proper timebase for it, you can set trigger point in reference to where in capture buffer it will be. So on a trigger event you get 20ms of data, 10 before and 10 after the trigger.. It is all visible on the screen and clearly defined. No need for mental acrobatics...
Nothing prevents that from remaining the case. In the implementation I outlined, the trigger point, by its position, guarantees the minimum amount of data that will be captured before and after any given trigger point. It still has the meaning one would expect.
The difference is that the implementation I outlined ensures that the scope will save all of the trigger events that the trigger system is capable of seeing irrespective of your timebase setting. Save for the additional memory that the pointers would need (and that could be considerable), I see no downside to this in principle.
I mentioned the trigger holdoff because right now, the trigger re-arming mechanism has an implied holdoff based on the time width of the screen, and my proposed implementation does away with that.
You have to decouple in your mind sampled data buffer and viewpoint (zoom). Once you have buffer you can zoom in and traverse anywhere in the buffer..
I do decouple that. In the implementation I outlined, a capture is just a contiguous series of samples that are bundled into a single entity. Its beginning is defined by the left edge of the screen and the trigger point. Its end is defined by the right edge of the screen relative to the first trigger event in the series that had a time delta between it and the subsequent trigger point greater than the amount of time between the trigger point definition and the right edge of the screen. The capture is an internal representation.
For presentation purposes, the manufacturer would have a couple of options. He could arrange things so that the history always shows the same size segments as it does right now, and moving to the next history entry just has the effect of showing that subset of the capture that the screen defined at the time of capture. The only difference between the current implementation and this is that, for the implementation under discussion, the time delta between two subsequent history events could be much smaller than the screen time width as it was at the time of capture, while the current implementation imposes the screen time width as the minimum time between history events.
Or the manufacturer could (and I would argue should, given the data the system would make available), make moving to a new history frame show you the portion of the waveform on the screen relative to that trigger event in the history frame, but instead of limiting the data in the frame to that which was represented by the screen's time width at the time of capture, it would allow you to see the entire capture if you zoom out enough. Which is to say, if the capture itself occupies more time than what the screen's time width at time of capture was, then you should be able to see everything in it if you so choose, or zoom in to any part of it, as you so choose. Your position in the history list would then be dictated by which capture you're looking at and where your view of the capture is relative to a history event, and you should be able to move between history events (really, recorded trigger events) either by moving within the list or by moving within the capture, as you see fit.
Also scopes do all kinds of tricks managing the memory, both in hardware and in software, and between separate buffers, not necessarily in same memory space or even physical chips . To make it deterministic and as fast as possible, not all kind of buffoonery is realistically possible.
Oh, I'm quite well aware of that. I don't claim that what I'm proposing here is possible without faster hardware. On that, I simply can't say.
Zoom mode should be designed to be as efficient and ergonomic as possible. Maybe a bit more control of screen use.
History mode should be made to better retain useful data.
Some data should not be retained in history, maybe, user might not want to keep old data after they changed some settings, because it makes old captures not something comparable with new ones. Or it can be left to user to choose.
I completely agree.
Enhance history/segemented buffer handling analysis.
Enhance search.
Etc etc.
No need to invent arcane contraptions to fix usability problems stemming from some features not being fully or most elegantly implemented. Most logical, easiest correct way is to fix/upgrade those to full potential of architecture. Otherwise you end up with spaghetti monster that is confusing and does nothing right.
You'd certainly need to keep things simple and understandable for the user, no question about that. I don't see why that isn't possible while doing what I described.
Remember: the purpose of what I described is to make it possible to see trigger events that currently go completely unnoticed even though they were present, without sacrificing capture length in the process. Put another way, trigger events and capture length should be decoupled, and right now they're not.
-
Uh, so much text in the last posts... :D
So what is now the bug in short form ?
Heh.
Well, two bugs so far.
Firstly, changing the waveform position, volts/div, or timebase, should be smooth as butter. Right now it's not, and given that the scope stops everything in its tracks when you're doing any of this, I see no reason for it to not be.
Secondly, there are multiple circumstances in which the history buffer is nuked, and it probably shouldn't be. Why should changing the voltage offset or volts/div nuke the history buffer?? I can think of no good reason for that. Changing the timebase, sure, I could see some justification for that (lame as it might be), since doing that could change the memory required by a capture.
-
Hi,
The second could be a bug, in my opinion.
For the first I wasn´t sure actually, but I´ve seen this behaviour on other scope brands as well.
Check this next year on our lecroy scopes at work.
BTW, still "buggy":
When activating the power analyzer, additional activated channels won´t be deactivated when deactivate this function, instead they remain, you have to turn them off manually.
The same was by using the bode plot - I don´t check this after the new firmware, but when the power analyzer thing is still the same, I think, the bode bug will still remains.
Check this tomorrow.
-
Hi,
The second could be a bug, in my opinion.
For the first I wasn´t sure actually, but I´ve seen this behaviour on other scope brands as well.
It would be interesting to know if, firstly, those scopes also stop visual processing and, secondly and more importantly, whether they stop capturing. The Siglent does both, and that's why I regard it as a bug. If you're going to stop everything in its tracks, then you've got the entirety of the scope's processing power available to you for the purpose of handling the control inputs, so why in the world wouldn't it be buttery smooth?
-
Secondly, there are multiple circumstances in which the history buffer is nuked, and it probably shouldn't be. Why should changing the voltage offset or volts/div nuke the history buffer?? I can think of no good reason for that. Changing the timebase, sure, I could see some justification for that (lame as it might be), since doing that could change the memory required by a capture.
When you change settings after then all what is already in buffer is not anymore compatible with new incoming ones and so old need reset. Buffer do not include settings. You need know v/div, offset, t/div. If you loose them, what you can measure or what you compare. This is instrument for analyze signals not for record fun figures about smoke what goes inside copper wires and components (and some times smoke leaks out and things stop working).
Thinking helps more than questions. If instrument do not work as imagined instrument, where is bug.. in this imagined instrument or real instrument. If you do not see reasons you have not think enough and enough wise.
Just one poor very simple example.
You capture unknown signal and it is also filling acquisition buffer. Some time signal have changes, what ever changes, then also you twiddle adjustments as game machine joystic etc. After then you stop scope or it stops due to no trigger.
After then you go to look history and perhaps start inspect carefully these every wfm in this buffer for look what happen in signal. For every segment (wfm) in buffer fifo you may use automatic measurements, FFT, use cursors, gated measurements and what ever.
Who keep now book about what change in signal is based to your scope settings changes and what are based to signal itself changes. Do you think every single wfm is recorded with setup data header or even every ADC sample.
Of course all can do but you do not want pay it.
Simple solution is. Buffer include only data where all changes are in captured signal, so every single segment (wfm) is based to same settings and directly comparable, only variable is signal. It must be so and it is so - until we do something very very different animal.
Of course it can do so that it store continuous wfm with setup data, and if user change anything it must close this already stored data block and then make new block with new settings and after any change, again close this block and start new block with new settings. After then some player or journalist twiddle knobs and start ranting why this and why that...
Professional way to use instrument is first design what to measure and why, then design how to measure/analyze and in tghis point need be familiar with instrumet(s) used for this and then also design how to probe it without destroying signal, how to set scope for it and finally after brain work start moving muscle --- opposite road is... this forum is (partially) full of this.
;D Period. ;D
-
Just wanted to thank Siglent for the configurable colors.
I can finally tell channel 4 from channel 1 now. I know this happened in Nov but time off in the holidays let me notice the upgraded firmware version.
-
When you change settings after then all what is already in buffer is not anymore compatible with new incoming ones and so old need reset. Buffer do not include settings. You need know v/div, offset, t/div. If you loose them, what you can measure or what you compare. This is instrument for analyze signals not for record fun figures about smoke what goes inside copper wires and components.
It may be that Siglent's specific implementation of what is stored demands what you're talking about here, but that's implementation-specific. Nothing says that Siglent can't store the capture's specific parameters along with each capture, so as to be able to properly interpret the saved data, or store the timestamped capture parameters in a separate list so that captures can be properly reconstructed after the fact. Nor is there anything that says that Siglent can't simply store the voltage values directly, and a sample rate along with the trigger time, thus bypassing the entire problem (though that, of course, would require a conversion step as part of the primary acquisition loop, something that is likely to be more expensive than it's worth unless it can be pipelined so as to retain the existing throughput).
Thinking helps more than questions. If instrument do not work as imagined instrument, where is bug.. in this imagined instrument or real instrument. If you do not see reasons you have not think enough and enough wise.
Just one poor very simple example.
Perhaps. But at the same time, just because a given implementation doesn't do something doesn't automatically mean it can't or shouldn't do something. And neither does it mean that a different implementation would have the same limitations. All we see as users is what the scope presents to us. How exactly are we supposed to know that what we believe should be possible is, in fact, not? We can work backwards from what we see, but in doing so we end up having to make assumptions that aren't necessarily valid.
You capture unknown signal and it is also filling acquisition buffer. Some time signal have changes, what ever changes, then also you twiddle adjustments as game machine joystic etc. After then you stop scope or it stops due to no trigger.
After then you go to look history and perhaps start inspect carefully these every wfm in this buffer for look what happen in signal. For every segment (wfm) in buffer fifo you may use automatic measurements, FFT, use cursors, gated measurements and what ever.
Who keep now book about what change in signal is based to your scope settings changes and what are based to signal itself changes. Do you think every single wfm is recorded with setup data header or even every ADC sample.
Considering that all you need to record are the screen boundary parameters, the trigger location within those boundaries, and the voltage offset, and considering that most of the time, a capture's parameters will be the same as the previous one's, the amount of overhead represented by the data necessary to properly interpret a capture independently of the other captures isn't exactly overpowering unless you want to be inefficient in how you store it...
I mean, look, at the very least the current history already has to record the time of acquisition. So you're already recording a capture-specific piece of data for every capture: the trigger time. Recording the other parameters necessary to reconstruct the waveform isn't a major deal. As an even better alternative, as you say, you can simply store the requisite parameters into a linked list of such parameters immediately prior to the scope restarting acquisition, along with either a timestamp or a pointer to the last capture (which is the capture immediately before the one it would apply to), and then you'll have everything you need to properly reconstruct the waveform of any history entry.
There are probably lots of things that could be done, some of which represent minimal overhead. Siglent has chosen to simply nuke the entire history. While that's certainly the simplest approach, the simplest approach isn't always the best one.
Of course all can do but you do not want pay it.
Perhaps so. It would certainly be more overhead than what we currently have, admittedly.
Simple solution is. Buffer include only data where all changes are in captured signal, so every single segment (wfm) is based to same settings and directly comparable, only variable is signal. It must be so and it is so - until we do something very very different animal.
Of course it can do so that it store continuous wfm with setup data, and if user change anything it must close this already stored data block and then make new block with new settings and after any change, again close this block and start new block with new settings. After then some player or journalist twiddle knobs and start ranting why this and why that...
Journalists do that anyway. There's no escape. :)
Professional way to use instrument is first design what to measure and why, then design how to measure/analyze and in tghis point need be familiar with instrumet(s) used for this and then also design how to probe it without destroying signal, how to set scope for it and finally after brain work start moving muscle --- opposite road is... this forum is (partially) full of this.
;D Period. ;D
LOL. True. :)
It just seemed like a surprising limitation given the acquisition design of the scope. But I can certainly see how it simplifies things. In any case, I'm perfectly happy to call this out as a feature request and not a bug.
Now then: why does it nuke the history when you press the "normal" or "auto" button when the scope is already acquiring with that mode? >:D Actually, that probably should be regarded as a bug: the scope shouldn't nuke your history just because you change the trigger mode from "auto" to "normal" or even "single", because you're not changing anything about the acquisition mechanism that isn't already being recorded on a per-capture basis.
-
Bug: moving around or changing the zoom level of the zoomed portion of zoom mode, while the scope is running, nukes the history buffer. Say all you want about the necessity of nuking it when the acquisition parameters change -- there is no good reason at all for nuking it when the zoom mode view of the unchanged acquisition changes.
I also noticed that moving around like that stops acquisition while you're moving around. That's fine as far as it goes, seeing how it might be necessary to maintain the necessary responsiveness. But it shouldn't nuke the history as a side effect. They're probably just using common code for both this situation and the normal un-zoomed situation in which acquisition parameters are changing. It's still a bug.
-
Do I understand correctly that merely adjusting the position of the displayed waveform nukes history?
You do indeed.
I've responded in your "Christmas Present" thread, and it was this thread to which I referred.
I can't (don't want to) believe that nuking history like this was a design decision. Surely it's a bug that will soon be no more. Or an oversight that will be addressed. Or a design decision by a junior designer who will be counseled to make better decisions.
I pray it's not a decision forced by the hardware design; this seems most unlikely as automatic history is a major feature (according to Siglent's marketing team, at least). I await clarification from the horse's mouth.
-
<Interesting stuff removed>
You seem to have a firm grasp of how my new toy handles its buffers. New to the Siglent Way, I need to learn how this works, especially the implications and unwanted/unconsidered side-effects of which I am surely unaware. The manual tells me which buttons to push and little more.
Having pulled what was for me was an expensive trigger, new toy in hand, I seek deep understanding. How did you learn so much about how buffering works? Have you found a tech reference that spells everything out in detail?
Healthy Holidays and a Healthy New Year to You and Yours
-
I can't (don't want to) believe that nuking history like this was a design decision. Surely it's a bug that will soon be no more. Or an oversight that will be addressed. Or a design decision by a junior designer who will be counseled to make better decisions.
Well it's your prerogative to have an attitude, no matter how wrong you might be..
What is the use of history buffers? Something similar to command line history that simply takes historic record of all of trigger events in a past until it runs from the memory?
So it will remember, say, 1000 last triggers, regardless of you switching channels on and off, change timebase, vertical sensitivity and offset.....
So you can twiddle through history buffers, reliving nice memories of probing through your last repair.
Or you might want capture last 1000 triggers captured with exactly the same settings from first to last, so you can compare the data...
History buffers in Siglent are implemented for second scenario. Think of it as history buffers of current capture session (session being defined as group of captures with exactly the same settings)..
First scenario is not very useful. I could see it maybe useful for documentation, but you could simply keep pressing save button on screens you need and get it that way.
I heard similar argument some time ago when someone was outraged that changing settings clears the screen and restarts when in roll mode...
Not understanding that voltage/time diagram makes no sense when time (x) axis has random values...
Of course, it should clear and restart only if it is currently in RUN mode, or after you press RUN or SINGLE button. If you are in STOP mode (acquisitions stopped), no amount of button twiddling should touch memory.... If it does, that is a bug... You should be able to traverse buffers, zoom in and out, and move zoom window inside each buffer.
Once you press RUN it nukes everything and starts a new session. It is basically same thing as segmented capture, except scope keeps running normally, and retrigger time is bit slower.
-
I can't (don't want to) believe that nuking history like this was a design decision. Surely it's a bug that will soon be no more. Or an oversight that will be addressed. Or a design decision by a junior designer who will be counseled to make better decisions.
I pray it's not a decision forced by the hardware design; this seems most unlikely as automatic history is a major feature (according to Siglent's marketing team, at least). I await clarification from the horse's mouth.
Seeing how my 1204X-E behaves the same way, I think it's a design decision. Certain not the best design decision in my opinion (others are welcome to differing opinions on that), but a design decision nonetheless.
-
Hi,
The posts of 2N3055 and rf-loops seeming reasonable to me, that this not a bug nor a "design decision".
Only a logical fact.
-
You capture unknown signal and it is also filling acquisition buffer. Some time signal have changes, what ever changes, then also you twiddle adjustments as game machine joystic etc. After then you stop scope or it stops due to no trigger.
After then you go to look history and perhaps start inspect carefully these every wfm in this buffer for look what happen in signal.
I didn't expect that history would include associated parameters for frame reconstruction. If so, that would be wonderful but sans the data, don't choose for me. Put up a small warning when displaying history as circumstances dictate, but don't mess with my data!
Need them or not, I don't want training wheels on such a fine vehicle.
-
Need them or not, I don't want training wheels on such a fine vehicle.
Well it seems that you kinda need them... >:D
Look, you paid lots of money to get something smart and capable.. Now you only need to learn how to use it..
Just take a good look at all the triggering options. Many of those need some thinking up front to setup right.
You'll need take some time to learn it to be able to use it to full potential..
Scope doesn't mess with your data, you are if you're twiddling knobs all the time... History of that is not very useful.
-
<Interesting stuff removed>
You seem to have a firm grasp of how my new toy handles its buffers. New to the Siglent Way, I need to learn how this works, especially the implications and unwanted/unconsidered side-effects of which I am surely unaware. The manual tells me which buttons to push and little more.
Having pulled what was for me was an expensive trigger, new toy in hand, I seek deep understanding. How did you learn so much about how buffering works? Have you found a tech reference that spells everything out in detail?
Keep in mind that the mechanism I described might be close to how the actual implementation works, but doesn't seem to be all that close to it.
I do computer software for a living and have done for the past 35 years. I learned about things like low level memory handling and such because back when I started, those were things you had to do yourself -- there didn't exist things like automatic garbage collection and such, and even memory protection and hardware page handling was something primarily found in larger machines. And I've always had a keen interest in the fundamentals of computer operating systems. Much of what I describe flows from thinking about the problem and how to optimize a solution to it. Treating memory like a circular buffer and storing pointers to locations within it seems like a logical way to (a) minimize the amount of memory required for both the process of acquisition and for the storage of captures, and (b) minimize the amount of copying that would otherwise have to be done to preserve captures. But just because that's a logical way to do it doesn't mean it's how Siglent has done it. In fact, there is evidence that Siglent might actually be copying data out of the active acquisition buffer to save captures into capture storage, meaning Siglent does not merely store pointers or something of that sort. The evidence for this is the fact that the amount of time between trigger events seems to increase with the amount of memory used per frame when everything else is held constant. If Siglent were just using a circular buffer approach like I described, the amount of time between trigger events would be unaffected by the amount of memory per capture, since the capture itself would just be a subset of memory written by a continuously running acquisition process. The fact that increasing the memory used per capture while leaving the timebase alone results in a larger amount of time between trigger events is proof that Siglent is performing some sort of processing of the samples prior to re-arming the trigger. But why do that processing within the main acquisition loop unless you have to? There might be other reasons for performing sample processing within the main acquisition loop, but the only one I can think of right now is to save the acquisition off into capture memory.
Operationally speaking, what does seem to be the case is that the delay between trigger events is never smaller than the screen width, even when the trigger event interval is less than the time represented by the screen. So we can pretty safely say that the trigger mechanism has a minimum holdoff that is imposed and which is based on the screen.
As a practical matter, properly characterizing the scope's behavior is going to require a lot of experimentation. This is so because the specifics of the scope's behavior is highly dependent upon the scope in question. There will be a lot of similarities within a family (so, e.g., we can expect the 2104X+ to behave similar to the 1204X-E as regards the foundations), but the presence of some features in one and not the other might profoundly affect the behavior of one versus the other in at least some circumstances. That said, rf-loop has, as I recall, provided things like block diagrams and such showing how the scope does its thing, and that can provide a lot of insight into what the scope does. I'll have to search for that. (EDIT: Hmm...maybe not: https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3361154/#msg3361154 (https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3361154/#msg3361154))
Healthy Holidays and a Healthy New Year to You and Yours
And to you!
-
Look, you paid lots of money to get something smart and capable.. Now you only need to learn how to use it..
Just take a good look at all the triggering options. Many of those need some thinking up front to setup right.
You'll need take some time to learn it to be able to use it to full potential..
Completely agree with this.
Scope doesn't mess with your data, you are if you're twiddling knobs all the time... History of that is not very useful.
But this, I don't agree with. It's on the user, not the scope manufacturer or anyone else, to decide whether or not the history is useful and under what circumstances (that said, the manufacturer clearly has to balance the pros and cons of clearing the history under various circumstances since the manufacturer is implementing the history mechanism, the capture mechanism, etc., so the manufacturer has to make a guess as to the usefulness of the history under various circumstances so as to perform that balancing act as best as he can). As a practical matter, merely moving the trace vertically (i.e., changing the voltage offset of the trace) doesn't seem to be something that of necessity would invalidate the usefulness of the frames that were captured right up to that point. Maybe you can make a compelling argument for that, but merely asserting it isn't very convincing. :)
-
Another bug related to history preservation: moving the cursors while the scope is performing acquisitions will nuke your history. In fact, just enabling or disabling the cursors will cause this.
It turns out that the history buffer is cleared upon the next acquisition after something like the above. If it's just sitting there waiting for the trigger to fire (i.e., you're in normal trigger mode and a trigger event hasn't yet happened), then it won't touch the history buffer.
Hitting the "normal", "single", or "auto" buttons will clear the history immediately, however.
-
Just don´t move them, while recording...
It´s like in good old times, when you´re taking a record with tape from the radio.
Choose your settings once, then record.
-
Just don´t move them, while recording...
It´s like in good old times, when you´re taking a record with tape from the radio.
Choose your settings once, then record.
Heh, well, yes, you can always try to work around it.
But here's the problem: you can't stop the scope, then twiddle the cursors, then start the scope, without also losing your history.
Which is to say, once you decide you need to move your cursors and then continue acquisition for whatever reason, whether the scope is running while you move the cursors or not, you can say goodbye to your history up to that point.
I can think of no advantage to this, at all.
-
Well it's your prerogative to have an attitude, no matter how wrong you might be..
What am I so wrong about?
What is the use of history buffers?
Not much if Siglent is going to decide when my data is no longer of use on my behalf. And yes, even if I do all those things that might invalidate old data, the most (and least, come to think of it) they should do is display a small warning along with the history frames. If I screw up, let me figure it out and make corrections. Training wheels neither required nor desired, if you please.
I heard similar argument some time ago when someone was outraged that changing settings clears the screen and restarts when in roll mode...
That wasn't me, and no one's talking about data captured during parameter changes.
I didn't give up traditional full-buffer captures for Siglent's "what you see is all you get" approach easily. Reading these forums I'd come to believe that there were advantages to Siglent's approach, so I bit the bullet.
Today I learned that the feature I didn't want (auto-history), which replaced something I wanted (traditional captures), has been hobbled, perhaps so I don't hurt myself with it. Of course I'm not happy. I'm not saying I would have passed on the 'scope for this reason, but I would have done some more digging first.
Maybe your attitude would be more like mine were you in similar circumstances?
BTW, this discussion of including required parameters with the frame data would be a powerful addition to this fine machine.
-
By the way, I think the history handling needs to be put into some perspective. And because this is just my perspective, others might differ (in both directions).
It's certainly a bug (whether a design bug or implementation bug) that the history gets nuked under circumstances where there's no truly good reason for it (such as when moving the cursors around). But it's not a bad bug or anything, unless one is relying on continuous history acquisition while twiddling the knobs. There may be some circumstances under which that will be the case. Those circumstances will, of course, be kept to a minimum if one is aware of this behavior in the first place.
The real problem is that this behavior isn't, that I'm aware, documented anywhere. And it most certainly violates the principle of least surprise, which is one of the cornerstones of user interface design. It is a bug. But it doesn't rise to the level of some bugs, e.g., when the scope shows something that is objectively incorrect.
That said, seeing how the automatic history is the justification for the "what you see is all you get" approach to acquisition in the presence of deep memory, it seems obvious that Siglent should be doing everything they can to preserve the history in as many circumstances as possible. And right now, the opposite seems to be the case.
Even so, I would much rather see Siglent polish the UI to near-perfection first. While the history issue is an issue, it only comes into play under certain circumstances. But the UI experience is universal and ever-present. Fixing that will make the scope a joy to use irrespective of some issues like the history ones described here.
-
I agree about the user interface. This is the most annoying thing of this scope. Perhaps, if I had the opportunity to work with the device for a couple of days (just work, not play :) ) - I'm not sure if I would buy it. I have to rotate the knobs constantly, and I personally use history quite rarely. Like most of us probably.
There are also complaints about the quality of rendered waveforms. Despite the rather large screen resolution (1024x600), the waveforms are rendered with the quality inherent in a 320x200 screen. Looking at the screenshots at high magnification, you can see that this is the case. There is a maximum of 16 gradations of brightness, but most likely 8. Antialiasing is very primitive. Therefore, even a pure sine wave appears to be "jagged" on the screen, as it is rendered at very low pixel and brightness resolution. In addition, Siglent for some reason, uses white color mixing with the channel colors to "increase brightness", which makes it a "dirty color" effect and impairs the already not best visibility of the waveforms.
For comparison, the waveform rendering of Siglent SDS2000X+ and the old Rigol DS2072. Guess where who is? :))))
-
About History Buffer.
Just my "groschen":
- I can understand that the history buffer is cleared when parameters are changed which affect the acquisition. Whether or not that could be handled differently by software can only be told by Siglent. But since that only happens while NOT in history viewing mode, but in a run mode, I personally do not consider that as a real problem. When I want to use history, I set up the device properly, and then do my test series, which I then can inspect.
- I agree that is it unexpected and unnecessary (aka a bug), that the history buffer is cleared on attempts which just change who data is displayed or analyzed or triggered(cursors, measurement, zoom, single shot (!)).
-
About Display rendering:
Yes, that leaves much room for improvement. I could understand that a 8 bit signal, if displayed in full height of the screen, uses more than one pixel per step. But a signal not using the full screen heigth could be definitely use 1 pixel per vertical step, and not always 2.
And sometimes vertical slopes look are displayed poor, such that it was not obvious whether a visible step in the slope was a display issue or a signal property. Most of the time, it was a display thing.
-
A signal that does not use the entire screen height does not use 8 bits. :) 8bit is the entire vertical visible area in best case. They can be stretched to more than the entire screen, but you cannot use all 8 bits on a limited area of the screen.
The problem is that Siglent uses a very primitive anti-aliasing algorithm (smoothing oblique lines), so the signals appear so stepped. And this does not depend on the number bits of ADC, but only on the visualization algorithms. It is quite possible to fix this by software, and I am almost sure that the processor performance is sufficient for this fix. But will Siglent do this?
-
A signal that does not use the entire screen height does not use 8 bits. :) 8bit is the entire vertical visible area in best case. They can be stretched to more than the entire screen, but you cannot use all 8 bits on a limited area of the screen.
8 bits is 256 discrete values. As long as you have more than 256 pixels vertically on your screen, you'll be able to display 256 values on even a subset of it. The resolution of the 2000X+ is 1024x600. You can fully display two signals vertically at full 8 bit resolution with pixels to spare.
10 bits, on the other hand, is a different matter ...
The problem is that Siglent uses a very primitive anti-aliasing algorithm (smoothing oblique lines), so the signals appear so stepped. And this does not depend on the number bits of ADC, but only on the visualization algorithms. It is quite possible to fix this by software, and I am almost sure that the processor performance is sufficient for this fix. But will Siglent do this?
I'm actually rather a bit surprised that there isn't a super-cheap LCD controller that has the equivalent of a built-in GPU. The GPU doesn't have to be amazingly fast or anything. Even something with the kind of power that the very first NVidia 3D GPUs had would be more than sufficient for the purposes of these displays.
-
But digital scopes work differently. If your signal is not stretched to full screen, it does not use all 8 bits, but less. For example, if the signal has a span of 4 div. out of 8, then it uses only 7 bits. If 2 divisions - 6 bits. Etc.
-
About rendering:
What I mean: Even when a sine or ramp signal that has a acquiring span (max - min) of 200 is displayed at a height of let's say 50 Pixels, the vertical steps are always 2 pixels. Different to that, the rendering of text in the menus is much better.
-
I agree about the user interface. This is the most annoying thing of this scope. Perhaps, if I had the opportunity to work with the device for a couple of days (just work, not play :) ) - I'm not sure if I would buy it. I have to rotate the knobs constantly, and I personally use history quite rarely. Like most of us probably.
There are also complaints about the quality of rendered waveforms. Despite the rather large screen resolution (1024x600), the waveforms are rendered with the quality inherent in a 320x200 screen. Looking at the screenshots at high magnification, you can see that this is the case. There is a maximum of 16 gradations of brightness, but most likely 8. Antialiasing is very primitive. Therefore, even a pure sine wave appears to be "jagged" on the screen, as it is rendered at very low pixel and brightness resolution. In addition, Siglent for some reason, uses white color mixing with the channel colors to "increase brightness", which makes it a "dirty color" effect and impairs the already not best visibility of the waveforms.
For comparison, the waveform rendering of Siglent SDS2000X+ and the old Rigol DS2072. Guess where who is? :))))
About these images.
It can see that Rigol have more artists and Siglent have more engineers.
One ADC data value is 8 bit. One step on screen is exactly 2 pixels If there is data value 9F there is data value 9F and not data value between 9F and 9E. Siglent is test and measurement image, not picture artists camera or movie display. Even if it is bit rough for eyes but truth must not hide. Siglent is mapping every sample to display and every sample need be exatly visible. So that do npty need guess if there is true data byte or if it is image rendering artist produced or hided because it is not nice to look.
Sorry but if data is rough it need also show it is rough and not hide truth.
From Siglent images I can tell exactlly what values there sure exists in image and what not. Rigol image leave lot of room for guessing (just made detail looking changing contrast and other things and impossile to say what pixels there is data and what are "artists" made.
I do not accept at all this Rigol result. But I am not artist. If this is done with art phtotographs, entertainment movies etc.. there I can accept, even hope many methods for make image better looking.. but now we are talking test and measurement instruments what need display data as it have captured. Data must not bend!
How much they hide because they have started this "nice looking image is more important than real data", how much they bend data for show all more nice. I can recommend, they can put these image artist for cleaning noise from signal image because it is not so nice to look.
8 bit data is rough on display and this truth must not hide, there is not "perhaps" or intermediate and not "more nice or wanted" values (except in IPCC data). What other things they do for "cleaning" data for more "nice". Display only "pleasant looking data". But yes, they have been famous in this area. Instruments for engineers and instruments for artists.
-
It can see that Rigol have more artists and Siglent have more engineers.
MMD! ;D
-
And the degree of artistry becomes greater because we are not talking about 8-bit! In reality we are talking about sub-8bits world as many of you have described recently. And the lower you are, the more creative you need to be.
-
Ok, I haven't posted zoomed screenshots from RTB2000 and MDO3054. Or only artists also work in R&S and Keysight? :)
If you draw a straight line from point A to point B by a pencil on paper, it will be very smooth. If we build it with Lego elements, it will be very jagged and rough. But this does not mean that it is more accurate. We have only 2 refer points, everything in between - approximate. You can connect the points with rough stepped lines or smooth them using graphical algorithms. Accuracy will not degrade. And the visual experience will be greatly improved.
-
Forgive me all but all this is useless wankery.
What is shown here is called pixel anti aliasing, and is purely visual eye candy. It just makes 1 pixel 5 pixels wide and blends the edges so they are not visually obvious.
It is popular in gaming to remove pixelation and replace it with blur.
While it might seem more pleasant it doesn't make scoping (is that a word?) better, and makes any visual and cursor measurement less accurate. It is also part of reason why Rigol renders such a noisy and thick waveforms...
Also who says Keysight does it ?
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1140844;image)
-
But digital scopes work differently. If your signal is not stretched to full screen, it does not use all 8 bits, but less. For example, if the signal has a span of 4 div. out of 8, then it uses only 7 bits. If 2 divisions - 6 bits. Etc.
You're quite right. I had forgotten about that, and was clearly thinking only of what the display was capable of relative to an 8 bit value. |O
-
About these images.
It can see that Rigol have more artists and Siglent have more engineers.
One ADC data value is 8 bit. One step on screen is exactly 2 pixels If there is data value 9F there is data value 9F and not data value between 9F and 9E. Siglent is test and measurement image, not picture artists camera or movie display. Even if it is bit rough for eyes but truth must not hide. Siglent is mapping every sample to display and every sample need be exatly visible. So that do npty need guess if there is true data byte or if it is image rendering artist produced or hided because it is not nice to look.
Sorry but if data is rough it need also show it is rough and not hide truth.
I have to disagree here, rf-loop -- this is what dot mode is for. If you want to see the raw data in that manner then dot mode is what you need to be using.
For interpolated data the results should be as smooth as the display will allow, as long as the resulting smoothing is not itself incorrect relative to the selected interpolation method.
In fact, done right, the resulting smoothed curve could even give you a visual representation of the uncertainty in the data, since smoothing (antialiasing) of a curve generally will also use lower intensity pixels as part of the process. After all, scaling the actual value in order to place it on the screen is not guaranteed to land it at an exact (non-fractional) location on the screen, and save for specific circumstances, it's incorrect to claim that each point in the waveform will always land squarely on a corresponding location on the screen.
-
About these images.
It can see that Rigol have more artists and Siglent have more engineers.
One ADC data value is 8 bit. One step on screen is exactly 2 pixels If there is data value 9F there is data value 9F and not data value between 9F and 9E. Siglent is test and measurement image, not picture artists camera or movie display. Even if it is bit rough for eyes but truth must not hide. Siglent is mapping every sample to display and every sample need be exatly visible. So that do npty need guess if there is true data byte or if it is image rendering artist produced or hided because it is not nice to look.
Sorry but if data is rough it need also show it is rough and not hide truth.
I have to disagree here, rf-loop -- this is what dot mode is for. If you want to see the raw data in that manner then dot mode is what you need to be using.
For interpolated data the results should be as smooth as the display will allow, as long as the resulting smoothing is not itself incorrect relative to the selected interpolation method.
In fact, done right, the resulting smoothed curve could even give you a visual representation of the uncertainty in the data, since smoothing (antialiasing) of a curve generally will also use lower intensity pixels as part of the process. After all, scaling the actual value in order to place it on the screen is not guaranteed to land it at an exact (non-fractional) location on the screen, and save for specific circumstances, it's incorrect to claim that each point in the waveform will always land squarely on a corresponding location on the screen.
And we disagree with you.
Pixel anti aliasing would serve no purpose except eye candy and would yield visually much higher displayed noise (thick trace).
Also, when display is running, you get exactly that pixel anti aliasing effect, by virtue of display intensity gradation in persistence. Only stopped it shows only last (single) capture that is single pixel wide.
When running trace looks smooth... Check it out.. It also works same way in dot mode, in which it creates effect of RIS sampling, making effective sample rate higher that spec.. Hence better impulse response (within limits of front end of course)
-
And we disagree with you.
Pixel anti aliasing would serve no purpose except eye candy and would yield visually much higher displayed noise (thick trace).
Let's say that you want to show a 1.3V value on the display at t = 0, the trigger location is at the center, and you have the display set for 1V/div with a 0V vertical offset, the vertical resolution of your display is 480 pixels, and it shows 10 divisions vertically. This gives you 48 pixels per division. 1.3V up from center would be 62.4 pixels up from center. How will you most accurately represent that? With a single pixel at 62 pixels up?
No. I argue that the most accurate representation of that value is with two vertical pixels, one at 62 and one at 63, where the pixel intensity of the one at 63 is 66% that of the one at 62 (62.4 means that 60% of the value is at 62 and 40% of it is at 63).
Also, when display is running, you get exactly that pixel anti aliasing effect, by virtue of display intensity gradation in persistence. Only stopped it shows only last (single) capture that is single pixel wide.
Right. But why is it a single pixel wide (or high) when the display is a discrete grid that, except under very specific circumstances, does not map 1:1 onto the values it's being asked to display? The very problem here is that the display is an inexact representation of the values it's being asked to display, precisely because of the scaling operations that have to take place prior to display. The use of multiple pixels at different intensity makes it possible to more accurately represent recorded values.
Of course, complicating this is the fact that the values themselves are the result of conversion from analog to digital, so that would have to factor into this to the degree possible.
And then there's the fact that the conversion itself is limited in resolution and, thus, carries with it uncertainty. Wouldn't it be most accurate to represent that uncertainty in the display as well?
Put another way, it is, generally, misleading in at least a couple of ways to represent the recorded value as a single pixel in the display, no?
--
If your argument is that the nature of displaying a single capture is such that you don't need to go to the trouble of antialiasing, then I can agree with that. You have cursors at your disposal if you want to see the actual value at any given point. But that is a very different argument from the one that says that "antialiasing" cannot serve a useful purpose. Done right, it can.
-
With all methods of applying a certain range of values to a range to display pixels, it seems unnecessary for me that the step size in the display is always 2 pixels. If for instance a signal with 256 discrete values is mapped onto a range 64 pixels, I see only 32 discrete values. I do not see a need to do it that way, even if the trace uses 2 pixels height for better visibility.
-
Signal with 256 discrete values is never displayed in 64 pixels height in normal (fullscreen) mode. It's impossible in digital scopes. Typically, 256 discrete values are stretched to the number of pixels in the output area vertically , which more than 256 pixels in modern oscilloscopes.
But even with 256 discrete levels for 512 pixels, you can draw lines in different ways. Siglent does not bother and draws as in the left picture. It doesn't look very good even on the oscilloscope screen, especially in the screenshots taken. Anti-aliasing does not thicken the line in any way. But it makes it smoother.
-
Not sure if this applies to the SDS 2XXX series as well, but the SDS12XX is missing a feature for alternate triggering across the channels.
e.g.: I want to trigger from CH1, sample and draw, the trigger from CH2 (or 3,4), sample and draw.
This is very useful when you want to compare signals that are related but not time synced. Think delay lines, phase shifts, that kind of stuff.
Hell, my old PM3070 CRO can do that, and you can even select a different timebase for CH2. A dual time base/trigger should be relatively easy to implement in a digital scope.
-
Signal with 256 discrete values is never displayed in 64 pixels height in normal (fullscreen) mode.
My concern was not full screen mode, but showing signals ar smaller height, which may happen if oyu have for instance 4 traces which should not overlap on the screen, and all the other information.
Besides that, your example for smoothing a display is right. And that technique seems to be used by Siglent for text.
Edit: Interestingly, the math trace display shows single pixel vertical steps.
-
Not sure if this applies to the SDS 2XXX series as well, but the SDS12XX is missing a feature for alternate triggering across the channels.
e.g.: I want to trigger from CH1, sample and draw, the trigger from CH2 (or 3,4), sample and draw.
This is very useful when you want to compare signals that are related but not time synced. Think delay lines, phase shifts, that kind of stuff.
Hell, my old PM3070 CRO can do that, and you can even select a different timebase for CH2. A dual time base/trigger should be relatively easy to implement in a digital scope.
Pretty much there is no modern digital scope from major brands that implements Alt triggering mode, except few exceptions.
You can sometimes achieve similar with logic trigger on some scopes.
-
After spreading it on several threads, I´m try to make a summary of what "our" two new siglent owners here concerns and their "issues" with the scope, because they aren´t bugs.
But it turns out do as if the scope has serious quirks, which is definitely not true.
So we should use this thread here only for wanting nice to haves.... :)
Wanted features (because it´s no bug):
- Faster response of the knobs in general.
- Doing whatever you want with the scope settings without nuking the history.
Am I right ? What else perhaps ?
Because it´s confusing to read a piece here, a piece there....
The aliasing thing is no bug also, we shouldn´t use magnifying glasses for looking at the scope screen..
Martin
-
After spreading it on several threads, I´m try to make a summary of what "our" two new siglent owners here concerns and their "issues" with the scope, because they aren´t bugs.
But it turns out do as if the scope has serious quirks, which is definitely not true.
So we should use this thread here only for wanting nice to haves.... :)
Wanted features (because it´s no bug):
- Faster response of the knobs in general.
Yep, that's a feature request. It would rise to the level of a bug if the UI went completely (or almost completely) unresponsive, but it hasn't done that to me except once, and restarting the scope seems to have cleared it. As it is, the UI is highly responsive to the touch screen menu operation.
I'd say the UI for moving traces around and things like that is responsive enough, even if it could be substantially improved. I've seen worse.
- Doing whatever you want with the scope settings without nuking the history.
That I think over-trivializes the problem.
It seems like doing just about anything with the scope while it's performing acquisitions will nuke the history. Moving the cursors does that. Merely highlighting a different digital channel (without making any changes to it, or changing its ordering, or anything else like that) will do that. Entering or exiting zoom mode will do that. Moving around within zoom mode will do that. These are things that don't change any settings.
That is a bug for sure. Whether a design bug or an implementation bug, it's a bug all the same, because it's doing something that it shouldn't do.
That doesn't mean there aren't any operations for which it's valid for it to clear the history -- a case can clearly be made that there are, and some here have made that case. But there are certainly operations for which there is no good reason to clear the history as a side effect.
The aliasing thing is no bug also, we shouldn´t use magnifying glasses for looking at the scope screen..
I'd agree that the aliasing thing is a feature request. It's not strictly incorrect for it to be displaying things as it is. It may not be terribly pleasing to look at, but that doesn't make it rise to the level of a bug.
-
Not sure if this applies to the SDS 2XXX series as well, but the SDS12XX is missing a feature for alternate triggering across the channels.
e.g.: I want to trigger from CH1, sample and draw, the trigger from CH2 (or 3,4), sample and draw.
This is very useful when you want to compare signals that are related but not time synced. Think delay lines, phase shifts, that kind of stuff.
Hell, my old PM3070 CRO can do that, and you can even select a different timebase for CH2. A dual time base/trigger should be relatively easy to implement in a digital scope.
For whatever reason, the features that you mention were ubiquitous in analog scopes and pretty much nonexistent in digital scopes.
See: https://www.eevblog.com/forum/blog/eevblog-1235-alternate-trigger-trickery-on-dsos/ (https://www.eevblog.com/forum/blog/eevblog-1235-alternate-trigger-trickery-on-dsos/)
-
Seems that enabling or disabling measurements, or even adding or removing measurements, will also clear the history buffer.
At this point, it's pretty clear that whenever you change pretty much anything while the scope is running, the scope will clear the history buffer.
To my astonishment, changing the scope's IP address doesn't clear the history, nor does turning the sound on and off. ;D
-
Well it seems that you kinda need them... >:D
Perhaps you should defer this conclusion until we've explored my reasoning?
If I'm wrong, then you're right; in any event I'm open to some education from you and the many others here who far know more than I do.
After all...
you paid lots of money to get something smart and capable..
I did indeed, and I got more that I could have hoped for; I truly love this 'scope. I don't see that changing.
When I started looking for a 'scope, I planed on spending in the $600-800 range. For context, the last time I bought a serious 'scope (for my employees, not me) I got a fully loaded TDS-544A (rep's sample), for something like $20-22K (my wife probably remembers to the penny!). I hadn't looked at a serious 'scope since, so imagine my surprise at finding what's available today! I changed priorities and jumped at the chance to spend well under 2K for something far more capable than that old Tek, wonderful as it was in its day.
What frustrates me is less-than-smart design decisions such as throwing away data when *nothing that invalidates it* has occurred.
We could have a reasonable discussion as to when it might be appropriate to dump suspect data, but can you really make a case for dumping data that is known to be good?
You'll need take some time to learn it to be able to use it to full potential..
Absolutely. I thought long and hard before I took leaped into the Siglent approach. I'm more than willing to put in the effort to learn every way in which this 'scope can help me - in electronics and in other interests, regardless of hard hard Siglent has made the process (I'm talking about docs here - different subject but adding to my frustration quickly). What I can do with triggering will get a lot of my attention, especially given the LA capabilities I now have, and the instrument's ability to combine their capabilities. What a world I have before me!
Scope doesn't mess with your data, you are if you're twiddling knobs all the time... History of that is not very useful.
That, sir, is my quarrel with your argument, so to speak. :)
Since Siglent (currently and apparently) refuses to distinguish between when my twiddling has invalidated my data and when it has not, they should do nothing (first, do no harm). Rather, they presume to assume I don't know what I'm doing (which may be the case!) and, rather than giving me the chance to learn something about the workings of my DSO, cripple the 'scope in an apparent attempt to protect me from myself. Since they know I've twiddled, they have all the information they need to display a warning as necessary, while allowing me to decide whether or not I've destroyed my history.
The problem with training wheels such as these is they can't be removed once you've become a good rider, thus keeping you from becoming better yet. Training wheels may be appropriate on "My First Bicycle," but knowing that's not what I bought I'm only asking they be removed.
-
Scope doesn't mess with your data, you are if you're twiddling knobs all the time... History of that is not very useful.
That, sir, is my quarrel with your argument, so to speak. :)
Since Siglent (currently and apparently) refuses to distinguish between when my twiddling has invalidated my data and when it has not, they should do nothing (first, do no harm). Rather, they presume to assume I don't know what I'm doing (which may be the case!) and, rather than giving me the chance to learn something about the workings of my DSO, cripple the 'scope in an apparent attempt to protect me from myself. Since they know I've twiddled, they have all the information they need to display a warning as necessary, while allowing me to decide whether or not I've destroyed my history.
The problem with training wheels such as these is they can't be removed once you've become a good rider, thus keeping you from becoming better yet. Training wheels may be appropriate on "My First Bicycle," but knowing that's not what I bought I'm only asking they be removed.
Whole point of history buffers is that they are implemented as segmented sequence capture, but with screen updates.
Segmented capture works in a way that you set scope to some settings, set it to get 100 sequential trigger captures.
Then you start, and it stops responding. Only button that works is STOP. In meantime it will patiently wait for trigger events, and capture and store them one by one in a memory, until it reaches 100 of them or you press STOP. While it is doing that, you cannot operate scope, or change the settings. You don't see anything on the screen. So by definition these 100 captures are going to be taken with exactly the same settings. One reason why it is implemented this way is to ensure minimum intersegment retrigger time. Other reason is that because of that you can directly compare captures. You can directly overlay them on top of each other, using persistence, to create signal envelope, you can replay them and get statistics measurements. They are directly comparable, point by point because it is guaranteed they are taken at exactly the same conditions. If there are differences, you know they came from signal.
History mode works exactly the same and has the same purpose and analysis tools. They are in the same menu.
Only difference is that it updates the screen, scope stays interactive and responds to user input, and for that, price is slower retrigger time.
But since scope uses same tools and everything to analyse it, it must ensure that data is taken with same premise as with segmented capture.
That is all.
As I said before ( and I don't remember was it to you or the other guy in the other topic ) there can always be improvements. And also bugs should not be there.
So on that:
- Anything that is used to look around history data while in STOP mode should not invalidate buffers immediately. After you restart with RUN, that is another session.
- Using zoom should not invalidate buffers.
- I guess they could add warning that buffers are going to be nuked. Maybe add option to save them. But that should be optional, because it would get annoying soon.
And that's it. It is more important for them to keep adding analysis options of what you can do with buffers. Current way of handling is perfectly simple and deterministic. It's not perfect and not solution to all problems, but perfectly usable.
For better explanation, go to LeCroy site and download manual for Waverunner series to see what it can do with buffers, that are implemented in a same way.. Then you might understand why it is this way..
-
And that's it. It is more important for them to keep adding analysis options of what you can do with buffers. Current way of handling is perfectly simple and deterministic. It's not perfect and not solution to all problems, but perfectly usable.
As much as I think it would add to the usefulness of the scope under certain conditions for them to retain the history when doing things like changing the trigger settings (playing with cursors, or adding/removing measurements, or doing things in zoom mode that don't affect the capture parameters are a different matter altogether and should be addressed IMO), I completely agree here -- the scope is perfectly usable.
In fact, I'll even go so far as to say that the scope is perfectly usable even with all of the things that will clear the history when they shouldn't (to be absolutely clear, I'm referring to the use of cursors, zoom mode, measurements, etc., not trigger settings or capture parameters). I find the same behavior on my 1204X-E as I do my 2104X+ with respect to all of this. It's clear that Siglent's scopes have behaved this way for some time. As far as I've been able to determine, nobody has raised this behavior as an issue until now. In fact, near as I can tell, few if any were even aware of the behavior with respect to these odd things.
Maybe that's an indicator of how infrequently people use the history mode on these scopes. No idea. But regardless, it should at least put all of these things in their proper context.
So: does the scope have bugs? Yep. Do those bugs make the scope unusable? No, not at all. In general, it's quite excellent in this neophyte's opinion. It could be better. Most things could be. But it's still very, very good despite its issues. And the power you get for the price is off the charts.
-
An update on the use of cursors and its effects on the history buffer: it seems that it's only when you move the cursors around in "track" mode (or when you enable or disable them when they're already in "track" mode) that it will clear the history. Moving the cursors when they are in manual mode has no effect on the history. And, in fact, when there's a delay between moving the cursor in "track" mode and the scope updating the cursor's secondary axis position (if you're moving its time location, then this would be when it figures out the voltage at the new position), the history buffer will not be cleared until the scope figures out the new secondary axis position.
-
Missing:
Intensity grade displaying on screen while adjusting it - You can only see it when you´re directly in the display menu.
-
I do computer software for a living and have done for the past 35 years. I learned about things like low level memory handling and such because back when I started, those were things you had to do yourself --
Back in the mid-80's I spent years working on an 805x based telephone device. As I recall I had 256 bytes of e-squared and perhaps twice that much ram. Or perhaps it was the other way around. The guy who did the hardware and early software found a company who took our voice prompts and converted them to data we would then play back via a resistor network. Damn clever! He and the voice prompt guys were soon gone, and as we hadn't paid north of $50K for their proprietary software...I was left to splice and rearrange pieces of voice data to make completely different messages was we evolved the basic design into several different and unrelated products.
Those were the days!
<interesting stuff snuffed>
What I understand least is the hardware end. My knowledge of hardware cpu/memory architectures is decades out of date, so I can't imagine how one might design such a highly optimized system. It's pretty amazing that we can in any way afford such capable instruments; did the price/performance criteria force a hardware design that somehow causes these buffers to be lost? I have no way of knowing.
There will be a lot of similarities within a family
From a family perspective, wouldn't the SDS1K class different from the SDS2K class?
That said, rf-loop has, as I recall, provided things like block diagrams and such showing how the scope does its thing
Thanks, I'll check that out.
-
Whole point of history buffers is that they are implemented as segmented sequence capture, but with screen updates.
Segmented capture works in a way that you set scope to some settings, set it to get 100 sequential trigger captures.
Then you start, and it stops responding. Only button that works is STOP.
Not exactly. On several DSOs you can choose between seeing what the oscilloscope does during segmented recording or not. Usually this is fast / slow acquisition mode. The advantage of slow (interactive) mode is being able to see what the oscilloscope is doing and correct things if they are not optimal. I don't know if Keysight offers this interactive segmented recording mode (like -for example- R&S and GW Instek do) nowadays but your remark makes me assume not. The Agilent DSO I owned captured signals without offering any visible captures and after the capturing is done (which can take an hour in some case) you can see if you wasted your time or not.
-
I do computer software for a living and have done for the past 35 years. I learned about things like low level memory handling and such because back when I started, those were things you had to do yourself --
Back in the mid-80's I spent years working on an 805x based telephone device. As I recall I had 256 bytes of e-squared and perhaps twice that much ram. Or perhaps it was the other way around. The guy who did the hardware and early software found a company who took our voice prompts and converted them to data we would then play back via a resistor network. Damn clever!
:o
Wow. I'm impressed.
He and the voice prompt guys were soon gone, and as we hadn't paid north of $50K for their proprietary software...I was left to splice and rearrange pieces of voice data to make completely different messages was we evolved the basic design into several different and unrelated products.
Those were the days!
They were indeed! Optimization seems to be something of a lost art, at least in the software world, these days. The capabilities of systems today are so high that few people think about minimizing the compute footprint of what they're writing. There are some notable exceptions, e.g. games, but I think even those are getting to the point where optimization of anything is the exception and not the rule.
Honestly, I can't entirely fault people for that. Optimization takes time, and that time might easily be best spent elsewhere. The problem is that when optimization is something that is rarely done, the techniques of optimization end up being forgotten (or, worse, never learned in the first place!), and it gets to the point where optimization can no longer happen even when it is clearly warranted.
What I understand least is the hardware end. My knowledge of hardware cpu/memory architectures is decades out of date, so I can't imagine how one might design such a highly optimized system. It's pretty amazing that we can in any way afford such capable instruments; did the price/performance criteria force a hardware design that somehow causes these buffers to be lost? I have no way of knowing.
I started in on a EE track before I finally switched to CS way back in the day (I switched because I found myself playing around with computers in my spare time, and figured that it was an indication of where my primary interests were -- and if that's where my primary interests were, it's probably what I should build my career on. Best decision I ever made). But I never entirely forgot about hardware and how it's constructed, and never entirely lost my interests in hardware.
CPUs today are incredibly complex beasts with all sorts of crazy optimization mechanisms (pipelining, lookahead, branch prediction, speculative execution, etc.). But even then, the fundamentals haven't really changed all that much.
As regards the Siglent scopes, it's possible that changes to things that have to look inside a capture somehow demand that the history be cleared. If that's truly the case, then there's no solving the problem of the history being cleared upon things like movement of tracking cursors while acquisition is happening, or addition/removal of measurements, etc. It would be surprising, to say the least, for that to be the case. But it's not entirely beyond the realm of possibility.
From a family perspective, wouldn't the SDS1K class different from the SDS2K class?
Yes and no. With respect to some of the details, certainly. But there's an enormous amount of effort that goes into the design of one of these scopes. You don't just throw away an architecture, particularly one that works well for you, and design something from scratch unless you've no real choice (the market can sometimes demand this, but it's relatively rare). Siglent has an enormous investment in their architecture, both with respect to the hardware and with respect to the software. And those two things (hardware and software) are fairly tightly coupled. You can craft the software in a somewhat hardware-independent manner, via various abstraction techniques, and it's certainly in their best interests to do so to the degree reasonably possible. But at some point the software has to interact with the hardware, and it's at that point that hardware dependence within the software will appear.
And note that it's not uncommon for abstraction methods within software to incur a performance cost, which of course goes back to the question of optimization. Sometimes you have to choose between greater hardware dependence within your software and poorer performance of a more abstract approach.
That said, rf-loop has, as I recall, provided things like block diagrams and such showing how the scope does its thing
Thanks, I'll check that out.
Well, as I said afterwards in a subsequent edit, I don't actually think he has block diagrams and such of how the scope's acquisition and storage mechanisms work, at least not enough to prove revealing. But if he does, then I'd certainly be interested in seeing them.
-
And we disagree with you.
Pixel anti aliasing would serve no purpose except eye candy, and would yield visually much higher displayed noise (thick trace)
Well, it's clear that disagreement abounds! :) I'm on the 'make it look as good as possible without compromising results' side of the fence. If you're worried about visual noise, Dot Mode to the rescue.
Those on your side of the fence seem to dismiss aesthetics as unimportant 'kids stuff', but ignore the human factor. Most people, whether they realize it or not, are happier and more productive when working in pleasing surroundings. Smart companies spend lots of money to place employees in such environments. Do you think this doesn't apply to our tools as well as our surroundings? BTW, I'm a 'function over form' guy, to which my 'form-over-function' wife of 40 years will attest.
-
BTW, I'm a 'function over form' guy, to which my 'form-over-function' wife of 40 years will attest.
:-DD
-
As I said before ( and I don't remember was it to you or the other guy in the other topic ) there can always be improvements. And also bugs should not be there.
So on that:
- Anything that is used to look around history data while in STOP mode should not invalidate buffers immediately. After you restart with RUN, that is another session.
- Using zoom should not invalidate buffers.
- I guess they could add warning that buffers are going to be nuked. Maybe add option to save them. But that should be optional, because it would get annoying soon.
I agree with this other than the 2nd clause of your first point, which I think needs more thought.
It is more important for them to keep adding analysis options of what you can do with buffers. Current way of handling is perfectly simple and deterministic. It's not perfect and not solution to all problems, but perfectly usable.
Agreed. One feature I'd like to see is search on decodes, another apparently controversial request. :) There are probably other features or improvements I'd prioritize first, but I haven't had time to find them yet.
My thinking is that fixing the history bug is trivial, or at least easy. If it's not, so be it.
For better explanation, go to LeCroy site and download manual for Waverunner
What a wonderfully helpful and completely outlandish suggestion.
Want to learn how to use my Siglent 'scope? Read LeCroy's manual!
Outrageous? Pathetic? You bet! Had I realized how poorly documented this complex instrument is, I probably would not have bought it.
-
For better explanation, go to LeCroy site and download manual for Waverunner
What a wonderfully helpful and completely outlandish suggestion.
Want to learn how to use my Siglent 'scope? Read LeCroy's manual!
Outrageous? Pathetic? You bet! Had I realized how poorly documented this complex instrument is, I probably would not have bought it.
Hilarious.... 8)
I was talking about history mode implementation in general and pointed to a implementation of history mode that is fully implemented in a mature and long running product. There you can see how it can be used and that will define how it should be gathered.
As far as documentation goes, I don't think it is so bad, even compared to premium brands. It is not a tutorial or textbook.
Keysight or R&S don't have much details in their user manual either. Keysight has many supplementary documents though, for different options and such...
Don't get me wrong, I also wish ALL of them would go back to how manuals were written in the 80ies... User manual/reference manual/programmer's manual combos with combined 2000 pages...
So if Siglent can improve manuals I'm all for it.. That's never wrong.
-
Wow. I'm impressed.
The technology was a bit rough, but was good enough for our purposes. The lengths we had to go to back in the day...
Optimization seems to be something of a lost art... Honestly, I can't entirely fault people for that. Optimization takes time
Commercially, software optimization has been unnecessary (with exceptions as you noted) for decades. What I lament most is the dismal state of UIs. Microsoft was the worst at this, having made two horrible (IMO) decisions: Desktops should have browser UIs, thus limiting your hardware capabilities to the LCD; and by far the worst - All Windows versions will be called Windows 10 forever, so no one will be able to find help online that matches the version they're running. Good plan.
IMO, Win7 was the golden age...
What I understand least is the hardware end. My knowledge of hardware cpu/memory architectures is decades out of date, so I can't imagine how one might design such a highly optimized system. It's pretty amazing that we can in any way afford such capable instruments; did the price/performance criteria force a hardware design that somehow causes these buffers to be lost? I have no way of knowing.
But I never entirely forgot about hardware and how it's constructed, and never entirely lost my interests in hardware.
My birth predates solid stated electronics (a big thank you to the green little men who died at Roswell for the help), but I've always had an interest. I escaped 'Nam via the submarine service, on the electronics track. My interest in software was born in the engineering spaces of the USS Thomas A. Edison, as a friend informed me that he was building a computer at home. At that time and to the best of my knowledge, computers were good for screwing up my Sears bill, number crunching, and little else!
For most of my software career, I worked in concert with EEs. Although I have no real electronics education, I have lots of experience and still have the equipment I've gathered over decades. What brought me back into hardware was my loss of interest in writing software, which has been my only hobby.
I started exploring possibilities via YouTube videos and learned what I could build with a 3D printer that I could afford. Which led me to RC control, servos, steppers and such. Which led me back to electronics: Dave, Anders with the Swiss Accent and many others have inspired me further.
CPUs today are incredibly complex beasts...
I may have been one of the only guys who really enjoyed optimization. There's something satisfying about planning where each byte or even bit will be stored, counting cycles and rearranging instructions as needed to squeeze another feature into an already crowded unit, that I've missed.
I can't imaging trying to hand-optimize a processor that messes with my code!
You can craft the software in a somewhat hardware-independent manner, via various abstraction techniques, and it's certainly in their best interests to do so to the degree reasonably possible.
Good point. As you said, abstraction is by nature the enemy of optimization, making this a most delicate balance.
-
Hilarious.... 8)
I'm not quite so amused.
-
It's going a bit off topic so I'll keep this relatively brief.
CPUs today are incredibly complex beasts...
I may have been one of the only guys who really enjoyed optimization. There's something satisfying about planning where each byte or even bit will be stored, counting cycles and rearranging instructions as needed to squeeze another feature into an already crowded unit, that I've missed.
I can't imaging trying to hand-optimize a processor that messes with my code!
Optimization is quite a bit different these days than before, but many of the fundamentals are the same. You don't do something unless you have to, and what you have to do, you do as little as possible. Algorithm and data structure selection is paramount, because that's the sort of thing that makes orders of magnitude worth of difference. You try to keep call stacks shallow. Those sorts of things. These are things that have always been applicable. But even though those things are pretty basic, a lot of developers utterly ignore them, and the result is software that is much less efficient than it could be.
Anyway, we can go to PM if you want to talk about this stuff further. As applied here, I can't say how much in the way of optimization or lack thereof there is in Siglent's firmware. It's clear that it could use some tuning in some areas, but the scope is certainly quite usable nonetheless. Developer time at this point would probably be best spent on fixing bona-fide functionality bugs.
I sometimes think that the best development environment for embedded stuff like the scope might be a development target in which everything runs at, say, a tenth of the speed of the actual hardware that's being targeted, with the requirement being that the result has to be usable on the development target. If it's usable on that development target, it'll be awesome on the real hardware.
-
I may have been one of the only guys who really enjoyed optimization. There's something satisfying about planning where each byte or even bit will be stored, counting cycles and rearranging instructions as needed to squeeze another feature into an already crowded unit, that I've missed.
I love it! ^-^
-
There are also complaints about the quality of rendered waveforms.
AM-Mod 8bit vs. 10bit.....Better? ;)
-
The bottom of the screen (zoomed waveform) - is better, the top (normal waveform) is equally bad. The steps on the waveforms are terrible.
-
LOL.
-
An 8 or even 10 bit signal is displayed on area about 100 pixels height (top of the screen). Explain why they should be drawn so roughly as if they were a 4-bit signal???
-
Don´t know, maybe because they are compressed into one division.
-
An 8 or even 10 bit signal is displayed on area about 100 pixels height (top of the screen). Explain why they should be drawn so roughly as if they were a 4-bit signal???
Please stop posting unrelated stuff and going of topic. This topic is designed for users of SDS2000X+ users to report real bugs.
We are glad you like your scope but R&S RTB2000 has it's own topic. Post there..
Or if you wish to make comparison (which I believe many members would like to see and would be grateful for your contribution) between SDS2000X+ and RTB2000, create your own topic and make a comparison, side by side.
You can start with much higher price, fact that it has 10 times less sample memory, no 50 Ohm inputs, fact that it can decode only one bidirectional protocol at the same time, and that it has very nice GUI and looks really awesome... Compare them side by side and post results. It would really be nice to see unbiased and thorough comparison.
Best regards,
Siniša
-
Don´t know, maybe because they are compressed into one division.
That's one reason. The other is, that the rendering almost always use 2 pixel vertical steps for channel waveforms. In rare cases you see single pixels steps. A good chance to get them is with the math eres function. You say that this is "just" display stuff. but:
- Oscilloscopes are about displaying signals. The "scope" part of the names comes from ancient greek for "observe" or "check by looking at it". Having the display as good as possible helps.
- There is still the possibility that this is a bug in rendering, or just below possible achievement.
Not that I care too much about it. The nuking of history is a somewhat larger obstacle for me. B.t.w: A similar odd behavior is with Bode plot, when the Max-Hold memory is lost even at actions which do not affect the data acquisition, like changing the marker type or manually moving a marker. The latter is not really helpful.
-
Maybe a bug or the bug is in front of the scope.... 8)
Always when I´m switching the attentuator ( from 1:1 to 1:10 or 1:100 and back), the following message appears:
Zone is too small
It pops up, dissapear after a few seconds and doesn´t have any effect of the scope handling.
It´s just irritating...
-
Maybe a bug or the bug is in front of the scope.... 8)
:D
Patch the string with a \0.
-
Patch the string with a \0.
:-//
-
\0 denotes an empty string, so nothing would be displayed. :-BROKE
-
Well...yes...But doesn´t help me to understand the "Zone is too small" message.
Which zone, why...
I´ve only set the attentuation...
-
Probably some Zone triggering bug...
Happy New Year everybody, hope new one will be better and wish everybody is safe!!
-
Same to you Sinisa - It could only going better... 8)
The only positive aspect in 2020 for me was, for our case here, to change the scope brand.. :D
-
Algorithm and data structure selection is paramount, because that's the sort of thing that makes orders of magnitude worth of difference.
Absolutely agree. You can't optimize away a bad plan by twiddling code, regardless of how well you know the processor and associated tricks.
Anyway, we can go to PM if you want to talk about this stuff further.
I think we've beat this topic sufficiently. :)
I sometimes think that the best development environment for embedded stuff like the scope might be a development target in which everything runs at, say, a tenth of the speed of the actual hardware that's being targeted
I used to have a fast dev machine, and a slow test machine for just this purpose...back in the day.
-
New bug introduced in latest firmware?
I was unable to get Dot Mode working. Original question/answer posted here:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3395528/#msg3395528 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3395528/#msg3395528)
-
Can't confirm. Dot mode is working. But anyhow a strange screen shot. Are the dots properly connected in vector mode? What kind of signal did xou capture.
Example screen shot below with a 1.3.7R5 firmware.
-
OK. At least I could reproduce a similar strange signal like yours, by
a) make a single shot of just an open channel at 1v/div
b) turning the vertical scale up in stop mode to 20 mV/div.
Then I have these sharp edges. The funny thing us the difference between sinc and x interpolation. Sinc goes really haywire.
But still, dots are shown properly.
-
Using the same setup as before:
a) capturing a 100 mV pp 50 MHz sine signal from the AWG at 1V/div as single shot
b) turning up vertical scale to 20 mv/div
I get strange results from the was the lines are drawn between the dots. That seems to add a lot of visible noise by itself, even visible in low scale. Just look at all the vertical steps added where are definitely not dots to join.
Maybe it's intended, nevertheless surprising. At least for the X interpolation I would draw the lines by hand different.
-
Looking at the detail it seems, that the interpolation itself creates noise to the displayed signal.
Also, in dot mode, while the instrument is in stop mode, switching between sinc and x interpolation, some dots move. That's strange too. And sinc seems to make the worse moves.
-
New bug introduced in latest firmware?
I was unable to get Dot Mode working. Original question/answer posted here:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3395528/#msg3395528 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3395528/#msg3395528)
When I went to check this on my scope, I saw the same thing, with version 1.3.7R5 of the firmware (which is what came with the scope). It didn't seem to matter what I did, the scope insisted on connecting the dots (whether via sinc or via straight lines). Recalling the default settings cleared it with the same signal and trigger settings on the same channel.
I honestly haven't a clue what caused the bug to manifest itself.
-
@roberthh:
Can reproduce it too.
Additionnaly I´ve played with several sinefrequencies/timebases ( to get more mempoints), amplitudes, always the same behaviour regardless of the stored points.
Last example was a 100Hz 2Vpp Sinewave, stopped by 2V/div. then decreasing to 500mV/div.
Running with 500mV/div then stop is no problem.
But everytime you decrease the V/div. in Stop-Mode, it seems, as if there was not enough "information" to form a proper signal.
Trying the same in 10bit mode, signal appears more polished.
-
@kcbrown about dot mode:
I had a similar picture when setting 'Persistence' to 'infinite'. But in you screen shot it was set to off. Just as a blind shot: could you try to set 'Persistence' to 'infinite' and then to 'off' again. Maybe some setting is stuck in the memory.
-
About screenshots, very loosely related to the actual discussion,
A few days after getting my SD2104+ and as an exercise, I made a little Python script to download screenshots with a command line command. It is based on the Python example in the SCPI documentation. Code attached. You have to change the IP address accordingly and eventually specify python3 in the first line, depeding on your defaults. In my view, using this command is a little bit more convenient than using the browser option, because I can specify the name. In a different way convenient is storing screenshots to a USB disc by just pushing the print button. But then you have to rename the files later.
Edit: One Option (way down the preference list) for the save button would be to send the screen shots to a server instead of storing them to the USB disk. The server could be a standard type (like ftp) or a specialized one. The latter could handle the file naming itself, making the configuration at the scope easier (just the IP address of the server).
-
One Option (way down the preference list) for the save button would be to send the screen shots to a server instead of storing them to the USB disk. The server could be a standard type (like ftp) or a specialized one. The latter could handle the file naming itself, making the configuration at the scope easier (just the IP address of the server).
Existing web server functionality offers a Save Screenshot virtual key that sends PNG screenshots directly to your browsers download folder incrementing the PNG file # as you go.
Of course they still need renaming however once on your PC that's very easy.
-
Existing web server functionality offers a Save Screenshot virtual key ........
I know that and I used it. The difference is where the user actions takes place, at the PC or at the instrument. Obviously, the difference is minor if the PC and the instrument are placed side-by-side.
-
About screenshots, very loosely related to the actual discussion
I don´t think so, see text in the post.
-
Color Grade Bug or Operator Error?
The signal in the following screenshots is from the internal AWG. I believe it was a 100mV sine but reset the 'scope while trying to understand figure this out, so I don't know for sure. I think the important point is that the signal is from a consistent source. The data is from a single shot capture.
The first screenshot displays the bottom band at a higher temperature than the others. This should indicate more points around that level if I understand correctly.
The second screenshot, zoomed to show the data, shows this isn't the case; the dots are hard to see even with the graticule off, but there are an equal number of points in each band. The color grade, however, indicates equal data in all bands.
Is this expected behavior, and if so, why?
Thank you for your insight!
[attachimg=1 align=left]
[attachimg=2 align=left]
-
It would be interesting on how you have set the AWG. I get a similar picture with teh AWG set to 25 MHz. At a sampling rate of 4 ms/s, this is by far undersampled. That's why you get these 4 bands. Besides that I would not expect to get anything reasonable from this measurement.
As far as I understand, the color grade indeed tells how often a certain band in a trace is hit. But i do not know how that applies to a undersampled trace. Repeating single shots I get all kinds of color assignments.
Edit: If you switch back the display to vectors you may see a sine. In my case it is a 1 MHz sine, sampled from a 25 MHz signal. Complete nonsense, but to be expected.
Edit2: At least I see that you got dot mode working.
-
It would be interesting on how you have set the AWG.
I could kick myself for not saving the settings before I reset the 'scope.
That's why you get these 4 bands.
Agreed. But note that each band is comprised of the same number of points.
As far as I understand, the color grade indeed tells how often a certain band in a trace is hit. But i do not know how that applies to a undersampled trace.
I'm not sure how under-sampling could affect the math. With the same number of points in each band, should not each band display in the same color?
Given that color temperature should indicate the degree of difference from one area to another, the colors in the first screenshot would indicate a large difference between the top 3 bands and the bottom band; no such difference exists as illustrated by dot mode (I had no idea how useful dot mode can be).
Also note that the all bands are displayed in the same color in the 2nd screenshot. Why?
Edit: If you switch back the display to vectors you may see a sine. In my case it is a 1 MHz sine, sampled from a 25 MHz signal. Complete nonsense, but to be expected.
Agreed.
Edit2: At least I see that you got dot mode working.
I did, with help from this fine community. :)
I was playing with dot mode when I stumbled into my color grading question.
-
Help Formatting
It's nice to have a help system. It would be nicer if it were a bit more readable. :)
[attachimg=1]
-
Ssshh...secret tip....user manual....Sssh.. 8) :)
-
Ssshh...secret tip....user manual....Sssh.. 8) :)
Who can write manual about scope users to scope designers and FW programmers.
-
@casterle
I'm not sure how under-sampling could affect the math. With the same number of points in each band, should not each band display in the same color?
I do not know. Maybe the history comes into play too. With our setting there are 39 history traces stored.
Another note: You get these four horizontal lines in your screen shots only, because you use the internal AWG with the frequency being a multiple of 1 MHz. The internal AWG seems to be controlled by the same clock source as the sampling. Using other frequencies - like 24.999998 MHz, the pictures look different.
-
Ssshh...secret tip....user manual....Sssh.. 8) :)
Seriously?
-
Looking at the different color grades in your sample screen shot (and own tests) the different colors may be related to the different vertical distribution of dots within each line. Each of them has a red code. Each line represents 500000 dots, about 500 per screen pixel. So if the vertical distribution is small, you have a line with a red code and blue rim. If the vertical distribution is almost identical within the line, it looks solid red. In the zoomed view you do not see that, because the time between dots is constant. It would be bad if not.
-
Seriously?
Yep, I find it more comfortable than staring at the screen.
-
Bazirro-World "No-Dots-Mode Bug"
Playing with dot mode a bit more, I find the 'scope in a state where there is little difference between vector mode and dot mode.
In this state, toggling between dot and vector mode displays the vector lines very faintly, at perhaps 10% intensity, while the dots continue to display at full intensity. Is this a reflection of my earlier bug, where I could not get vector lines to turn off?
[attach=2]
[attach=3]
At first glance, other than the menu area, the two screenshots above appear to be identical, but are not. Close examination shows pretty much what I see on my 'scope, only the vector lines seem a little brighter and perhaps a bit broader on the 'scope.
[attach=4]
This time I've saved my settings and attached the .xml file. The settings file is huge; I didn't see anything that looked like a security problem (but I didn't look that hard), so I've attached it. I couldn't find a way to attach my settings file.
-
You had that effect already in your January 01, 2021, 06:47:02 pm post, and it was discussed then. It happens when you capture a signal at e.g. 1V/div setting, go to stop mode and then increase the vertical scale to e.g. 50 mV/div. Then you see discrete voltage steps in the dots, and the screen you see represents 10 million dots.
We agreed already that the way of interpolating with vectors is at least surprising. I would call it a bug. If you zoom in the time, you will see the wild and completely unneeded oscillation of connections between dot levels, not even between dots!
-
After carefully watching the whole discussion about the history reset strategy, I have talked to Siglent R&D and recommended to not only fix the obvious bugs (history reset by events that cannot affect acquisition), but maybe restrict the triggers for history reset to a sensible minimum.
I've been promised that history will be taken care of for the next firmware release.
-
(Attachment Link)
(Attachment Link)
Speaking of bugs, somebody from eevblog's team should fix that image attachment bug. ;)
-
I've encountered bug. After playing with zone triggering, I've turned this function off (while one zone was "on"). When the probe with sensing was connected/disconnected, scope displayed "zone too small" message on the screen - the same was displayed when I've connected bnc shield to the surrounding gold ring).
-
Got this problem too, but don´t turned on the zone trigger before.
Today I´ve tested my new probes with auto-sense and this message appears.
And:
When you switch between the units, V or A, the message will appearing too.
-
This is strange, because from the very beginning of operation with SDS2000X+ I used Agilent 500MHz probes with auto-sense and often switched between V and A, but I have never seen this message.
What should be done to receive this message?
-
Check it again on my scope, IAmBack is right :-+
Like he had, I got one zone "on", although zone trigger is disabled. After going into the zone trigger menu and deactivating the zone, the fault message doesn´t appear anymore - That´s clearly a bug and thanks to IAmBack !
-
Bug in the channeldialog box (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3408646/#msg3408646)
-
You had that effect already in your January 01, 2021, 06:47:02 pm post, and it was discussed then. It happens when you capture a signal at e.g. 1V/div setting, go to stop mode and then increase the vertical scale to e.g. 50 mV/div. Then you see discrete voltage steps in the dots, and the screen you see represents 10 million dots.
We agreed already that the way of interpolating with vectors is at least surprising. I would call it a bug. If you zoom in the time, you will see the wild and completely unneeded oscillation of connections between dot levels, not even between dots!
What I was trying to illustrate with the images is that the vector lines are draw n faintly when they should have been drawn in full intensity, like the dots. They are barely visible on the 'scopes display!
This, sir, in my Most Humble Opinion, is a bug. :)
-
I definitely agree that the way of joining dots leaves much room for improvement, politely spoken. Even if that is more obvious in an vertically expended view, it is also present in non-expanded view and makes the trace look more noisy.
-
In the Bode plot application, the maximum generator amplitude that can be set is 6Vp-p, which corresponds to the capabilities of the built-in AWG. But when using an external generator, the 6Vp-p limit remains, which is not correct. Having connected SDG2042X, I cannot set the amplitude to more than 6Vp-p, although the generator allows up to 20Vp-p.
-
In the Bode plot application, the maximum generator amplitude that can be set is 6Vp-p, which corresponds to the capabilities of the built-in AWG. But when using an external generator, the 6Vp-p limit remains, which is not correct. Having connected SDG2042X, I cannot set the amplitude to more than 6Vp-p, although the generator allows up to 20Vp-p.
Experienced the same issue with the SDG2042X, the Bode plot should be able to address the full output of the applied AWG, but is limited to 6Vp-p.
Best,
-
SDS2104x-plus, 1.3.7R5
I'd like to have this feature:
Zoom should include function channel.
========================
A calculated function F1 = C1- C2 is not displayed in zoom window.
Shot 1: 1ms/div
Shot 2: Zoom added with 50ns/div ==> F1 is missing in zoom window.
Shot 3: How the zoomed content should look like.
-
In the Bode plot application, the maximum generator amplitude that can be set is 6Vp-p, which corresponds to the capabilities of the built-in AWG. But when using an external generator, the 6Vp-p limit remains, which is not correct. Having connected SDG2042X, I cannot set the amplitude to more than 6Vp-p, although the generator allows up to 20Vp-p.
Experienced the same issue with the SDG2042X, the Bode plot should be able to address the full output of the applied AWG, but is limited to 6Vp-p.
Best,
The bandwidth of external awg should be respected too.
-
The bandwidth of the Bode Plot is 120MHz with external AWG, which exactly corresponds to SDG2122X. :) It would be nice, that it be equal to the full scope bandwidth, of course!
-
SDS2104x-plus, 1.3.7R5
I'd like to have this feature:
Zoom should include function channel.
========================
A calculated function F1 = C1- C2 is not displayed in zoom window.
If you want a math trace in the zoom window, then simply select zoom data (Z1 ... Z4) as the source for the math.
-
If you want a math trace in the zoom window, then simply select zoom data (Z1 ... Z4) as the source for the math.
That would mean to define the function twice. But its a workaround at least, thx!
-
SDS2104X, 1.3.7R5, Topic Persistence
This is a good instrument and a complex software, so the following comments feel like nitpicking, but anyhow:
- if you enable persistence, the first trigger event is not accumulated. That may not hurt for fast events, but for rare events it may matter.
- if persistence is enabled, and you change the trigger setting, persistence will be switched off, even if the display menu still shows, that it is switch on. You have to switch persistence manually off and on again, to get it back working. That is just another example of the many cases, that the menu does not reflect the internal state.
Best Regards, Robert
-
I checked - persistence captures the waveform after the first trigger event, in my case.
-
I noticed that with a signal source, which created two pulses with slightly varying distance. Triggering on the first pulse, the second would occur at different places. Actually that's what I wanted to test: the range of the variation. There I noticed that the accumulation though persistence started with the second pulse pair event.
-
I would really like to be able to select Math channels as inputs to the XY Mode, but I can't find any way of doing it with the current firmware. My PicoScope can do this and I find it useful.
-
Hello world,
my first contribution is a bug report... >:D
I came over the following:
When recalling stored settings from an xml-file, attributes of DECODE->Bus display->Format are reset to "binary", regardless of what was set before.
In particular, I haven't verified yet, whether this happens during save or load - anyway it might be more efficient to have the code-owner @ Siglent look into it.
FW: 1.3.7R5
++Umgfoin.
-
Persistence/Colour grade missing on math traces, FFT averaging weak performance (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3475114/#msg3475114)
-
Hi,
After starting up the web interface page while the scope was booting, I no longer am able to see the scope screen (just white background plus buttons) on the web control nor use the Home or Lan Config button from that page. The buttons for firmware, save, etc. do respond. The home page, Lan Config, and SCPI are accessible when loading the home page by the scope IP. I am using firmware 1.3.7R5 and tried re-flashing both from the web page (since that button does work) and from USBdrive with no change.
Is there a way to reset the web/vnc server in the scope?
-
Hi,
After starting up the web interface page while the scope was booting, I no longer am able to see the scope screen (just white background plus buttons) on the web control nor use the Home or Lan Config button from that page. The buttons for firmware, save, etc. do respond. The home page, Lan Config, and SCPI are accessible when loading the home page by the scope IP. I am using firmware 1.3.7R5 and tried re-flashing both from the web page (since that button does work) and from USBdrive with no change.
Is there a way to reset the web/vnc server in the scope?
Does a reboot fix it ? Maybe accessing the web browser before the scope was fully booted caused the problem. :-//
Deleting the IP configuration can be done with the Secure Erase feature but it may also delete other settings.
-
I did try several reboots - some associated with the reflash attempts. I also tried resetting the IP config and changing/restoring the vnc port number (back to 5900 now). The issues is consistent between browsers from two different computer, so definitely an issue in the scope. I am guessing a file got corrupted. I found the reference for telnet access and started looking at the filesystem, but not sue where to start looking for the file for that page (or how to fix it if found).
I am not familiar with the secure erase.
Found and tried the security erase followed by a reboot, but no change.
-
I did try several reboots - some associated with the reflash attempts. I also tried resetting the IP config and changing/restoring the vnc port number (back to 5900 now). The issues is consistent between browsers from two different computer, so definitely an issue in the scope. I am guessing a file got corrupted. I found the reference for telnet access and started looking at the filesystem, but not sue where to start looking for the file for that page (or how to fix it if found).
Suggestions might be to install the latest firmware again.
I am not familiar with the secure erase.
I was to say RTFM but it's not mentioned there. :-//
SDS5kX that should be the same: Save/Recall>Recall>Security Erase
At worst if the OS is somehow damaged we can recover it to normal, PM me if we need go down that track.
-
SDS2104x-plus, 1.3.7R5, Manchester Decoder
On additional note about that decoder, which I forgot. It works mostly right. Just the last byte of a message will not be decoded, unless at least one trailing bit follows. It may not be a real issue if all practical applications send a few trailing bits after the last data bit. But the trailing bit is not needed for decoding.
I agree with Roberthh
The protocol config does not allow to set the 'idle bits' to 0 (min value is 2) this prevents the end of the data to be decoded, see the attached screenshot, adding 2 idle bits in my tests app make it works but that should not be required
-
I think i found a bug,
my siglent SPD3303X got odd random time delay between analog channels and logic analyzer.
or ? am i doing something wrong here ?
or is this really how it is supposed to be ?
see this video:
https://youtu.be/WzokRBxDM-g
PS: i am using my own logic analyzer input pcb, but as you see now with my latest speed trimmed resistor values
the digital to digital channels are perfectly fine, with in 2nS jitter = normal = the time resolution for LA.
This should be very easy to recreate, 25MHz 5V signal
also the attached picture : it shows the digital inputs are 16.6nS ahead of analog channels,
and on this ahead time, there is a lot of jitter, any one else seen this ?
UPDATE : Ahead time is a DESKEW adjustment in the digital menu.. NOT A PROBLEM, a cool feature for cable length compensation.
---
UPDATE : I was doing something wrong ! use the AWG (Advanced Waveform Generator) as clock source to your electronics,
completely removes the kind of jitter mentioned in this video.
All clock sources, Digital, Analog, AWG are delivered from the SAME internal master clock,
and by running your circuit of the AWG, your circuit is not free running.
-
It seems that the “three month rule” no longer works.
More than 4 month have passed since the latest firmware release, and no info about future updates. Even though the oscilloscope still has a lot of errors. :popcorn:
-
"Lots of errors"....
I hope you can still work with it, with all the errors.... ;)
-
try this :
have timeout enabled on pop up screen menu,
click ch1 analog
click apply to, an extra menu apear, now wait for time out,
and the apply to, screen stay there.
-
"Lots of errors"....
I hope you can still work with it, with all the errors.... ;)
In my opinion, the way the scope cripples the waveform to make it look like a staircase when shrinking the screen (right menu open) is a serious bug
-
"Lots of errors"....
I hope you can still work with it, with all the errors.... ;)
In my opinion, the way the scope cripples the waveform to make it look like a staircase when shrinking the screen (right menu open) is a serious bug
Then go into Utility Display and change how the menu is displayed......this feature was added in the last firmware. ;)
Edit
Sorry, this is in the Display menu;
Supported floating menu so that the waveform is not compressed horizontally when the right-side menu is displayed: Display | Menu Style
-
"Lots of errors"....
I hope you can still work with it, with all the errors.... ;)
In my opinion, the way the scope cripples the waveform to make it look like a staircase when shrinking the screen (right menu open) is a serious bug
Then go into Utility Display and change how the menu is displayed......this feature was added in the last firmware. ;)
Edit
Sorry, this is in the Display menu;
Supported floating menu so that the waveform is not compressed horizontally when the right-side menu is displayed: Display | Menu Style
Really? Thanks for the good news, I am going shopping right now
-
"Lots of errors"....
I hope you can still work with it, with all the errors.... ;)
In my opinion, the way the scope cripples the waveform to make it look like a staircase when shrinking the screen (right menu open) is a serious bug
Then go into Utility Display and change how the menu is displayed......this feature was added in the last firmware. ;)
Edit
Sorry, this is in the Display menu;
Supported floating menu so that the waveform is not compressed horizontally when the right-side menu is displayed: Display | Menu Style
Really? Thanks for the good news, I am going shopping right now
Yep, really back in Nov 2020.
Unlike you I prefer it to compress the display rather than cover part of the waveform but each to their own. ;)
Recent units have the autohide menu setting engaged and just for 3s as some factory default :-// which IMO is bloody annoying to change as you only have 3s to do it before the menu disappears.....puzzled who at the factory would think it was a good idea to ship units with that configuration. :rant:
No worries if you know your way around the UI but for those that don't ............
-
In Bode plot mode. How does one stop the active sweep so one can save the File.jpg of display.
-
In Bode plot mode. How does one stop the active sweep so one can save the File.jpg of display.
Use of the blue Print button will instantly capture whatever is on the display and save it as a PNG to a USB pendrive.
You can use Stop then Print or select from the Save/Recall menu and use various other filetypes.
-
In Bode plot mode. How does one stop the active sweep so one can save the File.jpg of display.
ETA: Tautech answer just when I was writing answer...
First, Please do NOT use jpg for technical graphics when it is using lossy packaging.. Png is much much better.
You have never read user manual? Is it fun they write these manuals, deven they are poor but least these minimalist user manuals need be read. Are these manuals difficult to read... how can read this answer here now. ;) ;)
If you use USB flash. Just push blue "Print" button.
What ever you do with scope... display copy is saved to USB flash when you push oscilloscope front panel blue "Print" button.
If you use PC Web browser directly to computer click oscilloscope web side button "ScreenShot" under scope live screen image.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1197980;image)
-
In Bode plot mode. How does one stop the active sweep so one can save the File.jpg of display.
First, Please do NOT use jpg for technical graphics when it is using lossy packaging.. Png is much much better.
If you use USB flash. Just push blue "Print" button.
You have never read user manual?
What ever you do with scope... display copy is saved to USB flash when you push oscilloscope front panel blue "Print" button.
If you use PC Web browser directly to computer click oscilloscope web side button "ScreenShot" under scope live screen image.
Analog4 is doing their homework while waiting for the scope to arrive:
Hi Rick,
I am looking to purchase a oscilloscope Siglent SDS2104X Plus from Saelig.
Is it still possible to get a discount?
-
In Bode plot mode. How does one stop the active sweep so one can save the File.jpg of display.
First, Please do NOT use jpg for technical graphics when it is using lossy packaging.. Png is much much better.
If you use USB flash. Just push blue "Print" button.
You have never read user manual?
What ever you do with scope... display copy is saved to USB flash when you push oscilloscope front panel blue "Print" button.
If you use PC Web browser directly to computer click oscilloscope web side button "ScreenShot" under scope live screen image.
Analog4 is doing their homework while waiting for the scope to arrive:
Hi Rick,
I am looking to purchase a oscilloscope Siglent SDS2104X Plus from Saelig.
Is it still possible to get a discount?
So, even more. Now is good time to read the user manual from front side to back side, every side, every sentence, every word, twice and repeat in reverse order. And then iterate this as many times as need.
-
>So, even more. Now is good time to read the user manual from front side to back side, every side, every sentence, every word,
> twice and repeat in reverse order. And then iterate this as many times as need.
if we all did this, the forum will be quite dead ?
-
if we all did this, the forum will be quite dead ?
I can imagine there might be some tiny little parts of the world, that are not described in manuals and worth to be discussed here. :)
-
exactly Peter, that is what i understand rf-loop kindly suggest we focus a little bit more on, as i read it politly :-)
-
This is not really a bug, it was more of a question, that did not seem to have an answer.
I have been reading the SDS2100+ manual in printed format, but it would probably be easier in to read it in electronic form. It may take awhile for me to get used to the format. I like to read the overview for context first, then look at the details (like hypertext). This manual mostly gives lots of step by step details.
The details are spread out loosely over so many printed pages, one needs to find the right detail in a separate section. The step by step format makes it hard to see the big picture for the details.
The search function for words in the PDF file do not seem to work for me.
In Bode mode, none of the buttons seemed to be able to hold the sweep. Stop & Print did nothing as far as I could tell from the zero response. I could try to save (but will not save while sweeping the data on the screen), but could not stop the sweep without the screen erasing.
The answer is probably obvious, once I know what the answer is.
-
This is not really a bug, it was more of a question, that did not seem to have an answer.
I have been reading the SDS2100+ manual in printed format, but it would probably be easier in to read it in electronic form. It may take awhile for me to get used to the format. I like to read the overview for context first, then look at the details (like hypertext). This manual mostly gives lots of step by step details.
The details are spread out loosely over so many printed pages, one needs to find the right detail in a separate section. The step by step format makes it hard to see the big picture for the details.
The search function for words in the PDF file do not seem to work for me.
In Bode mode, none of the buttons seemed to be able to hold the sweep. Stop & Print did nothing as far as I could tell from the zero response. I could try to save (but will not save while sweeping the data on the screen), but could not stop the sweep without the screen erasing.
The answer is probably obvious, once I know what the answer is.
Can't you just stop sweep on touchscreen button that you used to start the sweep?
Also you should be able to set the sweep to do single sweep and stop.
-
In Bode mode, none of the buttons seemed to be able to hold the sweep. Stop & Print did nothing as far as I could tell from the zero response. I could try to save (but will not save while sweeping the data on the screen), but could not stop the sweep without the screen erasing.
In Bode mode, none of the buttons seemed to be able to hold the sweep.
If you mean "hold sweep" as stop sweep and stay in this position and keep measurement still active just in this stopped frequency position... there is not this kind of "hold sweep" function.
If you want this kind of function please explain some important case when this function is needed or useful.
But, if you want only stop it, during sweep, to some position. Just select "Operation" and [Off]
It stops sweeping and leave bodeplot screen just as it was when turn "Operation" [Off].
Also in this situation you have full control to vertical adjustments for amplitude and phase. Even things what are outside of top or bottom they all are there. All what is plot as visible traces are totally secondary. Whole heart of BodePlot is data table inside system. When it run it write this Bode Plot primary data table. From this data table it draw traces and if you select data table visible, this is highly reduced data table and only one channel table derived from whole primary table(s). No need go further deep now...
When you have stopped it. If you then select "Operation [On] it do not continue from position it was stopped. it start whole new stepping sweep from defined start frequency.
It is of course stepping sweep.
It command generator to some frequency and level (if mode is Vari-Level it can also change level during sweep as user have defined, whole sweep can be frequencysweep combined with level sweep). After then BP look levels and if need adjust optimal sensitivity (automatic level control) and after then it start measure. And this measurement "receiver" is also frequency selective. It do not listen other than just this step frequency. (of course with some RBW what not very narrow)
No need go to further deep... Last image show this RBW when frequency is 450kHz. This have NOTHING to do with resolution. Resolution come from sweep steps and device under test. (This freq. selectivity reduce noise and eliminate some possible DUT generated spurs)
This make it bit slow but advantage is high dynamic range. It can be Up To 140dB what is really lot. Down from 0dBm still always better than -80dB and depending frequency and noise criteria even down to -100dB. Upside rejecting factor is oscilloscope maximum input level. It can handle this range in every single sweep step! Down to 1Hz steps if span is 500Hz.
It sweep more fast if turn Automatic level control off (Channel gain control [Auto] / [Hold]. Hold is ALC off).
Stop & Print did nothing as far as I could tell from the zero response.
Please explain what you try tell. And what is Stop&Print
When scope is in FRA aka BodePlot mode oscilloscope front panel button [Run/Stop] have no function. As told previously BP have its own on/off button in its menu but there is not physical button in front panel.
When scope is in BP mode front panel physical button [Print] works just normally, when ever you push it, it take snap shot from TFT and save image to USB flash in BMP, jpg or png format. And there I will recommend using only png if not some real important reason to use others. BMP is slow. Jpg smudge image because in this case it use usual lossy packaging. Png do lossless packaging and image file sizes are small.
When you push Print button it do not suspend anything, it take just copy from current TFT frame.
I could try to save (but will not save while sweeping the data on the screen), but could not stop the sweep without the screen erasing.
What you mean with this "save".
If you mean save screen image, just look previous.
If you mean saving bode plot full resolution full sweep primary data table. This can not do when BodePlot is running.
In this case need first do "Operation" [Off]
It leave sweep trace visible.
After then you go to BodePlot "Data" menu.
You select "Save" in this menu and then you see menu for select where you want save it and for give name for file. It save whole data table in .CSV form.
And btw, if you have this saved primary data table. If you some day want look it with scope BodePlot function.
Just Recall this table back tp scope. All is just as it was when it was originally when it was working, it draw trace(s) and you can adjust vertical positions and zoom vertically in and out as you want, but not horizontally.
Because it is just this primary data table what are heart of whole Bode Plot.
So, during sweep you can stop it in what ever position. After start again it start from new sweep from start freq.
Always, when ever it is running or stopped you press Print hardware button and it save TFT image to USB.
For saving hidden primary data table you need stop it and save.
All these images have saved during sweep. One is saved durig first sweep so trace is not full.
Others are saved during continuous sweep.
Note this one image red trace go over screen bottom. Still its data is there... even if it goes far away until noise bottom. And same if happen top border. All is there.. just change scale or move window up or down... because all is in primary data table and what trace is plotted to screen is only secondary thing. Also visible data table data resolution is really highly truncated from primary table. Primary data table have full resolution... more than enough.
Here four sample images using "Print" button.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1198750;image)
In this image sweep was just started and during sweep adjusted manually some vertical scale and reference levels and then pushed "Print" button... without suspending sweep, just on the fly.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1198754;image)
Here continuing sweep and position where is its going is this small ball in trace. Just Print button snap shot on the fly.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1198758;image)
Here continuing sweep and position where is its going is this small ball in trace. Just Print button snap shot on the fly.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1198770;image)
Here Bode Plot "Operation" [Off] and after then Print button for this image. And when it is [Off] also if want, full resolution primary data table can save to USB in .CSV format what then can open in exel, open office/libre office, and many other softwares what can handle CSV data, or just read it in notepad if one is some kind of masochist..
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1198796;image)
As told prevuiously and many many times, Siglent SFRA is working as frequency selective level meter. Generator sweeps and syncronously receiver also sweep and using some RBW filter. Here example what is RBW filter when freq position is 450kHz. RBW width is not constant, it is variable and it automatically change rlaltive to current frequency point. User can not change it.
There is one disadvantage in this method. DUT output frequency need be sqame as DUT input frequency. It can not sweep measure devices what convert frequency, example mixers etc.
Perhaps, I hope, some day Siglent add one selection for user so that user can select selectivity off or on. Just as selective and full BW. Of course wide have not same dynamic but some times this may be useful. ALC on/off there is but not freq. selectivity on/off.
-
I've recently been using the AWG a fair bit, and wanted to adjust the frequency over a small range (<1Hz in 10kHz) using the "universal" knob but it seems to only be able to control the second most significant digit (1kHz in 10kHz). I have had to resort to typing each frequency which is painful |O. Am I missing something, and is there a way to adjust which digit the "universal knob" controls? If not could it be added (something like pressing the "universal knob" to cycle through the digits). Hopefully it can already be done and I am just being a bit dim. ::)
-
The awg function is a little bit rudimentary as it doesn´t got sweeps for example.
Hopefully, they "fixed" it in a future update( for me it doesn´t matter, I got an sdg1062X)
By the way...
Last update was in november 2020, maybe the next would be a real "big one"... 8)
(Or they´re busy with other projects...)
-
It should be a very simple modification to make pressing the "universal knob" change the scaling when the knob is rotated so hopefully they will see this and implement it sometime soon. The main "vertical knob" already works in a similar way.
-
I found a small but important typo in the User Manual (UM0102XP-E01B):
On page 216/335, the Main Lobe Width for the Rectangle Window should read 4π/N and not 23π/N.
I’ve found some other typos along the way (e.g. missing reference - in Chinese! - for item F on page 205/335, or references to nonexistent keys or buttons on the control panel, these being probably carryovers from the SPS5000X manual) but the one above is more relevant, I think, and should be corrected in a future version of the Manual.
-
Firmware version: 1.3.7R5. Here is a GUI bug/typo which I found:
- The icons for rise and fall time in the Horizontal Measure Select screen are reversed. The "10-90%Rise" and "90-10%Fall" options are graphically depicted with L/U and U/L, whereas the user-adjustable options "Rise Time" and "Fall time" are illustrated graphically by 10/90 and 90/10. See screenshot.
This may sound like a small issue but it proves that attention to detail is far from the best for this Chinese manufacturer. And this is to say nothing about the many errors, typos and omissions I found by RTFMing! :palm:
-
Firmware version: 1.3.7R5. Checking out the effect of ERES on random noise, as follows:
- C1 = Random noise from the AWG
- C3 = Square wave from the probe calibration port
- F1 = C1 + C3
- F2 = ERES (F1)
The 0.5-bit option for ERES is greyed out and cannot be selected. Note that only the 0.5-bit option is affected.
The ERES 0.5-bit option does not work regardless if the ADC is set to 8 or 10 bits.
However, ERES 0.5-bit works for ERES(C1), but not for ERES(F1). I did not test the Digital or Reference channels.
-
Firmware version: 1.3.7R5. Setting up the user-adjustable rise- and fall-time measurements under Measure -> Menu -> Config -> Threshold ->Type. Once can select the Type between 'Percent' and 'Absolute'.
- C1 = Sine wave from the AWG, 1kHz
- C3 = Square wave from the probe calibration port
- F1 = C1 + C3
The Percent option appears to be working fine.
The Absolute option does not work for for the direct input channels, e.g. C1, C3, etc. The error reported is: "Invalid threshold", irrespective of the Upper/Middle/Lower voltage values selected. However the Absolute option functions apparently just fine for the Math channels, e.g. F1(C1+C3). I did not test the Digital or Reference channels.
In the screenshots provided the Absolute voltage values are calculated to match the Percentage values, and the Absolute measurement setting clearly does not work for the C channels.
-
@Michael YYZ Did you ever mention the firmware version used for your test?
-
I presumed, incorrectly obviously, that people would assume it’s the current (i.e. latest) firmware version. I went back and added this important information to my three previous posts. Thank you for pointing this out to me.
@Michael YYZ Did you ever mention the firmware version used for your test?
-
The Absolute option does not work for for the direct input channels, e.g. C1, C3, etc. The error reported is: "Invalid threshold", irrespective of the Upper/Middle/Lower voltage values selected. However the Absolute option functions apparently just fine for the Math channels, e.g. F1(C1+C3). I did not test the Digital or Reference channels.
The X10 probe setting in the vertical menu is not being used correctly by the software.
If you change to X1 in the vertical settings menu, and adjust the threshold values to suit, the absolute thresholds will work.
It will also work with X10 probe setting in the vertical menu if you use the threshold values fo X1 setting.
Regards.
-
Gosh! I checked and you are perfectly correct. :-+ Thank you!
The voltage threshold and the resulting measured values are indeed correct if the probe and the scope's software settings are set to 1X.
However, on 10X (and likely on other probe ratios as well, other than 1X) the scope's software does not correct the threshold voltage values with the factor of the probe. This results in the set threshold values being far above and below the pk-pk voltage of the trace and leads to failed measurements. One would have to reduce the voltage threshold values manually by the factor of the probe, e.g. divide the voltage by 10X for 10X probes, etc. I have posted screenshots for exemplification.
In my opinion, this is a serious bug :palm:; I wonder, however, if people from Siglent read these posts and really care about fixing these issues. :-// If not, at least we are helping each other here. :clap:
The X10 probe setting in the vertical menu is not being used correctly by the software.
If you change to X1 in the vertical settings menu, and adjust the threshold values to suit, the absolute thresholds will work.
It will also work with X10 probe setting in the vertical menu if you use the threshold values fo X1 setting.
Regards.
-
When using digital channels, I want to be able to rename some of the digital channel labels. Fine, but I cannot see a way to get overbars. Sure I can write OEBAR but I'd rather have OE with a overbar.
Is this something that can be added to the channel setup keyboard?
-
When using digital channels, I want to be able to rename some of the digital channel labels. Fine, but I cannot see a way to get overbars. Sure I can write OEBAR but I'd rather have OE with a overbar.
Is this something that can be added to the channel setup keyboard?
You can use ~OE instead
-
Last FW update was nearly a half year ago...Do we get Rigol behaviours now.... :scared:
-
Terrible thought, Martin!
It's okay for a bug-free device, but this one is clearly not.
One reason for which I selected Siglent vs. Rigol was the apparent tree-month firmware update cycle... which appears now to be broken.
Last FW update was nearly a half year ago...Do we get Rigol behaviours now.... :scared:
-
Still no worse than R&S... ^-^
And I, for one, wouldn't like if they would release minor updates just to release something.
Some changes require serious testing and need time.
That is the reason why R&S releases on quite sparse schedule.
For bugs you need to analyse bug and find a problem, devise solution (sometimes there will be dozen of potential solutions, and you need to chose which one to implement), test it in isolation, integrate it, test integration, then test for regressions (that you didn't create new bugs somewhere else), then create and test installation... Then you release to beta, and if that goes well, it gets released.
That is a short, very simplified version.
These scopes are quite sophisticated, sometimes it takes time.
Especially if you are listening the customer, so you are trying to implement many changes and improvements.. They don't have a magic wand... ^-^
@ Michael YYZ, Siglent does read EEVBLOG AFAIK, but it is not a primary channel to report. You can report to Siglent NA directly if you would like acknowledgement that it was received.
That is same for all manufacturers here, they help people here out of courtesy, but official channel is, well, official.
-
I’ve already reported the bugs found by me to Siglent NA and they quickly acknowledged receipt. Nice! :-+
@ Michael YYZ, Siglent does read EEVBLOG AFAIK, but it is not a primary channel to report. You can report to Siglent NA directly if you would like acknowledgement that it was received.
That is same for all manufacturers here, they help people here out of courtesy, but official channel is, well, official.
-
Terrible thought, Martin!
There are two possibilities, they´re working on a real big one and testing time is long.
Or they are too busy at the moment.
We´ll see.
-
Couple of bugs in 1.3.7R5 in digital signal analysis.
1) Sequence capture does not work with serial trigger from digital channel (when analog channels are turned off).
The capture can be set up properly, but when it's executed, it does not update sequence counter, and the capture never ends (I can see from Trig blinking that the trigger is hit). When I stop it manually (by pressing History), I can see the first triggered buffer, even though it shows buffer 0/0.
[attach=3][attach=5]
Exactly same scenario, triggered from analog channel works as expected. Even just having analog channels enabled somehow allows the capture to proceed.
[attach=4]
2) Entering XX in the serial trigger from the dialog window still does not work. There is no on-screen key for "X" and when there is XX in hex or XXXX XXXX in binary (as it is when XX is previously in the field, or entered via web interface or external keyboard) it gets changed into zero.
As a workaround, I can enter XX by scrolling universal knob. Not sure whether setting individual bits to X is not supported by scope or supported, only impossible to enter in the UI.
[attach=2]
3) Decoding I2C addresses does not display correct address. It includes read-write bit. Triggering works correctly e.g. when I set trigger to I2C address 0x40, then decode window shows 0x80 and 0x81, both in the bottom of the screen and in the decoded table.
[attach=1]
-
Couple of bugs in 1.3.7R5 in digital signal analysis.
1) Sequence capture does not work with serial trigger from digital channel (when analog channels are turned off).
That is really odd, and is definitely a bug. The presence or absence of analog channels shouldn't affect the sequence capture mechanism.
I presume this is limited to explicit sequence capture? The only reason you'd need to use that is if the normal capture mechanism is skipping frames, since the scope always uses segments for captures anyway.
2) Entering XX in the serial trigger from the dialog window still does not work. There is no on-screen key for "X" and when there is XX in hex or XXXX XXXX in binary (as it is when XX is previously in the field, or entered via web interface or external keyboard) it gets changed into zero.
As a workaround, I can enter XX by scrolling universal knob. Not sure whether setting individual bits to X is not supported by scope or supported, only impossible to enter in the UI.
(Attachment)
I don't think you can set individual bits to X. It would be awfully nice if you could. There wouldn't be a good way of displaying the trigger's configured address in hex, of course, if one were to do that.
Note that one of the buttons in the dialog is "default". If you hit that, you get the "don't care" value. That button really should be renamed "don't care".
3) Decoding I2C addresses does not display correct address. It includes read-write bit.
This one bit me as well, and it's not a bug. See https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3380846/#msg3380846 (https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg3380846/#msg3380846)
There's a setting in the decoder that says "include R/W bit", located in the "protocol config" section of the decoder configuration. You need to turn that off. Turn it off and the addresses will display properly (or, more precisely, as you expect).
-
Greetings to the forum :-)
It's really disappointing, that especially the 1X / 10X bug will not be fixed in a short time frame, e.g. hot-fix.
Also the scope is out now for a longer time and the number of bugs should be get smaller over time I guess. At least the QA should be familiar with the scope / SW and ensure that basic functions like 1X / 10X etc. is checked before FW release!? :o
-
I never saw a good answer to this question, so I thought I'd give it a shot, even though it's been a while...
Hi,
After starting up the web interface page while the scope was booting, I no longer am able to see the scope screen (just white background plus buttons) on the web control nor use the Home or Lan Config button from that page. The buttons for firmware, save, etc. do respond. The home page, Lan Config, and SCPI are accessible when loading the home page by the scope IP. I am using firmware 1.3.7R5 and tried re-flashing both from the web page (since that button does work) and from USBdrive with no change.
Is there a way to reset the web/vnc server in the scope?
It's entirely possible, particularly given the things you've done by now, that this isn't a problem with the scope itself, but rather with the browser. The browser will cache web page data it has on hand until either it replaces it with other data or the source gives it some information to indicate that the cached data is stale.
In light of that, there are a couple of things you can try:
1. Hold the shift key down and hit the "reload" button on the browser. In the browsers I've used, this will tell it to treat all data served up by the source as being "stale", which should then force the browser to re-retrieve it from the source (which in this case is the scope).
2. Explicitly clear your browser's cache. How you do this will differ across browsers but in general, it'll be buried in the preferences dialog structure somewhere.
If neither of those works then it's an issue with the scope, and you may need to get Siglent involved in fixing it.
-
Hi
I briefly could not find anything about this.
I have a problem with the cursors.
They some what can't be moved a cross the right and left sides of the screen (time mode).
Let say you are in Zoom and selected the top full view.
Starting with the cursors on to the left side of what is visible in the lower (zoomed) view.
Cursors are now on the left side of the black region.
Select both cursors in the upper view and try to move them right into the black (zoomed region).
Can not be done, you cant enter the zoomed area.
Now move the black (zoomed) region instead to the left and you will now get both cursors visible in the zoom view.
But you can not move the cursors outside the zoomed bottom view.
This also happens in non-zoomed situation, if the cursors are outside and you cannot get them in.
Let say you have both cursors inside left and right edges and the trigger position in horizontal center.
You can now adjust each of them.
Now change the horizontal scale so both hits the left and right side of the screen.
They are now stuck at the edges, no matter how much you turn the knob the will not move.
I would suggest removing the border control and adding a new feature instead.
When the cursors are outside and you want them to be visible, hold / press the Universal dial (the one you use when moving the cursors) for a longer time.
This will reset the position and place them centered with a half screen distance a part.
SDS2104X Plus Version 1.3.7R5
/Thanks
-
Hi (again)
Here is another thing.
When I trigger on a digital sequence it would be nice to be able move the center mark position.
Let say you trigger on a longer sequence with 50ms/div time.
Then for going into details I change the time base to 5ms/div.
Going up and down in time base is easy when the trigger point is on the horizontal center mark (Pushed Zero on the horizontal knob).
But everything before the trigger point is not interesting so I move the trigger point to the left.
I will now see more what happens after trigger point.
But if you change scale (let say 1ms/div) your trigger point fly's left and you have to adjust horizontal position.
This movment when the time base is changed is timely unnecessary thing and would easly be solved if the center marked could be moved.
Maybe this can already be done......
I found it!!!
It's under UTILITY / Reference Pos / Horizontal Ref Pos.
Nice :-+
-
Good.
Also bit exercise and perhaps you find these your previous message cursors also works. Just tried and what ever I do I can not find or hit situation what you told. I did even "blind monkey" and "never used oscilloscope before" tests procedures and still no problem with cursors. Naturally it do not proof something* do not exist (*something because your explanation was not completely gapless). Proofing that something do not exist is difficult. Proofing something exist is more practical so next is for it.
If you find/feel still there IS some problem/error, then please, reset your scope to well known factory initial state and start from it. Then write down all steps so that all can repeat exactly. (so that it can repeat fully and exactly just as you, and with images.) If there is error what can repeat, it makes more easy to repair it. ;)
With new instrument learning curve is... every day you find new things and there is - lot.
-
Yes, as you say learning curve ^-^
Fond that CURSORS / CursorX Ref: Position, changed the behavior to some what more normal mode.
Also UTILITY / Reference Pos / Horizontal Ref: Position has an impact on this.
Seems that I had these 2 in Delayed.
Wonder if I can get the cursors to follow when I change horizontal time base?
As now they are screen-fixed and delta read-out change when time base is changed.
-
I searched this thread and didn't find the NFC decode option. Keysight has an application note https://www.keysight.com/us/en/assets/7018-05761/application-notes/5992-2337.pdf?success=true (https://www.keysight.com/us/en/assets/7018-05761/application-notes/5992-2337.pdf?success=true) to do the NFC decode step-by-step. SDS2000X plus also has a Manchester decode option. Can it be used to decode NFC?
-
I asked about this in the main thread, but didn't get any replies, so I assume this is not possible in the current firmware. Consider these as feature requests.
I don't have this scope, but I'm curious of a couple of things for audio use.
1. There was a post a while ago asking about getting THD calculated when using the FFT. Any news about that?
2. Would be nice to be able to display watts, and perhaps the formula editor could be the way to go. I can't see any way of using measurements in the editor however. Is it possible to enter something like this? RMS(C1) * RMS(C1) / 8
Ideally it would be a custom "measurement" since it doesn't need a trace, but I can't see a way of doing that.
-
Some more feature requests.
1. WiFi has been mentioned before. Would be nice with an AC-dongle that supports the 5GHz band.
2. NTP support, recently released for the SDS1000X-E series so maybe big brother can get that too.
3. Related - time zone support, also added to SDS1000X-E. Screenshot files have the wrong time metadata associated since the time zone is missing.
4. Option to use the date and time (sortable format) in the filename of screenshots instead of a counter. Sometimes it's nice to remove old screenshots from the memory stick, but then the counter resets (atleast the SDS1000X-E does that), and I get duplicate filenames on my computer so I can't put them in the same folder.
-
Probably I'm alone with this request, but letting aside the zooming by "drawing" a rectangle area and the ability to measure frequencies also for falling edges, I also miss the ability of LeCroy scopes to measure (y) values of all the channels for a cursor position. E.g. even the WS3000 will display the values for all channels for each of the two cursor positions. For the SDS5000X/2000X there is only one (y) value that can be displayed for one cursor. So to measure two values at the same position (e.g. voltage and current), you need both cursors instead of one. Which makes it impossible to measure more than two values, letting aside all four values at two positions. This is somewhat limiting in some situations, specifically for screenshots to document one or two certain states.
To illustrate this, here's a screenshot where I used to cursors to measure two different voltages at a specific position. It' s OK for this case, but to with two cursors measuring both (or all) values, I could have marked the start and end of that little dent on channel 1.
[attach=1]
This being said, there's another great feature of LeCroy scopes which I miss on my SDSX5000, namely the visualization of the current signal rising/falling state that's very helpful when placing cursors. I.e. when trying to place a cursor on a falling edge, a LeCroy scope will help you find that edge manually by painting a rising or falling arrow at the cursor position. So if the signal is currently falling, the arrow fill be placed at the x/y position of the current sample, pointing down. If the signal is currently rising, the arrow will point up instead. So you can safely place the cursor in the middle of the edge without zooming in.
-
Finally, Siglent has published a new firmware version for the SDS200x Plus Version 1.3.9R4. The Revision record shows quite many added features and bug fixes.
-
Bug in the latest firmware (1.3.9R4): if you have all non-bandwidth licensed options enabled permanently (i.e., you've put in a license code for all of them), attempting to access the options page from the utility menu will hang the scope solid and will close any SCPI connections to it as well. Sounds like a hard crash to me. Deleting the license for one of the options makes the options page work again.
If I weren't such a wuss, I'd open up my scope and attach to the serial header to see what the console messages have to say. But it's certainly sufficient to say that this appears to be a real bug, easily reproduced.
We might end up seeing another firmware update in the relatively near future as a result of this. One can always hope. :)
-
Interesting. How do you delete and option using the SCPI commands?
-
I have all options enabled, including bandwidth upgrades, and experience no hanging around the options screen :-//
(I'm not saying there isn't a bug, just that it is fine on mine)
-
Did you enable the MSO option as well?
-
But it's certainly sufficient to say that this appears to be a real bug, easily reproduced.
Up till now, it looks like only you have the "bug" so I wouldn't call it "easily reproduced".
-
Did you enable the MSO option as well?
Yes, LA/MSO enabled.
-
Interesting. How do you delete and option using the SCPI commands?
Removing a license on the SDS2000X+ can be done by
LIC:DEL MANC
-
I have all options enabled, including bandwidth upgrades, and experience no hanging around the options screen :-//
(I'm not saying there isn't a bug, just that it is fine on mine)
Hi,
Same here !
Just did the upgrading a few minutes ago, no problems at all.
-
But it's certainly sufficient to say that this appears to be a real bug, easily reproduced.
Up till now, it looks like only you have the "bug"
I'm not the only one. In fact, I reported it only because someone else reported it and I attempted to reproduce it (successfully). Here's the first mention of the issue: https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3671614/#msg3671614 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3671614/#msg3671614)
so I wouldn't call it "easily reproduced".
Turns out that this won't reproduce unless you have a lower bandwidth than the full 500 MHz enabled. In my case, I was at the stock 100 MHz bandwidth on my scope.
When I took it to 500 MHz, the problem disappeared. I haven't tried it with any of the intermediate bandwidth options, nor have I tried reverting back to 100 MHz. I can try that and report my findings.
So, the necessary conditions seem to be:
1. A lower-than-maximum bandwidth
2. All non-bandwidth options enabled.
EDIT: I lowered the bandwidth to 350 MHz and, sure enough, the problem reproduced. As such, it's clear that if you have any bandwidth upgrade options available to you, the problem will probably reproduce.
-
It was pointed out in the main thread that firmware updates are not cumulative. This should be documented in the firmware update instructions.
The last FW update has about half the size oft the preceding updates.
Thats interesting ?
No problem. All help/language files what have no changes do not need update.
But that means it's not a cumulative update, but requires a certain minimum version to build upon?
-
Hi,
Axis-labeling (new firmware update) is a fine and useful thing - but this feature needs to be polish...
When activating, the (vertical)scales covering a part of the grid - and four digits after the comma displaying makes no sense also...
How it should be, see my pics taken from a lecroy scope.
Martin
-
Hi,
Axis-labeling (new firmware update) is a fine and useful thing - but this feature needs to be polish...
When activating, the (vertical)scales covering a part of the grid - and four digits after the comma displaying makes no sense also...
How it should be, see my pics taken from a lecroy scope.
Martin
What does Fine V/div look like on the LeCroy ?
-
Fine adjust I didn´t check(could do it tomorrow), but I´ve got a pic, when you´ve moved the "zero line"...
-
Hi,
Axis-labeling (new firmware update) is a fine and useful thing - but this feature needs to be polish...
When activating, the (vertical)scales covering a part of the grid - and four digits after the comma displaying makes no sense also...
How it should be, see my pics taken from a lecroy scope.
Martin
There are two possible styles here, writing inside and outside graticule. One writes on top (not nice sometimes) other write outside but makes usable graticule size smaller. Keysight writes on top like 2000X+ is now. LeCroy sacrifices some millimeters of screen to make nice looking graphs.
It's a compromise. I personally work with Keysight and got used to this way. It doesn't bother me anymore, as long as there are labels. They are super useful. I agree LeCroy looks nicer, but they have screen and resolution to spare..
I believe crazy precise, long numbers are known to Siglent and presume they will work it out.
-
I like the lecroy style more and could live with the screen spare... 8)
-
Fine adjust I didn´t check(could do it tomorrow), but I´ve got a pic, when you´ve moved the "zero line"...
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1270594)
OK just played with this on my SDS5000X and it seems there are a couple of modes when graticule values (Axis Labels) are ON.
Below in Moving mode with H-Pos, V-Pos and V-Fine engaged graticules move when H-Pos and/or V-Pos are adjusted to maintain the 0V and 0s positions and vertical scaling gets changed with Fine although the 0V position will not depart from its graticule.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1270924)
Should work exactly the same with SDS2000X Plus.
-
Should work exactly the same with SDS2000X Plus
Almost, besides the four trailing digits, which just clutter the screen.
-
Hi all you scope veterans, greetings from a digital scope newby,
not only based on all the comments in this forum I made a purchase decision some months ago and got me a 2104x (and missed the MSO bundle offer :palm:).
It turned out that one of the German Siglent box movers is right around the corner so I could pick it up the same day, anyway...
I'd like to know your opinion on this because I have no experience wether this is significant or neglectable:
YT user 'elektronik' showed this when he reviewed a 1204x-e I believe. Trigger on a sine wave and scale it out (800mVpp with 100mV/div). Now switch to fine scale and increase the vertical step by step until the waveform moves out of screen and take a single shot on each step. Now reduce the resolution and inspect the peaks. You will notice that up to a certain point the waveform (in my case 94mV/) is still captured without clipping. Does that mean the scope doesn't give full 8 bit resolution within the vertical graticules? Shouldn't the signal clip when it is moved right out of the last graticule? Is this normal DSO behaviour or Siglent special?
Some more comments/questions towards Siglent:
1) If I set bus encoding to ASCII, why are values up to 0x1f not shown in their short form (or at least hex, guess everybody can do a 'man ascii'), whats the point of displaying '[]'? Bonus question: Why can't the bus table show both ASCII and hex (or any other numerical encoded) values simultaneously?
2) Please cherry-pick the axis label code from the X5k series, printf("%4.04f") is seriously distracting.
Other than that, I appreciate your support and improving the scope and UI.
Joachim
-
Just froze my scope when misusing it as file system viewer (latest FW):
1) Stop scope (won't freeze when running, event loop not suspended?)
2) Insert USB drive and browse into USB drive via update
3) Wife calls, leave the file selector box open and wait until the screen saver kicks in: Et voila
Jo
-
Bugs in the FFT since the last firmware update:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3708991/#msg3708991 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg3708991/#msg3708991)
Plus the annoying axis-labeling thing with the useless 4 digit after the comma (will hide some screen information), and:
You couldn´t deactivate the axis labeling function in the FFT (maybe other math functions too)..
FFT, wanted feature when it´s not a bug:
Vertical scaling, variable or finer scaling should be possible in dB mode - actually it goes 5, 10, 20dB....
-
Hi all,
It's again really disappointing to see such new FFT bug and after one year waiting for a more "bug-free" and stable FW.
I'm wondering, if any testing is done at all ... in the previous FW we had e.g. the 1X / 10X bug which could be found quite easily, if someone at the Siglent test division would make some regression testing and using the simple switches systematically in their tests before each new alpha/beta release!?
I don't feel comfortable with this device anymore - before you like to measure an unknown signal or make an analysis, you have to read through this or other threads, checking if something popped up and may have an impact on what you like to measure.
Thanks to the competent community here, which is testing and reporting in a professional way - we know quite fast, what's behind the scene and FW release - many thanks for that!
I'm not blaming for the status of a FW shortly after the release of the new device, but things should improve, e.g. fixing errors before implementing new features...
How is your confidence level in this FW and scope today?
Regards
-
Hi,
This scope was launched in early 2020 - This is like "yesterday" happen, in comparison to a normal lifetime of a model.
I´m one of the very first owner, in this time it never hangs/freeze or something else, that could make it useless to work with.
Of course, there was, there is and there will be bugs in it - Nothing is perfect and for example, I´ve found several ones on our (company) 15000€ scope.
But you can work with it.
And surprise, you can "even" work with the siglent too, every day.
The known bugs are no showstoppers and yes, actually the FFT have a little bug and I´m sure, it wouldn´t take again a year from siglent to fix it.
before you like to measure an unknown signal or make an analysis, you have to read through this or other threads, checking if something popped up and may have an impact on what you like to measure.
Do you own this scope ? How often couldn´t you trust the measures from it because it could be a bug or the bug is in front of the scope?
-
To put things into perspective, here is the bug list of two manufacturers for two scopes that people seem trust implicitly without reserve.
Retail price for those 2 is easily 5x more..
I bold bugs directly pertaining to accuracy of data and basic functions of the scope...
Warning: lots of bugs, and serious ones... I hope people don't loose their trust... What do we do then? >:D
FIRST:
Bug Fixes
This software revision includes the following Bug fixes:
- Corrected the D3000BDLA ultimate bundle license to include the NFC trigger option.
- Changed the My Support Subscriptions table to show N/A for the Support Expiration and Status of legacy perpetual licenses, versus Expired.
- Changed the Installed Options section of the instrument web page to show N/A for the Support Expiration and Status of a legacy perpetual license, versus Expired.
- Networked printing via CUPS print server works correctly
Bug Fixes
This software revision includes the following Bug fixes:
- Corrected the NRZ serial decode from having an extra bit than the frame size when the Start-Bit is 0.
- Corrected “:MEASure:DELay:DEFine” for not accepting a definition that includes the “FALLing” edge parameter.
- Corrected the Reference Waveform data (.h5) from incorrectly saving data with twice the delay where is a delay on the displayed waveform.
- Corrected ":MEAS:SHOW?" always returning "1" regardless of the actual state.
- Fixed various LIN LDF file-parsing bugs.
- Fixed various issues related to the N7026A probe.
Bug Fixes
This software revision includes the following Bug fixes:
– An issue with handling CAN DBC signed integers has been corrected.
– Two channel measurements made with the N2820A probe are now functioning correctly.
Bug Fixes
This software revision includes the following Bug fixes:
– Digital channel skew has been corrected.
– Horizontal scale indicators at the bottom of the graticule now update appropriately regardless of the chosen time reference.
– An issue with calibrating an N275XA probe has been corrected.
– An issue with the MEAS:RES query ignoring the count parameter has been corrected.
Bug Fixes
This software revision includes the following Bug fixes:
– Fixed an issue where the user’s selected language was not remembered after the power was cycled.
– Fixed an issue where an attached mouse would not operate correctly after the power was cycled.
Bug Fixes
This software revision includes the following Bug fixes:
– Fixed an issue where in certain circumstances the Serial Lister would not properly display some UART data.
– Fixed an issue where in certain circumstances the Peak-Peak measurement was incorrect.
Bug Fixes
This software revision includes the following Bug fixes:
– Fixed incorrect DVM values in rare circumstances after toggling channel states.
– Fixed error messages when loading CAN FD .dbc files with data fields longer than 8 bytes.
– Fixed crash when saving H5 files with long path strings.
– Improved I2C decode reliability when SCL is acquired on a digital channel.
Bug Fixes
This software revision includes the following Bug fixes:
– Improved USB device mode stability when booting.
– Fixed various LIN symbol file (LDF) parsing errors.
– Fixed 50Ω probe calibration issue with the Power Analysis application.
– Improved performance when entering the IO menu.
– Fixed FFT vertical units when using a 50Ω current probe.
SECOND:
(not that this manufacturers dishonestly calls them "Improvements" not defects :--... At least first one is honestly admitting they are bugs (defects) and owns the obligation for fixing them. :-+
V01.600 Solved: Trigger level knob has no function after using zoom or QuickMeas in roll mode and turn back to normal time base mode.
V01.600 Solved: Wrong waveform data in zoom window when zoom is activated in roll initial mode and then the acquisition is stopped before the waveform window is complete.
V01.600 Solved: Sweep type 'Triangle' does not work correctly with RTM-B6.
V01.600 Solved: Wrong clipping math waveforms, depending on history of math and source setup.
V01.600 Solved: Sporadic incorrect data in math waveform.
V01.600 Solved: Wrong value in numeric input keypad after clear and new input that starts with '-'.
V01.600 Solved: Display of decode format bus 1 in ARINC 429 configuration window even when bus 2 to 4 is selected.
V01.600 Solved: No function of 'Find Threshold' button in ARINC 429 configuration window.
V01.600 Solved: A few instruments may irregularly show spikes in waveforms, depending on selected time base.
V01.600 Solved: In option RTM-K31 Switching Loss position cursors 3, 4 and 5 did not change measurement values.
V01.600 Solved: In rare cases, trigger jitter with positive trigger time and trigger point not in acquisition.
V01.600 Solved: Amplitude measurements with amplitude less than 7mV did not work.
V01.600 Solved: Wrong function of 'Wait on Trigger' Bit in status operation register after Break followed by Single.
V01.550 Solved: Overshoot calculated 0 % with more than one signal period.
V01.550 Solved: Sometimes Autoset sets wrong vertical scaling values with input frequencies lower than 500 Hz. It depends on control history.
V01.550 Solved: Wrong horizontal position zoom if zoom tool used when menu is open.
V01.501 Solved: Universal rotary knob did not work in Horizontal menu on Zoom Scale.
V01.501 Solved: Zero Adjust value in channel menu was lost with preset.
V01.501 Solved: Wrong waveform offset in XY diagram with measurement and statistic table
V01.400 Solved: Noise on signal of analog generator remains after function change.
V01.400 Solved: Firmware blocker after autoset in roll mode.
V01.400 Solved: Wrong waveform data display after stop in roll mode and QuickMeas.
V01.400 Solved: Setting ZA15 option for active probe RT-ZDxx did not work.
V01.400 Solved: Math function with inactive channels did not work.
V01.400 Solved: Wrong data display in XY mode and roll mode with high resolution active.
V01.400 Solved: Firmware blocker when waveform saving with 'Vis. Channels' or when saving bus table.
V01.400 Solved: Parallel bus displays more than one label in a large bus honeycomb.
V01.400 Solved: No possible waveform scaling after single in roll mode.
V01.400 Solved: Measurement delay did not work with reference as source.
V01.200 Solved: For active high-voltage differential probes RT-ZHD as well as power rail probe RTZPR the zero offset of the probes was not corrected automatically by the instrument.
V01.200 Solved: Probe attenuation was lost after preset with active probes.
V01.200 Solved: In XY mode channel unit A was not considered for grid annotation in diagrams directly.
-
Hi Martin,
I have to clarify my previous post - I'm disappointed about this ... FW release - expecting a little bit more w.r.t. tested functions and not to have such a glitch in the FFT, which could be found by automated test means, if this not only a display/visualization error!?
And don't misunderstand my point, it's not regarding new or improved functions and efforts spend by Siglent into this etc., but testing and releasing FW with such a visual error and similar to 1x/10x divider in the previous FW.
This scope was launched in early 2020 - This is like "yesterday" happen, in comparison to a normal lifetime of a model.
How long is the typical time to wait for a bug free product in this category?
I know the answer, just challenging ;)
I´m one of the very first owner, in this time it never hangs/freeze or something else, that could make it useless to work with.
Of course, there was, there is and there will be bugs in it - Nothing is perfect and for example, I´ve found several ones on our (company) 15000€ scope.
But you can work with it.
And surprise, you can "even" work with the siglent too, every day.
The known bugs are no showstoppers and yes, actually the FFT have a little bug and I´m sure, it wouldn´t take again a year from siglent to fix it.
Nothing to defend here ... I'm not saying that the SDS2000X+ is bad, useless or compare it with high(er) end equipments and their bugs.
Do you own this scope ? How often couldn´t you trust the measures from it because it could be a bug or the bug is in front of the scope?
Yes, I own this scope since 08/2020 and use it for hobby and educational purposes - no cutting edge things, but I want/like to trust the measurements ... by somehow.
And I totally agree, that most of the time, the problem is sitting in front of the device ;-)
My post was more related to FW testing before release (which is for me also related to confidence / trust) - and I don't want to compare this with other brands / models / prices, because I own this one.
Regards
-
To put things into perspective, here is the bug list of two manufacturers for two scopes that people seem trust implicitly without reserve.
Retail price for those 2 is easily 5x more..
I bold bugs directly pertaining to accuracy of data and basic functions of the scope...
Warning: lots of bugs, and serious ones... I hope people don't loose their trust... What do we do then? >:D
For completeness you also need to list the bugs that where introduced in new firmware versions (=functionality that worked before is now broken). As others pointed out: regression testing is extremely important to make sure fixing one bug doesn't introduce another one.
-
To put things into perspective, here is the bug list of two manufacturers for two scopes that people seem trust implicitly without reserve.
Retail price for those 2 is easily 5x more..
I bold bugs directly pertaining to accuracy of data and basic functions of the scope...
Warning: lots of bugs, and serious ones... I hope people don't loose their trust... What do we do then? >:D
For completeness you also need to list the bugs that where introduced in new firmware versions (=functionality that worked before is now broken). As others pointed out: regression testing is extremely important to make sure fixing one bug doesn't introduce another one.
I don't have to do anything.
Those two other manufacturers also didn't document what are new and what are old bugs..
They also had few regressions along the way.
I was replying to this sentence:
"
I don't feel comfortable with this device anymore - before you like to measure an unknown signal or make an analysis, you have to read through this or other threads, checking if something popped up and may have an impact on what you like to measure.
"
There are also some bugs Keysight decided not to fix, for instance... I reported one myself..
As I said, to put things in perspective...
Speaking off, Keysight 3000T has max 64K points FFT, and R&S RTM3000 has 128K FFT. RTM3000 does have very nice spectrogram option though. That cost as much as whole SDS2104X+ scope.
I mean, just to put things in perspective...
Keysight has "niggles", when Siglent or Rigol make mistake, nearby star will collapse..
You, know, to be fair and put things into perspective..
-
Hi 2N3055,
why do you start to bring other brands and their bugs into the discussion, and especially the point, that even more expensive gears have much worse bugs!?
I think this is the wrong perspective?
I mean, just to put things in perspective...
I don't care all the other brands and their problems, I made my decision for Siglent and the SDS2000X+ and like and appreciate new FW releases with bug fixing, but not introducing new once on existing/already working functions. So back to the point about testing and releasing ...
Keysight has "niggles", when Siglent or Rigol make mistake, nearby star will collapse..
You, know, to be fair and put things into perspective..
Why should a star collapse ... where is the unfair point here and in which perspective?
I was replying to this sentence:
"
I don't feel comfortable with this device anymore ...
Please, strike anymore and replace it with currently ... maybe with the next FW, everything is right, fingers crossed ;)
And I didn't noticed, that you were replying to my sentence before?
Regards
-
Software quality is not about not having any bugs. Every piece of complex software will have bugs. Quality is about how you deal with them, in terms of tracking, fixing, testing and communicating them. Test instruments are not just hardware, their worth nowadays is determined by mostly software. Some vendors have understood this. Others are still struggling. Siglent and Rigol are in the latter group. Just look at their release notes.
I think they will come to terms eventually. They must, if they want to have a fighting chance for the lucrative corporate accounts.
-
Software quality is not about not having any bugs. Every piece of complex software will have bugs. Quality is about how you deal with them, in terms of tracking, fixing, testing and communicating them. Test instruments are not just hardware, their worth nowadays is determined by mostly software. Some vendors have understood this. Others are still struggling. Siglent and Rigol are in the latter group. Just look at their release notes.
I think they will come to terms eventually. They must, if they want to have a fighting chance for the lucrative corporate accounts.
Agree.. It's just that, on average, they are not worse than big brands are nowadays... QED..
That is my point.
Legendary days of some big brands where devices were made pretty much perfect are long gone.
Both fact that today's devices are immensely more complicated, featured and sophisticated and still have to be sold at much lower prices that comparatively simple devices of the past contribute to this.
Even big brands, while still expensive, are charging much less than they used to, for devices that are harder to make.
And talking about Siglent, they are improving all the time..
-
Hi 2N3055,
why do you start to bring other brands and their bugs into the discussion, and especially the point, that even more expensive gears have much worse bugs!?
I think this is the wrong perspective?
I mean, just to put things in perspective...
I don't care all the other brands and their problems, I made my decision for Siglent and the SDS2000X+ and like and appreciate new FW releases with bug fixing, but not introducing new once on existing/already working functions. So back to the point about testing and releasing ...
Keysight has "niggles", when Siglent or Rigol make mistake, nearby star will collapse..
You, know, to be fair and put things into perspective..
Why should a star collapse ... where is the unfair point here and in which perspective?
I was replying to this sentence:
"
I don't feel comfortable with this device anymore ...
Please, strike anymore and replace it with currently ... maybe with the next FW, everything is right, fingers crossed ;)
And I didn't noticed, that you were replying to my sentence before?
Regards
To be clear, I'm not defending anybody's mistakes. Just pointing out that nobody should be measured by different metrics. Siglent should and will fix this.
They probably like it much less than you do. People like to be told they did a good job, not the vice versa..
"Putting things in perspective" is an English phrase meaning "to make sure that all things are viewed with same eyes" in this context.
R&S RTM3000 series, coming from very respectable manufacturer with very fancy pedigree, had much worse bugs during its first 3 years of existence and haven't had a firmware update in 18 months (a year and a half), despite having unresolved issues since release.. for instance "Sometimes no trigger when roll mode switched off. Workaround: Change vertical scale of trigger source"..
And nobody started making statements (like you did) that we should start doubting it's basic usability, despite it having real problems with very basic scope functions.
Cause it is R&S you know, they know how to make scopes.. Despite their very own documentation shows some worse bugs than cheap Siglent ever had.
-
A german "comedian" once played a fictional conversation between an engineer from siemens and him:
Do you know what we call it when we know that the product is not yet ready for the market, but still has to be delivered ?
No I don´t..
Banana version...
Banana version ?!
Yes, banana version - Matures at the customer.
;)
-
And nobody started making statements (like you did) that we should start doubting it's basic usability, despite it having real problems with very basic scope functions.
Cause it is R&S you know, they know how to make scopes.. Despite their very own documentation shows some worse bugs than cheap Siglent ever had.
IMHO you are over estimating R&S here. R&S is well known for their high end RF gear. However, oscilloscopes is something they started making later on. With the acquisition of Hameg they tried to tap into the lower end of the market. Where it comes to oscilloscopes R&S doesn't have the pedigree like Keysight, Lecroy, Tektronix and Yokogawa have. Regarding the relatively new R&S scopes (like the RTM3004) specifically I think they made the user interface way too complicated/fancy with all sorts of process synchronisation issues as a result. I have an RTM3004 on my bench and there are certain things about it that are dissapointing (see the review I wrote a couple of years ago). Still Thinkfat's remark about regression testing is a good one. It is very unlikely for an A-brand to introduce a bug in firmware which breaks previously working functionality.
-
And nobody started making statements (like you did) that we should start doubting it's basic usability, despite it having real problems with very basic scope functions.
Cause it is R&S you know, they know how to make scopes.. Despite their very own documentation shows some worse bugs than cheap Siglent ever had.
IMHO you are over estimating R&S here. R&S is well known for their high end RF gear. However, oscilloscopes is something they started making later on. With the acquisition of Hameg they tried to tap into the lower end of the market. Where it comes to oscilloscopes R&S doesn't have the pedigree like Keysight, Lecroy, Tektronix and Yokogawa have.
That makes no difference. A manufacturer's basic approach to software development and testing isn't going to change just because the kind of instrument is new or different.
The issues here arise from the development approach being taken, not the nature of the instrument.
And while R&S may not have the same pedigree with respect to oscilloscopes that the other manufacturers have, they're still regarded as an A-brand manufacturer because of their other instrument lines.
For this discussion, the "A brand" designation isn't given to product lines, but to manufacturers, because manufacturers decide how they do development, and product lines are merely the results of those development efforts.
Now, if you still want to go on and say that R&S is a "B-brand" manufacturer like Siglent, by all means, knock yourself out. >:D
It is very unlikely for an A-brand to introduce a bug in firmware which breaks previously working functionality.
That's how it should be. But whether that's how it actually is seems to be up for some debate.
-
Oh man, what to say about this ...
To be clear, I'm not defending anybody's mistakes. Just pointing out that nobody should be measured by different metrics. Siglent should and will fix this.
They probably like it much less than you do. People like to be told they did a good job, not the vice versa..
I didn't use metrics at all or compared it to anything else, just my expectation ... you should read my initial comment ... "disappointed" about this FW, and not due to "fixing bugs" :-+ but introducing a new one into a function, which had no issue before.
And this brings me to the point of testing and how this glitch could come through (after 1 year of ...)?
This is my personal perspective and I don't care about any other brand and their list of bugs (useless), because I own the Siglent one.
And nobody started making statements (like you did) that we should start doubting it's basic usability, despite it having real problems with very basic scope functions.
Cause it is R&S you know, they know how to make scopes.. Despite their very own documentation shows some worse bugs than cheap Siglent ever had.
Just my opinion, expressed by "I don't feel ..." and the FFT is nowadys a basic function, which I like to use without a fixed divider in my mind ;)
-
Oh man, what to say about this ...
To be clear, I'm not defending anybody's mistakes. Just pointing out that nobody should be measured by different metrics. Siglent should and will fix this.
They probably like it much less than you do. People like to be told they did a good job, not the vice versa..
I didn't use metrics at all or compared it to anything else, just my expectation ... you should read my initial comment ... "disappointed" about this FW, and not due to "fixing bugs" :-+ but introducing a new one into a function, which had no issue before.
And this brings me to the point of testing and how this glitch could come through (after 1 year of ...)?
This is my personal perspective and I don't care about any other brand and their list of bugs (useless), because I own the Siglent one.
And nobody started making statements (like you did) that we should start doubting it's basic usability, despite it having real problems with very basic scope functions.
Cause it is R&S you know, they know how to make scopes.. Despite their very own documentation shows some worse bugs than cheap Siglent ever had.
Just my opinion, expressed by "I don't feel ..." and the FFT is nowadys a basic function, which I like to use without a fixed divider in my mind ;)
Yes, this is Internet. You have right to express your opinions.
And so do I. Your post, to me sounds a bit drama queen type. That is my opinion. Hence my "put into perspective" comment.
Not what you talk about, but how. Blowing things out of proportion is nice dramatic tool, but won't fix the scope.
As for defects, they should be fixed. NO excuse for THAT.
And I'm sure they will. Nobody likes to be singled out for doing a bad job..
-
Hi,
A "summary" question to the beta-testers and siglent vendors:
The FFT "quirk" caused by the last firmware - is this a accepted bug and will be as soon as possible fixed ?
What about the 4 digits after the comma axis labeling ?
Last thing, is there any chance that the internal AWG will be polished in several things ?
Martin
-
It will probably be fixed. But the concept of "soon as possible" is a very relative concept. :(
-
Technically, those are bugs that are quite easy to fix. There's no random behavior, they're 100% reproducible and if their software is not a complete mess where unrelated changes cause bugs somewhere else (which I won't rule out, knowing how EE's typically develop software ;-), it is only a question of priorities.
-
In SW development it is like: the sum of bugs is a constant :-DD
IMHO, currently looks like they put all engineers on SNA5000 product.
Waiting Siglent fixes:
. SDG2k modulation issue, as latest response from Siglent Support, A FPGA limitation and may only one channel working using a special FW
. SDS2K issues on fast rising square waves
. SSA2k plus, jitter on synthesizer (1Hz and 200Hz Span to check, external OXCO do not help in this regard), BW on remote SW no 1Hz support
. SDM3065x display fixes, graph plot issue on restart as temp mode
so for a serious lab, may use for 40% for your low end measurements and for serious any xx..xxxK$ brands to consider :palm:
-
Just my opinion, expressed by "I don't feel ..." and the FFT is nowadys a basic function, which I like to use without a fixed divider in my mind ;)
You've created a big drama out of a small issue. The Siglent 5kX (a more expensive scope) originally had 3 digits resolution for frequency in its peak table that made it close to useless. They were pretty quick in fixing that. While it's annoying to have superfluous digits in the axes (especially at the vertical/dB scale) and it takes valuable space, it's still not the end of the world. The wrong peaks mean that memory depth has to be restricted, so there is workaround.
DSOs are complex SW based equipments nowadays and the hard fact with complex SW that it cannot be made bug free (no matter what vendor) and the developers have to prioritize. This issue, although seems a "low hanging fruit", is probably not the most serious one to jump on but let's hope that it will happen eventually.
Disclaimer: I have no affiliation with Siglent, bought some of their equipments, with some I'm more happy than with the others but in overall I think they do a good job in fixing issues (it's quite visible that for example the SDM product line they give less focus than other more expensive ones).
-
IMHO, currently looks like they put all engineers on SNA5000 product.
Looking at the price tags and guessing from that how much profit they are likely to make from various test equipments like DSO of this thread and from the more expensive T&M equipments it's very much unsurprising what is more in focus and what is less...
-
It will probably be fixed. But the concept of "soon as possible" is a very relative concept. :(
Of course, me I´m wating since three years for a bugfix for a lecroy wavesurfer..
We are not alone in this world, the sds2k+ is not the only device from siglent, there are many other things to do for them.
It would be nice if the new bug will be fixed soon, but it won´t be the world´s end if not. ;)
-
Hey,
I've skimmed over this thread, but didn't find anything related (sorry, if I missed it). Anyway, I've recently been moving stuff around in my lab, and I noticed that whenever I unplug my Siglent SDS2140X+ from mains power (while it's powered off of course) and then plug it back in after a while it will automatically turn itself on. I'm not sure, if this is a bug or not, but I would prefer that it stayed off until I manually power it back on by pressing the power button. Sometimes there's a thunderstorm, and I have a habit of unplugging my stuff prior. But when I re-apply power to the lab, the machine will turn on. We can also get power cuts here which means the machine will likely power itself on automatically, if that happens. Sometimes (i.e. in the winter during heavy snowfall) we can even get multiple cuts in a row and power is like on/off/on/off/on/off. I worry this will negatively affect my scope, if it keeps turning on and off like that.
Is there a setting I can change to prevent it from automatically powering on when the mains power is applied? I'm on firmware version 1.3.9R4.
EDIT: Thanks, Martin72.
-
A look at the manual, page 29:
Power on Line
When the “Power on Line” option is enabled, once the oscilloscope is
connected to the AC power supply through the power cord, the
oscilloscope boots automatically.
8)
-
I asked about this in the main thread, but didn't get any replies, so I assume this is not possible in the current firmware. Consider these as feature requests.
...
2. Would be nice to be able to display watts, and perhaps the formula editor could be the way to go. I can't see any way of using measurements in the editor however. Is it possible to enter something like this? RMS(C1) * RMS(C1) / 8
Ideally it would be a custom "measurement" since it doesn't need a trace, but I can't see a way of doing that.
Well, to quote myself again here, it seems #2 is sort of possible:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1293619;image)
Wish it was possible to base it on the RMS measurement instead, but better than nothing.
This is what it looks like:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1293625;image)
The Pk-Pk(F2) measurement is watts into 8 ohm.
Now for some feedback on the formula editor.
1. Bug - the formula editor is blank after booting the scope, which is quite annoying when you want to edit a long formula:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1293631;image)
The formula is remembered, as can be seen by the function shown in the menu, except it's not possible to edit it. It should be pre-filled in the editor when you open it.
2. Request - a way of storing and selecting favorite formulas. It gets old fast entering these formulas.
3. Request - support longer formulas. The one I used is almost max length. If I try to use the ERES function I only get the first character:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1293637;image)
There is obviously lots of room to write there, but it's not possible to enter any more characters.
4. Request - support hiding the math trace, like the channel traces can. The trace is in the way for my use case. I only need the measurement.
-
Good morning,
we have a new firmware available:
SDS2000X Plus Firmware-V1.3.9R6 (Release Date 10.24.21) (http://int.siglent.com/upload_file/zip/firmware/Oscilloscope/SDS2000X%20Plus_V1.3.9R6_EN.zip)
SMB1-only connectivity-flaw still unchanged.
'Asking myself, if this is really *that* hard to fix?
10/21/2021 1.3.9R6
1. Fixed several bugs
a) When selecting the option screen the scope hangs
b) Wrong FFT frequency when memory depth > 10 Mpts
c) Incorrect network storage path leads the scope to hang
++umgfoin
-
Hi,
SMB1-only connectivity-flaw still unchanged.
'Asking myself, if this is really *that* hard to fix?
This is a very quick "emergency" update, not a full one as you can see it on the few fixes in the list.
Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.
Martin
-
wow blurby fantastic,
I have been looking for a way to use the RMS read out value, for a little bit math, and make it watts into 8 ohms,
-
Hi Martin,
Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.
No, it isn't:
umount /usr/bin/siglent/usr/mass_storage/net_storage
mount -t cifs -o vers=3.0,username=foo,password=bar,rw,soft //HostIP/Share /usr/bin/siglent/usr/mass_storage/net_share
++umgfoin.
-
Hi Martin,
Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.
No, it isn't:
umount /usr/bin/siglent/usr/mass_storage/net_storage
mount -t cifs -o vers=3.0,username=foo,password=bar,rw,soft //HostIP/Share /usr/bin/siglent/usr/mass_storage/net_share
++umgfoin.
It is always easy to say other peoples job is easy....
Mapping is NOT being done from command line. It is being done from GUI, and with code.. So that has to be changed and checked. Which is a bit more involved than what you say.
Mind you, it is not huge job, but it is a job and a test and a...
They literally have better (as in more important) things to do.
FFT fix was important and done very quickly. Priorities...
Complexity of these machines is astonishing. No matter how many developers you put on it you will always have to have priorities.
Most important thing is that this scope is a part of platform that is going to be with us for some time. And will develop and be made better and better.
It takes time to do this. That is all.
Only 4-5 years ago, scope with these kind of capability for this price was unheard of.
My very expensive Keysight 3000T doesn't have any LAN mapping capability. It runs Windows CE, it would be trivial to add it... right...?
I would be happy if it would map any level of SMB, but it doesn't. And they don't care.
People asked Siglent for LAN mapping, and they did it... Not perfect, but hey, that can be fixed. But they listen, apparently.
Unlike others..
-
It is always easy to say other peoples job is easy....
Yep. How often have any of us said "how hard can it be?" when contemplating doing something, and then we actually go try it, and find that it's far more difficult than we originally anticipated?
I dare say that many of us have been through that.
It's something to always keep in mind when looking at something. You have to have a pretty deep understanding of how something works to be able to say with legitimate confidence that a change to it would be easy.
You'd think that the change here shouldn't be hard. And compared with some other things, it might not be. But remember that they have to do this right.
It turns out that I have direct experience with the problem seen here, in a product I maintain at work. To do this right, you have to attempt the mount using various option combinations until you succeed or until all of them fail. Worse, mount failures can occur for all sorts of reasons, which means that unless you want to try all of the option combinations one by one (which, if the issue is that the remote server is off the air, means the total time before you accept defeat could easily be longer than the user would normally tolerate), you have to examine the actual error returned, parse it (I don't see anything in the mount.cifs manpage that describes exit codes), and figure out what it implies.
So, yes, if all you're interested in doing is mounting a version 3.0 CIFS share, then that is straightforward. But what Siglent is really interested in doing here is mounting any CIFS share of any version, because they cannot know in advance what version of CIFS is in use on the target server.
Now, I don't know what version of the Linux kernel they're using here, but this is what the mount.cifs manpage says about the version argument:
The default since v4.13.5 is for the client and server to negotiate the highest possible version greater than or equal to 2.1. In kernels prior to v4.13, the default was 1.0. For kernels between v4.13 and v4.13.5 the default is 3.0.
So if the kernel version in use by Siglent is 4.13.5 or higher, then the failures seen here are likely due to something other than the version itself, and Siglent would have to explicitly specify 1.0 or 2.0 to attempt mounts against those versions. Conversely, if they're using something earlier then the protocol version used by default will depend on the kernel version they're using.
And that's just the version argument. There's also the question of what password hashing mechanism the mount attempt should use, something that also differs by target server. Now the number of option combinations you need to try has increased severalfold.
There may be additional options that could make the difference between success and failure, and each of those would increase the number of option combinations to try by at least twofold.
With all that, you can see why Siglent likely chose to use the defaults when attempting the mount (without knowing the specific command line arguments they're using, I can't say anything definitive).
Mapping is NOT being done from command line. It is being done from GUI, and with code.. So that has to be changed and checked. Which is a bit more involved than what you say.
Mind you, it is not huge job, but it is a job and a test and a...
They literally have better (as in more important) things to do.
Yep, exactly. Meanwhile, unless you're using this feature in a work setting, you might well be able to change the server settings to also support an SMB 1.x mount.
People asked Siglent for LAN mapping, and they did it... Not perfect, but hey, that can be fixed. But they listen, apparently.
Unlike others..
I wonder how long it'll be before nctnico changes his mind about Siglent ... >:D
-
Now, I don't know what version of the Linux kernel they're using here, but this is what the mount.cifs manpage says about the version argument:
The default since v4.13.5 is for the client and server to negotiate the highest possible version greater than or equal to 2.1. In kernels prior to v4.13, the default was 1.0. For kernels between v4.13 and v4.13.5 the default is 3.0.
/ # uname -a
Linux (none) 3.19.0-01-svn165603 #192 SMP PREEMPT Tue Aug 6 23:16:29 CST 2019 armv7l GNU/Linux
1.0 then :)
-
Hey guys,
I just received my SDS2104X Plus and am generally impressed with it (especially considering the price point). The only thing that immediately started to annoy me is the fan noise.
I saw the fan noise mentioned as something that could be improved (in this thread actually once), but I'm not sure whether my fan noise is even normal. I would highly appreciate if someone had a look at my short youtube video (https://www.youtube.com/watch?v=i2O9Q0FmYmc (https://www.youtube.com/watch?v=i2O9Q0FmYmc)) to compare it with your own unit. I can clearly hear a sound that I would describe almost more like a rattle than a hum. Otherwise the fan noise is totally acceptable imho. When playing the video on my laptop I kind of don't hear it as clearly as in real life, so please keep this in mind). If this sound is normal it is definitively something that should be addressed by Siglent and is hence somewhat a "bug" (by all means: increase the price by $5 and use a different fan ;) ).
If it wasn't for the warranty, I'd probably try to use some rubber to dampen the fan noise and possibly use a different fan altogether. But I'm not too keen on opening a still fairly expensive new piece of gear with warranty if I don't absolutely have to.
Thanks,
Sebastian
-
Yep, mine sounds like that, but I normally have a radio on, so don’t really notice it.
-
Hi Martin,
Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.
No, it isn't:
umount /usr/bin/siglent/usr/mass_storage/net_storage
mount -t cifs -o vers=3.0,username=foo,password=bar,rw,soft //HostIP/Share /usr/bin/siglent/usr/mass_storage/net_share
++umgfoin.
Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.
The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin ;)
Here is a short step by step procedure:
1) Copy the code below into a text editor and modify it to your needs and setup: IP-Address of the intended Win10 machine, the username and password (Windows) and the shared folder which should be mounted by the scope.
mount -t cifs -o vers=3.0,user=Winuser,password=Winpass,dir_mode=0777,file_mode=0777 //Win-IP/shared_folder /usr/bin/siglent/usr/mass_storage/net_storage
2) Save the file as siglent_device_startup.sh.
3) On the Windows computer, the intended shared folder should have full access rights for Everyone (Full control, Write, Read - permission).
4) Copy the prepared siglent_device_startup.sh on a USB stick, insert it into the scope and power it up or reboot.
5) After boot up, remove the USB stick and press [Print] on the front panel. You should see a white notice string/message that a file/picture was stored on the net_storage ...
6) You can also check the mounted network share via [Save/Recall] and using the builtin File Manager to check the mounted windows folder => new SIGLENT folder.
Credits to umgfoin and wgoeo!
Have fun,
Deichgraf
-
Hey guys,
I just received my SDS2104X Plus and am generally impressed with it (especially considering the price point). The only thing that immediately started to annoy me is the fan noise.
I saw the fan noise mentioned as something that could be improved (in this thread actually once), but I'm not sure whether my fan noise is even normal. I would highly appreciate if someone had a look at my short youtube video to compare it with your own unit. I can clearly hear a sound that I would describe almost more like a rattle than a hum.
That sound is very familiar. We had a discussion not long ago in the main thread:
One question - is the fan supposed to tick? I've read some complaints about noise, but mine ticks very fast, like a clock on speed.
It's nothing wrong with the fan it seems, they just chose one that ticks.
-
Good to know, thanks for the confirmation. I already know what will happen once the warranty is over (or -- more likely -- I don't care about the warranty anymore) :)
-
Bug report: when the scope is under significant load, it is largely unresponsive to the front panel controls, particularly the timebase and/or vertical sensitivity controls.
To reproduce this, feed a 1 MHz signal into the scope on one channel. Turn off all other channels. Configure acquisition for a 200M buffer, and the trigger for rising edge and normal mode. Set your timebase to 10 ms/div (so that the entire buffer is used -- these settings will result in a screen time coverage of 100ms). Then enable zoom mode.
Now play with the timebase and vertical sensitivity controls on the front panel. Notice how it will fail to recognize some of the movement of the controls when you move them even moderately quickly.
This is with the latest firmware (1.3.9R6), but seems to be the case with earlier firmware versions as well.
--
This shouldn't happen. It's clear from the mouse handling that the scope is perfectly capable of dealing with input events in a timely fashion. Movement of the mouse under the above conditions is smooth, so it's clear the scope is capable of recognizing a large number of input events in a relatively small amount of time. Handling of the front panel should be the same way. Now, I realize that some of the effects of the front panel may take some time to process and display, but events from the front panel should be buffered and those events merged together when possible. For instance, if I move the timebase knob 6 clicks counterclockwise, I expect to see the time per division increase by a factor of 100 no matter how heavily loaded the scope is, no matter how quickly I moved the knob, and no matter how quickly it's able to update the display: it should buffer the events and merge them into a single change, and then apply that change. This kind of predictability of the effects of knob movement is exactly why the timebase and vertical sensitivity knobs have detents in the first place! By ignoring events from the front panel, the scope eliminates the predictability that one otherwise expects.
Now, I'm not expecting Keysight-like responsiveness or anything (nice as that would be). Responsiveness is the speed with which changes become apparent on the screen. But I am expecting the scope to at least put every front panel input event into a queue for processing, and to merge the effects together when possible so that it can present as smooth an experience as possible (so if I quickly turn the timebase knob counterclockwise by 6 detents, it might go straight from where it is to a time per division that's 100 times larger, without showing the intervening steps, depending on how often it's able to update the screen). I don't know if the front panel generates interrupts when you use it, but if it doesn't then the scope should have a very high priority thread dedicated to reading the front panel and putting events from it into a queue. And if it does, then obviously the interrupt handler should be queuing the events. Save for when the scope is doing fast segment acquisition, which blocks all other operations, under no conditions should the scope miss events from the front panel.
-
Bug report: when the scope is under significant load, it is largely unresponsive to the front panel controls, particularly the timebase and/or vertical sensitivity controls.
To reproduce this, feed a 1 MHz signal into the scope on one channel. Turn off all other channels. Configure acquisition for a 200M buffer, and the trigger for rising edge and normal mode. Set your timebase to 10 ms/div (so that the entire buffer is used -- these settings will result in a screen time coverage of 100ms). Then enable zoom mode.
Now play with the timebase and vertical sensitivity controls on the front panel. Notice how it will fail to recognize some of the movement of the controls when you move them even moderately quickly.
This is with the latest firmware (1.3.9R6), but seems to be the case with earlier firmware versions as well.
--
This shouldn't happen. It's clear from the mouse handling that the scope is perfectly capable of dealing with input events in a timely fashion. Movement of the mouse under the above conditions is smooth, so it's clear the scope is capable of recognizing a large number of input events in a relatively small amount of time. Handling of the front panel should be the same way. Now, I realize that some of the effects of the front panel may take some time to process and display, but events from the front panel should be buffered and those events merged together when possible. For instance, if I move the timebase knob 6 clicks counterclockwise, I expect to see the time per division increase by a factor of 100 no matter how heavily loaded the scope is, no matter how quickly I moved the knob, and no matter how quickly it's able to update the display: it should buffer the events and merge them into a single change, and then apply that change. This kind of predictability of the effects of knob movement is exactly why the timebase and vertical sensitivity knobs have detents in the first place! By ignoring events from the front panel, the scope eliminates the predictability that one otherwise expects.
Now, I'm not expecting Keysight-like responsiveness or anything (nice as that would be). Responsiveness is the speed with which changes become apparent on the screen. But I am expecting the scope to at least put every front panel input event into a queue for processing, and to merge the effects together when possible so that it can present as smooth an experience as possible (so if I quickly turn the timebase knob counterclockwise by 6 detents, it might go straight from where it is to a time per division that's 100 times larger, without showing the intervening steps, depending on how often it's able to update the screen). I don't know if the front panel generates interrupts when you use it, but if it doesn't then the scope should have a very high priority thread dedicated to reading the front panel and putting events from it into a queue. And if it does, then obviously the interrupt handler should be queuing the events. Save for when the scope is doing fast segment acquisition, which blocks all other operations, under no conditions should the scope miss events from the front panel.
It's running linux and the top command is available in the compiled busybox ... so telnet'ing into the scope and checking the kernel / main.app usage is possible.
I checked it a week ago ... normal trace display (1 - 4) will show ~15% load, and with FFT enabled I could see ~63%
-
is there a general: SIGLENT Bugs / Missing Features / Feature Requests
thread ?
or at least one for their Power supplies ?
i spend quite along time searching this forum, but dont find it,
this thread is for the SCOPE SDS2000 only..
I got a few ideas for the SPD3303 and even for a brand new model, I would love to purchase from them, if available,
and i am sure many other users would feel the same way. it could be interesting to ask the users what they feel / need / wish for
-
Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.
The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin ;)
/SNIP
Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:
So, basically, it's sufficient to add ,vers=3.0 directly after username (or password) in the respective input controls...
++umgfoin.
-
Yep, exactly. Meanwhile, unless you're using this feature in a work setting, you might well be able to change the server settings to also support an SMB 1.x mount.
It is always easy to say other peoples job is easy....
Good afternoon gentlemen,
I didn't expect my comment to lead into a philosophical discussion. :-)
Sure your points of concern are legitmate as an engineer's general attitude.
In this specific case, I'm having sufficently deep insight:
The discussion SMB1 compatibility vs. security has been lead time ago and the reason why current implementations should refrain from using SMB1 are convincing (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2017-0143+CVE-2017-0144+CVE-2017-0145+CVE-2017-0146+CVE-2017-0147+CVE-2017-0148).
However, here it is not about disabling CIFS/SMB1-support, but enabling higher versioned dialects for those that support or rely on it (e.g. any recent (>=1803) std. WIN10 box uninstalls SMB1-support silently, if no SMB1 traffic is detected within 14d). NT LM 0.12 & POSIX2 aka CIFS will still be available in my shell-example shown above.
This instrument currently builds upon Linux kernel 3.19.0, thus it defaults to "negotiate up to SMB1.0"-behaviour unless you allow it to offer higher versioned dialects.
From a developer's point of view and under the given situation it is all about one single additional const char* option-flag, regardless of the implementation method chosen (Linux API, shell-call).
@2N3055: Linux Programmer's Manual: MOUNT(2). (https://man7.org/linux/man-pages/man2/mount.2.html)
This fact was the reason for my laconic comment.
Sure, you still won't satisfy all possible client/server combinations out there, but you cover the most common combinations at the time being.
Imho, it is not desirable to limit a contempory network-client to a deprecated protocol-revision.
I greatly honour Siglent's effort to add features after product-release, especially as the decision to add a SMB-client to a rolled out emb. device is something many manufacturers would consider to be possibly painful and thus refrain from doing it. I clearly prefer Siglent's approach.
Just my two cts.
++umgfoin.
-
Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.
The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin ;)
/SNIP
Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:
So, basically, it's sufficient to add ,vers=3.0 directly after username (or password) in the respective input controls...
++umgfoin.
Briliant!
-
Yep, exactly. Meanwhile, unless you're using this feature in a work setting, you might well be able to change the server settings to also support an SMB 1.x mount.
It is always easy to say other peoples job is easy....
Good afternoon gentlemen,
I didn't expect my comment to lead into a philosophical discussion. :-)
Sure your points of concern are legitmate as an engineer's general attitude.
In this specific case, I'm having sufficently deep insight:
The discussion SMB1 compatibility vs. security has been lead time ago and the reason why current implementations should refrain from using SMB1 are convincing (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2017-0143+CVE-2017-0144+CVE-2017-0145+CVE-2017-0146+CVE-2017-0147+CVE-2017-0148).
However, here it is not about disabling CIFS/SMB1-support, but enabling higher versioned dialects for those that support or rely on it (e.g. any recent (>=1803) std. WIN10 box uninstalls SMB1-support silently, if no SMB1 traffic is detected within 14d). NT LM 0.12 & POSIX2 aka CIFS will still be available in my shell-example shown above.
This instrument currently builds upon Linux kernel 3.19.0, thus it defaults to "negotiate up to SMB1.0"-behaviour unless you allow it to offer higher versioned dialects.
From a developer's point of view and under the given situation it is all about one single additional const char* option-flag, regardless of the implementation method chosen (Linux API, shell-call).
@2N3055: Linux Programmer's Manual: MOUNT(2). (https://man7.org/linux/man-pages/man2/mount.2.html)
This fact was the reason for my laconic comment.
Sure, you still won't satisfy all possible client/server combinations out there, but you cover the most common combinations at the time being.
Imho, it is not desirable to limit a contempory network-client to a deprecated protocol-revision.
I greatly honour Siglent's effort to add features after product-release, especially as the decision to add a SMB-client to a rolled out emb. device is something many manufacturers would consider to be possibly painful and thus refrain from doing it. I clearly prefer Siglent's approach.
Just my two cts.
++umgfoin.
I know how API works. That is not a problem, catching all the errors from all combinations and testing that is the actual work.
I do want to apologize for knee jerk reaction, I'm highly allergic to the "that is easy" statement (being the old fart that was on the receiving side one too many times >:(), so I might have been a bit more abrasive than i should have been. Sorry if I was. I do understand you act from a good place.
And I do not say it is not an issue and that it shouldn't be made better. It should. Siglent is making great effort to play in the big league and they should strive for the best.
But priorities exists for a reason, and this scope is not something that would (should) be facing hostile network so from risk triad calculated, risk is rather small. I do like that this is openly discussed. So users know not to do something naive..
AFAIK Siglent is aware..
And in meantime, your little trick works like charm..
-
is there a general: SIGLENT Bugs / Missing Features / Feature Requests
thread ?
or at least one for their Power supplies ?
i spend quite along time searching this forum, but dont find it,
this thread is for the SCOPE SDS2000 only..
I got a few ideas for the SPD3303 and even for a brand new model, I would love to purchase from them, if available,
and i am sure many other users would feel the same way. it could be interesting to ask the users what they feel / need / wish for
Yes:
https://www.eevblog.com/forum/testgear/siglent-technical-support-join-in-eevblog/ (https://www.eevblog.com/forum/testgear/siglent-technical-support-join-in-eevblog/)
Some of their product threads are listed in the OP however none for any of the 3ch PSU's of which there's been 3 series over the years. SDP3303X-E has been their most popular.
-
Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.
The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin ;)
/SNIP
Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:
So, basically, it's sufficient to add ,vers=3.0 directly after username (or password) in the respective input controls...
++umgfoin.
Hi umgfoin, (bavarian?)
thanks for sharing your research results on sniffing through the main.app and the nice outcome / side effect ;)
So they put the dialog input directly into a (shell) system call with mount but without any encapsulation / quotes on these strings!?
meanwhile ... copying main.app for inspection :o
-
Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.
The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin ;)
/SNIP
Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:
So, basically, it's sufficient to add ,vers=3.0 directly after username (or password) in the respective input controls...
++umgfoin.
Hi umgfoin, (bavarian?)
thanks for sharing your research results on sniffing through the main.app and the nice outcome / side effect ;)
So they put the dialog input directly into a (shell) system call with mount but without any encapsulation / quotes on these strings!?
meanwhile ... copying main.app for inspection :o
No they did not "put the dialog input directly into a (shell) system call ".. That is Linux filesystem API, same one that shell calls... But it accepts pretty much same mount flags as you would pass as a options on a command line when calling mount from the shell.
-
Bug report: when the scope is under significant load, it is largely unresponsive to the front panel controls, particularly the timebase and/or vertical sensitivity controls.
To reproduce this, feed a 1 MHz signal into the scope on one channel. Turn off all other channels. Configure acquisition for a 200M buffer, and the trigger for rising edge and normal mode. Set your timebase to 10 ms/div (so that the entire buffer is used -- these settings will result in a screen time coverage of 100ms). Then enable zoom mode.
Now play with the timebase and vertical sensitivity controls on the front panel. Notice how it will fail to recognize some of the movement of the controls when you move them even moderately quickly.
This is with the latest firmware (1.3.9R6), but seems to be the case with earlier firmware versions as well.
Hi kcbrown,
I checked the "CPU load" with your input/test setup, but this seems to be not a problem of CPU load ...
But the response on the controls is somehow linked to the screen update/buffer acquisition rate.
I have the impression, that the event input buffer is limited to the first or last event in the queue in this "slow" acquisition scenario or in general to avoid "unwanted overshot" w.r.t. changing the scope settings!?
We can see much more "CPU load" for active FFT and/or Measuring tasks ... see attached pictures.
-
Hi kcbrown,
I checked the "CPU load" with your input/test setup, but this seems to be not a problem of CPU load ...
I didn't expect it would be. CPUs are generally really fast, and human perception is glacial in comparison. Your CPU could be 99.99% loaded and you'd never notice it in the UI. Try running something that burns 100% CPU on all of the cores on your computer and you'll see what I mean: the computer remains perfectly responsive.
The "load" I had in mind was more with respect to resource contention (such as access to a memory buffer that's continuously being written to and which requires locking to prevent race conditions). That is something that will slow down a UI.
But the response on the controls is somehow linked to the screen update/buffer acquisition rate.
I have the impression, that the event input buffer is limited to the first or last event in the queue in this "slow" acquisition scenario or in general to avoid "unwanted overshot" w.r.t. changing the scope settings!?
That seems like a reasonable assessment. It should be noted that even with a faster update rate, the scope still misses events from the front panel from time to time (certainly more often than it should -- it shouldn't miss any).
We can see much more "CPU load" for active FFT and/or Measuring tasks ... see attached pictures.
Yeah, that's not a surprise. I think you'll find that the CPU load can be high while the responsiveness to the front panel remains somewhat better than under the conditions I outlined.
Frankly, if you're playing with the controls like this, the scope should, if acquisition is what's interfering with UI responsiveness, stop acquisition immediately, and restart it a short period of time after the user stops moving the controls. This is so because if you're playing with the timebase, vertical sensitivity, etc., the scope is going to throw away the current acquisition anyway, and will keep doing so until you stop moving the controls. Meanwhile, with acquisition stopped, the scope can direct all of its attention to the controls and the display updates that result from their manipulation, and the end result will be a UI that is ultra-responsive. But again, it should do so only if acquisition is interfering with UI responsiveness in the first place, something that I think may be true only to a limited degree.
How do I know? Well, try setting up the scope as described, let it do its acquisition, and then stop the scope. Then play with the controls. You'll find that the responsiveness isn't much better than it was with the scope running. But obviously it should be far better, because there's nothing that the scope is doing at that point except interacting with the user.
-
Good afternoon gentlemen,
I didn't expect my comment to lead into a philosophical discussion. :-)
Sure your points of concern are legitmate as an engineer's general attitude.
In this specific case, I'm having sufficently deep insight:
The discussion SMB1 compatibility vs. security has been lead time ago and the reason why current implementations should refrain from using SMB1 are convincing (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2017-0143+CVE-2017-0144+CVE-2017-0145+CVE-2017-0146+CVE-2017-0147+CVE-2017-0148).
However, here it is not about disabling CIFS/SMB1-support, but enabling higher versioned dialects for those that support or rely on it (e.g. any recent (>=1803) std. WIN10 box uninstalls SMB1-support silently, if no SMB1 traffic is detected within 14d). NT LM 0.12 & POSIX2 aka CIFS will still be available in my shell-example shown above.
This instrument currently builds upon Linux kernel 3.19.0, thus it defaults to "negotiate up to SMB1.0"-behaviour unless you allow it to offer higher versioned dialects.
From a developer's point of view and under the given situation it is all about one single additional const char* option-flag, regardless of the implementation method chosen (Linux API, shell-call).
@2N3055: Linux Programmer's Manual: MOUNT(2). (https://man7.org/linux/man-pages/man2/mount.2.html)
This fact was the reason for my laconic comment.
Sure, you still won't satisfy all possible client/server combinations out there, but you cover the most common combinations at the time being.
Imho, it is not desirable to limit a contempory network-client to a deprecated protocol-revision.
I greatly honour Siglent's effort to add features after product-release, especially as the decision to add a SMB-client to a rolled out emb. device is something many manufacturers would consider to be possibly painful and thus refrain from doing it. I clearly prefer Siglent's approach.
Just my two cts.
++umgfoin.
Hello,
As probably many others, I would like also to try using network folder with the oscilloscope.
Anyway, I must admit that network configuration is obscure for me and despite some effort
I don't have been able to do it working. :-\
Note that the scope is not directly connected to the network, but it use a LAN cable between it and a win10 computer.
This computer is itself connected to the network using WiFi.
With such configuratuin and as I understand, This is my computer that need to host the SMB server, to allow to be seen by the scope to create a
network folder where the scope will write data.
Does anybody could explain how to proceed step by step ?
Thank in advance.
Regards.
Frex
-
Hi Frex,
the Ethernet cable between the scope and the Win10 computer is a good starting point ... a connection to the (internet) router/gateway (network as you wrote?), is not necessary for the scope.
To enable the communication between scope and computer, both have to be in the same logical (sub-)network in your lan ... same IP-Address range.
Example: Win10-IP: 192.168.1.x / Scope-IP: 192.168.1.y with x, y in (1..255) and x !=y
So power-up your scope and the Win10 computer and let's check your IP-configuration on the Win10 machine:
1) Open a command shell (cmd) and enter: ipconfig
2) As a result, you will get a list of the installed network interfaces and their IP configuration
3) Depending on this list and the configuration of the interfaces, we can proceed with the next step(s) ...
Regards
-
Hello Deichgraf,
Thanks for your quick answer.
(Just note that I already have configured the network on the scope to be able to have access to it with web browser).
I have used the ipconfig command with success.
The computer IP of Ethernet link is 169.254.xxx.xxx // 255.255.0.0
The scope IP use same 169.254.xxx.xxx range.
Then, the Wifi network interface (USB dongle) use IP that use 192.168.x.xx // 255.255.255.0 address.
It is as expected ?
Thank you.
Frex
-
Good evening Frex,
this looks quite good ... I was not sure whether you had IPV4 or IPV6 on your computer enabled.
So final steps - make sure that you note the scope and computer IP's, e.g. 169.254.1.1 (Win10) and 169.254.1.2 (Scope).
1) With the explorer create a folder at a convienent place ... but for simplicity in this test chose e.g.: C:\Temp\Frex
2) Open properties of folder Frex and select Share-Tab -> Extended shares -> select check box Share this folder and
3) Click on permissions -> give all permissions to Everyone (Full control, write, read) access
4) Apply all dialogs with ok
Now this folder should be writeable from the scope point of view!
5) On your scope, click Utility -> System settings -> I/O -> Net Storage
6) In this dialog, you enter your Win10 computer IP and Frex shared folder, your Win10 username and password
-> see attachment example and the special hack (thx to umgfoin) with ,vers=3.0 after the username!!!
7) Click connect ... now the scope should have mounted your Win10 shared folder
=> press Print on the scope and the file should be stored over the network on your Win10 computer/Frex folder.
Have fun,
Deichgraf
-
Hello Deichgraf,
Thank you very much for your write up.
It was very clear and it work now.
Your help was much appreciated !
Best regards and thank again.
:-+
Frex
-
Bug report:
As I noted before, there are certain conditions under which the scope will improperly clear the history buffer. Siglent has addressed at least some of that, so kudos to them for it.
At least one specific condition remains, and really shouldn't: single-shot capture mode.
Right now, if you use that, it clears the history buffer. But it obviously should do so only if the capture settings have changed. If they remain the same then there is no harm at all in adding the new capture to the history, thus making it possible to review multiple sequential single-shot captures via the history.
I regard this as a bug because I can see no good reason whatsoever for clearing the history buffer just because you're capturing a single manually-triggered event rather than an automatic sequence of triggered events.
-
Just bought a nice micsig DP20003 probe for motor switch snubber design.
It's 200x and 2000x.
NP to edit the Probe setting. The V/div display works fine too.
BUT: There is only a strange line for the damping probe attenuation factor in the channel descriptor box instead of "200x" or "2000x". Testwise it's the same e.g. for "99x".
Same on device screen and remote instrument control on PC.
-
Just bought a nice micsig DP20003 probe for motor switch snubber design.
It's 200x and 2000x.
NP to edit the Probe setting. The V/div display works fine too.
BUT: There is only a strange line for the damping factor in the channel descriptor box instead of "200x" or "2000x". Testwise it's the same e.g. for "99x".
Same on device screen and remote instrument control on PC.
That is not attenuation factor ("damping" as you say).. That is actual V/div scale for the channel. When you change vertical it should change to current efective V/div including probe atten factor.
-
That is not attenuation factor ("damping" as you say)..
OK. What's meant schould be clear from the picture.
As for the wording I checked with the Siglent User manual and changed "damping factor" into "probe attenuation factor" in my post above. That's the wording Siglent is using. And that's what I do mean.
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
That is actual V/div scale for the channel. When you change vertical it should change to current efective V/div including probe atten factor.
As I wrote: V/div display is fine.
-
That is not attenuation factor ("damping" as you say)..
OK. What's meant schould be clear from the picture.
As for the wording I checked with the Siglent User manual and changed "damping factor" into "probe attenuation factor" in my post above. That's the wording Siglent is using. And that's what I do mean.
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
That is actual V/div scale for the channel. When you change vertical it should change to current efective V/div including probe atten factor.
As I wrote: V/div display is fine.
Down in channel box there is never going to be probe factor. It makes no sense. It is V/div.. except t"div" part is not spelled explicitly...
So "20V/" means 20V per division in this case. It is quite logical to me and never even noticed it as a problem.
R&S uses same nomenclature for their scopes, so does Keysight. It is industry standard, really..
Also in probe setup, Siglent correctly specifies it as 100:1 instead 100x probe that is quite common but wrong, as a 100x probe is a probe with amplification of 100x.
-
It is the probe factor in that part of the field
But I think it has been to confusing to display all kind of values when use custom value.
There for that symbols simply indicates "Custom probe value"
That is my interpretation
-
It is the probe factor in that part of the field
But I think it has been to confusing to display all kind of values when use custom value.
There for that symbols simply indicates "Custom probe value"
That is my interpretation
Oh thank you, I didn't understand , the small probe icon instead of attn factor..
Yes, that is "custom probe" symbol. It is deliberate , because if you take into account all combinations (including current conversions) it gets too involved really quick.
-
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.
SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
-
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.
SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
Thx for claryfying. That explaines the symbol. :-+
Would be great to have the value of the user attenuation in that field. :)
I understand, that it might be some work in case Siglent is mapping static bitmaps for the predefined values now.
-
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.
SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
Thx for claryfying. That explaines the symbol. :-+
Would be great to have the value of the user attenuation in that field. :)
I understand, that in might be some work in case Siglent is mapping static bitmaps for the predefined values now.
Certainly there's potential to add a # more predefined attenuations like as there is in X-E models however the practical need for more than the 3 currently available is debatable. Once set and the vertical units/div are correct for whatever probe is used we already have enough visible channel tab info for documentation and correct use.
But bounce this around owners here and if good support comes for a common solution you can be sure the beta testers here will take it to Siglent to consider.
-
To make it clear again: In the attached screenshot from the scope, I'd expect "2000X" in the channel descriptor box for the probe attenuation factor instead of the strange dash.
The strange dash represents a sideways pen/pencil/probe signifying a user input attenuation is applied.
SDS2kX+ and 5kX models display this whenever a user attenuation has been set.
Thx for claryfying. That explaines the symbol. :-+
Would be great to have the value of the user attenuation in that field. :)
I understand, that it might be some work in case Siglent is mapping static bitmaps for the predefined values now.
There is no place there to show all the combinations. For instance you would need to show 1234,5A/1mv for a current probe. And that would make no sense because you are looking at current values on a screen and don't care for voltage at all at that moment.
And as I said, ultimately it is not necessary. Who cares. This whole probe definition business is there to properly scale V/div A/div settings so measurements, graticule and all notations show proper value. After you set the probe you don't care what it is..
Theoretically it wouldn't hurt, but meh, who cares..
-
When returning to the desk from lunch etc. I like to check the settings, e.g. if the probe attenuation factor is still matching the switch position at the differential amp or switchable probe to ensure the diplayed V/div setting is correct. Would be nice to have it on screen at first glance without having to enter the menu. The scope shows values of 1X, 10X and 100X already. I can see no disadvantage of showing a user value in that place too.
I think I made my point.
-
When returning to the desk from lunch etc. I like to check the settings, e.g. if the probe attenuation factor is still matching the switch position at the differential amp or switchable probe to ensure the diplayed V/div setting is correct. Would be nice to have it on screen at first glance without having to enter the menu. The scope shows values of 1X, 10X and 100X already. I can see no disadvantage of showing a user value in that place too.
I think I made my point.
You have and there's certainly room in the probe attenuation menu for many more preset values to be available especially if the scroll bar is added like in some other menus.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1370405)
Certainly 1000x should be added along with common differential probe values like 50x, 200x and 500x....in fact if real user convenience was properly considered a list matching the X-E range should be added.
Some might complain the commonly used values will be lost in the list yet probes with autosense capability which are more commonly used by professionals will set themselves up automatically without even need to select them from a list.
The User menu should be also moved to the top so it's always visible.
-
Maybe it's a good compromise to leave the menu short as is. And just write the user value in the channel descriptor box instead of the probe symbol.
Anyhow - and here 2n3055 is right - it's a matter of convinience only. And in case developer's time is needed to fix real malfunction, that should be priority of course.
-
> Some might complain the commonly used values will be lost in the list
Those common values could be listed above the others...on the other hand, there are more urgent issues (like all those unnecessary decimal places) that I think many would agree should take priority.
-
Hi,
Wanted Feature for the for the Platform (2k+/2k hd/5k/6k) :
Like bigger lecroy scopes, we got free chooseable channel colours - very good.
But like the lecroy got, it would be a nice to have if you can also choose different colours for printing.
Example, on screen colour for ch1 is red, ch1 printed is green and so on.
This possibility got it´s advantage when printing with white background.
Martin
-
I have been encountering problems with the SDS when using its serial decode function. These problems were discussed (and partly confirmed by others) in another thread (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/3125/) on this forum. In short:
1. The SDS does not show any error messages in its telegram or bus display when LIN protocol errors occur. This makes it very hard to see whether the shown decoded data are in fact correct or not. Unlike other scopes, there is no row in the bus display view for showing such errors either (labelled "Errors" or "State" in other scopes).
2. In several cases, the SDS indeed shows entirely wrong decoded data (wrong ID’s, wrong message length, wrong payloads) without showing errors. - Such situations showing entirely wrong data can be reproduced by taking a ‘good’ LIN signal and reversing its polarity (in using 'invert' the channel settings). (see screenshots below). This has been confirmed by other users.
- Completely wrong decoded data is sometimes also shown when the polarity of the LIN signal is correct and everything otherwise seems correct (see screenshot SDS.png). Yet these situations are harder to reproduce. You don’t know in advance.
3. Using the SDS serial trigger function for errors, one can indeed observe that the scope itself is aware of all these errors it is not showing in telegram or bus display.
- But this is a very cumbersome procedure, as for each decode you have to set up an entire error trigger procedure.
- Also, when wrongly decoded messages are shown, the serial trigger function do not completely behave as expected (IDs shown on the screen are not found by the serial trigger) – probably because the messages are incorrect in the first place.
- Moreover, to trigger on LIN checksum errors, one must first know and enter the message ID and the precise content of the first two bytes of the payload. This makes it virtually impossible to carry out this serial trigger check in a full way.
As a result, it is hard to know whether the SDS is decoding properly unless you have another oscilloscope(s) next to it decoding the same signal.
Edited: On the basis of a quick check, the above problem (1) seems to extend to CAN, I2C, UART (partially) and possible other decoders as well (have not checked all). Problem 2 may or may not exist in other protocols, have not tested that (yet).
Edit: the above observations relate to FW 1.3.9R6, which is the most recent one as of 1 February 2022.
Screenprints in attachment:
. RTB_wrong_polarity_LIN.PNG
SDOX_wrong_polarity_LIN.png
SDS_wrong_polarity_LIN.png
-> These three pictures show how other scopes show error messages and the SDS does not, all displaying the same data where a LIN signal is given the wrong polarity (so idle is low whereas it should be high)
. PicoScope.png
RTB.PNG
DSOX.png
SDS.png
-> Here, four scopes are offered the same, valid LIN signal. Three display it properly, the SDS everywhere shows wrong message IDs, wrong message lengths and wrong payloads – yet does not show any error.
-
1. The SDS does not show any error messages in its telegram or bus display when LIN protocol errors occur. This makes it very hard to see whether the shown decoded data are in fact correct or not. Unlike other scopes, there is no row in the bus display view for showing such errors either (labelled "Errors" or "State" in other scopes).
2. In several cases, the SDS indeed shows entirely wrong decoded data (wrong ID’s, wrong message length, wrong payloads) without showing errors.
Such situations showing entirely wrong data can be reproduced by taking a ‘good’ LIN signal and reversing its polarity (in using 'invert' the channel settings). (see screenshots below). This has been confirmed by other users.
Completely wrong decoded data is sometimes also shown when the polarity of the LIN signal is correct and everything otherwise seems correct (see screenshot SDS.png). Yet these situations are harder to reproduce. You don’t know in advance.
3. Using the SDS serial trigger function for errors, one can indeed observe that the scope itself is aware of all these errors it is not showing in telegram or bus display.
But this is a very cumbersome procedure, as for each decode you have to set up an entire error trigger procedure.
Also, when wrongly decoded messages are shown, the serial trigger function do not completely behave as expected (IDs shown on the screen are not found by the serial trigger) – probably because the messages are incorrect in the first place.
Moreover, to trigger on LIN checksum errors, one must first know and enter the message ID and the precise content of the first two bytes of the payload. This makes it virtually impossible to carry out this serial trigger check in a full way.
As a result, it is hard to know whether the SDS is decoding properly unless you have another oscilloscope(s) next to it decoding the same signal.
The above problem extends to CAN decode as well. It may extend to other serial protocol decodes as well but I have not tested this (but also there, I see no specific row in the table for errors or status so I suspect it does extend there too).
Hi RBBVNL9,
thanks for reporting and your effort to trace it down!
I'm wondering if, beside LIN and CAN error detection and decoding issues, the 1553B is also affected?
Can someone check this?
Regards
-
thanks for reporting and your effort to trace it down!
I'm wondering if, beside LIN and CAN error detection and decoding issues, the 1553B is also affected?
Can someone check this?
You're welcome! In the end this took way more time and energy than I was expecting to spend in it :-|
Whether the MIL-STD-1553B decoder is affected as well I don't know. I would need a 1553B coded signal with known errors in there to check, and preferably a couple of other devices that can decode this standard as comparison points.
However, in contrast with most other protocol decoders in the SDS, the 1553 protocol bus display has a column called "Error". It's all the way on the right. This suggests that for this protocol, errors are indeed shown. But someone would need to test to be sure.
-
If I would take my scope at work, I could decode 1553 - But causing an error on the bus...Must talk to our software guy. ;)
Couldn´t do that immediately, so have patience everyone.
-
If I would take my scope at work, I could decode 1553 - But causing an error on the bus...Must talk to our software guy. ;)
Couldn´t do that immediately, so have patience everyone.
Just a thought: perhaps mix a good 1553 signal with some infrequent, disturbing pulses coming from a function generator? I guess this would at least lead to some forms or decode error (and see whether that get displayed in telegram or bus display), and check that error also via serial trigger (where I see eight error categories the SDS distinguishes). This approach could lead to some testing, but obviously not to all types of errors being tested.
But it would save you having to ask software engineers to write code for you!
-
How about recording a piece of 1553 data with a scope, edit the waveform to add errors and transfer it to an AWG? Or skip the recording part and create a waveform using a script and load that into an AWG. You can create all kinds of errors and bit time variations that way.
-
How about recording a piece of 1553 data with a scope, edit the waveform to add errors and transfer it to an AWG? Or skip the recording part and create a waveform using a script and load that into an AWG. You can create all kinds of errors and bit time variations that way.
A similar thought crossed my mind. Also to be able to send the captured waveform to others so they can test it on their devices. Perhaps capture it and save from the SDS itself, so it can be easily played from the SDS AWG.
If I have time I might try something like this...
The limitations here is that this is only (in a simple way) possible with 1-wire protocols. With protocols requiring more than one pin, a single channel AWG is not sufficient. I assume it should be possible to play such multi-pin waves from the RTB though, as it has a 4-pin pattern generator, which allows ARB patterns, and this hardware is in fact used by the RTB to make its own UART, I2C, SPI, CAN and LIN training/demo sequences. Of course, it needs to fit in the specific specifications of that pattern generator (timing speeds, etc.) So, if anyone cares to make such patterns for MIL-STD-1553B, FlexRay, CAN FD, SENT, or Manchester, with or without deliberately inserted errors, do share them in the community!
-
How about recording a piece of 1553 data with a scope, edit the waveform to add errors and transfer it to an AWG? Or skip the recording part and create a waveform using a script and load that into an AWG. You can create all kinds of errors and bit time variations that way.
The 1553 standard allows the BC (Bus Controller) to inject certain type of errors for test & sw-evaluation purpose. So, if the bus is "driven" by some BC-Simulation HW/SW (e.g. CoPilot or similar), then this would be a very quick task by defining 1553 messages with error injection (manchster coding, crc ...) stuff.
-
Missing feature: lack of high/low/bandpass filter in math section (or in any other place). Today I needed this feature, and ended up playing with 1054z... Or I couldn't find it.
-
You can search as long as you could, you won´t find it... ;)
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.
You may ask why siglent doesn´t implement it so far, while "even" a rigol ds1054z got it.
I had the bigger, stronger, faster model mso5000 and of course it got the filters, but they don´t work proper as expected.
And this may be the point and this is what I like on siglent:
If you can´t be sure that it works as it should, don´t do it.
Maybe they find a way to implement it with proper function someday.
But I don´t think that is a high priority point for siglent, even the sds6000a doesn´t got it.
-
Small question for the SDS experts :)
These instruments allow the user to set the horizontal reference strategy (Utility > Menu > Reference position). It is described in the manual on page 337.
- You can choose between a "Fixed Delay' (simply called 'Delay' on the screen of the device). Then the reference point is simply in the middle of the screen, and when the horizontal timebase scale is changed, the waveform expands/contracts around the center of the display.
- Then there is "Fixed Position" (simply called 'Position' on the screen of the device). Here the user can select a reference position from 0% (outer left of the screen) to 100% (outer right of the screen). Then the waveform expands/contract from that chosen position.
This is a welcome function indeed.
Now the question... In the current FW 1.3.9R6, when ‘position’ is selected (i.e., the button turns blue), the position entry field disappears, and if you select “delay”, the horizontal entry field re-appears.
Could it be that the labels on these two buttons are accidentally switched in the user interface?
(Also, I find the terminology position vs. delay used kind of confusing. It would be more intuitive calling this "Centre Position" and "Adjustable" Position", or simply a single parameter that is default at 50% and can be changed. Just my two cents.)
-
You can search as long as you could, you won´t find it... ;)
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.
Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.
-
Small question for the SDS experts :)
These instruments allow the user to set the horizontal reference strategy (Utility > Menu > Reference position). It is described in the manual on page 337.
- You can choose between a "Fixed Delay' (simply called 'Delay' on the screen of the device). Then the reference point is simply in the middle of the screen, and when the horizontal timebase scale is changed, the waveform expands/contracts around the center of the display.
- Then there is "Fixed Position" (simply called 'Position' on the screen of the device). Here the user can select a reference position from 0% (outer left of the screen) to 100% (outer right of the screen). Then the waveform expands/contract from that chosen position.
This is a welcome function indeed.
Now the question... In the current FW 1.3.9R6, when ‘position’ is selected (i.e., the button turns blue), the position entry field disappears, and if you select “delay”, the horizontal entry field re-appears.
Could it be that the labels on these two buttons are accidentally switched in the user interface?
(Also, I find the terminology position vs. delay used kind of confusing. It would be more intuitive calling this "Centre Position" and "Adjustable" Position", or simply a single parameter that is default at 50% and can be changed. Just my two cents.)
This setting alters the function of the horizontal position knob, and everything is labelled correctly.
If we use the “fixed delay” strategy, then the trigger delay with respect to the reference position is set by the horizontal position knob. The reference position on the other hand can be set to anything between 0 and 100 % of the display width in the Horizontal Ref. Pos. field, where 50 % is the default value.
It means that the delay remains constant and because of this, the trigger position changes with timebase and can get shifted far outside the visible screen quite easily. That’s fine if you want to observe a certain region of the waveform that has a certain delay with respect to the trigger point – this is the reference position, that remains constant, regardless of the timebase.
For example, if you have a trigger delay set to 1 µs and the reference position to 20 % in constant delay mode, the trigger point will be at 10 % of the screen width at 1 µs/div and you get the part of the waveform at the reference position at 20 %, that is exactly 1 µs after the trigger event. Now if you change the timebase to e.g. 100 ns/div, the trigger point is far outside the visible screen area, but you still see a zoomed version of that 1 µs delayed part of the waveform at the reference position, which you had set to 20 % of the screen width.
If we use the “fixed position” strategy, then the trigger position is always equal to the reference position and both can be adjusted simultaneously using the horizontal position knob. The only problem is the hollow triangle that remains at 50 % of the screen width, suggesting there is anything of importance there – actually, there is not.
It means that the reference = trigger position remains constant with various timebase settings. That’s fine if you want to observe the trigger point in a waveform regardless of the timebase setting.
For example, if you set the horizontal position to 20 % in constant position mode, the trigger point will be at 20 % of the screen width at any timebase setting.
You can ask yourself why we need the two different modes – after all, “constant delay” already does everything we need. Well, trigger delay is a concept dating back to the times where memoryless storage scopes (from Tek) were a thing and we needed a set of crouches to overcome the limitations going with it. Nowadays, with deep memory and well implemented zoom modes, trigger delay is not nearly as important as it used to be, so we might prefer just setting the trigger position with the position knob quickly, instead of digging into a menu.
-
You can search as long as you could, you won´t find it... ;)
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.
Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.
You’re not serious, are you?
Siglent’s SDS2000X Plus of all things should not be able to measure low level low frequency signals (within the constraints of a general purpose oscilloscope), whereas a noisy Rigol is? And the excellent HF noise of the Siglent, which is somewhere between 2.4 and 3.5 nV/sqrt(Hz) should be a problem for LF measurements?
It’s not the first time that I’ve demonstrated low level, low frequency measurements with a Siglent DSO.
There are so many measures to ensure proper measurements under challenging conditions, including the trigger noise rejection function and HF-rejection coupling.
For the acquisition we have 10 bits mode, 20 MHz bandwidth limiter and average and ERES math functions. ERES is a lowpass filter by the way.
In the attached screenshot you can see a 10 Hz, 1.1 mVpp sinewave directly captured with 10 bits and 20 MHz bandwidth limit. Perfectly usable already, no further measures required. Is that not low frequency low level? Can you demonstrate how the Rigol does it so much better?
But there are two additional math traces. F1 is ERES 3.0, boosting the total resolution up to 16 bits. By limiting the record length to only 200 kpts the ERES lowpass has a corner frequency of just 7 kHz. Since its not the HF noise, but the 1/f noise that is a problem with all general purpose oscilloscopes, we still see some significant LF noise at the sensitivity of 500 µV/div. The measurements are pretty close, so neither the resolution enhancement nor the lowpass filter was really required.
F2 shows the result of 16x averaging. Since this is a static signal, it is the more effective measure, because it also reduces the LF noise. Still not a huge difference.
Finally it would be possible to combine ERES with averaging in a single math trace by means of the formula editor.
SDS2354X Plus_1mVpp_10Hz_200kpts(ERES7kHz)
-
You can search as long as you could, you won´t find it... ;)
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.
Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.
You’re not serious, are you?
Siglent’s SDS2000X Plus of all things should not be able to measure low level low frequency signals (within the constraints of a general purpose oscilloscope), whereas a noisy Rigol is? And the excellent HF noise of the Siglent, which is somewhere between 2.4 and 3.5 nV/sqrt(Hz) should be a problem for LF measurements?
It’s not the first time that I’ve demonstrated low level, low frequency measurements with a Siglent DSO.
That is not the issue. In some cases the signal coming into the oscilloscope has a lot of noise in frequency bands that you are not interested in. It is very handy if the oscilloscope can do digital filtering on the signal to get rid of those unwanted frequencies. It is one of the reasons that I hang on to my GW Instek DSO. Digital filtering is a very handy feature if you develop digital signal processing applications; you can use the filtering in the DSO to get a feel of how well (or not) a signal will clean up in the digital domain.
-
This setting alters the function of the horizontal position knob, and everything is labelled correctly.
Thanks for the response, will soon dig deeper into that.
Can't help though to think that even if there is no mistake, this could all be much more intuitive. Leaving out on the screen the word fixed for the Fixed Delay mode and the Fixed Position mode creates unnecessary confusion. (I mean, if I read Position on a menu item then I kind of expect that here I can change the position. if I read Fixed position then I understand I cannot change the position...)
(And we do have seen SDS screen interface elements being accidentally switched in earlier firmware versions, see the above thread.)
But thanks again.
-
Can't help though to think that even if there is no mistake, this could all be much more intuitive. Leaving out on the screen the word fixed for the Fixed Delay mode and the Fixed Position mode creates unnecessary confusion. (I mean, if I read Position on a menu item then I kind of expect that here I can change the position. if I read Fixed position then I understand I cannot change the position...)
Either the delay or the position can remain unchanged (= stay fixed) when the timebase is changed.
With fixed delay, the trigger position wil change according to the timebase.
With fixed position, the delay has to change according to the timebase.
Only exception: if the reference position is at 50 % and the delay is zero. In this case neither of them changes, regardless what timebase is used.
-
You can search as long as you could, you won´t find it... ;)
None of the siglent models have these functions and I´ve added them to my wishlist "long time ago" too.
Pity.
Measuring low level, low frequency signals was (almost) impossible on Siglent due to hf excessive noise. Rigol did it without a problem. Even it's noisy front-end was not a problem.
Well, at last I have good excuse for not selling my second, sorry, third... Sorry. Just not selling this little scope.
You’re not serious, are you?
Siglent’s SDS2000X Plus of all things should not be able to measure low level low frequency signals (within the constraints of a general purpose oscilloscope), whereas a noisy Rigol is? And the excellent HF noise of the Siglent, which is somewhere between 2.4 and 3.5 nV/sqrt(Hz) should be a problem for LF measurements?
It’s not the first time that I’ve demonstrated low level, low frequency measurements with a Siglent DSO.
There are so many measures to ensure proper measurements under challenging conditions, including the trigger noise rejection function and HF-rejection coupling.
For the acquisition we have 10 bits mode, 20 MHz bandwidth limiter and average and ERES math functions. ERES is a lowpass filter by the way.
In the attached screenshot you can see a 10 Hz, 1.1 mVpp sinewave directly captured with 10 bits and 20 MHz bandwidth limit. Perfectly usable already, no further measures required. Is that not low frequency low level? Can you demonstrate how the Rigol does it so much better?
But there are two additional math traces. F1 is ERES 3.0, boosting the total resolution up to 16 bits. By limiting the record length to only 200 kpts the ERES lowpass has a corner frequency of just 7 kHz. Since its not the HF noise, but the 1/f noise that is a problem with all general purpose oscilloscopes, we still see some significant LF noise at the sensitivity of 500 µV/div. The measurements are pretty close, so neither the resolution enhancement nor the lowpass filter was really required.
F2 shows the result of 16x averaging. Since this is a static signal, it is the more effective measure, because it also reduces the LF noise. Still not a huge difference.
Finally it would be possible to combine ERES with averaging in a single math trace by means of the formula editor.
SDS2354X Plus_1mVpp_10Hz_200kpts(ERES7kHz)
Thank You for Your input!
I'm describing below what happened, and why I would like to have filters.
I've set minimal amplitude (2mV pk-pk) @ 1kHz on SDG2042x. This signal was connected to the input of the transformer with ratio about 1:1. There was a reason to keep amplitude of test signal low. The signal on the output was "enriched" with the spikes from a different psu-s around, therefore syncing was troublesome. I tried to average signal, but it started to... dissapear (as syncing was unstable due to "spikes", averaging was approaching to the value of 0). Limiting input bandwith to 20M didn't helped. I was thinking about using ERES, but unfortunatelly I'm not as familiar with my scope as I wish to be, so limiting memory depth wouldn't be solution I might want to try. Thank You for this trick!!!
On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.
-
In some cases the signal coming into the oscilloscope has a lot of noise in frequency bands that you are not interested in. It is very handy if the oscilloscope can do digital filtering on the signal to get rid of those unwanted frequencies. It is one of the reasons that I hang on to my GW Instek DSO. Digital filtering is a very handy feature if you develop digital signal processing applications; you can use the filtering in the DSO to get a feel of how well (or not) a signal will clean up in the digital domain.
I've never said that digital filters can't be useful. Yet when someone complains about"HF noise", then we need a lowpass, right? Consequently I've listed the appropriate features to limit the bandwidth (10-bit mode, bandwidth limit, ERES math-function).
I've also never said that we might not get a filter package eventually. But then folks will most likely complain if they cannot get a 20 kHz lowpass at 1 GSa/s sample rate.
-
On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.
It sounds like the issue here is getting a stable trigger and I'm not seeing how LPF in a MATH function would help that. Why/how did the DS1054 get a stable trigger when the other scopes didn't? Or did you just use a single shot?
-
Thank You for Your input!
I'm describing below what happened, and why I would like to have filters.
I've set minimal amplitude (2mV pk-pk) @ 1kHz on SDG2042x. This signal was connected to the input of the transformer with ratio about 1:1. There was a reason to keep amplitude of test signal low. The signal on the output was "enriched" with the spikes from a different psu-s around, therefore syncing was troublesome. I tried to average signal, but it started to... dissapear (as syncing was unstable due to "spikes", averaging was approaching to the value of 0). Limiting input bandwith to 20M didn't helped. I was thinking about using ERES, but unfortunatelly I'm not as familiar with my scope as I wish to be, so limiting memory depth wouldn't be solution I might want to try. Thank You for this trick!!!
On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.
The user manual UM0102XP-E01B, on page 209, contains a table that lists how to calculate the ERES bandwidth from the number of bits and the sample rate.
With deep memory, the sample rate remains pretty constant of a wide range of horizontal timebase settings, but at slower timebases and by limiting the max. memory in the Acquisition menu you can get an appropriate sample rate for your timebase. A future firware might bring a more convenient constant sample rate setting exactly for these purposes (the SDS6000 already has it).
Even a dedicated filter package will need such tricks, because ressources go through the roof if you want low frequency, high resolution at still high sample rates. Try looking at just the audio band using even an 1 Mpts FFT at 2 GSa/s effective FFT sample rate. And then 1 Mpts certainly isn't an option for a realtime DSP filter...
-
In some cases the signal coming into the oscilloscope has a lot of noise in frequency bands that you are not interested in. It is very handy if the oscilloscope can do digital filtering on the signal to get rid of those unwanted frequencies. It is one of the reasons that I hang on to my GW Instek DSO. Digital filtering is a very handy feature if you develop digital signal processing applications; you can use the filtering in the DSO to get a feel of how well (or not) a signal will clean up in the digital domain.
I've never said that digital filters can't be useful. Yet when someone complains about"HF noise", then we need a lowpass, right? Consequently I've listed the appropriate features to limit the bandwidth (10-bit mode, bandwidth limit, ERES math-function).
I've also never said that we might not get a filter package eventually. But then folks will most likely complain if they cannot get a 20 kHz lowpass at 1 GSa/s sample rate.
You are not understanding the use case here. My GW Instek can low-pass filter to less than 20kHz with 1Gs/s input data just fine... For a project I did a couple of years ago I had a lot of noise coming from a circut at around 150kHz (nothing to do about that due to the nature of the circuit) but I needed to see signals in the several kHz range that got buried in the noise (edit: well, not noise perse but non interesting content in a different frequency band). In such cases there is no other way than to use filtering and it is extremely handy if the DSO can do that digitally (adjustable). In the end Eres and bandwidth limiting only get you so far because the unwanted content can alias back into your signal with lower samplerates; the minimum samplerate has to be high enough to meet nyquist for the signal content you want to get rid of otherwise it will alias. And there may also be cases where a highpass or bandpass filter come in very handy. Think about protocols that are modulated onto mains.
Edit: added some clarifications; replace 'noise' by 'unwanted signal content'.
-
Think having selectable/settable digital filters of various types would be a great asset to the Siglent line of DSOs. In addition to the practical value in the field and lab, the value for educational purposes would be tremendous, where students could "see" in real time the effects of various analog approximations (IIR) and digital (FIR) filters on different analog input signals :-+
Maybe someone from Siglent is listening ::)
Best,
-
Think having selectable/settable digital filters of various types would be a great asset to the Siglent line of DSOs.
Fairly recently, R&S added various digital filters to their RTB series by means of a firmware update.
They have proven quite useful to me...
Maybe someone from Siglent is listening ::)
Hope so!
-
You are not understanding the use case here. My GW Instek can low-pass filter to less than 20kHz with 1Gs/s input data just fine...
Is that filtering pre or post-trigger? IOW, can it prevent triggering on HF spikes?
I agree that this would be a very useful feature if properly implemented, and at first glance I don't think it would be particularly difficult. I don't know about the computational resources needed to do it in real time so as to mimic an analog front end filter. I have high-impedance 10:1 analog front end filters that go as low as 4kHz, they're fairly easy to make. Being able to just dial those in and get the exact same function would be quite useful.
-
On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.
It sounds like the issue here is getting a stable trigger and I'm not seeing how LPF in a MATH function would help that. Why/how did the DS1054 get a stable trigger when the other scopes didn't? Or did you just use a single shot?
No matter how stable triggering on 1054z was, I got reliable pk-pk measurement, which was what I wanted to get.
-
Thank You for Your input!
I'm describing below what happened, and why I would like to have filters.
I've set minimal amplitude (2mV pk-pk) @ 1kHz on SDG2042x. This signal was connected to the input of the transformer with ratio about 1:1. There was a reason to keep amplitude of test signal low. The signal on the output was "enriched" with the spikes from a different psu-s around, therefore syncing was troublesome. I tried to average signal, but it started to... dissapear (as syncing was unstable due to "spikes", averaging was approaching to the value of 0). Limiting input bandwith to 20M didn't helped. I was thinking about using ERES, but unfortunatelly I'm not as familiar with my scope as I wish to be, so limiting memory depth wouldn't be solution I might want to try. Thank You for this trick!!!
On the DS1054 I turned math with lpf, set filter's bw to 3kHz and it was done.
The user manual UM0102XP-E01B, on page 209, contains a table that lists how to calculate the ERES bandwidth from the number of bits and the sample rate.
With deep memory, the sample rate remains pretty constant of a wide range of horizontal timebase settings, but at slower timebases and by limiting the max. memory in the Acquisition menu you can get an appropriate sample rate for your timebase. A future firware might bring a more convenient constant sample rate setting exactly for these purposes (the SDS6000 already has it).
Even a dedicated filter package will need such tricks, because ressources go through the roof if you want low frequency, high resolution at still high sample rates. Try looking at just the audio band using even an 1 Mpts FFT at 2 GSa/s effective FFT sample rate. And then 1 Mpts certainly isn't an option for a realtime DSP filter...
Ok, but what if I would like to eliminate something from low-band side? Eg. 50Hz hum?
-
You are not understanding the use case here. My GW Instek can low-pass filter to less than 20kHz with 1Gs/s input data just fine...
Is that filtering pre or post-trigger? IOW, can it prevent triggering on HF spikes?
It is post-trigger (post acquisition filtering; you can change the settings without needing to re-acquire on the GW Instek). Triggering typically already has various high-pass / low pass filter settings so having extra filters is not really necessary. With enough memory you can usually just take a random snapshot and have plenty of data to work with; precise triggering becomes less important if you have deep memory.
-
You are not understanding the use case here. My GW Instek can low-pass filter to less than 20kHz with 1Gs/s input data just fine...
Oh, interesting. Are you sure that the effective sample rate used for the filter trace is actually 1 GSa/s for such low frequency limits?
Have you ever tried that with the RTM3000?
For a project I did a couple of years ago I had a lot of noise coming from a circut at around 150kHz (nothing to do about that due to the nature of the circuit) but I needed to see signals in the several kHz range that got buried in the noise (edit: well, not noise perse but non interesting content in a different frequency band). In such cases there is no other way than to use filtering and it is extremely handy if the DSO can do that digitally (adjustable).
Yes, no need to repeat the obvious over and over again. I never disputed that and already said that we might get something in the future.
In the end Eres and bandwidth limiting only get you so far because the unwanted content can alias back into your signal with lower samplerates; the minimum samplerate has to be high enough to meet nyquist for the signal content you want to get rid of otherwise it will alias. And there may also be cases where a highpass or bandpass filter come in very handy. Think about protocols that are modulated onto mains.
Huh?
Òn which scope will the bandwidht limiter affect the sample rate?
And in what aspect do you think ERES is different from a LP filter math function, so that it might affect the sample rate? Yes, ERES frequency range is closely related to sample rate - like any digital filter.
And yes, (re-iterating it once again) high- and bandpass filters can be useful as well. Does the GW have a bandpass? And what about the R&S?
On the other hand, when Siglent provides an offer in the future, it will be a complete filter-package.
-
My GW Instek, R&S and Micsig, Yokogawa and Lecroy scopes have low-pass, band-pass and high pass filtering (although R&S uses decimated data). So it is not some kind of outlandish feature. And they all do that today (well, if I had the extended math option on the Yokogawa; but it is there), not at some undefined point in the future. On the GW Instek I can set it to 1 Hz if I want with a 1Gs/s samplerate; don't care how they do it -it works-.
Regarding Eres: you suggested to lower the samplerate in order to bring the cutoff-frequency of the filtering Eres down, but that comes at the risk of aliasing. So in the end that is a severely limited filtering function and not much of a replacement for having dedicated filter functions. That is the point I wanted to make.
-
My GW Instek, R&S and Micsig, Yokogawa and Lecroy scopes have low-pass, band-pass and high pass filtering (although R&S uses decimated data). So it is not some kind of outlandish feature. And they all do that today (well, if I had the extended math option on the Yokogawa; but it is there), not at some undefined point in the future. On the GW Instek I can set it to 1 Hz if I want with a 1Gs/s samplerate; don't care how they do it -it works-.
Regarding Eres: you suggested to lower the samplerate in order to bring the cutoff-frequency of the filtering Eres down, but that comes at the risk of aliasing. So in the end that is a severely limited filtering function and not much of a replacement for having dedicated filter functions. That is the point I wanted to make.
We spoke about this already few time. ERES is lowpass filtering on full sample rate, NOT decimation. High frequency content gets filtered out, it cannot alias....
It is actually an digital antialias filter...
-
My GW Instek, R&S and Micsig, Yokogawa and Lecroy scopes have low-pass, band-pass and high pass filtering (although R&S uses decimated data). So it is not some kind of outlandish feature. And they all do that today (well, if I had the extended math option on the Yokogawa; but it is there), not at some undefined point in the future. On the GW Instek I can set it to 1 Hz if I want with a 1Gs/s samplerate; don't care how they do it -it works-.
Regarding Eres: you suggested to lower the samplerate in order to bring the cutoff-frequency of the filtering Eres down, but that comes at the risk of aliasing. So in the end that is a severely limited filtering function and not much of a replacement for having dedicated filter functions. That is the point I wanted to make.
We spoke about this already few time. ERES is lowpass filtering on full sample rate, NOT decimation. High frequency content gets filtered out, it cannot alias....
It is actually an digital antialias filter...
Think you pointed to this LeCroy document awhile back.
https://teledynelecroy.com/doc/differences-between-eres-and-hires
Best,
-
My GW Instek, R&S and Micsig, Yokogawa and Lecroy scopes have low-pass, band-pass and high pass filtering (although R&S uses decimated data). So it is not some kind of outlandish feature. And they all do that today (well, if I had the extended math option on the Yokogawa; but it is there), not at some undefined point in the future. On the GW Instek I can set it to 1 Hz if I want with a 1Gs/s samplerate; don't care how they do it -it works-.
Regarding Eres: you suggested to lower the samplerate in order to bring the cutoff-frequency of the filtering Eres down, but that comes at the risk of aliasing. So in the end that is a severely limited filtering function and not much of a replacement for having dedicated filter functions. That is the point I wanted to make.
We spoke about this already few time. ERES is lowpass filtering on full sample rate, NOT decimation. High frequency content gets filtered out, it cannot alias....
It is actually an digital antialias filter...
Think you pointed to this LeCroy document awhile back.
https://teledynelecroy.com/doc/differences-between-eres-and-hires
I stand corrected but still Eres is a far cry from having filters which have samplerate independant adjustable cut-off frequencies and band pass / high pass filtering in addition to low pass filtering.
Edit: reading the website again, I don't see that the filter length for Eres is adjusted for a lower samplerate. And given that Eres preserves the original data (being a post processing math operation), I don't see how Eres would prevent aliasing when the samplerate is pushed down in order to make the cut-off frequency lower. Perhaps someone can eloborate on that.
-
My GW Instek, R&S and Micsig, Yokogawa and Lecroy scopes have low-pass, band-pass and high pass filtering (although R&S uses decimated data). So it is not some kind of outlandish feature. And they all do that today (well, if I had the extended math option on the Yokogawa; but it is there), not at some undefined point in the future. On the GW Instek I can set it to 1 Hz if I want with a 1Gs/s samplerate; don't care how they do it -it works-.
Regarding Eres: you suggested to lower the samplerate in order to bring the cutoff-frequency of the filtering Eres down, but that comes at the risk of aliasing. So in the end that is a severely limited filtering function and not much of a replacement for having dedicated filter functions. That is the point I wanted to make.
We spoke about this already few time. ERES is lowpass filtering on full sample rate, NOT decimation. High frequency content gets filtered out, it cannot alias....
It is actually an digital antialias filter...
Think you pointed to this LeCroy document awhile back.
https://teledynelecroy.com/doc/differences-between-eres-and-hires
I stand corrected but still Eres is a far cry from having filters which have samplerate independant adjustable cut-off frequencies and band pass / high pass filtering in addition to low pass filtering.
As Performa said, nobody disputes that fully featured filters are very useful.
-
Edit: reading the website again, I don't see that the filter length for Eres is adjusted for a lower samplerate. And given that Eres preserves the original data (being a post processing math operation), I don't see how Eres would prevent aliasing when the samplerate is pushed down in order to make the cut-off frequency lower. Perhaps someone can eloborate on that.
I think it works for the same reason a sampling RF voltmeter 'works'--there can be aliasing in the acquired data, but after 3-bit ERES is applied, it all gets filtered out. You might be thinking that perhaps a signal just over Nyquist would alias all the way down to the frequency you want to see and I can't think of a good reason offhand why that wouldn't happen. I suppose an experiment is in order.
-
OK, is there some reason the MATH traces don't show up in the zoom window??? :-// I guess I'm in the correct thread to complain about that...
Anyway, as far as I can tell using 5ms/div, 20 kpts which results in 400kSa/s and 201kHz, the ERES operation removes any aliased signal. It is completely flat with a 201kHz signal input and shows normal filter response as you go from 1 to 5 kHz and so on.
Edit: It seems to be the case that MATH doesn't appear in a zoom window on at least the SDS1000X-E and SDS2000X+ series. I never noticed before, but this seems egregious on a scope with memory management that essentially requires you to use zoom for things that other scopes don't and particularly egregious on the SDS200X+ where ERES is implemented as a math channel instead of an acquisition mode. Am I missing something? What do other scopes do?
-
If your ROI is 0..5kHz then the potential alias regions are N*fs-5...N*fs+5 kHz, so rather try to inject an unwanted signal of (say) 399 or 401 kHz, if the sample rate is 400kSa/s. In the absence of an apropriate analog anti-aliasing filter in front of the ADC, this frequecy will appear at 1kHz then, and can't be removed any more with a digital filter w/o disturbing the wanted signal in the ROI as well.
-
OK, is there some reason the MATH traces don't show up in the zoom window??? :-// I guess I'm in the correct thread to complain about that...
Even though we have deep measurements and math (in contrast to just using screen data), at one point we need to start decimating the original sample data in order to be able to handle them with reasonable performance. For a Keysight MSOX, the size of the decimated data is some 64 kpts, whereas for the Siglents it is at least 12.5 Mpts.
In certain situations, the record length might be longer than 12.5 Mpts and then all math and measurements are using the secondary buffer that contains the decimated data. In this case, a zoomed version of the original math function would not be quite what we want.
Solution: We have the zoom channels Z1...Z4 as additional data sources. With these, we get full resolution math and measurements, no matter how long the original record is and what zoom factor we use.
-
My GW Instek, R&S and Micsig, Yokogawa and Lecroy scopes have low-pass, band-pass and high pass filtering (although R&S uses decimated data). So it is not some kind of outlandish feature. And they all do that today (well, if I had the extended math option on the Yokogawa; but it is there), not at some undefined point in the future. On the GW Instek I can set it to 1 Hz if I want with a 1Gs/s samplerate; don't care how they do it -it works-.
I never claimed it was an outstanding feature.
You did not answer my question about low filter frequencies on the R&S at full sample rate - or yes, maybe you did, as you admitted that it uses decimated data. And you are not afraid this might cause aliasing problems?
And as cool as it might sound "I don't care how it's done", it should be quite obvious, that 1 Hz corner frequency just isn't feasible at e.g. 1 GSa/s - and no serious instrument will have this feature - all the more so without any mention how it works, because the latter would be absolutely required in order to warn the user - for the exact reason that you brought up: sample rate reduction might cause problems with aliasing. Because the only way to implement this will of course be internal data decimation, hence reduction of the effective sample rate. All the more so on a not so high performance embedded platform.
I already hinted on the FFT, which shares the same basic problem: one might want to keep the effective sample rate high because of some unwanted signals in the HF region, but still closely inspect the audio frequency range at the same time. It just doesn't happen. At 1 GSa/s, even 1 Mpts FFT has a the frequency step of ~2 kHz, resolution bandwidth would be some 7 kHz with the FlatTop window. In order to get a more useful RBW of less than 100 Hz, we'd need a 128 Mpts FFT. and for 1 Hz frequency step (not RBW) we'd need 2 Gpts.
-
My GW Instek, R&S and Micsig, Yokogawa and Lecroy scopes have low-pass, band-pass and high pass filtering (although R&S uses decimated data). So it is not some kind of outlandish feature. And they all do that today (well, if I had the extended math option on the Yokogawa; but it is there), not at some undefined point in the future. On the GW Instek I can set it to 1 Hz if I want with a 1Gs/s samplerate; don't care how they do it -it works-.
I never claimed it was an outstanding feature.
You did not answer my question about low filter frequencies on the R&S at full sample rate - or yes, maybe you did, as you admitted that it uses decimated data. And you are not afraid this might cause aliasing problems?
I checked my old notes: The decimation used by the R&S scopes uses some form of subsampling (likely to retain the shape/outline of the signal) which causes aliasing problems with filtering; the R&S wouldn't be my tool of choice when I need filtering (which I also wrote in the review I did on the RTM3004 a couple of years ago).
And as cool as it might sound "I don't care how it's done", it should be quite obvious, that 1 Hz corner frequency just isn't feasible at e.g. 1 GSa/s - and no serious instrument will have this feature - all the more so without any mention how it works, because the latter would be absolutely required in order to warn the user - for the exact reason that you brought up: sample rate reduction might cause problems with aliasing. Because the only way to implement this will of course be internal data decimation, hence reduction of the effective sample rate. All the more so on a not so high performance embedded platform.
The likely way it is implemented on the GW Instek is by cascading filters and decimate the signal a couple of times to get to a lowpass or bandpass filter. But that doesn't mean that there is aliasing! And the decimation filters don't have to be very tidy; an elliptic filter doesn't need much resources. Or even averaring a number of samples to form a lowpass filter could be enough. In my experience cascading filters in order to decimate the samplerate is a good way to start from a high sampling rate if the aim is to filter a relatively low frequency. Using one filter is usually problematic due to finite resolution and stability issues.
I already hinted on the FFT, which shares the same basic problem: one might want to keep the effective sample rate high because of some unwanted signals in the HF region, but still closely inspect the audio frequency range at the same time. It just doesn't happen. At 1 GSa/s, even 1 Mpts FFT has a the frequency step of ~2 kHz, resolution bandwidth would be some 7 kHz with the FlatTop window. In order to get a more useful RBW of less than 100 Hz, we'd need a 128 Mpts FFT. and for 1 Hz frequency step (not RBW) we'd need 2 Gpts.
There is a limit to everything.
-
Eres.
Least with these example oscilloscopes, SDS1204X-E and some unknown oscilloscope ERES do not prevent aliasing.
Here decimated samplerate in both cases is 500kSa/s
In both cases ADC true hardware samplerate is 1GSa/s.
Both oscilloscopes input is roughly equal signal, 50501 kHz level roughly 5.6dBm (naturally same works with 501, 1001, 1501, 2001 kHz and so on. )
Both oscilloscopes set for ERES ench.bits 3.0
Both show 1kHz without even attanuation. Both 50ohm inputs 200mV/div.
Same 1kHz is of course available using what ever signal what is sampling frequency or decimated sampling frequency harmonic (as I have used 101th) + 1kHz or -1kHz (if want 1kHz alias)
Of course also some other frequencies, just then alias is different.
This is also why fixed ADCs can use for frequency converter. And, in digital side there is not any single method for regognize what is alias or not alias (if we do not get some more information for detect this.) (naturally there is methods for hide aliasing on oscilloscope screen while at the same time accepting the nasty things it causes.
Why I use so high freq, this result can see alsousing just 501 or 499kHz. (for get 1kHz as IF if just think ADC is like mixer where LO is 500kHz and 501 or 499 is freq in.)
But why I use so high freq... ERES is 3.0 and ADC true HW sampling frequency is 1GHz. With 3 bit enchange -3dB is perhaps around 0.008 x fSampling. (0.016 x fNyquist) in LeCroy paper. But I do not know Siglent filtering. (looks like -3dB is bit lower) But least it is somehere under 10MHz at this 1GSa/s.
But because decimated samplerate 500kSa/s it can easy see that example using 50.504kHz this alias drops more than -3dB (same happen if use 504kHz signal.)
If look LeCroy paper -3dB is 250kHz * 0.016 it is 4kHz but when I look it with example SDS1204X-E it is somewhere around 3.5kHz.
But I can not see attenuation in alias if example alias is 1kHz and input freq is this bit over 50MHz.
(If I look this same bit over 50MHz signal with 1GSa/s samplerate and use same ERES 3.0 of course then this 50MHz is highly attenuated, just as expected)
Naturally this 1kHz alias do not trig so its position jumps around.
With ERES user need understand what is alias and how to avoid traps caused by it, specially when use low decimated samplerate and wide band front end.
-
This conversation just went wrong direction.
The original statement that I responded to (as far as I understood it) was that if you apply ERES on a signal sampled at 5 GS/s you will get a lowpass filter effect. If you go for 3 Bit ERES you get effective lowpass filter with less than 100 MHz of bandwidth.
And then was said that if you apply a high frequency, say 200Mhz, it will alias.
While setup like that, if you apply 200 MHz signal it won't alias. It will show 200MHz signal. It will have amplitude defined by ERES filter stopband. But it won't alias.
Then people started talking about different scenario: If you setup sample rate too low for the signal (10 MS/s for 30 MHz signal), and then apply ERES there will be aliasing... Of course there will be aliasing.
Because you sampled with sample rate too low in a first place, got aliased samples and then applied ERES to already subsampled signal. What was ERES supposed to do: magically reverse destroyed signal?
-
The original question was this:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg3988559/#msg3988559 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg3988559/#msg3988559)
Fits "perfect" to this thread from the meaning.
The answers to this question are drifting more and more away from it.
-
Because you sampled with sample rate too low in a first place, got aliased samples and then applied ERES to already subsampled signal. What was ERES supposed to do: magically reverse destroyed signal?
No, it just shows that Eres is not a replacement for having real filtering. It is simple as that.
-
My previous answer, if it wasn’t clear enough, was largely a caricature example. I tried to stop all possible stories that ERES was like some kind of anti-alias filter.
I think I should have said it in a simple short sentence so that it also reaches potential readers with little knowledge on the subject.
ERES (which we are talking about in this context) does not in itself remove the alias regardless of the sample rate. Filtering (for prevent aliasing) signal max f below the aliasing frequencies should occur before the AD converter. It cannot be done properly after the AD converter for fixed frequency sampling or decimated directly from it.
ERES does not prevent aliasing. Period.
It may prevent aliasing at some known spot frequencies, but the oscilloscope must work to analyze unknown signals to resolve the signal.
It is the user's responsibility to examine only signals that do not pass significant amounts above the fNyquist frequencies at the input of the AD converter.
And as observed, this is strongly on the sidelines for one of the questions raised previously.
But any misunderstandings that ERES would act as an anti-alias filter must also be stopped so that no one is left with false beliefs about it.
However, ERES is very good when used correctly. Some of its benefits are described in LeCroy’s white paper.
-
Because you sampled with sample rate too low in a first place, got aliased samples and then applied ERES to already subsampled signal. What was ERES supposed to do: magically reverse destroyed signal?
No, it just shows that Eres is not a replacement for having real filtering. It is simple as that.
No. It shows GIGO principle. Garbage in garbage out.
As far as aliasing goes, ERES is working better than HiRes on Keysight. HiRes on Keysight, for instance, can be made to alias fairly easy.
-
My previous answer, if it wasn’t clear enough, was largely a caricature example. I tried to stop all possible stories that ERES was like some kind of anti-alias filter.
I think I should have said it in a simple short sentence so that it also reaches potential readers with little knowledge on the subject.
ERES (which we are talking about in this context) does not in itself remove the alias regardless of the sample rate. Filtering (for prevent aliasing) signal max f below the aliasing frequencies should occur before the AD converter. It cannot be done properly after the AD converter for fixed frequency sampling or decimated directly from it.
ERES does not prevent aliasing. Period.
It may prevent aliasing at some known spot frequencies, but the oscilloscope must work to analyze unknown signals to resolve the signal.
It is the user's responsibility to examine only signals that do not pass significant amounts above the fNyquist frequencies at the input of the AD converter.
And as observed, this is strongly on the sidelines for one of the questions raised previously.
But any misunderstandings that ERES would act as an anti-alias filter must also be stopped so that no one is left with false beliefs about it.
However, ERES is very good when used correctly. Some of its benefits are described in LeCroy’s white paper.
ERES is not an aliasing REMOVER. That is for sure.
But it won't cause aliasing, if sampling is proper for signal in question before ERES is applied.
As Martin pointed out, this all has nothing to do with bugs or missing features. ERES is one of the things that works well.
The crux here is SDS2000X+ at the current time has no filters. Will Siglent port their filter package to SDS2000X+ and in which form remains to be seen.
-
I checked my old notes: The decimation used by the R&S scopes uses some form of subsampling (likely to retain the shape/outline of the signal) which causes aliasing problems with filtering; the R&S wouldn't be my tool of choice when I need filtering (which I also wrote in the review I did on the RTM3004 a couple of years ago).
Isn't it funny, how a prohibitively expensive DSO from a reputable A-brand wouldn't be "the tool of choice"?
And what about other serious instruments, e.g. from Keysight or LeCroy?
Sorry, but I don't buy the "Goodwill can magically circumvent the principles of digital signal processing" narrative.
And as cool as it might sound "I don't care how it's done", it should be quite obvious, that 1 Hz corner frequency just isn't feasible at e.g. 1 GSa/s - and no serious instrument will have this feature - all the more so without any mention how it works, because the latter would be absolutely required in order to warn the user - for the exact reason that you brought up: sample rate reduction might cause problems with aliasing. Because the only way to implement this will of course be internal data decimation, hence reduction of the effective sample rate. All the more so on a not so high performance embedded platform.
The likely way it is implemented on the GW Instek is by cascading filters and decimate the signal a couple of times to get to a lowpass or bandpass filter. But that doesn't mean that there is aliasing! And the decimation filters don't have to be very tidy; an elliptic filter doesn't need much resources. Or even averaring a number of samples to form a lowpass filter could be enough. In my experience cascading filters in order to decimate the samplerate is a good way to start from a high sampling rate if the aim is to filter a relatively low frequency. Using one filter is usually problematic due to finite resolution and stability issues.
So, the truth is that you're just speculating (not the first time) and actually don't know. Therefore, my quoted statement is still valid.
Have you ever tried to find out the true frequency resolution for e.g. a 100 MHz filter (no matter if it's low-, high- or bandpass)? Do you really believe you can set the frequency in 1 Hz steps up there? Yes, that's hard to find out, but maybe the actual frequency steps are coarse enough so that it's not that difficult to do.
-
I checked my old notes: The decimation used by the R&S scopes uses some form of subsampling (likely to retain the shape/outline of the signal) which causes aliasing problems with filtering; the R&S wouldn't be my tool of choice when I need filtering (which I also wrote in the review I did on the RTM3004 a couple of years ago).
Isn't it funny, how a prohibitively expensive DSO from a reputable A-brand wouldn't be "the tool of choice"?
And what about other serious instruments, e.g. from Keysight or LeCroy?
Simple: there ain't no such thing as the perfect scope. You may want to downplay the GW Instek but you might want to try the GDS-2000E series some time. You'll find these are very effective instruments within their capabilities, a real joy to use. Mine is currently sitting on top of a Lecroy Wavepro 7k series at my second work area. Only when things get though (like needing high time resolution or complicated measurements) the Lecroy gets powered on; otherwise it is the GW Instek.
And as cool as it might sound "I don't care how it's done", it should be quite obvious, that 1 Hz corner frequency just isn't feasible at e.g. 1 GSa/s - and no serious instrument will have this feature - all the more so without any mention how it works, because the latter would be absolutely required in order to warn the user - for the exact reason that you brought up: sample rate reduction might cause problems with aliasing. Because the only way to implement this will of course be internal data decimation, hence reduction of the effective sample rate. All the more so on a not so high performance embedded platform.
The likely way it is implemented on the GW Instek is by cascading filters and decimate the signal a couple of times to get to a lowpass or bandpass filter. But that doesn't mean that there is aliasing! And the decimation filters don't have to be very tidy; an elliptic filter doesn't need much resources. Or even averaring a number of samples to form a lowpass filter could be enough. In my experience cascading filters in order to decimate the samplerate is a good way to start from a high sampling rate if the aim is to filter a relatively low frequency. Using one filter is usually problematic due to finite resolution and stability issues.
So, the truth is that you're just speculating (not the first time) and actually don't know. Therefore, my quoted statement is still valid.
Have you ever tried to find out the true frequency resolution for e.g. a 100 MHz filter (no matter if it's low-, high- or bandpass)? Do you really believe you can set the frequency in 1 Hz steps up there? Yes, that's hard to find out, but maybe the actual frequency steps are coarse enough so that it's not that difficult to do.
I can try some time but I have no reason to doubt it works. You may think that it is impossible to do but as I wrote before: by cascasing filters, getting 1Hz resolution even when starting from 1Gs/s is perfectly doable. But this likely takes using test signals in the single digit Hz range. With a bandwidth of 100MHz a 1Hz resolution will get lost in the noise so that is not very useful to test. From using the GW Instek for real work I have found that the frequency resolution of the filters is really fine. The coefficients are calculated on-the-fly; it is not a bunch of preset filters.
-
Digital filters:
Tomorrow I guess, I´ll get a 30-days-trial license for our waverunner scope, the digital filter package.
Will post some pics here, maybe we got a clue what will await us, when siglent offers digital filters too.
-
Hi everybody,
I would like to report a bug regarding the SDS2104X Plus with SPL2016, Firmware v1.3.9R6.
Issue: Digital Bus Hex decode not in sync with digital lines
Situation:
1) Trigger on Strobe (D7) falling edge, Timebase 1ms/div (see pic A)
2) "Zooming in" by changing Timbase to 200ns/div (see pic B), the digital lines D0-7 show 08H, but the bus Hex decode shows FFH (incorrect)
Note: if Timebase is changed from 200ns/div to 100ns/div (or 500ns/div) the bus decode shows the correct value for a short time and then "jumps" back to the incorrect value.
3) If triggered on Strobe (D7) falling edge, 200ns/div (see pic C), the Bus Hex decode shows the correct value 08H
This behavior does not occur on my SDS1104X-E with SLA1016.
Please confirm, thanks, Matthias
-
[Apologies if the below question was already answered before; I saw a couple of posts on it but no real solutions.]
I want to load a custom waveform – preferable a measured wave - in the SDS2000X+ function generator (current FW 1.3.9R6). According to the specifications and manual, there are three ways of using custom waveforms. Two ways do not seem to work at all for me, and one way only half.
The first way is to copy a trace to the AWG. The manual is pretty silent on this (except saying it is possible) but it appears that the AWG > ARB TYPE > STORED > CHANNEL is the way to do this. When I do so, however, I invariably get a ‘File does not exist!' error. I tried different ways to see whether I can store a waveform (saved a trace as 1.CSV, saved a trace as 1.BIN) but all at no avail.
The second way is to send a wave from the Siglent EasyWave Windows software, as mentioned in the manual. The software recognizes my SDS as such, and via COMMUNICATION | SEND WAVE I can send a wave to the SDS in what is called 'store location' “ARB1” to “ARB4”. (*) When done so, I hear some relays in the SDS click, had have the feeling something is really happening. But the problem is that after that, the transferred file cannot be found anywhere in the ARB selection menu of the SDS (and cannot be found in the File Manager of the device either…) So upload from EasyWave is unsuccessful on the SDS. The same procedure, however, DOES work on my Siglent SDS2042X function generator.
(*) another strange thing: creating a new waveform only allows the user to choose between 20Vpp and 20mVpp, I had to choose the latter as the SDS does only support up to 6Vpp for ARB (as indicated by both on the SDS itself and the EasyWave software, that gives an error that 20Vpp is not allowed for this 6Vpp device).
The third way is to load an *.CSV, a *.DAT or an *.BIN waveform from a USB flash drive (unfortunately not from the internal memory, where such wave can be saved by the SDS itself). There is no description in the manual of how that CSV (or another file) should be formatted. After some experimentation, I found that the HaversineExampleFile.csv in the ZIP file at https://siglentna.com/wp-content/uploads/2017/12/EasyWaveCSV.zip can serve as a starting point (this file is meant for the EasyWave software but apparently works on the scope too). With trial and error, I get some waveforms to upload, but it seems that the parameters at the top of the file (amplitude, frequency) are not correctly read by the SDS.
So, long story. Questions to anyone with experience:
A. did anyone get options 1 or 2 (copy trace, import from EasyWave) to work? How?
B. Does anyone know the actual specifications of the CSV file the SDS ARB can read properly?
Thanks, Rudi
-
Small addition to the previous email: reading some posts, I now also tried EasyWaveX (current version, 1.1.0.13).
Alas, when I connect the SDS2000X + and in the software select "Send Waveform to AWG", I get the error "Non-Supported Manufacturer or unavailable resource."
-
Idea for a feature request, would be nice if the FFT horizontal axis can be displayed in log scale, would make the already powerful FFT capability even more useful imo.
-
Regarding having high pass / low pass with user defined cutoff frequency, it would be extremely helpful if say you need to measure RMS voltage from specifically 10Hz to 1MHz for obtaining an industry standard noise spec of a circuit.
I am currently building a low noise amplifier for characterizing noise, and have to build in a hardware 4th order filter at the output stage to shape the response of the output. It is 2022, my scope should be able to do that in software.
-
Additionally to the problems and questions described in #624, I've found, that even if set AWG parameters manually to wanted values, these are lost after save -> power-off -> recall. It means recall only restores settings of oscilloscope part of SDS2000X Plus, but not AWG settings.
So my question/request is:
* to read AWG settings from [wave].csv file, if valid values are there
* to make it possible to load csv files from internal disk (not usb-drive only)
* to make it possible to store the wave in AWG/ArbType/Stored-page and recall from it
* to save/recall all AWG settings by using save/recall button
Thanks and br
Holger
-
Someone knows how does the AWG works on this oscilloscope?
Because one hour ago I turned on for the first time this function to make a square wave and a sine wave but if I switch from high impedance to 50ohm nothing happens!
The only thing that changes is the max admitted voltage on the Vpp value box. But the wave stay the same without any change.
Because it's the first time I use a waveform generator maybe I am missing something.
I'm worried about it could have a relay that should switch between the different impedance resistors and it is not working..... It's a brand new oscilloscope.... damn!
Thanks
-
Hi Fiorenzo,
Your scope is ok... ;)
To say it simple, you need also a 50ohm load - easiest example, switch input impedance of one channel of the scope to 50ohm...
-
Someone knows how does the AWG works on this oscilloscope?
Because one hour ago I turned on for the first time this function to make a square wave and a sine wave but if I switch from high impedance to 50ohm nothing happens!
The only thing that changes is the max admitted voltage on the Vpp value box. But the wave stay the same without any change.
Because it's the first time I use a waveform generator maybe I am missing something.
I'm worried about it could have a relay that should switch between the different impedance resistors and it is not working..... It's a brand new oscilloscope.... damn!
Thanks
Like Martin says, it is ok.
This one is a little confusing for beginners.
Think of it this way: Generator is always 50Ω. That button is for you to set what kind of LOAD you are using it with.
So if you are using it with 50Ω load or say 1MΩ generator is always doing the same.
But if you are using it with 50Ω, internal 50Ω impedance of the generator and 50Ω will make a divider by 2 so your voltage will be the half of what you get when generator is unloaded (High Z, large impedance connected).
This setting is only a configuration for AWG how it should correctly calculate output voltage it shows you on screen in regards to your load.
-
Yeah, you guys are super super super kind
Thank you very much for the explanation.
So it is only a "graphical setting" for the scale...
-
So it is only a "graphical setting" for the scale...
It's not just a graphical setting. The input of the scope does really have an impedance or input resistance of 50 Ohms now. So the source has to deliver a higher current than into an input resistance of 1MOhm. There is a real power P=U*I or P=U²/50 Ohms the input of the scope has to handle. That's the reason, the input voltage is limited when in 50Ohm mode.
-
It's not just a graphical setting.
Well, yes and no.
The OP asked about the 50Ω setting in the AWG. This is located at setting "AWG > Setting > Output Load" (and can be set to 50Ω of High-Z). There, it is purely a graphical setting. The output impedance of the AWG is always 50Ω, and the setting in question simply makes sure that *if* you load it with an actual 50Ω load then the scope shows the output voltage appearing over that load. So it's only about values being shown on the screen, no difference in the physical world.
The 50Ω setting for channels (which was not the actual question of the OP) is located at setting "Channel X > Impedance" (and can be set to 50Ω) actually changes something in the physical world. When 50Ω is selected, the oscilloscope activates a relay that puts a 50Ω resistor across the input channel in question. Great feature, but be careful: if you connect a signal greater than approx 7V DC or ACrms to that channel, you will burn that resistor and thus damage the oscilloscope, with an expensive repair as a result. I have seen quite some broken scopes for this very reason.
You may want to look at the extensive overview I posted at rudiselectronicslab.com (http://rudiselectronicslab.com) , where the above and many other things are covered, or the series of videos (https://www.youtube.com/channel/UCSTHQUENuAc2UwmrlHkVGKw) I made on this scope.
Best, Rudi
-
if you connect a signal greater than approx 7V DC or ACrms to that channel, you will burn that resistor and thus damage the oscilloscope, with an expensive repair as a result. I have seen quite some broken scopes for this very reason.
And since this is the "Bugs / Missing Features / Feature Requests thread, I'd call again for Siglent to 'fix' this by monitoring and automatically disconnecting the 50R input when the signal level gets too high.
-
........ by monitoring and automatically disconnecting the 50R input when the signal level gets too high.
Think the old Tektronix analog scopes did this.
Best,
-
Think the old Tektronix analog scopes did this.
Yes, the Tek 24xx series manages to do this just fine, not sure about other models. It seems an obvious feature to add and it doesn't require anything extra in the signal path.
-
It seems an obvious feature to add and it doesn't require anything extra in the signal path.
Yes, you would think so.
This exact topic has been under deep discussion the last few days on the Siglent forum.
Can't yet say what will be implemented in the X Plus.
-
if you connect a signal greater than approx 7V DC or ACrms to that channel, you will burn that resistor and thus damage the oscilloscope, with an expensive repair as a result. I have seen quite some broken scopes for this very reason.
And since this is the "Bugs / Missing Features / Feature Requests thread, I'd call again for Siglent to 'fix' this by monitoring and automatically disconnecting the 50R input when the signal level gets too high.
Define 'too high'. You can't just add a comparator or so that looks at the voltage level. It would need a circuit that monitors power dissipation over time instead of just a voltage level. At some point I've fed pulses into a DSO for which I needed the 20V/div range in 50 OHm mode in order for the signal to fit on the screen vertically.
-
Define 'too high'. You can't just add a comparator or so that looks at the voltage level. It would need a circuit that monitors power dissipation over time instead of just a voltage level. At some point I've fed pulses into a DSO for which I needed the 20V/div range in 50 OHm mode in order for the signal to fit on the screen vertically.
"Too high" = enough to damage the resistor. The exact method is up to them, but since this issue has presumably been solved satisfactorily by others, I'm sure they can figure something out. There probably are limits to what the hardware can accomplish and we'd have to live with those.
-
if you connect a signal greater than approx 7V DC or ACrms to that channel, you will burn that resistor and thus damage the oscilloscope, with an expensive repair as a result. I have seen quite some broken scopes for this very reason.
And since this is the "Bugs / Missing Features / Feature Requests thread, I'd call again for Siglent to 'fix' this by monitoring and automatically disconnecting the 50R input when the signal level gets too high.
Define 'too high'. You can't just add a comparator or so that looks at the voltage level. It would need a circuit that monitors power dissipation over time instead of just a voltage level. At some point I've fed pulses into a DSO for which I needed the 20V/div range in 50 OHm mode in order for the signal to fit on the screen vertically.
This is one important point.
Now in some Siglent models what have internal 50ohm load resistor before normal Hi-Z amplifier/attenuator, display vertical sensitivity is limited to max 1V/div. It do not protect anything but limits usability strongly. If it "protect" something, it only happen in human (user) mind but nothing inside oscilloscope - this "protection" effect I do not believe so much.
After 50ohm parallel load resistor there is nothing to protect but just exactly normal oscilloscope 1Mohm /xx pF input.
So this 50ohm load resistor(s) is component what is first in circuit and important to protect (of course also other things if want dive more deep to these things)
SDS models what have internal 50 ohm and what can also set for DC50 ohm or AC50 ohm (not all models where is 50ohm input available) need note that DC connected 50ohm load is before DC block. DC block (AC coupling) is there in 1Mohm input circuit after 50 ohm load. So 50ohm input is DC coupled to GND, independent of AC or DC selection, if AC selection is available.
If think this 50 ohm load and signal what it can handle it also good to look some common basics
https://www.vishay.com/docs/48516/_ms9702509-2003-vishaychecklistpulseload.pdf (https://www.vishay.com/docs/48516/_ms9702509-2003-vishaychecklistpulseload.pdf)
It also depends highly about what resistors there are used and also what kind of drift we can accept in long time use or even due to single overload peak (Also resistors manufacturing quality and also front end PCB thermal design are important factors).
But it is extremely clear it do not fail if I have just one simple example:
24V positive pulses. Pulse width is 50ns and whole cycle is 5us (200kHz 50ns pulses from 0 to 24V)
Cycle power 5000ns, and and long time average is 0.115W
Peak power(50ns) is 11.5W
Peak V is 24V
Peak I is 480mA
And now I think what ever resistor there is used... it do not break with this.
I believe it last well and without even long time meaningful drift or damage risk in practical user cases.
But user can not look this simple pulse with SDS oscilloscope using internal 50ohm... displayed full vertical is 8V with 1V/div.
This limit do not protect any single thing but rejects usability. It only torture users.
Also can calculate with more extreme cases...
But also then need be careful, user can not know this 50ohm load resistor type, thermal dynamics and failure/permanet drift characteristics.
Naturally one good solution is external direct feed thru or attenuating terminator what can handle more power and if fails no need repair scope and with it, full V/div range can use.
-
Naturally one good solution is external direct feed thru or attenuating terminator what can handle more power and if fails no need repair scope and with it, full V/div range can use.
That´s what we at work are doing, at least after the third expemsive repair because of the blowing internal resistor. 8)
We do this, when we KNOW it could be critical and/or when we DON´T know it could be critical.. ;)
-
But user can not look this simple pulse with SDS oscilloscope using internal 50ohm... displayed full vertical is 8V with 1V/div.
This limit do not protect any single thing but rejects usability. It only torture users.
Since the option of an external 50R feed-through is readily available, any protection system does not have to be overly complicated nor accommodative of all use cases, even reasonable ones. They could simply leave the 1V/div limitation along with a monitor that disengages the 50R resistor if any portion of the peak exceeds 8V. If the user needs to measure some taller pulses, the external terminator is used. As for the AC50R mode, I hadn't considered that--and unfortunately that appears to me to make the problem not fully solvable in software. I would recommend having an option in the utility menu to disable that mode, and also to have a warning come up whenever you engage it. AC-coupled 50R doesn't seem all that useful to me.
-
But user can not look this simple pulse with SDS oscilloscope using internal 50ohm... displayed full vertical is 8V with 1V/div.
This limit do not protect any single thing but rejects usability. It only torture users.
Since the option of an external 50R feed-through is readily available, any protection system does not have to be overly complicated nor accommodative of all use cases, even reasonable ones. They could simply leave the 1V/div limitation along with a monitor that disengages the 50R resistor if any portion of the peak exceeds 8V. If the user needs to measure some taller pulses, the external terminator is used. As for the AC50R mode, I hadn't considered that--and unfortunately that appears to me to make the problem not fully solvable in software. I would recommend having an option in the utility menu to disable that mode, and also to have a warning come up whenever you engage it. AC-coupled 50R doesn't seem all that useful to me.
But my old real workhorse Tek 2465A DM/CT can handle these bit higher short pulses just hands down without any single problem using 50ohm inputs and if there is overload it nicely turn 50ohm off, no drama, no difficult design. Designed by hardcore well experienced professionals and there V/div setup range is not limited when 50ohm is selected. If there is single reason for limit it, they have done it.
But yes there is overload protection based to 50ohm load resistor temperature measurements what can protect from some mistakes what also professional users sometimes may do.
500mW power is not lot... just 27dBm. And with this Siglent 1V/div limit even this sinewave can not look and it is hardly clipping and producing lot of harmonics. And still it is in acceptable range in specifications. 22dBm is diplay vertical full range. (160mW)
I can not see any other reason for this limit but somehow warn user that signal may be too high for 50ohm. But it do not prevent anything. And also it is like indirect warning to user then when he meet this situation and start thinking... if he start thinking.
Speccially for models where is not hardware made any overload protection. Much better for this reminder to the user is simple short warning message on screen (in these some situations where warning is mostly like prevent possible accident, as example when scope boot with 50ohm or example when this current oscilloscope power on period 50ohm is first time selected) The user can acknowledge the reminder, for example, by waving hand or saying yes-yes unless he can wait for clock to take care of it.
-
But my old real workhorse Tek 2465A DM/CT can handle these bit higher short pulses just hands down without any single problem using 50ohm inputs and if there is overload it nicely turn 50ohm off, no drama, no difficult design. Designed by hardcore well experienced professionals and there V/div setup range is not limited when 50ohm is selected. If there is single reason for limit it, they have done it.
Yes, that's why I had hoped that protection would be included with the 50R input feature. But the Tek solution was implemented in (mostly) hardware as part of a very expensive instrument. The thrifting required to put out a scope with the features of the SDS2000X+ series at their price point probably rules out any such luxuries unless they can be implemented in software. Given the limited choices, I personally would prefer having to occasionally use an external terminator as opposed to occasionally damaging my scope in error. No need to lament the unavailability of a more elegant solution in budget gear.
-
The Tek 2465 has the 50 ohm termination resistor integrated on the input hybrid substrate (we've repaired these so know the hybrid design), it's very large and likely can dissipate a considerable amount of power.
Tek notes the input 50 ohm DC mode limit of 5VRMS. Also the Tek doesn't have an AC(50) mode I'm aware of (not on 2465), only DC(50) mode.
The AC(50) mode mentioned on the Siglent must place the 50 ohm termination in front of the AC coupling capacitor, if it were behind the coupling cap then the High Pass AC corner would suffer significantly, or the coupling capacitor would have to be much too large.
This raises an interesting situation because the 50 termination is DC coupled and present at the input even tho the input is set to AC coupling mode. One won't be "seeing" the DC on the scope display, but the input signal will still "see" the 50 ohm termination, so the potential for DUT or scope damage is ever present in AC(50) mode.
Tek's solution on the 2465 was to only offer DC(50) and not AC(50), likely for this very reason!!
Best,
-
The Tek 2465 has the 50 ohm termination resistor integrated on the input hybrid substrate (we've repaired these so know the hybrid design), it's very large and likely can dissipate a considerable amount of power.
Tek notes the input 50 ohm DC mode limit of 5VRMS. Also the Tek doesn't have an AC(50) mode I'm aware of (not on 2465), only DC(50) mode.
The AC(50) mode mentioned on the Siglent must place the 50 ohm termination in front of the AC coupling capacitor, if it were behind the coupling cap then the High Pass AC corner would suffer significantly, or the coupling capacitor would have to be much too large.
This raises an interesting situation because the 50 termination is DC coupled and present at the input even tho the input is set to AC coupling mode. One won't be "seeing" the DC on the scope display, but the input signal will still "see" the 50 ohm termination, so the potential for DUT or scope damage is ever present in AC(50) mode.
Tek's solution on the 2465 was to only offer DC(50) and not AC(50), likely for this very reason!!
Best,
To everything you said: Yes.
Siglent many models what have internal 50ohm support only DC 50ohm.
In some models there can select also AC after DC coupled 50ohm. (on screen there read just AC50 and not warning that load is DC coupled)
Example BodePlot set automatically 50ohm to AC mode so it block DC component which could disturb Automatic Level Control (ALC) what is important to maximize BP dynamic range (but also this max dynamic range (if 50 ohm is in use) is limited some dB's with this unnecessary 1V/div limit).
-
50 ohms inputs are only available in DC-coupled mode for the SDS6000A.
Just like the 1V/div limit, this is of course no true protection, but it will remind the operator to be extremely cautious.
It might be a good idea to restrict also the 2000 and 5000 series DSOs to DC-coupling in 50 ohms mode - and this would be an easy firmware fix, but this also means to violate the existing specifications. Therefore it will only be done for future devices.
Speaking of input coupling: like any modern design, AC-coupling does not change the input path significantly. The thinking of a capacitor in series to the input is outdated for these designs. Try to measure the DC-input resistance with a DMM in AC coupled mode. For those too lazy to do that: it is still 1 meg ohm.
It is very true that there is no cheap solution for a 50 ohms input protection, especially not in high bandwidth instruments. Quite obviously, the existing hardware cannot measure the input voltage. For example, how do you detect that the input exceeds 5 Vrms when using e.g. 10 mV/div vertical gain, where the ADC is overdriven at 100mVpp already? So we would need extra hardware for that, which not only costs money, but also leads to the next problem...
Those who use 50 ohms mode regularly, will most likely be concerned about the input return loss and accordingly the standing wave ratio (VSWR). By convention, it shall never exceed 1.5 over the full bandwidth. This cannot be accomplished by just using a relay to connect a termination resistor across the input without further measures. At least we also need to get rid of the (designed in) input capacitance. I suspect this might be one of the reasons, why we cannot use the (frequency compensated) attenuators in 50 ohms mode, hence the 1V/div limit has pure technical reasons as well. Any voltage detection circuit directly at the input, i.e. before the input buffer, will affect the input impedance and degrade instrument performance. As a consequence, this is only feasible if the bandwidth is not too high and money is no object. We simply cannot compare a highend scope of the good old days (with only 400 MHz bandwidth) to instruments that are significantly lower cost and/or higher bandwidth.
For the reasons given above, the cheap SDS2000X Plus of all things has no protection. The SDS2000X HD on the other hand, will have thermal monitoring of the termination resistors. This will not be an absolute protection, yet should be sufficient as long as you don't connect the instrument to high voltage high energy sources.
As we are at it: The solution to overcome the 1V/div limit is of course the use of external attenuators. Anyone dealing with 50 ohms systems should have a rich assortment of these.
An external pass-through terminator on the other hand, can never be a substitute for the internal 50 ohms termination. Because the input capacitance is still present, external trough-terminators are only acceptable up to about 100 MHz.
-
It might be a good idea to restrict also the 2000 and 5000 series DSOs to DC-coupling in 50 ohms mode - and this would be an easy firmware fix, but this also means to violate the existing specifications. Therefore it will only be done for future devices.
It is very true that there is no cheap solution for a 50 ohms input protection, especially not in high bandwidth instruments. Quite obviously, the existing hardware cannot measure the input voltage. For example, how do you detect that the input exceeds 5 Vrms when using e.g. 10 mV/div vertical gain, where the ADC is overdriven at 100mVpp already? So we would need extra hardware for that, which not only costs money, but also leads to the next problem...
I would only expect a fix improvement that is achievable thru firmware with existing hardware. All of your issues are resolved if you just allow for two mode settings in the utility menu--SAFE and EXPERT or whatever. In the SAFE mode the 50R terminator disconnects whenever the input is overloaded (even at the lower ranges) and AC50R is disabled. EXPERT just gives you a warning and leaves you to fry your scope at will. Or maybe even have a LOCK setting where you need a password to access the 50R menu...
-
I would only expect a fix improvement that is achievable thru firmware with existing hardware. All of your issues are resolved if you just allow for two mode settings in the utility menu--SAFE and EXPERT or whatever. In the SAFE mode the 50R terminator disconnects whenever the input is overloaded (even at the lower ranges) and AC50R is disabled. EXPERT just gives you a warning and leaves you to fry your scope at will. Or maybe even have a LOCK setting where you need a password to access the 50R menu...
Whenever the protection kicks in, the scope would exit the 50 ohms mode and revert back to 1 meg input impedance. By this, the amplitude gets doubled - if the frequency is low enough that transmission line effects don't come into play yet. Now adjusting for the correct vertical gain (which would usually result in an amplitude of more than 50% of the screen height in order to maximise dynamic range) could be very confusing. Of course, operators would have to get used to a workflow that starts at the lowest sensitivity (= 1 V/div) and only then connect the signal and increase sensitivity as required.
All in all, I'm predicting that this would not work. The average users would complain to no end, until they either RTFM or get advice in a (this?) forum, so they're finally able to turn this "foolproof mode" off. At the other hand, even though it's only "programmed hardware" (FPGA), this protection still requires resources, which the SDS2000x Plus might not even have - after all this model doesn't even have the otherwise indispensable "DVM". So it's certainly not very attractive to waste resources on something that in the end nobody will use anyway - because the way you have suggested (and the only feasible) is just too much hassle for the operator.
-
So it's certainly not very attractive to waste resources on something that in the end nobody will use anyway - because the way you have suggested (and the only feasible) is just too much hassle for the operator.
Of course I thoroughly disagree! Its true that most people wouldn't 'use' it. The SAFE mode would be the default and in the vast majority of circumstances, you'd never know the feature existed. Some people might get slightly annoyed that it trips out of 50R if they exceed some low vertical limit---like the 10mV/div range--but they'd figure it out. And dialing down from a higher range is always a good idea anyway. What the SAFE mode would best prevent is people fat-fingering the 50R button while they are looking at PSU ripple on a 24V supply using AC coupling with their 1X probe.
As far as it being a hassle, it's a pretty complex scope and the UI is, well, OK. I doubt what I've proposed would really be a big deal either way.
-
Hi,
Today I check the "50Ohm behaviour" of an much more expensive scope, in this case a WR9054 from lecroy, appx 12 times more expensive than sds2k+.
First, it got only DC50, not AC50.
Second, when turning to 50 ohms, voltage per division will be limited to 1V/div.
Third, carefully increased the (DC-)voltage above the mentioned maximum of 5V, nothing will happen, increased to 7.5Vdc.
No warning, no switchback to 1M.
FYI.
Martin
-
Today I check the "50Ohm behaviour" of an much more expensive scope, in this case a WR9054 from lecroy, appx 12 times more expensive than sds2k+.
First, it got only DC50, not AC50.
Second, when turning to 50 ohms, voltage per division will be limited to 1V/div.
Third, carefully increased the (DC-)voltage above the mentioned maximum of 5V, nothing will happen, increased to 7.5Vdc.
No warning, no switchback to 1M.
I'm pretty sure, the LeCroy will have some thermal protection too. For this, you need to take into account that the internal termination actually can take a little more than the 500 mW suggested by the front panel message (5 Vrms). It will most likely be at least 1W, so there is some headroom for the overload protection. If you run the scope with 7.5V DC-input for a long time, the thermal protection should eventually kick in, but you might need an even higher voltage to achieve this.
-
The instantaneous power in the resistor is V2/R. Would you guys be ok to lose a maths channel (ie use existing resources) to track this? Instead of having an artificial/compromise limit on the Y axis, have a limit on the time axis instead, eg 20ms total sample time? Then just put a small amount of logic in to automatically trip out if the mean V2 on the input BNC exceeds a preset value. You could also have a Vpeak threshold value if you wanted to, and trip on that too, just like a "real" circuit breaker.
While I appreciate that its not always possible to put comprehensive protection into high end instruments, because it can mess up the readings, it seems to me that having protection 'coverage' in a general purpose bench oscilloscope is something that's worth spending effort on. With Siglent philosophy of putting as much function as possible while being thrifty with the hardware costs, the software approach would seem to be a good, achievable match.
In a lab setting, especially in a training/university lab I imagine it is reassuring for the demonstrator to be able to say -- "don't worry about experimenting with the controls, you can't break anything".
-
The instantaneous power in the resistor is V2/R. Would you guys be ok to lose a maths channel (ie use existing resources) to track this? Instead of having an artificial/compromise limit on the Y axis, have a limit on the time axis instead, eg 20ms total sample time? Then just put a small amount of logic in to automatically trip out if the mean V2 on the input BNC exceeds a preset value. You could also have a Vpeak threshold value if you wanted to, and trip on that too, just like a "real" circuit breaker.
While I appreciate that its not always possible to put comprehensive protection into high end instruments, because it can mess up the readings, it seems to me that having protection 'coverage' in a general purpose bench oscilloscope is something that's worth spending effort on. With Siglent philosophy of putting as much function as possible while being thrifty with the hardware costs, the software approach would seem to be a good, achievable match.
In a lab setting, especially in a training/university lab I imagine it is reassuring for the demonstrator to be able to say -- "don't worry about experimenting with the controls, you can't break anything".
If you put a channel in 1 mV/div, you overload ADC at 5mV. Software cutoff makes sense only if you are at highest range (1V/div) already and then ADC detects off scale.
Which might or not be the case.
Putting anything "comprehensive" into any device always ends up much harder and more expensive than people think.
Even 500Mhz (and this is 500MHz scope) is high enough for this not to be trivial.
Simple example: everybody speaks about protection circuit. But you actually need 4, one for each channel. And then a connection back to CPU so it can know it scrambled. etc etc..
That is a mainboard redesign (provided current design has resources, that are not planned for other, more pressing stuff for the target users). And full characterisation. And you end up with a new product. With new name..etc... Then you have to support both...
And respectfully, "" In a lab setting, especially in a training/university lab I imagine it is reassuring for the demonstrator to be able to say -- "don't worry about experimenting with the controls, you can't break anything"." is exactly the wrong thing to say to university students. That is kindergarten "positive reinforcement" attitude. That is preschool stuff. In university, they better be taught to know exactly what will happen if they turn that knob... They are not playing with legos, they are supposed to be engineers and scientists... They came to university to learn to think and understand...Not randomly try stuff until it either works or explodes...
-
And respectfully, "" In a lab setting, especially in a training/university lab I imagine it is reassuring for the demonstrator to be able to say -- "don't worry about experimenting with the controls, you can't break anything"." is exactly the wrong thing to say to university students. That is kindergarten "positive reinforcement" attitude. That is preschool stuff. In university, they better be taught to know exactly what will happen if they turn that knob... They are not playing with legos, they are supposed to be engineers and scientists... They came to university to learn to think and understand...Not randomly try stuff until it either works or explodes...
:clap:
-
They are not playing with legos, they are supposed to be engineers and scientists... They came to university to learn to think and understand...Not randomly try stuff until it either works or explodes...
Unless they are training for Quality Assurance!
I expect every life critical system to be tested in all work/explode scenario as practical possible.
-
They are not playing with legos, they are supposed to be engineers and scientists... They came to university to learn to think and understand...Not randomly try stuff until it either works or explodes...
Unless they are training for Quality Assurance!
I expect every life critical system to be tested in all work/explode scenario as practical possible.
And that is almost as fun a job as working with explosives.... :-DD
But it is even more dependent on predicting all outcomes up front...
In which case they designed scenario, simulated and calculated outcomes, and then made real life experiment where thing exploded exactly where calculation predicted. If it didn't, something was wrong and go back to the drawing board, until model aligns with real life testing. Only then we can have good certainty that product is safe by design....
-
They are not playing with legos, they are supposed to be engineers and scientists... They came to university to learn to think and understand...Not randomly try stuff until it either works or explodes...
We all make mistakes and errant button-presses. Given the option, I'd rather have a device that doesn't blow up with one errant touch of the screen during an otherwise perfectly normal operation (PSU ripple on AC1M, bump the 50R button and poof!) It would have been easier to implement this all from the beginning, but the whole bang-for-buck thrifting process yielded what we have and any implementation now would necessarily be a bit clunky. But I think it is perfectly doable, and for those users that don't like my SAFE mode, they can disable it and make their scope fry-able again. If tripping the protection on the 1mV/div range is so terrible, perhaps they could introduce continuous autoranging, or at at least auto-UP-ranging when 50R is selected.
However, I doubt we'll see this anytime soon. I'm sure it isn't a priority and they will be putting their efforts elsewhere. IMO the least they could do would be to put options in the setup menu to disable the AC50R mode and perhaps the 50R as well so a user can proactively choose to protect themselves from their own thumbs. So be careful with the buttons!
-
If you run the scope with 7.5V DC-input for a long time, the thermal protection should eventually kick in, but you might need an even higher voltage to achieve this.
You might be right, because:
Caution: The maximum input voltage depends on the input used. Limits are displayed on the body
of the instrument. Whenever the voltage exceeds this limit, the coupling mode automatically
switches to GROUND. You then have to manually reset the coupling to its previous state. While the
unit does provide this protection, damage can still occur if extreme voltages are applied.
Probe
This state I haven´t reached.....Mhh...Should I try it..
-
.....
This state I haven´t reached.....Mhh...Should I try it..
Please don't... :scared:
Murphy never sleeps...
-
;D
There is something, that makes me a little bit confusing...
Either it was on the HDO6034A or on the WR9054 (although they got the same UI), but I could swear, one of them showed once a message while booting up, that there were a 50ohm coupling activated last time shutdown and gave me the try to change it before booting was complete.
But I couldn´t reproduce it in the last two days.
Maybe I´ve dreamed this..
-
Mod + Burst
Is this ever going to happen?
-
It takes some time to understand what you mean... ;)
The siglent beta-testers here may corect me, but after 2yrs I don´t think they will change anything on the integrated awg.
-
Yeah, probably not. Attempting to EasywaveX to do the same thing but the spectrum looks terrible.
-
Maybe a bug:
While playing with the differential function for some reasons (see "original" thread), I´ve found out that the universal knob won´t function when you want to change Dx although it´s activating.
You can change Dx by using the virtual keypad.
When you did this, then you can use the universal knob to change the value back - one time....
Martin
-
Wanted features:
- Display split mode not only for FFT, it would be nice to have it for all math functions avaible.
- Additional print mode black&white.
Wanted "Polishes":
- Axis scaling : 4 digits after the comma is not useful and "steals" visibility. Better: Max. 1 digit after the comma.
- Channel colours are free selectable - Excellent. A little bit more nice would be when you can select between colours on screen and on print like lecroy scopes.
Example, channel 1 is yellow on the screen but will be "printed" in red or any other colour selected before.
-
Hi there,
Not a bug, more a little wish:
We got several sds2104X+ at work and they will be daily used under "real conditions" (Pic shows scope while short circuit measuring)...
From time to time I go and ask the colleagues if they are satisfied with them.
They are....Mostly with all. 8)
Here a little wish from the last asking.
On new lecroy scopes we hardly miss the free moveable measuring gate over the whole screen* - The siglent got it so all are happy.
To measure loadsteps on our inverters, we adjust the gate to say 2.5ms (for one 400Hz cycle) then turn the gate to the loadstep, measure what´s in this gate.
Then move the gate to the next cycle after loadstep, measure, move to the next and so on.
"Problem":
To move the gate you use the universal knob, so far so good.
But you must always go to the measure menu, go the Gate A-B, then universal knob is active and you can move - Otherwise the knob adjust the intensity..
For every measure-step we must repeat this instead having the universal-knob for this as long as we need it.
A more or less free alignment for this knob would be nice...(Must say, don´t looked at the manual after colleague asked me)
Then:
The measured value represent this what´s in the defined gate - As expected.
BUT: While you move the gate, the value won´t change - It changes only when you stop and wait a little bit.
Knowing the opposite from lecroy scopes that is uncommon, therefore the wish is to have actual changing value displaying.
Thanks in advance.. :)
Martin
Edit: *) On elder lecroy models, you can define a gate and inbetween this gate it measures.
Today lecroys got it too, but not the "tracking function" of the elder ones, where you can move the before defined gate over the screen..
-
So the SDS1204X-E has "Sample Logging" and "Measure Logging" built in, and NTP... I wonder if the 2000X Plus will ever get these ?
I found a small bug, there is a timezone setting option but it doesn't work ? I cannot get it to bring up any timezones.
-
Hi,
Actually there is a "Timezone bug" present, I guess it´s "valid" for all touchscreen-models (2k+, 2k HD, 5k+, 6k A) because of more or less the same software.
-
So the SDS1204X-E has "Sample Logging" and "Measure Logging" built in, and NTP... I wonder if the 2000X Plus will ever get these ?
I found a small bug, there is a timezone setting option but it doesn't work ? I cannot get it to bring up any timezones.
Email sent.
-
So the SDS1204X-E has "Sample Logging" and "Measure Logging" built in, and NTP... I wonder if the 2000X Plus will ever get these ?
I found a small bug, there is a timezone setting option but it doesn't work ? I cannot get it to bring up any timezones.
Email sent.
If it was about sample/measure logging and/or ntp, please send it to me too :)
-
Bug present in : 1.3.9R12
Bug Solved in in : 1.5.2R1 - Thank you Siglent :-+
Scope now renews on "half-time of lease", just as the "doctor (RFC) ordered"
***** TLDR *****
I just finished the "Options" on my new SDS2104X Plus SDS2504X Plus.
I haven't upgraded fw to latest yet, so i'm still on 1.3.9R12
I'm noticing that the above version have an "often occuring bug" on embedded systems...
The Scope DHCP Client does not renew the DHCP lease, on lease timeout.
Many users prob. won't detect that, as the scope just keeps using the DHCP IP it was "offered" when booting.
But in my setup i use my linux server with the ISC-DHCP server & the bind9 dns server setup for "dynamic dns add of DHCP clients".
The setup for my "measure vlan" is DHCP with a 1800s (30 min) lease time, and since the scope doesn't send a DHCP identifier i have just added one into my DHCP config file.
I have chosen : sds2104x
This means that when the scope accepts the DHCP offer, the linux DHCP server will automatically inform the DNS server that it should create a new "host entry" with the above name, and a TTL (lifetime) of 1800 sec.
I noticed the error, when i suddenly couldn't resolve the dns name anymore (more than 30 min since boot), and did a bit of DHCP/DNS log checkking.
Yepp ....
The scope does not respect my 1800s lease time, and for now i have only seen it request a DHCP address on boot, not ever seen a DHCP renew.
Here's a DHCP/DNS log snip from my linux server.
Note the :
Add new forward map, where it adds the scope dns name
And that exactly 30 min later the DHCP server "purges" the dns name , since it hasn't seen a new DHCP transaction from the scope.
Nov 19 12:32:00 frodo dhcpd[23534]: DHCPOFFER on xx.yy.70.130 to <Scope-MAC> via xx.yy.70.1
Nov 19 12:32:00 frodo dhcpd[23534]: DHCPREQUEST for xx.yy.70.130 (aa.bb.117.101) from <Scope-MAC> via xx.yy.70.1
Nov 19 12:32:00 frodo dhcpd[23534]: DHCPACK on xx.yy.70.130 to <Scope-MAC> via xx.yy.70.1
Nov 19 12:32:00 frodo dhcpd[23534]: Added new forward map from sds2104x.mydomain.org. to xx.yy.70.130
Nov 19 12:32:10 frodo dhcpd[23534]: reuse_lease: lease age 10 (secs) under 25% threshold, reply with unaltered, existing lease for xx.yy.70.130
Nov 19 12:32:10 frodo dhcpd[23534]: DHCPOFFER on xx.yy.70.130 to <Scope-MAC> via xx.yy.70.1
Nov 19 12:32:11 frodo dhcpd[23534]: reuse_lease: lease age 11 (secs) under 25% threshold, reply with unaltered, existing lease for xx.yy.70.130
Nov 19 12:32:11 frodo dhcpd[23534]: DHCPREQUEST for xx.yy.70.130 (aa.bb.117.101) from <Scope-MAC> via xx.yy.70.1
Nov 19 12:32:11 frodo dhcpd[23534]: DHCPACK on xx.yy.70.130 to <Scope-MAC> via xx.yy.70.1
Nov 19 13:02:00 frodo dhcpd[23534]: Removed forward map from sds2104x.mydomain.org. to xx.yy.70.130
I have been looking in the newer firmware 1.5.2R1 release notes , and nothing is mentioned about a DHCP Client fix.
So I suppose it's still there in the latest fw. Will upgrade soon, and will test again.
But i think it ought to be reported here.
/Bingo
-
I just finished the "Options" on my new SDS2104X Plus SDS2504X Plus.
I haven't upgraded fw to latest yet, so i'm still on 1.3.9R12
Why oh why are ppl so reluctant to upgrade FW ? :-//
Please just do it ! :horse:
-
I just finished the "Options" on my new SDS2104X Plus SDS2504X Plus.
I haven't upgraded fw to latest yet, so i'm still on 1.3.9R12
Why oh why are ppl so reluctant to upgrade FW ? :-//
Please just do it ! :horse:
For my part :
1:
I wanted to finish doing the "Options" on a release that i knew was "working".
I still remember Rigol's upgrade that was "disabling" the "options"
2:
I don't have a stock of these, and if Sh... hits the F.. , i have to send an "already BW upgraded" scope back to Batronix.
I have to take a deep breath, before doing it.....
Well:
Now that i have done all the options, i'll prob. upgrade it this afternoon.
/Bingo
-
I still remember Rigol's upgrade that was "disabling" the "options"
/Bingo
Totally irrelevant, yours is a Siglent and they don't do that shit.
-
DHCP Renewal Bug Solved in in : 1.5.2R1 - Thank you Siglent :-+
Scope now renews on "half-time of lease", just as the "doctor (RFC) ordered"
/Bingo
-
Idea for a feature request, would be nice if the FFT horizontal axis can be displayed in log scale, would make the already powerful FFT capability even more useful imo.
I second to the idea. The logarithmic frequency scale helps investigating low frequency signal and filter behavior a lot.
-
- Bode Plot:
Showing the waveform at the same time
- FFT:
Logarithmic frequency scale
- Math:
HP/LP/BP Filter
- Non-segmented acquition
Just duplicate the zoom mode and turn the waveform preview into an indication strip.
The above are in the order of importance to myself.
Regarding the non-segmented acquition (zoom out capbility). I think current current segmented design may have it's perks. It just doesn't go with my habits
of previous HP scopes. But I still confused about what's the difference between sequence mode and default non-sequence mode.
-
Not sure if this has been reported in this thread yet, but when setting up network storage the UI dialog asks for "//server/share". It should be "//server_ip/share" as it will not resolve the server name and entering the IP address is required.
It's a minor detail but since setting up network storage is not covered in the manual it can be a small source of frustration.
-
- Bode Plot:
Showing the waveform at the same time
But I still confused about what's the difference between sequence mode and default non-sequence mode.
On 2000HD if you go into display, there is a option to choose time domain display in Bode mode..
Difference between segment and history mode: History mode is transparent. In segmented mode scope doesn't display acquisitions on screen until it is done with all of the segments. Because of that it can retrigger really fast..
-
Greetings to all!
I am very happy with my new SDS2104X but my oscilloscope shows some DC offset (~40 - 70uV) on all 4 channels every time after I turn it on. No probes connected, all channels are set to maximum sensitivity (500uV) and set as internally grounded. Ambient temperature ~+20C - +22C. I tried to run internal self-calibration without success...
Also should mention, the DC offset tends to drift and decrease to 15-20uV after 15-20 minutes of work.
Did not able to find information about that, this is very disturbing to me :palm:... Could someone check that on his own device? Please confirm if it is common behavior of SDS2000X Plus or should I treat that as some defect. I greatly appreciate any help!
-
Hi,
You can´t expect absolute zero....
There´s a "naturally" (thermal) drift given, all scopes got it.
As long as it in the specs*, there´s no need to worry about this.
DC offset (~40 - 70uV)
To get an idea what this means, 1mV are 0.001V.
1µV are 0.000001V or in your "worst case" 0.00007V....
Imagine what this means in practice when you´re looking at signal of e.g. 10mV...
*):
Offset accuracy ±(1.5%*offset+1.5%*full scale+1 mV)
-
Greetings to all!
I am very happy with my new SDS2104X but my oscilloscope shows some DC offset (~40 - 70uV) on all 4 channels every time after I turn it on. No probes connected, all channels are set to maximum sensitivity (500uV) and set as internally grounded. Ambient temperature ~+20C - +22C. I tried to run internal self-calibration without success...
Also should mention, the DC offset tends to drift and decrease to 15-20uV after 15-20 minutes of work.
Did not able to find information about that, this is very disturbing to me :palm:... Could someone check that on his own device? Please confirm if it is common behavior of SDS2000X Plus or should I treat that as some defect. I greatly appreciate any help!
Nothing to worry about. Mine is a bit worse and it does nor bother me a bit.
-
Greetings to all!
I am very happy with my new SDS2104X but my oscilloscope shows some DC offset (~40 - 70uV) on all 4 channels every time after I turn it on. No probes connected, all channels are set to maximum sensitivity (500uV) and set as internally grounded. Ambient temperature ~+20C - +22C. I tried to run internal self-calibration without success...
Also should mention, the DC offset tends to drift and decrease to 15-20uV after 15-20 minutes of work.
Did not able to find information about that, this is very disturbing to me :palm:... Could someone check that on his own device? Please confirm if it is common behavior of SDS2000X Plus or should I treat that as some defect. I greatly appreciate any help!
So after instrument is properly warmed up you get 15-20 uv... And quite good. It is hard to design amplifiers and AD converters to go from DC to 500 MHz and be perfect.
Every now and then, a topic pops up where people complain about how long it takes to boot modern instruments.
All the while forgetting that every instrument needs to warm up for half an hour or more to get to work temperature inside for best accuracy.
-
I just finished the "Options" on my new SDS2104X Plus SDS2504X Plus.
I haven't upgraded fw to latest yet, so i'm still on 1.3.9R12
Why oh why are ppl so reluctant to upgrade FW ? :-//
Please just do it ! :horse:
I think this comment is a little inappropriate.
1.) It is obvious from bingo600's comments that his is a brand new instrument. After switching on a new expensive piece of equipment the first thing that you definitely not do is upgrading the firmware. First you play a bit to see if there are any problems with the specimen. Only after you gain a bit of confidence that everything's allright you upgrade. It looks to me he upgraded quicker than I'd have done.
2.) I guess people would upgrade more if Siglent wouldn't do such a crappy job maintaining their websites. My scope is still at v1.3.9R6, because that's what I believed up to today to be the latest version, after all, the Siglent website tells me so: https://www.siglent.eu/downloads (https://www.siglent.eu/downloads) Still find it hard to believe that they made me miss several releases because of sloppy website maintenance.
3.) You could have helped by announcing that a new signicant release is out, couldn't you. I mean, as an authorised distributor ...
-
Hi,
To 1): I´ll do it the opposite - First take the scope to the latest firmware, then checking if everything is working...Makes more sense.
To 2) : This site is a VENDORs site....
Here´s the siglent site:
https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds2000x-plus (https://www.siglenteu.com/service-and-support/firmware-software/digital-oscilloscopes/#sds2000x-plus)
With the latest firmware update for the Xplus....They do their job..
-
I just finished the "Options" on my new SDS2104X Plus SDS2504X Plus.
I haven't upgraded fw to latest yet, so i'm still on 1.3.9R12
Why oh why are ppl so reluctant to upgrade FW ? :-//
Please just do it ! :horse:
I think this comment is a little inappropriate.
You might and be wrong.
1.) It is obvious from bingo600's comments that his is a brand new instrument. After switching on a new expensive piece of equipment the first thing that you definitely not do is upgrading the firmware. First you play a bit to see if there are any problems with the specimen. Only after you gain a bit of confidence that everything's allright you upgrade. It looks to me he upgraded quicker than I'd have done.
We upgrade every instrument if a firmware update is available. As factory fresh instruments take 6-8 weeks to arrive it is not uncommon for a firmware update to be released while they are in transit.
2.) I guess people would upgrade more if Siglent wouldn't do such a crappy job maintaining their websites. My scope is still at v1.3.9R6, because that's what I believed up to today to be the latest version, after all, the Siglent website tells me so: https://www.siglent.eu/downloads (https://www.siglent.eu/downloads) Still find it hard to believe that they made me miss several releases because of sloppy website maintenance.
Siglent has no control of the quality of JR Special Electronics website, none.
Whereas the official Siglent EU website is largely maintained by HQ:
https://www.siglenteu.com/ (https://www.siglenteu.com/)
This situation arose before Siglent opened their Germany branch and has persisted since to catch many less observant people ever since. Siglent EU and NA websites are nearly identical except for pricing.
3.) You could have helped by announcing that a new signicant release is out, couldn't you. I mean, as an authorised distributor ...
I do many but as I'm not the only Siglent agent here others sometimes beat me to the punch, even members do sometimes as we rarely get early notice of a firmware release and spot it only with recent website checks or the rare sharing of a beta version shortly before release.
Eg. we got a 2kX+ V1.5.2 version shortly before public release of 2R1 that has the new time zone feature and its little bug so not to confuse our customers we instead install V1.5.2 prior to dispatch.
Anyways Slartibartfast, good to see you here and if there's anything else you need to report please do. :-+
-
I'm just using the LAN instrument control which is working fine in gerneral, but:
Device's screen saver and remote windows content on the PC are coupled. Should be independent:
The device's Screen Saver should not stop the data delivery to LAN instrument control.
(Maybe not a big deal, as one klick into the Windows window brings it back to life.)
But:
Klicking the Windows window on the PC reactivates the screen display of the device too.
Remote use with the device's screen staying black would be best imho.
-
I'm just using the LAN instrument control which is working fine in gerneral, but:
Device's screen saver and remote windows content on the PC are coupled. Should be independent:
The device's Screen Saver should not stop the data delivery to LAN instrument control.
(Maybe not a big deal, as one klick into the Windows window brings it back to life.)
But:
Klicking the Windows window on the PC reactivates the screen display of the device too.
Remote use with the device's screen staying black would be best imho.
Remote window is remote window. It is not a separate console session.
In perfect world all devices would have infinite resources.
Screen saver is something I never use. LCD does not need it like CRTs do..
Not saying you are saying something wrong, but no device is perfect.
Kesight 3000T that is much more expensive does the same.
-
I have another one:
I cannot find a way to export the FFT peak list into a file.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/?action=dlattach;attach=1660462)
-
- Bode Plot:
Showing the waveform at the same time
But I still confused about what's the difference between sequence mode and default non-sequence mode.
On 2000HD if you go into display, there is a option to choose time domain display in Bode mode..
Difference between segment and history mode: History mode is transparent. In segmented mode scope doesn't display acquisitions on screen until it is done with all of the segments. Because of that it can retrigger really fast..
Thanks for the information. 2000X plus has this option as well. I've tried showing the waveform and found it's helpful. But it seems different with Keysight's or RIGOL's. It shows much more cycles on the screen.
So history mode is Siglent's standard way of acquiring waveform. I feel it's not a drawback comparing with the zoom out capability. They just designed in different logic. On top of the standard history mode, we still can zoom out first and acquire the waveform we want.
-
- Bode Plot:
Showing the waveform at the same time
But I still confused about what's the difference between sequence mode and default non-sequence mode.
On 2000HD if you go into display, there is a option to choose time domain display in Bode mode..
Difference between segment and history mode: History mode is transparent. In segmented mode scope doesn't display acquisitions on screen until it is done with all of the segments. Because of that it can retrigger really fast..
Thanks for the information. 2000X plus has this option as well. I've tried showing the waveform and found it's helpful. But it seems different with Keysight's or RIGOL's. It shows much more cycles on the screen.
So history mode is Siglent's standard way of acquiring waveform. I feel it's not a drawback comparing with the zoom out capability. They just designed in different logic. On top of the standard history mode, we still can zoom out first and acquire the waveform we want.
I'm glad I could help. And also, thank you for understanding what I (and quite a few of us) are trying to explain: it is different. And has its own benefits when used properly.
-
Adding the wish of having a THD in percent to the wanted features of the HD:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg4583812/#msg4583812 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg4583812/#msg4583812)
Because they got the same software, I post it here too.
-
Hi,
To 1): I´ll do it the opposite - First take the scope to the latest firmware, then checking if everything is working...Makes more sense.
Ich beg to differ, because of bitter experience. Some vendors rejecting my claim of defect on arrival by insinuating that I did something wrong during the update, like cutting power too early, or whatever.
I will not give any vendor the same excuse again, even if only a small minority would (mis)use it. The pre-installed firmware must be able to at least demonstrate that all basic hardware functions work correctly (otherwise it would mean I'm treated as an unpaid beta tester). Only after it has done so it is time to replace it by the latest version.
To 2) : This site is a VENDORs site....
As I have noticed. Eventually.
It is normal behaviour for any manufacturer to absolutely ensure that no website it does not have control over uses the brand name, the particular style of writing, and the logo, in a way that allows a customer to mistake the site for the manufacturer's site. This is called trademark enforcement. It is a far too great risk for the brand's reputation to be negligent here. If you ask why, then just look at my case: I might not have found out, and then much later come to the conclusion that Siglent does not care about firmware bugs and never fixes them. Could be even worse: if that vendor does not react properly to customer complaints, Siglent will be blamed.
This particular vendor uses the Siglent brand exactly the same way as Siglent does.
With the latest firmware update for the Xplus....They do their job..
Regarding firmware, it certainly looks so.
-
1.) It is obvious from bingo600's comments that his is a brand new instrument. After switching on a new expensive piece of equipment the first thing that you definitely not do is upgrading the firmware. First you play a bit to see if there are any problems with the specimen. Only after you gain a bit of confidence that everything's allright you upgrade. It looks to me he upgraded quicker than I'd have done.
We upgrade every instrument if a firmware update is available. As factory fresh instruments take 6-8 weeks to arrive it is not uncommon for a firmware update to be released while they are in transit.
I'm aware of that, but I fail to see what that has to do with your exclamation "Why oh why are ppl so reluctant to upgrade FW ? :-//". As I understand it you critized bingo600's behaviour of testing the device before upgrading. A behaviour I find absolutely reasonable.
2.) I guess people would upgrade more if Siglent wouldn't do such a crappy job maintaining their websites. My scope is still at v1.3.9R6, because that's what I believed up to today to be the latest version, after all, the Siglent website tells me so: https://www.siglent.eu/downloads (https://www.siglent.eu/downloads) Still find it hard to believe that they made me miss several releases because of sloppy website maintenance.
Siglent has no control of the quality of JR Special Electronics website, none.
That is not true. They could threaten a lawsuit for using the Siglent brand in an unapproved, misleading manner. In fact, the WTO even requires that action, lest they risk loosing protection of their brand.
Anyways Slartibartfast, good to see you here and if there's anything else you need to report please do. :-+
Thanks. I was about to report my finding that CIFS access only works with SMBv1, a fact I found ridiculous as this protocol version is infamous for more than half a decade to have gaping security holes. Then I found it amusing that not only had it been reported before (which I had anticipated of course), but somebody had found another security hole in the GUI, exploiting which enables activating SMBv3.
So, I've been reading here for quite a while, and also posting in the LA-hardware hack thread. The information available there allowed me to build LA probes with some personal improvements. I'm very happy with my SDS2104X+ so far, and while before purchasing this device last year I was barely aware of the brand, for future purchases Siglent devices will be amongst the first for consideration.
-
2.) I guess people would upgrade more if Siglent wouldn't do such a crappy job maintaining their websites. My scope is still at v1.3.9R6, because that's what I believed up to today to be the latest version, after all, the Siglent website tells me so: https://www.siglent.eu/downloads (https://www.siglent.eu/downloads) Still find it hard to believe that they made me miss several releases because of sloppy website maintenance.
Siglent has no control of the quality of JR Special Electronics website, none.
That is not true. They could threaten a lawsuit for using the Siglent brand in an unapproved, misleading manner. In fact, the WTO even requires that action, lest they risk loosing protection of their brand.
Actually JR Special Electronics as a Siglent reseller had this website URL well before Siglent established their Germany office. For them to insist JR Special Electronics forfeit their URL could be seen as bullying.
JR Special Electronics undeniably have first rights to their URL as they were using it many years before Siglent had a permanent presence in the EU.
Actually if this issue was to be addressed on order to reduce confusion both JR Special Electronics and Siglent EU should have some agreed notification on one another's websites pointing to the other.
-
2.) I guess people would upgrade more if Siglent wouldn't do such a crappy job maintaining their websites. My scope is still at v1.3.9R6, because that's what I believed up to today to be the latest version, after all, the Siglent website tells me so: https://www.siglent.eu/downloads (https://www.siglent.eu/downloads) Still find it hard to believe that they made me miss several releases because of sloppy website maintenance.
Siglent has no control of the quality of JR Special Electronics website, none.
That is not true. They could threaten a lawsuit for using the Siglent brand in an unapproved, misleading manner. In fact, the WTO even requires that action, lest they risk loosing protection of their brand.
Actually JR Special Electronics as a Siglent reseller had this website URL well before Siglent established their Germany office. For them to insist JR Special Electronics forfeit their URL could be seen as bullying.
JR Special Electronics undeniably have first rights to their URL as they were using it many years before Siglent had a permanent presence in the EU.
Maybe, but that is irrelevant when it comes to brands and trademarks. Somebody owning cocacola.[com|net|org|eu] would have to give it up if Coca Cola Company requests it. At some stage it seemed certain that people can own and keep a domain if that is based on their own personal name. There was a widely publicised lawsuit by the steel giant Krupp against a person with the same name owning krupp.de, having first rights. Still, the person had to give it up. You can call it lamentable, but it's reality, unfortunately.
If Siglent does not do anything here, then the brand "Siglent" will eventually become unprotected. That means anybody could sell crappy devices under the name Siglent. I'm not familiar with the conditions, though, like, when protection expires. IANAL.
-
Hi everyone,
just got a SDS2104X Plus and I'm really impressed by the quality of the scope for this price point.
One feature I really came to love with the Keysight 3000T X Series at work is annotations:
In combination with the touch screen, this a wonderfully efficient way to make self-explanatory screenshots for documentation purposes.
R&S has similar features on their RTM lineup.
I know you can give the channels a label, which is great, but describing the event that is displayed on a screenshot is really a great thing.
-
Interesting wish...
Me I always did the comments "afterwards" by editing the scopepic with e.g. microsoft paint.
Doing this directly could save some time, no doubt.
-
Hello, I'm seeing a problem on my SDS2104X Plus scope where if I have the zoom enabled and perform a single trigger operation, I get spurious traces displayed. It looks like the signal is written twice to the display, once correctly and then again with a different time offset. If I change the horizontal time-base, change the offset slightly, or any operation that causes the screen to refresh, the correct waveform is displayed. I've done a quick search of this topic, but I don't see it mentioned. I'm running the 1.3.9R6 firmware, but looking at the release notes for newer firmware, they don't mention this issue being fixed in any newer firmware.
In the attached jpegs, capture5 shows the display with extra data that shouldn't be there, and capture6 shows the display after tweaking the horizontal position knob.
Is this a known issue with 1.3.9R6?
-
Hello, I'm seeing a problem on my SDS2104X Plus scope where if I have the zoom enabled and perform a single trigger operation, I get spurious traces displayed.
Welcome to the forum.
I'm running the 1.3.9R6 firmware, but looking at the release notes for newer firmware, they don't mention this issue being fixed in any newer firmware.
:scared:
Really, are you that many firmware versions behind ?
Best you install the latest and recheck your issue and report back.
https://int.siglent.com/download/firmwares/?ProId=53
-
Really, are you that many firmware versions behind ?
Best you install the latest and recheck your issue and report back.
https://int.siglent.com/download/firmwares/?ProId=53
1.3.9R6 was only 12 months ago.
I upgraded to 1.5.2R2, and I don't see that behaviour anymore. But I do think I see another difference: auto gating of measurements when in zoom mode. I have a measurement setup on channel 3 to count the number of pulses. I don't have gating turned on, but when I zoomed in on the old firmware, the count only included the pulses in the zoomed view. If I zoomed out the pulse count would change to reflect the timespan of the zoomed view. On the current firmware, it now appears to calculate based on the entire capture regardless of the zoom view, and I have to go in and manually set the gate ranges and update it each time I zoom into a different section of the capture. In addition, I'm not sure where it's getting 2Hz from on the frequency display for f(C2) just below the "Siglent|Stop" status on the top bar. See attachement 1-5-2R2-pulse-measurement.jpg.
-
1.3.9R6 was only 12 months ago.
This is somekind of cute.. :D
You should always keep your scope up to date, there are many fixes in a new firmware mostly not mentioned.
In addition, I'm not sure where it's getting 2Hz from on the frequency display for f(C2) just below the "Siglent|Stop" status on the top bar.
More precisely <2Hz, this means it can´t measure the frequency.
-
3.141529
Is Ch2 the Clock ?
We see both your screenshots captured with a Stop, is that because the waveform is not stable ?
-
I upgraded to 1.5.2R2, and I don't see that behaviour anymore. But I do think I see another difference: auto gating of measurements when in zoom mode. I have a measurement setup on channel 3 to count the number of pulses. I don't have gating turned on, but when I zoomed in on the old firmware, the count only included the pulses in the zoomed view. If I zoomed out the pulse count would change to reflect the timespan of the zoomed view. On the current firmware, it now appears to calculate based on the entire capture regardless of the zoom view, and I have to go in and manually set the gate ranges and update it each time I zoom into a different section of the capture.
There is no such thing as auto gating and never has been.
You measure (count) the pulses in channel C2, the result does not change when you use the zoom indeed - and this is correct behavior.
If you want to count the pulses in the zoom window, then you have to specify the zoom trace Z2 as your measurement source.
In addition, I'm not sure where it's getting 2Hz from on the frequency display for f(C2) just below the "Siglent|Stop" status on the top bar. See attachement 1-5-2R2-pulse-measurement.jpg.
You're referring to the trigger frequency counter. At the time of the screenshot the scope received less than two trigger events per second and looking at your waveform, this seems plausible.
-
3.141529
Is Ch2 the Clock ?
We see both your screenshots captured with a Stop, is that because the waveform is not stable ?
I'm capturing debug signals from a USB/JTAG device I'm working on. I'm trying to improve the throughput of the JTAG device when uploading firmware to an ARM device I'm playing with. So no, the waveform isn't stable, it goes away when the firmware transfer finishes. I'm measuring when JTAG shift in/out is occurring (CH2) along with reading from/writing to the USB bulk endpoints (CH3,4). CH1 shows when a USB control message is processed.
-
3.141529
Is Ch2 the Clock ?
We see both your screenshots captured with a Stop, is that because the waveform is not stable ?
I'm capturing debug signals from a USB/JTAG device I'm working on. I'm trying to improve the throughput of the JTAG device when uploading firmware to an ARM device I'm playing with. So no, the waveform isn't stable, it goes away when the firmware transfer finishes. I'm measuring when JTAG shift in/out is occurring (CH2) along with reading from/writing to the USB bulk endpoints (CH3,4). CH1 shows when a USB control message is processed.
Have you tried adding some Holdoff to the trigger setting so to not have it rearm in the middle of a packet ?
-
There is no such thing as auto gating and never has been.
You measure (count) the pulses in channel C2, the result does not change when you use the zoom indeed - and this is correct behavior.
If you want to count the pulses in the zoom window, then you have to specify the zoom trace Z2 as your measurement source.
Thanks! I guess I had set that when I originally setup the scope a couple weeks ago, but I didn't remember I had done that. After the upgrade I had to clear all my settings, re-setup the measurements, and didn't set the measurement from the zoom trace. The newer UI now shows signal source as (C2/Z2), where the older UI didn't.
-
Have you tried adding some Holdoff to the trigger setting so to not have it rearm in the middle of a packet ?
No I haven't. Thank you for the suggestion, I could do that, but I'm happy capturing a packet train as a one-shot, and zooming into bits that interest me. This is what happens when you let software devs near hardware. ;D
-
No I haven't. Thank you for the suggestion, I could do that, but I'm happy capturing a packet train as a one-shot, and zooming into bits that interest me. This is what happens when you let software devs near hardware. ;D
This an opportunity to make yourself au fait with the process. Some day you'll need to use it and it may even reveal something to you for your current use.
Never pass up an opportunity to learn on the job.
-
XY mode ??
did anyone try to use XY mode on their SDS2204X ??
I find it very hard to use, it must trigger !! or use auto trig, store the two channels and then draw the stored in XY mode,
next trig the points from last dont align,.,
I really miss en old free running CRT scope for XY
is it not possible to make it so it simply draw in real time XY with out trig and store ?
-
XY mode ??
did anyone try to use XY mode on their SDS2204X ??
I find it very hard to use, it must trigger !! or use auto trig, store the two channels and then draw the stored in XY mode,
next trig the points from last dont align,.,
I really miss en old free running CRT scope for XY
is it not possible to make it so it simply draw in real time XY with out trig and store ?
Please see for further info/understanding:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2787208/#msg2787208 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-coming/msg2787208/#msg2787208)
-
thanks a lot that looks amazing, i am not able to recreate it,
or to figure out how to turn of a need for triggering,
i want live realtime XY, just like an old CRT scope, problem solved, i just repaired an old scope from the junkyard,
see a nice XY mode that works, only problem is it uses 275 watts
-
Is the only way to apply averaging to a waveform (to remove noise) by using the average feature in math?
-
On the SDS2000X, Average and Eres are math functions, while on the 2000HD and 5000X they are also present in the Acquisition menu.
-
XY mode ??
did anyone try to use XY mode on their SDS2204X ??
I find it very hard to use, it must trigger !! or use auto trig, store the two channels and then draw the stored in XY mode,
next trig the points from last dont align,.,
I really miss en old free running CRT scope for XY
is it not possible to make it so it simply draw in real time XY with out trig and store ?
It definitely is possible on the X+. The other day I enjoyed playing a bit with analog computer circuitry solving some chaotic system of differential equations at various speeds. I used X-Y mode on my SDS2104X+ to display the variables, basically pretty much the same way as I'd have used it on an analog scope. The trace is not as smooth but shows pixel artifacts of course.
I would have uploaded a short video clip showing the scope in X-Y mode displaying the signals from solving the Lorenz differential equation system. Seems Dave does not allow videos.
-
super, just upload the video to youtube or such, and then post a link
I still work with XY mode and vector stuff, i am now in the middle of restoring another analog scope
I hope is even better for this.
-
PLEASE PLEASE PLEASE add at least LP digital filter capability on the channels. I didn't realize how useful this has been until I purchased a scope that doesn't have it. I wasn't expecting that to be missing!
-
XY is working well (noise on the picure is coming from my probes). What is missing (for me) is a gated X Y Z as on the tDS3000 in order to have a nice constellation. and the possibiliy to have a pass/Fail in this mode.
-
Please, it is better to use .png instead of .jpg when you save images from oscilloscope. Also .png give quite small file size (in this kind of images)You see dramatic difference in image quality. You can select file type in oscilloscope menu.
-
It has probably been discussed, but I just noticed today that the mouse control over the web interface does not work if you have touch control turned off. In fact, you have no control a all because web control relies on a mouse..
It's also not mentioned in the manual that I can find.
Not a real problem unless you forgot and were then relying on that feature from a remote place and had your day ruined as a result.
Am I missing something or is that the way it was designed?
-
It's also not mentioned in the manual that I can find.
Make sense, I can´t see any reason why the scope shouldn´t be controlled via webinterface when touchscreen is deactivated.
Sounds like it is clearly a bug.
Want to check it on my HD "tomorrow"..
-
Has no one noticed the last "anomaly" I mentioned? Perhaps no one cares. :-//
Well, looks like I found another "anomaly". Have a look at the capture attached. Notice the counts on the statistics. For some really odd reason, the count on the fall time is twice the others even though they were all started at teh same time. :palm:
-
Has no one noticed the last "anomaly" I mentioned? Perhaps no one cares. :-//
Well, looks like I found another "anomaly". Have a look at the capture attached. Notice the counts on the statistics. For some really odd reason, the count on the fall time is twice the others even though they were all started at teh same time. :palm:
Not an anomaly.
Some measurements are performed once per screen, some will be done as many times as possible.
For instance, RMS is once per screen (one triggered acquisition), period or frequency can be 100 or 1000 times if there are 1000 pulses on screen.
Combine this with track on measurements for seeing how it changes with time.
In measurements Statistics menu you can setup how it works.
There are Count Limit and AIM limit params.
AIM limit controls how much maximum measurements will be performed per screen (for measurements that support it).
IF you set it to 1 you will get only one measurement per screen for every measurement
Count limit is max number of running length of data used for statistics.. If you set it to anything else than unlimited, than that number will be max of measurements used for stats, and there will be no multi measurements either.
Play with that a bit to get an idea..
-
Has no one noticed the last "anomaly" I mentioned? Perhaps no one cares. :-//
Well, looks like I found another "anomaly". Have a look at the capture attached. Notice the counts on the statistics. For some really odd reason, the count on the fall time is twice the others even though they were all started at teh same time. :palm:
An "anomaly" ? :palm:
How many rising edges do you see? And how many falling?
Change the timebase and watch the statistics, then you will understand the implications of deep measurements (over the full record length) with regard to speed and accuracy of measurement statistics.
-
Ahh ..., I see! Said the blind man to the deaf mute.
Okay, will give that a try. :-+
-
Flash upgrade does not work via WEB interface
When I try to upgrade from the WEB interface, the file (*.ADS) is uploaded and a message is given back
"Fail:File type not supported"
(Firefox web browser, Linux Platform)
When I do the upgrade by USB stick with the same file no problem.
SDS2104x plus with "option" to SDS2504x plus.
Firmware pack 1.5.2R2
(did the upgrade from 1.3.9R10, if I re-try the 1.5.2R2 I get this failure)
Not a big issue but strange
-
Flash upgrade does not work via WEB interface
When I try to upgrade from the WEB interface, the file (*.ADS) is uploaded and a message is given back
"Fail:File type not supported"
(Firefox web browser, Linux Platform)
When I do the upgrade by USB stick with the same file no problem.
SDS2104x plus with "option" to SDS2504x plus.
Firmware pack 1.5.2R2
(did the upgrade from 1.3.9R10, if I re-try the 1.5.2R2 I get this failure)
Not a big issue but strange
Just tested (Windows). Just mouse click..click..click and ok.
I use "isolated" Opera (do not ask), for only instruments and for www other browsers in same computer. But imho this do not matter anything.
SDS2000XP_V1.5.2R2.ADS (SDS2000X Plus FW update file)
MD5 checksum is: D74B28B943463918B4365A89612BC80F
If this match your .ADS file is ok.
When oscilloscope get this file ok, it can not result as: "Fail:File type not supported"
But why you update to V1.5.2R2. Do you have 06-xx hardware version?
-
Checksum is the same as yours
The same file updated perfect via USB-stick method
I will test with different browser/platforms
-
Strange !
Browser update.
If I try web update with the same version of firefox browser but on windows7 platform it works as expected
3 different web browser on Linux/Fedora...it fails at end of upload "Fail:File type not supported"
-
New scope(04/2023) at work, latest firmware, "old" bug ?
Timesetting:
Choosing the correct timezone (EU/Berlin), enter the correct time, leaving the menu after pressing OK, time will be shown correct in the lower right corner as expected.
Then switch off the scope, switch it on again - Time is incorrect.. :P
Timezone stays, but time itself is increased to +2h.
Martin
-
@Martin72
Mine is even more stranges
Dont have the LAN tab in that window
In the TIME tab the Time zone is blank and I can not chose any timezone
Firmware 5.0.1.5.2R2 and 2R3 (2104X plus => all options)
Connected to LAN with DHCP or Fixed IP
Knud
-
@Martin72
Mine is even more stranges
Dont have the LAN tab in that window
In the TIME tab the Time zone is blank and I can not chose any timezone
Firmware 5.0.1.5.2R2 and 2R3 (2104X plus => all options)
Connected to LAN with DHCP or Fixed IP
Knud
Go to Utility -> I/O Setting, and you should see LAN config there.
I also have the latest firmware, and cannot select Timezone at all. Time works fine anyway though.
-
I just wonder why a brand new scope behave different
And time setting does not work here only, manual is ok
I will say BUG !
Knud
@Martin72
Mine is even more stranges
Dont have the LAN tab in that window
In the TIME tab the Time zone is blank and I can not chose any timezone
Firmware 5.0.1.5.2R2 and 2R3 (2104X plus => all options)
Connected to LAN with DHCP or Fixed IP
Knud
Go to Utility -> I/O Setting, and you should see LAN config there.
I also have the latest firmware, and cannot select Timezone at all. Time works fine anyway though.
-
Siglent does not provide the time zone files in firmware upgrades, so those who bought the scope before the feature was added can not set a time zone. New scopes have those files in place from the factory. Still hope Siglent will provide those files in the future, but we have been waiting a while now.
-
Siglent does not provide the time zone files in firmware upgrades, so those who bought the scope before the feature was added can not set a time zone. New scopes have those files in place from the factory. Still hope Siglent will provide those files in the future, but we have been waiting a while now.
That's interesting. If that's the case, then maybe somebody with the time zone files can copy them off of their scopes to make them available to the rest of us.
-
That's interesting. If that's the case, then maybe somebody with the time zone files can copy them off of their scopes to make them available to the rest of us.
They also disabled the usual telnet trick that would have made that "easy" in newer firmware versions, so that's a bit unfortunate.
It's better if they finish the rollout of the feature in a supported proper way.
Looking at you tautech ;)
-
I guess this is a feature request, since I can't find a way to do it (and I don't want to RTFM again).
I want to be able to compare two frequencies on a bode plot. For example, I'd like one marker at 200Hz, and the 2nd marker at the peak. I'm running 80/dec for the resolution I need, and they don't both fit in the list on screen.
It would also be nice if there were more measurement options in bode plots. For example...comparing the peak to a specific frequency. 😉
-
For example, I'd like one marker at 200Hz, and the 2nd marker at the peak.
The cursor function won´t help ?
-
For example, I'd like one marker at 200Hz, and the 2nd marker at the peak.
The cursor function won´t help ?
It seems like it only allows me to select one point at a time:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1808368;image)
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1808374;image)
Is there already a way to add multiple points at once?
Thanks,
Josh
-
Could check it "tomorrow", but here´s what the FM says:
Cursors
SDS2000X Plus can use the cursor to measure the bode plot curve. The
cursor of the bode plot is similar to the ordinary cursor, see the chapter
"Cursors" for details. Touch Display>Cursors to recall the cursor setting
dialog box
-
Could check it "tomorrow", but here´s what the FM says:
Cursors
SDS2000X Plus can use the cursor to measure the bode plot curve. The
cursor of the bode plot is similar to the ordinary cursor, see the chapter
"Cursors" for details. Touch Display>Cursors to recall the cursor setting
dialog box
Hmm, I guess I better hook everything back up and try again lol.
Thanks,
Josh
-
It doesn't work. I did a bode plot with lower resolution to go faster:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1808380;image)
The top menu disappears during bode plot, so it certainly can't be done remotely. Pressing the physical display, cursor, or measure buttons on the scope itself doesn't do anything either. It appears the only physical button that works is the Print button.
Did the FM lie?? 🤣
-
When you touch the "Display" button in the bode menu, nothing will happen ?
-
When you touch the "Display" button in the bode menu, nothing will happen ?
Ohhh, thaaat Display button. 🤣
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1808386;image)
That's pretty cool! Except I guess it wasn't helping that I was trying to do everything from the web console. It seems like you have to use Fungus' favorite universal scroll button to adjust the measurement points.
So then my feature requests are:
1. Make the cursors adjustable from the web console
2. Remember load and sweep settings (everything else seems to be remembered).
-
Well....Bingo, I guess... ;)
-
Well....Bingo, I guess... ;)
Pretty close, I edited in my new requests. 😉
Thanks!
Edit: Why can't I select 200Hz with the stupid select knob?? That's annoying. It skips by 2, and there's no adjustment for it (199 or 201 are the only options). They need to update the UI so I can use it from the web console and enter the exact frequency I want without that dumb knob.
-
It´s way too late for me to play with my HD scope (which bode feature is the same), but let´s say in the "afternoon" I´ll play around with it, especially the web thing.
-
Well....Bingo, I guess... ;)
Pretty close, I edited in my new requests. 😉
Thanks!
Edit: Why can't I select 200Hz with the stupid select knob?? That's annoying. It skips by 2, and there's no adjustment for it (199 or 201 are the only options). They need to update the UI so I can use it from the web console and enter the exact frequency I want without that dumb knob.
Double tap/click it and enter the frequency via the virtual keypad.
Adjustment resolution will be related to the # of measurement points in use.
-
Double tap/click it and enter the frequency via the virtual keypad.
Adjustment resolution will be related to the # of measurement points in use.
I agree, that is what should happen, but it doesn't. It pops up or goes away; no virtual keypad, and no manual number entry. I'm assuming by "it" you mean the box where the number I want to edit is. The attached images are the only things that popup.
-
Double tap/click it and enter the frequency via the virtual keypad.
Adjustment resolution will be related to the # of measurement points in use.
I agree, that is what should happen, but it doesn't. It pops up or goes away; no virtual keypad, and no manual number entry. I'm assuming by "it" you mean the box where the number I want to edit is. The attached images are the only things that popup.
Yep and it need work for a mouse scroll wheel too.
Sent to Siglent as a new feature request for all models that support Bode plot.
-
It´s way too late for me to play with my HD scope (which bode feature is the same), but let´s say in the "afternoon" I´ll play around with it, especially the web thing.
Short tests...
Indeed, there´s no web control about the cursors in bode mode* - In normal mode, you can control the cursors via mouse pointer.
In the bode mode you can´t.
I can type in the start/stop frequency via keypad over web control without problems, e.g. the 200hz is no problem here regardles of the number of points (80/dec or 105/dec).
I use the batronix demoboard and connected both of the filter outputs to the bode plotter - first time I´ve tried, looks nice. ;)
When ending the bode mode you can go and get some coffee... :-X
*)My guess, bode is a kind of autark mode and ending it will be same as if you boot the scope.
This is also supported by the fact that in Bode mode you can only operate the elements in the Bode menu - everything else is "dead".
(no time base, no vertical, no measurements, no cursors, no display settings, etc, etc).
Siglent should perhaps reconsider whether that has to be the case.
-
I can type in the start/stop frequency via keypad over web control without problems, e.g. the 200hz is no problem here regardles of the number of points (80/dec or 105/dec).
The setup screen is no issue. It is annoying that it doesn't remember all the settings on the next startup. It always defaults to Continuous, but I usually do Single. It also defaults Load to 50Ω. Also forgets trace visibility and a couple other things. They should remember ALL Bode Plot settings, and have a button for full reset of Bode Plot settings (keeping it separate from the regular default button).
-
Test it:
Frequency range, source and DUT channels remains, also the amount of measure points and lin./dec.
Load and trace visibility not, maybe more, which is not noticeable in my setup.
-
Test it:
Frequency range, source and DUT channels remains, also the amount of measure points and lin./dec.
Load and trace visibility not, maybe more, which is not noticeable in my setup.
That stuff stays. Trace visibility doesn't. I only notice because I disable the phase trace, but it always comes back. The single/continuous thing is more annoying than that though. Doing 80/dec takes long enough for a single plot.
They get most of it to stay, but it' snot enough. 😉
-
There's another feature I'm assuming isn't available yet:
I'd like to be able to compare 2 or 3 different single sweep bode plots on screen at once.
Like this:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1809136;image)
I hope it might be possible if the data is saved to the USB stick for the 2 or 3 plots, and then they can be loaded and compared on screen. If not, is there a non-Photoshop way people are doing this?
-
There's another feature I'm assuming isn't available yet:
I'd like to be able to compare 2 or 3 different single sweep bode plots on screen at once.
Like this:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1809136;image)
I hope it might be possible if the data is saved to the USB stick for the 2 or 3 plots, and then they can be loaded and compared on screen. If not, is there a non-Photoshop way people are doing this?
Try using the Reference waveform feature.
It's in the Save/Recall menu where you can name and save several, internally and externally.
Maybe best you have a play with it in normal scope mode to get the hang of it before trying it with a Bode plot. ;)
-
There's another feature I'm assuming isn't available yet:
I'd like to be able to compare 2 or 3 different single sweep bode plots on screen at once.
Like this:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1809136;image)
I hope it might be possible if the data is saved to the USB stick for the 2 or 3 plots, and then they can be loaded and compared on screen. If not, is there a non-Photoshop way people are doing this?
No need do photo editing for this.
Bode Plot heart is one data table what it produce during sweep. What it display is then "secondary" feature based to this table.
All what BodePlot do and display is based to this single table. (also what goes out of BodePlot vertical display area all is still there in table.)
You can save this data table to USB and you can also recall it back to oscilloscope BodePlot for look and analyze it later. But it only handles one table at a time.
It need heavy changes to whole BodePlot for make this kind of function you like si that it can simultaneously keep many tables and display all these for compare. Also data tables parameters for compare need be comparable.
Naturally there is other way than Photo editing.
BodePlot data table is normal simple CSV file (also BodePlot display is just draw from this table).
You can do what ever with these data tables. Something example as Exel or LibreOffice etc can use for this.
Just if you want compare two bode plot sweep. Save both tables to USB.
Copypaste these data fields you are interested to new .CSV table and let LibreOffice or Exel draw these traces and visually compare or do what ever math using these data. It is very easy to do.
Ones you make this and save some settings already for next use then next time is more easy and fast. (or write tiny simple sw what can do it)
Here is one random BodePlot table so that all readers can imagine what it is in practice.
Note that CSV file every lines end is LF alone. Not CR LF. So if you open it using conventional old "Notepad" it is not nice to look.
Because in this forum .CSV attachments are forbidden (really unbelievable stupid rule) load it and remove file type .txt then it is .csv.
(also you can open it using Notepad++ what is light year ahead this ancient MS Notebad...aka Notepad)
-
Try using the Reference waveform feature.
It's in the Save/Recall menu where you can name and save several, internally and externally.
Maybe best you have a play with it in normal scope mode to get the hang of it before trying it with a Bode plot. ;)
While I'm well aware that I have a LOT to learn about all the things this scope can do (hence why I bought the batronix demo board), I don't see how that helps with bode plots.
A perfect example is that I want to compare the 3 attached plots (data files included in zip). I loaded all 3 as you suggested for REF A - C, and it says data loaded successfully, then doesn't do anything else. How can I view all 3 at once? It doesn't show any of them on screen after loading, and it doesn't appear to have anything to do with the bode plot feature either.
Thanks to @rf-loop 's suggestion, I was able to do (almost) exactly what I want in Excel:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1809505;image)
Now if I can figure out how to scale the X-axis more like the original, that would be cool. (Edit: figured that out.) I'd still prefer to have the scope be able to do this without the extra step of using Excel.
Thanks,
Josh
-
Things that should be fixed with Bode Plot:
Recalling plot data changes manual amplitude scale settings (despite the data having been recorded with the manual settings). They're set manual on purpose, if Auto isn't selected, it simply shouldn't change.
Manual amplitude scale/ref level settings are not recalled after reboot.
Other settings not recalled after reboot (that should be):
Bode plot settings including Load, & Sweap/Meas.
Display- Trace Visibility
Display- Cursor Positions (X1 is always supposed to be 200Hz for my current tests, but it jumps to other numbers after reboot).
There should be a "Bode default" soft button to reset Bode settings, otherwise, everything should be remembered.
-
I loaded all 3 as you suggested for REF A - C, and it says data loaded successfully, then doesn't do anything else.
Did your try to Recall them ?
Here's some I did while comparing probes:
https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4689083/#msg4689083 (https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4689083/#msg4689083)
-
I loaded all 3 as you suggested for REF A - C, and it says data loaded successfully, then doesn't do anything else.
Did your try to Recall them ?
Here's some I did while comparing probes:
https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4689083/#msg4689083 (https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4689083/#msg4689083)
Yes, I was trying to recall them. I guess I was wrong though, I thought it said file loaded, but it says "file format is illegal!" when trying to load the CSV files.
-
I loaded all 3 as you suggested for REF A - C, and it says data loaded successfully, then doesn't do anything else.
Did your try to Recall them ?
Here's some I did while comparing probes:
https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4689083/#msg4689083 (https://www.eevblog.com/forum/testgear/probe-into-probes-whats-up/msg4689083/#msg4689083)
Yes, I was trying to recall them. I guess I was wrong though, I thought it said file loaded, but it says "file format is illegal!" when trying to load the CSV files.
Reference file format is not CSV !
You need Save as a Reference file to your preferred destination and point Recall to it.
-
Reference file format is not CSV !
You need Save as a Reference file to your preferred destination and point Recall to it.
How do you suggest I do that, if Bode Plots only save data as CSV? The only option is to change the filename, not file type.
-
Like I wrote before, Bode is it´s own "universe" when active...you can´t do anything else... :P
But what I did a few minutes ago is:
-bode plotting ch2
-Data--save--ch2
-bode plotting again, but now with ch4 as dut output
-Check that no content from ch2 was avaible, yes, no content.
-Then recall the data from ch2
-Trace visibility ch2 on.
Now you have ch2 as a kind of reference.
-
This is what I'm actually trying to do:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1810867;image)
For now I've created this template in Excel, and it will work. Though it would be nice if the scope were capable of doing this on its own. Other people are using a crappy software scope that can do this by itself.
-
Measure no load, save the curve.
Measure loaded, save the curve.
Measure inductance, then load the prior saved curves, then you´ll have all three curves(conditions) on the screen.
Or do I miss something ?
-
Measure no load, save the curve.
Measure loaded, save the curve.
Measure inductance, then load the prior saved curves, then you´ll have all three curves(conditions) on the screen.
Or do I miss something ?
From your suggestion, I would need to keep swapping the probe channel correct? If I do that 3 times, will it give me the option to choose peaks for all 3 plots? And show the data?
-
If I remember it right, the full data content will be saved.
I would need to keep swapping the probe channel correct?
Yes, so my thoughts.
Now it is a little late (22h44) to check it for me, maybe tomorrow early evening - or you try it first. ;)
-
I have a small issue when swapping from using a digital/MSO input as trigger, to an analog input as trigger.
Everything works as expected, but the display shows accumulated waveforms, similar to if infinite persistence was set (intensity is still at 50%).
So the probe can be lifted entirely away from the probed test-point, and the aggregated waveforms continue to show on the display, rather than a horizontal line for DC 0V.
Hitting the 'default' button fixes it. But one then has to re-configure the probe settings, timebase, vertical resolution etc.
I am still learning and exploring, so it may be something very obvious.
Without enough information about all things affecting here, it is impossible to answer. Yes I can start speculation like if this and perhaps if this and that...
Please tell enough information. We don't see the things that you see in it and that you know about. At least I don't know any clairvoyants here.
It's also quite frustrating and time-consuming to start asking each impressive thing separately.
Now, for the sake of example, I am asking just one very essential setting. There are three modes of action related to triggering: Auto. Normal. Single.
So I ask, Auto or Normal? *)
Then there are two different modes. DPO (in Siglent "SPO") or traditional DSO. (Acquisition modes: Fast(default, SPO) and Slow (like ancient DSO))
Because your explanation (without screen dump image) I believe Aq. mode is Fast.
If acq mode is Fast and trigger mode is Normal... when trigger disappear you can see last acquisitions... until next trig. (or do something what clears display)
In DPO mode one display frame can include several last acquisitions overlaid **) (depending signal and scope settings) and if this situation freeze due to missing trigger... you can see this static display on the screen.
If not then it is broken.
*)
When trigger mode is Normal all stay on the screen until next trigger.
When trigger mode is Auto. If not Trigger events it start generate automatic trigger. In case when signal trig.. it draw signal... if trig disappear it start display what ever is input. If zero then it display zero. Time delay after Trigger disappear until it start Auto trig is quite short.
**)
in some cases with fastest setup one TFT frame may contain up to thousands of sequential last acquisition traces overlaid in one display frame.
If you turn acquisition mode to Slow... one TFT frame can have only one acquisition. (in some case useful setting)
I can not now test if there exist some problem when LA channels in use...
Please next if need more... take screen image where can see exactly what happen including also settings.
-
I have a small issue when swapping from using a digital/MSO input as trigger, to an analog input as trigger.
Everything works as expected, but the display shows accumulated waveforms, similar to if infinite persistence was set (intensity is still at 50%).
So the probe can be lifted entirely away from the probed test-point, and the aggregated waveforms continue to show on the display, rather than a horizontal line for DC 0V.
Hitting the 'default' button fixes it. But one then has to re-configure the probe settings, timebase, vertical resolution etc.
I am still learning and exploring, so it may be something very obvious.
One normally reports a bug stating the FW version installed and with the latest, V1.5.2R3, any changes to the timebase delete any existing persistence.
I strongly suspect user error accidentally engaging Persistence by way of double tapping the Display button.
This is a feature in that you don't need to enter the Display menu to engage Infinite Persistence.
BTW, if the Display button is illuminated Persistence = ON.
It can also be useful to turn Hide Menu to OFF so to have it up and see what settings are active. One can easily hide it with a click or touch on a blank part of the display and bring it back touching or clicking the menu header that remains or pressing the Display menu again.
-
Hi rf-loop and Tautech,
I deleted the post not to waste anybody's time. too late..
And my post was partly in the form of a question, so more properly belongs to the general thread for sds2000x+.
When it happened on exit from MSO/digital mode each time in the past, I cycled/stabbed through all Normal and Auto, And Single, without being able to change the behavior.
But I am cursed, and cannot now replicate it.
Its a mistake to try to problem solve DUT issues, and experiment with scope at the same.
If it happens again, and I cannot determine what is happening based on your posts, I will provide more detail with screen shots.
-
Hi rf-loop and Tautech,
I deleted the post not to waste anybody's time. too late..
And my post was partly in the form of a question, so more properly belongs to the general thread for sds2000x+.
When it happened on exit from MSO/digital mode each time in the past, I cycled/stabbed through all Normal and Auto, And Single, without being able to change the behavior.
But I am cursed, and cannot now replicate it.
Its a mistake to try to problem solve DUT issues, and experiment with scope at the same.
If it happens again, and I cannot determine what is happening based on your posts, I will provide more detail with screen shots.
Good questions are never a waste of time, just be sure to give as much info as you can and screenshots too. ;)
About Default, you can set your very own preferred Default which is done from within the Save Recall menu.
-
If I remember it right, the full data content will be saved.
I would need to keep swapping the probe channel correct?
Yes, so my thoughts.
Now it is a little late (22h44) to check it for me, maybe tomorrow early evening - or you try it first. ;)
Unfortunately, that method didn't work for me at all. I ran plots on CH1 and CH2 separately, and then tried recalling the data. It only shows one at a time for me, alternating back and forth.
It's only capable of showing the list of test points from 1 channel at a time, and the cursors can also only do one channel at a time.
It gets more tedious because switching channels on the plot config forgets load and amplitude (likely other things too). More steps to forget the parameters for good comparison. Did I measure high or low impedance at 3Vpp or 5Vpp? Who knows, the scope won't remember for me. 😉 Edit: it might have been exiting and reentering bode plot to setup the channel settings to match, since I couldn't do that within the bode plot universe. Either way, it needs to remember settings better.
I copied and pasted the saved data into my Excel template, and here's how it's supposed to be:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1811482;image)
-
I dunno if this is a bug exactly, but...
My old Default key settings had CH1 set to a 1x probe. My probe in CH1 is an auto-sense 10x probe. Pressing Default set CH1 to 1x ignoring the auto sense. I obviously changed the default to 10x to avoid future nuisances, but it seems odd to me that hitting the Default key would ignore the auto-sense feature of the scope/probe(s).
-
Missing Feature / Feature Request
Maybe already suggested/requested:
10 MHz In, 10 MHz Out
Would be nice to take clock from GPSDO
Maybe on the next version: SDS2000X Plus MkII ?
-
Feature Request:
Ability to change the number of divisions.
For example, instead of 8 div vertical scale, we could change it to 10.
-
Hi,
I tried to use the mask feature with saved mask file : does not work. After the loading of the saved xxx.smsk file, the vertical range is reset to the minimum and the small part of the mask is visible on the top of the screen.
Used FW version : V1.5.2R1
Used scope : SDS2104X Plus
I tried to load the mask file from python - the loading is not happen at all.
import pyvisa
#https://siglentna.com/wp-content/uploads/dlm_uploads/2023/04/SDS-Series_ProgrammingGuide_EN11D.pdf
rm = pyvisa.ResourceManager()
inst = rm.open_resource("TCPIP::10.35.89.136::INSTR")
print(inst.query("*IDN?"))
inst.write(":MTESt ON")
inst.write(":MTESt:MASK:LOAD EXTernal,\"local/mask.smsk\"")
inst.write(":MTESt:OPERate ON")
Kind Regards,
Krasi
-
Used FW version : V1.5.2R1
Latest FW is 1.5.2R3. I dunno if the bug exists or not, but you should try the latest firmware anyway.
-
Thanks for the advise, but unfortunately the FW ver 1.5.2R3 does not fix the problem.
-
Has anybody else noticed that Video Sync as a trigger option is not working as expected ?
I've set the trigger to PAL, on line 1 field 1, but it seems that at different timebases triggering happens at either field 1 or field 2 randomly; and sometimes on both field 1 and field 2.
Recently I got the Siglent SDS2104 with free 200 MHz uprade.
The PAL video triggering is very poor indeed.
The line numbering is not correct at all, in the odd field it should count from 1 - 313 and the even field from 314 - 625. The line setting does not exceed 313. In the even field it starts again at 1. The count is also incorrect, if you choose line 24 you will see line 22. It is also very difficult to get a stable image.
These are serious bugs. I hope Siglent will solve these problems.
My old Tektronix TDS2024B triggers very well and I also have an old PM8917 video line selector, which still works fine.
Now I don't need video triggering that often anymore. In the past I developed teletext inserter boards for local TV channels and good video triggering is very important for that.
-
The built-in VNC server seems to be very finicky. If I try to connect to it via one client, the VNC server crashes and refuses connections until the next reboot. Other VNC clients simply report a problem connecting. I don't see anything glaringly obvious with a quick VNC packet capture and dissection.
Does anybody know how I can still get to a Linux shell to look at the logs or look at which version of libvncserver they're using? My firmware is 1.5.2R3. (It also happened with 1.3.9R12.)
-
VNC buggy
Strange....haven't used this feature for a longer time
Now it gave just a black screen on both PC and Scope....only the webpages HOME, LAN CONFIG, SCPI where correct.
Both WEB server and VNC server gave black screen
Then I entered the Display menu on the scope, looked a little around in different sub menus but did not change anything.
Now it works ok ????
I have properly 1 or 2 firmware updates before used this function last.....maybe some setting need to be refreshed ???
Knud
-
After approx 20-30sec screen goes black both PC and scope, return to normal if I click on the scope area
Have they introduced a screensaver ?
Upss...Found it was set to 1min
Don't remember I did that :)
Knud
-
In the menu "Utility => System Setting" you will find the settings of the screensaver.
-
I dunno if this is a bug exactly, but...
My old Default key settings had CH1 set to a 1x probe. My probe in CH1 is an auto-sense 10x probe. Pressing Default set CH1 to 1x ignoring the auto sense. I obviously changed the default to 10x to avoid future nuisances, but it seems odd to me that hitting the Default key would ignore the auto-sense feature of the scope/probe(s).
This is clearly a bug, and appears to affect the HD model too. Hitting Default ignores the auto-sense probe and that's no good.
-
I dunno if this is a bug exactly, but...
My old Default key settings had CH1 set to a 1x probe. My probe in CH1 is an auto-sense 10x probe. Pressing Default set CH1 to 1x ignoring the auto sense. I obviously changed the default to 10x to avoid future nuisances, but it seems odd to me that hitting the Default key would ignore the auto-sense feature of the scope/probe(s).
This is clearly a bug, and appears to affect the HD model too. Hitting Default ignores the auto-sense probe and that's no good.
Same problem here with an SDS2354X Plus with Siglent SP2035A 350 MHz probes. CH1 ignores that it is an auto-sense 10X probe even after pressing the Default button. With CH2 to CH4 it works mostly quite well.
-
I used a 32GB (or 16 or 64, icr) flashdive, formatted to FAT32, to up-date the firmware on my 2104Xplus when I got it a month or so ago. And then yesterday, I popped in that FD to print/save some screen shots on the scope. But then when I plugged it back into my win10 PC, it said I had to reformat the drive again. It's a new FD, and I haven't used it between the firmware up-date and yesterday.
Does that sound familiar to anyone ??
-
In the V1.5 firmware, Siglent added the ability to read/write measurement types used by Power Analysis, including:
- PFACtor Power Factor
- RPOWer Real Power
- APOWer Apparent Power
- RPOWer Reactive Power
- PANGle Phase Angle
Bug report: They use RPOWer for both Real Power and Reactive Power. As a result, you can't specify Reactive Power via SCPI.
Additionally, the above measurements are **** until you turn on Power Analysis, and there's no way to control Power Analysis via SCPI. I think all of the other options can be controlled by SCPI, so this seems like an omission.
Feature request: Add SCPI commands to control Power Analysis, at least to turn it on. That way I could configure the scope to display power measurements entirely via SCPI.
For now I can simply script VNC to click on the right spots ("Analysis" then "Power Analysis" then "Test State" on), but it would also be nice if it wouldn't reset everything when I do.
Nice to have: Ideally there would be UI for configuring measurement display of power analysis rather than just SCPI. (For example, a "Power" tab in the "Measure select" window could let you select Power Analysis measurements.)
Nice to have: It would also be nice to have RMS() be an available math function in the function editor. Right now I can define F1=C1*C2 and display RMS(F1), but real power is RMS(C1)*RMS(C2).
-
It would also be nice to have RMS() be an available math function in the function editor. Right now I can define F1=C1*C2 and display RMS(F1), but real power is RMS(C1)*RMS(C2).
Real power is neither RMS(C1)*RMS(C2) nor RMS(C1*C2).
If C1 and C2 are voltage(t) and current(t), then the real power is the (cycle) mean of C1*C2.
(Or if you mean instantaneous power, as a function of time, then it is simply C1*C2.)
-
Nice to have: It would also be nice to have RMS() be an available math function in the function editor. Right now I can define F1=C1*C2 and display RMS(F1), but real power is RMS(C1)*RMS(C2).
Something like this is possible, even though it's a bit awkward to use:
I asked about this in the main thread, but didn't get any replies, so I assume this is not possible in the current firmware. Consider these as feature requests.
...
2. Would be nice to be able to display watts, and perhaps the formula editor could be the way to go. I can't see any way of using measurements in the editor however. Is it possible to enter something like this? RMS(C1) * RMS(C1) / 8
Ideally it would be a custom "measurement" since it doesn't need a trace, but I can't see a way of doing that.
Well, to quote myself again here, it seems #2 is sort of possible:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1293619;image)
Wish it was possible to base it on the RMS measurement instead, but better than nothing.
This is what it looks like:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1293625;image)
The Pk-Pk(F2) measurement is watts into 8 ohm.
...
Still hoping for some improvements here.
-
Hi,
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5175306/#msg5175306 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5175306/#msg5175306)
Same here..
-
Hoping for a fix to the request posted by Martin72 above, as it will increase usability of the parallel probes quite a lot.
I have some more requests as well, related to the user experience. All of which can be seen on the 1 screenshot below.
1. Can the modal "saved to file" dialog you get after taking a screenshot be dismissed automatically after a timeout? It never goes away unless I click the X in the corner, which seems unnecessary, and it's always in the way of something. The good thing is that it's dismissed when taking another screenshot, so you normally don't see it when taking multiple screenshots in a row. But the last one must be manually dismissed.
2. Can the mouse cursor hide automatically when taking screenshots? Can't really see any reason to have the mouse cursor in the screenshot, and I find it distracting. It takes the focus away from what I'm trying to capture.
3. Can the mouse cursor hide automatically when the mouse is idle? Like when watching a video on YouTube, the cursor hides after a few seconds unless you move it. Not as important as #2, but would still be a nice improvement to keep the user interface focused on what's important.
4. The axis labels used to have 4 or 5 decimals, and now it varies a bit. On some instances, like shown here, it's 3 decimals. Is it necessary? I would prefer 2 decimals to keep the interface cleaner and more focused on the content.
[attachimg=1]
-
Realistically, do we think there's much hope of another feature release for this scope series? The most recent release which added new features worth mentioning was two years ago, according to the release notes. Is there any indication from Siglent that they will invest time into another feature upgrade?
I have just ordered the 2000X+ but don't have hands-on experience yet. From what I have read, two things high on my wishlist would be:
- Ability to send part of a captured waveform to the AWG, e.g. using the cursors. I understand that the only thing you can do so far is to replay the whole screen width of a captured signal -- which will almost never be an exact period of the signal, since you also don't have a horizontal vernier. Seems like such an obvious feature for a scope with an internal AWG.
- Enable support for WiFi dongles. It seems that the Realtek driver is still part of the firmware, but Siglent removed the interface for configuring WiFI -- which is present in the smaller 1000X-series siblings. Is there a known technical reason for this? If not, can we please have this functionality? (Yes, I know that you can use a mini-router. But it will either need its own power supply, or a cable round to the front USB ports, which is just messy.)
-
@blurpy:
1. This annoying thing has already been fixed on some models (you can then set whether and for how long), including my HD - I think this will also be included in the next update for the plus.
2. Simply move the pointer briefly to the side or corner, then it disappears from the screen, then press print, a matter of seconds. I tried this earlier and it works wonderfully.
3. See 2nd, simply push into the corner.
4. Is it necessary?
I think that's well thought out.
From 1V/div it is two digits, from 10V/div it is one digit, at 500mV it is three digits.
Alternative: Switch off the scale.
-
1. This annoying thing has already been fixed on some models (you can then set whether and for how long), including my HD - I think this will also be included in the next update for the plus.
Nice, can't wait :D
2. Simply move the pointer briefly to the side or corner, then it disappears from the screen, then press print, a matter of seconds. I tried this earlier and it works wonderfully.
3. See 2nd, simply push into the corner.
Well, it's a sort of a workaround. I do that already, except when I forget, or when I take a screenshot in a hurry. And I see the annoying cursor in the screenshot on my computer when it's too late :palm:
I think it's ok for #3, but not for #2.
4. Is it necessary?
I think that's well thought out.
From 1V/div it is two digits, from 10V/div it is one digit, at 500mV it is three digits.
Alternative: Switch off the scale.
Sure, it's not too bad, but I can't see the usecase for the 3 digits. I usually use measurements if I need more accuracy, and the labels are there just for a ballpark as it's difficult to judge the accurate value anyway.
-
2. Can the mouse cursor hide automatically when taking screenshots? Can't really see any reason to have the mouse cursor in the screenshot, and I find it distracting. It takes the focus away from what I'm trying to capture.
I could see the mouse cursor actually being useful in a screenshot, to point out some feature (or problem) in a trace. Hence I like the option to have it in the screenshot, or manually move it out of the way when I don't want it.
I think that's well thought out.
From 1V/div it is two digits, from 10V/div it is one digit, at 500mV it is three digits.
Alternative: Switch off the scale.
In my view, the axis labels in blurpy's screenshot all have two redundant zeros. These take up extra space, increase the likelihood of obscuring some trace detail, and actually make the numbers harder to read because the significant digits are less obvious.
Using up to three digits in the 500 mV range and below might make sense. But if all axis labels are even numbers, with only zeros in the trailing position(s), they should be shortened in my opinion to remove the redundant zeros.
-
It has been worse before... ;)
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg3686440/#msg3686440 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg3686440/#msg3686440)
-
FYI
A 1.6.0 beta FW has been with beta testers for a few weeks to replace the current V1.5.2R3 FW.
Improvements are coming. ;)
-
FYI
A 1.6.0 beta FW has been with beta testers for a few weeks to replace the current V1.5.2R3 FW.
Improvements are coming. ;)
Any spoilers on them improvements? 😉
-
Realistically, do we think there's much hope of another feature release for this scope series? The most recent release which added new features worth mentioning was two years ago, according to the release notes. Is there any indication from Siglent that they will invest time into another feature upgrade?
As long as the EOL has not been reached, you can always count on something happening in this direction.
The Scope is now quite mature and has been on the market for three years, so the firmware update rate is correspondingly low.
The good thing is that the scope is based on the same UI as other models, be it the 5000X which made the start (2018), be it the 6000A which is the premium model, be it the HD which came out two years after the plus.
I don't know exactly, but I can imagine that when a new feature is realized, siglent looks to see if it can be realized on the other models, hardware-wise.
For example, digital filters, four math channels, four memory channels and memory management were not an issue in the consumer models at the beginning (recognizable by the "X" in the model name).
In the meantime, my HD has all this and I can well imagine that siglent are at least thinking about which of these features can also be added to the plus model.
-
For example, digital filters, four math channels, four memory channels and memory management were not an issue in the consumer models at the beginning (recognizable by the "X" in the model name).
In the meantime, my HD has all this and I can well imagine that siglent are at least thinking about which of these features can also be added to the plus model.
Here's hoping! I had not dared to suggest filters or more math channels, since I figured that the 2000X Plus CPU might be at capacity. But maybe we will get some pleasant surpises?
Let's hope that the incubation time of the new 1.6 firmware release is shorter than the one of the SDS1000X HD. ::)
-
Hold yours in your hands for now, if I remember correctly you have a DS1054Z - That will be a leap that will make you forget which features would still be nice to have.
So for now. ;)
As for the 1000X HD, I can't imagine that what it has more of won't work on the 2000Xplus platform. :-X
Apart from the 12 bit.
-
FYI
A 1.6.0 beta FW has been with beta testers for a few weeks to replace the current V1.5.2R3 FW.
Improvements are coming. ;)
Have the PAL video triggering bugs also been reported to Siglent, as I mentioned earlier?
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg4975681/#msg4975681 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg4975681/#msg4975681)
-
FYI
A 1.6.0 beta FW has been with beta testers for a few weeks to replace the current V1.5.2R3 FW.
Improvements are coming. ;)
Have the PAL video triggering bugs also been reported to Siglent, as I mentioned earlier?
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg4975681/#msg4975681 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg4975681/#msg4975681)
I only see Zone trigger addressed however not all improvements are in the list and the FW is not the same version that will be public. ;)
-
The next firmware might not be perceived as a major update, but it still comprises a small new feature...
And for those who are doubting: this will not be the end. HW resources are limited, but as long as resources permit, new features will still be implemented in the future even though the instrument is in the market for quite a while now. Stay tuned...
-
2. Can the mouse cursor hide automatically when taking screenshots? Can't really see any reason to have the mouse cursor in the screenshot, and I find it distracting. It takes the focus away from what I'm trying to capture.
I could see the mouse cursor actually being useful in a screenshot, to point out some feature (or problem) in a trace. Hence I like the option to have it in the screenshot, or manually move it out of the way when I don't want it.
Annotations would be the ideal way to do that. See a quick video about how Rohde & Schwarz implemented it:
https://www.rohde-schwarz.com/us/knowledge-center/videos/r-s-rtb2000-easy-report-creation-video-detailpage_251220-505222.html (https://www.rohde-schwarz.com/us/knowledge-center/videos/r-s-rtb2000-easy-report-creation-video-detailpage_251220-505222.html)
Since people here like the cursor, it could just be an option to have it hidden in screenshots.
I've used the scope for 2 years without missing a cursor on my screenshots, but having the mouse plugged in for a day was enough to annoy me. Can't imagine I'm the only one ;)
-
The next firmware might not be perceived as a major update, but it still comprises a small new feature...
And for those who are doubting: this will not be the end. HW resources are limited, but as long as resources permit, new features will still be implemented in the future even though the instrument is in the market for quite a while now. Stay tuned...
I am very pleased to read that -- well, at least the second part of your message. ;)
But I would be even more pleased to see corresponding action from Siglent. As mentioned earlier, it looks like the last somewhat major functional update happened two years ago, and learning that 1.6 will be yet another minor release is not too encouraging. Does that mean another year until we can (maybe) check a few things off the wishlist?
-
This is also a wishlist, not a to do list. ;)
-
This is also a wishlist, not a to do list. ;)
Sure, but seeing Siglent grant some wishes would please me. (And others too, I guess.) ;)
-
I think I should clarify some things.
This thread has been started with the intention to have all bug reports and feature requests in one place, so far, so good. Most of the bugs have been fixed and quite some features added, sometimes even without notice in the version history. The scopes wouldn’t be as good as they are without the constructive feedback from competent users.
Other than some of the competition, Siglent has opted to cooperate with beta testers and consultants from the (also high end) industry quite a while ago. These folks build a team that not only reports bugs and requests features, but have also compiled long lists of requirements and corresponding feature requests long before an instrument was released in the western world. Even these folks have had to learn that not every single wish or recommendation would be accepted by the majority within the team, hence wouldn’t make it on said list. And then we had to learn that Siglent R&D always has the last (and most important) vote, as only they can decide what is feasible at all and how big the risk of certain modifications is.
For instance, I’ve fought long and hard to get four math channels on the SDS2104X Plus, it just wasn’t possible because of the lack of hardware resources. The same goes for the HW-supported acquisition modes ERES and Average, which had to be sacrificed because of the 10 bit mode – which has absolutely no speed penalty and most users will value it pretty quickly.
Our fellow forum member Martin72 has pestered me endlessly because of the above shortcomings, nevertheless I couldn’t change the facts. At least we’ve got the formula editor to mitigate the sparse number of math channels a little.
This thread contains many sensible requests and most of them have been or will be fulfilled, either because they happen to be similar to something that was already requested by the beta team, or someone was brave enough to report it to Siglent – every user could do this by themselves, by the way. On the other hand, there are also the users who happily request things without the bigger picture and without knowing much about the details of a modern DSO.
And sometimes we hear arguments like: “but the DS1054Z can do that!”, not taking into account that you can easily implement everything you like on a scope that only uses screen buffer data (some 1 kpts) for everything, whereas e.g. an SDS1000X-E has to deal with up to 14 Mpts for each operation (math, measurements…), hence requires orders of magnitude more processing power and memory space to accomplish the same thing – but also presents usable results in return.
Another classic: “We want some additional info on the screen, and there is some unused space somewhere in the info-bar, why not put it there?” this comes from people who have never seen a full fledged instrument (e.g. with MSO option), where every square centimeter of space is in use.
Nevertheless, thanks to such user complaints the UI of Siglent scopes provides an unrivaled amount of information, hence a clear picture about the setup, which makes screenshots almost self-explanatory. You need not guess about the sample rate, record length, input bandwidth, probe factor, coupling, input impedance – even the acquisition mode is clearly shown with the newest firmware. And never requested by anyone, but provided by Siglent right from the start, the 7-digit trigger frequency counter, which is permanently visible. I would never have a DSO without that feature.
To cut a long story short: we all, users, consultants and beta testers have to live with real world constraints, where limited (also human) resources is one of them. And there might be good reasons, why some wishes cannot be fulfilled. And even when a request is granted, it might have been assigned a low priority and take quite a while until it can be released. Or R&D faces difficulties and they have to discard all the work so far and start again with a new approach.
Whenever you buy a new instrument, you have to make your decision based on the current state of things, as it is documented in the data sheets and various demonstrations in the associated thread in this forum. You cannot say: “oh, I want 4 math channels and HW accelerated average acquisition and this scope doesn’t have it, but hey, there’s a ‘bug and feature’ thread, I’ll place my wishes there and expect it to be available with the next firmware update, which I’d like to receive within the next two months. If not, I’ll call Siglent a bad company!”
-
Our fellow forum member Martin72 has pestered me endlessly because of the above shortcomings
Sorry... ;)
-
Thank you for the perspective, Performa01. To be clear, I certainly don't expect Siglent to grant every wish and implement every feature request; that would obviously be unreasonable.
More clarity would help to manage expectations -- e.g. your statement that four math channels just can't happen due to limited computational resources. I had suspected that, but had not yet seen a clear statement anywhere. More transparency regarding timelines would also be helpful in my opinion. I would strongly encourage Siglent to switch to a time-boxed development and release cycle for updates once an instrument is in "sustaining" mode: Set a release cadence upfront, say one feature release per year, then implement features incrementally until the drop-dead date for the test and release phase.
May I also say that the Siglent advocates here on the forum have set expectations pretty high. Siglent is touted as "the company which keeps developing their products and adding features throughout the product life cycle", and also as "the company which does not implement 'checkbox features' just to have them in the spec sheet, but does things properly". Seeing that the last major feature release for the SDS2000X+ happened two years ago, and apparently the next one will not happen soon, conflicts with those expectations. And seeing the very basic AWG in the same scope, and its lack of integration with the scope functionality, is not in line with the second claim.
I have nevertheless ordered the 2000X+, based on its current specs. It still seems to be the best match for my needs within the budget I have set for myself. But it was a painful decision due to some of the unexpected limitations, and I was hoping that the firmware update plans would make it a bit easier.
-
Thank you for the perspective, Performa01. To be clear, I certainly don't expect Siglent to grant every wish and implement every feature request; that would obviously be unreasonable.
More clarity would help to manage expectations -- e.g. your statement that four math channels just can't happen due to limited computational resources. I had suspected that, but had not yet seen a clear statement anywhere. More transparency regarding timelines would also be helpful in my opinion. I would strongly encourage Siglent to switch to a time-boxed development and release cycle for updates once an instrument is in "sustaining" mode: Set a release cadence upfront, say one feature release per year, then implement features incrementally until the drop-dead date for the test and release phase.
May I also say that the Siglent advocates here on the forum have set expectations pretty high. Siglent is touted as "the company which keeps developing their products and adding features throughout the product life cycle", and also as "the company which does not implement 'checkbox features' just to have them in the spec sheet, but does things properly". Seeing that the last major feature release for the SDS2000X+ happened two years ago, and apparently the next one will not happen soon, conflicts with those expectations. And seeing the very basic AWG in the same scope, and its lack of integration with the scope functionality, is not in line with the second claim.
I have nevertheless ordered the 2000X+, based on its current specs. It still seems to be the best match for my needs within the budget I have set for myself. But it was a painful decision due to some of the unexpected limitations, and I was hoping that the firmware update plans would make it a bit easier.
If you don't mind, I would like to throw in my 2c into discussion.
Statements on how Siglent keeps developing products are more than true. Track record speaks for them.
In my experience expectations by customers are almost always "too optimistic". From my own experience, with my own products. Nothing wrong with that, but customer expectations are not same as the promise by the manufacturer. Manufacturer might give their best to keep the platform live and vibrant or they can release it, fix glaring mistakes and forget about it. It is up to reader to do their homework which is which.
As to expectations, fact that Siglent is still keeping this scope in active development and keeps adding features long after release should not be confused with "Siglent promises to keep adding major features that will with time convert a 1000€ scope into same capability as 20000€ LeCroy".
Realistically, manufacturer will add features to keep scope competent contender in a marketplace where it belongs. They might add a bit more to keep it fresh and to keep certain strategic advantage. But mostly never it will grow so much to exit it's class and enter one above. For both strategic and technical reasons.
Unfortunately, I don't keep an archive of old datasheets and manuals so we can compare. Shame.
As for development and release schedules, that is also interesting and not so simple topic.
First, these touchscopes from Siglent are part of platform based on common code base.
While they don't share common FW in binary form, they share common framework.
Adding new features logically happens on platform level and then gets propagated to it's members, based on product placement, architecture and technical details.
There will be some implementation details specific to certain model. If that specific detail would require a separate, model specific, piece of code to accomplish something differently than the rest, than that is not optimal. In which case chance of that happening is not so high, unless it is something of vital importance. Sometimes, a feature is developed for higher models and propagated to all because it is nice to have and no problem to implement. Like mounting disk shares etc...
Development and release cycles are all impacted by this. This makes them highly nonlinear and interdependent.
In addition to that, modern practice to develop software on fixed released schedules without and regard to quality or completeness of code has shown catastrophic results for quality of code.
Just look at Rigol which released 4 different new scopes (4 products) based solely on management decision to stick to aggressive timetables. It's been half a year now... They basically released hardware-software prototypes, what Microsoft would call RC (release candidates). It is almost completely defined hardware and software developed to the point of software architecture largely defined and basic modules implemented in their first iteration.
This is what you get if you have to release software twice a year instead of when it's done..
Since Siglent is very mindful of their professional market (while Rigol seems to focus mostly on hobby market, strategically) they make sure their releases pass the litmus test before releasing. Of course nothing is completely perfect all the time, but they put in serious effort to do so. As opposed to blatant disregard to these principles like some other do.
I ask you to take Keysight and R&S as example an take a look how aggressive are they with releases and how often they do them.
And how many real features they added during lifecycle. Whatever they did add was to simply fix initial bad decision to artificially limit products in a first place. R&S added slightly better math on RTB2000 only after sever backlash by users that complained that 3000-4000 € scope had worse math than 500€ Chinese scopes. You still have to buy segmented memory and basic decodes for RTB2000 as a separate option.. Or Keysight with 1000X where they finally opened up DSOX1204 to have simply basic functions other much less expensive scope had for years. Basic measurement statistics was only added in september of 2021. and that was last release of FW for it. Since release there were only 4 FW updates (since October 2018).
None of the "big boys" will ever commit to any schedules or feature.
FW updates are in a way a strategic resource, nobody wants to open their cards..
I thing Siglent is actually doing a better job in this regard.
-
I have nevertheless ordered the 2000X+, based on its current specs. It still seems to be the best match for my needs within the budget I have set for myself.
Good choice!!
You'll like the 2000X+, quite a value, and slated more for professional types with higher end features that are actually useful and work rather than being cute!!
For example, just yesterday we modified our flawed Micsig DP10007 Differential Probe (thanks ExaLab!!). This is a simple hardware "fix" to improve CMRR (way out of spec), and requires recalibration. When attempting such the signal of interest is buried in noise, and difficult to null. However employing the SD2000X+ nice FFT (it's somewhat slow tho) makes this nulling exercise a little easier to accomplish.
https://www.eevblog.com/forum/testgear/new-eevblog-hv-probe/150/ (https://www.eevblog.com/forum/testgear/new-eevblog-hv-probe/150/)
Also, contrary to many opinions, we've found the Bode Function (FRA) quite useful, and even developed a set of "Injection Transformers" to support Open Loop measurements within Closed Loop Systems!!
Best,
-
Well, Siglent certainly has loyal customers/beta-testers/consultants here -- so they must be doing something right! :-+
Thanks for you long post, 2N3055. You make several valid points. I'll comment on just a few aspects where I don't concur:
As to expectations, fact that Siglent is still keeping this scope in active development and keeps adding features long after release should not be confused with "Siglent promises to keep adding major features that will with time convert a 1000€ scope into same capability as 20000€ LeCroy".
Realistically, manufacturer will add features to keep scope competent contender in a marketplace where it belongs. They might add a bit more to keep it fresh and to keep certain strategic advantage. But mostly never it will grow so much to exit it's class and enter one above. For both strategic and technical reasons.
Can we please keep this discussion fair and level. I don't think I suggested anything unreasonable which would catapult the scope out of its class:
- The ability to "trim" a captured waveform and send it to the AWG -- such that a full period is played back, rather than some arbitrary chunk which happens to fit the screen width -- is standard on pretty much every DSO with a built-in AWG, to my knowledge.
- Filters (as a Math operation) are also standard in this class, e.g. on the RTB2000, DSOX1200, MSO5000. The SDS2000X+ is the odd one out here, since it apparently still does not have them. And while I get it that going beyond 2 math channels would stretch the computational resources too much, I can't see why simple FIR or IIR filters should require more computing power than other math operations.
- Being able to configure a WiFi dongle is not standard yet. But since Siglent have this feature in the lower-end scopes, and actually have the RTL8188 driver up and running on the X+, it seems like low-hanging fruit and a nice differentiator.
So please don't give a distorted view of user expecations here.
As for development and release schedules, that is also interesting and not so simple topic.
[...]
In addition to that, modern practice to develop software on fixed released schedules without and regard to quality or completeness of code has shown catastrophic results for quality of code.
Just look at Rigol which released 4 different new scopes (4 products) based solely on management decision to stick to aggressive timetables. [...]
This is what you get if you have to release software twice a year instead of when it's done..
Sure, I know about dependencies, platform approach etc.; I have been working in industrial instrument R&D for a long time. I specifically suggested that Siglent switch to a time-boxed approach once the product is in "sustaining" mode, with incremental feature additions and bug fixes -- not for new development. No need for shadow-boxing, please.
None of the "big boys" will ever commit to any schedules or feature.
FW updates are in a way a strategic resource, nobody wants to open their cards..
I thing Siglent is actually doing a better job in this regard.
Again, commiting to features upfront is not what I suggested. The idea is to commit to a timeline cadence for updates -- so customers see that you are still committed to the product, and don't keep scratching at your door to ask when the next update will come. Keep the scope of the release open, to manage technical risk and keep some flexibility in the resources you can assign to firmware improvements.
Maybe this is not standard in the industry. I am not saying that Siglent is doing worse than other brands. But I think this would be a realistic approach how they could do better than the competition.
-
Being able to configure a WiFi dongle is not standard yet. But since Siglent have this feature in the lower-end scopes, and actually have the RTL8188 driver up and running on the X+, it seems like low-hanging fruit and a nice differentiator.
The idea is to commit to a timeline cadence for updates -- so customers see that you are still committed to the product, and don't keep scratching at your door to ask when the next update will come.
You don't need a wifi dongle if it's that important to you. You can connect a TL-WR902AC or TL-WR802N or similar to connect your scope via wifi. The wifi dongle idea limits your ability for range and speed.
I completely disagree with you on setting dates for the firmware releases. There's absolutely no point beyond consumers having something to look forward to. The way they do it now is perfect. Work on shit, test it, test it more, then release it. The flipside of your idea is that a bug fix could be ready, but the release date is 4 months away. What's the point of that? If stuff is ready, release it! If not, don't!
-
Well, Siglent certainly has loyal customers/beta-testers/consultants here -- so they must be doing something right! :-+
In our case Siglent had to "Earn" our loyalty !!
Our career spanned over 6 decades (still going), mostly in R&D, and we've used just every piece of TE one can imagine. When we retired from regular duty and formed our own company, our 1st major purchase was a DSO/MSO.
We loitered here for awhile gathering information and understanding sources of such, we decided to get the Siglent SDS2000X+ a few years ago, best equipment purchase decision we've made, so we got another!! So next was a SA, SSA3021X+ another good decision, then AWG the SDG2042X and SDG6022X pretty darn good AWGs, then the PS the SDP3303X, also pretty good and we got 2 more, then SDM3065X, not a DMM we particularly are fond of (not bad tho, but for our precision use it's up against some stiff competition) and why we have 3 KS34465As, DM6500, HP34401A and AG34401A. When we needed an Electronic Load and got the SDL1020X-E which has been put through it's paces wrt dealing with lots of power up to 30amps emulating various high power loads and it hasn't smoked yet!! Believe me we didn't expect it to survive what we've thrown at it, but it has, a tribute to the design and margin involved :-+
With all this Siglent equipment we haven't seen a hiccup yet (well we did screw up a PS by not following the Cal procedure properly, Siglent NA fixed it at no charge!!), even just today we "thought" our SDG6022X had developed a problem (see attachment). Figured the AWG somehow got hosed it up and causing the squarewave with issue shown. Checked everything over and over, even started a post and when back before posting and tried to "think" what could cause this, and rechecked everything again, nope nothing found. Then we reminded ourselves KTI (Know Thy Instrument), and went back a 3rd time and sure enough we had the output waveform combine turn "ON", dumb arse |O
We have other equipment from Konrad, Tonghui, Hioki, GW Instek, Rigol, Pico, Tektronix, LeCroy, Micsig, Analog Discovery and so on, and tend to do our homework before acquisition and don't like to return things unless they are defective, or totally misleading.
We have a pro-equipment mentality, and a pro-support mentality, meaning we don't want to take advantage of suppliers and such as they are the life blood of our chosen field, and without such we would be back in the electronics "dark ages", but also don't hold back when somethings not right, and/or equipment is misleading in performance expectations (many stories behind this).
Anyway, as always YMMV and we've certainly got good mileage from our Siglent gear!!
Best,
-
Well, Siglent certainly has loyal customers/beta-testers/consultants here -- so they must be doing something right! :-+
Thanks for you long post, 2N3055. You make several valid points. I'll comment on just a few aspects where I don't concur:
As to expectations, fact that Siglent is still keeping this scope in active development and keeps adding features long after release should not be confused with "Siglent promises to keep adding major features that will with time convert a 1000€ scope into same capability as 20000€ LeCroy".
Realistically, manufacturer will add features to keep scope competent contender in a marketplace where it belongs. They might add a bit more to keep it fresh and to keep certain strategic advantage. But mostly never it will grow so much to exit it's class and enter one above. For both strategic and technical reasons.
Can we please keep this discussion fair and level. I don't think I suggested anything unreasonable which would catapult the scope out of its class:
- The ability to "trim" a captured waveform and send it to the AWG -- such that a full period is played back, rather than some arbitrary chunk which happens to fit the screen width -- is standard on pretty much every DSO with a built-in AWG, to my knowledge.
- Filters (as a Math operation) are also standard in this class, e.g. on the RTB2000, DSOX1200, MSO5000. The SDS2000X+ is the odd one out here, since it apparently still does not have them. And while I get it that going beyond 2 math channels would stretch the computational resources too much, I can't see why simple FIR or IIR filters should require more computing power than other math operations.
- Being able to configure a WiFi dongle is not standard yet. But since Siglent have this feature in the lower-end scopes, and actually have the RTL8188 driver up and running on the X+, it seems like low-hanging fruit and a nice differentiator.
So please don't give a distorted view of user expecations here.
As for development and release schedules, that is also interesting and not so simple topic.
[...]
In addition to that, modern practice to develop software on fixed released schedules without and regard to quality or completeness of code has shown catastrophic results for quality of code.
Just look at Rigol which released 4 different new scopes (4 products) based solely on management decision to stick to aggressive timetables. [...]
This is what you get if you have to release software twice a year instead of when it's done..
Sure, I know about dependencies, platform approach etc.; I have been working in industrial instrument R&D for a long time. I specifically suggested that Siglent switch to a time-boxed approach once the product is in "sustaining" mode, with incremental feature additions and bug fixes -- not for new development. No need for shadow-boxing, please.
None of the "big boys" will ever commit to any schedules or feature.
FW updates are in a way a strategic resource, nobody wants to open their cards..
I thing Siglent is actually doing a better job in this regard.
Again, commiting to features upfront is not what I suggested. The idea is to commit to a timeline cadence for updates -- so customers see that you are still committed to the product, and don't keep scratching at your door to ask when the next update will come. Keep the scope of the release open, to manage technical risk and keep some flexibility in the resources you can assign to firmware improvements.
Maybe this is not standard in the industry. I am not saying that Siglent is doing worse than other brands. But I think this would be a realistic approach how they could do better than the competition.
I do try to keep discussion fair and level. If I fail sometimes that is because of me being human. There will always be misunderstandings and failing to explain things in a way others can easily understand. Fact that most of us are communicating in second language does not help either.
I would just like to respond to you on few things I would like to point out.
I was talking about expectations in regards to capabilities as released/ few years later on the same scope. Not compared to other scopes in same class.
Those other scopes also have many shortcomings and architectural differences that benefit some features and are impeding others.
They work with smaller memories and decimated data.
As I said, a simplified Filter package just for 2000X+ probably could be made. But not very likely only for it.
If they find a way to run full filter package you will get it. Filtering also might be connected with manual control of sampling rate...
As for cadence of updates, in my opinion, those agile development processes are producing horrible code quality. Because they shift priority from quality or even functionality to regular releases. So big, chunky problems sometimes are not even solved because they don't fit into framework.. I have several friends working in very serious software development and they tell me horror stories all the time.
As I said, development of firmware is very interdependent. Sometimes one part waits for other.. Regular releases without substance but with full regression test nevertheless are huge resource hog. It is something Boeing does to US military because their contracts allow for it. And they have to give proof of progress all the time..
When you are doing most efficient internal development, on a stable and mature device, you obey your priorities. And you don't release just to throw dog a bone. I believe Siglent wouldn't do that to their customers, out of respect. When they have something of substance they release it. Otherwise they are not insulting customers with trivial distractions...
Just to make sure, I am not belittling your opinion but trying to give you more insight into process..
-
So big, chunky problems sometimes are not even solved [in a time-boxed development process] because they don't fit into framework..
Looking back over the firmware release notes, what would be examples of big, chunky problems (or features), requiring major changes to the existing framework, which Siglent tackled in the 2000X+ after its release?
[...] trying to give you more insight into process..
Thanks. As mentioned, I have done and led R&D for scientific instruments (which do of course include firmware and PC software these days) for a few decades, so I get the idea. ::)
I am still a firm believer in time-boxed releases, for the incremental features and bug fixes that typically get implemented after a product has shipped. I don't see why would not be entirely feasible, with good product quality, and with happy customers.
...
Heck, am I the only one who gets disappointed when tautech indicates that we will eventually get another firmware release (with a new major version number, and after more than a year of no user-facing updates) -- only to be told by Performa01 that it will not be a major update, but will comprise a single, small new feature? :-\
Oh -- I am the only one, at least in here? Never mind, I'll shut up then...
-
Heck, am I the only one who gets disappointed when tautech indicates that we will eventually get another firmware release (with a new major version number, and after more than a year of no user-facing updates) -- only to be told by Performa01 that it will not be a major update, but will comprise a single, small new feature? :-\
You made an assumption based on a version number without any other information. I miiiight have had a similar thought, but since nothing specific has been confirmed, I'm not going to get excited about it.
I want my scope to be and remain stable. That's what I care about. The biggest bug that bugs me is the popup not going away on its own after taking a screenshot. I'm pretty sure that's going to be taken care of in the next firmware update. Beyond that, I hope it keeps working forever until I get bored and get something shinier and newer.
My only big wish for the scope would be a more efficient bode plot that doesn't take as long. But I can live with it as it is if I need to.
-
Heck, am I the only one who gets disappointed when tautech indicates that we will eventually get another firmware release (with a new major version number, and after more than a year of no user-facing updates) -- only to be told by Performa01 that it will not be a major update, but will comprise a single, small new feature? :-\
As mentioned there will be improvements that won't be mentioned in release notes....there always is.
However full tests of this FW need be made and errors sorted.....
Adding new features logically happens on platform level and then gets propagated to it's members, based on product placement, architecture and technical details.
This ^
One improvement hoping to be rolled into 2kX+ and gradually into all models is colored trace markers in Digital mode....a little but nice improvement I suggested some months back which was accepted by Siglent and endorsed by all beta testers.
Improvement is continual......just as it should be.
However development teams currently also have a lot on their plate......
-
I'm pretty sure that's going to be taken care of in the next firmware update.
Me too. ;)
The Scope has been on the market for 3 years, here is an (incomplete) list of innovations and improvements that have been incorporated since then in addition to the bug fixes.
- Supported to hide analog traces
Added function expression information to the math box
Frequency counter supported to count serial trigger events
Supported Sign as a math function
New serial protocols supported (optional):
SENT, trigger & decode
Manchester, decode only
Measurement enhancement:
Supported user-defined thresholds (Upper, Middle and Lower): Measure | Config | Threshold
Added items: +Area@AC, -Area@AC, Area@AC, AbsArea@AC
Math: added new operator – Interpolate
Display:
Supported selectable color for traces: Display | Color Setting
Supported floating menu so that the waveform is not compressed horizontally when the right-side menu is displayed: Display | Menu Style
Supported to show bandwidth information on the channel descriptor box
Save/Recall:
Added option “Save all channel” for csv file
Supported to save math traces (except FFT)
Supported serial trigger as source of the frequency counter
Unlocked zoom in stop mode for Roll
Supported trigger Default or AutoSetup operations by pressing corresponding button twice
Measurement enhancement:
Supported cursors for measurement
Supported Track plot
Added parameters: Positive Slope and Negative Slope
Display:
Supported to display axis label
Auto hide menu setting increased to 10 seconds
Added “Hide” button in the fast menu of channel for quickly hiding trace
Save/Recall:
Supported network storage
Supported to Print only grid area
Supported to save FFT result
Updated the File Manager
Bode Plot:
The maximum generator amplitude changed from 6Vp-p to 24Vp-p
Supported single sweep
Horizontal: Time Zero strategy updated – time zero changed from center display to trigger position.
Supported setting Cursors by virtual keypad
That's quite unique from one manufacturer, I don't know of any other, so we should "turn a blind eye" if there hasn't been another banger recently.... ;)
-
Being able to configure a WiFi dongle is not standard yet. But since Siglent have this feature in the lower-end scopes, and actually have the RTL8188 driver up and running on the X+, it seems like low-hanging fruit and a nice differentiator.
You don't need a wifi dongle if it's that important to you. You can connect a TL-WR902AC or TL-WR802N or similar to connect your scope via wifi. The wifi dongle idea limits your ability for range and speed.
This ^
You configure them in bridge mode where they become totally invisible to the WiFi network and can also be used on any LAN capable instrument for WiFi connectivity. < done it and these USB powered LAN > WiFi adaptors work just like magic.
While typing this another thought comes to mind that I have yet to try is using one in conjunction with a switch so to provide a # of LAN capable devices with LAN > WiFi connectivity....no reason why it won't work and therefore becomes far more useful than a single USB WiFi dongle providing connectivity to only a single instrument.
-
Improvement is continual......just as it should be.
However development teams currently also have a lot on their plate......
That summarizes my concerns nicely. Improvement is continual, until it peters out because the company's attention shifts to newer products. Where is the SDS2000X+ on that curve?
No doubt it was a great buy 2 or 3 years ago (when I was not in the market for a new scope). But what I am tempted to read into the various comments made here is that it has reached the limit of its technical capabilities -- due to its memory architecture, a not-so-powerful CPU, combined with the ambitious approach of doing everything on full-resolution data.
As mentioned before, the 2000X+ is still the best match for my needs today. But "today" seems to be a time where next-generation scopes in its price bracket will hit the market soon -- be it the SDS1000 HD from Siglent or a DHO1000 upgrade with LA and AWG from Rigol. I don't see the commitment (or ability) from Siglent to keep the X+ fresh in that situation, but rather a focus on the newer 2000 HD and 1000 HD, positioned somewhat above and below it.
So maybe today is not the time to buy a scope in this price range at all, if I don't have an immediate need?
-
Improvement is continual......just as it should be.
However development teams currently also have a lot on their plate......
That summarizes my concerns nicely. Improvement is continual, until it peters out because the company's attention shifts to newer products. Where is the SDS2000X+ on that curve?
It still has bugs and improvements required to become equivalent to later models.
-
That summarizes my concerns nicely. Improvement is continual, until it peters out because the company's attention shifts to newer products. Where is the SDS2000X+ on that curve?
Your concern is your prerogative.
Products are supported until there are no bugs to fix and platform cannot accept new stuff.
Where is SDS2000X+? Still in the active support, like we already said.
I have never said improvement is guaranteed. No A brand improves their products unless they are really forced. And then only for newly bought product. For instance, on Keysight 3000T if you bought full bundle, and later Keysight added new protocols, you would not get those. You have to buy them separately.
As example of big chunk of development I will mention rewrite of part of acquisition engine to support filters that were not even in the stars when platform was devised. Since you do understand the complexity you'll get my meaning.
As I said, Keysight's last release of FW for 1200 Series was 2 years ago. Same as R&S RTB2000. These scopes don't have a fraction of functions SDS2000X+ has. RTB2000 is a bit closer for 4x the price. Nice scope though.
There is simply no reason to release anything on predefined schedule. Nobody does that. And releasing some trivial things just to be able to say you released something is something that is being done for software products on rent/lease/subscription. And is done just for reasons to justify why people are paying for subscription. No additional quality stems from it. Quite the opposite most the time. Kudos to those exceptions that still do the good job despite.
As for competition and other models, they all have a place under the sun.
Rigol DHO1000, apart from 12 bit is otherwise simpleton scope in comparison. New SDS1000X HD will be class above.
Rigol DHO1000 MSO is a figment of imagination of Rigol fans. There is not a peep of anything like that on horizon.. not even a rumor from China...
By that logic it is never the right time to buy anything. There is always some new, prettier, shinier, glossier, more fancy product just few months away...
-
By that logic it is never the right time to buy anything. There is always some new, prettier, shinier, glossier, more fancy product just few months away...
In other words, we should all buy SDS7404A scopes.
-
I will put aside a hundred every month and in just under 23 years' time I will be ready. 8)
-
As mentioned before, the 2000X+ is still the best match for my needs today. But "today" seems to be a time where next-generation scopes in its price bracket will hit the market soon -- be it the SDS1000 HD from Siglent or a DHO1000 upgrade with LA and AWG from Rigol. I don't see the commitment (or ability) from Siglent to keep the X+ fresh in that situation, but rather a focus on the newer 2000 HD and 1000 HD, positioned somewhat above and below it.
So maybe today is not the time to buy a scope in this price range at all, if I don't have an immediate need?
Define "Next Generation"...
The rigol you outlined does not exist, perhaps in the minds of some who hope that something better than now avaible will come along.
And even then, such a model would "only" have the 12 bit as an advantage, nothing else.
With the 1000X HD it looks a little different, but basically the same, higher resolution, but less memory and sample rate (with 4 channels).
But that's a bit off-topic here.
You haven't even got your hands on the 2k+ yet, but you're worried that it won't be any better than it already is.
Relax.. ;)
-
Relax.. ;)
... says the guy who had the X+ when it was in its prime (relative to the market), and has since traded it for something better (and more expensive). ;)
-
If you can and want to spend more than twice as much then do it. ;)
The HD is currently the only scope that partially outperforms the Xplus and that comes at a price.
For me last year it was a fun purchase, nothing more.
It was only later that I noticed the benefits.
I am not a benchmark.
Read the only review on Batronix, it came from me and I still stand by it to this day.
-
I will put aside a hundred every month and in just under 23 years' time I will be ready. 8)
Imagine the amazing scope you'll get for that price in 23 years though! It will probably just be a chip for your brain, and no comment on where the probes plug in. 😇😉
-
I want my scope to be and remain stable. That's what I care about. The biggest bug that bugs me is the popup not going away on its own after taking a screenshot. I'm pretty sure that's going to be taken care of in the next firmware update.
Yes, V1.6.0 takes care of that.
This is a perfect example how too much "listening to customers" can easily backfire.
The feature has been introduced with the last official firmware (I think) and it had annoyed everyone in the beta team. Both the fact that the box pops up and won't go away by itself and also the prediction of the file name for the next screenshot, which is just annoying nonsense, because even an idiot can predict it themselves and doesn't need the help of the DSO for this, all the more so as the prediction can be plain wrong, e.g. when the user pulls the Flash Drive, in which case the next screenshot would go to the internal memory.
Yet this had been a customer request.
We had to make clear that even customers are just humans that make nonsensical requests at times.
So the final solution can already be seen in the SDS2000X HD:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5114079/#msg5114079 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5114079/#msg5114079)
-
So the final solution can already be seen in the SDS2000X HD:
And it already exists in SDS1000X HD and SDS6000A.
Screenshot message management must be consistent across the product range.
-
Gimme!
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1934763;image)
-
I will put aside a hundred every month and in just under 23 years' time I will be ready. 8)
Imagine the amazing scope you'll get for that price in 23 years though! It will probably just be a chip for your brain, and no comment on where the probes plug in. 😇😉
This discussion ist so tiring, every so many years over and over again. In the 1990ies plenty of people warned against buying a new PC, better wait a year, and get more for the money. Don't remember the fad in the 2000s, but in the 2010s it was about smartphones, where prices would drop in a couple months 'cos the next model would come out. Now with scopes.
:=\
When will people manage to wrap their brain around the simple fact that in rapidly evolving technology there is no such thing as "the right time to buy", at least from the bang-for-the-buck perspective?
Cheers Peter
-
When will people manage to wrap their brain around the simple fact that in rapidly evolving technology there is no such thing as "the right time to buy", at least from the bang-for-the-buck perspective?
That's simply not true. There is a right time to buy if you're looking for better pricing. Certain times of year give better discounts. Whether you pay $1000 or $1400 for the SDS2104XP depends on whether or not they're running a sale.
With phones specifically, you're especially wrong. What phone manufacturers do from one year to the next is usually stupid BS like mostly the same phone with a slightly faster processor. Not exciting. They also hide downgrades without mentioning them.
My phone is a OnePlus 9 Pro. I bought it when the 10 Pro was fairly new and going on sale with better pricing. The 9 Pro is a better phone with more antennas for better versatility with different providers. The 10 Pro reduced the amount of antennas and added a faster chip. There's a number of reasons I won't bore you with why the previous gen was better. I got my phone for a much better price with double the memory. I could have got another for half what I paid when they finally clearanced them out a few months later.
The point being if you know what you're looking at, and familiar with the actual specs of the devices you're comparing, you can make smarter choices.
-
The point being if you know what you're looking at, and familiar with the actual specs of the devices you're comparing, you can make smarter choices.
That's useless in the context. The one thing that might help is knowing exactly what you need, and not getting tempted by new features that beforehand were deemed not to be needed. But even then the thought would pop up that the very set of features deemed to be needed may be available cheaper next year. So in addition, you'd need to set a budget, buy, when the features fit into the budget, and better not keep looking at prices.
On the other hand, understanding that a general "right time to buy" doesn't exist provides for the relaxed attitude that allows you to look at future prices without regret.
Cheers Peter
PS.: Better forget about sales. If you deem your own time to be worth anything, then you'll find that looking out for when the device you want is on sale costs you so much time that in the end you paid more than just paying the normal price. With sales, you just trade in time and effort for a little price reduction.
-
PS.: Better forget about sales. If you deem your own time to be worth anything, then you'll find that looking out for when the device you want is on sale costs you so much time that in the end you paid more than just paying the normal price. With sales, you just trade in time and effort for a little price reduction.
That depends on whether or not somebody is in a hurry. I wouldn't wait 2 months to save $20. OTOH, if you already have a scope, and you want something better, saving $400 off of a $1400 scope is significant. If you can't wait, you can't wait. Those are different situations. You can't speak for everyone regarding the urgency of their purchase or the specs they require. Pricing is more of a concern for hobbyists/home users than what most corporate budgets care about. But whatever, I'm content with my SDS2504XP. I'd be surprised if I ever need anything better. 🤷
-
Wondering if this is a bug in the I2C decoder.
The screenshot shows a READ operation of 4 bytes from a standard 2kBit EEPROM, connected by a I2C bus that has somewhat borderline pull-up resistors. Even though being borderline, bus semantics are properly followed, as you can see by close inspection. First we see the dummy write, setting the internal address register to 0. Then, without a STOP, but with a START, a read operation commences. The address (0xA1) is decoded fine, and also the first byte sent by the EEPROM (0xFE). Then, for no apparent reason, the decoder looses sync and fails to decode the following byte (red arrow). Following bytes (green arrow) are decoded wrong, more specifically, they are shifted by one bit. Interestingly, on a following bus operation (not shown in the screenshot), the bits are also shifted in the same way, even though a STOP and a following START condition would have provided the opportunity for the decoder to re-sync.
What do you think? Bug?
Cheers Peter
PS.: I've added two screenshots. The first one shows the mentioned failure to recognise a STOP/START condition for resynchronisation. The second one shows where it, after loosing sync, suddenly starts decoding a new command, that on the bus would require a START condition (at least), where obviously there is none. The C3 trace shows low-pulses where a ACK/NACK just has been transmitted, and the first bit of the next byte is about to start.
-
Without a CS try adding some Trigger Holdoff.
The packet above is ~200us long, try adding 250-300us to prevent the tigger rearming before the packet is finished.
-
Why do you think triggering is related to the issue?
From my point of view, there are traces that show signals from a specific time window of 200µs at some instance in time. This acquired data is what the decoder has to work on. Now, it is clear that if the traces would start right in the middle of an ongoing transmission, the decoder has nothing to sync on at the beginning of the trace, but even then it should resynchronise when it sees START or STOP conditions. But even that is not the case. The trace starts at a time when the bus is idle, and consequently the decoder start decoding porperly, and then suddenly looses sync. Later in the trace, the decoded information is inconsistent with the traces. This should not happen.
I completely fail to see any connection to the triggering.
Please note I'm not triggering on a bus event, but use normal edge-type triggering.
Cheers Peter
-
Why do you think triggering is related to the issue?
I never got the I²C signal from the Batronix demo board to trigger properly.
But when I stopped and scrolled through the table, the data was visible without dropouts.
-
Well 1 thing that's going bad, is my new probes that came with the sds2204x+. I really haven't used the scope that much, but already, my green probe gets attenuated maybe 20-30% when sitting in certain positions. It seems to be at the end where the probe meets the coax cable.
Now the same thing happened to my other Siglent probe sets, and similar ones I bought online once. But none as quick as the new problem one. I try to be careful with them, so IDK what's happened.
How hard is it to repair these, do you need some special tools and parts? Maybe it's not worth it, or too hard to do it right.
Any other uses for the cable ? I know it's not regular 50R coax.
-
Why do you think triggering is related to the issue?
The spikes on Ch2 here:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1943961)
From my point of view, there are traces that show signals from a specific time window of 200µs at some instance in time. This acquired data is what the decoder has to work on. Now, it is clear that if the traces would start right in the middle of an ongoing transmission, the decoder has nothing to sync on at the beginning of the trace, but even then it should resynchronise when it sees START or STOP conditions. But even that is not the case. The trace starts at a time when the bus is idle, and consequently the decoder start decoding porperly, and then suddenly looses sync. Later in the trace, the decoded information is inconsistent with the traces. This should not happen.
I completely fail to see any connection to the triggering.
225us trigger offset is NOT Holdoff !
Please note I'm not triggering on a bus event, but use normal edge-type triggering.
Totally understood and I can see this in the Trigger tab. ;)
Using Holdoff and a Falling Edge for simple decoding illustrations is how I do it too but to trigger on specific bits one must use a decode trigger.
Holdoff is never shown/displayed so set it to a bit longer than a packet and show us the result.
-
But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.
-
Well 1 thing that's going bad, is my new probes that came with the sds2204x+. I really haven't used the scope that much, but already, my green probe gets attenuated maybe 20-30% when sitting in certain positions. It seems to be at the end where the probe meets the coax cable.
Now the same thing happened to my other Siglent probe sets, and similar ones I bought online once. But none as quick as the new problem one. I try to be careful with them, so IDK what's happened.
How hard is it to repair these, do you need some special tools and parts? Maybe it's not worth it, or too hard to do it right.
Any other uses for the cable ? I know it's not regular 50R coax.
P215 probes ?
Claim warranty. Probes = 1 year.
-
Wondering if this is a bug in the I2C decoder.
BTW, please state firmware version in use.
-
But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.
If it need be Stop'ed, Trigger or some other decode setting are not optimal.
-
But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.
If it need be Stop'ed, Trigger or some other decode setting are not optimal.
... or you might just admit that you misunderstood the problem and gave irrelevant advice. Happens to the best of us... ::)
We don't know if it had to be stopped to decode at all, or was just stopped to take the screenshot. And in any case, tweaking the triggering will not help because there is apparently another issue, which was shown to cause decoding problems even when triggering is taken out of the game entirely.
-
But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.
If it need be Stop'ed, Trigger or some other decode setting are not optimal.
... or you might just admit that you misunderstood the problem and gave irrelevant advice. Happens to the best of us... ::)
We don't know if it had to be stopped to decode at all, or was just stopped to take the screenshot. And in any case, tweaking the triggering will not help because there is apparently another issue, which was shown to cause decoding problems even when triggering is taken out of the game entirely.
Yes well I am considering getting a 2kX Plus out and showing results......
First we need see which FW was being used. :popcorn:
-
I currently have a Plus model in the house, but my STB-3 board is still a bit buggy when it comes to I²C decoding. ;)
-
I currently have a Plus model in the house, but my STB-3 board is still a bit buggy when it comes to I²C decoding. ;)
Yep yours is and when I visit Siglent next year you can be sure I'll be taking it up with them as all I have heard back about yours is crickets ! :horse:
-
Ok I'll check into warranty on the probes, thanks. I never yanked on them or tripped over them, so IDK.
Now I'm afraid that my "good probes" which cost +$100 for 4, also had a problem way early than I expected, and that's why I was using these new included probes from day 1. Or was I just giving the old ones a rest?
-
Ok I'll check into warranty on the probes, thanks. I never yanked on them or tripped over them, so IDK.
They are much better now however we did have a poor batch of P215 and Siglent have worked with their supplier to improve quality.
The shield connection was often poor and would make/break when flexed.
Member xrunner had one replaced and went on to fix the faulty one.
Here and investigations are in previous posts:
https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg4667176/#msg4667176 (https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg4667176/#msg4667176)
-
Why do you think triggering is related to the issue?
The spikes on Ch2 here:
Those spikes are real and are there because the master released data a little earlier than the slave asserts it for the ACK. They are harmless, because they happen during clock being low, hence they are ignored. They are not due to premature re-triggering. Please note there is no retriggering, as single acquisition was used. Acquisition is stopped, as ebastler pointed out before me.
From my point of view, there are traces that show signals from a specific time window of 200µs at some instance in time. This acquired data is what the decoder has to work on. Now, it is clear that if the traces would start right in the middle of an ongoing transmission, the decoder has nothing to sync on at the beginning of the trace, but even then it should resynchronise when it sees START or STOP conditions. But even that is not the case. The trace starts at a time when the bus is idle, and consequently the decoder start decoding porperly, and then suddenly looses sync. Later in the trace, the decoded information is inconsistent with the traces. This should not happen.
I completely fail to see any connection to the triggering.
225us trigger offset is NOT Holdoff !
I never claimed it is. I still don't see what's the issue with hold-off. I don't use it (in this case). Why should I?
Using Holdoff and a Falling Edge for simple decoding illustrations is how I do it too but to trigger on specific bits one must use a decode trigger.
I do not trigger on bits, but on the first clock edge.
Holdoff is never shown/displayed so set it to a bit longer than a packet and show us the result.
I did that anyway, and as I expected(*), the result ist basically the same. It lost sync one byte earlier, but repeating a few times I found it sometimes looses sync on one, sometimes on the other byte. This indeed seems to suggest that the decoder fails to cope with the borderline pull-ups, i.e. not rapidly enough rising edges. No issue for the chips on the bus, though, the I2C communication seems to work properly.
(*) With single acquisition, and the last clock edge many seconds to minutes before the trigger point, what's the point of hold-off?
BTW, please state firmware version in use.
The firmware is obviously the latest, 1.5.2r3. What's the point of trying to identify a firmware bug if the firmware weren't the latest?
-
With single acquisition, and the last clock edge many seconds to minutes before the trigger point, what's the point of hold-off?
Sure for single it shouldn't be needed however in Run mode the correct Holdoff gives rock solid triggering although with multiple packets coming through the payload is often changing.
I need make room on the bench to setup some examples......
-
But acquisition is stopped. The data signal is right there with all the bits, and a clean-looking clock too. Why can't it be decoded? I also fail to see how triggering could get in the way.
If it need be Stop'ed, Trigger or some other decode setting are not optimal.
Sorry, but this is bullshit. There are always cases where picking a specific instant in time (and none later) in a complex, non-repetitive signal is just not within the trigger capabilities of any given scope. This is particularly frequent on digital buses. You want to see that instant, and avoid having the scope re-triggering on later events, you choose single acquisition. That's what it's for. And after it triggered, it stops.
-
We don't know if it had to be stopped to decode at all, or was just stopped to take the screenshot.
In this case, I'm debugging firmware. I wanted to see the very first few transactions on the bus because those are the only ones where I know precisely what data is supposed to be transferred. So I set the scope to single trigger, and reset the MCU.
-
Sure for single it shouldn't be needed however in Run mode the correct Holdoff gives rock solid triggering although with multiple packets coming through the payload is often changing.
I need make room on the bench to setup some examples......
I don't think examples will be needed. Nobody is doubting that a holdoff time can be useful when triggering on complex recurring sequences. All we are saying is that holdoff is a solution which has nothing to do with slartibartfast's present problem. :-//
-
I had a hunch, and it looks as if it was right.
In the wild, perfect signals are the exception, usually signals are messy in one or the other way. Here, the borderline pull-ups. I added additional pull-up resistors (i.e. in parallel) up to the point where the resistance becomes so low that the EEPROM is getting close to the limit of it's driving capability. The signals are cleaner in the sense of rising much more rapidly. And lo and behold! The decoder works a lot better!
The first screenshot shows the previously shown first read transaction on the bus. Now the decoder keeps sync perfectly and decodes properly. The same is true in the second picture where it has to work with less samples per bit. On a side note: Here is in fact a bug in the firmware of the device I'm working on: It writes 15 bytes in a row, which these standard EEPROMs cannot handle this way.
So it seems to me that it is not a bug in the I2C decoder per se what I have observed, but a really lousy capability of dealing with less-than-perfect signals. This really could do with an improvement, as my original signals were still clean enough for the chips involved, so test equipment should also be up to the task.
Apart from that, a few minor observations and wishes on the scope:
- After one of the last upgrades (don't know which) it seems the option of choosing the storage path seems to have disappeared, I cannot find it anymore. Where is it? It is not where the manual says it is.
- I like the option to not include the menu bar in the screenshot, but can we get rid of the mouse pointer as well? That would be really good for using shots in documentation, where they should be clean. A menu bar is easy to edit out, a mouse pointer, possibly covering a bit of a trace, not so.
- After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?
- I believe it normally is not necessary to specifically unmount a USB drive before disconnecting it. At least, neither Linux nor Windows complains about an inconsistent file system, and I also found no hint of any such requirement in the manual. In addition, I cannot find in any menu any button that would trigger an unmount. However, I observed a few times, that after pulling out a USB stick, even after allowing several extra seconds to complete the write, the scope would not accept any USB sticks anymore.
Beyond these, I'm still very happy with the scope.
Cheers Peter
-
After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?
Should come with the next update - On my HD this has been already "fixed".
Edit:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5114079/#msg5114079 (https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5114079/#msg5114079)
-
I had a hunch, and it looks as if it was right.
In the wild, perfect signals are the exception, usually signals are messy in one or the other way. Here, the borderline pull-ups. I added additional pull-up resistors (i.e. in parallel) up to the point where the resistance becomes so low that the EEPROM is getting close to the limit of it's driving capability. The signals are cleaner in the sense of rising much more rapidly. And lo and behold! The decoder works a lot better!
The first screenshot shows the previously shown first read transaction on the bus. Now the decoder keeps sync perfectly and decodes properly. The same is true in the second picture where it has to work with less samples per bit. On a side note: Here is in fact a bug in the firmware of the device I'm working on: It writes 15 bytes in a row, which these standard EEPROMs cannot handle this way.
So it seems to me that it is not a bug in the I2C decoder per se what I have observed, but a really lousy capability of dealing with less-than-perfect signals. This really could do with an improvement, as my original signals were still clean enough for the chips involved, so test equipment should also be up to the task.
Apart from that, a few minor observations and wishes on the scope:
- After one of the last upgrades (don't know which) it seems the option of choosing the storage path seems to have disappeared, I cannot find it anymore. Where is it? It is not where the manual says it is.
- I like the option to not include the menu bar in the screenshot, but can we get rid of the mouse pointer as well? That would be really good for using shots in documentation, where they should be clean. A menu bar is easy to edit out, a mouse pointer, possibly covering a bit of a trace, not so.
- After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?
- I believe it normally is not necessary to specifically unmount a USB drive before disconnecting it. At least, neither Linux nor Windows complains about an inconsistent file system, and I also found no hint of any such requirement in the manual. In addition, I cannot find in any menu any button that would trigger an unmount. However, I observed a few times, that after pulling out a USB stick, even after allowing several extra seconds to complete the write, the scope would not accept any USB sticks anymore.
Beyond these, I'm still very happy with the scope.
Cheers Peter
It seems that nobody asked how thresholds for clock and data signals in decode setup was set?
Sometimes with edges that are slow, voltage threshold can, to significant degree, move where detection point is in time and screw up timing...
One thing that is sometimes confusing is that thresholds for trigger and decode are separate (you can copy them though).
-
It seems that nobody asked how thresholds for clock and data signals in decode setup was set?
This is a good point, I should have mentioned that I had set the threshold to exactly the same voltage as the trigger: 2V. Maybe I forgot because indirectly the info is there: in the trigger box. ::)
Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.
Cheers Peter
-
So it seems to me that it is not a bug in the I2C decoder per se what I have observed, but a really lousy capability of dealing with less-than-perfect signals. This really could do with an improvement, as my original signals were still clean enough for the chips involved, so test equipment should also be up to the task.
As 2N3055 has pointed out, the threshold levels play a major role when dealing with slow signals. This would be the first place to do any tweaking. And yes, decoders and triggers are completely separate modules, only connected by the possibility to copy settings either direction. The preferred way to deal with that is to set up the decoding until it works fine and the copy these settings to the trigger engine, which should then enable the triggering on specific messages.
- After one of the last upgrades (don't know which) it seems the option of choosing the storage path seems to have disappeared, I cannot find it anymore. Where is it? It is not where the manual says it is.
What does the manual say? The latest manual (EN01D) gives the same example as older versions to set the image format, default path and basis filename for screenshots together with some options for the visual appearance in chapter 29.3.2 on page 317. This is still valid even for the unreleased V1.6.0 beta firmware. This example isn’t a particularly good one, because BMP is certainly not the screenshot format of choice; what we really want is PNG!
- I like the option to not include the menu bar in the screenshot, but can we get rid of the mouse pointer as well? That would be really good for using shots in documentation, where they should be clean. A menu bar is easy to edit out, a mouse pointer, possibly covering a bit of a trace, not so.
I’ve never tried it (I do not use a mouse), but it’s said that the mouse pointer is not visible in the screenshot if you move it to the border of the screen.
- After hitting the PRINT button, a box appears saying "Saved to file ... / Next save as file ...". Is there a way to make that box disappear automatically?
It’s already in the V1.6.0 firmware and works exactly like in the SDS2000X HD and SDS6000A.
- I believe it normally is not necessary to specifically unmount a USB drive before disconnecting it. At least, neither Linux nor Windows complains about an inconsistent file system, and I also found no hint of any such requirement in the manual. In addition, I cannot find in any menu any button that would trigger an unmount. However, I observed a few times, that after pulling out a USB stick, even after allowing several extra seconds to complete the write, the scope would not accept any USB sticks anymore.
Since I’ve currently not set up a network connection, I do all picture transfers via USB stick at the moment. This includes 4 DSOs, where the SDS2000X Plus and HD see the most use by far and the USB stick is plugged and unplugged dozens of times a day. Never ever did I have any issues like that.
-
It seems that nobody asked how thresholds for clock and data signals in decode setup was set?
This is a good point, I should have mentioned that I had set the threshold to exactly the same voltage as the trigger: 2V. Maybe I forgot because indirectly the info is there: in the trigger box. ::)
Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.
Cheers Peter
I2C Protocol Signals menu.
For I2C protocol you have separate thresholds for SCL and SDA.
If you want for scope to "see" same thing as your hardware, check hardware thresholds and set it to similar value.
-
Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.
Huh?
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1944573;image)
SDS2354X_Plus_Serial_I2C_Thresholds
-
Why do you talk about thresholds (plural)? I can only set one threshold, presumably valid for both clock and data.
Huh?
Sorry for that, I messed that up, talking from memory, rather than checking.
In my measurements, both were set to 2V.
Cheers Peter
-
And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.
In I2C is is better if there are separate thresholds for High state and Low state.
Typical definition is that signal level is High if level is >70% and it is Low if level is <30%
Or different depending circuits used.
Other possibility is set threshold and hysteresis.
The decoder should use as precisely as possible the specified limit values according to the specification or the values used by the examined bus. Otherwise, the decoding may show an error even though the actual traffic is working or vice versa.
Anyway, it kind of bothers me that only one HI/LO threshold (with unknown hysteresis) is set for each signal (in this case for SCL and SDA) when in reality there is an accepted level window for 1 and an accepted level window for 0 and the level window between these are "undefined" status. Although these are not really hardcore analyzers. Still, it would be good to strive for better.
-
The preferred way to deal with that is to set up the decoding until it works fine
>:D Rookie's method (trial and error) to set up the decoding? >:D
I prefer to use an informed choice for the thresholds.
PS.: I think rf-loop has an important point.
What does the manual say? The latest manual (EN01D) gives the same example as older versions to set the image format, default path and basis filename for screenshots together with some options for the visual appearance in chapter 29.3.2 on page 317. This is still valid even for the unreleased V1.6.0 beta firmware. This example isn’t a particularly good one, because BMP is certainly not the screenshot format of choice; what we really want is PNG!
Shame on me, I was still on EN01C. But as you say, EN01D is no different (well, they chose to replace a font in EN01C that was really nice to read, particularly on screen, by one in EN01D that's rather awful on anything but printed on paper).
On the issue of the default path: Pages 312 to 314 each show a menu that has the option "Save Path" or "Recall Path" with "Internal" and "External". These options do not exist on my scope. When saving/recalling via mouse or on-screen-finger one can choose this via the file manager. This does not work, though, when hitting the PRINT button. So, concrete question: How do I set the scope up such that after powering up, without messing with menus first (i.e. by default), hitting PRINT saves the screenshot in a particular folder, that is not called 'SIGLENT', on the thumb drive?
The page you're mentioning explains all a sort of things by using menus. It does not explain how to set up defaults. In fact, the only sentence in the manual where the word 'default' refers to a path, is "The default save path is \SIGLENT\." (Page 318 EN01D)
I’ve never tried it (I do not use a mouse), but it’s said that the mouse pointer is not visible in the screenshot if you move it to the border of the screen.
I do not use a mouse either, as it takes too much space on a lab table. A trackball is just perfect for this purpose. What I cannot stand at all is fatty fingerprints on screens.
In any case, your suggestion is off the point. During normal workflow I would create screenshots during the development work, and when writing documentation, I choose from those. During development I do not have documentation on my mind, and certainly would not care where the pointer is. I wonder if this would be much different for anybody.
Since I’ve currently not set up a network connection, I do all picture transfers via USB stick at the moment. This includes 4 DSOs, where the SDS2000X Plus and HD see the most use by far and the USB stick is plugged and unplugged dozens of times a day. Never ever did I have any issues like that.
Same for me, I also used to save directly to my NAS, but I'm without network at the moment. So it's possible the issue was there before, I just didn't notice because I did not use thumb drives at the time. Well, I'll keep watching out, might be a hardware issue.
Cheers Peter
-
And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.
Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion
In I2C is is better if there are separate thresholds for High state and Low state.
Typical definition is that signal level is High if level is >70% and it is Low if level is <30%
Or different depending circuits used.
Other possibility is set threshold and hysteresis.
and would even prefer high / low thresholds over having separate thresholds for the two lines.
The decoder should use as precisely as possible the specified limit values according to the specification or the values used by the examined bus. Otherwise, the decoding may show an error even though the actual traffic is working or vice versa.
Correct. However, AFAIK I²C does not specify the thresholds. The values for the involved chips could be used, however the chips on the bus do not all have the same thresholds, and sometimes the master, sometimes a slave drives the D line, or listens to the level. A perfect decoder that takes all that into account is immensely complex, as it needs to figure out which device is driving the line at any particular moment.
Cheers Peter
-
And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.
Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion
No, there IS only one threshold for one signal in SDS2000X Plus, SDS2000X HD and many other Siglent oscilloscopes (and many others too). Example SCL (this is one signal in my context) have just one threshold. Can not define threshold for High state level and Low state level.
Here's an example of how NXP says general information related to their stuff and views on I2C definitions. (https://www.nxp.com/docs/en/user-guide/UM10204.pdf)
-
And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.
Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion
No, there IS only one threshold for one signal in SDS2000X Plus, SDS2000X HD and many other Siglent oscilloscopes (and many others too). Example SCL (this is one signal in my context) have just one threshold. Can not define threshold for High state level and Low state level.
Here's an example of how NXP says general information related to their stuff and views on I2C definitions. (https://www.nxp.com/docs/en/user-guide/UM10204.pdf)
Yet we can define the logic type/level when in Digital mode.
Maybe a small range of choices need be added for analogue decoding too ?
Something we need take to the Siglent forum ?
-
>:D Rookie's method (trial and error) to set up the decoding? >:D
I prefer to use an informed choice for the thresholds.
Didn’t expect that my words could be misinterpreted so badly (on purpose?) ::)
What I meant was of course that we set up the decoding first, including baud rate, polarity, idle level or whatever applies to the protocol in question, then test it and only when it runs okay, copy the settings to the trigger. I was talking about serial decode in general and the fact that I2C doesn’t have any specific settings apart from the R/W-bit inclusion is irrelevant here.
One can always make some mistake, such as wrong signal connections or inappropriate threshold levels. It is sensible to test this before happily copying to the trigger and just hoping that everything works and the scope will trigger on the right message…
On the issue of the default path: Pages 312 to 314 each show a menu that has the option "Save Path" or "Recall Path" with "Internal" and "External". These options do not exist on my scope. When saving/recalling via mouse or on-screen-finger one can choose this via the file manager. This does not work, though, when hitting the PRINT button. So, concrete question: How do I set the scope up such that after powering up, without messing with menus first (i.e. by default), hitting PRINT saves the screenshot in a particular folder, that is not called 'SIGLENT', on the thumb drive?
The page you're mentioning explains all a sort of things by using menus. It does not explain how to set up defaults. In fact, the only sentence in the manual where the word 'default' refers to a path, is "The default save path is \SIGLENT\." (Page 318 EN01D)
It might not be brilliant in a didactical sense, yet you just should have sticked to the page I’ve referred to.
It simply works as follows:
In the SAVE menu, you select the appropriate type (PNG), image style and menu inclusion and then you launch the File Manger:
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1944750;image)
SDS2354X_Plus_File Manager
Now you see the internal memory (local) as well as any externally plugged thumb drives (U-disk). You select the external U-disk here. 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.
Now you select the U-disk, navigate and subsequently use the “New Dir” command to create a new folder wherever you want with whatever name you like, then navigate into that folder and save the PNG file under an arbitrary name that you like. Bingo!
This very first screenshot will be saved just with the name you’ve typed. All subsequent screenshots (initiated by the blue “Print” or “Save” button will go to the same folder and have the same filename, but get a sequence number appended. The sequence number starts with “2” in this special case; after emptying the screenshot directory on the PC, sequence number will be reset to “1”.
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1944756;image)
Custom Screenshot Save Path
If you forget to plug your U-disk in, the scope automatically stores to the internal memory. If it was a precious, irreplaceable screenshot, then you can insert the U-disk and copy the file using the File Manager. Otherwise, you can just delete it – or leave it where it is until you run out of internal memory one day...
-
And if we want make better.
Oscilloscope decoder need have more settings for signals.
Now there is only one threshold for one signal.
Sorry, that was my mistake. There are indeed two settings, separate for CK and D. But I share your opinion
No, there IS only one threshold for one signal in SDS2000X Plus,
I guess there is a misunderstanding at work here. If by "one threshold for one signal" you mean "one threshold per signal" then we're in sync. In an earlier posting I stated falsely that there is only one threshold that applies to both signals. I had thought you were referring to that.
-
>:D Rookie's method (trial and error) to set up the decoding? >:D
I prefer to use an informed choice for the thresholds.
Didn’t expect that my words could be misinterpreted so badly (on purpose?) ::)
Well, since I'm used to well-informed postings from you I suspected that what you wrote was not exactly what you meant. That's why I used two flashy devil smileys to make it very clear that I wasn't serious.
Didn't expect that two such smileys in those locations aren't enough to make that obvious.
What I meant was of course that we set up the decoding first, including baud rate, polarity, idle level or whatever applies to the protocol in question, then test it and only when it runs okay, copy the settings to the trigger. I was talking about serial decode in general and the fact that I2C doesn’t have any specific settings apart from the R/W-bit inclusion is irrelevant here.
What you write here I indeed cannot find in your original words, at least not with my (admittedly very limited) capability of english understanding.
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.
One can always make some mistake, such as wrong signal connections or inappropriate threshold levels. It is sensible to test this before happily copying to the trigger
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.
On the issue of the default path: Pages 312 to 314 each show a menu that has the option "Save Path" or "Recall Path" with "Internal" and "External". These options do not exist on my scope. When saving/recalling via mouse or on-screen-finger one can choose this via the file manager. This does not work, though, when hitting the PRINT button. So, concrete question: How do I set the scope up such that after powering up, without messing with menus first (i.e. by default), hitting PRINT saves the screenshot in a particular folder, that is not called 'SIGLENT', on the thumb drive?
The page you're mentioning explains all a sort of things by using menus. It does not explain how to set up defaults. In fact, the only sentence in the manual where the word 'default' refers to a path, is "The default save path is \SIGLENT\." (Page 318 EN01D)
It might not be brilliant in a didactical sense, yet you just should have sticked to the page I’ve referred to.
It simply works as follows:
Why should I have assumed that what you choose in the file manager also applies to the PRINT button, let alone surviving a reboot? To me, this is far from obvious. IMHO it flies in the face of user interface good practices, because it is not intuitive. Brilliant or not, the manual just does not have this information.
I will play with that a bit tomorrow.
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.
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?
-
I use copy to trigger and back quite often.
It not only copies levels, it does it for all the signals and also signal to channel assignments and other parameters.
For full SPI that is 4 channel assignments and level for each.. and other settings..
I connect, capture single, set timebase, capture again, go to decode, setup signal connections and levels. Once I get meaningful result, copy to trigger. No need to set 10 parameters again.
-
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.
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.
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.
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.
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.
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?
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….
-
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.
-
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.
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.
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.
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.
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:
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.
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?
Yes, I found it out immediately – and quite honestly, this is something I set once in my lifetime and then forget about it.
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?
-
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:
https://www.youtube.com/watch?v=cS8qT2--0-s (https://www.youtube.com/watch?v=cS8qT2--0-s)
Maybe someone can try to reproduce this?
-
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.
-
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.
I've tried with both Ch.1 + Ch.2 and also Ch.3 + Ch.4, but was unable to reproduce this particular behaviour with FW 1.6.0, HW 02-00.
In General, Sequence Recording can be unresponsive, because the difference to normal mode is exactly that it only acquires the number of specified segments, while not drawing anything on the screen and ignoring most user inputs. On the other hand, I've never seen a "processing" message before in the lower right corner (only "Acquiring..."), so there might be something wrong indeed.
Since I cannot reproduce any of this with FW 1.6.0 I take it that this bug will be solved with the next public firmware version.
-
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.
I've tried with both Ch.1 + Ch.2 and also Ch.3 + Ch.4, but was unable to reproduce this particular behaviour with FW 1.6.0, HW 02-00.
In General, Sequence Recording can be unresponsive, because the difference to normal mode is exactly that it only acquires the number of specified segments, while not drawing anything on the screen and ignoring most user inputs. On the other hand, I've never seen a "processing" message before in the lower right corner (only "Acquiring..."), so there might be something wrong indeed.
Since I cannot reproduce any of this with FW 1.6.0 I take it that this bug will be solved with the next public firmware version.
I have reproduced it also with FW1.6.0 (HW 06-05)
ETA: for reproduce this, mode need be 8bit
Also if Timebase is still 500us/div and zoom window timebase is 500ps/div this same problem exist but now only ifcombination: Interpolation=Sinc, display type=Dots
"Processing" bar appears and continue infinitely...
later when I get some free time I try find what is procedure how it can repeat... (do it need using some special order or what.) Also never seen this before and I have used Sequence quite lot.
ETA: after Security erase and factory defaults, it happen just simply.
There need be Ch1 and Ch2 on only OR Ch3 and Ch4 only. With other combinations I can not reproduce this
(https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/?action=dlattach;attach=1973466;image)
-
Hi,
Does the FW 1.6.0 will support Math Digital Filter and 4 Math traces (F1~F4)?
-
Hi,
Does the FW 1.6.0 will support Math Digital Filter and 4 Math traces (F1~F4)?
Not.
-
Does the FW 1.6.0 will support Math Digital Filter and 4 Math traces (F1~F4)?
It has been stated several times already that there are not enough HW resources (FPGA, RAM) in the SDS2000X Plus to support any resource-hungry additional features, like math channels as well as the traditional ERES and Average acquisition modes. After all this is an alalysing oscilloscope with deep math and measurements, which does not work on heavily decimated (or even just screen) data.
It is different for the filter math. This has been shown to be operative with a beta version of FW 1.5.2 already, but had to be disabled because the full filter functionality also requires the extended memory management which supports fixed sample rate like on more advanced instruments such as the SDS2000X HD. This feature in turn is not yet ported to the SDS2000X Plus and this is a low priority task, so it might take a while. It is not in the 1.6.0 frmware, but I'd expect the next pulic FW release to be one step ahead.
-
I have reproduced it also with FW1.6.0 (HW 06-05)
ETA: for reproduce this, mode need be 8bit
Also if Timebase is still 500us/div and zoom window timebase is 500ps/div this same problem exist but now only ifcombination: Interpolation=Sinc, display type=Dots
"Processing" bar appears and continue infinitely...
Thanks for checking this out. Was already thinking I might have a faulty device... :-//
In 500µs/div timebase and zoom window timebase at 500ps/div I can confirm the problem exists, but it doesn't make a difference whether I choose Vector or Dots mode. In Vector mode, it seems to be dependant of the number of Sequence Segments selected in Sequence menu and there is a delay until which the problem occurs:
(Settings: 500µs/div timebase, 500ps/div zoom, Sinc interpolation, Vector mode, 8 bits Resolution, 10 M max mem depth)
- with 2 Seq. Segments: nearly instanteous
- with 3 Seq. Segments: around 10 to 12s
- with 4 Seq. Segments: about a minute
- with 5 Seq. Segments: can take several minutes: measured 1'20'', 0'12'', 3'15'' and 1'55''
When the bug occurs, "Clear Sweeps" button (or Display -> Clear Display) resets it and the trace is shown again until bug gets triggered again after some time.
Max mem depth has to be at 10M or 100M. I haven't seen it on the lower settings.
Bug seems unaffected by any vertical settings so far. I used the probe calibration square signal on Ch 1 and have put Ch 2 to GND and it's still reproducable.
-
When using the scope with digital channels but NO analog channels, it would be great if the vertical scale labels (voltage) were turned off, as it interferes with the labels for the digital channels, and isn't relevant. I know I can turn off all axis labels, but would like to keep the timebase labels.
-
Is the approximate release date for the new firmware known?
-
To the experts among us,
I got a nice I3C demo project with a Microchip PIC18F16Q20: https://github.com/microchip-pic-avr-examples/pic18f16q20-i3c-getting-started-mplab-mcc and a STMicro Sensors (LSM6DSO32) with I3C support: https://binho.io/blogs/i3c-articles/stmicro-sensors-with-i3c-support-available-now
Will the firmware upgrade 1.6.0 also include support for a new serial I3C decoder?
Cheers, mathstudi
-
I found a weird behaviour today saving images.
First I plugged in an USB stick and it was commented something like "stick found".
Upon pressing the "print" I was reminded that the image was saved. Each time, it incremented the name by one.
After the session I took out the stick to read the images on the PC, but there was nothing on it. So probably it saved to "internal". Back to the scope, there were no images in the internal memory either. Just to be sure, I took another one and it showed up as the one and only in the internal memory.
As I wanted to move this to the USB stick, that I again placed into the connector, I found that it had not been recognized at all. No "external". I tried with several sticks - none of them are recognized anymore, although they are good at the PC.
Did I break something? Can I convince the scope to at least format one? Do I have to prepare on specially to get it recognized again?
I'm a little confused. This has been working before. :-//
I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?
-
I found a weird behaviour today saving images.
First I plugged in an USB stick and it was commented something like "stick found".
Upon pressing the "print" I was reminded that the image was saved. Each time, it incremented the name by one.
After the session I took out the stick to read the images on the PC, but there was nothing on it. So probably it saved to "internal". Back to the scope, there were no images in the internal memory either. Just to be sure, I took another one and it showed up as the one and only in the internal memory.
As I wanted to move this to the USB stick, that I again placed into the connector, I found that it had not been recognized at all. No "external". I tried with several sticks - none of them are recognized anymore, although they are good at the PC.
Did I break something? Can I convince the scope to at least format one? Do I have to prepare on specially to get it recognized again?
I'm a little confused. This has been working before. :-//
Do you have the USB stick formatted FAT32 and preferably 4k clusters ?
Try a reboot.
I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?
Yep still the current version however V1.6.2 is with beta testers.
-
I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?
Yep still the current version however V1.6.2 is with beta testers.
Played with V1.6.2 last night and some cool things have been added.....can't wait for it to go public.
One little teaser screenshot....teaser I said and replaced with another....
-
As an E02A documentation update request for the "How to Extract Data from Binary File..."
Did just used a hex editor to analyze the content of a 32M file and found the following:
- Version is already Version 4, as on manual page 37 only mentioned for SDS200X HD after 0.9.6 & SDS5000X & SDS 6000 after 1.4.1.0
- the starting of data is located at 0x1000
- the data is as word offset binary (16 bit values)
Example as using the extract tool to get the decimal text values from the csv file
Data on Bin Text on csv file
33600 1.08E-04
33600 1.08E-04
33408 8.33E-05
33472 9.17E-05
33600 1.08E-04
33600 1.08E-04
33472 9.17E-05
33600 1.08E-04
- there is some complete false: Convert the Data to Voltage
Formula on page 46: voltage = (data-128) * ch_volt_div_val /1000/code_per_div + ch_vert_offset
as this formula is for 8 bit data as data-128
- In addition the mystery: Code_per_div is 25 as mention for SDS1000 & SDS2000X... so for the binray offset is this still valid?
And updated Version 4 documentation or corrected calculations are welcome...
Hp
-
I would like to believe that colored digital channels are not the only significant innovation in 1.6.2. ;D ;D ;D
-
I would like to believe that colored channels are not the only significant innovation in 1.6.2.
It's not, the Fade saved file feature already in some other models is also added.
So far we have not seen release notes but they will come at public release. ;)
Sorry you missed the previous teaser showing a Serial coms tester.
-
Yes, probably I missed the previous teaser...
I hope that soon I will be able to learn about all this on my own scope :)
-
One little teaser screenshot....teaser I said and replaced with another....
:(
-
I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?
Yep still the current version however V1.6.2 is with beta testers.
Played with V1.6.2 last night and some cool things have been added.....can't wait for it to go public.
One little teaser screenshot....teaser I said and replaced with another....
Hi Tautech,
Will the upcoming firmware version V1.6.2 have the following functions?
1. Selectable vertical label position (Left, Middle, Right) in Vertical Axis Label Setting like SDS800X HD?
2. Selectable font size (Large, Small) in Display Menu like SDS800X HD?
3. Selectable linear or decade display in FFT Horizontal Menu?
-
I just glimpsed at the firmware page, the latest one is still SDS2000X Plus_V1.5.2R3_EN.zip?
Yep still the current version however V1.6.2 is with beta testers.
Played with V1.6.2 last night and some cool things have been added.....can't wait for it to go public.
One little teaser screenshot....teaser I said and replaced with another....
Hi Tautech,
Will the upcoming firmware version V1.6.2 have the following functions?
1. Selectable vertical label position (Left, Middle, Right) in Vertical Axis Label Setting like SDS800X HD?
2. Selectable font size (Large, Small) in Display Menu like SDS800X HD?
3. Selectable linear or decade display in FFT Horizontal Menu?
1. Yes
2. Yes
3. Linear or Logarithmic
-
Proposed release date?
-
Let's be patient!
A professional and quality managed software release takes time.
I'm happy, the SDS2000X+ gets serviced some years after release. :-+
-
I may have missed the announcement again, but will there be automatic/manual control of memory depth in 1.6.2?
-
Let's be patient!
Not being impatient, just inquiring.
-
I may have missed the announcement again, but will there be automatic/manual control of memory depth in 1.6.2?
Only setting the max available. < nothing changed.
-
I may have missed the announcement again, but will there be automatic/manual control of memory depth in 1.6.2?
It has often been noted over the years that, despite the same software platform, certain features will not be available for all models.
-
Has anyone tested the SigScopeLab software with an SDS2000X Plus?
It doesn't seem to work with firmware V1.5.2R3 (release date 04.03.23 ), maybe I'm doing something wrong. But it is an interesting approach.
I found the information at: https://int.siglent.com/download/softwares/?ProId=53
-
Does anyone know if I can export / save waveform data as a single binary file instead of a separate binary for each channel? The 1000X X-E has all waveforms saved as a single bin and it is pretty convenient. Also, is there an easy way to convert a large batch of binary files?
-
Has anyone tested the SigScopeLab software with an SDS2000X Plus?
I tried using this software.
Unfortunately, it does not work correctly with SDS2000X+. The timebase is not set correctly, it is in the range from 5 sec/div to 1 sec/div, regardless of what you set from PC. Maybe with the new firmware (when it released) the situation will improve, but for now this software useless for SDS2000X+ owners.
-
Has anyone tested the SigScopeLab software with an SDS2000X Plus?
It doesn't seem to work with firmware V1.5.2R3 (release date 04.03.23 ), maybe I'm doing something wrong. But it is an interesting approach.
I found the information at: https://int.siglent.com/download/softwares/?ProId=53 (https://int.siglent.com/download/softwares/?ProId=53)
Read on for the Banana ware https://www.eevblog.com/forum/testgear/siglent-sigscopelab-how-it-goes/ (https://www.eevblog.com/forum/testgear/siglent-sigscopelab-how-it-goes/)
-
Hello :)
I'm thinking of upgrading to an SDS2000X HD or SDS3000X HD.
Is anyone interested in buying my 2104X Plus ?
-
I might, but this kind of sales rarely turn into a better offer than getting the scope without VAT.
-
As using latest given FW.
Now getting repeated DSO hangings as saving a BIN file to external USB Stick. Error checking the USB did not showed any errors. :palm:
Is this known? Or any chance to the the upcoming FW?
Some more about the culprit:
- I set the probe as 0.10 as 20dB gain given from the amplifier.... and this causes to crash after certain samples. This means, NOT fully written 1Gs & 100M-samples and as stopped on 5% indication.
In other situation it looks as OK, even 0.1 probe value. So may a math issue :-DD
- Setting the probe as 1:1 works
Update:
Getting repeated hangup's, I used FFT & 4x AVG as always on and C2 channel as Hide & 10ms & 1G/s to save 100M samples to a folder on the USB stick.
What works now after:
- Formatted 16G USB stick on Win10 as 4k & FAT32
- Did a DSO calibration
- Saved now to any folders using C2 channel on as 0.1x probe settings (gain of amplifier) and FFT OFF
Hp
-
firmware 1.6.2R1 was released today! :-+
-
Has anyone seen documentation for the new "Serial Signal Test"?
3/28/2024 1.6.2R1
1. Added new Analysis function: Serial Signal Test (Analysis | Serial Signal Test)
2 .Optimized UI
3. Supported USB-GPIB adapter
4. Fixed several bugs
a) "Bended" / "tilted" trace at small V/div
b) Math: Filter sample rate adaption cannot work
c) Frequency / Period measurements fail on certain waveforms
-
Has anyone seen documentation for the new "Serial Signal Test"?
3/28/2024 1.6.2R1
1. Added new Analysis function: Serial Signal Test (Analysis | Serial Signal Test)
2 .Optimized UI
3. Supported USB-GPIB adapter
4. Fixed several bugs
a) "Bended" / "tilted" trace at small V/div
b) Math: Filter sample rate adaption cannot work
c) Frequency / Period measurements fail on certain waveforms
Not in the doc yet AFAIK...
That is brand spanking new feature right from the oven.....
I don't have SDS2000X+.
What protocols are supported : I2C and SPI ?
-
Not in the doc yet AFAIK...
That is brand spanking new feature right from the oven.....
I don't have SDS2000X+.
What protocols are supported : I2C and SPI ?
Supported protocols are I2C and SPI.
Analysis -> Serial Signal Test.
Haven't tested the new function yet. I'll wait for the adapted documentation.
-
ARINC decoder was added (trial).
Parameters setup:
-
New UI update seems to lack anti-aliasing and the padding is also off, buttons are harder to press with fingers now..
I hope this will be reverted to be in the style of 1.5.3 :o
-
Not in the doc yet AFAIK...
That is brand spanking new feature right from the oven.....
I don't have SDS2000X+.
What protocols are supported : I2C and SPI ?
Supported protocols are I2C and SPI.
Analysis -> Serial Signal Test.
Haven't tested the new function yet. I'll wait for the adapted documentation.
These are what is called compliance tests.
They will automatically test number of critical parameters of protocol and compile a PASS/FAIL test report with data.
-
Small changes in FFT. Now we can find dF and RBW separately, and horizontal sweep can be switched log10/linear
-
This is a minor UI bug.
-
Small changes in FFT. Now log10/linear
Yes, this is nice
as it gets, was looking for any colors changing. Look at given pic's dark yellow text and lighter yellow line... so hard to see about the freq. axis values
-
New UI update seems to lack anti-aliasing and the padding is also off, buttons are harder to press with fingers now..
I hope this will be reverted to be in the style of 1.5.3 :o
Yes, I also noticed the anti-aliasing, but only when you pointed it out. It doesn't bother me, but it's an aesthetic thing that is perceived individually.
I like the serial decoders that I tested today. Too bad the documentation (Serial Signal Test for I2C and SPI) is not ready yet.
My bandwidth tests with the tinySA ULTRA were all positive.
Unfortunately there is no I3C decoder. This is probably a licensing problem, because there is no free I3C decoder for the saleae Logic Analyzer either, although many decoders are already included with the saleae.
What makes me happy is the fact that Siglent is still doing a great job of product maintenance. Especially that new gadgets are still being added.
Cheers
-
Small changes in FFT. Now log10/linear
Yes, this is nice
as it gets, was looking for any colors changing. Look at given pic's dark yellow text and lighter yellow line... so hard to see about the freq. axis values
Change your Scale or Ref level. :P
-
buttons are harder to press with fingers now.
Which button is more difficult to press? The size of the button looks the same. It would be even better if a picture could be attached.
-
Small changes in FFT. Now log10/linear
Yes, this is nice
as it gets, was looking for any colors changing. Look at given pic's dark yellow text and lighter yellow line... so hard to see about the freq. axis values
Change your Scale or Ref level. :P
Sometimes it is prefered to keep the full scale as to track the progress.
As only 20dB/div maximum scale possible, not any 25...30..40..50 given O:((
Now on print png, the text gets now some white/blue collor while saving.
-
Now on print png, the text gets now some white/blue collor while saving.
Do you have an example? The PNG should look just as the screen. Happening with the "print" button, or via web interface?
-
Now on print png, the text gets now some white/blue collor while saving.
Do you have an example? The PNG should look just as the screen. Happening with the "print" button, or via web interface?
As I told you, the axis x/y text gets this color while saving in progress. Only at that time and then come back to normal.
In addition, you will see scope & FFT axis X/Y color as quasi nor readable while it is NOT POSSIBLE to alter those line or axis colors.
So the request is simple :-DD:
- lets modify the colors as all SW allow this :-+
- add 25/30/40/50 dB/div :-+
- may as simple wish, to add scale dBV/rthz as a simple task :-+
-
Small changes in FFT. Now log10/linear
Yes, this is nice
as it gets, was looking for any colors changing. Look at given pic's dark yellow text and lighter yellow line... so hard to see about the freq. axis values
Change your Scale or Ref level. :P
Sometimes it is prefered to keep the full scale as to track the progress.
As only 20dB/div maximum scale possible, not any 25...30..40..50 given O:((
Now on print png, the text gets now some white/blue collor while saving.
What would be the purpose of 50dB/div ??
You think any system in the universe have 400dB instantaneous dynamic range?
On a 8 bit scope?
-
well, 50dB for a 4..5 x 50dB as 200..250dB full range as my pictures shows up.
-
One more wish:
- add the used FFT Window to the BIN file, so we know later on, what FFT Window has been used
- may add better performing FFT Window functions as BH7
-
well, 50dB for a 4..5 x 50dB as 200..250dB full range as my pictures shows up.
FFT has 8 vertical divisions. 8*50=400
You can also use split window.
-
As I told you, the axis x/y text gets this color while saving in progress. Only at that time and then come back to normal.
Are you complaining about the colors in your screenshot being inverted? That's a setting.
-
well, 50dB for a 4..5 x 50dB as 200..250dB full range as my pictures shows up.
FFT has 8 vertical divisions. 8*50=400
You can also use split window.
Look, the probe gain supports +1E6 to -1E6 so we get +/- 120dB ... so for 8 x 20dB Grid there is not much room left
-
About the color thing: this is possible and in the latest given documented.
To setup / change the colors:
[1] >> Display menu... then on the right go down until this settings sub menu entry is visible.
[2] only Math F1 or F2 as for line and axis text.
-
Three bug seen on V1.6.2:
[1] reboot and have setup as C2 & F1: you will see for a while the NOT enabled C1 input and than alters to C2 & F1
[2] using this setup: on the right side an 500Hz vertical line is drawn. See picture with red rectagle
[3] If you enable on C2 the axis text as level & time as I use right justify: the level Y axis text gets overwritten by the trace line
-
..
Haven't tested the new function yet. I'll wait for the adapted documentation.
These are what is called compliance tests.
They will automatically test number of critical parameters of protocol and compile a PASS/FAIL test report with data.
I actually wanted to wait for the updated documentation. But the interest in the new function was greater and so today I ran some tests with an I2C protocol.
I am impressed! I've been looking for something like this for a long time, especially for the popular I2C and SPI protocols.
This is exactly what I appreciate about Siglent, that even years after the market launch, new gadgets are still being added.
The "fail" with the "Clock Signal Frequency" is my mistake -> wrong configuration.
A report can also be generated (HTML/XML), which is quite impressive. I will do further tests.
-
Did 1.6.2 get yanked? Everywhere I checked is still 1.5.2R3 (int.siglent.com, siglentna.com, and siglent.com)
-
Yes, there were some problems (freezes) with the upgrade for some,
so the update has been withdrawn until further notice.
I think we have to wait here for now.
Regards Chris
-
That’s a bummer! I discovered my VNC no longer works properly after upgrading to the latest 1.5 version and found this thread where others seemed to have the same issue.
Hopefully the 1.6 version goes public soon so I can see if that fixes it.
-
That’s a bummer! I discovered my VNC no longer works properly after upgrading to the latest 1.5 version and found this thread where others seemed to have the same issue.
Hopefully the 1.6 version goes public soon so I can see if that fixes it.
I never tried connecting through VNC before 1.6, but it worked fine on 1.6.2R1 for me.
-
Unplugging everything and doing the Math button repeated press upon boot seems to have fixed it for now.
I had tried that last night but didn’t unplug the Ethernet cable. Unplugging it today and doing it seems to have worked.
-
Unplugging everything and doing the Math button repeated press upon boot seems to have fixed it for now.
Is that a thing? I don't remember reading about that.
-
Yea, I was closely reading Siglent’s directions last night…
[attach=1]
-
Yea, I was closely reading Siglent’s directions last night…
Yes, for boot freeze recovery.
Did pressing Default not work for you ?
-
Didn’t try that
-
Yea, I was closely reading Siglent’s directions last night…
I always wondered how rocket scientists are able recover their gadget a zillion miles away, when it choked on the last command, wrecked the antenna and drained the batteries.
If designed carefully, there is always another Plan-C, bypass, backdoor and spare circuit that can jump in
if everything else is broken (https://www.youtube.com/watch?v=zvRQonLjhFw).
:-+
-
There's a minor repeatable bug in 1.6.2r1.
After being in XY mode, exiting XY mode enables the digital channels on screen.
This hasn't happened in every instance, but it happens for me when I've been in XY for a while, and/maybe or when the scope is powered on in XY mode.
-
There's a minor repeatable bug in 1.6.2r1.
After being in XY mode, exiting XY mode enables the digital channels on screen.
This hasn't happened in every instance, but it happens for me when I've been in XY for a while, and/maybe or when the scope is powered on in XY mode.
When powered in X-Y and then you exit.
Already reported... 8)
-
Has anyone tested the SigScopeLab software with an SDS2000X Plus?
I tried using this software.
Unfortunately, it does not work correctly with SDS2000X+. The timebase is not set correctly, it is in the range from 5 sec/div to 1 sec/div, regardless of what you set from PC. Maybe with the new firmware (when it released) the situation will improve, but for now this software useless for SDS2000X+ owners.
I had same problem using it on my Windows 10 PC which had the language and date/number format set to "German" (i.e. using comma "," as decimal separator). After changing Windows settings to use dot "." as decimal separator, as used in USA, the timebase settings were applied correctly. Maybe this helps.