Although the term ‘quantum battery’ is a bit of a vague term, the cell that [Kieran Hymas] et al. demonstrate in a recent paper does seem to suggest that it uses quantum effects to charge faster than would otherwise be possible, with this rate increasing faster than its volume, meaning at a superextensive rate.

The general idea behind a quantum battery is that these somehow use a quantum effect to store and release energy faster than would be possible using classical physics. First proposed in 2013, the initial Dicke model saw its theoretical quantum advantage shot down by 2020, leading to the search for alternative models.

We have previously seen claims of a quantum advantage in batteries based on the Sachdev-Ye-Kitaev model, such as by [Davide Rossini] et al., but this new paper may be the first prototype cell demonstrating a reproducible effect.

In the here demonstrated cell a microcavity is created with strong light-matter coupling, allowing for both energy storage and discharging, with the illuminated particles super-absorbing the light with what the researchers claim to be due to these particles cooperating using a quantum mechanism. Effectively scaling up the cell would thus scale up the charge- and discharge rate faster than in a conventional chemical cell.

Whether this demonstration can be replicated and expanded upon remains to be seen, naturally. The stored energy in this experiment was very small and the storage time only very brief, so for now it serves primarily as an interesting experimental result for researchers to dig through.

Although e-paper displays are famous for being low-power and lasting essentially forever if not damaged physically, the recent push to drive even cheaper e-paper displays at a framerate like 30 FPS for a decent monochrome gaming experience does raise a few questions. The first being what this does to the power usage of these displays, and the second whether this will wear out the display in short order. To investigate this, [Bo Made It] set up a few experiments.

Subject of this test was a Waveshare ESP32-S3-ePaper board, which had previously been demonstrated running a Game Boy emulator at 30 FPS. With this software running, the board consumed on average about 115 mA, which would run down the device’s 400 mAh battery in about 3.5 hours. From here key was to isolate the power consumption of the display itself, with the system minus the display updates consuming about 90 mA.

Running the frame calculations for the greyscale mode without rendering to the screen pushed that up to 107.6 mA, with even in the 30 FPS greyscale mode the display thus only consuming about 7.4 mA, which is vanishingly small. Clearly the low-power claims of e-paper remain intact even at higher framerates.

As for lifespan, one datasheet gives the typical lifespan as one million updates. This would translate to about 9.3 hours at 30 FPS, though that assumes a full display refresh. Since a smart driver only updates changed pixels, obviously this will be longer, but the question is how much longer, and what will degradation look like?

After running 2.16 million frames of a custom endurance test featuring repeating patterns, some ghosting was apparent, but repeated refreshing made this go away again. This means that so far no permanent damage has been detected within the no doubt conservative limit provided by e-paper manufacturers.

It should be noted that Waveshare itself also recommends against running such high-FPS applications on their device, meaning that this is definitely one big longevity experiment. If actual damage occurs, this means that obviously this won’t be covered under any warranty.

Upcycling smartphones makes a lot of sense, especially since they contain so many components that remain useful long after their desirability as a smartphone has faded. In the case of [Mountain DS Lab], they opted to use an 8-year old Xiaomi Mi 8 phone to add long-range FPV video link and remote control functionality to an RC plane, using the phone’s LTE cellular connectivity.

The smartphone was bought used for $23, with the default Xiaomi ROM overwritten by LineageOS to get a more lightweight and up to date Android installation on it. From the video it’s clear that this phone has seen better days, with the glass back cracked and a few ugly lines running across the display. Fortunately all that is needed is the motherboard itself.

One gotcha here is that the OS checks for the display on boot and will time-out if it’s not present, potentially halting the process entirely. The workaround requires disabling the display in the device tree, which is done by modifying the boot.img file as explained in the video. Next a custom bracket for the motherboard was printed so that it could be fitted inside the target airplane.

To communicate with the avionics, a USB-to-UART adapter PCB was created with a CH340 IC on it. This was then connected together for an initial test, with the extended front camera being used as the FPV camera for the custom Android application. Using the controller via the remote LTE link worked with the flight controller, so next the airplane was assembled for initial testing.

From this point it’s all pretty standard RC airplane assembly and testing, just with the typical RF-based control and FPV link replaced with the LTE link. Unfortunately flying drones isn’t permitted in the immediate area where the creator lives, so only some taxiing was tried prior to its maiden flight at a local airstrip that will be featured in an upcoming video.

Naturally, this isn’t the first time that someone has tried this type of remote control, with the ongoing Russo-Ukraine war being a prime example of LTE-based remote control of drones. Although we do not advocate wiping out a third of a nation’s strategic bomber fleet with upcycled smartphones, ultimately this is the same technology and a good way to create an RC drone that can last more than the few kilometers eked out from a 2.4 GHz link or so. Just be prepared for the LTE link to add a few milliseconds of latency.

Recently [shraiwi] decided to have a bit of good nerdy fun and implement the FAST machine vision algorithm on an ESP32-S3 using its SIMD ISA. This involves using the assembly instructions for the ISA, making for an exciting opportunity to become familiar with this part of this Xtensa Lx7-based twin-core MCU.

The Features from Accelerated Segment Test (FAST) algorithm is a corner detection method that can determine with reasonable accuracy and in real-time whether a given input frame contains said corners which thus may correspond to objects and other characteristics worthy of note. This is essential for machine vision, with machine learning able to bump up its recognition accuracy even more.

Implementing this algorithm on the ESP32-S3 proved to be a bit of a challenge due to somewhat limited SIMD ISA. Missing instructions included things like comparisons between unsigned byte values, and there is no support for direct misaligned reads.

All of these required some creative coding to work around, but in the end the ESP32-S3 running at 240 MHz was able to process a VGA stream in real-time at 30 FPS. This means about a 2x speed-up over a naive implementation using only non-SIMD instructions.

If you want to play along at home, the Platform IO project is made available on GitHub.

Recently [Rod Burlamaqui] released the arc-rebar project on GitHub, enabling Intel GPUs to work significantly more efficiently if the system’s mainboard does not support resizable BAR. It does require a Debian or Ubuntu installation and of course a supported Intel GPU.

Although the resizable base address register (ReBAR) feature has been part of the PCIe specification for a while, its use was quite limited until Intel released its Arc series of graphic cards. These use this feature to map much more of the GPU’s video RAM (VRAM) into the PC’s address space than the standard 256 MB, assuming that the system is capable of decoding addresses above 4 GB, i.e. allow for 64-bit BARs.

For GPU manufacturers like AMD and Nvidia this wasn’t so much of an issue as their GPU designs developed in a world where ReBAR didn’t exist, while Intel’s new GPU generations were designed with ReBAR as a core feature, which naturally cripples performance if the mainboard does not have it enabled during PCIe bus enumeration.

This initramfs-based fix runs before the GPU driver loads and performs the requisite BAR configuration. In testing with an Intel Arc B580 GPU on a 2015-era Intel Xeon mainboard the difference between the default and the fixed bandwidth was a bump from a pitiful 15 GB/s to a respectable 392 GB/s, showing how this one fix can breathe new life into older systems.

Learning a new natural language can be a daunting proposition at the best of times, with repetition and immersion generally considered to be the best ways to build up not only vocabulary but also that innate sense for grammar and cultural details that sneak into every spoken language. Flash cards are one way to help with vocabulary and sentence building, such as [Peter Hraska]’s Enkiplate project that uses the Inkplate 4Tempera being an  interesting alternative to lugging a stack of cards with you.

Although the software also works in the browser, using the Inkplate or similar device means that you can keep it with you while it keeps track of your progress in learning the shown cards, with a starting pace of 12 cards per day to learn. It also shows you calendar items for that day and the weather using an online weather service.

Starting from basic kana, i.e. the two phonetic writing systems, the difficulty is slowly ramped up to cover kanji and then sentences. Due to the limitations of the 4Tempera’s ESP32-WROVER-E module’s local storage up to 16 flash cards can be stored at a time, with an application on a PC being necessary to obtain new cards.

Infrared (IR) communication technologies are probably one of the most influential, yet also one of the least flashiest. The fact that IR communication tends to be highly directional and often limited to low data rate leads many people to scoff at it, deeming it barely worthy of more than making TV remotes work, perhaps along with some unloved industrial gear like the IR interface of electrical meters.

This is a shame, because TV remotes are a good example of why sometimes you want something that is directional, and anyone who has battled with Bluetooth pairing can attest to the value of things simply working by pointing it at the device. IR protocols also have the advantage of inherent privacy protection as walls and other obstacles will block the signal, unlike that of an exploitable Bluetooth device which happily advertises to your neighbors and passersby.

For reasons like the above – as well as their simplicity and hackability – IR protocols are worthy of a detailed look.

Remote Control

Naturally, one of the oldest uses of consumer IR protocols is that of the venerable IR remote control. Initially TVs used wired and ultrasonic remote controls, with the latter using simple ultrasonic tones to transfer a command, but with IR protocols and the advent of cheap MCUs it became possible to create extensive communication protocols. Of these the NEC, Sony IR (SIRC) and Philips protocols are probably the most well-known and most used.

These use an approximately 38 kHz carrier, with the common NEC protocol using pulse distance encoding – a form of amplitude-shift keying – and the Philips RC-5 protocol using Manchester encoding. Within this encoding, these protocols define various bit fields and other values that can be used by a receiver to determine whether it’s being targeted, and if so what command the user wishes to have performed.

When it comes to those cheap-and-cheerful remotes that you get with just about any RGB light strip and others gadgets these days, they tend to use the same NEC protocol, with many MCU-based projects around that can control these gadgets directly with a simple IR LED.

For example this STM32F0-based project by [eleksaggr] on GitHub that targets the common 24-key RGB remotes. This Infrared Remote Control Implementation application note by Texas Instruments for the MSP430, which contains a good overview of the modulation and encoding schemes, as well as how to implement a remote control.

Many smartphones have – or used to have – an IR blaster feature that can target the same carrier frequency and a range of protocols to control just about anything that is IR remote controlled. In a world of smartphones this would theoretically mean that everyone has a universal remote in their pocket at any time, if it wasn’t for IR blasters becoming pretty rare. If your recently purchased smartphone still has an IR blaster, it’s very likely a Chinese brand, which is a shame as IR remotes are still used for so many things.

IrDA

Of course, IR remotes are quite a specific use case, but you can send a lot more than just a basic set of commands to a device. The most well-known standard here is IrDA, which stands for Infrared Data Association, the association which defined the various standards.

The basic principles behind IrDA remain effectively the same as with the remote control protocols, just designed to be capable of far higher transfer speeds. This is accomplished through various types of encoding, modulation and other techniques also observed with non-IR forms of wireless communication. Using this a range of speeds are possible, defined as:

• SIR (115 kbit/s).
• MIR (1 Mbit/s).
• FIR (4 Mbit/s).
• VFIR (16 Mb/s).
• UFIR (96 Mbit/s).
• Giga-IR (512 Mbit/s – 1 Gbit/s).

In addition a range of derived protocols exist such as IrSimple that allows for easy sharing of images between phones, printers, and displays. All of this uses generally the same IrDA software stack, though the special versions such as IrSimple optimize it to make transfers take less than a second for a 500 kB picture.

All communication generally happens in half-duplex, as the sending side tends to produce too much interference for the receiving side of the transceiver to reliably receive data. Distance between the two sides can be as much as two meters, though the lower power versions shrink that down to 20 cm or thereabouts.

Within this range of speeds you can pick whatever the device needs. Power meters, for instance, are plenty happy with the IrDA-SIR protocol, which is low-power and speed enough to bitbang on even a basic MCU in these meters with just a basic IR transceiver attached to its pins.

Power Meters

The humble power meter that lurks in your utility closet or wherever else it is installed has to be shielded from whatever environment it is installed in, ergo they require some kind of low-power, low-speed wireless interface. Using nothing but an IR-transparent window on the enclosure it is then possible for a read-out device to be pressed up to said window, where it’ll quickly query the device for the necessary information.

This same feature is also found on heat meters and other types of devices where such basic read-out functionality is required. Here security is managed by not only the short-distance, line-of-sight requirement of an IR communication link, but also by having a sign-on involving an encrypted password exchange.

Although IrDA-SIR was commonly used here, these days DLMS/COSEM, also known as IEC 62056, is much more common. While radio-based forms of automatic meter reading (AMR) are also used, short-range protocols like this have a definite privacy advantage, with the line-of-sight feature meaning that the reader has to be literally in front of the meter to work, unlike with RF wireless approaches.

Whether this privacy aspect is important depends on the situation, but it’s hard to argue with the low power requirements compared to stuffing a Bluetooth or Wi-Fi module into the meter and dealing with its implications.

Game Consoles

Although it may seem that handheld game consoles went straight from the Game Boy’s link cable to Wi-Fi transfers on the Nintendo 3DS beyond, it featured an IR communication port. This was intended to support peripherals like the Circle Pad Pro and the Amiibo reader/writer device for the original 3DS as it did not feature the NFC reader of the New Nintendo 3DS.

As it turns out, the 3DS uses irDA-SIR for this expansion feature, with e.g. the Circle Pad Pro using a 96000 baud rate. Since this peripheral merely is there to add a second circle pad to match the built-in left one, it doesn’t need a lot of bandwidth.

In the case of the external NFC reader, this was a similar low bandwidth application where it made a lot of sense to use this same IR port to provide this new feature to older 3DS consoles, instead of making it a New 3DS-exclusive feature. Although one could have used Bluetooth for this even back then, the 3DS console did not include Bluetooth, and when looking at e.g. the Joycons of the Nintendo Switch it’s clear that they are a tad more power hungry and complex circuitry-wise.

When low-power and line-of-sight are benefits rather than a potential source of confusion of which peripheral you’re trying to pair with, it can make a lot of sense.

DIY IR Transceiver

If you’re feeling like making your own IR receiver, receiver or even transceiver solution, there are many options. Perhaps the most exciting aspect is that even if you want to use something like IrDA, this feature is often part of the UART in many MCUs. In the case of Espressif’s ESP32 MCUs, for example, you can look at its list of potential UART modes and note that you can pick IrDA as well as RS485 in addition to plain UART functionality.

There are also dedicated IrDA encoder/decoder ICs, such as the MCP2120. This gets you IrDA-SIR support for any UART interface that does not directly implement this protocol. You can also use something like the Vishay TFDU4101 IrDA transceiver that integrates everything including the IR elements into a single package.

If you’re more about messing with NEC, Sony and Philips remote control protocols, then a common part like the VS1838b provides a similar solution to the Vishay part for 38 kHz applications. This IR receiver handles all the receiving, demodulating, amplification and other tasks, leaving it to the receiving MCU to parse the received data.

This of course just barely scratches the surface of everything IR communication-related, so feel free to chime in with your own info dumps and requests for additional topics to cover.

In the world of silicon semiconductors, the process of creating transistors and similar structures involves various rounds of modifications and additions in order to create the requisite functional layers. A less involved approach would simply create these structures in-situ, with research the past years having focused on transition-metal dichalcogenide (TMDC) monolayers to do exactly this. Recently [Seok Young Min] et al. reported (paywalled, Phys.org summary) on creating transistors in-situ in a tungsten ditelluride (WTe₂) monolayer.

By selectively changing parts of the top layer into tungsten oxide (WO_x) as an insulator and other sections into n-type WS₂ and p-type WSe₂ the researchers were able to create functional MOSFETs, without the normally requisite grafting on of different materials. An obvious advantage of this is that this can be done at an atomic scale, potentially achieving densities significantly higher than with industry standard silicon semiconductor technology.

WTe₂ is not the only TMDC that could be viable here, of course, with other researchers investigating the use of MoSe₂ for a similar purpose, as in this research by [N. Lu] et al. from 2014. This being the creation of 2D semiconductors, referring to the thin layers of these monolayer TMDCs, along with potentially other materials such as graphene.

With the topic of marble clocks having been quite well explored at this point, it raises the question of how easy it would be to take the basic principle and create a text display using black and white marbles. As [Ivan Miranda] found out in a recent marble text scroller project, this is far from easy.

The reason why a scrolling text display was picked comes down to not wanting to be limited to a fixed number of digits. This resulted in a round wheel design, with inner steel ball bearings and a stepper motor on both the wheel and an inner selector mechanism. These respectively align the marble channels and pick the right color of marbles to be dropped into any of the wheel’s slots, creating the right sequence of marbles for the target text.

Perhaps the most amazing thing about it is that it’s an absolutely massive structure, yet it’s all 3D printed and bolted together. It took a number of trial-and-error cycles, and debugging issues like the IR sensors getting confused by daylight, but it now mostly seems to work all right.

There are still some remaining issues, such as having to manually home the wheel before starting, and the ratio of black vs white marbles can cause unexpected gaps in the final text. Despite this the text is quite legible and definitely infinite.

Even though laptops from around the early 2000s came with just about every conceivable port on them, they still would often feature a somewhat unusual combined video output port. While at its core this was just a 4-pin analog S-video output, the three additional pins on the mini-DIN connector provided some more features. Of course, as [VWestlife] found out during his archaeological research, not every manufacturer used the same pinout here.

The naming for this specific port differs, with the name ‘S-video+’ appearing regularly, yet many descriptions glossing over the additional pins and only mentioning that it can be used with a 4-pin S-video connector. As it turns out, most manufacturers used roughly the same pinout, matching the shown Dell one. This adds composite output, along with two S/PDIF digital audio pins that could be routed out with an adapter into their full-sized ports.

Of course, the Apple PowerBook G4 had to be that exception again, with it omitting the audio pins and putting the composite signal on pin 5. This left the last two pins completely unused, but serving to completely confuse anyone who thought that they could get more out of the port with an adapter for those uncouth PC systems.

As to the remark at the end about how the transition to ‘just USB ports’ has made everything better, we’d challenge the average person to look at a random USB-C port and tell based on its appearance which standards it actually supports.

The RepRapMicron (also µRepRap) is pretty much the microscopic take on what RepRap did for more macroscale manufacturing, with the most recent innovation being a UV print head, called the PIKA UV Head. What this does is use off-the-shelf optical fiber and UV LED modules to create 3D structures in-situ in a UV resin, allowing for pretty small structures to be printed, down to a resolution of about 9 µm.

More photos of prints can be found on the blog page with links to YouTube videos. It’s naturally somewhat tricky to get clean photographs of a 3D print that’s small enough to lose forever if you so much as sneeze or breathe too loudly.

For the UV head assembly a single mode fiber optical cable was used in the form of a regular patch cord that got trimmed a bit with a hacksaw. This was used in combination with a “3W” UV LED module, which may or may not be its true rating, but it was definitely able to cure the SLA resin. The used resin was regular eSun Standard Resin.

Afterwards you have to do the typical SLA post-processing, including cleaning off of liquid resin – both the part and fiber – and curing the part. So far results are pretty decent, with overhangs still being a weak spot that will be addressed in future revisions.

The Chinese had been using large crossbows – akin to Greek and Roman ballistae – for warfare for many of the same reasons that European armies loved them. Their single, large arrow was effectively unstoppable, though this also was rather useless against large groups of infantry unless they were so kind to neatly line up. Old Chinese records mention a special kind of ammunition, called a cup arrow, or ‘storm of crows’, which involves launching many smaller arrows instead of a single large one, a feat that [Tod] really wanted to try and recreate.

In itself this doesn’t sound too complex: just grab some arrows, loosely tie them together in a bundle and slap them on the crossbow. Yet with the immense forces applied on this bundle it clearly turns out that the engineering challenge isn’t quite that straightforward, as the arrows love to scatter wildly in all directions or otherwise be rather unpredictable.

Although we can find historical references to multiple bolt siege crossbows being used, details are sparse on how the Chinese engineers addressed these aforementioned issues, so [Tod] tries a range of approaches to try and make it work on his own siege crossbow. Unfortunately he wasn’t able to make it work reliably, but he says he’ll be back with a range of improvements, with the community invited to pitch in their own ideas.

These type of weapons were very commonly used in China and surrounding nations from hundreds of years BCE to around the 16th century CE, when black powder was used to launch projectiles like fire arrows from a Huo Che or the Korean equivalent of the Hwacha, effectively multiple rocket launchers, not unlike the MLRS units seen in militaries today.

Recently the [Chornobyl Family] got their hands on an ES-4001 control panel for a 1970s-era Soviet mainframe, with the intention to restore it to full working order. Not just because they’re really into cool old Soviet technology, but also because of the connection that this control panel holds to the Chernobyl nuclear accident that was so instrumental to the area in modern times.

During the 1970s the USSR felt that it could not be left behind in the race to create better digital computers. This led them to not only create a few original designs, but also effectively clone the IBM System/360 and System/370. This resulted in the ES EVM-series of mainframes, with an ES-1060 finding itself installed at the Duga-1 early warning radar system near what is now the Chornobyl nuclear power plant in Ukraine.

Although the radar arrays are the most well-known feature of the Duga-1, below it is the computer center where the ES-1060 was installed. It was never put into service following the ChNPP Unit-4 accident — all that remains of a once pinnacle of Soviet engineering are the picked-over carcass of the mainframe and its control panel.

The control panel in question was obtained was from the early 1980s, serving a more gentle service life in a datacenter and looks to be in a mostly good condition. That said, there was still enough to be done to make it work and undo the damage of its violent removal from the mainframe. Along the way we also learn how the system was used and how the control panel works.

Although similar in some ways to the System/370, it’s still very different, and with only about 300 of these mainframes produced, it’s worth saving whatever elements still remain today, along with the surviving documentation.

Although you can do basic floating point format operations like addition and subtraction just fine on any CPU, having specialized hardware for it can provide a significant speed boost. Here Intel’s 8087 was the first mainstream floating-point coprocessor to provide this option to a wide audience, with [Ken Shirriff] recently reverse-engineering using an 8087 die how these basic operations were implemented.

The real-world speed-up of even simple operations like adding two floating point numbers compared to the 8086 CPU was on the order of a hundred times, which is very relevant the moment you start doing interesting things with spreadsheets, not to mention rendering 3D scenes in CAD software or even games.

As always, the devil is in the details, with sneaky infinities and edge cases also providing the biggest potential for speed-ups in dedicated silicon, along with the large circuitry spent on the shifter. With floating point values being very much about aligning values with shifting by a number of bits, this circuitry along with the detecting of over- and underflows is the key element why the 8087 and its successors were so crucial in making floating-point operations at all feasible in PC applications.

How this shifting works in theory is detailed in the article by [Ken], along with how the 8087 implements this in its circuits. Naturally, a large part of this is implemented in microcode, the listing for which is also provided. From this it’s quite clear how what seems like a simple set of operations is actually quite complex, making even the now much maligned x87 ISA an improvement over doing it all in integer-based software.

Before the advent of effective semiconductor LEDs many display types existed to display things like numbers and other characters. The Nixie tube is a well-known one, along with VFDs and there are also lesser known ones such as Burrough’s Panaplex, which all saw plentiful use in everything from calculators to audio equipment. The design that [Witchcraft and Alchemy] made appears to lean heavily on this Panaplex design.

Rather than neon, this uses argon as the gas. The anode is formed by the indium-tin oxide layer on a piece of glass, with the cathode sputtered onto the other side in the form of first a titanium layer followed by platinum. This combination helps to prevent the latter from flaking off due to incompatibilities between the molecular matrices of the glass and platinum.

Since this is an early prototype, only five segments were sputtered onto the glass and driven with a 74141 Nixie driver IC, creating the expected purple glow in a vacuum chamber. Following this a self-contained prototype was created, but this proved to be less successful, with the prototype quickly failing to light up as expected.

For a next attempt no tape or epoxy for sealing the device will be used, but rather a gasket instead of gluing the front glass onto the device. The use of conductive vias should make the device’s vacuum more permanent, and enable those last two segments to make it a seven-segment display. The final change should be to use a Penning mixture instead of pure argon.

Measuring electric currents is an essential element of many electrical systems, but doing so in a way that is as nonintrusive as possible is not an easy problem to solve. Due to this we got a wide variety of current sensors to choose from for any given application, with [ElectrArc240] running us through these variants in a recent video.

The fairly low-tech, cheap and quite reliable method of using a shunt resistor is first demonstrated. This sees a lot of use in fairly low-voltage and low-current applications, with for example videocards using it to limit the amount of power the GPU can use, a feature that modders will happily bypass. Here simply the voltage drop across a known resistance value is measured, from which the current can be derived.

Of course, you got higher voltage and higher current applications too, as well as direct- and alternating current, with the latter especially allowing for easy current measurements simply from the electromagnetic field, or flux. Anyone who has used a clamp meter can attest to that such contact-free current sensing works, even for DC applications.

Beyond the basic transformer type you got many variants including Hall-Effect, TMR and fluxgate sensors, as well as the fiber-optic current sensor that uses an interferometer to measure the phase-change induced by the magnetic field – the Faraday effect – to the transmitted electromagnetic radiation. These more exotic types will improve resolution, at the cost of a rapidly increasing void in your project budget.

These various sensor types and their construction are demonstrated and discussed in the video, including when you’d want to use a specific type, and what the potential gotchas are with each type. Even if for many applications a simple shunt resistor suffices, it’s a good idea to know these different types, as well as their underlying theory of operation.

Although we generally do not look at bubbles in fluids as more than a curiosity – if not an outright annoyance – in certain contexts they can be very useful. If you can namely control their formation and position, you can use them in small systems to control actuators and dynamically affect acoustic systems. The main issues here are that controlling their formation, lifetime and controllability remain hard to solve. This is what [Zhiyuan Zhang] et al. sought to address, with a recent study published in Science Advances covering their approach using ultrasound-driven, electronically programmable microbubbles.

There’s also a Cornell press release article about their findings, which uses a new device that produces hydrogen bubbles along a grid of electrodes, before using ultrasound to steer them around. Using this chip-like device they claim to be able to control the 10-100 micron sized bubbles, with the ultrasound matching the resonant frequency of the target bubble. With each bubble size having its own resonant frequency, this allows for individual control by varying the induced oscillations.

Although in the demonstrated 2D setup this microbubble approach works well, it still requires a fairly bulky bench top setup around it which would need to be scaled down to be more practical. There is also the issue that the chamber geometry affects the movement of a bubble, which becomes especially important to further research when using complex (3D) chambers with this technology.

If you have developed in Pascal or Delphi in the past decades, you’re probably familiar with the Lazarus IDE that provides an interface to the Free Pascal Compiler (FPC), much like Delphi’s IDE. For users of Lazarus IDE there’s now an exciting new development, with the announcement that FPC and Lazarus now support dynamic packages.

The upshot of this is that you no longer need to rebuild the IDE if you want to add components, controls and Lazarus extensions. In addition you can use this same dynamic package feature in your own Pascal applications this way.

Naturally this is a great improvement, and it’s good to see more improvements to such a venerable programming language. Not only is it still being used today for just about anything, including web development, but there is a good case to be made for using Pascal today as it’s no longer the language it was half a decade ago.

We’d also be remiss to not mention the legacy of [Niklaus Wirth], who not only created Pascal, but was also instrumental in the development of Object Pascal together with Apple. This effort ultimately led to everything from Turbo Pascal to Delphi, FPC and so much more, making it a heartening sight to see this legacy being kept alive today.

One could make a joke about how an astronaut walking on the lunar surface is rather akin to a cat walking on the carpet in the living room, but out in space the resulting triboelectric discharge can do a lot more damage than just some stinging fingers and a bemused looking cat.

The problem that NASA and other space agencies are dealing with is that the charge that builds up on a lunar-walking astronaut is very hard to equalize with something like a lunar lander. For this reason they have now set up the Lunar Grounding Challenge to consult the public whilst dangling $150,000 of rewards in front of anyone ready to pounce with a good idea.

Here on Earth we got many ways in which we can get rid of such an unwanted charge, with dry winter weather demonstrating quite effectively why humidity is a crucial factor here. With no real atmosphere on the Moon, each astronaut thus becomes a walking capacitor, which is worsened when said astronaut ventures outside of the sunlit areas and then returns to the slightly positively charged lander.

The challenge here is thus to equalize the astronaut and lander, with a design specification of a -100 kV or higher astronaut and about 100 V lander. A resulting current should not exceed 1 mA, ideally less than 0.2 mA to remain below human perception levels. If an arc exists it should not contact the suit or astronaut.

Of course, the most low-tech solution would be to use a resistor to limit the current, but at those voltage ranges it would take an awful long time to bleed off, in an environment that’s basically a perfect insulator as space will never be cold. It definitely seems like a fun challenge to sink one’s fangs into.

Joining the ranks of fresh backported Nintendo games is Super Mario Galaxy for the Nintendo Game Boy Advance (GBA), courtesy of [Tobias Friedly], AKA [Tobi]. In a recent video he announces the release of this game, along with the release of the source code of the engine and all the game’s code in a GitHub project.

Naturally none of the original Wii game’s assets are provided to appease Nintendo’s vicious lawyers, so you’re expected to bring your own super-legally acquired ISO image or equivalent to fill in these blanks when you build your ROM for the GBA.

This is a mostly complete port, even integrating the star pointer despite the GBA’s limited number of controls compared to the Wii. In some situations it’s opted to have star bits automatically collected to work around this limitation, which is probably a quality-of-life improvement that many SMG players will appreciate.

For the game’s logic a lot of code was borrowed from the recently decompiled version of the original game, which saved a lot of time even if the GBA’s hardware is no match for the Wii’s. From the gameplay in the video it definitely looks like a playable version of the game, with an acceptable frame rate that looks to be worth a try.