Mysterious Files PH

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.

The weather is warming up, and for many of us that means more time spent working out in the yard. You probably won’t find any new life or new civilizations out there, but if you’ve spent the last few months indoors on your computer, the garden may as well be a strange new world. In that case, you’d do well to equip the members of your landing party with this Star Trek: The Original Series hose sprayer designed by [Curt Turner].

If you’re wondering how [Curt] managed to 3D print a functional hose sprayer, the short answer is that he didn’t. Once assembled, the printed parts cleverly attach to the top of a standard sprayer, specifically the model 56516 “Pro Flo” from Orbit. Without the design constraints that would have come from trying to make the thing actually contain pressurized water, [Curt] was free to focus on the aesthetics, and it shows.

Even with a garden variety — no pun intended — sprayer strapped to the bottom, it’s remarkable how much the “Sprayser” looks like the real thing. Well, not real, but you know what we mean.

[Curt] has also done an excellent job documenting this project for others that want to imagine they’re fighting off Romulans in their backyard. He’s got assembly diagrams that break down which color each of the principle components is to be printed in, as well as a build video that we’ve embedded below.

We’ve seen a fair number of Star Trek props built over the years, some of which have packed in considerably more functionality than anything they would have had back on the set. These days you can even by an officially licensed tricorder that can actually do some of the things the fictional versions were capable of.

No, we’re not talking about cultural appropriation of Japan’s most famous form of short poem–this is the other Haiku, the open-source descendant of BeOS, which now has a fully-native meshcore chat client called Sestriere, thanks to the efforts of one [Atomozero]. Of course you’ll need a LoRa radio to act as a modem, but anything that speaks USB serial– which is any of the ESP32-based offerings on the market–should work.

This is interesting in that we don’t see many desktop applications leveraging LoRa networks– meshtastic or meshcore– so for one to appear for the relatively-obscure BeOS derivative is just neat. It’s also a nice peice of work: the chat window is full featured, organizing your contacts, and communicating not just with text but emojis and reaction GIFs. GIFs seem a bit extravagant for LoRa bandwith, but apparently it works. There are also Codec2-based voice messages, another thing that we didn’t expect to see over LoRa, since most ‘chat’ projects restrict themselves to text messaging.

The software will also map all the nodes with which you are in contact, both diagrammatically and geographically, overlaid on OpenStreetMap tiles. The network map conveniently colour-codes your contacts by the link quality, but what’s even more interesting is the WireShark-inspired packet sniffer built into the software to let you keep a really close eye on traffic on the mesh network.

Neither Haiku or MeshCore are to everyone’s tastes, but as an OS it is a worthy daily driver, even if you have to jump through some hoops to install it if you have a UEFI-only system.

If you need more range, try a Yagi.

As straightforward as the concept of taking battery packs out of an old electric or hybrid car and reusing them for home power storage sounds, this thought process skips a few essential steps. As argued by [Ed] in a recent video based on his own experiences with high-voltage Nissan Leaf batteries in a home PV system, the main problem is that you’re taking a battery out of a larger system including a lot of the management hardware and software.

The referenced Battery Emulator project is an open source effort to create a suitable interface between these EV batteries, with the mentioned Nissan Leaf being just one example in the project Wiki, with the connection scheme shown in the top image. It’s also noted that the Leaf battery BMS is not designed to operate continuously, so they need to be restarted every day or so lest they become too inaccurate.

These and other things are all solid reasons why you have to be absolutely certain that you want to integrate these high-voltage battery packs into your 12 – 48V low-voltage DC system. You’re after all assuming all the responsibility of setting up a system that’s both safe and reliable, so having a good read through something like the Battery Emulator Wiki and sourcing first-hand experiences from the folk in this community would be a very wise first step.