Hantek2d42 bugs report

gf1

Finally I had time to test the proposed modification. I've changed R61 to 1.5K as indicated, installed the last FW (20190312001) and run the calibration. I noticed some improvement but I still get glitchs in the waveforms

I had not yet change R61, because I didn't have a suitable 1k5 resistor at hand, so I only installed the firmware. Since the resistor change did not help for your device, I'll reneounce it.

Unfortunately I accidentally hit the Calibrate (F3) button (while I actually wanted to adjust the offset with F2 instead), and the AWG did re-calibrate (without asking for a confirmation), so my calibration  is now ~2...3% off

@Amy:

In fact I still do not understand, why the proposed solution (increase the full-scale DAC current, thereby likely even exceeding the DAC's maximum value) were supposed to eliminate the glitches. My understanding is that it would only shift the glitches to a different vertical positions in the generated waveform.

You did not tell whether your engineer has already identified the root cause, or not.

My observation is that all occuring glitches are eventually located at particular absolute output voltage levels, which are integral mutiples of ~87mV on my device, and IMO these levels correspond to digital counts which are integral multiples of 64.

It is well known, and we have to live with the fact, that some DAC architectures do suffer from glitches, and assuming a segmented architecture with 32 segments (which is IMO likely for this kind of DAC models), the major-carry glitches are indeed supposed to happen at integral multiples of 1/64 of full scale (which is 4096/64=64 for a 12-bit DAC). This would fit with the observed picture. The size of the observed glitches does however not fit. The typical specified glitch energy for DA convertes like DAC902 or similar is as low as 3...5 pVs. But what I see at the AWG output is rather a glitch area of about 50mv * 20ns = 1000 pVs. Directly at the DAC outputs (before the amp) this still corresponds to ~170 pVs, so the spikes we see are IMO magnitutes larger than explainable by typical DAC glitches. So either your secret Chinese DAC model is of very low quality (compared to e.g. DAC902), or maybe you are overclocking them too much, or the root cause is not the DAC chip, but is still a different one.

Another potential reason coming into my mind are timing errors on the DAC's data inputs, with regard to the clock, and/or signal integrity errors (rise time, ringing,...) of these signals. The required setup und hold times of e.g. DAC902 are specified with 1ns and 1.5ns, so given 250MSPS (4ns period), there is only a time window of 1.5ns left where the data are allowed to change. If your secret Chinese DAC model has even larger setup/hold times, then it becomes even more challenging for the FPGA to output signals with the correct timing. I also don't see any damping resistors in the data lines from FPGA to DAC. I'm not sure if they are needed here, but on the other hand I see that you did install series resistors in the data lines from AD9288 to the FGPA (although they run at a slower clock). I can't verify/measure the timing, since this would require a MSO/LA with several GSPS, which I do not own, but likely your engineer can.

Yet another  reason might be logical errors in the digital counts sent to the DAC. IMO this would be even the best case, since it could be fixed with a firmware or FPGA upgrade.

gf1

gf1

Dear Amy,

well, these glitches/spikes relly stick in my head and don't let me sleep...
Since the observed glitches are magnitudes larger than regular DAC glitches, I also continued some investigations on the DAC input side.

If I generate a suqare wave signal, then the MSB of the digital count is supposed to be a square wave signal as well, because zero-crossings are only expected at the rising edge and the falling edge, right?

So I set the AWG to ~4MZH square wave, 2V amplitude, 0V offset, and measured the MSB signal on pin 1 of the DAC. This time I used a self-soldered Z0 probe with 50 Ohm termination at the scope, which gives faster rise times than the PP-80, and less capacitive load on the DUT.



The small spike (A) is a reflection caused by my measurement setup (horizontal position varies with cable length), it's neglectable for this consideration. The ringing (B) after the rising (or falling) edges is likely caused by the measurement setup as well, but it's amplitide sufficiently small either.

But the three peaks (C) which occur prior to the rising edge make me worried. I'm pretty confident that they are are not caused by the measurement setup, but that they are actually present in the signal from the FPGA to the DAC. Maybe they are even three full low-high-low transitions of the MSB (and my 6074BD is just too slow to display them with full amplitude). It is worth to note that they have a time-spacing of exactly 4ns (which is the DAC clock period - this can't be just by chance), while the ringing (B) has a lower, uncorrelated frequency. IMO these pulses are unexpected-- I'd rather expect to see a clean square wave on the MSB. Similar pulses are also present on other data lines, preceeding the rising edge. I also can't get rid of the feeling that they might be related to the AWG glitches (when happening on pin 6), but even if this is not the case I still find them strange. Maybe your engineer can measure with faster equipment, and also revisit the the FPGA logic and timing in this area.

Here's also a zoom-in:



Btw:

• Unfortunately, the cursor measurements (3.99ns in the above picture) don't show up in the screen image saved by the 6000 software.
• I'm positively surprised to see a rise time of almost 2ns (with my Z0 probe) on my 6074BD, although it is just the 70 MHz model.
• I don't find inexpensive Z0 probes on the market, though they are pretty simple. Might be a potential idea for a new Hantek product?
  

gf1

gf1

OASJ2YSeeEhBQo1 replied at 2019-3-16 13:21
Finally I had time to test the proposed modification. I've changed R61 to 1.5K as indicated, insta ...

In the first picture the AWG is off, in the second AWG is set to sine wave, 1MHz, 1V and turned on. There is nothing conected to the inputs.

That's really heavy!
I've never seen such a high amplitude on mine.

Does it make a difference in your case whether the AWG is open or driving a load?

Was USB connected to PC or power supply?

Does the noise amplitude (in div units on the display) change with V/div setting of CH2?
(particularly for <= 200 mv/div, which bypass the 50:1 attenuator directly at the input)

EDIT:

Unless the noise would happen to enter directly at the input, the ranges 500mv...10V/div are more or less equivilalent to 10mV...200mV/div - the only difference between them is the 50:1 input attenuator, which is either present or bypassed (relay-switched).

If the noise amplitude on the display is independent of V/div setting, then it is likely injected after the 2nd attenuator stage (otherwise it would be attenuted gradually as well, when switching from 10mv/div  step by step to 200mV/div).


gf1

gf1

amy replied at 2019-4-1 15:09
Hi, about the waveform burr, our engineer modify the FPGA.Please use this to update.

Thank you very much, Amy, and congratulations! I installed the FPGA code and it looks much better now There are still small glitches visible, but I think that's now a level we need to accept. I also compared to the AWG of my 6074BD, and I see almost no difference now.

gf1

gf1

I'd like to come back to this low-frequency scope noise issue when the AWG is driving a load.
When I increase the AWG frequency to about 5500 Hz, then I get this picture:



Again there is no signal connected to both scope inputs, but the scope inputs are 50 Ohm terminated (in order that the BNC connectors don't pick up EMI). The AWG is set to 5500 Hz square wave, 2.3V amplitude, and drives a 50 Ohm load. The peak-peak noise amplitude on both, CH1 and CH2 is almost 1 div , when the channels are set to either 10mv/div or 500mv/div.

Here's what I've analyzed so far:

• If the AWG is driving a load (particularly with square wave with fast risetime), is is of course unavoidable that it creates load transients on the power supply rails.
• The DC converter for the negative supply has obviously a rather small phase margin, so that its load transient response shows significant overshoot/ringing, with crossover frequency of about 5500 Hz. When the AWG is set to 500 Hz, the overshoot is about 40mV pp. With an AWG frequency of ~5500 Hz, we hit the resonance frequency of the DC conveter, and amplitude is even higher (-> above image).
• Besides the dynamic transient response, there is also a small residual ohmic voltage drop on the power supply rail which follows the AWG waveform. With the AWG set to 500 Hz, this component is only about 7mV pp  (but even this is sufficient to couple about 2mV pp into the scope frontend).
• The power supply rails of the AWG and the scope frontends are not sufficiently decoupled from each other.
• The FET buffer amplifier in the frontends has a very low PSRR with regard to V- at low frequencies (not more than ~10dB). The weak spot are the two current sinks which are biased by a resistive devider between the (noisy) V- and GND, copuling the noise into the constant current. There is a bypass capacitor, but it is much to small to help at low frequencies. There is also the DC compensation path for the FET buffer via the opamp, but it joins in at only even lower frequencices (< 20 Hz ?) and does not help at say 500 Hz.
  

So far I could achieve the best mitigation by adding an additional 100uF bypass from the bias point of the current sinks in the frontends to V-, and adding 1000uF low ESR from V- to GND near the AWG's output amp (where the load transients originate). Well, 1000uF is of course pretty large. Alternatively I tried to add a  feedforward capacitor of 10nF to the V- DC converter. This does indeed improve the ringing and the amplitude of transient response, reducing the amplitude of the 5500 Hz scope noise (image above) from 1 div to 1/3-1/2 div pp, but this is still too much, and the 1000uF bypass still performes better. I'm still investigating/trying...

[ Btw, I'm talking about low-frequency noise. High-frequency noise ist yet another issue. ]