Plot limited to sampling frequency

[javiercarrascocruz]

Hi, I am connected to a remote target over the network and I am able to read properties and single values from an IIO device (hts221), which provides a triggered buffer, and its maximum sampling frequency is 13 samples/second.

The plot view only lets me capture up to 13 samples in both single shot and continuous measurement. If I try to read more samples than the sampling frequency (e.g. 14, any value greater than 13), the application freezes and I see on the target that iiod throws a timeout:

iiod[541]: WARNING: High-speed mode not enabled
iiod[541]: ERROR: Reading from device failed: -110

Is the plot view limited to the samples than can be taken in one second?

When at it, is there any way to get processed samples (offset and scale applied) in the plot view like it is already done in the DMM mode? Thanks.

[dNechita]

Hi,
The plot view is not expected to enforce such a limit. Error 110 means that connections has timed out. What iio-osciloscope has, is an internal hardcoded timeout. One way to go forward would be to modify this internal value which can be done via the .ini file. Also make sure you have the latest iio-oscillscope (the latest from main branch and not the latest release).
For example, to force the internal timeout value to 5 seconds, you can modify the .ini file (that gets saved once the iio-osc closes and gets loaded when the iio-osc opens up) like this:
"capture_timeout=5000"

Regarding applying offset and scale, yes, the plot allows adding some simple math operations for each channel. Just right click on a channel and select the 'math' option. Then you will be able to provide an offset to be added to the signal and a gain value to be multiplied to the signal.

I apologize for the late reply.

[dlech]

What iio-osciloscope has, is an internal hardcoded timeout.

Actually, this is not true. We hit this issue with a device that has per-channel sampling frequency and looked into the source code to find out what was going on.

If a device has a sampling frequency attribute, that is used to compute the timeout.

iio-oscilloscope/osc.c

Lines 1505 to 1514 in fbd5aa5

	freq = read_sampling_frequency(dev);
	if (freq > 0) {
	/* 2 x capture time + 1s */
	timeout = sample_count * 1000 / freq;
	if (dev_info->channel_trigger_enabled)
	timeout *= 2;
	timeout += 1000;
	if (timeout > min_timeout)
	min_timeout = timeout;
	}

This is a problem for multi-channel devices that are self-triggered and don't do simultaneous sampling. On those, the effective sample period is the sum of the sample periods of each enabled channel (citation). So the sampling frequency should be calculated as:

$$f_{effective}=\frac{1}{\displaystyle\sum_{k=1}^n \frac{1}{f_k}}$$

But iii-oscilliscope just uses the sampling frequency of the first voltage channel as the effective sampling frequency. So when enabling multiple channels, we get a timeout because it only used one channel for the timeout calculation.

[dNechita]

@dlech, you are correct that iio-oscilloscope does not currently support multi-channel devices that are self-triggered. When the timeout computation code was written, it did not account for the use case you mentioned. This appears to be an improvement that should be added to the iio-osc requirements list.
For clarity, for anyone reading this thread, iio-oscilloscope does include a mechanism to override the computed value based on the sampling frequency attribute. The override value is read from the .ini file.

iio-oscilloscope/osc.c

Lines 1519 to 1524 in fbd5aa5

	if (ctx) {
	if (ini_capture_timeout_loaded) {
	min_timeout = ini_capture_timeout;
	}
	iio_context_set_timeout(ctx, min_timeout);
	}