Protest Phone – Part 1

This is the rough draft of the letter for the Hackaday 2016 challenge with Naim Hilal:

SMAC

Go check out the project!

These ramblings are left here as reference.

Protest Phone is a series detailing the idea, design, and hopefully realization of this idea that has been in my head for months.

As we have seen in numerous recent protests and uprisings, social media and instant communication are crucial to organisation of the group. The means to quickly disseminate information to participants means larger numbers are able to arrive and organize. We have also seen governments and organisations start to realize this, and deploy counter measures, ensuring that protests are stopped before they get started, in a more PR friendly way than force.
What we purpose is a phone that is resilient to both surveillance, trust network infiltration, and jamming. It is also cheap, resilient, and can function without an energy grid. Those last two points are crucial for it to work in actual protest situations. The phone would be used in text only mode for the majority of use cases, with audio and video possible when connected to a normal network, or when priority/reputation is high enough for the user (more on this later)
Lets start with Jamming. The phone uses a mesh network topology where every message sent from each device is packetized and routed by any available route. This protects against a centralized take down of the cell infrastructure, and is somewhat resilient to jamming, as it can route around trouble areas, but it is not totally invulnerable.
To make the phone almost invulnerable to jamming, we turn to the backup RFID sneaker-net system. In heavy jamming situations, users would touch phones together with all their closest neighbors, thereby passing on messages like nodes in a network. This would take roughly 10 hops to get from end to end of a large crowd, so as long as people tap phones ~10 times a minute, communication latency would be fairly low. The power requirement of jamming near range, shielded (by the interlocking bodies of the phone) RFID communications would be so large, they are well outside the range of conventional or military hardware.
Surveillance is the easiest to explain. With a modern, public-private key architecture, encryption of all message contents should be about as secure as currently feasible. Key exchange would take place between phone users for private conversations, and shared public-private key groups would enable messaging boards, etc.
Trust network infiltration is a more difficult one to get totally right, and so far is fairly underdeveloped. The issue with public-private key exchange, and with covert networks in general, is that if an informant is place in the organisation, the group is exposed. To solve this issue, my current thoughts are to use a similar, if not identical, model to the bitcoin blockchain. Here, the blockchain would be used to authenticate that messages actually came from the user the message claims, and to accrue reputation for users.
The idea here is that when messages are passed on, the user doing the passing gains a little reputation. Positively acknowledging the receipt of a message intended for you also gives the sender some reputation. Thus, to send messages, users must be actively passing messages on, which acts as an incentive for snearker-net message passing, and generally good behavior. If the recipient sends a negative message receipt, this decreases the senders reputation, effectively preventing message spamming. This also conversely makes the most convincing voices (the organizers or leaders of a protest) the highest priority messages in the network, as they would naturally have the highest reputation. Reputation donations would also be permitted, along with paying more reputation for higher message priority, or higher bandwidth requirements.
Users would have their own, private, encrypted “phone book” containing identities that they have exchanged keys with. Exchanging info would be as simple as taping phones together, and pressing accept.
Lastly, voice messages or even images/video would need huge bandwidth and packet fragmentation. This would only be possible for users willing to pay a lot of reputation.
The network would maintain anonymous information on the amount of active modules, to help balance load and set the blockchain specifics (size, distribution, etc). New networks would be spun up for every event, and most likely dissolved afterwards.
Hardware:
The design is centered around the ESP8266. This chip is low cost, high bandwidth, flexible, and is fairly powerful.
The system contains:
– solar panels
– li-ion battery, battery charger and management,
– ESP8266,
– RFID transceiver + antenna,
– low power touch screen,
– speaker + mic + ADC,
– possibly low cost camera.
Software:
– Simple UI with on screen keyboard
– Encrypted top to bottom with public-private key exchange
– Bitcoin-like blockchain implementation
– mesh network + packetizing protocols
Mech:
– Strudy plastic casing, mostly waterproof
– Clear back for solar cells
– About the size of a large smartphone (7″)
IP:
All designs are open source, and can be made by anyone with access to parts. Parts are specifically chosen to be hand solder-able and low cost.

Ultrasonic Amplifier – Part 1

This ultrasonic amplifier project comes in two parts, design, and testing. Today we will cover the design and rational.

Idea

Many animals emit high pitch noises, what we call ultrasonic, that is beyond the hearing range of humans. Two such animals I am interested in are rats/mice, and bats. I want to hear the noises that they emit.

The classic approach that many bat detectors use is to amplify the signal coming from an ultrasonic microphone, then just treat it as a square wave and divide it down into human hearing range. This seems a little cheap to me, as you are getting a severely distorted noise, that does not carry amplitude info at all. Imagine a speaker screeching in distortion because someone set it too high, that is essentially what you are hearing from this detector.

My thought was, why not do a FFT (or even better, an FHT) to get the spectrum of the sound, compress it if needed, and then shift it down into human hearing range. Lastly, we just do an inverse FFT/FHT, and voila, truthful sound at roughly the right speed.

http://www.alwayslearn.com/dft%20and%20fft%20tutorial/DFTandFFT_BasicIdea.html
Attribution in alt text

 

ultrasonic amplifier Circuit Design

First things first, we need to amplify the signal from a ultrasonic microphone. The ultrasonic amplifier works in three stages, with the final stage having an adjustable 1-100x gain. When selecting the gain per stage, don’t forget to consider the gain-bandwidth product of the amplifier! The 1/2Vcc below is generated by a simple resistor divider, which works fine in this use case, as your op-amp input impedance is very high.

Ultrasonic AmplifierThis signal is then fed to a single stage Sallen-key filter, to remove any signals above ~90kHz, and then into an ADC. Remember to always chose an ADC with a sampling frequency at least 2x your highest signal frequency, this is known as the Nyquist rate. In reality, you want a sampling frequency of ~5x or more, to get a decent picture of the sampled waveform.

Ultrasonic Amplifier ADC

The signal can then be read by a oscilloscope for testing, and fed via SPI to a microcontroller. I will be using the ESP8266 for the FHT and IFHT steps later, possibly showing the waveform in a webpage.

Circuit Layout

The circuit layout is a fairly straightforward 2 layer board. The only trick for this ultrasonic amplifier is that the microphone is mounted horizontally to save on board space.

Ultrasonic Amplifier Layout

Now to wait 2-4 weeks for delivery and assembly 🙂

As always, these projects are open source and usable for any reason (preferably with some attribution). You can find the designs on my Altium circuit maker page:

http://workspace.circuitmaker.com/User/A590ACC4-C8D6-4893-ACF8-6250986C2EBF

What should Google do with robots?

A very interesting article here:

http://spectrum.ieee.org/automaton/robotics/robotics-hardware/what-google-should-do-with-its-robots

In my hopefully incorrect view, Google is making the same mistake that Microsoft made; it is purchasing companies only to stifle them. This has now happened with a number of promising companies, with a notable local example: BufferBox.