Brigade App

02/04/2024

An in development app which connects people during times in which traditional communication such as cellular and wifi are not functioning

Introduction

In the modern world perhaps the most important tool of the human race is communication. In disaster situations it’s one of the first systems to become damaged or unusable in disaster situations. The goal of the app that I’m designing, currently named Brigade, is built to fill the gaps left by traditional communication systems in uncommon cases, like in disaster situations. After traditional communication systems like cellular and wifi are damaged, it’s extremely difficult for government aid to make its way to areas in need, and for first responders to be directed to areas in need of help, or to provide more information about affected areas, etc. it's that gap which Brigade is intended to fill. The hope is that it could make use of mobile phones in the area which have Bluetooth capability to create a communication web that would pass messages along until they can be collected to web servers, or until they are passed to first responders or other users who are also outside of traditional communication.

User Flow

The main idea of the app is to be usable quickly and efficiently while the user is in distress and for this reason when the app is opened the user will be presented with two buttons which fill the screen, with a red button covering 50% of the screen asking the user if they need help and a smaller green button allowing the user to decline help.

If the user selects the option to request help a bluetooth signal will be advertised with Bluetooth Low Energy (BLE) and will be picked up by any phone within 30 feet which has the app running or installed. When it's picked up the signal will be passed to as many phones as possible in the same way, except the phone that originally created the signal will be ignored. Using this method for transmitting data, a max range of 30 ft becomes a lot more useful over distances. If a phone can’t find any nearby phones it’ll continue to advertise the signal and then once a new phone becomes available it’ll transmit it. In larger collections, a ton of distress signals could be sent in quick succession once a connection between two phones becomes available, with each keeping a sort of ledger with which signals they’ve already received.

Every signal sent across the network will contain the id of the sending device and a geographic location. When creating this I thought about making use of the iBeacon which is a feature of iPhones, creating a sort of GPS beacon broadcasted across bluetooth, but one worry is cross compatibility. There is a google version of this, but one development issue is that the processing would potentially be different, meaning I would need to create two “paths” for an incoming signal to follow, one for if it's apple the other if it’s android. Also I think it would be easier to ensure that the bluetooth signaling is as controllable as possible, I believe it would be easier to process and breakdown a signal that I designed v.s. a precompiled one.

If the user selects that they don’t need help, which requires them to press and hold a button to avoid any misclicks, they'll be able to see which help signals they are receiving. They’ll also be able to post in blog-like fashion on a feed that contains longer help requests intended for those who are able to to find ways they can help their community. That might take the form of collecting water, helping make and collect food, etc. This feed could also be localized, so that people can focus on whatever neighborhood or block they’re on. Network & Density

When considering a system that relies on a certain amount of phones existing in an area, its important to question how stable this system is. The ability of this app to perform its function essentially rests on the density of connected and usable phones within an area. Firstly, I considered a best case scenario, a U.S. city in which 95% of the population have phones, which is unsurprisingly a low estimate according to a study done by pew research. Next, I chose Boston as an example city just to have some concrete numbers, but the population density is about 13,976.7 per square mile in 2020. This comes out to an average of about 2.5 phones per square foot. That doesn’t sound like a lot, but the maximum range of a phones class 2 bluetooth antenna is 33ft. This means at any given time there is a potential 82 phones within range. This number is more realistic when we consider that only a fraction of these phones will actually have the app and be usable during disaster situations, but if every phone has at least 2 usable phones in range, it can be a valuable member of the network. Next let us consider a suburban environment in which the network will struggle more. Bloomberg & many sources seem to define a suburb as being relatively close to a city and having a density of approximately 1,800 to 2,000 people per square mile. Applying the same math as before, we get about 11 phones within range. While this will certainly cause gaps in the system, it still has a lot of potential to be effective, even in this “worst case scenario”.

Issues & Solutions

The primary issue with a system such as this one is the fact that gaps will always exist, and overcoming those gaps has multiple solutions that could even potentially work in tandem.

Case Study: Marblehead (Hometown) Flood

To understand the first of these gap issues, lets take a look at my hometown, it has an island connected by a long thin, unpopulated causeway. This creates a networking problem, in which both two separate networks are formed, but if the problem is for example a flood which has separated the two and taken out cellular connection & wifi then there is no way to get that important information from the island. Instead of needing to restore cellular first, cheap small buoys could be dropped, spaced ~30ft from each other, which contain BLE capability, and then bridge that gap. Even though the farther reaches of the island are not connected directly to the mainland, their signals are able to reach over.

Another potential solution is the handshake system, in which as the users of phones move around, new connections will be made available. By taking advantage of these momentary opportunities, a much less dense area can be covered utilizing the movement of people. One issue with this is fears of battery life and the effects of constant advertising but bluetooth low energy (BLE) has come far enough that it is unlikely this will be a significant enough issue. Variance Correction & Navigation

Another issue with this system is that in most smartphones, the internal compass is not very accurate. They are designed to account for the magnets within the smartphone that may throw off readings, but when in a potentially unsafe situation such as a flood or earthquake while infrastructure is damaged, it’s important to understand how to check and correct for potentially faulty readings, as smartphone compasses can be off by up to 15 degrees.

We can determine the variance by finding the total distance to the target, then traveling a portion of that total distance and finding the new distance to the target. If the new distance is not equal to the total - portion traveled, then we can use trig to find the original angle that we were off by, then create a new angle to the target which accounts for that original variance angle. us. One issue with this solution is that it relies on an accurate gps system, which the iphone does not necessarily have. For this reason we must find a way to determine a direction accurately and dynamically, in a way that adjusts for these multitudes of potential errors. This problem generally points to needing an implementation of Kalman Filtering. Kalman filtering is essentially just a mathmatical way to figure out with some degree of certainty, the unkowns of a system even when the knowns or measurements are imprecise and/or uncertain.