The Siglent SDG2042X Thread

[analogNewbie]

Well, I got mine yesterday. It costs me about USD500 in China.  And this is what I've done to it this afternoon...

[tautech]

Well, I got mine yesterday. It costs me about USD500 in China.  And this is what I've done to it this afternoon...

   
Care to share your secret  for others too?

Hmm, seems like you've had this plan for a while. well done, the FIRST Siglent I've heard of hacked.
https://www.eevblog.com/forum/blog/eevblog-805-siglent-sdg2122x-arb-generator-teardown/msg776709/#msg776709

[TheSteve]

Well, I got mine yesterday. It costs me about USD500 in China.  And this is what I've done to it this afternoon...

Top work! Can't help but think Siglent will try to stop this though, I don't think they are as entertained by software mods as Rigol is. Might want to keep the mod quiet for the time being until there are more of them out there.

[tautech]

Well, I got mine yesterday. It costs me about USD500 in China.  And this is what I've done to it this afternoon...

Top work! Can't help but think Siglent will try to stop this though, I don't think they are as entertained by software mods as Rigol is. Might want to keep the mod quiet for the time being until there are more of them out there.

I have no idea how they might view this, I personally have no problem with it, if they've not closed and locked the door  then who's at fault?
You just might not want to upload new FW onto it though.
Let's take note of the HW version and build date and see if they shut the door with new builds.

@analogNewbie
The last 4 digits of the SN are the units SN, what are the preceding digits, they identify the build date?

[analogNewbie]

This signal generator is implemented like a dev board .... You can download and upload anything you want.  So you can just modify 1 byte in the app of the equipment and get 120M unlocked. Now I have totally lost the will to research the algoritm

[tautech]

This signal generator is implemented like a dev board .... You can download and upload anything you want.  So you can just modify 1 byte in the app of the equipment and get 120M unlocked. Now I have totally lost the will to research the algoritm

But you no longer need to......easy crack.

[analogNewbie]

Well, I got mine yesterday. It costs me about USD500 in China.  And this is what I've done to it this afternoon...

Top work! Can't help but think Siglent will try to stop this though, I don't think they are as entertained by software mods as Rigol is. Might want to keep the mod quiet for the time being until there are more of them out there.

I have no idea how they might view this, I personally have no problem with it, if they've not closed and locked the door  then who's at fault?
You just might not want to upload new FW onto it though.
Let's take note of the HW version and build date and see if they shut the door with new builds.

@analogNewbie
The last 4 digits of the SN are the units SN, what are the preceding digits, they identify the build date?

I have no idea about the SN number. After I hacked the app ,the 40M license is still valid. I think the license contains the infomation about freq and SN. A valid license will update the freq range. I just bypassed this result.

[analogNewbie]

Well. I am still working on the algorithm and I have made some progress.

The DC  level accuracy is poor btw...

[tautech]

Well. I am still working on the algorithm and I have made some progress.

The DC  level accuracy is poor btw...

This very much depends on the AWG output setup matching the termination used. 50 Ohm or Hi-Z

How have you come to this conclusion?
How much is the error?
Pics?
Waveforms?

[analogNewbie]

It's not too bad, but I think they can do better.

The INL of this 16bit DAC is +- 3.7LSB. If it outputs the DC offset with a dedicated 18bit DAC, it will be better.

[smarteebit]

It's not too bad, but I think they can do better.

The INL of this 16bit DAC is +- 3.7LSB. If it outputs the DC offset with a dedicated 18bit DAC, it will be better.

DC accuracy is a system spec. It's not enough to keep the eyes on the INL or DNL spec of the DAC. Every analog device on the signal chain could contribute uncertainty/error to the DC accuracy, such as Vos and nonlinearity of the OPAmps.

[cnkz]

This signal generator is implemented like a dev board .... You can download and upload anything you want.  So you can just modify 1 byte in the app of the equipment and get 120M unlocked. Now I have totally lost the will to research the algoritm

Of cause i am very interested in more details....

[jackenhack]

This signal generator is implemented like a dev board .... You can download and upload anything you want.  So you can just modify 1 byte in the app of the equipment and get 120M unlocked. Now I have totally lost the will to research the algoritm

One more vote for more info! 

[analogNewbie]

I've found another way to unlock....

Most equipments lost all the options when no valid license is found, this one is implemented the other way . If the xml file contains the license is missing, it creates a new one and turns to be a SDG2122x.

Since I am new to this forum, I am not sure if it is good to publish the details.
Not sure how Siglent would do to it. Did they do this on purpose? Maybe Dave can interview the Siglent CEO later.

[smgvbest]

Looking at the readings and the spec sheet for DC of +/-1%+2mV it looks like all those readings are in spec and that's what's important right?
I am assuming the comment is they to say  on the DC characteristics that they could improve the results by using a dedicated DAC for the DC offset correct?

I have to say I'm very happy with it so far.   very much in spec.   hooked up to a external reference it's very accurate.
internal reference has a std-dev of 32hz @ 15Mhz and on the external reference it was 39uhz @ 15Mhz and 1.056Hz @ 111,999,652 Mhz  (just a random frequency near the top of range on external reference)   I'm very happy with that and the DC is all within spec.

It's not too bad, but I think they can do better.

The INL of this 16bit DAC is +- 3.7LSB. If it outputs the DC offset with a dedicated 18bit DAC, it will be better.

DC accuracy is a system spec. It's not enough to keep the eyes on the INL or DNL spec of the DAC. Every analog device on the signal chain could contribute uncertainty/error to the DC accuracy, such as Vos and nonlinearity of the OPAmps.

[analogNewbie]

It's not too bad, but I think they can do better.

The INL of this 16bit DAC is +- 3.7LSB. If it outputs the DC offset with a dedicated 18bit DAC, it will be better.

DC accuracy is a system spec. It's not enough to keep the eyes on the INL or DNL spec of the DAC. Every analog device on the signal chain could contribute uncertainty/error to the DC accuracy, such as Vos and nonlinearity of the OPAmps.

Are you from the siglent? I suggest that you guys embed drivers of some well-known usb wifi chip. 

[smarteebit]

It's not too bad, but I think they can do better.

The INL of this 16bit DAC is +- 3.7LSB. If it outputs the DC offset with a dedicated 18bit DAC, it will be better.

DC accuracy is a system spec. It's not enough to keep the eyes on the INL or DNL spec of the DAC. Every analog device on the signal chain could contribute uncertainty/error to the DC accuracy, such as Vos and nonlinearity of the OPAmps.

Are you from the siglent? I suggest that you guys embed drivers of some well-known usb wifi chip. 

As I know, Siglent has a public account on this forum. You should feedback this to it.

[tautech]

It's not too bad, but I think they can do better.

The INL of this 16bit DAC is +- 3.7LSB. If it outputs the DC offset with a dedicated 18bit DAC, it will be better.

DC accuracy is a system spec. It's not enough to keep the eyes on the INL or DNL spec of the DAC. Every analog device on the signal chain could contribute uncertainty/error to the DC accuracy, such as Vos and nonlinearity of the OPAmps.

Are you from the siglent? I suggest that you guys embed drivers of some well-known usb wifi chip. 

FYI
Some in Siglent have seen this thread and now know of your fine efforts. 

Whether Siglent will choose to shut this door is unknown by me at this stage.
All I can suggest is if there is a FW upgrade released very soon......well you know what that might fix. 

[gby]

External Input Details:

I have been testing the analog input used for external modulation input and have figured out its characteristics.

From the Specification Sheet:
Input Impedance:          10 k Ohm min
Frequency:                    0 to 50 kHz
100% Modulation:          11/12/13 min/nom/max

Based On Tests:
A/D range:                    -6 V to +6V nominal
Bits:                              9 (lsb = 12V/512 = 23.4 mV)
Sampling Frequency:      300/512 MHz = 585.9375 kHz
Low Pass Filter:              >10 MHz/none
Input to Output Delay:    1 sample (1.707 uSec)
DC offset:                      -27 mV or 1 lsb on the particular test instrument

Note:  Output offset adjustment is after modulation.  Setting wave amplitude to 0 and offset to 1 V with modulation on gives a dc 1V output and not 1V modulated.

The test I ran used a second generator to drive the SDG2042X external input and set the SDG2042X to DSB AM with the carrier set to 1 mHz 10 Vpp input 50 Ohm load.  Using this setup I could directly look at the external modulation input to CH1 output path with a constant gain factor while the carrier was high and/or low.

When I input sine waves below 250 kHz there was no aliasing.  Input frequency of 585938 Hz aliased to almost zero Hz.  Given the 300 MHz DDS sub-system clock that probably means the SDG2042X is using that clock divided by 512 for the A/D.  I also measured the quantization step time length and that period coincided.

I then input an external square wave to look at the rise time.  Basically it jumped up the full step amplitude in 1 and a small fraction sample times hence the conclusion there is no anti-alias low pass filter before the A/D.  I also put in 2.92 MHz sine and the aliased output of 9.687 kHz was only half amplitude and I expect an issue with the A/D sampling being not fast enough to see 2.92 MHz rather than an actual low pass filter.

I used the scope in sweep averaging mode with a trigger from the external modulation input.  The output showed a full A/D sample frequency of delay followed by a linear slope from the many sweep averages over another sample period.  See attached scope plot.  So, the net phase delay from input to output is 1.5 A/D samples periods or 2.56 uSec.

Lastly, I wondered about the A/D being 9 bits.  I am familiar with 8, 10, 12, 14, and 16 bits converters but not 9.  So, I wondered if the Siglent SDG2042X might being using an 8 bit unipolar A/D and adding input analog processing to rectify the input signal to get the 9th bit.  Looking carefully at small amplitude (500 mVpp) signals around zero there was clearly a huge flat spot in the output around 0 implying that the input analog rectifier being used to convert the 8 bit unipolar A/D into 8 bit plus sign converter is not the best.  In fact, for quality waveforms you really need the external modulation input to be above about 1.5 Vpp.  If the slew rate through 0 is fast enough from either higher frequencies or through larger amplitude it seems to work much better.  For example, 10 kHz input small amplitude sine looked better than 2 kHz input sine same amplitude.

Given the poor response through 0 on this converter I took at picture to show how bad it can be.  500 mV p-p input sinewave (scope not showing 10x probe atten on sine input) with very low distortion yielding (5V 0-p)/(6 Vdc)*(500 mV) = 417 mV p-p ideally. 

[alank2]

So, can you send commands over the LAN port directly?  I tried to connect with telnet on open ports, but none worked.

[cnkz]

I used telnet with default ports (did not specify anything) and it worked

[alank2]

I used telnet with default ports (did not specify anything) and it worked

To get console access to the OS, right?

How about getting access to controlling the generator so you can issue commands like *IDN?

[pascal_sweden]

I remember from another thread about upgrading the Hantek signal generator from 5 MHz to 100 MHz, that increasing the bandwidth as such, could actually require a new calibration/adjustment of the device.

Link to the Hantek HDG2000B series:
http://www.hantek.com/en/ProductDetail_149.html

Link to the thread where they talk about the upgrade from 5 MHz to 100 MHz, and indicate the need for a new calibration/adjustment after the BW upgrade:

https://www.eevblog.com/forum/testgear/hantek-hdg2002b-awg-5mhz-or-100mhz-let's-see!/msg727235/#msg727235

This makes me conclude that the upgrade from 40 MHz to 120 MHz on the Siglent SDG2042X might also require a full calibration/adjustment? Is this something which can be confirmed/denied by making actual measurements after the upgrade?

[cnkz]

How would the update via Update-Code work if you need to re-calibrate?

From what i have measured (amplitude only so far) it works nice. The amplitude is correct.

The higher harmonics are getting quite large, especially for output voltages higher than 1Vpp. That has already been showed by Dave in his review video of the SDG2122X that the performance at high frequencies was not that great... It seems the non-linearities are coming from the output amplifier, by going to 1Vpp you can hear a relay switching and at the same time the third harmonic comes up...

[analogNewbie]

The easiest way by now is to backup and remove the file /usr/bin/siglent/config/NSP_system_info.xml

This file contains the serial number and bandwidth license info. If the license is missing, it turns to a SDG2122x

It will generate a new SDG2122x license with serial no 0123456789. Since this could be easily fixed by siglent, consider this as a gift for the 1st batch buyers from them.

This works for 2.01.01.15R2 version(the latest at the moment).

read file content:
/usr/bin/siglent/config # cat NSP_system_info.xml
<?xml version="1.0" encoding="UTF-8"?>
<nsp_system_info_root>
  <device>
    <system_information>
      <serial_number>
        <chip>SDG2XBAxxxxxx</chip>
      </serial_number>
    <license><bandwidth_update_license>xxxxxx</bandwidth_update_license></license></system_information>
  </device>
</nsp_system_info_root>

backup and remove the file:
mv /usr/bin/siglent/config/NSP_system_info.xml /usr/bin/siglent/config/NSP_system_info.xml.bak