Writing An ESP32 Bluetooth Printer Driver In Two Acts

[Bas BotBerg] wanted to use a portable Bluetooth thermal printer to run off reports on sensor data collected by an ESP32-C3 microcontroller. But as is so often the case these days, the only official way to interface with the printer was through a proprietary smartphone application provided by the manufacturer. With no documentation on how the thing works, he set out to reverse engineer the printer’s communications protocol so he could control it from the MCU — but the route he took to get there was a bit different than what we usually see, and is an excellent case study for those who might have similar projects in mind.

The standard procedure for something like this, if it can be called that, is to use Android’s built-in debugging capability to log Bluetooth communications while running the manufacturer’s application. The resulting file can be fed into Wireshark, and with patience and some educated guesses, you can usually work out the various commands and values that get passed to the hardware.

But in this case, [Bas BotBerg] ignored the manufacturer’s software and instead used an application that can query a device and list its Bluetooth Low Energy services and characteristics. Specifically, he looks for services that are marked as writable, and starts pushing data into them to see how the printer responds. For this he uses Python with the Bleak library, as it allows him to rapidly iterate and adapt his code. After a bit of poking and experimentation, he finds the proper incantation to get the printer’s motor to kick on and advance the paper — a critical first milestone that tells him he’s on the right path.

Once [Bas BotBerg] mapped out what data needed to be sent to what endpoints to operate the printer in Python, it was a relatively straightforward process to send those same payloads using C++ code on the ESP32. For extra style points he also brought in the Adafruit GFX library so he could produce icons and more easily format the output of the printer.

It doesn’t look like [Bas BotBerg] has released the code in this case (perhaps if we all ask nicely), but we’ve seen similar efforts to bring open source drivers to these cheap Bluetooth printers for the good of the community.

Rusting An E-scooter (In A Good Way)

It is a classic Hackaday situation. You have an Egret GT E-scooter. It has a screen that shows the usual dash stats, but that led to an annoyance. You could accidentally enter firmware update mode and, from there, enter operational mode without the security PIN. [Ben] couldn’t let that stand, so he reverse-engineered the protocol and rewrote the firmware in Rust. As he put it, “… because I have to break… everything I own…” We get it.

The mobile app was useful for some basic info, since sniffing Bluetooth is fairly easy and analyzing mobile code is, more or less, straightforward. Analysis revealed some data that doesn’t show on the display and that several things are sent back to home base tagged with the scooter’s unique ID — another reason to gut the existing firmware.

Continue reading “Rusting An E-scooter (In A Good Way)”

Bluetooth Shock Collar Keeps Wearer On Task

Like a lot of us [Liam Kloppers] had a problem with doomscrolling. Unwilling to go cold-turkey because he does find some utility in social media. He tried a number of things before deciding to say “Screw it” and just go full Pavlov on himself with some old-fashioned classical conditioning. Who needs willpower when you have electric shocks to dissuade you?

The key here was finding an electric-shock dog collar that could be controlled via a smartphone application, which meant he could reverse-engineer its Bluetooth protocol and get it linked up to his own software. The initial implementation ties his quick-and-dirty Python control program with a web server living on his laptop, which he’s configured MacroDroid to call on when his personal criterion for ‘doomscrolling’ is met.

With the shock collar wrapped around his leg, [Liam] was ready to test. It turns out dogs are a lot tougher than people, because even when set to a low level, the shock from the device made him toss his phone across the room and had him hesitant to even pick it up again.

Since he couldn’t bring himself to put the shock collar back onto his leg, he’s now thinking of an audible alarm, something we’ve seen work before. If you’re as unhappy with your habits as [Liam], perhaps consider a device like Commodore’s social-media-free phone before resorting to self-electrocution.

Making A Locked Down Wearable Work Without A Subscription

WHOOP does not have the presence in the wearable space as other brands, but in certain circles, it’s a household name. Their business model requires you to have a yearly app subscription to use their fitness tracker, but here at Hackaday, we are big fans of actually owning the devices you buy — which is why we were happy to hear about an open source and subscription free WHOOP compatible app!

The goal of the so-called OpenStrap project is not to re-create the WHOOP app. Rather, the algorithms and processing methods are developed from scratch, based on public research. It’s all calculated locally on a 1 Hz interval, based on the data the WHOOP 4.0 device feeds the app. As such, the health data collected from the watch, never leaves the phone. While not the main goal of the project, the privacy improvement of the app’s serverless nature cannot be overstated. However, to display metrics, you first need to get data off the WHOOP to begin with.

The crux of the issue with making the WHOOP 4.0 work without the official app is the reliance on proprietary Bluetooth protocols. Fortunately, the protocol itself ended up being relatively simple. The WHOOP 4.0 amounts to little more than a series of sensors that sit on the user’s wrist. As such, the app can subscribe to the Bluetooth feed and decode the data, right? Well, the devil is always in the details with such things, and the protocol came with its fair share of quirks. The hardware clock needs to be synchronized, or it simply defaults to zero Unix time. Moreover, the analog sensors like, ambient temperature are given in relative ADC values, and are not terribly useful without calibration. Regardless, the result of the reverse engineering effort speaks for itself with the OpenStrap app able to recreate much of the functionality in WHOOP’s official app.

Quite often, devices reliant on proprietary apps are little more than manufactured e-waste. While we don’t expect many of you to actually own a WHOOP 4.0, we do hope to see the OpenStrap project keep at least a few out of the landfill in the future.

Flight Sim Tracking From Spatial Audio

Flight sims are wonderful to play around with to get immersed in the position of a pilot. Racing sims can give you a thrill that can only be beaten by the real thing. However, most of this tech is on the more expensive side, so it would be great if you could use some of the hardware already found in your house. Many Sony headphones already have rotation and movement data built in for spatial audio, so why not start there?

[Nicholas Slattery] had this very idea and has produced an open-source application to connect your headphones straight to your sim. There’s a surprising amount of support built into many headsets that use a known protocol called the Android Head Tracker HID protocol. This allowed [Nicholas] to connect a family of Sony headphones straight into OpenTrack, which is often used with flight sims. The best part is you can still use the headphones as normal with a Bluetooth connection.

If you want to give this a try with your own rig, check out [Nicholas]’s GitHub here. While flight and driving sims might be expensive to put together, it’s never too hard to hack together something to lower that barrier! Whether it’s a flight sim force-feedback joystick or driving sim hand-breaks we got you!

Building A Wireless Fingerprint Authorization Device

Once upon a time, there was a bit of a fad for fingerprint authentication in laptops and desktop computers. It has long since faded, but [superdog] wanted just such a device for Linux and Mac machines. Thus, it was time to build one.

[superdog] designed the device, nicknamed immurok, as a tool for people who use external keyboards, and do lots of terminal work on Mac and Linux machines. Repeat password requests can interrupt one’s flow when hustling at the keys, so immurok was designed to ease this pain.

The device is based on a WCH CH592F microcontroller, which comes with Bluetooth connectivity out of the box. This allows immurok to connect wirelessly to the machine of your choice, advertising itself as a standard Bluetooth HID keyboard device. Fingerprint-wise, scanning is done with an R559S capacitive sensor, which verifies the match locally so there’s no transmitting biometric data anywhere. On the computer side, Linux is setup to use a CLI/TUI app plus PAM integration to handle authorization for system logins and sudo in the terminal. On the Mac platform, it’s used with a menu bar app, with PAM integration for admin prompts. There’s also a separate helper path for using it with the lock screen.

If you’re sick of entering your password all the time and wish unlocking your PC was more like unlocking your phone, this might be the project for you. We’ve seen similar projects before, too. If you’re whipping up fun gear for biometric auth, don’t hesitate to let us know on the tipsline.

A T9 Keyboard For Your Smartphone

These days, most of us are fortunate enough to use smartphones with decent touchscreen keyboard capabilities. However, once upon a time, if you wanted to type something on a phone, you had to tap it out on the number keys instead. [Jarrett] is bringing that back with a custom T9 keyboard for modern phones. 

The build is designed around the keypad of the Nokia E52, a Symbian smartphone released in 2009—two years after Apple changed the game with the first iPhone. The phone keypad itself is laid over a custom PCB with Alps SKRK tactile switches corresponding to each individual key. Each is wired with a diode and the switches are scanned as a row/column array as is typical for keyboards. Reading the matrix is an ESP32-C6 microcontroller, which counts the keypresses and spits out the right letters over its Bluetooth connection to an attached smartphone or other device. Power is via a small lithium-ion battery, looked after by a TP4200 charger chip.

Overall, the keyboard works as you’d expect, allowing T9-style input to any compatible device that works with Bluetooth keyboards. [Jarrett] does have one regret, with the 0.98 N actuation force switches used leaving he keypad feeling a little mushy. The firmer 1.57 N switches were suspected to give a more satisfying response under thumb, which was a nice upgrade in the second revision build.

We’ve seen other builds in this vein before, too, albeit with bigger keys. If you’re coming up with your own esoteric input methods, don’t hesitate to notify the tipsline.