(around the 23’45” mark)

You can’t just flip a switch on your baby monitor, and turn it into something that interferes with air traffic control signals. But powerful software-defined radios can change from baby monitor to emergency services dispatcher to air traffic controller just by loading and executing different software, which is why…

Video and transcript

This is yesterday’s message from Josh Blum to the discuss-gnuradio mailing list announcing some interesting work he’s done:

All the work is on my next branch, see here:
http://gnuradio.org/cgit/jblum.git/log/?h=next

##################################################
# Write gnuradio blocks in python
##################################################
This work, formally known as grblock was on my github. The project has
now been integrated into gnuradio-core on my next branch.

So basically, all of the facilities of a gr_block are now available in
python. Overload work, scheduler integration, stream tags, and also the
message passing I will mention below. See this wiki page for relevant
docs and examples.

http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython

##################################################
# Useful message passing
##################################################
I have create a message passing framework that fits in with the existing
gnuradio. Basically, each block can accept messages, and can post
messages to other blocks. The coordination of who can post messages to
who is handled by the the msg_connect() call which is the message
equivalent of the connect() call used on streams.

Messages can be used to pass arbitrary serialized data between two
blocks. The unit of message passing is the same as the stream tags,
which is the pmt library. See gruel/pmt.h for basic usage.

I have also extended the pmt blob type (memory container type) to manage
memory. This allows blocks to pass messages with bulk data; effectively
allowing for a mac/packet layer inside of gnuradio.

##################################################
# New blocks - gr_blob_to_stream/gr_stream_to_blob
##################################################
These blocks provide a cross over between the streaming domain in
gnuradio and a kind of packet-based stream of message blobs.

This is useful for testing the various blocks mentioned below:

##################################################
# New blocks - gr_blob_to_socket/gr_socket_to_blob
##################################################
These blocks read and write sockets (TCP or UDP) and output/input a
stream of message blobs. This has a few advantages of the current UDP
source/sink:

- respects packet boundaries, each blob corresponds to a packet.
Consider integration with gstreamer or VLC's udp socket streamers
- implements TCP as well, which can offer backpressure when
communicating between flowgraphs

##################################################
# New blocks - digital packet framer/deframer
##################################################
Basically that horrid packet framer in tunnel.py. I took the same packet
utils, its the same code, but the important distinction:

- the packet framer input messages
- the packet deframer outputs messages

The blocks are in grc if anyone cares to play.

##################################################
# New blocks - tuntap
##################################################
A tuntap interface with message input and message output, also available
in grc. This is the thing that implements the tunnel in tunnel.py Sorry,
linux only, unless someone wants to take a whack it for mac os, or
windows (however you do that).

##################################################
# Conclusions
##################################################
The message passing and making blocks in python work supersedes the need
for the old style message queues as the gateway between c++ and python.

Someone could make the equivalent of tunnel.py in GRC using the new
packet framer/deframer and tuntap block. The implementation would be
clearer and smarter.

Feedback and testing is welcome!
-Josh

This how-to describes the step-by-step installation process of GNU Radio 3.3.0 on a MacMini running MacOSX Server 10.6.3 “Snow Leopard” through MacPorts.

Problem 1: MacPorts requires XCode

The MacOSX Server comes with a DVD containing XCode, but the MacMini I got has no DVD drive. So I tried the “App Store” (available only after the system updates and a reboot). The thing is, the App Store contains only XCode 4.x, which requires MacOSX 10.7! So you have to register for a free “Apple Developer” account at http://developer.apple.com/ (lengthy process) and download the 4.5GB “XCode 3.2.6 and iOS SDK 4.3″ .dmg disk image. During installation, make sure “Unix Development” and “System Tools” are selected.

Problem 2: Corporate firewall blocks rsync

The first thing to do after installing MacPorts is to “sync”, i.e. download the repository contents by running the command sudo port sync. In my case the command failed and after some investigation I found out my corporate firewall blocks the rsync protocol (TCP port 873). At moments like this I’m glad I have an always-on, ssh-accessible machine at home :-) The workaround is to use the less efficient http method by editing /opt/local/etc/macports/sources.conf as described here: PortTreeTarball.

After that, just run sudo port install gnuradio and you’re done!

Reference: http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall

Building the GIT tree

If instead you want to build from the latest git tree (e.g. to be able to use UHD), here’s how:

1) Install git, wget and get the sources
sudo port install git-core
git clone http://gnuradio.org/git/gnuradio.git gnuradio
git clone http://github.com/EttusResearch/UHD-Mirror.git uhd
wget http://files.ettus.com/uhd_releases/master_images/auto/current.tar.gz
2) Install dependencies
sudo port install libtool gawk pkgconfig zlib automake swig-python \
  guile cppunit fftw-3-single py26-numpy boost py26-wxpython \
  gsl sdcc doxygen libusb-legacy
3) Build & install uhd/host and extract the UHD pre-built images
cd uhd/host; cmake; make clean; make; sudo make install
cd ../../; tar xf current.tar.gz; sudo mkdir -p /usr/local/share/uhd/images; sudo mv UHD*/share/uhd/images/* /usr/local/share/uhd/images
4) Use glibtoolize

You need to make the bootstrap scripts of gnuradio use glibtoolize rather than libtoolize. Do this also for any subproject bootstrap scripts (at the time of writing, this was necessary only for  volk)

5) Build & install GNU Radio
./bootstrap; ./configure; make; sudo make install

These are the steps for upgrading an old USRP2’s SD card for the UHD driver:

  • Download, build and install GNU Radio using the build-gnuradio script.
  • Download pre-built FPGA and firmware images from http://files.ettus.com/uhd_releases/master_images/ (we only need usrp2_fpga.bin and usrp2_fw.bin
  • Install python-tk (required by usrp2_card_burner_gui.py)
  • Run sudo usrp2_card_burner_gui.py, choose the two .bin files above. It will automatically choose the correct device (/dev/mmcblk0)
  • The IP addresses should be: laptop: 192.168.10.1, usrp2: 192.168.10.2

Reference: http://files.ettus.com/uhd_docs/manual/html/usrp2.html

The 7th Karlsruhe Workshop on Software Radios will be held on March 7/8, 2012.

Topics of interest include (but are not limited to):

  • antennas,
  • radio frontend architectures,
  • analog to digital conversion,
  • hardware and baseband processing,
  • cognitive radio and cognitive networks,
  • dynamic spectrum access,
  • green radio communications,
  • regulation and standards.
=====================================================

New Product Announcements from Ettus Research

=====================================================

We are very excited to announce the immediate availability of the
latest low cost Software Radio product from Ettus Research, the
USRP(tm) B100.  The B100 has the following features:

- USB 2.0 interface
- Xilinx Spartan 3A-1400 FPGA
- Compatibility with our entire daughterboard family
- Fully supported by UHD drivers
- Dual 64 MS/s 12-bit ADCs
- Dual 128 MS/s 14-bit DACs
- Onboard TCXO for precise frequency control
- 10 MHz and 1 PPS inputs for external references
- Flexible clocking from 10 MHz to 64 MHz
- 8 MHz of RF bandwidth with 16 bit samples
- 16 MHz of RF bandwidth with 8 bit samples

The price is $650 each, and the B100 is in stock and ready to ship.

=====================================================

The USRP E110 has a larger FPGA (Spartan 3A-DSP 3400) than
the E100, but is otherwise the same.  This is perfect for those who
wish to offload DSP operations from the main ARM processor.

Both the E100 and E110 are now fully compatible with the GPSDO.

The price of the USRP E110 is $1500 and the E100 is $1300.
Both the E100 and E110 are in stock and ready to ship.

=====================================================

As always, you can purchase all of our products through:

    http://www.ettus.com/order

and you can contact sales@ettus.com if you have any further
questions.

Thanks,
Matt Ettus
President, Ettus Research LLC

You can find the presentation slides from the GNU Radio Conference 2011 here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/GRConf2011

Follow

Get every new post delivered to your Inbox.