Pressing record and delete while turning the device on, the camcorders give the following information:
FW-VERSION: 03.40
CAMERA ID: GC3052xxxxxx PCB VER: B3 |
FW-VERSION: 03.40
CAMERA ID: GC4052xxxxxx PCB VER: B3 |
Next step done (after taking it apart and marvelling at the really clean board design) was the installation of a USB cable to one of the cameras. The pinout of the header hidden underneath the "Must be returned to the CVS Photo Center for DVD" sticker is the same as for the PV2.
Pin | Signal Name | Description |
---|---|---|
1 | ||
2 | Ground | |
3 | ||
4 | ||
5 | ||
6 | USB +5V power | Connects to red wire. |
7 | USB Ground | Connects to black wire (you can also use pin 2 or 10). |
8 | USB Data + | Connects to green wire. |
9 | USB Data - | Connects to white wire. |
10 | Ground |
I didn't bother with the pinout above, and soldered the cable directly on the components and traces on the opposite side of the header.
NOTE: Please be aware that not all USB cables are equal (mine had red,black,yellow and blue wires). Test your cable before soldering!
A really good USB in a nutshell can be found here. After plugging in the camera, assigning it a libUSB driver, the following information can be obtained:
Output libusbtest | Output HHD USB monitor |
---|---|
bus/device idVendor/idProduct bus-0/\\.\libusb0-0004--0x167b-0x0101 167B/0101 - Manufacturer : Pure Digital Inc. - Product : Saturn - Serial Number: PS0000010 wTotalLength: 39 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 80h MaxPower: 48 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 3 bInterfaceClass: 0 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 01h bmAttributes: 02h wMaxPacketSize: 512 bInterval: 0 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 81h bmAttributes: 02h wMaxPacketSize: 512 bInterval: 0 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 83h bmAttributes: 02h wMaxPacketSize: 512 bInterval: 0 bRefresh: 0 bSynchAddress: 0 |
LibUSB CVS camcorder Hub Power: Self Power Number of Ports: 6 Power switching: Ganged Compound device: No Over-current Protection: Global Device Descriptor USB Version: 2.0 Device Class: (0) Reserved (defined in Interface Descriptor) Device Subclass: 0 Device Protocol: 0 Max Packet Size: 0x40 (64) bytes Vendor: 0x167b () Product ID: 0x0101 Product Version: 0x0000 Manufacturer: 1 0x0409: Pure Digital Inc. Product: 2 0x0409: Saturn SerialNumber: 3 0x0409: PS0000010 Number of Configurations: 1 Connection Status: Device Connected Current Configuration: 0 Device Bus Speed: Full Device Address: 0x01 Number of Open Pipes: 0 Configuration Descriptor (1) Total Length: 39 bytes Number of Interfaces: 1 Configuration Value: 1 Configuration: 0 Attributes: 0x80 Bus Powered Max Power: 0x30 (96 Ma) Interface Descriptor (0) Interface Number: 0 Alternate Setting: 0x00 Number of Endpoints: 0x03 Interface Class: (0) Reserved Interface Subclass: 0 Interface Protocol: 0 Interface: 0 Endpoint Descriptor (Addr: 0x01) Endpoint Address: 0x01, Output Transfer Type: Bulk Max Packet Size: 0x0200 (512) bytes Interval: 0x00 Endpoint Descriptor (Addr: 0x81) Endpoint Address: 0x81, Input Transfer Type: Bulk Max Packet Size: 0x0200 (512) bytes Interval: 0x00 Endpoint Descriptor (Addr: 0x83) Endpoint Address: 0x83, Input Transfer Type: Bulk Max Packet Size: 0x0200 (512) bytes Interval: 0x00 |
Interesting to note is that the camera refuses to identify itself as any particular device. it first states in the Device descriptor
In the short run this is going to rule out the use of an existing USB driver to talk with the device.
Morcheeba found clues that point to the possibility of accessing the camera as a Mass Storage device.
Seeing that the camera also does not give away information on how to access it, I tried the following to see if it would respond as a mass storage device:
Try to access as: | result: |
---|---|
Mass Storage C/B/I | All ADSC requests return with error condition. There are also no interrupt endpoints available on the device. |
Mass Storage C/B | All ADSC requests return with error condition, all bulk read/writes return error condition. |
Mass Storage B/B/B | All bulk read/writes return with error condition. |
Taking into account the above, the camera is probably locked (the same as the PV2 camera), and needs to be unlocked before it can be accessed as a Mass Storage device. We now have to find out how to send an unlock code to the camera.
It turns out the camera does respond to requests (outside of the normal USB spec) and returns data. To explain this we need to look at how a Host controller normally communicates with a USB device.
When you plug in a USB device, the host starts querying the device to find out information about it, so that a driver can be loaded. Above you can see the output of 2 programs that queried the device. On the lower level, this information is acquired with setup packets on the default (or control) endpoint. The structure of a setup packet is shown in the table below.
Offset |
Field |
Size |
Value |
Description |
0 |
bmRequestType |
1 |
Bit-Map |
D7 Data Phase Transfer Direction 0 = Host to Device 1 = Device to Host D6..5 Type 0 = Standard 1 = Class 2 = Vendor 3 = Reserved D4..0 Recipient 0 = Device 1 = Interface 2 = Endpoint 3 = Other 4..31 = Reserved |
1 |
bRequest |
1 |
Value |
Request |
2 |
wValue |
2 |
Value |
Value |
4 |
wIndex |
2 |
Index or Offset |
Index |
6 |
wLength |
2 |
Count |
Number of bytes to transfer if there is a data phase |
Querying the default device with default requests (bmRequestType = 0x80, bRequest = 0x06, wValue = 0x0000 .. 0xFFFF, wIndex = 0x0000), the camera will give back data of upto 4096 bytes. The most interesting responses come from values for wValue: 0x0200 - 0x02FF and 0x0700 - 0x07FF. The responses are not always consistent. See table below for a preliminary/incomplete overview of responses. Most of it looks like it's overflowing a buffer in the camera, but some of it is more structured.
wValue | Response | Note |
---|---|---|
0x0000 - 0x00FF | No response. | |
0x0100 - 0x01FF | Response of 18 bytes. | Standard response. |
0x0200 - 0x02FF | Either 4096 bytes returned, or the camera locks, or the camera turns itself of. | Does not always give the same response when you replug the camera. |
0x0300 | Response of 4 bytes. | Standard response. |
0x0301 - 0x05FF | No response. | |
0x0600 - 0x06FF | Response of 10 bytes. | Standard response ? |
0x0700 | Response of 39 bytes. | |
0x0701 - 0x070F | Either 4096 bytes returned, or the camera locks, or the camera turns itself of, or a nice surprise. | Does not always give the same response when the camera is replugged. |
0x0800 - 0xFFFF | No response. |
Querying the interface/device with vendor specific requests (bmRequestType = 0xC0/0xC1, bRequest = 0x??, wValue = 0x0000 .. 0xFFFF, wIndex = 0x0000) we also get data back from the camera. See the table below for a preliminary/incomplete overview.
wValue | Response | Note |
---|---|---|
0x9201 | 4 byte response | |
0x9202 | 2 byte response | |
0x9203 | 12 byte response | |
0x9D00 - 0x9DFF | 10 byte response | |
0xF800 - 0xF8FF | 10 byte response | |
0xFF00 - 0xFFFF | 4 bytes response |
The results above were obtained by a small utility that makes use of libUSB. Download source code and a WIN32 executable here. It runs from the cmd line, and the options are:
CVStest.exe bmRequestType bRequest wValuefrom wValueto wIndex wLength Example: CVStest.exe 0xC0 0x06 0x9201 0x9203 0x0000 4096 will print the response for wValue 0x9201 - 0x9203.
Follow the steps below to retrieve the last movie:
bmRequestType | bRequest | wValue | wIndex | wLength |
---|---|---|---|---|
0x40 | 0x01 | 0x9300 | 0x0000 | 0x0000 |
Some movies I downloaded from my camera: