Significant progress on talking to CAN Bus on Spyder

[Spyder Monkey]

So I managed to sweet talk a former employer into borrowing a $700 CAN bus adapter that lets my laptop see the CAN bus traffic over USB. Last night I finally sat down and played with the system to see what I could learn. This is going to be a somewhat long and technical post so bear with me, I'm basically going to type up my notes so I can get feedback and ideas from the technical folks.

I have a 2008 SM5 GS, so what I see on the CAN bus is less than what you would see on a SE5 because I don't have that shifting subsystem. Also I believe the RT has a few more sensors as well.

The basics:
The system talks at 500Kbits per second and uses the basic "11 bit mode" for addressing (not the extended 29 bit mode)
With the key in the on position and engine off, I get 13 unique CAN message identifiers that update at a rate of either 10 or 20 milliseconds. Most of the data is unchanging (because the bike is just sitting there) but a few of the data bytes are bouncing around. One appears to be a timer / sequence number counting up but I can't make heads or tails of most of the "changing data while sitting still" so far.

Here's what I have learned / tried so far. I'm using the software nerd convention of zero based numbering for the data bytes. Each CAN message has up to 8 bytes of data containing in a message, numbered D0 through D7. Some bytes are combined into a 2 byte integer. If you have no idea what I am talking about, don't worry about it. Read on, you can still help and I value your opinions. Numbers given are all in decimal, not hex.

So here is what I learned / partially decoded

Message ID 786 has 8 bytes. The last two bytes are throttle position. They are combined to make a 16 bit unsigned short. Throttle closed is 0, throttle WFO is 116 and 250 for the last 2 bytes. Appears to be linear over the range. Don't know what the other 6 bytes are yet.

Message ID 512 is also 8 bytes Byte D4 might be a current sensor value, it seemed to go up as I turned things on. Byte D5 is the gear sensor but it is numbered oddly. 1st gear=17, 2nd gear = 18, all the way through 5th. Neutral is 23. But strangely enough, No change when I put it in reverse. I could not see any data change when I dropped it in reverse.

Message ID 560 is also 8 bytes. D0 through D3 are the 4 wheel speed sensors. D0 is left front wheel speed in "sensor pickup ticks per second". D1 is right front. D2 and D3 are rear. The computer gets really mad at you when the wheels are turning in opposite directions with the engine off. Had to turn it off and back on to get out of an error state.

Message ID 195 is only 5 bytes. First two bytes are steering angle sensor data.

The rest of the message ID's are unknown at this time. I get lots of rapidly changing data when I start the engine and I think I know what coolant temp is. But I ran out of time for this particular session.

Some things I tried I really expected to see in the data stream but did not (or at least I missed it):
No change in the data I saw when I changed the kill switch, high beam switch, parking brake, or had my boy sit on the passenger seat switch.

Ok, time for a break and breakfast. This is all the raw data from last night... back in a few minutes with the rest of the story.

 

[Bob Denman]

:shocked: WOW!! :shocked: :2thumbs: :clap::bowdown::bowdown::bowdown:
I have absolutely no idea what you just said (THAT happens all the time! ); but I have no doubt that it's going to find a useful home in here somewhere! :thumbup:

 

[finless]

That's great progress! :bowdown:

It would be so cool if one day we could have our own BUDs on the cheap. Maybe not ability to flash software but to clear codes for things like changing your own break fluid, etc.

Keep up the good work man!

Bob

 

[Spyder Monkey]

Part Two, now what?

So while fun and entertaining, I don't think the current method is likely to get me / us to where we want. I want to know the data protocol well enough to have a basic "BUDS for the shade tree mechanic". I don't want to reprogram keys or change engine timing or override the nanny. I just want to have access to the basic diagnostics.

I have to give back the nice CAN to USB adapter on Monday to my former employer. And even if I had unlimited access to it, it is very time consuming process. I enjoy messing with it but I have to split my time between hobbies and customers who pay for my time and you can guess how that goes.

So I see a few options I wanted to throw out (short of giving up) and see what the board thinks.

Option A: Ask Bombardier nicely for the unrestricted portions of the protocol. Explain why we want it, why they should not hold owners hostage to $125/hr technicians for basic work, why it would increase the desirability of their brand among tech-heads, etc. I seriously doubt that will succeed but it is easy enough that I will probably try for the heck of it. Anybody here have an ear of someone inside BRP that they could put me in touch with? Otherwise I was just going to try their PR department.

Option B: I think there are certain states that require manufacturers to provide the public with access to the same proprietary diagnostic data that they provide to their dealers. I can't find the law right now but I think it was Massachusetts. So if someone is a lawyer or legally inclined to pursue that, we could possibly get the information to decode the protocol.

Option C: If you google the right key words, there are copies of the BUDS installer on the web. I have a copy of BUDS. The installer did not require me to agree to any license restrictions to install it. All of the information we want is encoded in those files. It might be possible to decompile those binaries and extract the information I want. I don't know the legality of what I propose, I certainly do not want to get myself into hot water. I am not a lawyer and am hesitant to do this.

Option D: If there were enough like minded and technically inclined people, I could probably build / find a fairly inexpensive microcontroller system to let others see the same raw data I am seeing. If those folks were willing to help with the cost of hardware development and contribute to software as well, maybe a lot of us working together could figure it out much faster than this lone geek. Plus it would allow RT, ST, and SE5 owners to play along.

I'm leaning toward trying A first and seeing where it leads. Any ideas? Any other input on the tasks?

 

[Spyder Monkey]

That's great progress! :bowdown:

It would be so cool if one day we could have our own BUDs on the cheap. Maybe not ability to flash software but to clear codes for things like changing your own break fluid, etc.

Keep up the good work man!

Bob

That's my goal. Frankly, it pisses me off to be held hostage to a $125 an hour tech when I know I am better trained and educated to troubleshoot complex electromechanical systems. No offense to all the hard working and competent techs but I should not be required to pay those outrageous rates just because BUDS is proprietary.

 

[wd5gnr]

Nice work. Where are you tapping the bus? If you go with option D I might be able to help there as I have a fair amount of experience in that area.

What I would like is enough info to put my gauges out on WiFi, velcro an old Android phone to my dash and let it mirror image the data to reflect in the windshield as a HUD ;-)

Or something like that.

 

[mrfats]

:shocked: WOW!! :shocked: :2thumbs: :clap::bowdown::bowdown::bowdown:
I have absolutely no idea what you just said (THAT happens all the time! ); but I have no doubt that it's going to find a useful home in here somewhere! :thumbup:

Waaaay over my head too!

 

[finless]

Option B: I think there are certain states that require manufacturers to provide the public with access to the same proprietary diagnostic data that they provide to their dealers. I can't find the law right now but I think it was Massachusetts. So if someone is a lawyer or legally inclined to pursue that, we could possibly get the information to decode the protocol.

This is correct and I believe it is all states!! I work for a major corporation and we HAVE to make available our diagnostics to allow 3rd party service and fair competition. BRP has to by law sell BUDs to someone if asked. Now what they charge for it can be the issue. Parts of that law requires they sell any proprietary diagnostics tools at a "fair" price but this is open ended and thus if they charge you say $10,000 only thing you can do then is take them to court usually via a class action unfair competition suit. I have been down this road in the late 80's when our company was doing these practices so trust me I know.

Updated: FYI they do not have to tell you the protocol as part of that law. They only have to make available the tools needed to do service on a product e.g. allow a 3rd party company to provide service as part of fair competition.

Bob

 

[Bob Denman]

So now we just need them to 'fess up and tell us what's floating around in those numbers...

 

[Spyder Monkey]

So now we just need them to 'fess up and tell us what's floating around in those numbers...

Yep, that sums it up pretty well. With time, smarts, analysis, etc, I might be able to figure out most of the protocol but I sure would like to know it all.

Gotta go mow the lawn before the thunderstorms hit this afternoon. Check back in later with some more ideas.

David

 

[KX5062]

Very cool stuff SM. Now if we could parlay that into a homebrewed diagnositic/code reader/clearer.........
(Like Tune ECU, Yosh box, etc)

 

[NancysToy]

This is correct and I believe it is all states!! I work for a major corporation and we HAVE to make available our diagnostics to allow 3rd party service and fair competition. BRP has to by law sell BUDs to someone if asked. Now what they charge for it can be the issue. Parts of that law requires they sell any proprietary diagnostics tools at a "fair" price but this is open ended and thus if they charge you say $10,000 only thing you can do then is take them to court usually via a class action unfair competition suit. I have been down this road in the late 80's when our company was doing these practices so trust me I know.

Updated: FYI they do not have to tell you the protocol as part of that law. They only have to make available the tools needed to do service on a product e.g. allow a 3rd party company to provide service as part of fair competition.

Bob

Don't count on it. This applies to vehicles (automobiles) that are required to be OBD-II compliant, but the Spyder is not one of them and I do not believe it applies to BUDS and BRP's proprietary diagnostics system, or BMW motorcycle's' proprietary diagnostics, etc..

 

[ARCTIC]

What if you were able to get a hold of a buds tool? Would you be able to crack the code?

 

[Showie]

:hun: :bowdown:

 

[UNCLEDAVE]

Reducing the "fog" index in the BUDS discussion

Couple of comments on terms used in the "BUDS" discussions (Tapping into the computer in your Spyder):

• Your Spyder "on-board" computer captures data many times a second in some cases. i.e. data concerning engine status, ABS status, cruise control status & much-much more
• Spyder data is just like what's stored in a black box of an airplane. i.e. What was "on", what was "off", temperature, etc.
• Typically, this data is captured via numerous sensors in your engine & components
  • Above sensors have wires that are connected to a common cable called BUS
  • Being able to physically tap into this BUS is just the start
  • Knowing what the data means (traveling through the BUS) is the "unknown" here
  • Data:
    • Is stored in binary (0's & 1's)
    • A fixed number of 0's & 1's equals a byte
    • The contents of a given byte is a mystery unless you know the protocol
    • Protocol is basically how the data is arranged for a given situation
    • Protocol's can be very simple in some case
    • Or, protocols can be complex depending how a system (software) was designed and what they're reporting
• Keep in mind that as the writer(s) stated, protocols are sacred to the folks (companies) that developed them. They typically have spend tons of money designing & debugging these systems & giving out ALL of the internal workings/nomenclature is like loaning money in a poker game. i.e. You're betting against yourself.

UncleDave

 

[finless]

I think your confusing the BUDs proprietary (code and protocol) with fair competition laws. If you sell a product to the public that requires service to maintain, then you have to sell all specialty tools that are required to properly service the product or you are maintaining a monopoly.

I work for Xerox corp. For years we had proprietary software and tools used to diagnose copiers and printers that was protected from access except to Xerox people. We spent huge amounts of dollars developing it. Protocols were also involved. We got sued by 3rd party service companies in a Anti-Trust class action that we were unfairly monopolizing the service revenue for Xerox machines. We lost (or settled) and had to then offer for sale when asked these tools and software!
This did not mean we had to give up the protocol or "how the code works" as that is a trade secret, patents, etc... So again BRP does not have to tell you anything about the protocol or software. They simply HAVE to sell you the device if it is required to properly service the product.

It's called the Sherman Act.

http://www.justice.gov/atr/public/divisionmanual/chapter2.pdf

For your reading enjoyment about Xerox:

http://www.law.gmu.edu/assets/files/publications/working_papers/01-02.pdf


Now the problem is if BRP holds out, you would probably have to take them to court to get them to stop.

Bob

 

[NancysToy]

I think your confusing the BUDs proprietary (code and protocol) with fair competition laws. If you sell a product to the public that requires service to maintain, then you have to sell all specialty tools that are required to properly service the product or you are maintaining a monopoly.

I work for Xerox corp. For years we had proprietary software and tools used to diagnose copiers and printers that was protected from access except to Xerox people. We spent huge amounts of dollars developing it. Protocols were also involved. We got sued by 3rd party service companies in a Anti-Trust class action that we were unfairly monopolizing the service revenue for Xerox machines. We lost (or settled) and had to then offer for sale when asked these tools and software!
This did not mean we had to give up the protocol or "how the code works" as that is a trade secret, patents, etc... So again BRP does not have to tell you anything about the protocol or software. They simply HAVE to sell you the device if it is required to properly service the product.

It's called the Sherman Act.

http://www.justice.gov/atr/public/divisionmanual/chapter2.pdf

For your reading enjoyment about Xerox:

http://www.law.gmu.edu/assets/files/publications/working_papers/01-02.pdf


Now the problem is if BRP holds out, you would probably have to take them to court to get them to stop.

Bob

The only special tool is the cable, which can be purchased from BRP. BUDS is the software, which is protected as I understand it.

 

[billrob71]

Congrats on your progress , can bus system is pretty complicated and a big parts of a lot of new cars out there. Rewriting over the programs is going to be a challenge if that's your goal probably not impossible.

It would be nice to desensitize the system a little would make a whole new riding experience :thumbup:

 

[Spyder Monkey]

Wish there were more hours in the day (or the weekend at least ). Lots to reply to here but I've only got access to these tools for a few more hours.

What is the easiest "error code" that is harmless and easy to cause / clear? I'm curious if the error codes listed in the manual map to data on the bus. Does what I am saying make sense? I want to trigger an error on purpose and make the Spyder throw an error. Then I want to be able to clear it and see if I can decode it.

David

 

[NancysToy]

Wish there were more hours in the day (or the weekend at least ). Lots to reply to here but I've only got access to these tools for a few more hours.

What is the easiest "error code" that is harmless and easy to cause / clear? I'm curious if the error codes listed in the manual map to data on the bus. Does what I am saying make sense? I want to trigger an error on purpose and make the Spyder throw an error. Then I want to be able to clear it and see if I can decode it.

David

Open the brake reservoir and push down on the float, simulating a low brake fluid condition. Be gentle, so you don't overflow the corrosive brake fluid...and use a clean tool (or finger) to push down the float. Note that this would indicate the switch position. Unless I am mistaken, the corresponding error code would be interpreted and stored by the processor, so you would be unlikely to see fault codes themselves on the CANbus.