Pin out for that 6 pin Diagnostic connector?

[Spyder Monkey]

I finally got the parts to start reverse engineering the BUDS protocol and I can't seem to find the pin assignments for the 6 pin Buds connector and the service PDF is going slower than christmas for some reason. Does anybody know / have the pinout for that 6 pin connector? I think CAN Hi is White / beige and CAN Lo is White / black but I am not sure. Any help appreciated.

David

[NancysToy]

CAN-HI is White/Beige
CAN-LO is White/Black

According to the 2010 wiring diagram.

[Spyder Monkey]

Thanks. Will build the cable this weekend and see how far I can get.


Sent from my GT-N7000 using Tapatalk 2

[pro10is]

Here you go. We spoke back in August. Let me know if I can do anything to help.
63932

[Spyder Monkey]

See the picture

Anybody explain what the "K-Line" signal is?

David

[NancysToy]

See the picture

Anybody explain what the "K-Line" signal is?

David
I'm assuming it is a common for the two CANBus channels, but I really haven't a clue how it really works...that's just a wild guess.

[pro10is]

See the picture

Anybody explain what the "K-Line" signal is?

David

David, the "K-Line" is an alternative underlying physical layer for OBD via the KWP2000 protocol (ISO-9141) providing bidirectional serial communication with a data rate up 10.4 kilobaud. The CAN line (ISO-11898) is significantly faster with data rates of up to 1 Mbit/s.

[NancysToy]

David, the "K-Line" is an alternative underlying physical layer for OBD via the KWP2000 protocol (ISO-9141) providing bidirectional serial communication with a data rate up 10.4 kilobaud. The CAN line (ISO-11898) is significantly faster with data rates of up to 1 Mbit/s.

Thanks for clearing up the mystery. :thumbup:

I wonder if BUDS utilizes this channel, too, for some purpose.

[Cruzr Joe]

David, the "K-Line" is an alternative underlying physical layer for OBD via the KWP2000 protocol (ISO-9141) providing bidirectional serial communication with a data rate up 10.4 kilobaud. The CAN line (ISO-11898) is significantly faster with data rates of up to 1 Mbit/s.


Dang it, i thought that was a double gitback. :roflblack::roflblack::roflblack:

Cruzr Joe

[Spyder Monkey]

Thanks for clearing up the mystery. :thumbup:

I wonder if BUDS utilizes this channel, too, for some purpose.

Doubt it since the BUDS USB adapter is a rebadged USB to CAN adapter. But possible.

Made small progress but my CAN enabled Microcontroller had a steeper learning curve than I expected. I was able to exchange CAN messages with another microcontroller but have not yet built cable for Spyder.

[NancysToy]

I wouldn't be a bit surprised if they used that to write data into the Spyder.
Sounds logical. Those updates have to go somewhere. Things were sure easier in the old days! ;)

[Spyder Monkey]

Tried and failed at the easy path. Hooked the can lines plus the k line to an Elm327 chip to see if the dialect of can was one known to that obd decoder chip. No joy.

That Deutsch connector is an impressive little sucker. Looks very study and water tight. So now I build another cable to hook it up to my microcontroller and see if I can at least figure out the baud rate and simple messages like gear and speed.

Sent from my GT-N7000 using Tapatalk 2

[NancysToy]

.....I have absolutely no experience with OBD but starting from scratch and analyzing the bus activity and then reverse engineering an interface sounds like a fun project.
Yeah, lots of fun, sort of like a root canal. :roflblack:

[flamingobabe]

SpyderMonkey...keep it going...all this is way-over my head...I like to put key in...start engine...ride...but Mark and lots of others could use this info to work on Spyders

[pro10is]

If I was going to do this I would start by getting my hands on ISO 11898, parts 1 and 2. http://www.iso.org/iso/catalogue_detail.htm?csnumber=33422 or at least something that described it. That would give you the base data link layer and the physical signalling. Then (and this is the tricky part) you could concentrate on decoding BRP's proprietary final data layer.

[Spyder Monkey]

If I was going to do this I would start by getting my hands on ISO 11898, parts 1 and 2. http://www.iso.org/iso/catalogue_detail.htm?csnumber=33422 or at least something that described it. That would give you the base data link layer and the physical signalling. Then (and this is the tricky part) you could concentrate on decoding BRP's proprietary final data layer.

Ok, at first you scared me that I was way off track but after looking at the parts, I think we agree in the approach just different ways of getting there.

CAN was developed for automotive applications but it is widely used in many industries now. Believe it or not, I learned about CAN working on building a treadmill for the ISS at NASA because the motor controller spoke CAN.

I bought http://www.embeddedartists.com/products/app/aoa_kit.php because:

It has CAN PHY and controller built in
It is cheap compared to most USB to CAN adapters
I already have tools and experience programming a very similar NXP microcontroller from the same family.


So I messed with it some this weekend and I got the board up and running and built the CAN example code and ran it and it works. Had some power supply headaches (turns out it really needs a full amp or you get weird errors programming the flash.

So next is to see if I can just eavesdrop on the bus and get the baud right. If that works I have to figure out how fast I can log data to the SD card (it is only accessing it in SPI mode so probably not very fast).

My company wants me to write blog posts on technical topics like this so I'll keep you guys posted of any progress.

[Spyder Monkey]

Not a lot of progress but some. Here is a blog post that does not cover much new ground from what is posted here that I put on my company website:
http://www.sparxeng.com/blog/hardware/reverse-engineering-the-can-am-spyder-diagnostic-interface

68052
I built a cable that pulls 12V power from the diagnostic connector and uses a cheap DC-DC converter to step it down to 5V and then powers my AOA microcontroller setup. I ran the sample CAN code provided with the unit to talk CAN to their provided CAN node (the little tiny board on the right side) while controlling the setup from my phone. So in short, I can power my development prototype from the Spyder and communicate with another CAN device so I should be able to communicate with with the Spyder itself. Next step is to try to just passively listen to the bus and see if I can fish out simple information like gear selected.

Another blog post to follow as soon as I can get the time.

David

[jthornton]

:popcorn::popcorn::popcorn:

[Spyder Monkey]

And another small update:
http://www.sparxeng.com/blog/hardware/spyder-diagnostichacking-2-things-dont-always-follow-the-plan

Short version of the above... still figuring out my development platform. Turns out the serial console was trying to update the software when I opened it so I burned a few more hours just figuring out how to get simultaneous serial debug and CAN output.

David

[Spyder Monkey]

Had trouble guessing the baud rate in software so I drug the oscilloscope out to the parking lot this morning and successfully captured a CAN message off the diagnostic connector. Looks like I was guessing too low. Cool stuff, progress is being made.

Sent from my GT-N7000 using Tapatalk 2

[rlynchtx]

I find this fascinating even though it's making my head hurt. So glad we have this sort of brain power on the forum!

[NoJive]

I agree. Awesome stuff!

Sent from my SPH-L900 using Tapatalk 2

[Spyder Monkey]

Time to update a long idle thread:
I just successfully "eavesdropped" on the Spyder CAN bus for the first time. Bit rate is 500,000 bits per second. There are about a dozen different CAN message ID's that update about every 10-20 milliseconds. The interpretation of the messages is not leaping out at me yet but I think with some careful analysis I should be able to figure them out. When it is not so late and I have had a chance to digest the data a little, I'll post some snippets and everyone can help decode.

David