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.

This is the "set volume" command

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?]

Delay

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:

Initial response

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.

More reads

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 bytea for the purpose of decoding its purpose are bytes four and five, "03 e0", as far as my scheme goes.

 < 0d 00 18 ca 63 01 ff ff ff ff 14 26 35 01

A decimal-encoded timestamp.

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

Another pair of time updates from the buffer...

 < 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

And another...

 < 0e 00 18 03 e0 00 01 05 00 ff ff ff ff ff ff

Finally another of the unknown "03 e0" updates.