Audi TT Forum banner

Custom text on the DIS LCD!

10K views 48 replies 26 participants last post by  John949  
#1 ·
Just got this working - I can send arbitrary text to the radio/CD status area of the DIS:

Image


Image


Image


Figured out the protocol the stock radios use to talk to the DIS, and I'm using a Raspberry Pi to send compatible messages to the DIS. Technical detail to follow later.

I intend to use this to display status from the onboard computer and whatever I can read out of some VCDS compatible software. Hopefully boost pressures - I have a BAM engine so I think it has the MAP sensor I need for this, right?

Any other ideas for what I can use this segment of the DIS for? :D
 
#13 ·
Nice one. Another use for a Raspberry Pi :D

You can read back manifold absolute pressure in mBar on measuring block (115) from the ECU and subtract atmosphere, calibrated at ignition switch on perhaps, leaving you boost as a useful display :)
 
#14 ·
Very impressive as you mention getting VCDS stuff displayed would be great

Maybe scope to partner up something with liquidTT?

Do you only control text or can you force graphics of your choice?

Well done.
 
#18 ·
JorgeTTCQ said:
Well done, very good.
There was a similar system a few years ago called EFU system from a german company called zusatzinstrumente with turbo boost and more info on fis:

(images snipped)

Cheers
Aah, very interesting. I figured I couldn't be the first to do this, it just seemed unlikely. :) Great to know someone else has done it, specifically the boost pressure display.
 
#19 ·
Wak said:
Very impressive as you mention getting VCDS stuff displayed would be great

Maybe scope to partner up something with liquidTT?

Do you only control text or can you force graphics of your choice?

Well done.
The first bit will require implementing a minimal Linux VCDS-style client, but without the GUI. I've been looking at the protocol docs and sniffing VCDS' traffic, it doesn't look too hard to do the basics. Most of the value/work in VCDS appears to be in things like the model specific knowledge like the label files, coding, etc, so just implementing enough to read the boost pressure shouldn't be too hard. Intending to open source that whenever it happens!

Don't have a liquidTT, wondering if two devices can interrogate the same component over the CAN bus or not. I suspect not...

So far I only have control of the text. There's a control byte in the messages that I haven't figured out yet, it is possible that the DIS supports other formats that might enable control of individual pixels, but I'm not going to play with it until I can get my hands on another instrument cluster for fear of bricking mine!

Interestingly, the lowercase character set has been repurposed for various special characters, this is supposed to be "ttforum.co.uk" in lowercase:

Image


So one more little task is to document the mapping. Amusing how in the TT the letter 't' is preserved in the lowercase character set, but probably just a coincidence. :)
 
#23 ·
uv101 said:
Are you replacing the original functionality, or adding to it?

I guess if you're adding to it, the Pi will need to also interpret the DIS messages already on the wire??
I've removed the original radio so the signal lines I'm using are unused now, but I think it's possible to make something like this coexist by not attempting to send when the original radio is.
 
#24 ·
I don't think it matters if you have the original radio so long as you stick to the protocol things will play nicely.
It's a little like ethernet where there are going to be clashes, but they get resolved and message re-sent.

Now you need to hook up the Pi's digital audio to an amp, and get MP3 tags displaying. 8)
I don't imagine you will be able to shove bitmaps to the display though. The controller would have it's own character set probably? I'd love to be proved wrong though. I used to load custom characters into my dot matrix printer in about 1985.
 
#25 ·
horseoutside said:
uv101 said:
Are you replacing the original functionality, or adding to it?

I guess if you're adding to it, the Pi will need to also interpret the DIS messages already on the wire??
I've removed the original radio so the signal lines I'm using are unused now, but I think it's possible to make something like this coexist by not attempting to send when the original radio is.
I guess the original radio would have been unaware of any problem status and that the dash handles a warning on the display as a priority over whatever the radio outputs.

Sounds like the original warning will still take priority over the Pi output which is the behavior I'd probably want.

How fast can you update the info on the display? a changing value for example.
 
#26 ·
uv101 said:
I guess the original radio would have been unaware of any problem status and that the dash handles a warning on the display as a priority over whatever the radio outputs.

Sounds like the original warning will still take priority over the Pi output which is the behavior I'd probably want.

How fast can you update the info on the display? a changing value for example.
I believe warnings will override anything sent like this. The DIS thinks it's the radio sending this, which I imagine is about the lowest priority system there is here. :)

The theoretical maximum update rate is around 33Hz but I'll test that. Slightly worried about bricking the instrument cluster here too, so I won't push it quite that far.