[Wayne Venables], like many of us, found himself sitting more than usual the past few months. Armed with a Bluetooth-enabled under desk exercise bike, he quickly found the app to be rather sub-optimal and set about reverse-engineering the protocol of his bike.
Custom GUI for the exercise bike
The first step was to use some apps on his Android phone to reveal the profiles on the bike, which showed his particular machine used a Nordic Bluetooth UART. This meant the only work would be decoding the stream of bytes coming off the wireless serial port. Using Wireshark and Bluetooth logs on his phone, [Wayne] was able to correspond the various commands to points in the video. There were still a few bytes that he wasn’t able to identify, but [Wayne] had enough to whip up a quick .NET app that can start a workout and log it all to a database. The code for his app is on his GitHub.
While [Wayne] doesn’t specifically name the bike he uses in this project, we tracked down the image he shows on his writeup to the Exerpeutic 900e. It appears to be discontinued but the reverse engineering approach should be usable on a range of Bluetooth-connected machines. This isn’t the first bike we’ve seen liberated by reverse engineering here at Hackaday. And we have a feeling it won’t be the last.
Looking for a hands-free way to page through sheet music on an iPad, [The_Larch] came up with this simple Bluetooth input device based on the ESP32. The microcontroller just needed to have two switches wired into the GPIO pins, in this case the same heavy-duty plungers you’d find on a guitar pedal, and a USB bulkhead pass-through to provide power. Thanks to the excellent ESP32-BLE-Keyboard library, it only took a few lines of code to fire off the appropriate key strokes when the left or right button was pressed.
While undeniably a simple project from an electronics standpoint, the wooden enclosure [The_Larch] built is an interesting change of pace from the 3D printed fare we normally see around these parts. It started life as strips of oak reclaimed from an old kitchen table, which were laminated together to make a solid block. A large spade bit was then used to bore into the block to make a void for the electronics, and a second flat piece of oak was fashioned into a front panel.
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!
While the PlayStation 3 and Gamecube come from opposing sides of the aisle, and in fact aren’t even from the same generation of hardware, this DIY adapter built by [Jeannot] allows Nintendo’s console to use Sony’s Bluetooth controllers with surprisingly little fuss. This might seem unnecessary given the fact that Nintendo put out an official wireless controller for the system, but given how expensive they are on the second-hand market, you’d need to have pretty deep pockets for an untethered four-player session. Plus, there’s plenty of people who simply prefer the more traditional control layout offered by Sony’s pad.
The internals of the 3D printed adapter are actually quite straightforward, consisting of nothing more than an Arduino Nano wired to a MAX3421E USB host shield. A common USB Bluetooth adapter is plugged into the shield, and the enclosure has an opening so it can be swapped out easily; which is important since that’s what the PS3 controller is actually paired to.
A Gamecube controller extension cable must be sacrificed to source the male connector, though if you wanted to fully commit to using Bluetooth controllers, it seems like you could turn this into an internal modification fairly easily. That would let you solder right to the controller port’s pads on the PCB, cutting the bill of materials down ever further.
[Jeannot] says the firmware is the product of combining a few existing libraries with a fair amount of experimentation, but as demonstrated in the video below, it works well enough to navigate the console’s built-in menu system. Future enhancements include getting the stick sensitivity closer to the values for the Gamecube’s standard controller, and adapting the code to work with newer PS4 controllers.
Apple’s “Find My” service allows users to track their missing devices by leveraging a worldwide network of location-aware iGadgets. With millions of iPhones and Macs out in the wild listening for the missing device’s Bluetooth advertisements and relaying their findings to the Cupertino Mothership, it’s a highly effective way of tracking hardware so long as it stays in relatively urban areas. Unfortunately, the system is completely proprietary and non-Apple devices aren’t invited to play.
Or at least, that used to be the case. A project recently released by the [Secure Mobile Networking Lab] called OpenHaystack demonstrates how generic devices can utilize Apple’s Find My network by mimicking the appropriate Bluetooth Low Energy (BLE) broadcasts. Currently they have a firmware image for the BBC micro:bit, as well as a Python script for Linux, that will allow you to spin up an impromptu Find My target. But the team has also published all the information required to implement similar functionality on other BLE-capable devices and microcontrollers, so expect the list of supported hardware to grow shortly.
Somewhat ironically, while OpenHaystack allows you to track non-Apple devices on the Find Me tracking network, you will need a Mac computer to actually see where your device is. The team’s software requires a computer running macOS 11 (Big Sur) to run, and judging by the fact it integrates with Apple Mail to pull the tracking data through a private API, we’re going to assume this isn’t something that can easily be recreated in a platform-agnostic way. Beyond the occasional Hackintosh that might sneak in there, it looks like Tim Cook might have the last laugh after all.
It’s not immediately clear how difficult it will be for Apple to close this loophole, but the talk of utilizing a private API makes us think there might be a built-in time limit on how long this project will be viable. After all, Big Tech doesn’t generally approve of us peons poking around inside their machinations for long. Though even if Apple finds a way to block OpenHaystack, it’s expected the company will be releasing “AirTags” sometime this year which will allow users to track whatever objects they like through the system.
For this project, [Dan] wanted to make sure no original functionality was lost. The radio still functions on the AM/FM bands, but now with the flip of a switch, he can listen to the audio coming his way courtesy of a Apt-X low-latency Bluetooth receiver. It sounds like the link is quick enough that he can even use this as a wireless speaker for watching TV, which isn’t always possible with cheaper chipsets that introduce a noticeable lag.
Isolating the audio trace.
The trick was to track down the receiver IC, a Silicon Labs chip similar to ones we’ve seen used in a few DIY radio projects previously. A peek at the datasheet told him which pins were carrying the audio signal, and after following them around the board, he found a convenient spot to cut the trace before it went into the volume control. From there is was just a matter of wiring in a SPDT slide switch that allowed him to select which device was passed through to the radio’s audio hardware.
While he had everything apart, [Dan] exorcised the Apt-X’s original 300 mAh LiPo pouch and replaced it with a DC-DC converter connected to the radio’s battery compartment. This allows him to run all of the hardware off of the same set of rechargeable NiMH cells, and also provides considerably improved runtime for the Bluetooth receiver.
Now as for physically integrating the Apt-X into the case of the radio…well, what can we say? [Dan] admits it’s a bit rough, but then the point was never to enter the thing into beauty pageants. It works well enough for his purposes, and in the end that’s all that matters.
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.