Paul Jakma's Blog

It’s pretty rare that I get to blog about both cycling and networking. Hard to see how those two topics share any common ground. That’s about to change as SRAM, the American bicycle component maker, appear to have a wireless gear shifting system in advanced testing.

The system was seen at the Tour of California earlier this year, though disguised with decoy wires to make it seem like a wired, electronic system. It was also spotted recently at the USA Pro Cycling Challenge, now without the decoy wires.

You may ask, why on earth would bicycles need radio-controlled gear shifting? Which is a good question. One benefit seems to be that the wireless shifting weighs slightly less than either a conventional mechanically actuated system, or even a wired electrical one. However, that benefit surely will be very marginal. The lack of cabling may make installation and maintenance easier too. Perhaps. Another possibility is that SRAM were behind Shimano and Campagnolo in delivering an electronically controlled shifting system, and SRAM decided that going wireless would help differentiate their product from the other two. Who knows!

As someone who specialises in network protocols, I’m curious to know how it might work in terms of the messages sent, logical layers of the radio protocol, and how the different components communicate to co-ordinate shifting.

There are obvious questions: Is it secure? Are there any limitations? Will it be reliable? The brief answers to which are, yes it should be secure; yes, there seem to be some limitations over traditional shifting systems; and probably it should be quite reliable, however when it isn’t there could be quite strange behaviour.

The rest of this blog will go into the details of how this system works at a network protocol level, as gleaned from SRAMs’ patent on electronic shifting. It will look at the ramifications of the design decisions made, and also how this could affect the operation of the system in extreme circumstances where messages are lost due to, e.g., radio noise.

The quick summary:

The SRAM system, at least as described in their patent, has a number of limitations that are a consequence of the network protocol:

• It can not support more than two front chain rings
• It can not support intentional simultaneous shifting of front and rear dérailleurs

While radio noise is unlikely to be a significant problem, outside of deliberate interference or some unusual locations, should the system be affected by continued noise it may manifest itself as:

• Missed rear shifts followed by an overshift of the rear
• Overshifting rear shift, after an apparently normal front shift
• Combined unintentional shift of both dérailleurs, on an intended front shift

The system should though be relatively robust against interference, due to its use of a low-bitrate network layer. It should be secure, due to use of strong encryption, so that only those with physical access to the bicycle (e.g. the rider) can control the gear system.

The system that goes into production may differ from the system described in SRAMs’ patent, and some or all of of these limitations may not apply to it. We won’t know till it is released.

Update 20150213: I’ve just noticed the very bottom of the SRAM patent mentions that the dérailleurs can transmit their current gear position. The patent mentions this might be used to allow the front mech to adjust its trim according to which gear the rear dérailleur is in. The patent does not mention this being used in the control protocol though, e.g. to have the dérailleurs ACK the shifter messages which could make the protocol more robust to missed messages. However, the hardware described in the patent is at least capable of this, and production systems could be enhanced this way. There may still be issues left in how the system appears to allow for shifting to be distributed over two shifters, I’d need to go back and re-check.

How it works

In conventional road bicycle shifting systems, one shifter operates the front dérailleur and the other shift operates the rear dérailleur. A shifter either has one lever which is moved one way or another to change up or down, or the shifter has two levers with one lever to change up and one to change down.

SRAM have decided to change this for their wireless system. Their wireless system apparently has two buttons. One on each shifter. Pressing one button changes the rear dérailleur down, pressing the other button changes the rear dérailleur up. To change the front dérailleur requires pressing both buttons.

This decision has some immediately obvious ramifications.

The first ramification is that the front can only be told “change”, there is no way to send “up” or “down” command to the front dérailleur. Clearly, this system can never work with triple front chain-rings, but is limited to dual-ring front dérailleurs.

Triple front chainsets are a niche on road bikes, of course. SRAMs’ wireless groupset will no doubt target the road bike market at first. However, it may limit the wider applicability of SRAMs’ electronic offering down the road, should electronic ever trickle down to touring or hybrid markets. In the mountain bike market SRAM appear to be moving towards single-ring front chainsets (no shifting mechanism needed obviously) and wide-range rear cassettes.

The second ramification is that, as each of the two buttons are on a different shifter, neither shifter can know on its own which dérailleur the button press is intended for. This means the network protocol becomes a non-trivial distributed system. To control the front dérailleur, the two shifters must either coördinate in advance and have one instruct the front dérailleur, or they must send commands in such a way that the front dérailleur can listen to both and figure out whether the combination of their messages refer to it. The protocol demands either additional communication, or subtle complexities. SRAM chose the latter approach, and the details and consequences will be examined below.

Network Layer & Security

The patent suggests SRAM are using IEEE 802.15.4 (for full details see: 802.15.4-2006 and 802.15.4-2011) in the unlicensed ITU 2.4 to 2.5 GHz band. This is a low-power, lowish-bitrate radio and network protocol aimed at being suitable for microcontrollers, derived from the Zigbee protocol. The ITU 2.4 – 2.5 GHz band is shared with a wide variety of other unlicensed radio protocols, including 802.11 Wifi, Bluetooth, ANT+, DECT phones, garage openers, etc. IEEE 802.15.4 uses a CSMA-SA protocol in its MAC, similar to 802.11 wifi.

The SRAM patent goes into detail on about transmitting on a channel, listening for noise, waiting, etc. This seems strange given that this is precisely what the IEEE 802.15.4 standard covers. This makes me suspect that SRAM are simply describing the 802.15.4 protocol they are building on. If that is the case, it seems somewhat misleading to include those details in the patent, however I am not a patent lawyer.

SRAM do however seem to have added their own “turn the chip/radio on and off at intervals” protocol on top of that though to save power. Such things of course can be tricky to get right. Protocols can work in controlled settings, but then fall apart in certain other conditions that are only experienced in the real-world. This blog does not look further into the effectiveness and robustness of this aspect of their protocol however.

IEEE 802.15.4 can use AES with pre-shared keys, which SRAM are using. Key management is not specified. SRAMs’ patent suggests the shifter and the dérailleur have a pairing mode that can be activated by holding a button for an extended length of time. In this pairing mode the shifter and dérailleur could exchange a key. Presuming this pairing phase is not observed, the AES encryption should provide high security from spoofing. That is, it would not be possible for any one other than the rider controlling the shifters to initiate a gear change.

It is not completely clear to me from the patent whether SRAM use a group key, sharing one key between both shifters and both dérailleurs, or whether separate keys are used for each pairing. However, given how the front dérailleur shifting protocol works, with each shifter not knowing the intended target dérailleur, it seems to me it could only use a single, shared group key. Further, to simplify pairing and group key management, it’s possible SRAM have the shifters use a static key that doesn’t change in re-pairing. If so, observing pairing of a shifter just once would compromise the security of that shifter forever.

The wireless system may be subject to noise. In extreme cases messages could be lost, potentially for prolonged periods. The radio PHY on/off power-saving protocol additionally adds further opportunity for command messages to be missed. The impact this can have on the operation of the command protocol is looked at below.

Command Protocol

The SRAM patent suggests each shifter sends fairly simple “Shift up” or “shift down” commands. At least, it’s sufficient to consider those being the commands for shifting the rear dérailleur.The patent then has to discuss how the problem of duplicate or lost commands are dealt with.

Commands can be lost because of either radio noise, or because of the aforementioned “turn the radio off for intervals” power-saving protocol. To compensate for this, the shifter also sends a count, e.g. “Shift up 3” to indicate this is the 3rd up shift in a row. I would presume the shifter resets this count when an opposite shift is made [correction: the shifters would have to coördinate to know if it was in a row, instead the dérailleurs compare received counts]. When the dérailleur receives a message where the count is higher than the previous message it received, then it knows it missed a message and can compensate by shifting more, to match the number of missed shifts.

Note that the patent as written says the receiver increments the count, but I think they must mean the shifter does. I don’t understand how the protocol could work otherwise, unless the dérailleur acknowledged shift counts. However the patent doesn’t mention acknowledgements.

The presence of this counter might lead one to think that lost commands from the shifters can be an issue, due to RF noise or due to the power-saving protocol.

The protocol is actually a little more complicated than this. Separate messages are actually sent on button press and release. That is, the messages actually consist of “Shift up pressed 3” and “Shift up released 3”. This is done to allow each of the front and rear dérailleurs to differentiate whether a shift command is intended for it or the other dérailleur, based on the ordering of the messages received.

E.g., if just one button is pressed and released, the command is intended for the rear dérailleur. The dérailleurs will receive either:

1. “shift up pressed x”
2. “shift up released x”

or

1. “shift down pressed y”
2. “shift down released y”

The dérailleurs then know it was intended for the rear dérailleur. The front then does nothing, the rear acts on the commanded shift.

If both buttons are pressed and then released after a delay, then the dérailleurs should receive:

• “shift up pressed x”
• “shift down pressed y”

In either order, and then later receive, in either order:

• “shift up released x”
• “shift down released y”

The dérailleurs can each see that the button presses overlap and so know it was intended for the front derailleur. The front acts by shifting to its other ring, and the rear ignores this set of messages (other than updating its shadow copies of the counters to x and y).

Note that this protocol means this SRAM system is incapable of commanding both the rear and front dérailleurs to shift simultaneously. This is a limitation not just in the rider shift selection system (the “UI” so to speak), but baked into this gear changing network protocol.

The question I’m interested in is what happens when messages are lost. The next two sections will look into this. First considering what happens if single-button, rear-shift command messages are lost, then considering what happens if messages are lost from a two-button, front-shift command.

Missed Rear Shift Message

Imagine the rider tries to change gears on the rear dérailleur. The obvious question is what happens if sufficient messages are lost that the rider notices, and then compensates themselves by pressing the shift button again? What happens when messages start getting through again? The answer is that the rear dérailleur may shift multiple times – as many times as the shifts that failed to get through due to the counter. The sequence of states and events would be:

1. Dérailleur last got “shift down, count: x-1”
2. Rider wants to shift down again, clicks
3. Shifter sends “Shift down, count: x”, and does so at intervals for long enough that the dérailleur must have had an awake period, to have had a chance to receive – e.g. 100ms is suggested in the patent, but that might not what the released systems use.
4. The dérailleur doesn’t get the message for some reason, e.g. because of high radio noise.
5. After 1 or 2 seconds the rider notices the missed shift, and moves the shifter again.
6. Repeat steps 2 to 4 another n times, where n is 0 or higher, depending on how long the radio noise lasts. Each time the shifter is sending an incremented x.
7. Finally the dérailleur receives the message, and suddenly shifts down x+n times.

That overshift might just be a minor problem in most cases. However, in some cases it could be nasty, e.g. overshifting to a much easier gear could cause the rider to lose balance if stood up.

This issue could be avoided by having the rear dérailleur acknowledge shifts, and having the shifters increment their shift count only on receipt of the acknowledgement. This would mean the dérailleur could no longer be a passive listener in the protocol, but would have to transmit. This would add an energy burden on the dérailleur’s batteries.

However, should the system ever be expanded to allow the dérailleur to report its current position, e.g. for handle-bar displays, then that energy cost would be no burden. Indeed, then it would make sense to change the protocol to have the shifters make explicitly enumerated shifts. The shifter would no longer maintain a counter, but the current gear position. The shifter wouldn’t send “Shift up” or “shift down” commands, but explicit “Shift to gear X” commands.

Explicit shifting would not be compatible with the “two buttons for front shift” scheme though.

Missed Front Shift Messages

The front dérailleur acts on overlapped button press/release messages. The question here is what happens if the rider presses both buttons, and messages are lost? What could happen?

One possibility is that all messages are lost to one of the dérailleurs.

• If all messages are missed by the front dérailleur alone, but the rear dérailleur sees them, then no shift will occur. If the rider tries again and the messages get through, the front dérailleur should shift as normal. The next rear shift should not be affected either way.
• If all messages are missed by the rear dérailleur alone, but the front dérailleur sees them, then the front dérailleur will shift as normal. The rear dérailleur’s shift counts will now be off. If the next shift made is another front shift, the rear can update its counts and there should be no further problems. However, if the rider next tries to shift the rear, then the rear dérailleur will overshift.

What happens if the messages of just one of the shifters are missed at one of the dérailleurs?

• If one shifter’s messages are missed by the front dérailleur alone, but the rear dérailleur sees all the messages, then no shift will occur. If the rider tries again and the messages get through, the front dérailleur should shift as normal. The next rear shift should not be affected either way.
• If one shifter’s messages are missed by the rear dérailleur alone, but the front dérailleur sees them, then the front dérailleur will shift as normal. The rear dérailleur will also shift, either up or down, depending which set of messages it missed.

Summary

The SRAM system described in their patent has a number of limitations, that are a consequence of the network protocol:

• It can not support more than two front chain rings
• It can not support intentional simultaneous shifting of front and rear dérailleurs

While radio noise is unlikely to be a significant problem, outside of deliberate interference or some unusual locations, should the system be affected by continued noise it may manifest itself as:

• Missed rear shifts followed by an overshift of the rear
• Overshifting rear shift, after an apparently normal front shift
• Combined unintentional shift of both dérailleurs, on an intended front shift

It will be interesting to find out how rarely, if ever, users experience these once the product goes on the market.

The SRAM system should however generally be quite secure and not allow anyone but the rider to initiate a shift, due to its use of strong encryption. It would take a skilled attacker with physical access to the bicycle at some point, or else close proximity while mechanics are pairing components, to be able to hijack shifting remotely.