Electronic Engineer Discuss

Title: Hantek2d42 bugs report [Print this page]
Author: OASJ2YSeeEhBQo1    Time: 2019-2-14 13:11
Title: Hantek2d42 bugs report
Edited by OASJ2YSeeEhBQo1 at 2019-3-16 12:15

Hello Amy, how was the Holidays, I hope you have enjoyed it.

So I have a new handheld 2D42 and I'm enjoying it so far but I found some bugs that I would like to report, if you don't mind:
FW: 2019011101
PCB: 0000001
FPGA: V02

1- In oscilloscope mode, pressing Autoset button does not limit the memory depth
Description: Activate only one channel, let's say CH1. Change memory depth from 3k to 6k. Keep only CH1 on and apply a signal to CH1 and CH2. Press Autoset button. The memory depth won't be limited automaticaly to 3k and you will see both waveforms on the screen all crazy, as the data is broken. Setting de mem. depth manually to 3k solve it. Fixed (in FW 20190220001)
If you turn on CH2 by pressing Channel -> CH2 -> On the memory depth is automatically limited to 3k, that is fine.

2- In DMM mode, selecting the Buzzer function using the arrow keys ">" or "<" does not activate the buzzer and it is silent I need do press F3 for it to work. Fixed (in FW 20190220001)

3- This one is probably a hardware limitation/problem. In th AWG mode, the waveform is clipping on the negative side as I increase the amplitude to near the 2.5V limit or if I set a negative offset (see picture)
[attach]2602[/attach]

4- The jitter of the AFG is pretty horrendous, specially with frequencies over 1MHz. Is that normal?
[attach]2599[/attach]


5-Waveforms presents some artifacts under various settings of frequencie and amplitude (I am still trying to isolate this one)
[attach]2600[/attach][attach]2601[/attach]

regards,





Author: amy    Time: 2019-2-14 15:58



Sir, thanks for your feedback.
Our engineer will modify.
Author: gf1    Time: 2019-2-16 20:36
Edited by gf1 at 2019-2-17 18:53

... In th AWG mode, the waveform is clipping on the negative side as I increase the amplitude to near the 2.5V limit or if I set a negative offse...

I'm facing the same issue as well on my 2D72. I measure a supply voltage of +5V / -3.3V on the output amp (EL5166) of the AWG. According to the datasheet, the output of the EL5166 can swing to within 1V of either supply rail, so -2.5V is actually beyond this limit. Fixing this issue would IMO require a hardware change (i.e. increase the negative supply voltage of the amp).

The jitter of the AFG is pretty horrendous, specially with frequencies over 1MHz. Is that normal?


For instance, a 5MZh square wave would fulfill the condition (1), but the DDS can't generate exactly 5MHz, due to condition (2). But the closest frequency which can be generated by the DDS generator does no longer fulfill condition (1) and also suffers from phase truncation errors. So you are rather limited regarding the square wave frequencies which can be generated "exactly" without stretching/shortening some of the pulses  (=> basically only power of 2 fractions of the DAC clock freqency).

If I try for instance 7.8125 MZh (= 250MZh / 32) on my 2D72, I get a nice square wave - but not for any arbitrary frequency.

Regarding DDS, see for instance https://www.analog.com/media/en/ ... utorials/MT-085.pdf, or one of the many other DDS resources which can be found in the internet.

EDIT:
Square waves and pulses with very steep edges and/or small pulse widths are of course the worst case waveforms forms for DDS, when they should be reproduced at higher frequencies. Sine waves are not a problem in this regard, since they are already band-limited to the sine wave frequency. But for other kind of waveforms, the resampling done by the DDS may eventually violate the Nyquist–Shannon sampling when generating signals with higher frequencies, and this implies that the signal cannot be reconstructed exactly from the sampled data.

A possible workaround you can do is to increase the rise time (and thus reduce the bandwidth) of the square wave manually, by approximating a square wave with a trapezia. If you generate, for instance, a trapezia on the Hantek 2000, with RiseDuty=FallDuty=0.08 and HighDuty=FallDuty=0.42 with 5MHZ, then you'll notice less jitter than with a 5MHz square wave - but at the cost of renouncing the steep rise time of a true square wave.

[attach]2616[/attach]

Regards,
gf1


Author: gf1    Time: 2019-2-17 05:31
Edited by gf1 at 2019-2-19 03:15
Waveforms presents some artifacts under various settings of frequencie and amplitude

I'm seeing similar glitches, too, at the AWG output of my 2D72. However, I can in particular reproduce it at 2.5V output voltage (when the negative lobe gets clipped). The spikes are already present at the input of the AWG's power amp (see blue curve below), so I don't think it caused by the clipping of the amp.  I don't see any correlated gltches on the power rails, either. I'm still unsure regarding the origin of the glitches. Since I have no evidence yet for an analog root cause, I would not rule out that they are already present in the digital signal fed into the DAC. I have no logic analyzer to measure that, though.

Yellow = AWG output, blue = input of EL5166 = output of DAC902
(captured with my Hantek 6074BD)

[attach]2614[/attach]

EDIT:
I was able to reproduce it at a much lower amplitude as well, and also manged to get a stable pulse trigger on a particular glitch. Further investigations reveal, that this glitch (in the center of my screenshots below) obviously happens at the time when DAC input Bit5 goes high and Bits 6, 7, etc. go low. I guess that it is a timing issue - possibly for some (but not all) of the BitX inputs, the required setup times are not met, so that they are seen by the DAC one cycle too late. The carry-over from  bits 6,7,... to bit 5 is obviously one of the places where this happens on my device, but there exist obviously other voltage levels as well, where glitches do occur.

EDIT:
The rising/falling edges of the DAC inputs are not clean either, but show some kind of oscillation/ringing/noise. I'm not sure whether this intentional noise added by the DDS to the digital signal, or whether it is an undesired flaw of the circuit. I also can't rule out that the latter is caused by the load of the oscilloscope probe attached to the pins, however, the double-probing test (i.e. attaching a 2nd probe to the same signal) did not make much difference.


yellow = AWG output, blue = DAC input Bit5 (Bit6 in 2nd image)

[attach]2617[/attach]

[attach]2617[/attach]

-gf1


Author: OASJ2YSeeEhBQo1    Time: 2019-2-19 00:07
Yeap, those are the glitches I was referring in the item 5 of may previous post. I will try to take some screen shots later and post here, with another problem I'm found on the oscilloscope.
Author: OASJ2YSeeEhBQo1    Time: 2019-2-19 09:45

Just some more screenshots to ilustrate the gitches problems in the output of the AWG.

[attach]2623[/attach][attach]2622[/attach]

6 - Another problem I noticed in my oscilloscope is that the wave form in CH2 is deformed comparing with CH1, even if I apply the same signal to both. The problem is more visible with channels 1 and 2 turned on and at higher frequencies (around 1MHz), but the difference is noticeable with just CH2 on too. Maybe the sample rate is not enough or some problem with the interpolation calculation, I don't know

[attach]2624[/attach][attach]2625[/attach][attach]2626[/attach]

A few more images
[attach]2629[/attach][attach]2628[/attach][attach]2627[/attach]


Author: gf1    Time: 2019-2-22 07:37
Edited by gf1 at 2019-2-22 18:04

What I see in 2ch_1M.jpg and 2ch_1M_sq.jpg looks mostly like random noise. The additional spikes are likely from the AWG - I guess - and not from the scope - did you use the internal AWG? And yes, CH2 seems to be more noisy than CH1. I am facing exactly the same as well, when the device is assembled. FFT does not show a peak at particular frequencies, but rather flat wideband noise. However, if I lift one PCB, so that there is a distance of about 5cm between the two PCBs (as much as the ribbon cable length allows), then this noise decreases and CH2 becomes as clean as CH1. Apparently, some noise is radiated by the processor board and picked up near the ADC inputs. I'm wondering if a shield between the boards would help? In fact the front ends behave pretty well, regarding noise. At 10mV/div, the noise level of the 2D72 is similar to the noise level of my 6074BD. [ Of course only, as long as I keep the two PBCs at distance. ]

Your other images, like deform2.jpg, look like an attempt to apply sinc interpolation to a noisy signal - this does not work well. If you want to see what was really catpured by the ADC, then select a timebase of 500ns/div or even 1us/div. You still get 125MSPS or 100MSPS with this timebase. Then freeze the capture, and zoom-in. This avoids sinc interpolation and displays the captured samples as staircase on the device (or linearly interpolated in the PC software).

gf1


Author: amy    Time: 2019-2-22 13:41
Sorry, I didn't reply in time.
About signal burrs and the waveform is clipping on the negative side, the hardware needs to be changed.
Other firmware problem, please refer to this post to update the firmware: https://www.eediscuss.com/forum. ... id=13676&extra=
We'll give you the best solution. Please wait for some days.
Author: OASJ2YSeeEhBQo1    Time: 2019-2-23 06:24
Hi Amy,

Thanks for the reply. I just updated to the FW: 201902201 run I quick test and apparently the bugs 1 and 2 are fixed. I noticed the Measure window in scope mode was also changed... I will do some more in depth tests and I came back if I found anything else.
Regarding the other problems that are hardware related, would you mind to provide some more details?

To @gf1: I tested using the internal AWG and a HDG2002B function generator,  I tried various setup configuration, using coax cable with and without 50ohm termination, x10 probes, signal output from same channel and from 2 different channels of the awg. I also tried the BW limit on and off, nothing makes a difference that's why I don't think the problem is only noise, let's wait to see if Hantek can give us a better explanation.
Author: gf1    Time: 2019-2-23 23:28
Edited by gf1 at 2019-2-23 23:36

At the moment I'm facing the following noise issue:

[attach]2638[/attach]

These artifacts do happen, when the device is connected to the PC and if the windows software is collecting data. If I stop data collection in the PC software (i.e. press the pause button in the toolbar), then these artifacts disappear on the display of the device (which continues capturing and displaying data). If I continue data data collection in the PC software, the artifacts are back again. I also managed to trigger and capture this noise alone, without any signal connected to CH2 (input terminated with 50 Ohm resistor), see following image.

[attach]2639[/attach]

For better resolution I have also calulated a 1200 point FFT from the saved data (unfortunately, the PC software is still limited to saving only 1200 data points, even though capture buffer is 3k).

[attach]2640[/attach]


Author: gf1    Time: 2019-2-25 00:27
Edited by gf1 at 2019-2-25 04:19

@OASJ2YSeeEhBQo1:

To demonstrate how sinc interpolation can screw-up the displayed waveform (when the bandwidth of the captured signal did violate the sampling theorem) I have captured a 7.8125 MHz square wave signal from the 2D72 AWG with my 6074BD, a) with sinc interpolation and b) with linear interpolation. In order to force a reduced sampling rate of 250MSPS (in order that the result is better comparable to the 2D72), I have turned on all 4 channels.

6074BD - sinc interpolation:

[attach]2641[/attach]

6074BD - linear interpolation:

[attach]2642[/attach]

The "linear" result is likely closer to the  true waveform (square wave). And the sinc result looks almost like the waveform displayed on my 2D72 (in single channel mode) at the same sampling rate and timebase. Unfortunately, sinc interpolation is the default on the 2D72 and can't be turned off - in cases where it is undesired.

EDIT: Added the 2D72 screenshot for comparison (also 250MSPS, 50ns/div) - looks almost the same as 6074BD with sinc.

[attach]2643[/attach]


@Amy: Feature Requests:





Author: OASJ2YSeeEhBQo1    Time: 2019-2-25 14:55
Edited by OASJ2YSeeEhBQo1 at 2019-3-16 12:12

Hi Amy,

I have a few more observations, if you allow me. Please, don't get me wrong, I really like this device and I think it has a great potential, it just need some polishing.

1- With the last FW in Scope mode, Measure window was changed from amplitude to max/min, but the values for MAX and MIN are computed with reference to the center of the screen, not to the channel cursor. So if I move the channel trace, the values changes. Fixed (in FW 2019030201)
Regarding the Measure windows I have two suggestion:
a- Add the option to choose a different parameter to measure, like Vpeak-peak, Vrms, Max/Min, amplitude, frequency, duty cycle and period. It don't need to have all types of measurement, I understand that you want to keep it simple, but having just one type is very limiting.
b- Display the values only for the channel that is active. The screen is small and there is no reason to keep showing a banner with only "????" on top of the signal I'm trying to see.

2- Connecting the USB cable to the scope adds a small DC offset to the waveform;
3- This one is very annoying: Every time the device is connected to the PC software, its settings are reset to default. The software also do not keep the last configuration used nor reads the actual settings on the device.
4- The PC software uses only 1200 data points to trace the waveform when we could have up to 6k;
5- The PC software is very slow and barely usable;
6- The AutoUpdate feature is very nice to have, but the related window need to be translated to English; Fixed (in Software version 1.1.10)
[attach]2644[/attach]
7- When using the device connected to the PC software, the configurations are not synced in both ways. If I set a parameter in the software the corresponding function in the handheld is updated but it does not work the other way around causing some problems. For exemple:
[attach]2645[/attach]
8- The PC software in DMM mode keeps logging values even while the hold or "stop collecting data" button is pressed.
9- Just a minor detail: in AWG mode setting a negative offset and then using the arrow keys "^" to increase the value will show "-0.00V" when it gets to 0V.
10- One last suggestion: add the ability for the button "Menu" to toggle the menu on and off. So when I press the button the menu is shown on the display, pressing it again will close it, this way I don't have to wait a delay time for the menu to disapear. Same for Channel, Time and Trig buttons.






Author: amy    Time: 2019-3-2 16:34
gf1 replied at 2019-2-25 00:27
@OASJ2YSeeEhBQo1:

To demonstrate how sinc interpolation can screw-up the displayed waveform (when t ...

Sir, sorry, the default interpolation mode is sinusoidal interpolation. No longer add other interpolation modes.
In fact, the choice of hardware components determines the transmission speed, operation speed and storage depth. Can not increase sampling number and add average sampling.
About the AWG burr, we will come up with a solution next week.
But about CH2 noise, our engineer has not come up with a good idea yet.
Please wait for some days.
Author: amy    Time: 2019-3-2 16:56
OASJ2YSeeEhBQo1 replied at 2019-2-25 14:55
Hi Amy,

I have a few more observations, if you allow me. Please, don't get me wrong, I really like  ...

Sir, the  values for MAX and MIN have been modified. Please download the latest firmware to update.
Due to the choice of hardware components, the transmission speed, operation speed and storage depth will be limited. Can not increase sampling number on PC software.
The update software has not been added English language.
About other usage and communication issues, I will feed back to the Engineer to modify.
I will reply you before next Friday.
Author: gf1    Time: 2019-3-2 23:24
Edited by gf1 at 2019-3-3 05:57
But about CH2 noise, our engineer has not come up with a good idea yet.

There seem to be multiple sources of noise.

I'm pretty confident that one of them is related to the AGW.

AWG turned on (nothing connected to the device):
[attach]2657[/attach]

AWG turned off:
[attach]2658[/attach]

EDIT:

When the AWG is turned on, the device also radiates some EMI noise, which I can pick up with a small wire loop "antenna" in the proximity (a few centimeters) of the device. The waveform and spectrum of this noise varies, depending on the selected AWG parameters (frequency, waveform and amplitude). When I set the AWG to square wave, then I can see a clear correlation between the radiated  noise bursts and the generated signal (yellow = picked-up noise radiated by the 2D72, blue = AWG output):

[attach]2659[/attach]

The same, zoomed-in:

[attach]2660[/attach]

Even more zoom (noise only - w/o AWG signal) - CW frequency of the burst circa 250 MHz:

[attach]2661[/attach]

I guess that this noise is not only radiated as EMI, but also coupled into the frontents and/or the signal path between frontent and ADC (where CH2 happens to be affected stronger than CH1).






Author: gf1    Time: 2019-3-3 06:31

Dear Amy,

that's not a problem, but a remark:

I find the "Hello" boot logo useless, and I see no need that the user can turn it on or off.
If I were you, I would generally display the Hantek company logo and the Sys Info for a couple of seconds during boot (and remove the "Boot Logo" menu entry on page 5/5)

gf1



Author: OASJ2YSeeEhBQo1    Time: 2019-3-8 08:15
Thx for keeping us informed. I will test the last firmware while I wait for news about the other issues.

Author: amy    Time: 2019-3-8 16:08
Sorry to reply you that the software and firmware modifications have not yet been completed.
The engineer will finish next week.
Author: gf1    Time: 2019-3-11 00:37
Edited by gf1 at 2019-3-11 00:39

Dear Amy,

yet another issue with the AWG:


Thanks,
gf1





Author: amy    Time: 2019-3-12 15:20
Edited by amy at 2019-3-12 15:22

Sir, about the AWG burr, there is a solution to deal with.
1. Replace the resistance to 1.5KΩ in the following picture.
   [attach]2680[/attach]

2. Use the firmware to update.
   [attach]2681[/attach]

3. Connect "Gen out" to "CH1".
4. Open the oscilloscope and press "AWG".
5. Set the waveform type to "Sine", enter the second page and press "Calibrate(F3)" to calibrate.











Author: gf1    Time: 2019-3-13 06:33
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





Author: gf1    Time: 2019-3-15 06:19
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.


[attach]2685[/attach]

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


Author: OASJ2YSeeEhBQo1    Time: 2019-3-16 13:21


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

[attach]2695[/attach][attach]2691[/attach]

[attach]2692[/attach][attach]2693[/attach]

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:
[attach]2697[/attach][attach]2698[/attach]

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.



Author: amy    Time: 2019-3-16 16:47
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.
Author: amy    Time: 2019-3-16 16:48
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.
Author: gf1    Time: 2019-3-17 05:45
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


Author: gf1    Time: 2019-3-17 17:35
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:

gf1


Author: 罐头瓶子    Time: 2019-3-18 10:40
请问下，你们的上位机软件自带的远程更新模块，版本还是老版本，没有放更新文件
Author: amy    Time: 2019-3-18 16:42
罐头瓶子 replied at 2019-3-18 10:40
请问下，你们的上位机软件自带的远程更新模块，版本还是老版本，没有放更新文件
...

最新固件已上传，请再次升级试试
Author: 罐头瓶子    Time: 2019-3-20 09:01
amy replied at 2019-3-18 16:42
最新固件已上传，请再次升级试试

非常感谢，已更新，这个功能真的很方便
Author: gf1    Time: 2019-3-22 05:18
Edited by gf1 at 2019-3-22 06:20
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




Author: amy    Time: 2019-3-22 14:47
Sorry, our Engineer hasn't given me a conclusion yet.  I'll urge him to reply next week.
Author: OASJ2YSeeEhBQo1    Time: 2019-3-24 11:57
Title: RE: Hantek2d42 bugs report
gf1 replied at 2019-3-22 05:18
That's really heavy!
I've never seen such a high amplitude on mine.


I tought that is strange too, the noise problem on CH2 was clearly noticeable before but I don't rementer it was this bad. Maybe it got worse after the change made to the resistor or the FW update but I'm not sure, I wasn't paying much attention to this problem before. I'll try to revert the changes later to see if there is any improvement.

Does it make a difference in your case whether the AWG is open or driving a load?
None
Was USB connected to PC or power supply?
No, tested both ways. The only problem (already reported) when connecting the USB cable is the few mV offset added to the traces.


Does the noise amplitude (in div units on the display) change with V/div setting of CH2?
No, the signal looks exactly the same whatever voltage scale I use, the only configuration that reduces the displayed noise a bit is turning on the BW limit, anything else has no effect.


Sorry, our Engineer hasn't given me a conclusion yet.  I'll urge him to reply next week.
I'm looking forward to that. I hope they will consider the other suggestions as well.



Author: OASJ2YSeeEhBQo1    Time: 2019-3-27 12:27
Edited by OASJ2YSeeEhBQo1 at 2019-3-27 14:48

Just to keep this thread alive while we wait for the other solutions:

12 -The Measure windows doesn't compute the frequency of the signal if at least part of it is not crossing the center line of the screen. That means, if I move the trace to the top half or the bottom half of the screen, the oscilloscope reads the frequency as 0.00. See pictures, I am using FW 2019031201.
[attach]2713[/attach] [attach]2714[/attach] [attach]2715[/attach] [attach]2716[/attach]

Please, also note the difference between MAX and Min values caused by a small offset in the channel that I can't get rid off even after calibration (maybe it is a similar bug in the calibration rotine as reported in the other thread about the 6074?)




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

[attach]2724[/attach]

Author: OASJ2YSeeEhBQo1    Time: 2019-4-2 07:35
Hi Amy, thanks again for the update. I will try the FPGA update tonight.

Any news about the other issues reported as well?
Author: amy    Time: 2019-4-2 11:33
Sorry, the firmware bugs have not been updated yet.
Author: gf1    Time: 2019-4-3 02:32
Edited by gf1 at 2019-4-3 13:15
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




Author: gf1    Time: 2019-4-10 05:26
Edited by gf1 at 2019-4-10 07:02

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:

[attach]2782[/attach]

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:


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




Author: thoquz    Time: 2019-4-27 17:38
Hi Amy, sometimes it does not read what the frequency is, so I have to use the cursor.
The cursor can easily show me the time (period) in seconds, but it does not show the frequency which is just 1/time.
This should be an very easy update, could you please ask the engineers?
Author: OASJ2YSeeEhBQo1    Time: 2019-8-12 02:02
thoquz replied at 2019-4-27 17:38
Hi Amy, sometimes it does not read what the frequency is, so I have to use the cursor.
The cursor ca ...

Which FW version are you using? There was a bug with the frequency measurement that I reported some time ago but it was already fixed in the latest FW.
https://www.eediscuss.com/forum. ... 2&fromuid=26055

You can get the newest version here:
https://www.eediscuss.com/forum. ... 8&fromuid=26055




Welcome to Electronic Engineer Discuss (https://eediscuss.com/) Powered by Discuz! X3.2