Here at Hackaday we see a lot of technological hoaxes looking for funding. Some are on Kickstarter, others are firms looking for investors. And unlike a lot of the press, we’re both skeptical and experienced enough to smell the snake oil. When you read about a laser-powered razor blade that looks too good to be true, you know we’ve got your back.
The background: [Zachary Feinstein] is a professor at Washington University in St. Louis who studies financial engineering, and in particular systemic financial risk in the banking sectors. So he’s just exactly the guy you’d tap to write a paper on the financial repercussions of the destruction of the Death Stars in Star Wars (PDF). Wait, what?
The central argument of the paper is that, since the Empire has so much money wrapped up in building the Death Stars, it’s economic suicide for the Rebels to destroy it. To quantify any of this, [Feinstein] runs financial crisis models. The idea is that the Rebels win, but they inherit an economy that’s so dysfunctional that they’d have been better off not destroying the Death Stars.
We’re not saying that the rest of the press is gullible, but we are saying that they’re not putting their best economists onto articles about financing Death Stars. But here at Hackaday, we are. And we’re calling it a hoax. So let’s look into what the paper gets right, and what makes less sense even than Chewbacca’s infernal growling. Spoiler: we’ll get wrapped up in numbers because it’s fun, but the whole thing is moot for Econ 101-style reasons.
We love a good tear-down, and last week’s “Enginursday” at Sparkfun satisfied our desire to see the insides of AC-DC switching power supplies, accompanied by knowledgeable commentary. [MTaylor] walks us through how the basic circuit works and then points out why various other elaborations are made, and how corners are sometimes cut, in a few power supplies that he’s taken apart.
What struck us in the comparison was that some of the power supplies were very minimal designs, while others had “features” that were obviously added after the fact. For instance, the Li Shin supply (about half-way down the page) has an extra circuit board tacked on to the bottom of the real circuit board to act as EM shielding.
Rather than declare this a dodgy hack, as we would have, [MTaylor] declares it to be “Good News!” because it means that they’ve probably run an emissions test, failed it, and then added this bit on to make it pass. This is of course in contrast to the other makers who’ve probably never even considered emissions testing. Sigh.
Normally, strain sensors are limited in their flexibility by the underlying substrate. This lead researchers at the University of Manitoba to an off-the-wall solution: mixing carbon nanotubes into a chewing-gum base. You can watch their demo video below the break.
The procedure, documented with good scientific rigor, is to have a graduate student chew a couple sticks of Doublemint for half an hour, and then wash the gum in ethanol and dry it out overnight. Carbon nanotubes are then added, and the gum is repeatedly stretched and folded, like you would with pizza dough, to align the ‘tubes. After that, just hook up electrodes and measure the resistance as you bend it.
The obvious advantage of a gum sensor is that it’s slightly sticky and very stretchy. The team says it works when stretched up to five times its resting length. Try that with your Power Glove.
The 900-pound gorilla in the corner of the Internet of Things (IoT) hype that everyone is trying to ignore is interoperability. In the Internet of Internets (IoI) everything works on a few standards that are widely accepted: IP and HTML. The discrepancies are in the details and the standards wars are in the past. Websites are largely interoperable. Not so in the wild-west ethos of the IoT.
Philips makes a line of ZigBee-enabled RGB lightbulbs that took the enthusiast community by storm. And initially, Philips was very friendly to other devices — it makes a ZigBee-to-WiFi bridge that would let you control all of your ZigBee-based lights, regardless of their manufacturer, from your phone. Until now.
Philips has just rolled out a “Friends of Hue” certification process, and has since pushed out a firmware update where their Hue bridges stop interoperating with non-certified devices. You can read Philips’ version of the story here.
Philips Locks Out 3rd Party ZigBee Hardware
The hub shown on the right is what’s being locked down.
The short version is that, ZigBee standards be damned, your future non-Philips lights won’t be allowed to associate with the Philips bridge. Your GE and Osram bulbs aren’t Friends of Hue. DIY RGB strips in your lighting mix? Not Friends of Hue. In fact, you won’t be surprised to know who the “Friends of Hue” are: other Philips products, and Apple. That’s it. If you were used to running a mixed lighting system, those days are over. If you’re not on the friends list, you are an Enemy of Hue.
Their claim is that third party products may display buggy behavior on a Philips network, and that this loads up their customer-response hotlines and makes people think that Philips is responsible. Of course, they could simply tell people to disable the “other” devices and see how it works, putting the blame where it belongs. Or they could open up a “developer mode” that made it clear that the user was doing something “innovative”. But neither of these strategies prevent consumers from buying other firms’ bulbs, which cost only 30-50% of Philips’ Hue line.
While Philips is very careful to not couch it as such, the Friends of Hue program really looks like an attempt to shut out their competitors; Philips got an early lead in the RGB LED game and has a large share of the market. As they say themselves in their own press release “Today these 3rd party bulbs represent a minimal fraction of the total product connected to our bridges so the percentage of our users affected is minimal.” And they’d like to keep it that way, even though the people they’re hurting are probably their most vocal and dedicated customers.
And while we, with our manual light switches, laugh comfortably at the first-world problems of Hue consumers, we have to ask ourselves whether we’re next. Today they come for our RGB lightbulbs, but tomorrow it might be our networked toasters. A chilling thought!
Snark aside, the IoT brings two of the saddest realities of the software world into your home appliances: Where there’s code, there’s vulnerabilities, and when you can’t control the code yourself you aren’t really in control. You may own the lightbulb, but you’re merely licensing the firmware that runs it. The manufacturer can change the rules of the game, or go out of the product line entirely, and you’re high and dry. What can you do? Pull out your JTAG debugger.
Of course it’s insane to suggest that everyone needs to become an embedded-device firmware hacker just to keep their fridge running. As we’ve written before, we need to come up with some solution that puts a little more control in the hands of the ostensible owners of the devices, while at the same time keeping the baddies out. We suggest a press-to-revert-firmware button, for instance. When Philips pushes a non-consumer-friendly upgrade, you could vote with your fingertips — but then you’d miss out on bug fixes as well. Maybe it’s better to just give in an learn to love Windows 10.
There are no easy solutions and no perfect software. The industry is still young and we’ll see a lot of companies staking out their turf as with any new technology. It seems to us that IoT devices leave consumers with even less choice and control than in the past, because they are driven by firmware that’s supposed to be invisible. It’s just a lightbulb, right?
What do you think? Any ideas about how to put the power back in the hands of the “owner” of the device without everyone’s refrigerators becoming botnet zombies? Let us know in the comments.
“We underestimated the impact this would have upon the small number of our customers who currently use uncertified lights from other brands in the Philips Hue system. We have decided to continue to enable our customers who wish to integrate these uncertified products within their Philips Hue system.”
It’s no secret that we like 3D printing, but Artist and architect [Michael Hansmeyer]really likes 3D printing. So much so that he’s based his entire career around exploring the artistic possibilities of what he calls “computational architecture”.
We first fell in love with [Michael]’s work “Columns” because it was both daring and relatively low-budget at the same time. He made a series of architectural-sized columns out of cross-sections of laser-cut cardboard. Why cardboard? Because his goal was to make the columns as complex as possible and the current range of 3D printers couldn’t give him the resolution he wanted.
Fast-forward to “Digital Grotesque”. Now [Michael] has access to a large-scale sand printer, and the license to go entirely nuts. He makes a space reminiscent of a Rococo grotto, but full of so much detail that you can’t really take it all in: it’s nearly fractal. Some stats: 11 tons of printed sandstone, 260 million surfaces, 30 billion voxels. We’re stoked that we don’t have to dust it!
His latest piece, “Arabesque Wall” is partly organic and elegant, and part Aliens. If we can play art critic, we think it’s beautiful. Go click through the portfolio. (And although they never got printed, we really like some of the “Voxels” series of cellular-automata pieces.)
From new paint materials opening up new color possibilities to new instruments enabling entirely different types of music, art, and technology mutually inform each other much more than we often appreciate. In ten years time, we’ll be looking back on this work and saying “this piece looks good” and “that piece looks bad” instead of “wow, amazing tech!”. But for now, we’re also content to wallow in the “wow”.
We hope we’re not insulting you by suggesting this, but it’s possible that even the best among us may be faced with bugs in our embedded code from time to time. And while we’re great fans of printf debugging over the serial port, and its high-speed equivalent — flipping a GPIO pin — there’s a time when your bug is so deep that having a real debugger is the best way to dig it out.
[slaff] has been doing some great work documenting C/C++ programming on the ESP-8266, mostly using Eclipse and some of the Arduino libraries. In the fourth part of his series of posts, he walks through using a couple debugger options for the ESP. What makes this all work is the ESP-gdbstub code from Espressif themselves. gdbstub looks great — it works both with the standard SDK as well as with FreeRTOS, so you can debug your ESP-8266 code whether it’s in an OS or on the bare metal. And all this just using the standard serial connection that’s used for programming.
Now, this still may not help with timing-related bugs. ESP-gdbstub uses the serial port, after all. But having the ability to set breakpoints and interactively inspect what’s going on in the chip’s memory is priceless, and doing so with no extra hardware connections is brilliant.
Spritz itself is a neat cipher. Instead of taking in fixed blocks of data and operating on them, it allows you to process it in (almost) whatever chunks it comes in naturally, and then extract out the encrypted results piecewise. It works both as a two-way cipher and as a one-way hash function. It looks like Spritz is a one-stop-shop for all of your encryption needs, and now you can run it on your Arduino.
In case you are afraid of new implementations of new ciphers (and you should be), Spritz’s pedigree should help to put you at ease: it was developed by [Ron Rivest] to be a successor to his RC4 algorithm, and it incorporates a lot of the lessons learned about that algorithm over the past. This doesn’t exclude subtle flaws in the implementation of the library (no offence, [Abderraouf]!) or your work downstream, but at least the underlying algorithm seems to be the real deal.
[Abderraouf] links it in his writeup, but just for completeness, here’s the Spritz paper (PDF). What crypto libraries do you currently use for Arduino or microcontroller projects? We’ve been fans of XXTEA for ages, but more because it’s simple and small than because it’s secure. Spritz may be simple enough to implement easily, and still more secure. Sweet.
