Mysterious Files PH

Although in our imagination those scale models of cars certainly can drive and steer just like their full-scale counterparts, there’s something incredibly satisfying about watching them truly come to life. Here [diorama111] is an absolute master at the craft, with the most recent conversion of a 1:150 Toyota Probox car model once again demonstrating these skills with casual ease.

We previously covered such conversions, with another recent one in 2024 involving another 1:150 scale model. That particular one demonstrated driving around on scale model roads, which shows a good practical use of this conversion if you want to have e.g. a scale model town with cars that actually drive around.

In the video you can see how first the base of the scale model has a tiny 25 mAh Li-polymer battery installed, along with two motors, one for steering and one for driving using a rod-linkage system and a lead screw.

The tiny gears used were salvaged from mechanical watches, with photoreflectors keeping track of the driving and steering positions. Remote control is done by infrared, with a tiny SMD IR receiver module in the car, while charging and programming of the MCU is done via terminals installed on the bottom.

In the final part of the video the car is demonstrated driving around, with working head- and rear lights, as well as blinkers and stop lights, including the top rear one. In the video description links are provided to the various schematics and software on Google Drive for those who are feeling like a fun Sunday afternoon project.

Sometimes it’s useful to add extra mass to a 3D print, and [Joe Fedewa] shared a simple and effective technique that uses plaster of Paris. Rather than pause the print and insert hardware or weighted bits inside, he designed the base as hollow. Not in the sense of zero infill, but in the sense of modeling a cavity into the open bottom of the object.

After the print is complete, he mixes the dry plaster with water until it creates a thick but pourable mixture. Then the object gets turned upside-down and the cavity filled. In about an hour, it will have set up enough to be handled and worked.

Plaster of Paris has a good heft to it, but more importantly it can be made perfectly presentable thanks to being very friendly to post-processing. Any rough spots can be easily sanded and the whole bottom smoothed, so one doesn’t even need to cap it off. Completely cured plaster can be sealed with a clear coat for a more durable finish, if desired.

This basic concept has been used in other ways, such as reinforcing prints with concrete to yield parts solid enough to make tools out of. But using plaster of Paris not just to add mass, but specifically to create a presentable surface that doesn’t need covering up is a neat and highly economical adaptation of the idea.

Other methods of adding mass to a 3D print include inserting metal balls or chunky nuts, bolts, or other hardware, but this method doesn’t require pausing prints to insert things. Nor does it require sealing off or capping the print, messing with goopy epoxies or resins, or spending a lot of money — making it a good one to keep in mind in case it comes in handy someday.

Last week, Elliot got his foot stepped on by a 1.5 metric ton draft horse, and boy is he glad to be back to the relative safety of podcasting! Joining him today is Jenny List, no stranger to farm life, who has been trodden by a cow. It’s going to be one of those podcasts, folks.

Another thing the two hosts have in common is a love for the mystery of the numbers station. But did you know that GPS satellites, for the last 20 years, have broadcast literally millions of secret messages to everyone on the earth with a receiver? After that bombshell, we have an ATtiny85 emulating an 8080, a primer on how to embed magnets in 3D prints, definitive proof that more than one cassette mechanism is still being manufactured, and a look at what makes home automation enthusiasts tick.

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 in DRM-free MP3 and play it in space.

Episode 373 Show Notes:

News:

• No news is good news.  No Mailbag, on the other hand, is no fun!  Write or mail in a question to mailbag@hackaday.com.

What’s That Sound:

• Jenny came in with a sound this week. Have a guess at it!

Interesting Hacks of the Week:

• • Spy Tech: The GPS Numbers Station
    • New address for GNSS data and products – GFZ GNSS Observatory
    • Investigation into September 2020 GPS SVN 74 Performance Anomaly
  • Secret Radio Stations By The Numbers
    • Numbers Station Simulator, Right In Your Browser
  • An Unlikely Host For An 8080 Emulator
    • Because You Can: Linux On An Arduino Uno
  • Ways To Embed Magnets In 3D Prints And Not Ruin Printers
  • As It Turns Out, There’s More Than One Cassette Mechanism Being Made After All
    • Know Audio: Mixtapes, Tape Loops, And Razor Blades
  • Vintage Turntable Gets Brain Transplant And Home Assistant Integration
  • Connecting Your Car To Home Assistant
  • Print Your Own Robby The Robot
    • 3D Printing Computer Space

Quick Hacks:

• • • Elliot’s Picks:
      • The Winners Of The 2025 Obfuscated C Code Contest
      • If You Want To Hack Me, Come In Through The Speaker
      • Pico-Driven Ultrasound Enables Scaled Acoustic Model Of Home Stereo
      • Optimizing Pancakes From Chemical Principles
    • Jenny’s Picks:
      • Re-Enable All Compute Units On The PS5-like BC-250 Cryptomining Card
      • Less Than 10 Years? Commonwealth Fusion Systems Applies To Plug Into Grid In 2030s
      • A New Life For A Rare Console

Can’t-Miss Articles:

• • • Questions Remain About Tense Moment Aboard ISS
    • NASA Announces Artemis III Crew And Ambitious Goals
    • 10 Years Ago: EVA 23 – How A High Visibility Close Call Cut Short a Spacewalk – NASA
    • Remember When Flash Drives Were Going To Make Your PC Faster?

What counts as portable is somewhat a matter of opinion, especially over the years. [Helge Fykse] has a portable spy radio of Swedish origin. For its time, it was considered very portable, crammed into a good-sized suitcase.

You can see the large crystal that sets the transmit frequency and a key to send Morse code. The receiver has a VFO, so it was more agile. Based on the regenerative knob, it appears the receiver was of the regenerative type. The suitcase had its own battery, and with tubes, it could probably put out some kind of signal if connected to anything metal, like bedsprings, a clothesline, or anything. There was a lightbulb to let you see when you were transmitting maximum power.

Speaking of tubes, there were five inside, two for the transmitter and three for the receiver. The radio had storage for spare tubes, and the agent could maintain the radio in the field.

You not only get a peek inside the suitcase, but a look at the schematic. The radio is a model of simplicity, but we are certain it did its job.

We love looking at exotic spy gear, especially radios.

Unlike on Mars where for decades we have had dozens of orbital and ground-based platforms zipping and scurrying about to prod at every bit of emitted radiation, rock type and twitch of dust devils in its thin atmosphere, for other planets and their moons we have to do a lot more speculative interpretation of data. Such was the case with the presumed existence of water plumes on Jupiter’s moon Europa. These now appear to have been a statistical fluke, per research by [L. Roth] et al. in Astronomy & Astrophysics.

As succinctly summarized in the article on this by [Javier Barbuzano] of Sky and Telescope, the original 2013 finding of said water plumes by the same team was based on faint UV emissions from Europa’s southern hemisphere as captured by the Hubble Space Telescope. However, in more recent captures these emissions were not detected again, leading them to reexamine their original analysis of the 2013 data.

One of the main flaws was in the assumption of where Europe was located on Hubble’s 1,000 x 1,000 resolution detector, with the re-analysis showing that they were off by a couple of pixels. A second flaw was quite understandable as since 2013 we have learned that Europa has a thin hydrogen exosphere which interacts with the Sun’s UV radiation. The resulting scattering induces a UV glow which could be mistaken for UV radiation emanating from the moon’s surface.

Even with this one intriguing feature turning out to be a mirage, it doesn’t make Europa any less interesting as it’s still assumed to have vast liquid water oceans. Along with Uranus’ moon Miranda this makes it very worth it to experience more of the sights and sounds of these alien worlds, whether in person or via our robotic friends.

If you work with radio, the chances are that before too long you’ll be winding an inductor. At radio frequencies these won’t be big chunky transformer style chokes, but often air-cored affairs supported by their own rigidity. As grizzled old radio amateurs will tell you though, relying on such a coil for stability is a fool’s errand. It will shift inductance from the slightest movement, thermal expansion, or even sound. Luckily [SolderSmoke] is here to remind us of the trusty fix, in the form of Q-dope, or a polystyrene solution that dries to form a rigid low-dielectric coating.

Where this is being written it wasn’t on the market so it was more usual to use nail lacquer, but reading the piece it seems American hams swore by the stuff. That’s in the past tense because it seems it’s no longer on the market. Even there though help is at hand, because dissolving packaging polystyrene in solvent yields an acceptable substitute. There’s even an 11-year-old how-to video linked from the SolderSmoke post, should you fancy making some of your own. We suggest you proceed with caution though, polymers dissolved in solvents sounds a lot like home-made napalm, and probably puts out fumes you don’t want to breathe.

Meanwhile should you fancy experiments of your own with inductors, we’ve got you covered.

The world of software has seen many paradigms come and go, all of which were supposed to revolutionize its development. Still, one of the basic tenets in engineering of there being no shortcuts to just doing the work properly also rings true in the field of software engineering: trying to skip ‘nice to haves’ like proper documentation, code formatting, and proper testing inevitably results in developers nervously trying to ignore the looming avalanche of technical and other project debts as they keep piling up.

While Test-Driven Development (TDD) once got praised as the silver bullet, the principle of writing tests before writing code merely postpones the inevitable project collapse. The elephant in the room is that you cannot pass on the basics in engineering and expect to come out fine on the other end. There’s a reason why phrases like “all tests green, successfully failed in production” have become common.

This is where the concept of Comment-Driven Development (CDD) comes into play. What started as a bit of a joke many years ago stuck in my mind and led me to my current approach in software development that tries to effectively mirror solid engineering principles.

Defining Comments

In the field of software engineering, code comments are often regarded as a bit of an unloved stepchild. No developer regards them in the same way, few appreciate them, most neglect them and some outright banish them from their lives. The most extreme response here is probably that of the Clean Code movement, who together with the Self-Documenting Code crowd insist that inline comments in particular are unnecessary, an eyesore and that beautiful, well-written code documents itself.

Then there are those who use comments as a (temporary) crutch, as in what is referred to as ‘comment programming‘.  This puts comments in the place where code is supposed to go, for either later replacement or to elucidate a specific aspect. None of this uses comments consistently to provide a parallel flow with the code that explains the what, why and how of said code.

Why this matters is that despite claims to the contrary, reading and understanding code is hard. Grasping architectural decisions and intuitively separating them from quick hacks is hard even if you’re reading back your own code after a few development cycles. This is also basically why writing documentation based on just code with at most spotty inline commentary is a nightmare at best.

After working with a variety of (commercial) codebases over the years that were practically dripping technical debt and regrets – as well as writing comprehensive documentation for some of them – I have become convinced that comments are ultimately the Alpha and Omega of a healthy codebase and up to date documentation.

Software Engineering

Although most people see the finished product of engineering and believe that that’s all there’s to it, the truth is that before that bridge, high-rise building or even some fancy electronic widget sees the light of day, most of the work has already happened. Building it is then theoretically as easy as following the provided instructions.

An essential point here is the assumption that said instructions are half-way correct and you don’t end up building your very own Millennium Tower.

Thus the process of engineering begins with the list of requirements. These have to be chiseled into the hardest of stone, as any change here will have potentially massive repercussions. From these requirements you can then begin to work on a design document that details the overall design of the product, from which the desired architecture follows.

While the specific details will differ for each specific field of engineering, it is this condensing from an abstract idea into increasingly more concrete steps that enables for all angles to be considered before committing to a specific decision that can be hard to revert or change later. In the case of the aforementioned Millennium Tower project, those in charge omitted steps like peer review, where an external set of eyes is asked to give their two cents, because this would have ‘taken too long’.

From Design To Code

Even if in general software is easier to change than e.g. the blueprints for a civil engineering project, you still want to avoid having to go back repeatedly to change or modify parts of a codebase. To this end you do not want to write code until you are very confident that said code is proper and correct.

Fortunately, with the detailed design document and architectural planning already in the bag you can then start start the feedback loop of laying out the foundations, with any obvious issues discovered during this phase being used to improve the design and architectural documentation.

Laying out these foundations involves creating the codebase’s basic layout, including details like creating header and source files with appropriate naming. Next, within these files the architectural structure is laid out, such as creating the skeletons of types, classes, functions and methods that establish the APIs.

For each file a heading comment block is added that briefly summarizes the file’s purpose, the features contained therein, as well as a truncated change list with date and name, for accountability.

At this point we are ready to pour in the details of each compile unit’s implementation, starting by taking the design and related documents and turning the details contained therein into comments that describe the overarching design decisions, special considerations, the flow within a section and any interactions with other modules.

An example of this can be found in my Sarge command line argument parsing library, which both in its C++ and Ada form would be a very hairy mess of logic to keep track of without having the continuous flow of thought describing what is happening, why it’s happening and relevant implications.

Although it may seem simple and obvious, doing this consistently and in a way that doesn’t leave future you staring dumbfounded at a section of code, or chasing red herrings during a debugging session due to a flawed assumption is somewhat of an art. Here it’s crucial that whenever you find yourself in such a state that the relevant inline comments are updated or new ones added as necessary to prevent future confusion.

It shouldn’t even have to be said that keeping these comments – and related documentation – updated whenever code changes are made is absolutely paramount as well. While it’s ‘boring’ work, you don’t do it for your present self, but your future self and/or fellow developers who’ll otherwise use extremely colorful language related to your person.

Documentation And Tests

Writing the documentation with CDD starts from the first list of requirements, with the design document being the next major part, both providing the higher-level overview of the project before diving into the nitty-gritty of the architecture and implementation.

What the best approach here is largely depends on the project and who might be interested in documentation and to which extent. For a typical commercial project where there never is budget for ‘writing documentation’, simply having the design document and the detailed inline comments in the source might be what one has to settle for.

Here it might also be possible to use said inline comments to generate e.g. API listings from with tools such as Doxygen. My own experiences with such tools are mixed, but in a CDD context such auto-generated documentation could be significantly more useful, not to mention accurate.

Finally, any tests required to test specific functionality would be defined along with the code’s architecture, letting it define the testing scope rather than vice versa. With APIs for modules already settled early on, writing unit- and integration tests tends to be a lot easier and without the nagging and nebulous goal of that mystical ‘100% test coverage’.

Mitigating Circumstances

Of course, not every software project is the same, especially for hobbyist projects where you’re often the sole maintainer. It is here your prerogative to take all the shortcuts you want, as long as it is in the knowledge that you’ll only have yourself to blame.

This is why some of my projects are definitely a bit more loose in their adherence to CDD, while others are a complete stickler. for example, when I created my NyanSD network service discovery protocol, I started by writing out a complete requirements and design document, including the protocol itself. By following the top-down CDD approach here I was able to design and implement the entire protocol in the course of about two days, and have it mostly work first try.

Ultimately, CDD in my eyes is the correct approach to software engineering, as it saves a lot of time while being the only approach that actually follows basic engineering principles. You can change the field, but ultimately both physics and underlying hardware remain just as unimpressed by your personal views on how things ought to work.