Hacking Ultegra Di2?

I haven't found much discussion of Shimano's electric shifting on here, yet it seems very relevant. I know there are a couple commercially available ebikes that shift gears automatically so rider can pedal at a constant cadence no matter what the motor speed, but Di2 seems to offer an opportunity for more DiY experimentation while still leveraging the decades of deraileur development. Plus, the price is no longer so forbidding.

That's what I told mysef anyway, before buying an ultegra di2 build kit last week. Now that I'm ankle deep in the technical deets, I'm having second thoughts...

- My first thought was to hook up a decoder and watch the CAN messages go by. After all, using an OBD reader with my car was dead easy... But I have yet to find anyone who has done this with Di2 successfully. While the evidence that Di2 (only ultegra version, NOT dura ace) is based around the CAN bus is strong, and hooking up an o-scope to the system provided additional comfort, getting a clean enough connection to decode proved surprisingly tricky. Either a) I am a butter fingered fool, or b) Shimano is using something odd, like the GM single-wire version of CAN. Most likely, both.

- "If you fail, move up the stack and try again... " Shimano sells a PC interface box that allows you to connect via USB to your drivetrain, and throws in a simple app that can trigger the various components as well as update firmware etc. Disassembly is trivial and the objects/methods are fairly well structured. Below, for example, is the public method to SetGear (basically, checks if it's doing front or rear, issues appropriate command over wire, then waits for response code.)

Of course, instantiating all the state to get to the point where this function can be called is ... more elaborate.

Which is why I'm here. Has anyone already done this? (Either the CAN way or the PC/USB way)? Any tips would be most welcome.

Thanks,
s.


public static bool SetCurrentGear(byte[] settingsGear, int slotNo, string modelNo)
{
byte[] data = new byte[] { settingsGear[0], settingsGear[1], 0, 0 };
int num = -1;
int num2 = 0;
byte groupId = 0;
string commandName = null;
if (modelNo == "FD-6770")
{
groupId = 10;
commandName = "EXTM_FR_SFT_LV_SET";
}
else
{
groupId = 11;
commandName = "EXTM_RA_SFT_LV_SET";
}
do
{
EtubeDataLinksMain.Instance.SendUnitCommandData(groupId, 8, data, slotNo);
EtubeDataLinksLog.SendCommandLog(slotNo, commandName, data, new string[] { "gear" });
DateTime time = DateTime.Now.AddMilliseconds(3000.0);
while (true)
{
AbsSerialDataReceivedEventArgs args = EtubeDataLinksMain.Instance.WaitUnitCommand(groupId, 10);
if ((args != null) && (args.Result == SerialDataReceivedResult.Success))
{
if (args.ReceiveData[1] == 10)
{
EtubeDataLinksLog.CommunicationLog(slotNo, "CurrentGear = " + args.ReceiveData[2]);
if (args.ReceiveData[2] == settingsGear[0])
{
num = 0;
break;
}
num = -1;
}
else if (args.ReceiveData[1] == 11)
{
EtubeDataLinksLog.ReceiveErrorResponseLog(slotNo, commandName, args.ReceiveData);
return false;
}
}
if (DateTime.Now > time)
{
EtubeDataLinksLog.ReceiveTimeoutLog(slotNo, commandName);
break;
}
}
}
while ((num2++ < 2) && (num != 0));
return (num == 0);
}

There is a lot of chatter in the forums about Di2 using the CAN bus, although nobody has yet connected to it with a decoder. The Single Wire CAN bus (GM version, SWCAN) requites a minimum of three wires (ground, power and signal). I don't have a Di2 yet, so I can't see for myself, but from the photos it looks like there are only two wires in the cables that go to the handlebar switches. Can anybody confirm?
If there are two wires, and the power is carried on the same wire as the signal, could it then be a proprietary physical bus - that requires a tweaked CAN transceiver? Or could it be a LIN bus (as in http://www.melexis.com/Assets/Local-Interconnect-Network-(LIN)-A-Unique-Animated-Tutorial-Movie-5502.aspx ) - that one can be made a true one-wire...
Any ideas?

I will buy a CAN bus decoder for my Tek scope. I use the RS-232 bus decoder for debug purposes and find it works well for basic comm issues. If I can get reliable comms I'll work out a better CAN bus sniffer to log the messages. I'm interested in knowing why the battery holder is programmed? Battery power management?

If only it were so easy.. Several people have tried using CAN sniffers/diagnostic tools (including myself) with no luck. It appears that Shimano uses some non-standard standard-- "Power Over CAN", to makeup a term.

Oh, I don't think there is any reason for putting some of the signaling logic into the battery holder other than every system needs one and it's the right physical size.

s.

Brilliant idea though man. It's particularly a problem on an ebike, the gear changes can be alot more awkward because acceleration and mass is so much greater.