OE message LCD CAN interface

**theshadow27** · 10-04-2009, 10:59 PM

My car (2005 Volvo S40) has an LCD in the gauge cluster (see top screen)which displays messages from the various computer modules in the car (like the door module, which sends a "passenger door open" message when you open the door) via a Controller Area Network (CAN) bus. I'd be willing to help develop a interface like connect but rather than outputting via RS232, outputs messages to the CAN bus.

Many cars these days have similar screens, and they almost exclusively use CAN, however the protocols are probably different across makes, and even models. So the challenge is:

1) Develop a CAN hardware platform that can automatically determine vehicle network speed and monitor messages.
2) Create a USB interface that can log messages from the CAN bus.
3) For each make/model, have the user log a bunch of messages while triggering things that show up on the LCD
4) Start an online CAN message database/forum where CAN logs can be posted and us techies can figure out a "driver" for each vehicle
5) Once there's a driver, allow it to be loaded in the device and connected to the V1

I picked up two of these kits:
http://www.microchip.com/stellent/id...t=MCP2515DM-BM
And will play around when they show up. The order has been pushed back until 30-October though :/

**justchat_1** · 10-05-2009, 02:41 AM

Originally Posted by theshadow27

My car (2005 Volvo S40) has an LCD in the gauge cluster (see top screen)which displays messages from the various computer modules in the car (like the door module, which sends a "passenger door open" message when you open the door) via a Controller Area Network (CAN) bus. I'd be willing to help develop a interface like connect but rather than outputting via RS232, outputs messages to the CAN bus.

Many cars these days have similar screens, and they almost exclusively use CAN, however the protocols are probably different across makes, and even models. So the challenge is:

1) Develop a CAN hardware platform that can automatically determine vehicle network speed and monitor messages.
2) Create a USB interface that can log messages from the CAN bus.
3) For each make/model, have the user log a bunch of messages while triggering things that show up on the LCD
4) Start an online CAN message database/forum where CAN logs can be posted and us techies can figure out a "driver" for each vehicle
5) Once there's a driver, allow it to be loaded in the device and connected to the V1

I picked up two of these kits:
http://www.microchip.com/stellent/id...t=MCP2515DM-BM
And will play around when they show up. The order has been pushed back until 30-October though :/

Two of those kits as in 4 board??

Also, curious...why a standalone board compared to an obdII reader with the elm327 chip...and just software that resets it to 500kbps when the connection is opened. That should be more then enough to handle even the fastest CAN buses and would be quite a bit easier (and safer) to connect.

I hate to say it but I think your going to be very disappointed with the lack of forum response to this idea. Your talking about something that doesn't only vary between manufacturers but can also vary between individual models and years - your talking thousand of different possibilities...with quite a bit of work for each.

That said....best of luck

**theshadow27** · 10-05-2009, 08:54 AM

Originally Posted by CityFan86

Originally Posted by theshadow27

I've talked to folks who have tried similar things and supposedly the best way to sniff CAN is to hook up and start unplugging things. When that address drops off the trace, plug it back in and filter it out. Eventually you're only left with the thing you're looking for. This sounds like a tremendous PITA though.

What I'd like to do is come up with a method of "searching" for the correct address with the embedded system in it's final form. This may not be possible between different makes, but I'd bet that all Volvo's use the same type of command to put messages on the LCD screen. Other car makers probably do the same. It just doesn't make sense to re-invent the wheel every time you change the background color of the gauge cluster...

I think the only way is the PITA way. You could log all the messages and try and look to see if one makes sense. You should in theory be able to see the ASCII characters being transmitted that correlate to the display, so may not be too bad. But yes, all message ids will vary between makes and probably between models.

I don't think we'll see ASCII, at least not with a raw hex dump. CAN uses 8 bytes per message, and ASCII would be terribly inefficient. At the very least, it'd use 7 bits per character, but I think they would probably also get rid of the 32 control chars at the beginning. You can get things down to 6 bits using something like the BASE64 alphabet (A–Z, a–z, 0–9, then ".", and ":") which would allow 10 chars + 4 control bits in each message.

The thing that worries me is that it's a 3 line x 16 char display. Although the messages are only the upper two lines, even with 6 bits per character it would take 3 CAN messages to set the entire thing. If this is the case, there may be a more complicated multi-message protocol going on... Or it's using a dictionary, in which case I'm going to cry.

I agree that different cars will have very different protocols, but I think building the sniffer into the board will make things faster, just so others don't have to duplicate our work.

Originally Posted by justchat_1

Two of those kits as in 4 board??

Also, curious...why a standalone board compared to an obdII reader with the elm327 chip...and just software that resets it to 500kbps when the connection is opened. That should be more then enough to handle even the fastest CAN buses and would be quite a bit easier (and safer) to connect.

Yeah 4 boards, I generally buy two of everything for electronics stuff, just in case something gets messed up during hacking/protoing. Two of these boards will get optoisolators, one will also get another PIC for V1 display reading.

I chose to go custom rather than OTS for versatility. This board is going to do a number of things if I succeed:
- Read the V1's HDSP and output radar messages to the gauge-cluster LCD.
- Monitor mute wires from two LI computers and output laser messages to the gauge cluster LCD.
- Use the factory mute feature to turn of the stereo and beep when either of the above conditions are met.
- Monitor vehicle speed readings from the car's ECM. This will disable the LI computers and disable audio mute/warnings under 25 mph.

The V1 HDSP needs a few external components to input, as does the LI. The audio mute/output needs at the very least a small amp and relay. All of this stuff will eventually go on a PCB so I figured I'd start with something that had a protoboard.

Originally Posted by justchat_1

I hate to say it but I think your going to be very disappointed with the lack of forum response to this idea. Your talking about something that doesn't only vary between manufacturers but can also vary between individual models and years - your talking thousand of different possibilities...with quite a bit of work for each.

Yeah, I don't have high expectations. I doubt this will ever turn into a real "product" that others can build, but input is always valuable and always welcome.

Originally Posted by justchat_1

That said....best of luck

Thanks! I'll need it.

**MattJackson86** · 10-05-2009, 10:55 AM

Reagarding the ASCII, I bet there are multiple CAN messages IDs for each display. Each message will send ASCII characters (actually the HEX code for each character). As you said each message can only fit x number of characters, hence the reason multiple messages will be sent to build up the full display.

I think the way to go about the hardware is to just build a generic CAN BUS message reader/writer. All it does is connect to the 2 CAN BUS wires and starts dumping all messages to a serial port. Software could also write to the serial port that would in turn send a message. This way the hardware has unlimited CAN BUS usage. Then you write software specifically for the HU display.

**justchat_1** · 10-05-2009, 11:12 AM

Originally Posted by CityFan86

Reagarding the ASCII, I bet there are multiple CAN messages IDs for each display. Each message will send ASCII characters (actually the HEX code for each character). As you said each message can only fit x number of characters, hence the reason multiple messages will be sent to build up the full display.

I think the way to go about the hardware is to just build a generic CAN BUS message reader/writer. All it does is connect to the 2 CAN BUS wires and starts dumping all messages to a serial port. Software could also write to the serial port that would in turn send a message. This way the hardware has unlimited CAN BUS usage. Then you write software specifically for the HU display.

I'll bet not. For many design reasons it doesn't make sense to transmit whole ascii messages across a bus when the data set is so small. Not familiar with your car in particular but many of those displays also include graphics (door open, etc). Typically these units just listen to the can bus and display messages in response to received messages. Door open message triggers an ascii string and possibly graphic stored in memory to be displayed. This prevents display-specific messages from being sent and allows for things like using the same hardware for different regions (ex: you just need a different display for german characters instead of different ECU programming).

i would say the best approach is like stated above to just hook up the two wires and do a data dump. But more then that setup some custom software first. It should have an activate/deactivate filter learning setting for best results. This way you turn the car on...wait a minute and then without touching anything begin dumping data adding every message type detected to the filter. Now with all the "noise" being filtered disable the filter learning (leaving the filter on) and do a simple action like turn on the headlights or open a door (one at a time work through the easy ones). Then drive around for a few miles and do another data dump after using the original filters. The only messages that get through should be the new fuel level. Theres a dozen of these tests you can do to slowly weed out whats out-but that should start you off.

**MattJackson86** · 10-05-2009, 11:15 AM

If thats the case, then on the cars which are like that I dont know how custom messages could be sent and displayed. It sounds like they just react to a message id and display standard wording/graphics. Time to start logging the messages and seeing.

**theshadow27** · 10-05-2009, 11:28 AM

Originally Posted by CityFan86

I think the way to go about the hardware is to just build a generic CAN BUS message reader/writer. All it does is connect to the 2 CAN BUS wires and starts dumping all messages to a serial port. Software could also write to the serial port that would in turn send a message. This way the hardware has unlimited CAN BUS usage. Then you write software specifically for the HU display.

That's exactly what the Microchip boards do out of the box. They come with software for sending and recieving messages over USB. That's why I got 'em

I also have the C# source for the PC side, and will implement filtering and decoding in SW.

There's a number of comercial products that do that already, but the HW starts at $400 and the SW at $1500. The Microchip boards were $60...

However I want the final form to be entirely embedded. I refuse to trust Windows with SIGINT; can you imagine blowing by a cop at 175 with no alert because it was trying to do a Windows Update? FTN

Originally Posted by CityFan86

If thats the case, then on the cars which are like that I dont know how custom messages could be sent and displayed. It sounds like they just react to a message id and display standard wording/graphics.

That's what I meant by "dictionary." For my car I'm inclined to think this is not the case, since I talked to someone who specifically said that the messages were sent as text to the display from various modules. But he could be wrong...

Originally Posted by CityFan86

Time to start logging the messages and seeing.

+1

**_Dejan_** · 10-05-2009, 02:41 PM

Hi guys,
I will try you help with researching CAN protocol and share my experience

1.) Im using USBCAN device which have 2 wire connection or CAN network. Device new cost around 100€ What is little more than ELM327 device(Not cheap chinese toy)...
2.)For logging Im use CANHacker application which have Monitor mode from which you can easy monitor data and se what thing change what without searching trough all lines...
3.)Im make my own CAN plugin for Centrafuse and must say that is prety simple to do it

Much easier than my GPS engine plugin

You just open serial port send 2-3 commands(clear FIFO, setup CAN speed and open can network) and you see data which come to COMPort. Data are in next format:

Code:

t28180082803E000000002CBC
t38A200002CC9
t18060000000000002CCB
t2A04800000892CD3
t38082044484C003E0D052CDC
t38868800007D98002CE3
t3C04000000002CE5
t282200002CED
t140800000080080000002CF0
t286800080000000000002CF2
t28180082803E000000002CF7
t3C332010402D1D
t28180082803E000000002D27
t2A04800000892D3D
t286800080000000000002D54

For example from last t281 we can see:
t28180082803E000000002D27
where next xx things for my car mean:
t2818008280xx000000002D27

engine water temp. offset -40 degrees from -40 to 215 degrees:
3E(HEX)=62(DEC) temp= 22°C

t28180082803Exxxx00002D27

fuel consumption factor 0.0022 from 0 to 132 L / hour
car turned off so there has not be any consumption

t28180082803E000000xx2D27

engine speed (rpm) factor = 32 0 to 8000 rpm
car turned off...

And there is a lot of researching... A lot of CAN codes for my car Im find on web so this has been a lot of easier...

**MattJackson86** · 10-05-2009, 03:43 PM

Great info Dejan. Any links to the hardware and/or software?

**_Dejan_** · 10-05-2009, 03:53 PM

Originally Posted by CityFan86

Great info Dejan. Any links to the hardware and/or software?

You must know that all this data is vehicle specific and you can't make some device like OBD scanner which have LCD...
Few links:
CANUSB
CAN232 (Same as CANUSB but I preffer USB version which is better for higher CAN speeds)...
CANHack forum
I think that you will find a lot of usefull info in this forum, you will find CANHacker application...

Good luck

P.S. Looks like canhack forum has crash and all data has been lose...