Siglent SDG6000X series 200-500 MHz AWG's

[KungFuJosh]

The touchscreen on my SDG6000X decided to stop working. WTF, Batman?

Still not working ?

Nope. It's been at least a week since I noticed it. I tried downgrading and upgrading firmware with no change.

Trying to calibrate the touchscreen gets not response either.

Thanks,
Josh

[Grandchuck]

48 bytes removed ...

[Grandchuck]

The 48 bytes

[KungFuJosh]

48 bytes removed ...

What was the point though? Your trigger position is different, as is your timebase, but they look the same otherwise.

[tautech]

I’m struggling with a synchronization issue on my equipment (Signal Generator + Oscilloscope) that makes the Sync Output practically useless for precision work.
Firmware version: "6.01.01.38R3"
Hardware version: "03-00-00-81-41"
 
I am feeding a 20ns pulse and the Sync Output from the generator into an oscilloscope. I am monitoring the time interval between the sync edge and the pulse edge using a trend plot. I see a constant linear phase drift. The offset "ramps" from -550ps to 3ns. While this technically stays within the manufacturer's jitter specification (3.5ns), it is clearly not random jitter but a deterministic drift.
(Attachment Link)

The speed of this drift is highly dependent on the output frequency:
At 10 MHz: the timing is perfectly stable.
At 2.5 MHz: the drift is very slow; a full cycle (~3.5ns) takes approximately 12 hours.
At 250 kHz: the drift period from minimum to maximum is about 45 minutes (one division on my trend's X-axis is 10 min).At non-multiple frequencies: the drift accelerates significantly.
At 20 kHz, a full cycle takes 3 minutes; at 1 kHz, the phase "rolls over" every 20 seconds.

It seems like the Sync signal and the Main Output are derived from different clock domains or there is an accumulated rounding error in the NCO/Phase Accumulator that isn't being reset. For non-integer ratios, the error builds up rapidly, causing the phase to "crawl" relative to the trigger.Has anyone else encountered this? Is this a known firmware bug that might be fixed, or is it a fundamental architecture flaw in the FPGA/DDS implementation? In its current state, the Sync Output is completely unreliable for any time-domain measurements

How are you frequency referencing both instruments ?
When phasing is critical you will need to provide both with a 10 MHz reference and possibly use a channel deskew to null cable propagation delays.

[KungFuJosh]

Are you using high-quality, phase-matched cables of equal length?

[KungFuJosh]

Did you read the manual? See attached.

[KungFuJosh]

Did you read the manual? See attached.

Looking at that manual, how does it explain the behavior on my F1 trend plot?

Sorry, I guess I skimmed what you wrote too quickly. I thought you said it worked up to 10MHz. tl;dr and all that.

I'd suggest looking through the manual and checking your settings to make sure you have the correct sync source, and that it's active.

[tautech]

@user
Would love to look deeper at the drift you’re seeing but away from instruments for a few days yet.
Wondering if it’s your AWG or your scope….. 

[KungFuJosh]

The touchscreen on my SDG6000X decided to stop working. WTF, Batman?

Still not working ?

I popped it open and wiggled the wires. It's working again.  Thanks for the tip.

I might replace the fan. Here's the specs of the stock fan:
BOYD (formerly AAVID)
PAAD16025SL
0.15A 12VDC
60x60x25.4mm
Airflow: 17.12 CFM
Static Pressure: 0.16 inH₂O / 3.99 mmH₂O
Noise Level: 29 dBA
Connector: 2-Pin

ETA: Probably gonna go with Sunon again.
MF60251V1-1000U-A99
75mA 12VDC
60x60x25mm
Airflow: 23.5CFM
Static Pressure: 0.21 inH₂O / 5.33 mmH₂O
Noise Level: 27 dBA
Connector: 2-Pin

Thanks,
Josh

[KungFuJosh]

@user
Would love to look deeper at the drift you’re seeing but away from instruments for a few days yet.
Wondering if it’s your AWG or your scope….. 

I could possibly test the SDG with my 53132A. 🤔

[tautech]

@user
Would love to look deeper at the drift you’re seeing but away from instruments for a few days yet.
Wondering if it’s your AWG or your scope….. 

I could possibly test the SDG with my 53132A. 🤔

IMO tests should be with and without an external reference…..for both instruments.
Then there should be zero drift but some jitter might still be present…..but these instruments will have a jitter spec to refer to.

[KungFuJosh]

@user
Would love to look deeper at the drift you’re seeing but away from instruments for a few days yet.
Wondering if it’s your AWG or your scope….. 

I could possibly test the SDG with my 53132A. 🤔

IMO tests should be with and without an external reference…..for both instruments.
Then there should be zero drift but some jitter might still be present…..but these instruments will have a jitter spec to refer to.

Sure. But even my reference has jitter. In any case, the 53132A can test phase, so that might tell us something. It's almost 2am here though, so we'll see if I remember this tomorrow lol.

[Tjuurko]

What was the point though? Your trigger position is different, as is your timebase, but they look the same otherwise.

The first 48 bytes are service (file name and something else) and for Siglent SDGxxxx they look like “garbage”.

[2N3055]

I will look into this in days to come, when I have time.

I never had problems with this because I usually just use 2 channels locked, for same purpose, in which case jitter is random, at 1kHz has P-P of some 60ps, and RMS of 9ps.

[gf]

The manufacturer specifies this 3.5ns value in the datasheet as 'Jitter,' but my analysis proves this is a complete misnomer.Look at the facts:True Jitter: At 10 MHz, where the phase drift is zero, the actual random jitter is in the tens of picoseconds range. This is the real performance floor of the hardware.Deterministic Deviation: The 3.3ns - 3.5ns figure mentioned in the datasheet is not jitter at all. It is a constant linear phase deviation with a period that depends entirely on the output frequency.By labeling a systematic, frequency-dependent phase crawl as 'jitter,' the manufacturer is obfuscating a fundamental flaw in their clock synthesis architecture. In any other frequency than 10 MHz, the 'Sync Out' isn't experiencing random noise; it is suffering from a rolling phase error.Calling this 'jitter' is like calling a leaking roof 'high humidity' — it’s technically a misuse of the term to hide a structural defect

Assuming the sync signal is a digital output, its timing is likely quantized to the FPGA clock. Conversely, the edges of the generated bandwidth-limited analog signal are not restricted to these clock intervals and can occur at arbitrary points in time.

I do not want to start the philosophical debate over whether such timing uncertainty should be formally classified as 'jitter' or not.

[TurboTom]

What you see here is just the "normal" trigger jitter, a result of the (what Siglent calls it) "TrueArb & EasyPulse Technology". The trigger output signal is directly generated by the digital logic while the output signal is interpolated by modifying the amplitude of the samples adjacent to the slope. The (analog) signal reconstruction filter then produces the slope to be observed on the scope. Since the amplitude "adaptation" is arranged to match the programmed timing as accurately as possible, the slope position of the analog output signal may get to be situated at incremental positions between the possible trigger timing positions. If you trigger your scope on the signal, the trigger of the AWG appear to "walk trough" between the extremes defined by the "real" sampling frequency.

I attached a scope screenshot of my SDG6000X output, configured as you described but with pulse repetition frequency of 7kHz. The scope is set to a persitance of 500ms. CH1 is signal, CH2 trigger output. You can easily the trigger "smeared" over a jitter width of ~2.9ns at these settings.

I guess that's simply the price you've got to pay for digital signal generation at a budget...

Cheers,
Thomas

P.S. Added an old photo of the same problem, measured with my hp 53310A MDA. So this issue was already known round about eight years ago. It's pretty certain that it's hardware-related and cannot be eliminated via a firmware update.

[RoGeorge]

I’m struggling with a synchronization issue on my equipment (Signal Generator + Oscilloscope) that makes the Sync Output practically useless for precision work.
Firmware version: "6.01.01.38R3"
Hardware version: "03-00-00-81-41"
 
I am feeding a 20ns pulse and the Sync Output from the generator into an oscilloscope. I am monitoring the time interval between the sync edge and the pulse edge using a trend plot. I see a constant linear phase drift. The offset "ramps" from -550ps to 3ns. While this technically stays within the manufacturer's jitter specification (3.5ns), it is clearly not random jitter but a deterministic drift.
(Attachment Link)

The speed of this drift is highly dependent on the output frequency:
At 10 MHz: the timing is perfectly stable.
At 2.5 MHz: the drift is very slow; a full cycle (~3.5ns) takes approximately 12 hours.
At 250 kHz: the drift period from minimum to maximum is about 45 minutes (one division on my trend's X-axis is 10 min).At non-multiple frequencies: the drift accelerates significantly.
At 20 kHz, a full cycle takes 3 minutes; at 1 kHz, the phase "rolls over" every 20 seconds.

It seems like the Sync signal and the Main Output are derived from different clock domains or there is an accumulated rounding error in the NCO/Phase Accumulator that isn't being reset. For non-integer ratios, the error builds up rapidly, causing the phase to "crawl" relative to the trigger.Has anyone else encountered this? Is this a known firmware bug that might be fixed, or is it a fundamental architecture flaw in the FPGA/DDS implementation? In its current state, the Sync Output is completely unreliable for any time-domain measurements

That kind of behavior is not unexpected from an AWG.

To keep things even weirder, my Rigol DG4000 AWG sync output is a BNC with TTL output, which means that it will never output more than 20-25MHz (don't recall the exact frequency), even if it should.  It's a quirk mentioned somewhere in the Rigol AWG's manual, but I didn't notice it.

Took me half a day of "debugging" my DUT, until I realized the TTL sync out of the AWG doesn't really follow the channel output signal, but it is limited to the max frequency supported by a normal TTL gate.  There was nothing wrong with my DUT design, it was the weird AWG sync out suddenly halving when going above 25MHz, and thus making the DUT to fail the tests! 

I don't know the exact algorithm they are using for capping the sync out at 25MHz while still keeping it synchronous with the channel output.  My guess is, that is why you see different "jitter" at different frequencies, and at certain F values there is no jitter:  because of this Fmax capping algorithm (for the sync output only).


As a workaround, if your AWG has 2 channels, you may try putting the 2 channels in sync, and using the channel 2 out (Ch2 out, not Sync2 out) as a sync output, in the hope that that will get rid of the "jitter" or rolling phase errors, however you want to call them.


Another known quirk for AWGs (no matter the model), is that they synthesize the signal period digitally, which means the half period edge might "dance" around the expected edge location, because AWGs are using an internal table and a rolling phase as NCO.  When the ratio between internal clock and the requested frequency is not an integer, it will be some "jitter"

Even weirder is the situation when you use your own table, where for example you replace a sin function with some sequence of 0 and 1's, and try to change the frequency of that sequence.  Because of the rolling phase between the table and the FPGA clock, you may get a very different train of 0's and 1's than the one that you put in your signal waveform table. 

AWG are not like the analog signal generators, where all the oscillations have precisely the same duration, and the jitter is random.  That is why, it is not unusual to need in the lab both an AWG and an RF Generator.

[Grandchuck]

48 bytes removed ...

What was the point though? Your trigger position is different, as is your timebase, but they look the same otherwise.

To get rid of these:

[2N3055]

What you see here is just the "normal" trigger jitter, a result of the (what Siglent calls it) "TrueArb & EasyPulse Technology". The trigger output signal is directly generated by the digital logic while the output signal is interpolated by modifying the amplitude of the samples adjacent to the slope. The (analog) signal reconstruction filter then produces the slope to be observed on the scope. Since the amplitude "adaptation" is arranged to match the programmed timing as accurately as possible, the slope position of the analog output signal may get to be situated at incremental positions between the possible trigger timing positions. If you trigger your scope on the signal, the trigger of the AWG appear to "walk trough" between the extremes defined by the "real" sampling frequency.

If that is indeed the case, it is an extremely questionable design choice. What is the practical purpose of a Sync Output in such a generator? Even an ancient HP 33120A provides a proper Sync output that can actually be used for synchronization, rather than for observing this "sawtooth dance" disguised as jitter. Even the toy-like GK101 manages to output a phase-locked sync signal. It is perfectly logical that the analog slope is interpolated to achieve sub-sample precision beyond the discrete sampling grid, while the Sync Out remains locked to the discrete FPGA clock cycles. However, it is equally logical - and standard industry practice - to perform a phase reset or alignment with every cycle. This is how almost everyone else implements it. There is a fundamental difference between "smearing" (random jitter) and "walking" (deterministic drift).
 In your screenshot with 500ms persistence, you see "smearing", which looks like jitter at a glance. But if you were to plot the trend for that measurement, you would find that the pulse is not jumping randomly; it is shifting linearly.By providing a 'Sync' output that constantly drifts relative to the signal, the manufacturer renders it useless for any precision time-domain work, such as averaging or high-resolution capture. You simply cannot average out a deterministic ramp. This implementation effectively turns a 'Sync' port into just another independent oscillator that happens to run at a similar frequency

I attached a scope screenshot of my SDG6000X output, configured as you described but with pulse repetition frequency of 7kHz. The scope is set to a persitance of 500ms. CH1 is signal, CH2 trigger output. You can easily the trigger "smeared" over a jitter width of ~2.9ns at these settings.

Set your frequency to 5 kHz, and you will observe the signal edge cyclically drifting by 3 ns every 100 seconds. It is very difficult to classify a perfectly periodic, 100-second cycle as "jitter".

What is a practical significance of 3ns jitter on 5kHz signal? What do you do that needs that? That is 15 ppm of timing error on the signal?
Like I said, if you need tight timing, just use two channels, one as synch other as signal. They will be synched together into ps range.

[2N3055]

What is a practical significance of 3ns jitter on 5kHz signal? What do you do that needs that? That is 15 ppm of timing error on the signal?
Like I said, if you need tight timing, just use two channels, one as synch other as signal. They will be synched together into ps range.

I mentioned the 5 kHz test purely as a way to verify the drift. In my actual application, I need to work with millivolt-level signals and precisely monitor the timing between two edges. When dealing with such weak, noisy signals, the oscilloscope trigger cannot reliably lock onto the waveform itself. This is exactly why a sync output exists - to provide a clean, high-amplitude reference for stable triggering. However, because of this "phase dance", the sync out is useless for this task.

I don't understand the persistent reluctance to admit that this is a Rigol-level flaw. I was unaware of this "feature" until I actually needed it for a real-world task. I’ve been using this Siglent as my primary generator for over a year because it’s so user-friendly (I only turn on the Tektronix when I need speeds above 500 MHz and can sacrifice convenience). But this phase drift is a childish oversight that you seem to be ignoring by offering "workarounds". I eventually had to solve it by using an attenuator on a main channel and taking the sync from a splitter before the attenuation. This is the typical Siglent experience: you get a great instrument for a fair price, but then some "small" issue like this crawls out. Seriously, what is the fundamental purpose of a sync output like this? If it can’t provide a stable phase reference for low-level signal analysis or averaging, it’s just a marketing checkbox, not a functional tool. Why defend a broken implementation when even basic legacy gear gets it right?

Now you are just ignoring what I said. I said you can use SECONDARY channel as a trigger. But you seem to insist of doing something in a particular just to prove you are right.

I also DID NOT say there is no such behavior. I DID say I will personally investigate this when I have time. I am curious too.
I presume it is some consequence of rounding errors on the very principle how fractional NCO works, and what we see are corrections.

I have no idea "what is the fundamental purpose of a sync output like this".
I did point out this is 15 ppm level of timing error on signal you used as an example. Many times it is of no significance. You didn't explain why exactly is that a problem.
I gave you working alternative that you can use for that particular measurement.

[KungFuJosh]

To get rid of these:

Ha, I trigger on those. That's the point to get a consistent trigger. If you want to center the heart, you can offset simply that way too.

[TurboTom]

Btw, this seems to be an "old" problem: https://www.eevblog.com/forum/testgear/siglent-sdg6000-series-awg_s/msg4556488/#msg4556488 

[gf]

If we extrapolate this issue to the world of oscillography, it is equivalent to having an external trigger input on a scope that doesn't just have some random jitter, but instead "walks" back and forth by several nanoseconds, with the drift speed depending on your memory depth or timebase settings. Imagine if you complained about such a broken trigger, and someone told you: "That's normal, just use your second analog channel for triggering instead". No one in their right mind would accept that as "normal" for an oscilloscope.

What you consider 'not normal' has become standard for external triggers of many DSOs as well. Modern systems omit a TDC to cut costs and just feed the signal through a comparator into a digital input. As a result, the external trigger path suffers from inherently higher trigger jitter (due to time quantization), while precise triggering is restricted to the analog channels (provided the analog path is properly bandwidth-limited, enabling interpolatiton).

[Detlev]

I used a frequency counter to measure the phase between the CH1 output and the trigger output of the SDG6000X. The measurement ran for 13 hours.

The setup is as follows:

SDG6000X
FCA3000
Huber & Suhner ST18/SMAm/SMAm/36 cables (identical batch number)
Huber & Suhner SMA-to-BNC adapters
External reference: Leo Bodnar GPSDO
F = 1 MHz
Waveform: 50% square wave
Level: 0 dBm

The phase between the output and the trigger signal drifts slowly until it is "captured," after which it drifts again.
This behavior is reproducible and independent of the time reference (internal or external).

The phase is negative; the trigger output leads the signal output.

The drift values ​​are:

P-P: 1.38 degrees
Adev: 0.015 degrees
Std: 0.378 degrees
Min: 0.52 degrees
Max: 1.89 degrees

The x-axis in the image represents 50.000 seconds.

I find this behavior very interesting, but I cannot explain how it arises.

A comparative measurement between the two outputs, CH1 and CH2, shows a completely constant and phase-synchronous relationship (difference of 0.011 degrees).