[Gadgeteer]

Hello All,

Anyone out there ever actually tried hacking the Can-Bus between the ECU and the instrument cluster?

I've searched and read lots of threads saying that the clocks and ECU have to be connected and talking to each other before the motor will run. Also, that the speedo gauges don't have to be matched or coded to the ECU, just from the correct model year.

It makes me think that the messaging between ECU and cluster can't be too complex with serial numbers and so on, maybe just a standard response or checksum.

I've done something similar and hacked the clocks on my Suzuki TLR before, but that was just a basic serial interface. Can Bus is a bit more tricky but luckily I have a CanBus development kit to play with (and an electronics degree which is always handy!)

It must be possible because T3 racing have done it with their race dash. We just don't know if they got help from Triumph or had to work it out themselves.

So I plan to have a crack at this and make a little box of tricks that will make the ECU think that the clocks are connected. If anyone else has tried this - let me know.

My other problem - I have a half started race-bike project so I have an engine and ECU, but no clocks to test with. If anyone out there has some old damaged/crashed/bashed clocks lying around that I could strip down for the electronics, that would be handy. No cheap ones on eBay at the mo.

Thanks
Gadgeteer

 

[Tripped1]

http://www.interfacebus.com/Design_Connector_CAN.html

I bought two connectors and built a tap and started pulling signals with an 8 channel digital O-scope...issue is that I don't often have access to that scope and I damn sure can't afford a $70,000 piece of test equipment for one of my nerdy experiments.

From what I can tell the cluster missing is a ECU panic, and it won't fire the injectors

 

[Gadgeteer]

Thanks for the link Tripped. Should come in handy.

FYI, the dev board I'm going to use for this is this one:https://www.silabs.com/Support%20Documents/TechnicalDocs/ToolStick_F582_DC_UG.pdf
Luckily I work for Silabs so can raid the storeroom for the hardware and can call on our software team for CanBus advice. These things only cost a few $ so if it works then it could be useful for everyone who wants aftermarket clocks.

I'm really hopeful that this may just be about basic handshaking between ECU and the clocks (or my dummy clocks module at the same address). There is a thread here where a guy is using AIM datalogger instead of Triumph clocks and I think its using CanBus. Seems to work for him, and I doubt AIM put anything 'Triumph specific' in their unit. http://www.triumph675.net/forum/showthread.php?t=42621

Cheers
Gadgeteer

 

[Tripped1]

Thanks for the link Tripped. Should come in handy.

FYI, the dev board I'm going to use for this is this one:https://www.silabs.com/Support%20Documents/TechnicalDocs/ToolStick_F582_DC_UG.pdf
Luckily I work for Silabs so can raid the storeroom for the hardware and can call on our software team for CanBus advice. These things only cost a few $ so if it works then it could be useful for everyone who wants aftermarket clocks.

Ohhhh daddy like

I'm really hopeful that this may just be about basic handshaking between ECU and the clocks (or my dummy clocks module at the same address). There is a thread here where a guy is using AIM datalogger instead of Triumph clocks and I think its using CanBus. Seems to work for him, and I doubt AIM put anything 'Triumph specific' in their unit. http://www.triumph675.net/forum/showthread.php?t=42621

Cheers
Gadgeteer

It would be interesting.

It was just something I was messing around with......now I may have to get one of those silabs boards and a mess around a bit.

 

[Harsh]

Also, that the speedo gauges don't have to be matched or coded to the ECU, just from the correct model year.

I don't think the same year model even matters. There has been some discussion on swapping out older dash units for the nicer newer units and that they will just plug in with no ill affects.

 

[Gadgeteer]

Good point. Not sure where I got that idea -maybe from some posts where people were trying to get the right clocks to match their bikes.

I've been reading more about CanBus protocol tonight and I'm growing in confidence that this is going to work.

Cheers,
Gadgeteer

 

[Budo]

This must be what it feels like to be blonde...

I have no freaking idea what you guys are talking about :laugh:

 

[Ruby Racing]

This must be what it feels like to be blonde...

I have no freaking idea what you guys are talking about :laugh:

http://www.interfacebus.com/Design_Connector_CAN.html

I'm with you on that one Budo. I read the first line of that www.interfacebus.com link and then left quickly whilst nobody was looking. I have no idea what is being said, it might as well be a foreign language! However I have subscribed as I'd like to know the outcome.

Good luck Gadgeteer.

 

[>moto<]

I don't see that having the clocks connected would do anything but act as a permissive to fire. I'm quite confident it's a basic handshake before the ECU runs through the start/ignition sequence.

Anything other than that is well, pointless!

 

[LIV2]

I wouldn't be surprised if there was some form of handshake between the ECU and clock, I have heard of the ECU needing a year specific unlock when they're uncrated, or when people have done engine swaps.

 

[Tripped1]

I wouldn't be surprised if there was some form of handshake between the ECU and clock, I have heard of the ECU needing a year specific unlock when they're uncrated, or when people have done engine swaps.

In computer terms the handshake is the communication of two computers (or any device with its own processor). In a canBUS its not a technical handshake, the controller (ECU) is running the show. Likely not having the cluster present and not allowing the bike to fire is a anti-fraud feature so you can't milk the odo mileage. I doubt that anything functionally required is going on. in the gauge.

I've heard of sync procesedures...but I can't really see the need. McBandit would likely be able to shine some light there.

I messed around with it a bit and but the bike didn't seem to have spark trying to get it to fire without the cluster, it may be something as simple as a relay voltage that isn't supplied with the cluster disconnected. But I admittedly haven't dug to deeply into what is running or where and triumph is NOTORIOUS light in the documentation department. Thus I didn't get out the meter and confirm that no injector signal was being sent or any such.

I really like Gadget's idea about emulating the cluster so the bike will fire without it.

...and my warranty is up next month.:thumbup:

I'm debating looking for a cheaper version of...http://www.anagate.de/en/products/AnaGateCANUSB.htm USB canBUS gateway so I don't have to try to decode the signal.

 

[williamr]

Handshake is a term we usually use when an interface includes dedicated signal lines such as Request and Acknowledge between two physically directly connected units.

Canbus seems to be a message driven LAN passing message frames using start and stop bits like the old teletypes - but a bit faster, and with a bi-directional interface. Does it use collision avoidance and detection? Ah yes, detection only with arbitration rather than 'back off and wait'.

So I'm guessing that during POST checks the ecu requests data from the cluster - one or more requests. The best solution is probably to build an emulator that'll return the frames that the ecu expects to see.

Anybody know which CanBus protocol Triumph are using?

Rob

 

[Tripped1]

Handshake is a term we usually use when an interface includes dedicated signal lines such as Request and Acknowledge between two physically directly connected units.

Fair enough I've heard the term used 6 or 7 ways.

Canbus seems to be a message driven LAN passing message frames using start and stop bits like the old teletypes - but a bit faster, and with a bi-directional interface. Does it use collision avoidance and detection? Ah yes, detection only with arbitration rather than 'back off and wait'.

Pretty sure its arbitrated, in that regard it seems a lot like VME except packetized serial transfer vice 64 bit parallel.

So I'm guessing that during POST checks the ecu requests data from the cluster - one or more requests. The best solution is probably to build an emulator that'll return the frames that the ecu expects to see.

Exactly what Gaget was driving at.

Anybody know which CanBus protocol Triumph are using? Nmea is for marine use (use that for the GPS and instruments on the boat) ISOBUS is mainly agricultural, J1939, J1708 and J1587 are primarily for commercial vehicle use, but have the car and bike guys taken them over?

Rob

Nope I manged to decode a couple status words, but that was about it.

 

[chewwtoy]

Love to jump in here. Sorry, I found this thread through google and it's up my alley.

I have been working with CAN Bus for quite some time and run a service company that specializes in Reverse Engineering CAN BUS on vehicles. Although I don't have any information specifically to the Triumph, I can tell you this.

There are three types of CAN Bus and for this application, I imagine that the ISO 11898-1 is used. It is also most likely a 500kbp baud rate. As far as simulating the Cluster, there is a good chance this can be done by connecting a tool that can monitor the CAN Bus (google can bus to usb adapter). These typically run from $95 up to $295 depending on what features you want. With this you should be able to view all of the messages on the network.

To find the messages specific to the cluster, simply look at the data, make a list of the message IDs, then disconnect the cluster and see which messages stopped updating. This will give you a very good idea of what messages come from the cluster.

One important thing to note, that if there is an authentication that occurs between the engine controller and the cluster, this may be very, very difficult to bypass or simulate and here's why... The engine controller may send a Challenge out on the CAN bus. Then the cluster, also on the same bus, may receive the challenge, understand that this is a challenge and respond to this challenge by using some unknown algorithm to authenticate itself to the engine controller.

In automobiles, this is how immobilizer systems work when they challenge the vehicle's key. In these situations the cost to reverse engineer and understand this authentication and then the ability to simulate the authentication are very high and, if you are doing this just for hobby, the costs/time are way too high.

To find out if there is a challenge and a response, look for a message whose data seems to be sent at start, one-time, and whose data seems to be random each time you start. Then, after the challenge, you will see a similar message whose data seems to be random and it will always change based on the challenge data. These two individual messages will be the challenge and response. If there are they, then you will have one hell of a project ahead of you in order to find the algorithm for the authentication.

Good Luck and if you are looking for more information about hacking the CAN Bus, check out my blog at http://www.CanBusHack.com

 

[williamr]

I think we've all been assuming that there'd be no immobiliser style challenge/reponse with pseudo random data. That would create an unnecessary complication in replacing instruments No guarantee that Triumph haven't done that though.

For the coms guys out there, be aware that the Can Bus spec describes the physical layer of the ISO model, not the higher level protocols that run over it.

Rob

 

[zlostar50]

did anyone made it....to run engine without cluster