Difference between revisions of "DisasterRadio"
|Line 64:||Line 64:|
= DisasterRadio wiki pages =
= DisasterRadio wiki pages =
*[[DisasterRadio/SDR|SDR software]]: GNU Radio, etc.
*[[DisasterRadio/SDR |SDR software]]: GNU Radio, etc.
*[[DisasterRadio/SDR|SDR hardware]]: RTL-SDR, USRP, transmitter design.
*[[DisasterRadio/SDR |SDR hardware]]: RTL-SDR, USRP, transmitter design.
*[[DisasterRadio/|Android app]]: The beginnings of the android app.
Revision as of 16:12, 13 September 2013
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.
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.
Prototype using a USRP1 with a WBX board and a GRC sketch is implemented and transmitting data.
GNU Radio python script using RTL-SDR and DQPSK implemented but not yet able to receive data.
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.
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.
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.