New Hantek DSO2X1X models?

[Aldo22]

It's probably the RAM, happened to me too. I just leave it stock, OC only the CPU.
You'll get nothing out of that extra 5% OC else that lockups.

Thank you.
I had MEM_OC_PLL_N=15, now trying with 13

[Aldo22]

I wrote a little script to measure frequency response with the Hantek.
It's my first Python script longer than 3 lines, so...,  but maybe someone will find it useful. 

Requires pyvisa and gnuplot. I only tested it on Linux. It may also run on other systems with small adjustments.

You can choose between three (cheap) signal generators or add your own:
Hantek internal sg.
Feeltech fy3200: Two channels, phase measurement
Tinysa: Higher bandwidth.

The code is attached and there is a small README.md in the zip.
If anyone would like to try it and has any questions, please ask!
Attention, it is quite slow!
So don't choose too many points for initial tests.
But you can just let it run and don't have to worry about it.

EDIT: BUG FIXED
A new zip is attached.
I mixed up FFR (the time between the first falling edge of source 1 and the first rising edge of source 2) and FRR (the time between the first rising edge of source 1 and the first rising edge of source 2).
The bug was not immediately obvious. 

Pictures:

10db_att_internal.png
10dB Attenuator, internal SG

30M_30P_tinysa.png
30MHz LPF from RF Demo Kit with tinysa

6.5_internal.png
6.5MHz BSF from RF Demo Kit with tinysa

6.5m_40_feeltech4.png
6.5MHz BSF from RF Demo Kit with fy3200, second channel with phase. 40 points.

[Aldo22]

It's probably the RAM, happened to me too. I just leave it stock, OC only the CPU.
You'll get nothing out of that extra 5% OC else that lockups.

Yes, avoiding to overclock the RAM prevents occasional lockups after startup. 

[phmarek]

Hmmm, thanks, but doesn't help -- resp. the key default setup doesn't seem to work at all.

I removed the files from /data/setup (looked promising as last.pho was 0 bytes!) but that didn't help either.

Ah, thanks! /dso/etc/aslf/ is the directory with settings - moving that away and rebooting fixed the DSO!


Merci!

[Aldo22]

Ah, thanks! /dso/etc/aslf/ is the directory with settings - moving that away and rebooting fixed the DSO!

Interesting.
Can you explain what was going on?
What can go so wrong with "settings" that the keys no longer work, as you wrote?

[phmarek]

I have no idea -- DavidAlfa suggested it!

And it's not that no key worked -- a few of them did, once or twice.


My hunch would have been to look at the FPGA firmware, as that one's responsible for translating key presses to input events.

[Aldo22]

When I tested the script (above), I found that the frequency response with the tinysa from 1M to 150M was not very flat or linear. (-> picture, direct connection, dummy load, no DUT).
10dB gain over the frequency range.

Now I'm wondering if it's the Hantek, the tinysa, the cable or the script.
Unfortunately, I think the Hantek is the culprit, but I would prefer it to be for other reasons.
Does anyone know anything about it?

Can someone check this with a decent signal generator?
It doesn't have to be with the script, a few measurements would be enough (e.g. 1, 10, 50, 100, 150 MHz).
Perhaps someone has already tested this?

Thank you.

[Aldo22]

If I connect the oscilloscope to the PC via USB (SCPI), does it make sense to use an Adum3160 USB Isolator ?
Do the SCPI commands work with it?

E.g. https://www.eevblog.com/forum/reviews/chinese-usb-isolator-test/

Thank you!

[Russ3000]

New firmware released
https://4pda.to/forum/index.php?showtopic=1018961&view=findpost&p=128715169

[Aldo22]

New firmware released
https://4pda.to/forum/index.php?showtopic=1018961&view=findpost&p=128715169

Thanks!
But the link there does not work for me:

Ой! Ошибка 404.
Запрашиваемая информация не существует, перемещена или удалена.

Do you have to be a member and logged in?

[DavidAlfa]

Warning: This update forces the fpga fw update to a new version: FW3208.

I modded it to only apply the software update, preserving the existing fpga FW, so it doesn't cause issues on scopes with FW3000/3102.
Also made a new FW update package.

»  3208_B208

»  2024.02.02
»  2024.02.02_fpga_3208 -> Sets FW3208

[Aldo22]

Thank you for your efforts.
Are there any obvious show-stopper bugs, like the 4k-only bug mentioned in the other thread?
Are there any obvious improvements?
Is it a slower debug version, as someone on 4dpa noted?
Would you recommend updating now or should we wait for the official release from Hantek?

[phmarek]

Any idea what the changes are?

[Aleksandr]

Any idea what the changes are?

Fixed the mathematical division function, it didn't work before.

[DavidAlfa]

Meh, that's no sense, the binary size is almost identical to older versions, definitely not a debug build.
In fact it would be the best thing happening, if they ever make that error we could see the original function and variable names (Debug symbols), allowing much easier reverse engineering.

[Aldo22]

I have done the (full) update.
All I can say so far is that it is still running and has not crashed.

EDIT: Math Div seems to work now.

[Aldo22]

I have attached two measurements with the above script that might be (somewhat) interesting in general.

The measurements are made with the internal signal generator from 1MHz to 25MHz sine (50cm coax with 50Ω dummy load).

The first frequency response is without bandwidth limitation.
You can see in the footer that it is approx. -0.75dB at approx. 25MHz (x,y).

The second frequency response is with the internal 20Mhz bandwidth limitation.
You can see in the footer that the -3dB point is reached at approx. 22.5Mhz (x,y).

Please note: y2 and Phase are not relevant here.

[vistorik]

Hola DavidAlfa! Used the dsoflash v0.34, made a backup, renamed the backup files as "restore.bin" and "restore.md5", then run write.bat and got an error.

[DavidAlfa]

"File doesn't match t*he Flash size"
What the heck?
Try running it several times to see if It always fails in the same way?
Is your system 100% working, not overclocked or anything?
Never seen this!

[vistorik]

"File doesn't match t*he Flash size"
What the heck?
Try running it several times to see if It always fails in the same way?
Is your system 100% working, not overclocked or anything?
Never seen this!

3 times ran, the same result. "What the heck?"  This is the text from dsoflash v0.34 main.c:

Code: [Select]

else{
                printf("File doesn't match t*he flash size\r\n");
                printf(" Flash: %uBytes,   File: %uBytes\r\n", read_bytes, capacity);
                terminal_error();
         
"Is your system 100% working, not overclocked or anything?" nothing of these, windows 10, scope withour overclocking. Reading is OK. Without restore.md5 dsoflash writes the same restore.bin without problem.

[DavidAlfa]

Is your system 32 or 64bit?

[vistorik]

Is your system 32 or 64bit?

32 bit

[DavidAlfa]

Spotted the bug. Try the lastest v0.35.

[vistorik]

Spotted the bug. Try the lastest v0.35.

Now it works.

[DavidAlfa]

Great!

The "F*lash" thing was a plain, giant typo, but wasn't the bug.

When I added md5 check, I loaded the files in the wrong order.
Md5 file is 33 bytes, so the last loaded file size was that.
Of course it didn't match the flash size!

Now I wonder how I missed this. After trying 300 times, maybe I missed the last one!