SRAMs’ wireless bicycle gear shifting: Protocol analysis

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”


  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.


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.


  1. Interesting article Paul.

    That decision to go with a single shift button then try to combine the messages to decide it’s a front derailleur change sounds like a nightmare to me. Glad I’m not in the firmware team for that.

    I don’t like the fact that it’s just a toggle for the FD either. Sometimes I desparately hit the shift buttons hoping for more chain rings 🙂 I certainly wouldn’t want to accidentally shift to the big ring if I was on a steep hill.

    I still can’t help the feeling that wireless shifting is absurd anyway.

    • Paul Jakma said

      Thanks! 🙂

      Yes, the complexities and the failure modes here (rare as they may end being in practice) stem largely from SRAMs decision to just have one set of buttons. I wonder what the thinking was there? Seems “brave” to say the least.

      Not sure I’d get on with the “press both for front” selection either. I’d be bound to get it wrong at some point.

      • giobox said

        Great read, thanks! In response to your wondering about the thinking here, I had wondered if a large attraction of this two button design is that SRAM can keep the “Double-Tap” shifting brand around. The Double Tap mechanical implementation is largely impractical for an electronic shifter.

        “Double-Tap” I suspect will be reused in the marketing materials to mean the simultaneous press of left and right shifter to change the front ring.

  2. RayG said

    Wouldn’t sending a shift count spoil your ability to just tell the derailleur to make the missed shift? Say the RD missed “Shift Up 3” and you pressed the button again, sending “Shift up 4”. The RD then shifts twice when you only wanted it to shift once.

    • Paul Jakma said

      What I was suggesting was to have the rear dérailleur send a message back, acknowledging the shift occurred, and the shifter only updates its count when it receives that. I.e., basically the rear sends out its current position and the shifter remembers that and uses the desired position to shift to in commands. That would fix this protocol.

      I suspect SRAM didn’t do this to save battery, and keep the dérailleurs as passive as possible radio wise. However, what’s the bets one day they’ll add gear position transmission anyway (e.g. for integration into data-loggers)? In which case, it’d be silly to still have the shifters use the more error-prone up/down protocol.

      • Paul Jakma said

        Oh, acks would solve the network protocol. It doesn’t fix the user-interface of course. However, with such a change/fix, the rider shouldn’t click again: they should just wait, knowing the shifter will retry by itself and the dérailleur hopefully eventually soon get the message and shift.

  3. I wonder how long the derailleurs will have to wait after receiving a message from one shifter before they decide that a message isn’t coming from the other shifter?

    It’ll depend on how closely the rider presses the two buttons, and then add in a bit of transmission delay – especially if there had to be retries. Still, maybe it’s so quick that it’s not noticeable.

    Imagine a scenario too where the FD received the messages from both shifters, but the RD missed one of them…

    I still think having to have batteries everywhere kills the idea anyway.

    • Paul Jakma said

      The dérailleurs don’t have to wait. The shifters are sending messages for each button being pressed and released. So the dérailleurs can see when button presses overlap. Now, as to what happens if messages are missed, that should be (partly) covered in the “Missed Front Shift Messages” section I think. At least, if both press/release messages from one shifter are missed by one or both shifters (just one message missing – it can probably still infer the right thing in most cases).

      If that happens it’s possible that *both* dérailleurs shift, unintentionally, if the rear receives only one shifters messages. Another case is that the front shift goes normally, and then the *next* time the rider tries to shift the rear, it overshifts (if the rear previously missed both shifter’s sets of messages).

      • I meant that the derailleur needs to wait after receiving the first “left button down” message to see if there is or isn’t a “right button down” message following. It can’t start to act until some guard time has elapsed.

        • Paul Jakma said

          Well, it needn’t act until it sees the next message. So if it receives “up pressed”, then what happens depends on the next message received. If it’s “up released”, that’s a rear shift. If the next message is “down pressed”, then it’s a front shift.

          If, for a front-shift, only one message goes missing, the shifters can sometimes infer. E.g. if “up pressed” goes missing, and a shifter still receives “down pressed” and if it then receives “up released” /before/ “down released”, then the shifter can still infer it was a front shift. However, if “down released” received before “up released”, then the shifters could interpret that as a rear shift.

RSS feed for comments on this post · TrackBack URI

Leave a Reply to Paul Jakma Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: