Hackfest1501

Hackfest January 2015 at TU Delft

Location: http://www.es.ewi.tudelft.nl/

Dates: Jan 26 - 30, 2015

Proposed Projects:

• Improving packet communications: continuing work to make packet formatting and parsing easier to use and extend.
• Develop simple example GRC projects for each block to demo how it works.
• RFNoC development and applications.
• Android developments
• Unit tests and QA for GRC
• Validate and update documentation for embedded GNU Radio development.

Projects

Tom Rondeau

Tom has been working on porting GNU Radio to Android to help us explore that space of developers and hardware. There's a patched version of GNU Radio that runs on Android and will be released soon. We also have the RTL-SDR hardware working with GNU Radio on Android via the gr-osmosdr interface. At Delft, Tom worked on expanding the capabilities to support UHD-based devices under Android -- specifically aiming at a USRP B200 to interface with things like Android phones and tablets over USB. We didn't get it to work completely, but made significant progress. Its current project state is "almost working."

Tom is also pursuing some work to improve our documentation and help in using GNU Radio. With the planned release of VOLK as a stand-alone project, we wanted a much better manual for it, including information on all of the kernels. Each kernel now has a Doxygen-formattted comment at the start of the kernel to explain the behavior, and this becomes a single page of the VOLK manual. Each kernel's page includes the following information:

• Name of the kernel's dispatcher function.
• An description (overview) of what the kernel does.
• The kernel's function prototype.
• The description of the inputs and outputs.
• An example of using the kernel.

In Tom's branch, all kernels have this header and basic description. There are a few FIXMEs in the code for more information, and almost none have actual examples, and this will need to get filled in.

Tom is also working on a new project to provide the simplest possible example for all blocks in GNU Radio. These examples are all GRC files, and where applicable, visualization tools and interactive tools like sliders so we can both see what's happening with the signal and play with the parameters. We want this to stand alone to help people explore the blocks and how to work with them, and it should even become the basis for some unit testing that we want to do for GRC.

Sylvain

• RFNoC fosphor:
  • Debug some ethernet issue on RFNoC
  • First version producing a result
  • See: http://i.imgur.com/49PJS3c.png
• Work on gr-gmr1
  • Previous version has issue with tagged stream length and buffer size control (i.e. can't control input buffer length), especially when using non-tagged stream aware for normal processing (like filtering / resampling) on those bursts.
  • Move to a model where along the signal processing chains, all bursts have 'sob' and 'eob' tags (and possibly zero-padding in-between to flush histories).
  • Create a block that, at the end of the processing chain converts those sob/eob pairs into tagged stream. (and this block controls its output buffer size, so no problem even with long bursts)

Philip

• Embedded workflow docs
  • cleaned up, working with e310, uhd, etc.
  • docs are current on website
• modes_rx running on e310 with cross compiling

Nico

• Better support for Python Blocks
  • tool for helping people get up to speed

Vlad

• OFDM - script to use OFDM blocks with channel to test different parameters

Matt

Matt worked on RFNoC stuff.

We studied the latency problem when continuously streaming and idle tone. When filling space in the output, we fill up the buffers with whatever idle info we use (0's, 1's, random numbers, etc.). The thought is to create a new block that uses timing information from a USRP to properly gate the idle tone injection into the flowgraph. We would define a maximum tolerable latency and use that to manage how full the buffers are allowed to get before we mux in the actual signal of interest.

• Tom created a user trigger block that just generically posts a PMT-formatted message when the user triggers it somehow. Currently, this is done with a check box GUI element. When the user clicks the check box, the trigger block posts a PMT_T message. When the box is unchecked, it posts the PMT_F message. This message is used with the Copy block's enable, or "en," port, which uses a boolean value to enable or disable copy (note: turn on the Show Msg Ports in the Copy block's properties).

• Martin DvH created the idle mux block that will take in the data stream on one port and the idle info stream on another port as well as a stream from a UHD receiver to help with timing information. It would then make sure that the data stream is the switched-in stream when data is made available within the user-settable latency.

• Matt built the flowgraph that tests and shows off the idle delay problem.

• We have not yet put it all together to see if it will work.

We also talked about the two-clock problem between, say, a radio receiver and an audio sink. We thought the problem was very hardware and application specific, but there were some more general thoughts about how we could possible handle this. Potentially inside of a special audio_sink block. Nothing was really scheduled to attack this problem directly, though.

Martin

Martin worked with Matt and Tom on the RFNoC stuff. (See Matt's description above).
He also worked on getting further with his work-in-progress passive radar demo's using GPS and DVB signals. This is still far from finished, but it helps to be able to focus on it for a few days.