Siglent SDS2000X Plus

[Martin72]

Hi John,

Will do it tomorrow - Although I´ve covered the "area" around the button with my hands, to make sure I´m not too blind...
But I´ll check it again.
Martin

Did it today....It´s dark..
Also we test the MIL 1553B decoding...It seems, it won´t work proper, but we want to try something, maybe it´s a matter of the adjustments(I wasn´t there when it was testing).
Will report in the next days and when it´s necessary, in the bug fred.
One more thing:
Today I´ve seen something in the channel dialogbox, I haven´t seen before at my siglent.
Probe symbols were displaying...Does anybody know when they will come up ?
And what does they mean?
At home I didn´t got these symbols (pic shows at work (left), home)

Martin

[tautech]

Today I´ve seen something in the channel dialogbox, I haven´t seen before at my siglent.
Probe symbols were displaying...Does anybody when they will come up ?
And what does they mean?
At home I didn´t got these symbols (pic shows at work (left), home)

Indicates Custom probe attenuation setting.

[Martin72]

Hi,

The colleagues are impressed about the sds2k+, so the next two scopes are now on their way...
When the current probe will arrive next week (hopefully), all the stuff will be send to the ext. cal-lab.
I´ll scan the protocols then and present them here, FYI.

[cragen]

Anybody have any success enabling "telnet" access to an SDS2000X Plus lately?  Running latest firmware (Version： V1.3.9R6), and the 'siglent_device_startup.sh' on a USB key method is not working for me.  I'm Linux savvy, and have tried multiple times with various tweaks to the content of the file as found on other posts, but no joy.  If someone can verify it still works for them, I'll keep at it...

Thanks

[tubularnut]

Anybody have any success enabling "telnet" access to an SDS2000X Plus lately?  Running latest firmware (Version： V1.3.9R6), and the 'siglent_device_startup.sh' on a USB key method is not working for me.  I'm Linux savvy, and have tried multiple times with various tweaks to the content of the file as found on other posts, but no joy.  If someone can verify it still works for them, I'll keep at it...

Thanks

Yes, it still works.

Are you putting the USB stick in first, before shutting it down and restarting? (That works for me)

Edit. Just tried from a power removed cold boot, and it still works ok.

[cragen]

Thanks for the response.  I'm clearly doing something wrong, as I just spent another hour trying to get it to work.

Would you mind posting the exact contents of your "siglent_device_startup.sh" file?  The network, and USB stick seem to work fine, but I never see an open port for the telnet daemon on either the default (23), or specified ports (e.g. -p 2222).  Tried cold/warm restarts, but no joy...

[tubularnut]

Drive is 32GB Kingston, formatted FAT32

Code: [Select]

iMac:KINGSTON $ ls -l
-rwxrwxrwx@ 1 aaaaaaa  staff     29 20 Feb 11:35 siglent_device_startup.sh

iMac:KINGSTON $ cat siglent_device_startup.sh
/usr/sbin/telnetd -l /bin/sh


[blurpy]

Have you tried a different usb port? I seem to remember only one of them works for running bootup scripts.

[cragen]

I was only using one of the two front USB ports, but trying the other one was not successful either....  I've exhausted my options, so when I get up the gumption, I'll  get on the UART and see what's up.

[cragen]

I take it all back.  In one last desperate attempt, I dug out an old USB stick that hadn't been used since 2014.  Put the script file on it, rebooted, and surprisingly there was port 23 in my nmap report .

I don't know why this particular USB key worked and the other did not.  It's smaller (512M), instead of 8GB that the other one is.  Both FAT32, but I'm thinking the format must be just different enough that the larger stick is not mounted correctly in early boot.

Anyway, I'm in , thanks for the help and confirmation to make me keep trying.

[cragen]

Just to close the loop in case someone else has the same issue (and because I don't like a mystery).

Turns out the 8GB USB flash drive I was having trouble with, was not partitioned. The fat32 file system was created on the main volume.  Thus it shows up under Linux as "/dev/sdc", and not as "/dev/sdc1" like a drive with a partition would.  Don't know how it got to be that way, as it was formatted from scratch on a Win10 box, but that was the issue. 

I used "parted" to create an "msdos" partition table, and a single primary partition with a fat32 file system on it.  Put the script in the top level directory, rebooted the scope (didn't have to power cycle), and the telnet daemon was waiting for me after the restart.

Cheers!

(now to get ntpd to set the time in my local timezone...)

[TopQuark]

Here's a slow, un-optimised and crude python script that pulls samples from the scope and plots a noise spectral density graph, turning the scope into a crude dynamic signal analyser.

Pulling samples from the scope through LAN SCPI seems to be broken on the latest firmware, only managed to pull correct data from the scope with firmware 1.3.9R4. The reason the python script is crude, is I am pissed and spent too many hours troubleshooting the issue, only to realise the scope firmware is not working properly.

Sources of inspiration (i.e. where I stole my code from):
https://www.eevblog.com/forum/metrology/noise-spectral-density-(nsd)/msg3955334/#msg3955334
https://siglentna.com/download/19881/

[Martin72]

It could be we already got this in the past, I couldn´t remember it actually:
Measuring...
Today at work, I had to adjust a triangle-signal for offset - Using the siglent for the first time for it.
Took as always the "mean" parameter, set the timebase in such manner, to have at least one full period on the screen.
Using the gate-lines for exactly zero-crossing at the beginning and end of the period.
Works fine, no problem at all - But I also got the frequency parameter acitve, nothing was displayed except *** .
The "hardware-counter" (?) instead is working...
Sounds so familar to me, I´m sure we got this case..

Martin

[2N3055]

It could be we already got this in the past, I couldn´t remember it actually:
Measuring...
Today at work, I had to adjust a triangle-signal for offset - Using the siglent for the first time for it.
Took as always the "mean" parameter, set the timebase in such manner, to have at least one full period on the screen.
Using the gate-lines for exactly zero-crossing at the beginning and end of the period.
Works fine, no problem at all - But I also got the frequency parameter acitve, nothing was displayed except *** .
The "hardware-counter" (?) instead is working...
Sounds so familar to me, I´m sure we got this case..

Martin

Frequency measurement between gates requires enough of waveform between the gates so algorithm can detect waveform features and decide where it repeats.
More specifically you need at least two passings trough zero in the same direction between the gates. Your gates are just too close to the period, right on the zero point. Move them a bit wider...

[Martin72]

OK sinisa, got it...
But...
For calculating the frequency a full period is all you need, when you calculate it manually (f=1/T).
A DSO can´t do it ?
But it can measure/calculate amplitude, mean and all other "vertical stuff" ?
Interesting..
When you don´t specify the measure gate, it will measure on the whole screen(lecroy, siglent).
Frequency then will be measure correctly, but mean for example not*.
When you specify the measure gate, about one period, mean will be correctly measured, but frequency not.
interesting, again..
And why can the "hardware counter" get it ?
Because it gather the "information" over the whole memory and not what´s on the screen ?
Interesting, the third..

Martin

*) The lower the timebase will be set, the more you come closer to the value it measures on only one period

[2N3055]

OK sinisa, got it...
But...
For calculating the frequency a full period is all you need, when you calculate it manually (f=1/T).
A DSO can´t do it ?
But it can measure/calculate amplitude, mean and all other "vertical stuff" ?
Interesting..
When you don´t specify the measure gate, it will measure on the whole screen.
Frequency then will be measure correctly, but mean for example not*.
When you specify the measure gate, about one period, mean will be correctly measured, but frequency not.
interesting, again..
And why can the "hardware counter" get it ?
Because it gather the "information" over the whole memory and not what´s on the screen ?
Interesting, the third..

Martin

*) The lower the timebase will be set, the more you came closer to the value it measures on only one period

You are correct, one full period is what it needs. Here measurement cursors come in handy. They show you where algorithm is measuring. And algorithm needs a certain area before and after two consecutive passes through center line of waveform to detect a full period. It is a bit crazy, I know, but it is logical as to why...

It will in fact, in full screen and in gates, find a first full period from the left and measure that.
Make note how things get interesting when you are not looking at simple repetitive waveform.
I used chirp that changes frequency in time...

Other measurements are vertical, an amplitude (or area). They will take anything between the gates, it doesn't have to "make decision".

Hardware counter is exactly that, it uses trigger circuit and measures independent to gates.

[cragen]

Thought I'd post a version of the "siglent_device_startup.sh" script that I created to enable NTP time keeping for this scope (and a couple of other things).  Could work as a template for other tweaks people might like to do.  My starting point was that I did not want to make any permanent changes to the firmware on the scope.  I know you can mount some of the flash as read-write, and make mods to preempt the invocation of "main.app", but I didn't feel comfortable doing that and possibly bricking the scope (requiring UART access).

The script is overkill for what it ends up doing (starting "ntpd"), but my OCD really wanted to have the time/date shown on the scope to be in my local timezone (rather than UTC), and thus required a modifiable "/etc" directory so I could add a "localtime" file.  Once I had a writeable "/etc", I couldn't resist a couple of other tweaks to create a nicer shell environment and password protect the telnetd service.

I noted that once "/etc" was writeable, the DHCP client creates a valid "/etc/resolv" file.  I was happy that I could now use FQDNs for my NTP server(s), or other hosts.  However, my hopes were soon dashed, as I found that the resolver does not work on this version of the firmware (V1.3.9R6).  There is some mismatch in the shared libraries for the busybox binary, and any attempts to resolve a host name results in the following error,

relocation error: /lib/libresolv.so.2: symbol __sendmmsg, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

So static IP addresses for now.    Here is the script and my personal "profile" mods (also attached).  You will have to supply your own "localtime" file for your timezone.  Remove ".txt" extension from attached files as I had to add it to allow posting.

Code: [Select]

# A script to tweak a few things on a Siglent SDS2000X Plus scope
# (developed on firmware = V1.3.9R6)
#
# Expects you to have files named "profile" and "localtime" in the top level
# directory of the USB media alongside this script. Use "localtime" file from any Linux
# OS configured for the desired timezone, or grab one from "/usr/share/zoneinfo/".

# Path to this script and other support files
USB_TLD=$(dirname $0)

# Clone /etc so we can make some run-time mods (very small)
/bin/cp -a /etc /tmp

# Now cover original /etc with a bind mount to copied dir
/bin/mount --bind /tmp/etc /etc

# Change the root password for telnet
# Generated with "mkpasswd --method=sha256crypt"
echo 'root:$5$pr81dcqw1/OpvOPT$L8tE.M8YZHEGY7DW2SqBJl9Abn/tjYbRiGoF9gFQAS/' | chpasswd -e

# Add localtime file from USB media for setting timezone
/bin/cp ${USB_TLD}/localtime /etc/localtime

# Augment environment for the shell with personal preferences from USB media
/bin/cat ${USB_TLD}/profile >> /etc/profile

# Remount as read-only (or not)
#/bin/mount -o remount,ro /etc

# Start telnet server (requires login via password above)
/usr/sbin/telnetd

# Set NTP server address as needed for your environment
# Note: resolver does not currently work, so must be numeric IP address
NTP_SERVER_IP="192.168.1.222"

# Create a script to run when "ntpd" generates an event
# Remove "#DEBUG " to get logging of the events
NTPD_SCRIPT="/tmp/set_rtc.sh"
NTPD_LOG="/tmp/ntpd_log.txt"

/bin/cat >${NTPD_SCRIPT} <<-"HEREDOC"
#!/bin/sh
NTPD_LOG="/tmp/ntpd_log.txt"
#DEBUG echo $1 >> ${NTPD_LOG}
#DEBUG echo "stratum=$stratum, freq_drift_ppm=$freq_drift_ppm, poll_interval=$poll_interval, offset=$offset" >> ${NTPD_LOG}
if [ $1 == "step" ]; then
    /sbin/hwclock --systohc
#DEBUG     echo "Set RTC" >> ${NTPD_LOG}
fi
#DEBUG /bin/date -u >> ${NTPD_LOG}
#DEBUG /bin/date >> ${NTPD_LOG}
HEREDOC

# Make above ntpd script executable
/bin/chmod a+rx ${NTPD_SCRIPT}

# Start the NTP daemon with the option to run a script on events
/usr/sbin/ntpd -S ${NTPD_SCRIPT} -p ${NTP_SERVER_IP}


[cragen]

I also wanted to note that I was able to plug in a little wireless mouse/keyboard USB dongle into the scope, and it worked great.  Now I'm not reaching up to the shelf to adjust the scope, and don't have an extra wire in the way to tangle with the probes and everything else.  Pretty slick!  Kudos to Siglent for that 

[2N3055]

In addition to what I wrote up few responses back, I must remind the readers that SDS2000X+ will NOT measure only one left most period in a gate (or screen if gates are not on). It will measure every single period in measurement scopes (screen/gate) and calculate stats on this. There are measurements that are bound to single cycles (and will be many for the  measurement scope if many periods are captured) and some will be single for measurement scope because they are, by definition, single value (like Max, P-P etc).

[Performa01]

2N3055 has already answered most of it, yet I want to summarize...

For calculating the frequency a full period is all you need, when you calculate it manually (f=1/T).
A DSO can´t do it ?
But it can measure/calculate amplitude, mean and all other "vertical stuff" ?
Interesting..

Of course one period is sufficient. The problem is, the measurement algorithm needs to know what a period is. For this, it requires at least one sample before and after the relevant zero crossing (or 50% level). If you position the measurement gate precisely, you will miss the samples outside the period, hence the period cannot be determined.
It can measure amplitude, because the transition in the middle of the measurement gate is relevant for this.
It can measure mean, because it doesn't need to detect any transition to calculate that.

When you don´t specify the measure gate, it will measure on the whole screen(lecroy, siglent).
Frequency then will be measure correctly, but mean for example not*.
When you specify the measure gate, about one period, mean will be correctly measured, but frequency not.
interesting, again..

Over the entire record, frequency measurement will indeed be correct as long as at least two complete transitions in the same direction are present.
Amplitude measurement would be correct too.
Mean measurement cannot be correct, as long as the record does not contain an exact integer number of periods. The error decreases with record length; if you measure one and a half period of a standard waveform, then the error will be at its maximum. The difference between e.g. 10 or 10.5 periods will be much smaller.

And why can the "hardware counter" get it ?
Because it gather the "information" over the whole memory and not what´s on the screen ?
Interesting, the third..

The trigger frequency counter is independent of the waveform acquisition.
The trigger frequency counter, as its name implies, counts the trigger events. It analyzes the continuous data stream that goes to the trigger engine. So, it doesn't care for record lengths or measurement gates.


Simple solution to get it all right:
Forget about the measurement gate - it looks like this is not needed for your application. But for the amplitude measurements, like Mean, RMS, Stdev, use the corresponding Cycle-measurements. I.e. "Cycle Mean", "Cycle RMS", Cycle Stdev". This way you'll get a correct frequency measurement and correct amplitude measurements at the same time.

[Martin72]

Hi,

The colleagues are impressed about the sds2k+, so the next two scopes are now on their way...
When the current probe will arrive next week (hopefully), all the stuff will be send to the ext. cal-lab.
I´ll scan the protocols then and present them here, FYI.

Meh...
Instead of two scopes, yesterday only one arrived and the currentprobe, awaiting for the middle of march, is still not here.
 

[Martin72]

Still the third scope and the currentprobe are not here...
Apart from that, actually the two existing ones are used every day, every time.
"Real Life"....
And there are two things, which are slghtly negative, really only slightly.
First the scope ist light-weight, good building quality but light-weight.
When you try to plug in a probe, you must grab the scope and hold it not to force it to fall behind...
Second the viewing angle, especially vertically, no grid visible when you look slightly above because of the height of the second stage of our working desk.
Both not truly killing things, but a little bit annoying..

[RBBVNL9]

>> When you try to plug in a probe, you must grab the scope and hold it not to force it to fall behind...

On my bench, I made a wooden vertical 'stand' just behind the instrument. Not only good for when you connect a probe, but also when you use the upper buttons. It's now rock steady!

>> Second the viewing angle, especially vertically, no grid visible when you look slightly above because of the height of the second stage of our working desk.

Indeed, the vertical viewing angle is rather poor (see my comparison document...) This is especially a thing when the scope is higher placed. I am still thinking of trying to make something so it bends slightly downwards towards me, but have not figured out the details yet. It requires some tinkering as the scope must be solid in place (not fall over!), the BNC inputs must have good clearance around them, etc.   

[hj]

Great question, wouldn't VESA mount threads help?

[RBBVNL9]

Great question, wouldn't VESA mount threads help?

Such a mount would be a great help! But the SDS doesn't have one (and I'm not sure any other test equipment gear I have does..)