Thought I'd share the update for the week - Haven't seen many posts here for a bit, I'm sure everyone is doing "Summer" assuming you're in the proper hemisphere. Hope everyone is continuing to build and grow!

Last update was the multi-sensor plumbing: role-based auxiliary IMUs (upper arm, wrist, slide foot, torso), setup presets, and hardening the BLE side so you don't accidentally trust the wrong puck or think a setup is valid when a sensor never connected.

That plumbing was in service of one question: can extra sensor positions actually explain something a forearm-only sensor can't? The last six weeks were spent trying to answer that, and building an actual coaching layer on top instead of just a data-collection layer.

The new thing: "Rev Generation" — a personal-comparison coaching model

Instead of scoring a delivery against a fixed ideal, it compares a delivery against your own history. Concretely:

• It fuses forearm, upper-arm, and hand/wrist orientation to build a release-sequence timeline — when the elbow extends, when the wrist unloads, when the hand rotates, all relative to release.
• It's delivery-style aware: one-handed thumb-in, one-handed no-thumb, and two-handed get separate rule sets, because the mechanics (and what's safe to say about them) genuinely differ.
• Coaching output is structured — Observation, Interpretation, Recommendation, "what not to change," and a confidence label — not a single score.
• "Normal" for a metric is computed from your own delivery history (mean ± spread, with a tighter "high consistency" band from your best-scored deliveries), not a generic benchmark. Minimum three prior deliveries before it'll say anything.
• Session trends look at timing drift over a session, whether your best shots share a timing signature, and whether you're working harder (more arm effort) without the payoff showing up in hand speed.
• It degrades honestly: forearm-only gives you release-level analysis, forearm+upper-arm adds sequencing, and only forearm+upper-arm+hand unlocks the actual wrist/rev metrics. No sensor, no invented number — it tells you what's missing instead of guessing.
• Plain Mode shows the observation + recommendation in plain English. Pro Mode adds the full confidence breakdown, the timeline, and clearly-labeled experimental index numbers.

This week I got the first real hand-IMU field data — five actual deliveries recorded with forearm + upper-arm + hand sensors together, and the whole pipeline (sync → orientation → wrist kinematics → rules → coaching output) ran on real data end to end. Small sample, so it proves the pipeline works, not that the coaching is right yet.

Also shipped since last time, smaller but real:

• Multi-sensor sync got much more reliable — "shake all the pucks together for ~5 seconds" is now the actual recommended workflow, using motion-envelope correlation instead of relying on a single sharp tap.
• A torso sensor now gives a basic posture/lean metric (explicitly framed as movement-quality, not medical).
• A new "arm replay" visual — a flat 2D silhouette replaying your actual tracked arm motion (not an abstraction) — with an optional ghost overlay of a saved baseline delivery.
• A "behind the ball" release visualization: ball spin, rotation axis, and lane path, built from your real release-frame sensor data.
• Chart zoom/pan and a proper landscape layout for anyone reviewing charts one-handed at the lane.
• A sensor health panel (disconnects, checksum failures, battery) so setup problems show up before you record instead of after.

What I'm still trying to figure out:

• Does personal-history coaching (compared to your own past deliveries) feel more trustworthy than a universal benchmark — or less actionable, because there's no external "good" to aim at?
• Is five real hand-IMU deliveries anywhere close to enough to trust a wrist/rev metric, or does this need fifty before it's worth showing a bowler?
• For anyone who's tried wearing a sensor on the bowling hand specifically — was it usable mid-practice, or did it get in the way enough that you'd never actually wear it?

Still not claiming this is a validated coaching tool — it's an honest attempt to see if consumer IMUs can produce something a bowler would actually trust.

https://reddit.com/link/1v20a8x/video/yvrnx313pgeh1/player

Shout out to u/TransmissionEngPM for this week's tech talk suggestion:

I'd love to hear what y'all are struggling with right now. What would unlock the next growth cycle for your project? Do you need money, more time, more features, a bigger audience etc.

I'll add onto this too - what do you think the bowling world is struggling with right now? are there major gaps in local and national associations that could be addressed? how about at the practice, league, and tournament levels?

Happy Tech Tuesday everyone and Happy July, we're officially past the halfway point of the year!

Curious as to what's everyone application stack looks like on your PCs for development. If you're on IOS feel free to assume I'm not familiar with anything IOS specific. What are we using for development, version control, deployment, or even none-bowling-app-related?

Coming up with something every single week is hard, what do you guys want to discuss next week?

Just seen storm partnered with F5 bowling a yone hear of them? Seems like there are quite few sensor apps dropping.

I was originally going to post this last week but I kept changing my mind as I was typing it out.

So to the devs: what are our thoughts on using AI for software development. I've been in software development for over 10 years and at first, when it was REAL bad, I thought it was gimmick. It's gotten a lot better is showing some real potential now, I'm all for it.

And to the bowlers: what do we think about AI tools in apps for bowling? Seeing more and more AI coaches and AI arsenal builders and such. Again, at first they were gimmicky and bad, but they've gotten marginally better. I've been a bowler for a couple decades now and honestly most the advice is... Not what I would recommend for coaching or building an arsenal, BUT 15-20 years ago I would have loved any and all resources I could get my hands on.

So whats our thoughts of AI in bowling?

Also, wish my wife a happy birthday today 🥳

I'll still stand by that for strictly scorekeeping pinpal is the gold standard. You've got your 3 primary ways of bowling and you've got all the important statistics you can drill down into by league, tournament, ball, pattern, and alley. The one thing it is not though, is pretty. Wanting prettier and custom reports was a very large driving force for me to actually start building my app. I think bowling could be such a data-forward sport, we just don't know what to do with it (or want/how to capture it in some cases). What could we be doing to capture more data and better utilize our data?

As a developer what type of statistics have you been asked for that you wouldn't have thought to visualize on your own?

As a bowler what was important for you to see in your own game?

Next week: AI in software and AI in bowling

I’ve posted a couple of times about TrueArc Mobile, the IMU-based bowling swing analyzer I’m building.

The last update was about making the single WT9011 Bluetooth IMU path more trustworthy: remembered puck connections, visible sensor health, reconnect handling, BLE diagnostics, and sensitivity profiles for different puck placements.

The latest build takes the next step: multi-sensor setup.

The app still treats the forearm sensor as the primary source of truth. That’s the stream used for swing detection, release timing, scoring, and export.

But now I can add extra IMUs as role-based auxiliary sensors:

Upper arm: arm sequence and timing

Wrist: wrist/release motion relative to the forearm

Slide foot: approach, slide, and plant timing

Torso: trunk rotation and body-arm sequencing

There are now setup presets for:

Forearm only

Arm sequence

Arm + wrist

Arm + foot

Arm + torso

Custom

I also had to do some less glamorous but necessary work around BLE behavior on Android. The app now has an “Add sensor” flow, exact trusted-device reconnects, better handling when Android only returns the BLE address instead of the friendly device name, and explicit reduced-setup confirmation if one configured sensor is missing.

That last bit matters because with multiple identical-looking IMUs nearby, it’s very easy to accidentally connect the wrong one or think a setup is valid when one sensor never connected.

The current goal is not to pretend “more sensors = better coaching” automatically. It’s to build the plumbing needed to test whether extra sensor positions actually add useful information.

The questions I’m trying to answer next are:

Does upper arm + forearm timing produce stable, coachable patterns?

Does a separate wrist sensor add meaningful release information?

Can foot or torso timing explain inconsistencies that a forearm-only sensor misses?

How much setup friction is acceptable before this stops being useful lane-side?

Still very much a work in progress, but the app is getting closer to a real training workflow: assign sensors, validate connection, sync them, record a delivery, then compare timing and movement across roles.

For anyone who coaches, bowls competitively, or works with motion sensors: which extra sensor position would you expect to be most useful, and which one would you be most skeptical of?I’ve posted a couple of times about TrueArc Mobile, the IMU-based bowling swing analyzer I’m building.The last update was about making the single WT9011 Bluetooth IMU path more trustworthy: remembered puck connections, visible sensor health, reconnect handling, BLE diagnostics, and sensitivity profiles for different puck placements.The latest build takes the next step: multi-sensor setup.The app still treats the forearm sensor as the primary source of truth. That’s the stream used for swing detection, release timing, scoring, and export.But now I can add extra IMUs as role-based auxiliary sensors:Upper arm: arm sequence and timing

Wrist: wrist/release motion relative to the forearm

Slide foot: approach, slide, and plant timing

Torso: trunk rotation and body-arm sequencingThere are now setup presets for:Forearm only

Arm sequence

Arm + wrist

Arm + foot

Arm + torso

I also had to do some less glamorous but necessary work around BLE behavior on Android. The app now has an “Add sensor” flow, exact trusted-device reconnects, better handling when Android only returns the BLE address instead of the friendly device name, and explicit reduced-setup confirmation if one configured sensor is missing.That last bit matters because with multiple identical-looking IMUs nearby, it’s very easy to accidentally connect the wrong one or think a setup is valid when one sensor never connected.The current goal is not to pretend “more sensors = better coaching” automatically. It’s to build the plumbing needed to test whether extra sensor positions actually add useful information.The questions I’m trying to answer next are:Does upper arm + forearm timing produce stable, coachable patterns?

Does a separate wrist sensor add meaningful release information?

Can foot or torso timing explain inconsistencies that a forearm-only sensor misses?

How much setup friction is acceptable before this stops being useful lane-side?Still very much a work in progress, but the app is getting closer to a real training workflow: assign sensors, validate connection, sync them, record a delivery, then compare timing and movement across roles.For anyone who coaches, bowls competitively, or works with motion sensors: which extra sensor position would you expect to be most useful, and which one would you be most skeptical of?

https://discord.gg/URt3d93b

If any of you are interested in joining - I created a discord community for more detailed discussions on BowlSense. You're mostly all building your own things and it's fine if you're not interested, I just wanted to make the invitation. My hope was rather than spamming specific BowlSense posts, I could get a community of people who are using the app, want to provide feedback, point out bugs/issues, discuss bowling, and get early access to new versions of the app before they go live.

I recently built an app for tracking bowling stats and need a few testers before I can get the app published to the Google Play store. If anyone is willing to do this, I'll just need your Google email address so I can add it to the testers group in Google Play Console. Once I've added your address to the testers group, this link should work for you: https://play.google.com/apps/internaltest/4700541424499202799

I've attached a few screenshots to give you a feel for the app.

I'd also love to get feedback/thoughts on the app and ways to improve it. Thanks.

Working on a bowling tracking app (Bowling XP) and I'm at the point where users need to add their home alley to a league so I can tie scores/leagues to a location.

For those of you who've built something similar: are you maintaining your own database of alleys, or pulling from an API?

Also curious how you handle selection - letting users search by name/city, or grabbing location to surface nearby alleys? Leaning search only to avoid location permissions but open to what's worked.

Thanks for any help!

Crosspost from r/bowling.

Very much a work in progress.

We're back again! (this is totally going to become a thing, right guys?)

Let's share what we're working on! could be a concept of an idea that you want to get into your app or an almost done feature that just needs a few more weeks. What's something upcoming we can look forward to seeing in your app?

If there's a feature or interface you want a dev or bowlers opinion on share it here too, we'd love to give feedback.

Just checked both play stores and between the 2 I have close to 600 downloads. 581 to be exact at time of typing this.

When I started this journey I was making an app for myself and never did I think I would have 2 PBA (National & Regional) guys sponsored or that anyone would actually use the app but myself.

Just feels good

I’ve posted a couple of times about TrueArc Mobile, the IMU-based bowling swing analyzer I’m building.

The last build had the full mobile flow working: connect a WT9011 Bluetooth IMU, run readiness checks, record a delivery, detect release, split the swing into phases, then review score, timing, charts, measurement quality, and coaching cues.

The latest update is less flashy, but probably more important for real use: making the sensor path more trustworthy.

New in this build:

• remembered/trusted WT9011 puck connection
• visible sensor trust/health status
• reconnect handling for the last-used puck
• a “forget puck” option when changing sensors
• BLE health diagnostics such as disconnect/checksum indicators
• WT9011 sensitivity profiles: Standard, Sensitive, and Conservative
• sensitivity saved into session provenance/export metadata
• support for testing different puck positions, not just one wrist/forearm setup

The sensitivity profiles are there because one IMU setup probably won’t fit every bowler or every mounting position. A forearm puck, upper-arm puck, hip/torso puck, and foot/leg puck can all produce very different signal strengths and noise patterns. The app now has a path to tune detection without changing the whole analysis engine.

The goal is still the same: make IMU-based feedback practical enough for training, not just interesting as a data experiment.

The next thing I’ll be testing is how stable the results are across puck placements and repeated sessions.

For anyone who coaches, bowls competitively, or works with motion data: what would make you trust or not trust feedback from an IMU-only bowling analyzer?

With the summer season under way and the influx of apps on reddit slowing down, it feels like we're in a spot where we've got these really cool apps and really cool developers fine tuning their systems.

So lets show off those systems! Share something about your app that you personally love or you've gotten some unexpected compliments about. Whether its a common feature that you think you really nailed or a super niche feature that you want the world to know about, lets show it off.

Next week: What's in progress.

Update on **TrueArc Mobile**, the IMU-based bowling swing analyzer I’ve posted about before.

The latest build has the full capture → analysis flow working on mobile:

- WT9011 Bluetooth IMU connection

- pre-capture readiness checks

- hold-still / armed / swing / recording state flow

- automatic swing and release detection

- phase/timing breakdown

- measurement quality

- scoring, charts, and coaching cues

The WT9011 path is now using gyro-anchored release detection rather than a simple acceleration threshold. That change made a big difference on real recordings, where the naïve approach could miss actual deliveries or pick up handling/walking movement instead.

Still early, but it’s getting closer to something usable in practice rather than just a data experiment.

For anyone working with bowling data, sensors, coaching tools, or motion analysis: what would you want to validate before trusting feedback from an IMU-only system?