yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] ulysse31_revient:
I need also to dig on your grounding in lvds, maybe if screen motor (or entire screen) is not detected, it does not read the incoming message from idrive ? I will dig on this possibility once I have check the one I'm onto right now :

I have found some other stuffs about the possibility of the can bus signal not being send out correctly :

- on another forum, a user posted the photo of its MCU on his head unit, when I saw the photo, something jump to my eyes (since I just looked to mine this morning), here is the photo he posted :

And here is mine :

It seems mine DOES NOT have the chips on U7 and U8 ...

The MCU used is a STM32F105RB, this MCU as 2 embedded CAN controllers, a CAN controller sends signal to the can bus via RX and TX pins, but THEY DO NOT SEND SIGNAL DIRECTLY, a can controller is generally used in combination with a CAN transceiver, on the photo the guy posted (thanks dice66), we can see those 2 CAN transceivers and read on them NXP TJXXXX2, we cannot read entirely because chips are usually scrapped by chinese manufacturer ... BUT ! digging with google I came to the assumption that it may certainly be a NXP TJA1042 ^^'

Digging more on internet about can bus protocol, made me read that a CAN controller MAY send/receive signals directly without transceivers, but they will be exposed to high noise, and will see their signal range reduced to a single meter max.

I suppose that without this chip, signal strength can be severely reduced, and thus signal from idrive might be received by android HU, but not correctly resend because of the lack of these chips ?

If the original screen is connected, maybe more strength for the MCU to resend since video signal is not being managed by the android HU ?

So I made the following assumption : their are lot of different 10.25 HU unit clones, would some of them try to reduce cost by removing those kind of chips ?

Have some people checked inside their HU and see if they have those chips ?

(HINT: the MCU is on the back of the motherboard).

Regards,

--

Ulysse31
[Android Head-Units] ErikE87:
Thanks for your explanation! Makes sense! I can confirm that having the screen motor attached does not make a difference. When i connect the original screen and change only the lvds cable (so screen motor cable is connected) it still doesn't work. Could it be that the screen actually has logic in it? So the can signal is send over the lvds cable?? and the screen interprets it? Seems weird to be honest... I tried to open my original screen to measure the original lvds cable and the android HU one but i don't know how to open it and am afraid to brake it since it is my only way to work on the original interface at the moment.
[Android Head-Units] ulysse31_revient:
Hi,

From what you explain here, I'm thinking several tests that could be done :

- Checking that motor is really NOT needed : leave the original screen connected (no parts from android HU), but motor disconnected, try with the original screen open if it shows menu, and if you can interact with the idrive.

- Checking if outer metal cable as an interest : for this point 2 sequential tests :

* with the original screen connected and key car in (BMW menu on screen), mesure with a multimeter in volt if their is a difference between the outer shell of the cable (take one test head of multimeter on the back of the CCC controller for example), and the ground of the vehicule (the black wires on the big power connector of the CCC controller on its back) if you see a voltage (check first range 0-20V, then mV if 0 !). if you see a voltage, then it means that it is used for sending a signal. if not, well, it means outer shell is useless.

* if their was a result on last test, connect the new android HU screen completely (Y connector, screen cable, etc ...), and a 1 meter wire, connect one side of the wire to the outer shell of the screen connector on the back of the CCC controller and the other side to the other side of the android lvds screen connector (from my remembering, there is a metal part in its outer shell).

Test those and keep me in touch.

UPDATE: TIP for the original screen : when powered off (motor disconnected), you can open or close the original screen without forcing (do not forget to remove the screen BEHIND the screen when screen is opened, because those screw may block the opening or closing is not taken out).

--

Ulysse31
[Android Head-Units] ErikE87:
Hi! In red my findings.. it is weird. It doesn't seem the outer metal part does anything and the motor cable isn't needed. After the tests i found this online: https://www.newtis.info/tisv2/a/en/e60-m5-lim/repair-manuals/84-communication-systems/1puXMxl

It looks like besides the lvds cable another cable comes in with k-can signal? That is connected to the idrive control (nr 35 on the diagram). The only cable that is connected to to the CID besides the lvds is the motor cable... Will try my test again to validate.

Are we sure the lvds cable only provides the signal for the screen and not also some canbus signal??
[Android Head-Units] ulysse31_revient:
Hi again,

The only thing I am sure, is that can bus is, by definition, only one pair of cable (composed of wire CAN High and wire CAN Low), and all equipments are linked to this bus, the goal of can bus is to reduce cabling, so I doubt that the screen would send a can bus signal (which, would need 2 pins/wires), in addition to the can bus that is already connected to the CCC controller.

One other thing, have you noticed that when you reconnect the screen motor, your can "ear" can bus devices getting initialized (a little noise of different equipment, very particular ^^' i don't know how to describe it by writting ^^') (UPDATE: maybe the JBE initialisation ?) so yes, I think that the original screen (CID) is connected to can bus, but I would suppose by the motor wires (6pin/wire flat cable/connector).

But has you say that you can "navigate" the menu and change audio input while motor cable is disconnected, I suppose that even if it has can connection, it is not mandatory for menu interaction with idrive.

Anyways, this schema is really interresting, thanks for sharing it ^^.

--

Ulysse31
[Android Head-Units] ErikE87:
Ok retried the test where i had the lvds and motor power cable connected to the original screen and disconnected the lvds cable to see if i can still control the ccc system on the (darked out) original screen. Spoilers: really interesting findings, here it goes:

1. When i have the lvds and motor power cable connected to the original unit everything works as in this video: https://www.youtube.com/watch?v=E7b7ipcs6Hk

2. when i disconnect the lvds cable but leave the motor power cable connected at first i could not control the ccc system with idrive controller anymore.

3. BUT BUT BUT, when i connected the lvds cable and quickly tried the idrive control i could switch from aux to FM (remembered what to do since the screen was black) a few seconds later i was not able to control it anymore!

4. to verify these results at last i disconnected the lvds cable (original) and really quickly connected the android HU lvds cable and quess what! I was able to control the original idrive menu on the android HU for only 1 second (one twist on the idrive controller).

I don't know that much about electronics but to me this really looks like a ground thing... for a few seconds it holds it or something and than loses it and you cannot control the original screen with the idrive controller anymore... Could it than just be that the ground (metal outer part) of the lvds connector on the radio unit needs to be connected to a ground or something? Is the motor cable acting as a ground??

I think we are on to something but don't know exactly how to proceed now.. any ideas?
[Android Head-Units] ulysse31_revient:
Sorry if you already tried this but :

- if you connect a wire to the outer of the lvds connector on the CCC (it is metallic), and that you connect the other side of the wire to the outer of the lvds connector of the android (which is plastic, but one side has a metallic shield), what does it gives ?
[Android Head-Units] ErikE87:
Hi! Already tried this and didn't work. Did some more tests and it is very interesting. Besides my previous tests i did the following now:

1. start with original screen (motor power cable and lvds) connected. --> everything works on the original screen (as in the video i posted earlier.

2. When i disconnect the motor power cable it still works: https://www.youtube.com/watch?v=MtYQFO_f6n0

3. But when i then pull out the lvds cable and reconnect it or pull out the key (ccc off and android HU off) and then start again the idrive control doesn't work.

So after all these tests we have the following results:

1. It seems that the lvds cable needs te be connected to be able to let it work (or really shortly after disconnecting it, it works for a couple of seconds)

2. when the motor cable is disconnect while the ccc system works it keeps working

3. when the motor cable is disconnected when starting or when you disconnect the lvds cable and reconnect it again the ccc system doesn't work anymore.

No idea yet what this means but it seems somehow that the motor cable needs to be connected when the power is put on the system. Just thinking out loud: could it be that the car (based on the motor power cable) detects that the screen is open (what it does during startup) and that the metal outer part is needed on the lvds cable? This would explain the above if i'm not making a mistake.

My next test tomorrow will be to solder the outer metal part of the radio to the android HU metal part of the lvds connector and starting with the motor power cable so the screen opens during startup. If this works i think it will prove the above hypothesis.

If i am missing something or making a mistake please do tell! :D
[Android Head-Units] ulysse31_revient:
Crossing fingers ^^

Keep me in touch :p

Thanks a lot for your share
[Android Head-Units] ErikE87:
Ok was too curious. Tried it but doesn't work....

The original menu definitely doesn't work when the screen is closed:

It opens the screen first before you can go one. Disconnecting the motor power cable after it is closed results in no control over the original unit anymore. So it really looks like it knows from the motor power cable that it is open or not or a combination of the lvds and motor power cable.

Little bit out of ideas to test again.

[MENTION=9908479]ulysse31_revient[/MENTION]: you have an open unit right? Could you see where the metal part of the lvds connector on the android unit goes to?

Any other ideas to test?
[Android Head-Units] ulysse31_revient:
On the android HU, the lvds connector cable is one molded plastic cable, the plastic cable goes inside then to a flat connector on the motherboard, I need to re-open it and test with a multimeter to know which cable on the flat connector is the outside metallic part. Give me some time: this type of activity is not WAF (Wife Acceptance Factor) compatible ^^'
[Android Head-Units] ErikE87:
Hahaha can relate ?

I found a interesting video on YouTube where someone also says the car thinks the screen is closed and that you need to code your car. What do you think of this? Do you have coding experience?

[youtube]jl1U5RHgRbE[/youtube]
[Android Head-Units] ulysse31_revient:
Hmmm, I would say ... "maybe" ... but if true, leaving the motor connected and the android screen connected to lvds should work: unless it is a problem of "bad lvds cable + motor opening detection", and if true, when you test to solder the cable tomorrow, also try it with and without old screen motor connected ^^' ... just in case.

For the lvds cable on the android side, I have tested with a multimeter : it is cabled to the 5th cable (black rugged) on the flat connector to the motherboard (12 pin flat connector ... yes 12 ... don't ask me why ...)

I say black rugged, because there is another black wire on the connector, but thin like the others, this one (the fifth) is ticker and rough.

Cheers,

--

Ulysse31
[Android Head-Units] ErikE87:
Think you missed my comment but already tried the soldering to the metal outer part with motor connected. Both with motor and without motor attached it does not work. But because the original system also stops working after I disconnect the lvds cable might it be that the car also thinks the screen is off when the lvds connector is disconnected? Seems weird and some over engineering of the BMW team way back in 2006 but you never know. I cannot explain why the system doesn't work without the lvds cable otherwise.

Do you have experience with coding your car or know anyone who can?
[Android Head-Units] ulysse31_revient:
When you tried with the cable soldered, have you check the conductivity of it ? What I found strange is that if the outer shell was not important, why would the manufacturer of the android HU connect that to the motherboard ?

I've read about using NCS Expert with a ODB/K-CAN usb cable, from what I read, you need to download a set of files corresponding to your vehicule, the set contains the "configuration" (programming) of each modules on your car (so the set must match your car year and model, of course), once you have the files, you import them on NCSExpert and then you can upload them to the selected module, before uploading you need to set some variables like the VIN code of your car to be uploaded to the module : if a module does not have the same VIN code than the rest of the car, it may stop working. I suppose that in the variables, their is one for the flap screen like indicated on the youtube video comment.

Finding someone who can use NCSExpert would be simple : just find a third party garage (not bmw), that can repair BMW, they have people for doing those kind of things, since NCSExpert is used for updating vehicule modules, and to replace failed modules.
[Android Head-Units] ErikE87:
No did not check the conductivity.. can do that tonight. It's also strange to me but on pictures of older units i see the lvds cable also doesn't have a metal outer part and does are working fine i think (only can find threads about this with the ccc e87/e82 with foldable screen and android PX6 8.1 unit). I ask the guy that posted the youtube message if he could upload a video of it working and how to code it with NCS expert. Maybe someone on the f30 forum can help us with trying to code it?
[Android Head-Units] ulysse31_revient:
Hello all,

just posting this for those that would be interrested :

https://share.qclt.com/bmw资料/ICT/English/Participant_manual/mfp-tnu-e87-ikt_en.pdf

Can be useful ^^

From the different diagrams, it is clear that the CID (the display) IS connected to the CAN bus (K-CAN or body CAN bus). So, it may also be a "do I see the CID on the CAN network ?" from the CCC controller, that does not receive reply or life sign from it, and therefor decides to not take into account the idrive moves.

If it is the case :

- the lvds external ground linking won't change a thing.

- having motor cabled won't be enough (if screen circuitry power on the can module only if lvds cable connected / powered ... need to find a pinout of this cable and check if possible to power it without cabling it to CCC controller).

Just programing car modules might not be enough also ...
[Android Head-Units] ErikE87:
Interesting diagrams! Will study them... Would be useful to speak to a engineer that worked at BMW at the time of manufacturing.. I know someone that worked there at the time in it. Will ask him if he knows anything from CCC system in our cars.

---------- Post added at 08:17 PM ---------- Previous post was at 08:12 PM ----------

Do you have the business or professional system in your e87 btw?
[Android Head-Units] ulysse31_revient:
Yes indeed, interesting for its diagrams, even thought we cannot trust it 100% : it was released in April 2004, and from what I have read, e87 was released in September 2004, but since this document is a "participant documentation" it makes sense. But in fact it means that some slight modifications could have been made.

I have the navigation business, with the Harman controller (the second one listed on the factory setup on the android HU), and you ?
[Android Head-Units] ulysse31_revient:
Hi all,

I'm still searching over the original CID (Central Information Display: the original screen) working mechanism : I've seen a youtube video were a guy dismantle the motorized screen, from what we see in the video, the "motor connector" (because on the motor side), does not seem to be connected to the motor : the motor seems in fact connected to the motherboard inside the screen, and the cables coming from outside are connected to the motherboard.

Following the documentation found on last posts, the CID should be connected on the CAN bus. and this video comforts the idea on this side : there is 4 wires on that connector : one black, one red, one white and one green. The red and black are pretty obvious (vcc and ground, but still need to determine voltage), so I suspect the white and green to possibly be CAN_L and CAN_H.

I've tested having both screen connected with the original screen connected to the lvds of CCC, and it works : we can use the android in one side, and the OEM menu in the other side. I made a CAN data log at car ignition (putting the key inside, launching the screen) in order to get the can IDs, I supposed that doing so would give me on the dump new can IDs that I should not find on my previous dumps, since I now have the original screen connected, after dumping, came back home to compare, and find which IDs I do not have on my previous dumps.

And in fact, I've found new IDs ^^' but a bit too much IDs, here is a list of all new can IDs :

0x0172

0x01aa

0x0202

0x0205

0x021a

0x0228

0x023a

0x0242

0x0246

0x0252

0x02ce

0x02ee

0x02f0

0x02f7

0x0336

0x033a

0x0380

0x0388

0x0394

0x03d4

0x03d5

0x03d6

0x03d8

0x03d9

0x03dc

0x03dd

0x03df

0x04e2

0x04f3

0x0592

0x05a9

0x05e2

0x05e7

0x05f2

My "error" was that I forgot that on my last dumps, I did not have the "ignition" period, I have dumped after ignition. But one thing is sure, on those IDs, there is the CID somewhere ^^'

I started searching the net for a CAN ID database for BMW ... but clearly there is only a few, all IDs are not referenced, and the IDs may change depending on the car model for the same module type ...

I'll go back to the car tomorrow, and generate another full dump from ignition time, but with the original screen off in order to remove more non-CID-related IDs.

--

Ulysse31
[Android Head-Units] ErikE87:
Wow that are some nice findings! Great job! :D

To answer your earlier question i also have the business harman setup. So it seems we have the exact same.

Based on the canbus codes the CID sends it makes sense what you are saying and it correlates with the tests i did where disconnecting the original lvds cable results in a idrive controller that works for a couple of seconds (after a couple of seconds the ccc unit doesn't receive a heartbeat signal over canbus and the idrive controller stops working for the OEM screen). My other tests showed that the OEM menu still works when you disconnect the motor cable... Can we conclude from that the heartbeat signal/message is actually send over the lvds cable?

I still am in contact with the seller of my unit and he is giving me (unnecessary) tasks to try and make it work. It seems that the most elegant and easiest way is to let them update the MCU firmware to send out the heartbeat right? I will explain the findings in this thread to him and hope he can contact the manufacture, although i don't think that will lead to a solution very fast.
[Android Head-Units] ulysse31_revient:
Hi ErikE87,

I think we should not call the "motor cable" a "motor cable" ^^' :

- it as 4 wires : I first thought that it would be a stepper motor, but no, it is rpm, those kind of motors don't use 4 wires, they use 2 (ground, vcc) or 3 (ground, vcc and rpm/phase).

- cables are not "powering" the motor, but the screen motherboard itself, that then manages the motor power and has "endstops" to know when it has reached the open state, or closed state.

- again, it has 4 wires, ground, vcc, a white and a green : I suspect white and green to be CAN_L and CAN_H (read next to know why)

- my CAN dumps are made with the android HU, it is only connected to the Y connector to the car, and it "taps" the can bus to the CCC (it is between the can bus line in the rectangular connector from the car, and the CCC harman controller), I receive the can bus messages from the original screen from this line ! if they were sent via lvds directly to the CCC, why would I see them in main CAN bus ? moreover, on the documentation schema, we clearly see lvds in one side, and K-CAN on the other side linked to the CID from the CAN bus main line.

- LVDS is a standard, It does not seem to implement can bus inside.

- so to me, can bus signal is clearly sent from screen to the car via the (lets call it like this) "main power connector" of the CID.

To answer your question of why after disconnecting "main power connector" of CID, it still work : the messages are sent regularly from the CID, I suppose that CCC waits at init (car ignition) to see them, to know if it needs to interpret futur idrive message, if at init it receives them, then it knows that screen is available, and it won't check often if they are still there, but eventually, after some time without notification from screen (10 sec ? 30 sec ? 1 min ? 5 min ?) it may then declare screen "unavailable" and then won't interpret the idrive messages anymore. The regular sending of status messages from CID are there to avoid that.

Clearly, if you are still in touch with your seller, yes, the best option is to get them implement it inside the MCU, send them this info, if needed, you can do the same data logging (or I can send you mine).

On my side, let say that with my seller, we put an end to our "relationship" ^^' . In my case, without the help of the seller, my best option ("fastest", even if it may take me weeks, since I can only work on that during my "hobby time") is the arduino CID faker/simulator.

I hope you understand all my points, if you have questions, feel free to ask.

Cheers,

--

Ulysse31
[Android Head-Units] ErikE87:
Hi Ulysse31, you are right about the name of the cable that powers the CID lets call it the main power connector of the CID ;)

It would help if you send me the can data log files from your tests to convince the seller that they need to update the MCU. I will also run your tests again and will add the tests i already had done but with can data logging enabled! Will come back with the results.

Erik
[Android Head-Units] ulysse31_revient:
Here you'll find my can datalog with OEM screen used (original connected on main power connector and lvds, Android connected on Y connector) :

https://mega.nz/#!hpBElCTL!M12zeT8TIWAhtJHNKEwhM_Wkj1uzVxsulnYESKRq2NU

I managed to have the android waked up before car ignition (putting the key on the car), to enable can data logging, and then, put the key on the car and log all can bus packets.

To do your can data logs :

- connect an empty usb flash drive to the android HU

- go to factory setup

- on the same menu where you set the CCC type (alpine/harman), you can put "Enable Can data logging" to ON.

- it will start directly logging all can bus packets to the usb flash drive

- if the android is powered off (by taking the car key off) it will automatically put the option back to "OFF" at next boot.

it creates a directory "can" containing a file called "canData.txt".

Cheers,

--

Ulysse31
[Android Head-Units] ulysse31_revient:
Hurray ^^

Hi all,

So for those have the "idrive not working on OEM" ... I have some good news :

My "CID Faker" project, based on a arduino to simulate the CID (genuine screen) presence on the car network ... WORKS !! YESSSSSSS :D

I now have access to both menus (Android and BMW) and I can switch between those 2 without problems ^^

Just need to make a "real board" PCB (for now soldered on a PCB prototype board) ^^

Cheers all,

--

Ulysse31