What we’ve shipped—and where R+D is going next

Hey lovely people,

I’ve been fairly quiet lately, but not because there has been nothing happening. I’ve spent most of the last two months rebuilding some of the least glamorous—and most important—parts of R+D: documentation, browser tools, firmware releases, update recovery, and the communication layer shared by our devices.

The direction is becoming much clearer. I want our products to remain open and hackable while getting substantially easier and more dependable for people who simply want to use them. Those goals are not in conflict. Better shared foundations let us support both.

Here is what is available now, what is still being tested, and why I think it matters.

Available now

Documentation we can keep free and improve

Our User Guides, Developer Docs, and OHAI assembly guides have moved onto a Fumadocs stack that we control.

The old documentation platform had become far too expensive, and it made ordinary editing harder than it needed to be. The new setup is faster, keeps the documentation free to read, and stores the real source in Git instead of burying it inside a proprietary editor. It also gives us room for human-written guides, direct community corrections, interactive tools, and richer assembly material.

The OHAI guides have their assembly-focused layout back, including photographs, bills of materials, captions, and interactive KiCad board views. This is not just a visual migration; it is a better foundation for documenting how the machines are actually built, repaired, and modified.

You can browse the User Guides, Developer Docs, and OSSM assembly guide now.

The OSSM browser tools are back

The OSSM BLE controller is live again for direct control from a compatible desktop browser.

The OSSM Funscript player is also back as an experimental tool. It can play a local video and Funscript together over Web Bluetooth without uploading either file; they stay inside your browser.

Browser-based firmware tools are live again for OSSM, DTT, Lockbox, and RADR. These are intended for installing or recovering official firmware from a desktop browser when the relevant guide or support flow asks you to do so.

Quieter reliability work across every device

A lot of the recent work is intentionally boring. Firmware publishing across OSSM, RADR, DTT, and Lockbox now has stricter validation, immutable release artifacts, more predictable version allocation, and safer recovery behavior. This reduces the chance of a device being offered the wrong build or repeatedly trying to install the same update.

There have also been smaller product-specific fixes. OSSM received fixes for drift and repeated back-endstop behavior around BLE sessions. DTT can preserve completed training results when an upload fails and now has a safer migration path for older control boards. Lockbox received display-stability and break-behavior fixes. RADR has a more dependable release chain, along with public CAD for its battery cover.

These changes do not make dramatic demo videos, but they make everything built on top of them less fragile.

rad-ble is public

I released rad-ble v1.0.0 as a public, versioned ESP32 library and protocol.

The goal is to give our devices a shared language for controls, telemetry, resources, streamed inputs, outputs, and firmware updates. Developers should not need to rediscover a completely different set of conventions for every R+D product.

The library itself is available now. Its firmware integrations are moving through staging across OSSM, RADR, DTT, and Lockbox, so I do not want to describe the whole product family as migrated yet.

What I’m working on next

Smoother and safer OSSM streaming

The largest active piece is a major OSSM BLE streaming update.

Today, a stream of incoming positions can contain uneven timing, sudden jumps, delayed packets, or a backlog that is no longer relevant. A machine should not reproduce that input blindly.

The new planner treats the stream as a timed trajectory. It limits jerk and acceleration, drops stale backlog, improves buffering and connection timing, and keeps targets inside guarded travel limits. It can apply a gentle return toward the safe region when input disappears, then reset its motion state cleanly when playback stops. The branch also adds stress metrics and hardware validation tools so the behavior can be measured rather than guessed at.

This is still under review and hardware testing. It is the main thing I want technically curious OSSM owners and developers to help challenge.

One open control layer across the product family

The same BLE v1 contract is being integrated across RADR, DTT, and Lockbox as well. That does not mean forcing every product into an identical interface. It means using common discovery, identity, telemetry, and update conventions while each device exposes the capabilities that make sense for it.

RADR is especially useful here: it is both a product and an open, configurable controller, so it benefits directly from clearer resources and richer live controls.

Verifiable firmware without locking people out

I am also adding signed firmware provenance. Official builds will carry cryptographic evidence showing where they came from, and tools will be able to display that evidence.

This is not Secure Boot, flash encryption, or a plan to block community firmware. Owners and makers will still be able to build and flash their own code. Provenance is about making origin visible, not turning open hardware into a locked appliance.

On the developer side, I’m also cleaning up DTT schedule and session APIs, adding completion webhooks, and fixing Lockbox API duration behavior so earned adjustments are preserved. Those changes are still under review.

The larger direction

The useful version of “open” is not merely putting source code on GitHub. It is giving people understandable protocols, working tools, repairable hardware, documentation that can be corrected, and a safe path to experiment.

At the same time, openness cannot be an excuse for unreliable releases or unsafe motion. I want the normal experience to become calmer and more predictable while the edges become more configurable.

That means more shared open-source foundations, more browser-based tools where they make sense, better staged testing, and documentation treated as part of the product rather than an afterthought.

If you want to help, try the OSSM tools, inspect rad-ble, or review the OSSM streaming work. Bugs, strange edge cases, documentation fixes, and thoughtful disagreement are all useful.

Thank you for continuing to build this with me.

— AJ