Minimum System Performance Specs?

[LameLefty]

Has anyone determined the minimum performance specifications for host computers to run OpenHantek? The reason I ask is, I have both ends of the performance spectrum covered but no data points for the middle. For instance, OH runs perfectly well on my Win10 gaming laptop (2016, i7 quad-core at 2.8 - 3.7 GHz, 16GB DDR4 memory, GTX1070 video), consuming 3 - 6% of a single CPU core. By contrast on a Pi Zero W is sucks up 100% of the anemic CPU and doesn't actually seem to collect and display data - heck, it can't even load up and display the full axis and grid properly.

I also tried to run the same microSD card in an RPi 3 but performance didn't seem much better. I don't know if I need to compile OH natively on the Pi 3 rather than just swapping cards, but I can't imagine performance would be really great anyway. I would love to be wrong on this - a tiny Pi-based lab-computer would be great for my workbench rather than a full-blown PC setup. Is the extra 200 MHz clock on a Pi 3B+ enough to make a useable setup?

[dendvz]

There are two major performance critical components: data acquisition over USB and data processing + display. Can you please check the USB performance of Pi boards with @jhoenicke 's example_linux_perf_test.py https://github.com/rpcope1/Hantek6022API ? If pure data acquisition (w/o processing and GUI) appears to be functional, we can put CPU cycle eaters on a diet by reducing display refresh rate.

[LameLefty]

Thank you for the reply - I will not have time to run any real tests until the weekend, but I will do so when able and report back.

[LameLefty]

So before closing this issue, or pursuing too much further, I was trolling through the closed issues and found #103 Compatibility with Raspberry Pi. It looks like others have had success with some specific OS settings and compilation options, so I've ordered a new microSD card and will follow the steps outlined in the issue discussion posts to see how it goes.

I am hesitant to close the issue entirely yet, as it would be useful to determine the bare minimum specs to run. For instance, I have a spare Raspberry Pi 2 sitting in a box right now. Will OH run on it? I have an RPi3 currently in use as my RetroPie rig that will in the coming months be replaced with a 3B+. Can OH run on the 3? Etc. Additional data points might prove useful to other users.

[LameLefty]

Okay, I have feedback for those looking to run OH on a Pi … On my RPi3, with a fresh install of the latest Raspian, I was able to use the instructions provided in the discussion of issue #103 with one modification: I had to comment out the troublesome line 4 in CMakeLists.txt [e.g.,"cmake_policy(SET CMP0072 NEW)"] After doing that, OH compiled without issue.

Now, with all both channels active at 1M/s sample rate measuring the scope calibration square wave, plus the math channel active, plus all three spectra displaying, CPU usage on the desktop meter topped out at about 54%. With just a single channel active and no spectra displaying, CPU usage was in the low/mid 30% range. There is no slowdown in the GUI response or mouse cursor, though with more channels and spectra displaying the apparent line-drawing rate for the spectra appeared a bit slower but still more than acceptable.

So all in all, a basic RPi3 will in fact handle OH just fine for my purposes. With a newer 3+, I imagine performance would be even better.

[LameLefty]

One more data point for people on a really tight budget: following all the instructions in issue #103 and in my post above (commenting out line 4 in CMakeLists.txt), OH will run on even a Raspberry Pi Zero W. The GUI is a bit slow to register mouse-clicks, and as you can see, the CPU usage is pegged, but it runs. It's not ideal, certainly, but it will work in a pinch.

Of course, all this goes out the window if the Qt3D stuff from the openhantek2 branch becomes a requirement but for the current branch, we now have a basic performance-floor: if it runs on a PiZeroW, it'll run on pretty much anything these days.

This is probably a good time to close this issue now that users have more data points.