Hardware-Software Interfaces

The Ethernet/PCIe DAQ board (EDAQ) has multiple hardware-software interface options to provide system architecture flexibility for the integrator.

Two distinct virtual interfaces between the EDAQ hardware and the host PC software are utilized, generally referred to as the Control interface and the Capture interface:

Control Interface

The Control interface is low-bandwidth, bidirectional, and consists of command & control, diagnostics, configuration, and status messaging between the EDAQ hardware and host software. It is also used for updating firmware on the EDAQ board. The Control Interface is also used for command & control messaging with the Laser Engine board and CameraLink DAQ board.

Capture Interface

The Capture interface is high-bandwidth, unidirectional (from EDAQ to host only), and consists of the OCT image data stream generated by the EDAQ and transmitted to the host software for subsequent display, analysis, and archival by the user. The Capture Interface is relevant to the Ethernet/PCIe DAQ only.

Physical Interfaces

There are also several physical interfaces supported between the EDAQ hardware and host PC, including USB 2.0, Gigabit Ethernet, USB 3.0 [1], and PCI-Express (PCIe). For the Axsun Integrated Engine configuration, a RS-232 interface directly between the EDAQ and the Laser Engine board provides a convenient pass-thru of laser messages via this serial connection when the EDAQ is connected to the host via Ethernet/USB 3.0.

The Control and Capture virtual interfaces are supported on the EDAQ’s physical interfaces according to the following table:

​[1] All Ethernet functionality described in this manual is also supported over USB 3.0 via a separate Ethernet-to-USB 3.0 converter based on the Realtek RTL8153 chipset. For example: https://www.amazon.com/Anker-Portable-Aluminum-Ethernet-Supporting/dp/B00PC0H9IE​

Software Libraries

The Capture and Control virtual interfaces are decomposed into two separate Windows OS dynamic link libraries: AxsunOCTControl.dll and AxsunOCTCapture.dll (or *.so for corresponding Linux OS shared object or *.dylib for corresponding MacOS shared object). There is one exception: some limited PCIe-only Control functionality is provided by the AxsunOCTCapture.dll library.

Axsun provides basic GUI tools for exercising the functionality provided in the Capture and Control libraries, as well as APIs and sample code for each of the libraries for system integrators to develop custom applications based on these libraries.

This multi-library software architecture is convenient in the API integration phase of custom software development because it allows the integrator to debug new code based on one library while relying on an Axsun-provided GUI tool to exercise functionality in the other library. Once new code has been developed at the module level for both libraries separately, final integration of these modules into a single application can be achieved with more confidence and less debugging complexity.

A summary of the Capture and Control library characteristics is provided in the following table:

Hardware Architecture

The Axsun EDAQ employs both a small microcontroller and a large FPGA processor. The microcontroller is responsible for managing bidirectional communications with the Host PC via the AxsunOCTControl intreface and with a connected Laser Engine board, for loading its own program and the FPGA program at power-on, for managing non-volatile configuration settings, and for providing USB 2.0 I/O. The FPGA is responsible for computationally intensive tasks such as OCT image formation (Fourier transformation, compression, etc.) and also provides the Gigabit Ethernet and PCIe I/O.

The integration strategy for systems based on the EDAQ will likely depend on whether Ethernet or PCIe is the preferred method for transmitting high-bandwidth image data for the specific application. The Ethernet-based implementation is more straightforward from the perspective of cable interconnects and is easier to achieve a high degree of portability, especially if physical separation between the DAQ and the host PC is required and if JPEG image compression is tolerable. The PCIe-based implementation requires close proximity between the DAQ and the host PC, but supports data transfer of raw, partially-processed, or fully-processed data without lossy compression at full A-line rates.

The following block diagrams show basic Ethernet, USB, and PCIe interconnections for the EDAQ and associated Laser Engine board in the Axsun Integrated Engine, along with the software libraries which utilize these interfaces:

Ethernet Mode (also USB 3.0 Mode)

PCIe Mode

GUI Tools

The AxsunOCTCapture API and AxsunOCTControl API enable users to integrate library functionality in custom executables for application-specific workflows and requirements. Axsun also provides several Windows-based GUI Tools for exercising basic library functionality without the need for custom software development.

Image Capture Tool

The Image Capture Tool (AxsunImageCaptureTool.exe) is a LabVIEW-based application which exemplifies the core functionality provided by the AxsunOCTCapture library, including live image display, on-demand image retrieval by unique image number, indication of the EDAQ’s imaging mode, Image_sync trigger status, and main image buffer statistics.

Secondary functionality includes controls for the direct OpenGL rendering features, real-time image averaging, image cropping, saving & loading, and some FPGA register access (PCIe interface only).

Hardware Control Tool

The Hardware Control Tool (AxsunHardwareControlTool.exe) is a LabVIEW-based application that provides push-button operation for many of the basic functions of the EDAQ and laser via the AxsunOCTControl library, including the indication of hardware connectivity, toggling laser emission on/off, toggling DAQ imaging mode on/off, starting a burst record operation, adjusting the K-clock delay, and controlling a motorized variable delay line (if installed).

High-level DAQ functionality (achieved via scripted low-level FPGA register reading/writing) is provided on separate tabs and includes setting power-on defaults, programming a user-defined windowing function, polarization channel selection, dispersion compensation, background subtraction, and raw data / bypass mode configuration.

OCT Host

OCT Host (OCTHost.exe) is a Windows Forms-based GUI that provides a subset of the features of the Hardware Control Tool (also via the AxsunOCTControl library), including toggling laser emission on/off, indicating hardware connectivity state, adjusting the K-clock delay, and controlling a motorized variable delay line (if installed). OCT Host also provides more advanced laser diagnostics, maintenance, and debugging information, as well as system firmware upgrade capabilities. EDAQ functionally in OCT Host is limited to low-level operations such as FPGA register reading/writing and setting power-on defaults in non-volatile RAM.

Summary of GUI Tools

The following table summarizes some of the characteristics and functionality of the Axsun-provided GUI Tools:

FPGA Image Processing Pipeline

Analog-to-Digital Conversion

Two 12-bit Analog-to-Digital Converters (ADC) perform digitization of two separate analog OCT signals at the front end of the image processing pipeline. These two channels are typically used for acquiring horizontal $(\textbf{H})$ and vertical $(\textbf{V})$ polarization signals for OCT interferometers in a polarization diverse configuration, but one channel can be disabled for non-polarization diverse configurations.

Windowing and Zero-Padding

The number of raw data samples $(N_{samp})$acquired for each A-scan depends on the laser source bandwidth and k-clock determined scan depth, up to a maximum of 2048 samples. A programmable apodization window function consisting of $N_{samp}$ values concatenated with additional zeros for a total vector length of 2048 is multiplied by the sampled raw data, effectively windowing and zero-padding the raw data to 2048 samples in a single step. The window function is complex-valued in order to provide compensation of group delay dispersion.

Fourier Transformation, Complex Modulus, and Polarization Mixer

Following Inverse Fast Fourier Transformation of each channel, the negative frequencies are truncated (they are symmetric and thus redundant) and the complex modulus is calculated on the remaining 1024 samples. The complex modulus of each channel is the square root of the sum of the squares of the real and imaginary components of the IFFT output. The polarization diverse output is the square root of the sum of the squares of the complex moduli of the H and V channels. Conveniently, a level of square roots and squares cancel out, reducing the overall result to the square root of the sum of the squares of the two $Real$ and two $Imaginary$ components of the two channels, a linearly-scaled OCT intensity signal:

Logarithmic Compression and Dynamic Range Reduction

OCT images are typically displayed with a logarithmic intensity scaling on a monitor which provides no more than 256 grey levels (8-bit). The logarithmically-scaled OCT intensity signal or power spectrum $(\textbf{PS})$ is calculated with 16-bit precision as:

For dynamic-range reduction (16- to 8-bit), a user-configurable GAIN and OFFSET is applied to scale and shift the output values appropriately prior to truncation of the lowest byte. This is analogous to a Brightness/Contrast or White-level/Black-level adjustment. The result is an 8-bit power spectrum appropriate for display:

JPEG Compression (Ethernet interface only)

JPEG compression with a quality factor of 30 results in average bandwidth reduction of approximately 3x on the transmitted OCT intensity image. Although JPEG compression is lossy, this compression ratio provides qualitatively equivalent images as the non-compressed mode and is typically sufficient for image analysis by the naked-eye. Users applying advanced quantitative image processing algorithms such as automated classification or texture analysis should investigate the effects of logarithmic, dynamic range, and JPEG compression on an individual basis and consider using the PCIe interface if access to non-compressed data is required.