Wirelessness

( proposed by Roel Roscam Abbing + Dennis de Bel)

When speaking about invisible technologies radio is perhaps both the most invisible and yet the most present. At any given moment the air is filled signals ranging from cell phone packets, the chatter of bus drivers, commercial radio stations, wireless internet modems, airplane tracking signals, satellite broadcasts and much much more. The radio wave has interesting properties, signals can propagate across the earth, reach us from outerspace and transcend political borders. These signals, while physical and legistlated, are difficult to ‘own’ and in a way the ‘hertzian space’ can be interpreted as a commons, like the air we breathe and the water we drink.

Radio now is an ‘old medium’, as such is now unaffected by the promises and expectations that charactarize ‘new media’. Utopias have been replaced by (capitalist) realisms and to a large extent radio has left our space of imagination. Alternative and subversive radio practices have diminished, pirate radio for example gave way to internet streaming stations in many countries.

At the same time it is radio technology that lies at the base of newer developments and concepts like the internet of things, smart cities, distributed sensor networks and their implied modes of governance. So while they might no longer lie at the focus of our attention, wireless technologies still have strings attached to them.

The wireless track will have two main strands. One is to introduce and open up a relatively new set of FLOSS tools; SDR (Software defined radio). The track will be a basic introduction into radio and to these SDR tools. What are radio waves, how is information written to them, how are they organized spatially and legally across the spectrum? (What is the spectrum?) How does SDR differ from other radio? What interfaces are used and what do they tell us? How do these tools fit within in a FLOSS workflow? How do I compile the unofficial multimon-ng fork on my debian x86 system?

The second strand will be discourse on radio infrastructure. Both radio as an infrastructure, and the infrastructure of radio. That means identifying not just the physical towers, hardware etc but rather also taking into account the protocols, the laws and practices that constitute the whole apparatus.

What is made invisible or what is conciously not mapped can be read as a way to enforce control. Think of sea maps that don’t include depth measurements, yet are available for a few. Common maps (or interfaces for that matter) represent powerstructures by emphazising some mechanisms and leaving out others. Making new maps can be a way to reveal them and open a space for critique or intervention. As such the discourse on radio infrastructure will also revolve around making maps, whether visual, textual, physical or pads.

Radio tools

Software defined radio (SDR)

The main idea behind SDR is that to replace components in radios that are traditionally hardware (such as filters, mixers and amplifiers) by software algorithms. An SDR thus receives ‘everything’ it can receive and sends that to the computer to be processed.

SDR recently became popular and affordable through RTL-SDR. RTL-SDR uses DVB dongles based on RTL chips Depending on the chipsets SDR can receive roughly between 22mhz and 2200mhz.

The list of supported RTL chips and tuner frequency range (source):

Other SDR hardware

Buying hardware
if you wish to buy one of the RTL-SDR dongles make sure the DVB device has one of the chipsets listed here

Software for SDR (sorted by interface)

There are various programs to interface with SDR both GUI and non-gui, here’s a brief description.

The Flowchart

GnuRadio + GnuRadio Companion

GnuRadio is a set of libraries for doing SDR. GQRX is built on top of it. Mostly C++ but with a with a lot of python bindingings

GnuRadio Companion is a visual programming tool (think: pure data / maxmsp interface) to control the SDR on a pretty low level. It has quite a steep learning curve but it is extremely powerfull. The software allows to use ‘blocks’ of various signal processing functions and connect them together. The blocks are then ‘compiled’ to a python script.
These blocks can also be modified or expanded easily withing the GRC by just writing more python to them. It’s a very easy way to create specific/custom GUI SDR programs.
Some examples: https://github.com/argilo/sdr-examples

!--![](http://stuff2233.club/~arra/gqrx/GRC-plus-compiled-output.png)--

A screenshot of GRC with the flowchart on the left and the ‘compiled’output on the right.

The Waterfall

The typical interface for SDR is the so-called waterfall, which is a spectrogram of the signal to noise ratio on a slice of the spectrum, plotted in time. Usually showing blue as the noise floor and any signals als yellow/red/. As time passes the past signals scroll downwards like a waterfall. This allows one to visually discover signals, even after they have stopped transmitting, rathter than having to be tuned in at the right time to hear them.

GQRX

a GUI receiver that is easily installed on your favorite distro or OSX. Uses The Waterfall as a way to visually represent activity on the radio spectrum. apt-get install gqrx-sdr

There are however some downsides to the Waterfall, the slice of spectrum that you can plot is limited to the native bandwith of the SDR receiver (in the case of RTL-SDR this is usually around 8mhz). At around 20 seconds or so, the amount of time that gets visualized is rather limited. That means it is also easy to ‘miss’ transmissions if you didn’t see them in time, or if they broadcast very sporadically. (from here).

The Commandline

There are some command line tools for SDR. Most of these generate raw datasets which then need to be piped into either sound players or plotting software. One of the big advantages of cli radio software is that it is often light enough to be run on old or not so powerful hardware like the RaspberryPi.

rtl_power

a tool which can log the signal strenght on any given frequency for any given amount of time. The data can be used to make plots.

To take a 10 minute measuring of FM frequencies between 88Mhz and 110Mhz in steps of 8Khz and save to output.csv: rtl_power -f 88M:110M:8k -e 10m output.csv To make a visual plot have a look at this script.


A plot of airport communications made with heatmap.py

rtl_fm

general purpose analog radio demodulator. Outputs digital audio data which can be piped into a variety other tools. Tune to 103.1mhz FM and pipe into Sox to hear the audio: rtl_fm -M wbfm -f 103.1M | play -r 32k -t raw -e s -b 16 -c 1 -V1 - Additionally the digital audio data can be piped into software used for demodulating signals such as digitally encoded speech etc

Both are packaged into the rtl-sdr software package, so to install them like so sudo apt-get install rtl-sdr

RTLSDR-Airband

Designed for monitoring airtraffic signals. The main feature is that it allows for monitoring up ot 8 different signals simultaneously per dongle and also supports using multiple dongles. Also allows to convert audio to MP3 or stream to Icecast or SHOUT. As with other SDR applications have a look at the forks for more features etc.

On x86 linux has following dependencies (source):
libmp3lame-dev libvorbis-dev libshout-dev libfftw3-dev librtlsdr

https://github.com/microtony/RTLSDR-Airband <- original repo
https://github.com/szpajder/RTLSDR-Airband <- usefull fork (x86 install instructions)
.

Decoding

Increasignly many signals that can be picked up are not analog but rather digital. An analog signal can be easily ‘heard’ and identified by a listener, think of FM broadcast radio or walkie talkie signals. Digital signals however are encoded as they represent binary information, which to the ear can often sound like noise but with the help of additional software can be decoded into audio or data.

Some of the decoders are gui based and directly take input from the sound card while others are only command-line based and read from stdin or from a file.

Below an overview of (multi-purpose) decoders for common signals:

MINIMODEM
http://www.whence.com/minimodem/
A general-purpose software audio FSK modem which can decode and encode various standard FSK protocols such as Bell103, Bell202, RTTY, NOAA SAME, and Caller-ID.

It expects (audio)input from a file or stdin:rtl_fm -M nfm -f 14467.3K | minimodem -r -a rtty

Minimodem can also be used to encode: man minimoden | minimodem -t 200
This encodes the minimodem manpage in 200 baud FSK audio.

MULTIMON NG
https://github.com/EliasOenal/multimon-ng

Can be used to decode the following transmissionmodes:

Since multimon-ng is being actively developed it might be useful to regularly check for updates. Also have a look at some of the forks, since these might support other encodings such as FLEX/P2000

Also expects input from a file or stdin:
rtl_fm -f 157.950e6 -g 100 -s 22050 -l 310 - |./multimon-ng -t raw -c -a POCSAG512 -a POCSAG1200 -a POCSAG2400 -a SCOPE /dev/stdin This was used to receive signals from a pager and decode them.


In this example GQRX (right) is used to tune into 169.6Mh using a Wide FM filter. The resulting audio is then streamed over a local server. In the terminal window on the left nc (‘netcat’) is used to listen to the local server and pipe the output into sox, which converts the audio to the required sample rate and pipes it into multimon-ng. For more info on streaming from GQRX check this out.

DSD (Digital Speech Decoder)
https://github.com/szechyjs/dsd

Some signals include speech that has been digitally encoded. DSD can decode these protocols and synthesize the speech.

Supported protocols (source + details)

Use it by piping audio into the application:
rtl_fm -f 157.950e6 -g 100 -s 48000 -l 310 - | dsd -i /dev/stdin -fa -w output.wav

Find a detailed description of options here.

FLDIGI
Fldigi (Fast Light Digital Modem Application) is a cross-platform modem (=MOdulatorDEModulator) program that supports most of the so called ‘digital modes’ (signals generated on a computer, usually by keyboard input, and then sent to the radio) used on the amateur radio bands (source).

This software is specifically aimed towards HAM radio, which is evident throughout the interface.

This software uses the Waterfall interface. To demodulate, use the filter to tune in to the frequency of the signal and select the right protocol. Fldigi can also be used to transmit messages using the modulator.

The following encodings are supported (source + additional details):

There is an extensive user manual which can be found here

SIGMIRA
http://www.saharlow.com/technology/sigmira/

A standalone GUI application. Included in this list because it seems to be the only one that includes support for decoding protocols like NATO STANAG 4285 (military) and the ‘Slot Machine’ (it sounds like one) by the Japanese Navy.

Linux packages are available but not supported.

Haven’t tried it.

OSMOCOM decoding projects

There are a few initiatives under the umbrella of OSMOCOM (Open Sources Mobile Communication) that aim to reverse engineer commerical protocols. Most of these projects include software to demodulate the signal and forward te demodulated packets to wireshark

TETRA
http://tetra.osmocom.org/trac/
Terrestrial Trunked Radio, used for expensive walkie talkies (b/c encryption) by police, security etc. Works similarly to cell(phone)networks with base stations that relay to other basestations

P25
http://op25.osmocom.org/trac/wiki

“ APCO Project 25 is the digital communications standard used by many police and emergency services throughout the world.” source

GSM
https://svn.berlin.ccc.de/projects/airprobe/ (self-signed)

Decodes GSM and can forward the packets to wireshark. Also has the ability to decrypt (altough not in realtime).

Extremely detailed write-up on how to decode GSM with rtl-sdr .

DVBT
https://wiki.archlinux.org/index.php/DVB-T

Encoding vs Encrypting

The tools described above are used for decoding, which is not the same as decrypting. Decoding is the process of turning the modulation of the carrier signal into information, which might still be scrambled or encrypted. In the case of protocols like TETRA, GSM etc the signals can be decoded so the packet headers become legible, but the content of the packets themselves remain encrypted.

Calibratring your SDR
https://github.com/steve-m/kalibrate-rtl
Radio is data
but also possible with HackRF
If you
https://wiki.hacdc.org/index.php/Notes_on_Soundmodem

Legality

http://www.bipt.be/public/files/nl/1011/939_nl_scannernl.pdf

Scanning the spectrum, listening to anything other than CB (citizen’s band), Broadcast radio, or amateur radio frequencies without consent is illegal. It is not allowed to own equipment with other frequencies pre-programmed and when caught in the street it can lead to fines etc.

Interestingly scanning is illegal in Belgium because of ‘privacy’ concerns. Yet the radio frequencies one isn’t allowed to listen to are either owned by government or companies. It is also not clear how privacy applies to an increasingly pervasive scenario where you have machines talking to machines.

Pointers for Infrastructure

Online information:

http://radiontvangst.freehostia.com - Belgian resource for ‘scanners’
Dutch forum for radio scanners, which has a subforum about belgium
http://frequentiedatabase.tk/ - Tool made by scannerforum.nl (look for a placename to find frequencies)
Brussels map about GSM antennas

http://seeingnetworks.in/nyc/

Possible approaches and connections

Radio spectrum walk

A city walk as one of the practical approaches into the subject. Scanning the spectrum while paying attention at the interplay between wireless technologies and architecture (antenna farms, towers etc), walking around and discovering what’s on either side of the ‘known’ FM-spectrum, identifying that and coupling it to specific technologies or practices. The mapping could happen on site in the street as some sort of ‘war chalking’ exercise. Perhaps in collaboration with the data/network/film city track to be discussed