There’s a lot of mysticism around coffee roasting, but in the end it couldn’t be simpler. Take a bunch of beans, heat them up evenly, and stop before they get burned. The rest is details.
And the same goes for coffee roasters. The most primitive roasting technique involves stirring the beans in a pan or wok to keep them from scorching on the bottom. This works great, but it doesn’t scale. Industrial drum roasters heat a rotating drum with ridges on the inside like a cement mixer to keep the beans in constant motion while they pass over a gas fire. Fluidized-bed roasters use a strong stream of heated air to whirl the beans around while roasting them evenly. But the bottom line is that a coffee roaster needs to agitate the beans over a controllable heat source so that they roast as evenly as possible.
My DIY coffee roaster gave up the ghost a few days ago and I immediately ordered the essential replacement part, a hot air popcorn popper, to avert a true crisis: no coffee! While I was rebuilding, I thought I’d take some pictures and share what I know about the subject. So if you’re interested in roasting coffee, making a popcorn popper into a roaster, or even just taking an inside look at a thoroughly value-engineered kitchen machine, read on!
If you have even the most passing interest in space and what it takes to get there, you’ve probably already played Kerbal Space Program (KSP). If you haven’t, then you should set aside about ten hours today to go check that out real quick. Don’t worry, Hackaday will still be here when you get back. Right now you need to focus on getting those rockets built and establishing a network of communication satellites so you can get out of low orbit.
For those of you who’ve played the game (or are joining us again after playing KSP for the prescribed 10, 12, 16 hours), you’ll know that the humble computer keyboard is not very well suited to jaunts through space. You really want a joystick and throttle at the absolute minimum for accurate maneuvers, but even you’ll be spending plenty of time back on the keyboard to operate the craft’s various systems. If you want the ultimate KSP control setup, you’ll need to follow in the footsteps of [Hugo Peeters] and build your own. Luckily for us, he’s written up an exceptionally well detailed guide on building KSP controllers that should prove useful even if you don’t want to clone his.
Wiring switches and buttons to the Arduino.
At the most basic level, building a KSP controller consists of hooking a bunch of switches and buttons to a microcontroller such as the Arduino or Teensy, and converting those to USB HID key presses that the game understands. This works fine up to a point, but is limited because it’s only a one-way method of communication. For his controller, [Hugo] forked KSPSerialIO, a plugin for KSP that allows bidirectional communication between the game and your controller, enabling things like digital readouts of speed and fuel levels on the controller’s panel.
Once the logistics of how you’ll talk to the game are settled, the rest is really up to the individual. The first step in building your own KSP controller is deciding what you want it to do. Are you looking to fly planes? Control a rover? Maybe you just want a master control panel for your space station. There’s a whole lot of things you can build in KSP, and the layout, inputs, and displays on your controller should ideally reflect your play style.
[Hugo] went with a fairly general purpose panel, but did spend quite a bit of extra time to get some slick LED bar graphs hooked up to display resource levels of different systems on his craft. That’s an extra step that isn’t strictly required for a build like this, but once you see it, you’re going to have a hard time not wanting to include it on your own panel. He also went through the expense of having the panel and case professionally laser cut and etched, which definitely gives it a polished feel.
If you’re interested in making things (particularly metal things), you’re on a road that eventually leads to machine tools. Machine tools have a special place in history, because they are basically the difference between subsistence farming and modern civilization. A bold statement, I realize — but the ability to make very precise things is what gave us the industrial revolution, and everything that snowballed afterward. If you want to build a modern life filled with jet airplanes and inexpensive chocolate, start here.
Precision is more than just a desirable property. It’s a product. It has value, there is competition to create it, and our ability to create it as a species has improved over time. When your “precision product” is in the centimeter range, congratulations — you can make catapults and portcullises. Once you get into the millimeter range, guess what? You can make fine millwork in fancy houses, and indoor plumbing. Once you get sub-millimeter, now things get really interesting. It’s time for steam engines and automobiles. Once you get into the micrometer range, well, now we’re talking artificial heart valves and spaceships. Much like materials science, the ability to create precision is the unsung foundation and driving force of our standard of living.
Okay, so assuming I’ve sold you on the value of this product called “precision”, how do we make it? Machine tools are how humans currently get there, despite the dreams of the 3D printer crowd. Yes, drizzled plastic is great and the future is bright, but for right now, subtractive manufacturing is where it’s at when something has to be perfect.
As hackers, we occasionally forget that not everyone is enamored with the same nerdy minutia that we are. Configuring hardware by changing some lines in the code and compiling a new firmware doesn’t sound like that big of a deal to those of us who’ve been around the block a few times, but might as well be ancient Sanskrit to the average person. As long as your projects are for personal use this isn’t really a concern, but what if you plan on distributing the code for a project or perhaps even selling finished products? Shipping it out with hard-coded variables simply isn’t an option.
Code for loading configuration file from SPIFFS
In a recent video, [Proto G] shows a clever way to use WiFiManager to make configuring your ESP32 project easier for end-users. Not only can you use the captive portal system to configure the ESP32’s WiFi against a nearby access point, but it can allow users to enter in configuration data which can be picked up in your code by using SPI Flash File System (SPIFSS).
With the setup demonstrated in the video below by [Proto G], you don’t need anything more exotic than a web browser to configure the device. The end user simply searches for the device’s WiFi network, connects to it, and is presented with an easy to understand dialog which has them select a WiFi network to configure against along with some fields to enter in custom variables. All this information is then stored to a file on the SPI flash. When the ESP32 reboots, it reads the configuration from the saved file and applies the requested settings.
This is very similar to how many consumer devices are now configured, and even the less technically-inclined recipients of such a device should be able to work through the setup with a bit of hand-holding. If you plan on handing one of your ESP32 projects to John Q. Public, this is the kind of configuration you should be aiming for.
When it comes to finding what direction a radio signal is coming from, the best and cheapest way to accomplish the task is usually a Yagi and getting dizzy. There are other methods, and at Shmoocon this last weekend, [Michael Ossmann] and [Schuyler St. Leger] demonstrated pseudo-doppler direction finding using cheap, off-the-shelf software defined radio hardware.
The hardware for this build is, of course, the HackRF, but this pseudo-doppler requires antenna switching. That means length-matched antennas, and switching antennas without interrupts or other CPU delays. This required an add-on board for the HackRF dubbed the Opera Cake. This board is effectively an eight-input antenna switcher using the state configurable timer found in the LPC43xx found on the HackRF.
The key technique for pseudo-doppler is basically switching between an array of antennas mounted in a circle. By switching through these antennas very, very quickly — on the order of hundreds of thousands of times per second — you can measure the Doppler shift of a transmitter.
However, teasing out a distinct signal from a bunch of antennas virtually whizzing about isn’t exactly easy. If you look at what the HackRF an Opera Cake receive on a waterfall display, you’ll find a big peak around where you expect, and copies of that signal trailing off, separated by whatever your antenna switching frequency is. This was initially a problem for [Schuyler] and [Ossmann]’s experiments. Spinning the antennas at 20 kHz meant there was only 20 kHz difference in these copies, resulting in a mess that can’t be decoded. The solution was to virtually spin these antennas much faster, resulting in more separation, and a clean signal.
There are significant challenges when it comes to finding the direction of modern radio targets. Internet of Things things sometimes have very short packet duration, modulation interferes with antenna rotation, and packet detection must maintain the phase. That said, is this technique actually able to find the direction of IoT garbage devices? Yes, the demo on stage was simply finding the direction of one of the wireless microphones for the talk. It mostly worked, but the guys have some ideas for the future that would make this technique work a little better. They’re going to try phase demodulation instead of only frequency-based demodulation. They’re also going to try asymmetric antenna arrays and pseudorandom antenna switching. With any luck, this is going to become an easy and cheap way to do pseudo-doppler direction finding, all enabled by a few dollars in hardware and a laser-cut jig to hold a few antennas.
[Tobias Kuhn] had watched a YouTube video about a robot arm which used servo motors, and wanted to try making one himself. But he found it hard to get slow or smooth movements out of the servos. Even removing the microcontroller and trying to work with the servo’s driver-IC and potentiometer from an Arduino Nano didn’t get him satisfaction.
Then he found the very affordable 28BYJ-48 stepper motor. After some experimenting, he came up with a smooth moving robot arm with four steppers controlled from an Arduino Mega and A4988 stepper motor drivers. Rather than write a bunch of stepper motor code himself, he installed and ran a four-axis fork of grbl on the Arduino, turning it into a stepper motor controller. One minor hitch was that the A4988 motor drivers are for bipolar stepper motors but 28BYJ-48 steppers are unipolar. Luckily he knew of a very simple hack which our [Brian Benchoff] wrote about for turning a unipolar motor into a bipolar motor.
To tell the robot arm what to do, he built a replica arm with potentiometers in place of the stepper motors. As he manipulates the replica, the values of the potentiometers are read by a Raspberry Pi and some custom Python code which sends the appropriate G-code to the Arduino/grbl controlled robot arm. There’s a bit of a lag but when he moves the replica arm, the robot arm does the same move. See it in action in the video below.
It’s a simple fact that most programs created for the personal computer involve the same methods of interaction, almost regardless of purpose. Word processors, graphics utilities, even games – the vast majority of interaction is performed through a keyboard and mouse. However, sometimes it can be fun to experiment with alternative technologies for users to interact with code – Paper Programs is an exciting way to do just that.
Paper Programs is a combination of a variety of existing technologies to create a way of interacting with code which is highly tangible. The setup consists of a projector, and a webcam which can see the projected area, combined with Javascript programs running in a browser. Programs can be edited in the browser, then printed out with special coloured dots around the page. When the page is placed in the projection area, these dots identify the unique program and are picked up by the webcam, and the server executes the relevant code, projecting back onto the page.
It’s a system that creates a very tactile way of interacting with a program – by moving the page around or placing different pages next to each other, programs can interact in various ways. The system is setup for collaboration as well, allowing users to edit code directly in the browser.
The project reminds us of earlier works on DIY multitouch screens, but with a greater focus on direct engagement with the underlying code. What other unique ways exist to interact with code? Let us know in the comments.
