#
# CAMERA_MODEL 	"Hamamatsu ORCA-flash4.0"
#

# camera description, for camera selection GUI and apps
# camera_class should be the manufacturer's name
#
camera_class:                  "Hamamatsu"
camera_model:                  "ORCA-flash4.0, 16-bit, 5-tap"
camera_info:                   "2048x2048 (freerun)"

# actual width/height (total pixels) and depth of data from camera
# to only grab high 8-bits, set depth to 8 but leave extdepth set
# to actual depth, and adjust shift and mask accordingly
#
width:                         2048
height:                        2048
depth:                         16
extdepth:                      16

# camera link data path register bits (argument is a 2-digit hex value):
# sets the expected input data size and #taps
# bits 0-3: number of bits per pixel minus 1
# bits 4-7: number of taps minus 1
#
CL_DATA_PATH_NORM:              4f

# camera link config register bits
# (arg is a 2-digit hex value, hexval shown in parens):
# 0 (01): RGB (set for RGB (except bayer). Applies to older/PCI, ignored on newer/PCIe)
# 1 (02): ignore data valid (on for most cameras though not all)
# 2 (04): generate an FVAL on every LVAL or vactv lines if bit 4 is set, for line scan cameras
# 3 (08): disable ROI (rarely set)
# 4 (10): generate an FVAL after every vactv lines if bit 2 is also set, for line scan cameras
# 5 (20): data valid invert (rare)
# 6 (40): RGB swap -- swap red/blue
# 7 (80): enable roi pad: if ROI > img output, will pad missing bytes
#
CL_CFG_NORM:                   02

#fast re-arm of acquisition. auto re-arm board when FVAL detected low
CL_CFG2_NORM: 40

# htaps/vtaps: if multiple taps, set either htaps or vtaps to match the number
# of taps and whether they represent horizontal or vertical. Most common it's
# htaps (that is, pixels in parallel taps are from pixels next to each other on
# the same line) For example with a 2-tap 8-bit camera (CL_DATA_PATH_NORM: 17)
# where the two taps are from adjacent pixels on the same line, you would uncomment
# htaps and leave it at 2.
#
htaps:		5
#vtaps:		2

# interlace method
# only for interleaved and some dual tap cameras
# determines how image is deinterleaved for display -- WORD_INTLV is only
# one of many available methods -- see *_INTLV in pdv_dependent.h and
# camera configuration guide for more
#
method_interlace:	WORD_INTLV_MIDTOP_LINE

# the following directives can be used to send us any serial commands
# necessary to put the camera to put it into the expected state.
# serial_init takes a colon-separated list of ASCII commands, and should
# be used for cameras that use an ASCII serial command set. serial_binit
# takes space-separated groups of hex bytes, for cameras that use binary
# serial instead of ASCII; each group gets send as a separate command with
# a serial_read of the response (thrown away) between each.  Examples of
# commands that should be sent include those that put the camera into the
# desired trigger mode (e.g. continuous, triggered, controlled), #bits and
# taps, etc. The idea is to set the camera mode to match how the rest
# of the config directives are setting up the FG board.
#
#serial_init: "CMD 1:CMD 2:CMD 3"
#serial_binit: "00 11 aa bb" or "001122 aabbccddeeff"

serial_init: "AMD N:SMD N:ACT I:SPX 1:PEC O"

# Serial termination Character
# defines the termination character(s) that will be sent after each
# serial command sent by the library subroutine pdv_serial_command, including
# those sent by serial_init (above).  If no serial_term is specified, the
# default, carriage return character (0d hex) will be sent. If some other
# sequence is needed, uncomment serial_term and insert the appropriate hex
# byte(s) separated by spaces.  serial_term only applies to EDT's
# ASCII-specific serial directives (e.g. serial_init) and library subroutines
# (pdv_serial_command),
# NOT binary ones (serial_binit, pdv_serial_binary_command).  To specify no
# serial terminator, call serial_term with an empty list <>
#
serial_term: <0d>

# Serial wait character
# The pdv_serial_wait() subroutine in EDT API normally waits for a fixed period
# of time before returning, to make sure it has received all of the characters
# in a given respnse. If the camera has a unique character that terminates every
# response, serial_waitc can be used to tell pdv_serial_wait to return immediately
# when that character is seen, speeding up serial initialization and the serial
# command/response sequence in general. The argument to this directive is hexidecimal
# value; therefore if the last character of every response is a newline, specify 0a ;
# if it is a carriage return, specify 0d and so on.
#
#serial_waitc:  0a

#Serial baud rate
serial_baud: 38400

# Mode Control register (hex)
# Hex value -- the left-most nibble determines which CC line is toggled for
# the EXPOSE pulse (if method_camera_shutter_timing is other than AIA_SERIAL).
# The right-most nibble determines which of the CC lines are held permanently
# high or low.  Typically this is set automatically by merthod_camera_timing
# (to 10 hex for triggered and MCL modes, 00 otherwise).  However if your
# camera needs it set otherwise, use this directive to do so.
#
# MODE_CNTL_NORM: 10

# Region of Interest start and area (decimal)
# vskip/hskip is how many pixels to skip before ROI, vert and horiz
# vactv/hactv is how many pixels to DMA to memory after skip, vert and horiz
# if full frame is desired, you can leave these commented out or make them the
# same as the camera width/height. hskip/hactv can also be used to trim columns
# for cameras that output non-4-byte-aligned data to multiple of 4 bytes (in
# width) to ensure proper operation of windows applications that depend on
# 4-byte alignment, e.g. pdvshow
#
#hskip: 0
#hactv: 2048
#vskip: 0
#vactv: 2048