[Android Head-Units] ulysse31_revient:
Hello all,

I just got the time to do new CAN dumps, but this time with an arduino that outputs dump like :

timestamp,can_id,can_dlc,data[0],data[1]...

Since I'm not using the Android screen to dump, I left it disconnected, those dumps goal is to determine which packets to resend and their timings.

I made 2 dumps with the original screen :

- one starts before putting the key on the car, and ends 1.5 mins after taking out the key :

Entered in the car, connected the wires to the canbus, and used my phone to connect to arduino serial => I was surprized to see that packets were already flowing at an inside rate ! And without even putting the keys on the car ^^' so I let it dump everything, and on my log arround second 54 (arround 1.5 mins after getting into the car), the activity stopped, then I put the key in the ignition(at second 77 on my dump), activity starts again at an insame pace. I leave the dump running, made some actions on the screen at second 150, then 200, and took the keys off arround second 380.

- for the second dump, since I packets were already flowing when I started the first dump, I waited for the car CAN bus to "fall asleep", started the dump, and then "awaked" it, by pressing on a internal light button (yes, lights are connected to CAN Bus :D) I then waited 1.5min that the activity to go asleep by itself, just to have a init dump with no key ignition.

I'm writing this as I'm reading and analyzing the dumps, using this post as a note ^^' (might be silly, but really excited :p ) :

what first I notice, is that without the key input, 0x4f3 can messages id from the screen are already flowing, but with values that I didn't have before (which can be explained by the fact that I never made a dump before key ignition) this may seem problematic at first sight since I plan to have the arduino to boot at same time as the Android, so packets will only start at key ignition, but they might not be mandatory, since I already made it work with the arduino (but need to test after long wait of taking out the old screen ...), lets describe the 2 can messages separately :

The 0x33a packet :

- 0x33a packets starts only at key input, no packets of it before, at begining, it starts with a "high frame rate" : arround 6 to 8 packets per seconds ! but that irregular send can be explained by the CID wanting to advertise its quick status changes (data values varies a lot compared to other can bus devices).

- 0x33a goes at "high frame rate" to advertise its boot status, then, after around 25 seconds (CID boot/init end?) it slows down the pace, to 3 packets separated by 160ms, each 10030 ms. this seems to be the "normal sending rate" of this can id, since this pattern can be verified until taking the key out.

- 0x33a is sent all along with the same packet data status once booted ("normal rate") each packet is 0x33A,0x5,0x30,0x82,0x81,0xA,0x7F

The 0x4f3 packet :

- before putting the key, 0x4f3 is sent regularly, but around 1 packet each 840ms, and before key input, packet data is always the same : 0x4F3,0x8,0x78,0x52,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF

- once car key is inserted, 3 packets with different data values separated by arround 160ms, from data I suppose "closed" state, one "unknown for now ^^' " and a an "opening"

- right after the 3, it switch to "displaying" frame : 0x4F3,0x8,0x78,0x42,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF

- displaying frame data value is always the same (unless you try to close and reopen screen)

- displaying frame is sent around every 940 ms so this rate and packet data is the one that should be used for this can id message.

To resume, we should send every 10030 ms :

0x33A,0x5,0x30,0x82,0x81,0xA,0x7F

[160ms]

0x33A,0x5,0x30,0x82,0x81,0xA,0x7F

[160ms]

0x33A,0x5,0x30,0x82,0x81,0xA,0x7F

and, at the same time, each 940ms :

0x4F3,0x8,0x78,0x42,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF

Now, code this as a first reference. And test it "in real life usage" ^^'

Cheers all,

UPDATE: updated timing values, while coding and debugging, I got more accurate values re-reading the dumps ^^"

--

Ulysse31