We would have enjoyed [Harishankar’s] tear down of a robot vacuum cleaner, even if it didn’t have a savage twist at the end. Turns out, the company deliberately bricked his smart vacuum.
Like many of us, [Harishankar] is suspicious of devices beaming data back to their makers. He noted a new vacuum cleaner was pinging a few IP address, including one that was spitting out logging or telemetry data frequently. Of course, he had the ability to block the IP address which he did. End of story, right?
No. After a few days of working perfectly, the robot wouldn’t turn on. He returned it under warranty, but the company declared it worked fine. They returned it and, indeed, it was working. A few days later, it quit again. This started a cycle of returning the device where it would work, it would come home and work for a few days, then quit again.
You can probably guess where this is going, but to be fair, we gave you a big hint. The fact that it would work for days after blocking the IP address wouldn’t seem like a smoking gun in real time.
The counter wheel and white worm gear inside the counter. (Credit: Anthony Francis-Jones, YouTube)
Recently [Anthony Francis-Jones] decided to take a closer look at the inhaler that his son got prescribed for some mild breathing issues, specifically to teardown the mechanical counter on it. Commonly used with COPD conditions as well as asthma, these inhalers are designed to provide the person using it with an exact dose of medication that helps to relax the muscles of the airways. Considering the somewhat crucial nature of this in the case of extreme forms of COPD, the mechanical counter that existed on older versions of these inhalers is very helpful to know how many doses you have left.
Disassembling the inhaler is very easy, with the counter section easily extracted and further disassembled. The mechanism is both ingenious and simple, featuring the counter wheel that’s driven by a worm gear, itself engaged by a ratcheting mechanism that’s progressed every time the cylinder with the medication is pushed down against a metal spring.
After the counter wheel hits the 0 mark, a plastic tab prevents it from spinning any further, so that you know for certain that the medication has run out. In the video [Anthony] speculates that the newer, counter-less inhalers that they got with the latest prescription can perhaps be harvested for their medication cylinder to refill the old inhaler, followed by resetting the mechanical counter. Of course, this should absolutely not be taken as medical advice.
The Zynq-7000 usage at the core of the robot controller. (Credit: Excessive Overkill, YouTube)
Industrial robots like robotic arms are basically everywhere, albeit usually out of the public’s eye in factories. This also means that they get replaced and scrapped all the time, making for many opportunities to snap up an industrial robot that once cost as much as a pretty fancy car for essentially peanuts. Over the years the bloke behind the [Excessive Overkill] YouTube channel did this a lot, which also revealed the main issue with these ‘cheap’ robots: the electronics and associated software, with the manufacturer rarely going out of their way to appease to hobbyists trying to fix up one of these units, never mind for free.
That said, if you’re persistent enough, you can reverse-engineer these beasts to the point where you can develop your own controller hardware and software solution. This is exactly what was done, resulting in an open source controller, found on the ExcessiveMotion GitHub page, that should allow you to control many of these industrial robots. At the core is a Zynq-7000 hybrid FPGA-ARM SoC chip, running real-time Linux (with preemptive scheduling patch) on the SoC side and custom HDL on the FPGA side to handle the hard real-time tasks.
The controller during testing. (Credit: Excessive Overkill, YouTube)
The controller is made to be modular, with a backplane that can accept various interface cards in addition to the current RS-485 and RS-422 interfaces that are commonly used in industrial settings, such as here for controlling the individual servo drives of the robots. To make assembly and testing interesting, the first controller and integration with a robot was made ready for display at the Open Sauce 2025 event, requiring things to be rushed along, including reverse-engineering the servo protocol for a small-ish industrial robot suitable for public display and use, as well as developing the kinematics for the robotic arm.
With the controller now demonstrated, clearly this is the perfect time to rush out and get one of these fun industrial robots for a few hundred bucks. Currently the controller is still being finalized, with the author asking for feedback on what it should be able to support. If you have a particularly unusual industrial robot lounging around without the requisite controller, this might be your chance to revive it.
Theoretically USB-C is a pretty nifty connector, but the reality is that it mostly provides many exciting new ways to make your device not work as expected. With the gory details covered by [Alvaro], the latest to join the party is Segger, with its J-Link BASE Compact MCU debugger displaying the same behavior which we saw back when the Raspberry Pi 4 was released in 2019. Back then so-called e-marked USB-C cables failed to power the SBC, much like how this particular J-Link unit refuses to power up when connected using one of those special USB-C cables.
We covered the issue in great detail back then, discussing how the CC1 and CC1 connections need to be wired up correctly with appropriate resistors in order for the USB-C supply – like a host PC – to provide power to the device. As [Alvaro] discovered through some investigation, this unit made basically the same mistake as the RPi 4B SBC before the corrected design. This involves wiring CC1 and CC2 together and as a result seeing the same <1 kOhm resistance on the active CC line, meaning that to the host device you just hooked up a USB-C audio dongle, which obviously shouldn’t be supplied with power.
Although it’s not easy to tell when this particular J-Link device was produced, the PCB notes its revision as v12.1, so presumably it’s not the first rodeo for this general design, and the product page already shows a different label than for the device that [Alvaro] has. It’s possible that it originally was sloppily converted from a previous micro-USB-powered design where CC lines do not exist and things Just Work™, but it’s still a pretty major oversight from what should be a reputable brand selling a device that costs €400 + VAT, rather than a reputable brand selling a <$100 SBC.
For any in the audience who have one of these USB-C-powered debuggers, does yours work with e-marked cables, and what is the revision and/or purchase date?
Perpetual motion devices are either a gag, a scam, or as in the case of this particular toy that [Big Clive] bought on AliExpress, a rather fascinating demonstration of a contact-free inductive sensor combined with a pulsed magnet boost for the metal ball. A cool part about the device is that it comes with a completely clear enclosure, so you can admire its internals while it’s operating. Less cool was that after unboxing the device wasn’t working as the detector wasn’t getting the 12 V it needs to operate, requiring a bit of repairing first.
The crucial part of the perpetual motion device schematic with the sensor, MCU and coil. (Credit: bigclivedotcom, YouTube)
Based on the label on the bottom of the device with the creative model identifier P-toy-002, its standby current is 10 µA which ramps up to 3 A when it’s operating. This makes sense when you look at the two core components: the industrial inductive detector, and a rather big electromagnet that’s driven by a bank of three 10 mF, 35V capacitors, turning it into something akin to a coilgun. Annoyingly, an attempt was made to erase most of the IC package markings.
The circuitry isn’t too complex, fortunately, with an adjustable electromagnet coil voltage circuit combined with a MOSFET to provide the pulse, and a 78L12 regulator to generate the 12 VDC from the coil’s voltage rail for the sensor that is monitored by a MCU.
The PIXO Aspire is a roughly $35 USD vape that can almost play DOOM, with [Aaron Christophel] finding that the only thing that realistically stops it from doing so is that the Cortex-M4-based Puya PY32F403XC MCU only has 64 kB of SRAM. CPU-wise it would be more than capable, with a roomy 16 MB of external SPI Flash and a 323×173 pixel LC touch screen display covering the other needs. It even has a vibration motor to give you some force feedback. Interestingly, this vape has a Bluetooth Low-Energy chip built-in, but this does not seem to be used by the original Aspire firmware.
What [Aaron] did to still get some DOOM vapors on the device was to implement a screenshare firmware, allowing a PC to use the device as a secondary display via its USB interface. This way you can use the regular PC mouse and keyboard inputs to play DOOM, while squinting at the small screen.
Although not as completely overpowered as a recent Anker charging station that [Aaron] played DOOM on, we fully expect vapes in a few years to be perfectly usable for some casual gaming, with this potentially even becoming an original manufacturer’s function, if it isn’t already.
For the past years people have been collecting disposable vapes primarily for their lithium-ion batteries, but as these disposable vapes have begun to incorporate more elaborate electronics, these too have become an interesting target for reusability. To prove the point of how capable these electronics have become, [BogdanTheGeek] decided to turn one of these vapes into a webserver, appropriately called the vapeserver.
While tearing apart some of the fancier adult pacifiers, [Bogdan] discovered that a number of them feature Puya MCUs, which is a name that some of our esteemed readers may recognize from ‘cheapest MCU’ articles. The target vape has a Puya PY32F002B MCU, which comes with a Cortex-M0+ core at 24 MHz, 3 kB SRAM and 24 kB of Flash. All of which now counts as ‘disposable’ in 2025, it would appear.
Even with a fairly perky MCU, running a webserver with these specs would seem to be a fool’s errand. Getting around the limited hardware involved using the uIP TCP/IP stack, and using SLIP (Serial Line Internet Protocol), along with semihosting to create a serial device that the OS can use like one would a modem and create a visible IP address with the webserver.
The URL to the vapeserver is contained in the article and on the GitHub project page, but out of respect for not melting it down with an unintended DDoS, it isn’t linked here. You are of course totally free to replicate the effort on a disposable adult pacifier of your choice, or other compatible MCU.
