Fail Of The Week: Sonar Submersibility Sealing

October 2, 2014 by Kristina Panos 45 Comments

For the last decade or so, [Jason] has wanted to build an underwater robot. Can you blame him? More recently, he’s been researching sonar sensing and experimenting with the relatively inexpensive HC-SR04 module. Since he had good luck getting it to work with a PC sound card and a Stellaris Launchpad, he figured it was time to try using it underwater.

Hydrophone research led him to the idea of submerging the sensor in mineral ~~water~~ oil to both seal it and couple it with the water. Unfortunately, the HC-SR04 only sends one pulse and waits for echo. Through the air, it reliably and repeatedly returned a small value. Once inside a pill bottle filled with mineral oil, though, it does something pretty strange: it fluctuates between sending back a very small value and an enormous value. This behavior has him stumped, so he’s going to go back to the Launchpad unless you can help him figure out what’s going on. Should he use a different method to seal it?

Fail of the Week is a Hackaday column which runs every Thursday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Ask Hackaday: Help NASA With Their High Altitude Problem

October 1, 2014 by Will Sweatman 97 Comments

image of hackaday logo on box at high altitude

Unless you’ve been living under a high voltage transformer, you’ve probably heard that NASA has grounded the Space Shuttle fleet. This makes getting stuff to and from the International Space Station slightly more difficult. With the growing need to get small experiments back to the surface quickly and safely, NASA is researching an idea they call Small Payload Quick Return, or SPQR (pdf warning). Basically, they toss the experiment out of the window, use drag to slow it down, and then use a High Altitude High Opening (HAHO) self guiding parafoil to steer the thing down to a predefined location on the surface.

Now, what we’re interested in is the self guided parafoil part, as it takes place in known hacker territory – around 100,000 feet. This is the altitude where most high altitude balloon experiments take place. NASA is throwing a bunch of money and brainpower to research this part of the system, but they’re having problems. Lots of problems.

Stick around after the break and see if you can help, and maybe pick up some ideas on how to steer your next High Altitude Balloon project back to the launch pad.

Continue reading “Ask Hackaday: Help NASA With Their High Altitude Problem” →

Developed On Hackaday: Sometimes, All You Need Is A Few Flags

October 1, 2014 by Mathieu Stephan 26 Comments

The development of the Hackaday community offline password keeper has been going on for a little less than a year now. Since July our beta testers have been hard at work giving us constant suggestions about features they’d like to see implemented and improvements the development team could make. This led up to more than 1100 GitHub commits and ten thousand lines of code. As you can guess, our little 8bit microcontroller’s flash memory was starting to get filled pretty quickly.

One of our contributors, [Miguel], recently discovered one compilation and one linker flags that made us save around 3KB of Flash storage on our 26KB firmware with little added processing overhead. Hold on to your hats, this write-up is going to get technical…

Many coders from all around the globe work at the same time on the Mooltipass firmware. Depending on the functionality they want to implement, a dedicated folder is assigned for them to work in. Logically, the code they produce is split into many C functions depending on the required task. This adds up to many function calls that the GCC compiler usually makes using the CALL assembler instruction.

This particular 8-bit instruction uses a 22-bit long value containing the absolute address of the function to call. Hence, a total of 4 flash bytes are used per function call (without argument passing). However, the AVR instruction set also contains another way to call functions by using relative addressing. This instruction is RCALL and uses an 11-bit long value containing the offset between the current program counter and the function to call. This reduces a function call to 2 bytes and takes one less clock cycle. The -mrelax flag therefore made us save 1KB by having the linker switch CALL with RCALL instructions whenever possible.

Finally, the -mcall-prologues compiler flag freed 2KB of Flash storage. It creates master prologue/epilogue routines that are called at the start and end of program routines. To put things simply, it prepares the AVR stack and registers in a same manner before any function is executed. This will therefore waste a little execution time while saving a lot of code space.

More space saving techniques can be found by clicking this link. Want to stay tuned of the Mooltipass launch date? Subscribe to our official Google Group!

Retrotechtacular: The First Atlas Launch

September 30, 2014 by Kristina Panos 31 Comments

As the Cold War conflict expanded in the 1950s, the Soviet Union dry-tested a hydrogen bomb and defense tactics became a top priority for the United States. Seeking to create a long-range nuclear missile option, the Air Force contracted Convair Astronautics to deliver SM-65 Atlas, the first in series of ICBMs. In the spotlight this week is a sort of video progress report which shows the first launch from Cape Canaveral’s LC-14 on June 11, 1957.

After the angle of attack probe is unsheathed, everyone moves out of the way. The launch is being monitored by base central control, but the swingin’ spot to spectate is the blockhouse. They have a periscope and everything. As the countdown continues, liquid oxygen pipelines whistle and wail into the idyllic Florida afternoon with the urgency of a thousand teakettles. Cameras and tracking equipment are readied, and the blockhouse’s blast door is sealed up tight.

Continue reading “Retrotechtacular: The First Atlas Launch” →

Hacklet 17 – Keyboards

September 26, 2014 by Adam Fabio 18 Comments

This week on The Hacklet we’re featuring some of the best keyboard hacks from Hackaday.io!

Hackers are really into their keyboards. Everyone has a favorite, and those favorites vary wildly. Mechanical, soft touch, ergonomic, QWERTY, DVORAK, chorded, you name it, there is a hacker, maker, or engineer who loves it, or absolutely hates it. For some, no commercial product is perfect. All is not lost though, as a custom keyboard is just a hack away!

[Warren Janssens] gets things rolling with Ergo60, his 60 key ergonomic keyboard. [Warren’s] layout is a pair of 25 key hand clusters, each with a matching 5 key thumb cluster. This layout minimizes lateral wrist movement. With the reduced key count and stacked keys, the user’s hands never move from the home row. [Warren] rolled his own PCBs for Ergo60. A Teensy 2.0 running a fork of TMK serves as Ergo60’s controller. [Warren’s] is running Cherry Black switches and his keycaps are from Signature Plastics. [Warren] is using Ergo60 as his daily driver these days, so it’s no surprise that he’s set the “Completed Project” tag.

Some say he needs no keyboard at all, and that his heartbeat sounds just like an IBM Model M. All we know is he’s called [Brian Benchoff]. [Brian’s] created a pair of minimalist keyboard projects. The Unhappy Hacking Keyboard takes us back to basics. After all, computers run on 1’s and 0’s, right? What more could a person need? Apparently just a space and return. Unhappy Hacking Keyboard uses an ATtiny85 with V-USB as the controller and the interface. Keys are cherry MX blues. The keycaps are [Brian’s] own Hackaday Cherry MX Keycaps printed by Shapeways.

An entire generation of hackers don’t know the joy of typing on a tiny rubber keyboard. [Alistair MacDonald] aimed to fix that, so he turned an old computer into a keyboard with his ZX Keyboard. [Alistair] started with a broken ZX Spectrum. He gutted the original electronics and added an Ardunio Pro Mini running the V-USB library. [Alistair] directly wired the row and column I/O lines from the keyboard to his Arduino. The result is a keyboard which is the perfect size for cell phones, Raspberry Pi’s and the like.

[Servo] teaches us new ways to type with Chordy KEY, his chording keyboard project. Chordy Key is meant to be used in the left hand. Five finger buttons and three thumb buttons are all that is needed to chord out 64 different letters and symbols. [Servo] utilized an ATmega32U4 powered Sparkfun pro micro to control his keyboard. Chordy Key is a proof of concept, but with [Servos’s] use of 3D printed parts, Chordy Key looks like it’s ready for your next wearable computing project!

[jmptable] is also working on a chorded keyboard design. Chord Keyboard uses only 7 keys to send the entire ASCII character set and a few control combinations. [jmptable] used an ATmega328P as his processor. Chord keyboard isn’t wired though. An RN-42-HID module provides bluetooth connectivity to the world.

[jmptable] has provided an amazing amount of detail on his research, including one of his goals of adding a chorded keyboard to the Gameboy Advance. They keyboard itself would be mounted on the spine of a game cartridge. We would love to see that idea come to fruition, [Servo]!

Finally we have [Gertlex], who just wanted a scroll wheel embedded in his keyboard. He got there with the help of an Apple Mighty Mouse. Keyboard with Apple Mouse Scroll Ball is one of those hacks that looks like it original equipment. [Gertlex] took a drill to a Targus slim USB keyboard, putting a small hole right between the ESC and F1 keys. He fit the scroll ball from his Apple Mighty Mouse in the hole. Electronics are as simple as plugging the mouse and keyboard into the same USB hub. The only downside to the design is that [Gertlex’s] keyboard doesn’t recognize fast enough to send key presses during the boot process.

That’s just about enough keystrokes for this episode of The Hacklet. As always, see you next week. Same hack time, same hack channel, bringing you the best of Hackaday.io!

Update – check our our keyboard list right here!

Fail Of The Week: Battery Packin’

September 25, 2014 by Kristina Panos 35 Comments

[NeXT] got himself an IBM ThinkPad TransNote and yeah, we’re pretty jealous. For the uninitiated, the TransNote was IBM’s foray into intelligent note transcription from roughly fifteen years ago. The ThinkPad doesn’t even have to be on to capture your notes because the proprietary pen has 2MB of flash memory. It won an award and everything. Not the pen, the TransNote.

Unfortunately, the battery life is poor in [NeXT]’s machine. The TransNote was (perhaps) ahead of its time. Since it didn’t last on the market very long, there isn’t a Chinese market for replacement batteries. [NeXT] decided to rebuild the replacement battery pack himself after sending it off with no luck.

The TransNote’s battery pack uses some weird, flat Samsung 103450 cells that are both expensive and rare. [NeXT] eventually found some camera batteries that have a single cell and a charge controller. He had to rearrange the wiring because the tabs were on the same side, but ultimately, they did work. He got the cells together in the right configuration, took steps to prevent shorts, and added the TransNote’s charge controller back into the circuit.

Nothing blew up, and the ThinkPad went through POST just fine. He plugged it in to charge and waited a total of 90 minutes. The charging rate was pretty lousy, though. At 94% charge, the estimated life showed 28 minutes, which is worse than before. What are your thoughts on the outcome and if it were you, what would be the next move?

Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Retrotechtacular: The Diesel Story

September 23, 2014 by Kristina Panos 50 Comments

The diesel engine was, like many things, born of necessity. The main engine types of the day—hot bulb oil, steam, coal gas, and gasoline—were not so thermally efficient or ideal for doing heavy-duty work like driving large-scale electrical generators. But how did the diesel engine come about? Settle in and watch the 1952 documentary “The Diesel Story“, produced by Shell Oil.

The diesel engine is founded on the principle of internal combustion. Throughout the Industrial Age, technology was developing at breakneck pace. While steam power was a great boon to many burgeoning industries, engineers wanted to get away from using boilers. The atmospheric gas engine fit the bill, but it simply wasn’t powerful enough to replace the steam engine.

By 1877, [Nikolaus Otto] had completed work on his coal gas engine built on four-stroke theory. This was the first really useful internal combustion engine and the precursor of modern four-stroke engines. It was eventually adapted for transportation with gasoline fuel. In 1890, the hot bulb oil engine was developed under the name Hornsby-Akroyd and primarily used in stationary power plants. Their flywheels had to be started manually, but once the engine was going, the bulb that drove combustion required no further heating.