Products > Test Equipment

New bench scope - Fnirsi 1014D, 7", 1GSa/s

<< < (46/67) > >>

pcprogrammer:
The sampling part of the 1013D code has been reverse engineered so far, to say with confidence there is no equivalent time sampling in there. They use some strange filtering technique on the sampled data to make it look good on the display causing it to be so slow that the display looks very stable.

The new firmware does no filtering and just displays the samples as is, directly after getting them from the FPGA memory. This makes it look a bit skittish, but it is much closer to the real signal. The moment you lower your sampling rate to below your signal frequency it will show aliasing in both versions of the firmware. I don't think you can reconstruct the original signal even when you process multiple sample buffers, unless maybe with doing a hell of a lot of processing on the data, and even then I'm not sure it will lead to anything good. But I'm no expert in the field.

Strange that you can't find much on the hantek scopes. There are at least four threads here on the forum.

https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/
https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/
https://www.eevblog.com/forum/testgear/hantek-dso2x1x-firmware-updates-and-best-use-practices/
https://www.eevblog.com/forum/testgear/hantek-dso2xxx-schematics/

The used ADC in it is assumed to be the ADC08D500 because it matches the pin out used on the board. It might well be a clone.

donwulff:
I think I need more X's in the search strings, though I did just add reference to it on my notes. To note though, https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/475/ last posts, review isn't glowing, and the cheap price link is 335 EUR with shipping for me.  :-DD 250 EUR:ish isn't bad for "utility scope" and it sounds like they haven't yet plugged the upgrade-hole (So that means the AWG BNC is always in place?), but doesn't quite make the <200 "gadget price" cut, and sounds like it runs the risk of not having everything enabled. Couldn't figure if the Linux build which doesn't need to be flashed in can do anything with the DSO part, but that's just a little bit of reverse engineering, right? It's interesting these are at a price point where I think shipping actually makes major part of the product price, and even labor/assembly despite it being China.

But ahem, 1014D thread, still kinda trying to focus on that ;) I'll definitely be keeping an eye on the Hantek one though.

pcprogrammer:

--- Quote from: donwulff on January 01, 2023, 09:25:44 pm ---(So that means the AWG BNC is always in place?)

--- End quote ---

Yes because it is also used for the external trigger input, so always there.

And yes it has plenty of bugs that makes it not the best.

Reverse engineering it, despite it running on linux is no small feat though. There was some talk about it, but not much happened since.

pcprogrammer:
I looked at the link you added to your notes about equivalent time sampling (https://www.tek.com/en/documents/application-note/real-time-versus-equivalent-time-sampling) which provides interesting information, but confirms my believe it can't be done with the 1013D or 1014D as is. You need to be able to set a specified delay on the trigger to get the shift in the samples needed to reconstruct the original signal. The trigger system in the FPGA does not cater for this.

It also states that the maximum bandwidth that can be measured with this technique is the analog bandwidth, which in these scopes is ~30MHz. This is also below the real time bandwidth of 80MHz (200MSa/s / 2.5), so no need for equivalent time sampling.

donwulff:
Anyway, sorry to distract from the arguments lol, but finally got around to testing loading the 1013D firmware (Remote Desktop Infrastructure maps the SD as a remote drive, and Cygwin can't even compile gparted, and I mostly have Windows at work, on lunch break lol). I partitioned a blank image on remote Linux machine, used Cygwin dd to install things (Of note: Writing 8 GB flash on 1014D took almost 4 hours, at 611kB/s, also needlessly used up flash endurance, don't do that). Turns out the Pecos firmware at least really needs FAT partition, so I built dosfstools on Cygwin and ./mkfs.fat -F32 -v /dev/sdb1

The screen seems to work without any changes, and I'm really digging the look in the Pecos firmware, although the knobs & buttons don't work of course so I can't actually do anything yet. Looks like I may have to figure out some other differences though, because it's showing about 10 volt 40 uS rounded sawtooth on both channels, but connecting anything to the probe channels changes nothing. But this is definitely a good spot to start from, as I can see the UI and, well, something is working haha. Of course, after partitioning & FAT32 format this is just smooth sailing as I can use just dd.

Unfortunately I can't yet switch the Pecos firmware to USB writing mode, and sunxi-fel seems to suffer from common libusb ailment of not being able to find a device whose parent is the Remote Desktop terminal-server host.

https://github.com/pecostm32/FNIRSI_1013D_Firmware/tree/main/fnirsi_1013d_scope/dist/Debug/GNU_ARM-Linux says "The other file fnirsi_1013d_scope.bin can be loaded to DRAM with sunxi-fel and the scope in FEL mode to do testing without writing to the SD card." so I think I need to figure out this sunxi-fel stuff & build environment next, and I'm not even getting through reading the thousands of messages on the threads, most of which are just people who wouldn't get the scope anyway bitching about it. How_to_load_scope.txt tells how to use "sunxi-fel" which might require writing https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/sunxi_stuff or https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Binaries/Hacked%20files/sunxi_stuff on SPI or SD. Though https://linux-sunxi.org/FEL has link to the sunxi-fel utility repository.

However, I grabbed https://github.com/linux-sunxi/sunxi-tools which in turn required building https://mirrors.edge.kernel.org/pub/software/utils/dtc/ which requires adding -Wno-error=char-subscripts to WARNINGS because I CBA to fix the coding violation, and PREFIX to /usr/ so the default build can find it.

At this point I might almost try to fix the libusb error, although I briefly tried earlier, or see if sunxi-fel can be easily changed to get around that issue.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod