When multiples channels are used the topmost is always the channel assigned/selected to be controlled.
Does this not happen ?
Have you tried adjusting the settings in the Display menu to gain transparency through the Ref trace ?
When multiples channels are used the topmost is always the channel assigned/selected to be controlled.
Does this not happen ?
Exactly. No matter what channel I select, REF1 is always on top of them all.
Have you tried adjusting the settings in the Display menu to gain transparency through the Ref trace ?
Yes, to no avail... No matter what level of Intensity or Transparence I select, REF1 is stone solid and on top of all channels.
BTW:
OS 8.3
FW 6.1.37R9
Upon further analysis:
When multiples channels are used the topmost is always the channel assigned/selected to be controlled.
Does this not happen ?
Yes, channels 1, 2 3 & 4 act like that but once any REF channel is selected, it sits on top of the normal ones, no matter which one gets assigned/selected.
ASMOF, different REF channels also act as you said, that is, the selected REF channel sits on top of the other REF channels but they're all always on top of the normal channels. This is counterintuitive and not very useful I'm afraid
Upon further analysis:
When multiples channels are used the topmost is always the channel assigned/selected to be controlled.
Does this not happen ?
Yes, channels 1, 2 3 & 4 act like that but once any REF channel is selected, it sits on top of the normal ones, no matter which one gets assigned/selected.
ASMOF, different REF channels also act as you said, that is, the selected REF channel sits on top of the other REF channels but they're all always on top of the normal channels. This is counterintuitive and not very useful I'm afraid
Somehow I understand designer thinking about this reference priority on screen but just as you told it is not optimal in some cases if example really need this kind of reference you displayed. So perhaps it is better user can select also this or example set transparency.
Upon further analysis:
When multiples channels are used the topmost is always the channel assigned/selected to be controlled.
Does this not happen ?
Yes, channels 1, 2 3 & 4 act like that but once any REF channel is selected, it sits on top of the normal ones, no matter which one gets assigned/selected.
ASMOF, different REF channels also act as you said, that is, the selected REF channel sits on top of the other REF channels but they're all always on top of the normal channels. This is counterintuitive and not very useful I'm afraid
Somehow I understand designer thinking about this reference priority on screen but just as you told it is not optimal in some cases if example really need this kind of reference you displayed. So perhaps it is better user can select also this or example set transparency.
As the Ref waveform is like no other for this scope, please share this designer thinking ?
Tautech, while rf-loop answers your question, have you experienced this same REF waves behaviour? I want to know if this is a problem with my SDS1104X-E or is it a FW problem.
In other words: a bug
Tautech, while rf-loop answers your question, have you experienced this same REF waves behaviour? I want to know if this is a problem with my SDS1104X-E or is it a FW problem.
In other words: a bug
No bug, this is intended behaviour and like you I ask why ?
It makes no sense that any Ref waveform cannot be transparent if/when the user requires it so ?
It has alway been this way and we have accepted it as so and not asked why but we need question this choice now after some discussion.
Before we ask Siglent to make changes we need more feedback.
It makes no sense that any Ref waveform cannot be transparent if/when the user requires it so ? .../... Before we ask Siglent to make changes we need more feedback.
Feedback? well you stated it correctly: it makes no sense as it is now. If the wave is "hollow", er... well... somewhat right, but if the wave is solid it is completely useless.
For instance, we cannot do this (minute 5 onwards):
...which we can perfectly do with a RIGOL scope, much older and underspecced
Hello,
my SDS1104X-E seems to struggle to display square waves with low frequency correctly. There is a slight slope which is not there when looking with my other scope. Is this normal or just my device? Waveform is a square wave with 100Hz, 3Vpp and 1.5V offset generated by AWG of SDS2354X+.
Is the probe compensated correctly ?
Is the probe compensated correctly ?
No probe connected, just BNC cable to the AWG.
Can somebody please check the same with the SDS1104X-E and an AWG? Just a square wave as shown in the picture with 100Hz, 3Vpp. Would like to know if this is just my device or others show similar waveforms.
Is the probe compensated correctly ?
No probe connected, just BNC cable to the AWG.
Can somebody please check the same with the SDS1104X-E and an AWG? Just a square wave as shown in the picture with 100Hz, 3Vpp. Would like to know if this is just my device or others show similar waveforms.
Here you are(excuse my FY-6800):
Edit: Note the difference between the acquiring depths; side-note: the mentioned effect happens when somewhere is a capacitor in series with the signal.
Hello,
my SDS1104X-E seems to struggle to display square waves with low frequency correctly. There is a slight slope which is not there when looking with my other scope. Is this normal or just my device? Waveform is a square wave with 100Hz, 3Vpp and 1.5V offset generated by AWG of SDS2354X+.
I'm seeing the same thing.
I'm also seeing a 2mV positive offset in AC coupling mode. Running self-calibration has no effect.
These are real issues.
Regarding the square wave issue, my SDS1104X-E (hacked) shows the same as yours but the no-input / AC-coupling seems a bit better.
Regarding the square wave issue, my SDS1104X-E (hacked) shows the same as yours but the no-input / AC-coupling seems a bit better.
What firmware are you at? I'm running 8.3.6.1.37R9.
Exactly the same FW than yours!
HW Version: 01-05
Exactly the same FW than yours!
HW Version: 01-05
Mine is 09-06. I wonder if that would account for it?
Does anyone know if there is a process for making Siglent aware of these issues?
Exactly the same FW than yours!
HW Version: 01-05
Mine is 09-06. I wonder if that would account for it?
Does anyone know if there is a process for making Siglent aware of these issues?
tautech(see a few of posts above) is following the thread, and if he finds problems, will report to Siglent. PM him to be sure.
I seem to have the same problem
6.1.37R9
HW 01-03
Thanks for the feedback. So if other scopes show the same problem with low frequency square waves it seems to be somehow "normal" for this series. Doesn't really boost the confidence in it.
No real issue here with offset in AC coupling. Starts with +500µV to -200µV when turned on. And after warming up for half an hour its down below +/-200µV on all channels. Thats fine for me.
Software Version: 6.1.37R8
Uboot-OS Version: 7.2
FPGA Version: 2021-11-08
Hardware Version: 01-03
Product Type: SDS1104X-E
Same thing on my 1104X-E (a slope of about 3 pixels in 5 ms).
Tried the same setup on another scope, and the wave is absolutely horizontal and flat.
Looks like a less than perfect compensation in the scope's front-end.
Same for my SDS1104X-E.
Droop on the positive and negative side of the square wave approx. 50mV
Indeed, very strange!
Mean Offset in AC coupling @ 500uV/ each channel open input(!):
<=0.2 divisions for all 4 channels.
SW 6.1.37R8
U-BOOT 7.2
FPGA 2021-11-08
HW 00-03
Thanks for reporting in folks.
For those that had acceptable offset in AC coupling, have you done the 200MHz BW "improvement"?
In my case its even worse on channel 2. After letting the scope warm-up for 2Hrs this is what I get.
Ch. 1 +1.89mv
Ch. 2 +3.05mv
Ch. 3 +1.32mv
Ch. 4 +1.30mv
for the low frequency square wave issue, it seems to have a limited time span. These traces are at ~33Hz and you can see a dip at the beginning that corrects after 8ms or so.
For those that had acceptable offset in AC coupling, have you done the 200MHz BW "improvement"?
Yes
I can also confirm that things go better with some warming time.
OS: 8.3
FW: 6.1.37R9
HW: 01.05
FPGA: 2021-11-08