My first port of call was to survey the usual Chinese megastores e.g. AliExpress, Temu etc., and I ordered a few very cheap options. The strongest contender were claimed GPS trackers, that took a SIM card and periodically reported their location to a service located in the PRC, which you then accessed with an ad-laden app. This in itself felt a bit dodge, but since the device wasn’t actually a GPS tracker at all, just a highly inaccurate cell tower based tracker, and the fact that it had abysmal battery life, it was a non-starter. Instead, after speaking to a friend, I got myself a PebbleBee tracker. This is basically an Android equivalent of an Apple AirTag which don’t track in themselves, but rely on briefly connecting (via BLE) to nearby/passing mobile phones which then report the tracker’s location on its behalf. At ~£25 each this was somewhat more than I really wanted to spend, especially in that if and when the bin does again go AWOL, I may not necessarily be able to retrieve it from wherever it ends up. Nevertheless, I coughed up the required notes chiefly because I JUST WANT TO KNOW WTF IS HAPPENING TO MY BIN.

The PebbleBees themselves are nice bits of kit, pretty small and unobtrusive, are USB-C chargeable, and have a nice loud beeper and bright LEDs for when you want to locate an item. They also integrate with the Google Find Hub system, so you don’t need to use any software from PebbleBee directly. They have obviously not been engineered for tracking a bin however, and have a key ring style form factor. Now I could have just got a bit of double sided tape or glue and stuck the thing to my bin and said job done, but this would have looked highly conspicuous to an inquisitive refuse collector and furthermore would have made charging the battery quite annoying. Fortunately it doesn’t seem like this needs to be done particularly often, but if you’ve read any of this site before you’ll know that I only need the vaguest of excuses for a 3D printing project.

The bin itself is a standard injection molded affair as you’ll find in many cities across the world. I identified a suitably discreet pocket inbetween two reinforcing ribs, that was just about large enough for the tracker, and set about designing a housing. Eventually I arrived at a form where one half is permanently affixed to the bin, and the other secured to the first via two print-in-place screws, facilitating occasional removal for the aforementioned charging. The PebbleBee claims IPX6 water-resistance, but since it will always be facing downwards it should never get directly wet, besides condensation or humidity. Nevertheless I added a hole to the half that houses the tracker, doubling up as an outlet for the built in speaker and as a drain hole for any moisture that does accumulate.

As installed and printed in black it’s quite discreet – you’d have to be paying close attention to notice it. It’s been about a month now and my bin remains mercifully present. Rest assured if it ever goes missing again I will update the post to (hopefully) explain its fate, but having gone to all this effort it almost certainly won’t.

The camera that comes with the kit is designed to stick to the rear screen, assuming you have one, or above the number plate. I already have a camera here for the parking camera connected to the head unit, and besides, for the purposes of seeing rearwards, mounting it there is really lower down than ideal. Instead I decided to place it higher up, in line with where the real sight line would be, had it existed. It turns out that you can get aftermarket third brake lights that integrate a camera, specifically for this purpose.

The quality of this item is… OK. It’s obviously been reverse engineered from the real thing then various measures have been employed to reduce the cost as much as possible. Now, I know from experience that reverse cameras are basically all 5 volt, S-video based affairs, so I probably could have managed to graft this camera into the wiring for the new one, but rather than risk this not working, instead I made an adapter that allowed for the new camera to mount to the third brake light housing.

In addition to the adapter itself I made a TPU gasket and seal for the existing hole in the third brake light housing. When I eventually fitted this I liberally coated the interfacing surfaces with RTV silicone, hopefully avoiding any water ingress

The usual iterative process was employed and I eventually ended up with a functional prototype in PLA.

PLA, however, was not going to cut it. In addition to not really dealing with heat very well, PLA is also not especially stable under UV light, both properties that make it an unsuitable polymer for use in an outdoor context. Instead therefore, I decided to try printing it with ASA, a close relative of the more common ABS. These plastics don’t have the downsides of PLA, but unfortunately are a bit tougher to print. In addition to fuming slightly when melted, ASA and ABS basically require a heated chamber as otherwise printed layers cool too quickly and contract/curl to the point where they don’t adhere to the underlying layer; ask me how I know. Rather than replace my geriatric printer with something more modern that has an enclosure, I decided to upgrade what I had using a different means.

By simply turning the bed heater on and letting the printer “soak” for half an hour or so prior to printing, the temperature under the box rises to 45°C and ASA prints successfully, without issue. The only real downside to this approach is that by enclosing the entire printer, there is a slight risk of cooking its electronics, but in the grand scheme of things it’s a pretty low risk.

In addition to the other components I also made this tiny little shim that glues to the connector socket of the brake light housing. This compensates for the extremely loose interface that presumably results from some injection moulding related failure.

In addition to the poor injection moulding, another shortcoming of the third party brake light is that the fresnel diffuser is completely absent, meaning that when the brake light is activated you see each individual LED quite distinctly. I’m not particularly bothered by this myself in that unless something has gone horribly wrong, I’m unlikely to be looking at my own brake lights. On the other hand, my friendly local MOT inspector may not see things quite the same way, so I took the diffuser from the existing brake light and carefully modified it via sandpaper to fit the new housing, because obviously it can’t be easy and just slot in to the knock-off.

It needed a bit more finagling with a heat gun to bend some of the assembly tabs into places they now needed to be, and the metal mounting plates from the original light needed some modification to fit the new one, but eventually a cobbled together solution was arrived at, and the whole thing fitted to the rear door of the van.

Thereafter it was just a case of feeding the wiring through the body, sacrificing the normal quantities of knuckle skin while uttering the necessary traditional four-letter Anglo-saxon incantations. Annoyingly in doing so I obviously tugged on the cable a bit too hard at some point, because the connection to the rear camera proved unreliable. Either that or the cable was defective from the get go, and indeed that was my story to their very responsive support team, who supplied a replacement cable free of charge. The only downside here was they had no UK stock, so I had to wait a frustrating few weeks while one was shipped from China.

Auto-Vox’s solution to patching the wiring in your vehicle is to provide connectors that resemble a standard automotive fuse, and have a socket in the back where the fuse the connector replaces piggy-backs. This seemed like a bit of a kludge to me and anyway, as an ex-British Gas van it has a very convenient supplementary fuse block with spade connectors, used to power the panoply of extra peripherals that adorn British Gas vans. So instead I chopped off the fuse connectors and replaced them with crimped on spade sockets.

As far as mounting the mirror itself goes, it’s a universal fitment affair, complete with a range of adapters to suit various vehicle manufacturers’ mounting solutions. I followed the instructions for a VW and found that while it worked, the mirror had a tendency to jiggle a bit – all a bit unconvincing. I re-read the instructions several times in case I had got the wrong end of the stick as to my mind it’s a case of surely-they-can’t-mean-for-it-to-work-this-way. Incidentally, if anyone who has one of these in a VW has any insight here into what they’re thinking, I’m open all ears. To compensate I designed a little widget that slots into the void in order to provide something solid for the screws to bear against. I printed it in ASA, for the aforementioned heat resistant properties. If it proves inadequate in this regard, I guess I’ll just mill it out of aluminium instead, but for now this serves to firm up the mounting, eliminating the wiggle.

When all is said and done, it works quite well, although it’s taking a bit of getting used to having driven without a mirror for so long. The software could be better. In particular the touchscreen lags significantly behind the display, which is of no consequence 99% of the time, but when trying to set up the reversing guide lines it’s highly annoying. Speaking of the reversing guide lines, I can’t comprehend why they’ve made it possible to individually adjust the left and right lines independently – in what possible circumstance would you ever want them to be asymmetric? By default it makes noises, which mercifully there is an option to disable, but on power up they’ve obviously forgotten to clear the audio buffer and it briefly pops. This is the kind of thing that almost no one will care about, but because I know why it’s happening I find it irritating.

The other problem I’ve had is that the rear camera doesn’t seem to record reliably. I think the reason for this is that I start the car by first turning the ignition on and letting the glow plugs have their effect, in which time the mirror powers up. When I subsequently engage the starter the rear view briefly drops out, presumably because of the voltage drop experienced due to starting itself, but also the quite long distance over which the cable must reach. The loss of the rear camera seems to stop it recording, in that it does record the few seconds when the ignition is turned on, but nothing subsequent to that. This is likely another annoying software bug. I could potentially put some kind of voltage regulator or buck converter inline to hold the voltage up, or I could get into the habit of just starting the car without waiting, but either way it’s a bit crap. Minor quibbles aside though, on the whole I’m pretty pleased with it.

I found myself a bit of ABS (for that’s what it was) off an old tyre lever, jammed in an appropriate thread insert from my 3D printing supplies, and attacked it with a soldering iron. Incidentally the metal bar with “NCY” written on it is a magnet. This proved very annoying as the soldering iron kept getting pulled onto it. Anyway, an effective repair was made – it’s not particularly pretty, but it works.

The top of the keyboard housing had some lumps in it on the left hand side, that I knocked down with judicious use of my various car body work tools, but there was also a little concave dent around one of the vents on the side of the housing. This was so minor it really didn’t matter, if I’m completely honest, but I was in fixing mode so I decided to have a go at pulling it out. There wasn’t really an obvious way to get any leverage on it, until I remembered I had a cheap glue tab dent puller that I could perhaps use. I wasn’t going to get enough purchase with glue, so instead I deferred to the universal problem solver – the 3D printer.

This wee thing, that took literal minutes to design and manufacture, could then be used to hook in under the dent and the puller would attach to it to do the actual job.

And now my laptop keyboard is straight(ish). Woohoo!

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. 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. 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.

I’m a bit perplexed by their choice of connector here, to be frank. It’s a connector from Higo, a company that specialises in connectors for use in e-bikes. This is all well and good, but given the insertion force required and obvious waterproofing, it seems to me like these are really intended to be used to connect the various internal components of an e-bike together, and not as an end user accessible charging port, where you might expect to find a (sufficiently waterproofed) traditional 3.5mm power jack or such like. It could be that the system was developed more with having a display involved, connecting to the CAN bus lines also found on the connector pins, with the OEM making their own loom extension and choosing their own charging connector, who knows. Never mind, it just seems a bit lazy on Pinion’s part, or should I say FIT E-Bike, who appear to be the partner predominantly responsible for developing the system.

Anyway, it is what it is, and in a case of (almost) square peg, (almost) round hole, I needed to find a less ugly way to make it accessible. The connector itself is only a millimetre or so narrower than the hole through which I intended for it to be available so engineering something to hold it in place was going to be tricky from a clearance and tolerance point of view. As a first step I used some silicone putty to take a mould of the orifice I would be working to, and subsequently cast a replica in epoxy resin.

Basically this is a time saving device, wherein testing a prototype does not require opening two doors, descending a flight of stairs, opening the garage, finding the prototype doesn’t fit, then reversing the aforementioned steps and trying again. I could of course bring my bike upstairs into my flat but, while I love my bike very much, I also love the state of my carpets. In order to complete my prototyping tools, I also needed a replica of the connector itself.

The black/purple colour here is just from me having covered it in black Sharpie marker, the clear resin I used having made it difficult to see what was going on due to internal reflections.

I decided early doors that the only feasible way to make this work was in 3D printing TPU, creating a small device that held the connector itself while at the same time interfacing with the hole in the frame. TPU differs to standard PLA filament, in that it is flexible, the resultant prints being both pliable and highly resistant to damage, to the extent that I’m pretty confident you could print a Benchy, twat it with a hammer and it suffer no obvious ill effects – it’s amazingly useful stuff.

After probably 10 to 15 prints to test out various ideas and approaches, I eventually ended up with the following. The black thing is an approximation of the connector, the red is the holder itself, and the green is a cap to cover the port when not in use.

The flexibility of TPU is useful in three separate ways for my purposes here:

• The hole in the frame is clearly not accessible from the rear for any potential fixing hardware, so it needed to deform so that it could pass through the hole and rebound back into its original shape to snap into place.
• The connector is (obviously) on the end of a cable which must exit the connector holder. The only way it could be assembled without first cutting the cable is if the holder is flexed open and the connector and cable inserted through a strategically placed slit in its side.
• Given the electrical nature of the system, moisture is the enemy. Making the cap fit tightly should in theory prevent any ingress; this is only possible if it’s flexible enough to deform and snap into place.

Actually fixing the connector to the holder was a problem. I briefly considered using some kind of adhesive but this makes repairs or future changes more difficult, so I was keen to avoid this if possible. I had noticed that the rear most cylindrical section of the connector had a very slight negative taper to it, which when clamped creates a mechanical fixing of sorts, albeit a weak one. To actually facilitate the clamping I turned to the humble zip tie, surely one of the unsung heroes of the modern world. The holder has two external channels to locate said zip ties, preventing any lateral movement once tight. The zip tie nearest the frame hole doesn’t mechanically arrest the connector like the other does, but it at least provides some additional clamping friction.

Having proved the print could work with the epoxy casting, the only thing left to do was install it in the real thing.

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.

It takes a fair bit of physical effort to actually connect the charger, mostly due to the design of the connector seemingly being intended for a more permanent connection, as I mentioned earlier. As a result of this, I was concerned that pulling the charger out might bring the connector with it, but fortunately this doesn’t seem to be the case.

The cap is deliberately quite a tight fit over the charge port; it really needs a strong thumbnail or possibly even a screwdriver to pry it off. This will hopefully ensure it is decently waterproof. The next time I go on a properly wet bike ride I’ll give it a close inspection and see how it’s doing.

The irony in going to all this effort of making it easy to access the charge port is that the battery itself is of such a capacity that at my current usage rates I estimate that it will need charging probably twice a year, at the absolute most. Oh well, it looks a lot better than the piece of tape that it replaced.

It looked from promotional shots as though the bolt pattern of the new gearbox was identical to their previous iterations, so from that point of view it seemed at first glance as though it would literally be a case of bolting it in to my existing Deviate Guide. What was less clear was how the electrical side of things worked. Pinion are curiously tight-lipped when it comes to dealing with end users, seemingly preferring to communicate via OEMs. Nevertheless via various Instagram stories and inquiries to small bike builders, I was eventually able to ascertain the general architecture of the thing. In addition to the gearbox, there is the motor unit that includes the control electronics and a loom to connect this to the shifter, (optional) speed sensor, and the external battery. This last item presented the biggest problem. Consisting of two standard 18650s, it’s not exactly svelte, and if I was to fit the system as-is to the bike then both the battery and the loom would need to be fixed externally on the frame somehow. This could probably have been done quite easily by re-purposing the bottle cage mount that I wasn’t using anyway, but it would have been an aesthetic mess and very difficult to keep clean and tidy. Therefore I started to explore other potential options that placed the battery internal to the frame.

My first thought was that maybe the head tube was open to the down tube (I couldn’t remember), and that there might be just enough room to squeeze the battery in there, but alas I removed the fork for an exploratory poke only to find it (reassuringly, structurally speaking) closed. I then wondered if the space beneath the seat post could be used, but my 210mm dropper put paid to that, and the tube was too narrow anyway. The only realistic potential remaining option was ahead of the gearbox mount position, in the lower section of the downtube. Of course there was no actual means of accessing the inside of the frame here, so if I was to go down this route it would necessarily involve some modification of the frame itself. Obviously I wasn’t about to just spontaneously start hacking away at a highly expensive piece of carbon fibre, so I cleaned and stripped the bike down (it needed a bunch of servicing anyway), 2D scanned the frame(!), and made an approximate CAD model of the relevant section, in order to test out my thoughts.

Needless to say, getting hold of a consumer grade 3D scanner is climbing up the priority list. Maybe next time I’m in the position where it might be useful I’ll have a closer look at what’s available, although in this case it’s the inside of the frame that was important, so having an external scan might have saved a bit of time, but it wouldn’t have actually helped massively in terms of capturing accuracy where it mattered.

It’s the area immediately behind the cable holes that I had identified as having potential, with access gained by making a hole ahead of the gearbox position, effectively in the end of the downtube. I came up with numerous ideas about how to tackle this problem. For obvious reasons I was keen to minimise the size of any holes I made in the frame, so my first serious idea was to 3D print a small bracket for the battery that would sit on the bottom of the internal face of the frame, either epoxied directly in or secured with carbon fibre strips. I got as far as modelling it but in the end decided against the approach, for two reasons. Firstly, I would be relying entirely on whichever adhesive method I chose. Carefully considered carbon fibre could have perhaps achieved a decent fixing, but in making the access hole minimally sized, access to lay the plys would be difficult. The other reason is that, as anyone who owns a mountain bike knows, water and dirt have an incredible ability to get everywhere, and with the battery sitting at the lowest internal point, I wasn’t keen on the possibility of it living in a pool of water, despite it having its own waterproofing.

I decided instead that it would be better to use a mechanical mount that held the battery aloft. This way should it fail I would be able to iterate on the design without being concerned with extricating failed parts and/or their adhesive. Helpfully the downtube tapers slightly, lending itself to having any potential support structure wedge itself into position without the possibility of it moving. I designed such a rear support structure, shaped in such a way as it could be inserted horizontally into the frame and then tipped up and assembled into position by the main body of the battery holder. I also put various cut outs and holes in place for the loom to pass through. In retrospect I should have made these a bit bigger as it’s a tight squeeze, though obviously that would have compromised the structure slightly.

The battery holder itself is designed to take advantage of the inherent flexibility of plastic such that it can bend sufficiently to clear the smaller hole which it must pass through, but then rebound into its original shape such that it provides a rear face for clamping into position. This clamping itself is provided by an external cover plate. I felt confident enough in my design now that I thought it had a chance of actually working, so I bit the bullet and ordered a gearbox. Thanks to some idiots it took bloody ages to arrive and cost me 25% more than it really needed to, but hey ho.

I had already been 3D printing prototypes in order to get a physical sense of my ideas – there’s something about holding an object in your hands that garners more insight than if you’re just staring at it on a screen. I now had the real thing though, so could produce prints to match the actual objects involved.

Incidentally this was the first time I’ve used heat set thread inserts. They’re definitely a lot less hassle that using captive nuts, which probably wouldn’t have been an option here anyway, due to space constraints. Hopefully they prove comparably adept mechanically. By this point I was rapidly running out of excuses to delay any potential frameicide, but one thing I did do was to run a couple of simple static load FEA tests.

Honestly my understanding is paddling pool shallow here, but the results I got at least reassured me that I wasn’t making an obviously terrible decision. My intuition told me that a centrally placed flat hole with rounded corners shouldn’t have a significant effect on the structure, but nevertheless it was nice to have some numbers to back that assertion up. With the hole position and size now finalised, I printed up a guide jig that screwed into the 4 forward-most of the gearbox mounting holes, making it very difficult to screw it up.

Trembling slightly, I removed the bulk of the centre section with a Dremel and then gradually snuck up on the perimeter using a rather nice set of Perma-Grit files that I had bought. I don’t need much of an excuse to buy new tools. There was no going back now, so I forged ahead and trial fit the prototypes that I had printed. As I had expected, some adjustment was required as the inside of the frame didn’t match what I had modelled, indeed it would be a huge surprise if everything did work straight away. To get a good fit, I found the most expedient way was to print a deliberately undersized version of the rear support and coat the mating faces in epoxy putty, take an impression, adjust the CAD model to match the results, then print again and iterate as required.

I think I also had to adjust the rear clamping faces of the holder itself, as the internal corners of the frame had more of a radius that I was anticipating. Anyway, eventually I got a decent fit, good enough for a trial mounting.

I had decided early on in the process that FDM printed PLA was probably not going to be suitable as a material. On the holder part in particular, in order to facilitate its flexture, it has several very thin sections that are not ideal from a layer bonding point of view, and I didn’t have a lot of confidence in such a part surviving long term (ab)use. Instead therefore, I intended (for the first time) to get the parts commercially printed, eventually settling on MJF technology to print in PA-12 Nylon.

The technology we have available to us today really is extraordinary; these fully functional and strong parts only cost me about £25 to get manufactured. Only a decade or so ago, the only realistic prospect of getting a part like this made would be to machine various dies and injection mould – this would obviously be prohibitively expensive by orders of magnitude. It’s probably only a matter of time before such powdered polymer based systems are available to hobbyists at a reasonable price. Anyway the lion’s share of the work was now complete and I could install the system in the frame. This wasn’t entirely straightforward due the awkward shape/length of the loom and the fact that none of it was ever supposed to be employed as it was, but I got there eventually. All that remained was to find a place for the speed sensor.

This old school reed switch and wheel magnet affair is an optional component of the system; if the electronics can read the wheel speed then various automatic shifting options are enabled. I wasn’t sure if I’d use them (more on this later), but after having literally cut a hole in the frame, installing a little sensor seemed like a small task in comparison. The magnet that was supplied with the sensor sat on top of two of the disc rotor bolt holes, but unfortunately it was a little too proud for my setup and clashed with the disc brake adapter. I found a Hope magnet that was lower profile though and this avoided any collisions by a significant margin. I now needed to find a position for the sensor itself. Obviously the frame has no provision for this, and I was loathe to go making more holes in a non-replaceable part, so really the only remaining option was to affix the sensor to the disc brake adapter in some way. As is standard procedure for this project I modelled all the relevant parts, printing them out to thought experiment with positioning and fixing methods, eventually resulting in a little housing with a slide off cover, that screwed to the underside of the brake adapter. There’s also a roll pin pressed in to stop rotation.

Incidentally I discovered an interesting slicer setting during my experiments here. I confess I was a little worried that the cover wouldn’t be robustly fixed enough to stay in place; it just snaps in, relying on the flexibility of the plastic. Having said that it appears to be coping just fine.

The Deviate family of bikes are all so called high pivot which means that the sensor cable needed to take a particularly circuitous route in order to connect to the main loom, and as luck would have it said cable was fractionally too short, so I had to extend it. I now have a longer one that I’ll fit in due course. Besides a few cable management bits and pieces though, it was now sufficiently done to actually use in anger.

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 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 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.

I 3D printed a couple of moulds, roughly the dimensions of the cable outer.

Then I used a glue gun to liberally coat the “naked” portion of the join from all angles, wrapped it in grease proof paper, quickly pressing it between the two moulds.

The excess was trimmed, and I then applied a bit of external heat shrink as a belt and braces measure.

It’s probably churlish to claim to have invented this idea, but I did at least come up with it independently. I’m fairly sceptical it will last in the long term, as in my experience glue gun glue has a tendency to get brittle over time. It doesn’t have to work for long anyway, as I have the correct longer cable to swap out at a later date, but I thought it was an interesting technique that was worth sharing.

Here’s what I came up with. It uses the slicer’s vase mode, which basically means that when presented with a solid object, the output will be a hollowed out version with an open top, resembling a vase. This uses literally the minimum amount of filament and thus weighs very little. It also prints rapidly.

Thankfully I haven’t needed to use its contents yet. In saying that I’ve probably now jinxed it.

Can we pause for just a second and marvel at how absolutely bonkers it is that something like this can be designed, manufactured and shipped halfway around the world, and still presumably make the seller a profit? Anyway, as you can see this is designed to screw into some fixed point, as opposed to being held in a spindle. You could probably get away with grabbing the stubby thread in a collet, but it’s hardly ideal. What could I do instead?

Wait what?

Oh.

I did very little research before getting one; they all seemed much of a muchness as far as I could tell, and in practice I found it wasn’t something I used very often anyway. The thermostat itself is a stand alone unit that needs mains power, and connects to a separate control unit (called Heat Link) that switches your heating. This is where it gets interesting. Its expected that you fit it with a flex and plug, affixing it to the wall using rawl plugs or similar. You could do this with a UK plug, but that would be a bulky and untidy solution. I was going to have to add a socket for it in this case, and if I’m doing that, a neater solution would be to use a fused switch, routing power to a standard backbox on which the control unit sat. Unfortunately there was no provision for mounting it on a UK backbox, presumably because it was designed for the North American market.

3D printing’s propensity for being a solution looking for problems came to the fore and I designed a pattress that adapts the Google Heat Link to a standard UK backbox.

This resulted in a much neater installation that I would have otherwise achieved.