Siglent SDG6000X series 200-500 MHz AWG's

[rf-loop]

@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.

Thanks for the deeper tests you have done.
Now, new tests better exclude some possible external factors.
14. show some overshoot but in this context not so bad and only one overshoot without multiple cycle ringing.

Based to your tests here, SDG risetime  is in the class of 0.3ns (sweep mode, pulses)
(LeoBodnar's  average rt  vs SDG /sweep mode pulse rt average.)
But as in image 15, when rt is "normal" it looks better than just good.

Imho, 0.3ns risetime feels bit too fast for its output circuits. And together with this observed ringing, there can perhaps speculate, is it possible, there is bug in output filtering control.

[TurboTom]

Things get more an more weird and I get the impression that we're still at the very beginning of understanding and characterizing this instrument (and I'm afraid, Siglent may be as well...  ). As suggested by @rf-loop, I checked the overshoot / ringing situation with some ARB waveforms (among them Radar and Square 50%), and it appears that there's still some "controlled slope" managed in this mode, yet advanced to 1ns which results in some pretty ringing. Funny enough, if I additinoally enable sweep, I get the "uncontrolled slope" with rise times basically in the ballpark of my scope's frontend (only slightly slower). Please see the three screenshots. Configuration is the same as in my previous post. The REF trace in No 21 is the unswept square wave from No 20.

I also found that the Beta firmware provided by Siglent to me, fails with reproducing some of the arbitrary waveforms (Radar for instance doesn't work properly) and I also found some other problems so currently I'm back on the stock firmware. I won't got into detail here and discuss this with Siglent directly. It seems there's still some work do be done to sort all the problems completely. Since ringing / overshoot isn't specified for rise times faster than 2ns, these observations cannot be interpreted as bugs. But the customers may ask for a slope limiting function so the overshoot could actually be kept within specs in all operating modes.

Don't get me wrong, I'm not bashing Siglent, in contrary I'm quite pleased of their open communication and the approach to solve the issues in collaboration with the users. I think this is the way to improve the product and finally get a better result than the engineers alone could have ever reached in the same time. Let's see how the journey will continue...

[rf-loop]

Things get more an more weird and I get the impression that we're still at the very beginning of understanding and characterizing this instrument (and I'm afraid, Siglent may be as well...  ). As suggested by @rf-loop, I checked the overshoot / ringing situation with some ARB waveforms (among them Radar and Square 50%), and it appears that there's still some "controlled slope" managed in this mode, yet advanced to 1ns which results in some pretty ringing. Funny enough, if I additinoally enable sweep, I get the "uncontrolled slope" with rise times basically in the ballpark of my scope's frontend (only slightly slower). Please see the three screenshots. Configuration is the same as in my previous post. The REF trace in No 21 is the unswept square wave from No 20.

I also found that the Beta firmware provided by Siglent to me, fails with reproducing some of the arbitrary waveforms (Radar for instance doesn't work properly) and I also found some other problems so currently I'm back on the stock firmware. I won't got into detail here and discuss this with Siglent directly. It seems there's still some work do be done to sort all the problems completely. Since ringing / overshoot isn't specified for rise times faster than 2ns, these observations cannot be interpreted as bugs. But the customers may ask for a slope limiting function so the overshoot could actually be kept within specs in all operating modes.

Don't get me wrong, I'm not bashing Siglent, in contrary I'm quite pleased of their open communication and the approach to solve the issues in collaboration with the users. I think this is the way to improve the product and finally get a better result than the engineers alone could have ever reached in the same time. Let's see how the journey will continue...

How you can say

Funny enough, if I additinoally enable sweep, I get the "uncontrolled slope" with rise times basically in the ballpark of my scope's frontend (only slightly slower).

Due to previous tests including Leo Bodnar pulser test result with your scope, I think Siglent risetime is here in image must be 21 much faster than your scope risetime.
(image 14 LeoBodnar pulser your scope measure risetime average 638ps. Lets think this is your scope risetime. Now image 21 your scope measure 721ps. It mean that Siglent risetime is 336ps. [ (SQR(638ps^2 + 336ps^2) = 721ps ] )

But how ever, it is intersting. And there is now some "dejavu". I believe I have seen this happen somewhere previously somehow but I do not remember where. I mean some Siglent older equipment where I have seen some increase in risetime when change some mode (perhaps just from continuous mode to sweep) but this is now only some weak memory image in my old head also my memory can be wrong. 

So or so.. 
but how it give 0.3ns risetime out...   
Is it same result if you do tests with SDG6022X "out from box" condition (official 200MHz version)?

I'm not bashing Siglent,...

Do not worry,  careful well done tests and real raw data is not at all like bashing.
Also if there is problem, honest truth wins trumpth (aka alternative truth). Even if truth is worse than alternative truth.

I do not even think if this is real problem or not or borderline but it is technically interesting this phenomena exist and least it is good to know. My opinion is that this is better to fix (hw or sw) in normal order after higher priority things. Siglent also needs to notice this.

[TurboTom]

Oh, well, my rise time "statement" refered to the figures indicated on the screen (i.e. the measurement). Of course, I'm aware that the real rise time of the AWG has to be faster than my scope to produce these figures and that the numbers add up geometrically. I guess I didn't express it correctly - that's the problem of two individuals, both communicating in a foreign language  .

Cheers,
Thomas

[rf-loop]

Previously I told I have some kind of "dejavu" about something like this what I have seen somewhere....
I have checked it and I think I find this what I mean, not exactly same but..

SDG5000

If normal Square wave, (example 10MHz Sqr) rise time is  ~5.7ns

If just turn Sweep on (without any sweep, example start 10MHz and stop 10MHz)  risetime is 1ns more fast,  ~4.7ns and it also add some small detectable  "ringing" after edge but not at all this ringing level amount what we can see in @TurboTom images.
So, with different numbers but roughly same effect.
It looks like sweep mode change filtering.

[MrW0lf]

It looks like sweep mode change filtering.

I suspect it changes also from oversampling to DDS and you will get decreased frequency resolution also. Width SDG2000X 1.2GSa/s => 300MSa/s, SDG6000X 2.4GSa/s => 1.2GSa/s. This might also explain why on 2000 between channel oversampled (!) square vs sine phase relations are "complicated"*. Some "filtering" gets wfm shape straight but programmers have forgotten to hack phases right also. I'd suggest to check for sine vs square phase issues on 6000. Is it non-sweep square phase messed up in stepped manner depending on phase value (NB! error is also "oversmapled"), and is square sweep discretely stepped by 0.8ns.

Edit: * turns out not complicated at all

[Performa01]

Last weekend I’ve had a look at the “undulation” effect at 1ns transition times and sure enough I was able to reproduce it on the SDG6052X, as demonstrated by the following screenshots. Yet it’ll turn out that’s not the whole story…

First the minimum pulse width of 3.4ns with 1ns transition times viewed on a fast scope at a timebase of 5ns/div. The reference traces are just there to demonstrate what this pulse looks like with 200MHz (blue) and 20MHz (orange) 1st order bandwidth limit. This further demonstrates that we really need a fast scope in order to properly characterize a beast like the SDG6052X:


Pulse_BWL_SDG6052X_1.5V_3.4ns_1ns


The same scenario at a faster timebase of 1ns/div just for closer inspection. We can see that the rise- and fall times of the SDG6052X are still pretty accurate despite the continuously changing waveform, aka “undulation”:


Pulse_BWL_SDG6052X_1.5V_3.4ns_1ns_Z


As we already know, this effect nearly ceases when reverting to the default 2ns transition times:


Pulse_BWL_SDG6052X_1.5V_3.4ns_2ns


The same “undulation” effect can be observed with wider pulses, like 10ns in the following example:


Pulse_BWL_SDG6052X_1.5V_10ns_1ns


And again, the pulse gets pretty clean with 2ns transition times:


Pulse_BWL_SDG6052X_1.5V_10ns_2ns


So far so good (or not), this has been nothing new. But when I needed a narrow pulse with fast transitions again the next day, things looked completely different. As can be seen, all of a sudden the shape of the pulse is now absolutely stable and as expected, average transition times got even faster with less standard deviation:


Pulse_SDG6052X_1.5V_A10dB_3.3ns_1ns


The same is true for the wider 10ns pulse:


Pulse_SDG6052X_1.5V_A10dB_10ns_1ns


Finally a cursor measurement in order to confirm the automatic rise time measurement of 970ps:


Pulse_SDG6052X_RT_1.5V_A10dB_10ns_1ns


So it looks like the SDG6000X behaves differently (depending on its mood) every other day and I suspect some incomplete initialization, which Siglent should be able to fix eventually. At least my test indicates that the issue should be easily fixable.


Btw, I also looked at the Sync to Output jitter and was unable to reproduce it at 1MHz. Yet the ~3.3ns jitter is certainly there at most other frequencies.

[MrW0lf]

a fast scope

[Performa01]

a fast scope

Indeed

After all, there are signals much faster than what an SDG6052X can do (and these could use an even faster scope), so your scope can never be too fast


Demo_Square_160MHz_10mV

[JohnG]

so your scope can never be too fast

Agreed

[egonotto]

Hello,

is this a new Siglent scope?

Best regards
egonotto

[tautech]

Hello,

is this a new Siglent scope?

Best regards
egonotto

https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/

[tv84]

I thought it was a homebrew model...

[2N3055]

It seems like a 1GHz model....

[rf-loop]

a fast scope

Indeed

After all, there are signals much faster than what an SDG6052X can do (and these could use an even faster scope), so your scope can never be too fast


Demo_Square_160MHz_10mV

Risetime  and layout looks like scope is Ding Yang SDS5104X  (1GHz) or better.

[KaneTW]

The UI reminds me a bit of my R&S RTB2004.

[TurboTom]

Meanwhile more than a month has passed since Siglent's first reaction to my "rants" and the bug reports (and the beta firmware that introduced new bugs so I'm back on the stock version), and since then, it's been rather silent except a short PM round about three weeks ago that their engineers are working on the waveform quality issue (probably the overshoot/undulation problem vs. the option to have a 2ns rise time in all operational modes which should put the instrument overshoot-wise within its specs). Actually, I already regret not to have drawn the option to return the instrument after I thorougly tested it. My current situation is like this: When I'm doing some quick tests (calibration of my turbine engine control units or the like), I use a different generator of which I know that the output signal is reliable.

Just now that I wanted to give the SDG6000X another chance to prove itself useful, I found another bug in the standard firmware that I quickly report here: Phase setting independent, select any built-in arbitrary waveform -- I tested with several --, for simplicity reasons, just use "StairUp". I checked at 2kHz but I think the frequency is not really important. Then toggle the "ArbMode" from DDS to TrueArb (I selected 65.536MSa/s to have the same frequency) and back to DDS -- see how the slopes look funny. Toggling On/Off any of the Mod / Sweep / Burst functions will restore the waveform. In phase locked mode, this doesn't happen.

It's really a shame that instruments of apparetly decent hardware design get crippled by unfinished software. Of course I'm aware that probably 80 to 90% of the complexity and work of an instrument like this lies in software design. Anyway, regardless of the complexity situation, I think a customer can expect to receive an instrument (that's clearly designed towards at least the semi-professional user) that has been thoroughly tested at the manufacturer's QC / engineering department. And then, bugs like these shouldn't have slipped through.

Whatsoever, I really hope for a substantial bug fix / firmware update in due time.

Cheers,
Thomas

[emax]

It took me a lot of picoseconds to (basically) understand all of your screenshots and explanations.

You guys are really awesome! 

[2N3055]

Any news on new firmware...??
I bought one in meantime for a project I'm working on..

I also confirmed all bugs here mentioned, and found some new ones, connected to output filtering issue.
I found that sometimes changing frequency on CH2 upsets filtering on CH1 so pulses start ringing. Disable and enable CH1 makes it OK again.
Also, once I had problem that I loaded two different AW into two channels, did what I was doing, and when switching back to pulses it also started ringing.
I had to reboot this time to make it ok.

Apart from that (I hope it will be solved soon), powerful little beast.
Amplitude flatness seems excellent, nicely implemented PRBS with preset logic levels and differential driving..
Channel mixing is also very nice feature.

I also have a feature suggestion (request ?): would it be possible to add a waveform sequence mode like Keysight 33500B/33600A (Waveform sequencing) or Rigol DG800/900 (Sequence function)?
That would be enormous usability and capability enhancement.

Regards,

Sinisa

[janekivi]

Some of their generators got today new firmware... but this doesn't mean anything.
May be adds a little bit hope.
SDG1000 Firmware UpdateCurrent Version: V1.01.01.39R7 | Published：2019-01-29
SDG1000X Firmware UpdateCurrent Version: V1.01.01.30R1B2 | Published：2019-01-28

[jjoonathan]

I'm having trouble with the memdump technique. I can get a root console and have had good luck with the "move a file" technique, but that only unlocks bandwidth, not IQ. Here's what I have tried:

* Grabbing /dev/mem and running FindKeys on it. It returns many hits. I haven't been able to get TryKeys to work though. These tools look slightly oscilloscope specific?

* Writing a quick program to grab and scan awg.app's memory directly (ptrace, /proc/pid/{mem,maps}). I look for 16-char capital alphanumerics with at most 6 repeats of any single character. I can see two copies of my 200MHz Bandwidth key if it's installed, but if I remove the key from the xml file without touching the serial number, I can't find it in memory anymore. I don't see any other keys. One candidate, but it doesn't work and it doesn't have similar surroundings to the known real key, so I'm pretty sure it's a false positive.

I suspect I am missing a simple trick. Do you have to do something to provoke the other keys to appear in memory?

In any case, I have attached the tool I made. Here's the output. Dots are key candidates. Only one looks sane and it doesn't work. The known good key does not appear unless it is installed.

Code: [Select]

/usr/bin/siglent/usr/mass_storage/U-disk0 # ps -e | grep awg
  667 root       0:13 /usr/bin/siglent/awg.app
  839 root       0:00 grep awg
/usr/bin/siglent/usr/mass_storage/U-disk0 # ./memdump 667 mem2.bin > mem2.txt
SKIP 00008000-005d3000 r-xp 00000000 00:0f 612        /usr/bin/siglent/awg.app
SCAN 005da000-0094c000 rw-p 005ca000 00:0f 612        /usr/bin/siglent/awg.app
SCAN 0094c000-01b21000 rw-p 00000000 00:00 0          [heap]
...
SCAN 28600000-28680000 rw-p 00000000 00:00 0
SCAN 28680000-28700000 rw-s 00000000 00:06 1108       /dev/fb0
SKIP 28700000-28701000 ---p 00000000 00:00 0
SCAN 28701000-28f00000 rw-p 00000000 00:00 0          [stack:746]
SCAN 28f00000-28f80000 rw-s 0ad80000 00:06 15         /dev/mem
SCAN 28f80000-29000000 rw-s 0ad00000 00:06 15         /dev/mem
SCAN 29000000-2b800000 rw-s 0d800000 00:06 15         /dev/mem
SCAN 2b800000-2b880000 rw-s 0ac80000 00:06 15         /dev/mem
SCAN 2b880000-2b900000 rw-s 0ac00000 00:06 15         /dev/mem
SCAN 2b900000-2e100000 rw-s 0b000000 00:06 15         /dev/mem
SKIP 2e100000-2e101000 ---p 00000000 00:00 0
SCAN 2e101000-2e900000 rw-p 00000000 00:00 0          [stack:728]
SKIP 2e900000-2e901000 ---p 00000000 00:00 0
SCAN 2e901000-2f100000 rw-p 00000000 00:00 0          [stack:703]
SKIP 2f100000-2f101000 ---p 00000000 00:00 0
SCAN 2f101000-2f900000 rw-p 00000000 00:00 0          [stack:702]
SKIP 2f900000-2f901000 ---p 00000000 00:00 0
SCAN 2f901000-30100000 rw-p 00000000 00:00 0          [stack:701]
SKIP 30100000-30101000 ---p 00000000 00:00 0
SCAN 30101000-30900000 rw-p 00000000 00:00 0          [stack:700]
SKIP 30900000-30901000 ---p 00000000 00:00 0
SCAN 30901000-31100000 rw-p 00000000 00:00 0          [stack:699]
SKIP 31100000-31101000 ---p 00000000 00:00 0
SCAN 31101000-31900000 rw-p 00000000 00:00 0          [stack:692]
SKIP 31900000-31901000 ---p 00000000 00:00 0
SCAN 31901000-32100000 rw-p 00000000 00:00 0          [stack:691]
SKIP 32100000-32101000 ---p 00000000 00:00 0
SCAN 32101000-32900000 rw-p 00000000 00:00 0          [stack:689]
SKIP 32900000-32901000 ---p 00000000 00:00 0
SCAN 32901000-33100000 rw-p 00000000 00:00 0          [stack:688]
SKIP 33100000-33101000 ---p 00000000 00:00 0
SCAN 33101000-33900000 rw-p 00000000 00:00 0          [stack:687]
SKIP 33900000-33901000 ---p 00000000 00:00 0
SCAN 33901000-34100000 rw-p 00000000 00:00 0          [stack:686]
SKIP 34100000-34101000 ---p 00000000 00:00 0
SCAN 34101000-34900000 rw-p 00000000 00:00 0
SCAN 34900000-34955000 rw-p 00000000 00:00 0
SKIP 34955000-34a00000 ---p 00000000 00:00 0
SCAN 34a40000-34a50000 rw-s 0af00000 00:06 15         /dev/mem
SCAN 34a50000-34a60000 rw-s 0ae00000 00:06 15         /dev/mem
SCAN 34a60000-34a70000 rw-s 40400000 00:06 15         /dev/mem
SCAN 34a70000-34a80000 rw-s 40410000 00:06 15         /dev/mem
SCAN 34a80000-34a90000 rw-s 40600000 00:06 15         /dev/mem
SCAN 34a90000-34aa0000 rw-s 40400000 00:06 15         /dev/mem
SCAN 34aa0000-34ab0000 rw-s 40410000 00:06 15         /dev/mem
SCAN 34ab0000-34ac0000 rw-s 40600000 00:06 15         /dev/mem
SCAN 34ac0000-34ad0000 rw-s 40400000 00:06 15         /dev/mem
SCAN 34ad0000-34ae0000 rw-s 40410000 00:06 15         /dev/mem
SCAN 34ae0000-34af0000 rw-s 40600000 00:06 15         /dev/mem
SKIP 34af0000-34af1000 ---p 00000000 00:00 0
SCAN 34af1000-352f0000 rw-p 00000000 00:00 0          [stack:684]
SKIP 352f0000-352f1000 ---p 00000000 00:00 0
SCAN 352f1000-35af0000 rw-p 00000000 00:00 0          [stack:683]
SKIP 35af0000-35af1000 ---p 00000000 00:00 0
SCAN 35af1000-362f0000 rw-p 00000000 00:00 0          [stack:679]
SKIP 362f0000-362f1000 ---p 00000000 00:00 0
SCAN 362f1000-36af0000 rw-p 00000000 00:00 0          [stack:678]
SKIP 36af0000-36af4000 r-xp 00000000 1f:05 1489472    /lib/libdl-2.11.1.so
SKIP 36af4000-36afb000 ---p 00004000 1f:05 1489472    /lib/libdl-2.11.1.so
SKIP 36afb000-36afc000 r--p 00003000 1f:05 1489472    /lib/libdl-2.11.1.so
SKIP 36afc000-36afd000 rw-p 00004000 1f:05 1489472    /lib/libdl-2.11.1.so
SKIP 36afd000-36c39000 r-xp 00000000 1f:05 739944     /lib/libc-2.13.so
SKIP 36c39000-36c41000 ---p 0013c000 1f:05 739944     /lib/libc-2.13.so
SKIP 36c41000-36c43000 r--p 0013c000 1f:05 739944     /lib/libc-2.13.so
SKIP 36c43000-36c44000 rw-p 0013e000 1f:05 739944     /lib/libc-2.13.so
SCAN 36c44000-36c47000 rw-p 00000000 00:00 0
SKIP 36c47000-36c66000 r-xp 00000000 1f:05 1498276    /lib/libgcc_s.so.1
SKIP 36c66000-36c6d000 ---p 0001f000 1f:05 1498276    /lib/libgcc_s.so.1
SKIP 36c6d000-36c6e000 rw-p 0001e000 1f:05 1498276    /lib/libgcc_s.so.1
SKIP 36c6e000-36cdc000 r-xp 00000000 1f:05 1547208    /lib/libm-2.11.1.so
SKIP 36cdc000-36ce3000 ---p 0006e000 1f:05 1547208    /lib/libm-2.11.1.so
SKIP 36ce3000-36ce4000 r--p 0006d000 1f:05 1547208    /lib/libm-2.11.1.so
SKIP 36ce4000-36ce5000 rw-p 0006e000 1f:05 1547208    /lib/libm-2.11.1.so
SKIP 36ce5000-36da9000 r-xp 00000000 1f:05 9371652    /usr/lib/libstdc++.so.6
SKIP 36da9000-36db0000 ---p 000c4000 1f:05 9371652    /usr/lib/libstdc++.so.6
SKIP 36db0000-36db4000 r--p 000c3000 1f:05 9371652    /usr/lib/libstdc++.so.6
SKIP 36db4000-36db6000 rw-p 000c7000 1f:05 9371652    /usr/lib/libstdc++.so.6
SCAN 36db6000-36dbc000 rw-p 00000000 00:00 0
...
SKIP 36dbc000-36edc000 r-xp 00000000 1f:05 1981724    /lib/libxml2.so.2.7.8
SKIP 36edc000-36ee3000 ---p 00120000 1f:05 1981724    /lib/libxml2.so.2.7.8
SKIP 36ee3000-36ee9000 rw-p 0011f000 1f:05 1981724    /lib/libxml2.so.2.7.8
SKIP 36ee9000-36f04000 r-xp 00000000 1f:05 7050472    /usr/lib/libglog.so.0
SKIP 36f04000-36f0b000 ---p 0001b000 1f:05 7050472    /usr/lib/libglog.so.0
SKIP 36f0b000-36f0c000 rw-p 0001a000 1f:05 7050472    /usr/lib/libglog.so.0
SCAN 36f0c000-36f1c000 rw-p 00000000 00:00 0
SKIP 36f1c000-36f36000 r-xp 00000000 1f:05 3682060    /lib/libz.so.1.2.8
SKIP 36f36000-36f3e000 ---p 0001a000 1f:05 3682060    /lib/libz.so.1.2.8
SKIP 36f3e000-36f3f000 rw-p 0001a000 1f:05 3682060    /lib/libz.so.1.2.8
SKIP 36f3f000-36f46000 r-xp 00000000 1f:05 1967524    /lib/librt-2.11.1.so
SKIP 36f46000-36f4d000 ---p 00007000 1f:05 1967524    /lib/librt-2.11.1.so
SKIP 36f4d000-36f4e000 r--p 00006000 1f:05 1967524    /lib/librt-2.11.1.so
SKIP 36f4e000-36f4f000 rw-p 00007000 1f:05 1967524    /lib/librt-2.11.1.so
SKIP 36f4f000-36f64000 r-xp 00000000 1f:05 1925640    /lib/libpthread-2.13.so
SKIP 36f64000-36f6b000 ---p 00015000 1f:05 1925640    /lib/libpthread-2.13.so
SKIP 36f6b000-36f6c000 r--p 00014000 1f:05 1925640    /lib/libpthread-2.13.so
SKIP 36f6c000-36f6d000 rw-p 00015000 1f:05 1925640    /lib/libpthread-2.13.so
SCAN 36f6d000-36f6f000 rw-p 00000000 00:00 0
SKIP 36f6f000-36f8f000 r-xp 00000000 1f:05 655204     /lib/ld-2.13.so
SCAN 36f90000-36f91000 rw-s f8001000 00:06 15         /dev/mem
SCAN 36f91000-36f96000 rw-p 00000000 00:00 0
SKIP 36f96000-36f97000 r--p 0001f000 1f:05 655204     /lib/ld-2.13.so
SKIP 36f97000-36f98000 rw-p 00020000 1f:05 655204     /lib/ld-2.13.so
SCAN 3e9fe000-3ea1f000 rw-p 00000000 00:00 0          [stack]
SKIP 3eff7000-3eff8000 r-xp 00000000 00:00 0          [sigpage]
SKIP ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]


[gorillamotors]

I think that actually helps a lot... thank you tv84!

I got the 6022X to 500MHz but how do I upgrade the IQ license?

[2N3055]

2 months passed...
Is there ANY news on new firmware for SDG6000X

Anybody ?

Thanks.

[TurboTom]

Actually more than five (!) month since my last correspondence with Siglent regarding the bugs and possible improvements. Either they are very busy with other equipment and the SDG6000X series is running under low priority or the problems are possibly more severe than anticipated and maybe require a hardware tweak (anti-aliasing-filter?) to get solved properly.

I hope the problems get finally taken care of. Shortly! 

[2N3055]

I think they are working, SDG1000x just got upgrade, they gave it Truearb tech and preview of ARB waveforms when selecting...

It seems they are dedicated to do it right, it's just takes a lot of time..