Joined
·
3,733 Posts
So, this weekend I finally got around to looking at the CANbus on the K1600. First surprise is that the diagnostics connector under the seat is firewalled; it doesn't see the communication stream from all of the onboard CANbus devices. Second surprise is that all of the handlebar, Nav, Radio, etc. are on a separate single wire bus called a LINbus.
Since the diagnostics plug isn't active without some BMW service computer magic, I had to tap into the twisted-pair CAN lines under the right side panel. So far I have verified that it is standard CAN protocol, 500kbs, no extended message addressing (11-bits, not 29), the full 8 bytes of data always sent, and there's nothing that appears even remotely related to the SAE J1979 message tags used in automobiles. I've never really learned to speak "CAN" until now (last bike project like this was VPW) so I had to come up to speed on the protocol, stuffing bits, etc; pretty straightforward.
Using a homebrew sniffer, I've identified 24 different message headers and done some rough statistics on how often they're used. Since lower number message IDs have bus priority, the combination of the ID and occurrence rate can help me to start to identify the packets that I'm interested in (fueling, RPM, speed, etc.).
Just like my past motorcycles, I want to add some information to the dash with a separate LCD graphic display. For starters, I'm looking for a large digit speedo, coolant temperature, race timing (60', 1/8, and 1/4 mile; off road use only
), digital battery and charging voltage, etc. Just a little project to keep me off the street at night.
I attached a photo of an interesting (at least to me) collections of notes where I manually deciphered a packet from the digital oscilloscope screen that I'm seeing quite often (message ID 2D0) just to make sure that my sniffer is doing the job correctly. The circled bits are the ones that I finally realized have to be removed from the stream to adhere to CANbus bit stuffing rules. The 24 message codes that I've identified so far are also shown if it is helpful to anyone. The next step is to start filtering for each code, watching the data stream, and trying to correlate changes in the numbers to what's happening on the bike. Major detective work but interesting.
![]()
Since the diagnostics plug isn't active without some BMW service computer magic, I had to tap into the twisted-pair CAN lines under the right side panel. So far I have verified that it is standard CAN protocol, 500kbs, no extended message addressing (11-bits, not 29), the full 8 bytes of data always sent, and there's nothing that appears even remotely related to the SAE J1979 message tags used in automobiles. I've never really learned to speak "CAN" until now (last bike project like this was VPW) so I had to come up to speed on the protocol, stuffing bits, etc; pretty straightforward.
Using a homebrew sniffer, I've identified 24 different message headers and done some rough statistics on how often they're used. Since lower number message IDs have bus priority, the combination of the ID and occurrence rate can help me to start to identify the packets that I'm interested in (fueling, RPM, speed, etc.).
Just like my past motorcycles, I want to add some information to the dash with a separate LCD graphic display. For starters, I'm looking for a large digit speedo, coolant temperature, race timing (60', 1/8, and 1/4 mile; off road use only
), digital battery and charging voltage, etc. Just a little project to keep me off the street at night.I attached a photo of an interesting (at least to me) collections of notes where I manually deciphered a packet from the digital oscilloscope screen that I'm seeing quite often (message ID 2D0) just to make sure that my sniffer is doing the job correctly. The circled bits are the ones that I finally realized have to be removed from the stream to adhere to CANbus bit stuffing rules. The 24 message codes that I've identified so far are also shown if it is helpful to anyone. The next step is to start filtering for each code, watching the data stream, and trying to correlate changes in the numbers to what's happening on the bike. Major detective work but interesting.
