Difference between revisions of "DisasterRadio"

From Sudo Room
Jump to navigation Jump to search
Line 12: Line 12:
*[[DisasterRadio/SDR hardware|SDR hardware]]: RTL-SDR, USRP, transmitter design.
*[[DisasterRadio/SDR hardware|SDR hardware]]: RTL-SDR, USRP, transmitter design.
*[[DisasterRadio/Android app|Android app]]: The beginnings of the android app.
*[[DisasterRadio/Android app|Android app]]: The beginnings of the android app.


== Using the DisasterRadio mesh ==
== Using the DisasterRadio mesh ==

Revision as of 18:00, 13 September 2013

Introduction

DisasterRadio uses cheap software defined radios (SDRs) to create a low bandwidth disaster-recovery mesh. Disasters being either natural (e.g. earthquake) or man-made (e.g. extreme censorship scenarios).

The goal of DisasterRadio is to allow people to communicate short text messages that optionally include GPS coordinates in the event of a disaster, both within the affected area and to the outside world. A map-based interface allows people to find resources such as medical facilities, cell phone charge stations, food, shelter, etc.

The mesh will have many receive-only nodes and fewer transmit-capable nodes, due to the much higher cost of transmit-capable SDRs.

Pages


Using the DisasterRadio mesh

Smartphone based communication

Smartphone receive and charge stations will be set up at houses with existing off-grid power (usually solar). These stations will be publicly accessible from the sidewalk. People can charge their phones by hooking them into one of the USB outlets and connect to a wifi access point that allows them to install the DisasterRadio application. The application contains a map-based interface with an offline map of the local area. Every time the phone running the DisasterRadio app comes into range of a receive station it synchronizes over bluetooth (to conserve power) with the receive station and the map displays up to date locations for services and points of interest, while a list interface shows non-mapped data. The user is free to move away from the receive station and remains able to browse the latest data they receive. If two phones running the DisasterRadio app come into contact, they will synchronize their data, ensuring that both devices have the latest data.

One of the types of locations displayed on the map interface is receive/charge stations and transmit stations.

Transmit stations are exactly like receive stations, except there

Laptop based data reception

Before the disaster (hopefully before) people get/buy a little water-proof baggie containing:

  • A USB stick.
  • An RTL-SDR stick.
  • An antenna.
  • A booklet with instructions for how to boot from USB for various computers.

The USB stick contains a GNU/Linux distro that boots straight into an app that starts receiving emergency info from the DisasterRadio mesh and displays it on the map. The USB stick already contains a map of the local area.

Status

Transmitter

Prototype using a USRP1 with a WBX board and a GRC sketch is implemented and transmitting data.

Receiver

GNU Radio python script using RTL-SDR and DQPSK implemented but not yet able to receive data.

Receive/charge/transmit station

A Beagle Bone Black is running Debian and GNU Radio and talking to an RTL-SDR device. Compiling GNU Radio was problematic, but we figured out the right parameters and workarounds and it seems to be taking full advantage of the NEON FPU accelerator.

Work remaining: Turn this into a minimal image that can fit onto the 2 gig of internal memory on the beagle bone black so we don't have to pay for extra SD cards. Make a weather-proof box for it. Add a bunch of cheap 5v supplies (or one big one, but may be more failure-prone), a way to mount it in a theft-proof, an LED-lit sign to let people find it at night, and a long outdoor extension cord.

Android app

Bluetooth scan for devices implemented. Connecting to other DisasterRadio devices implemented, but having trouble connecting to python-bluez examples and currently troubleshooting. Could be because python-bluez is unmaintained since 2009 or because the bluetooth usb sticks we have just plain suck.

Also working on porting scuttlebutt data synchronization.

Bootable USB stick with customized distro

Work has not yet begun. Thinking of implementing the GUI using a full screen web app.

Offline map

We have successfully generated local-area-only maps using TileMill and the Open Street Map data. We need to find a way to only supply phones with the local area relevant based on receive station location without having to re-generate the tile-sets, and we should figure out how to automate the process.

Documentation

Is in a sad state. I am working to remedy this situation (Juul (talk) 17:10, 13 September 2013 (PDT))