Siglent SDG6000X series 200-500 MHz AWG's

[tautech]

New firmware for SDG6000X models.

Version 6.01.01.33R2
25.5 MB
https://www.siglentamerica.com/download/8841/


Changelog
1. Removed the warning message when parameter is set to a value beyond the limit
2. Supported to copy/paste/delete folder in Store/Recall file manager
3. Optimized initialization time when the waveform is switched between IQ and other waveforms
4. Supported phase compensation in IQ mode
5. Fixed several bugs:
a) [2018/09/14-924144, 2018/09/14-937446] Signals get interrupted upon timing-related change of the settings in Independent mode
b) Anomaly on square/pulse waveform with some settings
c) [2018/11/06-92208] Anomaly on arb waveform when toggle the "ArbMode" from DDS to TrueArb and back to DDS in Independent mode

[2N3055]

I will test thoroughly later when I have time..

Update went  without a problem.
On a first view, going into I/Q and out of it to other mode is instantaneous as opposed to 10s of seconds . 
Also they didn't say it in release notes, but they GREATLY improved U/I for choosing built in waveforms. 

After more testing I will report back.

So far promising..

Thanks to Tautech for heads up...
Regards,

[janekivi]

Changelog
1. Removed the warning message when parameter is set to a value beyond the limit

They have eye on us or can they see by himself this was good idea.
This is lux model, for SDG2000X I must have my own solution....?

SDG2000X_eevblog_edit_23R7.zip - with reduced ".. limit..." message box delay.

[tv84]

New upgrades in this new .ADS:

upgrade_uimage "BOOT.bin" "mtd0"
upgrade_uimage "uImage" "mtd1"
upgrade_uimage "devicetree.dtb" "mtd2"
upgrade_uimage "rootfs.cramfs" "mtd11"

[tv84]

They have eye on us or can they see by himself this was good idea.
This is lux model, for SDG2000X I must have my own solution....?

SDG2000X_eevblog_edit_23R7.zip - with reduced ".. limit..." message box delay.

In the next one, the password already comes as "eevblog"... 

[BillB]

They have eye on us or can they see by himself this was good idea.
This is lux model, for SDG2000X I must have my own solution....?

SDG2000X_eevblog_edit_23R7.zip - with reduced ".. limit..." message box delay.

In the next one, the password already comes as "eevblog"... 

That would save everyone a little time, wouldn't it. 

[jjoonathan]

> 1. Removed the warning message when parameter is set to a value beyond the limit

This alone would make the update worth it!

[2N3055]

I did a bit of testing last night, didn't have time to do more than quick run through..

As far as I could see, error that filtering (edge control) on one channel would go crazy when you twiddle frequency on other channel seems to be fixed. Or at least seems so from limited testing I did.

Will test more later.

[janekivi]

New upgrades in this new .ADS:

upgrade_uimage "BOOT.bin" "mtd0"
upgrade_uimage "uImage" "mtd1"
upgrade_uimage "devicetree.dtb" "mtd2"
upgrade_uimage "rootfs.cramfs" "mtd11"

What you like to say there... most of the files are the same.
BOOT.bin - exactly the same
devicetree.dtb - exactly the same
uImage - is updated
update.sh - has 2 changed rows
awg.app - is much bigger now
rootfs.cramfs - has new file dates inside I think, files are the same
other directories have all the old files with 12 February 2019 date

[TurboTom]

It seems Siglent managed to correct some of the major shortcomings of the SDG6000X in the new firmware which are the menu system to access the built-in arbitraries (nice solution btw, yet I would have prefered to get a direct access to the arbitrary waveform selection screen instead of the general waveforms selection menu -- there's a hard button for that already -- when I'm in built-in arbitrary mode and tap the picture of the arbitrary curve on the touchscreen). Maybe that's a possible improvement for the next update...

In phase-independant mode, I really wasn't able to notice any glitches when changing waveform parameters (like frequency, pulse width or rise/fall times). Seems like that problem is solved, at least to tell from my superficial testing tonight.

To eliminate the end-of-range warning with the accompanying delay is also a big improvement.

Yet, I also still found a lot to desire: When changing several parameters in sequence, why doesn't the instrument remember the digit of a parameter that had been modified and returns the cursor to the same digit if the user returns to the parameter after adjusting something different in between. This would improve usability considerably.

Moreover, to improve eyes-off experience (I know, I must seem like an addict to that...  ), it would be great to be able to set limits to the parameters (like it's possible to set a limit for the output amplitude). Let's say, I want to generate an old-fashioned PPM radio control signal, set the frequency of a pulse to 50Hz and would like to generate a pulse width between 1 and 2ms. If I could set limits for that, I could adjust the pulse width with the encoder without having to look at the screen while I'm always certain to stay within the valid interval. Come on Siglent, this shouldn't be too difficult to implement.

Signal-quality wise, not too much has happened. To keep the "undulation" and signal overshoot low, be sure to select a minimum rise time of 2ns or higher (where applicable).

I still found a real bug that results in a completely messed up signal. You can replicate it with the following sequence:

- Phase mode independant
- output a 500MHz (or thereabout) sine signal on a channel of choice.
- change the frequency of that channel to 10MHz by entering the new frequency via the keypad (didn't try using the encoder)
- change the waveform to square and observe what you get on an oscilloscope

You can get back the undistorted square wave by toggling burst or sweep on and off.
It seems like the fpga doesn't get initialized properly during the frequency change sequence, or maybe some garbage stays in the waveform memory that should be deleted / overwritten. See the attached screenshots, the first with the distorted "square wave"  , the second after toggling "burst".

Seems like we can still expect a few firmware updates...I hope.

Anyway, thanks to Siglent for the fixes so far!

Cheers!

[TurboTom]

New peculiar findings (bugs) with the SDG6X:

Even in independant phase mode, there may still be some glitches when outputting pulses under certain circumstances -- Select waveform pulse, frequency 150MHz and pulse width 3.3ns (I think this is configured automatically like specified when the mentioned frequency is dialed in). Rise/fall times 1ns. Then, select a lower frequency (100kHz for example) and tweak the frequency via the encoder. You can now observe the glitches shown in the first screenshot while adjusting the frequency upwards. When lowering the frequency, the signal doesn't glitch. If the pulse width is altered, the glitch disappears.

Another, very nice finding is how the SDG6X will output a 300MHz sine wave of considerable amplitude (more than supposed to in "real" sine mode at that frequency) in rectangular mode at 0Hz  , see the photo. And here's how to get there: Phase mode independant, sine output, frequency 500MHz. Then change waveform to square and dial in frequency 0Hz -- voila. You can tweak the amplitude somewhat, at more than 3.2Vpp into 50 Ohms, the output signal gets distorted/modulated, probably due to an overload of the output amplifier.

After that I experimented with phase coupled mode a little and just for fun generated the "old time" PAL sweep signals (i.e. 50Hz and 15625Hz, triangle with 100% symmetry). In X-Y mode of the scope I wanted to check if I get a proper screen raster. Just for fun, I also viewed both waveforms in Y-t mode to see if I could align the phase -- surprise, surprise, the phase was walking through at a very slow pace. If the math was correct in the SDG, this shouldn't happen and the phase of the waveforms should stay locked against each other, maybe oscillate a tiny bit to and fro but definitely not continuously drift. The last two screenshots show this behavior, once as a still and then as a history plot (don't know why the rigol scope produces the glitch at 0 phase difference -- maybe while the counters roll over).

An then, there's still the substantial ringing in Arbitrary DDS mode after steep slopes. When selecting TrueARB, it's gone due to the slower slopes. I guess this cannot be easily solved in software, somehow there would have to be a "soft slope" mechanism implemented to limit the rise/fall times to slower than 2ns. No screen shot for this, sorry...

So depending on the settings and sequence of inputs, the SDG6X may well produce unexpected signals at the output which still means it's an unreliable instrument that cannot be depended on completely without additional care and checkups. As this, I wouldn't consider it to be a professional instrument with its current firmware. I guess there's some way to go for the Siglent engineers after all. I really hope they will put the effort into the SDG6X to eliminate the problems that are still present, the hardware is really capable and the firmware got improved a lot with the current release, but we're not quite there!

I'll keep on experimenting as time permits and will post new findings as they turn up.

Cheers,
Thomas

[electronic_eel]

For anyone looking for janekivi's update files with patched root password:
Try the ones posted by tv84 instead:
https://www.eevblog.com/forum/testgear/siglent-ads-firmware-file-format/msg1870091/#msg1870091

[Performa01]

I finally got some spare time to measure the level accuracy and amplitude flatness of the SDG6052X as a sine signal source for e.g. frequency response measurements.

As a comparison (and as a sanity check for my measurements) I’m including the corresponding results for a high performance signal generator (Anritsu MG3633A), which features excellent phase noise, high output power and good amplitude accuracy, especially if it is operated below 500MHz.

The Siglent SDG6052X can replace an RF signal generator in many situations, if the following limitations are observed:

•   Maximum output level is limited to 0dBm for the full frequency range of 500MHz (Anritsu MG3633A: +19dBm up to >1GHz)
•   Output levels below -56dBm require external attenuators (Anritsu MG3633A: internal attenuator to -140dBm)

So the first test is for the maximum output level of 0dBm:


SDG6052X Level Accuracy 0dBm

As we can see, the output level is a little on the low side on my unit with an average error of -0.1dB. There are weird discontinuities of +0.12dB at 1MHz and -0.12dB at 300 and 400MHz, but the overall amplitude flatness is rather decent at +0.08/-0.17dB (0.25dB peak to peak deviation).

Compare this to the Anritsu MG633A:


MG3633A Level Accuracy 0dBm

The Output level is spot-on with an average error of just -0.01dB. There are no discontinuities and the amplitude flatness is excellent at +0.09/-0.11dB (0.2dB peak to peak deviation).

When comparing the two devices, we should keep in mind that the Anritsu MG3633A is a 2.7GHz generator, so it can easily give excellent performance in the small subrange of 500MHz, whereas the Siglent SDG 6052X has to approach its absolute bandwidth limits.

Yet there is a sweet spot for the SDG6052X when it is operated at -30dBm:


SDG6052X Level Accuracy -30dBm

Once again the output level is a little low with an average error of -0.05dB. The only discontinuity of +0.1dB occurs at 1MHz again and the amplitude flatness is sensational at +0.06/-0.04dB (0.1dB peak to peak deviation).

In the same situation, the Anritsu MG3633A performs slightly worse:


MG3633A Level Accuracy -30dBm

Output level is a little high with an average error of +0.11dB. There are no discontinuities and the amplitude flatness is excellent at +0.07/-0.1dB (0.17dB peak to peak deviation).

I’ve tested all output levels from 0dBm down to -50dBm (in 10dB steps), but below -40dBm (100nW) my power meter introduces additional errors. At least all meaurements are very consistent with the results from the MG3633A.

The measurement results are only shown for frequencies above 100kHz because the power sensor is specified for 200kHz to 18GHz. It works well enough down to at least 20kHz, but the additional errors cannot be ignored anymore when we’re expecting accuracies of better than 0.1 decibel.

Here is a table overview of my measurements:


SDG6052X Level Accuracy Table

Level is the nominal signal level as it was set on the generator.
Min. is the minimum absolute level over the full measurement bandwidth.
Max. is the maximum absolute level over the full measurement bandwidth.
Err_max is the maximum absolute amplitude error over the full measurement bandwidth.
Mean is the average absolute amplitude level.
Dev+ is the positive peak deviation of the output level relative to Mean.
Dev- is the negative peak deviation of the output level relative to Mean.

Here is an overview of the SDG6052X measurements, starting at 10kHz (which is outside the specification of the power sensor!):


SDG6052X Level Accuracy Overview

EDIT: Frequency response overview graph added.

[Performa01]

I’ve mentioned the possible use of the SDG6000X as a substitute for a RF signal generator and demonstrated that amplitude accuracy and flatness up to 500MHz is absolutely adequate for the task.

Yet there are some other considerations, such as frequency accuracy and phase noise.

I’ve measured a 100MHz sine signal as 99.9999729MHz on my sample of the SDG6052X, This is a deviation of 28.1Hz or 0.281ppm. This means that the frequency accuracy is at least on par with most of the cheaper signal generators, unless they have the (usually expensive) OCXO option fitted. Since the SDG6000X accepts an external reference clock, the accuracy can be easily increased to any desired level.

Now for the phase noise, also measured at 100MHz. First the general shape of the noise spectrum, displayed within +/-100kHz of the carrier:


SDG6052X SA CF100MHz SP200kHz RBW1Hz

This looks very clean and clearly beats the old analog PLL synthesizers by quite a margin.

Here’s the corresponding phase noise plot for 10Hz to 1MHz carrier offset – which might just show the limits of the spectrum analyzer rather than the SDG6000X – at least for frequency offsets above 1kHz:


SDG6052X PN 100MHz

A phase noise of -98 dBc/Hz at 100Hz offset is certainly very competitive.

Most likely these measurements also apply for the SDG2000X.

As a conclusion, the Siglent 16bit SDG generators can replace a RF signal generator and within their limited frequency range they will perform vastly better than most ancient boat anchors from the analog PLL synthesizer era. You just need an external step attenuator (or 3-4 20dB inline attenuators per channel) to be able to get the low level signals required for receiver testing.

[tautech]

Firmware update for SDG6000X models.

Version 6.01.01.35R5B1
25.6 MB
https://int.siglent.com/upload_file/zip/firmware/Signal_generator/SDG6000X_6.01.01.35R5B1_EN.zip

Release notes
1. Changed the upper limit of carrier frequency (sine) in Burst mode from 300 MHz to 500 MHz
2. Added some missing SCPI commands
3. Fixed several bugs:
a) Messed up signal after switching from 500 MHz sine to square in independent mode
b) Glitches when outputting pulses under certain circumstances in independent mode

[2N3055]

Upgrade went without problems.

I tested only one thing, the one that was most annoying to me: the undulation phenomenon.

And it seems that is gone, at least I cannot reproduce it with previous settings.

Will test more and report.

EDIT:

- Tried bug from post 596 by TurboTom (500 MHz sine> 10 MHz> square) and that is fixed too..
- Dropouts in signal  (few ms long) are still there when you change settings. I see it happening in phase locked mode. It stops to resynchronise channels.
- In phase independent mode (P.I.M.) i don't see glitches, even for current channel. It simply starts with different timing, no glitch.  It does seem to switchover at any time, not at zero..But signal is continuous.
- In P.I.M., on squarewave, duty cycles changes (manual and numeric) are seamless..
- In P.I.M., on pulse mode, duty cycles changes (manual and numeric) are seamless..
- squarewave has fixed 2 ns edges. (SDG6052X). Quite clean.
- In pulse mode, when edges are set to 1 ns, they are actually sub 1 ns. There is ringing on top, but no undulation of any sort. When set to 1.3 ns edges signal gets much better.
Actually my scope measures 1 ns when gen is set to 1,2 ns, which, when you take into account 450ps scope rise time, this ends up around 900 ps.
So at 1.3 ns set at AWG, you get about real 1 ns edges. at AWG set to 1 ns, you get around 800 ps measured, which would be around 660 ps coming from AWG.

Those are 10%/90% times from automated measurements.

I use MSOX3104T (internal 50 Ohm termination) and cables that came with SDG6000X.
Maybe someone with faster scope with clean step response (Gaussian, mine has maximally flat response) should verify if this is not my scope acting up.
I don't have alternative 1 ns flat top signal source at hand to verify scope response.

[2N3055]

Just wanted to mention something.
And I mean this in a nicest possible way... I really love my SDG6000X. But...
FIX THE ENCODER !!!!. Please!
It is not skipping sometimes. It is skipping all the time...
It's driving me crazy... 
Or do I have one with bad encoder??

[TurboTom]

I haven't got much of a problem with the encoder on mine, so maybe you've really got a generator with a faulty one. These tiny "twisty-switcherydoodahs" haven't really got a reputation for high quality or long service life. The encoders of the 1990s "name brand" gear are someting else, definitely...

But I've got a different problem (rant mode on):
After the update, which went completely eventless, I had to do some tests of a circuit, outputting a pulse waveform of 18kHz. Everything went well and no problem whatsoever. I noticed short interruptions of the waveform when I changed the parameters, though, which were due to the instrument configured in "phase coupled" mode.

Powered the thing down and up again after the lunch break. Changed phase mode to independent and continued testing, just to find the circuit was behaving completely different from before. Feeling a little awkward about the generator already, I looked at the signal, and see what I found (my apologies for the poor photo quality and the mess in the background -- I guess such is life ...). Once again, the memory of the AWG appears not to have been initialized properly.

I expected Siglent to have taken care of these initialization problems with this firmware update. I pointed them to the problem when switching from high frequency sine to "0Hz Square" which has been solved now. But can't they just look at all the situations when a complete initialization of the WF memory is required, especially when there has been an issue with this before? Come on Siglent, do your homework! You are asking definitely professional prices for that instrument, and a professional instrument requires one thing first and this is reliability and dependability (okay, two things...). Finding the instrument to output a waveform that's not configured on the screen is a no-go, period! TBH, right now I prefer a Rigol AWG any time over this crap and I really regret not having returned it while I could. Maybe the problems will get sorted eventually with follow-up updates, but with the experience so far, will I ever trust the instrument to perform as expected? Will I ever use it to simulate drive signals for high-power output stages, containing semiconductors with three- or even four-digit price tags (summed up)?

I have to admit, Siglent as a manufacturer of test gear considerably dropped on my personal "white list" of where to go to when buying new equipment.

And by the way, the undulation issue is still there. Just select pulse mode, minimum rise/fall times and there you go. But I guess that's just a result of the anti-aliasing filter's step respopnse and the steep slope -- when selecting 2ns rise/fall times, everything looks much better.

Cheers,
Thomas

[2N3055]

Well, I thought I was crazy then, because I know there wasn't any undulation  when I tried.
So I tried again, and GRRRRRHH it IS THERE......
Then I tried to reproduce how I got it to be clean, an got it...

In phase dependent mode there IS undulation.
In phase independent mode THERE IS NOT... 

Also I managed to reproduce that effect on that 18Khz pulse after restart ONCE. Then 10 times it worked nicely... 

Yep, it's a bit hit and miss......


EDIT:

Investigated a bit more.

By using slow repetition, for instance 1 kHz on a 3,3ns pulse with 1 ns edges, there IS undulation regardless of channel phase coupling.
So undulation is dependent of fastest edges and varies with repetition frequency...
I don't like that.

[TurboTom]

Tinkered again a little to understand how to reproduce the weirdness and guess what: I can repeat the fault every time (so far).

The SDG6000 is configured in phase mode independent, power up configuration - last. I select CH1 pulse waveform, 18kHz, 16µs PW, leading/trailing edge 1µs, maximum amplitude (don't know if that's relavant). Output impedance doesn't seem to matter. After configuration, the waveform is usually okay. The I simply power the instrument down and up again after maybe 30 seconds. When it's fully booted, I enable output 1, and voila!    Looks to me like an incomplete power-up initialization. Toggling modulation on-off restores the correct waveform. Anybody needs an almost better-than-new SDG6000? 

[2N3055]

Tinkered again a little to understand how to reproduce the weirdness and guess what: I can repeat the fault every time (so far).

The SDG6000 is configured in phase mode independent, power up configuration - last. I select CH1 pulse waveform, 18kHz, 16µs PW, leading/trailing edge 1µs, maximum amplitude (don't know if that's relavant). Output impedance doesn't seem to matter. After configuration, the waveform is usually okay. The I simply power the instrument down and up again after maybe 30 seconds. When it's fully booted, I enable output 1, and voila!    Looks to me like an incomplete power-up initialization. Toggling modulation on-off restores the correct waveform. Anybody needs an almost better-than-new SDG6000? 

I think I found something interesting. I'm still testing in detail.
But, just quickly, it seems that it is either not saving or not reading last state config completely.

I just played with 100MHz pulses. Then I set it the way you said again, rebooted, and it came up with my previous 100 MHz pulse. Like it didn't save it right or didn't  read it all..
I will try to test in more detail..

Steps to reproduce:

pulse, 100MHz repetiton, 1 ns rise/fall, 3,3 ns width. Phase independent.  Then set your 16 kHz pulse and reboot. All data entered by keyboard. Tried changing frequency with encoder, all the same.
What you get after reboot?

If I set AWG to boot to user config file, save state to that config file it will boot right.
So only LAST function doesn't work properly...

[tv84]

Anybody needs an almost better-than-new SDG6000? 

Do you accept a DP811 in exchange?   

[TurboTom]

Anybody needs an almost better-than-new SDG6000? 

Do you accept a DP811 in exchange?   

Sorry, got one already -- also almost better-than-new condition... 

[tv84]

Sorry, got one already -- also almost better-than-new condition... 

I know but 2 are better than 1 ! 

[tautech]

Firmware update for SDG6000X models.

Version 6.01.01.35R5B1
25.6 MB
https://int.siglent.com/upload_file/zip/firmware/Signal_generator/SDG6000X_6.01.01.35R5B1_EN.zip

Release notes
1. Changed the upper limit of carrier frequency (sine) in Burst mode from 300 MHz to 500 MHz
2. Added some missing SCPI commands
3. Fixed several bugs:
a) Messed up signal after switching from 500 MHz sine to square in independent mode
b) Glitches when outputting pulses under certain circumstances in independent mode

It seems 6.01.01.35R5B1 is some beta version as some things are fixed but some are broken. 

A customer had some problems with IQ usage and SCPI commands that the factory are now aware of and are addressing.
So for now unless you need something from 35R5B1 best advice is to stay with 6.01.01.33R2.