I have been studying the communications between the Mavica CD500 and the RM-VD1 Remote with the goal of computer controlled operation. This page details what I have learned so far. This Linux C-program and this PIC-16F877A microprocessor program for the DLP-2232PB-G protoboard allow computer control of on/off, shutter release, and zoom capabilities of the Mavica CD500.
There are 3 wires connecting the RM-VD1 Remote with the Mavica CD500 via its ACC port. The plug tip is the signal lead, the plug band supplies 5.58 V of power to the remote, and the base connection is the ground. The source impedance of
The camera will turn on if the lead connected to the plug tip is connected to the ground lead through less than 2.5 kOhms for longer than 1/16 second.
When the remote is not connected, the camera sends out groups of 8 sync pulses every 1/60 second (US model, probably 1/50 for European use). The signal line is normally high at 3.0 V and is pulled low by either the camera or remote to signal a '1'. The sync pulse lasts 104 uS, following it are 8 104-uS slots which are interpreted as either '1' (low) or '0' (high). These 9 slots are then followed by 3 slots where the line is left high. Thus each byte takes 12x104 = 1248 uS. After 8 bytes are sent for a total of 9984 uS, the line is left high for the remainder of the 1/60 S = 16667 uS. The camera leaves all but the 6th byte at 0x00's (line stays high) during this idling sequence. For the 6th byte, it sends a 0xf0.
When the remote is first connected, it detects the sync pulses and places an 0x70 byte at the start of each group of 8 bytes.
About 1/6 second later, the camera responds by repeatedly filling the 3rd byte with 0x80, 0x00, 0xea, or 0xe2, the 5th byte with a 0x7f, the 6th byte with 0x01,0x0a,0x06, or 0x0e, and the final 2 bytes with 0x00s.
After another 1/6 second, the camera signals its readiness to receive commands by changing the 5th byte from 0x7f to 0x77 and adding data to bytes 7 and 8. The 6th byte is now 0x81,0x8a,0x86, or 0x8e.
The remote seems to be responsible for bytes 1 & 2. It also seems to do a handshake with by changing byte 3 from 0x80 to 0xc2 or 0xca in a regular pattern (see below). Bytes 4-8 seem to always be generated by the camera.
While idling with the remote attached, the 8-byte groups repeat themselves every 100 groups. The last 4 bytes appear in 4 different groupings (77 81 00 00, 77 86 ec 08, 77 8a 80 c0, and 77 8e 15 00), each grouping appearing with equal frequency. The first 4 bytes appear in 6 groupings, but some occur much more frequently than others. In the 100 group cycle, the grouping 70 00 80 00 occurs 48 times out of 100, 70 00 e2 80 and 70 00 ea 80 each occur 10 times out of 100, 70 00 00 00 occurs 20 times, 70 00 ca 00 occurs 8 times, and 70 00 c2 00 only occurs 4 times.
The first two bytes convey commands from the remote to the camera as detailed below.
The third byte is usually supplied by the camera, but certain camera-supplied 0x80 bytes are changed by the remote to become 0xc2 and 0xca. The rule is a bit complicated, but after the fifth occurrence of either a 0xe2 or 0xea byte, the subsequent three 0x80 bytes are replaced by 0xc2, 0xca, and 0xca. If the camera does not see this 3rd-byte handshake after about 30 consecutive groupings of 8 have been exchanged, it will fall back to the original "00 00 00 00 00 f0 00 00" search sequence.
I have no idea what function the camera-supplied 4th byte serves.
The last 4 bytes are supplied by the camera once it has determined that a remote is attached.
The groupings of initial 4 bytes match up with the final 4 bytes in the following combinations:
The meaning of the two bytes following the 77 86 report the speed and aperature settings. The upper nibble of byte 6 gives the aperature:
60 = f2.0 e0 = f2.2 10 = f2.5 90 = f2.8 50 = f3.2 d0 = f3.5 30 = f4.0 b0 = f4.5 70 = f5.0 f0 = f5.6 00 = f6.3 80 = f7.1 40 = f8.0
The lower nibble of byte 6 is usually 0x0c as shown above, but is sometimes made 0x01 during the period surrounding actual picture taking.
The higher order 5 bits of byte 7 give the shutter speed:
18 = 7,8 sec e8 = 3,4,5 sec 68 = 1.6,2,2.5 sec a8 = 1/1.3,1,1.3 sec 28 = 1/2.5,1/2,1/1.6 sec c8 = 1/5,1/4,1/3 sec 48 = 1/10,1/8,1/6 sec 88 = 1/20,1/15,1/13 sec 08 = 1/40,1/30,1/25 sec 00 = 1/60,1/50 sec 80 = 1/80 sec 40 = 1/100 sec c0 = 1/125 sec 20 = 1/160 sec a0 = 1/200 sec 60 = 1/250 sec e0 = 1/320 sec 10 = 1/400 sec 90 = 1/500 sec 50 = 1/640 sec d0 = 1/800 sec 30 = 1/1000 sec
Byte 7 is sometimes ORed with 0x04 during the period surrounding actual picture taking. For some reason, it is also ORed with 02 when shutter settings f6.3, f7.1 and f8.0 are selected.
Examples of bytes 6 and 7 coding are:
The ACC is also used by a Sony flash attachment. When the camera flashes, the grouping 77 81 00 00 is changes to end in a two-byte code that I have been unable to decipher. Presumably, it provides the auxiliary flash with useful brightness data. Those bytes appear to be set precisely when the flash is firing. If all light is blocked (i.e. if the lens cap is left on), these bytes will be set to ff ff.
The last byte of the 77 8e 15 00 grouping might be an error byte. It changes to f0 when the lens cap is blocking all light.
The RM-VD1 remote control is used for other Sony products and appears to have capabilities no applicable to the CD-500 camera.
When pressing a button, byte 1 changes from 0x70 to 0x78 and byte 2 changes from 0x00 to one of the following commands:
The camera responds by adding 0x10 to byte 6 when it is busy and not receptive to commands. This changes the 81, 86, 8a and 8e bytes to 91, 96, 9a and 9e.
I suspect that this remote control is far more capable that I have observed. It is probably possible to use it to run diagnostic programs on the camera and to even upload new ROM code. It may be dangerous to casually throw assorted bytes at it to see what will happen.
Last updated: June 6, 2007