Open uunicorn opened 6 years ago
Ran into the same problem with my DSO2090. The edge which triggered the scope was always off the screen, but only for 100 MS/s fast mode.
This patch fixed it
diff --git a/openhantek/src/hantekdso/hantekdsocontrol.cpp b/openhantek/src/hantekdso/hantekdsocontrol.cpp
index bd50286..8e08448 100644
--- a/openhantek/src/hantekdso/hantekdsocontrol.cpp
+++ b/openhantek/src/hantekdso/hantekdsocontrol.cpp
@@ -972,7 +972,11 @@ Dso::ErrorCode HantekDsoControl::setPretriggerPosition(double position) {
double positionSamples = position * controlsettings.samplerate.current;
unsigned recordLength = getRecordLength();
// Fast rate mode uses both channels
- if (isFastRate()) positionSamples /= specification->channels;
+ if (isFastRate()){
+ positionSamples /= specification->channels;
+ // Fix trigger position offset bug for 100 MS/s mode
+ positionSamples += recordLength / 2;
+ }
switch (specification->cmdSetPretrigger) {
case BulkCode::SETTRIGGERANDSAMPLERATE: {
I observed that when isFastRate()
is True, recordLength
doubles in value. Not sure if intentional?
When in fast mode (1ch, 250MS/s), the edge is triggering the transfer successfully, but the edge position in the buffer is consistently in a wrong place.
I've got an OpenGL perl app which I wrote about 10 years ago based on disassembly of Hantek DLLs. I was using this app ever since. It's ugly and does not really have any UI (to change gains or the timebase I had to edit the perl source), but it was doing it's job. Looking at my old code now it seems like trigger position is calculated based on 10240 samples per frame, regardless of whether it is in a fast mode or in a normal mode. I know it's odd, but applying the following diff fixes the trigger position bug in OpenHantek for me.
Can someone with another device supporting fast mode check if it works for you? If so, I'll raise a pull request.