Keeping Track Of The Night Sky With Discrete Logic Chips

As hobbies go, stargazing has a pretty low barrier to entry. All you really need is a pair of Mark 1 eyeballs and maybe a little caffeine to help you stay up late enough. Astronomy, on the other hand, takes quite a bit more equipment, not least of which is a telescope and a way to get it pointed in the right direction at the right time, and to make up for the pesky fact that we’re on a moving, spinning ball of rock.

Yes, most of the equipment needed for real astronomy is commercially available, but [Mitsuru Yamada] decided to go his own way with this homebrew retro-style telescope motor controller. Dubbed MCT-6, the controller teams up with his dual-6502 PERSEUS-9 computer to keep his scope on target. There are a lot of literally moving parts to this build, including the equatorial mount which is made from machined aluminum and powered by a pair of off-the-shelf stepper-powered rotary stages for declination and right ascension. The controller that runs the motors is built completely from discrete 74HCxx logic chips that divide down a 7.0097-MHz crystal oscillator signal to drive the steppers precisely at one revolution per diurnal day. The pulse stream can also be sped up for rapid slewing, to aim the telescope at new targets using a hand controller.

As impressive as all this is, the real star (sorry) of the show here is the fit and finish. In typical [Yamada-san] fashion, the impeccably wire-wrapped mainboard fits in a robust die-cast aluminum case that fits the retro aesthetic of the whole project. The PERSEUS-9 is used mainly as a display and control terminal, running custom software to show where the telescope is pointed and calculate the coordinates of various heavenly bodies. As a bonus, the 40×7 alphanumeric red LED display should be easy on dark-adapted eyes.

Hats off to [Mitsuru Yamada] on another fabulous build. If you haven’t had enough of his build style yet, be sure to check out his PERSEUS-8 or even his foray into the analog world.

Continue reading “Keeping Track Of The Night Sky With Discrete Logic Chips”

FOSDEM Saved, With 3D Printing

If you were to consider what the most important component of a hacker event might be, the chances are you’d pick something that’s part of the program, the ambiance, or the culture. But as the organizers of FOSDEM in Brussels found out, what’s really the most important part of such an event is the toilet paper.

If you can’t keep the supplies coming, you’re in trouble, and since they only had one key for the dispensers across the whole event, they were heading for a sticky situation. But this is a hacker event, and our community is resourceful. The folks on the FreeCAD booth created a model of the key which they shared via the Ondsel collaboration tools, while those on the Prusa booth fired up their Prusa XL and ran off a set of keys to keep the event well supplied.

Perhaps for many of us, the act of running off a 3D model and printing it is such a mundane task as to be unremarkable — and indeed the speed at which they were able to do it points to it being a straightforward task for them. But the sight of a bunch of hardware hackers saving the event by doing what they do best is still one to warm the cockles of our hearts. We’re fairly certain it’s not the first time we’ve seen a bit of clandestine venue hacking save an event, but perhaps for the sake of those involved, we’d better not go into it.

Better Living Through Biomedical Engineering

We don’t often think of medicine and engineering as being related concepts, and most of the time, they aren’t. But there’s a point where medicine alone may not be enough to treat a particular ailment or injury, and it might be necessary to blend the mechanical with the biological. When a limb is lost, we don’t have the technology to regrow it, but we can apply engineering principles to build a functional facsimile that can help the patient regain lost independence and improve their quality of life.

The area where these two disciplines overlap is called biomedical engineering (BME), and it’s a field that’s seeing fantastic growth thanks to advances in 3D printing, materials science, and machine learning. It’s also a field where open source principles and DIY are making surprising inroads, as hobbyists look to put their own knowledge and experience to use by creating low-cost assistive devices — something we were honored to help facilitate over the years through the Hackaday Prize.

Continue reading “Better Living Through Biomedical Engineering”

Hackaday Podcast Episode 256: 0, 256, 400, 0x100, And 10000000

For this week’s episode, we did something super special — we all convened to answer your burning questions about your hosts, both as hackers and as humans. We kick things off with a segment featuring a hearty round-table discussion between Elliot, Al, Dan, Kristina, and Tom. What’s on our benches? What do we type on? Go find out!

None of us figured out What’s That Sound though a few of us had some creative guesses. Can you guess the sound? There could be a t-shirt in it for ya.

Kristina and Elliot went on to have a normal podcast too, but since the round table section went so long, we’ll process up that section and put it out early next week.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download this epic monument of podcasting and savor it for the next 256 weeks.

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

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.

This Week In Security: Broken Shims, LassPass, And Toothbrushes?

Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?”

Flipped Bit Could Mark The End Of Voyager 1‘s Interstellar Mission

Sometimes it’s hard to read the tea leaves of what’s going on with high-profile space missions. Weighted down as they are with the need to be careful with taxpayer money and having so much national prestige on the line, space agencies are usually pretty cagey about what’s going on up there. But when project managers talk about needing a “miracle” to continue a project, you know things have gotten serious.

And so things now sit with Voyager 1, humanity’s most distant scientific outpost, currently careening away from Mother Earth at 17 kilometers every second and unable to transmit useful scientific or engineering data back to us across nearly a light-day of space. The problem with the 46-year-old spacecraft cropped up back in November, when Voyager started sending gibberish back to Earth. NASA publicly discussed the problem in December, initially blaming it on the telemetry modulation unit (TMU) that packages data from the remaining operable scientific instruments along with engineering data for transmission back to Earth. It appeared at the time that the TMU was not properly communicating with the flight data system (FDS), the main flight computer aboard the spacecraft.

Since then, flight controllers have determined that the problem lies within the one remaining FDS on board (the backup FDS failed back in 1981), most likely thanks to a single bit of corrupted memory. The Deep Space Network is still receiving carrier signals from Voyager, meaning its 3.7-meter high-gain antenna is still pointing back at Earth, so that’s encouraging. But with the corrupt memory, they’ve got no engineering data from the spacecraft to confirm their hypothesis.

The team has tried rebooting the FDS, to no avail. They’re currently evaluating a plan to send commands to put the spacecraft into a flight mode last used during its planetary fly-bys, in the hope that will yield some clues about where the memory is corrupted, if indeed it is. But without a simulator to test the changes, and with most of the engineers who originally built the spacecraft long gone now, the team is treading very carefully.

Voyager 1 is long past warranty, of course, and with an unparalleled record of discovery, it doesn’t owe us anything at this point. But we’re not quite ready to see it slip into its long interstellar sleep, and we wish the team good luck while it works through the issue.