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’ve all been there: after assessing a problem and thinking about a solution, we immediately rush to pursue the first that comes to mind, only to later find that there was a vastly simpler alternative. Thankfully, developing an obscure solution, though sometimes frustrating at the time, does tend to make a good Hackaday post. This time it was [David Wehr] and AudioSerial: a simple way of outputting raw serial data over the audio port of an Android phone. Though [David] could have easily used USB OTG for this project, many microcontrollers don’t have the USB-to-TTL capabilities of his Arduino – so this wasn’t entirely in vain.
At first, it seemed like a simple task: any respectable phone’s DAC should have a sample rate of at least 44.1kHz. [David] used Oboe, a high performance C++ library for Android audio apps, to create the required waveform. The 8-bit data chunks he sent can only make up 256 unique messages, so he pre-generated them. However, the DAC tried to be clever and do some interpolation with the signal – great for audio, not so much for digital waveforms. You can see the warped signal in blue compared to what it should be in orange. To fix this, an op-amp comparator was used to clean up the signal, as well as boosting it to the required voltage.
Prefer your Arduino connections wireless? Check out this smartphone-controlled periodic table of elements, or this wireless robotic hand.
Continue reading “Serial Connection Over Audio: Arduino Can Listen To UART”
Did you ever wonder what your monitor and your computer are talking about behind your back? As it turns out, there’s quite a conversation going on while the monitor and the computer decide how to get along, and sniffing out VGA communications can reveal some pretty fascinating stuff about the I²C protocol.
To reverse engineer the configuration information exchanged between a VGA monitor and a video card, [Ken Shirriff] began by lopping a VGA cable in two. The inside of such cables is surprisingly complex, with separate shielding wires for each color and sync channel and a host of control wires, all bundled in multiple layers of shielding foil and braid to reduce EMI. [Ken] identified the clock and data lines used for the I²C interface and broke those out into a PocketBeagle for analysis using the tiny Linux machine’s I²C tools.
With a Python script to help decode the monitor’s Extended Display Identification Data (EDID) data, [Ken] was able to see everything the monitor knows about itself — manufacturer, serial number, all the supported resolution modes, and even deprecated timing and signal information left over from the days when CRTs ruled the desktop. Particularly interesting are the surprisingly limited capabilities of a VGA display in terms of color reproduction, as well as [Ken]’s detailed discussion on the I²C bus in general and how it works.
We always enjoy these looks under the hood that [Ken] is so good at, and we look forward to his reverse engineering write-ups. His recent efforts include a look at core memory from a 50-year old mainframe and reverse engineering at the silicon level.
printf is something [StorePeter] has always found super handy, and as a result he’s always been interested in tweaking the process for improvements. This kind of debugging usually has microcontrollers sending messages over a serial port, but in embedded development there isn’t always a hardware UART, or it might already be in use. His preferred method of avoiding those problems is to use a USB to Serial adapter and bit-bang the serial on the microcontroller side. It was during this process that it occurred to [StorePeter] that there was a lot of streamlining he could be doing, and thanks to serial terminal programs that support arbitrary baud rates, he’s reliably sending debug messages over serial at 5.3 Mbit/sec, or 5333333 Baud. His code is available for download from his site, and works perfectly in the Arduino IDE.
The whole thing consists of some simple, easily ported code to implement a bare minimum bit-banged serial communication. This is output only, no feedback, and timing consists of just sending bits as quickly as the CPU can handle, leaving it up to the USB Serial adapter and rest of the world to handle whatever that speed turns out to be. On a 16 MHz AVR, transmitting one bit can be done in three instructions, which comes out to about 5333333 baud or roughly 5.3 Mbit/sec. Set a terminal program to 5333333 baud, and you can get a “Hello world” in about 20 microseconds compared to 1 millisecond at 115200 baud.
He’s got additional tips on using serial print debugging as a process, and he’s done a followup where he stress-tests the reliability of a 5.3 MBit/sec serial stream from an ATMega2560 at 16 MHz in his 3D printer, and found no missed packets. That certainly covers using
printf as a debugger, so how about a method of using the debugger as printf?
If you’ve played even just a few minutes of Minecraft, you know what a creeper is. For those not familiar with the wildly popular sandbox game, a creeper is a monster that creeps along silently until it’s close to a player, whereupon it self-destructs by exploding. Sometimes it kills the player outright, and other times the explosion blows them into lava or off a cliff, or off a cliff and then into lava. Creepers have no friends.
But now there’s a way to avoid creeper attacks, or at least get a little heads up that these green nasties are lurking about. With [John Allwine]’s creeper detector, Minecraft players can get a real-world indicator of the current in-game creeper threat. The hardware end is simple enough — it’s just a SparkFun RedBoard and a small strip of Neopixels in a laser-cut plywood case. The LEDs lie behind a piece of etched acrylic to diffuse their glow — extra points for the creeper pattern in the lens. The detector talks over USB to a Minecraft mod that [John] wrote to interface the game with the real world. The closer a creeper gets to the player, the brighter the light. — and when it flashes, watch out. See it in action in the video below, if you can stomach watching someone dig straight down. Never dig straight down.
If interfacing the Minecraft world and the real world sounds familiar, maybe it’s because we featured [John]’s SerialCraft mod a while back and admired the potential for using Minecraft as a gateway for getting kids into hardware hacking. We agree that this is a great project to work on with kids, but we may just order the parts to do it for our own Minecraft world. Creeper hate isn’t just for kids.
Continue reading “Threat Meter Gauges Risk of Creeper-Assisted Suicide”
We’ve all at some point or other seen something done online by somebody else, and thought “I’d like to have a go at that!”. When [Phooky] saw the artwork on the #PlotterTwitter hashtag, he remembered a past donation of a plotter to the NYC Resistor hackerspace. Some searching through the loft revealed a dusty cardboard box containing not the lovely Hewlett-Packard he’d hoped for, but instead an Apple 410 Color Plotter. This proved to be such an obscure part of the legacy Apple product line that almost no information was available for it save for a few diagrams showing DIP switch settings for the serial port.
Undeterred, he took a look inside and found a straightforward enough control board featuring a Z80 processor and support chips with 1983 date codes. The ROMs were conveniently socketed, so after dumping their contents, he was able to identify the routine for the plotter’s test program, and thus work from there to deduce its command set. A small matter of the plotter using hardware handshaking lines to signal a full buffer later, and he was able to use it to produce beautiful plots. Should you be one of the lucky few remaining Apple 410 owners, you may find his software library for it to be of some use.
If you’d like to see some more aged plotter action on these pages, we’ve had an analog Hewlett Packard here in the past, as well as a vintage drum plotter.
Thanks [Sophi] for the tip.
Being a member of the bomb squad would be pretty high up when it comes to ranking stressful occupations. It also makes for great fun with friends. Keep Talking and Nobody Explodes is a two-player video game where one player attempts to defuse a bomb based on instructions from someone on the other end of a phone. [hephaisto] found the game great fun, but thought it could really benefit from some actual hardware. They set about building a real-life bomb defusal game named BUMM.
The “bomb” itself consists of a Raspberry Pi brain that communicates with a series of modules over a serial bus. The modules consist of a timer, a serial number display, and two “riddle” boxes covered in switches and LEDs. It’s the job of the bomb defuser to describe what they see on the various modules to the remote operator, who reads a manual and relays instructions based on this data back to the defuser. For example, the defuser may report seeing a yellow and green LED lit on the riddle module – the operator will then look this up and instruct the defuser on which switches to set in order to defuse that part of the bomb. It’s the challenge of quickly and accurately communicating in the face of a ticking clock that makes the game fun.
[hephaisto] took this build to Make Rhein-Main 2017, where they were very accepting of a “bomb” being brought onto the premises. The game was setup in a booth with an old analog S-video camera feed and a field telephone for communication – we love the detail touches that really add atmosphere to the gameplay experience.
Overall, it’s a great project that could easily be recreated by any hackerspace looking for something fun to share on community nights. The build files are all available on the project GitHub so it’s easy to see the nuts and bolts of how it works.
We’ve seen builds that bring video games into the real world before – like this coilgun Scorched Earth build. Fantastic.