Hackaday Prize Entry: Let Your Muscles Do The Work

July 23, 2016 by Brian Benchoff 6 Comments

Electromyography is a technique used to study and record the electrical signals generated when a muscle contracts. It’s used for medical diagnosis, rehab, kinesiological studies, and is the preferred method of control for robotic prosthetics and exoskeletons. There are a few companies out there with myoelectric products, and the use case for those products is flipping the slides on a PowerPoint presentation. Lucky for us, this project in the Hackaday Prize isn’t encumbered by such trivialities. It’s an open, expandable platform to turn muscle contractions into anything.

As you would expect, reading the electrical signals from muscles requires a little more technical expertise than plugging a cable into an Arduino. This project has opamps in spades, and is more than sensitive enough to serve as a useful sensor platform. Already this project is being used to monitor bruxism – inadvertent clenching or grinding of the jaw – and the results are great.

While it’s doubtful this device will ever be used in a medical context, it is a great little board to add muscle control to a robot arm, or build a very cool suit of power armor. All in all, a very cool entry for The Hackaday Prize.

Encrypted USB Bootloader For AVRs

July 23, 2016 by Elliot Williams 13 Comments

It probably doesn’t matter much for the hacker who sleeps with a bag of various microcontroller flash programmers under the pillow, but for an end-user to apply a firmware upgrade, convenience is king. These days that means using USB, and there are a few good AVR USB bootloaders out there.

But [Dmitry Grinberg] wanted more: the ability to encrypt the ROM images and verify that they haven’t been tampered with or otherwise messed up in transit. Combined with the USB requirement, that meant writing his own bootloader and PC-side tools. His bootloader will take unencrypted uploads if it doesn’t have a password, but if it’s compiled with a key, it will only accept (correctly) encrypted hex files.

Since the bootloader, including the USB firmware, is on the hefty side at 3.3 kB, [Dmitry] included hooks to re-use the bootloader’s USB code from within the target application. So if you were going to use V-USB in your program anyway, it doesn’t actually take up that much extra space. It’s a cute trick, but it ties the bootloader and user program together in a way that gives us the willies, without specifically knowing why. Perhaps we can debate this in the comments.

If you need an AVR USB bootloader, but you don’t need the encryption, we like Micronucleus. But if you need to deliver updates to users without them being able to modify (or screw up) the code in the middle, give [Dmitry]’s setup a try.

Retrotechtacular: The Modern Telephone

July 23, 2016 by Jenny List 22 Comments

We take recorded telephone messages for granted in these days of smartphones and VOIP. Our voicemail lives on an anonymous server in a data centre in the cloud somewhere, in a flash memory chip on our DECT base station, or if we’re of a retro persuasion, on a micro-cassette. Wherever we go, we now know our calls will not go unanswered.

Today’s subject takes us back to a time when automatically recording a phone call was the last word in high technology, with a British Pathé newsreel piece from 1959 entitled “Modern Telephone”. Its subject is the Ansafone J10, one of the first telephone answering machines available on the British market. After featuring a fantastic home-made Meccano answering machine with turntable recording created by a doctor, it takes us to the Ansafone factory where the twin tape mechanisms of the commercial model are assembled and tested. Finally we get to see it in use on the desk of a bona fide Captain of Industry, probably about the only sort of person who could afford an Ansafone in 1959.

Part of the film’s charm comes not from the technology but from the glimpse it gives us of 1950s Britain sanitised for the newsreel. The clipped tones, leather armchairs and bookshelves, the coal fire and the engineer in a three-piece suit. The past is a foreign country; they do things differently there.

Take a look at the film below after the break, and never take your recorded calls for granted again.

Continue reading “Retrotechtacular: The Modern Telephone” →

BitCluster Brings A New Way To Snoop Through BitCoin Transactions

July 23, 2016 by Mike Szczys 8 Comments

Mining the wealth of information in the BitCoin blockchain is nothing new, but BitCluster goes a long way to make sense of the information you’ll find there. The tool was released by Mathieu Lavoie and David Decary-Hetu, PH.D. on Friday following their talk at HOPE XI.

I greatly enjoyed sitting in on the talk which began with some BitCoin basics. The cryptocurrency uses user generated “wallets” which are essentially addresses that identify transactions. Each is established using key pairs and there are roughly 146 million of these wallets in existence now

If you’re a thrifty person you might think you can get one wallet and use it for years. That might be true of the sweaty alligator-skin nightmare you’ve had in your back pocket for a decade now. It’s not true when it comes to digital bits — they’re cheap (some would say free). People who don’t generate a new wallet for every transaction weaken their BitCoin anonymity and this weakness is the core of BitCluster’s approach.

Every time you transfer BitCoin (BTC) you send the network the address of the transaction when you acquired the BTCs and sign it with your key to validate the data. If you reuse the same wallet address on subsequent transactions — maybe because you didn’t spend all of the wallet’s coins in one transaction or you overpaid and have the change routed back to your wallet. The uniqueness of that signed address can be tracked across those multiple transactions. This alone won’t dox you, but does allow a clever piece of software to build a database of nodes by associating transactions together.

Mathieu’s description of first attempts at mapping the blockchain were amusing. The demonstration showed a Python script called from the command line which started off analyzing a little more than a block a second but by the fourth or fifth blocks hit the process had slowed to a standstill that would never progress. This reminds me of some of the puzzles from Project Euler.

After a rabbit hole of optimizations the problem has been solved. All you need to recreate the work is a pair of machines (one for Python one for mondoDB) with the fastest processors you can afford, a 500 GB SSD, 32 GB of RAM (but would be 64 better), Python 64-bit, and at least a week of time. The good news is that you don’t have to recreate this. The 200GB database is available for download through a torrent and the code to navigate it is up on GitHub. Like I said, this type of blockchain sleuthing isn’t new but a powerful open source tool like this is.

Both Ransomware and illicit markets can be observed using this technique. Successful, yet not-so-cautious ransomers sometimes use the same BitCoin address for all payments. For example, research into a 2014 data sample turned up a ransomware instance that pulled in $611k (averaging $10k per day but actually pulling in most of the money during one three-week period). If you’re paying attention you know using the same wallet address is a bad move and this ransomware was eventually shut down.

Illicit markets like Silk Road are another application for BitCluster. Prior research methods relied on mining comments left by customers to estimate revenue. Imagine if you had to guess at how well Amazon was doing reading customer reviews and hoping they mentioned the price? The ability to observe BTC payment nodes is a much more powerful method.

A good illicit market won’t use just one wallet address. But to protect customers they use escrow address and these do get reused making cluster analysis possible. Silk Road was doing about $800k per month in revenue at its height. The bulk of purchases were for less than $500 with only a tiny percentage above $1000. But those large purchases were likely to be drug purchases of a kilo or more. That small sliver of total transactions actually added up to about a third of the total revenue.

It’s fascinating to peer into transactions in this manner. And the good news is that there’s plenty of interesting stuff just waiting to be discovered. After all, the blockchain is a historical record so the data isn’t going anywhere. BitCluster is intriguing and worth playing with. Currently you can search for a BTC address and see total BTC in and out, then sift through income and expense sorted by date, amount, etc. But the tool can be truly great with more development. On the top of the wishlist are automated database updates, labeling of nodes (so you can search “Silk Road” instead of a numerical address), visual graphs of flows, and a hosted version of the query tool (but computing power becomes prohibitive.)

Hacklet 117 – NFC Projects

July 23, 2016 by Adam Fabio 5 Comments

Near Field Communication (NFC) is something we take for granted these days. Nearly all smartphones have it. We even have NFC interfaces for all our favorite development boards. NFC’s history goes back all the way to 1997, when an early version was used in Star Wars special edition toys. Radio Frequency Identification (RFID), which NFC builds on, goes back even further. The patent citation trail leads all the way back to 1983 in a patent awarded to [Charles Walton]. NFC is much more than RFID though. The idea of two way communication between devices opens up tons of possibilities for projects and hacks. This week on the Hacklet we’re checking out some of the best NFC projects on Hackaday.io!

We start with [Patrick] and Ctrl-O. Somewhere in the hackerspace bible there is a clause that states “Thou shalt build an electronic access control system”. In [Patrick’s] case, a door lock became a complex membership subscription management database. Members who have paid can use an NFC tag to gain access to the hackerspace. The system consists of a Raspberry Pi with an NFC interface. A relay allows the Pi to control the door lock. The Pi can be manually configured through a web interface. It connects to Paypal to verify that each user’s membership has actually been paid. Of course a project like this is never done. The last we heard from [Patrick], he was planning future upgrades such as startup company memberships with multiple people.

Next up is [Pierre Charlier] and KeyDuino. KeyDuino is an Arduino compatible board with all the NFC hardware baked right in. The board is based upon the Arduino Leonardo, with an ATmega32u4 processor. [Pierre] must be on to something, because the KeyDuino had a successful Kickstarter back in 2015. It’s also open source hardware, so you can build your own whenever you want. The real gem is checking out [Pierre’s] other projects. He’s documented all his KeyDuino example projects right on Hackaday.io. These include an NFC Controlled infinity mirror coffee table, a locking wooden gift box, and NFC controlled car door locks, just to name a few.

Next we have [John McLear] with 2016 NFC Ring. [John] jumped into wearable technology with one of the toughest form factors imaginable – a ring. Between the tiny amount of space and the lack of batteries, you might think there isn’t much you can do with a ring. Undaunted, [John] managed to fit two NXP NFC chips and their antennas inside a standard ring. This is the upgraded 2016 version of the ring. [John] was nice enough to supply several hundred of the earlier models to hackers at the Hackaday Supercon back in 2015. [John’s] rings would be hard for the average hacker to reproduce. [Sean Hodgins] comes to the rescue here with his own project, DIY NFC Bentwood Ring.

Finally, we have [CaptMcAllister] with RFID air pressure sensor. As the name implies, this sensor measures air pressure. It could be in open air, a tire, or even a football used by the New England Patriots. Sure, cars all have Tire Pressure Monitoring Systems (TPMS) sensors which do something similar. [CaptMcAllister’s] design has one important difference – it has no batteries. The heart of the system is a Texas Instruments RF430FRL15X, a device with the NFC radio and a low power MSP430 microcontroller in one chip. The system is energy harvesting, being powered by an external reader. As you can imagine, tuning the antenna was critical to this design. You can read all about it in [CaptMcAllister’s] 24 project logs.

If you want to see more NFC projects and hacks, check out our new near field communication projects list. See a project I might have missed? 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!

Semisolid Lithium Ion Batteries Promise Better Cars, Solar

July 23, 2016 by Al Williams 28 Comments

Lithium-ion batteries make possible smaller and lighter electronics. Unfortunately, they are also costly to produce. In a conventional lithium-ion battery, many thin layers create the finished product much like filo dough in baklava. A startup company called 24M thinks they have the answer to making less expensive lithium-ion batteries: a semisolid electrode made by mixing powders and liquid to form an electrolyte goo.

Not only will the batteries be cheaper and faster to create, but the cost of the factory will be less. Currently, 24M has a pilot manufacturing line, but by 2020 they expect to scale to produce batteries that cost less than $100 per kilowatt hour (today’s costs are about $200 to $250 for conventional batteries). Under $100, the batteries become competitive with the cost of internal combustion engines, according to the article.

Continue reading “Semisolid Lithium Ion Batteries Promise Better Cars, Solar” →

Manipulators Get A 1000x FPGA-based Speed Bump

July 23, 2016 by Sonya Vasquez 35 Comments

For humans, moving our arms and hands onto an object to pick it up is pretty easy; but for manipulators, it’s a different story. Once we’ve found the object we want our robot to pick up, we still need to plan a path from our robot hand to the object all the while lugging the remaining limbs along for the ride without snagging them on any incoming obstacles. The space of all possible joint configurations is called the “joint configuration space.” Planning a collision-free path through them is called path planning, and it’s a tricky one to solve quickly in the world of robotics.

These days, roboticists have nailed out a few algorithms, but executing them takes 100s of milliseconds to compute. The result? Robots spend most of their time “thinking” about moving, rather than executing the actual move.

Robots have been lurching along pretty slowly for a while until recently when researchers at Duke University [PDF] pushed much of the computation to hardware on an FPGA. The result? Path planning in hardware with a 6-degree-of-freedom arm takes under a millisecond to compute!

It’s worth asking: why is this problem so hard? How did hardware make it faster? There’s a few layers here, but it’s worth investigating the big ones. Planning a path from point A to point B usually happens probabilistically (randomly iterating to the finishing point), and if there exists a path, the algorithm will find it. The issue, however, arises when we need to lug our remaining limbs through the space to reach that object. This feature is called the swept volume, and it’s the entire shape that our ‘bot limbs envelope while getting from A to B. This is not just a collision-free path for the hand, but for the entire set of joints.

swept_volume — Image Credit: Robot Motion Planning on a Chip

Encoding a map on a computer is done by discretizing the space into a sufficient resolution of 3D voxels. If a voxel is occupied by an obstacle, it gets one state. If it’s not occupied, it gets another. To compute whether or not a path is OK, a set of voxels that represent the swept volume needs to be compared against the voxels that represent the environment. Here’s where the FPGA kicks in with the speed bump. With the hardware implementation, voxel occupation is encoded in bits, and the entire volume calculation is done in parallel. Nifty to have custom hardware for this, right?

We applaud the folks at Duke University for getting this up-and-running, and we can’t wait to see custom “robot path-planning chips” hit the market some day. For now, though, if you’d like to sink your teeth into seeing how FPGAs can parallelize conventional algorithms, check out our linear-time sorting feature from a few months back.

Continue reading “Manipulators Get A 1000x FPGA-based Speed Bump” →