Difference between revisions of "DisasterRadio"

From Sudo Room
Jump to navigation Jump to search
Line 1: Line 1:
This page attempt to document the low-bandwidth disaster recovery mesh (DisasterRadio).
= Introduction =


= Resources =
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).


*[https://www.cgran.org/wiki/Projects List of awesome GNU Radio projects]
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.


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


The command:
== Using the DisasterRadio mesh ==


  sudo uhd_find_devices
=== Smartphone based communication ===


Should list the gain range for the TX or RX frontend of choice.
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.  


E.g. for the WBX TX frontend you get:
One of the types of locations displayed on the map interface is receive/charge stations and transmit stations.


  Gain range PGA0: 0.0 to 25.0 step 0.1 dB
Transmit stations are exactly like receive stations, except there


Make sure you're not looking at the gain range for TX when you're looking to receive or vice-versa, as the won't necessarily be the same!
=== Laptop based data reception ===


= GNU Radio UHD device selection =
Before the disaster (hopefully before) people get/buy a little water-proof baggie containing:


For a USRP 1 this should be in the form: serial=<hex_serial>. E.g:
*A USB stick.
*An RTL-SDR stick.
*An antenna.
*A booklet with instructions for how to boot from USB for various computers.


  serial=24e6b31a
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.


To find device serial run:
= Status =


  sudo uhd_find_devices
== Transmitter ==


You're looking for output that looks like:
Prototype using a USRP1 with a WBX board and a GRC sketch is implemented and transmitting data.


|    _____________________________________________________
== Receiver ==
|    /
|  |      Mboard: USRP1
|  |  serial: 24e6b31a


To set the sub-device (the daughterboard and channel) use the format:
GNU Radio python script using RTL-SDR and DQPSK implemented but not yet able to receive data.


  <slot_name>:<daughterboard_frontend_id>
== Receive/charge/transmit station ==


E.g:
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.


  B:0
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.


This slot_name and daughterboard_frontend_id are also findable with the command:
== Android app ==


  sudo uhd_find_devices
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.


The output you're looking for looks like:
Also working on porting scuttlebutt data synchronization.


|  |    _____________________________________________________
== Bootable USB stick with customized distro ==
|  |    /
|  |  |      RX Dboard: B
|  |  |  ID: WBX, WBX + Simple GDB (0x0053)
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Frontend: 0
|  |  |  |  Name: WBXv2 RX+GDB
|  |  |  |  Antennas: TX/RX, RX2, CAL
|  |  |  |  Sensors: lo_locked
|  |  |  |  Freq range: 68.750 to 2200.000 Mhz
|  |  |  |  Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|  |  |  |  Connection Type: IQ
|  |  |  |  Uses LO offset: No


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


|  |  |      RX Dboard: B
== Offline map ==


and:
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.


|  |  |  |      RX Frontend: 0
== Documentation ==


Together making up the B:0.
Is in a sad state. I am working to remedy this situation ([[User:Juul|Juul]] ([[User talk:Juul|talk]]) 17:10, 13 September 2013 (PDT))


== For command-line python scripts ==
= DisasterRadio wiki pages =


For command line scripts, device and sub-device is often specified with the --args and --spec arguments. E.g:
*[[DisasterRadio/SDR|SDR software]]: GNU Radio, etc.
 
*[[DisasterRadio/SDR|SDR hardware]]: RTL-SDR, USRP, transmitter design.
  my_script.py --args serial=24e6b31a --spec B:0
*[[DisasterRadio/SDR|Android app]]: The beginnings of the android app.
 
This syntax may vary from script to script, but this is the most common syntax.
 
== For GNU Radio Companion ==
 
For the "UHD: USRP Sink" in the latest version of grc (as of this writing) the field "Device Addr" would be set to e.g. serial=24e6b31a and the field "Mb0: Subdev Spec" would be set to e.g. "B:0".

Revision as of 16:10, 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.

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))

DisasterRadio wiki pages

Retrieved from "https://sudoroom.org/mediawiki/index.php?title=DisasterRadio&oldid=5593"