Originally Posted by Putput
Y E S
(did you hear it ?)
Well, of course it works *much* better once signal is not inverted :-) - Thanks a thousand times, Ale !
By the way, I used the 18k resistor in series with the incoming line and it works perfectly. Schema and scope traces will come soon but ... what we all are interested in is hex dumps, aren't we ?
So here we go. You'll find below a zip file containing two traces.
The first one with a CD playing track 1 of CD1 for a long time, then I began skipping to tracks 2,3,4,5 (and 6 maybe ?), each time trying to wait for 5 seconds before going to the next track.
For the second one, I skipped to CD 1 (which was already playing and restarted at the beginning of track 1 ) then CD 2, 3, 4, 5, 6 and back to 1, each time also trying to wait for 5 seconds of song playing before going to the next CD
A word about the way the traces were taken : I'm using the MTTTY samples as I already said, but modified in the following ways :
- dump byte in hex and binary formats, plus ascii character if in the 32-127 range (or something like that)
- only dump one byte per line
- connect to a second serial port at the same time. All bytes coming from the second serial port are indented to the right, making a second column.
- dump results to file
(sources or exe available on request, but beware, it's quick and dirty...)
The "dual channel" sometimes gives display problems when both threads try to write on screen at the same time, so sometimes you get things like :
which should read :Code:47h 01000111b G 01h 00000001b 01h 00 C5h 11000101b 000001b 00h 00000000b
I also have a systematic error on "SetCommState" on start, and the program even crashed once after a "long" session (the first file "playing + track changes"), but well, it's just a spying prototype :-)Code:47h 01000111b G 01h 00000001b 01h 00000001b C5h 11000101b 00h 00000000b
If I have time, I'll change the app to have a timestamp at the start of each line and also be more systematic and providing a timestamped description of the operations I made, but I'm afraid the week-end will be very busy...
Who'll be the first to crack this protocol ? :-)
Tip : Left column is what the CD Changer says, right (indented) column is what the head unit says.
On your marks... get set... Go !
(Oh, and yes, please, post your findings as soon as you have even a very partial decoding, so that others can use it. Thanks)
Mmh, couldn't resist to take a look at the dumps before going to sleep.
I'm afraid the two columns are not correcly synchronized, because the CD-changer frames I had on the scope always had the exact same length, while here the number of bytes is variable between ACKs. I guess there's some buffering somewhere...
I think the correct reference is in my manually decoded sample : CDC frame is 15 bytes long. Now where's the beginning... You tell me :-)
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 :-)
Great stuff!!! Congratulations!
Because earthquakes are not frequent in this region I knew it had to be you, hope you didn't hurt yourself to much freaking out.
I'll get on to it ASAP (probably tomorrow). I know of a few CRC's frequently used, I'll try to figure this on out first. I've you got the time, can you post (or update) the circuit that you used? I'm more a 'softy' then a 'hardy' when it comes to computers..
Thanks!
Here's a re-re-reformat of the first dump.
Not only are there ACKs, but some frames also seem to be truncated (or follow another format). The big difference is in bytes 2 and 3. Byte 2 is almost always = frame length - 4 and byte 3 would be the "frame type" after all...
Anyway, considering only full 15-byte frames, it's now obvious that byte 4 is track number.
Status of the 15-byte frames decoding :
0 : ?? (3Dh or 3Fh)
1 : frame id ?
2 : frame length - 4 ? (0bh)
3 : frame type ? (47h)
4 : track number
5 : ?? (01)
6 : ?? (00)
7 : elapsed time from CD start, minutes (bcd encoded)
8 : elapsed time from CD start, seconds (bcd encoded)
9 : ?? (constant per track, 00 for track 1)
10 : ?? (00)
11 : elapsed time from track start, minutes (bcd encoded)
12 : elapsed time from track start, seconds (bcd encoded)
13 : ?? (00)
14 : CRC ?
Seems we won't be able to display ID3 tags :-(... but well.
Here it is, "(c) Ale" for the smart use of the 232 inputs to invert the signal.
Funny enough, the working circuit needs less components than the previous non-working one.
** Edit : Threshold needed values tweaking.
Working circuit available in post 197 ***
I only have a HU with a single CD player and no CDC so I don't know what the display shows when playing with a CDC unit. But it's a CD Changer so where is the disk number? Probably byte 5? Perhaps you can try this? I've found some time this afternoon so I'll start working on the CRC (or what looks like it).
While playing, the display contains only the track number and cd number, no time information. Maybe more information is provided for people who have the GPS navigation option with LCD screen. On my basic display, CD number is a separate (smaller) digit on the right.
I agree with "play" frame decoding and i suggest
2 : frame length, the length of following data byte before CRC
For ID3 tag perhaps there is a frame type to send some text data, becouse they say the vdo chm604 mp3 support ID3 tag...
I think I've found the CRC. I developed a prog that can load a text file with the following format:
3Dh 38h 0Bh 47h 01h 01h 00h 00h 45h 00h 00h 00h 43h 00h
3Dh 39h 0Bh 47h 01h 01h 00h 00h 46h 00h 00h 00h 44h 00h
3Dh 3Ah 0Bh 47h 01h 01h 00h 00h 47h 00h 00h 00h 45h 00h
and so on. As you can see there are only 14 bytes, the last byte is removed from Vicne's logfile (lines MUST be 56 chars long!).
When you push the Calculate button it starts to calculate a CRC or actually a FCS for each frame and adds it to each line. When the frame starts with 3D it calculates the FCS perfectly, only when it starts with 3F it goes wrong. When I change the 3F to 3D the result is ok again, so maybe the 3F could be a glitch? Only problem is, when I zip it the file is 203kb in size and the maximum size for attached files is 200kb on this forumI will try to send it in a PM to Vicne.
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote
Bookmarks