Oscilloscope emulator

[jayriordan]

First of all, this is not another thread asking for help with the example scope application. The example scope application does not behave the way a real oscilloscope would. Take an analog oscilloscope for example, the trace reaches the end of the 'plot' and wraps back to the left hand side and begins drawing again; the example oscilloscope will continue scrolling and increment the time scale to the right infinitely.

So what am I getting at, what am I trying to do? I'm developing a scope emulator with a normalized time scale; one similar to a hardware oscilloscope. The behavior I'm looking for is best described as one you would see with a digital hardware oscilloscope (analog doesn't do large time/div well) where the traces sweep from left to right and do what I call the snake eating its tail. When the head reaches the right side of the plot, it should appear on the left and begin drawing over the oldest points.

I've been experimenting with a qwt_plot and a qwt_plot_curve but what I've found is a few new unwanted behaviors when I manipulate the data I'm putting into the plot curve:
-If I treat the samples as a vector, when I try to wrap the data points to start back at the beginning of the plot, I end up with a line between the last point on the right side of the screen and the latest point on the left side of the screen.
-If I treat the samples as a ring buffer, I reach the right side of the plot and 'wrap' I pop the first sample off from the vector and pre-pend the next, I end up with an undesired line between the latest point and the 'second' point which is 1 time scale behind the latest point. I think that might be wordy; I don't want a line between the head and the tail.

I've been looking through the qwt documentation for a module that I could re-implement to behave the way I want it to but I've come up empty. The documentation is great, but there descriptions of each class is a little lacking to truly understand what I could expand the classes to do.


Thanks for taking the time to read this,

Jay

[Uwe]

The behavior I'm looking for is best described as one you would see with a digital hardware oscilloscope (analog doesn't do large time/div well) where the traces sweep from left to right and do what I call the snake eating its tail. When the head reaches the right side of the plot, it should appear on the left and begin drawing over the oldest points.

You always need to have 2 curves: one for the previous interval and one for the current. With each update you have to remove points from the previous one and add points to the second one. You could implement it using a single buffer with a cursor ( index of the current point ), but you need to implement 2 QwtSeriesData<QPointF> bridges, wher the first one returns the points <= cursor index and the second one returns all points behind. When reachin the end you simply swap the QwtSeriesData<QPointF> objects ( or the curves ).

So far this should be a no-brainer - only when you need to avoid full replots for each update ( too many points + high refresh rates + slow embedded device ) things become more tricky. In opposite to the oscilloscope example it is not enough to draw incrementally ( no replot ! ) as you always have to erase a section of the previous curve. How to do this best depends on what else is visible on your plot.

To be honest I would be interested in adding an example for such an osci to the Qwt package. So if you send me some implementation - without optimized drawing - per Email I would do the rest. Maybe you also have a good idea how to generate synthetic points, that look realistic - at least we would need to have 2 different cycles.

Uwe

[jayriordan]

You always need to have 2 curves: one for the previous interval and one for the current. With each update you have to remove points from the previous one and add points to the second one. You could implement it using a single buffer with a cursor ( index of the current point ), but you need to implement 2 QwtSeriesData<QPointF> bridges, wher the first one returns the points <= cursor index and the second one returns all points behind. When reachin the end you simply swap the QwtSeriesData<QPointF> objects ( or the curves ).

So far this should be a no-brainer - only when you need to avoid full replots for each update ( too many points + high refresh rates + slow embedded device ) things become more tricky. In opposite to the oscilloscope example it is not enough to draw incrementally ( no replot ! ) as you always have to erase a section of the previous curve. How to do this best depends on what else is visible on your plot.

Fortunately for my application the intended target is a desktop computer; however I can see the inefficiencies in too many points with a high refresh rate even on a desktop PC.

I had thought to use two buffers like you're suggesting, but I was hoping there was a simpler way. With this implementation, you must keep in mind that you may have more or less data points / fraction of a second in either buffer. The behavior for what I feel like I'm failing to describe here is the case where the two curves overlap in the x axis. I'll do my best attempt at drawing the scope output in ascii art:

###############
#             #
#      _______#
#             #
#________     #
#             #
###############

###############
#             #
#      _______#
#             #
#________     #
#             #
###############

To copy to clipboard, switch view to plain text mode 

This could be avoided by eliminating samples based on the x coordinate instead of just popping off the first element from the buffer.

I'll do my best to come up with something that I could send you to contribute towards qwt!

Thanks for taking the time to read and respond!

Jay



Edit: Trying to get the formatting correct on the ascii art.

[Uwe]

I had thought to use two buffers like you're suggesting, but I was hoping there was a simpler way..

No I was suggesting 2 curves - connected to the same buffer !

Uwe

[jayriordan]

No I was suggesting 2 curves - connected to the same buffer !

Uwe

I re-read your first post, yes a single buffer to store data and plot two curves based on the current x value.