Garmin App for Pinion Smart.Shift Settings

In one of my earlier posts where I discuss my first impressions of the Pinion Smart.Shift gearbox I had fitted to my bike, I had a little moan about the missed opportunity in the Pre.Select auto shifting feature. This is a setting where a gear is automatically pre-selected if the system detects you’re coasting. In general I like it, but it becomes annoying when switched on all the time. For me I only really want it enabled on descents, where it comes into its own. What is really needed is a simple way to easily toggle it on and off as and when required. Sadly Pinion don’t agree, and the only way you can do so is via the phone app. When you’re covered in mud and have got gloves on, and your phone is safely tucked away in your backpack, it’s really not very convenient to have to get it out, take your gloves off, hunt around for the app etc., just to change a single setting.

After posting about my charge port 3D print, there developed a conversation in the comments beneath the post about the possibility of displaying the current gear on a bike computer. I had previously noticed that there were CAN Bus lines in the loom that I thought might potentially be a source for reverse engineering a system for getting at such data, but the initial commenter pointed out that (obviously, in hindsight) the phone app must communicate with the Smart.Shift box via Bluetooth, and was asking if I might take a look. Initially just using my phone to verify that it was indeed advertising Bluetooth, intrigued, I subsequently got myself a Bluetooth sniffer dongle and started to look a bit deeper. (Incidentally, I designed and printed a case for the dongle, having stupidly bought the caseless version.)

After some setup gymnastics I got the dongle to work with Wireshark and set to work. By going through the options one by one on my phone as I simultaneously did a network traffic capture and screen recording, I was able to correlate the changing bytes to settings I was changing on the phone. It’s quite a simple protocol, so relatively quickly I had an idea of how it worked. I would later learn that it’s essentially the CANOpen protocol, and the data was in the form of SDOs (Service Data Objects). To ease my understanding I wrote a dissector, basically a plugin that would decode the data so that Wireshark could display it in a more human readable format. Incidentally this gave me strange flashbacks to my first job out of university, where the game we worked on used Lua as its scripting language; I hadn’t used it since then.

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.

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. They have a platform called ConnectIQ 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 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.

It’s a bit slow due to accumulating polling delay, but as you can see it does work. I tried it out on an actual bike ride but found that the connection had a tendency to drop after a few minutes, unfortunately making it not very practical (although, more on this later). In order for a device to connect to the Smart.Shift box — be it the phone app or anything else — it must be put into ‘pairing’ mode. To most people who have used Bluetooth devices, ‘pairing’ implies forming a persistent, automatic connection between two devices. However, Pinion’s ‘pairing’ mode is actually a misnomer; it simply turns on Bluetooth advertising for a short period, making the gearbox visible to other devices. This means that if the connection to your Garmin drops for any reason, you must manually hold down the rear shift button for 3 seconds again to re-enable advertising and allow the device to reconnect. It’s this manual intervention that makes the gear display data field a bit impractical for continuous use. If the Garmin to Smart.Shift connection drops for any reason, and the Smart.Shift box is no longer advertising, the data field can’t reconnect itself without manual user intervention; hardly ideal.

(It was at about this time that Patrick Schlangen showed up the comments of the previous post, having independently followed much the same path as I had, and developed his own gear/battery display Smart.Shift widget. He was finding, as I was, that the connection dropped often and easily, so abandoned his effort there as a result. He subsequently took things much further and made a lot of progress reverse engineering the CAN protocol, as I had originally suggested I might attempt. Unfortunately for other reasons that seems to have also hit a dead end. Nevertheless we had a very interesting conversation. He also has a blog where he documented his project to use Shimano brake levers with his Pinion. Check it out!)

The connection persistence isn’t really a great concern from my point of view, where my use case is just turning Pre.Select on and off - having to enter ‘pairing’ mode is just an inconvenience. Speaking of which, I now turned my attention to how I might implement this function. ConnectIQ apps exist in three flavours: Data Fields, Apps and Widgets. The Data Fields are as already discussed, a non-interactive¹ way of displaying data to the user. Apps are full blown applications, launched from the Garmin’s main menu. Unfortunately, they can only be started when not already engaged in an activity (i.e. a recording of your bike ride), so are not much use for anything during a bike ride. That leaves Widgets, that are very much like Apps besides a few restrictions, but crucially they are able to be executed from the Widgets menu, during an activity. So a Widget it was.

Good software engineer that I am, I decided to implement the Pinion communication part of my widget as a library (or a ‘Barrel’, in ConnectIQ terms). I’ll spare you the details, but I probably went a bit overboard here in terms of my actual needs. If you implement the code for dealing with switching one setting, other settings are obviously going to be very similar, so why not add those too? Long story short, the library can read and change all the settings that you’d realistically want to.

For the app itself I decided that since I had made this library that can read and write all the settings you’d realistically want to, I may as well just make a UI that allows you to use most of the features of the library. So that’s what I did, effectively ending up with a near-clone of the phone app. Again, I’ll spare you the details, it’s just normal software development stuff for the most part.

I mentioned before the difficulty in establishing a connection to the Pinion from the Garmin with my quick hack gear indicator data field. For the purposes of the settings app this was less of a concern, but nevertheless it was still a present irritation, and a confusingly inconsistent one at that — sometimes it would connect and persist absolutely fine. Eventually I established that the pattern was that the connection problems only occurred when I was wearing my Polar heart rate monitor. I found it was configured to connect using ANT+, so on a whim decided to try switch it over to BLE mode, and… the Pinion/Garmin connection problems immediately went away. Whether this is the fault of Pinion, Garmin, Polar or just the general congestion of the 2.4Ghz radio band, I don’t know, but it’s nice to have that fixed. I may have another look at doing a gear indicator data field, now that this is (apparently) solved, and that I have written a nice library to talk to the Pinion.

The net result of all of this is that I’m now able to turn my Pre.Select on and off during a bike ride. It still could be a lot better in that in order to do so I first have to put the Smart.Shift box in pairing mode by holding the button, then on the garmin I need to go back to the home screen, up to the status page, up again to select Widgets then select to start the widget, then select to toggle Pre.Select, then all those steps in reverse to get back to my activity. In total it’s a Konami Code-esque Back, Up, Up, Select, Select, Back, Select, which is a lot for what should really just be a long press on one of the shifter buttons or something, but in any case is still way, way, way better than having to fumble about with my phone during peak Scottish Winter.

If you have a Pinion Smart.Shift gearbox and a Garmin Edge device, in theory you could side load² the widget and have a play with it yourself. I have GitHub configured to automatically make builds for various Edge devices, so do feel free. If there are people who actually find this useful I might publish it through more official channels, but given the number of hacks I was forced to employ and quirks I encountered during development, I’m slightly reticent to do so on devices that I don’t own and obviously can’t test myself. If you do try it out and happen to have something other than an Edge 530, do let me know your experiences and if it works for you. Obviously this is not an official Pinion product, so it may brick your gearbox or void your warranty or eat your homework, and I accept no responsibility for any of that. I mean it won’t, but if it does it’s not my fault.

Despite some frustrations, this was quite an interesting project to work on. I’m a strong advocate for trying to develop for a new software platform or paradigm on a regular basis, as you’ll almost always learn something new, and it keeps you sharp. It’s something I haven’t really done enough of in recent years.