Editing GSoCOldIdeas

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 256: Line 256:
 
* survey the existing GNU Radio samples for ham radio, many are listed on the HamRadio page of this wiki.
 
* survey the existing GNU Radio samples for ham radio, many are listed on the HamRadio page of this wiki.
 
* design user interface improvements for the samples to make them more intuitive to new users and traditional radio operators. Consider how they can interact with [[HardwareTransceiver|Hardware]] such as a VFO tuning knob, PTT microphone switch and even a morse key
 
* design user interface improvements for the samples to make them more intuitive to new users and traditional radio operators. Consider how they can interact with [[HardwareTransceiver|Hardware]] such as a VFO tuning knob, PTT microphone switch and even a morse key
* look through the other packages in the [https://www.debian.org/blends/hamradio/get/metapackages Debian Ham Radio metapackage list] and consider how they could interact with GNU Radio. In particular, we are interested in the use of message bus solutions, such as [https://gnuradio.org/doc/doxygen/page_zeromq.html ZeroMQ] or [https://dbus.freedesktop.org D-Bus] - for example, GNU Radio could send alerts on the bus when incoming signals exceed the squelch threshold. GNU Radio could also receive events over a message bus, for example, patching "gpredict"http://gpredict.oz9aec.net/ to send Doppler shift information.
+
* look through the other packages in the [https://www.debian.org/blends/hamradio/get/metapackages Debian Ham Radio metapackage list] and consider how they could interact with GNU Radio. In particular, we are interested in the use of message bus solutions, such as [https://gnuradio.org/doc/doxygen/page_zeromq.html ZeroMQ] or [https://dbus.freedesktop.org D-Bus] - for example, GNU Radio could send alerts on the bus when incoming signals exceed the squelch threshold. GNU Radio could also receive events over a message bus, for example, patching "gpredict"http://gpredict.oz9aec.net/ to send Doppler shift information.
 
* developing and packaging libraries needed to process digital voice transmissions
 
* developing and packaging libraries needed to process digital voice transmissions
 
* look at how one or more of the samples can be deployed as a Debian package so users can just install the package and have a working radio
 
* look at how one or more of the samples can be deployed as a Debian package so users can just install the package and have a working radio
Line 442: Line 442:
 
==== Wireless Networks In-the-Loop ====
 
==== Wireless Networks In-the-Loop ====
  
The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to build a GR-based network emulator. This implies the modeling of the underlying SDR hardware, the individual channels & interference characteristics, as well as the timing behavior (produce correct amount of noise samples if no node is transmitting). The project already started in 2011 and as a outcome, the basic functionality -- the framework with client-server based "sample dispatcher" as well as some example hardware & channel models -- has already been implemented in the gr-winelo OOT, which will be published on github soon. See [[http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm|http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm]] for a quick introduction to "Wireless Networks In-the-Loop".
+
The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to build a GR-based network emulator. This implies the modeling of the underlying SDR hardware, the individual channels & interference characteristics, as well as the timing behavior (produce correct amount of noise samples if no node is transmitting). The project already started in 2011 and as a outcome, the basic functionality -- the framework with client-server based "sample dispatcher" as well as some example hardware & channel models -- has already been implemented in the gr-winelo OOT, which will be published on github soon. See [[http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm|http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm]] for a quick introduction to "Wireless Networks In-the-Loop".
  
 
===== Objectives =====
 
===== Objectives =====
Line 449: Line 449:
  
 
* (Signal Processing) Implementation of new hardware/channel models like a SDR platform/specific daughterboards or reference channels.
 
* (Signal Processing) Implementation of new hardware/channel models like a SDR platform/specific daughterboards or reference channels.
* (Optimization & Performance) Improve performance of existing implementation (port python code to C/C++, develop new mechanisms to collect & distribute samples between several nodes).
+
* (Optimization & Performance) Improve performance of existing implementation (port python code to C/C++, develop new mechanisms to collect & distribute samples between several nodes).
* (Signal Processing & Development Tools) Implementation of new development tools like "breakpoints on the air link" (pause the entire emulation if certain criteria (BER, SNR, interference/collisions) is fulfilled on the virtual channel/at single nodes).
+
* (Signal Processing & Development Tools) Implementation of new development tools like "breakpoints on the air link" (pause the entire emulation if certain criteria (BER, SNR, interference/collisions) is fulfilled on the virtual channel/at single nodes).
  
 
===== Potential mentor(s) =====
 
===== Potential mentor(s) =====
Line 567: Line 567:
 
==== Remote deployment and control of flow graphs from within GRC ====
 
==== Remote deployment and control of flow graphs from within GRC ====
  
Users might want to run flow graphs on an embedded device or a distant machine. Currently in order to do this they will have to turn their GRC generated flowgraph into a Python file and transport it to the remote machine via scp. With control port we already have a way to remotely interact with flow graphs; however, remote deployment of a flowgraph is currently not possible. This could be achieved by using, e.g., python-execnet and a new "Generate" option. As for remote control/monitoring, a new component or OOT-module "gr-htmlgui" might be a flexible solution.
+
Users might want to run flow graphs on an embedded device or a distant machine. Currently in order to do this they will have to turn their GRC generated flowgraph into a Python file and transport it to the remote machine via scp. With control port we already have a way to remotely interact with flow graphs; however, remote deployment of a flowgraph is currently not possible. This could be achieved by using, e.g., python-execnet and a new "Generate" option. As for remote control/monitoring, a new component or OOT-module "gr-htmlgui" might be a flexible solution.
  
 
'''Requirements:'''
 
'''Requirements:'''
Line 639: Line 639:
 
==== Measurement Toolbox ====
 
==== Measurement Toolbox ====
  
As being widely used in the scientific area, an often recurring task when working with GR is measuring. The idea is to design and implement a new "gr-measurement" or "gr-sensornet" toolbox. Central aspects are "automation" and "centralization".
+
As being widely used in the scientific area, an often recurring task when working with GR is measuring. The idea is to design and implement a new "gr-measurement" or "gr-sensornet" toolbox. Central aspects are "automation" and "centralization".
  
 
===== Objectives =====
 
===== Objectives =====
Line 645: Line 645:
 
Possible (sub-)projects are:
 
Possible (sub-)projects are:
  
* Implementation of a distributed measurement tool Start flowgraphs on different hardware platforms (see also project idea "Remote deployment and control of flow graphs from within GRC"), collect measured samples or post-processed data from every platform after running the measurement & store the measurement with the appropriate tags in a "central measurement database", (create a nice-looking GUI).
+
* Implementation of a distributed measurement tool Start flowgraphs on different hardware platforms (see also project idea "Remote deployment and control of flow graphs from within GRC"), collect measured samples or post-processed data from every platform after running the measurement & store the measurement with the appropriate tags in a "central measurement database", (create a nice-looking GUI).
 
* Development and implementation of methods for synchronized distributed measurements (GPS, NTP, ...) - allow synchronized measurements at different locations, e.g. simultaneous spectrum observation at different locations.
 
* Development and implementation of methods for synchronized distributed measurements (GPS, NTP, ...) - allow synchronized measurements at different locations, e.g. simultaneous spectrum observation at different locations.
  

Please note that all contributions to GNU Radio are considered to be released under the Creative Commons Attribution-ShareAlike (see GNU Radio:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)