4-Bit Audio Output Via Voltage Reference

[Bruce Land] switched his microprocessor programming class over from Atmel parts to Microchip’s PIC32 series, and that means that he’s got a slightly different set of peripherals to play with. One thing that both chips lack, however is a digital-to-analog converter (DAC). Or do they? (Dun-dun-dun-duuuuhnnnn!)

The PIC part has a programmable, sixteen-level voltage reference. And what is a Vref if not a calibrated DAC? With that in mind, [Bruce] took to documenting its performance and starting to push it far beyond the manufacturer’s intentions. Turns out that the Vref has around 200 kHz of bandwidth. (Who would update a voltage reference 200,000 times per second?)

Anyway, [Bruce] being [Bruce], he noticed that the bits weren’t changing very often in anything more than the least significant bit: audio waveforms, sampled fast enough, are fairly continuous. This suggests using a differential PCM encoding, which knocks the bitrate down by 50% and saves a lot on storage. (Links to all the code for this experiment is inline with his writeup.)

The audio hacks that come out of [Bruce]’s Cornell ECE classes are always a treat. From the lock that you have to sing to open, to chiptunes programmed into an FPGA, there’s something for music fans of all inclinations.

Droolworthy Animatronic Stargate Horus Helmet

It’s incredibly likely that, unless you own one of the original movie props, your Stargate Horus helmet is not as cool as [jeromekelty]’s. We say this with some confidence because [jerome] got access to the original molds and put in an incredible amount of time on the animatronics. (See his latest video embedded below.)

Surprisingly, a number of the parts for this amazing piece were bought off the shelf. The irises that open and close they eyes, for instance, were bought on eBay. This is not to downplay the amount of custom design, though. The mechanism that moves the feathers is a sight to see, and there’s a lot of hand-machined metal holding it all together. But the payoff is watching the thing move under remote control. The eye dimming and closing, combined with the head movements, make it look almost alive.

Continue reading “Droolworthy Animatronic Stargate Horus Helmet”

ESP8266 MicroPython Contest Gives You The Excuse You Need

As if the prospect of having everyone’s favorite scripting language ported over weren’t enough to get you to install MicroPython on a spare ESP8266, there is now a contest for that. Over on Hackaday.io the MicroPython on ESP8266 contest is under way and you’ve only got until the end of August to submit your creation.

The prizes? First place gets an OpenMV camera board because [Radomir], who’s running the contest, has an extra one. OK, it’s not as lush as the corporate-sponsored goody-bag that we’ve got running in the Hackaday Prize, but there’s no reason that you can’t enter both. And if anyone wants to throw some more goodies into the pot, I’m sure they’d be welcome.

The rules are simple: use an ESP8266 or ESP8285 with MicroPython and post the project up on Hackaday.io. Bonus points are given for creating new libraries or hardware drivers. Basically, this just gives you an extra reason to get in there and play around. How cool is that?

If you need a start-up on MicroPython on the ESP8266, the official tutorial is great. We wrote up a first-look review of running MicroPython on the WeMos D1 hardware, but were plagued with (re-)flashing difficulties, so we’re going to have to give it another go.

Amazing SDR Built By 16 Year Old

[Lukas] started his epic SDR-from-scratch build when he was 16. Projects like this aren’t completed overnight. (He’s now 18. We’re impressed.)

The project itself is a Software-Defined Radio built on top of the 12-bit Analog Devices AD9364 transceiver IC. A big fat FPGA takes the data and runs it off to a USB 3.0 interface, which is necessary for the amount of data this thing will be producing — he’s got it receiving 56 MHz of bandwidth. In short, this is an SDR peripheral that’s in the big leagues.

After two years of work and (only!) three revision, [Lukas] got the thing working. Read his writeup for the blow-by-blow account. In the end, a 6-layer board was necessary for the routing to get the full speed out of the clocking, and he discovered the reason that you use exactly the specified bias resistors — the expensive ADC chip gets very hot. But he didn’t give up, and in the end he pulled off a project of immense complexity. In his own words:

I have discovered that taking on large projects, even when not knowing how to tackle problems that might arise, is a very effective way of learning for me. It’s just important to be persistent, as I’ve seen that almost any problem can be solved on your own — which is incredibly rewarding — even if you get stuck and seem to not make progress for a while.

[Lukas] is now working on the software. He’s already got a hacked osmocom driver working, so it plays nice with GNURadio.

Of course, there are tons of ways to get into SDR without building your own from scratch, but we applaud [Lukas] for going the hard way. If you’re tempted to follow in his footsteps, have a look at [Michael Ossmann]’s great talk on making the RF design process as tractable as possible.

Computer-Designed Portraits, Knit By Hand!

Artist [Petros Vrellis] has done something that we’ve never seen before: his piece “A New Way to Knit” lives up to its name. What he’s done is to take the traditional circular loom, some black thread, and toss some computing at it. And then he loops the string around and around and around.

a-new-way-to-knit-175653201mp4-shot0009_thumbnail

The end result of following the computer’s instructions is a greyscale portrait. Where few black strings overlap, it’s light, and where more overlap, it’s darker. That’s the whole gimmick, but the effect is awesome. As you zoom in and out, it goes from a recognizable face to a tangle of wires and back. Check out his video embedded below.

Continue reading “Computer-Designed Portraits, Knit By Hand!”

Design For Hackers

Near the end of the lifecycle of mass-market commercial product development, an engineering team may come in and make a design for manufacturability (DFM) pass. The goal is to make the device easy, cheap, and reliable to build and actually improve reliability at the same time. We hackers don’t usually take this last step, because when you’re producing just a couple of any given device, it hardly makes sense. But when you release an open-source hardware design to the world, if a lot of people re-build your widget, it might be worth it to consider DFM, or at least a hardware hacker’s version of DFM.

If you want people to make their own versions of your project, make it easy and cheap for them to do so and don’t forget to also make it hackable. This isn’t the same as industrial DFM: rather than designing for 100,000s of boards to be put together by robot assembly machines, you are designing for an audience of penny-pinching hackers, each building your project only once. But thinking about how buildable your design is will still be worthwhile.

In this article, I’m going to touch on a couple of Design for Hackers (DFH) best practices. I really want to hear your experience and desires in the comments. What would you like to see in someone else’s open designs? What drives you nuts when replicating a project? What tricks do you know to make a project easily and cheaply buildable by the average hacker?

Continue reading “Design For Hackers”

Root On The Philips Hue IoT Bridge

Building on the work of others (as is always the case!) [pepe2k] managed to get root access on the Philips Hue Bridge v2 IoT light controller. There’s nothing unusual here, really. Connect to the device over serial, interrupt the boot process, boot up open firmware, dump the existing firmware, and work the hacker magic from there.

Of course, the details are the real story. Philips had set U-Boot to boot the firmware from flash in zero seconds, not allowing [pepe2k] much time to interrupt it. So he desoldered the flash, giving him all the time in the world, and allowing him to change the boot delay. Resoldering the flash and loading up his own system let him dump the firmware.

The “hacker magic” glossed over in the intro consisted of poking around until he found a script that was called on every boot. This is how [pepe2k] gets around not knowing the root password. The script compares the hash of the typed password with an environment variable, set with the hash of the correct password. Changing that environment variable to the hash of his favorite password (“root”) made him master of the box.

And just in case you’re one of the few Hackaday readers who doesn’t understand why we do these things, besides the fact that it’s just fun, consider Philips’ (eventually retracted) clampdown on the interoperability of this very device, or Google’s red bricks. The fatal flaw of IoT devices is that they place you at the whims of companies who may decide that they’re not making enough money any more, and shut them down. Keep your hacking skills sharp.

Thanks [Jan] for the great tip!