anatomy of a volume change
Here's an excerpt of sending a volume change along with my notes. In case it's not clear all digits are hexadecimal unless specified otherwise.
>> 05 00 60 c0 c8 38
Unpacked to binary for full microscopic detail.
05 - length
00 - always zero, always... who knows why
60 - address of the hifi device (first four bits?)
c0: 'amp' subsystem (first four bits?)
c8: 'volume' command
38: 00111 000 - volume value '7' (i.e. 7 << 3).
[Side note, am I perhaps representing these numbers wrong? Are lots of these values meant to be shifted? I should probably check to see if some bytes ever differ from multiples of eight. What would that mean, anyway?]
Note that a 'read' performed instantaneously after this write will return nothing; I haven't calculated the delay required to do the read but it's probably less than 500ms.
Performing a read thereafter gives us several lines:
Acknowledgement of the command:
< 05 00 18 c8 c7 38
05: length
00: always zero, always... who knows why
18: return address ("host"?)
c8: return subsystem
We see this pattern in most other command responses; commands sent to minidisc "b0" are returned to "b8"; this "rule" works for all subsystems except "c1", tuner, whose responses are usually "cf". I hope there's a logical explanation for this...
c7: ? 'volume' command -1 ?
38: the new volume value, confirmed! (again, 7 << 3).
So, we're not 100% sure what's in here but we're close.
The script I use keeps performing reads until there's nothing left. There are a few more status updates generated by the volume change, but apart from this the system seems to generate new messages roughly every second regardless of whether anything's happening, and buffers (an unknown but finite number, ~48?) between reads, which is why there are a few duplicates here.
< 16 00 18 c8 c1 00 05 00 02 56 4f 4c 55 4d 45 20 20 20 37 00 00 00 00
.. .. .. .. .. .. .. .. .. V O L U M E 7 .. .. .. ..
16: length
00: you guessed it, zeros
18: that's "us"
c8: reply from the "amp"
c1: seems to represent "display update" or "state update".
00: ?
05: ?
00: ?
02: ?
[10 bytes of ASCII, then]
[ 4 bytes of zeros]
Here's a display update! We see lots of these, including "Hello" on start, etc. I haven't been able to dissect them very far but a quick flip into ASCII (above) demonstrates some of the state that is returned.
< 0e 00 18 03 e0 00 01 05 00 ff f0 ff ff ff ff
Not sure what this line represents at all. The interesting bytes for the purpose of decoding its purpose are bytes four and five, "03 e0", as far as my scheme goes. Checking through my captures here's all the variants I've seen, in increasing order of popularity:
< 0e 00 18 03 e0 00 01 02 00 ff 02 ff ff ff ff
< 0e 00 18 03 e0 00 01 08 00 ff ff ff ff ff ff
< 0e 00 18 03 e0 00 00 ff 00 ff f0 00 00 00 c0
< 0e 00 18 03 e0 00 01 05 00 ff ff ff ff ff ff
< 0e 00 18 03 e0 00 01 0b 00 ff f0 ff ff ff ff
< 0e 00 18 03 e0 00 01 00 00 ff f0 ff ff ff ff
< 0e 00 18 03 e0 00 01 05 00 ff f0 ff ff ff ff
< 0e 00 18 03 e0 00 01 00 00 ff 00 ff ff ff ff
< 0e 00 18 03 e0 00 00 ff 00 ff ff 00 00 00 c0
< 0e 00 18 03 e0 00 01 02 00 ff f0 ff ff ff ff
< 0e 00 18 03 e0 00 01 0b 00 ff ff ff ff ff ff
< 0e 00 18 03 e0 00 01 00 00 ff ff ff ff ff ff
< 0e 00 18 03 e0 00 01 02 00 ff ff ff ff ff ff
< 0e 00 18 03 e0 00 01 04 00 ff 04 ff ff ff ff
< 0e 00 18 03 e0 00 01 04 00 ff f0 ff ff ff ff
< 0e 00 18 03 e0 00 01 04 00 ff ff ff ff ff ff
Context would probably help unpick these...
< 0d 00 18 ca 63 01 ff ff ff ff 14 26 35 01
It's a decimal-encoded timestamp with a few unknown bytes.
0d: length
00: more zeros
18: return address
ca: Not clear. Clock?
63: seems to represent "timestamp"
01: ?
[ 4 bytes of ff]
14: clock: decimal 20 (hour)
26: clock: decimal 38 (minute)
35: clock: decimal 53 (seconds, never displayed!)
01: ? varies ?
Followed by an ASCII-encoded version of the time!
< 14 00 18 ca e2 01 20 20 20 20 20 20 20 20 01 32 30 01 33 38 ff
.. .. .. .. .. .. .. 2 0 .. 3 8 ..
I don't have the clock displayed on screen but, if I did, I presume this is what it'd say. Note the alternating value between the hour and minute bytes.
< 0d 00 18 ca 63 01 ff ff ff ff 14 26 36 01
< 14 00 18 ca e2 01 20 20 20 20 20 20 20 20 01 32 30 00 33 38 ff
< 0d 00 18 ca 63 01 ff ff ff ff 14 26 37 01
< 14 00 18 ca e2 01 20 20 20 20 20 20 20 20 01 32 30 01 33 38 ff
< 0e 00 18 03 e0 00 01 05 00 ff ff ff ff ff ff
Another of the unknown "03 e0" updates, before reads ended.