Updated: October 18, 2020

Contact: aaronswartzday@gmail.com (or aaronswartzday@protonmail.com if you’d prefer encrypted email) – or DM us at @AaronSwartzDay on Twitter

New hackathon starts November 7, 2020!

We will begin adding new projects to this page soon :)

These projects below are from our last virtual hackathon – but they will be going strong in November too :)

 

New from our June 2020 virtual hackathon:  Our OP25 Guide!

 *****

Aaron Swartz Day and International Hackathon – RF Tech Edition Building emergency networks & local community resources (& more)

For more info contact: aaronswartzday@protonmail.com
or DM @AaronSwartzDay on Twitter

Create an account here for secure whiteboards: https://cryptpad.fr

Start of hackathon: Saturday June 13, 2020
End of hackathon: When we are done ^_^

Projects:

1. OP25 (works with GnuRadio) (GITTER)
OP25 GUIDE (moved to its own page)

2. Emergency LoRa network (low power network)  (antennae, repeaters, phone connectivity and messaging software) (GITTER)

3. Projects for OP25 & the Aaron Swartz Day Police Surveillance Project (ASDPSP) that don’t involve programming

4. The SwartzManning VR Destination

This FAQ will help you get set up to participate!

1) OP25 (works with GnuRadio)

See the new OP25 GUIDE (moved to its own page)

Github of our code for this project: https://github.com/AaronSwartzDay-SSP/op25

GITTER for this project

Debian package for testing: https://github.com/AaronSwartzDay-SSP/op25/tree/master/debian

GOALS:

We are looking for software developers and hardware hackers with software skills to help us:

– tighten up the code
– help with testing it
– writing good docs for it

The code needs to be tightened up in the following ways (that we know of – we will get specifics from the OP25 folks once we contact them):

1. Stable deployment on debian, Ubuntu, and Fedora linux distros

2. Build issues – library compilation issues

3. Cmake breaks during builds a lot

4. Dependency issues (list is in the Cmake file)

We are hoping to put together a little team of people to tighten up the existing code and then go on to make the OP25 code work really well.

First of all, it would be awesome to have a single package that installs this package with the GNU Radio source (https://github.com/gnuradio/gnuradio) all at once, with all dependencies accounted for.

Long Term Goals:

3. 3. 1. Get OP25 into the official repository (Short term goal would be a package that can be installed from our own PPA/repo.)
      2. Feature Request: To be able to input a pre-shared key string to be able to read phase 1 and phase 2 P25.

OP25 install instructions: https://osmocom.org/projects/op25/wiki/InstallInstructionsPage

Note: you’ll need to have GNURadio installed to use OP25:

GNU Radio code: https://github.com/gnuradio/gnuradio

Mac install: https://wiki.gnuradio.org/index.php/MacInstall

PC install: https://wiki.gnuradio.org/index.php/WindowsInstall

OP25 Wiki page (for discussing osmocomm fork): https://osmocom.org/projects/op25/wiki

OP25 “Q & A” page: https://osmocom.org/projects/op25/wiki/QandAs

OP25 Mailing list archives: https://lists.osmocom.org/pipermail/op25-dev/

OP25 Mailing list archives by subject: https://lists.osmocom.org/pipermail/op25-dev/2012/subject.html

Project 25 (P25 or APCO-25) on wikipedia: https://en.wikipedia.org/wiki/Project_25

APCO-25 Page on RadioReference Wiki: https://wiki.radioreference.com/index.php/APCO_Project_25

We analyzed the mailing list traffic & reached out to the group as a whole, explaining how our hackathon might further the project. These are the links that seem most relevant, after reading the wiki and looking through the mailing list. There were three web pages I found where people might look for specific features or bugs to work on:

1. The overview of bugs and features:
https://osmocom.org/projects/op25

2. The task list on the wiki page: https://osmocom.org/projects/op25/wiki

(these were the only tasks not crossed out):

Fix intermittent HDU decode failure

Add DES-OFB decryption support
Add AES-256 decryption support
Add RC4 (a.k.a. Motorola ADP) decryption support
Add P25 Phase 2 Tx support
Add trunking transmit and receive to simulate a live P25 trunking system

3. The FAQ – which contains several issues:
https://osmocom.org/projects/op25/wiki/QandAs

Background on Software Defined Radio:

-software defined radio (OP25) https://en.wikipedia.org/wiki/Software-defined_radio#RTL-SDR

-software defined radio demonstration (Wide-band WebSDR)
from the amateur radio club ETGD at the University of Twentem in the Netherlands: http://websdr.ewi.utwente.nl:8901/

2) Emergency LoRa network creation (antennae, repeaters, phone connectivity and messaging software)

Project Lead: Matteo Borri, Robots Everywhere spiritplumber@gmail.com

Github for this LoRa project: https://github.com/AaronSwartzDay-SSP/LoRa

GITTER for this project

Basically, this network is for the worst case scenario – which doesn’t seem as unlikely as it used to seem – where – after we have lost all internet wifi and even cell phone reception, we could still be able to send text messages to each other over our own emergency LoRa network.

Our network design will utilize a combination of “fixed repeaters” in and outside of buildings and “mobile repeaters” (in people’s pockets and backpacks) to allow for more “hops.”

We will use either bluetooth (BT) or wifi to connect the repeaters to everyones’ respective cell phones – enabling users to send messages across the LoRa network.

Specification for Creating an Emergency LoRa network

Model: We wish to send a message from A to B – from someone’s cell phone, across the LoRa mesh network – through a gateway – to another phone.

We are developing the “stack” to use in our LoRa network:

3. 3. • An open self-healing mesh network using LoRa for SMS like communications.
      • The idea here is to have something that will keep operating without the internet as much as possible. So, for a protest scenario – Folks are in a big crowd somewhere in SF and the cell phone and or internet gets cut, ideally, as many folks as possible would have repeaters in their pockets.
      • low bandwidth low power backup for things
      • Use omnidirectional antennae to boost and send stronger signals (fixed repeaters) and also use mobile repeaters (in people’s pockets and backpacks)
      • The network needs to be designed for an urban environment that is full of interference that will limit range
      • Keep the scope to text messages, and limit the size 255 characters or something. We can always increase the network capabilities later. [LoRa data rate is about 27kbps. it’s not going to handle video. Think the web back in 1991. There are dial-up modems which are faster than this. We can do data streams, but if people saturate the network trying to upload a video (or even an image), everyone is going to suffer.]
      • Solar power or power-harvesting could be used, which would allow buy once, leave alone forever. (If we do that we want to call it CellSol because this is something that we as a society could/should have done in the 90s, so it needs a 90s name).
        
      • reserve some bandwidth for hopping and keep the rest for personal/group use.
      • encryption is done at each end
      • It would be good to leave a UART port open, as well as a config mode switch. Designing a carrier PCB for this module is pretty trivial and members of our team can do it very quickly (a day or so).
      • Eventually we might want the mesh network portion of the stack to be done in smartBASIC on the module, but for now the android/ios app can handle it, and the module is left in bridge mode.
      • We can use either bluetooth or wifi for the “last mile” to the cell phones. We can use both, and if we design the protocol with this in mind, we can let anyone connect to it as they wish. There’s no need to artificially limit any entry point. (Someone could even bridge X-ray to LoRa, if they wanted, as long as they knew the right LoRa protocol to use, or wrote one for it.)

Laird Module or Rasberry Pi:

Due to battery considerations, we’re starting by trying this module from Laird – We went ahead and bought 4 of the modules for preliminary testing ($84 total). https://www.mouser.com/Search/Refine?Ntk=P_MarCom&Ntt=163748224 – it needs little more than a 3.7v battery and USB charging circuitry.

Questions to answer:

3. 3. • What networking layers will be used? (the stack)
      • What software do we need to make that happen?
      • What existing software might be used?
      • What must we write ourselves, since it doesn’t exist yet?
      • We may use some pre-defined libraries, depending on the hardware we decide on.
      • Will be use any existing LoRa mesh networking protocols?
      • Although, in this scenario, the internet would be down, it is still feasible for ad-hoc WAN/LAN networking to exist, and we can leverage something like scuttlebutt as well as interacting with personal devices via wifi to extend the reach to people’s existing devices. Scuttlebutt might be used for saving messages until a phone is within range to download them

GPS Considerations:

Questions:

How realistic is it to use gps, which every phone has, for a common timebase?

Geolocation of nodes would increase efficiency a lot since a packet could be sent only in roughly the right direction, but obviously then there’s the problem of being tracked. (maybe just give a heading?)

Answers:

Yes, you can use GPS for syncing time, it’s a common practice, specifically when needing a common time for encryption.

3. 3. • There are two elements to directionality, just to clarify. You could tell certain nodes not to repeat a packet based on their location and the origin of the packet, which might make sense, (maybe that as what was meant above?) but if a node is transmitting data, it would need an antenna array to be directional.
      • Transmitting data is still omni directional, as directionality of the EM waves is related to the antenna. You can’t say “send these EM waves north but send these ones south” without having a specific type of directional antenna.
      • You can change direction dynamically with an antenna array, i.e. 3-4 individual antennas which work together.
      • That all said, we believe it IS possible to say “This packet needs to go roughly north; i’m south of the originating node, so I shouldn’t rebroadcast it.” And we are trying to work out a way to do it WITHOUT necessarily sharing location data.
      • One option would be to “fuzz” the location to (let’s say) a mile, knowing everyone within a mile is going to receive it anyways. (Agreed: fudging coordinates would be sufficient, but we have do it in a way that they cannot be unfudged though.)
      • • Let’s say you want to send it north, and you’re at latitude 100. You randomly add or subtract somewhere between 0 and 1 mile from your latitude, and broadcast. So let’s say you broadcast with latitude 99.
      • • nodes in the mesh will rebroadcast the packet from latitude 99 and above to get it moving north.
      • • So you get some nodes south of the original node which receive it. They repeat it trying to get it to go north.
      • • Nodes south of them receive it, but they are south of latitude 99 and don’t rebroadcast.
      • • This could actually help the overall mesh since some nodes south of you might get you around obstacles to the east and west.
      • • It really depends how determined the person tracking you is. Once they are within a mile or so, they can triangulate you no matter what you do. And in reality, the more determined they are, the wider that range is.
      • • Really, dropping a decimal point or two off the GPS coordinates would be impossible to recover. It’s increasing the uncertainty in the position which isn’t recoverable from the data alone. Changing a decimal randomly (randomly being the key here, can’t be tied to time of day or existing location, etc) would also work. We could zero out the last n bits of the lat/long. Point being, just offer less information about the location rather than more, but incorrect) data.
      • • The last part is easy. Physical button on the repeater that changes one letter in the name. If it changes when you fiddle the button, you’re good to go, if not not.

Wifi & Bluetooth options & limitations (for connecting phones to the network):

One thing to decide early is BT or wifi? wifi has the advantage that it’s easy for it to serve multiple clients but BT is cheaper energetically. (Note: let’s do both? Question: can we do both at once?)

The problem with using the phones’ wifi and BT is that they have crappy range. LoRa fixes that (we might use something like a Xbee pro but it’s more expensive). https://www.digi.com/xbee

At this point all basic smartphones have gps (but no compass, I find) and bluetooth, so targeting something ancient like android 4 is reasonable.

Perhaps we might use AT commands for configuration, possibly with a pushbutton to avoid command strings being misinterpreted.

Question: can BT basic protocol do multipoint?

Answer: is BLE//WiFi for connecting to the LoRa device from the phone? (yes)

To exchange configuration information or some other purpose? I’m not clear on why multipoint is required, but the answer is “pretty much yes”

BLE has a lot of ways to interact with it. You can advertise a service on a device and people can query it and get information, or likewise send information. You don’t need pairing or any of that which is what would lock two devices to communicating only with each other.

But you need to implement the same protocol on both sides of the connection, since all you get is base64 strings. Of course you could advertise the protocol schema, but that’s really an implementation detail. And it depends what you’re trying to do exactly. When I advertise a service, it has a name and a probably unique ID, but anyone can spoof that, so there’s the issue of trusting the device to which you are connecting.

Although many people are used to treating BT as a serial port, BLE can provide other options. And yes,

BLE/wifi is for that.

Other Important issues & considerations:

3. 3. 1. How are users identified? By an email address? A unique identifier for their phone? (no!)
      2. If an email is sent to a specific person, and they aren’t there to get it, where does it go until they reconnect to the network?
      3. Decisions re: where do messages go? To everyone? or can we address them? How does your device know that a message has been sent to it? Does it say “To X” on it somehow? Does it use an email address? There are a lot of different ways to do this. For example, the internet makes use of centralized domain name servers – so that xxx@gmail.com goes to IP address xxx.xxx.xxx.xxx.
      4. Let’s say the internet is down. I could still connect to my computer, over my router, to a web server that is running. Or using a USB cable even – can be connected to the LoRa network that way – to send a message.
      5. Now the network is “seeing” that LoRa message being sent. Where does it go and how and why? How do we route those messages over LoRa. If there’s a gateway – we can use wifi or bluetooth to connect to other phones on the network. (LoRa gateway connects wifi and LoRa)
      6. We need to design the network to be used by people with their phones (over wifi or BT) – who do not necessarily have a repeater in their pocket, as it is unrealistic to think we can get them made and out to everyone in time. (So let’s get started (!) but still – let’s not count on it.)
      7. So even if there was only 1 gateway, let’s say, at Queerious Labs, downtown on 9th street in SF, all people would have to do would be to go there, get within 300 feet of their wifi (even if the wifi was not connected to the internet at this time) – to get a message across on the network. (Hotspots could potentially work this way too – a phone could potentially connect others to LoRa this way.)
      8. Scuttlebutt can be used this way – where you physically go to a location, such as Queerious Labs, where they are sort of dropped for you at a place, so that when you do re-connect to the LoRa network, you can get your messages.
      9. This is also why connecting to traditional servers in place is a great idea (as described in #1 above) because we can “warehouse messages” and get a shit ton more of storage space on the network. No one can be on the network at all times. Connections will drop, etc. So, this will take fault tolerance considerations into account.
      10. Re: jamming. Can’t someone just jam the shit out of it (answer: yes! The military can do this easily. But that would take THE MILITARY being used against citizens in a genuine civil war kind of scenario that we hope will not happen.)
      11. Remember that LoRa was designed for sensors of IOT and such. re: Pet tracking and kid tracking (and, even Whale tracking!) It was designed for point to point communication.
      12. LoRaWAN is one way to do it. It’s proprietary so it probably doesn’t fit the goals of this project. But maybe it does, someone needs to look into it. There are other protocols. LoRaWAN very intentionally limits how many messages can be sent, and when they can be sent. It’s a timed protocol, and probably wont work well for this since message sending is asynchronous.

However, it offers one model that may have parts we can reuse. It’s very much not a mesh network, for example. We are looking for alternate protocols which fit the goals of the project.

Another possibility: using LoRa to bridge physical gaps between other networks

LoRa could also be great to bridge physical gaps between local, unconnected ad-hoc networks as well, for example, reaching across the bay where obviously wifi wouldn’t. (Not sure if this is in scope, but it’s possible, so worth mentioning).

A first shot at a map of this:

[ LoRa device ]*—*[ LoRa device ]

as well as

[ LoRa device ]*—-[ local LoRa gateway ]—-[ local WiFi/ethernet]—-[local traditional server ]

and

[ local traditional server A ]—[ local LoRa gateway ]—[ LoRa Repeater]—[ LoRa gateway ]—[ local traditional server B ]

“traditional server” here could be warehousing (for example) scuttlebutt messages or web apps to write LoRa messages.

Other similar projects

Disaster Radio: A similar project associated with sudoroom. Might not tick

all the same boxes but is generally in the same vein. probably worth looking at:

https://sudoroom.org/wiki/DisasterRadio

Comments: This looks like more or less the same idea. Note that there’s a LoRa+BT box already out there, but nothing prevents using this hardware stack with it, LoRa is LoRa.

3. Projects for OP25 and ASDPSP that don’t involve programming:

3. 3. • • Install GnuRadio, and then install our Debian OP25 package – and see if it works well and/or what the actual errors messages & build issues are.
        • OP25 install instructions: https://osmocom.org/projects/op25/wiki/InstallInstructionsPage
        • GNU Radio code: https://github.com/gnuradio/gnuradio
        • Mac install: https://wiki.gnuradio.org/index.php/MacInstall
        • PC install: https://wiki.gnuradio.org/index.php/WindowsInstall
      • Look through our Police Surveillance data and help us decide what to file or re-file next: https://www.aaronswartzday.org/asdpsp-alldocs-dec2019/