Custom CDC to SID text

[Da Bear]

Thank you! :)

Yes I will do that. Maybe you can help me with that through email. I have made a github account but only "forked" version 2.1. No idea how to work from there.

I'm gonna update my module to accept the latest software (3.0? I'm still using 2.1 ) and clean up my code (I have 973 lines in CDC.cpp vs yours 402 lines ).

[Da Bear]

Some bad news.
My "crap"top crashed during a windows update and I lost the working code before I had a chance to backup it (I thought I did, but not), and I have not been able to re-produce it.

But I have some new ideas I'm gonna try. Stay tuned!

[mcaldwelva]

The flickering problem is due to the CAN library. It's filling the TX buffers in the wrong order, so if the bus is busy the messages will be transmitted in the wrong order.

[Karlis]

[Karlis]

So I think I've made some progress.

Here are my findings.

In order for a node to write on SID, it "has" to ask for a grant from SID to access a certain resource (0-both rows of SID, 1-top row, 2-bottom row).
This is achieved by sending a display resource request frame, which looks something like this:

<node ID> : NODE_APL_ADR,0x02,0x01,NODE_SID_FUNCTION_ID,0x00,0x00,0x00,0x00

Only four bytes. 0x02 means the requested object on SID (bottom row in this case). 0x01 means what type of message does the node want to write on SID. For now I'm assuming that 0x01 means "Test" and 0x05 means "Static text".

So the frame mentioned above would translate in "hey, I would like to write a test message on bottom row of the SID". If we want to write on SID, we have to ask for a grant, but no more frequently than every 1000ms. We may not start writing on SID if we haven't received a grant. Doing so will make all the nodes on the bus unhappy.

Once SID is happy and gives us a grant, the frame itself would look something like this:

0x368 : 0x02,NODE_SID_FUNCTION_ID,0x00,0x00,0x00,0x00,0x00,0x00,0x00

This literally means "go ahead, node with function ID x, you have been given grant to write on object (row) 2 of SID"

Then the node interested in writing to SID sends a group of three frames with ~35ms interval. This would look something like this:

<node->SID control ID> : 0x42,0x96,0x02,ASCII[0],ASCII[1],ASCII[2],ASCII[3],ASCII[4]
<node->SID control ID> : 0x01,0x96,0x02,ASCII[5],ASCII[6],ASCII[7],ASCII[8],ASCII[9]
<node->SID control ID> : 0x00,0x96,0x02,ASCII[10],ASCII[11],ASCII[12],ASCII[13],ASCII[14]

Bytes 0x42, 0x01 and 0x00 represent the frame sequence
Byte 0x96 is the address of SID
Byte 0x02 means that the frame has been sent on basetime (every 1000ms). If this byte is 0x82, that means that the particular frame has been sent on an event (text on SID has changed) and the whole basetime timing after this needs to be reset.

ASCII chars...the actual message.

Now here's the tricky part

SID can only show 12 characters on each row, but we need to send 15 to form a proper group of frames. So before sending the actual text, it needs to be "stripped" (zeroed out) of anything that's exceeding 12 chars. If this is not done, SID will be unhappy... :)

I may be wrong in some assumptions, but so far using these ideas I have been able to have custom SID text displayed without any flickering.

[homerisback]

Seems to be close beat the SID text reluctancy :)
I keep following those new experiments but a little less frequently, moving in my new house takes so much time !

[Karlis]

Ok, folks! I think we finally have a breakthrough!

TL:DR - IHU->SID text can be altered!

Long version

Up until now we thought that custom SID text control can be achieved only by suppressing IHU->SID write access (CD1 PLAY) with a help of changing priorities of messages or sending custom text to SID on behalf of some other node on the bus (commonly SPA was used for this). This is one way of doing things and it works...sort of... SPA->SID text control works great, but only if you don't have an actual SPA installed on your car.

So I did some thinking for a couple of days and remembered of "TELEPHONE" message being displayed on SID. Originally SAAB had an optional hands free system package for mobile phones that could be installed and when activated, would mute whatever sound was coming through audio system and would activate mobile phone. On US market cars there was also a GM system called "OnStar" that was installed on all cars by default. The basic idea is that you pay an annual fee and if you ever get in an accident or in trouble, press a button on the dash and Bruce Willis will come to rescue you in a helicopter gunship!

Since 2008, "OnStar" system has gone digital rendering all of these systems on OG SAABs in US useless. And I haven't heard of anyone in EU using the hands free optional package "per design". Not talking about the hacks people do to get an Aux-In...

Anyway...

I started thinking about which node and how sends that "TELEPHONE" text to SID? How??? And who??? And HOW (not IF) we can use that to our benefit?

Turns out...*drums rolling*...it's our good old friend IHU!!!

Yeah! I know... I was also like:



So I started to dig deeper and sniff CAN comms. And here's what I found:

*) IHU->SID text can be altered (not quite sure yet how, but it works)
*) There's clever timing in the sequence of CAN comms that basically tells SID that IHU won't display "CD1 PLAY" (or whatever) now and from now on will display "TELEPHONE" (or whatever).

Here's an output from CAN capture I got today with some comments.

*) I separated the groups of frames with an empty line.
*) Numbers under each frame represent time in milliseconds since the last frame that we are interested in was intercepted.
*) As we know, SID expects three CAN frames from a node that writes something on display
*) 1st byte (0x42, 0x01 and 0x00) is the sequence number of the frame in the group
*) 2nd byte - 0x96 is the "address" of the SID

SAAB CAN Sniffer v1.0 - September 2016

328 Rx-> 42 96 2 46 4D 31 20 20
949                
328 Rx-> 1 96 2 20 39 A6 35 30 // Group of three frames sent from IHU to SID on basetime (which should be 1000ms). Displaying “FM 96.50”
8                
328 Rx-> 0 96 2 20 1 0 0 0        
30              

328 Rx-> 42 96 2 46 4D 31 20 20        
950                
328 Rx-> 1 96 2 20 39 A6 35 30 // Group of three frames sent from IHU to SID on basetime (which should be 1000ms). Displaying “FM 96.50”
8                
328 Rx-> 0 96 2 20 1 0 0 0        
30              

328 Rx-> 42 96 82 20 20 20 20 20        // “OnStar” button/Telephone mode enabled. SID still grants IHU access to 2nd row, BUT mind the 2nd byte in the frame.
81                
328 Rx-> 1 96 82 20 20 20 20 20 // 0x82 definitely means “there’s a new event we need to react to; let’s “space out” everything out on the 2nd row of the SID!”
7                
328 Rx-> 0 96 82 20 20 0 0 0        // Still “spacing” out. Note that there are 12 x 0x20 bytes. 12 = length of SID row.
32                

328 Rx-> 42 96 2 20 20 20 20 20
822                
328 Rx-> 1 96 2 20 20 20 20 20 // “Spacing out” again, BUT now doing that on basetime (which again should be 1000ms). Notice the 2nd byte now.
8                
328 Rx-> 0 96 2 20 20 0 0 0        
32              

328 Rx-> 42 96 82 54 45 4C 45 50        
770              
328 Rx-> 1 96 82 48 4F 4E 45 20       // Sending the new text to SID as an event. Hence the 2nd byte = 0x82. Displaying “TELEPHONE”
8              
328 Rx-> 0 96 82 20 20 0 0 0      
31              

328 Rx-> 42 96 2 54 45 4C 45 50      
131              
328 Rx-> 1 96 2 48 4F 4E 45 20       // Group of three frames sent from IHU to SID on basetime (which should be 1000ms). Displaying “TELEPHONE”
6              
328 Rx-> 0 96 2 20 20 0 0 0      
31

So it looks like we could try and mimic these comms to our benefit and hope this works. I mean we could try, right?

[homerisback]

Nice, the end of the tunnel is not far anymore !
I've been far from here for one month (new job inside) and I'm amazed to see the steps achieved by this fabulous project

BlueSAAB makes its path and at least one folk asked me for one. Seems my soldering iron will soon get warm again...

[Da Bear]

Karlis wrote

And I haven't heard of anyone in EU using the hands free optional package "per design".

I do!  In both cars. ;)

[Karlis]

Oh, ok. So we'll have to make a special case in the code and mark in the comments: "This is for Da Bear"

[Da Bear]

  We'll have to work harder on the hands-free in BlueSAAB

Btw, rebuilt the AS1 in my SE today to AUX. Tapped into the CD player and built a pre-amp and burned a 80min silent CD. Works great.
Wish the SID would display AUX instead of CD PLAY though

[sbt]

Karlis wrote

And I haven't heard of anyone in EU using the hands free optional package "per design".

I'll just add to Da Bear's comment; I'm not in EU, but have a working hands free package in my 9-3 in Australia (it's even Bluetooth!). I believe there's more similarity between AU cars and EU ones than US, since we drive RHDs like UK.

So, please include this option. I don't have SPA, so that alternative would work fine for me. I guess a switch between SPA/Tel in the code would be cool. Could the CAN software detect which kind of car based on messages sent to the SID?

[Karlis]

If this works, it will work within the boundaries of one single node - IHU. Now BlueSaab acting as another node on the bus and "highjacking" other nodes' controls might be an issue. Anyway, I'm more inclined to go the IHU route so we don't mess up the functionality of other nodes (SPA). There's another way to get the messages to SID and that's is by using Trionic -> SID text control. This is heavily used in OpenSID project, BUT, it's a total unknown (as of now) how it would behave in cases when other nodes or driver would need a "breakthrough" access (light bulb went out, low coolant fluid level, etc.) access to SID.

[Da Bear]

I think the OpenSID route is more or less pointless. I did try that but OpenSID is flooding the SID with information, nothing else gets through unfortunately.

I'm so mad I lost my code that actually worked quite well.

Edit,
OpenSID text is 0x33F and control is 0x358 if my memory is right.

[Karlis]

On contrary - I believe OpenSID (Trionic7 -> SID) text control is the way to go. From what I've seen, if OpenSID is not "engaged" it won't send any information to SID. So we would just hijack display resource request/write text to display frames and use those. :)

[sbt]

Karlis wrote

Any ideas are welcomed. :)

I've opened an issue on the SAAB-CDC repo for discussion of some of the questions as you're closing in on getting the basic writing text to the SID function up and running.

See https://github.com/kveilands/SAAB-CDC/issues/17

Everyone's welcome to chime in...

Cheers,
Sam.

[Karlis]

Alright, folks! Long story short - custom SID text control is finally working. A couple of observations:

   - OpenSID uses ECU->SID text control feature and "Engineering test" type of messages, hence it always gets SID access, but no other message type can break through. So, if you have a light bulb failure or low coolant fluid level, ECU won't be able to break through with it's "Emergency" type of message.
   - IHU is a pretty stubborn node that keeps sending out display update requests on every button press event
   - SID has a "whitelist" of nodes it accepts display resource requests from
   - It's all about timing...

[saab95]

Excellent!

[Timpa]

Hi
How is the new working code looks like ?
Is it implemented in the 4.1 version ?
I'm trying to send some messages to SID and having problem with that.

/Timpa

[Karlis]

The code that handles custom text to SID is checked in and available on Github. The main portions of the code you would be interested in are in SidResource class and 'handleRxFrame()' method of CDC class.