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

[idpromnut]

I'm not sure if this is new, but I have just noticed that when modifying parameters for a wave (say square) such as the amplitude or offset via the keypad only, the FG does not actually change the output until I adjust the value with the jog wheel. Anyone else have this issue?

EDIT: if I modify the frequency in the same way, it is updated as soon as I press the correct unit on the keypad.

[Cyber7]

I've always had to press an Fx key to select the unit of measure after entering a value with the keypad, no matter the parameter. Testing after selecting a square wave output on chan1, I enter F1 for freq, enter 999, press F3 for khz. Then I enter F2 for amp, press 3.3, and press F1 for volts. The display changes both times after selecting the unit, and they output also changes at that moment, checked via scope.

I still find it strange that commands via USB or via the test_cmd utility do not update the front panel. It should be a simple matter for the devs to simulate the key presses at worst. It'd be interesting to spy on the d-bus messages and see what goes on there.

[alex.forencich]

I've always had to press an Fx key to select the unit of measure after entering a value with the keypad, no matter the parameter.

This is a very standard feature when there is a keypad - you have to push a unit key after entering the number.  If you just push 2, is that 2 Hz, 2 kHz, 2 MHz, or 2 GHz?  Or perhaps 2 mV, 2 uV, 2 V, 2 dBm, 2 dBV, 2 dBmV, or 2 dBuV?  All of the test equipment I have that has keypads actually has dedicated unit keys that you have to push to commit the value.  If there are no units for the value, then you generally just push the Hz key. 

[idpromnut]

@Cyber7: sorry, I wasn't clear; I select Duty Cycle, then on the keypad enter 10, then on the Fx keys select %. The display will then update but I will not see the output update with the new duty cycle value. If I then use the jog wheel to adjust the duty cycle, the output will snap to the display value and follow the display.

[Cyber7]

I do believe you've found a bug! If I do the same on a square wave, the duty cycle updates on the GUI, BUT fails to update the waveform output after pressing the the % key to commit the value. The same occurs with a Ramp waveform with the symmetry setting.

Amplitude and offset are not affected. I need to plugin both outputs to verify the phase setting.

Using Revs:

FW: 1.00.2
HW: 1004
FPGA: 12
KB: 3

[alex.forencich]

Mine crashed and rebooted itself while I was poking around in the settings pages.  Do you know if there is somewhere we should be reporting these sorts of bugs?  The hantek site does not even seem to have the firmware available for download, so where are we supposed to get the latest firmware, presuming they actually fix any of the issues?

[idpromnut]

Mine crashed and rebooted itself while I was poking around in the settings pages.  Do you know if there is somewhere we should be reporting these sorts of bugs?  The hantek site does not even seem to have the firmware available for download, so where are we supposed to get the latest firmware, presuming they actually fix any of the issues?

I suspect that there will probably not be any firmware updates... at least not in the foreseeable future.  I emailed Hantek about getting a firmware update several months ago and never got a reply.

[alex.forencich]

Mine crashed and rebooted itself while I was poking around in the settings pages.  Do you know if there is somewhere we should be reporting these sorts of bugs?  The hantek site does not even seem to have the firmware available for download, so where are we supposed to get the latest firmware, presuming they actually fix any of the issues?

I suspect that there will probably not be any firmware updates... at least not in the foreseeable future.  I emailed Hantek about getting a firmware update several months ago and never got a reply.

I'm beginning to think that picking one of these up may have been a waste of money due to shitty software.  Here are the issues that I have found so far:

- Crash and reboot in settings pages (can't remember exactly what I did, haven't tried to reproduce it either)
- Very annoying digit selection shift when using the wheel and a digit is added or removed (9 MHz with 9 selected, adjust up to 10 MHz, and the selection moves off of the 1 MHz place)
- Very laggy knob - if it can't process events fast enough, it should coalesce them and make a bigger step
- Very limited rate selection for arbitrary rate (no or very limited internal decimation, it seems)
- Poorly/undocumented commands for remote arbitrary waveform loading
- Very little documentation for digital output/no documented remote commands that I have seen so far

And probably more issues I have not seen yet.  This was all from playing around with it for a half an hour and reading over the manual. 

[idpromnut]

I'm beginning to think that picking one of these up may have been a waste of money due to shitty software.  Here are the issues that I have found so far:

Yeah, when I picked this unit up, I sort of figured it would be more of a what you get is all you get kinda thing. It basically works so I'm not going to complain too much. I might get rid of it and pick up a better unit (Rigol or something else) if I need it, but really, for me as a hobbyist, I can't spend the kind of money that a better unit would set me back.

[alex.forencich]

I'm beginning to think that picking one of these up may have been a waste of money due to shitty software.  Here are the issues that I have found so far:

Yeah, when I picked this unit up, I sort of figured it would be more of a what you get is all you get kinda thing. It basically works so I'm not going to complain too much. I might get rid of it and pick up a better unit (Rigol or something else) if I need it, but really, for me as a hobbyist, I can't spend the kind of money that a better unit would set me back.

I mainly wanted one for the large sample memory.  I have a Tek AWG2021 that also does 250 MSa/sec, but the memory depth is very limited.  I was just hoping that the Hantek device could be useful enough as a standalone unit. 

I wonder if there is anything to be said for building open source firmware for it?  I can write the FPGA code if there are people who would be interesting in working on the user interface. 

[idpromnut]

It would be an interesting project; I have very little experience with reverse engineering these types of devices, but I do have a *bit* of linux experience. I might be able to help out. I'm guessing they are using a custom graphical UI and not some variant of X.

[idpromnut]

Of course I say this and what's the first thing I say to myself? "Hmm, I wonder where I would start if I were to try and figure out how to re-write this thing..."

I fired up the console and the first thing I noted is that I think the base Linux distro is actually a variant of Google's Android OS.  Interesting.   We might should create a new thread for this?

[alex.forencich]

Of course I say this and what's the first thing I say to myself? "Hmm, I wonder where I would start if I were to try and figure out how to re-write this thing..."

I fired up the console and the first thing I noted is that I think the base Linux distro is actually a variant of Google's Android OS.  Interesting.   We might should create a new thread for this?

Well, that probably explains the shitty performance.  This is the chip: http://www.samsung.com/global/business/semiconductor/product/application/detail?iaId=836&productId=7116 .  Looks like a relatively standard ARM 9 based SoC.  I wonder if we could get a reference design from Samsung that at least covers the software. 

If we do reimplement this, we either do it right or we don't do it at all.  Basically, I'm thinking I can figure out the FPGA and the front end and write a new FPGA configuration so long as there is somebody else to figure out the OS on the ARM chip.  I have some tools to reverse engineer FPGA interconnections, though I may need a board that I can yank some of the BGAs off of (namely the memory chips). 

[idpromnut]

Yup, that's the same conclusion I came to from /proc/cpuinfo and a bit of digging. There seems to be perhaps an Android build for this SoC. I am looking into that now, and to see if it will be easy to rebuild an Android  firmware image that I could try and get working on my unit. Got to back up my firmware again before trying that though.

[alex.forencich]

Yup, that's the same conclusion I came to from /proc/cpuinfo and a bit of digging. There seems to be perhaps an Android build for this SoC. I am looking into that now, and to see if it will be easy to rebuild an Android  firmware image that I could try and get working on my unit. Got to back up my firmware again before trying that though.

Sounds like a plan.  I am taking a look at the front end and FPGA connections.  Looks like the connection between the FPGA and the ARM chip is only 8 wires, likely 4 one way and 4 the other way so they can use digital isolators.  I presume it connects to one of the SPI ports on the ARM chip.  On the FPGA side it most likely connects to the config pins, which would be recycled for communications.  The FPGA is a Xilinx Spartan 6 LX16 CSG 324.  Not sure about the speed grade. 

Also, there is what appears to be a 9-bit R2R DAC with two-stage LC filter connected to the FPGA.  No idea what this is intended for, though. 

The front-end relays are controlled by two 74HC595 shift registers, connected in series.  That still leaves 4 outputs on each '595 unaccounted for, though. 

[idpromnut]

Something like this might be handy to "not-brick" the HDG2002 initially (at least for me): http://www.wayengineer.com/index.php?main_page=product_info&products_id=3066#.VExWQucSVUV

[alex.forencich]

Internal voltages that cross the isolation are 5, 1.8, and 3.3.  On the footprint marked P11, the voltages are +3V3, GND, +1V8, GND, +5, GND. 

FPGA JTAG pinout is not Xilinx standard.  From the marked end of the connector, pinout is +3V3, TCK, TDI, TDO, TMS, GND.  I got it to show up in Impact correctly as an xc6slx16. 

[alex.forencich]

Something like this might be handy to "not-brick" the HDG2002 initially (at least for me): http://www.wayengineer.com/index.php?main_page=product_info&products_id=3066#.VExWQucSVUV

That looks like an excellent solution.  It even has the same Ethernet chip.  Only $100 including the screen?  Not bad at all.  I would be more interested in the software package that comes with it.  A crappy reference design is better than no reference design at all. 

I can do all of my debugging by disconnecting the FPGA from the controller.  That isolation is very handy!  Just pop off two resistor arrays and we're good to go. 

Maybe we should go ahead and fire up another thread.  And perhaps consider setting up a github repo. 

[idpromnut]

Where should that new thread go, in testgear or projects?

[alex.forencich]

Ha, I figured out what the R2R DAC is for.  It drives the SYNC out.  So it would be possible to turn that into a 3rd output.  However, it would not be as capable as the two main outputs. 

[alex.forencich]

Where should that new thread go, in testgear or projects?

Dunno.  Not sure which one would make more sense. 

[idpromnut]

I'll create one in testgear for the moment, since the bulk of the immediate work would be to figure out how to build a new firmware base for the unit. It can always be forked into different threads at that point depending if other people want to build on that base image to do different firmwares.

[flatlander]

Did some testing on my 'upgraded' Hantek HDG2002B and found that the amplitude of the generated signal (sine) quickly drops off past 5MHz. It seems that my unit's firmware is still limiting the bandwidth to 5Mhz even though it lets me increase the frequency to 100Mhz. I tried loading older FPGA firmware but that doesn't work at all (no output and all output related self tests fail). Possibly have to flash a 'matching' set of software and FPGA versions. I'd be interested to know if the amplitude issue also exists on earlier software/hardware versions.

Versions:

Software: 1.00.2 (140926.0)
Kernel: Linux 3.2.35
FPGA: 20
Keyboard: 3
PCB: 1004

PS: alex.forencich and idpromnut thanks for kicking off an open source initiative for this generator. I'll help where I can.

[alex.forencich]

Did some testing on my 'upgraded' Hantek HDG2002B and found that the amplitude of the generated signal (sine) quickly drops off past 5MHz. It seems that my unit's firmware is still limiting the bandwidth to 5Mhz even though it lets me increase the frequency to 100Mhz. I tried loading older FPGA firmware but that doesn't work at all (no output and all output related self tests fail). Possibly have to flash a 'matching' set of software and FPGA versions. I'd be interested to know if the amplitude issue also exists on earlier software/hardware versions.

Versions:

Software: 1.00.2 (140926.0)
Kernel: Linux 3.2.35
FPGA: 20
Keyboard: 3
PCB: 1004

PS: alex.forencich and idpromnut thanks for kicking off an open source initiative for this generator. I'll help where I can.

I think there is a filter in the output stage that you need to bypass in order to get full bandwidth.  There are details here somewhere...

[alex.forencich]

Reverse engineering thread is here: https://www.eevblog.com/forum/testgear/hdg2002b-awg-firmware-reverse-engineering/

I have managed to back out most of the pins going to the FPGA and create a partial UCF file.  The only ones left (that I can tell anyway) are the DDR2 SDRAM pins.  I have not figured out how I am going to probe those quite yet; it's not so easy to probe under a BGA.