Closed Leonleon33 closed 2 years ago
@Leonleon33 Thx for reporting and especially providing the videos. I tried to reproduce with identical settings including LANG=fr_FR.UTF-8
with no success. But it looks like the up/down jitter is caused by the changing measurement text display in top or bottom line. You could try to enlarge the program window's height a bit and see if this solves the issue. I will investigate further, also with different LANG settings - maybe the diacritics accents like acute and grave (é, è, ê) disturb the text height, so that the text grabs sometimes more and sometimes less space and squeezes the scope frame.
EDIT: Please provide your system setup, probably KDE Linux, Fusion style. What does the program say when started from command line? E.g. the output from mine...
OpenHantek6022 (20220406 - commit 986)
Graphic: 2.1 Mesa 20.3.5 - GLSL version 1.20
Did you change the system font settings?
Thank you for the reply. System Ubuntu 20.04 XFCE on ASUS X751LX laptop I do not use Fusion style Command line startup: OpenHantek6022 (20220408 - commit 995) Graphic: 4.6.0 NVIDIA 510.54 - GLSL version 1.20
Further investigation: The jitter appears only if I check MATH trace with CH1+CH2 or CH1-CH2 or CH2-CH1 not with other MATH functions not without MATH trace
enlarging the program window's height do not solve fusion style do not solve system font default to DejaVu sans condensed 10 fixed font Monospace regular 10
Thank you for the reply. System Ubuntu 20.04 XFCE on ASUS X751LX laptop I do not use Fusion style
Do not seam to be related to graphic card mode (optimus) jitter in both case Command line startup: (graphic set to NVIDIA performance mode) OpenHantek6022 (20220408 - commit 995) Graphic: 4.6.0 NVIDIA 510.54 - GLSL version 1.20 Command line startup: (with graphic set to INTEL power saving mode) OpenHantek6022 (20220408 - commit 995) Graphic: 4.6 (Compatibility Profile) Mesa 21.2.6 - GLSL version 1.20
Further investigation: The jitter appears only if I check MATH trace with CH1+CH2 or CH1-CH2 or CH2-CH1 not with other MATH functions not without MATH trace
enlarging the program window's height do not solve fusion style do not solve system font default to DejaVu sans condensed 10 fixed font Monospace regular 10
I do not use Fusion style
Your video shows Fusion: while this is the standard KDE Breeze style. I understand that you use Breeze as global style, but OpenHantek has the possibility to use Fusion, because this allows a less taller window (~700 pixel) that fits perfectly on older Laptops with the small HD resolution 1280x720, selectable in the Colors setting dialog:
I'll do a test with the fonts setting like your setting, therefore I need to restart KDE - stay tuned...
EDIT: Changed the font and restarted to be on the safe side - no jitter. This is in sync with your finding about the different graphic settings "OpenGL 4.6" vs. "OpenGL 3.0". Linux uses out of the box a relative old OpenGL version, while the NVidia SW (you use the NVidia graphic driver?) is more up to date.
Further investigations: I tried with another ASUS laptop X751LJ that has different graphic card => no jitter ! System Ubuntu 20.04 XFCE ; same settings (clone) Command line startup: OpenHantek6022 (20220408 - commit 995) Graphic: 3.0 Mesa 21.2.6 - GLSL version 1.20
So it could be that the jitter is linked to "Graphic: 4.6" ; no jitter with "Graphic: 3.0"
I made 2 slow motion zoomed videos to view the problem in more detail with the "Graphic: 4.6" LC_ALL=fr_FR.UTF8 : Jitter when the text changes from "1 000 mV=" to "1,00 V=" on the 2 last lines LC_ALL=C : It changes from "1,000 mV=" to "1.00 V=" without jitter
fr_FR.UTF8_slowmotion.mp4 https://mega.nz/file/rd1UESbT#ae8-RXXWCXdhlCAGVd78b0hyha-_Tz7XPlyNkyrD3rs LC_ALL=C_slowmotion.mp4 https://mega.nz/file/uYt0UYbQ#HAH69StlluBr3uG7i4qzy3UhUMqOchEZH-meEBOf5Rk
Both Laptop resolution 1600x900 Fusion is not checked I tried by checking Fusion in Color settings => no change
Did you try OpenHantek --useGLSL150
to use the more recent graphic command set?
Another option is to use OpenHantek --useGLES
to fall back to a more simple graphic command set.
Do you also have real HW or are you trying out the SW to check if it will work for you?
In this case my short review:
The Hantek scope is usable if you want to measure repeating signals in the extended audio range 1Hz..1MHz, maybe also up tp 4 MHz. It is weak when it comes to catch seldom events due to the triggering completely in SW. Also the missing AC coupling can be an issue, you should either use a simple capacitor in series with the probe or implement th AC mod. Also the frequency generation for the calibration out jitters at high frequencies, because the signal is created by SW in an interrupt routine, but there's also a simple HW mod available. Just look into the Help
menu.
I use Nvidia driver with prime-select to change nvidia/intel graphic card I tried with nouveau... without success on this issue
I will definitely use the X751LJ laptop with "3D controller: NVIDIA Corporation GK208BM [GeForce 920M] (rev a1)" for OpenHantek ("Graphic: 3.0") The "problematic" one X751LX with "3D controller: NVIDIA Corporation GM107M [GeForce GTX 950M] (rev a2)" for other purpose ("Graphic: 4.6")
Thank you for your input. You may close this issue whenever you want
OpenHantek --useGLSL150 as well as OpenHantek --useGLES do not solve the issue. I have real hardware, modified for AC coupling ; I use it for several years
I just changed my laptop (previously a very old Dell Vostro 3700) and wanted to check OpenHantek on the "new" ones The 2 Asus are more recent, I bought them as a lot for very little money, added SSD and more RAM.
Thank you All the best
Update: Changing only LC_NUMERIC is sufficient to remove jitter env LC_NUMERIC="en_US.UTF-8" OpenHantek
I found out that I am able to add 1 line to dsowidget.cpp and solve my issue by setting a minimum height for each row of bottom text. I set it at 2 * fontSize As I am not familiar with pull request, I put my solution here.
--- dsowidget.cpp 2022-04-08 21:07:19.000000000 +0200 +++ dsowidget-modif.cpp 2022-04-10 14:49:32.338735945 +0200 @@ -145,6 +145,7 @@ measurementLayout->setColumnStretch( 11, 3 ); // f measurementLayout->setColumnStretch( 12, 3 ); // note, cent for ( ChannelID channel = 0; channel < scope->voltage.size(); ++channel ) {
LC_NUMERIC is a good starting point - I dislike the localized numeric display in technical context, because it creates uncertain display (1 V is displayed as 1.00 V or 1,000 mV for en, de shows it as 1,00 V or 1.000 mV. This nasty 1000 separator may be helpful if displaying exact integer values like a bank account, but is highly misleading when handling values rounded to 3 significant digits. As a consequence of this issue I remove the localized numeric rendering and display all values as engineering values, decimal separator is the dot - that's it. CSV are saved according the locale anyhow to not annoy the LibreOffice Calc or MS Excel, because these rely on the (stupid) local preferences.
I already considered your setRowMinimumHeight
proposal, but this takes too much valuable vertical space. From some discussions I learned that OH6022 is used on many older laptops with screen resolution of 1280x720 or even 1024x768 (this also caused my decision to explicitly enable the use of the smaller Fusion style via config setting).
@Leonleon33 Please check if the latest unstable is jitter-free, merci.
OpenHantek6022 (20220410 - commit 1000) Graphic: 4.6.0 NVIDIA 470.103.01 - GLSL version 1.20
Jitter free !!!
First thank you for your work !
Then, 2 short videos may better explain than my poor English :)
When I type in a terminal "OpenHantek" and go to the Demo I obtain some jitter: https://mega.nz/file/fUdQCDSa#u31_m6WwgeRTKABDRLn4iamxTmEPQE-iCYoB9CL_wW8
When I type in a terminal "env LC_ALL=C OpenHantek" and go to the Demo I obtain no jitter: https://mega.nz/file/aU9CjRYK#Mtta1uMS_cOuzUdD62eFn0DrAl1orthRZbgw9en2nZ8 Downside is : no translation My locale is "fr_FR.UTF-8"
If ever somebody knows how to overcome this little inconvenient, let me know