|
OK, after a bit of reformating, some things begin to show up.
Please find attached a zip with 2 reformated versions of the first log (playing + track changes)
The first version is the "manually fixed" version of the previous one, with the cut bytes re-joined together (see above)
The second one contains only the CD-changer frames in hex format, grouped by 15. The good news is that the whole number of bytes a multiple of 15, so most probably the alignment is correct, with 3Dh being the first byte of most frames.
However, from frame 97 on, the alignment becomes corrupted, but it's most probably due to ACKs coming in the game when track changes are requested by the head unit, this has to be fixed manually in the dump...
Well, now for some observations, concentrating on frames 1-96 for now :
- bytes 8 and 12 increment at each frame and wrap at 59 > 00, provoking an increment of the previous byte (resp 7 or 11). Reminds me of something :-). But well, obviously, this is not hex but bcd if I'm not mistaken (each 4-bit nibble is limited to the 0-9 range)
- byte 0 is most probably a "frame type" indicator, mostly 3Dh, sometimes 3Fh.
- I guess the last byte (14) is a kind of CRC. It decrements while time increments and jumps when byte 0 changes.
- The byte 1 changes at each frame. It normally contains an incrementing hex number, but some values are replaced by 3FH... No idea what it means.
- All other bytes (2, 3, 4, 5, 6, 9, 10 and 13) are fixed in these frames. They certainly contain at least CD and track number.
That's all for now :-)
|