Built-in batteries put a timebomb inside devices, with especially the calendar aging feature of Li-ion chemistries setting a hard limit on when you’ll have to toss the device or figure out a way to replace the battery somehow. Here the EU’s Battery Regulation policy with the 2027 implementation of the user-serviceable battery requirement provided a lot of hope. Now six new categories of exemptions are diminishing what could have been a bonanza of easy repairability.
Most notable here are smartwatches, fitness trackers, wireless earbuds and other so-called ‘wet devices’, which as GSMArena also notes is an area where having a user-replaceable battery might affect features like being water-resistant. Something which is also relevant for e.g. outdoor wireless speakers. There’s also a new exemption for smartphones, where if its battery retains at least 83% of its original capacity after 500 charge cycles, battery replacement has to be only replaceable by professionals. Which is probably code for ‘glue, hotplates and prying tools’.
Considering just how daft of an idea built-in batteries are, this is somewhat disappointing to see. While it’s understandable that ‘wet devices’ get such broad exemptions, it should be noted here that advanced technologies like gaskets are neither complicated nor expensive. You can even hand the average user a tube of RTV silicone and let them go to town on a part in the happy knowledge that there’s never such a thing as ‘too much’ RTV silicone.
It is likely that there was some pressure from the industry on the EU to not change too much, but at the very least us happy few in the EU will be getting a new Nintendo Switch 2 with easily replaced battery in both the main unit and its controllers. For the average rechargeable device you keep kicking around the house this should also still apply as long as its manufacturer cannot squeeze it into one of these exemption categories.
Some breaking news from geostationary orbit, as the National Oceanic and Atmospheric Administration (NOAA) has announced that its newest Geostationary Operational Environmental Satellite (GOES) satellite unexpectedly went offline last night, and as of this morning, remains stuck in safe mode.
Launched in June of 2024, GOES-19 is one of four operational weather satellites that NOAA operates to provide forecast data and severe weather monitoring for the entire Western Hemisphere. The satellite is specifically responsible for covering the continental United States, Central and South America, as well as the Atlantic Ocean. This makes it a particularly critical asset even under normal circumstances, but the fact that it’s gone blind during the Atlantic hurricane season and while smoke from the raging Canadian wildfires is drifting over the Northeast and making the skies over Boston and New York City look like Mars is something of a worst-case scenario.
The good news is that two of the four satellites operate as orbital spares — the satellite that GOES-19 replaced in 2024, GOES-16, is still operational and can stand in as a backup for its coverage area. Obviously, it’s quite a bit older, having launched back in 2016, but it’s of the same design as GOES-19, and in good health, so there should be no degradation of service.
Still, getting GOES-19 back online will be critical for NOAA and the National Weather Service, and we expect they’ll be providing regular updates as the situation develops. Stay tuned.
If you have even the slightest interest in open hardware e-readers, you’ve certainly heard of [Joey Castillo]’s Open Book project. We’ve covered his efforts to develop an affordable reader that delivers a Kindle-like experience without the Orwellian megacorp trappings for several years now, and watched with great interest as the core hardware has evolved.
So we were particularly excited over the weekend to see the Open Book Touch finally hit Crowd Supply, and judging by the fact that the campaign for the $149 device has already blown past 60% of its funding goal in just a few days, it seems like we weren’t the only ones.
As the name implies, this latest iteration of the e-reader does away with physical navigation buttons and introduces an intuitive touch-based interface. Those who like to enjoy their open source hardware under the covers will be glad to hear that not only does this new version of the Open Book finally include an illuminated display, but it even allows you to adjust the color temperature and brightness of the LEDs with the swipe of a finger.
While the hardware improvements over the previous Open Book are impressive, the software has really come a long way as well. The user interface lets you organize your books on virtual shelves and browse through their covers, providing the sort of slick experience that you’d expect from a modern e-reader. You can also look up the definitions of words, or dog-ear favorite pages so you can return to them later.
But what you won’t get is locked down with DRM — the Open Book Touch uses standard EPUB and TXT files loaded from a micro SD card, and thanks to the WiFi-enabled ESP32 at its heart, it offers up a web interface that lets you manage your collection over the network.
It’s been nearly a decade since the Open Book first graced our pages, and though we’re not in the habit of picking favorites here at Hackaday, this is one project where the stakes are so high that we can’t help but feel invested. Reading shouldn’t require a subscription fee, or depend on a proprietary piece of hardware that can get ejected from its own ecosystem once its maker decides you need a new one. Obviously the Open Book Touch won’t even make a dent in the market share that Amazon’s Kindle enjoys, at least there will be an option available for those who wish to keep reading on their own terms.
We are absolutely stoked to announce that the Hackaday Superconference is taking place this year November 6th through 8th in glorious Pasadena California, and we want to see you there!
If you’ve been to any of the previous nine Supercons, you know that it’s a fantastic gathering of the most motivated and interesting hackers around — but it’s also been a relatively small gathering. And while we love the very high signal-to-noise ratio of folks who show up, we’re always a little bit sad when the tickets sell out because it represents hackers who couldn’t be there.
So this year, we’re celebrating Supercon Ten by expanding out of our traditional location at the Design Lab so that we can accommodate 20% more hackers, while still keeping the cosy nature of the event intact. So if you’ve been wanting to come to Supercon, but procrastinated the ticket sales every year, this year is looking 20% better.
Call for Proposals
If you want to give a talk to an interested audience of hackers just like you, now is your chance. Fill out the Call for Participation form before Wednesday, Aug 12th to put your hat in the ring. Presenters not only get to share their work with a like-minded audience, but they get in the door free! Presenting really is the best way to attend a conference like this – it’s the ultimate ice-breaker. (Plus, did we mention free?)
We will have two tracks of talks on two stages, and both are a mix of shorter 20-minute talks and longer 40-minute sessions, so whatever the size of your ideas, we have the slot for you. As always, we like to hear about your projects: hardware, software, creation, destruction, or anything in-between. In short, if you have a talk that would interest the readers of Hackaday, it fits. Check out last year’s slate if you’re curious, but bear in mind that we like to see new stuff, so don’t feel constrained by precedent. If you’re into it, there’s a good chance that many of us are too!
All you need is an abstract, a title, and a solid general idea of how the talk is going to go. First time speaker, or grizzled veteran: get your proposal in now.
Plus ça Change…
Supercon Ten starts out as usual with a casual badge-hacking day at Supplyframe HQ on the morning of Friday Nov 6th. We love this day because there’s “nothing” to do! It’s the perfect way to ease into the conference: the doors open, and the food and coffee starts flowing. As the solder melts, brought-along hacks get demoed, friendships form, and plans get hatched. We go on well into the night, with music and festivities to keep you motivated or distracted – the choice is yours.
Saturday and Sunday are chock-full of talks, workshops, challenges, and other events. This year, we’ll be a few blocks south at the ArtCenter South Campus, which means that we’ll be relocating our traditional back-alley ambiance to significantly fancier digs. But of course, we’ll have space for hacking, mingling, and watching the talks.
Sunday evening comes too soon, and at the end of this second day of talks, we’ll let you showcase all of the badge hacks that you’ve been working on before spilling out into the town and falling far too late into bed.
Just because enough is never enough, we’ll probably also meet up informally sometime Thursday night if you’re already in town. And if you’re able to finagle a half-day Monday into your schedule, you’ll find that a bunch of folks have off-schedule side trips that are always popular.
Get Excited!
We know that we’re announcing late this year. The new venue, combined with a late Hackaday Europe, made for a lot more planning to be done. But now that all of our ducks are in a row, we’re very much looking forward to November. And of course, we can’t wait to see what you all are going to bring with you to Supercon. After all, it’s the Hackaday community that makes it great.
Get your talk proposals in now, and in the next few weeks, we’ll open up ticket pre-sales. Tell your friends, neglect to mention it to your enemies, and start making your Supercon plans today.
As good as a desktop OS may be, at some point it has to feature accelerated 3D graphics. This has been a bit of a sticking point for Haiku OS, as none of the big names in GPU cards are likely to start putting out drivers for this OS any time soon. Fortunately there is the Linux open source driver code from Nvidia that can be used as a jumping-off point for a port, which is what [X512] and the community over at the Haiku forums did over the course of more than a year.
In a recent video [Action Retro] takes a poke at the fruits of these efforts, trying out the driver with an RTX2070 Super GPU. Of note is that this driver requires the GSP (GPU System Processor) controller that got added by Nvidia with the Turing series of GPUs, meaning that you need at least a GTX16 or RTX20 series card.
You can get an installation package from the GitHub repository, such as for the v0.0.2 pre-release that was created in January of 2026. In this pre-release state quite a few things are working, with the ability to play 3D games at a reasonable FPS being the biggest improvement over plain VESA mode. Features like CUDA are not available as they’re not in the open sourced section, of course.
In the [Action Retro] video the whole installation process is demonstrated, starting with a fresh nightly Haiku build. First the gaming performance in software-rendered VESA mode is demonstrated before the GPU driver is installed. This shows a marked improvement in performance, although Minecraft needs to be updated for the newest Mesa library that omits OSMesa, so that couldn’t be tested. Overall it shows that Haiku has made another massive leap forward in becoming a viable daily driver OS.
Meanwhile, over on the ReactOS side of things we just saw a Half-Life 2 playthrough by [Aotori Hibiki], on an Intel Sandy Bridge PC with GeForce 8400GS graphics. Here ReactOS has the advantage of being Windows NT-compatible, including WDDM-style GPU drivers, allowing it to use the same drivers as Windows. Simultaneously, ReactOS is now implementing its first NT6 kernel API calls to make it compatible with modern (Vista+) Windows.
The upshot here is that for people who want to daily drive an open source OS with all the creature comforts imaginable, things have never seemed more promising. Especially for people who don’t want Yet Another Linux Distro but just an utterly boring desktop-centric, single-user focused OS that Just Works these are great tidings.
Vehicles long ago began to incorporate electronics and software, to the point that modern vehicles increasingly have a sort of architecture problem. The software end of things evolves ever more rapidly, but vehicles and their centralized architecture are poorly-suited to continuous updates. As a result, the automotive industry is moving away from static, hardware-defined designs and more toward dynamic, software-defined platforms. In short, the era of software-defined vehicles looms nearer every year.
There are very good reasons vehicles are the way they are, however inconvenient it may be for pushing updates. A vehicle may be in service for decades, with safety and reliability a prime concern over that lifetime. Reflecting this, automobiles are built around centralized SoCs (System-on-a-Chip) supported by tried and true components and assemblies. As mentioned, this architecture isn’t terribly well suited to meshing with a rapidly evolving software world that may also have changing computing needs. How can one accommodate this without increasing safety risks?
Some new designs are moving away from monolithic SoCs to more modular systems; ones that can support and optimize safety-critical functions and other workloads independently. Computing requirements are chosen to prioritize consistent performance and low-latency sensor fusion over raw processing power, and modern design focuses less on individual components and more on integrated hardware and software assemblies that ease manufacture and reduce design complexity.
The main goal is to design vehicles in a way that can more easily take advantage of rapid developments in software and allow easy updates, without compromising safety or reliability. Automakers haven’t completely settled on what architecture will do this best, but the era of software-defined vehicles is certainly coming closer.
Flight sims are wonderful to play around with to get immersed in the position of a pilot. Racing sims can give you a thrill that can only be beaten by the real thing. However, most of this tech is on the more expensive side, so it would be great if you could use some of the hardware already found in your house. Many Sony headphones already have rotation and movement data built in for spatial audio, so why not start there?
[Nicholas Slattery] had this very idea and has produced an open-source application to connect your headphones straight to your sim. There’s a surprising amount of support built into many headsets that use a known protocol called the Android Head Tracker HID protocol. This allowed [Nicholas] to connect a family of Sony headphones straight into OpenTrack, which is often used with flight sims. The best part is you can still use the headphones as normal with a Bluetooth connection.
If you want to give this a try with your own rig, check out [Nicholas]’s GitHub here. While flight and driving sims might be expensive to put together, it’s never too hard to hack together something to lower that barrier! Whether it’s a flight sim force-feedback joystick or driving sim hand-breaks we got you!
Like so many large and popular open source projects these days, the Godot game engine struggles with an influx of pull requests. The situation has become increasingly dire due to the advent of AI-generated code. More specifically, the issue involves the inverse relationship between PR code quality and the number of PRs, which wastes a lot of time on the side of a limited number of (volunteer) reviewers. This has now forced the project to update its contribution policy.
An interesting point raised in the announcement article is that of the demoralizing effect of AI-generated PRs on reviewers. Often the human behind such a PR isn’t interested in being educated, or may even be an automated agent which isn’t capable of productive discussion on pros and cons of certain coding approaches — never mind in becoming a more permanent maintainer for the project.
This problem has led to new rules being instated, which include a ban on autonomous AI agents and vibe coding, a ban on substantial AI generating of code, and a ban on AI-generated text in human-to-human communication. It also codifies the requirement that all PRs are to be reviewed and approved by a human being before merging.
Meanwhile there are also indications that such ‘AI tool’ usage is reducing useful interactions with open source projects. What the future will bring here remains to be seen, but at least as far as open source projects go these tools are clearly increasingly being banished.
Last September, Denmark was gripped by a spate of drone sightings near airports. It’s familiar territory for Hackaday, as we reported on a similar drone panic saga at British airports back in the last decade. Back then the British police dragged their feet and hid behind secrecy laws for years to avoid admitting they overreacted, but it seems in Denmark they do things differently (Danish language, Google Translate link.).
The Danish police in Jutland have rolled back their report, and noted that a reported observation alone is not enough to confirm a drone was present. It’s not confirmed why they’ve taken this step, but we’ve been told that there’s been an effort within the drone community to identify possible aircraft flight paths which could have resulted in a false drone sighting at the times in question.
We welcome this correction, and hope that its important message travels widely. Of course it is the right thing to do for a police force to take drone reports seriously, but overreacting as the British police did is of little help. We commend the Danish police for taking this step, and we’re likely to trust any drone reports from them a little bit more in the future. If you’d like to read our plea for a sensible response at the time, it’s here.
When you’re driving your car, you’re probably regularly looking at the speedometer to make sure you comply with the local speed limits. The method by which it works is simple enough: the rotation of the wheels is sent mechanically via a cable to a dial on the dash, or an electronic sensor counts the rotations of the drivetrain and an electronically-controlled needle or display shows the speed.
But what about if you were in an aircraft, and the wheels had nothing to do with how fast you were going? How would you even begin to measure speed? There are two ways: there’s a convenient solution to this problem rooted in simple fluid mechanics, and a far-more-complex modern solution. Today, we’ll explore how planes and helicopters are able to figure out how fast they’re going, by the old ways and the new.
Classical Methods
Measuring airspeed can be achieved by measuring stagnation pressure with a pitot tube, and comparing this to static pressure. This can be done at different points on the aircraft, or a pitot-static tube can be used, which measures both stagnation pressure and static pressure in a single probe. Credit: Chaos386, CC BY-SA 3.0
A key thing most aviators want to know is how fast their aircraft is going. Specifically, it’s nice to know how fast it’s moving relative to the airstream around it, which is referred to as airspeed. This is important, because it’s the aircraft’s velocity relative to the flow, such as wind, that determines the performance of the airfoils, how much lift is generated, and whether or not the aircraft is approaching a stall condition where it might fall out of the sky.
Bernoulli’s equation, rearranged to find airspeed (u), by subtracting static pressure from stagnation pressure, multiplying it by 2, dividing by fluid density, and taking the square root of that result.
Measuring airspeed is most commonly achieved with the use of a device called a Pitot tube. The pitot tube is a tube with a hole in one end that points directly into the airflow in the direction of travel of the aircraft.
As air flows in, it reaches a dead end and the flow slows to a stop, or stagnates, since it has nowhere to go. This allows a pressure sensor or a manometer or other device to measure the stagnation pressure at this point. The stagnation pressure measurement is related to the flowspeed of the incoming air since the kinetic energy of the flow is converted to pressure as the flow comes to a halt.
A secondary tube, pointing perpendicular to the airflow, is then used to measure the static pressure of the surrounding air, without the ram effect of the air being forced in by the aircraft’s forward motion. Then, it’s possible to calculate the velocity of the aircraft relative to the airstream by plugging the stagnation pressure and static pressure into a rearranged Bernoulli’s equation. If the pitot tube and static tube are hooked up to electronic sensors, the airspeed can be calculated electronically, and fed to a display or digital gauge.
A classic airspeed indicator has the pitot tube and static tube feeding right into the gauge in the cockpit. The pressure differential causes the diaphragm to expand as the airspeed increases, which mvoes a mechanism causing the needle to move on the gauge. Credit: FAA, public domain
Alternatively, it’s possible to effectively do this “calculation” mechanically. In earlier days, static and stagnation pressure captured by each tube would be fed to a gauge. Inside, the stagnation pressure would be fed to a diaphragm which moved due to the difference relative to the static pressure which is fed into the gauge body, and the movement of the diaphragm would, via a simple mechanism, shift the needle on the gauge.
A small General Aviation aircraft might mount a single pitot tube on the aircraft, feeding the air speed instrument in the cockpit. Commercial aircraft might mount two or more for safety’s sake, in case one becomes inoperable, while large airliners may have four or even more to provide a high level of redundancy and error checking. Heaters are commonly included on pitot tubes to ensure they can be kept free of ice, which can otherwise completely block a tube and make it impossible to obtain an airspeed reading.
Pitot tubes sticking out in the airstream underneath a Boeing 777-381. Credit: Cassiopeia sweet, public domain
For pilots, not knowing how fast (or slow) the aircraft is going can be highly dangerous, as it can lead to entering unstable flight regimes such as stall. Thus, it’s imperative that the pitot tubes remain unobstructed and functional for safe flight. Many aircraft accidents have occurred because of blocked or malfunctioning pitot tubes or airspeed instruments.
The New Way
Of course, you could fuss about with pitot tubes and pressure sensors and deicing measures, but that’s all very fiddly and old hat. There is an entirely different way to figure out a plane’s speed, though it’s only been available for the last few decades. It’s as simple as throwing a GNSS receiver on the aircraft.
Yes, whether your particular poison is GPS, Baidou, GLONASS, or Galileo, any major satellite navigation system will be able to tell you the speed of your receiver. Simply measuring the change in the receiver’s position over time is enough to calculate out the speed, and any off-the-shelf receiver will present this information as standard. It’s generally not used as a primary indicator in aircraft, because it reports ground speed, not airspeed, the latter being more relevant for aviation purposes. Still, it can prove to be a useful sense check when traditional airspeed indicators are non-operative or reporting confusing data, and GNSS devices are widely used on many aircraft today.
Flying High
Many modern aircraft have so-called “glass cockpit” displays that include feeds from GNSS receivers, which can provide supplementary data such as satellite-based ground speed measurements. However, these readings are generally not used for the primary task of flying the aircraft. Credit: Bluedisk, CC BY-SA 3.0
If you’ve ever wondered how an aircraft measures its speed as it floats through the amorphous gas cloud we call an atmosphere, now you know. Even to this day, where electronics and computer wizardry control our fanciest aircraft, airspeed measurements are still done with the same simple physics, just with some fancier sensors for help. The fundamentals haven’t changed at all. Now you know, you can always dig deeper into the many other rich applications of Bernoulli’s equation and fluid mechanics in general. Happy learning.
Login
