Blindingly Fast ADC For Your BeagleBone

July 31, 2016 by Elliot Williams 28 Comments

[Jason Holt] wrote in to tell about of the release of his PRUDAQ project. It’s a dual-channel 10-bit ADC cape that ties into the BeagleBone’s Programmable Realtime Units (PRUs) to shuttle through up to as much as 20 megasamples per second for each channel. That’s a lot of bandwidth!

The trick is reading the ADC out with the PRUs, which are essentially a little bit of programmable logic that’s built on to the board. With a bit of PRU code, the data can be shuttled out of the ADC and into the BeagleBone’s memory about as fast as you could wish. Indeed, it’s too fast for the demo code that [Jason] wrote, which can’t even access the RAM that fast. Instead, you’ll want to use custom kernel drivers from the BeagleLogic project (that we’ve covered here before).

But even then, if you don’t want to process the data onboard, you’ve got to get it out somehow. 100 mbit Ethernet gets you 11.2 megabytes per second, and a cherry-picked flash drive can save something like 14-18 megabytes per second. But the two 10-bit ADCs, running full-bore at 20 megasamples per second each, produces something like 50-80 megabytes per second. Point is, PRUDAQ is producing a ton of data.

So what is this cape useful for? It’s limited to the two-volt input range of the ADCs — you’ll need to precondition signals for use as a general-purpose oscilloscope. You can also multiplex the ADCs, allowing for eight inputs, but of course not at exactly the same time. But two channels at high bandwidth would make a great backend for a custom SDR setup, for instance. Getting this much ADC bandwidth into a single-board computer is an awesome trick that used to cost thousands of dollars.

We asked [Jason] why he built it, and he said he can’t tell us. It’s a Google Research project, so let the wild conjecture-fest begin!

4-Bit Audio Output Via Voltage Reference

July 30, 2016 by Elliot Williams 18 Comments

[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

July 30, 2016 by Elliot Williams 23 Comments

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

July 29, 2016 by Elliot Williams 3 Comments

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

July 28, 2016 by Elliot Williams 48 Comments

[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!

July 28, 2016 by Elliot Williams 114 Comments

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.

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

July 27, 2016 by Elliot Williams 53 Comments

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” →