Hide Silent, Hide Deep: Submarine Tracking Technologies Of The Cold War

January 10, 2020 by 48 Comments

All through the cold war, there was a high-stakes game of cat and mouse in play. Nuclear powers like the United States and the Soviet Union would hide submarines armed with nuclear missiles underwater. The other side would try to know where they were so they could be targeted in the event of war. The common wisdom was that the United States had many high tech gadgets to help track enemy submarines, but that the Soviet Union was way behind in this area. This was proven false when a Soviet Victor-class boat followed a US missile submarine for six days. Now, a recently declassified CIA report shows how the Soviets didn’t use sonar at all but developed their own technology.

There is something fascinating about submarines. Like an old sailing ship, submarines are often out of touch with their command bases and the captain is the final authority. Like a space ship, the submarine has to survive in an inimical environment. I guess in all three cases, the crew doesn’t just use technology, they depend on it.

Although the submarine has some non-military uses, there are probably more military subs than any other type. After all, a sub is as close to a cloaking device as any real-life military vehicle has ever had. Before modern technology offered ways to find submarines using sonar or magnetic anomalies, a completely submerged submarine was effectively invisible.

There was a lot of speculation that the Soviet Union lacked sufficient technology to use sonar  the way the US did. However, in some cases, they had simply developed different types of detection — many of which the West had discarded as impractical.

Continue reading “Hide Silent, Hide Deep: Submarine Tracking Technologies Of The Cold War” →

This Week In Security: Camera Feeds, Python 2, FPGAs

January 10, 2020 by 6 Comments

Networked cameras keep making the news, and not in the best of ways. First it was compromised Ring accounts used for creepy pranks, and now it’s Xiaomi’s stale cache sending camera images to strangers! It’s not hard to imagine how such a flaw could happen: Xiaomi does some video feed transcoding in order to integrate with Google’s Hub service. When a transcoding slot is re-purposed from one camera to another, the old data stays in the buffer until it is replaced by the new camera’s feed. The root cause is probably the same as the random images shown when starting some 3D games.

Python is Dead, Long Live Python

Python 2 has finally reached End of Life. While there are many repercussions to this change, the security considerations are important too. The Python 2 environment will no longer receive updates, even if a severe security vulnerability is found. How often is a security vulnerability found in a language? Perhaps not very often, but the impact can be far-reaching. Let’s take, for instance, this 2016 bug in zipimport. It failed to sanitize the header of a ZIP file being processed, causing all the problems one would expect.

It is quite possible that because of the continued popularity and usage of Python2, a third party will step in and take over maintenance of the language, essentially forking Python. Unless such an event happens, it’s definitely time to migrate away from Python2.
Continue reading “This Week In Security: Camera Feeds, Python 2, FPGAs” →

Hackaday Podcast 049: Tiny Machine Learning, Basement Battery Bonanza, And Does This Uranium Feel Hot?

January 10, 2020 by 3 Comments

Hackaday editors Mike Szczys and Elliot Williams sort through all of the hacks to find the most interesting hardware projects you may have missed this week. Did you know you can use machine learning without a neural network? Here’s a project that does that on an ATtiny85. We also wrap our minds around a 3D-printed press brake, look at power-saving features of the ESP32 that make it better on a battery, and discuss the IoT coffee maker hack that’s so good it could be a stock feature. Plus we dive into naturally occurring nuclear reactors and admire the common, yet marvelous, bar code.

Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (60 MB or so.)

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast 049: Tiny Machine Learning, Basement Battery Bonanza, And Does This Uranium Feel Hot?” →

Hardware Hack Makes Robocall Blocking Service Even Better

January 10, 2020 by 69 Comments

Sorry to bear sad tidings, but your car’s extended warranty is about to expire. At least that’s what you’ll likely hear if you answer one of those robocalls that have descended like a plague upon us. We applaud any effort to control the flood of robocalls, even if it means supplementing a commercial blocking service with a DIY ring-blocker.

The commercial service that [Jim] engaged to do his landline blocking is called Nomorobo – get it? It uses the Simultaneous Ringing feature many VoIP carriers support to intercept blacklisted robocallers, but with a catch: it needs caller ID data, so it lets the first ring go through. [Jim]’s box intercepts the ringing signal coming from his Xfinity modem using a full-wave rectifier and an analog input on an Arduino. Once the ring pattern is received, the Arduino flips a relay that connects all the phones in the house to the line, letting the call ring through. If Nomorobo has blocked the call, he’ll never hear a thing. There were a few glitches to deal with, like false positives from going off- and on-hook, but those were handled in software. There’s also a delay in displaying caller ID information on his phones, but it’s a small price to pay for peace.

Any escalation in the war on robocalls is justified, and we applaud [Jim] for his service. Should you feel like joining the fray, step one is to know your enemy. This primer on robocalling will help.

Thanks to [Phil] for the tip.

DIY Autonomous Mower In The Wild

January 10, 2020 by 35 Comments

Mowing the lawn is one of those repetitive tasks most of us really wish we had a robot for. [Kenny Trussell] mowing needs are a bit more strenuous than most backyards, so he hacked a ride-on mower to handle multi-acre fields all on it’s own.

The mower started out life as a standard zero turn ride on lawn mower. It’s brains consist of a PixHawk board running Ardurover, an Ardupilot derivative for ground vehicles. Navigation is provided by a RTK GPS module that gets error corrections from a fixed base station via an Adafruit LoRa feather board, to achieve centimetre level accuracy. To control the mower, [Kenny] replaced the pneumatic shocks that centred the control levers with linear actuators.

So far [Kenny] has been using the mower to cut large 5-18 acre fields, which would be a very time-consuming job for a human operator. A relay was added to the existing safety circuit that only allows the mower to function when there is weight on the seat. This relay is wired directly to the RC receiver and is controlled from the hand-held RC transmitter. It will also stop the mower if it loses signal to the transmitter. To set up mowing missions, [Kenny] uses the Ardupilot Mission Planner for which he wrote a custom command line utility to create a concentric route for the mower to follow to completely cover a defined area. He has made a whole series of videos on the process, which is very handy for anyone wanting to do the same. We’re looking forward to a new video with all the latest updates.

This mower has been going strong for two years, but in terms of hours logged it’s got nothing on this veteran robotic mower that’s been at it for more than two decades and still runs off an Intel 386 processor.

A Luggable Computer For The Raspberry Pi Era

January 10, 2020 by 25 Comments

Today, computers are separated into basically two categories: desktops and laptops. But back in the early 1980s, when this ideological line in the sand was still a bit blurry, consumer’s had a third choice. Known as “portable computers” at the time, and often lovingly referred to as luggables by modern collectors, these machines were technically small enough to take with you on a plane or in the car.

Improvements in miniaturization ultimately made the portable computer obsolete, but that doesn’t mean some people still don’t want one. [Dave Estes] has been working on his own modern take on idea that he calls Reviiser, and so far it looks like it checks off all the boxes. With the addition of a rather hefty battery pack, it even manages to be more practical than the vintage beasts that inspired it.

In the video after the break, [Dave] walks us through some of the highlights of his luggable build, such as the fold-down mechanical keyboard, gloriously clunky mechanical power switches, and the integrated touch screen. We also really like the side-mounted touch pad, which actually looks perfectly usable given the largely keyboard driven software environment [Dave] has going on the internal Raspberry Pi 4. With a removable 30,000 mAh battery pack slotted into the back of the machine, he’ll have plenty of juice for his faux-retro adventures.

[Dave] mentions that eventually he’s looking to add support for “cartridges” which will allow the user to easily slot in new hardware that connects to the Pi’s GPIO pins. This would allow for a lot of interesting expansion possibilities, and fits in perfectly with the Reviiser’s vintage aesthetic. It would also go a long way towards justifying the considerable bulk of the machine; perhaps even ushering in a revival of sorts for the luggable computer thanks to hardware hackers who want a mobile workstation with all the bells and whistles.

Right now there isn’t a lot of detail on how you can build your own Reviiser, but [Dave] says more info will be added to his site soon. In the meantime, you can check out some of the similar projects we’ve seen recently to get some inspiration for your own Luggable Pi.

Continue reading “A Luggable Computer For The Raspberry Pi Era” →

HiFi Audio On The Commodore 64 – 48KHz, Yo!

January 9, 2020 by 34 Comments

Prior to the development of CD-quality audio hardware in the mid-1990s, home computers and consoles typically made do with synthesized music. Due to the storage and RAM limitations of the time, there weren’t a whole lot of other practical options. If you’re willing to ignore practicality, however, you can do some wonderful things – such as playing high-quality audio on a Commodore 64!

The project is the work of [Antonio Savona], who set out to play hi-fi audio on a Commodore 64 using only period-correct hardware. That means no 16MB RAM expansions, and no crazy high-capacity carts. The largest carts of the era were just 1MB, as produced by Ocean, and [Antonio] intended to cram in a full 90 seconds of music.

Targeting a sample rate of 48 KHz with 8-bit samples would mean the cartridge could only fit 20 seconds of raw audio into its 1MB of storage. This wasn’t good enough, so the audio would have to be compressed, with the target being a 4:1 ratio to reach the 90 second goal. With the C64’s CPU running at just 1MHz, there are just 21 clock cycles to deal with each sample when playing at 48 KHz.

Obviously, [Antonio] had set quite the challenge, and some masterful assembly coding was used to get the job done. The final result has the audio sounding impressively good, given that it’s being pumped out by a 6502 that is surely sweating to get the job done.

We love a good C64 hack around these parts, and it’s now even possible to build a new one from scratch if that’s your particular itch. Video after the break.

Continue reading “HiFi Audio On The Commodore 64 – 48KHz, Yo!” →