Using A Vending Machine Bill Acceptor With Arduino
By Tom Nardi
We’ve all seen, and occasionally wrestled with, bill acceptors like the one [Another Maker] recently liberated from an arcade machine. But have you ever had one apart to see how it works? If not, the video after the break is an interesting peak into how this ubiquitous piece of hardware tells the difference between a real bill and a piece of paper.
But [Another Maker] goes a bit farther than just showing the internals of the device. He also went through the trouble of figuring out how to talk to it with an Arduino, which makes all sorts of money-grabbing projects possible. Even if collecting paper money isn’t your kind of thing, it’s still interesting to see how this gadget works on a hardware and software level.
As explained in the video, a set of belts are used to pull the bill past an array of IR LEDs. The hardware uses these to scan the bill and perform some dark magic to determine if it’s a genuine piece of currency. [Another Maker] notes that these readers actually need to receive occasional firmware updates to take into account new bill designs. In fact, the particular unit he has is so out of date that it won’t accept modern $5 bills; which may explain how he got it for free in the first place.
The coaster is built around an Arduino Micro, which uses a microphone to detect audio levels in the room. When it detects an extended silence, it then fires off a sound clip using a Sparkfun audio breakout board. The questions vary from plain to politically sensitive, so there’s a good chance you could get some spicy conversation as a result. Any talking device runs a risk of being more annoying than helpful, and there’s certainly a risk that Chatty Coaster could fall into this category. Choosing the right content seems key here.
Overall, while this may not be the ultimate solution to boring company, it could get a laugh or two and serves as a good way to learn how to work with audio on microcontrollers. Video after the break.
We’ll admit, when we were reading this one, we thought we had deja vu. But this one’s a lot less blamey.
Perhaps August Dvorak Is More Your Type
By Kristina Panos
One of the strangest things about human nature is our tendency toward inertia. We take so much uncontrollable change in stride, but when our man-made constructs stop making sense, we’re suddenly stuck in our ways — for instance, the way we measure things in the US, or define daytime throughout the year. Inertia seems to be the only explanation for continuing to do things the old way, even when new and scientifically superior ways come along. But this isn’t about the metric system — it’s about something much more personal. If you use a keyboard with any degree of regularity, this affects you physically.
Many, many people are content to live their entire lives typing on QWERTY keyboards. They never give a thought to the unfortunate layout choices of common letters, nor do they pick up even a whisper of the heated debates about the effectiveness of QWERTY vs. other layouts. We would bet that most of our readers have at least heard of the Dvorak layout, and assume that a decent percentage of you have converted to it.
Hardly anyone in the history of typewriting has cared so much about subverting QWERTY as August Dvorak. Once he began to study the the QWERTY layout and all its associated problems, he devoted the rest of his life to the plight of the typist. Although the Dvorak keyboard layout never gained widespread adoption, plenty of people swear by it, and it continues to inspire more finger-friendly layouts to this day.
August Dvorak was born May 5th, 1894 in Glencoe, Minnesota. He served in the US Navy as a submarine skipper in WWII, and is believed to be a distant cousin of the Czech composer Antonín Dvořák. Not much has been published about his early life, but Dvorak wound up working as an educational psychologist and professor of the University of Washington in Seattle, and this is where his story really begins.
Dvorak’s interest in keyboards and typing was struck when he advised a student named Gertrude Ford with her master’s thesis on the subject of typing errors. Touch typing was only a few decades old at this point, but the QWERTY layout had already taken a firm hold on the industry.
As Dvorak studied Ford’s thesis, he began to believe that the QWERTY layout was to blame for most typing errors, and was inspired to lead a tireless crusade to supplant it with a layout that served the typist and not the typewriter. His brother-in-law and fellow college professor, William Dealey, joined him on this quest from the beginning.
AOEUIDHTNS
Dvorak and Dealey put a great deal of effort into analyzing every aspect of typing, studying everything from frequently-used letter combinations of English to human hand physiology. In 1914, Dealey saw a demonstration given by Frank and Lillian Gilbreth, who were using slow-motion film techniques to study industrial processes and worker fatigue. He told Dvorak what he’d seen, and they adopted a similar method to study the minute and complex movements of typists.
In 1936, after two decades of work, Dvorak and Dealey debuted a new layout designed to overcome all of QWERTY’s debilitating detriments. Whereas QWERTY places heavy use on the left hand and forces fingers outside the home row over 60% of the time, the Dvorak layout favors hand alternation and keeping the fingers working at home as much as possible. In this new arrangement, the number of words that can be typed without leaving the home row increased by a few thousandfold. Dvorak and Dealey along with Gertrude Ford and Nellie Merrick published all of their psychological and physiological findings about typing in the now out-of-print Typewriting Behavior (1936).
The original Dvorak layout. From Typewriting Behavior via @rand.ferch
At first, it seemed as though the Dvorak-Dealey simplified layout had half a chance of supplanting QWERTY. Dvorak found that students who had never learned to touch type could pick up Dvorak in one-third the time it took to learn QWERTY.
Dvorak entered his typists into contests, and they consistently out-typed the QWERTYists by a long shot. It got so bad that within a few years, Dvorak typists were banned outright from competing. This decision was overturned not long after, but the resentment remained. QWERTY typists were so unnerved by the speed of the Dvorak typists that Dvorak typewriters were sabotaged, and he had to hire security guards to protect them.
The QWERTY is Too Strong
Although there were likely many factors at play, the simple fact is that by the time Dvorak patented his layout, Remington & Sons had cornered the market on typewriters. Even so, Dvorak released his keyboard during the Depression, and hardly anyone could afford to buy a new typewriter just because there was some hot new layout.
Although Dvorak typewriters were never mass-produced, they almost made waves thanks to the US Navy. Faced with a shortage of trained typists during WWII, they experimented with retraining QWERTY typists on Dvorak and found a significant increase in speed. They allegedly ordered thousands of Dvorak typewriters, but were vetoed by the Treasury department because of QWERTY inertia.
August Dvorak went on to make one-handed keyboards with layouts for both the left and right hand. In 1975, he died a bitter man, never understanding why the public would continue to shrug their overworked shoulders and keep using QWERTY keyboards. He might have been pleased to know that the Dvorak layout eventually became an ANSI standard and comes installed on most systems, but dismayed to find the general population still considers it a fringe layout.
I’m tired of trying to do something worthwhile for the human race. They simply don’t want to change!
Reverse Engineering a Ceiling Fan Remote
By Rich Hawkes
In the quest to automate everything in your home, you no doubt have things that aren’t made with home automation in mind. Perhaps your window AC unit, or the dimmer in your dining room. [Seb] has several ceiling fans that are controlled by remotes and wanted to connect them to his home automation system. In doing so, [Seb] gives a good overview of how to tackle this problem and how to design a PCB so he doesn’t have a breadboard lying around connected to the guts of his remote control.
There are several things [Seb] needs to figure out in order to connect his fans to Home Assistant, the home automation system he uses: He needs to determine if the circuit in the remote can be powered by 5 or 3.3 V, he needs to connect the circuit to an ESP32 board, and he needs to figure out if he can create a custom PCB that combines the circuit and the ESP32 into one. The video goes through each of these steps and shows the development of each along the way.
There’s a lot of info in the video, so it might need to be slowed down a bit to see all the details. There are some other reverse engineering of home automation gear on the site, here, or, you might want to build your own remote to control your automated devices.
Behind The Scenes Of Folding@Home: How Do You Fight a Virus with Distributed Computing?
By Roger Cheng
A great big Thank You to everyone who answered the call to participate in Folding@Home, helping to understand proteins interactions of SARS-CoV-2 virus that causes COVID-19. Some members of the FAH research team hosted an AMA (Ask Me Anything) session on Reddit to provide us with behind-the-scenes details. Unsurprisingly, the top two topics are “Why isn’t my computer doing anything?” and “What does this actually accomplish?”
The first is easier to answer. Thanks to people spreading the word — like the amazing growth of Team Hackaday — there has been a huge infusion of new participants. We could see this happening on the leader boards, but in this AMA we have numbers direct from the source. Before this month there were roughly thirty thousand regular contributors. Since then, several hundredthousands more started pitching in. This has overwhelmed their server infrastructure and resulted in what’s been termed a friendly-fire DDoS attack.
Here’s a summary of current Folding@Home situation :
* We know about the work unit shortage
* It’s happening because of an approximately 20x increase in demand
* We are working on it and hope to have a solution very soon.
* Keep your machines running, they will eventually fold on their own.
* Every time we double our server resources, the number of Donors trying to help goes up by a factor of 4, outstripping whatever we do.
Why don’t they just buy more servers?
The answer can be found on Folding@Home donation FAQ. Most of their research grants have restrictions on how that funding is spent. These restrictions typically exclude capital equipment and infrastructure spending, meaning researchers can’t “just” buy more servers. Fortunately they are optimistic this recent fame has also attracted attention from enough donors with the right resources to help. As of this writing, their backend infrastructure has grown though not yet caught up to the flood. They’re still working on it, hang tight!
Computing hardware aside, there are human limitations on both input and output sides of this distributed supercomputer. Folding@Home need field experts to put together work units to be sent out to our computers, and such expertise is also required to review and interpret our submitted results. The good news is that our contribution has sped up their iteration cycle tremendously. Results that used to take weeks or months now return in days, informing where the next set of work units should investigate.
In a word, yes. Folding@Home results are available to researchers at no cost, and this data has contributed to many published papers and even more in the pipeline. For more details on publishing see our earlier update, but there were a few new questions in this AMA beyond papers.
This global pandemic has attracted attention at all levels, so there are many other computational research projects running like AlphaFold and efforts at Oak Ridge National Laboratory. Folding@Home isn’t even the only distributed computing platform, with Rosetta@Home on BOINC also vying for time on people’s personal computers. Are we all just duplicating effort? The team assured us that we are not. All of these are complementary efforts attacking the challenge from different sides. They are coordinating with, not competing against, all of these other researchers.
They do acknowledge it’s hard to make their work understandable outside of medical researchers. But public outreach is something they very much want to improve upon. They haven’t found a way to condense such a complex field into a single tweet, but in the meantime they’ll settle for efforts like this eleven-part thread summarizing how Folding@Home helps drug discovery and development.
What does the future hold?
We’re big fans of open source here at Hackaday, and thankfully someone brought up that topic. There is intent to open-source the Folding@Home client but that hasn’t happened yet and obviously not their top priority at the moment. They hope opening their source will attract contributors to bring Folding@Home to more platforms. BOINC is an obvious candidate, and we can also think of upcoming powerful video game consoles with teraflops to spare. Software developers who have a newfound interest in this field can get started by looking over the existing open-source foundations: GROMACS for their CPU folding core, and OpenMM for their GPU folding core. Additional technical background can be found on the folding support forum.
We’d love to have you join in the effort, if you do, use the team code #44851 to track your stats as part of Team Hackaday. And, we encourage all participants to continue even after this specific crisis is over, whenever that may be. After the original SARS subsided, research attention withered and in hindsight that might have been a mistake. Yes, we need to focus on SARS-CoV-2 today, but researchers want a better general understanding of the whole family. It’s only a matter of time before SARS-CoV-3 (or whatever its name will be) makes its appearance, how prepared will we be? Your support of Folding@Home will continue to be valuable long after this pandemic has been retired to the history books.
If you’ve seen both a fused filament fabrication (FFF) printer and a wire welder, you may have noticed that they work on a similar basic principle. Feedstock is supplied in filament form — aka wire — and melted to deposit on the work piece in order to build up either welds in the case of the welder, or 3D objects in the case of the printer. Of course, there are a number of difficulties that prevent you from simply substituting metal wire for your thermoplastic filament. But, it turns out these difficulties can be overcome with some serious effort. [Dominik Meffert] has done exactly this with his wire 3D printer project.
Extruder cold end using a standard feeder roller
For his filament, [Dominik] chose standard welding wire, and has also experimented with stainless steel and flux-cored wires. Initially, he used a normal toothed gear as the mechanism in the stepper-driven cold end of his Bowden-tube extrusion mechanism, but found a standard wire feeder wheel from a welder worked better. This pinch-drive feeds the wire through a Bowden tube to the hot end.
In thermoplastic 3D printers, the material is melted in a chamber inside the hotend, then extruded through a nozzle to be deposited. Instead of trying to duplicate this arrangement for the metal wire, [Dominik] used a modified microwave oven transformer (MOT) to generate the low-voltage/high-amperage required to heat the wire restively. The heating is controlled through a phase-fired rectifier power controller that modulates the power on the input of the transformer. Conveniently, this controller is connected to the cooling fan output of the 3D printer board, allowing any standard slicer software to generate g-code for the metal printer.
To allow the wire to heat and melt, there must be a complete circuit from the transformer secondary. A standard welding nozzle matching the wire diameter is used as the electrode on the hot end, while a metal build plate serves as the other electrode. As you can imagine, getting the build plate — and the first layer — right is quite tricky, even more so than with plastic printers. In this case, added complications involve the fact that the printed object must maintain good electrical continuity with the plate, must not end up solidly welded down, and the fact that the 1450 °C molten steel tends to warp the plate.
Considering all the issues that have to be solved to make this all work, we are very impressed with [Dominik’s] progress so far! Similar issues were solved years ago for the case of thermoplastic printers by a group of highly-motivated experimenters, and it’s great to see a similar thing starting to happen with metal printing, especially using simple, readily-available materials.
Fail of the Week: In CAD, Remember to Model the Environment
By Donald Papp
What’s wrong with the above picture? Failure can be an excellent teacher, and [J. Peterson] reminds us all of this when he says to remember to model the environment when designing things in CAD. He contrasts a failure with a success to demonstrate what that means.
The failure was a stand for a screwdriver set, shown above. He modeled up a simple stand to hold a screwdriver handle and the bits in a nice, tight formation. He didn’t model any of parts, he just took some measurements and designed the holder. Everything fit just fine, but it had a major ergonomic problem: you can barely reach the handle because it is fenced in by the surrounding bits! Had he modeled all of the parts during the design phase, and not just the part he was making, this problem would have been immediately obvious during the design phase.
The contrasting success is an adapter he designed to mount an artistic glass marble to a lit display stand. The stand itself as well as the glass marble were modeled in CAD, then the adapter designed afterwards to fit them. With all of the involved objects modeled, he could be certain of how everything fit together and it worked the first time.
Now, to most people with a 3D printer of their own, discovering a part isn’t quite right is not a big (nor even a particularly expensive) problem to have, but that’s not the point. Waste and rework should be avoided if possible. To help do that, it can be good to remember to model the whole environment, not just the thing being made. Add it on to the pile of great design advice we’ve seen for designing things like enclosures and interfaces.
DIY Bagpipes Made From Common Household Items
By Lewin Day
The bagpipes, most commonly seen in their Great Highland form from Scotland, are a loud and imposing musical instrument. Known for being difficult to practice quietly, they’re not the ideal thing to pick up in these times of quarantine and isolation. But, if you must, here’s how you can craft your own at home!
A garbage bag is used as the air bag for this design, readily available and easy to work with. A recorder is then installed into the bag to act as the chanter – the part of the instrument with with pitch is controlled by finger position. A second recorder is then installed as a drone, which produces the continuous harmonizing note typical of bagpipes. A pair of pens are used to create the blowpipe which supplies air to the instrument. Everything is then sealed up with tape and you’re ready to go!
Maxing Out Browser Tabs With 2TB Of Memory
By Lewin Day
Tabbed browsing was a gamechanger, allowing users to effectively browse multiple websites at once without losing context. It proved a better solution than using multiple windows, and was an efficiency boon celebrated by all. Many of us are tab fiends, opening great numbers at a time as a habitual part of our workflow. [Linus] decided to find out just how many he could open on a system armed with a full 2TB of RAM.
As may be obvious, setting up a system with 2TB of RAM is no mean feat. Special server-grade RAM modules were sourced, packing 128GB of RAM each, set up for ECC operation. Packing out 16 slots, there’s a performance penalty to addressing so much RAM with a single CPU, but for memory-intensive work, it’s worthwhile. The CPU in question is an AMD 64-core processor, providing plenty of grunt for the task at hand.
In testing, the machine began to slow down long before the RAM was full. Beyond 5000 tabs, things began to crawl. At 6000 tabs, it was simply impractical to open more, with the machine taking a full 26 seconds to respond to a single click. Memory usage at this point was just 200GB, suggesting that software limitations were getting in the way of opening yet more tabs.
While it’s not a useful measure of anything important, it’s fun to explore the limits nonetheless. We’ve seen their projects before, such as this original Xbox casemod. Video after the break.
Professional Ventilator Design Open Sourced Today by Medtronic
By Bob Baddeley
Medical device company Medtronic released designs for one of their ventilators to open source for use in the COVID-19 pandemic. This is a laudable action, and there is plenty to glean from the specs (notable is that the planned release is incomplete as of this writing, so more info is on the way). Some initial reactions: medical devices are complicated, requirements specifications are enormous, the bill of materials (BOM) is gigantic, and component sourcing, supply chain, assembly, and testing are just as vital as the design itself.
The pessimist in me says that this design was open sourced for two reasons; to capitalize on an opportunity to get some good press, and to flex in front of the DIY community and convince them that the big boys should be the ones solving the ventilator shortage. The likelihood of anyone actually taking these specs and building it as designed are essentially zero for a variety of reasons, but let’s assume their intent is to give a good starting point for newer changes. The optimist in me says that after what happened to California over the weekend with 170 ventilators arriving broken, it might be nice to have open designs to aid in repair of existing non-functioning ventilators.
The design details released today are for their PB560 model, which was originally launched in 2010 by a company called Covidien, before it merged with Medtronic, so we’re already starting with a device design that’s a decade old. But it’s also a design that has proven itself through widespread use, and this data dump gives us a great look at what actually goes into one of these machines. Let’s take a look.
Requirements Documents
There are a few very long documents in this section, but the overview is that this describes a document for a medical device with a lot of features and a lot of requirements, designed and manufactured in an orderly timeline. Two points that are worth mentioning are that these documents are great for looking at all the technical requirements of a ventilator, and that many pages can be crossed off in the name of expediency.
Electrical Schematics
The design functions around an ST10F27? (where ? is either an 8 or a B or a 3, depending on how you squint when looking at the PDF). There’s an ST10F273M that’s currently in active production by ST, so that might be it. There isn’t a full BOM available yet, but looking at some of the components shows that they are still available. There are no less than 4 different PCBs, with a main board, a board for the buzzer, a board for the power pack connection, and a board to control the motor.
Manufacturing Documents
There are lots of pretty pictures inside the manufacturing documents that show how the unit is assembled, with some overview documents that show the details of the assembly workflow. It seems there are some documents missing, though, because there’s nothing about the blower itself.
What’s Missing
Despite it being a dump of 53MB, there’s quite a bit missing if you were trying to build this machine. However, Medtronic did mention in their press release that “…software code and other information will follow shortly.” so there are more details on the way. Here are the things we’d like to see:
Firmware
Mechanical design
PCB layout
Complete BOM, not just of the electronics but of all the components
Programming, test, and assembly fixtures
We Need More Medical Devices Published as Open Source
Thank you, Medtronic. This is a great step, and we hope that useful information can be gleaned from this available design, and that others will follow your lead. While it’s not possible to recreate the product with the currently available files, it is a revealing view of the complexity involved in not just ventilators but any medical device.
We hope that this could be used to repair existing units that are not in service. Already, having the service manual and an explanation of the testing process is a huge help in this area. If they were also to release the mechanical design it would technically become possible to fabricate replacement parts to the original specifications if OEM replacements were for some reason unavailable.
However, we suspect that the amount of work that would be required to spin up assembly of this particular product is more than could be accomplished in the amount of time available, and the resources that would have to be mobilized are probably the same resources already working on building medical devices for other designs. The documentation around the release says any products released based on this are only to be used for COVID-19, so if anyone does manage to take this and use it to start production in a timely manner it will be both incredibly helpful, and super impressive.
But [Another Maker] goes a bit farther than just showing the internals of the device. He also went through the trouble of figuring out how to talk to it with an Arduino, which makes all sorts of money-grabbing projects possible. Even if collecting paper money isn’t your kind of thing, it’s still interesting to see how this gadget works on a hardware and software level.
3d print ......errori ed esperienze, 