discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Suggestions on GSoC project idea for HTML-based GUI


From: Kartik Patel
Subject: [Discuss-gnuradio] Suggestions on GSoC project idea for HTML-based GUI
Date: Sat, 18 Feb 2017 19:03:39 +0000

Hello all,

I was thinking on the project for HTML Based GUI for GNU Radio Applications. I have developed the probable workflow of the final OOT. I want some comments/suggestions/feedback on this flow. The details of the project is available here.

--------------
First of all, I have gone through the Plotly library and Bokeh library. I believe Bokeh library is a perfect choice for the task. Plotly has excellent charts, but all other tasks like Socket creation, data flow, serving the data etc. is needed to be done manually using other frameworks. On the other hand, serving the python app is among the main features of Bokeh library.

Currently GNU Radio generates a Python file top_block.py. It has all config options of QtGui Sinks and input tools. Similarly, in the HTML based GUI, it will have all config options related to HTML based GUI just like the current one. Also, bokeh has input tools which can be used as the inputs on HTML page. So, basically instances of sinks and input tools will be defined in top_block.py

Upon executing it, a Bokeh server will start at some port. The Bokeh server takes care of frontend and backend socket connections. Hence, the task is to create instances corresponding to each sink/inputs of the Bokeh plots/input and then simply serve through the Bokeh server. It should be noted that, all the calculations for plots will remain same as done in QtGUI.

During the execution: top_block.start() starts the simulation. top_block.show() will serve the Bokeh application. 
---------------
Also, I have some doubts related to current implementation of QTGUI and in proposed workflow:
  1. The block::work function returns new data. It should be received in a python file and it should accordingly redefine the structure of the new data to send to Bokeh server. Am I correct?
  2. I am unable to understand is, where exactly it is written that the plots should be continuous updated? I see the trigger_mode is doing the task. But even with trigger_mode=FREE, how is it continuously updating? According to our design, there should be a similar flow, which will stream the data to Bokeh server.
  3. This is most important: Where exactly the GUI is turned on? Which file/class/function iterates through all sinks in flowgraph? I think, that should be the point where the Bokeh server turns on. I see that the top_block.show() calls the function and there is a scheduler that plans out the task. But I couldn't understand the connection between top_block and gr-qtgui.
Thank you very much for your help. If you are unable to understand any specific detail, kindly ping me.

Regards,
Kartik Patel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]