Broken voltage levels

[phmarek]

With eccfd9641fcbc4d25f5740a97d940a4ac10722bb, I get good voltage measurements.

With 33723056459adec972927aa46331bd5675b02886 and the same settings (2V/div, DC), the displayed waveform seems to have only half the voltage.

I don't know whether the voltage divider settings sent to the oscilloscope are wrong, or whether it's just the display that's broken, though.

[davidgraeff]

Which DSO model do you use? The code base was modernized and restructured recently and I can only test with one of the supported types. There might be something messed up.

[phmarek]

I'm using a DSO2250. Thanks for the quick answer!

[phmarek]

Any updates? Still happens with c66be8a976a6af63706f692d638254bdb7e6f272 for me.

Looks like the relay settings and/or offsets sent to the oscilloscope or so are broken - small changes in the zero-line setting make the graph jump to the upper resp. lower border.

[davidgraeff]

The problem is, at the moment there are mainly contributions from people with a dso6022. That model doesn't support offset and relays. So nobody of the current contributors can test the offset and relay code.

[davidgraeff]

The openhantek2 branch contains a self-calibration and adjustable gain dividers, this should help.

[uunicorn]

I have the same problem on DSO2250. openhantek2 seems to be even worse - I can't seem to change the time base. Also offset/trigger markers are jumping up and down when trying to drag them around.

[phmarek]

That is on the master branch .... any chance for a fix on the openhantek2 branch as well?

[uunicorn]

openhantek2 looks pretty broken to me. I'm building against qt 5.11 with gcc-5.4. Got a couple of compilation errors:

• implicit cast to unique_ptr in levelslider.cpp
• two files called "enums.h" producing the same MOC file which is included twice causing duplicate decls

After fixing those errors I was able to run the application, but it's still quite broken:

• axes are not rendered properly (some random lines across the scope view)
• DeviceSettings::offsetAdjustStep returns result of integer division (1 / n, n > 1) which is always zero which prevents you from dragging offset and trigger sliders without holding the Alt key
• trigger position slider is stuck under some other widget and not receiving click events
• same with offset positions if they end up in the topmost position
• timebase/samperate selection is broken: unable to select anything except 100 MS/s, 102.4 µs which does not seem to always work as well

Nevertheless, the fix from the linked PR seems to resolve the problem with cmdGetLimits. If you want, I can raise the PR for openhantek2 with the same set of changes as in #241 , but I can't really test it without properly fixing all the other issues I've listed above.

[davidgraeff]

The OpenHantek2 branch was meant to restructure the codebase to increase maintainability and add devices more easily. But there are some issues as commented. it was only tested with one compiler and one scope at hand.