-
Hi, I'm starting a thread to track and list all bugs and strange observations for the Siglent 1000X-HD series.
Current firmware is
1.1.0.2
Feel free to confirm it, I am not ruling out a PEBKAC on my side.
Bug list:
#1 Activatingcursorsmenu during FFT makes FFT very slow.
EDIT: Seems to be related to the presence of the floating menu, not the cursors. When the floating menu is active, and for ~2 seconds after it disappears, the FFT function slows down from ~15 updates per second to 2 updates per second.
To reproduce: Feed 1MHz sine into CH1, Press Default -> Math -> Function -> Freq-Analysis -> FFT. Open and close the floating menu.
#2 SMB share function suggests wrong format.
The format suggested by the settings window is //server/share. I only got this to work with backslashes \\server\share on a Synology NAS SMB share.#3 Probe Check function is faulty.
In the probe setup, there is a function to automatically detect and adjust the probe attenuation, using the internal cal signal as reference. Every 10:1 probe I've tried wound up setting a 30ish:1 attenuation.
Note: confirmed as fixed in firmware 1.1.3.1
#4 Decode function menu does not show the custom channel labels.
You can set a custom label for each channel. The decode function still only shows CH1..2..3..4 when selecting the signals instead of showing the custom label.
EDIT: This refers to the menu where you select which channel is which protocol signal. Analysis/Decode/Protocol signals This seems to be the expected behavior, the labels only show up next t the traces in the main window.
#5 Firmware update of SLA1016 requires a reboot instead of reconnect.
If you update the firmware of the SLA1016 with the scope, it prompts you to reconnect the SLA1016 after completion. However, the unit did not recognize the SLA1016 any more until I rebooted the scope.#6 Possible I²C decode issue
see: https://www.eevblog.com/forum/testgear/siglent-sds1000x-hd-bugs-and-features-thread/msg5433341/#msg5433341
Note: Expected behavior as explained by 2N3055 below. Actually Siglent does it better than some "premium" brands.
#7 Acquisition spontaneously fails completely. Reinstalling firmware required.
https://www.eevblog.com/forum/testgear/siglent-sds1000x-hd-bugs-and-features-thread/msg5434688/#msg5434688
Present in 1.1.3.1
CHRISTMAS WISHLIST (take notes Siglent!)
- Add a NTP server setting. It's running Linux, shouldn't be too hard. -
Quote
You can set a custom label for each channel. The decode function still only shows CH1..2..3..4 when selecting the signals instead of showing the custom label.
This surprises me a little, as the software should be pretty much the same for 800X HD and 1000X HD.
Very stupid question:
It is not enough to call up the function and store a label name there, you have to activate it again afterwards - you will have done that ?
-
#2 SMB share function suggests wrong format.
The format suggested by the settings window is //server/share. I only got this to work with backslashes \\server\share on a Synology NAS SMB share.
Forward slashes are normal SMB share format for Samba/Linux syntax. Backslashes are for Windows syntax.
With the scope OS being Linux-based, I would assume //server/share is expected. Are you saying the scope requires the Windows backslash format to work, but is still prompting you to use forward slashes? -
Quote
You can set a custom label for each channel. The decode function still only shows CH1..2..3..4 when selecting the signals instead of showing the custom label.
It is not enough to call up the function and store a label name there, you have to activate it again afterwards - you will have done that ?
I do believe so:
EDIT:
Martin, I may have not made myself clear enough. I am referring to this:
-
With the scope OS being Linux-based, I would assume //server/share is expected. Are you saying the scope requires the Windows backslash format to work, but is still prompting you to use forward slashes?
That is the case. -
Quote
EDIT:
Martin, I may have not made myself clear enough. I am referring to this:
Ah, but I don't think that's a mistake.
It is (as an example) channel 2, why should there be a label text?
The label only applies to the display on the screen.
-
Hi, I'm starting a thread to track and list all bugs and strange observations for the Siglent 1000X-HD series.
Oh FFS they sent these out with that old FW !
Current firmware is
1.1.0.2
We know about some of your observations and 1.1.3.1 is being tested however not available to the public just yet. -
Jep, in fact, there is no FW available for download yet whatsoever. Not even the one it came with.
Oh FFS they sent these out with that old FW !
We know about some of your observations and 1.1.3.1 is being tested however not available to the public just yet. -
I know, preaching to the converted.
Jep, in fact, there is no FW available for download yet whatsoever. Not even the one it came with.
Oh FFS they sent these out with that old FW !
We know about some of your observations and 1.1.3.1 is being tested however not available to the public just yet.
Will send PM. -
#4 Decode function menu does not show the custom channel labels.
All models using this UI work in this way.
You can set a custom label for each channel. The decode function still only shows CH1..2..3..4 when selecting the signals instead of showing the custom label.
EDIT: This refers to the menu where you select which channel is which protocol signal. Analysis/Decode/Protocol signals
In the Decode menu you assign the channels to the required signals, SDA, CLK etc.
In the Probe menu custom trace labels are applied.
Any changes would require a complete platform variation and many models would be impacted.
Therefore a detailed report need be prepared for any consideration. -
Jep, in fact, there is no FW available for download yet whatsoever. Not even the one it came with.
Oh FFS they sent these out with that old FW !
We know about some of your observations and 1.1.3.1 is being tested however not available to the public just yet.
Actually it is 1.1.3.1 (12 March) - on the China site- Use Edge browser with automatic translation. - https://www.siglent.com/download/firmware/?ProId=96
I'm using it for about two month without problems and solved two major bugs ( arched waveform at maximum zoom and scope lock when using PSSR function in Power Analisys)
Later edit:
Reported bugs checked in 1.1.3.1
1. yes the FFT screen update slows down for 2 seconds when menu is activated (even is embeded or floating). Tolerable, not an issue.
2. explained by Veteran68
3. probe check detect correctly attenuation setting.
4. yes in decode menu the label setting does not appear.
5. N/A
-
I found something else that someone might try to reproduce:
It reliably does not decode the (7 bit) I²C addresses 0x78 (= 1111000 ) through 0x7B ( 1111011). So, these are all addresses starting with a "11110" pattern.
Test setup:
- I have an STM32 MCU trying to write a byte to the addresses 0x00 through 0x7F.
- Voltage threshold for SDA / SCL at 1,5V, 4K7 pullup resistors to 3.3Volt.
0x00 to 0x77 works fine, 0x78 to 0x7C fails, 0x7D, 0x7E 0x7F work fine again.
-
I just received my SDS1104X HD (from reputable US reseller) and have now spent a little bit of time getting familiar. Liking it so far. I have not tried to replicate any reported bugs as of yet. Mine came with 1.0.7.2 firmware, which seems quite old. I’m waiting to see when the next official update is released before worrying about other updates or chasing bugs. Unfortunately I can’t help right now with your I2C address issue, but will be watching.
I was a bit disappointed to see there is no NTP option in the network settings. I sort of assumed it would be there given the 800X support. I know it’s been mentioned before, but adding my vote to include this option in the future. -
I was a bit disappointed to see there is no NTP option in the network settings. I sort of assumed it would be there given the 800X support. I know it’s been mentioned before, but adding my vote to include this option in the future.
NTP was never considered for 1kX HD as it already has a RTC, unlike the 800X HD series. -
Presence of an RTC does not necessarily obviate the use of NTP (SNTP)
In this case I would grant that there are not many use cases where ongoing resynchronization would be required, and that this is more of a convenience item - at least as long as the RTC drift is reasonable. If you are trying to match up scope captured events and other external data/event data then such synchronization may be useful, but I have no definitive use case. -
Presence of an RTC does not necessarily obviate the use of NTP (SNTP)
I'd even argue that having an RTC is all the more reason to support NTP. -
1. yes the FFT screen update slows down for 2 seconds when menu is activated (even is embedded or floating). Tolerable, not an issue.
It's gotten better with 1.1.3.1, but still worth looking into IMHO, since it might be the same reason why the Bode Plot function is so dreadfully slow. The menu is always on during Bode Plot, so the function might suffer from the same issue. -
Aaaaaand it's dead...
Acquisition now has a permanent failure where everything between ground and the signal is filled with a pseudo 250MHz sine wave.
Probe Ch.1 is connected to cal signal, Probe Ch.2 is attached to ground.
I am not able to recover from this so far.
Update: I was able to recover the normal operation by reinstalling the firmware.
-
How was crashed?
You were in the middle of something? -
How was crashed?
You were in the middle of something?
I was playing arround with the Bode Plot function and FFT. Then I shut down the unit and went for lunch.
When I returned, it immediately started up in that state.
When this fault is active, it looks like it ia trying to interpolate anything into a 250MHz sine wave. It also combines all the samples from all channels into one trace. Really looks like the entire acquisition goes bonkers. -
I was playing arround with the Bode Plot function and FFT. Then I shut down the unit and went for lunch.
When I returned, it immediately started up in that state.
When this fault is active, it looks like it ia trying to interpolate anything into a 250MHz sine wave. It also combines all the samples from all channels into one trace. Really looks like the entire acquisition goes bonkers.
Bode plot was also responsible for PSRR bug. It was not closing completely and lock the scope when Power Analysis menu were open. The scope must be forced shutdown, reset to factory, and sometimes secure erased in order to be recovered.
-
So, I have a theory of what's happening with the I²C bug:
A CAN bus expects something called "bit stuffing" if you try and transmit five or more bits that are all ones or zeroes. So instead of the 5th identical bit, an inverted "stuff bit" gets inserted. This is because CAN has no clock signal, so CAN relies on the data bits themselves to recover a clock signal. Hence, bit stuffing ensures that you have an edge every now and then to synchronize on.
Let's look at that bug again. Only addresses starting with "11110" are not decoded. I'm willing to wager a nice bottle of single malt, that I²C decoding shares code with the CAN decoder and tosses out the "0" as a supposed "stuff bit". Consequently, the I²2 frame is "missing "a bit and is not decoded because it seems incomplete.
I²C has a clock signal, so bit stuffing is not required. But somehow "11110" gets treated the way a CAN frame would. By the way, "00001" works fine.
What do you think?
-
It is possible but as long as you don't have a confirmation from inside, you can't be sure about the cause.
For me as long as it can decode reliably what I need is enough for time being ...
-
So, I have a theory of what's happening with the I²C bug:
A CAN bus expects something called "bit stuffing" if you try and transmit five or more bits that are all ones or zeroes. So instead of the 5th identical bit, an inverted "stuff bit" gets inserted. This is because CAN has no clock signal, so CAN relies on the data bits themselves to recover a clock signal. Hence, bit stuffing ensures that you have an edge every now and then to synchronize on.
Let's look at that bug again. Only addresses starting with "11110" are not decoded. I'm willing to wager a nice bottle of single malt, that I²C decoding shares code with the CAN decoder and tosses out the "0" as a supposed "stuff bit". Consequently, the I²2 frame is "missing "a bit and is not decoded because it seems incomplete.
I²C has a clock signal, so bit stuffing is not required. But somehow "11110" gets treated the way a CAN frame would. By the way, "00001" works fine.
What do you think?
I'll send you my address for the bottle. I trust you to pick something nice.
It doesn't work because those are not valid packets. From standard:
111 10XX X 10-bit slave addressing
111 11XX X Reserved for future purposes
Nice page:
https://www.totalphase.com/support/articles/200349176-7-bit-8-bit-and-10-bit-i2c-slave-addressing/
And if your reference for this is Keysight scope make note that their implementation is not correct, i.e. not according to standard. It will decode 7bit addresses with invalid ranges.
Picoscope correctly decodes both 7 and 10 bit addressed I2C
-
I'll send you my address for the bottle. I trust you to pick something nice.
Please do, I am a man of my word.QuoteAnd if your reference for this is Keysight scope make note that their implementation is not correct[...]
Indeed. Come to think of it, I don't think I've ever used a non 7-bit I²C part in anger in the past 32 years as an EE. I completely forgot about the extended addressing.
Anyway, a fine bottle of scotch will find it's way to Croatia as soon as it knows where to go.