Syndicate content Hackaday
Fresh hacks every day
ถูกปรับปรุง 2 hours 5 min ก่อน

Hackaday Prize Semifinalist: Individualized Breathing Apparatus

เสาร์, 09/26/2015 - 12:00

Preterm infants frequently require ventilator support while they’re in the neonatal ICU, and this is usually done with a CPAP machine. The machine to infant interface is called a nasal cannula, a bit of plastic that connects an infant’s nose to the machine. Because there aren’t that many sizes of nasal cannula available, and preemies come in all sizes, there are inevitable problems. Ill-fitting nasal cannula can reduce the effectiveness of a CPAP, and can even cause significant damage to an infant’s septum.

For his Hackaday Prize entry, [Ben] is tackling this problem head on. He’s working on creating individualized nasal cannula for newborns using 3D modeling and printing, allowing nasal cannula of all shapes and sizes to be created in a matter of hours.

To create these customized cannula, [Ben] is 3D scanning an infant mannequin head to gather enough data to import it into a Processing sketch. A custom cannula is then created and printed with flexible 3D printer filament. In theory, it should work, apart from the considerations involved in building a medical device.

As for why custom plastic tubes matter, [Ben] works at the only NICU in Western Australia. Even though he only sees 8-10 CPAP ‘pressure injuries’ in his unit each year, these kids are extremely fragile and some parents have expressed a desire for something that isn’t as uncomfortable for their newborn than the off-the-shelf solution. Customizing these cannula from a quick 3D scan is a great way to do that, and a perfect example of the Hackaday Prize theme of ‘build something that matters.’

The 2015 Hackaday Prize is sponsored by:
Filed under: slider, The Hackaday Prize

STM32 JavaScript Peeks and Pokes

เสาร์, 09/26/2015 - 09:01

A lot of people find scripting languages very productive and we’ve seen quite a few chips now supporting what you normally think of as a scripting language. These high-level abstraction languages are great, until they aren’t. When you need to go under the abstraction and do something complex or you need every cycle of performance, you might have to break your normal tools.

The Espruino is an ARM processor (an STM32) that has JavaScript on board. However, [Gordon Williams] shows how you can use peeks and pokes to access the hardware directly when the need arises. The names derive from another popular abstraction’s escape hatch. The old BASIC languages allowed direct memory access using keywords peek and poke. [Gordon] shows some examples of accessing the timer for PWM, and even looks at the STM32 reference manual to show how he knew where to peek and poke to begin with.

We dislike abstraction layers you can’t break. If C couldn’t embed or call assembly, it wouldn’t be as powerful as it is, for example. Giving advanced users a way to break your abstraction makes it more useful in more situations.

You might enjoy an earlier post if you want to learn more about the Espruino (and check out the video below for a JavaScript/Espruino-driven robot). Another popular embedded scripting language is Lua–we’ve done many posts on the ESP8266 running it.

Filed under: ARM, Microcontrollers

Hacklet 77 – Projects that Tweet

เสาร์, 09/26/2015 - 06:01

Since it’s launch way back in 2006, Twitter has become a magnet for techies. Maybe it’s the simple interface, maybe it’s the 140 character limit. Whatever the reason, you can find plenty of hackers, makers, and engineers tweeting about their daily activities. It didn’t take long for folks to start incorporating Twitter into their projects. Ladyada’s Tweet-a-watt is a great early example of this. This week’s Hacklet is all about some of the best tweeting projects on Hackaday.io!

We start with [Henry Conklin] and A Twitter account for my dog. [Henry’s] dog [Oliver] loves to bark and finding a solution became his entry to The Hackaday Prize. Rather than bring Cesar Millan in, [Henry] decided to embrace [Oliver’s] vocalizations by sending them up to the cloud. A Raspberry Pi with a USB microphone uses some custom Python code to detect barks and ruffs. The Pi then sends this data to Twitter using the python-twitter library. The Pi is connected to the internet via a USB WiFi dongle. You can see the results of [Henry’s] work on [Oliver’s] own Twitter page!

Next up is [troy.forster] and tweetie-pi. Rather than constantly check his phone or computer, [Troy] wanted a device to read his tweets. A bit of NodeJS code later, and tweetie-pi was born. A Raspberry Pi connected to the internet pulls data through the Twitter stream API. When tweets directed at a pre-configured username are found, the data is sent to a an Emic 2 text to speech module. The Emic reads in that classic DECtalker style voice we all know and love from the movies. [Troy] even added code to properly handle usernames and retweets.


[SirClover] joined the internet of things by creating Home automation system with Twitter, his entry in the 2014 Hackaday Prize. This home automation system is based around an Arduino Leonardo and an Ethernet shield. [SirClover] rolled his own custom PCB to handle relays, a Cds cell, and a 2×16 character LCD. The system can be accessed through a simple web interface. This allows the user to open or close blinds, turn on lights, all that great smart home stuff. Every time it executes a command, the home automation system reports status to Twitter.

Finally we have [Jakob Andrén] with A danceable notification cube, which is [Jakob’s] entry in the 2015 Hackaday Prize. The cube itself is a translucent box that contains a metric crapton of LEDs. 148 Neopixels and 12 3W power LEDs to be exact. All these LEDs are driven by a Teensy 3.1, which serves as the main processor for the entire system. The Teensy reads position data from an MPU6040 IMU. This allows it to change brightness and color as the box is moved around – or “danced”. An ESP8266 provides the cube with data from the interwebs, specifically Facebook and Twitter. The cube lights up and flashes whenever it receives a message.

If you want to see more tweeting projects, check out our new projects that tweet list.  Did I miss 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!

Filed under: Hackaday Columns

2015 RedBull Creation Competition is Underway!

เสาร์, 09/26/2015 - 04:31

I’m here as a judge at the 2015 RedBull Creation Competition in Detroit — it’s a super intense 72 hour build off where makers, engineers, and artists can come to show us what they’ve got. This year’s theme is pretty broad: Serious Fun.

The event is at Recycle Here and is open to the public, so if you’re in the area, come check it out! A massive recycling depot warehouse has been temporarily transformed into a giant workshop. Teams have access to some serious tools including heavy duty welding equipment, industrial forming tools like pipe benders, brake presses, your standard drill presses, cutting equipment and of course laser cutters and 3D printers.

There are two competition categories — Open Class, which was free for anyone to join with a team, and Invite Only. The six Invite Only teams are working in the Recycle Here workshop, and the teams competing in the open category are scattered across the city, making use of their own workshops or hackerspaces. The theme was only just announced yesterday, and the 72 hour countdown has been ticking away ever since.  I can’t wait to see what awesome interactive projects can be built in time to show off to the public this weekend.

Stay tuned for competition updates. If you can’t wait, why not check out our coverage from last year? [Mike] and [Brian] had a blast.

Filed under: cons, news

Let’s Make Robots Changes Hands: Kerfuffle Ensues

เสาร์, 09/26/2015 - 03:01

There’s been a bit of a shakeup at Let’s Make Robots (LMR).

LMR is possibly the most popular DIY robotics website around and was started up by a fun-loving Dane, [Frits Lyneborg]. It grew a large community around building up minimal robots that nonetheless had a lot of personality or pushed a new technical idea into the DIY robotics scene. [Frits] says that he hasn’t had time for DIY robotics for a while now, and doesn’t have the resources to run a gigantic web forum either, so he worked out a deal to let the Canadian hobbyist supply company Robot Shop take it over.

LMR has always been a little bit Wild-West, and many of the members quite opinionated, and that’s been part of its charm. So when the new corporate overlords came in, set up “Rules” (which have seemingly been downgraded to “suggestions”) and clarified the ownership of the content, some feathers were ruffled.

A few weeks later, everything looks to be settling back down again. (Edit: Or has it?!? See the comments below.) We wish LMR all the best — everyone loves robots, and LMR is a tremendous resource for the newbie interested in getting into DIY robotics on the cheap. More than a few LMR posts have been featured here at Hackaday over the years. Among our favorites are this drumming rovera clever 3D printed gripper, and this wicked bicycle-style balancer.

Filed under: news, robots hacks

Embed With Elliot: Interrupts, the Bad

เสาร์, 09/26/2015 - 00:01

We love interrupts in our microcontroller projects. If you aren’t already convinced, go read the first installment in this series where we covered the best aspects of interrupts.

But everything is not sunshine and daffodils. Interrupts take place outside of the normal program flow, and indeed preempt it. The microcontroller will put down whatever code it’s running and go off to run your ISR every time the triggering event happens. That power is great when you need it, but recall with Spider-Man’s mantra: With great power comes great responsibility. It’s your responsibility to design for the implicit high priority of ISRs, and to make sure that your main code can still get its work done in between interrupt calls.

Put another way, adding interrupts in your microcontroller code introduces issues of scheduling and prioritization that you didn’t have to deal with before. Let’s have a look at that aspect now, and we’ll put off the truly gruesome side-effects of using interrupts until next time.

Starvation: Long Interrupts

Let’s go back to a concrete example. Imagine that you’ve got some input coming in from an accelerometer, and you’d like to do a bunch of math on it to figure out which way your board is pointing, and then maybe you’d like to send that tilt information out to a serial terminal for debugging.

The naïve approach is to handle all the math and serial stuff inside the interrupt. After all, you only need to process the incoming accelerometer data when it’s new, and the interrupt fires once for each new value. It seems like a perfect match, no?

ISR(INT1_vector){ read_accelerometer(); complicated_math(); wait_for_serial_line_to_clear(); send_results(); } int main(void){ while(1){ do_stuff(); if (emergency_shutdown_pressed()){ turn_off_killer_laser(); } } }

To make the example more drastic, we’ve also implemented an emergency shutdown for a killer laser by polling in the main() loop. Just looking at the main loop, we should be in good shape if do_stuff() runs very quickly, right? The emergency shutdown will get polled quite frequently, right?

Nope. We are hiding away a lot of work in our ISR, and because it’s in an ISR it preempts code running in the main body. So while the ISR is doing heavy math and queuing up data for output, the killer laser is burning through your lab. Clearly, we’ve at least got a priority mismatch here; there’s no way sending numbers to a screen is more important than user safety, right? But even without the priority problem, we’ve got an ISR that does too much.

The problem with heavy-weight interrupts is compounded when you have many inputs handled by interrupts. Your code may end up spending all of its time in ISRs, and have very little time left for the main routine, starving it. If, for instance, you have two long-running ISRs and the second is triggered while the first is still running, and then the first re-triggers while the second is running and so forth, your main loop may never see any CPU time at all.

The golden rule of ISR-writing is this: keep it short and sweet. ISRs are the highest-priority parts of your code, so treat them with respect. Do only the absolute minimum in the interrupt, and allow your code to return to normal as fast as possible.

Trimming your ISRs down to the bare minimum isn’t even very hard, but it requires declaring a few additional variables that can be passed between the ISR and the main flow. That way, instead of handling the once-per-update serial transmission inside the ISR, you can simply flag that it needs handling and let the main routine take care of it. For instance:

ISR(INT0_vector){ /* now handles killer laser shutdown */ turn_off_killer_laser(); } /* Some volatile variables to pass to/from the ISR */ volatile uint8_t raw_accelerometer_data; volatile enum {NO, YES} has_accelerometer_data = NO; ISR(INT1_vector){ raw_accelerometer_data = read_accelerometer(); has_accelerometer_data = YES; } int main(void){ while(1){ do_stuff(); if (has_accelerometer_data == YES){ complicated_math(); wait_for_serial_line_to_clear(); send_results(); has_accelerometer_data = NO; } } }

We’ve moved the laser kill switch off to the highest-priority interrupt. You may also be required by law to have a physical kill switch in real life but automated kill switches based on out-of-spec data are often included where danger to humans exists.

Now the accelerometer ISR doesn’t do more than it needs to — records the new data and sets a flag that lets the main body of the code know that it’s got something new to process. We’ve also made the complicated_math() preemptable by putting it in main() instead of an interrupt.

Those of you who followed the interrupt vs. polling debate from the last installment will recognize this as being a hybrid: the interrupt acquires the data, while the main routine polls for new data (in the form of the has_accelerometer_data flag) and does the slower and lower-priority serial handling. This splits up the accelerometer-handling task into low- and high-priority operations, and handles them in the appropriate places. All is well.

Finally, another viable pattern for this example would be to have a text buffer for handling data to be sent out over the serial interface, and poll that buffer each time around the main loop. That way, multiple subroutines can easily share the serial service. For simple situations, the ISR could even write directly to the text buffer without involving flags and so forth. This is one of the nicer services that you get with the Arduino libraries, for instance. We’ll run an article on this very common application soon.

Starvation: Frequent Interrupts

Interrupts are great for handling events fairly speedily, and lightweight ISRs help prevent main loop starvation. But “lightweight” is relative to how frequently the interrupts get called in the first place. No matter how little is going on inside the ISR, there’s always some finite call and return overhead. (Although there are clever, machine-specific ways to minimize this that are out of scope for this article, but that we’d love to cover later.) And the ISR has to do something after all.

If your ISR is going to be called very, very frequently, even a lightweight interrupt can block the main loop. Imagine that it takes a total of 40 cycles just to get into and out of an interrupt, and the interrupt-triggering event ends up happening every 50 cycles. You’re totally blocked if your ISR takes more than ten cycles to run, and your main loop code is reduced to a crawl no matter what. Even the shortest interrupts take some time for call and return.

A sneaky case of too-frequent interrupts can occur with push buttons. On one hand, it’s tempting to handle push button input through interrupts, responding to an infrequent input quite rapidly. But real-world push buttons often “bounce” — making and breaking the circuit many times over a couple of milliseconds as the metal plates inside settle into contact with each other. These glitches can trigger interrupts frequently enough that the ISRs can’t keep up, and thus the main loop gets blocked for a little while.

With a pushbutton, you can be pretty sure that it will only bounce for a few milliseconds, limiting the extent of the main loop starvation, so we view this case as technically flawed, but practically benign. But the same rationale goes for any noisy signal, and if noisy inputs can cause interrupt overload, you’ll need to think about how to deal with that noise. Imagine a loose wire on a model rocket guidance system preventing the main loop from getting its work done. For critical systems, some filtering on the input to keep it from bouncing around is probably a good idea.

Yo Dawg, I Heard You Liked Interrupts…

Compilers like AVR-GCC do The AVR hardware does you the favor of turning off the global interrupt mask bit upon entering an ISR. Why? Because you probably don’t want interrupts getting interrupted by other interrupts. If they’re intended to be short bits of code anyway, it’s more reasonable to finish up this ISR and then tackle the next. But there’s another reason you should be wary of interrupts inside your interrupts.

Each call to an ISR or any other function starts off with the compiler stashing variables and the current location of the program counter (which keeps track of which instruction the CPU is currently executing) in a memory location called the stack. Nesting functions inside functions pushes more and more variables onto the stack, and when the stack fills up to overflowing, bad things happen. Because microcontrollers often have relatively limited RAM, this can be a real problem.

If you’re the type of programmer who insists on writing recursive functions, you can at least estimate how many times your function will call itself and figure out if you’re likely to smash the stack. But since interrupts are triggered by external events, they’re out of your control, and allowing interrupts to interrupt each other leaves you hoping that they don’t end up nesting too deep. This is the rationale behind turning off the global interrupt enable bit by default when handling an ISR.

Of course, you may be running some lower-priority interrupts that you’d absolutely like to get interrupted by further interrupts. Even on AVR-GCC, there’s a provision for doing this, so it’s not like you can’t. Just be judicious when you let interrupts interrupt other interrupts on the smallest micros.

For instance in our accelerometer-with-killer-laser example above, since we only had two ISRs anyway and they had a very clear priority relationship, we could have either re-enabled the global interrupt bit from within the read_accelerometer() function, or defined the entire ISR to be interruptible. On the AVR platform, the “avr/interrupt.h” lets one define an interruptible interrupt like so:

ISR(INT0_vect, ISR_NOBLOCK) { ... }

Now you know. Just use it responsibly.

Next Column: The Ugly.

In the next Embed with Elliot, we’ll tackle The Ugly: race conditions and failures of atomicity. The short version of the story is that interrupts will strike at the worst possible times, and you’ll have to adjust your thinking correspondingly, or else mayhem ensues: if() blocks can behave “incorrectly” and variables can take on entirely “wrong” values.

But for now, to avoid “The Bad” of using interrupts, just remember to keep your ISRs short and don’t be afraid to subdivide tasks that need different priority levels. Sounds easy enough, no?

Filed under: Hackaday Columns, Microcontrollers

Mid-Priced Hardware Gets Serious About Software Defined Radio

ศุกร์, 09/25/2015 - 22:31

Regular Hackaday readers are used to seeing the hacks that use a cheap USB TV dongle as a software defined radio (SDR). There’s plenty of software that will work with them including the excellent GNU Radio software. However, the hardware is pretty bare-bones. Without modifications, the USB dongle won’t get lower frequencies.

There’s been plenty of other SDR radios available but they’ve had a much heftier price tag. But we recently noticed the SDRPlay RSP, and they now have US distribution. The manufacturer says it will receive signals with 12-bits of resolution over the range of 100 kHz to 2 GHz with an 8MHz bandwidth. The USB cable supplies power and a connection to the PC. The best part? An open API that supports Windows, Linux, Mac, Android, and will even work on a Raspberry Pi (and has GNU Radio support, too).

If you are like us, your brain is already spinning thinking of the hacks you can do with a fairly inexpensive (about $150) receiver that has that kind of range. Of course, you could use it as just a receiver, but it could do a lot more. For example, the second video below shows a ham that uses the device as a panadapter (a ham tool that amounts to a spectrum analyzer that visually monitors the entire ham radio band for activity).

The device has eight different front end filters that it selects depending on your chosen frequency. We haven’t had a chance to try one yet (stay tuned for that), but the specs look impressive–especially for the price. When you think that we’ve seen cheap SDRs make test equipment and even passive radar, you can only imagine what the community will dream up using these boxes.

Filed under: radio hacks

Hacking when it Counts: GI Ingenuity

ศุกร์, 09/25/2015 - 21:01

For most of us, hacking is a hobby, a pleasant diversion from reality. Yes, a lot of us work on projects which have the potential to change the world – witness the 2015 Hackaday Prize semifinalist list. But in general, almost any of us could walk away from the shop at any time without dire consequences. Indeed, that’s the reason a lot of our work benches are littered with projects started with the best of intentions but left unfinished for lack of funds, lack of interest, or lack of time. We’re free to more or less willingly shelve a project and come back to it whenever we please, or not at all.

But not everyone has that luxury. For some people, hacking is much more than a hobby – it’s a means of survival. Sometimes people are thrown into situations where they have to cobble together a solution to an immediate problem with whatever is at hand, when the penalty for failure is much higher than a cluttered bench and a bruised ego. I’ve already covered one such case, where biohacked insulin saved hundreds of lives in occupied Shanghai in WWII.

In this occasional series I’ll explore historical cases where hacking really counted; cases where lives were saved or improved by a hack performed under desperate conditions.

A Bustle in the Hedgerow

Unsurprisingly, war offers a lot of opportunities for field expedient solutions under dire circumstances, and battlefield conditions might be the most extreme example of hacking when it counts.

In the early days of the Invasion of Normandy during WWII, Allied forces were having a difficult time dealing with the bocage terrain of northern France. A mixture of pasture and woodland, the Normandy bocage was a natural killing field for Allied tanks because the woodlands took the form of hedgerows – earthen dikes topped with thick tangles of brush. Hedgerows separated pastures and kept livestock controlled, but also made things tough on infantry and mechanized cavalry alike. Climbing the steep hedgerows exposed the vulnerable bottom hull of the tanks to enemy fire, and waiting for engineers to demolish the hedgerows with explosive made them sitting ducks for German artillery. The Allied advance was seriously hampered by the hedgerows, and both men and materiel were being winnowed down from fixed German positions chosen specifically to take advantage of the bocage terrain.

Sgt. Curtis G. Culin (source: Cranford (NJ) Patch)

Enter Sgt. Curtis Grubb Culin III. Sgt. Culin, a tanker himself, was acutely aware of how vulnerable he was in his Sherman M4. The hedgerows were the problem, one apparently known to Allied command prior to the invasion for which no provision had been made. In the tradition of soldiers at the front of every battle throughout history, Sgt. Culin and his fellow tankers had to improvise a solution.

While kicking around ideas, one of the men suggested setting saw teeth on the front of a tank to cut through the hedgerows. He later attributed the comment to “A Tennessee hillbilly named Roberts”, and it was met with general laughter from the group as a crackpot scheme. But Sgt. Culin saw the potential in the idea, and began to develop it into a prototype.

Rhino-equipped tank (source: Wikipedia)

Raw materials for his prototype were not hard to come by. Czech hedgehogs, giant anti-tank barriers made of crossed steel beams, still littered the Normandy beaches. The failed German defenses were harvested with a cutting torch and welded to the underside of a tank to form a series of “tusks” across the hull between the tracks. Equipped with these tusks, the tank could now blast through the tangled roots of the brush-covered earth of the hedgerow dykes.

When demonstrated for General Omar Bradley, he was impressed enough to order them built in quantity for the tanks. Eventually the prototype became an engineered product (dubbed the “Culin Rhino Device”) that was fitted to many tanks before being shipped over from England. Rhino-equipped tanks ripped across Normandy and shredded the German battle plan, which assumed the hedgerows would funnel Allied forces through heavily defended chokepoints.

Without Sgt. Culin’s battlefield hack, and his inspiration by a hillbilly named Roberts whom history otherwise forgets, the invasion of Europe might have taken a very different course. The fact that he did the hack while under fire makes it all the more impressive, and is a perfect example of hacking when it counts.

Know of any more examples of hacking when it counts? Send us a tip for use in a future Hacking When it Counts article.

[Main image of Czech Hedgehog by Jesse CC-BY-SA 3.0]

Filed under: Featured, weapons hacks

Becoming A Zombie with the Hackable Electronic Badge

ศุกร์, 09/25/2015 - 18:01

Last week, Parallax released an open hackable electronic badge that will eventually be used at dozens of conferences. It’s a great idea that allows badge hacks developed during one conference to be used at a later conference.

[Mark] was at the Hackable Electronics Badge premier at the 2015 Open Hardware Summit last weekend, and he just finished up the first interactive hack for this badge. It’s the zombie apocalypse in badge form, pitting humans and zombies against each other at your next con.

The zombie survival game works with the IR transmitter and receiver on the badge normally used to exchange contact information. Upon receiving the badge, the user chooses to be either a zombie or survivor. Pressing the resistive buttons attacks, heals, or infects others over IR. The game is your standard zombie apocalypse affair: zombies infect survivors, survivors attack zombies and heal the infected, and the infected turn into zombies.

Yes, a zombie apocalypse is a simple game for a wearable with IR communications, but for the Hackable Electronics Badge, it’s a great development. There will eventually be tens of thousands of these badges floating around at cons, and having this game available on day-one of a conference will make for a lot of fun.

Filed under: cons, hardware, wearable hacks

Deep Sweep: A Home Made SigInt Platform

ศุกร์, 09/25/2015 - 15:01

Signals Intelligence (SigInt) isn’t something that you normally associate with home hackers, but the Deep Sweep project is looking to change that: it is a balloon platform that captures radio signals in the stratosphere, particularly conversations between drones and satellites. Created by three students at the Frank Ratchye Studio for Creative Inquiry at Carnegie-Mellon, Deep Sweep is a platform that is attached to a balloon and which captures signals over a wide range of frequencies, logging them for later analysis. The current version captures data on three frequency bands: LF/HF (10KHz-30KHz), UHF (650 – 1650MHz) and SHF (10-20GHz). The latter are often the bands used for satellite links between drones and satellites. They are difficult to intercept from the ground, as the signals are directed upwards towards the satellite. By creating a platform that can fly several kilometers above the earth, they are hoping to be able to capture some of this elusive traffic.

So far, the team has made two flights in Europe, both of which encountered technical issues. The first had a battery fault and only captured 10 minutes of data, and the second flew further than expected and ended up in Belarus, a country that isn’t likely to welcome this kind of thing. Fortunately, they were able to recover the balloon and are working on future launches in Europe and the USA. It will be interesting to see how the Department of Homeland Security feels about this.

Filed under: drone hacks, radio hacks

Hackaday Prize Semifinalist: Location Services For Robots

ศุกร์, 09/25/2015 - 12:00

Robots of the future will be in the home, and ready to do whatever job we tell them to do. But they’ll need to know where they are within the house. Dead reckoning with accelerometers and gyroscopes are just a sufficient solution; what we really need is an indoor location service. For his Hackaday Prize entry, [Göran] is doing just that. He’s building a small device that will find its position with 10 cm precision, indoors.

[Göran]’s LPS Mini is built around a very interesting part – the Decawave DWM100. It’s a module that uses an 802.15 radio to trilaterate the distance from several ‘anchors’ to a tag. This, by itself, gives the LPS Mini a navigation system with 10 cm precision. Even higher precision can be accomplished with an IMU gathering accelerometer, gyro, and compass data, and even further with a tiny altimeter. The result is a tiny board that knows exactly where it is.

As far as practical uses go, these LPS Mini boards were used to move beds around an art exhibit at Hayward Gallery in London. While moving beds around an art gallery doesn’t sound like a game-changing invention, think about the uses for GPS in the 1980s – no one could have imagined a chip that would tell you where you are or that could keep a quadcopter on the right heading.

You can check out [Göran]’s video for the LPS Mini below.

The 2015 Hackaday Prize is sponsored by:

Filed under: The Hackaday Prize

Raspberry Pi Weather Station In Progress

ศุกร์, 09/25/2015 - 09:01

[Jeremy Morgan] is building a weather station from scratch using a Raspberry Pi, and he has put together a nice write up that shows where he is at, and how it works. Currently, his setup is in the breadboard stage and is measuring humidity, temperature, pressure and light level using sensors that connect over one wire and I2C. He also shows how he is using Google Docs to store the data, by getting the Pi to write to a Google Spreadsheet over email: the Pi emails the data to Google every 30 seconds.

There is an analysis portion, with a Microsoft Azure web site that graphs the data over time. It’s a bit of a dogs breakfast (he might have used one interface technology for all of the sensors, for instance), but it is still a nice overview of the overall process.

Automatically channeling data into an easily accessible medium has been the target of many hacks going way back. We’ve seen a ton of companies pop up to help satisfy the need but between those and the hacked together (usually) open source solutions, there doesn’t seem to be a clear winner. What’s your favorite method of gathering and displaying data from projects like this onto the web? Let us know in the comments.

Filed under: Raspberry Pi

Arduino Teaches Morse Code

ศุกร์, 09/25/2015 - 06:01

You may wonder why anyone would want to learn Morse code. You don’t need it for a ham license anymore. There are, however, at least three reasons you might want to learn it anyway. First, some people actually enjoy it either for the nostalgia or the challenge of it. Another reason is that Morse code can often get through when other human-readable schemes fail. Morse code can be sent using low power, equipment built from simple materials or even using mirrors or flashlights. Finally, Morse code is a very simple way to do covert communications. If you know Morse code, you could privately talk to a concealed computer on just two I/O lines. We’ll let you imagine the uses for that.

In the old days, you usually learned Morse code from an experienced sender, by listening to the radio, or from an audio tape. The state of the art today employs a computer to randomly generate practice text. [M0TGN] wanted a device to generate practice code, so he built it around an Arduino. The device acts like an old commercial model, the Datong D70, although it can optionally accept an LCD screen, something the D70 didn’t have.

You can see the project in operation in the video below. Once you learn how to read Morse code, you might want to teach your Arduino to understand it, too. Or, you can check out some other Morse-based projects.

Filed under: Arduino Hacks

Cables And Winches Become An Awesome Simulator

ศุกร์, 09/25/2015 - 03:01

Straight from the Max Planck Institute for Biological Cybernetics, and displayed at this year’s Driving Simulation Conference & Exhibition is the coolest looking simulation platform we’ve ever seen. It’s a spherical (or icosahedral) roll cage, attached to the corners of a building by cables. With the right kinematics and some very heavy-duty hardware, this simulation platform has three degrees of translation, three degrees of rotation, and thousands of people that want to drive a virtual car or pilot a virtual plane with this gigantic robot.

The Cable Robot Simulator uses electric winches attached to the corners of a giant room to propel a platform with 1.5g of acceleration. The platform can move back and forth, up and down, and to and fro, simulating what a race car driver would feel going around the track, or what a fighter pilot would feel barreling through the canyons of the Mojave. All you need for a true virtual reality system is an Oculus Rift, which the team has already tested with driving and flight simulation programs

An earlier project by the same research group accomplished a similar feat in 2013, but this full-motion robotic simulator was not made of cable-based robotics. The CyberMotion Simulator used a robotic arm with a cockpit of sorts attached to the end of the arm. Inside the cockpit, stereo projectors displayed a wide-angle view, much like what a VR display does. In terms of capability and ability to simulate different environments, the CyberMotion Simulator may be a little more advanced; the Cable Robot Simulator cannot rotate more than about sixty degrees, while the CyberMotion Simulator can turn you upside down.

The Cable Robot Simulator takes up a very large room, and requires some serious engineering – the cables are huge and the winches are very powerful. These facts don’t preclude this technology being used in the future, though, and hopefully this sort of tech will make its way into a few larger arcades.

We often see concepts come in waves. Earlier this week we featured a cable robot used to move pallets around a warehouse.

Thanks [Arko] for the tip.

Filed under: robots hacks, Virtual Reality

Learn Flip Flops with (More) Simulation

ศุกร์, 09/25/2015 - 00:01

In the previous installment, we talked about why flip flops are such an important part of digital design. We also looked at some latch circuits. This time, I want to look at some actual flip flops–that is circuit elements that hold their state based on some clock signal.

Just like last time, I want to look at sequential building blocks in three different ways: at the abstraction level, at the gate level, and then using Verilog and two online tools that you can also use to simulate the circuits. Remember the SR latch? It takes two inputs, one to set the Q output and the other to reset it. This unassuming building block is at the heart of many other logic circuits.

A common enhancement to the SR latch is to include an enable signal. This precludes the output from changing when the enable signal is not asserted. The implementation is simple. You only need to put an additional gate on each input so that the output of the gate can’t assert unless the other input (the enable) is asserted. The schematic appears on the right.

In the case of this simulation (or the Verilog equivalent), the SR inputs become active high because of the inversion in the input NAND gates. If the enable input is low, nothing will change. If it is high, then asserted inputs on the S or R inputs will cause the latch to set or reset. Don’t set both high at the same time when the enable is high (or, go ahead–it is a simulation, so you can’t burn anything up).(Note: If you can’t see the entire circuit or you see nothing in the circuit simulator, try selecting Edit | Centre Circuit from the main menu.)

The SR latch could be useful, but in many applications it is inconvenient to have to expressly set and reset it. I said last time, these circuits were like a memory bit, so how could you make the latch just remember the state of a single bit? It’s easy. Just drive the S input with a bit and the R input with the inverse of the same bit. The diagram to the right is in falstad or using Verilog.

This is practically a digital version of a sample and hold circuit. When enable is asserted, the output follows the input. When enable is not asserted, the output holds its value.

There are other ways to get the same effect. Because latches and flip flops are so universal, there are a variety of designs. For example, look up Earle latch, which offers a fixed propagation delay compared to the traditional latch design.

The D Flip Flop

The SR latch modified with the inverter is often called a D latch because the single input is data for the latch to store. To make it a D flip flop, though, you need to arrange to capture the data at a clock edge, not just any time the latch is enabled.

One way this is done is called a master slave flip flop (which doesn’t have to be a D flip flop). The idea is to cascade two latches with a single enable line. However, the first flip flop (the master) gets the enable line straight. The slave gets an inverted copy. What this means is when you enable the flip flop, the master’s output will track the input. However, since the slave is disabled (because of the inverted enable line), no output change will occur. When the enable line drops, the master will hold the last state it saw, but now the slave’s enable line will turn on and the output will change. Since the master’s input can’t change, the effect is the entire flip flop stores the state of the input at the time the enable line is deasserted. Here’s a simulation (see image to the right).

It is more common, however, to make flip flops sensitive to the actual clock edge. One simple way to do that would be to use the pulse edge detector I mentioned earlier to feed the enable output of a conventional latch. The simulator also shows a different method using a few latches, one of which is built with a three-input gate.

In Verilog, edge sensitive flip flops are easy to create. The synthesis tool takes care of the details. Here’s an edge sensitive D flip flop:

module dff(input clk, input d, output reg q, output qnot); assign qnot=~q; always @(posedge clk) q<=d; endmodule

That’s it. You might add a reset signal:

module dff_reset(input reset, input clk, input d, output reg q, output qnot); assign qnot=~q; always @(posedge clk) if (reset) q<=1’b0; else q<=d; endmodule

In this case, the reset is synchronous because it only happens when the flip flop is processing a clock edge. One of the EDA Playground examples shows a D flip flop with an asynchronous reset you can experiment with.

The T Flip Flop

A T (or toggle) flip flop changes state on each clock pulse (at least, on each enabled clock pulse). This is simple to accomplish if you have a D flip flop. Just connect the inverted Q output to the D input (see left) and you are done. Notice this has the effect of dividing the clock frequency by two, and that’s one thing you frequently use flip flops for: frequency division.

In Verilog, the T flip flop is very simple (although you could, I suppose, wire up a D flip flop, it isn’t necessary):

module tff(input reset, input clk, output reg q); always @(posedge clk) if (reset) q<=1’b0; else q<=~q; endmodule

There are many other ways to build a T flip flop, including by wiring the J and K inputs of a JK flip flop together (see below).

The JK Flip Flop

The JK flip flop sounds mysterious, but it really isn’t. Think of it as an SR flip flop where the J input is equivalent to the S and the K input is equivalent to the R. The reason it is not an SR flip flop is that it has well-defined behavior if you assert both inputs at once: the output toggles (like a T flip flop).

You can find a simulation of the JK flip flop and experiment with it (see image to the left). Note the simulator has a metastability problem (see below) loading the JK flip flop from a link. If the Q output oscillates, go to the Circuits menu and under Sequential Logic, select Flip Flops, and then JK Flip Flop.

In Verilog, you usually don’t model this directly, although you certainly can. Here’s a Verilog JK flip flop:

module jkff(input clk, input j, input k, output reg q, output qnot); assign qnot=~q; always @(posedge clk) case ({j, k}) 2’b00: q<=q; 2’b01: q<=1’b0; 2’b10: q<=1’b1; 2’b11: q<=~q; endcase endmodule A Little More About FPGAs

Much of the time you don’t directly write flip flops by themselves when coding for an FPGA. First, most FPGA vendors supply optimized flip flop macros that you can use that take advantage of on chip resources. In addition, you’ll usually code at a higher level and the synthesizer will infer the flip flops you want.
For example, you might write a simple state machine:

always@(posedge clk or posedge reset) begin if (reset) begin state = s1; outbit = 1'b1; end else begin case (state) s1: begin if (x1==1'b1) state = s2; else state = s3; outbit = 1'b1; end s2: begin . . . endcase end end

Even though that doesn’t look exactly like one of the examples, the FPGA synthesizer will recognize this and build the corresponding circuit using flip flops. It also recognizes other flip flop-based circuits like counters and shift registers.

That’s not to say you shouldn’t know the flip flop types and know how to code them. Being able to do so will help you understand what the tools are inferring for you. However, if you look through a lot of practical code, you won’t see many exact copies of these flip flop instantiations.

What you will see, though, is clock sensitive always blocks with assignments in them. You’ll also see higher level constructs like counters and state machines that use these building blocks internally.

Flip Flop Timing

In the first part of this series, I talked about how our neat schematics don’t match the real world and while that is sometimes a problem, it is also sometimes a good thing. Flip flops are no exception. Because of real world circuit elements, flip flops have several issues: setup time, hold time, and–more generally–metastability.

You can see a graphical representation of setup and hold time to the left. Inputs to the flip flop must be stable for the setup time before the active clock edge. The inputs also have to stay stable for at least the hold time after the clock edge. Graphically, then, the signal can’t change between the outer red lines. The green signal is legal, but the other two violate the rules. In practice, this limits how fast the clock can be. Suppose your click has an active edge every 10ns. If your combinatorial logic feeding the flip flop has a 9ns delay, that should be ok, right? Not if the minimum setup time is more than 1nS. Setup and hold violations are sometimes difficult to troubleshoot, although modern scopes sometimes have special trigger modes to find violations.

If you violate the setup or hold times, the flip flop may go metastable. What this means is the flip flop may behave badly. In some cases it will oscillate or it may take longer to change states than normal. There are several cases where you have to worry about metastability. One is when you are changing clock domains (that is, feeding a flip flop from another flip flop that uses a different clock). Another problem is when you have data coming from a purely asynchronous domain such as a user input switch or an RS232 port. In that case, there’s no way to be sure the input won’t change within the setup or hold time (or even right on the clock edge).

When you have an asynchronous input you’ll usually cascade it through multiple D flip flops. Each additional flip flop you use reduces the chance of metastability (at the output). However, it also delays the input by a clock cycle for each flip flop.

Metastability is a big topic and probably deserves a whole post in its own right. If you can’t wait for that, there’s a good IEEE paper on the subject or have a look at the video below.

There are metastability resistant flip flop designs that have a reduced chance of going into the metastable state. These aren’t perfect, though, because you can’t make both the setup and hold times zero. In the end, there’s no substitute for good design.

Wrap Up

Flip flops are a powerful tool for a digital designer’s arsenal. Implementing them can range from a 555 chip (no kidding, you can make a slow flip flop with a 555) to using discrete components, to using ICs to writing Verilog or VHDL. Learning about flip flops is a lot like learning about chess. You can learn the moves in a few minutes. You can spend a lifetime trying to master them. I hope these two posts have taught you the moves. The rest is up to you.

Filed under: FPGA, Hackaday Columns, misc hacks

This Project Will Be Stolen

พฤ, 09/24/2015 - 22:31

What do you get when you take a flight case from Harbor Freight, fill it up with random electronics junk, and send it off to a stranger on the Internet? The travelling hacker box. It’s a project I’m putting together on hackaday.io to emulate a swap meet through the mail.

The idea is simple – take a box of random electronics junk, and send it off to a random person on hackaday.io. This person will take a few items out of the box, replace those items with something sitting on their workbench, and send it off to the next person. This is repeated until the box is stolen.

Has something like this been done before? Yes, yes it has. The Great Internet Migratory Box of Electronics Junk was a thing back in the ‘aughts, with Hackaday (via Eliot) receiving a box (code name: Rangoon) from [John Park], before sending it off to [Bre Pettis]. The box subsequently disappeared. There were many migratory boxes of electronics junk, but most didn’t travel very far. Already the Travelling Hacker Box has 2,525 miles on its odometer, and plans are in the works for travelling 25,000 miles – the circumference of the Earth – before heading out of the United States.

If you’re wondering what’s in the box, here’s a mostly complete inventory. With the exception of a few items from the swag bag from the Open Hardware Summit last weekend, it’s mostly random electronics stuff I’ve had sitting around on my workbench and desk. The first recipient grabbed a few dev boards and replaced them with a Teensy LC and enough tubes to make a small amplifier.

The current plan for the Travelling Hacker Box is to bounce across the United States for the circumference of the Earth until departing for more exotic lands. There are people queued up to receive the box from across the world, and the box will eventually be hitting Europe, India, Africa, Asia, and Australia. Everyone is welcome to participate as it is passed from hacker to hacker as a migratory box of electronic toys.

Filed under: misc hacks

Hackaday Dictionary: The ESP8266

พฤ, 09/24/2015 - 21:01

In August of 2014, something new started showing up in the markets of Shenzen, the hi-tech area of China where the majority of the world’s electronics components are made. This is the ESP8266, a WiFi SoC (System on a Chip) that can connect to 802.11b/g/n networks on the 2.4GHz band. It can be addressed with SPI or a serial connection, and has an AT command set that makes it behave rather like an old-style modem. Basically, it has everything you would need to connect a device to a WiFi network, with the ESP8266 chip itself handling the complicated business of finding, joining and transmitting/receiving over a WiFi network.

That’s nothing particularly new in itself: WiFi connection devices like the TI CC3000 have been around for longer, and do much the same thing. The difference was the price. While the TI solution costs about $10 if you buy several thousand of them, the ESP8266 costs less than $7 for an individual board that can plug straight into an Arduino or similar. Buy the chip in bulk, and you can get it for less than $2.

The ESP8266 is more than just a WiFi dongle, though: it is a fully fledged computer in itself, with a megabyte of flash memory and a 32-bit processor that uses a RISC architecture. This can run applications, turning the ESP8266 into a standalone module that can collect and send data over the Internet. And it can do this while drawing a reasonably low amount of power: while receiving data, it typically uses just 60mA, and sending data over an 802.11n connection uses just 145mA. That means you can drive it from a small battery or other small power source, and it will keep running for a long time.

It wasn’t an easy ship to write applications for in the early days, though: it was poorly documented and required a dedicated toolchain to work with. This made it more of a challenge than many hackers were comfortable with.  That changed earlier this year, though, when the Arduino IDE (Integrated Development Environment) was ported to the chip. This meant that you could use the much easier to write Arduino functions and libraries to write code for the chip, bringing it within reach of even the most casual hacker.

A decapped ESP8266, with area of interest marked by Reddit user swimmerdude. The big area on the right is memory

Why Is the ESP8266 Important?

The ESP8266 almost achieves the holy trifecta of electronics: cheap, powerful and easy to work with. Before this, if you wanted to add a wireless connection to a project, you had to use more power-hungry devices like USB WiFi dongles, or squish everything into a serial connection and use a wireless serial link. Either way added to the complexity of the project: you either needed a system that supported USB and had WiFI OS support, or you had to put up with the limitations of wireless serial links, which typically offer very limited bandwidth. The advent of WiFi SoCs removed these limitations because the SoC did the heavy lifting, and WiFi offered much more bandwidth. And the ESP8266 did this all at a very low cost: do some digging on eBay and you can get an ESP8266 board for less than $2. So, it is no surprise that we are starting to see the ESP8266 showing up in commercial products.

How Can I Use the ESP8266?

With the popularity of the ESP8266 for adding WiFi to projects, it is no surprise that there are a lot of options for trying it out. On the hardware side, ESP8266 development boards are available from a number of places, including Seeedstudio, Sparkfun and Olimex. Adafruit also has a nice ESP8266 board that breaks out all of the signals for easy breadboard use, and adds a 3.3V output, so it can drive an external device. It is also FCC approved, which is important if you are looking to sell or use the devices you build commercially. Some users have also been building their own development boards, which add features such as LCD displays and buttons.

The Adafruit Huzzah ESP8266 dev board

On the software side, the easiest way to get into the ESP8266 is to use the Arduino compatible mode. This involves loading custom firmware that turns the chip into a mid-range Arduino board, which makes for much easier programming. The people behind this project have produced a list of supported ESP8266 boards: buying one of these will make the installation process easier, as they have noted which data lines in the Arduino SDK correspond to the physical pins on the board. These boards also provide easy access to the reset lines that you have to use to install the Arduino compatible firmware.

This does include some limitations, though: it is rather complicated to upload new sketches over WiFi, and you can’t produce multiple PWM signals, which would make controlling multiple devices difficult. To get access to the full capabilities of the ESP8266, you’ll need to go to the source, and use the SDK that the manufacturers offer. [cnlohr] published an in-depth guide here on Hackaday for bare-metal programming the ESP8266 whih was mentioned earlier. Espressif also offer a pretty good getting started guide that covers creating a virtual Linux machine and connecting this to their chips.

The third option is to flash NodeMCU to the ESP8266 module. This turns it into a Lua interpreter. Scripting can be done in real-time to prototype your program, then flashed to the EEPROM to make your program persistent and remove the need for a serial connection.

Beginners will be comfortable with both the Arduino and NodeMCU approaches, but experienced users should be able to wade straight in and start writing code for this cheap, powerful and fairly easy to use chip.

Filed under: Arduino Hacks, Hackaday Columns, slider, wireless hacks

The Perfect Pen Knife Handle

พฤ, 09/24/2015 - 18:01

If you’ve ever tried to use a pen knife for anything other than cutting open a box or slicing material in one direction, you’ll know they really aren’t that ergonomic. When [Seamusriley] started Architecture school a few years ago he started on a journey — an epic journey to make the perfect pen knife handle.

He started by analyzing existing handles — the biggest problem with them is the skinny pen shape causes hyper-extension of the first joint in your index finger, so once he identified that as the root cause he started crafting a more ergonomic version. He started out with foam, then up to wood carved by hand, then 3D printing, and back to wood — but this time, with a CNC machine. Literally dozens of prototypes later, he’s come up with a very nice pen knife handle, so much so, he was asked to present it around Boston at design events!

This is a great example of the hacker mindset — identifying a problem, trying out a solution, trying out another solution, trying out a solution… and then finally getting to a finished product. It’s the tenacity that keeps us going which rewards us in the long run.

[via r/somethingimade]

Filed under: 3d Printer hacks, tool hacks

Buttons, Sliders, and Touchpads All 3D Printed with PrintPut

พฤ, 09/24/2015 - 15:01

[Jesse Burstyn] and some colleagues at Queen’s University and Carleton University (both in Canada) are delivering a paper at the INTERACT 2015 about PrintPut, their system for printing sensors directly into 3D printed objects. Using a printer with dual extrusion and conductive ABS filament, they have successfully formed capacitive touch sensors, digital resistive sensors, and analog resistive sensors.

In practice, this means they can print buttons, sliders, and even touch pads directly into objects. They also have a design for several pressure sensors and a flex sensor. The system includes scripts for the Rhinoceros 3D CAD package. Designers can create a model in any CAD package they want (including Rhinoceros) and then use these scripts to define the interactive areas.

Sure, you could stuff traditional sensors into the object, but it is difficult to, for example, match contours in the object. It also means increased manual finishing time after the object prints. We’ve covered a similar process using carbomorph. Of course, you could always just print with copper wire, instead. You can see some actual prints made with the PrintPut process in the video below.

Filed under: 3d Printer hacks, news

Hackaday Prize Semifinalist: An Affordable Robotic Arm

พฤ, 09/24/2015 - 12:00

Industrial robot arms are curious devices, found everywhere from the back of old engineering classrooms where they taught kinematics in the 90s, to the factory floor where they do the same thing over and over again while contemplating their existence. For his Hackaday Prize entry, [Dan] is building a big robot arm. It’s not big enough to ride on, but it is large enough to automate a few processes in a reasonably well-equipped lab.

This is not a tiny robotic arm powered by 9 gram hobby servos. For the bicep and tricep of [Dan]’s arm, he’s using linear actuators – they’re high precision and powerful. A few months ago, [Dan] tried to design a hypocycloid gear but couldn’t get a $3000 prototype to work. Although the hypocycloid is out, he did manage to build a strange differential pan/roll mechanism for the wrist of the arm. It really is a thing of beauty, and with the engineering [Dan] has put into it, it’s a very useful tool.

If you’d like to meet [Dan]’s robot arm in person, he’ll be at the 2015 NYC Maker Faire this weekend. Check out [Dan]’s Hackaday Prize video for his robot arm below.

The 2015 Hackaday Prize is sponsored by:

Filed under: The Hackaday Prize