Apollo Comms Flight Hardware Deep Dive

You no doubt recall the incredible Apollo Guidance Computer (AGC) reverse engineering and restoration project featured on the CuriousMarc YouTube channel a few years ago. Well, [Marc] and the team are at it again, this time restoring the Apollo Unified S-Band tracking and communication system flight hardware. As always, the project is well documented, carefully explained, full of problems, and is proceeding slowly despite the lack of documentation.

Like the guidance computer, the Unified S-Band system was pretty innovative for its day — able to track, provide voice communications, receive television signals, and send commands to and monitor the health of the spacecraft via telemetry. The system operates on three frequencies, an uplink containing ranging code, voice and data. There are two downlinks, one providing ranging, voice, and telemetry, the other used for television and the playback of recorded data. All crammed into two hefty boxes totaling 29 kg.

So far, [Marc] has released part 9 of the series (for reference, the Apollo Guidance Computer took 27 parts plus 8 auxiliary videos). There seems to be even less documentation for this equipment than the AGC, although miraculously the guys keep uncovering more and more as things progress. Also random pieces of essential ground test hardware keep coming out of the woodwork. It’s a fascinating dive into not only the system itself, but the design and construction techniques of the era. Be sure to check out the series (part 1 is below the break) and follow along as they bring this system back to life. [Marc] is posting various documents related to the project on his website. And if you missed the AGC project, here’s the playlist of videos, and the team joined us for a Hackaday Chat back in 2020.

Continue reading “Apollo Comms Flight Hardware Deep Dive”

New Privacy Policy Gets Audacity Back On Track

Regular readers will likely be aware of the considerable debate over changes being made to the free and open source audio editor Audacity by the project’s new owners, Muse Group. The company says their goal is to modernize the 20 year old GPLv2 program and bring it to a larger audience, but many in the community have questioned whether the new managers really understand the free software ethos. An already precarious situation has only been made worse by a series of PR blunders Muse Group has made over the last several months.

But for a change, it seems things might be moving in the right direction. In a recent post to Audacity’s GitHub repository, Muse Group unveiled the revised version of their much maligned Privacy Policy. The announcement also came with an admission that many of the key elements from the draft version of the Privacy Policy were poorly worded and confusing. It seems much of the problem can be attributed to an over-analysis of the situation; with the company inserting provocative boilerplate protections (such as a clause saying users must be over the age of 13) that simply weren’t necessary.

Ultimately, the new Privacy Policy bears little resemblance to the earlier draft. Which objectively, is a good thing. But it’s still difficult to understand why Muse Group publicly posted such a poorly constructed version of the document in the first place. Project lead Martin Keary, better known online as Tantacrul, says the team had to consult with various legal teams before they could release the revised policy. That sounds reasonable enough, but why where these same teams not consulted before releasing such a spectacularly ill-conceived draft?

The new Privacy Policy makes it clear that Audacity won’t be collecting any user data, and what little personally identifiable information Muse Group gets from the application when it automatically checks for an update (namely, the client’s IP address) isn’t being stored. It’s further explained in the GitHub post that the automatic update feature only applies to official binary builds of Audacity, meaning it will be disabled for Linux users who install it through their distribution’s package repository. The clause about working with unnamed law enforcement agencies has been deleted, as has the particularly troubling age requirement.

Credit where credit is due. Muse Group promised to revise their plans for adding telemetry to Audacity, and judging by the new Privacy Policy, it seems they’ve done an admirable job of addressing all of the issues brought up by the community. Those worried their FOSS audio editor of choice would start spying on them can rest easy. Unfortunately the issue of Audacity’s inflammatory Contributor License Agreement (CLA) has yet to be resolved, meaning recently christened forks of the audio editor dedicated to preserving its GPLv2 lineage are unlikely to stand down anytime soon.

Hacking A Solar Inverter RF Interface

One of the main advantages of cheap wireless modules is that they get used in consumer electronics, so if you know what’s being used you can build your own compatible hardware. While investigating the RF interface used in a series of cheap “smart” solar inverters [Aaron Christophel], created an Arduino library to receive inverter telemetry using a $2 RF module. See the demonstration after the break.

[Aaron] bought the inverter and ~40 euro USB “Data Box” that allows the user to wirelessly monitor the status of the inverter. Upon opening the two units, he found that they used LC12S 2.4Ghz modules, which create a wireless UART link. With a bit of reverse engineering, he was able to figure out the settings for the RF modules and the serial commands required to request the status of the inverter. He doesn’t delve into the possible security implications, but there doesn’t appear to be any form of encryption in the link. It should be possible for anyone with a module to sniff the messages, extract the ID of the inverter, and hijack the link. Just knowing the status of the inverter shouldn’t be all that dangerous, but he doesn’t mention what other commands can be sent to the module. Any others could have more severe implications.

Sniffing the wireless signal flashing through the air around us is a regular topic here on Hackaday. From testing the security of WiFi networks with an ESP32 to monitoring SpaceX launches with an SDR, the possibilities are infinite.

Continue reading “Hacking A Solar Inverter RF Interface”

Telemetry Debate Rocks Audacity Community In Open Source Dustup

Starting an open source project is easy: write some code, pick a compatible license, and push it up to GitHub. Extra points awarded if you came up with a clever logo and remembered to actually document what the project is supposed to do. But maintaining a large open source project and keeping its community happy while continuing to evolve and stay on the cutting edge is another story entirely.

Just ask the maintainers of Audacity. The GPLv2 licensed multi-platform audio editor has been providing a powerful and easy to use set of tools for amateurs and professionals alike since 1999, and is used daily by…well, it’s hard to say. Millions, tens of millions? Nobody really knows how many people are using this particular tool and on what platforms, so it’s not hard to see why a pull request was recently proposed which would bake analytics into the software in an effort to start answering some of these core questions.

Now, the sort of folks who believe that software should be free as in speech tend to be a prickly bunch. They hold privacy in high regard, and any talk of monitoring their activity is always going to be met with strong resistance. Sure enough, the comments for this particular pull request went south quickly. The accusations started flying, and it didn’t take long before the F-word started getting bandied around: fork. If Audacity was going to start snooping on its users, they argued, then it was time to take the source and spin it off into a new project free of such monitoring.

The situation may sound dire, but truth be told, it’s a common enough occurrence in the world of free and open source software (FOSS) development. You’d be hard pressed to find any large FOSS project that hasn’t been threatened with a fork or two when a subset of its users didn’t like the direction they felt things were moving in, and arguably, that’s exactly how the system is supposed to work. Under normal circumstances, you could just chalk this one up to Raymond’s Bazaar at work.

But this time, things were a bit more complicated. Proposing such large and sweeping changes with no warning showed a troubling lack of transparency, and some of the decisions on how to implement this new telemetry system were downright concerning. Combined with the fact that the pull request was made just days after it was announced that Audacity was to be brought under new management, there was plenty of reason to sound the alarm.

Continue reading “Telemetry Debate Rocks Audacity Community In Open Source Dustup”

Fun While It Lasted, Falcon 9 Telemetry Now Encrypted

A few weeks back we brought word that Reddit users [derekcz] and [Xerbot] had managed to receive the 2232.5 MHz telemetry downlink from a Falcon 9 upper stage and pull out some interesting plain-text strings. With further software fiddling, the vehicle’s video streams were decoded, resulting in some absolutely breathtaking shots of the rocket and its payload from low Earth orbit.

Unfortunately, it looks like those heady days are now over, as [derekcz] reports the downlink from the latest Falcon 9 mission was nothing but intelligible noise. Since the hardware and software haven’t changed on his side, the only logical conclusion is that SpaceX wasn’t too happy about radio amateurs listening in on their rocket and decided to employ some form of encryption.

Since this data has apparently been broadcast out in the clear for nearly a decade before anyone on the ground noticed, it’s easy to see this as an overreaction. After all, what’s the harm in a few geeks with hacked together antennas getting a peek at a stack of Starlink satellites? [derekcz] even mused that allowing hobbyists to capture these space views might earn the company some positive buzz, something Elon Musk never seems to get enough of.

Some of the images [derekcz] was able to capture from the Falcon 9

On the other hand, we know that SpaceX is actively pursuing more lucrative national security launch contracts for both the Falcon 9 and Falcon Heavy. For these sensitive government payloads, the normal on-screen telemetry data and space views are omitted from the company’s official live streams. It seems likely the Pentagon would be very interested in finding out how civilians were able to obtain this information, and a guarantee from SpaceX that the link would be encrypted for all future flights could have helped smooth things over.

At the end of the post [derekcz] echos a sentiment we’ve been hearing from other amateur radio operators  recently, which is that pretty soon space may be off-limits for us civilians. As older weather satellites begin to fail and get replaced with newer and inevitably more complex models, the days of picking up satellite images with an RTL-SDR and a few lines of Python are likely numbered.

A Look Behind The “Big Boards” At Mission Control In The Golden Age Of NASA

Certified space-nerd and all-around retro-tech guru [Fran Blanche] has just outdone herself with a comprehensive look at how NASA ran the Mission Control “Big Boards” that provided flight data for controllers for Apollo and for the next 20 years of manned spaceflight.

We’ve got to admit, [Fran] surprised us with this one. We had always assumed that the graphs and plots displayed in front of the rows of mint-green consoles and their skinny-tie wearing engineers were video projections using eidophor projectors. And to be sure, an eidophor, the tech of which [Jenny] profiled a while back, was used on one of the screens to feed video into Mission Control, either live from the Moon or from coverage of the launch and recovery operations. But even a cursory glance at the other screens in front of “The Pit” shows projections of a crispness and clarity that was far beyond what 1960s video could achieve.

Instead, plots and diagrams were projected into the rear of the massive screens using a completely electromechanical system. Glass and metal stencils were used to project the icons, maps, and grids, building up images layer by layer. Colors for each layer were obtained by the use of dichroic filters, and icons were physically moved to achieve animations. Graphs and plots were created Etch-a-Sketch style, with a servo-controlled stylus cutting through slides made opaque with a thin layer of metal. The whole thing is wonderfully complex, completely hacky, and a great example of engineering around the limits of technology.

Hats off to [Fran] for digging into this forgotten bit of Space Race tech. Seeing something like this makes the Mission Control centers of today look downright boring by comparison.

Continue reading “A Look Behind The “Big Boards” At Mission Control In The Golden Age Of NASA”

Raspberry Pi Helps Racer Master The Track

Looking to give himself a competitive edge, racer [Douglas Hedges] wanted to come up with a system that could give him real-time feedback on how his current performance compared to his previous fastest lap time. Armed with a Raspberry Pi and some Python libraries, he set out to add a simple telemetry system to his car. But as is often the case with these kind of projects, things just started snowballing from there.

The Raspberry Pi based data acquisition system.

At the most basic level, his system uses GPS position and speed information to light up a strip of RGB LEDs on the dashboard: green means he’s going faster than the previous best lap, and red means he isn’t. Any interface more complex than that would just be a distraction while he focuses on the track. But that doesn’t mean the Raspberry Pi can’t collect data for future review after the race is over.

With the basic functionality in place, [Douglas] turned his attention to collecting engine performance data. It turned out the car already had some pre-existing equipment for collecting metrics such as the air-fuel ratio and RPM, which he was able to connect to the Raspberry Pi thanks to its use of a well documented protocol. On top of that he added a Labjack U3 data acquisition system which let him pull in additional information like throttle position and coolant temperature. Grafana is used to visualize all of this data after the race, though it sounds like he’s also considering adding a cellular data connection vehicle data can be streamed out in real-time.

In the past we’ve seen onboard data collection systems make real-world races look more like their virtual counterparts, but it seems like the solution [Douglas] has come up with is more practical in the heat of the moment.

Continue reading “Raspberry Pi Helps Racer Master The Track”