Various minor corrections

timangus · timangus · commit b6eb177be6ff · 2025-08-29T18:14:28.000+01:00
diff --git a/_posts/2021-12-18-caddy-cruise-control.md b/_posts/2021-12-18-caddy-cruise-control.md
@@ -33,6 +33,6 @@ Now for the cruise control itself. It turns out that newer MFSWs (multi-function
 
 ![CC Wiring](/assets/caddy/wheel-9.jpg)
 
-In my case I also needed to re-pin the wheel a little, as in its stock configuration the horn would peep whenever I turned the cruise control on or off; not ideal. Anyway it all turned out well, though I use it less that I anticipated I would. If you get a quiet road it's fantastic, but if there's anybody in front of you they are inevitably unable to keep to a constant speed, so you're better just using the traditional right foot as opposed to constantly toggling the cruise control on and off.
+In my case I also needed to re-pin the wheel a little, as in its stock configuration the horn would peep whenever I turned the cruise control on or off; not ideal. Anyway it all turned out well, though I use it less that I anticipated I would. If you get a quiet road it's fantastic, but if there's anyone in front of you, they are inevitably unable to keep to a constant speed, so you're better just using the traditional right foot as opposed to constantly toggling the cruise control on and off.
 
 ![Finished Wheel](/assets/caddy/wheel-10.jpg)
diff --git a/_posts/2022-04-14-stans-hub-repair.md b/_posts/2022-04-14-stans-hub-repair.md
@@ -11,7 +11,7 @@ The culprit quickly became obvious, a broken axle in my [Stans](https://stans.co
 
 ![Broken Axle](/assets/bikes/stans-hub-repair-1.jpg)
 
-It seems quite ridiculous to me that they would have settled on Aluminium as the material for the axle. Everybody knows that Aluminium is extremely prone to stress fracture, and there are few more stressed components on a mountain bike that the hub axles. The total weight saving is probably less than 100g, which on a mountain bike is just noise. They did provide a steel option though, complete with PR bollocks along the lines of "suitable for today's discerning riders who demand more from their components...", just about tantamount to an admission of guilt that they'd made a mistake without actually saying so. Anyway, while waiting for a replacement to arrive I had another problem to deal with. One of the six freehub pawl springs had been ejected from its confines and crunched itself around the ratchet. We'll never know if this was related to the axle failure, but the springs live in the same lateral location as the axle break, so it seems somewhat possible. The pawls and springs weren't available anywhere (we were still experiencing pandemic induced supply chain issues), so the options were to reassemble with the remaining five pawls and hope for the best, or attempt to fabricate a new spring. There was nothing to lose with the latter option, so that's what I did.
+It seems quite ridiculous to me that they would have settled on aluminium as the material for the axle. Everybody knows that aluminium is extremely prone to stress fracture, and there are few more stressed components on a mountain bike than the hub axles. The total weight saving is probably less than 100g, which on a mountain bike is just noise. They did provide a steel option though, complete with PR bollocks along the lines of "suitable for today's discerning riders who demand more from their components...", just about tantamount to an admission of guilt that they'd made a mistake without actually saying so. Anyway, while waiting for a replacement to arrive I had another problem to deal with. One of the six freehub pawl springs had been ejected from its confines and crunched itself around the ratchet. We'll never know if this was related to the axle failure, but the springs live in the same lateral location as the axle break, so it seems somewhat possible. The pawls and springs weren't available anywhere (we were still experiencing pandemic induced supply chain issues), so the options were to reassemble with the remaining five pawls and hope for the best, or attempt to fabricate a new spring. There was nothing to lose with the latter option, so that's what I did.
 
 ![New Spring](/assets/bikes/stans-hub-repair-2.jpg)
 
diff --git a/_posts/2024-11-22-deviate-smart-shift.md b/_posts/2024-11-22-deviate-smart-shift.md
@@ -87,6 +87,6 @@ The [Deviate](https://www.deviatecycles.com/) family of bikes are all so called
 
 ![Finished](/assets/bikes/pinion-ss-21.jpg)
 
-All in all this had taken way longer than anticipated; I guess the software engineer's reputation as being notoriously bad at estimating project duration extends to the real world. It's all good though, I'm quite pleased with it. At the time of writing I've got about 100km on it, so while not at the bottom of the [bathtub](https://en.wikipedia.org/wiki/Bathtub_curve) yet, the gradient is surely starting to level off a bit. Pinion's claims of being able to shift under load are as expected a bit exaggerated (especially at the 4/5 and 8/9 boundaries), but for sure it shifts much better than its predecessor. It also shifts much more quickly compared to the Cinq trigger shifters. I did try the *Pre.Select* feature for a while, which auto shifts when coasting, but it's a little eager to do so for my liking. My suggestion would be that they introduce some hysteresis into the system so that you need to be coasting for a number of seconds before it gets enabled, and then similarly it is disabled after pedalling for the same number of seconds. It really comes into its own when descending, where you're coasting most of the time and not necessarily focused on what gear you should be it; having it auto shift so you're always in a sensible gear is pretty cool. I would just manually turn it on for descents, but to do so inevitably involves using a phone app, a phone app which seems quite reluctant to connect at the best of times, so that's not really practical. I have noticed that there are [CAN bus](https://en.wikipedia.org/wiki/CAN_bus) lines in the loom though, so maybe working around these niggles is a future reverse engineering project.
+All in all this had taken way longer than anticipated; I guess the software engineer's reputation as being notoriously bad at estimating project duration extends to the real world. It's all good though, I'm quite pleased with it. At the time of writing I've got about 100km on it, so while not at the bottom of the [bathtub](https://en.wikipedia.org/wiki/Bathtub_curve) yet, the gradient is surely starting to level off a bit. Pinion's claims of being able to shift under load are as expected a bit exaggerated (especially at the 4/5 and 8/9 boundaries), but for sure it shifts much better than its predecessor. It also shifts much more quickly compared to the Cinq trigger shifters. I did try the *Pre.Select* feature for a while, which auto shifts when coasting, but it's a little eager to do so for my liking. My suggestion would be that they introduce some hysteresis into the system so that you need to be coasting for a number of seconds before it gets enabled, and then similarly it is disabled after pedalling for the same number of seconds. It really comes into its own when descending, where you're coasting most of the time and not necessarily focused on what gear you should be in; having it auto shift so you're always in a sensible gear is pretty cool. I would just manually turn it on for descents, but to do so inevitably involves using a phone app, a phone app which seems quite reluctant to connect at the best of times, so that's not really practical. I have noticed that there are [CAN bus](https://en.wikipedia.org/wiki/CAN_bus) lines in the loom though, so maybe working around these niggles is a future reverse engineering project.
 
 I still need to find a good way of making the charge cable accessible externally. For now it just pokes out of one of the existing cable holes near the headtube, secured with Kapton tape. Some sort of TPU based 3D print will probably solve this one, but clearances are tight so it will need a bit of thought. The battery is so comically large that it will only need charging quite rarely, so this isn't a particularly pressing issue.
diff --git a/_posts/2025-01-27-pinion-charge-port.md b/_posts/2025-01-27-pinion-charge-port.md
@@ -49,7 +49,7 @@ Having proved the print could work with the epoxy casting, the only thing left t
 
 ![Pre Insertion](/assets/bikes/pinion-charge-port-10.jpg)
 
-It was a bit of a squeeze to get the head of forward most zip tie through the hole, but it's just about large enough.
+It was a bit of a squeeze to get the head of the forward most zip tie through the hole, but it's just about large enough.
 
 ![Installed](/assets/bikes/pinion-charge-port-11.jpg)
 
diff --git a/_posts/2025-08-09-pinion-garmin-settings.md b/_posts/2025-08-09-pinion-garmin-settings.md
@@ -15,7 +15,7 @@ After some setup gymnastics I got the dongle to work with [Wireshark](https://ww
 
 ![Wireshark Bluetooth Packet Capture](/assets/bikes/pinion-garmin-app-wireshark.png)
 
-I later realised that I could have saved myself quite a lot of effort here by just reverse engineering the phone app itself, but dismissed it as impractical and too time consuming versus just sniffing the data itself. However it turns out the that app is written in Javascript, and as such is trivially easy to understand. The wizened old software engineer that I am assumed that something that communicates with actual hardware would be written in a lower level compiled language like C++, or at least Java/C#/Kotlin, but no, Javascript! Learning about Bluetooth sniffing was quite interesting, regardless. Anyway, I digress.
+I later realised that I could have saved myself quite a lot of effort here by just reverse engineering the phone app itself, but dismissed it as impractical and too time consuming versus just sniffing the data itself. However, it turns out that the app is written in Javascript, and as such is trivially easy to understand. The wizened old software engineer that I am assumed that something that communicates with actual hardware would be written in a lower level compiled language like C++, or at least Java/C#/Kotlin, but no, Javascript! Learning about Bluetooth sniffing was quite interesting, regardless. Anyway, I digress.
 
 From here I started to look into the Garmin ecosystem, to see how the Smart.Shift box might be addressed from a Garmin device, such as my aging [Edge 530](https://www.garmin.com/en-GB/p/621224/). They have a platform called [ConnectIQ](https://developer.garmin.com/connect-iq/overview/) which allows for third party developers to write apps for their devices. I have various critical thoughts about this, but I'll save those for a later [addendum](#and-now-for-my-rants) as they're not really relevant to the job in hand. Anyway, to test the waters, I set about to develop a simple data field that displayed the current gear of the Pinion. It was very quick and dirty, doing the absolute bare minimum of error checking or good abstraction, the point being simply to see if it could be made to work at all.
 
