The Siglent SDG2042X Thread

[Vit G]

Wow! I take back my words. Now I used Putty instead of the Windows telnet console and I managed to enter the code!
I apologize for giving incorrect information earlier! 
At  120 MHz, SDG shows excellent accuracy. (500mV Vpp signal). I see a slight phase shift (the length of the cables is identical). In the Rigol generator there is a phase synchronization button, but in the SDG I don’t see this?

[Martin72]

Hi,

Use "phase coupling", default setting is OFF...
(Page 111 (121 on my pdf viewer))of the user manual)

https://www.batronix.com/files/Siglent/Funktionsgeneratoren/SDG2000X/SDG2000X_UserManual_EN.pdf

[Vit G]

 Hi, Martin72!
 This is a little different from what I was expecting. I also found an EqPhase button, an analogue of which is in the Rigol (and it works in Rigol).
 All that the shifting function does is adjust the phase of the second channel but does not calibrate it in any way.
 That`s what happens: https://youtu.be/m08x7QHvA24

 Manual says that EqPhase should eliminate phase mismatch.
 Maybe need some kind of calibration in the service menu?

[Martin72]

Hi,

Test it a few minutes ago, I took the phase mode to "deviation" and adjust it, see pic.

[Vit G]

 But then you see the same value of phase shifting in the main window. What's the point of walking so far when it can be done here?
 This problem definitely had to be solved by the EqPhase button.

[fkoran]

I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/

Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.

For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40

data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.

Have I missed something obvious?

Tim, I'll make contact by email with some stuff.

I'm having the same issue with arbitrary waveforms including 0x0a ("\n") over the TCP socket interface. Let's get in touch?

[tautech]

I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/

Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.

For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40

data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.

Have I missed something obvious?

Tim, I'll make contact by email with some stuff.

I'm having the same issue with arbitrary waveforms including 0x0a ("\n") over the TCP socket interface. Let's get in touch?

This was the feedback from HQ Tech support:
I think the customer uses the Socket communication. Is it right?

The '0A' is the terminating symbol. When the data inlcude '0A', it will stop the transmission.
I advise to use the usbtmc or tcpip by visa at the moment.

We will try to solve this problem.

[fkoran]

I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/

Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.

For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40

data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.

Have I missed something obvious?

Tim, I'll make contact by email with some stuff.

I'm having the same issue with arbitrary waveforms including 0x0a ("\n") over the TCP socket interface. Let's get in touch?

This was the feedback from HQ Tech support:
I think the customer uses the Socket communication. Is it right?

The '0A' is the terminating symbol. When the data inlcude '0A', it will stop the transmission.
I advise to use the usbtmc or tcpip by visa at the moment.

We will try to solve this problem.

Thanks! Has anyone had success using usbtmc mode in pyvisa? If so, what version and configuration are you using? I see that binary writes to a USB:INST session never terminate as though pyvisa isn't asserting termination correctly

[tautech]

Has anyone had success using usbtmc mode in pyvisa? If so, what version and configuration are you using? I see that binary writes to a USB:INST session never terminate as though pyvisa isn't asserting termination correctly

Have you looked at the resources on the US website ?
https://siglentna.com/application-note/16-bit-step-arb-sdgx/

[adacsaba]

Hello guys. Not sure if this issue was raised before, if so, sorry about duplicate. If not, can someone throw an opinion , please ?

Just acquired a "matching" pair of SDS1104X-E -- SDG 2042X specifically, for the Bode plot feature and the ease of hackability, didn't go for the higher end models, for this kind of equipment in general is like 50-100% pricier in this country than the advertised price by manufacturer. And obviously didn't want to wait 50 days for direct order from China ( but even if i did, the difference would be marginal, killer customs taxes, darn EU is so fckd up...).

Unlocked successfully the SDG to 120 MHz, works, but the signal level starts to drop from 80 MHz, falling to half at 120 MHz. I have the HW revision 02-xxxx, not the 05-xxxx, brand new, under warranty, etc., freshly imported through the Netherlands trade point. Not sure why it isn't the 05 version though.

I did verify the signal levels using different cables, one that should work up to the GHz ranges. Tested with the unlocked SDS and an older analog Hitachi scope. May not be mV accurate, but still the same proportianal decrease in signal level, from 80 to 120 MHz, the signal gradually drops to half.

Not sure how to proceed. Is this something eligible for Siglent support, or do you guys have any suggestion ? Maybe need to solder in or replace some components at output stage, if so, does anyone have some isntructions for ? It feels very much like a low pass filter , maybe a hardware bug in this model ?

Thanks in advance.

PS. great forum with great people all around. Practically i've made my choice on the purchase solely based on this forum and Dave's videos, the alternatives would have been models from Rigol, Hantek and Owon. Siglent had the best price-performance report (that includes the unlocking factor) and fastest shipment.

[JDubU]

What happens if you set the output voltage to 1V peak to peak?

[Roger Need]

Hello guys. Not sure if this issue was raised before, if so, sorry about duplicate. If not, can someone throw an opinion , please ?


Unlocked successfully the SDG to 120 MHz, works, but the signal level starts to drop from 80 MHz, falling to half at 120 MHz. I have the HW revision 02-xxxx, not the 05-xxxx, brand new, under warranty, etc., freshly imported through the Netherlands trade point. Not sure why it isn't the 05 version though.

I did verify the signal levels using different cables, one that should work up to the GHz ranges. Tested with the unlocked SDS and an older analog Hitachi scope. May not be mV accurate, but still the same proportianal decrease in signal level, from 80 to 120 MHz, the signal gradually drops to half.

I have a 2042X unlocked and it works fine up to 120 MHz. when measured using a 200 MHz. scope.

You are using a  SDS1104X-E which is a 100 MHz. scope so it is not surprising that you are 3 db down at 120 MHz.

Quote from Siglent..... https://siglentna.com/operating-tip/determine-bandwidth-scope-require-application/

Oscilloscope bandwidth is defined as the frequency at which the amplitude of the observed signal drops by -3 dB (or drops to 70.7% of its actual value) as we increase the test signal’s frequency as plotted on the amplitude-frequency characteristic curve (Figure 1).

Roger

[JeremyC]

I did verify the signal levels using different cables, one that should work up to the GHz ranges. Tested with the unlocked SDS and an older analog Hitachi scope. May not be mV accurate, but still the same proportianal decrease in signal level, from 80 to 120 MHz, the signal gradually drops to half.

If you use Hi-Z output, you should use scope probes and not a coaxial cable. If you want to use coaxial cable, then you should set generator output to 50 Ohm and have 50 Ohm pass trough terminator in the scope input.

Check this link:
 

I'm guessing your generator and scope are fine.

[tautech]

Hello guys.

Welcome to the forum.

Unlocked successfully the SDG to 120 MHz, works, but the signal level starts to drop from 80 MHz, falling to half at 120 MHz. I have the HW revision 02-xxxx, not the 05-xxxx, brand new, under warranty, etc., freshly imported through the Netherlands trade point. Not sure why it isn't the 05 version though.

I did verify the signal levels using different cables, one that should work up to the GHz ranges. Tested with the unlocked SDS and an older analog Hitachi scope. May not be mV accurate, but still the same proportianal decrease in signal level, from 80 to 120 MHz, the signal gradually drops to half.

You can't check amplitude flatness for a 120 MHz AWG with a 100 MHz scope.

Please also check the datasheet for the output spec which is:
+ 0.4 dB 100~120 MHz (Included), 50Ω load, 2.5Vpp, compare to 10kHz Sine
Meaning, it can only be tested to meet spec in that manner. ^^^

[adacsaba]

Thank you gentlemen, that was quite quick...

Acknowledged, and will follow both your advice. Don't have yet the no advanced cabling stuff, i will purchase a few terminators, splitters, wtf anyways. The default probe's 100 MHz only, so likely need to get a batch of higher frequency ones, saw some 300 MHz probes recently.

That being said. On this very forum there are claims and claims the SDS1104X-E does unlock to true 200 MHZ SDS1204X-E (or possibly the unreleased 1254X-E) . It's claimed the limit is all soft, no fiddling needed with the input circuitry. I know there is a different forum to that, but maybe it doesn't unlock after all.

Are you absolutely adamant on the fact SDG2042X does indeed unlock to 120 MHz fully, even with this version of the hardware ? Unfortunately i do have two variables here plus the cabling. Plus the somewhat non-existing experience with this specific hardware set.

[adacsaba]

What happens if you set the output voltage to 1V peak to peak?

It behaves same regardless of the peak voltage set. In case of 1V p2p i get around 400 and a wee bit of mV. It's basically a 3dB attenuation ( half ), as the other gentleman pointed it out. I did also a more thorough scan and there is a zone where actually i get higher voltage, looks like a resonance area.

Will need to delve into this more, RF has it's own magic, credits go to Tesla 

[Martin72]

Are you absolutely adamant on the fact SDG2042X does indeed unlock to 120 MHz fully

Yepp...

[adacsaba]

Just for our fun, can you please do a set of measurements, at 2.5Vpp , say 10, 20,40,50,80 and 100 MHz ?

[adacsaba]

First, thank you all so very much for the quick and most helpful advices. Most pleasant experience on a tech forum, especially when the smartest people are on.

Actually, i've found what the issue was. Unrelated to the SDG, which actually turns out perfect 2.64 Vpp@1kHZ, 2.56Vpp@60MHz, 2.52Vpp@120Mhz, that's like less than a dB. At the very least i have my doubts settled.

As for the issue, it's more of an FYI, for it's off topic actually. I think there were some engineering models in the SDS 1xx4X-E series, ultimately un-released by Siglent. So it happens i had, and forgotten, the SDS unlocked to 1254X-E. This model doesn't seem to exist in their catalog, hence i assume it was some engineering sample, 250 MHz BW with different input circuit. In 1254X-E mode the input filter, attenuator, wtf logic gets all screwed up. Sorry about that, please give me some amnesty here Turned it back to an 1204X-E, works like a charm.

The handmade "terminated transmission line" from a 1.2m piece of token ring cable, soldered BNC from a decommisioned balun and 2x100 Ohm 1% metal film resistors in parallel, turned out quite well actually.

[Vit G]

but.. 50 0hm resistor +50 ohm cable is 25 ohm ? Can it be more correct to put a resistor at the end of the cable and not at the beginning?

[Roger Need]

It would be nice if others running the latest firmware version (V2.01.01.37R3 released past month) could check for the frequency counter bug and post their hardware version and results, so we can report it to siglent for them to fix it.

To check for the bug, just run the frequency counter:

Code: [Select]

Utility -> Counter -> State "ON"
The device should start to feel laggy/unresponsive as the time passes and once "num" reaches between 700-1200 counts the device freezes.

To speed up the process you can enable fast counting under setup:

Code: [Select]

Utility -> Counter -> Setup -> Type "Fast"

A firmware update (V2.01.01.37R6) to correct the counter bug was released by Siglent on April 11, 2023

https://siglentna.com/service-and-support/firmware-software/waveform-generators/#sdg2000x-series

Release notes below....



I installed it today on an 2042X that had been upgraded to a 2122X and it went smoothly.  Initial testing showed teh bug is fixed and other functions work as before.

Roger

[JOFlaherty]

Thanks for the pointer to the fix. I installed it tonight, and have been playing with the counter for a while, and it has never become unresponsive or even slowed down.

[JDubU]

Just like firmware V2.01.01.37R3, V2.01.01.37R6 fails to install on my SDG2042X (hardware version 02-01-00-40-00).
Are they only for the newest hardware versions?

[tautech]

Just like firmware V2.01.01.37R3, V2.01.01.37R6 fails to install on my SDG2042X (hardware version 02-01-00-40-00).
Are they only for the newest hardware versions?

The release notes don't indicate such:
https://siglentna.com/wp-content/uploads/dlm_uploads/2023/04/SDG2000X-Firmware-Revise-History-Update-Instructions.pdf

Me thinks your most likely problem is with your USB stick, it's too large and/or incorrectly formatted.

[CustomEngineerer]

Both V2.01.01.37R3, V2.01.01.37R6 installed fine on my SDG2042X hardware version 01-07-00-40-00 (hardware version was 01-07-00-35-00 when I was on 37R3, it bumped up to the new one on installing 37R6).