Why You’ve Never Heard About Nintendo’s U-Force

90’s kids think that the Power Glove was the coolest game peripheral of the epoch. We might have thought so too, until we heard about Don’t Touch: The Story of the U-Force from [The Gaming Historian].

The device itself folded up like a laptop, and on the two surfaces had four IR LED/sensor pairs. All of these combined would localize your fist in space for playing Mike Tyson’s Punch Out, or would work with various other passive controller add-ons like a flight yoke for playing Top Gun. (One of the coolest bits is the flip-out IR reflectors triggered by the buttons in the yoke.)

All-in-all, the video’s take is that a number of factors doomed the U-Force to play second fiddle to the Power Glove. Battling Mattel’s marketing prowess is obvious, but other things like manufacturing problems due to bad hinges and inconsistent IR sensors delayed release and added cost. In the end, though, [Dave Capper], the U-Force’s inventor, puts it down simply to non-convincing gameplay. There were no blockbuster games that used it to its full potential.

At the time, the U-Force utilized more IR LEDs than any other consumer electronic device.

We think there’s interesting hacker potential in a simple interface like this. Perhaps its biggest Achilles heel outside of the lack of a killer application was the fact that it required calibration. We can imagine all sorts of awesome interactions, and we’re not afraid of a little tweaking. Or maybe we would update the sensors to something more modern, like those inexpensive time-of-flight distance units.

Thanks [Karl Koscher] for bringing this documentary to our attention in the comments about the very similarly interesting laser theremin project we featured last year. It’s definitely opened our eyes to an old interaction of the past that would seem no less magical today.

Continue reading “Why You’ve Never Heard About Nintendo’s U-Force”

Streamlining The Toolchain

Sometimes I try to do something magical, and it works. Most of the time this happens because other people have done a good part of the work for me, and shared it. I just cobble a bunch of existing tools into a flow that fits my needs. But the sum of all the parts is often less than the whole, when too many of the steps involve human intervention. Tools made for people simply keep the people in the loop.

For instance, I wanted to take a drawing that my son made into a stamp, by way of a CNC machine and whatever scrap wood we have kicking around in the basement. It’s easy enough, really. Take the photo, maybe use a little tweaking in GIMP to get the levels right, export it into Inkscape for the line detection and maybe even make the GCode right there, or take it off to any convenient SVG-to-GCode tool.

While this works straight out of the box for me, it turns out that’s because I have experience with all of the sub-tools. First, it helps a lot if you get the exposure right in the first place, and that’s not trivial when your camera’s light meter is aiming for grey, but the drawing is on white paper. Knowing this, you could set it up to always overexpose, I guess.

Still, there’s some experience needed in post-processing. If you haven’t played around with both image processing and image editing software, you don’t know how they’re going to interact. And finally, there are more parameters to tweak to get the CNC milling done than a beginner should have to decide.

In short, I had a toolchain up and running in a jiffy, and that’s a success. But in terms of passing it on to my son, it was a failure because he would have to learn way too many sub-tools to make it work for him. Bummer. I’m left wondering if I can streamline all of the parts to work together well enough, or whether I’m simply needed in the loop.

The Quiet Before The Storm?

My wife and I are reading a book about physics in the early 1900s. It’s half history of science and half biography of some of the most famous physicists, and it’s good fun. But it got me thinking about the state of physics 120 years ago.

What we’d now call classical mechanics was fully settled for quite a while, and even the mysterious electricity and magnetism had been recently put to rest by Maxwell and Heaviside. It seemed like there was nothing left to explain for a while. And then all the doors broke wide open.

As much as I personally like Einstein’s relativity work, I’d say the most revolutionary change in perspective, and driver of the most research in the intervening century, was quantum mechanics. And how did it all start? In the strangest of ways – with Niels Bohr worrying about why hydrogen and helium gasses gave off particular colors when ionized, which lead to his model of the atom and the idea of energy in quantum packets. Or maybe it was De Broglie’s idea that electrons could behave like waves or magnets, from slit and cathode-ray experiments respectively, that lead to Heisenberg’s uncertainty principle.

Either way, the birth of the strangest and most profound physics revolution – quantum mechanics – came from answering some ridiculously simple and straightforward questions. Why does helium emit pink, and how do TVs work? (I know, they didn’t have TVs yet…) Nobody looking at these phenomena, apart or together, could have thought that answering them would have required a complete re-thinking of how we think about reality. And yet it did.

I can’t help but wonder if there are, in addition to the multi-bazillion dollar projects like the Large Hadron Collider or the James Webb Space Telescope, some simpler phenomena out there that we should be asking “why?” about. Are we in a similar quiet before the storm? Or is it really true that the way to keep pushing back the boundaries of our ignorance is through these mega-projects?

2022 Hackaday Supercon: Call For Proposals Extended

Good news, procrastinators and those of you who simply have not yet worked up the nerve to submit! The 2022 Hackaday Supercon Call for Proposals has been extended one more week. You’ve been waiting until the last minute? Well, it’s now one minute past the last minute, but we’ve got your back. You have until Thurs, Sep. 1 to get your talk or workshop proposal in. (We’re not extending it twice!)

Everyone has a good story to share. Whether it’s a tale of software or hardware, or that tricky “firmware” that falls somewhere in the middle, we have a crowd who would love to hear it. You almost never leave a project as the same person who entered it, and you should tell us your story. We have two talk tracks, one for shorter talks and demos of around 20 minutes, and one for epic sagas of 45 minutes or so. Whether you’re a first-time presenter or a seasoned pro, we’d like to hear about your hacks.

To sweeten the pot, all presenters get in free. So what are you waiting for? Send in your ideas now – you’ve got a couple months to get the slides into shape.

Dream Projects Face Reality

Do you ever get a project stuck in your mind? An idea so good you just keep thinking about it? Going over iterations and options and pros and cons in the back of your mind, or maybe on paper, but having not yet subjected it to the hard work of pulling it into reality? I’ve had one of those lurking around for the last couple weeks, and it’s time for me to get building.

And I’ve got to get started soon, because it’s rare that any project makes the leap from thought to reality unscathed, and when I hold on to the in-thought project too long, I become far too fond of some of the details and nuances that just might not make the cut, or might get in the way of getting a first pass finished. When I really like a (theoretical) solution to a (theoretical) problem, I’ll try to make it work a lot longer than I should, and I can tell I’m getting attached to this one now.

The only cure to this illness is to get prototyping. When the rubber hits the road, and the bolts are tightened, either the solution is a good one or it’s not, and no amount of dreaming is going to change that. Building is a great antidote to the siren song of a dream project. Although it feels now like I don’t want the fantasy to have to adapt to reality, as it inevitably will, I know that getting something working feels a lot better. And it frees me up to start dreaming on the next project… To the workshop!

RollBack Breaks Into Your Car

Rolling codes change the signal sent by car keyfobs unpredictably on every use, rendering them safe from replay attacks, and we can all sleep well at night. A research team lead by [Levente Csikor] gave a presentation at Black Hat where they disclose that the situation is not pretty at all (PDF).

You might know [Samy Kamkar]’s RollJam attack, which basically consists of jamming the transmission between fob and car while the owner walks away, fooling the owner into clicking again, and then using one of the two rolling codes to lock up the car, keeping the other in your back pocket to steal it once they’re getting coffee. This is like that, but much, much worse. Continue reading “RollBack Breaks Into Your Car”

We’re Hiring: Come Join Us!

You wake up in the morning, and check Hackaday over breakfast. Then it’s off to work or school, where you’ve already had to explain the Jolly Wrencher to your shoulder-surfing colleagues. And then to a hackspace or back to your home lab, stopping by the skull-and-cross-wrenches while commuting, naturally. You don’t bleed red, but rather #F3BF10. It’s time we talked.

The Hackaday writing crew goes to great lengths to cover all that is interesting to engineers and enthusiasts. We find ourselves stretched a bit thin and it’s time to ask for help. Want to lend a hand while making some extra dough to plow back into your projects? We’re looking for contributors to write a few articles per week and keep the Hackaday flame burning.

Contributors are hired as private contractors and paid for each article. You should have the technical expertise to understand the projects you write about, and a passion for the wide range of topics we feature. You’ll have access to the Hackaday Tips Line, and we count on your judgement to help us find the juicy nuggets that you’d want to share with your hacker friends.

If you’re interested, please email our jobs line (jobs at hackaday dot com) and include:

  • One example article written in the voice of Hackaday. Include a banner image, at least 150 words, the link to the project, and any in-links to related and relevant Hackaday features. We need to know that you can write.
  • Details about your background (education, employment, interests) that make you a valuable addition to the team. What do you like, and what do you do?
  • Links to your blog/project posts/etc. that have been published on the Internet, if any.

What are you waiting for? Ladies and Gentlemen, start your applications!