• There were many reasons for the change of the site software, the biggest was security. The age of the old software also meant no server updates for certain programs. There are many benefits to the new software, one of the biggest is the mobile functionality. Ill fix up some stuff in the coming days, we'll also try to get some of the old addons back or the data imported back into the site like the garage. To create a thread or to reply with a post is basically the same as it was in the prior software. The default style of the site is light colored, but i temporarily added a darker colored style, to change you can find a link at the bottom of the site.

Need someone with a schematic to read me some pin-outs for the computer connector

Spyder Monkey

New member
Today I received my mating connectors for the Spyder computer connection. Time to fabricate a cable and see what I can figure out hacking into this thing.

There are three wires going into the back of the connector, my Spyder is in the shop right now so I can't even go look at the colors. CAN is a differential protocol so two of them should be the data+ and data- lines and I'm guessing the third is probably ground.

Could somebody with a service manual tell me what the wires are labeled as and what they connect to? Do they go to a single point inside the bike or are they part of a star topology bus? Do they have any resistors shown across the data lines?

If someone were to scan and email the relevant schematics to davidsmoot (at) gmail, I would be most grateful.

Thanks
 
I was thinking of doing this myself. Success will only be possible if they didn't use encryption.
canbus.JPG
 
Whats your goal?

I know very little about the can-bus system, so I have no idea what can be done by linking into it. Are you trying to monitor the system for faults or are you going to input data to do something?
 
Goal:
To entertain myself and learn more about the system. I don't think it would be very hard (but probably expensive) to duplicate what I can do with my OBDII adapter on my car.

I have some pie in the sky dreams to bring BUDS to the masses but I don't know if it is technically possible or legal. In all seriousness, is anyone here a real lawyer with knowledge of IP law? Contact me off the forum.

CAN is not an extremely complex protocol to listen to the bus. What is hard is talking on the bus and correctly handling the data collisions when you try to talk at the same time as someone else. But for now, I just hope to listen to the bus.

I highly doubt there is any form of encryption for most of the system data. Encryption adds processing overhead on both the sender and the receiver which drives up cost for the processor and/or makes them run slower and/or makes them burn more power. A lot of downside for very little benefit.

That said, most of the "good stuff" is probably difficult to figure out. I seriously doubt that I will be able to (or even want to) mess with VSS or the "nanny". But it should be easy to get access to all the stuff on your displays from the CAN bus (RPM, coolant temp, gear, speed, etc).

I've got a microcontroller with CAN on order.

By the way, I plan on open sourcing all my work if I get anything remotely interesting. I might sell kits or services but I'll share what I learn.

My main motivation for this is the lack of control of my vehicle and being forced to rely on the dealer. I took my spyder in for an error code to the dealer on Saturday (http://www.spyderlovers.com/forums/showthread.php?42446-Brake-Failure-Code-1282-on-08-GS-need-advice). When I called on Tuesday for status, they had already ordered the parts for a warranty replacement of the calipers. It may be petty, but I want to be able to analyze my own systems and decide what is wrong. My chosen dealer seems to be pretty smart and honest but I still trust my own judgment more than anyone else's.

I want the tools and knowledge to be able to analyze what's wrong with my vehicle before I have to drive 45 minutes away with another driver to pick me up.

So for now, baby steps. Connect a microcontroller with a CAN transceiver to the bus and listen to data. See if I can read the gear indicator data. We'll see where it leads.

By the way if someone has knowledge / skills with this stuff, I did buy a second connector if you want to help.

Anyone at BRP who anonymously sends me a protocol document would remain anonymous forever and I would never mention where all information came from. :pray:

It's a control thing... If your Spyder came with custom nuts and bolts that no standard tools could turn, owners would pitch a fit if they were prevented from doing basic maintenance. This thing is so heavily computerized that they have basically done the electronic equivalent of that. Read access to all the ECU codes should be a basic right of ownership. You should be allowed to know what the vehicle thinks is wrong.

What a diatribe... I was planning on keeping this low key but all the questions got me up on my soapbox.

David
 
David,
I'm not a IP lawyer but I do deal with them all the time. If you plan to develop anything you want to sell for profit you'll probably require a CAN Protocol License from Bosch (not Can Am). If you're just doing this as a hobby or for open source you're probably ok without it. It's generally ok to reverse engineer something as long as you don't develop a subsequent product for sale that uses patented technology.

You're right, CAN is a low-level protocol and doesn't employ intrinsic encryption but some security will probably exist especially concerning the DESS codes and control software write permission. Otherwise you'd be able to read the ignition key codes and/or overwrite the control software or stored data of the ECU or other controllers. But you should be able to read and decode most everything else and even figure out how to reset some maintenance codes so you won't have to pay a dealer to do it.

Like you said the raw CAN serial protocol is very complex with its dominant and recessive bit arbitration scheme, ID allocation, asynchronous bit timing, and multiple abstraction layers. It would be brutal to decode with just a logic or bus analyzer. What you really need is a CAN bus monitor like the Vector CanAlyzer but I'll bet those cost a small fortune. Your approach of employing a microcontroller with CAN is ambitious and sounds like a lot of fun. You'll need to be patient because this project is going to take a lot of time and effort but I wish you the best of luck.

I'm an electronic and software engineer. I have a lot of knowledge of real time control system hardware and the associated software, but very little free time. Still, if I can help you in any way please let me know.
 
Goal:
To entertain myself and learn more about the system. I don't think it would be very hard (but probably expensive) to duplicate what I can do with my OBDII adapter on my car.

I have some pie in the sky dreams to bring BUDS to the masses but I don't know if it is technically possible or legal. In all seriousness, is anyone here a real lawyer with knowledge of IP law? Contact me off the forum.

CAN is not an extremely complex protocol to listen to the bus. What is hard is talking on the bus and correctly handling the data collisions when you try to talk at the same time as someone else. But for now, I just hope to listen to the bus.

I highly doubt there is any form of encryption for most of the system data. Encryption adds processing overhead on both the sender and the receiver which drives up cost for the processor and/or makes them run slower and/or makes them burn more power. A lot of downside for very little benefit.

That said, most of the "good stuff" is probably difficult to figure out. I seriously doubt that I will be able to (or even want to) mess with VSS or the "nanny". But it should be easy to get access to all the stuff on your displays from the CAN bus (RPM, coolant temp, gear, speed, etc).

I've got a microcontroller with CAN on order.

By the way, I plan on open sourcing all my work if I get anything remotely interesting. I might sell kits or services but I'll share what I learn.

My main motivation for this is the lack of control of my vehicle and being forced to rely on the dealer. I took my spyder in for an error code to the dealer on Saturday (http://www.spyderlovers.com/forums/showthread.php?42446-Brake-Failure-Code-1282-on-08-GS-need-advice). When I called on Tuesday for status, they had already ordered the parts for a warranty replacement of the calipers. It may be petty, but I want to be able to analyze my own systems and decide what is wrong. My chosen dealer seems to be pretty smart and honest but I still trust my own judgment more than anyone else's.

I want the tools and knowledge to be able to analyze what's wrong with my vehicle before I have to drive 45 minutes away with another driver to pick me up.

So for now, baby steps. Connect a microcontroller with a CAN transceiver to the bus and listen to data. See if I can read the gear indicator data. We'll see where it leads.

By the way if someone has knowledge / skills with this stuff, I did buy a second connector if you want to help.

Anyone at BRP who anonymously sends me a protocol document would remain anonymous forever and I would never mention where all information came from. :pray:

It's a control thing... If your Spyder came with custom nuts and bolts that no standard tools could turn, owners would pitch a fit if they were prevented from doing basic maintenance. This thing is so heavily computerized that they have basically done the electronic equivalent of that. Read access to all the ECU codes should be a basic right of ownership. You should be allowed to know what the vehicle thinks is wrong.

What a diatribe... I was planning on keeping this low key but all the questions got me up on my soapbox.

David

Good explanation, thanks. My interest is in being able to do the housekeeping type things, example; resetting the steering position sensor after an alignment at home. It's an hour drive to the nearest Spyder dealer for me.
 
David,
I'm not a IP lawyer but I do deal with them all the time. If you plan to develop anything you want to sell for profit you'll probably require a CAN Protocol License from Bosch (not Can Am). If you're just doing this as a hobby or for open source you're probably ok without it. It's generally ok to reverse engineer something as long as you don't develop a subsequent product for sale that uses patented technology.
Good, your understanding basically agrees with mine. I'm not looking to get rich, it is more of a "power to the people" thing. We should not be held hostage to those who can afford BUDS.

You're right, CAN is a low-level protocol and doesn't employ intrinsic encryption but some security will probably exist especially concerning the DESS codes and control software write permission. Otherwise you'd be able to read the ignition key codes and/or overwrite the control software or stored data of the ECU or other controllers. But you should be able to read and decode most everything else and even figure out how to reset some maintenance codes so you won't have to pay a dealer to do it.
Not interested in hacking into DESS or VSS or really even the "Nanny". Mainly just want basic troubleshooting / code resetting / system monitoring. Heck, I can reset an OBDII code from my phone but it is significant time and money just for a dealer to tell what BUDS says is wrong.

Like you said the raw CAN serial protocol is very complex with its dominant and recessive bit arbitration scheme, ID allocation, asynchronous bit timing, and multiple abstraction layers. It would be brutal to decode with just a logic or bus analyzer. What you really need is a CAN bus monitor like the Vector CanAlyzer but I'll bet those cost a small fortune. Your approach of employing a microcontroller with CAN is ambitious and sounds like a lot of fun. You'll need to be patient because this project is going to take a lot of time and effort but I wish you the best of luck.
Correct on all accounts. CAN hardware is not cheap. A decent CAN bus traffic analyzer starts about $500 and easily goes up to $1K. I am going to try the microcontroller first because I have experience with a similar microcontroller at work and it has a wide CAN speed range. Plus I can easily throw the test rig in the frunk. If the bus is 125KBPS or slower then I will probably switch to www.canusb.com so I can use a laptop for monitoring.

I'm an electronic and software engineer. I have a lot of knowledge of real time control system hardware and the associated software, but very little free time. Still, if I can help you in any way please let me know.
Me too! Now I know who my beta tester will be:D.

Thanks,
David
 
Last edited:
Disappointment...

"Not interested in hacking into ... the "Nanny". "



I think 1/2 of the Mo Gang just went "Oh crap, just when you had my hopes up." :roflblack:
 
"Not interested in hacking into ... the "Nanny". "



I think 1/2 of the Mo Gang just went "Oh crap, just when you had my hopes up." :roflblack:

1. It is probably the hardest thing to do because that part of interface is totally undocumented. For stuff like gear, speed, coolant temp, I should be able to just "figure it out" by looking at the dash and looking at the data.

2. It is the most dangerous thing to do from a personal liability standpoint.

3. It is the most dangerous thing to do from a "screw up your spyder" standpoint.

That said, no promises. I just said that does not interest me, it does not mean I would not share if I figured it out. But I would have to have some way to cover my butt from liability.

David
 
Back
Top