Weasley Clock For Magically Low Cost

For those unfamiliar with the details of the expansive work of fiction of Harry Potter, it did introduce a few ideas that have really stuck in the collective conscious. Besides containing one of the few instances of time travel done properly and introducing a fairly comprehensive magical physics system, the one thing specifically that seems to have had the most impact around here is the Weasley family clock, which shows the location of several of the characters. We’ve seen these built before in non-magical ways, but this latest build seeks to drop the price tag on one substantially.

To do this, the build relies on several low-cost cloud computing solutions and smartphone apps to solve the location-finding problem. The app is called OwnTracks and is an open-source location tracker which can report data to any of a number of services. [Simon] sends the MQTT data to a cloud-based solution called HiveMQCloud, but you could send it anywhere in principle. With the location tracking handled, he turns to some very low-cost Arduinos to control the stepper motors which point the clock hands to the correct locations on the face.

While the build does rely on a 3D printer for some of the internal workings of the clock, this does bring the cost down substantially when compared to other options. Especially when compared to this Weasley family clock which was built into a much larger piece of timekeeping equipment, having an option for a lower-cost location-tracking clock face like this one is certainly welcome.

2022 Hackaday Prize: Boondock Echo Connects Your Radios With The Cloud

[Mark J Hughes] volunteers as a part of a local community fire watch which coordinates by radio. The La Habra Heights region of Los Angeles is an area of peaks and valleys, which makes direct radio connections challenging. Repeaters work well for range improvement, but in such areas, there is no good place to locate these. [Mark] says that during an emergency (such as a wildfire) the radio usage explodes, with him regularly tracking as many as eight radio frequencies and trying to make sense of it, whilst working out how to send the information on and to whom.

This led him together with collaborator [Kaushlesh Chandel] to create Project Boondock Echo, to help alleviate some of the stress of it all. The concept is to use a cheap Baofeng radio to feed into a gateway based around an ESP32 audio development kit. Mount this in a box with a LiPo based power supply, and you’ve got yourself a movable radio-to-cloud time-shift audio recorder.

By placing one or more of these units in the properties of several of the community group radio operators, all messages can be captured to an audio file, tagged with the radio frequency and time of transmission, and uploaded to a central server. From there they can be retrieved by anybody with access, no matter the physical location, only an internet connection is needed.

The next trick that can be performed, is to reverse the process and queue up previous recordings, and send it back over the cloud to remote locations for re-transmission via radio into the field. This is obviously a massive asset, because wherever there is some urbanization, there is likely an internet connection. With the addition of a Boondock Echo unit, anyone that has a receiver within a few miles can be fully connected with what’s going on outside the range of direct radio communications.

Source for the ESP32’s firmware as well as the web side of things can found on the project Boondock Echo GitHub, complete with some STLs for a 3D printed box to sit it in. Like always, there’s more than one way to solve a particular problem. Here’s an amateur radio repeater based using an RTL-SDR and a Raspberry Pi.

Against The Cloud

One of our writers is working on an article about hosting your own (project) website on your own iron, instead of doing it the modern, cloudy-servicey way. Already, this has caused quite a bit of hubbub in the Hackaday Headquarters. Who would run their own server in 2022, and why?

The arguments against DIY are all strong. If you just want to spin up a static website, you can do it for free in a bazillion different places. GitHub’s Pages is super convenient, and your content is version controlled as a side benefit. If you want an IoT-type data-logging and presentation service, there are tons of those as well — I don’t have a favorite. If you want e-mail, well, I don’t have to tell you that a large American search monopoly offers free accounts, for the low price of slurping up all of your behavioral data. Whatever your need, chances are very good that there’s a service for you out there somewhere in the cloud.

And that’s awesome if you only want the service provided. But what if you want to play around? Or learn how it all works under the hood? This is Hackaday!

For instance, you could run your own mail server just for your friends and family. The aforementioned search monopolist will probably flag all of your e-mail as spam, partly because they don’t trust small e-mail providers, and partly because that’s the “m” in monopoly. But if you can get folks to whitelist the addresses, you’ll be in business. And then you open up a world of fun and foolery. You can write hooks to automatically handle mail, or you can create an infinite number of mail accounts, even on the fly as per Spamgourmet, the most awesome anti-spam tool of the last 30 years. Or you can invent your own. Run a mailing list for your relatives. Or do something stupid.

I used to run a service where, when a particular account received an e-mail, the attached photo was pushed up to a website with the subject line as the caption. Instant photo-blog, of the strangest and least secure sort. Getting it running was a few lines of Bash scripting, and an afternoon of fun. Is there a service that does this, already existing in the cloud? Probably. One that allows you a little privacy and doesn’t track your every move? Maybe. But even if there is, would I have learned about sendmail by using this service? Nope!

I hear you saying “security” under your breath, and you’re right. This system was secured by lock made of purest obscurity. But still, in seven years of running the service, nobody guessed the magic e-mail address, not once. Knowledge of the e-mail address was essentially a password, but if I needed extra security I probably could have implemented it in a few lines of Bash anyway. The webpage itself was static HTML, so good luck with that, Hackerman! (The site’s been down for a while now, so you missed your chance.)

If you just want a service, you can be served. But if you want to be a server, a first-class Internet citizen, with your own cloud in the sky, nothing’s stopping you either. And in contrast to using someone else’s computers, running your own is an invitation to play. It’s a big, Internet-connected sandbox. There are an infinity of funny ideas out there that you can implement on your own box, and a lot to learn. If you hack on someone else’s box, it’s a crime. If you hack on your own, it’s a pleasure.

I know it’s anachronistic, but give it a try. (PDF, obscenity, uncorrected typos.) Be your own cloud.

DOOM Played By Tweet

Getting DOOM to run on hardware it was never intended to run on is a tradition as old as time. Old cell phones, embedded systems, and ancient televisions have all been converted to play this classic first-person shooter. This style of playing games on old hardware might be passé now as the new trend seems to be the ability to play this game on more ethereal platforms instead. This project brings DOOM to Twitter.

The gameplay is a little nontraditional as well. To play the game, a tweet needs to be sent with specific instructions for the bot. The bot then plays the game according to its instructions and then tweets a video. By responding to this tweet with more instructions, the player can continue the game tweet-by-tweet. While slightly cumbersome, it does have the advantage of allowing a player to resume any game simply by responding to the tweet where they would like to start. Behind the scenes of the DOOM-playing Twitter bot is interesting as well and the code is available on the project’s GitHub page.

While we’ve seen plenty of DOOM instances on all kinds of hardware, it’s safe to say we’ve never really seen a gameplay experience quite like this one. It may stay as a curiosity, but DOOM porters are always looking for something else to run this classic game so it may eventually branch out or develop into something more user-friendly like this cloud-based Atari 2600.

Spaghetti Detective Users Boiled By Security Gaffe

For readers that might not spend their free time watching spools of PLA slowly unwind, The Spaghetti Detective (TSD) is an open source project that aims to use computer vision and machine learning to identify when a 3D print has failed and resulted in a pile of plastic “spaghetti” on the build plate. Once users have installed the OctoPrint plugin, they need to point it to either a self-hosted server that’s running on a relatively powerful machine, or TSD’s paid cloud service that handles all the AI heavy lifting for a monthly fee.

Unfortunately, 73 of those cloud customers ended up getting a bit more than they bargained for when a configuration flub allowed strangers to take control of their printers. In a frank blog post, TSD founder Kenneth Jiang owns up to the August 19th mistake and explains exactly what happened, who was impacted, and how changes to the server-side code should prevent similar issues going forward.

Screenshot from TSD web interface
TSD allows users to remotely manage and monitor their printers.

For the record, it appears no permanent damage was done, and everyone who was potentially impacted by this issue has been notified. There was a fairly narrow window of opportunity for anyone to stumble upon the issue in the first place, meaning any bad actors would have had to be particularly quick on their keyboards to come up with some nefarious plot to sabotage any printers connected to TSD. That said, one user took to Reddit to show off the physical warning their printer spit out; the apparent handiwork of a fellow customer that discovered the glitch on their own.

According to Jiang, the issue stemmed from how TSD associates printers and users. When the server sees multiple connections coming from the same public IP, it’s assumed they’re physically connected to the same local network. This allows the server to link the OctoPrint plugin running on a Raspberry Pi to the user’s phone or computer. But on the night in question, an incorrectly configured load-balancing system stopped passing the source IP addresses to the server. This made TSD believe all of the printers and users who connected during this time period were on the same LAN, allowing anyone to connect with whatever machine they wished.

Changed TSD code from GitHub
New code pushed to the TSD repository limits how many devices can be associated with a single IP.

The mix-up only lasted about six hours, and so far, only the one user has actually reported their printer being remotely controlled by an outside party. After fixing the load-balancing configuration, the team also pushed an update to the TSD code which puts a cap on how many printers the server will associate with a given IP address. This seems like a reasonable enough precaution, though it’s not immediately obvious how this change would impact users who wish to add multiple printers to their account at the same time, such as in the case of a print farm.

While no doubt an embarrassing misstep for the team at The Spaghetti Detective, we can at least appreciate how swiftly they dealt with the issue and their transparency in bringing the flaw to light. This is also an excellent example of how open source allows the community to independently evaluate the fixes applied by the developer in response to a discovered flaw. Jiang says the team will be launching a full security audit of their own as well, so expect more changes getting pushed to the repository in the near future.

We were impressed with TSD when we first covered it back in 2019, and glad to see the project has flourished since we last checked in. Trust is difficult to gain and easy to lose, but we hope the team’s handling of this issue shows they’re on top of things and willing to do right by their community even if it means getting some egg on their face from time to time.

Cloud-Based Atari Gaming

While the Google Stadia may be the latest and greatest in the realm of cloud gaming, there are plenty of other ways to experience this new style of gameplay, especially if you’re willing to go a little retro. This project, for example, takes the Atari 2600 into the cloud for a nearly-complete gaming experience that is fully hosted in a server, including the video rendering.

[Michael Kohn] created this project mostly as a way to get more familiar with Kubernetes, a piece of open-source software which helps automate and deploy container-based applications. The setup runs on two Raspberry Pi 4s which can be accessed by pointing a browser at the correct IP address on his network, or by connecting to them via VNC. From there, the emulator runs a specific game called Space Revenge, chosen for its memory requirements and its lack of encumbrance of copyrights. There are some limitations in that the emulator he’s using doesn’t implement all of the Atari controls, and that the sound isn’t available through the remote desktop setup, but it’s impressive nonetheless

[Michael] also glosses over this part, but the Atari emulator was written by him “as quickly as possible” so he could focus on the Kubernetes setup. This is impressive in its own right, and of course he goes beyond this to show exactly how to set up the cloud-based system on his GitHub page as well. He also thinks there’s potential for a system like this to run an NES setup as well. If you’re looking for something a little more modern, though, it is possible to set up a cloud-based gaming system with a Nintendo Switch as well.

Continue reading “Cloud-Based Atari Gaming”