New Hantek DSO2X1X models?

[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!

[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?

I'll answer my own question ;-)

I bought one of each of these. One for the Hantek and one for the AWG.
Works perfectly on both devices.
I can't subjectively notice any speed penalty with SCPI (Attached image shows downloaded wave data).
A little bit of isolation is always a good thing. 

[vistorik]

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!

David. This is not an End! Now there is an error without *.md5 file.

[DavidAlfa]

Opps true. Should be fixed in v0.36, try it out.
I really don't have time to read/flash the scope every time, in fact it's been taking dust for weeks!

[vistorik]

Opps true. Should be fixed in v0.36, try it out.
I really don't have time to read/flash the scope every time, in fact it's been taking dust for weeks!

Now it writes without problems both without and with *.md5. End?

[DavidAlfa]

Should be.

[phmarek]

I can't subjectively notice any speed penalty with SCPI (Attached image shows downloaded wave data).

Well, did you ever try getting a 2 channel 4Msamples dump?
As SCPI runs in ~4kB blocks it's about 2000 round trips - you might see a measurable difference then.

(And that download speed is why I started my patch, see https://github.com/phmarek/hantek-dso2000-quick-fetch.)

[Aldo22]

Well, did you ever try getting a 2 channel 4Msamples dump?
As SCPI runs in ~4kB blocks it's about 2000 round trips - you might see a measurable difference then.

Yes, thank you, you're certainly right.
Like the official Hantek Windows software, I only download 4kpt data to get a somewhat up-to-date image.
Everything else is too slow anyway, with or without the USB-Isolator.

I'm interested in remote control of the device because I prefer to enter values with the keyboard and mouse rather than turning dubious rotary encoders.
I need the image to set triggers, positions and cursors.
It doesn't have to be particularly detailed (deep memory).

Btw. since the update 2024.02.02_fpga_3208 I haven't had a single crash and I use it several times a day.
It's really stable now.

[Aldo22]

I am answering my own question (again  ).

Apparently there is a big difference with the RF frequency response depending on "which side" of the relay you are on (200mV/div vs. 500mV/div)
I made the measurement above with 200mV/div, this new one below with 500mV/div.
At 500mV/div the frequency response is within 3dB up to 150Mhz.

I didn't find the phenomenon mentioned here, but it is discussed on 4pda.

So with 200mV/div the amplitudes are usable up to about 60/70MHz afaics.

Of course, this is not a reliable measurement, I don't have the tools for that. But as an impression it will probably be correct.

[DavidAlfa]

The bandwidth is normally specificied for a -3dB amplitude range.

[Aldo22]

The bandwidth is normally specificied for a -3dB amplitude range.

Yes, maybe the topic is a bit fragmented now.
I originally measured an amplitude increase of +10dB from 1MHz to 150MHz at 200mV/div. That had puzzled me. It is not very good and there are comments on this problem on 4pda.



At 500mV/div and above the frequency response looks good up to 150MHz (see new measurement one message above yours), i.e. within (-)3dB (Externally amplified signal).

[artmau]

Hello,
Today I've opened package with my new DSO2C10 from Aliexpress.  The oscilloscope looked undamaged. I turned it on without problems, went through physical button check and successfully made calibration procedure. Then turn off the oscilloscope. After turning it on again the display and all keys are frozen and there are no waveforms. It went completely frozen before I had chance for any backup. The Firmware version was 3205.

I tried recovering with Platform tools, but sadly  I get following error:
"
Erasing 'boot'                                     FAILED (remote: 'invalid NAND device')
fastboot: error: Command failed

Failed to erase the memory!
"

Please help!

[DavidAlfa]

If still booting, try hitting Default Setup several times.
You can also try performing factory reset through a SCPI command.

But this seems a memory failure, claim to the seller.
If you have the knowledge, you can resolder or replace the w25n01gv spi nand.

[artmau]

hitting Default Setup doesn't help.
factory reset through a SCPI doesn't help.

I made a claim to the seller, let's see how it goes.

I was able to use successfully use DSOFLASH tool (problem remains). Does it mean that nand itself is ok?
Maybe I should test previous version of platform tools with "cmds.bat"? Is there is any difference vs unified version with restore.bat?

[artmau]

I looked through a vent hole and apparently i have a some Gigadevice  spi nand chip, not Winbond! what now?

[DavidAlfa]

That's not a problem!
But you might need a specific platform tools. Send a mail to Hantek?

[artmau]

The NAND is GD5F1GQ5UEYIG. Email sent. TY!

[vistorik]

The NAND is GD5F1GQ5UEYIG. Email sent. TY!

artmau, I could try to solve your problem if you'll send me the backup.bin file that you've got with the dsoflash.

[artmau]

Here is the link to the file: https://filetransfer.io/data-package/to1hUCnm#link

I've tried comparing my dump file with the "default(original).bin" from dso2c10 (dated May 25 2021?) on my own but there are a lot of large and small differences... I cannot tell specific reason for the lockup. I do not want to copy/paste fragments randomly. Maybe restoring whole original dump with dsoflash is an idea?

[vistorik]

Here is the link to the file: https://filetransfer.io/data-package/to1hUCnm#link

I've tried comparing my dump file with the "default(original).bin" from dso2c10 (dated May 25 2021?) on my own but there are a lot of large and small differences... I cannot tell specific reason for the lockup. I do not want to copy/paste fragments randomly. Maybe restoring whole original dump with dsoflash is an idea?

The dump obtained on a W25N01GVZEIG chip will not work on a GD5F1GQ5UEYIG chip. So you need a new platform-tools that works with the GD5F1GQ5UEYIG. After using platform-tools you need to restore the system.inf and the dds_calbration.dat files. These files could be obtained from your dump. I've downloaded the backup.bin file and suppose to test this file with my device with a GD5F1GQ5UEYIG chip connected to the device.

[vistorik]

Here is the link to the file: https://filetransfer.io/data-package/to1hUCnm#link

artmau, I flashed your dump to my GD5F1GQ5UEYIG chip using dsoflash v.36. The device started normally, nothing freezes, everything works. But your device information is not in the dump. Your dump looks like after using a platform-tools. The system.inf file is not difficult to make if you know the serial number of your device. I extracted the information for the calibration file from your dump and can make a upk-file to restore the system.inf file (need the serial number of your device) and calibration file - this is not a problem. Have you tried turning on the device after using platform-tools?

[artmau]

Yes, the scope is still locked up (boots up, but at the end of sequence there the relays do not switch, no waveforms, the keybord is unresponsive, and the all keys are lit). But I used only unified version the Platform Tools (are there some tools missing?) for restoring and failed. I emailed Hantec for version working with GD5F1GQ5UEYIG, still waiting.  Btw. are the previous versions of PT still somewhere available?
It may not be apparent, but the serial number is on the bar code sticker on the back of the scope.
It seems, that the command "DDS:CAL:RESUlt" from SCPI codes list extracted by David gives back calibration data, in my case: 0.833235, 5.294509 (offset, amplitude). Is this correct?

Tomorrow morning I'll try to restore with dsoflash v.36 once more.

edit: the command should be "DDS:CAL:RESUlt?"

[vistorik]

Yes, the scope is still locked up (boots up, but at the end of sequence there the relays do not switch, no waveforms, the keybord is unresponsive, and the all keys are lit). But I used only unified version the Platform Tools (are there some tools missing?) for restoring and failed. I emailed Hantec for version working with GD5F1GQ5UEYIG, still waiting.  Btw. are the previous versions of PT still somewhere available?
It may not be apparent, but the serial number is on the bar code sticker on the back of the scope.
It seems, that the command "DDS:CAL:RESUlt" from SCPI codes list extracted by David gives back calibration data, in my case: 0.833235, 5.294509 (offset, amplitude). Is this correct?

Tomorrow morning I'll try to restore with dsoflash v.36 once more.

If your scope is locked up with the same memory contents as mine while my scope is working normally, this can only mean a problem with the hardware, provided that you sent me the dump exactly corresponding to the contents of your scope's memory at the current moment when your scop is locked up.
Calibration data are correct.
You could aloso try to flash the dump from another scope with the GD5F1GQ5UEYIG memory chip (link: https://filetransfer.io/data-package/vemVQ7dA#link) using dsoflash v0.36. If your scope is still locked up with this dump then it looks like a hardware problem.

[artmau]

Ok, after using the dsoflash v.36 second time with my own dump the oscilloscope is alive! The only change that I can think of is that the first time I reflashed the dump was in state before using "PRIVate:FACTORY:RESET" command.
Using the "PRIVate:FACTORY:RESET" itself did not unlock the scope for me.

edit: At first all looked good, but after the third power cycle the scope got locked again. This time noumerous flashing with dsoflash v.36 with any available dump does not unlock the scope. Some hardware issue after all...
edit2: looks like the unlocking was just a fluke. There is no apparent hardware cause and for now i do not have any more ideas.
 to go deeper i would need to know the end of startup sequence. I'll disconnect power for 12 hours like yesterday and try tomorrow morning. Should I update firmware to 3208 if the scope somehow unlocks?
edit3: still no luck. clearly a hardware problem

[supphol]

Hello all,

first post here so be gentle. I just got the DSO2D15 and i have read the topic from the start.

The following question / idea came to my mind about the slagish UI.

I have seen development boards for the GW2AR-18-144 (that manages all LVDS connectivity) and the F1C200S and what hit me was that the GW2AR-18-144 boards used 50Mhz crystals while F1C200S all used 24Mhz.

Likewise in the datasheets the only option for the F1C200S is 24/25Mhz crystals, which i consider a limitation to the GW2AR-18-144 that seems to be able to work with at least double the reference frequency.

So my idea is, if it is possible to utilize  a frequency doubler(phase-locked loop if im correct) to feed the GW2AR-18-144 with 48Mhz from the same 24Mhz crystal (to keep phase between ICs) that feeds them both on the factory hantek implementation? Fun part is that R820 is perfect to interfere with the GW2AR-18-144 Clock path.

Do you think this will solve the slagish UI?