Hantek HDG2002B AWG: 5Mhz or 100MHz? Let's see!

[idpromnut]

@tinhead: nice SA screen caps, thanks for that!

they has been made by RFasic, i only re-posting them

https://www.eevblog.com/forum/testgear/hantek-hdg2002b-awg-5mhz-or-100mhz-let's-see!/msg447032/#msg447032

Doh! I thought they looked a bit familiar

[tinhead]

and btw, i don't have any HGDxxxx here, i'm running only firmware dump of such AWG on S3C2416 dev board (with no FPGA/DAC), so all i can tell/do are things related to the SoC/firmware, but not to the performance of the AWG.

[idpromnut]

and btw, i don't have any HGDxxxx here, i'm running only firmware dump of such AWG on S3C2416 dev board (with no FPGA/DAC), so all i can tell/do are things related to the SoC/firmware, but not to the performance of the AWG.

Right, I think I remember you saying something to that effect already at the beginning of this thread.

[fremen67]

Code: [Select]

./test_bkl on 105
Poof the display popped back on! Of course on reboot it turned back off again. So after temporarily re-enabling the backlight, I went back into Utility -> System Status -> Startup and set it to Default, power cycled and boom, back in business no worries.   

Nice that you discovered that it was related to backlight
I also had the same problem but I solved it with the def.hsf file. I should have posted it before but It went out of my mind. I will try again this evening to see exactly how I did.

Code: [Select]

./test_bkl on 105Well I guess there are still a few bugs in the firmware     Please note that you can run into this bug REGARDLESS OF WHETHER YOU CRACK THIS FUNCTION GENERATOR OPEN OR NOT, and it has nothing to do with modifying the HDG2002. Except that if you don't crack it open after you do this, you seemingly have no way to recover.   

I think we should investigate on how the firmware update process is working (like Tinhead did for DSO5000) so that we can have a way of backing up/restoring files... doing things from the front USB jack or SD slot without opening the enclosure.
Of course in that case it would be difficult to restore things easily that way but for this one, we could at least describe the blind "key push "sequence to follow in order to restore settings (I think we can do it without turning the knob, just with simple keys).

Ok, I tried again to modify the setup so that it restart with the last settings. On reboot you have indeed a beautifull but useless black screen. Then just push the "Default" key. This will restore (but not save) the settings so that the screen will appear again. Than you can change the option in the utility so that it starts on power on with default settings.
I will put a warning on the first page.

[idpromnut]

Ok, I tried again to modify the setup so that it restart with the last settings. On reboot you have indeed a beautifull but useless black screen. Then just push the "Default" key. This will restore (but not save) the settings so that the screen will appear again. Than you can change the option in the utility so that it starts on power on with default settings.
I will put a warning on the first page.

  Glad there's a work around for that!

[Control:Eng]

Hmm...looking at the spectrum...Hantek's design really seems to be imperfect.

This is what the AD9747 is capable of:

http://wiki.analog.com/_detail/resources/fpga/xilinx/interposer/cf_ad9747_ebz_spectrum_1.jpg?id=resources%3Afpga%3Axilinx%3Ainterposer%3Aad9747

Could somebody maybe explain why we get these spurious spectrums?

two things: on the AD board the SMA is connected directly (except transformer) to DDS, so the spectrum will be worse than on Hantek. And of course when you check what setting they used on SA "span 115MHz/RBW 20kHz" then no wonder that there is nothing visible. There is as well clock aspect, AD is using 250MHz clock on that picture, comming directly from "external source", and you can bet they used good and clean source. With good jitter"free" clock the noise floor is for sure better (and less spurious, but whatever there is, it is not visible due the SA settings).

Hantek is using (variable?) clock coming from FPGA (LVDS AC coupled via C191/C187, with DC offset R150/R151). Everything out of FPGA have lot of jitter (minimum 100ps from internal logic pk-pk + pin driver jitter). Such "phase modulated" clock is creating all that spurious and phase noise degradations as shown here:



Of course is Hantek using good clock source for FPGA (a bad source would add additional jitter, overloaded external source as well), and some filtering after all, but one will not get better results when clocking with FPGA (they doing this probably to run variable clocks, however if not then one could add clock jitter attenuator from e.g. Silabs to get rid of that jitter. But of course, that extra 20USD or so, one have not to forget that this is not highend AWG). Sure, everything can be done better, and it has been already done, but if one buy gear for nearly price of the compoenents then please don't expect wonder

Thank you for clearing things up, tinhead!

But now I got some further questions

What are the main design differences between, let's say an Agilent AWG 33522A (~3000 Dollars) and the HDG2002b (hacked to 30MHz for example).

To me, the specs are quite the same. Same sample rate, BW, resolution...is it all about the HW-Design?

Is Agilent using other DAC's in their AWG's? Do they have better filters? If I'm right, we get a sin(x)/x attenuation because of the sampling process (correct?). Is there a chance to use an output filter that reconstructs this distortion?

I believe that the AD9747 should be quite a performant DAC if used correctly?

I don't mind spending some bucks to modify the Hardware of the HDG2002b if the chances are that these efforts could take the HDG to the next performance level.

[fremen67]

Regarding simple hardware modification, what would you think of an OCXO mod with a Micro Crystal OCXOVT-BV5?

Frequency : 10 MHz
Power Supply : 5V +/-0.2V
Current Consumption : 80 mA max @+30C / 120mA max @-20C
Output Level : HC-MOS Compatible
Stability vs Temp : +/- 0.15 ppm (-20C to +70C)
Stability vs Supply : +/- 0.1 ppm (@5V +/-0.2V)
Stability vs Load : +/- 0.01ppm ( @ load +/- 10%)
Frequency Tolerance : +/- 0.15 ppm max
Control Voltage : +0.5V to +5V DC
Frequency Control Range : +/- 4ppm
Aging : +/-0.7 ppm max / 1st year
Short Term Stability : < 5 E-10 (0.1 s to 30 s) Typical 5 E-11 @ 1 s
Phase Noise :
     10 Hz: -100 dBc / Hz
      100 Hz: -130 dBc / Hz
      1 KHz: -140 dBc / Hz
      10 KHz: -145 dBc / Hz

[idpromnut]

@fremen67: Given what tinhead was saying about how the clock is being provided via the FPGA, I doubt a better reference XO will make any difference. In fact the external clock when clocked form a reasonably clean and jitter free source (and I tried three, a Rb and two OCXOs and assuming that the HDG is not mangling this signal too much) had no appreciable difference on quality of the output (if anything it was worse!).

[fremen67]

@fremen67: Given what tinhead was saying about how the clock is being provided via the FPGA, I doubt a better reference XO will make any difference. In fact the external clock when clocked form a reasonably clean and jitter free source (and I tried three, a Rb and two OCXOs and assuming that the HDG is not mangling this signal too much) had no appreciable difference on quality of the output (if anything it was worse!).

OK. It was just because an OCXO option is announced on their website and there is room on the board for that. Of course if the design won't allow any benefit of it, it is useless.

Btw did you test the high frequency counter input on your HDG?

[idpromnut]

@fremen67: Given what tinhead was saying about how the clock is being provided via the FPGA, I doubt a better reference XO will make any difference. In fact the external clock when clocked form a reasonably clean and jitter free source (and I tried three, a Rb and two OCXOs and assuming that the HDG is not mangling this signal too much) had no appreciable difference on quality of the output (if anything it was worse!).

OK. It was just because an OCXO option is announced on their website and there is room on the board for that. Of course if the design won't allow any benefit of it, it is useless.

Btw did you test the high frequency counter input on your HDG?

Not yet; I want to wait for all the ethernet parts + BNC for the HF counter to take the board out once and perform the modifications, rather than pull it out multiple times and strip the case screws (the screws into plastic).

[tinhead]

>> AWG 33522A ?

i can't compare only based on paper specs because from papaer specs, as you said, they equal.

>> I believe that the AD9747 should be quite a performant DAC if used correctly?

it is 16bit DAC, so it will be good at least for (without reading any datasheet) for 12-14bit. The noise floor on Hantek didn't looks like 12-14bit (how it looks with 14bit gear, one can see on RFasic pictures) but as 10bit. Sure, that pictures taken on modified device (this is why i was hoping to see pictures of what Hantek can do when set to within its specs, and when set to what it was calibrated for).

>> Regarding simple hardware modification, what would you think of an OCXO mod with a Micro Crystal OCXOVT-BV5?

in principle it does matter what clock source has been used for FPGA (better source=better clock output, but still, the xxx ps jitter created by switching logic and/or PLL within FPGA is added on top of that), an OCXO will for sure be better than current TCXO.
But the main reason for OCXO is frequency stability, not noise floor/jitter. Sure, when one replace ordinary XO with an OCXO (and probably do the necessary calibration!) the improved signal quality will be directly visible even on an DSO. But here is already an (VC?)TCXO installed, so the only improvement will be in the frequency stability.

>> I don't mind spending some bucks to modify the Hardware of the HDG2002b

I can't give any recomendation for changes without the actuall hardware. I would not run and buy parts, except they
are obvious or cheap (when known what TCXO has been used one can select better OCXO, they can costs lot of money. Or these
parts for counter, they costs "cents", so not a big deal).

What I would do is to:
- check first if the clock is really generated by FPGA (from pictures it looks like it is), if not, think wtf wrong here?
- measure (and at least check) how the DAC clock looks like
- is it variable?
- what is the rise time of the dac clock
- make reference spectrum snapshots of signal within and above AWG specs, with modified and unmodified device
- as above, but wit external clock connected to DAC directly (caps to be removed first, watch the DAC clkin level specs!)
- do measurments and spectrum snapshots before and after the output amp/filter/attn/what so ever there
  (it might be interessting to see if there is any distortion coming from that part of the circuit)
- check the power rails. Hantek is chinese company, and these AWGs didn't costs enought to follow every design rule
  (chinese eng. are very creative! but when design is price driven they tend to be too creative), so for sure here and
  there are not enought caps, maybe better filtering, etc. But i would not just buy huge low ESR caps,
  this is the wrong/useless step. They only good when needed and not everywhere.
- check if display have any influence on signal quality, simply remove the FPC cable from the connector on board while
  measuring spectrum and look for changes.
- i would for sure check what's wrong with the ext clock input (level too high/low?, rise time to "sharp"?, overshoot?,
  how is when AC-coupled?, etc.)
- ...

[FrankenPC]

Can someone help me out with locating the proper header for the serial connector?  I want to avoid soldering the pins if I can.  If you can tell me what pin pitch to look for, I can find it at Digikey, or similar place.

[fremen67]

Can someone help me out with locating the proper header for the serial connector?  I want to avoid soldering the pins if I can.  If you can tell me what pin pitch to look for, I can find it at Digikey, or similar place.

J801 (5 holes) next to the back USB jack. A 4 pin header was already soldered on mine (2mm pitch).
Starting from the USB jack side and not counting the first hole you don't need, you have RX, TX, GND and 3.3V
Be careful, it's not RS-232. You need a USB To TTL interface.

[FrankenPC]

Can someone help me out with locating the proper header for the serial connector?  I want to avoid soldering the pins if I can.  If you can tell me what pin pitch to look for, I can find it at Digikey, or similar place.

J801 (5 holes) next to the back USB jack. A 4 pin header was already soldered on mine (2mm pitch).
Starting from the USB jack side and not counting the first hole you don't need, you have RX, TX, GND and 3.3V
Be careful, it's not RS-232. You need a USB To TTL interface.

Thanks!  So, my "FTDI friend" from Adafruit which has a 3V option should be perfect then?

[fremen67]

Can someone help me out with locating the proper header for the serial connector?  I want to avoid soldering the pins if I can.  If you can tell me what pin pitch to look for, I can find it at Digikey, or similar place.

J801 (5 holes) next to the back USB jack. A 4 pin header was already soldered on mine (2mm pitch).
Starting from the USB jack side and not counting the first hole you don't need, you have RX, TX, GND and 3.3V
Be careful, it's not RS-232. You need a USB To TTL interface.

Thanks!  So, my "FTDI friend" from Adafruit which has a 3V option should be perfect then?

It should, with just GND, RX and TX connected

[FrankenPC]

Can someone help me out with locating the proper header for the serial connector?  I want to avoid soldering the pins if I can.  If you can tell me what pin pitch to look for, I can find it at Digikey, or similar place.

J801 (5 holes) next to the back USB jack. A 4 pin header was already soldered on mine (2mm pitch).
Starting from the USB jack side and not counting the first hole you don't need, you have RX, TX, GND and 3.3V
Be careful, it's not RS-232. You need a USB To TTL interface.

Thanks!  So, my "FTDI friend" from Adafruit which has a 3V option should be perfect then?

It should, with just GND, RX and TX connected

Well...that was easy   I backed up the system.inf just in case.  Not really anything to that mod is there?

[FrankenPC]

Have any of you seen this error message as soon as the HDG2002 starts booting (before the kernel is uncompressed, etc):

*** Warning - bad CRC or NAND, using default environment

As a side effect, I don't think I can save any of my settings (the key beep for instance turns back on after a power cycle).

Yeah, I have this error as well.

Did  you figure out what's causing it?

[leppie]

Yeah, I have this error as well.

Did  you figure out what's causing it?

Just read a page back for the solution

It is caused by a presumably missing last config.

[Terry]

Does it have the Trueform technology like Agilent 33500B
http://www.agilent.com/about/newsroom/tmnews/background/33500B/?

[idpromnut]

Yeah, I have this error as well.

Did  you figure out what's causing it?

Just read a page back for the solution

It is caused by a presumably missing last config.

Actually no, this error i still have (and still had) when everything is working correctly. I thought originally that I might have a bad flash chip but I don't think that is the case anymore.

[fremen67]

There is something strange I forgot to mention regarding the power supply.

As you see on the first page pictures, there are two power supply connectors on the board, one on each extremity. On my HDG there is only one cable coming from the power supply connected to the board (to the DAC part). The other cable providing +5V for the S3c2416 part is not connected but tied to the other cable (so it is like this on purpose and not just only disconnected).
One half of the power supply is almost useless, except that it also provides 12v for the fan... quiet expensive for a fan supply. The S3c2416 part of the board is powered throught the bridge in the middle of the board... It does not look that clean.

Would it mean that Hantek run into design problems and did that as a workaround? What do you think?
Could you also check that on yours?

[idpromnut]

Same for mine, but I assumed that this was due to reuse of the same supply for both the DSO and function gen (and perhaps the MSO as well).

[fremen67]

Same for mine, but I assumed that this was due to reuse of the same supply for both the DSO and function gen (and perhaps the MSO as well).

No they have completely different designs. This one has to supply +V and -V for AWG functions. They are the same on both DSO and MSO but only supply 3.3V, 5V and 12V (if i remember well)

Plus the pinout of the "unused" cable connector fits the one on the board (GND,GND,5V,5V). This connector is not the same on a MSO/DSO (6 pins).

[fremen67]

Have any of you seen this error message as soon as the HDG2002 starts booting (before the kernel is uncompressed, etc):

*** Warning - bad CRC or NAND, using default environment

As a side effect, I don't think I can save any of my settings (the key beep for instance turns back on after a power cycle).

Yeah, I have this error as well.

Did  you figure out what's causing it?

Don't worry about that.
When starting your HDG, u-boot, the program which loads the system, can't find any valid environment already stored in the NAND memory and so just loads the default one. It's not a problem even if it does not look "clean".
If you really want to get rid of this message, just reboot and stop the boot process with the space key. You will see the u-boot menu. Select "0"  (set the boot) and "s" (Save the parameters to Nand Flash) which will, as you can figure it out ... save the default parameters to the NAND. Then q (Return main Menu) and r (Reboot u-boot).
If you don't feel like it, just ignore it 

It has nothing to do with the parameters in the utility menu not being saved, which is indeed a bug.

[tinhead]

attached some files one might need to play with NAND:
- s3c2416 SoC configs for openjtag (gui or openocd) and h-jtag/h-flasher (hfc file)
- dnw.exe for s3c2416
- windows device driver for HDG uboot.

Note1: afaik while in uboot menu, the USB client port is not active until you chose an function which need USB client port enabled. That means you have to chose an "less dangerous" function from menu while doing it first time, this is necessary to give windows enought time to install drivers. When you at that time select something more tricky, like upload new root fs, you can be sure that uboot will wipe out your NAND befor windows ended the driver installation, so be carefull!

Note2: even if i do have OpenJTAG or and other FTDI based JTAG adapters, but i never using them. This is because i do have H-JTAG USB, so please don't ask me how to use openocd etc.