Please select To the mobile version | Continue to access the desktop computer version

Electronic Engineer Discuss

Author: OASJ2YSeeEhBQo1

Hantek2d42 bugs report

[Copy link]

4

Threads

29

Posts

29

Credits

新手上路

Rank: 1

Credits
29
Post time 2019-3-13 06:33:58 | Show all posts
Edited by gf1 at 2019-3-14 03:01
amy replied at 2019-3-12 15:20
Sir, about the AWG burr, there is a solution to deal with.
1. Replace the resistance to 1.5KΩ in th ...

Dear Amy,

thanks for your efforts to get this issue resolved.

Do I understand correctly that the idea is to increase the full-scale DAC current by about 20% and to compensate this by sending a smaller digital count range to the DAC? Then re-calibrate the AWG, using the scope to measure the AWG output. I'm wondering whether the scope is accurate enough to act as calibration reference? Wouldn't the DMM have a significantly better accuracy?

Is it possible to save my current AWG calibration (which happens to pretty accurate, btw. ) and to restore it later if the AWG burr fix procedure does not give the desired results and if I need to fall back?

[ EDIT: re-phrased questions ]


Thank you,
gf1





4

Threads

29

Posts

29

Credits

新手上路

Rank: 1

Credits
29
Post time 2019-3-15 06:19:46 | Show all posts
Edited by gf1 at 2019-3-15 19:57

I noticed yet another noise pattern of the scope, caused by the AWG, and affecting both scope channels.

  • This one is particularly pronounced at low AWG frequencies.
  • AWG is set to square wave, 500 Hz, 2V amplitude.
  • AWG output is connected to a 50 Ohm load resistor.
  • CH1 and CH2 inputs are 50 Ohm terminated, i.e. no signal applied to the scope inputs (all you see below is noise).
  • If the load is removed from the AWG ouput, then the noise amplitude decreases as well. So I guess this particular noise is primarily
    caused by the ouput current of the AWG's EL5166 amp (or the corresponding current drawn from the power supply rails).



This noise has maximum amplitude at 10mV/div and 500mv/div, and progressively decreases at 20, 50, 100 and 200 mV/div. So I think it is already present at the output of the frontend's buffer amplifier (at the input of the the resistor ladder attenuator).

The AWG output waveform itself looks OK (when displayed on my 6074BD).

EDIT: The ringing component of this noise signal also shows up on the negative power supply rail of the AWG's EL5166, in an amount of about 40 mV pp. The positive rail is not perfectly clean either, but there is more high-frequency noise.

gf1


This post contains more resources

You have to Login for download or view attachment(s). No Account? Register

x

10

Threads

171

Posts

171

Credits

注册会员

Rank: 2

Credits
171
 Author| Post time 2019-3-16 13:21:56 | Show all posts


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





To observe these glitchs, I just set any frequency and them start changing the amplitude of the waveform step by step. For each frequency it will ocurr at a specific amplitude setting. (Apparently higher frequencies and amplitudes lower than 1V are the worst case).

As already reported, I'm also noticing a huge noise interference in CH2 of the scope, specially when the AWG is on:


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.



This post contains more resources

You have to Login for download or view attachment(s). No Account? Register

x

167

Threads

2070

Posts

2232

Credits

版主

Rank: 7Rank: 7Rank: 7

Credits
2232
Post time 2019-3-16 16:47:36 | Show all posts
gf1 replied at 2019-3-13 06:33
Dear Amy,

thanks for your efforts to get this issue resolved.

In fact, I don't know much about hardware circuits. It's a solution given by engineers.
Most users do not have BNC to DMM connectors. So I think BNC to BNC is more suitable.
And the original calibration data cannot be saved at present.  I will advise the engineer.

167

Threads

2070

Posts

2232

Credits

版主

Rank: 7Rank: 7Rank: 7

Credits
2232
Post time 2019-3-16 16:48:25 | Show all posts
gf1 replied at 2019-3-15 06:19
I noticed yet another noise pattern of the scope, caused by the AWG, and affecting both scope channe ...

About the noise, I will feedback.
We will reply you next week.

4

Threads

29

Posts

29

Credits

新手上路

Rank: 1

Credits
29
Post time 2019-3-17 05:45:38 | Show all posts
Edited by gf1 at 2019-3-17 05:49
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


4

Threads

29

Posts

29

Credits

新手上路

Rank: 1

Credits
29
Post time 2019-3-17 17:35:52 | Show all posts
Edited by gf1 at 2019-3-17 22:58

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


This post contains more resources

You have to Login for download or view attachment(s). No Account? Register

x

0

Threads

7

Posts

7

Credits

新手上路

Rank: 1

Credits
7
Post time 2019-3-18 10:40:58 | Show all posts
请问下,你们的上位机软件自带的远程更新模块,版本还是老版本,没有放更新文件

167

Threads

2070

Posts

2232

Credits

版主

Rank: 7Rank: 7Rank: 7

Credits
2232
Post time 2019-3-18 16:42:22 | Show all posts
罐头瓶子 replied at 2019-3-18 10:40
请问下,你们的上位机软件自带的远程更新模块,版本还是老版本,没有放更新文件
...

最新固件已上传,请再次升级试试

0

Threads

7

Posts

7

Credits

新手上路

Rank: 1

Credits
7
Post time 2019-3-20 09:01:06 | Show all posts
amy replied at 2019-3-18 16:42
最新固件已上传,请再次升级试试

非常感谢,已更新,这个功能真的很方便
You have to log in before you can reply Login | Register

Points Rules

Dark room|Mobile|Archiver|Electronic Engineer Discuss

2024-3-29 15:12 GMT+8 , Processed in 0.244968 second(s), 19 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

Quick Reply To Top Return to the list