I finally got another free evening to devote to reverse engineering the Can-Am Spyder diagnostic interface.  For the back story, see part 1 here.  But things did not quite work out like I hoped for tonight’s Spyder hacking. As usual, it is the hardware guy’s fault.

First order of business was to build another cable to connect the CAN lines from the Android Open Accessory kit to the Spyder itself since the Spyder to OBDII effort did not yield anything useful. The AOA board has footprints for both a DSUB-9 and an RJ45 but I used the DSUB connector because I could not find RJ-45 connectors in the lab without magnetics.

Based on the two schematic snippets, I fabricated a simple 3 wire cable connecting Pin 2 to Pin 2 (Can Low), pin 3 to pin 3 (Ground), and DSUB pin 7 to Deutsch pin 1 (CAN High).

AOA CAN Pinout

Spyder Deutsch 6 pin diagnostic connector pin out

The cable was pretty straightforward to fabricate thanks to the high quality Deutsch connectors. I should have chosen pins for smaller gauge wire but I made these work. See the pictures below for useful tips. Pry the orange weather boots out of the backside of the connectors and thread your wires through the boot before locking them into the housing. The boot makes a convenient way to hold them steady while you beep out the pinout one last time (had to be careful, no pin extraction tool available if I messed up). After the pins lock in place with a satisfying click, the green wedge piece inserts from the front to lock everything in place.

Green pin locking wedge shown installed left and loose right.

Weather boot fully inserted in finished cable top and not fully inserted bottom

Cable fabrication went smoothly but I was denied the quick and easy path to testing the new cable. The AOA board has an embedded FTDI 232R that the sample projects use as a console output. I had tested the console output and it worked fine on the lightweight web server example. I was hoping to do some simple exploration of baud rate and message count using the time honored printf debugging. But it appears that something in the code for the provided Android Accessory Protocol examples conflicts with the serial console and they refuse to load, debug, or execute when a USB cable is connected to the 232R. It is odd, maybe a power budget issue but I can have a working CAN demo session connected when I connect a USB cable to the FT232R. Connecting the cable is fine but as soon as I open the port, the CAN connection in the demo drops. And it returns immediately when I close the session.

So this Spyder diagnostic hacking session is over. Now I either spend time figuring out the serial console, log all data to internal SD via the FAT FS library, or develop an Android GUI. The Android GUI option is probably the best way to go long term, better bandwidth and faster dev cycle but it will be a steeper initial learning curve. Oh well, I wanted to get better at Android development anyway and this will probably make for an interesting part 3.

Update:  After looking at the schematics, I figured out how to enable the serial terminal without disrupting the CAN communications.  The two jumpers on JP4 are installed by default.  Remove them and you can open the port without triggering a reset of the processor.  Spyder Diagnostic Hacking is back on, I can at least figure out the baud rate now.

This was a continuation of a previous post.  Click through to see the first post.