Siglent SDG1000X Waveform Generators

[mirror]

So, your capture shows an deviation of 80mV on high end.

I checked both awg channels on self cal scope with builtin stairup (other arb waveforms are same).
Changing the scope input shows that the cause is the awg. So we can state for my device an max offset of 88mV. I believe that this comes from rounding and interpolation of the 16bit input data to the 14bit dac. Only negative range is affected - same for waveforms supplied by python script.

DC and pulse output is much more accurate, so we have no analog problem.

A bit disappointing by the promised TrueArbitrary approach.

I think we can close this case.

B.T.W.: Do you made this mod to 60MHz?

[HendriXML]

With 1V/div adc stepsize is 40mV on the scope. What kind of accuracy can one expect then? A scope isn't ment for doing precise measurements,  but it can be done more or less by mostly using the offset in a good way. In that way I characterized my awg dac pretty good.

An awg consist also of 2 dacs, one fast, one for offset. The fast one used for arb. is less accurate off course. Scaling is done using an Variable Gate Amplifier and also a bit before the dac. (Don't know why they don't always use the full range of the dac, maybe a calibration thing)

Going from 16 to 14 bit is /4, that doesn't seem to account for the deviations you found.. also 14 bit is still a lot of resolution (because of VGA).

Much more then an 8 bit scope can resolve. But it could be that your dac has a large INR or something error, but an extensive test would be needed to show at what bits.

Done that..

Btw vertically zooming in with a scope, and having a large portion of the signal off screen, can do funny things to your measurements. (Amplifier saturation recovery?)

[Hexley]

Worse yet, after running this test my SDG1032X wants to revert to the pulse waveform even if I set the waveform to something else, like a sine for example, before power cycling. It always comes back up in the pulse mode.

Upon further investigation, it seems that my SDG1032X has a hardware issue that is causing it to lose the memory of its last waveform. Even after using recovery tools to return the unit to factory setup -- shout out to Tautech for his excellent help -- the problem remains. Looks like it will have to go in for service.

I would like to ask if anyone with an SDG1032X would be kind enough to run a quick test to check the behavior of its "last setting" memory?

The question is whether the unit needs ~1 minute after making a settings change to recognize and record it. That is, if a change is made and the unit is powered down immediately thereafter, will it remember the change when powered up again? Or is a 1-minute wait essential?
 
The test would be this:
1.   Power up.
2.   Change the waveform type.
3.   Power down immediately.
4.   Power up and see if the changed waveform is restored correctly.
5.   If it does not restore correctly, then repeat the test but add a 1 minute delay before step 3 and see if that changes the result.

Thanks,
Hexley

[rf-loop]

Worse yet, after running this test my SDG1032X wants to revert to the pulse waveform even if I set the waveform to something else, like a sine for example, before power cycling. It always comes back up in the pulse mode.

Upon further investigation, it seems that my SDG1032X has a hardware issue that is causing it to lose the memory of its last waveform. Even after using recovery tools to return the unit to factory setup -- shout out to Tautech for his excellent help -- the problem remains. Looks like it will have to go in for service.

I would like to ask if anyone with an SDG1032X would be kind enough to run a quick test to check the behavior of its "last setting" memory?

The question is whether the unit needs ~1 minute after making a settings change to recognize and record it. That is, if a change is made and the unit is powered down immediately thereafter, will it remember the change when powered up again? Or is a 1-minute wait essential?
 
The test would be this:
1.   Power up.
2.   Change the waveform type.
3.   Power down immediately.
4.   Power up and see if the changed waveform is restored correctly.
5.   If it does not restore correctly, then repeat the test but add a 1 minute delay before step 3 and see if that changes the result.

Thanks,
Hexley

This is normal. Designed behavior.

Current setup are saved periodically to internal xml file where it keep it. This is in flash memory. There is not NVRAM for this. It is not wise to write this continuously to flash. Also there are not resources to detect that power just start going down and hurry save setups before all residual internal power is loosed.

Example some old Tektronix scope did it if I remember right.. but there was fast NVRAM and tiny amount of data, just some bytes.

Also it do not have internal controlled mechanism for delayed shut off. I mean user start shut off and after then it save things and after all is ready it do true shut off. It do not have this feature.


Now it may feel strange if sometimes it looks like it keep last changes and some times not, depending how very fast after last setup change user shut it off. Also it have not mechanism for delayed shut off. I mean user shut off and after then it  save things and after all is ready it do true shut off. It do not have this feature.

Btw, why user need shut off very soon after last change... why user change settings and then shut off without using these settings. Usually we use and change  settings for some things what we are doing. Is it just for playing fun to change settings and shut asap off. What is the real and necessary reason to do this? Playing fun or do real works.

Now when it do it using fixed interval... if waiting time is just ending it may save things just before shut off... if last save was just done and fast change some settings and shut off next saving period have not yet...and so on...

I do not know what is this period time but one minute feels too long.

[TurboTom]

I may put it the other way round: Why didn't Siglent include a tiny FRAM chip to store configuration data in their SDG1000X design, like other manufacturers are doing for ages? These components that permit virtually unlimited write cycles, enable the manufacturers to store configuration changes as soon as they are executed by the user and provide a full power-down config memory without any worries, questions or anything to be observed. I'ld say this was simply forgotten during design, or deliberately omitted to save a few pennies.

But on the other hand, as rf-loop pointed out, in everyday use, it shouldn't be much of a problem.

[Hexley]

This is normal. Designed behavior.

Current setup are saved periodically to internal xml file where it keep it. This is in flash memory. There is not NVRAM for this. It is not wise to write this continuously to flash. Also there are not resources to detect that power just start going down and hurry save setups before all residual internal power is loosed.

<snip>

Btw, why user need shut off very soon after last change... why user change settings and then shut off without using these settings. Usually we use and change  settings for some things what we are doing. Is it just for playing fun to change settings and shut asap off. What is the real and necessary reason to do this? Playing fun or do real works.

Interesting comments rf-loop; thanks.

There are some issues, though.

Periodically writing the state to flash has essentially the same problem as does writing the state to flash on every change -- too many unnecessary flash writes. If the instrument is on for several hours and has its settings changed many times in that interval, the flash will be updated with all the intermediate settings (modulo the write delay period), instead of only with the last one. So the flash wear problem is not really solved.

The best solution, which is familiar to most embedded system designers, is to detect loss of AC line power, then generate an interrupt and save state. This takes a zero cross detector -- probably an optocoupler, but sometimes only a resistor -- and a reasonable amount of bulk capacitance at the output of the power supply. Of course, this increases the BOM cost a tiny amount.

The next best solution, which is free of cost, is to have a means for the user to command a "save" operation. This was common in 1990s vintage instruments. A bit clunky, but at least the behavior is reliable.

Having an "automatic" system that does not reliably save the state is probably not the best solution, IMHO. I would suggest to Siglent that they deprecate this function; or at least mention its limitations somewhere in the manual.

As to why the user might encounter this problem, consider the case where one finishes the day's work and then returns the generator to one's preferred default setting for the next day's work and shuts it down. That may or may not work, depending on the exact timing of the power shut down.

Gung Hay Fat Choy, in any case.

[nctnico]

The best solution by far is to use either (high endurance) FRAM or a slightly larger flash in which every next write goes into a new sector. After writing the data is verified and if that verify fails then the next sector is used. This is how I implement storing data which is written regulary.

However if the device runs Linux on top of NAND flash using a wear leveling layer like UBIFS then writing to disk regulary is not much of a problem; UBIFS takes care of wear levelling and bad-sector detection. I don't know whether the SDG1000X series runs on Linux but if they do a simple fix for this problem is to call 'sync' after the user changes a setting so the changes get written to disk immediately.

[rf-loop]

I don't know whether the SDG1000X series runs on Linux...

I know. Also everyone who have done SW mod know. Linus T's  Finnish "fingerprint" is inside it.

[tautech]

So a customer asks how can they manually single cycle their ARB waveform....
Burst>N Cycles = 1>P2 Source = Manual>manually Trigger with the high lit button.

A portion of the result requiring Single or Normal trigger on the scope to catch it.

[Hexley]

The SDG1000X has an issue when producing a modulated square wave at low amplitude. If the amplitude is set below a certain level – around 10.0 mVpp – the output level will no longer match the set point. It can drop to 1/3 the indicated level, for example, as shown in the following example.

• First, the generator is set to 1 MHz, square wave, 10.0 mVpp into 50 ohms, 50% duty cycle. The modulation function is engaged – in this case, set to FM with 1 Hz modulation frequency and 100 uHz deviation. The output waveform is observed on a scope and verified to be about 10 mV, as expected. See the first image.
  
  
• Next, the amplitude is decreased by 0.1 mVpp, resulting in a setting of 9.9 mVpp. This was done using the knob, after positioning the cursor at the least significant digit. The scope reveals that the actual amplitude has dropped to about 3.24 mVpp, not the 9.9 mVpp it should be. This is not the expected behavior. It appears to indicate an issue with the instrument. See the second image.
  
  
• Finally, the modulation function is disengaged, leaving the amplitude at its last setting (9.9mVpp). The scope now shows the expected 9.9 mVpp output. So the problem comes and goes as the modulation function is turned on and off. This seems to confirm an issue within the instrument. See the third image.
  
  

As a further observation, the behavior of the second channel of the generator was similar, but the thresholds on that channel were not quite the same as on the first channel. The second channel functioned as expected when set to 10.1 mVpp, but when set to 10.0 mVpp it produced 3.32 mVpp if modulation was engaged. As with the first channel, the correct amplitude was restored when modulation was turned off.

Note about the scope images – to improve clarity, the scope was set to average 16 samples and the 20 MHz bandwidth limit was employed. That reduced noise and jitter and produced the sharp traces seen.

[Hexley]

The User Interface of the SDG1000X series can be somewhat confusing in the display of LOAD values:

If a load of 50-999 ohms is entered, that value is shown properly. Good.

But if a load of a few kohms is entered the value is rounded to a single significant digit for display. So entering "2700" reads"3K". But the instrument actually operates using the full entered value. This is rather misleading:

• There is no way to spot a mis-typed entry,
• The output voltage does not appear to correspond to the displayed load.

Above 10K it displays two significant digits, which is a bit better but still ambiguous -- entering "10.7K" will display "11K", and so on.

There is plenty of room on the LCD to display the full value. So this seems like a simple firmware fix, which I hope Siglent will include in an upcoming release.

[Edit to add examples and illustrations]

Here is a simple set of operations starting with the generator set to output 5.000 Vpp into 50 ohms, that illustrates the issue:

Case 1 setup: The load is set to 2501 ohms. This is shown in the first shot, just prior to pushing the ohms soft key.
Case 1 result: The load reads 3K ohms. The output voltage is 9.805 Vpp. See the second shot.
Case 2 setup: The load is now changed to 3499 ohms. See the third shot.
Case 2 result: The load still reads 3K ohms. The output voltage is now 9.860 Vpp. See the final shot.

As mentioned above, this seems simple to fix in firmware by merely displaying the load value as entered. That would eliminate inconsistencies in apparent load value versus actual output voltage.

[Hexley]

There has been some interest in the DC accuracy of the SDG1000X and SDG2000X generators.
I had occasion to measure this on one channel of an SDG1032X during a recent lab project.
The SDG1000X was stepped from -2.5V to +2.5V in steps of about 50 mV. The output was measured across a 50 ohm load by a Keysight 34465A 6.5 digit DMM.
The generator behaved well, as can be seen in the attached graphs.

[Roger Need]

Here is a simple set of operations starting with the generator set to output 5.000 Vpp into 50 ohms, that illustrates the issue:

Case 1 setup: The load is set to 2501 ohms. This is shown in the first shot, just prior to pushing the ohms soft key.
Case 1 result: The load reads 3K ohms. The output voltage is 9.805 Vpp. See the second shot.
Case 2 setup: The load is now changed to 3499 ohms. See the third shot.
Case 2 result: The load still reads 3K ohms. The output voltage is now 9.860 Vpp. See the final shot.

Hexley,

How are you getting those screenshots on your SDG1000X?  I have not been able to find a way of doing this.

Roger

[Hexley]

Hexley,

How are you getting those screenshots on your SDG1000X?  I have not been able to find a way of doing this.

Roger

Have a look here at colorado.rob's work: https://www.eevblog.com/forum/testgear/the-siglent-sdg2042x-thread/msg2346945/?topicseen#msg2346945

[coy]

Hi,

lately I got a SDG1032X myself, replacing a hacked Rigol DG811, for being able to do bode plots together with my Siglent SDS1204X-E scope.

However, I did a few tests and noticed that both channels of the SDG are not synced properly, of course I tried different settings (also the "eqPhase" button), but behavior didn't change.

So I am seeing an (apparently absolute) delay on one of the channels, causing a deviation in phase of up to 5° at 30MHz.

Has anyone else seen this behavior?

Regards
Markus

[tautech]

Hi,

lately I got a SDG1032X myself, replacing a hacked Rigol DG811, for being able to do bode plots together with my Siglent SDS1204X-E scope.

However, I did a few tests and noticed that both channels of the SDG are not synced properly, of course I tried different settings (also the "eqPhase" button), but behavior didn't change.

So I am seeing an (apparently absolute) delay on one of the channels, causing a deviation in phase of up to 5° at 30MHz.

Has anyone else seen this behavior?

Regards
Markus

Utility P2>Phase Mode = Phase Locked ?

[TurboTom]

Did you make sure the cables connecting the two channels to the scope inputs are identical and of equal length? Exchange the cables / scope inputs -- yes, the scope may also have slightly different propagation times at the input (but this can usually be adjusted).

[coy]

Hi,

ok phase lock is (and was) enabled.

Both BNC cables are new and have same length, using 50 Ohm termination resistor doesn't change anything.

See below:
 SDS00006.png (15.02 kB. 800x480 - viewed 100 times.) - Difference between CH1 (yellow) and CH2 (magenta)
 SDS00007.png (14.86 kB. 800x480 - viewed 85 times.) - Switched cables on scope: You see now difference is reversed - so no problem on the scope
 SDS00008.png (15.04 kB. 800x480 - viewed 88 times.) - Switched cables at generator: Same picturew as in attachment 1 -> No problem of the cable

Maybe I am too picky? But I didn't have the same with the Rigol, there the waveforms are matching exactly.

[Ringmodulator]

Hi Coy,

yo have 500MS/s, so 2ns between samples.
Now you find a delta os 0.64ns. Thia at positions that are most likely result of interpolation.

I would not worry about that.


Chris

[coy]

It must be definitely related to the generator, by using a T-plug and feeding CH1 of the generator to both CH1/CH2 scope channels, waveforms are exactly matching.

Below I changed the vertical scale of CH2 a little bit so you can see phase is exactly matching.

Of course this is complaining at very high level I was only wondering because I did the same with the DG811 before without any deviation.

[TurboTom]

The DG800/900/2000 series is a much more recent design, and considering the complexity of the cal files, I'm pretty sure that Rigol compensates for propagation delay differences between the channels. At least this would explain the decent phase accuracy of this instrument family.

[klausES]

You can (so I use it) to match it.

Steps:

Utitlity
Channel Copy / Coupling
Channel Coupling
PHASE COUPLING Set from OFF to ON (ON only during the setting)
CH1-CH2 Phase DEVIATION (°) then adjust until it is true
PHASE COUPLING then return to off again.
The set adjustment remains (anyway on Off) as long as the device is running.

[TurboTom]

A slight difference in channel propagation time can also easily be compensated by finding or preparing two BNC connection cables of slightly different length. This would leave all the configuration options on the AWG still available.

The trouble with selecting a phase deviation between the channels is that the phase difference depends on the frequency thus it needs to be re-adjusted after every frequency change. I'm not aware that the SDG1000X offers to set a fixed delay between the channels.

[klausES]

I'm still forgotten to mention that you can save these points in a setup file (as much more)
and instruct the device can load exactly this setup when booting.

Sorry if that already knew everyone.

[Hexley]

I ran into an issue with the SDG1000X yesterday.

tldr;
There is a bug in the way sweep mode start/stop frequency settings are handled. The fix seems simple; see the last section of this post.

For any readers who want the full story from start to finish, here it is:

Use Case
A system under test was being examined for resonance. First, the peak response was found by sweeping the system’s input using the SDG1000X “Sweep” mode. Then the dynamic response of the system was examined by sending bursts from the SDG1000X at test frequencies around the approximate peak frequency. This sequence was repeated multiple times, and unexpected behavior was observed from the SDG1000X.

Issue
The SDG1000X does not retain the start frequency/stop frequency settings between invocations of the sweep mode if the “waveform” frequency is changed in the interim.

How To Reproduce

• Select waveform as Sine, and set the frequency to a nominal value, say 1.000 MHz.
• Select Sweep mode. Select Start Frequency 100 kHz and Stop Frequency 10 MHz. Select log sweep. Note that the generator has silently adjusted the frequency to read 5.050 MHz.
• Deselect Sweep mode. The will return to the waveform Sine interface.
• Change the waveform frequency to 4 MHz, and then select Sweep again.
• Note that the generator has silently changed the stop and start of the sweep. Start frequency is now 1 uHz, not 100 kHz. Stop frequency is now 8.000 MHz, not 10 MHz.

Analysis
It appears that the firmware is saving center frequency and frequency span when leaving sweep mode. If the frequency of the generator is changed when not in sweep mode, that frequency then overwrites the saved center frequency. That should not happen.
This logic causes cascading errors when sweep is re-engaged, as both start and stop frequency are silently adjusted to try to match the new “center” frequency with the stored frequency span. If the span is greater than twice the new center frequency, the start frequency truncates to 1 uHz, and the stop frequency is forced to twice the new center frequency. This behavior is seen clearly in the “How To Reproduce” steps above.

Suggested Change

• The firmware should not change the sweep center frequency when the instrument is not in sweep mode.
• The waveform frequency before sweep mode is engaged should be stored. Then irrespective of any changes that happen when sweep mode is engaged, the waveform frequency should be restored when sweep mode is disengaged.  This will ensure no interaction between sweep settings and non-sweep.

# # #