Generally people equate the Arduino hardware platforms with MCU-centric options that are great for things like low-powered embedded computing, but less for running desktop operating systems. This looks about to change with the Arduino Uno Q, which keeps the familiar Uno formfactor, but features both a single-core Cortex-M33 STM32U575 MCU and a quad-core Cortex-A53 Qualcomm Dragonwing QRB2210 SoC.
According to the store page the board will ship starting October 24, with the price being $44 USD. This gets you a board with the aforementioned SoC and MCU, as well as 2 GB of LPDDR4 and 16 GB of eMMC. There’s also a WiFi and Bluetooth module present, which can be used with whatever OS you decide to install on the Qualcomm SoC.
This new product comes right on the heels of Arduino being acquired by Qualcomm. Whether the Uno Q is a worthy purchase mostly depends on what you intend to use the board for, with the SoC’s I/O going via a single USB-C connector which is also used for its power supply. This means that a USB-C expansion hub is basically required if you want to have video output, additional USB connectors, etc. If you wish to run a headless OS install this would of course be much less of a concern.
After the news cycle recently exploded with the announcement that Google would require every single Android app to be from a registered and verified developer, while killing third-party app stores and sideloading in the process, Google has now tried to put out some of the fires with a new Q&A blog post and a video discussion (also embedded below).
When we first covered the news, all that was known for certain was the schedule, with the first trials beginning in October of 2025 before a larger rollout the next year. One of the main questions pertained to installing apps from sources that are not the Google Play Store. The answer here is that the only way to install an app without requiring one to go through the developer verification process is by installing the app with the Android Debug Bridge, or adb for short.
The upcoming major release of Android 16 will feature a new process called the Android Developer Verifier, which will maintain a local cache of popular verified apps. The remaining ones will require a call back to the Google mothership where the full database will be maintained. In order to be a verified Android developer you must have a Google Play account, pay the $25 fee and send Google a scan of your government-provided ID. This doesn’t mean that you cannot also distribute your app also via F-Droid, it does however mean that you need to be a registered Play Store developer, negating many of the benefits of those third-party app stores.
Although Google states that they will also introduce a ‘free developer account type’, this will only allow your app to be installed on a limited number of devices, without providing an exact number so far. Effectively this would leave having users install unsigned APKs via the adb tool as the sole way to circumvent the new system once it is fully rolled out by 2027. On an unrelated note, Google’s blog post also is soliciting feedback from the public on these changes.
For those who missed out on the past few years of ‘smart home’ gadgets, the Logitech POP buttons were introduced in 2018 as a way to control smart home devices using these buttons and a central hub. After a few years of Logitech gradually turning off features on this $100+ system, it seems that Logitech will turn off the lights in two weeks from now. Remaining POP Button users are getting emails from Logitech in which they are informed of the shutdown on October 15 of 2025, along with a 15% off coupon code for the Logitech store.
Along with this coupon code only being usable for US-based customers, this move appears to disable the hub and with it any interactions with smart home systems like Apple HomeKit, Sonos, IFTTT and Philips Hue. If Logitech’s claim in the email that the buttons and connected hub will ‘lose all functionality’, then it’d shatter the hopes for those who had hoped to keep using these buttons in a local fashion.
Suffice it to say that this is a sudden and rather customer-hostile move by Logitech. Whether the hub can be made to work in a local fashion remains to be seen. At first glance there don’t seem to be any options for this, and it’s rather frustrating that Logitech doesn’t seem to be interested in the goodwill that it would generate to enable this option.
It takes quite a bit of effort to get a 0 out of 10 repairability score from iFixit, but in-ears like Apple’s AirPods are well on course for a clean streak there, with the AirPod Pro 3 making an abysmal showing in their vitriolic teardown video alongside their summary article. The conclusion is that while they are really well-engineered devices with a good feature set, the moment the battery wears out it is effectively e-waste. The inability to open them without causing at least some level of cosmetic damage is bad, and that’s before trying to glue the device back together. Never mind effecting any repairs beyond this.
Worse is that this glued-together nightmare continues with the charging case. Although you’d expect to be able to disassemble this case for a battery swap, it too is glued shut to the point where a non-destructive entry is basically impossible. As iFixit rightfully points out, there are plenty of examples of how to do it better, like the Fairbuds in-ears. We have seen other in-ears in the past that can have some maintenance performed without having to resort to violence, which makes Apple’s decisions here seem to be on purpose.
Although in the comments to the video there seem to be plenty of happy AirPod users for whom the expected 2-3 year lifespan is no objection, it’s clear that the AirPods are still getting zero love from the iFixit folk.
The idea of using the Apple II home computer for digital photography purposes may seem somewhat daft considering that this is not a purpose that they were ever designed for, yet this is the goal that [Colin Leroy-Mira] had, requiring some image decoder optimizations. That said, it’s less crazy than one might assume at first glance, considering that the Apple II was manufactured until 1993, while the Apple QuickTake digital cameras that [Colin] wanted to use for his nefarious purposes saw their first release in 1994.
These QuickTake cameras feature an astounding image resolution of up to 640×480, using 24-bit color. Using the official QuickTake software for Apple Macintosh System 7 through 9 the photographs in proprietary QTK format could be fetched for display and processing. Doing the same on an Apple II would obviously require a bit more work, not to mention adapting of the image to the limitations of the 8-bit Apple II compared to the Motorola 68K and PowerPC-based Macs that the QuickTake was designed to be used with.
Targeting the typical ~1 MHz 6502 CPU in an Apple II, the dcraw QTK decoder formed the basis for an initial decoder. Many memory and buffer optimizations later, an early conversion to monochrome and various other tweaks later – including a conversion to 6502 ASM for speed reasons – the decoder as it stands today manages to decode and render a QTK image in about a minute, compared to well over an hour previously.
Considering how anemic the Apple II is compared to even a budget Macintosh Classic II system, it’s amazing that displaying bitmap images works at all, though [Colin] reckons that more optimizations are possible.
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.
