18 comments

[ 3.3 ms ] story [ 39.5 ms ] thread
> As for my original sync problem? After all of that – decompiling an APK, reverse engineering a binary protocol, writing a BLE exploit script – it turned out the issue was on my phone the whole time. Not the cycling computer. The phone.

I can feel the pain.

I think about troubleshooting like OBST with test cost. Systems are a linear chain of points of failure. The more knowledge you have about how hard components are to test and which components break more often, the easier it is to choose the tests that optimize your time.
There seems to be a debugging pattern that arises when problems are in proximity to a poorly understood, highly complex part of the system: We tend to think that's where the problem probably is. And we can lose an inordinate amount of time looking for it there. It's like an inverse streetlight effect.

I've seen coding LLMs do it too. I have a well-tested, but complex, subsystem that constantly draws their attention when something non-obvious elsewhere goes wrong.

That's pretty interesting; I've always wondered about the internals of those things, as I stared at mine while pedaling up some steep grade.

I'm also curious about what the electronic derailleurs and shifters run.

That’s a really good point.

They also never seem to fail (unless the batteries are flat).

Fun fact: my non e-bike has lots of batteries.

2 in the shifters 2 in the derailleurs 1 in the front light 1 in the rear light/radar 1 in the computer + phone AirPods (transparency mode!).

Title is: How a Broken Bike Sync Led Me to Reverse Engineering My Wahoo's Hidden Debug Mode
I found this really hard to read due to the Claude-isms. "Classic" chicken and egg problem? 39 em-dashes, random numbered lists, etc.

If you're not going to even bother to take the time to write an article, why should I waste my time reading it?

Welcome to Hell, Reader.

(I liked the article, personally.)

Started reading, saw "That was it, That was the whole reason", closed the page.
"How a Broken Bike Sync Led Me to Reverse Engineering My Wahoo's Hidden Debug Mode" - this is brain-dead AI slop right in the title.
Yeah, I saw an oddly placed rule-of-three and closed the tab.

This website is going downhill, almost every blog post I open is just blatantly AI generated these days. It's like people don't have any self-awareness anymore, they just lazily prompt their AI to generate a post and then pat themselves on the back lol.

I love reading these kinds of stories!
I can't help imagining someone trying to debug this rigging their laptop to their bicycle handlebars, connecting to the ride computer and then going for a ride to get live data for the debug session.

It would be very hard not to die in a traffic accident while debugging in this way.

Welcome to hell, developer!

Tying to get a bike computer to work while riding is incredibly painful.

I’m a Garmin user and it blows my mind that the interface was chosen. Buttons and touch screen and confusion.

Not helped by both Garmin and Strava not putting enough arrows on the path of travel on their maps.

If you have a route the uses the same road in both directions (eg you ride to somewhere then back along the same path) it isn’t possible to tell when to turn off. Why can’t there be arrows indicating direction of travel?

And that’s when it’s working. Garmin seem to break shit on software updates and then sync stops working, the radar disconnects, it won’t lock on a satellite etc.

Can Apple make a bike computer please? Or at least play nice and sync their watch with Garmin properly?

It’s frustrating that this isn’t completely typical. As the writeup pointed out, this “exploit” can only be performed by the device owner anyway, so nobody is harmed by the unlockability. But 95% of devices that are sold, besides non-Mac PCs, and SBCs, are locked down completely, prohibiting anyone from using the device as they like.