Plotting socket data

[catto]

Hello,

I wrote an application that plots signal samples using Qwt. The application consists of a QMainWindow subclass that has some labels to present numeric values, a QTextEdit to present textual messages and a QwtPlot subclass to plot the signal samples. All three kinds of information are received through UDP sockets. The sockets are members of the QMainWindow subclass, so the received samples are passed to the QwtPlot subclass, which has a buffer a does the plotting. Before being represented, all the received data needs some kind of processing (besides being extracted from the corresponding socket).

With the current implementation, the application responsiveness is not as good as it should be. Could anyone give me some advice on what would be a good architecture for this kind of application (sockets+plotting)? Maybe a change in the class organization or some threads to help improve responsiveness?

What is the best approach to achieve bidirectional communication between the QMainWindow subclass and the QwtPlot subclass (samples have to be passed to the the QwtPlot subclass and the plot has to notify the mainwindows when it is out of samples)

Thanks for your advice.

Regards,
catto

[d_stranz]

I don't understand what you mean by "the plot has to notify the main window when it is out of samples". QwtPlot is generally just a passive display; it plots what it is told to plot and doesn't set up any kind of polling loop to ask for more data. If you've set up some kind of architecture that creates such a dependency, then that is likely the source of the sluggishness. The plot keeps asking, "Got any more data? Got any more data?" and for every two million times it asks the main window says "Yes" once. Better to put the main window in charge, and have it tell the plot "Here's more data" only when it actually has some.

On the other hand, if that's what you are doing, and the data rate is so high that the plot can't keep up, then you might think about some buffering or averaging strategy where you send the plot the average of every 10 samples, or update only once a second. There is a real-time plot demo in the examples which might give some ideas.

[unit]

good architecture is to use powerfull signal/slot mechanism that qt provide. Your socket subclass receive information and put it to mainwindow that can put it to widgets

[Uwe]

good architecture is to use powerfull signal/slot mechanism that qt provide.

????

For applications, where samples from some continuous source ( socket, device .. ) need to be displayed in a plot widget in "realtime" it is very important to decouple the refresh rate of the plot widget from the sample rate.

In detail it means to introduce a message queue, where the incoming data is simply collected. The plot widget periodically checks this message queue ( QTimer ) and displays new samples if available.

But even with a reasonable timer interval for the plot updates you might have the problem, that there are too many samples and a single replot takes too long and blocks your application. But this is a different type of problem, that can only be discussed when knowing the specific details of your application.

Uwe

PS: Check the oscilloscope example of Qwt 6.x.

[unit]

Uwe, you are right but we don't know what kind of task (what data, is it real-time data and other) catto want solve.

In my network monitoring software i have class that recieve and manipulate all needed data and then this data is used by plotter and other widgets. Yes, my class have buffer and other logic, so real-time monitoring work fine for me.

But catto should tell us more about his app.