RIT Senior Design Project 10662

D3 Engineering Camera Platform

Design Review November 6, 2009

Time: Friday November 6, 2009 9:00 am to 11:00 am

Location: RIT Campus. Building 9 Room 4435

Project Team

Gregory Hintz

Samuel Skalicky

Jeremy Greene

Jared Burdick

Michelle Bard

Anthony Perrone

Advisors

Bob Kremens (RIT)

Philip Bryan (RIT)

Scott Reardon (D3 Engineering)

Kevin Kearney (D3 Engineering)

Table of Contents

1 INTRODUCTION 4

1.1 SUMMARY 41.2 SYSTEM MODEL 41.3 DETAILED SYSTEM MODEL 5

2 CUSTOMER NEEDS 7

3 ENGINEERING SPECIFICATIONS 8

3.1 SYSTEM ENGINEERING SPECIFICATIONS 83.2 SUB- SYSTEM ENGINEERING SPECIFICATIONS 9

4 FPGA BOARD 11

4.1 HARDWARE DESCRIPTION PLAN (SOFTWARE DESIGN) 114.1.1 GOAL 114.1.2 DESCRIPTION 114.1.3 FPGA 114.1.4 DSP/OEM 124.1.5 ANALYSIS 134.2 FPGA SYSTEM SPEED ANALYSIS 144.2.1 REASON FOR NOT HAVING ENOUGH ANALYSIS IN THIS AREA 144.2.2 ANALYSIS 144.2.3 CORRELATION 164.2.4 DISCUSSION OF CALCULATIONS 184.2.5 CONCLUSION 18

5 THE CONNECTOR BOARD AND EXTERNAL INTERFACES 19

5.1 OVERVIEW 195.2 DESIGN DECISIONS 195.3 CURRENT DESIGN 20

6 INERTIAL NAVIGATION SYSTEM (INS) 22

6.1 OVERVIEW 226.2 DETAILS 226.3 SOFTWARE 22

7 CHASSIS INTERFACES 24

7.1 NEEDS 247.2 SPECIFICATIONS 247.2.1 AIRCRAFT SPECIFICATIONS 247.2.2 ELECTRONICS SPECIFICATIONS 25

2 | P a g e

7.3 DESIGN 25

8 VIBRATION DAMPING 26

8.1 NEEDS 268.2 CONSIDERATIONS 268.2.1 FREQUENCIES OF AIRCRAFT 268.2.2 ALLOWABLE VIBRATION IN IMAGE 268.2.3 COMPONENT RESONANT FREQUENCIES 278.3 APPROACH 288.4 CHASSIS DESIGN 298.4.1 PHASE 1: INDIVIDUAL COMPARTMENTS 298.4.2 PHASE 2: ASSURE COMPONENT SCALE 308.4.3 PHASE 3: DETAILED DESIGN TO ALLOW FOR REALISTIC THERMAL, VIBRATIONAL, AND SPATIAL ANALYSIS 318.4.4 PHASE 4: FINAL MECHANICAL DESIGN 32

9 ENVIRONMENTAL MANAGEMENT 34

9.1 HEAT 349.1.1 MAJOR SOURCES OF HEAT GENERATION INSIDE CHASSIS 349.1.2 HEAT TRANSFER MODELS 349.2 HEAT TRANSFER ANALYSIS, A RADIATION MODEL 359.2.1 ASSUMPTIONS 359.2.2 ANALYSIS 359.2.3 VARIABLES 359.3 HEAT TRANSFER ANALYSIS, A CONDUCTIVE MODEL 369.4 HEAT TRANSFER ANALYSIS, A COMBINED MODE APPROACH 37

10 OTHER ENVIRONMENTAL CONSIDERATIONS: CONDENSATION 39

10.1 DEW POINT ANALYSIS 39

11 MOUNTING 41

11.1 INTERNAL MOUNTING 4111.1.1 ELECTRONICS MOUNTING 4211.1.2 OPTICS MOUNTING 4311.2 EXTERNAL MOUNTING 44

12 APPENDIX 45

12.1 CONNECTOR BOARD SCHEMATIC 4512.1 CAMERALINK® TO D3 CHIP SCHEMATIC 46

3 | P a g e

1 Introduction

1.1 SummaryThe customer, D3 Engineering, desired that we integrate supplied components into an

environment-ready, flight-capable package that can record and transmit multi-spectral ground images and associated INS data. This solution should be capable of (if not initially configured for) processing that data in some way, including, but not limited to, compositing images from multiple spectrums and “stamping” image data with real time INS data.

1.2 System Model

Figure 1: Black Box model of System

The system will have up to 4 cameras and lens mounted internally to the bottom side of the enclosure that will input the data into the enclosure. Processed images with the corresponding INS data will be sent out through the FastEthernet port. CameraLink® and Gigabit Ethernet will also act as inputs for external cameras.

4 | P a g e

1.3 Detailed System Model The system is divided into the main parts for the purpose of design and referencing later on. The

Electronics Enclosure is used to house all the electronics. This unit is separate from the camera module to better allow for expandability and to help control the temperature and environment differences between the two. The Electronics System is made up of the OEM DSP Board, Novatel OEM Board, FPGA Board, Connector Board and the external connectors.

The OEM DSP board is a digital signal processing board that the customer has designed. This board already has the capabilities of basic image processing including compression and resolution modification, as well as INS integration.

The Noatel OEM Board is customer supplied multi-frequency GNSS Receiver. This board is being using to control the input GPS signal used to detect the location of the camera module. This is otherwise known as GPS.

The FPGA Board, otherwise referred to as the Processor Board is where most all of the processing and routing will take place. The FPGA will be located on this board along with internal memory to control the signals coming from the cameras and do basic processing of the signals. The FPGA will act as a switch between all the units of the system and store the necessary data onto the SSD SATA hard drive for access at a later time.

5 | P a g e

Figure 2: System Model of customer supplied parts and the basic configuration of the system.

The connector board acts as a medium between the FPGA board and the external connectors. Major power regulation will take place on the board along with a conversion between CameraLink® and D3 protocols to allow for easier processing on the FPGA board.

The Camera Enclosure houses up to 4 Cameras using the D3 camera protocol. For this project we will only be required to test the system for 2 but the customer would like to be able expand later to 4.

6 | P a g e

2 Customer Needs

1. Use Supplied Componentsa. 10MP Visual Camerab. IR Camerac. 1 of the 2 Inertial Navigation Systems depending on availability

i. NovAtel OEM Board OEMV3ii. NovAtel OEM Board OEMV2

d. OEM Camera Processing Board2. Interface to single 10Mpixel Camera through proprietary “D3 Camera” connector.3. Interface to single Thermal Camera through Camera Link Interface. 4. Capture 10MP data at 1FPS5. Capture the Thermal Camera data synchronized with the 10Mpixel camera. 6. Capture INS data and store to match corresponding photos. 7. Accept data from auxiliary external cameras and INS units8. Make data overlay and processing possible on-board9. Output data from the supplied OEM Board connection for real-time viewing10. Store data internally during flight using a SSD SATA drive. 11. Package must include mounting and space necessary for four cameras. 12. Package everything (except for the IR camera) to protect it against the environment and to

minimize the size. “Everything” Includes:

a. (4) visual cameras and their lensesb. (1) INS sensorc. (1) OEM Camera Processing Boardd. Any other components necessary for operation

13. Position images for ground observations14. Make cameras separable from the processing hardware15. Interface package to a light passenger aircraft.

7 | P a g e

3 Engineering Specifications

3.1 System Engineering Specifications1. Constraints

a. The system shall use the supplied 10MP Visual Band Camera at 1FPs.b. The system shall use the supplied CameraLink Camera at 30FPS.c. The system shall use the supplied Inertial Navigation System.d. The system shall use the supplied OEM Camera Processing Board.

2. Interfacesa. The system shall interface with the customer’s proprietary software. b. The system shall be powered from an external source. c. The system shall position the cameras with unobstructed line of sight in a direction

perpendicular to the direction of flight on the bottom side of the airplane. d. The system shall connect to a programming interface for hardware reconfiguration.e. The system shall connect to two external cameras and one external INS module.

3. Physicala. The system shall not exceed 8” x 6” by 7.5” tall. b. The system shall weigh no more than 15lbs. c. The cameras enclosure must be able to be removed from the electronics.

4. Environmentala. The system shall operate in the following environment:

b. The system shall limit EMI emission according to MIL-810G Standard.5. Configurability

a. The system shall enable configuration of the camera interfaceb. The system shall enable configuration of image compressionc. The system shall enable configuration of INS interfaces

6. Capacitya. The system shall store up to 20 minutes worth of image data. b. The system shall be able to house 4 cameras at a time.

7. Processinga. The system shall store the raw data from the cameras and the INS data to allow for

access before the next mission. b. The system shall process the images and output the data to the SSD Hard drive within

10 seconds of the picture being taken. c. The system shall transmit the low resolution images within 10 seconds of the pictures

being taken out of the OEM Board’s 10/100 connector.

8 | P a g e

Temperature -50°C to 45°CHumidity 90% or lessAltitude 10,000 ft (3048m)Shock and Vibration Per RTCA DO-160

3.2 Sub- System Engineering Specifications

1. Package

a. Given the environmental conditions defined in the System Engineering Specifications, the packaging shall maintain the following internal environment for the electronic components:

Temperature 0°C to 70°CHumidity < 60%Shock and Vibration Per RTCA DO-160

b. The packaging shall contain EMI per MIL 810-Gc. The packaging shall not degrade the optical performance of the cameras.d. The packaging shall enable replacement of any component within 10 minutes, given a

trained user, without custom tools.e. The packaging shall have the following connectors available externally:

i. 10/100 Connectorii. Gigabit Ethernet Connector (x2)

iii. CameraLink Connector (x2)iv. Power Connector (TBD)v. DB-9 Connector

vi. RCA Video Outf. The packaging without electronics installed shall weigh no more than 10lbsg. The external packaging shall not exceed 16” x 6.5” by 5”. (Length x Width x Height)h. The packaging shall mount fixed t a flat plate.

2. Processor Boarda. The Processor board must be able to be reconfigured for multiple different operations

by a technical expert. Different Operations to include but not limited toi. More than 2 inputs used.

ii. Overlay of the Camera inputs with the corresponding INS data. iii. Change in rate inputs are selected

b. The processor board shall not exceed 5” x 6” x Height TBD. c. The processor board shall weigh no more than 2lbs. d. Interfaces

i. The processor board shall be connected to the connector board by1. High speed header2. Header for the power

ii. The processor board shall be connected to the following external connectors directly (not from connector board):

1. Gigabit Ethernet (x2)iii. The processor board shall be powered by GND, +5V, 12V, 3V.iv. The processor board shall be securely mounted to the connector board and the

OEM board to not allow for movement between the boards.

9 | P a g e

v. The Processor Board must be able to communicate with the supplied OEM Camera Processing Board and the onboard storage device simultaneously through high speed connections.

3. Connector Boarda. The Connector board shall have the following inputs.

i. High Speed to Processor Boardii. CameraLink from External Connection

iii. Power Input cable from External Connectioniv. Power Output to Processor board

b. The connector board will have provide the necessary power for the system by outputting the necessary power based on the following voltages with an input voltage ranging from +9 to +36V DC in order to supply adequate power ranges for devices in the system.

i. GND ii. +5, TBD W

iii. +12V, TBD Wiv. +3V, TBD W

c. The connector board must be able to fit inside the electronics enclosure and shall not exceed 5” x 6” x height TBD.

d. The connector board must not exceed 2lbs. 4. Storage Unit

a. The Storage unit must be commercially available solution. b. The Storage unit must be upgradable and able to remove and replaced within 5

minutes, given a trained user, without custom tools. c. The Storage unit must be equal or greater than 250 GB in order to allow enough storage

of required data. (6.a)d. The Storage unit shall weigh no more than 1 lb. e. The Storage unit shall not exceed 4x6x3.f. The Storage unit shall be a solid state drive that will be able to withstand the

environment of the electronics enclosure. g. The Storage unit shall be connected to the Processor board using SATA.

10 | P a g e

4 FPGA Board

4.1 Hardware Description Plan (Software design)

4.1.1 GoalThis system will be able to receive data from multiple sources simultaneously and process that data. It will then save that data to a storage medium and pass the data along to another processor for compression and real time viewing.

4.1.2 DescriptionTo accomplish this goal the main system is broken up into two main parts: FPGA and DSP. The FPGA will accept input from various sources and process it in different ways. The DSP will receive input from the INS device and also images from the FPGA and do some processing on them.

4.1.3 FPGA

The FPGA will have software to describe specific components. This software has the potential to be turned into a physical device (ASIC) in the future to speed up the design and reduce costs. The major functions of the FPGA is to accept input, process this data, and to export the data. It will receive data from three different types of devices: D3 imagers, Gigabit Ethernet enabled cameras, and a DSP co-processor. The data from these devices will be controlled with a single main component that will function mainly as the Central Dispatch. Data will be exported two ways, through the DSP and to the hard drive.

The D3 imagers will each have a control module to receive the data in multiple cycles (as related to the external device, not the internal clock). It will initiate a collection cycle when instructed from the Central Dispatch. Upon receipt of this data in full, it will pass the data off to an intermediary storage location (DDR Memory). It will notify the Central Dispatch of its data deposit, and reset to wait for the next signal to begin data collection from the Central Dispatch.

The Gigabit Ethernet camera controllers will function similar to that of the D3 imager controllers. However they will have a complex component to handle the translation to/creation of TCP/IP packets and send this data out at gigabit speeds(1000Mbps) using a special Ethernet controller.

11 | P a g e

Figure 3: Software Model of FPGA

The hard drive will communicate over SATA I speeds. This requires a special controller to convert to serial communication and use specific hardware to keep the data rates high. This component will receive commands from the Central Dispatch to get data from the memory and store it on the hard drive.

The image-processing element will be designed as a pipeline to increase efficiency. This will allow us to replicate the element many times over to either speed up processing or to complete various levels of processing. This component will receive signals from the Central Dispatch to get data from memory (DDR) and then process it. Upon completion of processing, it will return this data back to memory and wait for the next instruction from Central Dispatch.

The last and essential component is the Central Dispatch (CD) that will control the other components. This element will contain various lists (Queues) of data that either needs to be processed, to be written to the hard drive or be sent to the DSP (for more processing or compression). It will also, at regular intervals, prompt the data input components to get data from their devices. These components will notify the CD of the location of the data acquired and the CD will add this to-do item to its various lists.

4.1.4 DSP/OEMThe DSP uses some signals similar to that of the D3 imagers, however it also has some high-speed data lines as well. This OEM controller module will be a two-way communication platform. It will send images to the DSP for more processing and return, and for compression to be sent out the Fast Ethernet connection to a user for real time viewing. This module will also serve the main entry point for spatial orientation data into the FPGA. Upon receipt the INS data will be stored directly to the hard drive. Image data may or may not have already been processed in the FPGA and thus will either be sent to be processed, or to be stored on the hard drive.

The co-processor for this design is the DSP, which will perform some functions already designed by the customer as well as perform new ones. Some of these will include image processing, image compression, INS integration, and real time video out. The DSP functions more like a CPU with discrete (hard-wired) components that process instructions run on a kernel (core). The DSP will need to have functions written for communication with the FPGA (including sending info back and forth) and specifically what type of processing to do and where the data will go next.

12 | P a g e

Figure 4: Software Model of DSP

4.1.5 AnalysisBased on the breakdown above this software package will be implementable in the time allotted for this project. The customer has acknowledged the large scope of the project and has designated certain levels of completeness for this area of design. Ideally they would like the entire software design to be implemented. However in the time allotted and considering the vast amount of other work needed to be complete on top of this, they have decided to stress the hardware design of this project more. Thus, the minimum requirement is to pass data through the FPGA to the DSP/OEM Board they have provided. This implementation will be trivial to implement considering the background of the team (use the FPGA Speed analysis document as a reference of background). We as a team will at least lay the foundation for this software by creating VHDL Entities for the various components described above. This will allow other engineers to come in behind and fill in the holes with little overall knowledge of the project, or even outsourcing the work to be a trivial task.

Based upon the breakdown, two main groups of elements exist. Both of them can be implemented in parallel and will even be done so in different development environments using differing languages. For example, the FPGA software design will be implemented in VHDL; the DSP will be written using the C programming language.This will allow the team to work efficiently and will allow the work to be completed within the time limits.

The image processing elements will probably not be implemented due to time constraints and the availability of algorithms and Ips(intellectual properties) for these components. This will allow multiple types of processing schemes to be implemented and interchanged based on the need and the planned use of this design. We will implement them as straight through Entities with no function inside. This will allow us to simulate processing by delaying the data and will enable us to calculate the types of processes that can be implemented based on the time available to keep the images streaming in “real time” at the rates required.

The various IO components will all be based off of one “parent” component that will encompass the majority of the functions in the camera modules. This will again reduce the total amount of time needed to complete the design. From this “child” component we will be able to tailor each component for the specific type of IO or add other elements such as Ethernet controllers to interface between other types of camera inputs.

Using these plans, the design will be able to be completed in the time allotted. Additionally the customer will be able to configure this design to their specific needs now, and in the future using the same hardware. This accomplishes the desire of the customer for adaptability and an acceptable lifetime. This configurability is inherently built into the design of the FPGA and the system interconnecting the various devices. The design of the software is influenced by this design in hardware.

13 | P a g e

4.2 FPGA System Speed Analysis

4.2.1 Reason for not having enough analysis in this area In a normal industrial situation when using an FPGA, all operations are coded, simulated, and

tested prior to choosing an FPGA model. However, due to our time constraints, coding and testing before designing the circuit board is not feasible. Hence, we are shooting for the best and using the resources we have to, as best as possible, approximate the needs of our operations on this FPGA.

4.2.2 AnalysisMembers of this team have worked with FPGAs before and have done research into specific

applications used on them. One such implementation is that of a Neural Network. Software in the past has used thousands of resources of computing power to simulation the human brain’s learning capabilities. Recently the design of an artificial network of cells in the brain is being used. The following will display this work and explain how the desing of our system will be fast enough to hand the operational data rates .

Traditionally, the term neural network had been used to refer to a network or circuit of biological neurons. The modern usage of the term often refers to artificial neural networks, which are composed of artificial neurons or nodes. Artificial neural networks are made up of interconnecting artificial neurons (programming constructs that mimic the properties of biological neurons). These networks may either be used to gain an understanding of their biological counterpart, or for solving artificial intelligence problems without necessarily creating a model of a real biological system. The real, biological nervous system is highly complex and includes some features that may seem superfluous based on an understanding of artificial networks. The cognitive modeling field involves the physical or mathematical modeling of the behavior of neural systems; ranging from the individual neural level (e.g. modeling the spike response curves of neurons to a stimulus), through the neural cluster level (e.g. modeling the release and effects of dopamine in the basal ganglia) to the complete organism (e.g. behavioral modeling of the organism's response to stimuli). For more detailed info about neural networks please see external sources such as Wikipedia or GCCIS Faculty.

This design shown below in Figure 1 was implemented on a Digilent Basys Spartan 3E-100 development board. It currently performs the function of XOR; however has no heuristic coding to help out. Instead it uses the theory touched on above to learn acceptable and unacceptable responses to input. This is not a simple design. Results of this network are outputs within 10% of the goal values for

14 | P a g e

Figure 5: Neural network Model

"high" and "low". These values are relatable to digital logic values in hardware and can be used as such. The results of the implementation in VHDL using the Xilinx WebPack ISE are shown below in table 1.

Table 1: Device Utilization Table for Spartan 3E-100

Total resources used: 19% Device Utilization Summary

Logic Utilization Used Available UtilizationNumber of Slice Latches 22 1,920 1%

Occupied Slices 197 960 20%4 input LUTs 360 1,920 18%

Logic 328 17%Route-thru 32 3%

Number of bonded IOBs 10 108 9%MULT18X18SIOs 4 4 100%

Table 2: Data Speeds

Node Levels Time Data In 29 13ns Data Out 2 5ns

Looking at the data from Table 1 we can see how little resources this design took up, a little less than 19% overall. This is not much considering the complexity of the design and the simplicity of the Spartan 3E-100 FPGA. For example the last row of table 1 shows that only 4 built in hardware optimized 18x18 bit multipliers exist in this device and all are used. For sure this design does a substantial amount of math to calculate the weights on the connections between neurons and more ALUs will need to be created using general purpose slices as can be seen in the usage of slices being about 20%.

15 | P a g e

This design was very fast and was able to process changes in inputs very quickly. We can see that 29 levels of logic were needed to be traversed from the input to the end of the processing pipeline. However this only takes 13ns, and we can calculate the frequency of this to be 76.92MHz. This number implies that we can handle 76 million changes of inputs per second on each pin that has input to this logic design. From this point in the design, to get to the output is only 2 levels and takes 5ns (or a speed of 200MHz). This is quite speedy on a device that we released to be a low price, slowest device in the product line in 2005. There are not many people that are still using computers considered "hot items" in 2005 (think first dual core processors, Celeron D ...). If the internal logic was simpler, or more pipelined we would be able to reduce these speeds in final design.

4.2.3 Correlation Unfortunately we have not been able to simulate this design on a Spartan 6LX75T core. We have

been having problems getting the Xilinx software setup. However we can attempt to build a ratio between the two devices. For example, the table (table 3) on the next page compares directly, the resources that both devices have available. As you can see there is a large increase on "on die" resources available. This does not mean that we can do the same task with fewer resources, just that the design will take up less space on this model. We must keep in mind that although there are more resources available, a larger number of resources will be used to route the data throughout the device. However this model is built using a different process of creating transistors, and thus will be able to run faster since the length of distance between individual elements is smaller on the same chip (up to a limit). We can see that the standard clock speed of the Spartan 6 is 2.5 times that of the tested unit. This will directly correlate to the speed of the device running from input to output. However this is not a 1:1 ratio, we cannot say it is due to the clock speed being higher since will run at 2.5x that of the Spartan3. But we can say that that speed available with the specific sequential calculations will be higher than that to some degree above 1 and below 2.5x. There are various factors to consider in this calculation, including the amount of actual processing that will be done (currently unknown), the clock speed of the other components in the design (memory, SATA, etc.). However, due to the amount of resources available and the low-end of the speed spectrum we know (250MHz), we can estimate that the speed will be closer to the 2x.

For example, say we are processing a pixel and we need to do X amount of math that takes Y seconds. Let’s say that Y is longer than 1/30th of a seconds (IR camera picture rate), this will cause a problem that we cannot process pictures fast enough. We will solve this not by making the FPGA faster, or have a higher clock speed, but instead by parallelizing the math done in X. This will reduce the time Y needed to process the pixel. Now, we realize that only so much can be done in parallel, and that we will not be utilizing all of the resources of this large FPGA. We will solve this next problem by parallel processing of multiple pixels simultaneously. There’s, no reason why we wouldn’t be able to just say copy the image pipeline above (A) and create another one called B. From this we can say after the pixel data is received for the next image, and pipeline A is not done yet, we can start the processing in B. This technique is very scalable, so the amount of processing we do is directly proportional to the number of parallel pipelines we will need to process all of the data in "real time".

16 | P a g e

Table 3: Comparing Spartan Models

Resource Type Spartan 3E-100 Spartan 6LXT75 % more than 3E-100

Slices 960 11,662 1210%

LUTs 1,920 46,648 2430%

Latch/FFs 1,920 93,296 4860%

User I/O 108 296 2740%

Diff. Pairs 40 148 370%

18x18SIO/DSP48a slices 4 132 3300%

Functional Clock Speed 100MHz 250MHZ 250%

Size of transistors 90nm process 45nm process 50%

Initially we will just use the FPGA as a large and super fast MUX. This will allow us to connect multiple cameras to the OEM board. The complexity of logic is much less than that of the Neural Network simulated in Test condition 1. This implies that the Speed from input pin to output pin will be less (however much so is irrelevant for this analysis, since 76MHz more than meets our needs) and here's why:

4.2.3.1     Visual Camera

10MP image size = 3664 x 2748 = 10,068,672 pixels

1 pixel = 12 bits of data (width of interface is 16 bits, so this works and gets passed in 1 clock cycle)

Clock cycles / pixel = 1

Number of images / second = 1

Speed = cycles / pixel * pixels * images / second = 1 * 10,068,672 * 1

17 | P a g e

Total required speed to get data in = 10,068,672Hz (or 10.07MHz)

4.2.3.2     IR Camera

    1.3MP image size = 640 x 480 = 307,200 pixels

1 pixel = 8 bits of data (width of interface is 16 bits, so this works and gets passed in 1 clock cycles, max)

Clock cycles / pixel = 1

Number of images / second = 30

Speed = cycles / pixel * pixels * images / second = 1 * 307,200 * 30 = 9,216,000

Total required speed to get data in = 9,216,000Hz (or 9.2MHz)

4.2.3.3         INS Unit Total size of data / capture = unkown

Total size of data / second = 1kB

RS-232 rate of device = unkown (serially so 1 bit / cycle)

# of captures = 30 (same as fastest image rate)

Total data needed to be recieved / second = #bits / #captures = 8000 / 30 = 270 bits = 34 bytes of data

Speed = 8000 bits / second = 8000 baud

**Note: Due to the fact that the INS will use the RS-232 standard, rates are calculated in Baud, or gross bit rate expressed in bits/second.

4.2.4     Discussion of Calculations

The calculations above show that the max speed for any type of camera connected to this system will be about 10MHz. From this we can ultimately say that yes, the image data will be able to be received in “real time” without causing any slow downs in the system. Now, you may be thinking if we use 6 cameras and each camera runs at 10MHz well that 60MHz to capture all the data. Well, you’re forgetting that the FPGA can do more than 1 thing at once. We can design capture components for each camera, individually running at 76MHz. Now, for sure all of this data will have to be funneled into the same place (DDR, SSD, OEM board). However once the data is inside the FPGA things run much faster as shown from the calculation of speed from the FPGA to the external pins at a speed of 200MHz. This speed is over and above what we would need for 6 cameras (60MHz).

18 | P a g e

4.2.5 ConclusionFrom the calculations above, the FPGA is able to handle getting the data in. Using the strategies

above we can appropriately parallel process to get all of the data in and processed successfully in the required time. The internal speeds of the FPGA allow plenty of time to organize the data and send it out to the various devices.

19 | P a g e

5 The Connector Board and External Interfaces

5.1 OverviewThe Connector Board will provide the electrical hardware interface for several of the system’s key requirements, namely the Inertial Measurement Unit (IMU) connector, the two Camera Link camera connectors and the primary system power supply connector. To facilitate the Camera Link cameras, circuitry will be included to convert from the Camera Link data format to the D3 Imager interface. Additionally, three of the six voltage levels needed by the system will be derived from the power supply using voltage regulator and monitoring circuitry.

The system specification provided by the customer instructed that two Gigabit Ethernet (GigE) connectors, one 10/100 Ethernet connector and one RCA output connector should be included, in addition to those already listed.

5.2 Design DecisionsInitially, some confusion was had over where each of the respective connectors would be mounted, with the original specification implying that all external connectors would be mounted on the Connector Board directly, although it was not clear how practical or necessary such an arrangement would be. After some deliberation, the decision was reached that the GigE, 10/100 Ethernet and RCA interfaces need not be associated with the Connector Board and that only the Camera Link connector should be mounted on the Connector Board itself. The reasoning for each decision follows:

The hardware driver for the two GigE connectors will be implemented in the FPGA, which was selected with this specific need in mind, with a facilitating IC chip on the FPGA Board. Since the hardware interface for GigE is relatively complicated, minimizing the number of transitions from board to wire, etc., is desirable. Therefore, the GigE connectors will be mounted on the FPGA Board. The GigE connectors will appear side-by-side, beneath the Camera Link connectors.

The 10/100 Ethernet and the RCA interfaces will be handled by the customer provided OEM Board, which has integrated support and connectors for both. Passing these interfaces from the OEM board to the FPGA Board and then to the Connector Board would be wasteful of board space and unnecessarily gratuitous. Therefore, a direct link from the OEM Board to panel mounted 10/100 Ethernet and RCA connectors will be used.

The IMU connector will be panel mounted in consideration of the large size of the connector and the limited space on the Connector Board – a DB-17 connector with integrated coaxial lines was found to be the most readily available option that satisfied both the needs for RS-232 support and for a coaxial data line. The various data lines will connect to a board header on the Connector Board with a direct link to the FPGA Board. Since the IMU interface uses the RS-232 standard to receive and respond to commands, a Null Modem configuration will be implemented on the Connector Board, to allow for proper communication.

The two Camera Link connectors will be mounted directly onto the Connector Board, in part because they will require non-trivial format conversion circuitry to operate with the FPGA and

20 | P a g e

OEM Board, but also because both will fit conveniently given the system size limitations. The Camera Link to D3 Imager format conversion circuitry will be placed on the Connector Board to save space on the FPGA Board; to limit the complexity of design, as the Camera Link uses differential signaling, which would complicate transfer from the Connector Board to the FPGA Board; and to minimize the number of data lines that must be transferred from the Connector Board to the FPGA Board, as the D3 Imager format will require fewer data lines than the Camera Link would.

The power supply connector will be panel mounted with a direct connection to the Connector Board via a board header. To prevent interference, which the circuitry on the FPGA Board may produce, the incoming power (9 to 36 Volts) will be switched to 12V, 5V and 3.3V on the Connector Board. These three voltage lines will be linked to the FPGA Board, where they will be further dropped to 2.5V, 1.8V and 1.2V. In addition to concerns over interference, the voltage regulators and monitors for some of the voltage lines will be placed on the Connector Board to save space on the FPGA Board.

5.3 Current DesignAfter determining the features and needs of the Connector Board, the block diagram in Figure 6 was developed to illustrate the design in an easily digestible form.

The block diagram was followed by development of a schematic for the Connector Board (Appendix A, Figure A1), which was itself derived from a circuit provided by the customer (Appendix A, Figure A2), which converts from the Camera Link format to the D3 Imager format. The circuitry for the power regulator is discussed in greater detail in its respective portion of this document.

21 | P a g e

In addition to the schematic developed, after all major Connector Board elements were determined (integrated circuits, connectors, etc.), an accurately sized “scarecrow” diagram was drawn to provide a realistic estimate of the minimum board size necessary for the Connector Board (Figure 7).

Figure 6: Block diagram of the Connector Board.

22 | P a g e

Figure 7: Accurately sized "scarecrow" diagram of the Connector Board.

23 | P a g e

6 Inertial Navigation System (INS)

6.1 OverviewAn INS combines location and orientation data retrieved from a Global Navigation Satellite System (GNSS) and an Inertial Measurement Unit (IMU). The best known GNSS is the U.S.’s Global Positioning System (GPS), although the Russian GLONASS system is also operational and several other systems are in development. An IMU is a local device that determines what direction the device is facing and at what speed it is moving.

6.2 DetailsThe original customer specification called for a complete INS to be implemented, although cost and availability concerns have scaled the requirement back to supporting just the GNSS, with plans to include an IMU if one can be acquired that satisfies our needs at a cost acceptable to the customer.

The customer has also specified that the NovAtel OEMV brand of GNSS receivers should be used, with the most likely choice coming down to either the OEMV-2 (Figure 3) or the OEMV-3 (Figure 4), although the final decision is ongoing. While both support data transfer using an RS-232 serial communications bus, in conjunction with a coaxial data line, the power requirements are for each are not the same: The OEMV-2 requires a 3.3 +5%/-3% VDC power supply, whereas the OEMV-3 requires a 4.5 to 18 VDC power supply. If we do not have a final selection prior to finalizing our designs, both possibilities will need to be accounted for.

6.3 SoftwareSoftware interaction with the OEMV board will be performed using a routine in the customer supplied OEM Board Digital Signal Processor (DSP). Communication with the OEMV involves sending commands over the RS-232 serial communications bus in either ASCII (plain text, verbose), abbreviated ASCII (plain text, non-verbose) or Binary (ones and zeros) format. Responses are sent from the OEMV board in like format, with some data being sent over a coaxial data line.

While detailed software specifications have yet to be written, a flowchart has been developed to illustrate the fundamental routine for interfacing with the OEMV board (Figure 5).

Figure 8: OEMV-2 GNSS receiver board.

24 | P a g e

Figure 9: OEMV-3 GNSS receiver board.

Figure 10: Basic routine for interfacing with the OEMV GNSS board.

25 | P a g e

7 Chassis Interfaces

7.1 NeedsThe chassis must meet two distinct sets of interface criteria. Firstly, it must interface with the electronics it was designed to enclose. It must house them internally as well as provide for their interface with external equipment. The customer also requires that the cameras be separable from the processing electronics. Secondly, it must interface with two airframes: those of a conventional single-propeller passenger plane as well as that of the RIT UAV Airframe “C” design. The former represents the flight platform that will actually be used by the customer. The latter represents a “loose” constraint; the RIT airframe is used merely as a means to obtain a tighter size restriction. The customer desires that the module be “compact”, so Airframe “C” is used as the design spec for “compact”.

7.2 Specifications

7.2.1 Aircraft SpecificationsThe specifications required to meet the above stated needs are summarized in the table below.

Table 4: Differences between Aircraft and UAV to consider when designing the chassis

Small Passenger Aircraft RIT U.A.V. Airframe “C”

Must be mountable to a flat plate Must be mountable to a flat wooden base

Smaller that a person; Approx 2’ x 2’ x 5’6” tall

Less than 16” x 6.5” x 5” tall

Less than 150lbs (68kg) Less than 15lbs (6.8kg)

Though all efforts will be made to conform to the requirements of Airframe “C”, failure to comply will not render the device unsuccessful.

26 | P a g e

7.2.2 Electronics SpecificationsThe chassis must contain the following electronic connectors on its outside surface:

– 2 Gigabit Ethernet– 1 10/100 Ethernet– 2 CameraLink – 1 DB-9 w/ Integral Coaxial– 1 RCA Video– 1 3-Pin Amphenol Power – 1 Indicator LED– 1 USB

The chassis must house the following components:

– 4 D3 Cameras with lenses*– 1 D3 OEM Image Processor Board– 1 FPGA-Based Controller Board– 1 Custom built connector board– 1 NovAtel OEMV-3 GPS Board– 1 MicroStrain 3DM-series IMU– 1 2.5” Solid-state hard drive– Interconnecting wiring for the above

*Lenses are Linos Mevis-C 16mm

7.3 DesignThe finalized design of the chassis can be seen in section 8.4.4. It encloses all of the components mentioned in section 7.2.2, dividing them into two sub-sections. The optics sub-section encompasses the cameras, lenses, and the IMU device, and serves as the base of the device. This larger enclosure determines the footprint of the device. The electronics sub-section encloses the remainder of the capture and processing hardware, and sits atop the optics section during normal use. The sub-sections are separable, and both capable of being mounted safely when separated.

Overall, the system measures 10.25” long x 6” wide x 6.5” tall and weighs 10.9 pounds. These specifications meet the requirements of the RIT UAV Airframe “C” payload in every measure but height. Because the height exceeds the allowable measure by a full 1.5”, it is not practical to attempt to meet the requirement by optimizing this configuration.

27 | P a g e

8 Vibration Damping

8.1 NeedsThe device needs to maintain structural integrity as well as take clear pictures while being subjected to normal aircraft vibrations.

8.2 Considerations

8.2.1 Frequencies of Aircraft The vibration character of the aircraft that the module will be mounted in is taken to be the vibration spectrum defined in RTCA DO-160, Section 8. Test category “S” is used, representing a standard, fixed-wing aircraft during normal operation. The device is assumed to be mounted in Aircraft Zone 2 (“Instrument Panel, Console & Equipment Rack”).

The vibration character is a sinusoidal wave, defined by varying frequencies and peak-to-peak amplitudes. The vibration spectrum is as follows:

Frequency Amplitude

5 – 15 Hz 0.1 in

15 – 55 Hz 0.01 in

55 – 500 Hz Linear Range: 0.01 in @ 55 Hz, 0.0002 in @ 500 Hz

8.2.2 Allowable Vibration in ImageThe clarity of images is quantified by a quality colloquially known as “smear”, measured in terms of the number of pixels worth of distance that the aircraft moves when the shutter is open. Smear is a function of aircraft speed and altitude, the image angle of the lenses in use, and the aircraft shutter speed. Smear is desired to be less than half a pixel, and smear must be less than one pixel.

The following flight parameters represent normal aircraft operation:

Max. Aircraft Speed: 70 knotsAltitude Range: 1000 – 5000 ft.Lens Focal Length: 25 mmLens Image Angle: 38.1°

An additional speed was accounted for due to the vibration. This speed was calculated as the derivative of the equation of motion of vibration. Thus, the known position equation: X=A sin(Ft ) yields the equation of speed: X '=FA cos(Ft ). Thus, the maximum speed due to vibration is FA. For calculation purposes, 0.1 in. and 500 Hz were used, which translate to a maximum speed of 1.27 m/s

28 | P a g e

Calculated smear due to aircraft speed was found to be 0.66 pixels at 1000ft and 0.13 pixels at 5000ft. Smear reduces to a desired limit at 1500ft, achieving a smear of 0.44 pixels. Smear due to vibration induced speeds was found to be an order of magnitude less than that due to aircraft speed. At 1000ft, smear is 0.023 pixels, reducing to 0.0047 pixels at 5000ft.

8.2.3 Component Resonant FrequenciesMost parts are small and rigid, causing resonant frequencies to be higher than will likely be experienced. This category is not to be forgotten, as more detailed data may reveal otherwise, but it is very low on the scale of actual risk of damaging the system.

29 | P a g e

8.3 ApproachPrior to the analysis of Sec. 8.2.2, it was thought that some form of mechanical isolation would be required in order to eliminate image distortion. However, it has come to light that the vibration character of the aircraft will not significantly distort image quality.

Figure 11: Solid Works model of System

In light of new developments, this design is no longer necessary. Not only are isolating mounts no longer necessary, but it is possible that they will amplify the vibration the chassis actually experiences. At present, the design will call for a flat flange to mount directly to a flooring surface.

30 | P a g e

Rubber Damping MountsOptical Enclosure

Electronics Enclosure

8.4 Chassis Design

8.4.1 Phase 1: Individual Compartments

Figure 12: Showing the first phase of design of Individual components

31 | P a g e

8.4.2 Phase 2: Assure Component Scale

Figure 13: Solid Works model showing Dummy Solids of Major Electrical components

Above: Dummy solids of major electrical components fit snugly in a 5.5” x 5.5” x 3” space. Below, four customer-specified lenses fit well into an enclosure of similar cross section.

Figure 14: Solid Works model showing Camera Lenses

32 | P a g e

8.4.3 Phase 3: Detailed design to allow for realistic thermal, vibrational, and spatial analysis

Figure 15: Solid works Model showing System design

- Vibrational dampers mount on center flange

- Interial grooves allow for component mounting to be modular, changeable, and secure

- Stock extruded enclosure reduces build time

- “Stacked” configuration maintains thermal separation at a minimal “footprint”

33 | P a g e

8.4.4 Phase 4: Final Mechanical Design

- Vibration damping omitted due to recent analysis- Custom machined to minimize size - Separates Optics from Electronics, minimizes footprint- Internals mounted on sub-frame, renders primary enclosure adaptable to new configurations

and different hardware.

34 | P a g e

35 | P a g e

9 Environmental Management

9.1 Heat

9.1.1 Major sources of heat generation inside chassis Hard drive

o about the half the heat produced comes from this Voltage Regulator FPGA DSP

9.1.2 Heat Transfer modelso All models are for steady state

Radiationo Model as black body

From electronics to chassis From chassis to external environment

Conductiono From electronics into chassis

Heat travels through ground planes on boards May route heat through standoffs

o From Chassis to external environment Through chassis material into external environment

Convectiono Negligible

Minimal (if any) moving air

36 | P a g e

Board stack

Chassis wall

q chassis

q board

-T chassis

-T boards

-T ambient-T chassis

9.2 Heat Transfer analysis, a radiation model

9.2.1 Assumptions

• Treat enclosure as a black box radiating heat to the outside air

• Neglect Convection• Protected from moving air

• Neglect Conduction• Only connected to airplane by

small vibration dampers• Temperature at surface of chassis =

temperature inside of chassis• All Power consumed by electronics is output

as heat radiating out• = .89 • Heat radiating from chassis is 50% of heat radiating from boards (qc = .5qb)

9.2.2 Analysis- Black box radiation :

σε T chassis4 =σε T ambient

4 +qchassisA chassis

σε T boards4 =σεT chassis

4 +qboardsAboards

Combined, this gives:

σε T boards4 =σεT ambient

4 +qchassisA chassis

+qboardsAboards

¿σε T ambient4 +

.5qboardsA chassis

+qboardsAboards

¿σε T ambient4 +qboards (

12 Achassis

+ 1Aboards

)

Re-arranged and solved for Tboards:

T boards=4√σεT ambient4 +qboards (

12 A chassis

+ 1Aboards

)

9.2.3 VariablesT chassis – temperature of chassis (K)T Ambient – temperature of environment outside of chassis (K) Tambient= (Tground (c)- altitude

(m)*6.5/1000)+273)q chassis – heat radiating from chassis (W)

q boards – heat radiating from electronics inside chassis (W)A chassis – surface area of chassis (m2)A boards – surface area of electronics (m2) - Stefan–Boltzmann constant: 5.67 x 10-8

(Wm-2K-4)

37 | P a g e

electronics Chassis wall

E outEgen

T s2

-T ambient

Ts1

Ein

- emissivity of the chassis

From spreadsheet solution of the above equations:

From this, if we have much more than 15 watts of heat generated by the electronics, the electronics will overheat. Having only radiation is a worst case scenario. Looking at another model may prove worthwhile.

9.3 Heat Transfer analysis, a conductive model

Assume: Ts1 = ambient temperature inside the chassisTs2 =ambient temperature outside the chassisTreat Egen as if the energy is being generated in

walldx= thickness of wall

According to conservation of energy: Ein+Egen-Eout=Estored (when we assume steady state, Estored=0)In our case:

- Egen is all the heat generated by the electronics which is equal to the power required by them -Ein is all the heat entering the chassis wall-Eout is all the heat exiting the chassis wall

Mathematically defining the terms:Egen = I2REin=-KAdTS1/dx

Eout=- KAdTS2/dx

Which gives:-KAdT/dx+ I2R-(- KAdT/dx)=0I2R = -KA(TS2-TS1/dx)

Solving for TS1:Ts1 = (I2R/KA)dx+Ts2

Variables:I2R : power supplied to electronicsTs1: (temp on inside of chassis wall) Ts2: (temp on outside of chassis wall)K: thermal conductivity of materialA: total surface area of chassisdx: thickness of chassis walls

from spreadsheet solution of the above equations:This model is not all encompassing either. Looking at a more detailed conduction and radiation model may be valuable.

38 | P a g e

Board dimensions

chassis dimensions

atmosheric conditions heat transfer

Aboards (m) a total (m2) tair Pgen (w) Tboards Final (°C)0.03677412 0.11320526 218 50 154.91989230.03677412 0.11320526 241.15 50 158.45584160.03677412 0.11320526 218 100 231.57864360.03677412 0.11320526 241.15 100 233.74861410.03677412 0.11320526 218 15 55.416331050.03677412 0.11320526 241.15 15 63.06223622

box dimensions (cm)

atmosheric conditions heat transfer

a total (cm2) s (m) tair

k,AL (W/mK)

Pgen (w) Ts1, box (k) Ts1, box (C)

0.1132 0.012 218 30 50 218.1766702 -54.82332980.1132 0.012 318 30 50 318.1766702 45.176670240.1132 0.012 218 30 100 218.3533405 -54.64665950.1132 0.012 318 30 100 318.3533405 45.353340470.1132 0.012 218 30 15 218.0530011 -54.94699890.1132 0.012 318 30 15 318.0530011 45.05300107

electronicsChassis wall

T aTb

Board mounting plate

standoffs

radiation radiation

9.4 Heat Transfer analysis, a combined mode approach Modeling as a thermal circuit where:

Tb-Ta = q Req And Req = Reach element The conductive resistances are:

Rc1=X1/K1A1

X1 = length of standoffs K1=conductivity of standoffs A1= Surface area of standoffsRc2=X2/K2A2

X2 = depth of mounting plate K2=conductivity of mounting plate A2= Surface area of mounting plateRc3=X2/K3A3

X3 = depth of wall K3=conductivity of wall A3= Surface area of wall

The radiation resistances are: Rr1= 1/hr1Ar1

Rr2=1/hr2Ar2

Ar1= Surface area of boardsAr2= Surface area of chassishr1=(Tb+Tin) (T2

b+T2in)

hr2=(Tb+Ta) (T2b+T2

a)Assuming:Tin= .7Tb

Twall= Tb

=.89= 5.67 x 10-8 (Wm-2K-4)

*I’m not quite sure how to model radiation without knowing Tb, since this is the value I’m trying to find…

39 | P a g e

Conduction between board mount and chassis wallRadiation between wall and external environment

Radiation between wall and external environmentConduction between board mount and chassis wall

Tb Ta

Standoffs: 4 conductive resistances in parallelRadiation between electronics and board mount

conduction between chassis wall and external environmentRadiation between electronics and board mountconduction between chassis wall and external environmentStandoffs: 4 conductive resistances in parallel

The equivalent resistance looks like this:

Req=( 1

( 4Rc1 ))+(Rr 1)+(Rc2)+(R c3)+(Rr 2)

Using the model:Tb = qReq+Ta

We get:Tb = q[((X1/K1A1)/4)+ (Rr1) + (X2/K2A2)+( X3/K3A3)+(Rr2) )]+Ta

Though I’m not entirely sure how to model it, I expect the solution to be between those of the first two models…

Sources:Fundamentals of heat and mass transfer by Incorpora et alHeat Transfer: a practical approach by Yunis A. Cengel For lapse rate in the troposphere: www.uwsp.edu and http://en.wikipedia.org/wiki/Tropopause Emissivity coefficients: http://www.engineeringtoolbox.com/emissivity-coefficients-d_447.html

40 | P a g e

10 Other Environmental Considerations: Condensation

10.1 Dew Point analysisDew point, the temperature at which water will condense on a surface, is a

function of ambient temperature and relative humidity. Knowing the dew point will tell whether additional steps should be taken to control temperature and/or humidity inside the chassis.

Dew point temperature is given as:

T d=T n ∙ln RH100%

+ m∙TT n+T

m−ln RH100%

− m∙TT n+T

Variables: Td - Dew point (C)T - Ambient temperature (C)RH - Relative humidity (%)m - Temperature range dependant constant (non-dimensional)Tn - Temperature range dependant constant (C)

From spreadsheet solution of the above equation (and info I currently have): Condensation may be a problem.

41 | P a g e

constantstemp range Tn (C) m0 to 50 243.12 17.62-40 to 0 272.62 22.46

RH T air (°c) dew point (°c)50 -32.6096 -38.9581750 47.021848 34.011322

1 -33.978152 -70.29261

There are two main options, including a heater to keep temperature inside the chassis above the dew point and reducing humidity inside the chassis to lower the dew point inside the chassis (a common method for doing this is to use silica gel)

42 | P a g e

Comparison of methods:    Heater system silica gel pack

weight rank with weight rank with weighteffective at reducing/preventing condensation

5 2 10 2 10

simplicity in manufacturing/implementation

3 -1 -3 1 3

allows for flexibility as heat requirements change

4 1 4 2 8

allows for air/water tight enclosure 2 2 4 2 4

total: 21 31

From this comparison: a compact silica gel pack of an appropriate size appears to be the best choice.Source for dew point info: www.sensirion.com sensor company explaining how to use info from sensors to calculate dew point

43 | P a g e

11 Mounting

11.1 Internal MountingWeighing different techniques against each other:Considerations heat management techniques

weight

central conductive mounting backbone wi

th w

eigh

t mount each piece to chassis seperately

with

wei

ght separate

optics and electronics packages

with

wei

ght single

package to house all components

with

wei

ght

effective at removing heat

5 1 5 1 5 1 5 1 5

effective at retaining heat

5 1 5 1 5 1 5 1 5

simplicity in manufacturing

3 2 6 -2 -6 -1 -3 1 3

allows for flexability as heat requirements change

4 1 4 1 4 1 4 0 0

meets temperature needs of specific components

5 0 0 0 0 2 10 -1 -5

allows for air/water tight enclosure

2 1 2 1 4 1 2 1 4

total: 22 12 23 12

44 | P a g e

11.1.1 Electronics mountingConsiderations:

Relations of components to one another Board to board mounting Cable connections External connections/locations

Customer’s desire for reconfigure-ability of hardware components Need for easy access to FPGA for reprogramming Need for easy access of hard drive

Manufacturability

Beginning concepts:

Beginning refinement:

45 | P a g e

Cantilever shelf mounted

mounted on frame of bars

-Handle on top for ease of access

-top and bottom plates fit into pre-cut grooves in chassis walls

-four stands connect top and bottom plates

-electronics connect to top and bottom plates

Side view Top view, gray portion represents top/bottom plates

46 | P a g e

Hole in center of plate for cables

Room for 4 cameras and additional space to mount other items (IMU?)

Side supports fit into inner grooves in chassis

Further refinement:

11.1.2 Optics mounting

Refined concepts

47 | P a g e

Main board stack

Main board stack and ssd mounted to frame that slides into enclosure via. Grooves cut into inner surface

11.2 External MountingDesign is still incomplete.

48 | P a g e

12 Appendix

12.1 Connector Board Schematic

Figure A1: Schematic for the Connector Board. The voltage regulator and monitor, represented by the lowermost symbol in the bottom right-hand corner, are discussed in greater detail in the Power section of this document.

49 | P a g e

12.1 CameraLink® to D3 Chip Schematic

Figure A2: Customer provided circuit to convert from the Camera Link format to the D3 Imager format used by the FPGA and the OEM Boards.

50 | P a g e