As a society, we’ve become accustomed to always-on high-speed data connections, whether we’re at home on the computer or out and about with a mobile device. But what happens if a natural disaster knocks out the local infrastructure? Sure some people will be able to fire up their radio if they need to reach out and touch someone, but even among hackers, hams are a minority. What we really need is a backup Internet.
The team behind the CellSol project hopes to show that building a volunteer-operated distributed communications network is not only within the capabilities of the hacker community but probably much easier and cheaper to do than you might think. Each node in the network, known as a Pylon in CellSol parlance, can shuttle data between the LoRa backbone and WiFi-enabled devices like smartphones and computers. Once the network is up and running, users don’t need any special hardware or software to use it.
Now to be clear, nobody is talking about surfing the web here. When a user connects to one of the ESP32 Pylons, they’ll be able to access a simplistic chat system through their browser. If the Pylon has an active Internet connection the chat can be bridged to an IRC channel. Without Internet connectivity, the pylon will simply give users on the CellSol network a means to communicate among each other. To keep things simple there’s no user names, private messages, or encryption. This is bare-bones, end-of-the-world style communication.
Want to join the CellSol revolution? All you really need is an ESP32, a LoRa radio, and the open-source firmware. If you get something like the Heltec LoRa 32 development board, you don’t even need to solder anything together. Just flash the board and go. Once you have a few Pylons going, you can also put together a cheap repeater node using a LoRa equipped Arduino. Both devices are small and energy efficient enough that they could easily be battery or solar powered. As you can see in the video after the break, the team even envisions a future where they could be dropped off in public areas via drone.
This isn’t the first time we’ve seen the ESP32 used to establish an off-grid LoRa communications network, and like those previous attempts, it’s usefulness will largely depend on how many people you can convince to set up their own nodes and repeaters. But if you’ve got some open minded friends who live relatively close by, this could be a great way to have a little chat.
Continue reading “IRC Over LoRa, For When Things Really Go South”
It’s a common enough Hollywood trope that we’ve all probably seen it: the general, chest bespangled with medals and ribbons, gazes at a big screen swarming with the phosphor traces of incoming ICBMs, defeatedly picks up the phone and somberly intones, “Get me the president.” We’re left on the edge of our seats as we ponder what it must be like to have to deliver the bad news to the boss, knowing full well that his response will literally light the world on fire.
Scenes like that work because we suspect that real-life versions of it probably played out dozens of times during the Cold War, and likely once or twice since its official conclusion. Such scenes also play into our suspicion that military and political leaders have at their disposal technologies that are vastly superior to what’s available to consumers, chief among them being special communications networks that provide capabilities we could only have dreamed of back then.
As it turns out, the US military did indeed have different and better telephone capabilities during the Cold War than those enjoyed by their civilian counterparts. But as we shall see, the increased capabilities of the network that came to be known as AUTOVON didn’t come so much from better technology, but more from duplicating the existing public switched-telephone network and using good engineering principles, a lot of concrete, and a dash of paranoia to protect it.
Continue reading “AUTOVON: A Phone System Fit For The Military”
Hundreds of years from now, the story of humanity’s inevitable spread across the solar system will be a collection of engineering problems solved, some probably in heroic fashion. We’ve already tackled a lot of these problems in our first furtive steps into the wider galaxy. Our engineering solutions have taken humans to the Moon and back, but that’s as far as we’ve been able to send our fragile and precious selves.
While we figure out how to solve the problems keeping us trapped in the Earth-Moon system, we’ve sent fleets of robotic emissaries to do our exploration by proxy, to make the observations we need to frame the next set of engineering problems to be solved. But as we reach further out into the solar system and beyond, our exploration capabilities are increasingly suffering from communications bottlenecks that restrict how much data we can ship back to Earth.
We need to find a way to send vast amounts of data back as quickly as possible using as few resources as possible on both ends of the communications link. Doing so may mean turning away from traditional radio communications and going way, way up the dial and developing practical means for communicating with X-rays.
Continue reading “X-Rays Are The Next Frontier In Space Communications”
By now most of us have used a Raspberry Pi at some level or another. As a headless server it’s a great tool because of its price point, and as an interface to the outside world the GPIO pins are incredibly easy to access with a simple Python script. For anyone looking for guidance on using this device at a higher level, though, [Arun] recently created a how-to for using some of the Pi’s available communications protocols.
Intended to be a do-everything “poor man’s hardware hacking tool” as [Arun] claims, his instruction manual details all the ways that a Raspberry Pi can communicate with other devices using SPI and I2C, two of the most common methods of interacting with other hardware beyond simple relays. If you need to go deeper, the Pi can also be used as a full JTAG interface or SWD programmer for ARM chips. Naturally, UART serial is baked in. What more do you need?
As either a tool to keep in your toolbox for all the times you need to communicate with various pieces of hardware, or as a primer for understanding more intricate ways of using a Raspberry Pi to communicate with things like sensors or other computers, this is a great write-up. We also have more information about SPI if you’re curious as to how the protocol works.
Thanks to [Adrian] for the tip!
Communicating with microcontrollers and other embedded systems requires a communications standard. SPI is a great one, and is commonly used, but it’s not the only one available. There’s also I2C which has some advantages and disadvantages compared to SPI. The problem with both standards, however, is that modern computers don’t come with either built-in. To solve that problem and allow easier access to debugging in SPI, [James Bowman] built the SPIDriver a few months ago, and is now back by popular demand with a similar device for I2C, the I2CDriver.
Much like the SPIDriver, the I2C driver is a debugging tool that can be used at your computer with a USB interface. Working with I2C is often a hassle, with many things going on all at once that need to sync up just right in order to work at all, and this device allows the user to set up I2C devices in a fraction of the time. To start, it has a screen built in that shows information about the current device, like the signal lines and a graphical decoding of the current traffic. It also shows an address space map, and has programmable pullup resistors built in, and can send data about the I2C traffic back to its host PC for analysis.
The I2CDriver is also completely open source, from the hardware to the software, meaning you could build one from scratch if you have the will and the parts, or make changes to the code on your own to suit your specific needs. If you’re stuck using SPI still, though, you can still find the original SPIDriver tool to help you with your debugging needs with that protocol as well.
It’s probably fair to say that anyone reading these words understands conceptually how physically connected devices communicate with each other. In the most basic configuration, one wire establishes a common ground as a shared reference point and then the “signal” is sent over a second wire. But what actually is a signal, how do the devices stay synchronized, and what happens when a dodgy link causes some data to go missing?
All of these questions, and more, are addressed by [Ben Eater] in his fascinating series on data transmission. He takes a very low-level approach to explaining the basics of communication, starting with the concept of non-return-to-zero encoding and working his way to a shared clock signal to make sure all of the devices in the network are in step. Most of us are familiar with the data and clock wires used in serial communications protocols like I2C, but rarely do you get to see such a clear and detailed explanation of how it all works.
He demonstrates the challenge of getting two independent devices to communicate, trying in vain to adjust the delays on the receiving and transmitting Arduinos to try to establish a reliable link at a leisurely five bits per second. But even at this digital snail’s pace, errors pop up within a few seconds. [Ben] goes on to show that the oscillators used in consumer electronics simply aren’t consistent enough between devices to stay synchronized for more than a few hundred bits. Until atomic clocks come standard on the Arduino, it’s just not an option.
[Ben] then explains the concept of a dedicated clock signal, and how it can be used to make sure the devices are in sync even if their local clocks drift around. As he shows, as long as the data signal and the clock signal are hitting at the same time, the actual timing doesn’t matter much. Even within the confines of this basic demo, some drift in the clock signal is observed, but it has no detrimental effect on communication.
In the next part of the series, [Ben] will tackle error correction techniques. Until then, you might want to check out the fantastic piece [Elliot Williams] put together on I2C.
[Thanks to George Graves for the tip.]
Continue reading “A Crash Course In Reliable Communication”
We use the Internet to do everything from filing our taxes to finding good pizza, but most critically it fulfills nearly all of our communication needs. Unfortunately, this reliance can be exploited by those pulling the strings; if your government is trying to do something shady, the first step is likely to be effecting how you can communicate with the outside world. The Internet is heavily censored and monitored in China, and in North Korea the entire country is effectively running on an intranet that’s cutoff from the wider Internet. The need for decentralized information services and communication is very real.
While it might not solve all the world’s communication problems, [::vtol::] writes in to tell us about a very interesting communication device he’s been working on that he calls “Hot Ninja”. Operating on the principle that users might be searching for accessible Wi-Fi networks in a situation where the Internet has been taken down, Hot Ninja allows the user to send simple messages through Wi-Fi SSIDs.
We’ve all seen creatively named Wi-Fi networks before, and the idea here is very much the same. Hot Ninja creates a Wi-Fi network with the user’s message as the SSID in hopes that somebody on a mobile device will see it. The SSID alone could be enough depending on the situation, but Hot Ninja is also able to serve up a basic web page to devices which actually connect. In the video after the break, [::vtol::] even demonstrates some rudimentary BBS-style functionality by presenting the client devices with a text field, the contents of which are saved to a log file.
In terms of hardware, Hot Ninja is made up of an Arduino Mega coupled to three ESP8266 boards, and a battery to keep it all running for up to eight hours so you can subvert a dictatorship while on the move. The user interface is provided by a small OLED screen and a keyboard made entirely of through-hole tactile switches, further reinforcing the trope that touch-typing will be a must have skill in the dystopian future. It might not be the most ergonomic device we’ve ever seen, but the fact it looks like something out of a Neal Stephenson novel more than makes up for it in our book.
This is not the first time we’ve seen Wi-Fi SSIDs used as a method of communication, thanks largely to how easy the ESP8266 makes it. For his part, [::vtol::] has previously experimented with using them to culturally enrich the masses.
Continue reading “A Mobile Terminal For Guerrilla Communications”