Modded Robot Vacuum Can Whistle While It Works

January 28, 2021 by Tom Nardi 7 Comments

While repairing his Neato Botvac D85, [elad] noticed the little fellow was packing a real speaker and not just a piezo buzzer. Thinking this was a bit overkill just for the occasional beep and bloop, he decided to round things out with a Bluetooth receiver and a second speaker so the bot can spin some stereo tunes while it gets down and dirty.

It wasn’t a very expensive modification. Between the VHM-314 Bluetooth receiver, the 3 watt PAM8403 amplifier, and a matching speaker, [elad] says he was only a few bucks out of pocket. Truly a small price to pay for a robotic vacuum that plays its own theme music as it travels around the house. A small demonstration of the Neato’s new musical talents can be heard in the video after the break.

Perhaps unsurprisingly, the audio hardware puts enough of a drain on the robot’s batteries at max volume that there’s a noticeable reduction in runtime. He’s not too worried about it right now, but [elad] mentions that if it ends up keeping the vacuum from being able to complete it’s whole cleaning cycle, that he might look into adding a dedicated power source to keep the music going.

Despite some early encouragement from iRobot, we haven’t seen quite as much robot vacuum hacking as you might think. It’s always interesting to get a glimpse inside of these automated housekeepers, especially when it’s a custom built machine.

Continue reading “Modded Robot Vacuum Can Whistle While It Works” →

A Look At How Nintendo Mastered Dual Screens

January 28, 2021 by Tom Nardi 24 Comments

When it was first announced, many people were skeptical of the Nintendo DS. Rather than pushing raw power, the unique dual screen handheld was designed to explore new styles of play. Compared to the more traditional handhelds like the Game Boy Advance (GBA) or even Sony’s PlayStation Portable (PSP), the DS seemed like huge gamble for the Japanese gaming giant.

But it paid off. The Nintendo DS ended up being one of the most successful gaming platforms of all time, and as [Modern Vintage Gamer] explains in a recent video, at least part of that was due to its surprising graphical prowess. While it was technically inferior to the PSP in almost every way, Nintendo’s decades of experience in pushing the limits of 2D graphics allowed them to squeeze more out of the hardware than many would have thought possible.

On one level, the Nintendo DS could be seen as a upgraded GBA. Developers who were already used to the 2D capabilities of that system would feel right at home when they made the switch to the DS. As with previous 2D consoles, the DS had several screen modes complete with hardware-accelerated support for moving, scaling, rotating, and reflecting up to four background layers. This made it easy and computationally efficient to pull off pseudo-3D effects such as having multiple backdrop images scrolling by at different speeds to convey a sense of depth.

On top of its GBA-inherited tile and sprite 2D engine, the DS also featured a rudimentary GPU responsible for handling 3D geometry and rendering. Hardware accelerated 3D could only used on one screen at a time, which meant most games would keep the closeup view of the action on one display, and used the second panel to show 2D imagery such as an overhead map. But developers did have the option of flipping between the displays on each frame to render 3D on both panels at a reduced frame rate. The hardware can also handle shadows and included integrated support for cell shading, which was a particularly popular graphical effect at the time.

By combining the 2D and 3D hardware capabilities of the Nintendo DS onto a single screen, developers could produce complex graphical effects. [Modern Vintage Gamer] uses the example of New Super Mario Bros, which places a detailed 3D model of Mario over several layers of moving 2D bitmaps. Ultimately the 3D capabilities of the DS were hindered by the limited resolution of its 256 x 192 LCD panels; but considering most people were still using flip phones when the DS came out, it was impressive for the time.

Compared to the Game Boy Advance, or even the original “brick” Game Boy, it doesn’t seem like hackers have had much luck coming up with ways to exploiting the capabilities of the Nintendo DS. But perhaps with more detailed retrospectives like this, the community will be inspired to take another look at this unique entry in gaming history.

Continue reading “A Look At How Nintendo Mastered Dual Screens” →

Decoding NOAA Satellite Images In Python

January 27, 2021 by Tom Nardi 10 Comments

You’d be forgiven for thinking that receiving data transmissions from orbiting satellites requires a complex array of hardware and software, because for a long time it did. These days we have the benefit of cheap software defined radios (SDRs) that let our computers easily tune into arbitrary frequencies. But what about the software side of things? As [Dmitrii Eliuseev] shows, decoding the data satellites are beaming down to Earth is probably a lot easier than you might think.

Well, at least in this case. The data [Dmitrii] is after happens to be broadcast from a relatively old fleet of satellites operated by the National Oceanic and Atmospheric Administration (NOAA). These birds (NOAA-15, NOAA-18 and NOAA-19) are somewhat unique in that they fly fairly low and utilize a simple analog signal transmitted at 137 MHz. This makes them especially good targets for hobbyists who are just dipping their toes into the world of satellite reception.

Continue reading “Decoding NOAA Satellite Images In Python” →

Raspberry Pi Zero Powers Spotify Streaming IPod

January 27, 2021 by Tom Nardi 32 Comments

Even those critical of Apple as a company have to admit that they were really onto something with the iPod. The click wheel was a brilliant input device, and the simplicity of the gadget’s user interface made it easy to get to the music you wanted with a minimum of hoop jumping. Unfortunately it was a harbinger of proprietary software and DRM, but eventually there were a few open source libraries that let you put songs on the thing without selling your soul to Cupertino.

Of course, modern users expect a bit more than what the old hardware can deliver. Which is why [Guy Dupont] swapped the internals of his iPod Classic with a Raspberry Pi Zero W. This new Linux-powered digital audio player is not only capable of playing essentially any audio format you throw at it, but can also tap into streaming services such as Spotify. But such greatness doesn’t come easy; to pull this off, he had to replace nearly every component inside the player with the notable exception of the click wheel itself. Good thing the Classics were pretty chunky to begin with.

In addition to the Pi Zero running the show, he also had to fit a 1000 mAh battery, its associated charging and boost modules, a vibration motor for force feedback, and a 2″ LCD from Adafruit. The display ended up being almost the perfect size to replace the iPod’s original screen, and since it uses composite video, only took two wires to drive from the Pi. To interface with the original click wheel, [Guy] credits the information he pulled from a decade-old Hackaday post.

Of course with a project like this, the hardware is only half the story. It’s one thing to cram all the necessary components inside the original iPod enclosure, but by creating such an accurate clone of its iconic UI in Python, [Guy] really took things to the next level. Especially since he was able to so seamlessly integrate support for Spotify, a feature the Apple devs could scarcely have imagined back at the turn of the millennium. We’re very interested in seeing the source code when he pushes it to the currently empty GitHub repository, and wouldn’t be surprised if it set off a resurgence of DIY iPod clones.

We’ve seen modern hardware grafted onto the original iPod mainboard, and over the years a few hackers have tried to spin up their own Pi-based portable music players. But this project that so skillfully combines both concepts really raises the bar.

Continue reading “Raspberry Pi Zero Powers Spotify Streaming IPod” →

Chasing Down Bad Caps To Save A Troubled PSU

January 26, 2021 by Tom Nardi 36 Comments

We know what you’re thinking. It’s a bad power supply, of course it was capacitors to blame. But even if we all intuitively know at this point that bad caps are almost always the culprit when a PSU gives up the ghost, it’s not always easy to figure out which one is to blame. Which is why this deep dive into a failed ETK450AWT by [eigma] is worth a look.

The first sign of trouble was when the computer would unexpectedly reboot with nothing in the system logs to indicate a problem. Eventually, [eigma] noticed a restart before the operating system even loaded, which confirmed the hardware was to blame. A quick look at the PSU output with a voltmeter showed things weren’t too far out of spec, but putting an oscilloscope on the 12 V line uncovered a nasty waveform that demanded further investigation.

By carefully following traces and comparing with common PSU diagrams, [eigma] was able to identify the SG5616 IC that checks the various voltages being produced by the PSU and generates the PWR_OK signal which tells the motherboard that everything is working normally. As before, all of the DC voltages at this chip seemed reasonable enough, but the pin that was measuring AC voltage from the transformer was showing the same ripple visible on the 12 VDC line.

Even more digging uncovered that the transformer itself had a control IC nestled away. The 13 VDC required by this chip to operate is pulled off the standby transformer by way of a Zener diode and a couple capacitors, but as [eigma] soon found, the circuit was producing another nasty ripple. Throwing a few new capacitors into the mix smoothed things out and got the PSU to kick on, but that’s not quite the end of the story.

Pulling the capacitors from the board and checking their values with the meter, [eigma] found they too appeared to be within reasonable enough limits. They even looked in good shape physically. But with the help of a signal generator, he was able to determine their equivalent series resistance (ESR) was way too high. Case closed.

While swapping out blown capacitors in older electronics is something of a rite of passage for hardware hackers, this case is an excellent example of how even the simplest of fixes can be tricky to troubleshoot.

What’s The Deal With Chromium On Linux? Google At Odds With Package Maintainers

January 26, 2021 by Tom Nardi 152 Comments

Linux users are more likely than most to be familiar with Chromium, Google’s the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project’s inception over a decade ago, users have been able to compile the BSD licensed code into a browser that’s almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.

A post made earlier this month to the official Chromium Blog explained that an audit had determined “third-party Chromium based browsers” were using APIs that were intended only for Google’s internal use. In response, any browser attempting to access features such as Chrome Sync with an unofficial API key would be prevented from doing so after March 15th.

To the average Chromium user, this doesn’t sound like much of a problem. In fact, you might even assume it doesn’t apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.

Unhappy with the idea of giving users a semi-functional browser, the Chromium maintainers for several distributions such as Arch Linux and Fedora have said they’re considering pulling the package from their respective repositories altogether. With a Google representative confirming the change is coming regardless of community feedback, it seems likely more distributions will follow suit.

Continue reading “What’s The Deal With Chromium On Linux? Google At Odds With Package Maintainers” →

Failed Test Could Further Delay NASA’s Troubled SLS Rocket

January 25, 2021 by Tom Nardi 74 Comments

The January 16th “Green Run” test of NASA’s Space Launch System (SLS) was intended to be the final milestone before the super heavy-lift booster would be moved to Cape Canaveral ahead of its inaugural Artemis I mission in November 2021. The full duration static fire test was designed to simulate a typical launch, with the rocket’s main engines burning for approximately eight minutes at maximum power. But despite a thunderous start start, the vehicle’s onboard systems triggered an automatic abort after just 67 seconds; making it the latest in a long line of disappointments surrounding the controversial booster.

When it was proposed in 2011, the SLS seemed so simple. Rather than spending the time and money required to develop a completely new rocket, the super heavy-lift booster would be based on lightly modified versions of Space Shuttle components. All engineers had to do was attach four of the Orbiter’s RS-25 engines to the bottom of an enlarged External Tank and strap on a pair of similarly elongated Solid Rocket Boosters. In place of the complex winged Orbiter, crew and cargo would ride atop the rocket using an upper stage and capsule not unlike what was used in the Apollo program.

The SLS core stage is rolled out for testing.

There’s very little that could be called “easy” when it comes to spaceflight, but the SLS was certainly designed to take the path of least resistance. By using flight-proven components assembled in existing production facilities, NASA estimated that the first SLS could be ready for a test flight in 2016.

If everything went according to schedule, the agency expected it would be ready to send astronauts beyond low Earth orbit by the early 2020s. Just in time to meet the aspirational goals laid out by President Obama in a 2010 speech at Kennedy Space Center, including the crewed exploitation of a nearby asteroid by 2025 and a potential mission to Mars in the 2030s.

But of course, none of that ever happened. By the time SLS was expected to make its first flight in 2016, with nearly $10 billion already spent on the program, only a few structural test articles had actually been assembled. Each year NASA pushed back the date for the booster’s first shakedown flight, as the project sailed past deadlines in 2017, 2018, 2019, and 2020. After the recent engine test ended before engineers were able to collect the data necessary to ensure the vehicle could safely perform a full-duration burn, outgoing NASA Administrator Jim Bridenstine said it was too early to tell if the booster would still fly this year.

What went wrong? As commercial entities like SpaceX and Blue Origin move in leaps and bounds, NASA seems stuck in the past. How did such a comparatively simple project get so far behind schedule and over budget?

Continue reading “Failed Test Could Further Delay NASA’s Troubled SLS Rocket” →