-
Yes, you are right but, to be a simmetrical diff amplifier as I also supposed (as also suggested on ADC902E datasheet) I should have to find a resistor from U13.3 to gnd. Not being able to find it.
The 560 Ohm resistor (marked "561") on the left side of my AWG-AMP.jpg photo, below the two 150 Ohm resistors (marked "18A").
-
Sure, how did I not see it? It is already of the correct value.
Thanks -
Is everything related to the AWG populated as in a geniune 2D72?
Are the various 0 Ohm resistors replaced with the actual values as well?
Are the 49.9 Ohm (68X) resistors from the DAC outputs to GND present?
What DC voltage do you measure from DAC pin 17 to GND, and from pin 18 to GND?
What is the value of your Rset resistor, from DAC pin 18 to GND?
When you set the AWG to rectangle with amplitude=2.5V and offset=0V, what peak-to-peak voltages do you measure on the two DAC outputs?
Expected are about 500mVpp on one output, and about 850mVpp on the other one.
Hi gf, check done!
So, first of all I can say that all 0 ohm resistors were replaced as requested and now are exactly the same as in your pictures.
That implies that also 68X resistors from DAC outputs to GND are there.
Moving to measures, pin 17 to GND is 1.247V wile 18 to GND 1.243V. From DAC902E datasheet pin 17 (REF in) should be 1.24 so, considering voltmeter tolerance, sounds good.
Rset was already in place, and is a 1.78K (25B), the same as in your 2d72.
Now, set AWG square wave, amp 2.5V with offset 0, on DAC outputs I have 700mVpp and 1100mVpp. They seems a little too much based on what you wrote.
In any case, let's wait the coax cable to make final testing, after replacing feedback resistor on U13, that is now 560 ohm as it should.
Regards, mostorer -
The numbers look pretty reasonable. The Chinese DAC in in the genuine 2D72 has a lower vref than the DAC902 - only about 1.1V instead of 1.24V. Consequently, in order to source the same output current, a larger Rset value is required for the DAC902. Likely the calibration can still fix the difference, but keep in mind that a full-scale output current of 22.3mA (= 1.24V / 1.78kOhm * 32) already exceeds the DAC902's upper limit of 20mA. So it is certainly not wrong to increase Rset to 2kOhm, which will reduce the DAC output currents (and voltages) by about 10% then. Given your measured DAC output voltages, even Rset=2.2k may happen to yield just enough output current, but that's very close to the limit then, leaving almost no headroom for tolerances (the calibration can only down-scale the digital counts sent to the DAC, but it cannot up-scale them to a value beyond 2^12-1).
Instead of a coax cable, the probe in 1x setting might work as well if you manage to avoid a loose contact for the duration of the calibration. Btw, don't forget to auto-calibrate the scope first before you calibrate the AWG. IMO it were better if they had used the DMM for the AWG calibration, instead of the scope, since the DMM is more accurate. But well, they didn't - maybe because it would require a BNC to banana cable
gf -
BNC cable arrived, so I'm going to calibrate the AWG.
First of all I have uploaded into the scope the formware HantekHTX2019031201.dfu published previously in this forum.
As already written in my previous post, screen upside-down with white background.
Run the general calibration from the main menu, then connected the BNC-BNC cable and run the AWG calibration.
Calibration success !!!
Going to scope screen, the sinusoid is perfectly tuned 600mV -600mV, perfectly centered (offset 0).
At this point I update the firmware with the last dfu available, but when I swith the scope on, I have a big surprise ... the AWG is not calibrated.
It seems that the firmware update reset calibration, or the old calibration firmware does not save the calibration data at all.
Any trick to maintain calibration with up-to-date firmware ?
mostorer -
Actually I've no clue
Did the calibration survive a power-cycle when the HantekHTX2019031201 firmware was installed?
IMO they are saved. I had upgraded (my genuine 2D72) to a later firmware than HantekHTX2019031201, w/o noticeable loss of calibration data, but I have indeed not upgraded to the most recent firmware yet.
Just a guess: Maybe the AWG calibration data are reset by the firmware (deliberately) if the device model is not a 2Dx2, in order to motivate people to buy a 2Dx2?
If the firmware or the firmware upgrade would reset the calibration data unconditionally, then the device could never retain the factory calibration.
[ IIRC, the calibration feature was only present in the 2019031201 firmware because a bug in a previous firmware release garbled the calibration data. So Hantek had the need to provide a solution in order that users of the buggy firmware can re-create the lost calibration data. Later, the feature disappeared again. ]
-
Did the calibration survive a power-cycle when the HantekHTX2019031201 firmware was installed?
To be honest, did not try. I will revert back to the AWG calibration firmware and try.Quote from: gfJust a guess: Maybe the AWG calibration data are reset by the firmware (deliberately) if the device model is not a 2Dx2, in order to motivate people to buy a 2Dx2?
Could be but ... it seems that the firmware recognize the difference between 2c and 2d based on the presence of components, as in Sysinfo my scope appears now as 2d42Quote from: gfIf the firmware or the firmware upgrade would reset the calibration data unconditionally, then the device could never retain the factory calibration.
Fully agree.
But ... am I the only one who changed from 2cx2 to 2dx2 ? I suppose no. So, what about AWG calibration for someone else who did the same thing ?
-
Tried newly the AWG calibration. Done!
Switch off and then on the scope ... calibration data did not survive
So, what is the use of a calibration function if data are not saved ?
The firmware is the same for all models, so it's strange that it behaves differently.
The only thing that comes to mind is that there are some operations to do after calibration, to make the data permanent.[ IIRC, the calibration feature was only present in the 2019031201 firmware because a bug in a previous firmware release garbled the calibration data. So Hantek had the need to provide a solution in order that users of the buggy firmware can re-create the lost calibration data. Later, the feature disappeared again. ]
I understand but, I thought the firmware was a test release or something like that as it is completely unusable ... look at the attached image.
Is it something happening just to me ?
-
Interesting, Hantek must have changed something in the later FW or FPGA, I've used the FW "HantekHTX2019031201.dfu" many times before to calibrate the AWG amplitude and it worked perfectly. I decide to test it now and indeed, the screen is inverted.
Regarding it not holding the calibration data, try to restore the device to factory default to see if it makes any difference.
I tried to revert to an earlier FPGA version to see if it work but still the same thing. -
Regarding it not holding the calibration data, try to restore the device to factory default to see if it makes any difference.
Restored to factory default, run scope calibration and then the AWG calibration. All ok.
Switch off and on ... AWG not calibrated. Really a strange behaviour.
I think I will have to work on Rset to reduce the output current, so to have the correct signal amplitude out of the DAC, without calibration.
In the next days I will review the DAC902E datasheet in order to check, based on current Rset, res on Iout and OpAmp gain, if the output is aligned to what it should be, then I will calculate a new value for Rset and will post my considerations.
In this moment an amplitude of 1V produces 1,25V on the output channel.
-
In the next days I will review the DAC902E datasheet in order to check, based on current Rset, res on Iout and OpAmp gain, if the output is aligned to what it should be, then I will calculate a new value for Rset and will post my considerations.
In this moment an amplitude of 1V produces 1,25V on the output channel.
Nominally, it's trivial: 1.25V / 1.0V * 1780 Ohm => 2225 Ohm
+/- tolerance of the measured 1.25V, +/- tolerance of the 1.78k Rset, +/- tolerance of the new Rset
For better accuracy I suggest to measure the AWG output voltage with a DMM, since the (Hantek2000) scope is only specified with 3% accuracy, IIRC. Set AWG amplitude to 0 and the offset to say +1.5V, then to -1.5V, measure the two resulting AWG output voltages (-> DC) with a DMM and use (Vout@+1.5V - Vout@-1.5V) / (2 * 1.5V) as scaling factor for Rset.
If you have a DMM which is more accurate than the tolerance of the resistor, you can furthermore measure the resistor instead of assuming its nominal value.
The drawback of calibrating gain with Rset in the analog domain is still the missing offset calibration...
EDIT:
The DAC902's contribution to the offset is supposed to be only +/-1.25mV at the AWG output(+/- 0.025% FSR), so I'd suppose anything beyond that to originate in the amp (due to insufficient CMRR of the differential amp circuit, and offset voltage/current of the opamp).
-
Hello all. New 2c42 owner here. I am checking my hacking options here, or if anyone noticed what I did.
I tried to test the bandwidth of my scopes and my probes with a fast pulse, and a signal generator today, and it seems mine has far more than the claimed 40MHz bandwidth, probably 70Mhz or so.
Unfortunately I find it hard to tell, as there is some overshot and ringing going on, that really seems like an interpolation problem.
Unfortunately I can't get the pure ADC data out of the scope, as the display is interpolated and there are no options to change that, and even the PC software can only extract the interpolated waveform.
I wish I could get bare sample points on screen, perhaps with a linear interpolation to see more of the measurement, and less of the guesswork, but that may be just me.
I mean perhaps I could try lowering the time/div until every extracted sample corresponds to an ADC sample, but TBH I don't trust them I can get anything out of it that is not already "manipulated". I digress.
So. Did anyone do proper bandwidth tests of the 2x42, the 2x72 and a hacked 2x42? I really can't find my 40MHz limit in device, only this, what I think is a crappy interpolation artefact.
Above the 70-100MHz range it is the sample rate that limits the system anyway.
See attached picture. Good quality 10MHz signal fed in from a 50 ohm source through an 50 ohm BNC terminated coax. Looks "perfect" on a proper high bandwidth scope.
-
Hello all. New 2c42 owner here. I am checking my hacking options here, or if anyone noticed what I did.
I tried to test the bandwidth of my scopes and my probes with a fast pulse, and a signal generator today, and it seems mine has far more than the claimed 40MHz bandwidth, probably 70Mhz or so.
Unfortunately I find it hard to tell, as there is some overshot and ringing going on, that really seems like an interpolation problem.
Unfortunately I can't get the pure ADC data out of the scope, as the display is interpolated and there are no options to change that, and even the PC software can only extract the interpolated waveform.
I wish I could get bare sample points on screen, perhaps with a linear interpolation to see more of the measurement, and less of the guesswork, but that may be just me.
I mean perhaps I could try lowering the time/div until every extracted sample corresponds to an ADC sample, but TBH I don't trust them I can get anything out of it that is not already "manipulated". I digress.
So. Did anyone do proper bandwidth tests of the 2x42, the 2x72 and a hacked 2x42? I really can't find my 40MHz limit in device, only this, what I think is a crappy interpolation artefact.
Above the 70-100MHz range it is the sample rate that limits the system anyway.
See attached picture. Good quality 10MHz signal fed in from a 50 ohm source through an 50 ohm BNC terminated coax. Looks "perfect" on a proper high bandwidth scope.
Per Hantek's specs (see below) the "2000" series 'scopes (2D72, 2D42, 2C72 and 2C42) all have the same ≤ 5 ns rise time¹ specs at the BNC connector, and share the same 250MSa/s(Single-channel), 125MSa/s(Dual-channel) sample rate.
This leaves me to believe they share fundamentally the same "innards" and that the "model number bandwidth" indicated by the 3rd character of the model nomenclature is more related to establishing marketplace price points than to each model's actual instrument performance.
This is not unusual in mass manufacturing--General Motors did it for years. 20 or so years ago the lame stream media put it forth as some great "scandal" that Cadillacs used Chevy drive trains.
----------------------------------------------
¹ - Convention has it that bandwidth * rise time = 0.35; so bandwidth = 0.35/rise time--0.35 / 5e-9 = 70 MHz
-
Hello all. New 2c42 owner here. I am checking my hacking options here, or if anyone noticed what I did.
I tried to test the bandwidth of my scopes and my probes with a fast pulse, and a signal generator today, and it seems mine has far more than the claimed 40MHz bandwidth, probably 70Mhz or so.
Unfortunately I find it hard to tell, as there is some overshot and ringing going on, that really seems like an interpolation problem.
Unfortunately I can't get the pure ADC data out of the scope, as the display is interpolated and there are no options to change that, and even the PC software can only extract the interpolated waveform.
I wish I could get bare sample points on screen, perhaps with a linear interpolation to see more of the measurement, and less of the guesswork, but that may be just me.
I mean perhaps I could try lowering the time/div until every extracted sample corresponds to an ADC sample, but TBH I don't trust them I can get anything out of it that is not already "manipulated". I digress.
So. Did anyone do proper bandwidth tests of the 2x42, the 2x72 and a hacked 2x42? I really can't find my 40MHz limit in device, only this, what I think is a crappy interpolation artefact.
Above the 70-100MHz range it is the sample rate that limits the system anyway.
See attached picture. Good quality 10MHz signal fed in from a 50 ohm source through an 50 ohm BNC terminated coax. Looks "perfect" on a proper high bandwidth scope.
Even after being degraded to some amount by the frontent, the pulse is still is "too fast" for the given sampling rate and contains too much high-frequency components >= fs/2. Therefore it violates the sampling theorem. Consequently a sinc interpolation can no longer reconstruct the original signal waveform exactly. An exact reconstruction is only possible if the original signal were band-limited to < fs/2 in the first place, before being sampled. The ringing in your picture is to be expected under this circumstances. I guess the "proper high bandwidth scope" has not just a higher bandwidth, but in particular a higher sampling rate as well? (and some scopes may also have a built-in anti-aliasing filter)
It is hard (if not impossible) to measure the step response of the frontent if the sampling rate is so low. Better sweep the frequency of a sine-wave signal and find the -3dB point (with a sine wave, you can go up to almost 125MHz without violating the sampling theorem (when the sampling rate is 250MSPS), and even beyond 125MHz you could still measure the amplitude of the down-converted sine wave).
-
Even after being degraded to some amount by the frontent, the pulse is still is "too fast" for the given sampling rate and contains too much high-frequency components >= fs/2. Therefore it violates the sampling theorem. Consequently a sinc interpolation can no longer reconstruct the original signal waveform exactly. An exact reconstruction is only possible if the original signal were band-limited to < fs/2 in the first place, before being sampled.
Thanks. I am not an expert on interpolation, but makes sense. Either limit the bandwidth - and I was wondering if the scope is more useful in BW limit mode at 20MHz, or change interpolation algorithm at a certain time/div value in firmware, which I seem to remember seeing in a cheap Chinese scope a few years ago. Interpolation options would be nice, but it's hard to get the balance right between usability and over complication, especially in a handheld.I guess the "proper high bandwidth scope" has not just a higher bandwidth, but in particular a higher sampling rate as well? (and some scopes may also have a built-in anti-aliasing filter)
Yes, the digital has 1GS/s, and my analog has infinite.
It is hard (if not impossible) to measure the step response of the frontent if the sampling rate is so low. Better sweep the frequency of a sine-wave signal and find the -3dB point (with a sine wave, you can go up to almost 125MHz without violating the sampling theorem (when the sampling rate is 250MSPS), and even beyond 125MHz you could still measure the amplitude of the down-converted sine wave).
I am not that bothered about the actual BW. The 40MHz claimed is plenty for the price, having more is good to know, but I think it is much more important to be aware that apparent spikes riding on top/bottom of fast edges may be just the artefact, and if they are important, verify, hook up a proper scope.
For most uses I will probably keep it in 20MHz limit which is still amazing for the price point and form factor, and then there is the 10mV/div minimum sensitivity, which asks for a fair amount of 1x probing anyway. -
This leaves me to believe they share fundamentally the same "innards" and that the "model number bandwidth" indicated by the 3rd character of the model nomenclature is more related to establishing marketplace price points than to each model's actual instrument performance.
Haha, yes.
Good times!
Way back when, they used to build the front end for the bandwidth.
Then they gave you the top of the range for free, just crippled it in firmware for you to hack.
Nowadays they can't even be bothered to do that!
Perhaps the limit in firmware was a planned feature that they cut once they estimated the costs and actual effect on sales.
Or... That "casual" users won't know that they were "cheated", while nerds will just do the research, buy the low price version, love the freebie, and remember in 5 years if/when Hantek becomes the new Rigol. -
Hello,
I made a big mistake this morning by wanting to measure resistances and tensions. in the precipitation I forgot to change the mode between AC and ohm. more AC and ohm reading result. R14 R15 burn, what are the values? please
thank's -
That seems to be a fairly common mistake, I have fixed a few of these devices with the same problem. Usually, simply replacing the resistor fix the multimeter.
R14 is 10K
and R15 is 1K both are 0603 1% SMD resistors
I've attached a picture of the resistors for future reference.
-
Hi I have the 2C42 version and will upgrade it to 2D42 following this forum. Is it possible to replace the DAC902 with DAC904? I don't know why the DAC904 is cheaper than DAC902 here. It is pin compatible according to the datasheet. It seems the only difference is the resolution.
-
Just wanted to document somewhere that I was able to update firmware using dfu-util (http://dfu-util.sourceforge.net) which supports the STM DfuSe extension (http://dfu-util.sourceforge.net/dfuse.html) used by this scope. dfu-util should be available as a package on most Linux distros, and also on macOS through homebrew, which is what I used.
To begin, place the device in DFU mode as normal (Hold F1 while powering on).
Then as a test and to create a backup of the current firmware, run:Code: [Select]$ dfu-util --device 0483:* -a 0 -s 0x08005000 -U backup.bin
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Limiting upload to end of memory segment, 503808 bytes
Upload [=========================] 100% 503808 bytes
Upload done.
If that works, then you're communicating with the device properly, so let's use the .dfu package to write the new firmware:Code: [Select]$ dfu-util --device 0483:* -a 0 -D HantekHTX2020070701.dfu
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Match product ID from file: 0000
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (1 elements, total size = 229444)
parsing element 1, address = 0x08005000, size = 229436
Download [=========================] 100% 229436 bytes
Download done.
done parsing DfuSe file
Finally, we need to exit DFU mode. dfu-util lets us do this, but not without doing another upload/download action. So let's read the firmware out again and also pass along the "leave" command to kick the device out of DFU.Code: [Select]$ dfu-util --device 0483:* -a 0 -s 0x08005000:leave -U backup_new.bin
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Limiting upload to end of memory segment, 503808 bytes
Upload [=========================] 100% 503808 bytes
Upload done.
Transitioning to dfuMANIFEST state
And finally, just to describe the command line flags used here: the --device flag picks the device, and while the raw binary reading isn't picky, the DfuSe mode wants this to match what's specified in the .dfu file, so 0483:* matches that. "-a 0" matches the DFU endpoint for the internal flash. SPI and NOR flash also seem to be exposed:Code: [Select]Found DFU: [0483:df11] ver=0200, devnum=9, cfg=1, intf=0, path="253-1.3", alt=2, name="@NOR Flash : M29W128F/0x64000000/0256*64Kg", serial="XXXXXXXXXXXX"
Found DFU: [0483:df11] ver=0200, devnum=9, cfg=1, intf=0, path="253-1.3", alt=1, name="@SPI Flash : M25P64/0x00000000/128*64Kg", serial="XXXXXXXXXXXX"
Found DFU: [0483:df11] ver=0200, devnum=9, cfg=1, intf=0, path="253-1.3", alt=0, name="@Internal Flash /0x08000000/06*002Ka,250*002Kg", serial="XXXXXXXXXXXX"
Hopefully this is useful to someone! -
Has anyone looked into adding wifi to these handheld hantek scopes? I noticed someone commented in this thread that it looks like there is an unpopulated space on the PCB for an ESP8266, but didn't see any other discussions about it. Not knowing what the code should be on the ESP8266 could be an issue, but it might be possible to dump/copy the code from Hantek's IDS1070A USB Wifi scope which also uses an ESP8266 for it's wifi communication...
Edit: the IDS1070A doesn't actually use an ESP8266, just a generic STM microcontroller with built-in wifi. But, it's protocol has already been reverse engineered on GitHub and is just a basic Request-Response protocol, so implementing it on an 8266 should be fairly straightforward. -
Just wanted to document somewhere that I was able to update firmware using dfu-util (http://dfu-util.sourceforge.net) which supports the STM DfuSe extension (http://dfu-util.sourceforge.net/dfuse.html) used by this scope. dfu-util should be available as a package on most Linux distros, and also on macOS through homebrew, which is what I used.
Hopefully this is useful to someone!
Tremendously helpful, thanks! -
I think I have put voltage on the terminals when the meter stand in Ohm After opening I have seen 2 o resistors on the underside of the CS7721CN chip above the banana bushes. which are burned.
If only the resistors are burned you are lucky, it's likely that you have damaged the dmm chip. Anyway, if you want to try to repair it, I opened up mine to check the resistors values: R14 is 10K 1% and R15 is 1K 1%.
I've tried to take a picture as well, it is not great but it may help.
(Attachment Link)
Just curiosity, what was the voltage you were measuring?
I've just had this happen on my new 2D42 when measuring mains voltage (around 250V AC) with the DMM section set to "AC V". The same two resistors are burned and the display still shows that I have "AC V" selected... Very annoying! -
I have the 2D72. The DMM DC volts calibration was out by about 10mv. To adjust the DMM calibration (after taking the back case off) use the top pot (farthest away from the bottom of the case) to get an accurate DC voltage measurement. You will need a stable voltage reference and a known accurate voltmeter to compare against. (I used a Fluke 87V that is know to be calibrated). The adjustment is quite sensitive, so make very small adjustments until the meters read the same. You may wish to calibrate in the voltage area of interest, in my case I am mostly interested in around the 12v to 13v area. The meter is not fully linear across the entire range. Make sure both of you meters (and voltage reference source) have been on for about 15 minutes, and both meters have been allowed to be in room temperature for several hours first. The 2nd pot (closest to the bottom of the case) will adjust the AV voltage reading. I could not get mine to match the Fluke 87V meter exactly. best I could get it was about .25 VAC off.
-
I have decided to upgrade my 2C42 to enable the AWG. I have gathered as much information as possible, got the chips and opened my scope. I was surprised everything is already present here - DAC, op amp, R65 that should inform the MCU the DAC is present - everything exactly as in the photos of 2Dx2. I have tried to change FW but no matter what I get the message no AWG is present. I have tried to find what is going on but without any success. The DAC is used to generate the calibration signal with frequency 1 kHz (someone somewhere said some other frequency is generated in the non-DAC version - strange). On the R65 is 0 V at the DAC side and about 3 V on the other side - I was not able to find where it is connected. Do you have some idea what I can try to enable the DAC?
EDIT: I tried to find where is the R65 is connected. One side is connected to the Enable pin of the DAC and FPGA. The other has direct connection to supply voltage of the FPGA. I am quite sure there is no direct connection to the ARM processor. I am not sure if it is connected to any I/O pin of the FPGA. Is it possible it is only a pull-up disabling the DAC until the FPGA overrides it? Can someone confirm this? If there is some short circuit on my board and the resistor should not be connected to FPGA Vcc, can you tell me where it is connected so I can fix it? Thanks.
