Siglent SDG6000X series 200-500 MHz AWG's

[TurboTom]

@tautech -- you've got a completely valid point here, please see the attached screenshot of the system info page of the "DS2072A-S". I got this scope for comparably little money from Rigol EU's clearance sales , not only did it contain the MSO hardware, but was also easily convinced to operate as the MSO2302A-S. Rise time is 1ns and -3dB bandwidth is in the ballpark of 370MHz. If it will make you feel more comfortable, I'll pull the Tek 2465 from the basement and replicate the tests with this one (provided it will still power up without errors... ).

Cheers,
Thomas

[tautech]

@tautech -- you've got a completely valid point here, please see the attached screenshot of the system info page of the "DS2072A-S". I got this scope for comparably little money from Rigol EU's clearance sales , not only did it contain the MSO hardware, but was also easily convinced to operate as the MSO2302A-S. Rise time is 1ns and -3dB bandwidth is in the ballpark of 370MHz. If it will make you feel more comfortable, I'll pull the Tek 2465 from the basement and replicate the tests with this one (provided it will still power up without errors... ).

Cheers,
Thomas

Your reply was as expected  so now I ask just as you have about the SDG6022X and higher BW liberated performance, how do you know performance of your liberated DSO matches a 'factory' MSO2303A ?
Truth is we can't say for absolute sure, just as we can't say 110% the SDG6022X liberated to SDG6052X operates perfectly as expected.
But then we know both your DSO and SDG6022X are BW limited so I don't understand why you would even question 'liberated' performance when using a liberated DSO. 

As to unexplained SDG behavior your video (to me) didn't show the settings well enough for your scope and if Auto triggering was being used so this behavior could be explained if you were using Normal triggering.
Points you have identified in earlier posts have been bought to Siglent's attention so we do expect changes in forthcoming FW to address these. Further, all three X series AWG's have very similar UI's and so improvements to another series will permeate into the other AWG's.

Thanks for your explorations into the SDG6000X series.

[dpenev]

Hi Thomas,

I have tried to reproduce the issue from your first video (1MHz square wave 60% duty cycle) but it seems the square wave is OK at my side.
Probably you hit a problematic unit? Please let us know how the discussion with the distributor goes.
 
 

[TurboTom]

Today I conducted several more tests with the SDG, among them also an attempt to "liberate" the instrument differently with apparently better results than before. Still I find some peculiar characteristics of which I'm not sure if they are correct. But let's start with a video clip of the instrument in its original configuration. My main objective was to decouple the output waveform from triggering of the oscilloscope. Fortunately, the SDG6000X features an AUXiliary connector at the rear that provides a sync signal if configured that way.  Unfortunately, the disappointment followed almost immediately after connecting it to the scope and powering it up -- there's considerable jitter between sync and the output phase and the sync is only available up to a frequency of 10MHz   . Anyway, here's the first clip, me demonstrating the sync / output jitter and some other strange stuff:

http://www.turbinemuseum.de/files/SDG6000X/SDG6000X_org2.mp4

After that I decided to have another go at "liberating" the machine, this time utilizing a different method. I won't go into detail here since I'm still not sure if it's a good idea to try this but whatsoever, apparently it worked a little better this way. At least the malfunctions of the waveform buttons have disappeared. Still, I find considerable "undulation", especially in pulse mode with 1ns rise/fall times and short pulses (< 10ns). At rise/fall times >= 2ns, the undulation almost disappears. I'ld be glad if someone could try to replicate this experiment with a fast scope. Regarding the scope that I use I've got to add (to eliminate any abiguities right from the start) that it's an "improved" Rigol MSO4014. Since Rigol themselves offer these bandwidth upgrades for this model, we can safely assume that the hardware is capable of the "liberated" bandwidth. It's upgraded to the full 500MHz, reporting the improvement as "official" . Here's the clip:

http://www.turbinemuseum.de/files/SDG6000X/SDG6000X_lib3.mp4

I'ld be really glad for some feedback regarding this test since it will help me to understand if my SDG6022X has got a problem or not.


After that and after having seen all the jitter and wiggles and whatnot, I thought to myself that it's time to pull the HP 53310A Modulation Domain Analyzer from the basement and have a go at the SDG6022x... 

To cut a long story short, in general the SDG is performing quite well IF an external reference gets used. The internal reference -- well, let's put it that way -- could be better...
The MDA basically is a very fast, very accurate frequency counter with integrated digital processing to provide a graphical representation of the measurements (especially histograms). It's primary display mode is frequency vs. time but it can sum up the results (just like a multi-channel analyzer) to provide a histogram that somewhat resembles a spectrum, yet it's not the level on the vertical axis but the quantity of the measurements that fall within the limits of that channel.

Most of the measurements I did are close to the limit of the MDA since the performance of the SDG6000X is quite good. But anyway, it shows some interesting details of the instrument.  Please bear with me for the many large photos I attached:


Here we start with a measurement of the reference generator itself. It consists of an Efratom LPRO-101 rubidium oscillator, a five channel isolation amplifier and a pulse shaper with three square wave outputs of 2.5, 3.3 and 5V. This reference is fed to the MDA as well as for some of the tests to the SDG6000X. This initial test is meant to show where the limits of the MDA are.


This photo shows the same setup as before but now the 5V square signal output is tested. It's amazing how much better 9.6mHz vs. 23mHz (this is millihertz!) the standard deviation of the frequency is. This basically is the result of the steeper edges of the square wave and hence the lower jitter of the input trigger / digitizing stages. We are right at the edge of the instrument's performance.


That's the first test of the SDG6000X, utilizing its internal reference oscillator. I decided to adjust amplitude of the sine wave to be 7dBm since the Rb reference outputs the same level. The histrogram looks pretty "how-you-doing" and the standard deviation is almost tenfold of what the RB source provides (this means jitter or phase noise).


For this test, I connected the external REF input of the SDG6000X to the RB reference. It's quite amazing how the figures change --  the standard deviation now is only slightly worse than the one of the reference itself. A more than eight-fold improvement...


For direct comparison with the reference, I also tested the SDG with a 10MHz square -- once again, the difference to the reference is neglible.

In the following tests, I step up with the frequency in 100MHz steps, initially to 300MHz:






Here the frequency limits of channel A of the MDA are already exceeded, yet it still appears to work okay. Moreover, at 300MHz the SDG cannot sustain a level of 7dBm anymore which may also contribute a little to higher trigger / digitizing jitter. Hence I did the same measurement on channel C of the MDA again:


This channel is equipped with a down converter. Since it requires its own local oscillator (PLL), it adds to the total jitter with some 100mHz in this configuration.




Finally at the limit of the SDG... It's amazing that at 500MHz -- provided the proper reference is used -- the generator produces less than 5Hz of total peak-to-peak jitter with a standard deviation of just a little more than half a hertz! Center frequency inaccuracy is just about 0.3Hz. For comparison, 500MHz with the internal reference:


Funny how much worse the SDG's internal reference is: an absolute error of around 240Hz, almost 20Hz Pk-Pk jitter and 4 Hz standard deviation.

Finally, I had to have a look at the internal reference of the SDG. Fortunately, it' got a reference output. Voila:


I guess that's not bad for a TCXO but the histogram is far from the ideal gauss profile. Probably it's okay for everyday's tasks but for some really accurate jobs, the SDG6000X's performance will improve a lot if a decent external reference is used.

Thanks for reading...that is, if you got that far... 

Cheers,
Thomas


Edit: Corrected link to second video

[jhenderson0107]

Turbo -

Can you also measure the phase stability of the trigger output from the SDG on the MDO?  Could be problematic, since it's much lower frequency.  It may allow visualization of the trigger walk that you observed on the scope earlier or highlight jitter on this signal as you manipulate the SDG frequency. 

Jim

[dpenev]

Hi Thomas,

I confirm the same behavior as your two videos.

[TurboTom]

@dpenev - Thanks a lot for testing that. Your matching result probably confirms that my SDG6022X isn't defective and the observations at the edges of it's operational range are the result of the design and operation principle. It's good to know this since now I don't need to worry about a potentially defective unit and can decide to keep or return it just upon my findings. I guess now we know why Siglent has limited the over/undershoot specs in their datasheet to rise times of 2ns and above... 

By the way, the single AUX In/Out port that is shared between Sync CH1 / CH2 Trigger In CH1 / CH2, Trigger Out CH1 / CH2, Modulation In CH1 / CH2 and Data In in I/Q modulation mode. That's a whole bunch of stuff that's all mutually exclusive. I can very well imagine situations where I would need more than one of these functions. At least combined Sync/Trigger/Modulation ports but separate for CH1 and CH2 would be desirable. I'ld rather do without the frequency counter or have this function shared on one of the ports.

@ Jim - Please have a look at the following photos:


This is the freq-vs-time measurement of the Sync output. It appears there are more or less periodic changes between high and low jitter that alter rather abruptly. Since the jitter levels are rather low already, I'm not too sure if this is really something that's present at the SDG's sync output or if it may be some interference picked up from somewhere else. The maximum time base available on the MDA (1s/div) isn't long enough to pick up a complete period of this trace. Since I found that just using a different BNC cable may change the standard deviation of the jitter by 10mHz, I guess we're really searching here the needle in the haystack.


That's an interesting one: I reconfigured the MDA to operate as an ultrafast timer with high repetition rate. The time delay between input A and B of the MDA is measured and graphically displayed vs. time. Input A is connected to CH1 of the SDG6000X, providing a square wave of 1MHz, and input B is wired to the Sync Out on the rear of the SDG. Now the "walk-through" of the Sync signal vs. the output is clearly shown and also the approx. 3.5ns span of the "jitter" can be directly measured. It also gets obvious that the frequency of the walkthrough depends on the deviation of the output frequency to a multiple of 200kHz.


Here I tested the phase jitter between CH1 and CH2 of the SDG, outputting the same square wave. As the MDA shows, standard deviation of the phase delay between the two channels is no more than 50ps (since the input / trigger and other circuitry of the MDS also contributes a little to the noise), a pretty good figure.

If Siglent manages to remove the pauses of the output signal when changing parameters like frequency, aspect ratio or pulse width via the rotary encoder, I'ld say the generator is a keeper, despite of the peculiarities when looking very close... I guess there's no piece of test equipment without some quirks. In general, the performance of the instrument is quite good. Bu how can I know if they will address this problem (I guess @tautech does his best to convince them to have a look at the situation. But if the design pertmits the required modifications to sort that out is another question.  Since the SDG6000X is a rather new model, we can probably expect several future firmware updates and maybe some improvements /extensions to its functions as well.

@ Siglent...    one more thing I wish to have included, and that should be an easy one: Please add in the "Phase" menu besides the existing degrees also a time value. Sometimes it's more comfortable to dial in the phase delay in milli, micro or nanoseconds than having to convert that frequency-dependant to degrees. Maybe also a third option could be added to the channel coupling - phase menu: Degrees offset, degrees ratio and constant time (seconds).

Cheers,
Thomas

[MrW0lf]

Now the "walk-through" of the Sync signal vs. the output is clearly shown and also the approx. 3.5ns span of the "jitter" can be directly measured. It also gets obvious that the frequency of the walkthrough depends on the deviation of the output frequency to a multiple of 200kHz.

That number sounds familiar, I have two SDGs and needed 4 channel sync and some other stuff. There similar number popped up ~3.3ns:
https://www.eevblog.com/forum/testgear/the-siglent-sdg2042x-thread/msg1081666/#msg1081666
After some hassle it got more less sorted. There are several posts on that page on the subject maybe you get some ideas.

[kerouanton]

I upgraded my SDG6022X from 6.01.01.28R1 to 6.01.01.29R10

- I noticed the hardware version was upgraded too (from 02-00-00-a9-30 to 02-00-00-68-38) ?! To what can it refer too? FPGA?
- I would need to revert back to the previous firmware, but I noticed it is not available on any siglent website (siglenteu.com, siglentamerica.com, and siglent.com/old.siglentamerica.com).

Any clue to get this previous firmware, please?

Thanks !

[tautech]

I upgraded my SDG6022X from 6.01.01.28R1 to 6.01.01.29R10

- I noticed the hardware version was upgraded too (from 02-00-00-a9-30 to 02-00-00-68-38) ?! To what can it refer too? FPGA?
- I would need to revert back to the previous firmware, but I noticed it is not available on any siglent website (siglenteu.com, siglentamerica.com, and siglent.com/old.siglentamerica.com).

Any clue to get this previous firmware, please?

Thanks !

AFAIK 6.01.01.28R1 was the first product release FW version and it hasn't been released onto the websites.
Siglent sometimes post this original version but in this case they haven't.
Unless they do, presume it's not available.

[TurboTom]

May I make a few suggestion for improvements of the user interface?

Since the predefined arbitrary waveforms are a real PITA to access and finding the right one (that may fit a measurement situation best) even more so, wouldn't it be a good idea to have in case of the predefined arbitraries a menu item "Waveform Item" on the right side that can be zapped or scrolled through with the encoder? This would display the waveform in the frame to the left and would make visually finding the proper waveform mach easier and faster. Moreover, tapping on the touchscreen in the predefined arbitrary window should take the user directly back to the arbitrary selection table and not to the waveform selection menu. Even though this would be slightly inconsistent vs. the standard waveform functions, it would make life so much easier. If the user wants to access the basic waveform selection, there's always the hard key for that.

I think Siglent should really make better use of the touchscreen and not only duplicate functions that are already easily accessible via physical buttons. A good example is the output impedance ("Load") setting, here the accessibility via the touch screen is considerably improved.

Oh yes, and I would appreciate a WAV import function in EasyWave. If there already is one, I didn't find it, if not, the road via WAV -> CSV -> EasyWave -> SDG is somewhat uncomfortable. Maybe also include a direct import filter for WAV files int he SDG? Maybe integrate an MP3 player ?? 

One thing I don't like is the yellow symbol with the exclamation mark indication for every message. For me a symbol like that indicates a warning. If I insert a USB thumb drive and get a message with this sign, it's somewhat out of place. A blue "i" for information would be much more reasonable in that case.

Edit: Just noticed: The function buttons should, if pressed repeatedly, and the associated menu consists of more than one page, toggle between the pages. This would eliminate the need for a "Page" button and permit faster access to the functions.

These are just a few things that may improve usability a lot and they shouldn't be too difficult to implement.

Cheers,
Thomas

[tautech]

@TurboTom
I believe Siglent has sent you some beta firmware to address some issues you found. Have you anything to report ?

[TurboTom]

Indeed, I received a beta firmware from Siglent. I agreed with them not to share it since it's experimental and Siglent don't want it to be "floating" through the web. I also had some good correspondence with them regarding my other ideas for improvements of the AWG and got their confirmation that their engineers will look into each of my points and check them for feasibility and will try to integrate them into future firmware versions. Most of these suggestions for improvement address the "eyes-off" operation of the U/I.

The beta firmware basically takes care of the signal pauses when changing parameters of the "conventional" waveforms. Actually, Siglent got that sorted, the problem is solved in independant channel mode only (that's what I was hoping for -- a big  for this!), a solution for the phase locked mode is apparently way more complex and will have to be addressed in future. I don't know when to expect the next official firmware update, but Siglent confirmed that the changes that solved the pausing problem will be included.

I'm actually very happy with their fast reaction to my "rants"...  , and especially this professional attitude convinced me to keep the SDG6022X.

Cheers,
Thomas

[kerouanton]

Thanks Thomas for the feedback, and a huge thanks to Siglent engineers for their really fast support.

I also was hoping the User Interface would be improved on my SDG6000X on the waveform selection. As you described, the list of waveforms should ideally include a small graphical representation. But more importantly, pressing the "waveform" button should display the *last* menu bar with the currently selected waveform, and not reset to first page with "Sin etc...". That would save a few keypresses and frustration.
Even better: ideally, pressing the "Waveform" button after choosing an arbitrary waveform should bring us back to the precise waveform selection page where we were. It would save also a few keypresses...

Bruno

[TurboTom]

It seems that with square (pulse??) output and sweep enabled, the SDG6000X automatically changes rise- and fall time from 2ns to 1ns which results in considerable overshoot and ringing, see attached screenshot. Can somewone confirm this on a stock instrument (my machine is currently "improved")?

Thanks,
Thomas

[MrW0lf]

It seems that with square (pulse??) output and sweep enabled, the SDG6000X automatically changes rise- and fall time from 2ns to 1ns which results in considerable overshoot and ringing, see attached screenshot.

Prob switches to DDS mode which is ringy by itself. Maybe worth checking if sweep change is smooth or "stepped" at top end. Sort of rings a bell if you look my issue with DDS square and phase shifts.
Will look sometime later if SDG2000X exibits same. It is of great interest because I sort of need SDG6000X myself but better if good people iron it out a little first...

[Performa01]

It seems that with square (pulse??) output and sweep enabled, the SDG6000X automatically changes rise- and fall time from 2ns to 1ns which results in considerable overshoot and ringing, see attached screenshot. Can somewone confirm this on a stock instrument (my machine is currently "improved")?

Thanks,
Thomas

I can confirm this. When sweep mode is engaged, the transition times decrease to 1ns (measured as some 1.3~1.4ns on the SDS2304X) and overshoot changes from virtually nothing to 10% for the rising edge - interestingly, only some 5% for the falling edge.


SDG6052X_Square_Sweep

It reverts back to 2ns and virtually no overshoot as soon as the sweep is switched off again.

[MrW0lf]

Yep, SDG2000X does square sweep with DDS. What annoying you cannot choose DDS for non-sweep mode, which could be useful in some cases. And of course no oversampled square for sweep currently... Sweeps 17.5-22.5MHz. Just square is 20MHz.



Edit: For reference. RFE6GEN 35-45MHz...


BTW looking manual for SDG2000X DDS is 300MSa/s => ~3.3ns step. SDG6000X is 1.2GSa/s => ~0.8ns step.

[rf-loop]

It seems that with square (pulse??) output and sweep enabled, the SDG6000X automatically changes rise- and fall time from 2ns to 1ns which results in considerable overshoot and ringing, see attached screenshot. Can somewone confirm this on a stock instrument (my machine is currently "improved")?

Thanks,
Thomas

What is this Rigol "DS4000 improved" true risetime.
In your image it looks there is around 0.7ns risetime.
Specified risetime for 500MHz model is 0.7ns and typically most of scopes are bit faster than specs limit.
Now if Siglent SDG risetime is 1ns, how this image is possible.
If rigol rt is 0.7 and Siglent 1ns then it need show 1.2ns
If Rigol risetime is (example) 0.5ns and siglent 0.5ns then we can see around 0.7ns (or what ever others what give: SQR(rtR^2+rtS^2) = 0.7
This can not  be Sinc interpolation "Gibbs" because sampling speed is 4GSa/s
So what is this around 500MHz ringing and where it happen and this same ringing frequency can also see before edge (aka preshoot) but quite low amplitude. Inside Siglent SDG alone or where.

What happen if you add 10dB attenuator to scope input bnc (and scope input 50ohm) and same with say example 10cm different cable length. (is it pure 50ohm impedance for these frequencies what are coming to input in this case)



@TurboTom image: Looks like 0.7ns risetime

[kerouanton]

Anyway, here's the first clip, me demonstrating the sync / output jitter and some other strange stuff:

http://www.turbinemuseum.de/files/SDG6000X/SDG6000X_org2.mp4

I tried to reproduce the 1MHz/1.000.001MHz jitter bug (1st video), but didn't succeed. With the same settings  connecting the output trigger of the SDG on my SDS 1104, the output signal seems stable, in all cases. I'm using the latest firmware on both machines.

[rf-loop]

Anyway, here's the first clip, me demonstrating the sync / output jitter and some other strange stuff:

http://www.turbinemuseum.de/files/SDG6000X/SDG6000X_org2.mp4

I tried to reproduce the 1MHz/1.000.001MHz jitter bug (1st video), but didn't succeed. With the same settings  connecting the output trigger of the SDG on my SDS 1104, the output signal seems stable, in all cases. I'm using the latest firmware on both machines.

But your trigger is from CH1, and then you look CH1 edge. Of course there is not visible jitter.
Set rising edge trigger to half of output trigger signal level (CH3) and then look CH1 edge.

[kerouanton]

Sure! I just noticed it 
Setting the trigger source to CH3 where my output trigger lands doesn't seem to change the result anyway. the signal is stable. Btw I forgot to mention I send a stable 10MHz reference clock to the SDG (Leobodnar GPSDO). Maybe it helps.

[TurboTom]

@rf-loop -

I did some tests with a 20db (10:1 by voltage) 50 ohm attenuator, here's the result. Please be aware that I dialed in the probe factor at the scope to match the attenuator so the amplitude measurements correspond to the input of the attenuator, not the scope. Both the attenuator (20dB SMA -> SMA) and the cable (90cm RG316 BNC -> SMA) I used are DIY but checked and verified for accuracy and impedance matching up to 2GHz, so in the required frequency range, we can consider them to perform accurately.

The first screeshot (No 14) represents the output signal of Leo Bodnar's fast square wave generator, routed directly through the attenuator to the scope input (no cables whatsoever. The pulser is characterized by Leo to provide rise- and fall times faster than 50ps. You may compare this measurement with the one here for the same signal without attenuator.

Next screenshot (No 15) corresponds to the square wave output of the SDG6000X without sweep, measured with the cable on the output and the attenuator on the scope input. Clean ("as a whistle"  ) 2ns slopes and almost no overshoot and no ringing present.

No. 17 shows the sweep, clearly observing the considerable ringing which is way more pronounced than the overshoot of the scope with the pulser (No 14). Slope is much faster now, if "averaging out" the ringing, it's in the ballpark of 1ns. I also took a reference trace with the cable / attenuator arrangement reversed, i.e. the attenuator is at the SDG6000X's ooutput. No difference was observable whatsoever.

To eliminate the faint possibility that the ringing is produced by the cable, I used a much shorter (length 30cm) RG316 cable in screenshot No 18, this time with the trace of No 17 as reference. The signal appears to have just a tiny bit higher amplitude which can be expected due to the much shorter length.

So I guess this pretty much proves that the ringing is actually present at the SDG6000X's output in square waveform sweep mode and that it's not a result of the scope's input circuitry or signal processing approach.

[kerouanton]

Okay I'm just a beginner in measurement...need to train more!
The issue is visible, yes.

[MrW0lf]

So I guess this pretty much proves that the ringing is actually present at the SDG6000X's output in square waveform sweep mode and that it's not a result of the scope's input circuitry or signal processing approach.

If take 50% square from Arb wfm built-ins and set generation to DDS (from TrueArb)? Does it look the same?