Playing with the canbus

[sparkybean]

Hi all.

Ive been looking at interfacing with CANBUS for a while. Not in any professional sense, more because i am curious and just like to tinker. I think what i am after is some software that i can connect my CANBUS to (i have a OBD-USB cable) so i can see what data is being sent through the BUS and possibly even inject some data/commands of my own.

Currently i cant find any software that seems to be what im after, suggestions much appreciated!

Thanks.

[Eggman]

I've been toying with the idea too, but have yet to come up with a compelling project that would get me beyond the pondering stage. I'm not particularly looking forward to these cars reaching an age where the canbus starts playing up though, whenever that is!

Anyway, this might be of interest, or maybe this.

[anonymous-user]

sparkybean said:

and possibly even inject some data/commands of my own.

Word of warning. Doing this without knowing what you are doing carries some risk. Although it is unlikely you will say accidentally inject the "trigger all airbags" code it is a possibility. Far more likely is that you will accidentally spoof some CCP command that effectively puts some random module into a fault loop, effectively immobilising your car !!

[stevieturbo]

I seen a Saab years ago with a broken stereo that immobilised the car !

WTF are some car makers thinking when they introduce these technologies ?

[anonymous-user]

There's plenty of CAN hardware and software availible, it just comes down to the price you want to pay and your skills as a programmer etc.

The high end stuff (Kvaser, Vector etc) is expensive (~£650 for a CAN-USB dongle, and >£1k for the software (CANALYSER etc)

The mid range stuff (PEAK USB-CAN (£160) + PCAN Explorer (~£400) makes it easy to just start logging without knowing a lot about coding / programing etc.


If you are familiar with any programming languages for PC, then the PEAK h/w comes with a well documented API, meaning you can just buy the hardware (USB-CAN) saving quite a bit of money (well, technically "trading" that money for your time!)

If you want really cheap, then you'll be using a commonorgarden microcontroller (take your pic, from er, a PIC, AVR etc etc) with some hand build hardware (either on-chip CAN or MPC2551 etc). This is a cheap option, but time consuming if you know nothing about programming / CAN.

Also, some knowledge of automotive CAN would be useful, (eg CCP, UDS, OBD PIDs etc) and make working out is going on much easier. Also, broadcast data only covers about a 10th of the availible data, and you may/will need to get through some gateway handshakes to get into the really good stuff.

[Nick1point9]

I wouldn't bother, without having a file that describes the scaling/channel names/signed or unsigned etc etc the info is completely useless. And there is no point "having a tinker". You won't be able to change any signals, just send your own, and that will mean either the nodes aren't expecting to receive it so won't do anything, or you'll make the BUS heavy but sending the same identifier as an existing channel.

[anonymous-user]

Nick1point9 said:

I wouldn't bother, without having a file that describes the scaling/channel names/signed or unsigned etc etc the info is completely useless. And there is no point "having a tinker". You won't be able to change any signals, just send your own, and that will mean either the nodes aren't expecting to receive it so won't do anything, or you'll make the BUS heavy but sending the same identifier as an existing channel.

It's perfectly possible to "reverse engineer" a lot of the CAN DBC from just observing the broadcast messages. Using things like the standardised UDS handshakes can also open up a lot of extra information.

I routinely do just that for competitor vehicle benchmarking studies (for which i obviously don't have OEM support). I now use data reduction and DOE techniques from within a Matlab environment to automate that process to some degree!