FCC Clears The Air With Wi-Fi Software Updates

November 14, 2015 by Brian Benchoff 33 Comments

A few months ago, the Internet resounded with news that the FCC would ban open source router firmware. This threat came from proposed rules to devices operating in the U-NII bands – 5GHz WiFi, basically. These rules would have required all devices operating in this band to prevent modification to the radio inside these devices. Thanks to the highly integrated architecture of these devices, Systems-on-Chips, and other cost cutting measures from router manufacturers, the fear was these regulations would ultimately prevent modifications to these devices. It’s a legitimate argument, and a number of the keepers of the Open Source flame aired their concerns on the matter.

Now, the FCC has decided to clear the air on firmware upgrades to wireless routers. There was a fair bit of confusion in the original document, given the wording, “how [its] device is protected from ‘flashing’ and the installation of third-party firmware such as DD-WRT.” This appeared to mandate wholesale blocking of Open Source firmware on devices, with no suggestion as to how manufacturers would accomplish this impossible task.

[Julias Knapp], chief of the FCC’s Office of Engineering and Technology has since clarified the Commission’s position. In response to the deluge of comments to the FCC’s Notice of Proposed Rulemaking, the phrase, ‘protected from flashing… Open Source firmware” has been removed from the upcoming regulation. There’s new, narrow wording (PDF) in this version that better completes the Commission’s goal of stopping overpowered radios without encroching on the Open Source firmware scene. The people spoke, and the FCC listened — democracy at work.

Halloween Doorbell Prop In Rube-Goldberg Overdrive

November 14, 2015 by Elliot Williams 8 Comments

[Conor] wired up his 3D-printed coffin doorbell to an array of RGB LEDs, a screaming speaker, and a spinning skull on a cordless screw driver to make a “quick” Halloween scare. Along the way, he included half of the Adafruit module catalog, a relay circuit board, and ESP8266 WiFi module, a Banana Pi, and more Arduinos of varying shapes and sizes than you could shake a stick at.

Our head spins, not unlike [Conor]’s screaming skull, just reading through this Rube Goldbergy arrangement. (We’re sure that’s half the fun for the builder!) Smoke ’em if ya got ’em!

Start with the RGB LEDs; rather than control them directly, [Conor] connected them to a WiFi-enabled strip controller. Great, now he can control the strip over the airwaves. But the control protocol was closed, so he spent a week learning Wireshark to sniff the network data, and then wrote a Bash script to send the relevant UDP packets to turn on the lights. But that was not fancy-schmancy enough, so [Conor] re-wrote the script in Go.

Yes, that’s right — a Go routine on a Banana Pi sends out custom UDP packets over WiFi to a WiFi-to-LED-driver bridge. To make lights blink. Wait until you see the skull.

The plastic skull has Neopixels in each ping-pong ball eye, controlled by an Arduino Nano and battery taped to the skull’s head. The skull is cemented to a driver bit that’s chucked in a cordless drill. A relay board and another Arduino make it trigger for 10 seconds at a time when the doorbell rings. Finally (wait for it!) an Arduino connected to the doorbell gives the signal, and sets a wire high that all the other Arduini and the Banana Pi are connected to.

Gentle Hackaday reader, now is not the time for “I could do that with a 555 and some chewing gum.” Now is the time to revel in the sheer hackery of it all. Because Halloween’s over, and we’re sure that [Conor] has unplugged all of the breadboards and Arduini and put them to use in his next project. And now he knows a thing or two about sniffing UDP packets.

Continue reading “Halloween Doorbell Prop In Rube-Goldberg Overdrive” →

Object Oriented State Machine Operating System Goes Open Source

November 14, 2015 by Al Williams 19 Comments

On a desktop computer, you think of an operating system as a big piece of complex software. For small systems (like an Arduino) you might want something a lot simpler. Object Oriented State Machine Operating System (OOSMOS) is a single-file and highly portable operating system, and it recently went open source.

OOSMOS has a unique approach because it is threadless, which makes it easy to use in memory constrained systems because there is no stack required for threads that don’t exist. The unit of execution is a C++ object (although you can use C) that contains a state machine.

You can read the API documentation online. Just remember that this is not an end user OS like Windows or Linux, but an operating environment for managing multiple tasks. You can, though, use OOSMOS under Windows or Linux as well as many other host systems.

Continue reading “Object Oriented State Machine Operating System Goes Open Source” →

Hacklet 84 – Alarm Clocks

November 13, 2015 by Adam Fabio 12 Comments

The stereotypical hardware hacker is a creature of the night. Some of us do our best work in the wee hours. The unfortunate side effect of this is that we have a hard time getting up in the morning. Sometimes life demands a hacker be up-and-at-em before noon though. In these cases, the only solution is an alarm clock. This week’s Hacklet features some of the best alarm clock projects on Hackaday.io!

We start with [hberg32] and Merciless Pi Alarm Clock. Merciless is a good name for this Raspberry Pi based clock. We have to say it’s quite snazzy with its laser cut case and large seven segment LED face. When the alarm goes off though, this Pi bites back.

Titanium drivers powered by a 20 watt amplifier will wake even the heaviest sleepers. If that’s not enough, [hberg32] added a bed shaker to vibrate you out of the sack. The snooze button only works 3 times, after that you can press all you want, the music will still play. As if that wasn’t enough, this clock even has a pressure sensor. If you get back in bed, the alarm starts up again. Truly fitting of the name “merciless”.

[Ceady] took the kinder, gentler route with Integrated Room Sunrise Simulator. This alarm clock simulates dawn, gently waking the user up. A Lutron Maestro series wireless dimmer allows the sunrise simulator to slowly increase the room’s light level over a period of 10 minutes, allowing [Ceady] to wake up silently.

The clock itself uses an ATmega168 for control. [Ceady] spent a considerable amount of time testing out different methods of creating a seven segment LED display. When casting with cornstarch and resin didn’t do the trick, he went to commercial LED diffuser film from Inventables. The film proved to be just what he was looking for.

Next up is [Spiros Papadimitriou] with DIY Chumby-lite. Taking inspiration from [Bunnie Huang] and the Chumby project, [Spiros] created a friendly alarm clock with a touchscreen LCD. Much like the Chumby, this clock packs a WiFi module.

In this case though, the WiFi module is an ESP8266, whose on-board Xtensa microcontroller runs the whole show. [Spiros] programmed his Sparkfun ESP8266 Thing in C++. To keep costs down, [Spiros] left out anything unnecessary – like a real-time clock module. The Chumby-lite uses NTP to stay regular. The reductions paid off – this clock can be built for around $13.00, not including the very nice 3D printed case.

[Wanderingmetalhead] takes us all way back to 1983 with his 7 Day Alarm Clock. 32 years ago, this was [wanderingmetalhead’s] first embedded system project. As the name implies, this clock stores a different wake time for each day of the week. Actual numeric entry sure beats the old “hold two buttons and watch the numbers spin” system.

This is an oldie. The system is based upon a Motorola (which became Freescale, and is now NXP) 6802 micro. The code was written in assembly and cross-assembled on an Apple II. A 3.58MHz colorburst crystal divided down to 60 Hz provides the time base. This setup wasn’t perfect, but good down to a about a minute a month. The whole project lived and worked in an old amplifier case, where it dutifully woke [wanderingmetalhead] each day for 17 years.

If you want to see more alarm clock projects, check out our new alarm clocks list! If I didn’t wake up early enough to catch your project, don’t be shy, just drop me a message on Hackaday.io. That’s it for this week’s Hacklet. As always, see you next week. Same hack time, same hack channel, bringing you the best of Hackaday.io!

DIY Matchhead Cannon Brings The Heat

November 13, 2015 by Kristina Panos 20 Comments

If your local surplus store is fresh out of supercapacitors but you’re just really in the mood to fire stuff at other stuff, check out [austiwawa]’s step-by-step guide to building a thermal cannon. It shoots whatever will fit into a 1/2″ copper pipe, propelled by cut-up matchheads and lit by a propane torch. [austiwawa] demonstrates it by firing an AA battery at an unsuspecting pumpkin. For what it’s worth, we don’t necessarily condone applying this much heat to alkaline cells.

[austiwawa] used a copper pipe for the barrel because it provides the fastest heat transfer. One end of it is flattened and folded over to form the propellant chamber. A couple of packs worth of match heads are tamped down into the folded end with a paper towel serving as wadding. [austiwawa] tosses in his battery, lights the torch, and then runs away.

This whole dangerous contraption is secured to a wooden base with a u-bolt and a couple of pipe straps, and suspended between more pieces of wood with a length of threaded rod for stability and aiming.

We’ll let the safety-conscious readers do our work for us in the comments, but in the meantime, note that this thing is not safe. As [austiwawa] demonstrates, the copper gets brittle and will split open along the folded edge.

But kudos anyway to [austiwawa] for showing shot after shot of the cannon in action at the end of his video. You know where to find it.

If it’s a stronger, more beautiful barrel you’re after, just machine one by hand.

Continue reading “DIY Matchhead Cannon Brings The Heat” →

Repairing A Twisted Prius Display Computer

November 13, 2015 by Anool Mahidharia 17 Comments

This one is from way back in 2007, but the steps [hobbit] took to evaluate and repair a failed Prius Multi-Function Display (MFD) is a refresher course in how to go about fixing stuff that’s broken.

The 2004 / 2005 models of the Prius had peculiar problems with their MFD. Buttons and touch functions became sluggish and unresponsive, it wouldn’t display ECU data such as current and average fuel consumption, and couldn’t control stereo and air-conditioning. Lots of Prius users were reporting similar problems on the Priuschat forum.

The issues would usually arise long after warranty expired, and replacement units cost a couple of thousand dollars new. Toyota knew what the problem was (PDF link), but their fix involved swapping the defective units out.

[hobbit] managed to get a defective MFD unit from a friend, and because his own Prius still had a working MFD, he was able to carry out comparative tests on both units. The broken unit was generally laggy, and the buttons didn’t beep when pressed. Apparently, the AVCLan, a small data network between various components in the car, wasn’t reaching the MFD reliably. The MFD would send the “beep” command to the audio amplifier and wait for a confirmation that would never arrive. The system hung here until the MFD timed out.

In the end, the cause of the problem was the 60-pin micro connector that interfaces the two main boards of the MFD. Once the two are mated, tightening the mounting screws twisted the two boards ever so slightly, leading to flaky contacts.

The fix? [hobbit] tweaked all of the 60 pins outwards enough that they still made contact even when the connector housing got twisted. Comparing the defective MFD to the one in [hobbit]’s own car also demonstrated how the factory fixed the problem.

Thanks to [Nick] for sending in this tip, which he stumbled upon “while searching for ideas for a very small solder tip to repair something on my laptop.”

A Better, Open Hardware Keyboard

November 13, 2015 by Brian Benchoff 47 Comments

A keyboard is the most important tool in the modern desk jockey’s arsenal but, despite this fact, millions of people suffer the $10 membrane keyboards that shipped with the computer they got a decade ago. It’s a terrible way to live your life, but for those of us who are enlightened, there’s another way: mechanical keyboards. [Mário] over at the Bit Bang Theory just built his own mechanical keyboard with his own homebrew firmware and a few interesting features that aren’t found in other open hardware keyboard projects.

The ‘from scratch’ aspect of this build is somewhat of a misnomer; the key switches used in this build were taken from a Monterey K108, and the key caps were taken from a keyboard with a Portuguese layout. Once the switches were in place and soldered up, it was time for the electronics.

While most homebrew keyboards these days use a Teensy 2 thanks to some amazing firmware and development tools that have grown up around this device, there’s not a Teensy to be found inside this keyboard. The keyboard controller is built around a PIC18F4550 and uses the USB available on the chip. Naturally, there are more than a few WS2812b RGB LEDs around the edge of the keyboard that “breathe”, run a KITT-style LED chaser, or simply display a single chosen color.

There are a few neat features in this keyboard controller that aren’t readily available with other open source keyboard firmwares. There’s a keylogger, macro recorder, and a toggle macro that will activate or deactivate a (secret) internal 8GB USB storage key. Settings are saved in the internal EEPROM.

It’s a great looking build, and something we don’t see enough of around here. In any event, it’s just one step further towards eliminating the menace of cheap keyboards, and something we hope to see more of soon.