The Internet overflows with prosthetics projects, and to a large extent this is somewhat understandable. Prosthetic devices are ultimately a custom made for each user, and 3D printers are trying to find a purpose. Put two and two together, and you’re going to get a few plastic limbs.
The electronics required for advanced prosthetics are a bit harder than a 3D scanner and a printer. If you’re designing a robotic leg, you will need to pump several hundred watts through an actuator to move a human forward. For the last few years, [Jean-François Duval] has been working on this problem at the MIT Media Lab Biomechatronics group and has come up with his entry for the Hackaday Prize. It’s a motor and motor control system for wearable robotics that addresses the problems no other project has thought of yet.
The goal of the FlexSEA isn’t to build prosthetics and wearable robotics – the goal is to build the electronics that drive these wearables. This means doing everything from driving motors, regulating power consumption, running control loops, and communicating with sensors. To accomplish this, [Jean-François] is using the BeagleBone Black, a Cypress PSoC, and an STM32F4, all very capable bits of hardware.
So far, [Jean-François] has documented the hardware and the software for the current controller, and has a few demo videos of his hardware in action. You can check that out below.
When he bought the table, he found that the electronics had been fried: many of the discrete components on the board had been burnt out. So, rather than replace the individual parts, he gutted the table and replaced the logic board with an Arduino Mega that drives the flippers, display and chimes that make pinball the delightful experience it is. Fortunately, this home pinball table is well documented, so he was able to figure out how to rewire the remaining parts fairly easily, and how to recreate the scoring system in software.
His total cost for the refurb was about $300 and the junker was just $50 to start with. Now for $350 you can probably find a working pinball table. But that’s not really the point here: he did it for the experience of working with electromechanical components like flippers and tilt switches. We would expect nothing less from the dude who previously built an Android oscilloscope from spare parts.
We were in Boston last week and Artistan’s Asylum welcomed us in to host a Hackaday Meetup. We usually pack the place when the Hackaday community turns out, but this was exceptional. This hackerspace has a sizeable open area that I’m told fits triple-digits and we were using all of it. In addition to food and beverage (courtesy of our parent company Supplyframe who also make trips like this one a possibility), we had lighting talks for people to show off their projects. One of the hits was a functional hoverboard shown above, but there were dozens of others.
Here is the quick gallery of images (from our Hackaday.io event page) to give you an overview. After the break you’ll find dozens more highlighting the builds which were being shown off.
Working Hoverboard
We brought the Hackaday Omnibus with us
Gentleman in white makes clothes with hundred+ yo machines
Spaceships made of duct tape
[Jimmy Rogers] and [Sophi Kravitz] having a good time
How do you fix a shorted cable ? Not just any cable. An underground, 3-phase, 230kV, 800 amp per phase, 10 mile long one, carrying power from a power station to a distribution centre. It costs $13,000 per hour in downtime, counting 1989 money, and takes 8 months to fix. That’s almost $75 million. The Los Angeles Department of Water and Power did this fix about 26 years ago on the cable going from the Scattergood Steam Plant in El Segundo to a distribution center near Bundy and S.M. Blvd. [Jamie Zawinski] posted details on his blog in 2002. [Jamie] a.k.a [jwz] may be familiar to many as one of the founders of Netscape and Mozilla.
To begin with, you need Liquid Nitrogen. Lots of it. As in truckloads. The cable is 16 inch diameter co-axial, filled with 100,000 gallons of oil dielectric pressurised to 200 psi. You can’t drain out all the oil for lots of very good reasons – time and cost being on top of the list. That’s where the LN2 comes in. They dig holes on both sides (20-30 feet each way) of the fault, wrap the pipe with giant blankets filled with all kind of tubes and wires, feed LN2 through the tubes, and *freeze* the oil. With the frozen oil acting as a plug, the faulty section is cut open, drained, the bad stuff removed, replaced, welded back together, topped off, and the plugs are thawed. To make sure the frozen plugs don’t blow out, the oil pressure is reduced to 80 psi during the repair process. They can’t lower it any further, again due to several compelling reasons. The cable was laid in 1972 and was designed to have a MTBF of 60 years.
There comes a time when you need to wire up three, four, or more identical i2c devices to a common microcontroller. Maybe you’re thinking about driving 128 seven-segment displays with eight of those MAX6955 16-way digit drivers, or maybe you have a robot full of joints–each of which needs a BNO055 inertial sensor for angle estimation. (See above.) Crikey! In both of those cases, you’re best bet might be a schnazzy I²C device that can do most of the work for you. The problem? With a single I²C bus, there’s no standard way defined in the protocol for connecting two or more devices with the same address. Shoot! It would’ve been handy to wire up three BNO055 IMUs or eight MAX6955s and call it a day. Luckily, there’s a workaround.
We’ve seen some clever tricks in the past for solving this problem. [Marv G‘s] method involves toggling between a device’s default and alternate address with an external pin. This method, while clever, assumes that the device (a) has an alternate I²C address and (b) features an external pin for toggling that address.
I’ll introduce two additional methods for getting the conversation started between your micro’ and your suite of identical sensors. The first is “a neat trick,” but somewhat impractical for widespread use. The second is far more production-worthy–something you could gloat over and show off to your boss! Without further ado, let’s get started with Method 1.
Lastly, if you’d like to follow along, feel free to check out the source code on Github.
In both methods, I’m using the same sensor setup to check that each circuit behaves correctly. I happened to have a bunch of extra BMA180s on the bench, so I rolled out an example based on these chips. Back in the day, the BMA180 was a pretty common three-axis digital accelerometer. It has an I²C interface with two optional addresses. For the purpose of this example, I’m fixing them all with the same address. I’ve mounted three of these guys on mutually perpendicular axes of my acrylic “test cube,” and I’m reading each chip’s Z-axis. In this configuration I can easily pick out the gravity vector from the corresponding sensor as the data goes flying by my serial port window. If I can uniquely address each sensor and read the data, I’ve got a working circuit.
Method 1: Splicing Clocks into Chip-Selects
This method tips its hat towards SPI in that it behaves in an oddly similar fashion. If you’re feeling rusty on SPI, here’s a quick recap.
A Quick SPI Refreshment:
SPI, like I²C, is another protocol that shares both its clock and data lines with multiple slave devices. The difference, though, lies in the addressing scheme to talk to these devices that share the same bus. With SPI, while clock and data lines are shared, devices are addressed with separate chip-select (CS) lines.
The master microcontroller dedicates a unique output pin to each device (~SS1, ~SS2, and ~SS3 in this illustration). When the master micro’ wants to talk to a device, it asserts that device’s chip-select input pin by pulling it to logic LOW, and the conversation begins over the data bus. With the chip select LOW, the corresponding slave listens to the data on the bus. Meanwhile, all other devices ignore the conversation between the master and it’s chosen slave by keeping their bus pins in a high impedance state.
Giving I²C Its Own Chip-Selects:
With I²C, Clock (SCL) and Data (SDA) lines are still shared between all I2C slave devices, but the addressing scheme happens by sending a message heard by all devices on the bus. To single out one device on the shared bus, the master first passes down the address of the slave device it wants to talk to, after which that slave replies with an ACKnowledge, and all other slaves ignore the data that follows until both data transmission is complete and the bus is “released.”
Because we have the problem of multiple devices with shared addresses, in theory, all of these devices would reply when the master passes down their shared address, and there’s no way for the master to single out a single device. In reality, this behavior is undefined on the I²C protocol.
Yikes! Anything goes when we wander away from defined behavior, so we try to avoid these things in practice.
The solution?
According to the I²C spec, It just so happens that an I²C slave device will ignore changes on the data line (SDA) provided that the clock line (SCL) is held high. In this method, I’ll “split” the SCL line into multiple SCL lines such that each shared I²C device gets its own SCL. By selectively rerouting the clock to each I²C device one-at-a-time, I’ve essentially turned the SCL line into a “chip select.”
To chop up that clock line, I’ll need a demultiplexer. A demultiplexer (or decoder) takes a logical input and reroutes it to one of several outputs based on the binary select lines.
I’ve dropped in the 74AC11138 eight-way demultiplexer for this task. It’s fast, capable of switching at megahertz rates, and its outputs default to logic HIGH. That second note is handy since idle SCL lines also default to logic HIGH.
The setup is shown in a simplified schematic above. In it, I’m using a Teensy 3.0 posing as the I²C bus master. To the right of the Teensy is the collection of identical chips, BMA180 accelerometers in this case. In the middle is the 74AC11138 eight-way demultiplexer.
Cons of this Method:
There’s a minor drawback with this technique, though, in that it doesn’t support I²C’s clock-stretching feature. Taking a step back, this method assumes that the SCL line is inherently unidirectional, controlled by only the I²C bus master. In other words, we’re making the assumption that data on the SCL line is only sent from master to slave and never the other way around. If your I²C slave devices implement clock-stretching, however, this assumption breaks down.
What is Clock Stretching?
Clock stretching is a method defined by the I²C protocol where the chip needs to “buy itself more time” and holds the SCL line low, hence, signalling to the master that it’s not ready for the upcoming data. In this scenario, the slave actively controls the SCL line, and it happens to be the only case where data moves up the SCL line from slave to master. In a setup with our demultiplexer between the master and our set of identical slaves, these slaves won’t be able to send back the clock-stretching signal to the master to indicate that they aren’t ready for data, if they happen to implement clock stretching. That said, clock stretching is a pretty rare feature among I²C-compatible devices, so this method is likely to work among a number of chips out now.
More Next Week
That’s all for Method 1. Thanks for tuning in, and check back next week for a slightly-more-professional method of tackling this same problem.
When it comes to manufacturing, no place in the world has the same kind of allure as the Pearl River Delta region of China. Within just an hour-long train ride, two vastly different cultures co-exist, each with its unique appeal that keeps attracting engineers, entrepreneurs, and hustlers alike. On the mainland side, cities like Shenzhen and Guangzhou bring the promise of cheap components, low-cost contract work, and the street cred of “having done the Shenzhen thing.” And on the island, the capitalist utopia called Hong Kong glows with all of its high finance and stories of lavish expat lifestyles.
As the “new” China evolves, it seems like it’s exactly the convergence of these two cultures that will bring the biggest change—and not just to the area but to the whole world. Still, understanding what exactly is going on and what the place is really all about remains a mystery to many. So, this June, we jumped on the bandwagon and headed east, trying to get our own feel for the whole thing.
[Rulof Maker] has a penchant for making nifty projects out of old electronics. The one that has caught our eye is a microphone made from parts of an old hard drive. The drive’s arm and magnet were set aside while the aluminum base was diagonally cut into two pieces. One piece was later used to reassemble the hard drive’s magnet and arm onto a wooden platform.
The drive’s arm and voice coil actuator are the key parts of this project. It was modified with a metal extension so that a paper cone cut from an audio speaker could be attached, an idea used in microphone projects we’ve previously featured. Copper wire scavenged from the speaker was then soldered to voice coil on the arm as well as an audio jack. In the first version of the Hard Drive Microphone, the arm is held upright with a pair of springs and vibrates when the cone catches sound.
While the microphone worked, [Rulof] saw room for improvement. In the second version, he replaced the mechanical springs with magnets to keep the arm aloft. One pair was glued to the sides of the base, while another pair recovered from an old optical drive was affixed to the arm. He fabricated a larger paper cone and added a pop filter made out of pantyhose for good measure. The higher sound quality is definitely noticeable. If you are interested in more of [Rulof’s] projects, check out his YouTube channel.
When he bought the table, he found that the electronics had been fried: many of the discrete components on the board had been burnt out. So, rather than replace the individual parts, he gutted the table and replaced the logic board with an Arduino Mega that drives the flippers, display and chimes that make pinball the delightful experience it is. Fortunately, 
![[Jimmy Rogers] and [Sophi Kravitz] having a good time](https://i0.wp.com/hackaday.com/wp-content/uploads/2015/07/5630501437772856747.png?w=396&h=264&ssl=1 "5630501437772856747")
I’ve dropped in the 74AC11138 eight-way demultiplexer for this task. It’s fast, capable of switching at megahertz rates, and its outputs default to logic HIGH. That second note is handy since idle SCL lines also default to logic HIGH.
The drive’s arm and voice coil actuator are the key parts of this project. It was modified with a metal extension so that a paper cone cut from an audio speaker could be attached, an idea used in 
