infinte monitoring about openhantek6022

[Ho-Ro]

Hi karamJAB,
thank you for your proposal. The data flow is described roughly in this document. The continuous export could be done e.g. with a (named) pipe as a postprocessing task after SpectrumGenerator::process() and before GraphGenerator::process() (the tasks are defined and ordered in main.cpp:165, //////// Create post processing objects ////////). At this stage the voltage as well as the spectrum data are available. But be warned that the scope doesn't sample continuously but acquires a block of 20000 samples (either 8-bit samples CH1 only or 16-bit samples CH1 & CH2), processes and acquires a next block leaving a gap between blocks. Maybe you better use sigrok that (IIRC) gives the possibility of continuous sampling. A quick check says - yes: https://sigrok.org/wiki/Sigrok-cli

[staticmem]

The amount of CVS sample data seems to be very limited at 20k samples. Could this be increased? on a modern PC this should not be an issue and there could be a setting for the buffer size.

If using a trigger will the software capture and store samples before the trigger point?

[Ho-Ro]

@staticmem: It's not the issue with PC storage. The program OpenHantek6022 is intended first of all as a digital storage scope. Therefore it collects as much data as necessary to display a stable and dynamic image that is refreshed frequently. The larger the sample size, the safer the program finds the trigger point - but on the other hand, the acquisition takes longer and the refresh rate decreases. The sample size of 20000 was chosen to compromise both purposes. The curve on the screen is a cutout from this 20000 samples window, depending on the trigger condition an undefined number of leading samples will be discarded to get a stable image (software trigger). The CVS export is a nice add on to save the raw sample window, it's not intended as a permanent data collector. If this is your application, then use sigrok which follows the metaphor of the line recorder, or try the low level python interface.

[staticmem]

I understand that you are displaying a window of data and this has to be limited, that's fine but why can't it store more values? Surely this is just a matter of keeping track of the insert and retrieve points and wrap it if it reaches the buffer limit. By that I mean shifting the pointers within the data. You could then just operate on that Window of data within the time frame required?

I'm not expecting high speed logic use but rather serial data at a maximum of say 115k baud.

[Ho-Ro]

The low level code is not able to sample continuously due to the underlying USB bulk transfer! All you can get are chunks of 20000 samples with an undefined time gap between. You can store more date but these samples are not gapless.
@staticmem: Please explain why you expect this feature so badly in OpenHantek6022 and don't want to use the proposed alternative programs - I don't need it and won't rewrite the whole program to implement this function. It's a DSO and not a line recorder. -> I will close this issue.

@karamJAB: If you find a simple solution you're welcome to propose a patch or pull request.

[staticmem]

Surely the DSO hardware has a buffer to store a "WINDOW" of data until the next request is made or is the DSO hardware that bad? If Sigrok can be used instead to capture analogue (not just logic levels on a 6022BE) wave forms I will use it instead. What other alternatives are there? If you claim this SW to be a DSO then it needs to perform like a DSO and not just a real-time window of data. "S" stands for storage. I want to see what led up to a trigger point to diagnose a HW issue.

[Ho-Ro]

is the DSO hardware that bad?

You decided to buy this device, so you checked its specs upfront (didn't you?). Otherwise take your time and get some facts, e.g. here, rough schematics can be found later in the discussion. The scope HW is build around a Cypress EzUSB chip that streams sample data to USB (with the little help of a 4 kByte internal FiFo buffer). The main HW drawbacks are no internal storage, no AC coupling, no HW trigger. Everything has to be done in SW, also the storage.

What other alternatives are there?

I've told you before, look up.

If you claim this SW to be a DSO then it needs to perform like a DSO and not just a real-time window of data.

If you don't like how the software works, don't use it. Otherwise, change it, it's free open source.

I develop this program for my needs and give it away for free. You are not my boss, so don't request or expect something.

I want to see what led up to a trigger point to diagnose a HW issue.

Shift the trigger point to the right and use single mode - you will see the history left of the trigger.

[staticmem]

Talk about being over sensitive! I produce open source software (not currently on GitHub) too and I don't respond like that to users when I'm asked questions. If it is just for yourself then why publish it and allow interactions? Seriously

[staticmem]

Ok so mark my posts as off-topic. So how is your comment below on topic?
"I develop this program for my needs and give it away for free. You are not my boss, so don't request or expect something."

[Ho-Ro]

After some noise in the discussion I reopen the issue again as it would be an enhancement, @karamJAB feel free to explore the possibility.

[Ho-Ro]

1 month without any activity - I close for now and will reopen if there's any progress.