Atlas IP67 20 MP Technical Reference Manual

C mount lenses can be used on a C mount camera. According to standard, the C mount flange back distance is 17.53 mm.

Mounting a heavy and long lens may cause damage to the camera board. If the lens is considerably heavier than the camera, the lens’ weight may exert significant force on the lens mount attached to the camera’s board causing unexpected damage to the board and soldered components. If a heavy lens is necessary for the production environment, it is recommended to use the lens as a mounting point rather than the camera to avoid damage to the camera.

Use IP67-rated cables with your ATP200S unit to keep dust and water out of the connection ports.

Find IP67-rated GigE and GPIO cables in the Cables section of the Lucid web store.

When the GPIO port on the ATP200S is not in use, you must attach the GPIO plug to achieve the IP67 rating.

Persistent IP and DHCP configurations can be disabled on the camera. The default camera configuration is as follows:

Out of the box, the camera first attempts to connect using DHCP. If the camera is unable to connect using DHCP, it will use Link-Local Addressing.

The following pseudocode demonstrates setting up persistent IP:

1
2
3
4
5
6
7

// Connect to camera
// Get device node map 

GevCurrentIPConfigurationPersistentIP = true;   
GevPersistentIPAddress = 192.168.0.10; //Enter persistent IP address for the camera 
GevPersistentSubnetMask = 255.255.255.0;
GevPersistentDefaultGateway = 192.168.0.1;

LUCID Vision Labs recommends enabling jumbo frames on your Ethernet adapter. A jumbo frame is an Ethernet frame that is larger than 1500 bytes. Most Ethernet adapters support jumbo frames, however it is usually turned off by default.

Enabling jumbo frames on the Ethernet adapter allows a packet size of up to 9000 bytes to be set on the Atlas. The larger packet size will enable optimal performance on high-bandwidth cameras, and it usually reduces CPU load on the host system. Please note in order to set a 9000 byte packet size on the camera, the Ethernet adapter must support a jumbo frame size of 9000 bytes or higher.

The following table are some of the Ethernet adapters that LUCID Vision Labs has tested:

If you still experience issues such as lost packets or dropped frames, you can also try:

• Updating the Ethernet adapter driver (you may need to enable jumbo frames again after updating).
• Increasing the receive buffer size in your Ethernet adapter properties.
• Reducing the DeviceLinkThroughputLimit value (this may reduce maximum frame rate).

A receive buffer is the size of system memory that can be used by the Ethernet adapter to receive packets. Some Ethernet adapter drivers or the operating system itself may set the receive buffer value to a low value by default, which may result in decreased performance. Increasing the receive buffer size, however, will also result in increased system memory usage.

The Device Link Throughput Limit is the maximum available bandwidth for transmission of data represented in bytes per second. This can be used to control the amount of bandwidth used by the camera. The maximum available frame rate may decrease when this value is lowered since less bandwidth is available for transmission.

The ATP200S features two customizable user sets to load or save user-defined settings on the camera. Accessing the user set named Default will allow loading or saving of factory default settings. The camera will load the user set selected in UserSetDefault when powering up or when reset.

A camera feature marked as Streamable allows the feature’s current value to be stored to and loaded from a file.

The ATP200S features persistent storage for generic file access on the camera. This feature allows users to save and load a custom file up to 16 megabytes with UserFile. Users can also save and load User Set contents to and from a file.

The following pseudocode demonstrates reading from the camera using file access:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Connect to camera
// Get device node map 
FileSelector = UserFile1;
FileOpenMode = Read;
FileOperationSelector = Open;
FileOperationExecute();
// Device sets FileOperationSelector = Close
// Read custom file from camera 
FileOperationExecute();
// Device sets FileOperationSelector = Open

The following pseudocode demonstrates writing to the camera using file access:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Connect to camera
// Get device node map 
FileSelector = UserFile1;
FileOpenMode = Write;
FileOperationSelector = Open;
FileOperationExecute();
// Device sets FileOperationSelector = Close
// Write custom file to camera 
FileOperationExecute();
// Device sets FileOperationSelector = Open

Opto-isolated Input Measurements:

Sample values measured at room temperature. Results may vary over temperature and setup.

Maximum supported input voltage: 24V

Opto-isolated Output Measurements:

Sample values measured at room temperature. Results may vary over temperature and setup.

Maximum supported output voltage: 24V

Non-isolated Input Measurements:

Typical values measured at room temperature. Results may vary over temperature.

Maximum supported input voltage: 24V

Non-isolated Output Measurements:

Typical values measured at room temperature. Results may vary over temperature.

Maximum supported output voltage: 24V

Same as Non-isolated Input – GPIO Line 2 (GPIO_IN is Pin 4, GND is Pin 5)

Same as Non-isolated Output – GPIO Line 2 (GPIO_OUT is Pin 4, GND is Pin 5)

This product has been tested and complies with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user will be required to correct the interference at his own expense.

Users are advised that any changes or modifications not approved by LUCID Vision Labs will void the FCC compliance. The product is intended to be used as a component of a larger system, hence users are advised that cable and other peripherals may affect overall system FCC compliance.

LUCID Vision Labs declares the ATP200S camera is in conformity of the following directives:

• RoHS 2011/65/EC
• REACH 1907/2006/EC
• WEEE 2012/19/EC

LUCID Vision Labs declares the ATP200S meets requirements necessary for CE marking. The product complies with the requirements of the listed directives below:

• EN 55032:2012 Electromagnetic compatibility of multimedia equipment – Emission requirements
• EN 61000-3-2:2014 Harmonic Current Emissions
• EN 61000-3-3:2013 Voltage Fluctuations and Flicker
• EN 61000-4-2:2008 Electrostatic Discharge
• EN 61000-4-3:2010 Radiated RF Immunity
• EN 61000-4-4:2012 Electrical Fast Transient/Burst
• EN 61000-4-5:2014 Surge Transient
• EN 61000-4-6:2013 Conducted Immunity
• EN 61000-4-8:2009 Power Frequency Magnetic Field
• EN 61000-4-11:2004 Voltage Dips and Interruptions

A급 기기
(업무용 방송통신기자재)

Class A Equipment (Industrial Broadcasting & Equipment)

이 기기는 업무용(A급) 전자파적합기기로서 판
매자 또는 사용자는 이 점을 주의하시기 바라
며. 가정외의 지역에서 사용하는 것을 목적으로
합니다.

This is electromagnetic wave compatibility equipment for business (Class A). Sellers and users need to pay attention to it. This is for any areas other than home.

The ATP200S supports a list of pixel coordinates to be corrected via firmware. For the list of pixel coordinates, their actual pixel values are replaced by interpolation of their neighboring pixel values. The camera has a preloaded pixel correction list and these pixels are loaded during the camera manufacturing process. It is natural that sensors come with defective pixels and they are inevitable in the semi-conductor manufacturing process. As the camera operates longer in heat or is exposed to radiation, more defective pixels may appear. Users can update the pixel correction list any time.

Steps to add a new pixel to the correction list

• Set OffsetX and OffsetY to zero. Set Width and Height to the maximum allowed value.
• Set Gain to zero and note the coordinates of any bright pixels in the image. Please ensure the camera is not exposed to light by covering it with a lens cap and placed in a dark box.
• Fire the DefectCorrectionGetNewDefect command.
• Enter the X-coordinate noted in step 2 into DefectCorrectionPositionX.
• Enter the Y-coordinate noted in step 2 into DefectCorrectionPositionY.
• Fire the DefectCorrectionApply command.
• Repeat steps 3-6 as needed and fire the DefectCorrectionSave when done.

Table below shows the maximum number of defective pixels that can be added to the correction list.

Gain refers to a multiplication factor applied to a signal to increase the strength of that signal. On Lucid cameras, gain can be either manually adjusted or automatically controlled.

Some cameras feature gain that is purely digital while others allow for analog gain control up to a certain value, beyond which the gain becomes digital. Depending on the camera family and sensor model, the specific gain control can vary.

Analog Gain

Analog Gain refers to amplification of the sensor signal prior to A/D conversion.

Digital Gain

Digital Gain refers to amplification of the signal after digitization.

The following pseudocode demonstrates setting Gain to 12 dB:

1
2
3
4

// Connect to camera
// Get device node map 
GainAuto = Off;
Gain = 12;

The Atlas camera is equipped with a debayering core within the image processing pipeline. The color processing core enables the camera to output a color processed image format in addition to the unprocessed Bayer-tiled image. Currently the camera supports the RGB8 pixel format which outputs 8-bits of data per color channel for a total of 24-bits per pixel. Due to the amount of bits per pixel, the total image size for RGB8 would be 3 times larger when compared to an 8-bit image. This increase in image data size per frame would result in a reduction of average frame rate for the camera.

The following pseudocode demonstrates configuring the camera to RGB8 pixel format:

1
2
3

// Connect to camera
// Get device node map 
PixelFormat = PixelFormat_RGB8;

The white balance module aims to change the balance between the Red, Green and Blue channels such that a white object appears white in the acquired images. LUCID Vision Labs cameras allow for manual white balance adjustment by the user, or automatic white balance adjustment based on statistics of previously acquired frames. Different external illuminations and different sensors may render acquired images with color shift. The White Balance module allows the user to correct for the color shift by adjusting gain value of each color channel.

LUCID Vision Labs offers two types of white balance algorithm as described below. Both methods below allow for user controlled anchor points or reference points, from which multipliers are computed for each channel. The different anchor points are summarized below.

Grey World

A grey world assumes that the average of all colors in an image is a neutral grey.

White Patch

White patch has the same idea as Grey World, but only considering a section of the image (i.e. the section being the white patches). A simple way to determine such section(s) of the image is to indicate a pixel as white when R+G+B is greater than the threshold pixel value. Determining the threshold can be done using a 90% percentile of previous image. There is also a need for an additional threshold to exclude saturated pixels for better white balance adjustment.

Look-Up Table also known as LUT is used for mapping 12-bit user-specified pixel values to replace 12-bit raw sensor pixel values. Users input values for the even indices including the last index 4095 while averaging is used to calculate rest of the odd indices. So there are in total 2049 effective input entries; 2048 even (e.g., 0, 2, 4, …, 4092, 4094) + 1 odd (4095). Index value 0 correspond to black color while the index value 4095 correspond to white color.

To build a LUT, users input index values (e.g., 0, 2, 4, …, 4092, 4094, 4095) that need to be replaced in the LUTIndex field and the corresponding new value in the LUTValue field. For the odd index values in the gap (e.g., 1,3,5 …,4089, 4091, 4093), their mapped value is calculated by taking the average of their neighbor mapped values (e.g., If the input mappings are LUTIndex = 1090 -> LUTValue = 10 and LUTIndex = 1092 -> LUTValue = 20, then the mapped value of LUTIndex = 1091 will be LUTValue = 15)

The following pseudocode demonstrates replacing black pixel values with white pixel values:

1
2
3
4
5
6
7

// Connect to camera
// Get device node map 

LUTEnable = true;   
LUTIndex = 0; //Pixel value to be replaced, in this case black  
LUTValue = 4095; //New pixel value, in this case white     
LUTSave();

The gamma control allows the optimization of brightness for display. LUCID implements Gamma using GenICam standard, that is

where,

• X = New pixel value; 0 <= X <=1
• Y = Old pixel value; 0 <= Y <=1
• Gamma = Pixel intensity: 0.2 <= Gamma <= 2

Y in the Gamma formula is scaled down to [0-1] from original pixel range which results in a pixel range of [0-1] for X. As an example, for 12-bit pixel formats, this would mean scaling down pixel range from [0-4095] to [0-1] and for 16-bit pixel formats, this would mean scaling down pixel range from [0-65535] to [0-1].

The camera applies gamma correction values to the intensity of each pixel. In general, gamma values can be summarized as follows:

• Gamma = 1: brightness is unchanged.
• 1 <= Gamma <= 2: brightness decreases.
• 0.2 <= Gamma <= 1: brightness increases.

The Color Space Conversion control allows the user to convert from RGB color space to another color space such as YUV. The conversion is done in a linear manner as shown in the following equation.

The color correction function allows the user to choose between a few preset values or user-configurable matrix values. The color correction is done by allowing the multiplication of a 3×3 matrix to the 3×1 matrix containing R, G and B pixel values to achieve a more desirable R’, G’ and B’ values. The specific mathematical procedure can be represented by the following.

• ColorTransformationEnable is a node that indicates whether the conversion matrix of the color space conversion module is used or bypassed.
• When the pixel format is YUV or YCbCr, ColorTransformationSelector is displayed as RGBtoYUV. When the pixel format is Mono, ColorTransformationSelector is displayed as RGBtoY.
• ColorTransformationValueSelector chooses which coefficient in the conversion matrix and the coefficient value is shown in ColorTransformationValue. In Mono, YUV or YCbCr pixel formats, ColorTransformationValue is read only.

The region of interest feature allows you to specify which region of the sensor is used for image acquisition. This feature allows a custom width and height for image size and a custom X and Y offset for image position. The width and height must be a multiple of the minimum width and height values allowed by the camera.

The following pseudocode demonstrates configuring the camera to use a region of interest of 200×200 at offset (250,150):

1
2
3
4
5
6

// Connect to camera
// Get device node map 
OffsetX = 250;
OffsetY = 150;
Width = 200;
Height = 200;

The ATP200S camera supports binning in which columns and/or rows of pixels are combined to achieve a reduced overall image size without changing the image’s field of view. This feature may result in an increase of camera’s frame rate.

The binning factor indicates how many pixels in the horizontal and vertical axis are combined. For example, when applying 2×2 binning, which is 2 pixels in the horizontal axis and 2 pixels in the vertical axis, 4 pixels combine to form 1 pixel. The resultant pixel values can be summed or averaged.

When binning is used, the settings of the image width and height will be affected. For example, if you are using a camera with sensor resolution of 2448 x 2048 and apply 2×2 binning, the effective resolution of the resultant image is reduced to 1224 x 1024. This can be verified by checking the Width and Height nodes.

The following pseudocode demonstrates configuring binning on the camera:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Connect to camera
// Get device node map 

BinningSelector = Digital;    // Digital binning is performed by FPGA, some cameras will support BinningSelector = Sensor 
BinningHorizontalMode = Sum;  // Binned horizontal pixels will be summed (additive binning) 
BinningVerticalMode = Sum;    // Binned vertical pixels will be summed  (additive binning) 

BinningHorizontal = 2; // Set Horizontal Binning by a factor of 2 
BinningVertical = 2;   // Set Vertical Binning by a factor of 2 

// Resulting image is 1/4 of original size

Three ADC bit modes available in this model are 8 Bit, 10 Bit and 12 Bit (12 Bit only for ATP200S). As a result of sensor being clocked differently for each of these bit modes, maximum frame rate achieved is different in each mode.

Following table shows maximum frame rate achieved using Mono8 pixel format.

The camera supports decimation in which columns and/or rows of pixel are skipped to achieve reduced overall image size without changing the image’s field of view. This feature is also known as “subsampling” due to the smaller sample size of pixels the camera transmits. This feature may result in an increase of camera’s frame rate.

When decimation is used, the settings of the image width and height will be effected. For example, if you are using a camera with sensor resolution of 2448 x 2048. When horizontal and vertical decimation are both set to 2, the effective resolution of the resultant image is reduced to 1224 x 1024. This can be verified by checking the Width and Height nodes.

The following pseudocode demonstrates configuring decimation on the camera:

1
2
3
4
5
6
7

// Connect to camera
// Get device node map 

DecimationHorizontal = 2; //Set Horizontal Decimation by factor of 2
DecimationVertical = 2; // Set Vertical Decimation by factor of 2

// Resulting image is 1/4 of original size

This feature allows the camera to flip the image horizontally and vertically. The flip action occurs on the camera before transmitting the image to the host.

The following pseudocode demonstrates configuring the camera to flip both horizontal and vertical axes:

1
2
3
4

// Connect to camera
// Get device node map 
ReverseX = True;
ReverseY = True;

The camera outputs a FPGA-generated pattern when test pattern is enabled.

When a Digital IO line is set to Input, the line can accept external pulses. To trigger the camera upon receipt of an external pulse, the camera must also have trigger mode enabled.

The following pseudocode demonstrates enabling trigger mode and setting Line0 as the trigger input source.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// Connect to camera
// Get device node map 

// Choose Line0 and set it to Input 
LineSelector = Line0;
LineMode = Input;

TriggerMode = On;
TriggerSelector = FrameStart;           // Trigger signal starts a frame capture 
TriggerSource = Line0;                  // External signal to be expected on Line0 
TriggerActivation = FallingEdge;        // Camera will trigger on the falling edge of the input signal 

AcquisitionStart();

// Acquire images by sending pulses to Line0

It is also possible to set software as the input source. This will enable the camera to trigger upon a software signal. Note this mechanism may not be as accurate as using an external trigger source.

The following pseudocode demonstrates enabling trigger mode and setting a software trigger source.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Connect to camera
// Get device node map 

TriggerMode = On;
TriggerSelector = FrameStart;           // Trigger signal starts a frame capture 
TriggerSource = Software;               // Software signal will trigger camera 

AcquisitionStart();

TriggerSoftware();                      // Execute TriggerSoftware to signal the camera to acquire an image

By default, the ATP200S will reject input pulses until the last triggered image has completed the readout step on the sensor. This may limit the maximum achievable trigger frequency on some cameras when compared to maximum non-triggered FrameRate.

To address this situation, the ATP200S also supports TriggerOverlap functionality. When TriggerOverlap is enabled, this allows the camera to accept an input pulse before the readout step is complete. This allows the camera to be triggered at frequencies closer to the maximum non-triggered FrameRate.

When a Digital IO line is set to Output, the line can fire pulses.

The following pseudocode demonstrates setting Line1 as the output source. This sets up the camera to fire a pulse when the camera is acquiring an image.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Connect to camera
// Get device node map 

// Choose Line1 and set it to Output 
LineSelector = Line1;
LineMode = Output;
LineSource = ExposureActive;            // The output pulse will match the duration of ExposureTime

AcquisitionStart();

// Acquire images and process signal from Line1

The Atlas is capable of supplying external circuits with power through the VDD line. By default this line is turned off. The following pseudocode demonstrates enabling the GPIO VDD line to output 2.5V.

1
2
3
4
5
6
7
8

// Connect to camera
// Get device node map 

// Choose Line4 and set it to output external voltage 
LineSelector = Line4;
VoltageExternalEnable = True;

// Continue with the rest of the program...

When the chunk data property named CRC is enabled, the camera tags a cyclic-redundancy check (CRC) checksum that is calculated against the image payload.

The following pseudocode demonstrates enabling the CRC property in chunk data and extracting the ChunkCRC chunk from acquired images:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Connect to camera
// Get device node map 
ChunkModeActive = True;
ChunkSelector   = CRC;
ChunkEnable     = True;

AcquisitionStart();

// Acquire image into buffer
// Read chunk data from received buffer 
bufferCRC   = ChunkCRC;        // CRC checksum for image payload

When using Automatic Transfer Control mode, the transfer of blocks to the host are controlled the device’s acquisition controls.

In Automatic Transfer Control mode, the TransferOperationMode is read only and set to Continuous. Using Continuous TransferOperationMode is similar to when Transfer Control is not enabled, except the host application can stop data transmission without stopping image acquisition on the device.

The following pseudocode demonstrates enabling Automatic Transfer Control mode on the camera.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

// Connect to camera
// Get device node map 

// Set desired Pixel Format, Width, Height

// Optional: Read TransferQueueMaxBlockCount to determine the number of blocks 
// that can be stored in the on-camera buffer with the current device settings 

TransferControlMode = Automatic;
TransferQueueMode = FirstInFirstOut;

AcquisitionStart();             // When in Automatic Transfer Control Mode, the 
                                // AcquisitionStart command automatically executes the TransferStart command 
                                
// Acquire images
// Images will be accumulating into the on-camera buffer
// Blocks will be transmitted to the host system automatically until TransferPause or AcquisitionStop is executed

// Retrieve images on host system

When using UserControlled Transfer Control mode, the transfer of blocks to the host are controlled by the host application. Using MultiBlock TransferOperationMode with UserControlled Transfer Control allows the host application to specify when to transmit data from the device.

The following pseudocode demonstrates enabling UserControlled Transfer Control mode with MultiBlock TransferOperationMode on the camera. It also demonstrates transferring 2 blocks from the on-camera buffer for each transmission operation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// Connect to camera
// Get device node map 

// Set desired PixelFormat, Width, Height

// Optional: Read TransferQueueMaxBlockCount to determine the number of blocks 
// that can be stored in the on-camera buffer with the current device settings 

TransferControlMode = UserControlled;
TransferQueueMode = FirstInFirstOut;

TransferOperationMode = MultiBlock;    // Transmit the number of blocks in TransferBlockCount 
TransferBlockCount = 2;                // This should be less than or equal to TransferQueueMaxBlockCount 

AcquisitionStart();             
                                
// Acquire images
// Images will be accumulating into the on-camera buffer

// Read TransferQueueCurrentBlockCount 
If (TransferQueueCurrentBlockCount > 0)
{
    // Transmit blocks to host system
    TransferStart();
    
    // Retrieve block 1 on host system
    // Retrieve block 2 on host system

    TransferStop();
}

Exposure Start event occurs when camera starts exposing the sensor to capture a frame. Following data is sent by the camera at Exposure Start event:

• EventExposureStart: Unique identifier of the Exposure Start type of Event.
• EventExposureStartTimestamp: Unique timestamp of the Exposure Start Event.
• EventExposureStartFrameID: Unique Frame ID related to Exposure Start Event.

Exposure End event occurs when camera has finished exposing the sensor. Following data is sent by the camera at Exposure End event:

• EventExposureEnd: Unique identifier of the Exposure End type of Event.
• EventExposureEndTimestamp: Unique timestamp of the Exposure End Event.
• EventExposureEndFrameID: Unique Frame ID related to Exposure End Event.

Test event occurs when TestEventGenerate node is executed. Test event is mainly used to confirm that camera is generating events. Following data is sent by the camera at Test event:

• EventTest: Unique identifier of the Test type of Event.
• EventTestTimestamp: Unique timestamp of the Test Event.

Counters can be used to keep a running total of an internal event. The Counter value can be reset, read, or written at any time.

The following nodes are available to configure the Counter increment:

• CounterSelector: The Counter control to be used
• CounterEventSource: The event source that will increment the Counter
• CounterEventActiviation: The activation mode used for CounterEventSource (e.x. RisingEdge)
• CounterTriggerSource: The source that will start the Counter

The following nodes are available to configure the Counter reset:

• CounterResetSource: The signal that will reset the Counter
• CounterResetActivation: The signal used to activate CounterResetSource
• CounterReset: The command will reset CounterValue and set the last value to CounterValueAtReset

The following nodes are available to read or control the Counter:

• CounterValue: The current value of the Counter
• CounterValueAtReset: The value of the Counter before it was reset
• CounterDuration: The value to count before setting CounterStatus = CounterCompleted
• CounterStatus: The status of the Counter

The following CounterStatus modes are available:

• CounterIdle: Counter control is not enabled
• CounterTriggerWait: Counter is waiting to be activated
• CounterActive: Counter is counting until the value specified in CounterDuration
• CounterCompleted: Counter has incremented to value set in CounterDuration
• CounterOverflow: CounterValue has reached its maximum possible value

The following pseudocode demonstrates using a Rising Edge counter event to track the number of rising edges signals received on Line 0. A second counter is enabled to track the number of Exposure Start events that occurred to indicate the number of images captured.

Timers can be used to measure the duration of internal or external signals.

The following nodes are available to configure the Timer:

• TimerSelector: The Timer control to be used
• TimerTriggerSource: The source that will trigger the Timer
• TimerTriggerActivation: The activation mode used for TimerTriggerSource (e.x. RisingEdge)
• TimerDuration: The duration of the Timer pulse in microseconds
• TimerDelay: The duration of delay to apply before starting the Timer upon receipt of a TimerTriggerActivation
• TimerReset: Resets the Timer control
• TimerValue: Reads or writes the current value of the Timer
• TimerStatus: The status of the Timer

The following TimerStatus modes are available:

• TimerIdle: Timer control is not enabled
• TimerTriggerWait: Timer is waiting to be activated
• TimerActive: Timer is counting for the specified duration in TimerDuration
• TimerCompleted: Timer has reached the duration specified in TimerDuration

The following pseudocode demonstrates using a Timer to delay a Line output pulse relative to the ExposureStart event of the image.

The following pseudocode demonstrates using a Timer output a pulse of a custom width. This can be used for a single pulse width or pulse width modulation.

• Navigate to your camera’s firmware update page in your web browser (http://{your-camera-ip-address}/firmware-update.html).
• Click Choose a file on the Firmware Update page and select your fwa file.
• Click Submit on the Firmware Update page. This will start the firmware update process.

The Firmware Update page will show the progress of the update. During the update, the camera will not be accessible for control or image capture. The update may take a few minutes to complete. Please refrain from removing power from the camera during the update.

When the firmware update is complete, the camera will reboot. Once the update is finished, you can close the Firmware Update page and access the camera again.

There are 3 main types of acquisition modes – SingleFrame acquisition, MultiFrame acquisition, and Continuous acquisition.