Figuring out the maximum number of peripherals which can be sensed or controlled with a minimum number of IOs is a classic optimization trap with a lot of viable solutions. The easiest might be something like an i2c IO expander, which would give you N outputs for 4 wires (SDA, SCL, Power, Ground). IO expanders are easy to interface with and not too expensive, but that ruins the fun. This is Hackaday, not optimal-cost-saving-engineer-aday! Accordingly there are myriad schemes for using high impedance modes, the directionality of diodes, analog RCs, and more to accomplish the same thing with maximum cleverness and minimum part cost. Tucoplexing is the newest variant we’ve seen, proven out by the the prolific [Micah Elizabeth Scott] (AKA [scanlime]) and not the first thing to be named after her cat Tuco.
[Micah’s] original problem was that she had a great 4 port USB switch with a crummy one button interface. Forget replacement; the hacker’s solution was to reverse and reprogram the micro to build a new interface that was easier to relocate on the workbench. Given limited IO the Tucoplex delivers 4 individually controllable LEDs and 4 buttons by mixing together a couple different concepts in a new way.
Up top we have 4 LEDs from a standard 3 wire Charlieplex setup. Instead of the remaining 2 LEDs from the 3 wire ‘plex at the bottom we have a two button Charlieplex pair plus two bonus buttons on an RC circuit. Given the scary analog circuit the scan method is pleasingly simple. By driving the R and T lines quickly the micro can check if there is a short, indicating a pressed switch. Once that’s established it can run the same scan again, this time pausing to let the cap charge before sensing. After releasing the line if there is no charge then the cap must have been shorted, meaning that switch was pressed. Else it must be the other non-cap switch. Check out the repo for hardware and firmware sources.
Last time we talked about a similar topic a bunch of readers jumped in to tell us about their favorite ways to add more devices to limited IOs. If you have more clever solutions to this problem, leave them below! If you want to see the Twitter thread with older schematics and naming of Tucoplexing look after the break.
What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.
Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.
There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.
Selecting Unpredictable Seeds
Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.
The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.
Noisy Hardware or a Jittery Clock
As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.
The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.
So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.
Most CNC robots people see involve belts and rails, gantries, lead screws, linear bearings, and so forth. Those components need a rigid chassis to support them and to keep them from wobbling during fabrication and adding imperfections to the design. As a result, the scale is necessarily small — hobbyist bots max out at cabinet-sized, for the most part. Their rigid axes are often laid out at Cartesian right angles.
One of the exceptions to this common configuration is the delta robot. Deltas might be the flashiest of CNC robots, moving the end effector on three arms that move to position it anywhere in the build envelope. A lot of these robots are super fast and precise when charged with carrying a light load, and they get put to work as pick-and-place machines and that sort of thing. It doesn’t hurt that delta bots are also parallel manipulators, which means that the motors work together to move the end effector, with one motor pulling while the matching motor pulls.
But while Cartesian CNC bots are sturdy workhorses, and deltas are fly-weight racehorces, neither can really cut it when you want to go gigantic. In terms of simplicity and scale, nothing beats cable bots.
Cable bots use wires or strings pulled by reel-mounted motors, with dimensions limited only by the room to mount the motors and the tensile strength of the cables used. When the strings are tensioned you can get a surprising degree of accuracy. Why not? Are they not computer-controlled motors? As long as your kinematic chain accounts for the end effector’s movement in one direction by unwinding another cable (for instance) you can very accurately control the end effector over a very wide scale.
The following are some fun cable bots that have caught my eye.
Some people are better than others when it comes to documenting their hacks. Some people, like [Micah Elizabeth Scott], aka [scanlime], set the gold standard with their recordings. Hacking sessions with the Winch Bot have been streamed regularly throughout the build and this is going to lead to a stacking effect in her next projects because the Winch Bot was designed to record hacking sessions. Hacking video inception anyone? Her Winch Bot summary video is after the break.
The first part of this build, which she calls the Tuco Flyer, was [Micah Elizabeth Scott]’s camera gimbal hack which we already covered and is a wonderful learning experience in itself. She refers to the gimbal portion as the “flyer” since it can move around. The Winch Bot contains the stationary parts of the Tuco Flyer and control where the camera will be in the room.
Sometimes when you need something, there is a cheap and easily obtainable product that almost fits the bill. Keyword: almost. [Micah Elizabeth Scott], also known as [scanlime], is creating a hovering camera to follow her cat around, and her Feiyu Mini3D 3-axis brushless gimbal almost did everything she’d need. After a few modifications, [Micah] now has a small and inexpensive 3-axis gimbal with a Crazyfire HZ-100P SDI camera and LIDAR-Lite distance sensor.
At thirty minutes long, [Micah’s] documenting video is rife with learning moments. We’ve said it before, and we’ll say it again: “just watch it and thank us later.” [Micah Elizabeth Scott] has a way of taking complicated concepts and processes and explaining things in a way that just makes sense (case in point: side-channel glitching) . And, while this hack isn’t exactly the most abstractly challenging, [Micah’s] natural talent as a teacher still comes through. She takes you through what goes right and what goes wrong, making sure to explain why things are wrong, and how she develops a solution.
Throughout her video, [Micah] shares small bits of wisdom gained from first-hand experience. From black hot glue to t-glase (a 3D printing filament), we learned of a few materials that could be mighty useful.
We’re no strangers to the work of [Micah Elizabeth Scott], she’s been on the scene for a while now. She’s been a Hackaday Prize Judge in 2015 and 2016 and is always making things we love to cover. She’s one of our three favorite hackers and has a beautiful website that showcases her past work.
What’s 18 feet tall, 12 feet wide, has 2,000 LEDs and turbine-driven blast furnaces? Believe it or not, it is a piece of kinetic sculpture created by [Therm] (a collective, not a person) for Burning Man 2016. The project is about 60% salvage, has a Raspberry Pi 3 helping its three human operators, and took a team of 30 about 9 months to complete.
The Raspberry Pi drives LED using fadecandy. You can see a video of the sculpture (three giant moths, to be exact) and a video about fadecandy, below. (We’ve covered a subtler fadecandy project before if you want to see a different take on it.)
We’re less than a week away from the Hackaday Superconference, where we’ll be announcing the winners of the Hackaday Prize. The Hackaday Prize is a celebration of the greatest hardware the Hackaday community has to offer, and in the past three years we’ve been running this amazing contest, we’ve seen some awesome stuff.
While not every project entered into the Hackaday Prize has gotten off the ground — the lawnmower-powered killacopter of decapitation is still tethered to its test stand — there have been some spectacular projects over the past few years that have already had an incredible impact in industry, academia, and the security industry. For the next few days, we’re going to revisit these projects, see how they’re doing, and look at the impact they’ve had on the world of Open Source hardware.
The first project we’re taking a look at is the ChipWhisperer a tool created by Colin O’Flynn to look at the secret insides of chips and firmware despite whatever embedded security is enabled on said chip. The ChipWhisperer was an entry into the first Hackaday Prize where it won second place. Since then, the ChipWhisperer has become the de facto hardware tool for investigating clock glitching, side channel analysis, and other exotic magic tricks that make security analysis so much fun.