6A1/6A2

[Karlis]

Ok, I got it figured out. The problem was that I wasn't looking only at the bottom half of byte 3. I was looking at the whole byte thus my case was never true. Now my code seems to handle 6A1 messages and replies with a series of four.

[Seth]

So just wanted to throw this into the mix. I tried Karlis' latest software (Jan 2016), and my module was NOT recognized by the car. He told me to comment out the section where the module would respond to 6A1 messages, and now my car can see the module fine.

So something in the 6A1 (more likely, the 6A2) message(s), kill the ability for a 9-3 to recognize the "cd changer".

Really weird...There almost needs to be a way to have the module know what kind of car it's installed in, and if its a 9-5, send 6A2 messages. if it's a 9-3, don't send 6A2 messages.

I think this could be done by looking at the VIN (Tomi has a way), and using that as our filter. It would only need to be done at power up; maybe read the VIN, determine the model, and set a (volatile?) flag...or even set a boolean flag that doesn't get changed unless the VIN changes (moving module to a new car, etc)...?

[leva3000]

I had airbag error on dashboard every 10 seconds on my Saab 9-5 '04 with the last code. A short trip turned into hell :) Karlis, can you take a look or suggest how to fix the problem?

[Karlis]

You should revert the CDC.cpp file back to the one posted here and give it a try.

Basically this will replace the 6A2 reply to 6A1 with just one message instead of one. This was the original implementation of the code that apparently has worked for a couple of years.

[leva3000]

With reverted CAN.cpp all works as expected without airbag errors. Do I wait for problems with MPG calculation on my Saab 9-5 with this code?

[Karlis]

Well we will need to figure out why the airbag indicator came up on your SAAB in the first place. I have a '01 car and even with the MPG fix I have never seen this problem. So there have to be some differences in how the car treats the responses. For now you'll have to stick with DTE values bug if you want to use the module till we resolve the issue.

[Ziq]

I got the airbag warning as well when I integrated the new response. I haven't seen any problems with DTE so I think I will leave it as it is.

[leva3000]

It looks like everything is ok with DTE/MPG calculation for me too with reverted CAN.cpp (Saab 9-5 '04)

[Sandwer]

Karlis,
There are different airbag triggers between an 01 and an 03 onwards in the 9-5 - there's an extra sensor on the driver seat rails from 03 onwards (which makes seat swapping...interesting).  So is it possible that the entire monitoring algorithm changed '03 onwards and we are only seeing the evidence by this trial and error that we are doing?

Have you got a way of grabbing the vehicle ID number from anywhere? TWICE/DICE, maybe?  I know how to pull the VIN string apart if it is any help....

Rich

[Karlis]

I believe that this is not related to an extra sensor. I think this has something to do with the "diagnostic" comms cause, for instance, when a Tech2 tool is connected to the car, ABS, SRS and the "magic triangle" come up. So my guess is that for some reason we're triggering comms with SRS control module. Just a wild guess...

It should be possible to pull VIN from the car. I think I even saw some code on Tomi's site. I can look into it. Decoding is the easy bit. :)

[Ziq]

The serial part of the VIN (last six digits) is in 4A0h.

If you want the full VIN it looks like you have to do a Trionic data query.

[Karlis]

So, sitrep. I integrated a timer library in the code, that performs actions on timely base (uploaded to Github). Sort of asynchronous execution of the code. I've integrated it with the 3C8 message that needs to be sent no less than once every 1000ms and in replies to 6A1. Now every message (out of batch of four) is sent with a 100ms (or whatever is defined) interval. I believe the interval can be increased but I'm sticking to 100ms for now, just to avoid some mess ups.

I've tested this code on my '01 9-5 and it seems to be working. Not sure about DTE values yet, but will keep testing. As of now it is a total unknown how this would behave on other cars. If you feel like being ready for some adventures, give it a try :).

One thing I've noticed is that once IHU is pushed into CDC mode, the SID goes out within first five or so seconds taking steering wheel controls with it. Everything else works. Mind you, this only happens with the engine off. I've seen this happening before so am not quite sure wether this is related to the latest code changes. I believe this is due to the fact that SID is not happy with what IHU is currently sending to it, which is "CD1 PLAY" message that lacks additional info (disc number, 'mm:ss' info, etc). Just a wild guess.

[Karlis]

After a number of tests I've determined that the interval between messages being sent back to IHU on 6A1 request should be 140ms. When this interval is used, it seems that SID is also happy and doesn't go out while the ignition is off.

[mcaldwelva]

I'm still surprised at the differences in behavior between our Viggens. The 4x 6A2 messages have been okay for me since I added the code back in November.

I think there's one other thing that should probably be in there... there's only three send buffers, so if we don't wrap the send call in a while loop, there's a good chance that we're not sending out all four messages e.g.

   while (CAN.send(&CAN_TxMsg) == 0xff);

Although the timing code that Karlis added should also take care of it.

[mcaldwelva]

A few more things I've noticed about the 6a1 message:

I see the 3/"power on" message each time the CDC is selected.

I see the 2/"active" message repeated every second while the CDC is active.

I only see the 8/"power off" message if the CDC was selected when the car was turned off.

[Karlis]

So what would be a "typical" reply to 6A1? As in the whole "conversation"? Currently the code looks at the bottom half of the 3rd byte of 6A1 to determine what the reply should be like. Then it sends a reply of four messages with 140ms interval each.

[Karlis]

So, another sitrep: I found a couple of issues with the 'fantastic four' frames that need to be sent back to 6A1 requests and fixed them. From what I see now on the output all four frames are being sent within exactly 140ms (yeah, I still believe this is the right timing) from each other. CDC also reports its status frequently with 1000ms intervals.

On my 9-5 I'm seeing only 'active' requests. No 'power up/down'. I believe that is because we constantly tell the IHU with 3C8 frame that the CDC is married to the car, it is active and is playing a disk. So IHU assumes CDC can't be in any other state.

I've checked in the code on Github. If anyone wants to give it a try, you are welcome! Any feedback would be appreciated.

[mcaldwelva]

I think I'm seeing that as well. I don't think we'll get a 6a1 power-up request if we're already telling it we're powered-on via 3c8 status.

Here's a couple other things I've picked up from logging... It looks like we receive a 6a1 message every 1.3 seconds while the CDC is active. And very rarely (about 1 in 500), I see one of these messages instead of the normal "active" message:

21 00 00 92 01 02 44 00
61 00 00 32 00 00 00 00

Still don't know what they mean, but I treat them like the normal active message (based on the lower nibble of byte 3).

[mcaldwelva]

After reviewing more log data, I'm seeing 6a1 messages 1080ms apart when a proper 6a2 sequence is sent. I only see 1300ms in cases where the proper 4 message sequence wasn't sent. So it looks like the system is trying to give the CDC a little more time to respond. I imagine this is related to the MPG issue we noted earlier although I don't see that any other message times are affected.

[Karlis]

Thanks for the update! I've been using the code with timing (reply with a set of four frames every time a '6A1' comes in) for quite a while now. All four replies go out with an interval of 140ms. I suspect nodes on the bus are not happy with someone sending frames more frequently than 50ms. And anything beyond 140ms also seemed to break things. MPG and AVG values are fine (even after longer trips with multiple fill ups).