Reverse Engineering Saves Weller With A Wonky LCD From The Trash Pile

There’s nothing more satisfying than finding a broken piece of gear in the trash and bringing it back to life. Satisfying, but also potentially more time-consuming — someone tossed it for a reason, after all. Figuring out what that reason is and finding a way to back it better is where the fun — and the peril — are.

Luckily, some pieces of equipment have a relatively short list of well-known failure modes, a fact that [Lauri Pirttiaho] relied on for this fix of an old Weller WD1 soldering station. The unit, sporting the familiar light blue Weller livery and more than a few scratches and dings, had an LCD that was DOA. Typically it’s the driver that’s the problem here, but [Lauri]’s diagnosis revealed it was the LCD module itself that was bad.

With OEM replacements being basically unobtainium at this point, the fix was to intercept the data heading from the driver to the old LCD and send it to a new, easily sourced 16×2 character LCD display. This began with an inspection of the display controller’s datasheet, and a bit of probing of the old display to find out which segments and backplanes map to which pins. A little bit of case modding allowed the new display to fit, the old controller chip was removed, and a PIC16 went into its place, in a tidy nest of Kapton tape and bodge wires. The PIC does the job of translating the original display, which had a fair number of custom icons and symbols, into sensible text-based equivalents and sending them to the 16×2 via I2C. The video below shows the hack in action; it honestly looks like it could have come from the factory like that.

The nice thing here is that [Lauri]’s fix applies to a whole range of Weller stations, so if you find one in the trash, you might be able to resuscitate it. Failing that, you could always roll your own Weller from (more-or-less) scratch.

Continue reading “Reverse Engineering Saves Weller With A Wonky LCD From The Trash Pile”

Hackaday Links Column Banner

Hackaday Links: December 25, 2022

Looks like it’s lights out on Mars for the InSight lander. The solar-powered lander’s last selfie, sent back in April, showed a thick layer of dust covering everything, including the large circular solar panels needed to power the craft. At the time, NASA warned that InSight would probably give up the ghost sometime before the end of the year, and it looks like InSight is sticking to that schedule. InSight sent back what might be its last picture recently, showing the SEIS seismic package deployed on the regolith alongside the failed HP3 “mole” experiment, which failed to burrow into the soil as planned. But one bad experiment does not a failed mission make — it was wildly successful at most everything it was sent there to do, including documenting the largest marsquake ever recorded. As it usually does, NASA has anthropomorphized InSight with bittersweet sentiments like “Don’t cry, I had a good life,” and we’re not quite sure how we feel about that. On the one hand, it kind of trivializes the engineering and scientific accomplishments of the mission, but then again, it seems to engage the public, so in the final rinse, it’s probably mostly harmless.

Continue reading “Hackaday Links: December 25, 2022”

Self-Propelled Chainsaw Reduces Injuries

[Advoko] is an expert at milling logs into various sizes of boards. He typically uses nothing but a chainsaw to enable him to mill on-site without needing to bring any large or expensive equipment. The only problem is that sometimes he gets a little carried away running his mill non-stop until he has enough lumber for whatever project he is building, which has led to some repetitive strain injuries. To enable him to continue to run his mill, he’s created this self-propelled chainsaw jig.

The creation of the self-propelled chainsaw was a little serendipitous. [Advoko] needed to mill a tree which had fallen on a slope, and he couldn’t move the large trunk before starting to mill. To avoid fatigue while pulling his chainsaw upwards, he devised a system of rubber belts that would help pull the weight of the chainsaw up the hill. Noticing that if the chainsaw could have been operated downhill, it would essentially pull itself along the cut, he set about building a carriage for the mill to hold the chainsaw in place while it semi-autonomously milled lumber for him.

The chainsaw jig isn’t fully autonomous; [Advoko] still needs to start and stop the chainsaw and set up the jig. It does have a number of safety features to prevent damage to the jig, the chainsaw, and himself too, and over a number of iterations of this device he has perfected it to the point where he can start it on a cut and then do other tasks such as move boards or set up other logs for cutting while it is running, saving him both time and reducing his risk of other repetitive strain injuries. If you don’t fully trust the automatic chainsaw jig, take a look at this one which requires a little more human effort but still significantly reduces the strain of milling a large log.

Continue reading “Self-Propelled Chainsaw Reduces Injuries”

Three purple OshPark boards and a white bread board all attached using a number of jumper wires on a grey cutting mat.

An (Almost) Single-Chip Apple IIe

The Apple II is one of the most iconic microcomputers, and [James Lewis] decided to use the Mega-II “Apple IIe on a chip” from an Apple IIgs to build a tiny Apple IIe.

While there was an Apple II compatibility card using the related Gemini chip, it was initially unclear whether the Mega-II could even work outside of an Apple IIgs given the lack of documentation for either Apple II SOC. [Lewis] did finally get the Mega-II to boot after a great deal of effort in debugging and design. The system is built with three boards: the Mega-II and RAM board, a CPU board with a 65C02, and a video out board.

To simplify routing, the boards are all four layer PCBs. Unfortunately, the chips needed to make this system, especially the Mega-II, aren’t available on their own and must be harvested from an existing IIgs. [Lewis] took care to make sure any desoldering or other part removal was done in a way that it could be reversed. If you want to see all the nitty gritty details, check out his GitHub for the project.

If you want another 6502-based computer in a tiny package, why not try this one built on Perf+ boards?

Continue reading “An (Almost) Single-Chip Apple IIe”

Your Next Airport Meal May Be Delivered By Robot

Robot delivery has long been touted as a game-changing technology of the future. However, it still hasn’t cracked the big time. Drones still aren’t airdropping packages into our gutters by accident, nor are our pizzas brought to us via self-driving cars.

That’s not to say that able minds aren’t working on the problem. In one case, a group of engineers are working ton a robot that will handle the crucial duty of delivering food to hungry flyers at the airport.

Continue reading “Your Next Airport Meal May Be Delivered By Robot”

Working With I2S-Compatible FM Tuners

While the Internet is a great place to get access to any music or audio you can dream of, there’s still a place for broadcast radio. [mit41301] has recently been exploring implementing a simple FM tuner chip in various projects.

The chip in question is the RDA7088, which is designed to require the bare minimum in external components, and is available in a compact SOP16 package. As per the datasheet, it was intended for use in applications like portable radios, PDAs, cell phones, and MP3 players.

[mit41301]’s first attempt involved using the chip as a simple tuner, hooked up to a PIC10F200 for control. Investigation revealed it was capable of outputting digital audio via I2S, while being commanded via I2C. By default, it spits out audio at a low sample rate of 8 kHz, but reconfiguration will jump that up to 44.1 or 48 kHz. Piping that digital I2S stream out to a DAC then delivers analog output that can be fed to an amplifier. The build also got remote control, with the PIC handling decoding IR signals and outputting commands to the radio chip.

Following this success, [mit41301] then went further, hooking up an ESP-01 to the chip to try and get RDS going. If you’re unfamiliar with the Radio Data System, it’s a way for short textual messages to be sent out by FM broadcasters. In addition to the duties carried out by the PIC module, the ESP-01 is also charged with receiving RDS data from the RDA7088, and outputting it to a display.

While using such chips is routine in industry, it’s always great to see a DIY guide to interfacing with specific hardware. If you want to integrate FM radio into your own projects, the RDA7088 is a simple and easy way to do so. We’ve seen similar work before, adding FM radio to the Raspberry Pi.

Continue reading “Working With I2S-Compatible FM Tuners”

This Week In Security: GitHub Actions, SHA-1 Retirement, And A Self-Worming Vulnerability

It should be no surprise that running untrusted code in a GitHub Actions workflow can have unintended consequences. It’s a killer feature, to automatically run through a code test suite whenever a pull request is opened. But that pull request is run in some part of the target’s development environment, and there’s been a few clever attacks found over the years that take advantage of that. There’s now another one, what Legit Security calls Github Environment Injection, and there were some big-name organizations vulnerable to it.

The crux of the issue is the $GITHUB_ENV file, which contains environment variables to be set in the Actions environment. Individual variables get added to this file as part of the automated action, and that process needs to include some sanitization of data. Otherwise, an attacker can send an environment variable that includes a newline and completely unintended environment variable. And an unintended, arbitrary environment variable is game over for the security of the workflow. The example uses the NODE_OPTIONS variable to dump the entire environment to an accessible output. Any API keys or other secrets are revealed.

This particular attack was reported to GitHub, but there isn’t a practical way to fix it architecturally. So it’s up to individual projects to be very careful about writing untrusted data into the $GITHUB_ENV file.

Continue reading “This Week In Security: GitHub Actions, SHA-1 Retirement, And A Self-Worming Vulnerability”