Virtually any hobby has an endless series of rabbit holes to fall into, with new details to learn around every corner. This is true for beekeeping, microcontrollers, bicycles, and gardening (just to name a few), but those involved in the intricate world of coffee roasting and brewing turn this detail dial up to the max. There are countless methods of making coffee, all with devout followers and detractors alike, and each with its unique set of equipment. To explore one of those methods and brew a perfect espresso, [Eric] turned to his trusted 3D printer and some compressed gas cylinders.
An espresso machine uses high pressure to force hot water through finely ground coffee. This pressure is often developed with an electric pump, but there are manual espresso machines as well. These require expensive parts which can withstand high forces, so rather than build a heavy-duty machine with levers, [Eric] turned to compressed CO2 to deliver the high pressure needed.
To build the pressure/brew chamber, he 3D printed most of the parts with the exception of the metal basked which holds the coffee. The 3D printed cap needs to withstand around nine atmospheres of pressure so it’s reasonably thick, held down with four large bolts, and holds a small CO2 canister, relief valve, and pressure gauge.
To [Eric]’s fine tastes, the contraption makes an excellent cup of coffee at minimal cost compared to a traditional espresso machine. The expendable CO2 cartridges only add $0.15 to the total cost of the cup and for it’s simplicity and small size this is an excellent trade-off. He plans to improve on the design over time, and we can’t wait to see what he discovers. In the meantime, we’ll focus on making sure that our beans are of the highest quality so they’re ready for that next espresso.
Usually when we post a Fail Of The Week, it’s a heroic tale of a project made with the best of intentions that somehow failed to hit its mark. The communicator that didn’t, or the 3D-printed linkage that pushed the boundaries of squirted plastic a little bit too far. But today we’re bringing you something from a source that should be above reproach, thanks to [Boldport] bringing us a Twitter conversation between [Stargirl] and [Ticktok] about a Texas Instruments datasheet.
The SN65220 schematic
The SN65220 is a suppressor chip for USB ports, designed to protect whatever the USB hardware is from voltage spikes. You probably have several of them without realising it, the tiny six-pin package nestling on the PCB next to the USB connector. Its data sheet reveals that it needs a resistor network between it and the USB device it protects, and it’s this that is the source of the fail.
There are two resistors, a 15kO and a 27O, 15k ohms, and 270 ohms, right? Looking more closely though, that 27O is not 270 with a zero, but 27O with a capital “O”, so in fact 27 ohms.
The symbol for resistance has for many decades been an uppercase Greek Omega, or Ω. It’s understood that sometimes a typeface doesn’t contain Greek letters, so there is a widely used convention of using an uppercase “R” to represent it, followed by a “K” for kilo-ohms, an “M” for mega-ohms, and so on. Thus a 270 ohm resistor will often be written as 270R, and 270 kilo-ohm one as 270K. In the case of a fractional value the convention is to put the fraction after the letter, so for example 2.7kilo-ohms becomes 2K7. For some reason the editor of the TI datasheet has taken it upon themselves to use an uppercase “O” to represent “Ohms”, leading to ambiguity over values below 1 kilo-ohm.
We can’t imagine an engineer would have made that choice so we’re looking towards their publishing department on this one, and meanwhile we wonder how many USB devices have gone to manufacture with a 270R resistor in their data path. After all, putting the wrong resistor in can affect any of us.
If you’re looking to get started with the ESP8266, there’s no shortage of development boards out there to select from. But we don’t think you’ll find one with a more unique a backstory than the open source ME-ESP8266. That’s because Malouf, the company that makes the $20 USD board, is a home goods company better known for their pillows and bed frames.
So how do you go from mattress toppers to microcontrollers? Well, as unlikely as it might seem, the missing element is Toys R’ Us. Or more specifically, the liquidation of Toys R’ Us. A Texas distribution center Malouf purchased from the iconic toy retailer included an automated conveyor belt system to move product through the gargantuan building, but unfortunately, they couldn’t get it to work with their existing system. The company decided to use their in-house team of engineers to solve the problem, and the ME-ESP8266 was born.
It turns out that an ESP8266 board developed to move bedding around an old Toys R’ Us warehouse has a lot of useful features for hackers and makers. It’s got an integrated relay, 16 MB of flash storage, an IR receiver, beefy screw terminals, and a 2.54mm-pitch GPIO pin header. There’s even a MAX232 on the board so it can talk to RS-232 devices. The hardware is compatible with the standard Arduino IDE as a “Generic ESP8266 Module”, so you’ll have no problem using existing libraries and example code.
Now under normal circumstances, the public would never know about this sort of behind the scenes engineering. But instead of keeping their new ESP board to themselves, the team at Malouf got the go ahead from the company’s Chief Technology Officer (CTO) to release it as an open source project. Even more impressive, they got the company to put the board into production so it could be sold to the public. So today we not only learned that bedding companies have CTOs, but that they can be exceptionally open-minded.
We know, we know. Generally speaking, you should try and switch your household devices over to rechargeable cells rather than using disposable alkaline batteries. But while they might seem increasingly quaint in the lithium-ion era, features such as a long shelf life make it worth keeping a pack of disposables around. So which ones should you buy? That’s what [Moragor] wanted to find out with his personal battery analyzer.
Designed as a shield for the Arduino Mega 2560, the analyzer combines a small programmable electronic load with a INA219 current sensor, OLED display, and SD card reader. The user selects the cutoff voltage and discharge rate before the test begins, and once it’s running, data is collected every second and saved to the SD card for later analysis. Once the battery voltage reaches the predetermined value, the test is over and you’re ready to put a new cell through its paces.
After testing 27 different brands of batteries, [Moragor] tabulated all the data and produced some helpful charts to illustrate the results. With few exceptions, the performance level for most of the batteries was remarkably similar. If anything, the test seemed to show that higher tier batteries from companies like Duracell and Energizer actually performed slightly worse than the mid-range offerings. Perhaps the biggest surprise is that, when the per-cell cost was factored in, the local cheapo batteries provided a better value than anything else in the test.
While the selection of battery brands may be different from where you live, the data [Moragor] collected is still a fascinating even if you don’t recognize some of the names on the chart. Of particular note is the confirmation that lithium batteries handily outperformed any of the Alkaline cells tested when it came to high-drain applications. We’d still rather they came in rechargeable form, but at least it’s a step in the right direction.
This is a story about a successful system that nevertheless failed to make the cut. An experimental LED brightness adjustment is something [Mitxela] explored in a project for a high-precision clock; one that shows time down to the nearest millisecond, and won’t flicker or otherwise look weird when photographed with a high-speed camera. To pull this off means reinventing many things about a clock display, including how to handle brightness adjustment elegantly. Now, to be clear, the brightness adjustment idea described here is something that did not end up being used, but it’s interesting enough that [Mitxela] wrote it up and we’re very glad he did.
The idea was to have a smooth and seamless automatic brightness adjustment, ideally with no added components. Since LEDs can be used as light sensors, [Mitxela] saw an opportunity to use elements of the clock displays themselves as sensors. This is how it works: a charge in the p-n junction that makes up an LED will decay at a rate proportional to the amount of light hitting the junction. By measuring the speed of this decay, it’s therefore possible to tell how much light is hitting the LED. It’s effective and elegant, but there are a few practical issues to deal with.
The first failed idea was to employ as sensors the unused decimal points in the seven-segment LED modules, but that turned out to have issues. One was the common-cathode wiring of the display modules; this makes them very convenient to drive as displays, but made using the decimal point as a light sensor impractical. The other issue was that the built-in diffuser that makes the displays easier to read absorbs a lot of ambient light. A much better option was to use the LEDs in the colon separators between digits, since they’re independent. Naturally they still have to light up in addition to being used as sensors, but [Mitxela] made a successful prototype by performing the necessary measurements in between the LEDs being driven by PWM.
Despite how clever and efficient the solution was, in the end what sank it was the fact that the LEDs just don’t do a very good job of sensing ambient light for this purpose. The LEDs are simply too directional. Even after sanding away the top (lens) part of the LEDs, they still had a very narrow field of view. As [Mitxela] describes it, tilting the clock towards the ceiling could send it to full brightness, and the shadow of one’s head falling across the clock would plummet it into “night mode” dimness. In short, it responded to what was directly in front of it, rather than the ambient light level as a whole.
It’s a reminder that sometimes a solution simply won’t tick all the right boxes, and it can happen for unexpected reasons. Still, LEDs are versatile things. Not only can they sense light, but as the name implies they’re also diodes. As diodes can be used as temperature sensors that means LEDs can as well.
If you’re a reader of Hackaday, then you’ve almost certainly encountered an Espressif part. The twin microcontroller families ESP8266 and ESP32 burst onto the scene and immediately became the budget-friendly microcontroller option for projects of all types. We’ve seen the line expand recently with the ESP32-C3 (packing a hacker-friendly RISC-V core) and ESP32-S3 with oodles of IO and fresh new CPU peripherals. Now we have a first peek at the ESP32-C6; a brand new RISC-V based design with the hottest Wi-Fi standard on the block; Wi-Fi 6.
There’s not much to go on here besides the standard Espressif block diagram and a press release, so we’ll tease out what detail we can. From the diagram it looks like the standard set of interfaces will be on offer; they even go so far as to say “ESP32-C6 is similar to ESP32-C3” so we’ll refer you to [Jenny’s] excellent coverage of that part. In terms of other radios the ESP32-C6 continues Espressif’s trend of supporting Bluetooth 5.0. Of note is that this part includes both the coded and 2 Mbps Bluetooth PHYs, allowing for either dramatically longer range or a doubling of speed. Again, this isn’t the first ESP32 to support these features but we always appreciate when a manufacturer goes above and beyond the minimum spec.
Welcome to the ESP32-C6
The headline feature is, of course, Wi-Fi 6 (AKA 802.11ax). Unfortunately this is still exclusively a 2.4GHz part, so if you’re looking for 5GHz support (or 6GHz in Wi-Fi 6E) this isn’t the part for you. And while Wi-Fi 6 brings a bevy of features from significantly higher speed to better support for mesh networks, that isn’t the focus here either. Espressif have brought a set of IoT-centric features; two radio improvements with OFDMA and MU-MIMO, and the protocol feature Target Wake Time.
OFDMA and MU-MIMO are both different ways of allowing multiple connected device to communicate with an access point simultaneously. OFDMA allows devices to slice up and share channels more efficiency; allowing the AP more flexibility in allocating its constrained wireless resources. With OFDMA the access point can elect to give an entire channel to a single device, or slice it up to multiplex between more than once device simultaneously. MU-MIMO works similarly, but with entire antennas. Single User MIMO (SU-MIMO) allows an AP and connected device to communicate using a more than one antenna each. In contrast Multi User MIMO (MU-MIMO) allows APs and devices to share antenna arrays between multiple devices simultaneously, grouped directionally.
Finally there’s Target Wake Time, the simplest of the bunch. It works very similarly to the Bluetooth Low Energy (4.X and 5.X) concept of a connection interval, allowing devices to negotiate when they’re next going to communicate. This allows devices more focused on power than throughput to negotiate long intervals between which they can shut down their wireless radios (or more of the processor) to extended battery life.
These wireless features are useful on their own, but there is another potential benefit. Some fancy new wireless modes are only available on a network if every connected device supports them. A Wi-Fi 6 network with 10 Wi-Fi 6 devices and one W-Fi 5 (802.11ac) one may not be able to use all the bells and whistles, degrading the entire network to the lowest common denominator. The recent multiplication of low cost IoT devices has meant a corresponding proliferation of bargain-basement wireless radios (often Espressif parts!). Including new Wi-Fi 6 exclusive features in what’s sure to be an accessible part is a good start to alleviating problems with our already strained home networks.
When will we start seeing the ESP32-C6 in the wild? We’re still waiting to hear but we’ll let you know as soon as we can get our hands on some development hardware to try out.
Thanks to friend of the Hackaday [Fred Temperton] for spotting this while it was fresh!
Since the introduction of the Raspberry Pi Compute Module 4, power users have wanted to use NVMe drives with the diminutive ARM board. While it was always possible to get one plugged in through an adapter on the IO Board, it was a bit too awkward for serious use. But as [Jeff Geerling] recently discussed on his blog, we’re not only starting to see CM4 carrier boards with full-size M.2 slots onboard, but the Raspberry Pi Foundation has unveiled beta support for booting from these speedy storage devices.
The MirkoPC board that [Jeff] looks at is certainly impressive on its own. Even if you don’t feel like jumping through the hoops necessary to actually boot to NVMe, the fact that you can simply plug in a standard drive and use it for mass storage is a big advantage. But the board also breaks out pretty much any I/O you could possibly want from the CM4, and even includes some of its own niceties like an RTC module and I2S DAC with a high-quality headphone amplifier.
Once the NVMe drive is safely nestled into position and you’ve updated to the beta bootloader, you can say goodbye to SD cards. But don’t get too excited just yet. Somewhat surprisingly, [Jeff] finds that booting from the NVMe drive is no faster than the SD card. That said, actually loading programs and other day-to-day tasks are far snappier once the system gets up and running. Perhaps the boot time can be improved with future tweaks, but honestly, the ~7 seconds it currently takes to start up the CM4 hardly seems excessive.
An espresso machine uses high pressure to force hot water through finely ground coffee. This pressure is often developed with an electric pump, but there are manual espresso machines as well. These require expensive parts which can withstand high forces, so rather than build a heavy-duty machine with levers, [Eric] turned to compressed CO2 to deliver the high pressure needed.
