search

analogdevicesinc / scopy

A software oscilloscope and signal analysis toolset
http://wiki.analog.com/scopy
GNU General Public License v3.0
398 stars 164 forks source link

Item 21 From Issue #4: Sine Wave Set for Amp = 5 V and OS = -5 V Produces Incorrect Waveform #41

Closed jonpearson closed 7 years ago

jonpearson commented 8 years ago

Item 21 from Issue #4

"Under the waveform controls for the sine wave you can set Amp = +5 and offset = -5 and the displayed wave goes from 0 to -10 which is not a valid range for the actual output. Same for a + offset."

jonpearson commented 8 years ago

Output waveform observed on an oscilloscope to have glitches similar to those seen in other issues.

damercer commented 8 years ago

As was verified the actual analog output suffers from the inversion issues posted in other places. The point with this comment is GUI related and was that the waveform drawn in the generator screen should not allow / show voltages beyond the specified range of the hardware. Drawing a waveform that goes to either +/- 10 is not within the +/- 5 V range of the output amplifier. User should be warned that entry is not valid and drawn waveform should be clipped / limited as the actual output will be.

pcercuei commented 8 years ago

Problem is, what's the range of the output amplifier? We have no way to know that from the software, just like we have no way to know the exact relation between the values of the samples and the voltage, in a device-independent way. Right now Scopy is full of workarounds that only work with the M2K, and that is certainly not future-proof.

damercer commented 8 years ago

All excellent points from a global point of view but the from the perspective of the user the software needs to know what hardware it is connected to and adjust what the user sees based on that.

If Scopy is going to support multiple hardware platforms with different capabilities ( ie M1k, M2k ... ) in the future it is going to have to be able to adjust its UI to accommodate the hardware. The software needs to be able to query the hardware and get a response as to what it is and/or what its capabilities are. If that is not yet supported in the hardware / firmware then the team needs to figure out how that will get implemented. If you want to call this hardware specific workarounds OK but that is how it will probably turn out.

Calibration gives you the exact relation between the values requested by the user and what gets sent to / from the hardware ( DACs and ADCs ). I'm not following your point about the output amplifier.

mhennerich commented 8 years ago

We shouldn’t intermingle application specific code with generic IIO. However we need an application specific transformation layer that can be used a skin across the entire application. IIO doesn’t allow us to describe processing flow graphs, however that’s something GNU Radio is good in. The HW itself has a state which is controlled by GUI widgets and the logic behind them.

It’s shouldn’t be too difficult to draw a flow graph that has all reference voltages, gain elements, offsets, rails, etc. Based on the HW state we configure this graph and at the end of the pipe we get the transfer function, which includes everything including clipping.

Thoughts?

pcercuei commented 7 years ago

Would it be possible / easy to represent the graph as a string? Because then that's an info that we could carry using the soon-to-be-introduced "context attributes" of libiio.

pcercuei commented 7 years ago

I think the behaviour is correct now. @damercer, could you confirm?

damercer commented 7 years ago

Yes, works as defined now.

pcercuei commented 7 years ago

Ok - thanks.