When I’m building something, I like to have a decent-sized scrap pile on hand. Because when I’ve got to test something out — does this glue adhere to this fabric, how much force will this hold if I tap it and put a screw in, will it snap if reinforced with carbon fiber and epoxy — it’s nice to have some of the material in question on hand just for experimentation. So I pull a chunk out of the scrap pile!
But scrap piles can’t expand forever, and we all know that “too much of a good thing” is a thing, right? Scrap piles require constant pruning. You don’t really need more than a few aluminum extrusion cutoffs, so when you start building up excess inventory, it’s time to scrap it. I mean, throw it away.
A corollary of this, that I’ve only recently started to appreciate, is that if I limit the number of materials that I’m working with, it’s a lot more manageable to keep the scrap pile(s) under control. It’s simple math. If I’m working with twenty different materials, that’s twenty different heaps of scrap. But if I can get by with one weight of fiberglass for everything, that one pile of scraps can do double or triple duty. There is also the added benefit that I already know how the material works, and maybe even have old test samples on hand.
Indeed, I’m such a scrapaholic that it’s almost painful to start working with a new material and not have a scrap pile built up yet. I’m always loathe to cut into a nice square piece of stock just to test something out. But this too is part of the Great Circle of Life. By not testing things out beforehand, I’m almost guaranteed to screw up and create scrap out of what I had hoped was going to be a finished piece. See? No problem! Next version.
What do you think? Are scrap, offcuts, and their close cousins — test pieces and samples — worth keeping around in your shop? Do you have a disciplined approach, or do you just throw them in the corner? Purge per project, or only when the mountain of XPS foam gets as high as your head?
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
Flipper Zero is an open-source multitool for hackers, and [Pavel] recently shared details on what goes into the production and testing of these devices. Each unit contains four separate PCBs, and in high-volume production it is inevitable that some boards are faulty in some way. Not all faults are identical — some are not even obvious — but they all must be dealt with before they end up in a finished product.
Designing a process to effectively detect and deal with faults is a serious undertaking, one the Flipper Zero team addressed by designing a separate test station for each of the separate PCBs, allowing detection of defects as early as possible. Each board gets fitted into a custom test jig, then is subjected to an automated barrage of tests to ensure everything is as expected before being given the green light. A final test station gives a check to completed assemblies, and every test is logged into a database.
It may seem tempting to skip testing the individual boards and instead just do a single comprehensive test on finished units, but when dealing with production errors, it’s important to detect issues as early in the workflow as possible. The later a problem is detected, the more difficult and expensive it is to address. The worst possible outcome is to put a defective unit into a customer’s hands, where a issue is found only after all of the time and cost of assembly and shipping has already been spent. Another reason to detect issues early is that some faults become more difficult to address the later they are discovered. For example, a dim LED or poor antenna performance is much harder to troubleshoot when detected in a completely assembled unit, because the fault could be anywhere.
Placing two motors together in a shared drive is a simple enough task. By using something like a chain or a belt to couple them, or even placing them on the same shaft, the torque can be effectively doubled without too much hassle. But finding a way to keep the torque the same while adding the speeds of the motors, rather than the torques, is a little bit more complicated. [Levi Janssen] takes us through his prototype gearbox that attempts to do just that, although not everything works exactly as he predicts.
The prototype is based on the same principles as a differential, but reverses the direction of power flow. In something like a car, a single input from a driveshaft is sent to two output shafts that can vary in speed. In this differential drive, two input shafts at varying speeds drive a single output shaft that has a speed that is the sum of the two input speeds. Not only would this allow for higher output speeds than either of the two motors but in theory it could allow for arbitrarily fine speed control by spinning the two motors in opposite directions.
The first design uses two BLDC motors coupled to their own cycloidal drives. Each motor is placed in a housing which can rotate, and the housings are coupled to each other with a belt. This allows the secondary motor to spin the housing of the primary motor without impacting the actual speed that the primary motor is spinning. It’s all a lot to take in, but watching the video once (or twice) definitely helps to wrap one’s mind around it.
The tests of the drive didn’t go quite as planned when [Levi] got around to measuring the stall torque. It turns out that torque can’t be summed in the way he was expecting, although the drive is still able to increase the speed higher than either of the two motors. It still has some limited uses though as he notes in the video, but didn’t meet all of his expectations. It’s still an interesting build and great proof-of-concept otherwise though, and if you’re not clear on some of the design choices he made there are some other builds out there that take deep dives into cycloidal gearing or even a teardown of a standard automotive differential.
Audio and video synthesizers have been around for decades, and are pretty much only limited by one’s willingness to spend money on them. That is, unless you can develop your own FPGA-supercharged synthesizer to really get a leg up on the consumer-grade components. Of course, as [Julian] found out in this four-year project, you tend to pay for it anyway in time spent working on your projects.
[Julian] has actually decided to stop working on the project and open-source it to anyone who wants to continue on. He has already finished the PCB layout on a gargantuan 8-layer print, done all of the routing and parts selection, and really only needed to finish testing it to complete the project. It’s powered by the Xilinx Zynq and is packed with features too: HDMI, DDR3 ram, USB, a handful of sensors, and an Arduino Uno-style header to make interfacing and programming a breeze.
While we’re sympathetic with setting aside a project that we’ve worked so hard on, with most of the work done on this one it should be pretty easy to pick up and adapt for anyone interested in carrying the torch. If you were hoping to wet your whistle with something with fewer PCB layers, though, we’ve seen some interesting (but slightly simpler) video synthesizers made out of other unique hardware as well.
When shipping units in the hundreds rather than thousands, keeping overheads low is key to maintain a sustainable profit margin on each unit sold. Thus, [bald greg] built a rig that would allow for effective testing of devices rather than breaking the bank. The rig also handles programming, saving the cost of purchasing pre-programmed microcontrollers from the manufacturer. A Raspberry Pi runs the show, using its GPIO pins to program boards and saving test results and serial numbers for later reference. A bed of nails fixture is used to connect to each individual board. Additionally, to test each board as realistically as possible, hardware mimicking a real Airsoft electric pistol is used to properly load the hardware.
When the COVID-19 pandemic unfolded in early 2020, the hacker community responded in the most natural way possible: by making stuff. Isolation and idleness lead to a creative surge as hackers got to work on not only long-deferred fun projects but also potential solutions to problems raised by an overloaded medical system and choked supply chains. And so workshops and hackerspaces the world over churned out everything from novel ventilators to social-distancing aids.
But perhaps the greatest amount of creative energy was set loose on the problem of personal protective equipment, or PPE. This was due in no small part to predictions of a severe shortage of the masks, gowns, and gloves that front-line medical workers would need to keep them safe while caring for pandemic victims, but perhaps also because, at least compared to the complexity of something like a ventilator, building a mask seems easy. And indeed it is as long as you leave unanswered the crucial question: does the thing work?
Answering that question is not as easy as it seems, though. It’s not enough to assume that putting some filtration between the user and the world will work; you’ve got to actually make measurements. Hiram Gay and Lex Kravitz, colleagues at the Washington University School of Medicine in St. Louis, actually crunched the numbers on the full-face snorkel mask they modified for use as a face shield for medical PPE, and they have a lot of insights to share about proper testing of such devices. They’ll join the Hack Chat this week to discuss their findings, offer advice to builders, and reveal how they came up with their idea for a different way to build and test PPE.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about. Continue reading “PPE Testing Hack Chat”→
Date and time handling is hard, that’s an ugly truth about software development we’ll all learn the hard way one day. Sure, it might seem like some trivial everyday thing that you can easily implement yourself without relying on a third-party library. I mean, it’s basically just adding seconds on top of one another, roll them over to minutes, and from there keep rolling to hours, days, months, up until you hit the years. Throw in the occasional extra day every fourth February, and you’re good to go, right?
Well, obviously not. Assuming you thought about leap years in the first place — which sadly isn’t a given — there are a few exceptions that for instance cause the years 1900 and 2100 to be regular years, while the year 2000 was still a leap year. And then there’s leap seconds, which occur irregularly. But there are still more gotchas lying in wait. Case in point: back in May, a faulty lunar leap month handling in the Chinese calendar turned Samsung phones all over China into bricks. And while you may not plan to ever add support for non-Gregorian calendars to your own project, it’s just one more example of unanticipated peculiarities gone wild. Except, Samsung did everything right here.