[Android Head-Units] ulysse31_revient:
Hi again,

After reading the latest dump (dump with the original screen connected), I saw some message sequences that were similar to my opening and closing screen via idrive, those sequences are starting with 0x04f3 as CAN ID message.

Googling a little with 'BMW "0x4f3" gave me a surprising result ^^ :

https://www.m5board.com/vbulletin/e...t-e60-can-bus-code-hacking-3.html#post7043761

This guy is my saviour, he gives a complete (at least it seems) list of all can message ID for BMW ... and there is 3 CAN IDs that seems to match up my believes :

CAN_ID_HEX	CAN_ID_NAME	CAN_ID_NAME (Translated)	DIAG_ID_HEX	SG_NAME

0x33A	Status Monitor Front [3]	Status Monitor Front [3]	0x73	CID_C_H/CID_C

0x4F3	Netzwerkmanagement	Network management	0x73	CID_C/CID_C_H

0x5F3	Dienste	services	0x73	CID_C/CID_C_H

Those are related to the CID !

And I can confirm on my last dump, I see regular message from 0x033A :

0x033a 数据帧 标准帧 0x05 0x28 0x42 0x81 0x4d 0x7f

0x033a 数据帧 标准帧 0x05 0x28 0x42 0x81 0x4d 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x42 0x81 0x4d 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x42 0x81 0x4d 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x42 0x81 0x4d 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x42 0x81 0x4d 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x42 0x81 0x4d 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x42 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

0x033a 数据帧 标准帧 0x05 0x30 0x82 0x81 0x0a 0x7f

[...]

So screen sends status (0x033a) periodically to CCC that it is available, I do not know exactly for now the meaning of the different values, if those message IDs are not sent, CCC will assume that screen is NOT available, and will simply not interpret idrive messages.

Then, screen sends also 0x04f3, which I believe is linked to the action of closing and opening the screen, it generates a lot of packets, so won't list them all. but here is a portion :

0x04f3 数据帧 标准帧 0x08 0x78 0x02 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x42 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x73 0x01 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x01 0xff 0xff 0xff 0xff 0xff 0xff

0x04f3 数据帧 标准帧 0x08 0x78 0x02 0xff 0xff 0xff 0xff 0xff 0xff

[...]

These are of course spread in the file, I just "grep" them to get only 0x04f3. This 0x04f3 seems also cyclic, I suppose by looking at the cycles that it could be something like :

- sending "0x78 0x42" is when "displaying"

- sending "0x73 0x01" when "closing"

- sending "0x78 0x01" when "closed"

- sending "0x78 0x02" when "opening"

But for now those are suppositions.

Back to my problem with the HU :

If (which I'm being more and more sure about it) the CCC wants the screen to be open and alive to interpret the idrive knob moves on the interface, "programming" the module won't help : CCC will want both "available" status messages (0x033a) but also "mode set" (displaying, closed: 0x04f3). Telling the system that the screen is alway open will only suppress the need for 0x04f3, but not 0x033a. So doubting that it would really solve the problem of using the OEM menu on android screen.

For now, I see 2 possibilities :

1- modify the MCU on the android HU to send good status regularly (displaying and state) : this needs the source code of the MCU, which I do not have (at least for now), I know that there is some people on f30 (thanks __fred__ ^^' ) that are working on decompiling it to generate C code out of it (private joke "I am getting to old for those kind of stuff" ... ^^' ).

2- build a little can device, with an arduino nano and a MCP2515 for example, that would be connected to the original canbus pin head of the OEM screen (not used with the android HU), and would "simulate" the CID good status on the can bus.

That's all for today for me ^^

--

Ulysse31