Like many Victorian gentlemen of means, Richard Carrington did not need to sully himself with labor; instead, he turned his energies to the study of natural philosophy. It was the field of astronomy to which Carrington would apply himself, but unlike other gentlemen of similar inclination, he began his studies not as the sun set, but as it rose. Our star held great interest for Carrington, and what he saw on its face the morning of September 1, 1859, would astonish him. On that morning, as he sketched an unusual cluster of sunspots, the area erupted in a bright flash as an unfathomable amount of energy stored in the twisted ropes of the Sun’s magnetic field was released, propelling billions of tons of star-stuff on a collision course with Earth.
Carrington had witnessed a solar flare, and the consequent coronal mass ejection that would hit Earth just 17 hours later would result in a geomagnetic storm of such strength that it would be worldwide news the next day, and would bear his name into the future. The Carrington Event of 1859 was a glimpse of what our star is capable of under the right circumstances, the implications of which are sobering indeed given the web of delicate connections we’ve woven around and above the planet.
Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?
Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.
It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.
So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.
For the last few years, the Last Great Hope™ of the consumer electronics industry has been voice assistants. Alexas and Echos and Google Homes and Facebook Portals are all the rage. Over one hundred million Alexa devices have been sold, an impressive feat given that there are only about 120 Million households in the United States, and a similar number in Europe. Look to your left, look to your right, one of you lives in a house with an Internet connected voice assistant.
2018 saw a huge explosion of Internet connected voice assistants, in sometimes bizarre form factors. There’s a voice controlled microwave, which is great if you’ve ever wanted to defrost a chicken through the Internet. You can get hardware for developing your own voice assistant device. 2019 will be even bigger. Facebook is heavily advertising the Facebook Portal. If you haven’t yet deleted your Facebook account, you can put the Facebook Portal on your kitchen counter and make video calls with your family and friends through Facebook Messenger. With the Google Home Hub and a Nest doorbell camera, you too can be just like Stu Pickles from Rugrats.
This is not the first time the world has been enamored with Internet-connected assistants. This is not the first time the consumer electronics industry put all their hope into one product category. This has happened before, and all those devices failed spectacularly. These were the Internet appliances released between 1999 and 2001: the last great hurrah of the dot-com boom. They were dumb then, and they’re dumb now.
In recent months, the ability to hide components inside a circuit board has become an item of interest. We could trace this to the burgeoning badgelife movement, where engineers create beautiful works of electronic art. We can also attribute this interest to Bloomberg’s Big Hack, where Jordan Robertson and Michael Riley asserted Apple was the target of Chinese spying using components embedded inside a motherboard. The Big Hack story had legs, but so far no evidence of this hack’s existence has come to light, and the companies and governments involved have all issued denials that anything like this exists.
That said, embedding components inside a PCB is an interesting topic of discussion, and thanks to the dropping prices of PCB fabrication (this entire project cost $15 for the circuit boards), it’s now possible for hobbyists to experiment with the technique.
But first, it’s important to define what ‘stuffing components inside a piece of fiberglass’ is actually called. My research keeps coming back to the term ’embedded components’ which is utterly ungooglable, and a truly terrible name because ’embedded’ means something else entirely. You cannot call a PCB fabrication technique ’embedded components’ and expect people to find it on the Internet. For lack of a better term, I’m calling this ‘Oreo construction’, because of my predilection towards ‘stuf’, and because it needs to be called something. We’re all calling it ‘Oreo construction’ now, because the stuf is in the middle. This is how you do it with standard PCB design tools and cheap Chinese board houses.
I recently came across the most peculiar way to make a color CRT monitor. More than a few oscilloscopes have found their way on to my bench over the years, but I was particularly struck with a find from eBay. A quick look at the display reveals something a little alien. The sharpness is fantastic: each pixel is a perfect, uniform-colored little dot, a feat unequaled even by today’s best LCDs. The designers seem to have chosen a somewhat odd set of pastels for the UI though, and if you move your head just right, you can catch flashes of pure red, green, and blue. It turns out, this Tektronix TDS-754D sports a very peculiar display technology called NuColor — an evolutionary dead-end that was once touted as a superior alternative to traditional color CRTs.
Join me for a look inside to figure out what’s different from those old, heavy TVs that have gone the way of the dodo.
One of the killer apps of 3D printers is the ability to make custom gears, transmissions, and mechanisms. But there’s a learning curve. If you haven’t 3D printed your own gearbox or automaton, here’s a great reason to take the plunge. This morning Hackaday launched the 3D Printed Gears, Pulleys, and Cams contest, a challenge to make stuff move using 3D-printed mechanisms.
Adding movement to a project brings it to life. Often times we see projects where moving parts are connected directly to a servo or other motor, but you can do a lot more interesting things by adding some mechanical advantage between the source of the work, and the moving parts. We don’t care if it’s motorized or hand cranked, water powered or driven by the wind, we just want to see what neat things you can accomplish by 3D printing some gears, pulleys, or cams!
No mechanism is too small — if you have never printed gears before and manage to get just two meshing with each other, we want to see it! (And of course no gear is literally too small either — who can print the smallest gearbox as their entry?) Automatons, toys, drive trains, string plotters, useless machines, clockworks, and baubles are all fair game. We want to be inspired by the story of how you design your entry, and what it took to get from filament to functional prototype.
When Charles “Chuck” Yeager reached a speed of Mach 1.06 while flying the Bell X-1 Glamorous Glennis in 1947, he became the first man to fly faster than the speed of sound in controlled level flight. Specifying that he reached supersonic speed “in controlled level flight” might seem superfluous, but it’s actually a very important distinction. There had been several unconfirmed claims that aircraft had hit or even exceeded Mach 1 during the Second World War, but it had always been during a steep dive and generally resulted in the loss of the aircraft and its pilot. Yeager’s accomplishment wasn’t just going faster than sound, but doing it in a controlled and sustained flight that ended with a safe landing.
Chuck Yeager and his Bell X-1
In that way, the current status of hypersonic flight is not entirely unlike that of supersonic flight prior to 1947. We have missiles which travel at or above Mach 5, the start of the hypersonic regime, and spacecraft returning from orbit such as the Space Shuttle can attain speeds as high as Mach 25 while diving through the atmosphere. But neither example meets that same requirement of “controlled level flight” that Yeager achieved 72 years ago. Until a vehicle can accelerate up to Mach 5, sustain that speed for a useful period of time, and then land intact (with or without a human occupant), we can’t say that we’ve truly mastered hypersonic flight.
So why, nearly a century after we broke the sound barrier, are we still without practical hypersonic aircraft? One of the biggest issues historically has been the material the vehicle is made out of. The Lockheed SR-71 “Blackbird” struggled with the intense heat generated by flying at Mach 3, which ultimately required it to be constructed from an expensive and temperamental combination of titanium and polymer composites. A craft which flies at Mach 5 or beyond is subjected to even harsher conditions, and it has taken decades for material science to rise to the challenge.
With modern composites and the benefit of advanced computer simulations, we’re closing in on solving the physical aspects of surviving sustained hypersonic flight. With the recent announcement that Russia has put their Avangard hypersonic glider into production, small scale vehicles traveling at high Mach numbers for extended periods of time are now a reality. Saying it’s a solved problem isn’t quite accurate; the American hypersonic glider program has been plagued with issues related to the vehicle coming apart under the stress of Mach 20 flight, which heats the craft’s surface to temperatures in excess of 1,900 C (~3,500 F). But we’re getting closer, and it’s no longer the insurmountable problem it seemed a few decades ago.
Today, the biggest remaining challenge is propelling a hypersonic vehicle in level flight for a useful period of time. The most promising solution is the scramjet, an engine that relies on the speed of the vehicle itself to compress incoming air for combustion. They’re mechanically very simple, and the physics behind it have been known since about the time Yeager was climbing into the cockpit of the X-1. Unfortunately the road towards constructing, much less testing, a full scale hypersonic scramjet aircraft has been a long and hard one.
