Canon Arc Form Drive exploded. Credit: Markus Kohlpaintner

A Deep Dive Into Canon Autofocus Lenses

Credit: Markus Kohlpaintner

Although taken for granted these days, autofocus (AF) used to be a premium feature on film- and digital cameras, with [Markus Kohlpaintner] taking us through an exhaustive overview of Canon’s AF systems and how they work. On Canon cameras AF became a standard feature with the introduction of its EF lenses in 1987, which are found on its EOS SLR (single-lens reflex) series of professional and prosumer cameras.

Over the decades, Canon has used many different AF drive mechanisms within these lenses, all with their own pros and cons. The article goes through each of them, starting with the original Arc-Form Drive (AFD) and ending with the newest Voice Coil Motor (VCM), showing their internal construction.  Of note are the USM (ultrasonic motor) types of AF systems that use a piezoelectric motor, the functioning of which using a traveling wave across the stator is also detailed, including the integrated feedback control system.

Ultimately the end user is mostly concerned with how well the AF works, of course. Here the biggest difference is probably whether manual adjustment is possible, with not all AF systems supporting full-time manual adjustment. With the newer AF systems this manual adjustment is now performed digitally rather than with a direct coupling. Although few people probably give AF much thought, it’s fascinating to see how much engineering went into these complex systems before even touching upon the algorithms that decide what to focus on in a scene.

TrapC: A C Extension For The Memory Safety Boogeyman

In the world of programming languages it often feels like being stuck in a Groundhog Day-esque loop through purgatory, as effectively the same problems are being solved over and over, with previous solutions forgotten and there’s always that one jubilant inventor stumbling out of a darkened basement with the One True Solution™ to everything that plagues this world beset by the Unspeakable Horror that is the C programming language.

As the latest entry to pledge its fealty at the altar of the Church of the Holy Memory Safety, TrapC promises to fix C, while also lambasting Rust for allowing that terrible unsafe keyword. Of course, since this is yet another loop through purgatory, the entire idea that the problem is C and some perceived issue with this nebulous ‘memory safety’ is still a red herring, as pointed out previously.

In other words, it’s time for a fun trip back to the 1970s when many of the same arguments were being rehashed already, before the early 1980s saw the Steelman language requirements condensed by renowned experts into the Ada programming language. As it turns out, memory safety is a miniscule part of a well-written program.

Continue reading “TrapC: A C Extension For The Memory Safety Boogeyman”

The ESP32 Bluetooth Backdoor That Wasn’t

Recently there was a panicked scrambling after the announcement by [Tarlogic] of a ‘backdoor’ found in Espressif’s popular ESP32 MCUs. Specifically a backdoor on  the Bluetooth side that would give a lot of control over the system to any attacker. As [Xeno Kovah] explains, much about these claims is exaggerated, and calling it a ‘backdoor’ is far beyond the scope of what was actually discovered.

To summarize the original findings, the researchers found a number of vendor-specific commands (VSCs) in the (publicly available) ESP32 ROM that can be sent via the host-controller interface (HCI) between the software and the Bluetooth PHY. They found that these VSCs could do things like writing and reading the firmware in the PHY, as well as send low-level packets.

The thing about VSCs is of course that these are a standard feature with Bluetooth controllers, with each manufacturer implementing a range of these for use with their own software SDK. These VSCs allow for updating firmware, report temperatures and features like debugging, and are generally documented (except for Broadcom).

Effectively, [Xeno] makes the point that VSCs are a standard feature in Bluetooth controllers, which – like most features – can also be abused. [Tarlogic] has since updated their article as well to distance themselves from the ‘backdoor’ term and instead want to call these VSCs a ‘hidden feature’. That said, if these VSCs in ESP32 chips are a security risk, then as [Xeno] duly notes, millions of BT controllers from Texas Instruments, Broadcom and others with similar VSCs would similarly be a security risk.

Fixing An Unpleasant SD Card Slot Issue In A NanoVNA

SD cards & the much smaller microSD cards are found on many devices, with the card often accessible from outside the enclosure. Unfortunately there’s a solid chance that especially small microSD cards will find their way past the microSD card reader slot and into the enclosure. This is what happened to [Rob] of the SevenFortyOne Radios and Repairs channel on YouTube with a NanoVNA unit. While shaking the unit, you can clearly hear the microSD card rattling inside, courtesy of the rather large gap above the card slot.

After a quick teardown and extracting the lost microSD card, the solution to prevent this is a simple bit of foam stuck on top of the microSD card slot, so that the too large opening in the enclosure is now fully blocked. It’s clearly a bit of a design fail in this particular NanoVNA unit, worsened by the tiny size of the card and having to use a fingernail to push the card into the slot as it’s so far inside the enclosure.

While [Rob] seems to blame himself for this event, we’d chalk it mostly up to poor design. It’s an issue that’s seen with certain SBC enclosures and various gadgets too, where losing a microSD card is pretty much a matter of time, and hugely fiddly at the best of times. That said, what is your preferred way of handling microSD card insertion & removal in devices like these?

Continue reading “Fixing An Unpleasant SD Card Slot Issue In A NanoVNA”

Writing An OLED Display Driver In MicroZig

Although most people would use C, C++ or MicroPython for programming microcontrollers, there are a few more obscure options out there as well, with MicroZig being one of them. Recently [Andrew Conlin] wrote about how to use MicroZig with the Raspberry Pi RP2040 MCU, showing the process of writing an SSD1306 OLED display driver and running it. Although MicroZig has since published a built-in version, the blog post gives a good impression of what developing with MicroZig is like.

Zig is a programming language which seeks to improve on the C language, adding memory safety, safe pointers (via option types), while keeping as much as possible of what makes C so useful for low-level development intact. The MicroZig project customizes Zig for use in embedded projects,  targeting platforms including the Raspberry Pi MCUs and STM32.  During [Andrew]’s usage of MicroZig it was less the language or supplied tooling that tripped him up, and more just the convoluted initialization of the SSD1306 controller, which is probably a good sign. The resulting project code can be found on his GitHub page.

Run Xbox 360 Games On Your PC With XenonRecomp

Inspired by the N64: Recompiled project, XenonRecomp does something similar, except for the PowerPC-equipped Microsoft Xbox 360 game console. Based around the triple-core IBM CPU codenamed ‘Xenon‘, the Xbox 360 was released in 2005 and generally quite successful over its lifespan despite its Red Ring of Death issues. Although the current Xbox Series X supports running a number of Xbox 360 games, this is done via emulation and only 632 games out of 2,155 are supported.

This is where XenonRecomp not only promises turning the games into native (x86) software, but also allowing for a range of graphical improvements. Best of all, it allows for Xbox 360 games to be preserved instead of linked to an obsolete console. That said, much like with N64Recomp, it’s not a simple matter of running a tool over the PPC binary. You’re expected to have in-depth systems knowledge, with the tools in XenonRecomp assisting with the decompilation (into C++) and the recompilation into x86 binaries, but support for PPC instructions, VMX (vector instructions) and aspects like jump table conversion and (currently missing) MMIO support are likely to present an enterprising developer with hours of fun to implement and debug when issues arise.

Continue reading “Run Xbox 360 Games On Your PC With XenonRecomp”

GNSS Signals Tracked On The Moon By LuGRE

As part of the payloads on the Firefly Blue Ghost Mission 1 (BGM1) that recently touched down on the Moon, the Lunar GNNS Receiver Experiment (LuGRE) has become the first practical demonstration of acquiring and tracking Earth orbital GNSS satellites. LuGRE consists of a weak-signal GNSS receiver, a high-gain L-band patch antenna the requisite amplification and filter circuits, designed to track a number of GPS and Galileo signals.

Designed by NASA and the Italian Space Agency (ISA), the LuGRE payload’s goal was to demonstrate GNSS-based positioning, navigation and timing at the Moon. This successful demonstration makes it plausible that future lunar missions, whether in orbit or on the surface, could use Earth’s GNSS satellites to navigate and position themselves with. On the way to the lunar surface, LuGRE confirmed being able to track GNSS at various distances from the Earth.

Both LuGRE and BGM1 are part of NASA’s Commercial Lunar Payload Services (CLPS) program, with BGM1 delivering a total of ten payloads to the Moon, each designed to study a different aspect of the lunar environment, as well as hardware and technologies relevant to future missions.