CAN-Bus

Zitat von motral

RFA is dedicated module for cars with keyless start or entry (I had and have in my use such only)
433Mhz receiver connected to RFA, in other way its connected to BCM I suppose (but I can't see such pids in BCM firmware for out)

My car is keyless, also But my play-BCM is configured not to have it.
In my understanding "RFA" is this https://mk4-wiki.denkdose.de/grundlagen/rfa/start and keyless-module is called "KVM" (see this picture https://mk4-wiki.denkdose.de/_media/grundla…_uebersicht.png)

I'm not able to find CAN-IDs in a Firmware binary, maybe you have access to the sources or you're just genius and able debug the Assembler code... but i think it could depend on CCC? If one does not have keyless, maybe the ID is sent from BCM, and if one has it, it's sent vom the keyless-module (called KVM, Keyless-Vehicle-Module, not RFA).

Do you know communication between fuel firef heater (AHCM) and BCM? My observations show that BCM will trigger start of it at given time and IPC only displays the message that its running. I‘d like to know the commands it sends to/from the heater to make it start. Also i think that BCM controls climate module to set flaps and blower speed.
I tool many logs but cant decodr comm.

I see. But i don’t think you’re right about power of EATC module. It is connected to „POWER 30“ in schematics, which is permanent +12V directly from battery. So it seems it powers down itself or by some CAN commands. So it could wakeup on specific commands and control inner blower fan and flaps. They are not connected electrically with the aux heater.
All he does is send CAN commands to EATC.

Thanks for pointing this out, @motral. Looked at the schematics again and found that only the PWM control line of the blowers powermodule is from EATC. Power supply itself comes via a relay which is controlled by BCM port „FAN RELAY LOGIC“, as you said.

Flaps are not clearly documented in schematics. There is no external feed or relay, nor any amplification. The highlevel controls are inside of the EATC module (H-Bridge i think). So the module could(!) control them any time.

English would be ok, if you're more comfortable with. Google translations can't handle technicals terms correctly, so the last sentence means: "Could you send your table", but you shurely mean: "Could you send your spreadsheet"

Well, first of all, your welcome to do anything you have in mind and publish it here. As long as this is a dialog and you're willing to provide the information you evolve to others, i will support you as good as i can So, go ahead and tell what you discovered until now!

For me i can tell you, that i had identified nearly all senders of messages, but only a few payloads, because i mostly had focused on the MS-CAN until now. All my results are in a big Excel which is more a working area for me. Maybe we should start a Online-Spreadsheet with Google-Table or a Wikipage for adding all results... but there are even more questions to be answered.

To work efficiently together important questions to answer are:

Which equipment do you have? (which car? which radiosystem? which IPC(s)?

What do you use to inspect des CAN Bus? (Software and hardware to be able toexchange results and logs)

What are your technical skills? (Do you know how CAN works and the overlaying protocols?)

So, first of all you should be familar with the bus in the Mondeo. Take a look here: https://mk4-wiki.denkdose.de/artikel/can-bu…odule_im_mondeo

(sorry, not translated to English, use Chrome)

As you can see there, the IPC works as a gateway for most of the signals on the MS-CAN. Some are passed through without change, some change only the ID and others are completly reassembled. The IDs may vary from vFL to FL slightly.

CANhacker is good, because we could share tracefiles. Also it uses Lawicel SLCAN that is understood by a variety of tools. Because MM-CAN is very slow (only 125 kbit/s) there should be no problem with your Arduino interface solution.

I've written some PHP scripts to analyze the data to bring out desired information. But it's still hard work. Especially if there is a communication and not simply sending static data periodically. It's not easy to isolate a communication stream, because there is a loose coupling between sender and receiver, in cause of the nature of the bus. I'm a IT technican too, so i can tell you that CAN works totally different from what you might know.

Here is a list of all IDs i captured on my FL. In the first column there is the ID i've recorded, the second is the name of the identified module sending/creating that ID. If there is not name, i'm unsure or don't know who is the creator, but it is definitively NOT one of the named ones. The 3rd column is set, if the creator of the message is not located on the MM-CAN bus but is gatewayed by IPC (e.g. BCM or PAM).

024     
080	BCM	IPC
131	PAM	IPC
1C6	DAB
1D2	
1E6	ACM	-
1E6	ACM	-
1E6	ACM	-
1E7	
1E9	ACM	-
1E9	ACM	-
1F2	IPC
1F2	IPC
1F2	IPC
1F2	IPC
201	IPC
285	IPC
287	IPC
289	IPC
295
2A5	IPC
2D0
2D1
2D2
2D5	ACM	-
2D5	ACM	-
2D8	ACM	-
2D8	ACM	-
2D9	ACM	-
2D9	ACM	-
2D9	ACM	-
2DE	DAB
2DE	DAB
2DA	ACM	-
2DB	ACM	-
2DC	ACM	-
2E3	ACM	-
2E3	ACM	-
2E4	ACM	-
2E6	ACM	-
2E7	ACM	-
2E8	ACM	-
2ED	ACM	-
2EE
2F5	DAB
2FA
2FB	ACM	-
311	DAB
400	BCM	IPC
405	BCM	IPC
420	IPC
433	BCM	IPC
480	ACM	-
480	ACM	-
480	ACM	-
481	ACM	-
482	ACM	-
482	ACM	-
482	ACM	-
4C7
4D0	ACM	-
4D2	ACM	-
4D4
4D7	IPC
4D9
4DB
4DC
4DE	DAB
4F3	IPC
50C	ACM	-
50C	ACM	-
50C	ACM	-
50C	ACM	-
50F
511	IPC
56E	DAB

As you see, most messages comes from the Radiosystem itself, which is not a big surprise because there are only a few members on this bus

I currently have'nt identified any SRCM module IDs but i guesst it must be the missing ones, because my car did not have any more modules left there.

I identified the IDs by buying the module in question and run it on the desk, with only the CANinterface attached. Most modules need to see an IGN_ON signal on the bus to spit out their IDs and others also need to see the whole CCC, which is a multiplexed message on ID 400.

I have done many many tracelogs and stored them with information what i have done while recording it. Also i evolved some methods to find what i'm looking for. Mostly tools to reduce the data inside a log, e.g. remove IDs with static data if looking for a change. Or quantify the IDs or Data. Also remove known IDs from a log, to leave only the unknown for further inspection. Looking at ASCII representation of the payload can also bring interesting results. Mostly all data is unencrypted so it's easy to read if you're looking for music titles or such.

Another good approach is to record and isolate data and to replay it against the receiver. So if you replay a tracefile against an IPC on the desk, it should behave like in the car. Shurely you should remove all IDs the IPC is creating on it's own, to avoid collissions.

Maybe we should start with something simple. Is there a basic functionality you are looking for?

I guess if you are talking about an Andriod device (radio) the most common thing would be to have the menu-items visible in Convers+ (IPC) like "Radio". If testing this inside the car, you could simply disconnect the CAN-Wires on the Quadlock and inject your data using your Arduino-Interface.

To find out which data causes the IPC to display the "Radio" menu, you could do the "narrow down" trick. Make a capture with your Sony radio connected, so the menu appears. Just a few seconds should be enough. Then disconnect the radio and replay the trace. After disconnecting the radio, the menu should disappear (not only greyed out, it should really vanish). And after replaying the data, it should come back again. If this is true, start to remove single IDs from the log until the menu does not appear anymore. You should end up with a single of few IDs left. Next inspect them further and try to change values of the payload. If you could narrow it down to a single byte, keep in mind that many signals are bitwise, and try to set/unset bits from that byte. At the end, you have your data needed.

Hallo, ich hab mir mal etwas die DAB-Kommunikation angeschaut, also die Pakete die zwischen DAB-Modul und Radio (in dem Fall ein MCA) hin- und herfließen. Dabei bin ich auf viele interessante Sachen gestossen. Zum einen weiss ich nun das die auf den Senderwahltasten angezeigten Texte definitiv vom DAB-Modul gesendet werden. Aber auch noch viel mehr, ist aber alles noch nicht reif für eine Veröffentlichung.

Von einem meiner Spielereien und um auch was vorzeigen zu können habe mir ein kleines Tool programmierung und vom Ergebnis mal ein kurzes Video gedreht:

Wirklich nichts spektakuläres, aber nur um mal zu zeigen was alles geht...