Custom CDC to SID text

[Timpa]

Thanks, if  I understand it correct
You send a request from "SPA" to SID 0x357 (0x1F=request,0x02=row2, byte3 priority?)
and get a okay from SID 0x368 (byte 0=0x02(row2) and byte 1=0x12(SPA)).
Then you send 3 lines with Text to SID from "SPA" 0x337.
Hope I have get the principle right

Have you tried to use ACC instead of SPA ? ACC only uses SID when you make
some changes or calibrate.

/Timpa

[Karlis]

Timpa wrote

Thanks, if  I understand it correct
You send a request from "SPA" to SID 0x357 (0x1F=request,0x02=row2, byte3 priority?)

Yes: 0x1F=requesting node ID (SPA), 0x02=row2, byte3=message type (0x03=driver action)

Timpa wrote

and get a okay from SID 0x368 (byte 0=0x02(row2) and byte 1=0x12(SPA)).

Correct...

Timpa wrote

Then you send 3 lines with Text to SID from "SPA" 0x337.

Yes. These three frames include message sequence, type (sent on an event or basetime), address of the SID and 5 x bytes of an actual text. Note that everything larger than 12 chars of the text will be zeroed out as that's all SID can display on a single line.

Timpa wrote

Hope I have get the principle right

Yes, you got the idea right.

Timpa wrote

Have you tried to use ACC instead of SPA ? ACC only uses SID when you make
some changes or calibrate.

This can be done on behalf of any node on the car. The trick is to find and pick one that's not installed. The thing is that when a node is not interested in writing on SID, it has to send out a specific frame telling so. Then, when node is interested in writing on the SID, it starts asking for a grant to write. The SID then decides who and when can write. So even if ACC is used, you could, theoretically, send a request to write, but then the "Actual" ACC will also push out a frame saying that it doesn't want to write. So SID will be confused receiving two frames, supposedly from the same node with confusing requests. This can lead to all sorts of problems. From flickering text to SID going dark and the need to pull the fuse...

On my and Seth's car there's no SPA, so we have all the necessary means to pretend to be one and everyone else on the bus are happy as our requests/text sending don't interfere with anything else.

Good luck!

[Ziq]

Just a note here, my IHU (nav unit)  sends a message that it does not want to display anything every second. Upon seeing this message I immediately send a message pretending to be the same node but that i want to send something. I am then granted write permission and can write what I want. I have a short flicker once every five minutes or so but that I contribute to slow response of my microcontroller due to the lack of a interrupt implementation. If the ACC acts the same as my IHU i imagane it's free to highjack that empty space as well. It's been working fine for me fir18 months now... 

/Petter 

Den 18 aug. 2017 18:51 skrev "Karlis [via BlueSaab Forum]" <[hidden email]>:

Timpa wrote

Thanks, if  I understand it correct
You send a request from "SPA" to SID 0x357 (0x1F=request,0x02=row2, byte3 priority?)

Yes: 0x1F=requesting node ID (SPA), 0x02=row2, byte3=message type (0x03=driver action)

Timpa wrote

and get a okay from SID 0x368 (byte 0=0x02(row2) and byte 1=0x12(SPA)).

Correct...

Timpa wrote

Then you send 3 lines with Text to SID from "SPA" 0x337.

Yes. These three frames include message sequence, type (sent on an event or basetime), address of the SID and 5 x bytes of an actual text. Note that everything larger than 12 chars of the text will be zeroed out as that's all SID can display on a single line.

Timpa wrote

Hope I have get the principle right

Yes, you got the idea right.

Timpa wrote

Have you tried to use ACC instead of SPA ? ACC only uses SID when you make
some changes or calibrate.

This can be done on behalf of any node on the car. The trick is to find and pick one that's not installed. The thing is that when a node is not interested in writing on SID, it has to send out a specific frame telling so. Then, when node is interested in writing on the SID, it starts asking for a grant to write. The SID then decides who and when can write. So even if ACC is used, you could, theoretically, send a request to write, but then the "Actual" ACC will also push out a frame saying that it doesn't want to write. So SID will be confused receiving two frames, supposedly from the same node with confusing requests. This can lead to all sorts of problems. From flickering text to SID going dark and the need to pull the fuse...

On my and Seth's car there's no SPA, so we have all the necessary means to pretend to be one and everyone else on the bus are happy as our requests/text sending don't interfere with anything else.

Good luck!

---

If you reply to this email, your message will be added to the discussion below:

http://bluesaab-forum.2349123.n4.nabble.com/Custom-CDC-to-SID-text-tp90p1184.html

To unsubscribe from Custom CDC to SID text, click here.
NAML

[Karlis]

Thanks for the update, Petter!

Yes, from what I've seen this works fine(-ish) on IHU's with Navigation. The problem I've seen with this approach on my non-Navi IHU is that for every "driver action" (0x03), IHU briefly takes over SID no matter what gets displayed on it, because, of course, it has to show that there's been a switch to the next track/CD. So the flickering is more frequent. One way to suppress this is by using 0x01 (Engineering Test) as request type, but that prevents anything else (even ECU and "broken" light bulb messages) to get through when a need comes.

Also, even though SPA and ACC are nodes of "higher" priority (their frames always win CAN bus arbitration), that doesn't mean that they can push through when they need to. Meaning:

If SPA/ACC gets access to SID, IHU (even with lower possibility to win CAN arbitration), goes like "hey, I know I'm of lesser importance here at the moment, but I have this text I need to display because it came as a result of a driver action". So SID then gives grant to IHU.

Hope this is not too confusing...

[Timpa]

Is it still a issue with the Night Panel ?
Could a solution be that you check 410 byte5 and when night panel is active
you then stop sending/requesting SID text or something clever.

[Karlis]

I think there's no need to over-complicate things. For now, the whole idea is that BlueSaab=SPA (with regards to SID text control). When BlueSaab is engaged, it requests SID resource access on behalf of SPA. IHU still tries to push through its requests on driver action (button press/track change), but we detect that and start sending our own display requests with "driver action" byte set till IHU "calms down" and then we fall back to "static text" type of text which allows all the other nodes (including Night Panel feature) to take over SID if/when needed.

This whole thing also is needed, because IHU display resource request frame ID is of grater "priority" than SPA request ID, so IHU will always win the arbitration on the bus.

[Timpa]

Tada ! But with some issues:
Can't write to the area after SAAB and
when I tried row2 I only could write to the first 5 bytes.
I't could be me and my software probably..
and I have some timing issues also.
(I try to clean it up and show it on my blog.)

[Karlis]

Nice work!

You might want to be careful though with writing to the 2nd row in this case. As seen, 2nd row is already "occupied" and I'm 99.99% sure that the current requester for SID access in this case is ECU. So anything you want to write on 2nd row will interfere with frames sent by ECU. I don't *think* it can break something, but I'm almost sure it won't make ECU happy.

[Timpa]

Now I have made a software to read the Time from SID and then send it to SID when I
push the CLR button on the steeringwheel.
http://saab9000vector.blogspot.se/2017/08/tidsvisning-pa-siden.html
and the crappy software
 http://saab9000vector.blogspot.se/2017/08/tidsvisning-pa-siden-arduino-program.html
The trouble I have is that I can't set the Time because I don't have the stereo.
I've tried to send it with 720 but SID don't buy it.....
Is there any one that can sniff the 720 lines ?
I've got this information that it works (for some lucky ones). UKSaab

/Timpa

[Da Bear]

Long time no see!

I have not been following this for a while since I have rebuilt my Aero and don't know how much progress have been made since I've not been active online at all the past year.

But I have been thinking of the 'mute' button on the AS1 stereo in the SE I currently drive. Have anyone sniff'ed that node?
In my opinion it's much less used than SPA and TEL (Both which I my self use) and should be more suitable for our needs.

[mcaldwelva]

Been a while since I've checked in too. The Mute button isn't its own node unfortunately. If I recall correctly, it's just another audio text (328) message and results in CDC commands (3c0) when it's turned on & off.

I do wonder about OpenSID (338) and Trionic7 (33f) though. On my 9-3, I only see OpenSID on the bus. I'm wondering if Trionic7 might be specific to the 9-5? If that's the case, we'd have an unused id for each model type.

[Karlis]

mcaldwelva is right. Mute button is an "internal business" of IHU.

0x33F is a message that writes text to SID on behalf of Trionic7. From what I've seen during the testing is that OpenSID requests access to SID with "Eng test" text type, which is of top priority for SID, so it ignores everyone else but text coming from Trionic7. That's also why when OpenSID is engaged, no other text rather than OpenSID stuff can be seen on SID.

[mcaldwelva]

My apologies. I had the wrong id there. Someone identified 338 as the Trionic7 text id and 356 as the Trionic7 control id. I haven't seen either of these ID's on my 9-3's bus.

Have you seen 358 & 33f on the 9-5?

[Karlis]

No worries. :) Yep, 0x358 is display resource request coming from Trionic7. Once it receives 0x368 (SID grant), it starts writing to SID using 0x33F. I'm seeing these on my 9-5.

[mcaldwelva]

So what uses the 356/338 id's?

[Karlis]

These are coming from ECU (Trionic7). As far as I know, they are used for all of the "TIME FOR SERVICE", "WASHER FLUID LOW" and what not messages.

[Weby]

I wonder if anyone knows where the "keys : X, transponders : Y" messages comes from, when you press the boot open button on the key just after inserting it in the ignition.

It would make sense that it comes from Trionic, but could it at all be a separate (and perhaps usable) node?

I'm also wondering if it would be possible to spam the SID, like opensid does, but listen to other messages on the bus constantly, and stop the spam then. Would it be too hard to time correctly?

[Karlis]

Weby wrote

I wonder if anyone knows where the "keys : X, transponders : Y" messages comes from, when you press the boot open button on the key just after inserting it in the ignition.

It would make sense that it comes from Trionic, but could it at all be a separate (and perhaps usable) node?

This message comes from TWICE

Weby wrote

I'm also wondering if it would be possible to spam the SID, like opensid does, but listen to other messages on the bus constantly, and stop the spam then. Would it be too hard to time correctly?

This should be doable. In this case BlueSaab firmware needs to constantly monitor SID resource requests coming from other nodes and if there's a request of certain type (driver action breakthrough, emergency, etc.) then BlueSaab should step back and wait for that process to finish.

I'm working on a POC for this to see if this theory actually works.