[NullPxl]’s Ban-Rays concept is a wearable that detects when one is in the presence of camera-bearing smartglasses, such as Meta’s line of Ray-Bans. A project in progress, it’s currently focused on how to reliably perform detection without resorting to using a camera itself. Right now, it plays a well-known audio cue whenever it gets a hit.

Currently, [NullPxl] is exploring two main methods of detection. The first takes advantage of the fact that image sensors in cameras act as tiny reflectors for IR. That means camera-toting smartglasses have an identifying feature, which can be sensed and measured. You can see a sample such reflection in the header image, up above.

As mentioned, Ban-Rays eschews the idea of using a camera to perform this. [NullPxl] understandably feels that putting a camera on glasses in order to detect glasses with cameras doesn’t hold much water, conceptually.

The alternate approach is to project IR in a variety of wavelengths while sensing reflections with a photodiode. Initial tests show that scanning a pair of Meta smartglasses in this way does indeed look different from regular eyeglasses, but probably not enough to be conclusive on its own at the moment. That brings us to the second method being used: wireless activity.

Characterizing a device by its wireless activity turned out to be trickier than expected. At first, [NullPxl] aimed to simply watch for BLE (Bluetooth Low-Energy) advertisements coming from smartglasses, but these only seem to happen during pairing and power-up, and sometimes when the glasses are removed from the storage case. Clearly a bit more is going to be needed, but since these devices rely heavily on wireless communications there might yet be some way to actively query or otherwise characterize their activity.

This kind of project is something that is getting some interest. Here’s another smartglasses detector that seems to depend entirely on sniffing OUIs (Organizationally Unique Identifiers); an approach [NullPxl] suspects isn’t scalable due to address randomization in BLE. Clearly, a reliable approach is still in the works.

The increasing numbers of smartglasses raises questions about the impact of normalizing tech companies turning people into always-on recording devices. Of course, the average person is already being subtly recorded by a staggering number of hidden cameras. But at least it’s fairly obvious when an individual is recording you with a personal device like their phone. That may not be the case for much longer.

We love a good clock project, and [byeh_ in] has one with a design concept we don’t believe we have seen before. The Trace Line Clock has smooth lines and a clean presentation, with no sockets or visible mechanical fixtures.

Reading the clock is quite straightforward once one knows what is going on. At its heart, the unmarked face is much like any other analog clock face, and on the inside is a pretty normal clock movement. The inner recessed track on the face represents hours, and the outer is minutes. The blue line connects the two, drawing a constantly changing line.

To make the blue segment move without breaking the lines of the clock, [byeh_ in] uses magnets. The inside end moves around the inner ring with the hour hand, while the rest of the blue segment follows the minute hand. Since the length between these two points is not constant, [byeh_ in] cleverly designed one of the magnets to be floating. By keeping the magnet captive in a channel on the underside of the blue segment, the whole thing moves smoothly, no matter how the two ‘hands’ align.

Speaking of smooth, it’s important for the parts to move together with minimal friction. To achieve this [byeh_ in] uses something we think is under-utilized in 3D printed parts: candle wax. Wax is non-greasy, sticks well to 3D printed parts simply by rubbing, slides easily, and doesn’t make a mess. Directions and 3D models are available should you wish to try making your own.

We’re always delighted by the amazingly different ways people can re-imagine a clock. From clocks with hands but void of a face to clocks made out of clocks, we love to see ’em so if you’ve got a favorite, drop us a tip!

[VWestlife] purchased all kinds of USB video capture devices — many of them from the early 2000s — and put them through their paces in trying to digitize VHS classics like Instant Fireplace and Buying an Auxiliary Sailboat. The results were actually quite varied, but almost universally bad. They all worked, but they also brought unpleasant artifacts and side effects when it came to the final results. Sure, the analog source isn’t always the highest quality, but could it really be this hard to digitize a VHS tape?

It turns out there’s an exception to all the disappointment: the Sony Digital Video Media Converter (DVMC) is a piece of vintage hardware released in 1998 that completely outperformed the other devices [VWestlife] tested. There is a catch, but it’s a small one. More on that in a moment.

Unlike many other capture methods, the DVMC has a built-in time base corrector that stabilizes analog video signals by buffering them and correcting any timing errors that would cause problems like jitter or drift. This is a feature one wouldn’t normally find on budget capture devices, but [VWestlife] says the Sony DVMC can be found floating around on eBay for as low as 20 USD. It even has composite and S-Video inputs.

For an old device, [VWestlife] says using the DVMC was remarkably smooth. It needed no special drivers, defaults to analog input mode, and can be powered over USB. That last one may sound trivial, but it means there’s no worry about lacking some proprietary wall adapter with an oddball output voltage.

The catch? It isn’t really a USB device, and requires a FireWire (IEEE-1394) port in order to work. But if that’s not a deal-breaker, it does a fantastic job.

So if you’re looking to digitize older analog media, [VWestlife] says it might be worth heading to eBay and digging up a used Sony DVMC. But if one wants to get really serious about archiving analog media, capturing RF signals direct from the tape head is where it’s at.

Thanks to [Keith Olson] for the tip!

[Michael Lynch] recently decided to delve into the world of off-grid, decentralized communications with MeshCore, because being able to communicate wirelessly with others in a way that does not depend on traditional communication infrastructure is pretty compelling. After getting his hands on a variety of hardware and trying things out, he wrote up his thoughts from the perspective of a hardware-curious software developer.

He ends up testing a variety of things: MeshCore firmware installed on a Heltec V3 board (used via an app over Bluetooth), a similar standalone device with antenna and battery built in (SenseCAP T-1000e, left in the header image), and a Lilygo T-Deck+ (right in the header image above). These all use MeshCore, which is built on and reportedly compatible with Meshtastic, a framework we have featured in the past.

The first two devices are essentially MeshCore gateways, to which the user connects over Bluetooth. The T-Deck is a standalone device that resembles a Blackberry, complete with screen and keypad. [Michael] dove into what it was like to get them up and running.

Probably his most significant takeaway was that the whole process of onboarding seemed a lot more difficult and much less clear than it could be. This is an experience many of us can relate to: the fragmented documentation that exists seems written both by and for people who are already intimately familiar with the project in its entirety.

Another thing he learned was that while LoRa is a fantastic technology capable of communicating wirelessly over great distances with low power, those results require good antennas and line of sight. In a typical urban-ish environment, range is going to be much more limited. [Michael] was able to get a maximum range of about five blocks between two devices. Range could be improved by purchasing and installing repeaters or by having more devices online and in range of one another, but that’s where [Michael] drew the line. He felt he had gotten a pretty good idea of the state of things by then, and not being a radio expert, he declined to purchase repeater hardware without any real sense of where he should put them, or what performance gains he could expect by doing so.

Probably the most surprising discovery was that MeshCore is not entirely open source, which seems odd for an off-grid decentralized communications framework. Some parts are open, but the official clients (the mobile apps, web app, and T-Deck firmware) are not. [Michael] found this out when, being primarily a software developer, he took a look at the code to see if there was anything he could do to improve the poor user experience on the T-Deck and found that the firmware was proprietary.

[Michael]’s big takeaway as a hardware-curious software developer is that the concept is great and accessible (hardware is not expensive and there is no licensing requirement for LoRa), but it’s not really there yet in terms of whether it’s practical for someone to buy a few to distribute among friends for use in an emergency. Not without getting into setting up enough repeaters to ensure connectivity, anyway.

Who’s interested in a brand new, from-scratch boundary representation (BREP) kernel? How about one that has no topological naming problem, a web-native parametric CAD front end to play with, and has CAD-type operations making friends with triangle meshes? If you’re intrigued, check out [mmiscool]’s BREP project.

Functioning (let alone feature-filled, or efficient) CAD systems are not a software project we see a whole lot of. Ones that represent models as genuine BREP structures but cleverly use mesh-based operations where it makes sense? Even less so.

In theory, CAD programs are simple: allow a user to define features, keep track of what they are and how they relate to one another, and perform operations on them as requested. In practice, it’s significant work. Chains of operations and dependencies easily become complex, volatile things and there is really no room for error.

Read [Arya Voronova]’s best practices for using FreeCAD to get a few hints as to what goes on behind the scenes in a modern CAD program, and the kinds of challenges the back end has to deal with, like the topological naming problem (TNP). A problem [mmiscool]’s implementation completely avoids, by the way.

There is a live demo at BREP.io which acts as a playground for the state of the project. You can get started by clicking the + button towards the top on the left panel to add features and operations to the history (like add a cube, then add chamfers or fillets, or extrude a face, and so on).

[mmiscool] points out that all computation is done client-side; even complex operations like fillets, lofts, and multi-body booleans execute directly in the browser with no need to be offloaded to a back end. BREP’s development is being documented on Hackaday.io and there is a video embedded below that gives an overview. Why don’t you give it a spin?

Ever heard of MUMPS? Both programming language and database, it was developed in the 1960s for the Massachusetts General Hospital. The goal was to streamline the increasingly enormous timesink that information and records management had become, a problem that was certain to grow unless something was done. Far from being some historical footnote, MUMPS (Massachusetts General Hospital Utility Multi-Programming System) grew to be used by a wide variety of healthcare facilities and still runs today. If you’ve never heard of it, you’re in luck because [Asianometry] has a documentary video that’ll tell you everything.

MUMPS had rough beginnings but ultimately found widespread support and use that continues to this day. As a programming language, MUMPS (also known simply as “M”) has the unusual feature of very tight integration with the database end of things. That makes sense in light of the fact that it was created to streamline the gathering, processing, and updating of medical data in a busy, multi-user healthcare environment that churned along twenty-four hours per day.

It may show its age (the term “archaic” — among others — gets used when it’s brought up) but it is extremely good at what it does and has a proven track record in the health care industry. This, combined with the fact that efforts to move to newer electronic record systems always seem to find the job harder than expected, have helped keep it relevant. Have you ever used MUMPS? Let us know in the comments!

And hey, if vintage programming languages just aren’t unusual enough for you, we have some truly strange ones for you to check out.

Sometimes it makes sense to go with plain old batteries and off-the-shelf PVC pipe. That’s the thinking behind [Bertrand Selva]’s clever LoRaTube project.

LoRa is a fantastic solution for long-range and low-power wireless communication (and popular, judging by the number of projects built around it) and LoRaTube provides an autonomous repeater, contained entirely in a length of PVC pipe. Out the top comes the antenna and inside is all the necessary hardware, along with a stack of good old D-sized alkaline cells feeding a supercap-buffered power supply of his own design. It’s weatherproof, inexpensive, self-contained, and thanks to extremely low standby current should last a good five years by [Bertrand]’s reckoning.

One can make a quick LoRa repeater in about an hour but while the core hardware can be inexpensive, supporting electronics and components (not to mention enclosure) for off-grid deployment can quickly add significant cost. Solar panels, charge controllers, and a rechargeable power supply also add potential points of failure. Sometimes it makes more sense to go cheap, simple, and rugged. Eighteen D-sized alkaline cells stacked in a PVC tube is as rugged as it is affordable, especially if one gets several years’ worth of operation out of it.

You can watch [Bertrand] raise a LoRaTube repeater and do a range test in the video (French), embedded below. Source code and CAD files are on the project page. Black outdoor helper cat not included.

[Aditya Sripada] and [Abhishek Warrier]’s TARS3D robot came from asking what it would take to make a robot with the capabilities of TARS, the robotic character from Interstellar. We couldn’t find a repository of CAD files or code but the research paper for TARS3D explains the principles, which should be enough to inspire a motivated hacker.

What makes TARS so intriguing is the simple-looking structure combined with distinct and effective gaits. TARS is not a biologically-inspired design, yet it can walk and perform a high-speed roll. Making real-world version required not only some inspired mechanical design, but also clever software with machine learning.

[Aditya] and [Abhishek] created TARS3D as a proof of concept not only of how such locomotion can be made to work, but also as a way to demonstrate that unconventional body and limb designs (many of which are sci-fi inspired) can permit gaits that are as effective as they are unusual.

TARS3D is made up of four side-by-side columns that can rotate around a shared central ‘hip’ joint as well as shift in length. In the movie, TARS is notably flat-footed but [Aditya] found that this was unsuitable for rolling, so TARS3D has curved foot plates.

The rolling gait is pretty sensitive to terrain variations, but the walking gait proved to be quite robust. All in all it’s a pretty interesting platform that does more than just show a TARS-like dual gait robot can be made to actually work. It also demonstrates the value of reinforcement learning for robot gaits.

A brief video is below in which you can see the bipedal walk in action. Not that long ago, walking robots were a real challenge but with the tools available nowadays, even a robot running a 5k isn’t crazy.

[Slant 3D] has a useful video explaining some thoughtful CAD techniques for designing 3D printed pins that don’t break and the concepts can be extended to similar features.

Sure, one can make pins stronger simply by upping infill density or increasing the number of perimeters, but those depend on having access to the slicer settings. If someone else is printing a part, that part’s designer has no actual control over these things. So how can one ensure sturdier pins without relying on specific print settings? [Slant 3D] covers two approaches.

The first approach includes making a pin thick, making it short (less leverage for stress), and adding a fillet to the sharp corner where the pin meets the rest of the part. Why? Because a rounded corner spreads stress out, compared to a sharp corner.

Those are general best practices, but there’s even more that can be done with microfeatures. These are used to get increased strength as a side effect of how a 3D printer actually works when making a part.

One type of microfeature is to give the pin a bunch of little cutouts, making the cross-section look like a gear instead of a circle. The little cutouts don’t affect how the pin works, but increase the surface area of each layer, making the part stronger.

A denser infill increases strength, too. Again, instead of relying on slicer settings, one can use microfeatures for a similar result. Small slots extending down through the pin (and going into the part itself) don’t affect how the part works, but make the part sturdier. Because of how filament-based 3D printing works, these sorts of features are more or less “free” and don’t rely on specific printer or slicer settings.

[Slant 3D] frequently shares design tips like this, often focused on designing parts that are easier and more reliable to print. For example, while printers are great at generating useful support structures, sometimes it’s better and easier in the long run to just design supports directly into the part.

[Metal Massacre Fab Shop] has a review of a portable plasma cutter that ends up being a very good demonstration of exactly what these tools are capable of. If you’re unfamiliar with this kind of work, you might find the short video (about ten minutes, embedded below) to be just the right level of educational.

Plasma cutters work by forcing compressed air through a small nozzle, and ionizing it with a high voltage. This process converts the gas into a very maneuverable stream of electrically-conductive, high-temperature plasma which can do useful work, like cutting through metal. The particular unit demonstrated also has a rust removal function. By operating at a much lower level, the same plasma stream can be used to give an effect not unlike sandblasting.

Of course, an economical way to cut metal is to just wield a grinder. But grinders are slow and not very maneuverable. That’s where a plasma cutter shines, as [Metal Massacre Fab Shop] demonstrates by cutting troublesome locations and shapes. He seems a lot more satisfied with this unit than he was with the cheapest possible (and misspelled!) plasma cutter he tried last year.

And should you want a plasma cutter, and aren’t afraid to salvage components? Consider building your own.

Rolling two six-sided dice (2d6) gives results from 2 to 12 with a bell curve distribution. Seven being the most common result, two and twelve being the least common. But what if one could do this with a single die?

As part of research Putting Rigid Bodies to Rest, researchers show that a single eleven-sided asymmetric shape can deliver the same results. That is to say, it rolls numbers 2 to 12 in the same distribution as 2d6. It’s actually just one of the oddball dice [Hossein Baktash] and his group designed so if you find yourself intrigued, be sure to check out the 3D models and maybe print your own!

The research behind this is a novel method of figuring out what stable resting states exist for a given rigid body, without resorting to simulations. The method is differentiable, meaning it can be used not just to analyze shapes, but also to design shapes with specific properties.

For example, with a typical three-sided die each die face has an equal chance of coming up. But [Hossein] shows (at 8:05 in the video, embedded below) that it’s possible to design a three-sided die where the faces instead have a 25%-50%-25% distribution.

How well do they perform in practice? [Hossein] has done some physical testing showing results seem to match theory, at least when rolled on a hard surface. But we don’t think anyone has loaded these into an automated dice tester, yet.

Things are cooler when rack-mounted, and [KellerLab] aims to make that all far more accessible with the HomeRacker, a modular and 3D-printable rack building system designed to let you rack-mount to your heart’s content. While it can handle big things, it seems especially applicable to tasks like mounting one’s home network equipment and Raspberry Pi machines.

The basic system (or core) consists of three different parts: supports, connectors, and lock pins. The supports are the main structural bars, the connectors mostly go at the corners, and the lock pins ensure everything stays put. The nominal sizing is a 15 mm x 15 mm profile for the supports, with lengths being a multiple of 15 mm.

All is designed with 3D printing in mind, and requires no tools to assemble or disassemble. There are design elements we really appreciate, like how parts are printed at an angle, which improves strength while eliminating the need for supports. The lock pins (and the slots into which they go) are designed so that they are effective and will neither rattle nor fall out.

But the core system is just the foundation. There’s plenty of modularity and expansions to handle whatever one may need, from Gridfinity shelves and drawers to various faceplates and other modules. There are some example applications available from [KellerLab]’s HomeRacker models page, like CD shelf, under-desk drawer, or filament rack.

[KellerLab] welcomes any collaboration, so check out the GitHub repository for CAD references and design files.

One last point to make about the value of printing objects like this at an angle: not only can the resulting layer lines provide better strength and reduce or eliminate the need for supports, but printing at an angle can help hide layer lines.

Can a shape pass through itself? That is to say, if one had two identical solids, would it be possible to orient one such that a hole could be cut through it, allowing the other to pass through without breaking the first into separate pieces? It turns out that the answer is yes, at least for certain shapes. Recently, two friends, [Sergey Yurkevich] and [Jakob Steininger], found the first shape proven not to have this property.

Back in the late 1600s, Prince Rupert of the Rhine proved it was possible to accomplish this feat with two identical cubes. One can tilt a cube just so, and the other cube can fit through a tunnel bored through it. A representation is shown here.

Later, researchers showed this was also true of more complex shapes. This ability to pass unbroken through a copy of oneself became known as Rupert’s Property. Sometimes it’s an amazingly tight fit, but it seems to always work.

In fact, it was so difficult to find candidates for exceptions to this that it was generally understood and accepted by mathematicians that every convex polyhedron (that is, every shape with flat sides and no holes, protrusions, or indentations) would have Rupert’s property. Until one was found that did not.

The first shape proven not to be able to pass through itself — known as the Noperthedron — is a vaguely ball-like shape, with a flat top and bottom. A fan has already added a cavity to create a 3D-printable pencil holder version of the noperthedron (shown here) if you want your own.

There are other promising candidate objects (they are rare) that may also lack Rupert’s property, but so far, this is the only proven one.

Shapes with unusual properties are interesting, and we love how tactile and visual they are. Consider Penrose tiles, a tile set that can cover any size of area without repeating. For decades, the minimum number of tile shapes needed to accomplish this was two. Recently, though, the number has dropped to one thanks to a shape known as “the hat.”