Benchmarking Latency Across Common Wireless Links For MCUs

February 11, 2024 by Maya Posch 13 Comments

Although factors like bandwidth, power usage, and the number of (kilo)meters reach are important considerations with wireless communication for microcontrollers, latency should be another important factor to pay attention to. This is especially true for projects like controllers where round-trip latency and instant response to an input are essential, but where do you find the latency number in datasheets? This is where [Michael Orenstein] and [Scott] over at Electric UI found a lack of data, especially when taking software stacks into account. In other words, it was time to do some serious benchmarking.

The question to be answered here was specifically how fast a one-way wireless user interaction can be across three levels of payload sizes (12, 128, and 1024 bytes). The effective latency is measured from when the input is provided on the transmitter, and the receiver has processed it and triggered the relevant output pin. The internal latency was also measured by having a range of framework implementations respond to an external interrupt and drive a GPIO pin high. Even this test on an STM32F429 MCU already showed that, for example, the STM32 low-level (LL) framework is much faster than the stm32duino one.

Continue reading “Benchmarking Latency Across Common Wireless Links For MCUs” →

Running UNIX On A Nintendo Entertainment System

February 11, 2024 by Maya Posch 19 Comments

Who wouldn’t want to run a UNIX-like operating system on their NES or Famicom? Although there’s arguably no practical reason for doing so, [decrazyo] has cobbled together a working port of Little Unix (LUnix), which was originally written for the Commodore 64 and 128 by [Daniel Dallmann]. The impetus for this project was initially curiosity, but when [decrazyo] saw that someone had already written a UNIX-like OS for the 6502 processor, it seemed apparent that the NES was too similar to the C64 to not port it.

Much of this is relatively straightforward, as the 6502 MPU in the C64 is nearly identical to the Ricoh 2A03 in the NES, with the latter missing the binary-coded decimal support, which is not a crucial feature. The only significant roadblock was the lack of RAM in the NES. The console has a mere 2 KB of RAM and 2 KB of VRAM, which made it look anemic even next to the C64. Here, a Japan-only accessory came to the rescue: the Famicom Disk System (FDS), which is a proprietary floppy disk-based system that slots into the bottom of the Famicom and was used for games as well as storing saves back in the day.

By using a Famicom with FDS, it was possible to gain an additional 32 kB provided by the FDS, making the userspace utilities available in the shell. The fruits of this labor work well enough that he could also pop it up on an EverDrive cartridge that supports FDS ROMs and boot it up on an unmodified NES. Whether this is cooler than the NES-OS, which we covered previously, is up for debate.

Incidentally, [Maciej Witkowiak] seems to have resumed development on LUnix, with a new release in 2023, so maybe UNIX-on-6502 may see a revival after a few decades of little happening.

Continue reading “Running UNIX On A Nintendo Entertainment System” →

The Usage Of Embedded Linux In Spacecraft

February 10, 2024 by Maya Posch 46 Comments

As the first part of a series, [George Emad] takes us through a few examples of the Linux operating system being used in spacecraft. These range from SpaceX’s Dragon capsule to everyone’s favorite Martian helicopter. An interesting aspect is that the freshest Linux kernel isn’t necessarily onboard, as stability is far more important than having the latest whizzbang features. This is why SpaceX uses Linux kernel 3.2 (with real-time patches) on the primary flight computers of both Dragon and its rockets (Falcon 9 and Starship).

SpaceX’s flight computers use the typical triple redundancy setup, with three independent dual-core processors running the exact same calculations and a different Linux instance on each of its cores, and the result being compared afterwards. If any result doesn’t match that of the others, it is dropped. This approach also allows SpaceX to use fairly off-the-shelf (OTS) x86 computing hardware, with the flight software written in C++.

NASA’s efforts are similar, with Ingenuity in particular heavily using OTS parts, along with NASA’s open source, C++-based F’ (F Prime) framework. The chopper also uses some version of the Linux kernel on a Snapdragon 801 SoC, which as we have seen over the past 72 flights works very well.

Which is not to say using Linux is a no-brainer when it comes to use in avionics and similar critical applications. There is a lot of code in the monolithic Linux kernel that requires you to customize it for a specific task, especially if it’s on a resource-constrained platform. Linux isn’t particularly good at hard real-time applications either, but using it does provide access to a wealth of software and documentation — something that needs to be weighed up against the project’s needs.

Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More

February 9, 2024 by Maya Posch 17 Comments

The memory map of the original 8086 computer with its base and extended memory made the original PC rather straightforward, but also posed countless issues for DOS-based applications as they tried to make use of memory beyond the legacy 1 MB address space. The initial ways to deal with this like EMS, XMS and UMB were rather cumbersome and often impractical, but with the arrival of the 80286 and 80386 processors more options opened up, including protected mode. More interestingly, this led to unreal mode, DOS extenders and the somewhat more obscure LOADALL instruction, as covered by [Julio Merino] in a new article.

This article builds on the first one which covered the older methods and covered the basics of protected mode. Where protected mode is convenient compared to real mode is that with the former the memory accesses go via the MMU and thus allows for access to 16 MB on the 80286 and 4 GB on the 80386. The segment descriptors and resolving of these that make this possible can be (ab)used on the 80286 and up by realizing that these segment descriptors are also used in real mode. Unreal mode is thus about switching to protected mode, loading arbitrary segment descriptors and switching back to real mode. As this is outside the original processor spec, it is commonly called ‘unreal mode’.

Continue reading “Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More” →

NIF’s Laser Fusion Experiment’s Energy Gain Passes Peer Review

February 9, 2024 by Maya Posch 53 Comments

Back in December of 2022, a team of researchers at the USA’s National Ignition Facility (NIF) announced that they had exceeded ‘scientific breakeven’ with their laser-based inertial confinement fusion (ICF) system. Their work has now been peer-reviewed and passed scrutiny, confirming that the energy put into fusing a small amount of deuterium-tritium fuel resulted in a net gain (Q) of 1.5.

Laser Bay 2, one of NIF's two laser bays — Laser Bay 2 at the NIF.

The key take-away here of course remains that ICF is not a viable method of producing energy, as we detailed back in 2021 when we covered the 1.3 MJ yield announcement, and again in 2022 following the subject of this now completed peer review. The sheer amount of energy required to produce the laser energy targeting the fuel capsule and loss therein, as well as the energy required to manufacture each of these fuel capsules (Hohlraum) and sustaining a cycle make it a highly impractical proposition for anything except weapons research.

Despite this, it’s good to see that the NIF’s ICF research is bearing fruit, even if for energy production we should look towards magnetic confinement fusion (MCF), which includes the many tokamaks active today like Japan’s JT-60SE, as well as stellarators like Germany’s Wendelstein 7-X and other efforts to make MCF a major clean-energy source for the future.

How Airplanes Mostly Stopped Flying Into Terrain And Other Safety Improvements

February 8, 2024 by Maya Posch 13 Comments

We have all heard the statistics on how safe air travel is, with more people dying and getting injured on their way to and from the airport than while traveling by airplane. Things weren’t always this way, of course. Throughout the early days of commercial air travel and well into the 1980s there were many crashes that served as harsh lessons on basic air safety. The most tragic ones are probably those with a human cause, whether it was due to improper maintenance or pilot error, as we generally assume that we have a human element in the chain of events explicitly to prevent tragedies like these.

Among the worst pilot errors we find the phenomenon of controlled flight into terrain (CFIT), which usually sees the pilot losing track of his bearings due to a variety of reasons before a usually high-speed and fatal crash. When it comes to keeping airplanes off the ground until they’re at their destination, here ground proximity warning systems (GPWS) and successors have added a layer of safety, along with stall warnings and other automatic warning signals provided by the avionics.

With the recent passing of C. Donald Bateman – who has been credited with designing the GPWS – it seems like a good time to appreciate the technology that makes flying into the relatively safe experience that it is today.

Continue reading “How Airplanes Mostly Stopped Flying Into Terrain And Other Safety Improvements” →

A schematic representation of the different ionospheric sub-layers and how they evolve daily from day to night periods. (Credit: Carlos Molina)

Will Large Satellite Constellations Affect Earth’s Magnetic Field?

February 7, 2024 by Maya Posch 48 Comments

Imagine taking a significant amount of metals and other materials out of the Earth’s crust and scattering it into the atmosphere from space. This is effectively what we have been doing ever since the beginning of the Space Age, with an increasing number of rocket stages, satellites and related objects ending their existence as they burn up in the Earth’s atmosphere. Yet rather than vanish into nothing, the debris of this destruction remains partially in the atmosphere, where it forms pockets of material. As this material is often conductive, it will likely affect the Earth’s magnetic field, as argued by [Sierra Solter-Hunt] in a pre-publication article.

A summary by [Dr. Tony Phillips] references a 2023 NASA research article by [Daniel M. Murphy] et al. which describes the discovery that about 10% of the aerosol particles in the stratosphere are aluminium and other metals whose origin can be traced back to the ‘burn-up’ of the aforementioned space objects. This is a factor which can increase the Debye length of the ionosphere. What the exact effects of this may be is still largely unknown, but fact remains that we are launching massively more objects into space than even a decade ago, with the number of LEO objects consequently increasing.

Although the speculation by [Sierra] can be called ‘alarmist’, the research question of what’ll happen if over the coming years we’ll have daily Starlink and other satellites disintegrating in the atmosphere is a valid one. As this looks like it will coat the stratosphere and ionosphere in particular with metal aerosols at levels never seen before, it might be worth it to do the research up-front, rather than wait until we see something odd happening.