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”
NASA spends a lot of time researching the Earth and its surrounding space environment. One particular feature of interest are the Van Allen belts, so much so that NASA built special probes to study them! They’ve now discovered a protective bubble they believe has been generated by human transmissions in the VLF range.
VLF transmissions cover the 3-30 kHz range, and thus bandwidth is highly limited. VLF hardware is primarily used to communicate with submarines, often to remind them that, yes, everything is still fine and there’s no need to launch the nukes yet. It’s also used for navigation and broadcasting time signals.
It seems that this human transmission has created a barrier of sorts in the atmosphere that protects it against radiation from space. Interestingly, the outward edge of this “VLF Bubble” seems to correspond very closely with the innermost edge of the Van Allen belts caused by Earth’s magnetic field. What’s more, the inner limit of the Van Allan belts now appears to be much farther away from the Earth’s surface than it was in the 1960s, which suggests that man-made VLF transmissions could be responsible for pushing the boundary outwards.
Continue reading “Humans May Have Accidentally Created a Radiation Shield Around Earth”
Wireless is easier today than ever, with many standards to choose from. But you don’t need anything elaborate if you simply want to cut the cord. A few years back, [Roman Black] experimented with the cheap RF modules you can find on auction sites and from surplus electronics vendors for only a few dollars, and wrote up his findings. They’re well worth a look.
Continue reading “Sending Data Using Cheap RF Modules”