Multiplex is a german manufacturer of RC goodies, among the things they make are synthesizer based receivers. I have a receiver called RX-7-SYNTH IPD, yeah those germans have a way with names don't they? The receiver can be hooked up to a PC to do all sorts of interesting things like setting failsafe positions of servos and scanning the radioband.
unfortunately that's a bit of false advertising as there is no software for anything other than windows, so actually using all those fancy features is a bit hard for those of us who don't haven't installed that particular sort of malware.
The adaptor has a page on the mpx site, but their website is stuck with a frame based design from the last century, so linking directly doesn't work, but search for product #85149, note that the actual part you get might be mislabeled as #85148 which is the transmitter USB cable.
Stuffing the USB-to-receiver cable in my Linux box did nothing intersting other than print this in my /var/log/messages:
Jul 10 18:34:07 panther kernel: [ 2530.093021] usb 4-2: new full speed USB device using uhci_hcd and address 6 Jul 10 18:34:08 panther kernel: [ 2530.256007] usb 4-2: configuration #1 chosen from 1 choice
lsusb identifies the device as:
Bus 004 Device 005: ID 10c4:81a9 Cygnal Integrated Products, Inc.
So it's time to open it up, quite quickly it was revealed that the content was a single cp2101 USB-UART IC, the simple PCB contains only 3 other components of interest:
RX ---+--------[100R]----- RXD
|
+--|>|---[100R]----- TXD
RX is the yellow wire going off to the receiver, RXD and TXD are pins on the cp2101, so all that needs to be done is to get the exsting cp2101 driver to recognize the customized device id, this is done simply by adding this line:
{ USB_DEVICE(0x10C4, 0x81A9) }, /* Multiplex RX-MGR adaptor, part no: #85148 */
To the device id table in the driver, with that line in place the cp2101 driver picks up the device right away:
Jul 10 19:57:15 panther kernel: [ 7513.367889] usb 4-2: new full speed USB device using uhci_hcd and address 7 Jul 10 19:57:15 panther kernel: [ 7513.530876] usb 4-2: configuration #1 chosen from 1 choice Jul 10 19:57:15 panther kernel: [ 7513.533825] cp2101 4-2:1.0: cp2101 converter detected Jul 10 19:57:15 panther kernel: [ 7513.647663] usb 4-2: reset full speed USB device using uhci_hcd and address 7 Jul 10 19:57:15 panther kernel: [ 7513.793733] usb 4-2: cp2101 converter now attached to ttyUSB1
Although I got the USB serial driver patched to work in short order, there is still the problem of doing somehting with the device, as no documentation has been provided by the manufacturer I have to rely on reverse engineering of the downloadable windows program.
The best way to run a windows program is under wine as it's the fastest and easiest if I have to actually use it and it's also pretty well suited to reverse engineering the protocol. Mapping a serial port into wine is done simply by running:
ln -s /dev/ttyUSB1 .wine/dosdevices/com1
The installation program runs fine under wine and so does the rx manager, right until it tries to access the serial port, at that wine starts spewing error messages:
err:comm:get_baud_rate tcgetattr error 'Input/output error' err:comm:set_baud_rate tcgetattr error 'Input/output error'
The problem seemed to go away simply by adding myself to the dialout group so I had access to the serial port, after that the receiver was detected and the program started talking to the device, however that came to a sudden halt when the application popped up a dialog saying "Run-time error '5', Invalid procedure call or argument" and wine complained:
err:variant:SafeArrayCopy not copying an array of 0 elements err:variant:SafeArrayCopy not copying an array of 0 elements
It seems the application is doing something wrong, like passing an empty input array to SafeArrayCopy, others who have had this problem have resolved it by installing microsofts oleaut32.dll, I however think that wine should be fixed so it's bug-compatible with windows, so I edited dlls/oleaut32/safearray.c in wine to comment out the check against copying zero-length input arrays and the application started working.
The joy didn't last long as the receiver seemed to break completely after having updated a paramter, it now refuses to work at all.
The first thing that needs to be estabilished is the configuration of the serial port, wine lends a helping hand by outputting:
trace:comm:dump_dcb bytesize=8 baudrate=38400 fParity=0 Parity=0 stopbits=1
So, the serial port is configured for a bog-standard 38400/8n1, that's nice.
Stuck until I get the receiver repaired, it stopped cooperating when I tried to change the RF channel, boo-hiss!