Tactical Build Makes Machining Splined Shaft A Snap

Quick, what’s 360 divided by 23? It’s easy enough to get the answer, of course, but if you need to machine a feature every 15.652 degrees around a shaft, how exactly would you accomplish that? There are a number of ways, but they all involve some degree of machining wizardry. Or, you can just make the problem go away with a little automation.

The story behind [Tony Goacher]’s Rotary Table Buddy begins with some ATV tracks he got off AliExpress. His idea is to build a specialty electric vehicle for next year’s EMF Camp. The tracks require a splined shaft to drive them, which would need to be custom-made on a milling machine. A rotary table with a dividing plate — not as fancy as this one, of course –is usually the answer, but [Tony] was a little worried about getting everything set up correctly, so he embarked on a tactical automation solution to the problem.

An RP2040 provided the brains of the project, while a NEMA 23 stepper provides the brawn. [Tony] whipped up a quick PCB and 3D printed a case for the microcontroller, a stepper driver, an LCD display, and a few buttons. He 3D printed an adapter and a shaft coupler to mount the stepper motor to a rotary table. From there it was just a matter of coming up with a bit of code to run everything.

There’s a brief video in [Tony]’s blog post that shows Rotary Table Buddy in action, indexing to the next position after cutting one of the 23 splines. He says it took about ten minutes to cut each spline using this setup, which probably makes to total cutting time far less than the amount of time invested in the tool. But that’s hardly the point, and besides, now he’s set up for all kinds of machining operations in the future.

And we sure hope we hear about the EMF Camp build, too.

Op-Amp Challenge: Light Up Breadboard Shows Us The Signals

Most Hackaday readers will no doubt at some point used a solderless breadboard for prototyping. They do the job, but sometimes their layout can be inflexible and keeping track of signals can be a pain. There’s a neat idea from [rasmusviil0] which might go some way to making the humble breadboard easier to use, it’s a breadboard in which each line is coupled via an op-amp buffer to an LED. In this way it can be seen at a glance some indication of the DC voltage present.

It’s an idea reminiscent of those simple logic probes which were popular years ago, but its implementation is not entirely easy. Each circuit is simple enough, but to replicate it across all the lines in a breadboard makes for a huge amount of quad op-amp chips stuffed onto one piece of stripboard as well as a veritable forest of wires beneath the board.

The effect is of a breadboard crossed with a set of blinkenlights, and we could see that for simple digital circuits it could have some utility if not so much for higher frequency or analogue signals. Certainly it’s an experiment worth doing, and indeed it’s not the first tricked out breadboard we’ve seen.

Linux Fu: Supercharge Bash History

Having a history of shell commands is a great idea. It is, of course, enormously handy when you have to run something repetitively or you make a simple mistake that needs correction. However, as I’ve mentioned in the past, bash history isn’t without its problems. For one thing, by default, you don’t get history in one window from typing in another window. If you use a terminal multiplexer or a GUI, you are very likely to have many shells open. You can make them share history, but that comes with its own baggage. If you think about it, we have super fast computers with tons of storage compared to the “old days,” yet shell history is pretty much the same as it has been for decades. But [Rcaloras] did think about it and created Bashhub, a history database for bash, zsh, and probably some other shells, too.

Command detail screen

You might think you don’t need anything more than what you have, and, of course, you don’t. However, Bashhub offers privately stored and encrypted history across machines. It also provides context about commands you’ve executed in the past. In other words, you can see the directory you were in, the exact time and date, the system you were on, and the last return code of the command.

Continue reading “Linux Fu: Supercharge Bash History”

Hackaday Podcast 217: The Unintentional Space And 3D Printing Episode

Hackaday Editors Elliot Williams and Tom Nardi definitely didn’t plan on devoting most of this episode to 3D printing and space stories, but let’s be honest, it was bound to happen sooner or later. After an update on the Hackaday Prize, the discussion moves on to a pair of troubled spacecraft and the challenges of exploring the final frontier. From there you’ll hear about a chocolate 3D printer we’ve had our eyes on for years, the tools you should have next to your own (non-chocolate) 3D printer, and a bit of contemplation of what it really means to design for 3D printing versus traditional manufacturing methods. But it’s not all plastic fantastic — by the end of the episode you’ll also hear about some particularly bold high-altitude aviators and the surprisingly short time we have left with the humble barcode.

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!

Going to be stranded on a desert island? Download the podcast now!

Continue reading “Hackaday Podcast 217: The Unintentional Space And 3D Printing Episode”

A History Of NASA Supercomputers, Among Others

The History Guy on YouTube has posted an interesting video on the history of the supercomputer, with a specific focus on their use by NASA for the implementation of computational fluid dynamics (CFD) models of aeronautical assemblies.

The aero designers of the day were quickly finding out the limitations of the wind tunnel testing approach, especially for so-called transonic flow conditions. This occurs when an object moving through a fluid (like air can be modeled) produces regions of supersonic flow mixed in with subsonic flow and makes for additional drag scenarios. This severely impacts aircraft performance. Not accounting for these effects is not an option, hence the great industry interest in CFD modeling. But the equations for which (usually based around the Navier-Stokes system) are non-linear, and extremely computationally intensive.

Obviously, a certain Mr. Cray is a prominent player in this story, who, as the story goes, exhausted the financial tolerance of his employer, CDC, and subsequently formed Cray Research Inc, and the rest is (an interesting) history. Many Cray machines were instrumental in the development of the space program, and now adorn computing museums the world over. You simply haven’t lived until you’ve sipped your weak lemon drink whilst sitting on the ‘bench’ around an early Cray machine.

You see, supercomputers are a different beast from those machines mere mortals have access to, or at least the earlier ones were. The focus is on pure performance, ideally for floating-point computation, with cost far less of a concern, than getting to the next computational milestone. The Cray-1 for example, is a 64-bit machine capable of 80 MIPS scalar performance (whilst eating over 100 kW of juice), and some very limited parallel processing ability.

While this was immensely faster than anything else available at the time, the modern approach to supercomputing is less about fancy processor design and more about the massive use of parallelism of existing chips with lots of local fast storage mixed in. Every hacker out there should experience these old machines if they can, because the tricks they used and the lengths the designers went to get squeeze out every ounce of processing grunt, can be a real eye-opener.

Want to see what happens when you really push out the boat and use the whole wafer for parallel computation? Checkout the Cerberus. If your needs are somewhat less, but dabbling in parallel computing gets you all pumped, you could build a small array out of Pine64s. Finally, the story wouldn’t be complete without talking about the life and sad early demise of Seymour Cray.
Continue reading “A History Of NASA Supercomputers, Among Others”

This Week In Security: Oracle Opera, Passkeys, And AirTag RFC

There’s a problem with Opera. No, not that kind of opera. The Oracle kind. Oracle OPERA is a Property Management Solution (PMS) that is in use in a bunch of big-name hotels around the world. The PMS is the system that handles reservations and check-ins, talks to the phone system to put room extensions in the proper state, and generally runs the back-end of the property. It’s old code, and handles a bunch of tasks. And researchers at Assetnote found a serious vulnerability. CVE-2023-21932 is an arbitrary file upload issue, and rates at least a 7.2 CVSS.

It’s a tricky one, where the code does all the right things, but gets the steps out of order. Two parameters, jndiname and username are encrypted for transport, and the sanitization step happens before decryption. The username parameter receives no further sanitization, and is vulnerable to path traversal injection. There are two restrictions to exploitation. The string encryption has to be valid, and the request has to include a valid Java Naming and Directory Interface (JNDI) name. It looks like these are the issues leading Oracle to consider this flaw “difficult to exploit vulnerability allows high privileged attacker…”.

The only problem is that the encryption key is global and static. It was pretty straightforward to reverse engineer the encryption routine. And JDNI strings can be fetched anonymously from a trio of endpoints. This lead Assetnote to conclude that Oracle’s understanding of the flaw is faulty, and a much higher CVSS score is appropriate. Particularly with this Proof of Concept code, it is relatively straightforward to upload a web shell to an Opera system.

The one caveat there is that an attacker has to get network access to that install. These aren’t systems intended to be exposed to the internet, and my experience is that they are always on a dedicated network connection, not connected to the rest of the office network. Even the interconnect between the PMS and phone system is done via a serial connection, making this network flaw particularly hard to get to. Continue reading “This Week In Security: Oracle Opera, Passkeys, And AirTag RFC”

Linux Cell Phone? Build OURPhone

[Evan] couldn’t find a phone he liked, so he decided to build his own. There are advantages and disadvantages, as you might expect. On the plus side, you have the ultimate control. On the negative side, it doesn’t quite have the curb appeal — at least to the average user — of a sleek new cell phone from a major manufacturer.

The phone uses a Raspberry Pi, along with a 4G modem and a 480×800 touchscreen. There’s a laser cut box that measures 90x160x30 mm. For reference, a Google Pixel 7 is about 73x156x9 mm, so a little easier on the pocket.

But not one the pocketbook. The OURPhone only costs about $200 USD to build. There are trade-offs. For example, the touchscreen is resistive, so you’ll want a stylus (there’s a slot for it in the case). On the other hand, if you don’t like something, it is all there for you to change.

Obviously, a better screen would help. Thinner batteries might be a good enhancement too. But that’s the beauty of an open project. You can do all these things and more.

We wondered if you could get one of the “mobile” Linux editions to run or even Android. It seems like the hardest part is coming up with a sophisticated enclosure.