DRS Technologies Tamarisk 320 Technical manual

Tamarisk®320
17 μm 320x240 Long Wave Infrared Camera
Software Interface Control Document
Document No: 1012819
Revision: E

©Copyright 2013, DRS TECHNOLOGIES, Inc.- All rights reserved.
13532 N. Central Expressway
Dallas, TX 75243
877.377.4783
www.drsinfrared.com
The contents of this document may not be reproduced in whole or in part
without the written consent of the copyright owner.
NOTICE
ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED
WITHOUT WARRANTY OF ANY KIND. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE ARE
PROVIDED “AS IS” WITH ALL FAULTS. DRS DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE,
OR TRADE PRACTICE.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE
LICENSE OR LIMITED WARRANTY, CONTACT YOUR DRS REPRESENTATIVE FOR A COPY.
IN NO EVENT SHALL DRS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF DRS HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Rev History
Revision Number Release Date Description
C 03/15/2012 Initial Release
D 07/24/2012 Added customer NV read write commands, pixel map,
and AGC ROI Commands
E 11/1/2013
Ported over Tamarisk®640 revision B.2 document.
Change this document for Tamarisk®320. Corrected
non-volatile default values. Added version
requirements for certain features. Clarified 0xd7
command. Made changes in preparation for public
release. New ICE Commands added
Camera Link® is a registered trademark of the Automated Imaging Association.

Tamarisk®320 Software ICD
i
TABLE OF CONTENTS
Table of Contents.....................................................................................................................i
Acronyms and Abbreviations..................................................................................................ii
Reference Documentation.....................................................................................................iii
Safety Instructions .................................................................................................................iv
Notifications: Caution, Warning and Note.................................................................................. iv
1Scope.............................................................................................................................. 5
1.1 Systems Overview............................................................................................................5
1.2 Document Overview .........................................................................................................5
2Message Format - General............................................................................................. 6
2.1 Checksum Computation ...................................................................................................7
2.2 Command Message Format .............................................................................................8
2.3 Response Message Format..............................................................................................8
2.4 Response Message Timing ............................................................................................11
2.5 Command/Response Sequence.....................................................................................12
2.6 Camera Memory Data download ....................................................................................12
2.7 Camera Data Upload......................................................................................................17
3Operational Commands................................................................................................ 21
3.1 System Commands........................................................................................................21
3.2 Field Calibration Commands...........................................................................................31
3.3 AGC Commands ............................................................................................................37
3.4 Zoom Commands...........................................................................................................53
3.5 Non-Volatile Parameters Commands..............................................................................56
3.6 Pixel Map Commands.....................................................................................................67
3.7 Troubleshooting Commands...........................................................................................73
4Command Quick-Reference ......................................................................................... 79

Tamarisk®320 Software ICD
ii
ACRONYMS AND ABBREVIATIONS
Abbreviation
Description
Abbreviation
Description
°C
Celsius
mm
millimeter
°F
Fahrenheit
ms
milliseconds
AGC
automatic gain control
MSB
Most Significant Bit
BPR
bad pixel replacement
MTU
Maximum Transfer Unit
CCA
circuit card assembly
MWIR
Mid-wave infrared
CL
center line
NETD
noise equivalent temperature difference
COMM
communication
NTSC
National Television System Committee
CSC
Computer Software Component
NUC
non-uniformity correction
CSCI
Computer Software Configuration Item
NVTHERM
Night Vision Thermal Analysis Tool
CSU
Computer Software Unit
OEM
original equipment manufacturer
dB
decibels
OLA
Optical Lens Adapter
DSP
digital signal processor
P
probability
ESD
electrostatic discharge
POL
polarity
E-Zoom
electronic zoom
psi
pound per square inch
FOV
field of view
Rev
revision
FPA
Focal Plane Array
ROI
region of interest
ft
feet
SC
split configuration
G
gravitational force
SWIR
Short-wave infrared
g
gram
TBD
To Be Determined
GUI
graphical user interface
TCR
Temperature coefficient of resistance
H
height
TIM
Thermal Imaging Module
HFOV
horizontal field of view
UART
Universal Asynchronous Receiver Transmitter
I/O
input/output
UAV
unmanned aerial vehicle
ICD
Interface Control Document
UFPA
Un-cooled Focal Plane Array
ICE
Image Contrast Enhancement
USB
Universal Serial Bus
ID
identification
V
Vertical or Voltage
IR
infrared
VDC
volts direct current
IRS
Interface Requirements Specification
VGA
video graphics array
km
kilometer
VOx
Vanadium Oxide
LR
lower right
W
width or Watt
LWIR
long-wave infrared
μm
micron (micrometer)

Tamarisk®320 Software ICD
iii
REFERENCE DOCUMENTATION
The following documents form part of this specification. In the event of a conflict between
documents referenced herein and the contents of this specification, the contents of this specification
shall be considered a superseding requirement.
Document No: 1012593 Tamarisk®320 User Manual
Document No: 1012820 Tamarisk®320 Electrical Interface Control Document
Document No: 1012821 Tamarisk®320 Camera Control Software User Guide
Document No: 1003727 Tamarisk®320 Mechanical Interface Control Document

Tamarisk®320 Software ICD
iv
SAFETY INSTRUCTIONS
NOTIFICATIONS: CAUTION, WARNING AND NOTE
Throughout this manual, notifications are used to alert the user’s to potential risks and to minimize
the potential for personal injury and or damage to the product. When a notification is present, it is
important that the user review and understand all statements related to the notification before
proceeding. If questions arise, please contact your authorized dealler or DRS Technologies.
Notifications are preceeded by a symbol and followed by highlighted text. Three types of
notifications are used throughout this manual and are defined below:
CAUTION
A caution is a procedure, practice, or condition that, if not strictly followed, may
result in personal injury or damage to the equipment that may impede product
performance.
WARNING
A warning is intended to alert the user to the presence of potentially harmful
circumstances and provide precautionary guidance for mitigating risk of personal
injury and or damage to the product.
NOTE
A note is a statement that clarifies or is used to emphasize important information.
1. Read all instructions
2. Keep these instructions for future reference.
3. Follow all instructions
4. Heed all warnings.
5. Do not submerge this apparatus in liquid of any kind.
6. Clean per recommended instructions using dry non-abrasive cloth.
7. Do not install near any sources of intense heat such as radiators, furnaces,
stoves or other apparatus that regulary produce excessive heat.
8. Refer all servicing to qualified service personnel

Tamarisk®320 Software ICD
5
1SCOPE
This document describes the serial protocols and command interface for systems employing the
Tamarisk®320 Software Architecture. The Tamarisk®320 Software Architecture is a design for an
infrared thermal imaging core that uses an un-cooled focal plane array (UFPA).
1.1 SYSTEMS OVERVIEW
A thermal imaging module (TIM) based on the Tamarisk®320 Software Architecture communicates
with a connected device via the serial protocol described herein. The connected device is often a
personal computer (PC) running a graphical user interface (GUI) but may be a controller in an
embedded system. The connected device uses the serial protocol to configure, control, and monitor
status of the thermal imaging module.
Additionally, specific features of the system are tested by the serial protocol. This feature is useful
for troubleshooting anomalous TIMs.
1.2DOCUMENT OVERVIEW
This document describes the commands, parameters, and responses of the Tamarisk®320 Software
Architecture. The Tamarisk®320 Software Architecture is not a product in and of itself; it is a
component in a system. This document describe the commands for this specific component. Other
individual systems based on the Tamarisk®320 Software Architecture may include additional
commands that are specific to that system.
This document does not describe the physical interface to the system. The physical interface will
vary for each system. Typically, the serial protocol is transported over RS-232 links but USB and
LVCMOS UART interfaces are supported. The Tamarisk®320Electrical Interface Control
Document describes the connectors, voltage levels, framing, and data rates on which this protocol
resides. See Reference Documents for details.

Tamarisk®320 Software ICD
6
2MESSAGE FORMAT -GENERAL
The serial protocol allows the user to control and monitor status of the thermal imaging module.
Every message transmitted or received over the serial interface uses the same message format. The
message contains the following components:
1. Start Character – this is always 0x01. It identifies the start of a new message. Note
that the start character is not guaranteed to be unique in the serial data stream. Other
fields within the message may also contain this value.
2. Command Byte – This byte determines the type of command to be performed. For
responses, this byte identifies the type of response.
3. Parameter Length – this byte specifies the count of any additional parameter bytes
included in the message. If the message does not require any additional parameter
bytes this value will be zero. Note that the overall message length is limited by the
MTU size (see below).
4. Parameters – These bytes contain any parameters, or other data for the message.
Generally, the content and format of this data will depend on the specific message
type. However, a few general rules apply:
♦When parameter bytes contain strings, these are typically null-terminated arrays of
ASCII codes.
♦When data bytes contain integer or floating-point values, these are sent in big-endian
order – e.g., the MSB is sent first. This statement is true for both 16 and 32-bit
values.
5. Checksum – This is the frame check sequence for the message. It includes all bytes in
the message from the start character to the last parameter byte. It is calculated with the
formula in paragraph 2.1.
The Maximum Transfer Unit (MTU) size of the serial stream is 252 bytes. .
The parameter length for most messages is an even number of bytes (there are exceptions). This is
due to the 16-bit legacy architectures for which the protocol was developed.
The message format is illustrated below:
Table 1 – General Message Format
Byte Value/Type Description
1 0x01 (always) Start of message.
2 Unsigned integer Command ID.
3 0 to 252 Parameters length.
4 to
(N + 3) Message dependent Additional Data (0 to 252 bytes).
(N + 4) checksum Frame check sequence. See paragraph 2.1.

Tamarisk®320 Software ICD
7
2.1CHECKSUM COMPUTATION
Every message has an appended 8-bit checksum. The checksum is computed using all bytes in the
message from the start character to the last data byte.
=()

 256
Note that summing the negative byte values must be performed using 2’s-complement math, which
is common on most processors. Below is example code that computes the message checksum:
Uint8
ComputeChecksum (Uint8 uy_message_id,
Uint8 * pauy_parameters,
Uint32 ul_parameters_size_in_bytes)
{
Uint8 uy_message_checksum = 0 ;
uy_message_checksum -= 0x01 ; // start character
uy_message_checksum -= uy_message_id ;
uy_message_checksum -= ul_parameters_size_in_bytes ;
while (ul_parameters_size_in_bytes --)
{
uy_message_checksum -= * pauy_parameters ++ ;
}
uy_message_checksum &= 0xFF ;
return uy_message_checksum ;
} // ComputeChecksum
Alternatively, the checksum may be computed using the equivalent formula that follows:
Checksum = (~(two’s complement sum of all message byte) + 1)& 0xFF
For example, let’s say that the checksum for 0x01 0x2A 0x02 0x00 0x01 needs to be computed.
The two’s complement sum of all the message bytes would be
0x01 + 0x2A + 0x02 + 0x00 + 0x01 = 0x2E
Next, the formula indicates that the 0x2E must be inverted.
~0x2E = 0xFFF…FFFD1
Then, 1 must be added.0xFFF…FFFD1 + 1 = 0xFFF…FFFD2
Finally, a bit-wise AND with 0xFF needs to be performed.
0xFFF…FFFD2 & 0xFF = 0xD2.

Tamarisk®320 Software ICD
8
Note that the bit-wise AND operation ensures the checksum length remains 1 byte.
2.2COMMAND MESSAGE FORMAT
All commands originate from the connected device and are sent to the thermal imaging module
(TIM). The TIM does not originate commands but it may send occasional text messages.
All commands conform to the general message format. The command byte identifies the specific
command to be performed. Additional data bytes are included in the command as required. Refer
to command details section for specifics.
The module will be ready to accept commands within 2 seconds of power-on.
2.3 RESPONSE MESSAGE FORMAT
All commands sent to the TIM are expected to receive at least one response message (exception:
changing the baudrate command will not produce a response).
In general, systems communicating with the TIM should wait for the response message prior to
subsequent messages being sent.
If the TIM finds a message format error or bad checksum, the TIM will not send a response.
If the message format and checksum is correct, but the command is not recognized, the TIM will
send an Error (ERR) response. The error response may include a descriptive string that describes
the error.
If the received message is properly formatted (including checksum) and the command is
recognized, the TIM will generate an Acknowledgement (ACK) response.
On select commands, the module may send other responses. The type of response depends on the
command that was received. Response types are:
♦A text message. These are output using the TXT identifier. The text message will
contain the requested information or other feedback (see the individual message
detail) as null-terminated ASCII strings.
♦A value message. These are output using the VALUE identifier. The value message
includes a 16-bit numerical value.
♦The original command. The command will contain new parameters that include the
response data.
Table 2 – Response Message Types
Name Command
ID Additional data
Text message (TXT) 0x00
Text message (variable # of bytes defined in the
Data Length field)
Note: to receive a text message, the module must
have debug message mode ON.

Tamarisk®320 Software ICD
9
Acknowledgement (ACK) 0x02 Data filed includes16-bit command ID of the serial
command that is being acknowledged
Not acknowledged (NAK) 0x03 Data filed includes 16-bit command ID of the serial
command that is being unacknowledged
Error (ERR) 0x04 Data filed include 16-bit command ID of the serial
command that is in error
16-bit integer return value
(VALUE) 0x45 16-bit integer value broken up into 2 bytes
CMD Cmd Returns command code with response data
2.3.1 TXT Response
The TXT (Text) response provides feedback in human-readable form. The TXT message
contains an ASCII string of arbitrary length (the entire message must be less than the MTU
size). The connected unit may display the ASCII text as it sees fit or may discard the
information.
Table 3–TXT Response Format
Byte Value/Type Description
1 0x01 Start of message.
2 0x00 TXT Response ID.
3 N Number of text bytes to follow.
4 to
(N+3) ASCII chars ASCII text. Null termination not required.
(N+4) checksum Frame check sequence. See paragraph 2.1.
Table 4 –Example TXT Response
Byte Value/Type Description
1 0x01 Start of message.
2 0x00 TXT Response ID.
3 0x06 Text message contains 6 characters.
4 to 9
0x48 (“H”)
0x6F (“o”)
0x77 (“w”)
0x64 (“d”)
0x79 (“y”)
0x21 (“!”)
ASCII text (“Howdy!”)
10 checksum Frame check sequence. See paragraph 2.1.
2.3.2 ACK Response
The ACK response is a general-purpose acknowledgement that a command has been
received. Some commands will result in two ACK messages – one generated upon receipt

Tamarisk®320 Software ICD
10
of the command and a second generated upon completion of the command. The ACK
message contains the ID of the command being acknowledged.
Table 5 –ACK Response Format
Byte Value/Type Description
1 0x01 Start of message.
2 0x02 ACK Response ID.
3 0x02 ACK responses always have 2 parameter bytes.
4, 5 Command ID ID of command that is being ACK’d. Command IDs are 8 bits
in commands but are extended to 16 bits in an ACK.
6 checksum Frame check sequence. See paragraph 2.1.
2.3.3 NAK Response
The NAK response is generated to indicate a command cannot be processed for some
reason. The Tamarisk®640 architecture currently does not use the NAK response.
Table 6– NAK Response Format
Byte Value/Type Description
1 0x01 Start of message.
2 0x03 NAK Response ID.
3 0x02 NAK responses always have 2 parameter bytes.
4, 5 Command ID ID of command that is being NAK’d. Command IDs are 8 bits
in commands but are extended to 16 bits in an NAK.
6 checksum Frame check sequence. See paragraph 2.1.
2.3.4 ERR Response
The ERR response is generated when a command is not recognized or when an error occurs
during the processing of a command. There are two formats for the ERR response. The first
format contains only the ID of the command that generated the error. The second format
contains an informative text message.
Table 7– ERR ID Response Format
Byte Value/Type Description
1 0x01 Start of message.
2 0x04 ERR Response ID.
3 0x02 ERR responses always have 2 parameter bytes.
4, 5 Command ID ID of command that caused ERR. Command IDs are 8 bits in
commands but are extended to 16 bits in an ERR.
6 checksum Frame check sequence. See paragraph 2.1.

Tamarisk®320 Software ICD
11
Table 8– ERR String Response Format
Byte Value/Type Description
1 0x01 Start of message.
2 0x04 ERR Response ID.
3 N Number of text bytes to follow.
4 to
(N+3) ASCII chars ASCII text string that contains error message. Null termination not required.
(N+4) checksum Frame check sequence. See paragraph 2.1.
2.3.5 VALUE Response
The VALUE response is generated when a command returns a single 16-bit integer value.
Table 9– VALUE Response Format
Byte
Value/Type
Description
1 0x01 Start of message.
2 0x45 VALUE Response ID.
3 0x02 VALUE responses always have 2 parameter bytes.
4, 5 Unsigned integer Value.
6 checksum Frame check sequence. See paragraph 2.1.
2.3.6 CMD Response
The command response is generated by any command that requires a response that does not
fit any of the prior response types. The content of the response is dependent on the
command and the nature of the response.
Table 10 – CMD Response Format
Byte
Value/Type
Description
1 0x01 Start of message.
2 Command ID ID of corresponding command.
3 N Number of bytes to follow.
4 to
(N+3) varies The contents of this field depend on the command and response type.
(N+4) Checksum Frame check sequence. See paragraph 2.1.
2.4 RESPONSE MESSAGE TIMING
An ACK response will nominally be returned within 1 second of the command being sent.
However, there are exceptions:

Tamarisk®320 Software ICD
12
1. If the command causes flash memory to be erased or programmed, the command can
take somewhat longer before generating an ACK. The time is dependent on a number
of factors:
♦The number of flash sectors being erased or programmed. More sectors will require
more time.
♦The temperature of the flash. Colder flash parts require more time to erase and
program.
2. The response time for non-ACK response (ERR, NAK, etc) types depends on the type
of command.
2.5 COMMAND/RESPONSE SEQUENCE
Generally, every command is followed by an ACK response. However, there are numerous
exceptions:
1. Some commands will return a VALUE response or a response having the same
message ID as the command followed by and ACK.
2. Data transfer activities have a unique message sequence that is dependent on whether
an upload or download is requested, the size of the transfer, and any errors that may
occur during transfer.
2.6 CAMERA MEMORY DATA DOWNLOAD
Information in non-volatile memory may contain some information that is useful in system
development. Table 18 shows the data available in non-volatile storage. A sequence of commands
is required to download this information, and the information will need to be parsed according to
the table. Figure 1 shows the command sequence between the connected unit (CU) and the thermal
imaging module (TIM).
CU
TIM
0x73 (10)
0x02 (2)
0x41 (248)
0x47 (0)
Download Packet
Download Setup
Complete
ACK

Tamarisk®320 Software ICD
13
Figure 1 - Download command sequence
2.6.1 Download from Thermal Imaging Module (TIM) to Connected Unit (CU)
A download from the TIM is initiated by the CU with the “Data Transfer Download Setup”
message (0x73). This messages has five, 16-bit parameters (10 bytes total). The parameters
identify the device; region, range, and size of the download (see Figure 1)
The TIM checks the size and region parameters and, if acceptable, responds with an ACK
(0x02).
The TIM then begins sending packets to the CU using “Data Transfer Download Packet”
messages (0x41). Each packet message carries a payload whose size is always an even
number of bytes. The payload packet contains a packet number (16-bits) and packet
payload bytes. Payload size has historically been 244 bytes. The packet number is a zero-
based, integer count packets. It is used to detect missing packets and to initiate retries. The
TIM continues to transmit packets until the entire object is transmitted.
At any time during the transmission, the CU may send a “Data Transfer Upload Retry”
message (0x46) to indicate an error. The retry contains one 16-bit parameter that is the
packet number of the last packet received in order. Upon receipt of this message, the TIM
will retransmit all packets following the packet number.
At any time, the CU may send a “Data Transfer Abort” message (0x43). Upon receipt of
this message, the TIM will terminate transmission of packets, reset its internal state
machines, and await a new setup message.
Following receipt of the last data packet, the CU will send a “Data Transfer Download
Complete” message (0x47). This message indicates that the entire object has been received
intact by the CU and that data transfer operations will cease.
2.6.1.1 Data Transfer Download Setup – 0x73
Description: Setup a download from the TIM to the connected unit.
Command Format:
Table 11 – Data Transfer Download Setup Command Format
Byte Value Description
1 0x01 Start of message.
2 0x73 Data Transfer Download Setup Command ID.
3 0x0A Parameters length.
4 to 7 unsigned integer Transfer size in bytes.
8, 9 unsigned integer 0x0001
10, 11 unsigned integer 0x001A
12, 13 unsigned integer 0x0000.
14 Checksum Frame check sequence.

Tamarisk®320 Software ICD
14
Response Format:
Table 12 – Data Transfer Download Setup Response Format
Byte Value Description
1 0x01 Start of message.
2 0x02 ACK response.
3 0x02 Parameters length.
4, 5 0x0073 Data Transfer Download Setup Command ID.
6 Checksum Frame check sequence.
2.6.1.2 Data Transfer Download Packet – 0x41
Description: Carries payload bytes for the data transfer download.
Command Format:
Table 13 – Data Transfer Download Packet Command Format
Byte Value Description
1 0x01 Start of message.
2 0x41 Data Transfer Download Packet Command ID.
3 N Parameters length.
4, 5 unsigned integer Packet number. The first packet is 0.
6 to
(N+3) (any) Packet payload. The number of bytes in this array varies.
These are a portion of the bytes of the payload object being
sent from the TIM.
(N+4) Checksum Frame check sequence.
Response Format:
There is no response to this command unless packet is corrupted or is the last packet of
the transfer.
•If this packet is corrupted, the CU should generate a “Data Transfer Download Retry”
message (0x46) containing the packet number of the expected packet.
•If this packet is the last packet of the transfer, the CU should generate a “Data
Transfer Download Complete” message (0x47) that contains success status.
2.6.1.3 Data Transfer Download Retry – 0x46
Description: Setup a download from the TIM to the connected unit.
Command Format:

Tamarisk®320 Software ICD
15
Table 14 – Data Transfer Download Retry Command Format
Byte Value Description
1 0x01 Start of message.
2 0x46 Data Transfer Download Packet Command ID.
3 0x02 Parameters length.
4, 5 unsigned integer Packet number of expected packet.
6 Checksum Frame check sequence.
Response Format:
There is no response to this command other than to resume packet transmission at the
packet number of the expected packet. All packets following the expected packet shall be
retransmitted.
2.6.1.4 Data Transfer Download Complete – 0x47
Description: Indicates the CU has received all packets of the download and data transfer
operations will cease.
Command Format:
Table 15 – Data Transfer Download Complete Command Format
Byte Value Description
1 0x01 Start of message.
2 0x47 Data Transfer Download Complete Command ID.
3 0x00 Parameters length.
4 Checksum Frame check sequence.
Response Format:
There is no response to this command. Upon receipt of this command, the TIM will cease
data transfer operations.
2.6.1.5 Data Transfer Abort – 0x43
Description: Abort a data transfer. This command can be used to abort both uploads and
downloads.
Command Format:
Table 16 – Data Transfer Abort Command Format
Byte Value Description
1 0x01 Start of message.
2 0x43 Data Transfer Abort command ID.

Tamarisk®320 Software ICD
16
3 0x00 Parameters length.
4 Checksum Frame check sequence.
Response Format:
Table 17 – Data Transfer Abort Response Format
Byte Value Description
1 0x01 Start of message.
2 0x02 ACK response
3 0x02 Parameters length.
4, 5 0x0043 Data Transfer Abort command ID.
6 Checksum Frame check sequence.
2.6.2 Non-volatile Camera System Information.
There is information contained in the non-volatile memory that some customers may desire
to use for their products, such as camera part numbers and serial numbers. This information
is downloadable and parsable based on the information in Table 18. The Data Transfer
Download Setup Command (0x73) is used to download this information. To download the
data shown in Table 18 the user would write the following serial command to the camera:
0x01 0x73 0x0a 0x00 0x00 0x00 0x01 0x00 0x01 0x00 0x1a 0x00 0x00 0x66
Table 18 – TIM Manufacturing Information
Item Length (in bytes) Conversion from raw bytes
Mfg date information 2Year = int(data[0]) * 256 + int(data[1])
Mfg date information 1Month = int(data[2])
Mfg date information 1Day = int(data[3])
Mfg date information 2Year = int(data[4]) * 256 + int(data[5])
Mfg date information 1Month = int(data[6])
Mfg date information 1Day = int(data[7])
Mfg date information 2Year = int(data[8]) * 256 + int(data[9])
Mfg date information 1Month = int(data[10])
Mfg date information 1Day = int(data[11])
Mfg calibration information 6Chamber = string(data[12:17])
Mfg calibration information 6Position = string(data[18:23])
Mfg calibration information 10 Version = string(data[24:33])
Mfg software information 10 Version = string(data[34:43])
Mfg software information 10 Version = string(data[44:53])
Module Part Number 20 Part Number = string(data[54:73])
Module Serial Number 20 Serial Number = string(data[74:93])

Tamarisk®320 Software ICD
17
Item Length (in bytes) Conversion from raw bytes
Detector Part Number 20 Part Number = string(data[94:113])
Detector Serial Number 20 Serial Number = string(data[114:133])
2.7 CAMERA DATA UPLOAD
If the Tamarisk®320 camera is integrated in a system there may be occasions an embedded firmware
or embedded hardware programs could require an update. Customers that desire supporting that
update through their software or hardware would follow the upload procedure described below:
An upload to the TIM is initiated by the CU (connected with the “Data Transfer Upload Setup”
message (0x74). This messages has 9, 16-bit parameters (18 bytes total). The parameters identify
the device, region, range, size and CRC of the upload (see Figure 2).
Figure 2– Upload to TIM Message Sequence Diagram
The TIM checks the size and region parameters and, if acceptable, responds with an ACK and
setup response. The setup response message has the same command ID as the setup message
(0x74) and has 3, 16-bit parameters.
The CU then begins sending packets to the TIM using “Data Transfer Upload Packet” messages
(0x72). Each packet message carries a payload whose size is always an even number of bytes. The
payload packet contains a packet number (16-bits) and packet payload bytes. Payload size has
CU
TIM
0x74 (18)
0x02 (2)
0x74 (3)
0x72 (244)
0x72 (244)
…
0x72 (244)
0x72 (4)
0x72 (4)
…
0x72 (244)
0x72 (202)
0x72 (4)
0x72 (244)
Upload
Setup
ACK
Upload Packet
Upload
Packet
Upload Packet
Pause
Resume
Upload Packet
Upload Packet
Upload Packet
Upload Setup
Sector Burning (8)
Burning Complete (9)
Sector Burning (8)
0x72 (4)
Transfer Complete (10)
Flash
Sector
Flash
Sector

Tamarisk®320 Software ICD
18
historically been 244 bytes. The packet number is a zero-based, integer count packets. It is used to
detect missing packets and to initiate retries.
At any time, the TIM may send a “Data Transfer Upload Packet” (0x72) message to the CU to
control the flow of packets or to indicate an error condition. This flow control message includes 2,
16-bit parameters. The first is a response ID and the second is a packet number. When the CU
receives the flow control message, it should respond as indicated in Table 24
At any time, the CU may send a “Data Transfer Abort” message (0x43). Upon receipt of this
message the TIM will reset its internal state machines and await a new setup message.
Following transmission of the last data packet, the TIM will send a flow control message with
ID=8 to indicate flash is being programmed followed by a flow control message with ID=10 to
indicate that the upload has been successful, the flash burn is complete, data transfer operations
will now cease.
2.7.1 Data Transfer Upload Setup – 0x74
This message is used as both a command to the TIM and a response to the CU.
Description: Sets up a transfer from the connected unit to the TIM.
Command Format:
Table 19 – Data Transfer Upload Setup Command Format
Byte Value Description
1 0x01 Start of message.
2 0x74 Data Transfer Upload Setup Command ID.
3 0x12 Parameters length.
4, 5 Unsigned integer 0x00, 0x00
6, 7 Unsigned integer 0x00, 0x01
8, 9 Unsigned integer Software: 0x00, 0x0C FPGA:0x00, 0x0E
9, 10 Unsigned integer 0x00, 0x00
10, 11 Unsigned integer 0x00, 0x00
12, 13 Unsigned integer 0x00, 0x00
14, 17 Unsigned integer Total size of transfer.
18, 19 Unsigned integer CRC of entire transfer.
20 checksum Frame check sequence.
Response Format:
Table 20 – Data Transfer Upload Setup Response Format
Byte Value Description
1 0x01 Start of message.