Building A Smart Speaker From Scratch

Smart speakers have proliferated since their initial launch earlier this decade. The devices combine voice recognition and assistant functionality with a foreboding sense that paying corporations for the privilege of having your conversations eavesdropped upon could come back to bite one day. For this reason, [Yihui] is attempting to build an open-source smart speaker from scratch.

The initial prototype uses a Raspberry Pi 3B and a ReSpeaker microphone array. In order to try and bring costs down, development plans include replacing these components with a custom microphone array PCB and a NanoPi board, then implementing basic touch controls to help interface with the device.

There’s already been great progress, with the build showing off some nifty features. Particularly impressive is the ability to send WiFi settings to the device using sound, along with the implementation of both online and offline speech recognition capabilities. This is useful if your internet goes down but you still want your digital pal to turn out the lights at bed time.

It’s not the first time we’ve seen a privacy-focused virtual assistant, and we hope it’s not the last. Video after the break.

Continue reading “Building A Smart Speaker From Scratch”

Fly A Pi On Your Next Model Rocket

From time to time, we see electronics projects for model rocket instrumentation. Those who have been involved in the hobby for many years may remember when 8-bit microcontrollers like the PIC16F84 were the kind of hardware you might fly on a mission. These days, however, there’s little reason not to send a high-powered processor. This is exactly what [Mohamed Elhariry] has done with his PiX project, which turns a Raspberry Pi Zero W into a neat little flight data recorder.

The hardware has what you might expect from a flight recorder, including accelerometer, gyroscope, and pressure sensor. In addition, it carries temperature and humidity sensors, and of course, a camera. A 64 GB microSD card provides the storage, while a LiPo SHIM board allows the whole thing to run from a 150 mAh battery. All of the components are off-the-shelf breakouts, which makes assembly as easy as soldering a few connections and securing the modules with a little tape.

The project is in GitHub, including python code, schematics for the hardware, and detailed instructions. If you ever wanted to get started with instrumenting a model rocket, this looks like a great resource. Also in the repo is a captured video from an actual flight [34 MB GIF] if you just want to see the view from one launch.

Using commercial modules seems pretty convenient, but if custom hardware is more your thing, check out these 22 mm round PCBs designed to fit inside rockets.

Project Egress: Casting The Hatch Handle

Every door needs a handle, even – especially – the door of a spaceship. And [Paul] from “Paul’s Garage” got the nod to fabricate the handle for the Apollo 11 Command Module hatch being built as part of Project Egress.

For those not familiar with Project Egress, it’s a celebration of the 50th anniversary of the first Moon landing that aims to recreate an important artifact from the mission: the Unified Crew Hatch, or UCH, from the Apollo 11 Command Module Columbia. Forty-four makers from various disciplines have been tasked with making the various pieces of the UCH, and each one is free to use whatever materials and methods he or she wants. [Paul] chose what will probably turn out to be the consensus material – aluminum – and decided to play to his strengths by casting the part.

The handle itself is a chunky affair, as one would expect from something designed to be handled by an astronaut. [Paul] started with a 3D-printed version of the handle and created a two-piece mold in casting sand. The original part was probably machined, which meant that it didn’t have the draft angle that cast parts are supposed to have to make removal from the molding medium easier. [Paul] lucked out and got a perfect mold, and a perfect pour from silicon aluminum to boot. All the casting needed was a little cleanup and some holes to bolt it to the door.

[Paul]’s handle will get shipped to the Smithsonian along with the other parts, like [Fran Blanche]’s latch assembly, so that [Adam] can assemble the hatch live during the 50th-anniversary celebration later this month. Stay tuned for more Project Egress coverage as the parts keep rolling in.

Continue reading “Project Egress: Casting The Hatch Handle”

Salty? Tip Canister To Rage Quit Games

Do you long for a more pronounced way to rage quit video games? Smashing buttons comes naturally, of course, but this hurts the controller or keyboard. You can quit your longing, because [Insert Controller Here] has an elegant solution that’s worth its salt.

The Salty Rage Quit Controller is simple. The cup is filled with distilled water. When you pour salt in it, the two bolt terminals tell the Arduino Micro that the resistance in the water has decreased. The Micro sends whatever keystrokes you want, so you could call out your deadbeat medic before quitting, or just plain leave. [Insert Controller Here] has example code on his site to get you started. Click calmly past the break to watch the demo and build videos, or we’ll have to ban you for aggro.

With the right tools, you can turn anything into a game controller. Check out this car controller that uses Python and CAN bus sniffing.

Continue reading “Salty? Tip Canister To Rage Quit Games”

How Not To Get Paid For Open Source Work

[Avi Press] recently made a Medium post sharing his thoughts on a failed effort to allow for paid users of an open source project. [Avi] is the author of Toodles, a tool to help organize and manage TODO items in software development. Toodles enjoyed unexpected popularity, and some of its users were large organizations. It seemed that Toodles was of value to people who could afford to pay, and they might even be willing to do so if [Avi] provided a way for them to do it. It turned out that the monetizing process was far from simple, and he ultimately wasn’t successful.

Before he even started, [Avi] thought carefully about things and found that even basic and preliminary questions were difficult to answer, such as:

  • How many people were actually using the software on a regular basis? Were they gaining quantifiable value from it?
  • What exactly would someone be buying? How would they pay, and how would it get delivered to them?
  • How could companies be charged for the tool while still offering it freely to individuals?
  • Is it even ethical to accept money for a project to which others have contributed? How could money be shared with contributors? How to fairly decide who gets how much?

In short, [Avi] discovered that much of the data he felt he needed in order to make these decisions didn’t exist, wasn’t easily accessible, or couldn’t be reliably measured. His experiment in adding a license and payment system (which always seemed to need more work than it should) yielded no fruit, as there were zero paid users anyway.

Regardless of whether “difficulty in shoehorning a paid license system into an open source project” should be filed under “Feature, not Bug” [Avi] does thoughtfully present the issues he encountered. Open source and getting paid are not necessarily mutually exclusive. Octoprint is one example of an open source project that eventually navigated these waters, but that doesn’t mean it was easy, nor does it mean there are established tools and processes.

Raspberry Pi Catches The Early Bird

If you live in an area with high bird activity, setting up a bird feeder and watching some hungry little fellows visit you can be a nice and relaxing pastime. Throw in a Raspberry Pi with some sensors and it can also be the beginning of your next IoT project, as it was the case for [sbkirby] with his Bird Feeder Monitor project.

To track the arrival and departure times of his avian visitors, [sbkirby] attached a set of capacitive touch sensors to each side of his bird feeder, and hooked them up to a Raspberry Pi Zero W via a CAP1188 breakout board. The data is published via MQTT to another Raspberry Pi that serves as backend and stores the data, as well as to an optional additional camera-equipped Pi that will take a picture of each guest along the way. Taking into account that precipitation might affect the sensor readings, he also checks the current weather situation to re-calibrate the sensors if necessary, and also to observe a change in the birds’ presence and eating behavior based on weather conditions.

It seems that sensor-based animal feeding will always serve as inspiration for some new projects, whether feeding the animal itself is the goal, like most recently this fish feeder has shown, or whether the eating behavior is monitored and used for further research such as this squirrel-based weather forecast system.

Understanding Elliptic Curve Cryptography And Embedded Security

We all know the usual jokes about the ‘S’ in ‘IoT’ standing for ‘Security’. It’s hardly a secret that security in embedded, networked devices (‘IoT devices’) is all too often a last-minute task that gets left to whichever intern was unfortunate enough to walk first into the office that day. Inspired by this situation, All About Circuits is publishing a series of articles on embedded security, with a strong focus on network security.

In addition to the primer article, so far they have covered the Diffie-Hellman exchange (using prime numbers, exponentiation and modular arithmetic) and the evolution of this exchange using elliptic curve cryptography (ECC) which prevents anyone from brute-forcing the key. Barring any quantum computers, naturally. All three articles should be understandable by anyone, with a simple, step-by-step format.

The upcoming articles will cover implementing security on microcontrollers specifically.  For those who cannot wait to learn more, Wikipedia has a number of articles on the topic of Elliptic Curve Cryptography (comparing it to the more older and still very common RSA encryption) specifically, as well as the Elliptic-Curve Diffie-Hellman key agreement protocol as discussed in the All About Circuits article.

A detail of note here is that the hardest problem in secure communications isn’t to keep the communications going, but to securely exchange the keys in the first place. That’s why a much much computationally expensive key exchange scheme using an asymmetric (or public-key) cryptography scheme  is generally used to set up the second part of the communications, which would use a much faster symmetric-key cryptography scheme, where both parties have the means to decode and encode messages using the same private key.

All the math aside, one does have to wonder about how one might denote ‘secure’ IoT. Somehow ‘SIoT’ doesn’t feel very catchy.