Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OH doesn't really work in "Single" capture mode #189

Open
phmarek opened this issue Mar 2, 2018 · 2 comments
Open

OH doesn't really work in "Single" capture mode #189

phmarek opened this issue Mar 2, 2018 · 2 comments
Labels
bug fix_in_dev_branch A fix for this issue is available in the development branch

Comments

@phmarek
Copy link
Contributor

phmarek commented Mar 2, 2018

Hi,

thanks for all the work on OpenHantek!

I tried to capture some IR signals right now, and this works beautifully. The problem arises when I try to do some other operations - export a CSV, export Image/PDF, change the markers for zoom or measurements; these all stall while the capture is "paused".

This partly defeats the point of doing a single trigger - I have the image on the screen, but can't do anything with it!

Furthermore, when going back to Auto/Force trigger setting, the "Export/CSV" menu choices were processed, and I got asked about a filename multiple times; then OH crashed:

Thread 1 "OpenHantek" received signal SIGSEGV, Segmentation fault.
0x00007ffff52688e3 in std::_Rb_tree_increment(std::_Rb_tree_node_base*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff52688e3 in std::_Rb_tree_increment(std::_Rb_tree_node_base*) () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x0000555555589c97 in std::_Rb_tree_const_iterator<ExporterInterface*>::operator++() (this=<synthetic pointer>) at /usr/include/c++/7/bits/stl_tree.h:366
#2  0x0000555555589c97 in ExporterRegistry::checkForWaitingExporters() (this=0x7fffffffcb30) at openhantek/src/exporting/exporterregistry.cpp:71
#3  0x00007ffff57fd8c2 in QObject::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff6529453 in QWidget::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#5  0x00007ffff663c1fb in QMainWindow::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x00007ffff64ea63c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x00007ffff64f1f04 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007ffff57ce258 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007ffff57d09cd in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007ffff5827ac3 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007ffff2950f67 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff29511a0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff295122c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff58270ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff57cc2aa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007ffff57d5214 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x0000555555576ed8 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at openhantek/src/main.cpp:199

but I guess this should be solved as soon as OH doesn't block on Single trigger any more.

@davidgraeff
Copy link
Member

Yes that's correct, for the single capture to work, the last sample set (the one that is visible) should be cached in the post processing module and export should always use that cached sample set instead of waiting for a new one.

@davidgraeff davidgraeff added bug fix_in_dev_branch A fix for this issue is available in the development branch labels Mar 9, 2018
@Rader02
Copy link

Rader02 commented May 14, 2018

May I ask how you got a scan with long time base?

My observations:

  • Firstly I struggle with sample rate and time base. If I set time base to eg 4 sec then sample rate jumps to 100kS/s. Much to many points per sec, so I understand why there is only a very short signal on the left.
  • 4 sec time base means 40 sec for a full sweep from left to right, right?
  • If I change sample rate and time base back and forth I finally achieve 4 sec / 100 S/s.
  • I expected to see a dot, moving slowly from left to right.
  • If I record a 50 Hz noise signal and scan it with 4 sec/div baseline I would have expected more or less random dots in vertical, and these dots moving from left to right.
  • Instead I get a full line.
  • This way I fail to record a slowly changing signal. Even if saving fails I would be glad to reproduce your succes of having this signal on screen.

What do I misunderstand?
Is it possible to insert time base / rample rate a a manual command?

Please find attached a scan with 1.6 min(!) timeline of a 1 kHz signal.
(Attachment does not work.You would have seen a sharp edge of the square signa)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug fix_in_dev_branch A fix for this issue is available in the development branch
Projects
None yet
Development

No branches or pull requests

3 participants