Skip to content

Home

Jump to bottom
Graham edited this page May 24, 2021 · 22 revisions

Hardware

This is being tested with:

  • MacOS X (10.10+), Linux (4.x/arm64) & Windows 10 (2018+)
  • PCLK-MN10 (should be at least partly compatible with PCLK-MN10a and PCLK-MN20 but I have no way of knowing)
  • DHC-MD595 (but should be compatible with any MDS-xxxx with a 6-pin DIN but, again, I have no way of knowing)

My stupid plan:

  • Windows 2000(!) VM + M-Crew
    • success! even though none of the installers seemed to work.
  • usb sniffing
    • success! here are the raw usb logs and here are all the output commands
    • I passed the logs through a bit of awk to give a nice transcript.
    • I'd like to go back and run through some functions methodically, perhaps with a stopwatch, to collect better data now I know what I'm looking for.
  • some fiddling with pyUSB (because why not)
    • success! we have limited device control and, I think, all we need at the USB layer.
  • mapping functions, etc.
    • lots of message decoding left to do, both to and from the device.
    • top goals: read and set input source and volume level. all done, we have full control of input and volume, and can read them out (though the interface for this is very poor right now)
    • later goals: read MiniDisc and CD-Text; maintain device state; generate events from changes
  • find the remote control found it!
  • ...
  • profit? (lawyers: I'm joking)

There is bound to be a more intelligent way to do most of this stuff but I'm just stumbling around for fun.

PyUSB

See USB Basics. It turned out to be all done for me.

now what?

Some random commands that I sniffed seem to work when replayed:

write(0x00,0x60,0x00), read()

turns it on!

write([0x04,0x00,0x60,0xc0,0x2f]), read()
write([0x04,0x00,0x60,0x90,0x26]), read()
write([0x04,0x00,0x60,0xb0,0x26]), read()

(no more, no less) turns it off... is it mere coincidence that ASCII 0x4F, 0x46, 0x46 would read 'OFF'? (As it turns out, yes, it is coincidence I think; the first command is all that's required, which leads me to question what the subsequent '26' commands are doing... I'm sure we'll find out at some point.)

reading data

Output data from repeated read() seemed at times almost completely random (though the first int clearly contains the message length) but it does have something to do with the state of the hifi device behind the link; the message length increases significantly if I fiddle with the controls. I captured some output but lost the full log. Mapping is being done in messages.

...

Lots more to discover. Source switching turned out to be trivial, so other commands should follow very simply.

Also compatible with...

Looks like they made a PCLK-MN10a and a PCLK-MN20 using supersets of the MN10's functionality. So I assume these should work with the same USB commands, but I have no way of knowing.

References

Surely not alone...

I find it hard to believe nobody's been here before me. If I'm really lucky the PCLK-MN10 simply passes data through to the underlying device using a variant of one of their existing protocols which others have investigated in detail before, e.g. S-Link described by http://www.brian-patti.com/s-link/CAVuser.htm http://www.edcheung.com/automa/sircs.htm and http://www.armory.com/~spcecdt/remote/control-S.html, but there's lots more reading to be done...

Update: Someone did get there (10+ years) before me -- and even published the source! 'ripnetuk' produced a Windows utility to replace M-Crew (https://web.archive.org/web/20031009144912/http://www.ripnet.co.uk:80/freeware/RipMDSPC3/readme004.htm) and has very kindly furnished me with a much better understanding of the command protocols and all the sources I need to complete the MiniDisc command set (Now, to read it...).

Clone this wiki locally