Issac Asimov wrote Caves of Steel in 1953. In it, he mentions something called trimensional personification. In an age before WebEx and Zoom, imagining that people would have remote meetings replete with 3D holograms was pretty far-sighted. We don’t know if any Google engineers read the book, but they are trying to create a very similar experience with project Starline.
The system is one of those that seems simple on the face of it, but we are sure the implementation isn’t easy. You sit facing something that looks like a window. The other person shows up in 3D as though they were on the other side of the window. Think prison visitation without the phone handset. The camera is mounted such that you look naturally at the other person through your virtual window.
Our favorite raft of otters is back at it again with another display of open source audio prowess as they bring us the OtterCastAmp, the newest member of the OtterCast family of open source audio multitools. If you looked at the previous entry in the series – the OtterCastAudio – and thought it was nice but lacking in the pixel count or output power departments then this is the device for you.
The Amp is fundamentally a very similar device to the OtterCastAudio. It shares the same Allwinner S3 Cortex-A application processor and runs the same embedded Linux build assembled with Buildroot. In turn it offers the same substantial set of features and audio protocol support. It can be targeted by Snapcast, Spotify Connect or AirPlay if those are your tools of choice, or act as a generic PulseAudio sink for your Linux audio needs. And there’s still a separate line in so it source audio as well.
One look at the chassis and it’s clear that unlike the OtterCastAudio this is not a simple Chromecast Audio replacement. The face of the OtterCastAmp is graced by a luscious 340×800 LCD for all the cover art your listening ear can enjoy. And the raft of connectors in the back (and mountain of inductors on the PCBA) make it clear that this is a fully fledged class D amplifier, driving up to 120W of power across four channels. Though it may drive a theoretical 30W or 60W peak across its various outputs, with a maximum supply power of 100W (via USB-C power delivery, naturally) the true maximum output will be a little lower. Rounding out the feature set is an Ethernet jack and some wonderfully designed copper PCB otters to enjoy inside and out.
As before, it looks like this design is very close to ready for prime time but not quite there yet, so order at your own risk. Full fab files and some hints are linked in the repo mentioned above. If home fabrication is a little much it looks like there might be a small manufacturing run of these devices coming soon.
When Google halted production of the Chromecast Audio at the start of 2019, there was a (now silent) outcry. Fans of the device loved the single purpose audio streaming dongle that delivered wide compatibility and drop-dead simplicity at a rock bottom $35 price. For evidence of this, look no further than your favorite auction site where they now sell for significantly more than they did new, if you can even find an active listing. What’s a prolific hacker to do about this clear case of corporate malice? Why, reinvent it of course! And thus the Otter Cast Audio V2 was born, another high quality otter themed hack from one of our favorite teams of hardware magicians [Niklas Fauth, Jan Henrik, Toble Miner, and Manawyrm].
The Otter Cast Audio is a disc about the shape and size of standard Chromecast (about 50mm in diameter) and delivers a nearly complete superset of the original Chromecast Audio’s features plus the addition of a line in port to redirect audio from existing devices. Protocol support is more flexible than the original, with AirPlay, a web interface, Spotify Connect, Snapcast, and even a PulseAudio sink to get your Linux flavored audio bits flowing. Ironically the one thing the Otter Cast Audio doesn’t do is act as a target to Cast to. [Jan] notes that out of all the protocols supported here, actual Cast support was locked down enough that it was difficult to provide support for. We’re keeping our fingers crossed a solution can be found there to bring the Otter Cast Audio to complete feature parity with the original Chromecast Audio.
But this is Hackaday, so just as important as what the Otter Cast Audio does is how it does it. The OtterCast team have skipped right over shoehorning all this magic into a microcontroller and stepped right up to an Allwinner S3 SOC, a capable little Cortex A7 based machine with 128 MB of onboard DDR3 RAM. Pint sized by the bloated standards of a fully interactive desktop, but an absolutely perfect match to juggling WiFi, Bluetooth, Ethernet, and convenient support for all the protocols above. If you’re familiar with these hackers’ other work it won’t surprise you that what they produced here lives up to the typical extremely high quality bar set by such wonders as this USB-C adapter for JBC soldering iron handles and this TS-100 mainboard replacement.
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.
Google’s fledgling Stadia service leverages the Chrome ecosystem to deliver streamed PC games on mobile devices, web browsers, and TVs. While not strictly required, the company even offers a dedicated Stadia controller that connects directly to the streaming servers over its own WiFi connection to reduce overall system latency. Of course, being a Google product, the controller has a tiny microphone that’s always listening in for interacting with the voice assistant.
So [Heikki] came up with a bold idea. Knowing roughly the position of the microphone, he would simply drill through the controller’s case to expose and ultimately remove the device. The operation was complicated by the fact that, from the teardown video he saw, he knew he’d also have to drill through the PCB to get to the microphone mounted to the opposite side. The only bright spot was that the microphone was on its own separate PCB, so physically destroying it probably wouldn’t take the whole controller out with it.
Now we don’t have to explain why drilling into a gadget powered by an internal lithium-ion battery is dangerous, and we’re not necessarily vouching for the technique [Heikki] used here. But when presented with a sealed unit like this, we admit there weren’t a lot of good options. The fact that the user should have to go to such ridiculous lengths to disable the microphone in a game controller is a perfect example of why we should try to avoid these adversarially designed devices, but that’s a discussion for another time.
In the end, with a steady and and increasingly larger bits, [Heikki] was able to put a 7 mm hole in the back of the Stadia controller that allowed him to extract the microphone in one piece. Removing the microphone seems to have had no adverse effect on the device as, surprisingly enough, it turns out that a game controller doesn’t actually need to listen to the player. Who knew?
He uses the Arduino MKR board in his build, but notes any number of other boards would work as well. A force sensor detects his jumps and a stretch sensor detects him ducking. Both the stretch and force sensors are resistive transducers, so two simple voltage divider circuits (one for each sensor) are needed to convert changes in force to a voltage. You may need to adjust the sensor threshold to ensure the code responds to your movements, but [Ryan] makes that pretty easy to do in software as both thresholds are stored as global variables.
Had too much self-quarantine? [Sharathnaik] had, so he decided to build a robot companion named Ewon. Using a Raspberry Pi, Ewon isn’t a robot that moves around, but rather an expressive Google assistant. Using some servo-driven ears and a display, Ewon reacts to you based on keywords you use in your queries. For example, it might perk up and smile at the mention of ice cream. Or look unhappy if you mention sadness.
The project is simple because of the Google Assistant API. However, we liked the 3D printed body and some of the additional features the robot adds.