Meade Pictor DIY technical manual ----------------------------------------- revision 1.0 Rick Hudson, KPO rhudson@paradise.net.nz Introduction ------------ The Meade Pictor series of CCD cameras have one attractive feature not found on many cameras - a SCSI interface which has a huge speed advantage over serial interfaces (usually RS232). Other manufacturers also make high-speed parallel interface cameras but these interfaces usually take the form of a PCI card or even a printer port. These are fine is you're using a PC but, if you're not, SCSI offers the advantage of availability on most, if not all, platforms. The problem here is that Meade, for reasons known only to themselves, have decided not to make available the information required to control the camera with custom written software. For automated systems this is clearly essential. The information in this manual provides this required information. Disclaimer ---------- The information here was determined experimentally. It is provided in good faith and its suitability for any given application is not guaranteed. Note that this manual is not in any way endorsed by Meade nor was its contents determined by the disassembly (or any other reverse engineering) of copyrighted software. About SCSI ---------- The following descriptions are context specific versions of what are otherwise standard SCSI commands. Therefore it is *not* a manual for controlling the camera from any specific operating system and it is assumed that the reader is familiar with whatever interface their operating system provides for SCSI. SCSI commands are generally blocks of data. A command descriptor block (CDB) is block of 6-16 bytes which define the SCSI command and the standard parameters. Several commands pass further parameters in the Data-Out buffer. Because of the experimental determination of this data, large chunks of information are of unknown purpose (and mostly constant) and are listed without comment. Other mandatory (and universal) SCSI commands are not documented here. These include 0x00 (Test unit ready) and 0x12 (Inquiry). Multi-byte information is in the big-endian format (MSB first) in both the CDB and data blocks. General Pictor communication concepts ------------------------------------- The Pictor camera is treated like a scanner and, if referring to standard SCSI documents, the commands are used in the scanner context (eg command 0x25 is the Get Window variation rather than Read Capacity). The information here covers basic control of the camera only and does not cover any of the things that would have required an LX200 to determine (if these are in fact functions of the camera interface). Communication with the camera is basically one of these things: - Request for camera status (ie temperature information) - Setting the camera status (ie thermostat temperature) - Starting an exposure and downloading the data Reading the camera's state simply requires issuing a mode sense command (0x1A) and the Pictor returns a 144-byte status in the Data-In block. Similarly setting the camera's state is done with the mode select command (0x15) with a 144-byte status in the Data-Out block. Taking an exposure typically requires a sequence like this: - set scan window, exposure time, binning, etc with the set window command (0x24). - send a mode sense command (0x1A). The exact purpose of this is unclear but it seems to be necessary. - send the scan command (0x1B) to start the exposure. - wait for the exposure and data transfer from camera to interface to complete by polling with the test unit ready command (0x00). - (At this point PictorView uses the get window command (0x25), presumably to verify the settings and/or fetch the exact image configuration for the purposes of memory allocation. This is not required but perhaps good practice) - Download the data with the read command (0x28). ***************** Command details ***************** This section details the data for the descriptor and data blocks in the following SCSI commands: Inquiry (0x12) Set window (0x24) Get window (0x25) Mode sense (0x1A) Mode select (0x15) Scan (0x1B) Read (0x28) Inquiry (0x12) -------------- Read-mode, 6-byte CDB The inquiry command is used to identify a SCSI device and determine any specific modes of use. CDB: Byte Description Contents 0 Op code 12 1 Reserved 00 2 Page/op 00 3 Reserved 00 4 Allocation len 50 5 Control 00 0x50 byte data block returned by Pictor: Addr Hex dump Ascii dump 00 06 00 02 02 48 00 00 00 4D 45 41 44 45 20 20 20 ....H...MEADE 10 50 69 63 74 6F 72 20 34 31 36 20 20 20 20 20 20 Pictor 416 20 50 72 6F 64 32 2E 30 30 20 20 00 52 4F 4D 20 64 Prod2.00 .ROM d 30 61 74 65 3A 32 38 2D 53 65 70 2D 39 35 00 53 65 ate:28-Sep-95.Se 40 72 69 61 6C 20 23 3A 20 20 20 20 20 20 20 30 00 rial #: 0. In detail: Addr Data Meaning 00 06 bits 0-4 = device type (6=scanner) 01 00 bit 7 = removable medium (0=not) 02 02 bits 0-2 = ANSI version (2=ANSI X3.131-1994 (SCSI-2)) 03 02 bits 0-2 = response data format (2=normal) 04 48 additional length (n-4) (48 = 0x4C extra bytes) 05 00 reserved 06 00 misc bits 07 00 misc bits 08-0F ascii Vendor ID ("MEADE ") 10-1F ascii Product ID ("Pictor 416 ") It appears the remaining data is not standard conforming. The standard specifies 20-23 = Product revision, 24-37 = Vendor specific, 38-5F = reserved. The Pictor 416 returns this ascii text: 20-4F ascii Prod2.00 \x00ROM date:28-Sep-95.Serial #: 0\x00 where \x00 are NULL bytes Set window (0x24) ----------------- Write-mode, 10-byte CDB The set window command is a scanner-specific command used to set the rectangle for scanning. CDB: Byte Description Contents 0 Op code 24 1 Reserved 00 2 Page/op 00 3 Reserved 00 4 Reserved 00 5 Reserved 00 6 Reserved 00 7 Data len (MSB) 00 8 Data len (LSB) 4E 9 Control 00 Data block (78 = 0x4E bytes): Addr Description dump example 00 ??? 00 00 00 00 04 ??? 00 00 00 46 08 (Window identifier) 01 09 Reserved 00 0A X resolution (pixels/inch) 0B 06 (for 9um pixels) 0C Y resolution (pixels/inch) 0B 06 (for 9um pixels) 0E window left edge (4 bytes) 00 00 00 00 12 window top edge (4 bytes) 00 00 00 00 16 window width (4 bytes) 00 00 03 00 (768) 1A window height (4 bytes) 00 00 02 00 (512) 1E (scanner brightness setting) 00 1F (scanner threshold setting) 00 20 (scanner contrast setting) 00 21 (image type, 2=greyscale) 02 22 (bits per pixel) 00 23 (scanner halftone pattern) 00 00 25 (reverse image) 00 26 (bit ordering) 00 00 28 (compression type) 00 29 (compression arg) 00 2A (reserved) 00 00 2C exposure in ms (4 bytes) 00 00 03 E8 (1000 ms) 30 ??? 00 00 00 00 34 ??? 00 00 00 00 38 ??? 00 00 7F FE 3C ??? 00 00 2F 03 40 ??? 00 00 00 00 44 ??? 00 00 00 47 shutter control? 00 (normal mode) 48 ??? 00 00 00 00 4C ??? 00 00 Notes: - The first 8 bytes are presumably a standard header. - Descriptions in brackets are mainly for 'normal' scanners and are effectively irrelevant for the Pictor. - The X and Y resolutions are in pixels per inch. Since the Pictor has 9um pixels (Kodak KAF-0400 and Kodak KAF-1600 CCDs) this is 25.4mm/9µm = 2822 = 0x0B06. For 2x2 analogue binning the pixel density is halved to 0x0583. There is probably no point in binning any higher than this since download speed is not really an issue and values other than 0x0B06 and 0x0583 have not been tested. - The window position and size are all in actual pixels. ie the values are absolute regardless of resolution specified. - The shutter control appears to be affected by byte 0x47 with a value of 0x00 being normal (open the shutter for length of exposure) and 0x04 for dark frame (keep the shutter closed while exposing). Get window (0x25) ----------------- Read-mode, 10-byte CDB The get window command is a scanner-specific command used to read the current settings of the scan rectangle and related parameters. CDB: Byte Description Contents 0 Op code 25 1 ? 01 2 ? 00 3 ? 00 4 ? 00 5 ? 01 6 ? 00 7 Data len (MSB) 00 8 Data len (LSB) 4E 9 Control 00 Data block (78 = 0x4E bytes): Addr Description dump example 00 ??? 00 4E 00 00 04 ??? 00 00 00 46 08 (Window identifier) 01 09 Reserved 00 0A X resolution (pixels/inch) 0B 06 (for 9um pixels) 0C Y resolution (pixels/inch) 0B 06 (for 9um pixels) 0E window left edge (4 bytes) 00 00 00 00 12 window top edge (4 bytes) 00 00 00 00 16 window width (4 bytes) 00 00 03 00 (768) 1A window height (4 bytes) 00 00 02 00 (512) 1E (scanner brightness setting) 00 1F (scanner threshold setting) 00 20 (scanner contrast setting) 00 21 (image type, 2=greyscale) 02 22 (bits per pixel) 00 23 (scanner halftone pattern) 00 00 25 (reverse image) 00 26 (bit ordering) 00 00 28 (compression type) 00 29 (compression arg) 00 2A (reserved) 00 00 2C exposure in ms (4 bytes) 00 00 03 E8 (1000 ms) 30 ??? 00 00 03 E8 34 ??? 00 00 00 00 38 ??? 00 00 7F FE 3C ??? 00 63 00 03 40 ??? 00 00 02 02 44 ??? 00 04 80 C3 48 ??? 01 00 00 00 4C ??? 00 00 Mode sense (0x1A) ----------------- Read-mode, 6-byte CDB The mode sense command returns general parameter information about the device. CDB: Byte Description Contents 0 Op code 1A 1 bit 3=DBD 08 2 page code 09 3 reserved 00 4 Data len 90 5 Control 00 The first 128 bytes appear to be useless: Addr Hex dump ascii dump 00 90 00 00 00 89 8A AB CD 00 00 00 00 01 00 00 00 ................ 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 20 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 30 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 40 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 50 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 60 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 70 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... Addr Description eg dump 80-82 ??? 00 00 80 83 Cooling power sense (%) 00 84-85 Target temperature (0.1°C 2's comp) 11 9E 86-87 Chip temperature (0.1°C 2's comp) 11 9E 88-89 Case temperature (0.1°C 2's comp) 00 D2 8A-8F ??? 44 44 00 44 44 44 Values of 0x119E in target and chip temperatures appear to be returned when the thermostat is disabled meaning that chip temperature cannot be read unless the cooler is running. Mode select (0x15) ----------------- Write-mode, 6-byte CDB The mode select command sets general parameter information for the device. CDB: Byte Description Contents 0 Op code 1A 1 PF/SP 10 2 reserved 00 3 reserved 00 4 Data len 90 5 Control 00 The first 128 bytes look something like this (don't know what it's for): Addr Hex dump ascii dump 00 00 00 00 00 09 8A AB CD 00 00 00 00 01 00 00 00 ................ 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 20 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 30 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 40 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 50 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 60 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... 70 00 00 3C 65 6D 70 74 79 3E 00 00 00 00 00 00 00 ......... Addr Description eg dump 80 purpose unknown (preserve from read?) 00 00 80 83 power sense (value irrelevant?) 00 84 target temperature (0.1°C, &07FF=off) 11 9E 86 chip temp (value irrelevant?) 11 9E 88 case temp (value irrelevant?) 01 01 8A purpose unknown (preserve from read?) 44 44 00 44 44 44 Scan (0x1B) ----------- Write-mode, 6-byte CDB The scan command is specific to scanners and initiates a scan operation. For the Pictor this means 'starts the exposure'. CDB: Byte Description Contents 0 Op code 1B 1 ??? 00 2 ??? 00 3 ??? 00 4 Data len 01 5 Control 00 Only a single byte is in the data block: Addr Description eg dump 00 Unknown 01 Read (0x28) ----------- Read-mode, 10-byte CDB The read command is a general SCSI command for fetching data from a device. CDB: Byte Description Contents 0 Op code 28 1 ? 00 2 ? 00 3 ? 00 4 ? 00 5 ? 00 6 ? 00 7 Data len (MSB) FF 8 Data len (LSB) FE 9 Control 00 The Pictor seems to be capable of transferring at least 0xFFFE bytes per command (PictorView uses 0xFF8, test attempts to transfer 0x10000 bytes may have failed because of either the Pictor or the OS interface - exactly which could not be determined). Data is returned in a continuous stream of 16-bit words (MSB first). On the operating system that these tests were done it is possible to continuously request 0xFFFE byte blocks and the end of data can be detected automatically by the fact that a non-zero number of bytes did not transfer. ie it is not necessary to pre-calculate how many bytes the image will require.