Motion capture, and the layer where a device meets a phone

TuringSense, Inc.Senior Software EngineerSanta Clara, CaliforniaJan 2020 – present

C#UnityJavaAndroidBLE

The hardest ones talked to hardware — BLE, motion sensors, and the awkward layer between a device and the phone in your hand.

The stack

C# inside Unity: real-time 3D, motion capture, and the Bluetooth link between a sensor garment and the phone driving it. The parts I own are underneath the 3D — the native Bluetooth layer, written in Java, and the wrapper our apps talk to.

The plugin we depended on stopped being maintained

Our Bluetooth connection came from a Unity plugin bought off the asset store. It worked until it didn’t. During demos in expo halls and hotel function rooms, the connection between the phone and the garment would drop and then fail to come back. The only recovery we had was to kill the app and start the demo again, in front of whoever we had brought there to watch it.

The plugin had not been updated since July 2024, the fix needed changes inside the plugin’s own code, and its author was not in a position to help. So we stopped waiting. We wrote our own Android Bluetooth plugin — TSBLE — in Java against the platform’s native BLE API, which put reconnection somewhere we could actually reach it.

The bug that took weeks

Writing the reconnection was not the hard part. The hard part was that the layers disagreed about reality.

Unity held a connection state. The Android layer held a connection state. And underneath both of them, the radio would sometimes reconnect on its own and tell neither — so the app believed it was disconnected while the hardware was happily streaming, or the reverse. Add a threading bug that only appeared when the reconnection landed at the wrong moment, and we spent weeks in the failure cases rather than the feature.

What fixed it was deciding which layer was allowed to be right. The native layer sits closest to the radio, so the native layer owns connection state; our SDK wrapper polls it and reconciles rather than keeping a second copy; the app subscribes to the wrapper and never tracks connection itself. One source of truth, at the bottom, and everything above it derives.

Before that: getting rid of nine seconds

Earlier on, the garment and the app spoke over WiFi. Establishing that link meant picking a channel and running a sequence of checks before anything could be trusted, and a user watched a spinner for around nine seconds every time they connected.

We moved the transport to Bluetooth outright. The channel selection and most of the verification went away with it, and connecting — including verification — settled at about two to three seconds. Same product, same garment; the spinner just stopped being something you noticed.

The patent

I am a co-inventor, second of seven named, on US 12,198,243 B2, “Online interactive platform with motion detection” — granted 14 January 2025, with a priority date in September 2015. It covers comparing a person’s movement against a reference. The company holds it; I contributed to it.

What the last two years have actually been

There has been no shipped release in two years.

I am at TuringSense part-time now.

The company has spent that period pre-contract — building and demonstrating systems for customers whose agreements are not signed, so there is nothing I can show you and nothing I can name. What I have to point at is TSBLE and the reliability work above, both from 2025, and demos that now survive a bad room.

One handoff

An intern joined with no Bluetooth background at all and worked with me on TSBLE. By the end she was researching BLE Mesh on her own — not being walked through it, going and finding out. That is the measure I care about: not what someone can do while you are sitting next to them, but what they can do once you are not.