If 2020 can be remembered in any positive light, it would be that this has been the year of the hobby tryouts. Why not pottery? Sure, throwing pots won’t fill your belly like homemade bread. But we would bet you can see the value in having a bunch of expendable objects that are easily (and quite satisfyingly) smashed to smithereens. The best part is that between the workbench, junk box, and recycle bin, you can probably build [Jadem52]’s pottery wheel for ants with stuff you already have. Bonus!

Pottery wheels aren’t that complicated. They’re honestly kind of expensive for what they are — a motor and a belt driving a rotating platter. It’s like a record player, but less fussy. Where they really get you on expense is the kiln to heat-treat those pots into sturdy vessels. But you could always use air-dry clay, especially if you’re making these things just to smash them whenever you need to let off some steam.

So anyway, you don’t need much more than a motor, a jar lid for a wheel to throw on, and a bearing to make it spin smoothly. Store-bought pottery wheels have a foot feed to control the motor speed, but this pocket version is either spinning on nine volts or it isn’t. The great thing about a project like this is that once you have the general principle down and use the thing, you can iterate and upgrade to your heart’s content. Take it for a little spin after the break.

If you want to hack together a more conventionally-sized wheel, an old ceiling fan motor should be more than sufficient.

source https://hackaday.com/2020/07/14/take-pottery-for-a-spin-with-a-pocket-sized-wheel/

It’s perhaps easy to think that despite the rapid acceleration of technology that there are certain jobs that will never be automated out of existence. Generally the job said to be robot-proof is the one held by the person making the proclamation, we notice. But certainly the job of cutting and styling people’s hair could never be done by a robot, right?

We wouldn’t bet the farm on it, although judging by [Shane Wighton]’s quarantine haircut robot, it’ll be a while before the stylists of the world will be on the dole. Said to have sprung from the need to trim his boyishly long hair, the contraption is an object lesson recreating the subtle manual skills a stylist brings to every head they work on — there’s a reason it takes 1,500 hours or more of training to get a license, after all. [Shane] discovered this early, and realized that exactly replicating the manual dexterity of human hands was a non-starter. His cutting head uses a vacuum to stand the hair upright, 3D-printed fingers to grip a small bundle of hair, and servo-driven scissors to cut it to length. The angle of attack of the scissors can be adjusted through multiple axes, and the entire thing rotates on a hell-no-I’m-not-putting-my-head-in-that-thing mechanism.

To his great credit, [Shane] braved the machine as customer zero, after only a few non-conclusive life-safety tests with a dummy head and wig. We won’t spoil the ending, but suffice it to say that the thing actually worked with no bloodshed and only minimal damage to [Shane]’s style. The long-suffering [Mrs. Wighton], however, was not convinced to take a test drive.

In all seriousness, kudos to [Shane] for attacking such a complex problem. We love what he’s doing with his builds, like his basketball catcher and his robo-golf club, and we’re looking forward to more.

Thanks to [Ilkka Takayama] for the tip.

source https://hackaday.com/2020/07/14/a-robotic-stylist-for-your-lockdown-lengthened-locks/

We awake this morning to sad news of the premature passing of Grant Imahara at the age of 49 due to a brain aneurysm. Grant was best known for his role on the wildly popular Mythbusters television show on which he starred and built test apparatus for seasons three through twelve. He landed this role because he was a badass hardware hacker as much as he was an on-camera personality.

Grant received his degree in electrical engineering from USC in 1993 and landed a job with Lucasfilm, finding his way onto the Industrial Light and Magic team to work on blockbuster films like the Star Wars prequels (R2-D2 among other practical effects) and sequels to Terminator and The Matrix. Joining the Mythbusters team in 2005 was something of a move to rapid prototyping. Each of the 22-minute episodes operated on a 10-day build and a film cycle in which Grant was often tasked with designing and fabricating test rigs for repeatable testing with tightly controlled parameters.

After leaving the show, Grant pursued several acting opportunities, including the Kickstarter funded web series Star Trek Continues which we reported on back in 2013. But he did return to the myth busting genre with one season of The White Rabbit Project on Netflix. One of the most genuinely geeky appearances Grant made was on an early season of Battlebots where his robot ‘Deadblow’ sported a wicked spiked hammer. Video of his appearance in the quarter-finals is like a time-capsule in hacker history and guaranteed to bring a smile to your face.

Grant Imahara’s legacy is his advocacy of science and engineering. He was a role model who week after week proved that questioning how things work, and testing a hypothesis to find answers is both possible and awesome. At times he did so by celebrating destructive force in the machines and apparatus he built. But it was always done with observance of safety precautions and with a purpose in mind (well, perhaps with the exception of the Battlebots). His message was that robots and engineering are cool, that being a geek means you know what the heck you’re doing, and that we can entertain ourselves through creating. His message lives on through countless kids who have grown up to join engineering teams throughout the world.

Grant was the headliner at the first Hackaday Superconference in San Francisco back in 2015. I’ve embedded the fireside chat below where you can hear in his own words what inspired Grant, along with numerous stories from throughout his life.

[Main image source: Grant Imahara in The Verge 2018 web series Home of the Future ]

[Thumbnail image source: Grant Imahara by Gage Skidmore CC-BY-SA 3.0

source https://hackaday.com/2020/07/14/roboticist-grant-imahara-of-mythbusters-fame-dies-of-aneurysm-at-age-49/

Yes, circuit sculptures are amazing. But the patience and skill required puts most of the designs we’ve seen fairly far out of reach of the average beginner. We totally understand — not everyone finds fun in fiddly, structural soldering.

[Hari Wiguna] was captivated by the LED ball that [Jiří Praus] made last Christmas and figured there had to be less painful ways to cover a sphere in blinkenlights than printing a negative to use as a soldering jig. Turns out there is at least one way — just design the structure to use PCBs in place of brass rod, and fit everything together like a 3D puzzle made of FR4.

This SMD LED ball is almost ready for prime time. [Hari] wants this to be accessible for everyone and completely parametric, so he’s still working out the kinks. Check out the current form after the break as [Hari] rolls the ball through the various display modes using an Arduino and talks about the failures along the way, like having to file out the LED slots because they were designed too tightly the first time. [Hari] is also working on the friction fit of the pieces so the ball is easier to assemble, especially at the beginning.

3D prints as circuit sculpture soldering jigs are great tools, don’t get us wrong. How else are you gonna solder brass rod together on a curve?

 

 

source https://hackaday.com/2020/07/14/an-easier-way-to-roll-your-own-led-ball/

It should have been another fine day, but not all was well in paradise. Few things bring a creeping feeling of doom like a computer that hardlocks and then refuses to boot. The clicking sound coming from the tower probably isn’t a good sign either. Those backups are up to date, right? Right?

There are some legends and old stories about hard drive repair. One of my favorites is the official solution to stiction for old drives: Smack it with a mallet. Another trick I’ve heard repeatedly is to freeze a hard drive before trying to read data off of it. This could actually be useful in a couple instances. The temperature change can help with stiction, and freezing the drive could potentially help an overheating drive last a bit longer. The downside is the potential for condensation inside the drive. Don’t turn to one of these questionable fixes unless you’ve exhausted the safer options.

For the purpose of this article, we’ll assume the problem is the hard drive, and not another component like a power supply or SATA cable causing problems. A truly dead drive is a topic for another time, but if the drive is alive enough to show up as a block device when plugged in, then there’s hope for recovering the data. One of the USB to SATA cables available on your favorite online store is a great way to recover data. Another option is booting off a Linux DVD or flash drive, and accessing the drive in place. If you’re lucky, you can just copy your files and call it a day. If the file transfer fails because of the dying drive, or you need a full disk image, it’s time to pull out some tools and get to work.

As a hard drive degrades, individual sectors can become unreadable. This is an expected process, and modern drives are built with spare sectors to fend off the inevitable. As sectors begin to become unreliable, they are retired, and spare sectors are used instead. When the spare sectors are gone, the disk begins accumulating unreadable sectors. An unreadable sector in the middle of a file will kill a file transfer, or maybe even make the device unmountable. The ironic part is that it’s usually only a tiny percentage of the disk that’s unreadable. If only there was a way to manage those unreadable sectors.

Turning to DDRescue

The amateur sysadmin has a potent tool in his toolkit: ddrescue. It’s a descendant of sorts of the venerable dd disk copy tool, but with an important difference. When dd encounters a read error, it stops the transfer and displays the error. ddrescue makes a note of the error, leaves a blank spot in the output file, and continues transferring what data it can. Because there is record of the missing chunks, we can keep trying to read the missing parts, and maybe recover more data.

To get ddrescue running, we give it an input, an output, and a mapfile.
ddrescue /dev/sda diskimage.img mapfile.log
By default, ddrescue goes through three phases of rescue. First, it copies a sector at a time until it hits an error. For a drive that’s working perfectly, this operation completes without issue and the whole drive is copied. If a sector can’t be copied, or is even particularly slow in responding, ddrescue jumps ahead, hopefully beyond the problem.

The second phase is trimming. To put it simply, ddrescue starts at the end of each skipped section, and works backwards till it hits a bad sector. The purpose is to recover the largest amount of data as quickly as possible, and to establish exactly which sectors are the problematic ones. The last phase is scraping, where each unread sector is examined individually, attempting to read the data contained. Each time a sector is read, the mapfile is modified to keep track.

A sector might fail to read 15 times in a row, and on the 16th attempt, finally read successfully. Because of this, ddrescue supports making multiple scraping passes in alternating directions. Part of the theory is that the read head alignment might be slightly different when approaching the sector from a different location, and that difference might be enough to finally get a successful read.

When It’s Not So Simple

While the ideal operation of ddrescue is straightforward enough, there are some potential problems to be aware of. The first is heat. The process of trying to recover data from an already dying drive can quickly overheat it, and make further reads impossible. The best and simplest solution is a fan blowing cool air over the drive. The other common problem I’ve encountered is a bit harder to explain, but it’s identified by a specific error message: ddrescue: Input file disappeared: No such file or directory. When trying to read from the drive, something went wrong badly enough that the drive has disappeared from the system. My theory in this case is that the firmware on the drive itself has crashed and halted. Regardless, unpowering and repowering the drive is usually enough to get back to work.

This means that for a particularly stubborn drive, the process of recovering bits feels a lot like babysitting. Power cycle the drive once it crashes, and restart ddrescue — over and over and over again. Since the read fails as a result of the crash, that sector is marked as bad, and the rescue attempt jumps past it. Sectors in good shape might not trigger the crash, so some data gets read.

If you think that spending hours power cycling a hard drive doesn’t sound like a fun task, and is something that should be automated, then you’re right. It’s easy enough to wrap our ddrescue command in a loop, ideally along with five seconds of sleep. That handles half the problem, but power cycling the drive isn’t a software problem. I’ve used Adafruit’s power switch tail in the past, connected to a Raspberry Pi GPIO pin, to kill the drive’s power supply every 30 seconds. It’s not ideal, but it works. Unfortunately that device is discontinued, and I’m not aware of a direct replacement.

The last time I ran into this problem, I used a WiFi power switch, pictured above. Whenever the device disappeared, the script triggered the plug to power cycle the drive. This worked, and on a 500 GB drive, I recovered all but the last 1.5 megs. The only downside is that the smart plug only works via the cloud, so every power cycle required a request sent to the IFTTT cloud. Leaving the drive running overnight resulted in too many requests, and my account was frozen. Next time, Ill have to use a device that supports one of the open source firmwares, like Tasmota. Regardless, the script is simple:

while true; do
    sudo ddrescue /dev/sda diskimage.img mapfile.log
    if [ -a /dev/sdc ]; then
        sudo ddrescue /dev/sda diskimage.img mapfile.log -M
    else
        curl -X POST https://maker.ifttt.com/trigger/switch_off/with/key/REDACTED
        sleep 10
        curl -X POST https://maker.ifttt.com/trigger/switch_on/with/key/REDACTED
        sleep 10
    fi
done

If the device disappears, use the switch to power cycle the drive. If ddrescue completes, and the device is still present, then use the -M switch to mark all the bad sectors as untried.

In many cases, this isn’t a process that ever really finishes, but the rate of recovery eventually drops too low to be worth continuing. Once you’ve copied as much of the raw data off the drive as possible, it’s a good idea to use fsck/chkdsk to repair the now-rescued filesystem. If it’s a system drive, after you burn it to a new disk, you’ll want to use your OS’s tools to verify the system files. For Windows, I’ve had good success with SFC and DISM. On Linux, use your system’s package manager to verify your installed packages. On a Fedora/Red Hat system, rpm -Va will show any installed binaries that have unexpected contents.

Over the years I’ve rescued a handful of drives with ddrescue, that other techniques just wouldn’t touch. It’s true that a good backup is the ideal solution, but if you find yourself in a situation where you really need to get data off a dying drive, ddrescue might just be your saving grace. Good luck!

Banner Image: “Shiny” by Nick Perla, BY-ND

source https://hackaday.com/2020/07/14/tales-from-the-sysadmin-impending-hard-drive-doom/

[Mitxela]’s repair of a Roland JV-1080 (a rack-mounted 90s-era synthesizer) sounds simple: replace a broken rotary encoder on the front panel. It turned out to be anything but simple, since the part in question is not today’s idea of a standard rotary encoder at all. The JV-1080 uses some kind of rotary pulse switch, which has three outputs (one for each direction, and one for pushing the knob in like a button.) Turn the knob in one direction, and one of the output wires is briefly shorted to ground with every detent. Turn it the other way, and the same happens on the other output wire. This is the part that needed a replacement.

Rather than track down a source for the broken part, [Mitxela] opted to replace it with a modern rotary encoder combined with an ATtiny85 microcontroller to make it act like something the JV-1080 understands and expects. There was an additional wrinkle, however. The original rotary pulse switch is an entirely passive device, and lives at the end of a four-conductor cable with no power provided on it. How could the ATtiny85 be powered without resorting to running a wire to a DC voltage supply somewhere? Success was had, but it did take some finessing.

For the power, it turns out that the signal wires are weakly pulled up to +5 V and [Mitxela] used that for a power supply to the microcontroller. Still, by itself that wasn’t enough, because the ATtiny85 can easily consume more current than the weak pullups can source. We really recommend reading all the details in [Mitxela]’s writeup, but the short version is that the ATtiny85 does two things.

First, it minimizes its power usage by spending most of its time in sleep mode (consuming barely any power at all) and uses an interrupt to wake up just long enough to handle knob activity. Second, the trickle of power from the weak pullups doesn’t feed the ATtiny directly. It charges a 100 uF capacitor through a diode, and that is what keeps the microcontroller from browning out during its brief spurts of activity. Even better, after browsing the datasheet for the ATtiny, [Mitxela] saw it was possible to use the built-in ESD protection diodes for this purpose instead of adding a separate component.

It’s a neat trick and makes for a very compact package. Visit the project’s GitHub repository to dive into the nitty gritty. In the end, a single assembly at the end of a 4-wire connector acts just like the original passive component, no extra wires or hardware modifications needed.

When opening older hardware it’s never quite certain what will be found on the inside. But at least [Mitxela]’s repair duties on this synth didn’t end up with him tripping out on LSD.

source https://hackaday.com/2020/07/14/spoofing-an-analog-rotary-knob-with-an-attiny-and-vampiric-power/

[Mitxela]’s repair of a Roland JV-1080 (a rack-mounted 90s-era synthesizer) sounds simple: replace a broken rotary encoder on the front panel. It turned out to be anything but simple, since the part in question is not today’s idea of a standard rotary encoder at all. The JV-1080 uses some kind of rotary pulse switch, which has three outputs (one for each direction, and one for pushing the knob in like a button.) Turn the knob in one direction, and one of the output wires is briefly shorted to ground with every detent. Turn it the other way, and the same happens on the other output wire. This is the part that needed a replacement.

Rather than track down a source for the broken part, [Mitxela] opted to replace it with a modern rotary encoder combined with an ATtiny85 microcontroller to make it act like something the JV-1080 understands and expects. There was an additional wrinkle, however. The original rotary pulse switch is an entirely passive device, and lives at the end of a four-conductor cable with no power provided on it. How could the ATtiny85 be powered without resorting to running a wire to a DC voltage supply somewhere? Success was had, but it did take some finessing.

For the power, it turns out that the signal wires are weakly pulled up to +5 V and [Mitxela] used that for a power supply to the microcontroller. Still, by itself that wasn’t enough, because the ATtiny85 can easily consume more current than the weak pullups can source. We really recommend reading all the details in [Mitxela]’s writeup, but the short version is that the ATtiny85 does two things.

First, it minimizes its power usage by spending most of its time in sleep mode (consuming barely any power at all) and uses an interrupt to wake up just long enough to handle knob activity. Second, the trickle of power from the weak pullups doesn’t feed the ATtiny directly. It charges a 100 uF capacitor through a diode, and that is what keeps the microcontroller from browning out during its brief spurts of activity. Even better, after browsing the datasheet for the ATtiny, [Mitxela] saw it was possible to use the built-in ESD protection diodes for this purpose instead of adding a separate component.

It’s a neat trick and makes for a very compact package. Visit the project’s GitHub repository to dive into the nitty gritty. In the end, a single assembly at the end of a 4-wire connector acts just like the original passive component, no extra wires or hardware modifications needed.

When opening older hardware it’s never quite certain what will be found on the inside. But at least [Mitxela]’s repair duties on this synth didn’t end up with him tripping out on LSD.

source https://hackaday.com/2020/07/14/spoofing-an-analog-rotary-knob-with-an-attiny-and-vampiric-power/

[Mitxela]’s repair of a Roland JV-1080 (a rack-mounted 90s-era synthesizer) sounds simple: replace a broken rotary encoder on the front panel. It turned out to be anything but simple, since the part in question is not today’s idea of a standard rotary encoder at all. The JV-1080 uses some kind of rotary pulse switch, which has three outputs (one for each direction, and one for pushing the knob in like a button.) Turn the knob in one direction, and one of the output wires is briefly shorted to ground with every detent. Turn it the other way, and the same happens on the other output wire. This is the part that needed a replacement.

Rather than track down a source for the broken part, [Mitxela] opted to replace it with a modern rotary encoder combined with an ATtiny85 microcontroller to make it act like something the JV-1080 understands and expects. There was an additional wrinkle, however. The original rotary pulse switch is an entirely passive device, and lives at the end of a four-conductor cable with no power provided on it. How could the ATtiny85 be powered without resorting to running a wire to a DC voltage supply somewhere? Success was had, but it did take some finessing.

For the power, it turns out that the signal wires are weakly pulled up to +5 V and [Mitxela] used that for a power supply to the microcontroller. Still, by itself that wasn’t enough, because the ATtiny85 can easily consume more current than the weak pullups can source. We really recommend reading all the details in [Mitxela]’s writeup, but the short version is that the ATtiny85 does two things.

First, it minimizes its power usage by spending most of its time in sleep mode (consuming barely any power at all) and uses an interrupt to wake up just long enough to handle knob activity. Second, the trickle of power from the weak pullups doesn’t feed the ATtiny directly. It charges a 100 uF capacitor through a diode, and that is what keeps the microcontroller from browning out during its brief spurts of activity. Even better, after browsing the datasheet for the ATtiny, [Mitxela] saw it was possible to use the built-in ESD protection diodes for this purpose instead of adding a separate component.

It’s a neat trick and makes for a very compact package. Visit the project’s GitHub repository to dive into the nitty gritty. In the end, a single assembly at the end of a 4-wire connector acts just like the original passive component, no extra wires or hardware modifications needed.

When opening older hardware it’s never quite certain what will be found on the inside. But at least [Mitxela]’s repair duties on this synth didn’t end up with him tripping out on LSD.

source https://hackaday.com/2020/07/14/spoofing-an-analog-rotary-knob-with-an-attiny-and-vampiric-power/