The Myth Of Propellantless Space Propulsion Refuses To Die

In a Universe ruled by the harsh and unyielding laws of Physics, it’s often tempting to dream of mechanisms which defy these rigid restrictions. Although over the past hundred years we have made astounding progress in uncovering ways to work within these restrictions — including splitting and fusing atoms to liberate immense amounts of energy — there are those who dream of making reality a bit more magical. The concept of asymmetrical electrostatic propulsion is a major player here, with the EmDrive the infamous example. More recently [Dr. Charles Buhler] proposed trying it again, as part of his company Exodus Propulsion Technologies.

This slide from Dr. Buhler’s APEC presentation shows the custom-made vacuum chamber built to test their propellantless Propulsion drive in a simulated space environment. Image Credit: Exodus Propulsion Technologies, Buhler, et al.
This slide from Dr. Buhler’s APEC presentation shows the custom-made vacuum chamber built to test their propellantless Propulsion drive in a simulated space environment. Image Credit: Exodus Propulsion Technologies, Buhler, et al.

The problem with such propellantless space propulsion proposals is that they violate the core what we know about the physical rules, such as the conclusion by Newton that for any action there has to be an opposite reaction. If you induce an electrostatic field or whatever in some kind of device, you’d expect any kind of force (‘thrust’) this creates to act in all directions equally, ergo for thrust to exist, it has to push on something in the other direction. Rocket and ion engines (thrusters) solve this by using propellant that create the reaction mass.

The EmDrive was firmly disproven 2021 by [M. Tajmar] and colleagues in their paper titled High-accuracy thrust measurements of the EMDrive and elimination of false-positive effects as published in CEAS Space Journal, which had the researchers isolate the EmDrive from all possible outside influences. Since the reported thrust was on the level of a merest fraction of a Newton, even the impact from lighting in a room and body heat from the researchers can throw off the results, not to mention the heat developed from a microwave emitter as used in the EmDrive.

Meanwhile True Believers flock to the ‘Alt Propulsion Engineering Conference’ (APEC), as no self-respecting conference or scientific paper will accept such wishful claims. In the case of [Buhler], he claims that their new-and-improved EmDrive shows a force of 10 mN in a ‘stacked system’, yet no credible paper on the experiments can be found other than APEC presentations. Until their prototype is tested the way the EmDrive was tested by [M. Tajmar] et al., it seems fair to assume that the rules of physics as we know them today remain firmly intact.

Reverse Engineering A Fancy Disposable Vape

Many readers will be aware of the trend for disposable vapes, and how harvesting them for lithium-ion batteries has become a popular pastime in our community. We’re all used to the slim ones about the size of a marker pen, but it’s a surprise to find that they also come in larger sizes equipped with colour LCD screens. [Jason Gin] received one of this type of vape, and set about reverse engineering it.

What he found inside alongside the lithium-ion cell (we love his use of the term ” street lithium” by the way) was an ARM Cortex M0 microcontroller, 1 MB of flash, and that 80×160 display. Some investigation revealed this last part to have an ST7735S controller with an SPI interface. He turned his attention to the flash, which was filled with the bitmaps for the display. Seeing an opportunity there, this lead to the creation of a Windows 95 theme for the device.

Finally, the microcontroller turned out to be accessible with programming tools, with an unprotected firmware. The reverse engineering effort is ongoing, but we hope the result is a small dev board that will at least save some of the from being e-waste. If you’re curious, all the tools used are in a GitHub repository.

Meanwhile, we’ve looked at street lithium harvesting before.

Thanks [DeadFishOnTheLanding] for the tip!

Illustrated Kristina with an IBM Model M keyboard floating between her hands.

Keebin’ With Kristina: The One With The Transmitting Typewriter

Image by [SrBlonde] via Hackaday.IO
Okay, so we’re opening with more than just a keyboard, and that’s fine. In fact, it’s more than fine, it’s probably the cutest lil’ ZX Spectrum you’ll see today.

[SrBlonde]’s wonderful micro Spectrum project has only the essential inputs, which makes for an interesting-looking keyboard for sure. Inside you’ll find an Orange Pi Zero 2 board loaded with Batocera so [SrBlonde] can play all their favorite childhood games on the 5″ IPS display.

Something else that’s interesting is that the switches are a mix of blues and blacks — clickies and linears. I can’t figure out how they’re distributed based on the numbers in the components list, but I could see using clickies on the alphas and linears everywhere else (or vice versa). At any rate, it’s a great project, and you can grab the STL files from Thingiverse if you’re so inclined.

Continue reading “Keebin’ With Kristina: The One With The Transmitting Typewriter”

Chip Mystery: The Case Of The Purloined Pin

Let’s face it — electronics are hard. Difficult concepts, tiny parts, inscrutable datasheets, and a hundred other factors make it easy to screw up in new and exciting ways. Sometimes the Magic Smoke is released, but more often things just don’t work even though they absolutely should, and no amount of banging your head on the bench seems to change things.

It’s at times like this that one questions their sanity, as [Gili Yankovitch] probably did when he discovered that not all CH32V003s are created equal. In an attempt to recreate the Linux-on-a-microcontroller project, [Gili] decided to go with the A4M6 variant of the dirt-cheap RISC-V microcontroller. This variant lives in a SOP16 package, which makes soldering a bit easier than either of the 20-pin versions, which come in either QFN or TSSOP packages.

Wisely checking the datasheet before proceeding, [Gili] was surprised and alarmed that the clock line for the SPI interface didn’t appear to be bonded out to a pin. Not believing his eyes, he turned to the ultimate source of truth and knowledge, where pretty much everyone came to the same conclusion: the vendor done screwed up.

Now, is this a bug, or is this a feature? Opinions will vary, of course. We assume that the company will claim it’s intentional to provide only two of the three pins needed to support a critical interface, while every end user who gets tripped up by this will certainly consider it a mistake. But forewarned is forearmed, as they say, and hats off to [Gili] for taking one for the team and letting the community know.

Implantable Battery Charges Itself

Battery technology is the major limiting factor for the large-scale adoption of electric vehicles and grid-level energy storage. Marginal improvements have been made for lithium cells in the past decade but the technology has arguably been fairly stagnant, at least on massive industrial scales. At smaller levels there have been some more outside-of-the-box developments for things like embedded systems and, at least in the case of this battery that can recharge itself, implantable batteries for medical devices.

The tiny battery uses sodium and gold for the anode and cathode, and takes oxygen from the body to complete the chemical reaction. With a virtually unlimited supply of oxygen available to it, the battery essentially never needs to be replaced or recharged. In lab tests, it took a bit of time for the implant site to heal before there was a reliable oxygen supply, though, but once healing was complete the battery’s performance leveled off.

Currently the tiny batteries have only been tested in rats as a proof-of-concept to demonstrate the chemistry and electricity generation capabilities, but there didn’t appear to be any adverse consequences. Technology like this could be a big improvement for implanted devices like pacemakers if it can scale up, and could even help fight diseases and improve healing times. For some more background on implantable devices, [Dan Maloney] catches us up on the difficulties of building and powering replacement hearts for humans.

Sticky Situation Leads To Legit LEGO Hack

[samsuksiri] frequently uses a laptop and has an external drive to store projects. The drive flops around on the end of its tether and gets in the way, so they repurposed their old iPod pouch and attached it to the laptop lid with double-sided tape. You can guess how that went — the weight of the drive caused the pocket to sag and eventually detach over time.

Then [samsuksiri] remembered that they had LEGO DOTS patch stashed somewhere. It’s an 8×8 plate with adhesive on the back so you can build almost anywhere. Then the problem was this: how to attach LEGO to the drive itself? You’d think this is where the hot glue comes in, but that didn’t work because the drive is too slippery.

Nothing worked, really — not until [samsuksiri] flipped the drive over to work with the dimpled side that has un-coated plastic. Finally, the answer turned out to be mounting tape. Now, [samsuksiri] can attach the drive in any orientation, or even attach a second drive. Be sure to check it out after the break.

Looking for slightly more astounding LEGO creations? Check out this hydroelectric dam.

Continue reading “Sticky Situation Leads To Legit LEGO Hack”

The Performance Impact Of C++’s `final` Keyword For Optimization

In the world of software development the term ‘optimization’ is generally reason for experienced developers to start feeling decidedly nervous, especially when a feature is marked as an ‘easy and free optimization’. The final keyword introduced in C++11 is one of such features. It promises a way to speed up object-oriented code by omitting the vtable call indirection by marking a class or member function as – unsurprisingly – final, meaning that it cannot be inherited from or overridden. Inspired by this promise, [Benjamin Summerton] figured that he’d run a range of benchmarks to see what performance uplift he’d get on his ray tracing project.

To be as thorough as possible, the tests were run on three different systems, including 64-bit Intel and AMD systems, as well as on Apple Silicon (M1). For the compilers various versions of GCC (12.x, 13.x), as well as Clang  (15, 17) and MSVC (17) were employed, with rather interesting results for final versus no final tests. Clang was probably the biggest surprise, as with the keyword added, performance with Clang-generated code absolutely tanked. MSVC was a mixed bag, as were the GCC versions other than GCC 13.2 on AMD Ryzen, which saw a bump of a few percent faster.

Ultimately, it seems that there’s no free lunch as usual, and adding final to your code falls distinctly under ‘only use it if you know what you’re doing’. As things stand, the resulting behavior seems wildly inconsistent.