Siglent SDG6000X series 200-500 MHz AWG's

[Hexley]

Looking at something today, i found out this. I don't know if it is known thing..
If you enable sweep on square wave, output filter gets confused and on sweep output gets much faster risetime and it rings. Same with modulation.

This behavior is seen across the product family. See, for example, this report for the SDG1032X: https://www.eevblog.com/forum/testgear/siglent-sdg1000x-waveform-generators/msg3207954/#msg3207954

Probably baked into the hardware architecture; I doubt that it would be affected by firmware. Fortunately, it is more of a cosmetic issue than anything else.
 

[2N3055]

Looking at something today, i found out this. I don't know if it is known thing..
If you enable sweep on square wave, output filter gets confused and on sweep output gets much faster risetime and it rings. Same with modulation.

This behavior is seen across the product family. See, for example, this report for the SDG1032X: https://www.eevblog.com/forum/testgear/siglent-sdg1000x-waveform-generators/msg3207954/#msg3207954

Probably baked into the hardware architecture; I doubt that it would be affected by firmware. Fortunately, it is more of a cosmetic issue than anything else.

Thank you for info. But you are mistaken, it is more than cosmetic. In that state, AWG starts generating significant harmonic content up to 600MHz region, that is definitely not welcome...

In attachment, spectrum of 20 MHz square wave, without mod (red trace), and blue trace with 0% modulation (so there is no modulation whatsoever, but filtering goes crazy..)   

That is definitely far from good quality pulse generator, and limits it's use...

BUT......

I think they can fix this. You know why? Because if you go to pulse waveform, set it to 50% duty cycle, and 2 ns edges, it DOESN'T screw up filtering when you enable PWM modulation....  Also filter doesn't behave same for all types of modulation...

So at this moment I  use Pulse waveform most of the time..... It also has edge control...


Regards,

Siniša

[Sergio66]

Hello everybody,

I got my new SDG6022X since a few weeks and I'm now using and testing the instrument, being quite happy on its general performances. Here I'm reporting some issues using arbitrary waveform: before contacting Siglent, I'd like to check if anybody else has found the same problems. (By the way, my instrument has the last 6.01.01.35R5B1 firmware release).

First of all, since I need to generate a digital pattern to emulate a sequence of CAN frames, I'm defining an arbitrary waveform as a sequence of +1 and -1 (or 1 and 0, that's the same): for sure it is not the way the arbitrary waveform generator was supposed to be used, but ... (since I have not a pattern generator) why not?

Let's discuss the behavior in TrueArb mode first and then in DDS mode.

- TrueArb mode

The behavior is really perfect: the pattern is generated exactly as defined, using 0-order hold interpolation (also linear and three different sinc interpolations are available), for all the pattern length (that menas number of points) I used (up to 512k points). There are only a couple of limitations in TrueArb mode:
A) the sampling rate is limited to 300Msample/s (that is not really a limitation, but a specification; just to mention that in DDS the sampling rate is up to 1.2Gsample/s)
B) the waveform cannot be bursted nor sweeped. That's a big limitation for my purpose (to send burst of frames). Is it really not possible to burst a waveform generated in TrueArb mode? Are there intrinsic hardware limitations to do that or it would be possible in a new firmware release?

- DDS mode

In this mode I found several issues and I think a new firmware release to fix them would be needed. Here following the main problems.
1) interpolation mode cannot be selected: it is fixed to linear. I think it should be not an issue to provide also the 0-order hold, at least, so an upgrade in a new firmware would be really appreciated.
2) the number of points managed in DDS mode is 32k maximum (that means 32768 points). This could be not a huge limitation, but it should be clearly specified, in order to let the user understand which waveform the instrument will output. So, if a greater number of points is provided (in a .csv file, for example), these points will be down-sampled to 32k, while providing a lower number of samples, the waveform will be linearly interpolated to create a 32k-points waveform. I suppose this 32k is a hardware limit (the extent of the fast memory used to generate the DDS waveform) and we can accept this (provided this is clearly specified).
3) the interpolation applied by the instrument is really poor, or better, is affected by a bug.
Here attached you can see the behavior with a 1,-1,1,-1,1,-1,... sequence with a 2k (2048) total points.
 TEST_DDS_2k.zip (0.19 kB - downloaded 97 times.)

As you can see, 15 steps are added to a single point (from 1 point to 16 points, to fill the 32k memory), but the linear interpolation is performed as the steps would be 18 instead of 16, so, skipping the last two steps of interpolation.

In a similar way, providing a 4k sequence I got this behavior:
 TEST_DDS_4k.zip (0.21 kB - downloaded 90 times.)

In this case, a couple of points is "oversampled" to 16 points, with a linear interpolation with amplitudes computed as the points would be 18 (and skipping the last two steps).

As a further trial, providing a 32k sequence, the behavior is the following:
 TEST_DDS_32k.zip (0.36 kB - downloaded 96 times.)

Even if the number of points is matching the number used by the DDS generator, the bug of interpolating 16 points as they were 18, is providing this bad sequence of 16 steps (far from being the expected square waveform)

(please, note that I used a quite big period for the generated waveform and the result is not depending on that value, provided all the steps are not as short as the instrument limit).

I think this bad interpolation behavior is really poor and needs to be fixed!


Please, let me know in case you had similar or different experience with the arbitrary waveform generation on this instrument.


Best regards.

Sergio

[TurboTom]

Sergio -
yes I can confirm this behaviour with my 6000X. It appears that in DDS mode, the instrument (for whatever reason) tries to emulate a linear interpolation. In TruArb mode, there's the choice of the interpolation type (None, Linear, Sinc, Sinc27, Sinc13). If you chose linear, the signal looks similar but obviously much more clean. I assume that the 32k file is too long for a "proper" linear interpolation in DDS mode. Moreover, as you can see when comparing the outputs of the 2k and the 4k files in DDS mode, the more "information" (periods) have got to be cramped into the available sample, the more granular the interpolation gets.

What's really confusing is that once again, you get an output signal that differs completely from what's displayed on the screen.

I wonder when/if Siglent addresses the multitude of pending problems of this instrument and also if they will take care of the atrocious U/I and modernize it, making reasonable use of the touch screen. This is their top-notch AWG and reliability and dependability is a nightmare! Probably they want to sell an oscilloscope with each of the AWGs so the customers can use it to verify the generator is outputting the correct signal. They should actually include it in the box free of charge, otherwise the AWG is unusable  .


Edit: I just did some testing with other AWGs that I've got available and got some interesting findings: Apparently, all the generators that utilize some kind of "slope shaping", attempt to interpolate the edges of the waveform, regardless of the mode they are configured in. This means, a Rigol DG800/900 will also fail at accurate reproduction. Yet, a Rigol DG4000 series AWG will accurately generate the signal, though depending on frequency setting, it will suffer from phase jitter of one sampling clock period as it's common with "straight" DDS systems. Alltogether, maybe the sdg6000x shouldn't be attacked too hard for this shortcoming since the waveform is really somewhat special with extreme sample-to-sample difference. If it's possible to stretch the minimum pulsewidth to ten samples or the like, things will look much better. The problem may be the maximum sample length.

But I wonder why the manufacturers don't put protocol generators for common serial communication waveforms as a standard in their AWGs. Rigol does so for a standard UART protocol in their DG800/800/2000 series, but it will only generate one byte all over again. Nevertheless, a few times I found that useful already. What about CAN, I²C or SPI. Of course, if too complex arbitration is required, this dosn't make sense like in case of LAN or USB.

[2N3055]

Sergio -
yes I can confirm this behaviour with my 6000X. It appears that in DDS mode, the instrument (for whatever reason) tries to emulate a linear interpolation. In TruArb mode, there's the choice of the interpolation type (None, Linear, Sinc, Sinc27, Sinc13). If you chose linear, the signal looks similar but obviously much more clean. I assume that the 32k file is too long for a "proper" linear interpolation in DDS mode. Moreover, as you can see when comparing the outputs of the 2k and the 4k files in DDS mode, the more "information" (periods) have got to be cramped into the available sample, the more granular the interpolation gets.

What's really confusing is that once again, you get an output signal that differs completely from what's displayed on the screen.

I wonder when/if Siglent addresses the multitude of pending problems of this instrument and also if they will take care of the atrocious U/I and modernize it, making reasonable use of the touch screen. This is their top-notch AWG and reliability and dependability is a nightmare! Probably they want to sell an oscilloscope with each of the AWGs so the customers can use it to verify the generator is outputting the correct signal. They should actually include it in the box free of charge, otherwise the AWG is unusable  .


Edit: I just did some testing with other AWGs that I've got available and got some interesting findings: Apparently, all the generators that utilize some kind of "slope shaping", attempt to interpolate the edges of the waveform, regardless of the mode they are configured in. This means, a Rigol DG800/900 will also fail at accurate reproduction. Yet, a Rigol DG4000 series AWG will accurately generate the signal, though depending on frequency setting, it will suffer from phase jitter of one sampling clock period as it's common with "straight" DDS systems. Alltogether, maybe the sdg6000x shouldn't be attacked too hard for this shortcoming since the waveform is really somewhat special with extreme sample-to-sample difference. If it's possible to stretch the minimum pulsewidth to ten samples or the like, things will look much better. The problem may be the maximum sample length.

But I wonder why the manufacturers don't put protocol generators for common serial communication waveforms as a standard in their AWGs. Rigol does so for a standard UART protocol in their DG800/800/2000 series, but it will only generate one byte all over again. Nevertheless, a few times I found that useful already. What about CAN, I²C or SPI. Of course, if too complex arbitration is required, this dosn't make sense like in case of LAN or USB.

Thanks for info..

As for protocol generators, I got Digital Discovery. That one can serve as pattern generator and can generate some serial protocols...

[noreply]

@TurboTom

I have been wondering if it’s possible to use a device such as the SDG6000X series to generate a DVB-T modulated stream?

I don’t mean just to provide the IQ information to an external ‘box’ to generate the DVB-T signal stream but in fact the complete encoded data stream – like a DVB-T ‘test pattern’ signal.

Perhaps an external input of a digital encoded data stream could be used to provide a non-static DVB-T baseband signal ready for transmission to a DVB-T receiver?

Sorry I have never evaluated a device such as the  SDG6000X series and although it looks like a very capable – I’m not sure if it has some mileage for DTV experimentation other than some basic modulation testing by mixing some ‘synthetic noise’ signals with an external DVB-T modulated carrier?

Something I used in the past for generating DVB test signals has been with an SDR such as the ADLM Pluto using express DVB software – it works quite well – but it’s the work of a very clever guy who has generated this software for those interested in Amateur Radio DVB transmissions.

Having the flexibility of a test equipment generator to do similar would be great if indeed such functionality can be provided by devices such as the  SDG6000X series AWG's

My gut feeling is that’s not something that AWG’s were designed for – which leaves the door open for specialist DVB test equipment – which is a lucrative market in itself.

I guess I  answered my own question – but just asking anyway … just in case there is some mileage in using AWG’s for DVB work?

Cheers

[Sergio66]

Sergio -
yes I can confirm this behaviour with my 6000X. It appears that in DDS mode, the instrument (for whatever reason) tries to emulate a linear interpolation. In TruArb mode, there's the choice of the interpolation type (None, Linear, Sinc, Sinc27, Sinc13). If you chose linear, the signal looks similar but obviously much more clean. I assume that the 32k file is too long for a "proper" linear interpolation in DDS mode. Moreover, as you can see when comparing the outputs of the 2k and the 4k files in DDS mode, the more "information" (periods) have got to be cramped into the available sample, the more granular the interpolation gets.

Hi TurboTom,

    thanks for confirming this behavior in your side.

In DDS mode the interpolation type seems to be fixed to Linear (while None/0-order hold cannot be selected): it's pretty clear that, being 32k the memory size used for DDS, the granularity of the interpolation will be finer if the initial number of samples is lower. What I'm anyway expecting (and I think is a reasonable request) is that this linear interpolation is correctly implemented.
Now, it's quite evident the devices uses 32k memory for the DDS implementation looking at the built-in arbitrary waveforms: they are all defined with 32768 points. So, at the very end, I'm at least expecting the device allows the user to provide exactly the 32768 points the user defines, without any distortion/bad processing from the instrument.

Edit: I just did some testing with other AWGs that I've got available and got some interesting findings: Apparently, all the generators that utilize some kind of "slope shaping", attempt to interpolate the edges of the waveform, regardless of the mode they are configured in. This means, a Rigol DG800/900 will also fail at accurate reproduction. Yet, a Rigol DG4000 series AWG will accurately generate the signal, though depending on frequency setting, it will suffer from phase jitter of one sampling clock period as it's common with "straight" DDS systems. Alltogether, maybe the sdg6000x shouldn't be attacked too hard for this shortcoming since the waveform is really somewhat special with extreme sample-to-sample difference. If it's possible to stretch the minimum pulsewidth to ten samples or the like, things will look much better. The problem may be the maximum sample length.

On this last point, I don't fully agree with you. We can argument that here I'm trying to use the instrument as a pattern generator, that is not really the intended purpose of this arbitrary waveform mode, but if the generator is able to apply a decent linear interpolation in DDS only with a number of points limited to a few tens, this is, in my opinion, equivalent to say the arbitrary waveform in DDS mode is useless.
Here I'd like to point out that my main complaint is related to the bad linear interpolation of SDG600X, that is interpolating groups of 16 samples as they were 18: this is (still in my opinion) clearly a quite trivial bug, that most probably could be very easily fixed.
One point is not fully clear to me regarding the test you did with other Rigol generators: in DDS mode, are they allowing to select between linear interpolation and no interpolation?  Based on what you reported, I suppose DG4000 series has this capability, while the others (DG800/900) have only linear interpolation. But I suppose they are applying the linear interpolation in a correct way, isn't it? (of course, here I'm not considering the behavior in terms of jitter, since this is a well known limit of the DDS approach).

Here below I summarize my complaints related to the SDG6000X Arbitrary mode, to better clarify, also for other users, which limitations I faced.

1) an arbitrary waveform in TrueArb mode cannont be sweeped nor bursted. This limitation is not declared/clarified in the AWG datasheet.
2) an arbitrary waveform in DDS mode is only Linear interpolated (not possible to have 0-order hold interpolation). This limitation is not declared/clarified in the AWG datasheet.
3) number of points managed in DDS mode is equal to 32768. In SDG6000X datasheet number of points is reported as 2 min. and 20M max, without any mention to TrueArb mode (where these limits are true) or DDS mode.
4) wrong interpolation of the waveform in DDS mode, to generate the 32768 points used by the unit. The interpolation is generating groups of 16 samples linearly interpolated as they were 18 (skipping the last two samples).

For the first three items I agree we can accept them and we should not attack too hard Siglent for that (even if adding no-interpolation in DDS mode should be not a huge request), but the forth it's really a bug that needs to be fixed.

As I said before, I think the very minimum request is the following: considering the unit is using 32768 points to generate the waveform in DDS mode, the user should have the possibility to provide these 32768 samples, without any distortion or bad processing superimposed by the instrument.


...on top of that, if they can add a protocol generator for common serial communication, this would be more than welcome!


Thanks for all your comments and useful evaluations!

Sergio

[Sergio66]

Just to highlight that SDG6000X linear interpolation in DDS mode is really badly implemented: please, have a look at the waveforms I get with my SDS2104X Plus using its the internal AWG (50MHz, 125MS/s, 16ksamples) using the sequences 1,-1,1,-1,1,-1,...  with 2k (2048), 4k (4096) and 16k (16384) total points.





The internal AWG of the Siglent oscilloscope uses 16384 samples to DDS generate the waveforms, so, of course the interpolation is using a lower number of steps if compared to the ones generated by the SDG6000X, but in all cases the linear interpolation is correctly computed! In particular providing to the scope's AWG 16384 points, the generator will use exactly that provided set of points, without any "distortion" or bad processing on them.

So, the high performances, high cost SDG6000X AWG is in real case performing worse (from this point of view) than the low performances, low-cost, built-in generator of the SDS2000X Plus oscilloscope ....of course, both from Siglent!

....that's a shame!! 

Sergio

[2N3055]

Hello!

Question to Siglent.

Is SDG6000X considered abandoned product, or there is a plan to fix many complaints and bugs reported more than 6 months ago ?
It's been more  than a year since last firmware... SDG6000X Firmware – 6.01.01.35R5B1 (Release Date 09.18.19)
My patience is quite stretched at this point...


Regards, and Happy Holidays to all!!

Siniša

[TurboTom]

I already gave up asking... My '6000X is currently shelved in the basemet and collecting dust. Too annoying U/I and all the mentioned bugs make it compulsory to view the output on the scope every time something's changed, to be sure the instrument is working as it should. For low(er) frequencies, I've got enough more decent replacements, and if I need high frequencies, I'll pick an RF signal generator. Altogether, just too much pain to use. At some point in time, this hurts more than the feeling to have sunk a nice value into this generator. I drew my consequences -- you know "fool me once...".

[tautech]

Wee note from Siglent tech support today, Christmas day:

SDG6000X
We are preparing a new firmware version and it will be released at February 2021.

[2N3055]

Wee note from Siglent tech support today, Christmas day:

SDG6000X
We are preparing a new firmware version and it will be released at February 2021.

Thanks!!

[djhatton]

Oh man that's disappointing. I am in the market for a sig gen. I had high hopes for the 6000x as it looks like quite decent hw. But I guess Siglent aren't there yet.

The device started shipping in 2017. In 2021, we might get a firmware that might fix some of the bugs? Really?

I don't get it. Presumably, if they produced test equipment that was actually tested, they would totally cream the market (!?). Why wouldn't they have thrown all of the programmers at the device four years ago and debugged it fully? Then they could have spent the last three years establishing their product as a serious contender.

I guess it's part of the sledgehammer approach China is so fond of. Bash it out as soon as possible. I think T&M deserves more care.


An aside - my first post! I have perused for years. Now I sign up to rant Future posts potentially more productive

[2N3055]

Oh man that's disappointing. I am in the market for a sig gen. I had high hopes for the 6000x as it looks like quite decent hw. But I guess Siglent aren't there yet.

The device started shipping in 2017. In 2021, we might get a firmware that might fix some of the bugs? Really?

I don't get it. Presumably, if they produced test equipment that was actually tested, they would totally cream the market (!?). Why wouldn't they have thrown all of the programmers at the device four years ago and debugged it fully? Then they could have spent the last three years establishing their product as a serious contender.

I guess it's part of the sledgehammer approach China is so fond of. Bash it out as soon as possible. I think T&M deserves more care.


An aside - my first post! I have perused for years. Now I sign up to rant Future posts potentially more productive

Well,

it's not all black, you know..
AWG with 500MHz bandwidth, clean 2ns edges (less than that rings), PRBS, I/Q modulation... Even with quirks it still has something to offer.
It is mostly that it could be so much better. 
And it should be.

I'm still patient (not very much though) because, every update so far was much improvement. Problem is they stopped with updates, presumably because of pressure releasing 3 flagship scopes, that are breakthrough new platform..

If they resume with normal bug fix and firmware release policy for SDG6000X it will soon be forgotten and forgiven...
As you said, in hardware, it seems capable platform. If they fix all remaining quirks, to make it rock solid, it will be one great AWG.

Fact is, the part of the reason that price Siglent charges for their equipment is lower than, say, Keysight, is that Siglent has smaller workforce and smaller R&D budget.
So it is part of the tradeoff...

If that is unacceptable, there are much more expensive AWGs from brand name manufacturers. Pick your poison.

[tautech]

Wee note from Siglent tech support today, Christmas day:

SDG6000X
We are preparing a new firmware version and it will be released at February 2021.

Thanks!!

Yes well the community here has pushed them to get on with it as recent comments had been spotted and they felt they should get a move on. 
That's not to say I didn't thank tech support also however along with that bouquet was also a brickbat to get on with SDM3055 FW we've also been promised for months ! 

Some of the product mangers are excellent, some not so much....... 

[djhatton]

I appreciate that you (mostly) get what you pay for. I used a 33612 extensively at an old workplace and came to like it lots. I guess it is folly for me to hope the Siglent might compare.

But I mostly just see it as a missed opportunity. Potentially, it could have been quite competitive; the hardware is there to bring a strong fight. But the product has been out for years now and yet still feels beta. It would be one thing if it were just relatively benign UI bugs or whatever. But it seems there are a number of reported (and how many yet unreported?) problems in the core waveform generation / signal processing. I feel these absolutely fundamental aspects should have been more thoroughly tested before the thing shipped. There would be a modicum of concern every time I wanted to connect it to my DUT. Is the signal coming out as it says it is? Or will I blow up my circuit? I am reluctant to put something like that in my lab.

Instead of moving the design teams on to work on a new scope platform, I would first have had them finish the product at hand. I know, IRL, it is not that simple and it doesn't work like this But still, it feels like there was not enough testing done. For a test equipment manufacturer, I don't think that's good enough. Producing cheap equipment shouldn't preclude them from this, especially as it is the core of their business. The quality of their offering could be improved so dramatically, if they just spent a little bit more effort on the software and weren't so focused on continuously and aggressively rushing new hardware to market.

I feel just one 'golden' product is all it would take for them to begin changing their image. They could be producing the 'go-to' entry-level AWG, no? Word travels fast and if their generators were the killer entry, people would start to buy them en masse. Siglent could have their own HP200A-like moment?

[TurboTom]

...
Instead of moving the design teams on to work on a new scope platform, I would first have had them finish the product at hand. I know, IRL, it is not that simple and it doesn't work like this But still, it feels like there was not enough testing done. For a test equipment manufacturer, I don't think that's good enough.
...

And so the SNA5000X gets announced... 

[tautech]

New firmware for SDG6000X models.

Version： V6.01.01.36
25.6 MB
https://int.siglent.com/upload_file/zip/firmware/Signal_generator/SDG6000X_V6.01.01.36_EN.zip

Release notes
Allowed one channel to modulate the other
Supported Burst in TrueArb mode
Supported Burst Counter in Burst mode so the number of burst trains can be set to > 1 when trigger source = external or manual
Added an option to let the SDG start with activated outputs
Added 50 ohm output impedance text in the UI
Able to remember the digit of a parameter that had been modified
Fixed several bugs:
DDS interpolation bug
Switching on/off output causes random phase deviation between channels in Track mode
Incorrect square/pulse waveform initialization in some cases
Unable to store the level settings for noise
Unable to recognize the command MODE PHASE-LOCKED
Freezing issue when being written a 20MB long file with the EasyWaveX
The setting "BANDSET" with Waveform = NOISE leads to inconsistent behavior on the Noise Bandwidth of the output signal; The real-time noise bandwidth on channel 2 is changed if an AM sine modulation is switched on channel 1
Unable to install the IQ option before 30 trials run out

[2N3055]

Installed.
Right of the bat, I see no "undulation" effect in what I tried so far.. Will go into detail later..
Also in a quick test, I see no phase walking between channels..
So far so good.

And for the fun: AM modulating AWG waveform on a CH1 with burst AWG waveform on CH2...   

[TurboTom]

Installed new F/W as well - procedure was troublefree whatsoever - and directly did a few tests: It seems, Siglent took care of all  the initialization issues,  for that! Also, thanks a lot for providing a memory for the "adjusted digit location".

Yet, Siglent still missed the chance to add some improvements to the U/I that would make usage of the generator much more comfortable:

- Changing parameters incrementally is still awkward and inconsistent, i.e. enter frequency 10MHz and place the cursor for incremental adjustment of the 1MHz digit. As long as the set frequency is more than 1MHz, everything's fine. But if 1MHz is reached and the value decremented once more, the frequency changes to 0Hz and the cursor is placed on the 1Hz digit. If this happens in pulse mode, all the other timing parameters (width, slope) get reset to minimum! So if you reverse direction of the incremental input, you would adjust in 1Hz increments and not 1MHz as before. In this case, I would actually keep the leading zeros up to the digit that's suppsoed to be adjusted. Just don't jump digits! This makes using the incremental input a real PITA! And store the other timing parameters in pulse mode.

- The same situation for positioning the cursor for incremental adjustments: If you are in a low frequency range (say 1kHz) and would like to incrementally adjust the 1MHz digit, that's not possible without having to either enter a correspondingly high frequency via the keypad, or interactively by several times increasing the most significant digit until a carry to the next higher digit takes place and than changing cursor to that digit and so on. Couldn't just more leading zeros be added when changing the cursor position to the left? This and the previous issue is present in all menus that permit incremental number input. The noise WF bandwidth entry appears to be even more awkward, it's just not consistent with the other numeric input masks -- seems like different programmers working on the individual modules have used different input schemes -- time to get rid of these inconsistencies.

- Selection of (built-in) arbitraries still requires checking through way too many menus (Waveform -> Page2 -> Arb -> Arb Type -> Built-In / Stored WFM). Only then, the category and the actual waveform, or the file (stored WFM), can be selected. Why all this hassle while there would be an easy way to access the corresponding selection menu: When in arbitrary mode, depending on the last Arbitrary used, enter the "Built-In" or "Stored WFM" screen when tapping the waveform visualization on the touch screen instead of just opening the "Waveform" menu. This would be a deviation from the currently present standard, but it would improve usability a lot! To enter the "Waveform" selection screen, there's already a hard button, no need to duplicate this on the touch screen!

- Introduce a configuration switch to lock related parameters: If changing frequency for example, just limit the frequency adjustment range if the selected output amplitude wouldn't be available at the frequency dialed in. Same for frequency / pulse width / slope. Don't change other parameters to enable selecting a related pramerter that's outside the range available in that configuration. Such an "automatic adjustment" easily goes by unnoticed and may cause trouble afterwards. Some switch in the instrument options like "lock related parameters" / "adjust related parameters" would be very useful.

- In "Sine Harmonic Mode", please add Vrms and mVrms for configuring the harmonic amplitudes. I don't see a reason why this is omitted.

- I'ld still love to see configurable parameter limits to be added to the incremental control so the user can assure parameters to stay within a certain interval when using the encoder (for example: frequency within 450...460kHz or pulse width between 5...49µs). This would improve eyes-off usability considerably    . I still think, many users would appreciate this.

I'll have a closer look at the previous waveform problems later, so far it seems some progress is going on, and I want to thank Siglent for that!

Edit: Undulation effect still there, select pulse; rise- and fall times 1ns and a frequency just a tad off a natural multiple of the sampling frequency (i.e. 11.9999999 MHz), and here you go. But that doesn't come unexpectedly, the reconstruction filter just hasn't been optimized for such fast slopes. As before, at slopes of 2ns or more, the effect is neglible.

[oz2cpu]

thanks a lot for the latest fw tautech
just installed it, my brand new SDG6022X came with 6.01.01.35R5B1

the dial is still skipping steps, I need to turn it a bit slower then i am normally used to, for it to react correctly
I just need to learn to think slower i suppose :-)
output voltage swing at higher frequencies is not impressive (but that is clearly explained in spec sheet)
and its useable bandwidth in pulse mode or any other fancy modes over sinus, is about 10-50MHz
the 200MHz output range, is sinus only, and at very low voltage output, and even then, i see 60% less voltage at 200MHz versus 20Mhz (it is not the scope :-)

[rf-loop]

the 200MHz output range, is sinus only, and at very low voltage output, and even then, i see 60% less voltage at 200MHz versus 20Mhz (it is not the scope :-)

Sorry but I do not understand what you mean. Can you explain this bit more detailed.

[TurboTom]

..., and even then, i see 60% less voltage at 200MHz versus 20Mhz (it is not the scope :-)

Did you use proper termination and cabling for the measurement? Actually, I see still some improvement options for this AWG, but the level accuracy definitely isn't one of them. All my tests of my SDG6000X, and actually right from the start, confirmed that it's level accuracy is superb.

[oz2cpu]

after playing with arb wave forms and back to sinus, it went into low output odd mode, power off and back on, and now it acts normal again,
I cant remember exactly what combination of experiments i did, so now i am not able to recreate it,
by the way the VOICE : say Hello :-) so there might be an odd way to jam it,

anyways at 1v out setting i get 1v on scope, short bnc cable, and 50 ohm all
SINUS:
20MHz 1V
50MHz 970mV
100MHz 890mV
150MHz 750mV
200MHz 620mV

Most of my "complaints" are due to bandwidth, and once again can be explained by understanding the fundamental limits of what 200MHz means:
like goto Squarewave 1V out, max frek is only 80MHz
and the curve dont look at bit like squarewave, clearly due to it is 200MHz bw limited, and 3nS min rise and fall time,

for the more complex waveforms to actually look correct, the max frequency must be 10-50MHz else there is not enough bandwidth headroom to deliver the higher speed content of the curveforms,
again clearly normal, since it is 200MHz limited

lets try the ramp waveform
here is max possible set frequency is locked to 5MHz
risetime is under 2nS and the curve looks like attached
This is actually really nice, but I see some odd fast ringing at the top, and it is fading up and down,
I wounder how this looks on the faster models ?

[DL2XY]

This is what it looks on the SGS6052.

The ringing is due to sinc interpolation. Look at the risetime, 800ps has its fundamental frequency at 1.25GHz, this is Nyquist of the 2.5 Gsamples/s DAC!
Lower the risetime by allowing 1% symmetry and everthing looks fine.

Sine 200mV rms:
  20MHz   202.3mV  +0.10dB
  50MHz   203.3mV  +0.14dB
100MHz   202.6mV  +0.11dB
150MHZ   201.8mV  +0.08dB
200MHz   197.4mV  -0.11dB
300Mhz   189.0mV  -0.49dB
400Mhz   185.3mV  -0.66dB
500Mhz   168.5mV  -1.49dB

Measured with Cycle RMS Mean on SDS2504XPlus, 50Ohm internal termination.

Edit: The SDG reduces output level at higher frequencies due to slewrate limitation of the output power OP´s.
Look at the display [and manual ;-) ]
@150MHz:<=883mVrms, @200Mhz:<=530mVrms.