United Electronic Industries Industries DNx-ARINC-664 CPU Module User Manual

United Electronic Industries Industries DNx-ARINC-664 CPU Module

Product Information

Specifications

• Product Name: DNx-ARINC-664
• User Manual: ARINC-664 Protocol Communications Interface for the PowerDNA Cube or RACK series chassis
• Publication Date: November 2023
• Part Number: Man-DNx-ARINC-664

Features

• ARINC-664 protocol communications interface
• Compatible with PowerDNA Cube or RACK series chassis

Indicators
The product features indicators for status and activity monitoring.

Specifications
The specifications of the DNx-ARINC-664 are as follows:

• Device Architecture: Device RTOS
• Wiring & Connectors: Connecting to the ARINC-664 Network

Device Architecture
The DNx-ARINC-664 utilizes a Device RTOS for efficient and reliable performance.

Wiring & Connectors
To connect to the ARINC-664 network, follow the wiring and connector instructions provided in the manual.

Product Usage Instructions

Introduction
The introduction chapter provides an overview of the product and its organization within the manual.

Programming with the Low-level API
This chapter explains how to program the DNx-ARINC-664 using the low-level API. It covers the functions and their usage.

Frequently Asked Questions

• Can the DNx-ARINC-664 be used with any PowerDNA Cube or RACK series chassis?
  Yes, the DNx-ARINC-664 is compatible with the PowerDNA Cube or RACK series chassis.

• What is the device architecture used by the DNx-ARINC-664?
  The DNx-ARINC-664 utilizes a Device RTOS for efficient and reliable performance.

• How do I connect the DNx-ARINC-664 to the ARINC-664 network?
  Refer to the wiring and connector instructions provided in the manual for detailed steps on connecting the DNx-ARINC-664 to the ARINC-664 network.

© Copyright 1998-2023 United Electronic Industries, Inc. All rights reserved.

• No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form by any means, electronic, mechanical, by photocopying, recording, or otherwise without prior written permission.
• Information furnished in this manual is believed to be accurate and reliable. However, no responsibility is assumed for its use, or for any infringement of patents or other rights of third parties that may result from its use.
• All product names listed are trademarks or trade names of their respective companies.

See the UEI website for complete terms and conditions of sale:
http://www.ueidaq.com/cms/terms-and-conditions

Contacting United Electronic Industries

Mailing Address:
249 Vanderbilt Avenue Norwood, MA 02062 U.S.A.

Shipping Address:
24 Morgan Drive Norwood, MA 02062 U.S.A.

For a list of our distributors and partners in the US and around the world, don’t hesitate to get in touch with a member of our support team:

Support:

• Telephone: 508-921-4600
• Fax: 508-668-2350

Also, see our website’s FAQs and online “Live Help” feature.

Internet Support:

• Support: uei.support@ametek.com
• Web-Site: www.ueidaq.com
• FTP Site: ftp://ftp.ueidaq.com.

Product Disclaimer:

WARNING!
DO NOT USE PRODUCTS SOLD BY UNITED ELECTRONIC INDUSTRIES, INC. AS CRITICAL COMPONENTS IN LIFE SUPPORT DEVICES OR SYSTEMS.

Products sold by United Electronic Industries, Inc. are not authorized for use as critical components in life support devices or systems. A critical component is any component of a life support device or system whose failure to perform can be reasonably expected to cause the failure of the life support device or system or to affect its safety or effectiveness. Any attempt to purchase any United Electronic Industries, Inc. product for that purpose is null and void and United Electronic Industries Inc. accepts no liability whatsoever in contract, tort, or otherwise whether or not resulting from our or our employees’ negligence or failure to detect an improper purchase.

Specifications in this document are subject to change without notice. Check with UEI for the current status.

Introduction

This document outlines the feature set of the DNx-ARINC-664 board and its use as an ARINC-664 communications interface.

Manual Conventions

• To help you get the most out of this manual and our products, please note that we use the following conventions:
• Tips are designed to highlight quick ways to get the job done or to reveal good ideas you might not discover on your own.
• NOTE: Notes alert you to important information.
• CAUTION! Caution advises you of precautions to take to avoid injury, data loss, and damage to your boards or a system crash.
• Text formatted in bold typeface generally represents text that should be entered verbatim. For instance, it can represent a command, as in the following example: “You can instruct users how to run setup using a command such as setup.exe.”
• Text formatted in fixed typeface generally represents source code or other text that should be entered verbatim into the source code, initialization, or other file.

Examples of Manual Conventions
Before plugging any I/O connector into the Cube or RACKtangle, be sure to remove power from all field wiring. Failure to do so may cause severe damage to the equipment.

Usage of Terms
Throughout this manual, the term “Cube” refers to either a PowerDNA Cube product or to a PowerDNR RACKtangle TM rack-mounted system, whichever is applicable. The term DNR is a specific reference to the RACKtangle, DNA to the PowerDNA I/O Cube, and DNx to refer to both.

DNx-ARINC-664 Board Overview

The DNx-ARINC-664 is a 2 channel communications interface compatible with ARINC-664 Part 7 (a.k.a. ARINC-664 and the Airbus variant). The DNA-ARINC-664 and DNR-ARINC-664 versions are designed for UEI’s Cube and RACKtangle I/O chassis respectively. Channels may be configured as a single A or B channel or as one dual redundant channel. The network implementation supports 10/100/1000BASE-T. Each channel may operate as a transceiver, transmitter, or receiver.

• ARINC-664 Receiver
  In input mode, the user may time tag inputs with resolutions as low as 10 microseconds. The input automatically provides error/integrity checking, but this feature may be disabled in software if the application requires it. Receive filtering of virtual link (VL), port, and error properties is also supported.

• ARINC-664 Monitor
  Monitor mode allows the user to capture network traffic, providing the capability of capturing select information with automatic filtering. Monitor mode will also gather a variety of statistics from the bus/network. If desired, monitor mode may be set to capture UDP network traffic statistics, regardless of whether it is configured based on the ARINC-664 protocol.

• ARINC-664 Transmitter
  Transmit channels automatically configure traffic shaping via Bandwidth Allocation Gaps (BAGs) that can be set for 1, 2, 4, 8, 16, 32, 64, or 128 millisecond timing. Transmission may be based on an automatic scheduler or in one-shot asynchronous mode. Both unicast and multicast virtual links are fully supported. The transmitter generates and tags consecutive Sequence Numbers.

• Certification
  The board is based on the Freescale 8347 processor running the DO-178 certified µC Operating System. In PowerDNA mode, the Cube/RACK itself also uses µC/OS, so even though the units are not certified to DO-178, the fact that the operating system already is will dramatically reduce certification time. Advanced users may also wish to implement special functions in the board’s firmware which can be accessed with custom µC code. The Cube/RACK is well supported with a variety of debugging tools, and additionally, a dedicated RS-232 diagnostic port is provided on the board allowing easy access to the lowest levels of the board’s functionality.

• Software Support
  Software for the DNx-ARINC-664 series is provided with the UEI Software Suite, which includes an easy-to-use API for Windows and Linux.

**Features

**

The DNx-ARINC-664 features are as follws:

• Compatible with ARINC-664 Part 7 (a.k.a. ARINC-664 and the Airbus variant)
• 2 independent or 1 dual redundant channels
• 100 BASE-T default (10/100/1000BASE-T capability)
• Transmitter and/or Receiver functions
• Extensive error detection
• Extensive filtering and traffic scheduling
• Tested to withstand 5 g Vibration, 50 g Shock, -40 to +85°C Temperature, and Altitude up to 70,000 ft or 21,000 meters
• Weight of 150 g or 5.3 oz for DNA-ARINC-664; 162 g or 5.7 oz for DNR

Indicators

The Rack version of the DNx-ARINC-664 is shown in Figure 1-1.

Specification

The technical specification for DNx-ARINC-664 is provided in Table 1-1.

Table 1-1 . DNx-ARINC-664 Technical Specifications

ARINC-664 Overview

The ARINC-664 standard defines an aircraft data network in 8 parts. Part 71 of the standard (ARINC-664P7) specifies a deterministic network on the OSI data link layer. The UEI DNx-ARINC-664 board supports the standard ARINC-664 specification, but does not support the Boeing EDE extension. ARINC-664 is similar to ARINC-429, ARINC-629, MIL-STD-1553 in that it allows any two avionics devices to communicate reliably and deterministically within a specific time-interval across a fault-tolerant dual-redundant bus but with faster rates of communication, less wire, and lower cost using COTS components.

DNx-ARINC-664 Applications
The DNx-ARINC-664 can be used to send, receive, or report traffic on an ARINC-664 network. In practice, the DNx-ARINC-664 is used for the following applications:

• Test and debug of avionics network equipment during development, such as:
  • passively monitoring traffic (data/statistics) from specific ARINC-664 ports
  • actively inserting traffic onto the bus to provide input to equipment
• Emulate real plane traffic for physical avionic equipment (e.g., display LRUs) of commercial aircraft simulator(s)

Figure 1-2 shows an example of multiple avionics devices emulated by the DNx- ARINC-664:

The DNx-ARINC-664 provides the following capabilities in an ARINC-664 network:

• emulation of the ARINC-653 end system, partition, virtual links, & ports
• filtering of the received message by address and error
• scheduling transmission and periodic retransmissions required by the underlying ARINC-664 communication protocol

The DNx-ARINC-664 board is configurable by XML into the mode you require.

Once configured, the DNx-ARINC-664 allows your program to abstract away everything to ARINC-664 messages, allowing you to communicate using a handful of simple function calls documented in the PowerDNA API. Refer to Chapter 2 for more information about the DNx-ARINC-664 API and XML configuration. The remainder of this section explains the structure and behavior of ARINC-664 network nodes, as well as defines the most common attributes, terms and definitions.

ARINC-664 Network Overview
Figure 1-3 shows an example of aircraft network topology:

ARINC-664 Part 7 describes the data network as containing one or more of the following:

• EndSystem (ES): connects an aircraft computer system to the data network. Each end system must have a unique address in the network. An aircraft computer system will generally have multiple subsystems and applications, each of which is isolated within an ARINC-653 partition. These applications communicate with one another by transferring data oversampling or queuing (S/Q) communications ports defined by ARINC-653. ARINC-664 Part 7 additionally defines service access ports (SAP). Data from one port on one end system is sent across the network to a receiving port on another end system via a unidirectional logical channel called a Virtual Link (VL).
• Switch: transfers (and policies) data travelling between end systems. Policing is the process of checking that traffic flowing from one ES to another ES complies with the rules of ARINC-664 networks (traffic shaping) and ensures that the network is deterministic even if an ES malfunctions. Each switch pre-loads a configuration file with all end systems and their parameters (e.g., VLs, etc).

Endsystems & Partitions
Each end system has these characteristics:

• Each end system must have a unique address in the network consisting of 16 bits from an 8-bit Network ID plus an 8-bit End System ID and an additional 8-bit Partition ID.
• An endsystem can have 0 to 128 VLs.

Endsystem addresses are represented in IP address notation (Section 1.6.3):

• Unicast IP addresses (for source and destination) addresses are 10.[8-bit Network Id].[8-bit End System Id].[8-bit Partition ID]. These point-to-point addresses are always from 10.0.0.0 to 10.255.255.255. For example, 10.1.2.3 is Network 1, End System 2 and Partition 3.
• Multicast IP addresses (for destination addresses) are 224.224.[VLID] with the 16-bit VLID is split into two 8-bit octets. These point-to-multi-point addresses are always from 224.224.0.0 to 224.224.255.255.

Virtual Link
Each Virtual Link (VL) has these characteristics:

• Each is an input or output (unidirectional).
• Each has one or more receiving partitions (via unicast or multicast).
• Each VL has only one source address on the network (unique sender). Each sending VL can operate in “normal” (1 S/Q ports per VL) or “subVL” mode (one VL can be assigned 2, 3, or 4 Q/S ports per subVL). Each subVL is assigned an individual subVL ID and a sending queue.
• Each VL must send packets in the order that they are queued. A VL is divided into 2, 3, or 4 sub-VL queues and sends using a round-robin algorithm.
• Each VL can transmit once every BAG=1, 2, 4, 8, 16, 32, 64, or 128 ms.
• SkewMax should be between 0 and 253*BAG
• Ethernet frame length (Lmax) should be between 64 and 1518 bytes

Virtual Links are represented in Ethernet MAC address notation (see Section 1.6.3). The destination address has a 16-bit VLID in the last two octets [03:00:00:00:[VL: ID]]. The source MAC address format contains the source (transmitter) information: [02:00:00:8-bit Network ID:8-bit Equipment ID:8-bit Bus ID (20 is A, 40 is B)].

ARINC-664 COM Ports
There are three types of communication ports defined in ARINC-664P7:

• Sampling (SMP) as defined in ARINC-653 for avionics data.
• Queuing (QUE) as defined in ARINC-653 for avionics data.
• Service Access Ports (SAP) are defined in ARINC-664P7 for other uses.

In TCP/IP protocol notation this is a 16-bit UDP port from 0-65535 (see 1.6.3). Sampling ports have the following characteristics:

• Connectionless UDP with no flow or error management.
• Data is transmitted as the payload of a single non-fragmented UDP packet. Received data is of a fixed size that is preconfigured. The largest maximum data size is 1471 bytes (when Lmax=1518B).
• Multiple partitions on an end system may read from the same sampling port’s received message buffer. This buffer is not cleared upon reading. This receive buffer has a freshness indicator. Only a single buffer exists and is overwritten when a new message arrives.

Queuing ports have the following characteristics:

• Queuing ports use connectionless UDP with no acknowledgment.
• Data is transmitted as the payload of a single fragmentable UDP packet. Data size is set at transmission time. The maximum data size is 8192 bytes.
• When a message is completely received, it is added to a received message FIFO queue (depth preconfigured) where it can be retrieved by any partition. Retrieving a message removes it from the buffer.
• On buffer overflow (configured receive buffer too small) the message is discarded and an error status is provided to the receiving partition.
• IP fragmentation occurs when data exceeds Lmax – 47 bytes and is transmitted in fragments (up to 8 fragments max). As an example, an 8192-byte queuing message exceeds 1471 bytes and would require (8+8192) / 1479 bytes = 6 fragments to transmit when Lmax = 1518. Refer to Figure 1-5 for packet descriptions.
• The loss of a fragmented packet during reception causes the entire reassembly buffer to be discarded.

Service Access Ports have the following characteristics:

• SAPs provide UDP services to communicate with a Compliant Network, and access to a Compliant Network is done through a gateway or router.
• Messages are identical to Queuing messages, but the destination address and port are user-configurable and translated by the Gateway.
• SAPs are commonly used for management functions that include an SNMP agent, booting from TFTP, or ARINC 615A data loading.

Connections
On an ARINC-644 network, unique connections are identified as follows:

• Sampling and queuing communication port messages are unique for the quintuplet srcIP:srcPort + dstMAC(VL):dstIP:dstUdpPort below:
• A transmitting service access point port (SAP) is identified by the quadruplet srvMAC(VL):srcIP:srcPort->dstMAC(VL). The destination dstIP:dstPort is set by the user application for a Compliant Network. A receiving SAP is configured as interface:dstMAC(VL):dstIP:dstPort.

OSI Model Structure
The following descriptions are in reference to the OSI 7-layer model for network communication. Refer to Figure 1-4 for layer stack:

OSI Layer 1
Layer 1 is the Physical layer defining the hardware connection between sender and receiver. Note that it transports raw bits rather than logical data. ARINC 667 specifies that the IEEE 802.3 Ethernet standard shall be used for the physical layer. Each ARINC-664 device has a pair of physical interfaces, one used for channel/bus/network A, and for redundancy one for network B.
In practice the DNx-ARINC-664 implements two independent bus connectors that are IEEE 802.3ab 10/100/1000BASE-T Ethernet ports, that accept twisted-pair copper wiring with both receive and transmit, or “Ethernet cable”, as explained in architecture Section 1.7; for wiring, see Section 1.8.

OSI Layer 2
Layer 2 is the Data Link layer. The data-link layer transfers entire frames of logical data from sender to receiver, at least as far as Layer 3 is concerned. In the Ethernet standard, the Data Link layer (DLL) is composed of two parts: the medium access control (MAC) and logical link control (LLC) sublayer.

The MAC sublayer provides mechanisms to access the physical medium including packet switching and scheduling to transmit data (as Ethernet frames) assembled by the LLC’s multiplexing of data from Layer 3. The physical layer and MAC sublayer are designed to be embedded in hardware so that changing from twisted-pair copper to fibre or another medium is done by changing the COTS part. Higher layers are implemented in software.

The IEEE 802.3ab MAC sublayer specifies the use of the carrier sense multiple access with collision detection (CSMA/CD) protocol to choose which device will have exclusive access to the physical medium to transmit, but CSMA/CD alone is non-deterministic due to collisions that can cause indefinitely long contention for the transmission medium by devices with long transmissions. To ensure deterministic on-time delivery of data between devices on the avionics network ARINC-664 uses the Virtual Link mechanism in the data-link layer. The Virtual Link is a logical communication channel that guarantees bandwidth by limiting one transmission of 1518 bytes or less (<122 µs at 100 Mbps) once every
1-128 ms; Virtual Links are explained in more detail in later sections. ARINC-664 also adds a frame sequence number to the end of the Ethernet frame for redundancy management of identical frames sent across buses A and B.

OSI Layer 3

• Layer 3 is the Network layer. ARINC-664 specifies a connectionless communication network with no routing (gateways for SAP are not considered) with a very restricted IP header carrying either an ICMP ECHO or a UDP datagram. The IP header must have the following flags set or be discarded: Version=4, Type of Service=0, Flag={0,1,2}, TTL=1 (hop), Protocol={1:ICMP,17:UDP}.
• The Internet Control Message Protocol is restricted to ECHO datagrams only corresponding to ICMP type={0,8} code=0, which are used to “ping” an end-system to see if it is online; all other types and codes are not used.

OSI Layer 4
Layer 4 is the Transport layer. ARINC-664 defines UDP as the only transport layer protocol to carry a data payload. The UDP CRC is not used, and the length can be set to as low as the 4-byte header with no data up to 4+8192 bytes where 8192 bytes is defined as the maximum payload for a queuing port.

OSI Layers 5 to 7
Layers 5 to 7 above the Transport layer are not policed by ARINC-664 switches, but the respective data formats are found in other avionics standards.

ARINC-664 Packet Structure
Figure 1-5 illustrates an ARINC-664 network packet as a UDP datagram. The traditional Ethernet UDP datagram structure varies for ARINC-664 packets in the following ways:

• An Ethernet frame contains an ARINC-664 sequence number (SN), 0- 255.
• Ethernet MAC addresses use the ARINC-664 addressing scheme.
• Padding is added to ensure that the Ethernet frame size is at least 64 bytes and that the Ethernet length field is at least 46 bytes. A sampling port carrying 1-byte payload: 14+20+8+1payload+16padding+1+4 = 64, for example, or a fragment carrying 1 byte: 14+20+1+24padding+1+4 = 64. The minimum frame size is 64 bytes whether the packet is carrying up to 17 bytes of UDP payload: 14+20+8+17payload+1+4 = 64-byte frame.
• The IP header is simplified.
  • VER=4, ToS=0, TTL=1, Protocol is only UDP (or ICMP ECHO)
  • IP addresses use the ARINC-664 EndSystem & Partition addressing scheme.
• The UDP CRC is ignored. UDP payload may not exceed 8192 bytes.

Bandwidth
Bandwidth utilization for 17-byte and 1471-byte payloads is:

• 17 byte payload: 100Mbps/(8bits)/(84 octets/frame)=148810 frames/sec or effectively 148810 FPS * 17 Bytes/frame = 2,529,770 B/s (2.4 MiB/s)
• 1471 byte payload: 100Mbps/(8 bits)/(1538 octets/frame)=8127 frames/sec or effectively 8127 FPS * 1471 Bytes/frame = 11,954,817 B/s (11.4 MiB/s)

8127 frames/1000 msec is about 8 sampling messages of 1471 bytes per ms, and at 17 bytes that is 148 sampling messages per millisecond.

Device Architecture

This section describes the hardware used in the DNx-ARINC-664 board. A block diagram of the board is shown in Figure 1-6.

The front end of the DNx-ARINC-664 provides five ports and four status LEDs:

• Two TIA/EIA-568 sockets to connect ARINC-664 bus A/B to the board
• One RS-232 debug port for firmware updates or debugging
• One SD card port (for future use with storage media logic)
• One SYNC port (for future use with triggering and events logic)
• Four LEDs to provide status information

The TIA/EIA-568 sockets for Bus A and Bus B are wired into a 10/100/1000BASE-T Ethernet chip set that is forced into 100BASE-TX mode without auto-negotiation allows for a fast initialization. The Ethernet ports are wired into a 400MHz processor that manages communication with the ARINC-664 bus. This processor operates independently and is connected to a logic chip that interfaces it to the Cube/RACK’s DNA bus which the card is plugged into. This logic chip provides an access mechanism to exchange commands, data, and interrupts.

To indicate that a new command/data is ready for exchange, either the processor or the Cube/RACK’s main CPU (managing the DNA bus) will write to a doorbell register which triggers an interrupt to perform the exchange. The logic chip also provides access to the SD & SYNC ports. The 400MHz processor is additionally directly connected to the RS-232 debug port, from which it can be debugged or updated.

Device RTOS
The DNx-ARINC-664 incorporates a DO-178-certified real-time operating system “MicroC/OS” that facilitates ARINC-664 emulation. Important processes like the reception routine and statistic collection are described in “Device RTOS Processes”.

Wiring & Connectors

The following ports are located on the front-end of the DNx-ARINC-664 board:

• RS-232 female connector to debug the DNx-ARINC-664.
• Dual TIA/EIA-568 female sockets accept Category 5/6 straight-through unshielded twisted-pair (UTP) wire – the same Fast Ethernet or Gigabit Ethernet copper wiring that is used to connect PCs to LANs.
  Pin| Signal
  ---|---
  1| Tx+
  2| Tx-
  3| Rx+
  4| (none)
  5| (none)
  6| Rx-
  7| (none)
  8| (none)

The socket closer to the RS-232 port corresponds to Bus B. The socket closer to the SYNC/LED port is Bus A. See Figure 1-1 for bus labelling. Note that to connect to an avionics interface that uses an optic fiber link please contact Technical Support for a recommended media converter.

• SYNC port hardware for synchronization and triggering.

Connecting to the ARINC-664 Network
To connect the DNx-ARINC-664 board, use the following procedure:

1. Verify the DNx-ARINC-664 board is powered down.

2. Connect the network interface(s) to the switch(es) (Figure 1-7):

   • Connect the “Bus A” network interface port to the Switch for Bus A.
   • Connect the “Bus B” network interface port to the Switch for Bus B.

3. Apply power to the RACK or Cube IOM. The board will link to the network.
   Note: The board performs a fast link, and disconnecting either network cable will disable that network interface until it is power-cycled.

4. Confirm that network link lights are on as orange (10/100Mbps) or green. You are now connected to the ARINC-664 network.

Optionally, you can connect to the serial debug port using MTTTY (or PuTTY) at 57600 baud, no parity, 8 data bits, 1 stop bit to confirm connectivity.

NOTE: It is preferred that both the Bus A and Bus B Switch be certified ARINC-664 network switches that are properly pre-configured for the avionics network. COTS Ethernet switches will act as hubs which degrade overall performance.

Programming with the Low-level API

This chapter provides the following information about programming the DNx- ARINC-664 using the low-level API:

• About the Low-level API (Section 2.1)
• Low-level Functions (Section 2.2)
• Tutorial (Section 2.3)
• UEI ARINC-664 XML Configuration (Section 2.4)

About the Low-level API

• The low-level API provides direct access to the DAQBIOS protocol structure and registers in C. The low-level API is intended for speed-optimization, when programming unconventional functionality, or when programming under Linux or real-time operating systems.
• UEI also offers a high-level Framework API for use when programming in Windows OS; however, DNx-ARINC-664 is not supported in the Framework and must be programmed using the low-level API.

For additional information regarding low-level API, refer to the “PowerDNA API Reference Manual” located in either of the following directories:

• On Linux systems: <PowerDNA-x.y.z>/doc
• On Windows systems: Start » All Programs » UEI

Low-level Functions

Low-level functions are described in detail in the PowerDNA API Reference Manual. Table 2-1 provides a summary of DNx-ARINC-664-specific functions.

Table 2-1 Summary of Low-level API Functions for DNx-ARINC-664

as stored in the pAR664_DEV_INFO structure.
DqAdv664GetHandle| Gets a VL or port handle by their ID.
---|---
DqAdv664RecvMessage| Gets a Sampling or Queuing message.
DqAdv664RecvMessageHdr| Gets a Sampling, Queuing, or SAP message and headers.
DqAdv664SendMessage| Puts a Sampling or Queuing message.
DqAdv664SendMessageHdr| Puts a Sampling, Queuing, or SAP message and headers.
DqAdv664SendScheduleTable| Sends the transmitter scheduler table for high- performance bin-based scheduling.
DqAdv664SetConfig| Configures from file.
DqAdv664ValidateVlPortCfg| Validates parameters in an AR664_VL_CFG or AR664_PORT_CFG and performs boundary-checking functions.
DqAdv664VLPortStatus| Gets VL or port status for a specific handle.

Tutorial

The following tutorial provides a brief overview of how to set up and use your DNx-ARINC-664 using the low-level API.

For best results, use this tutorial in conjunction with an actual code example, which can be found in either of the following directories:

• /src/DAQLib_Samples/Sample664_xml (Linux)
• %PDNAROOT%\Examples\Visual C++\ARINC\Sample664_xml (Windows).

The following topics are explained in this tutorial:

• Initialization
  • Initializing the Cube or RACK and enabling DNx-ARINC-664 board(s).
• Configuration
  • Clearing any existing configuration from previous runs.
  • Adding each VL and associated Port with a function call.
  • Adding all VLs and associated Port from an XML file.
• Operation: Send / Receive Messages
  • Sending and receiving messages in simple mode or VMap mode.
• Stop Cleanly
  • Disabling boards cleanly.

Initialization
To initiate communication with the RACK or Cube, you must first get a DAQLib handle for the IOM by calling DqOpenIOM():

Configuration
Prepare to configure the DNx-ARINC-664 card by clearing any existing configuration from its memory:

Configure the VLs and ports by creating an XML configuration file and specifying its path to the DqAdv664SetConfig() call as shown in the following code snippet.

NOTE:
To create the XML file, use the UEI ARINC-664 Configurator tool or use one of the .xml samples in Sample664_xml as a template. Refer to “UEI ARINC-664 XML Configuration” on page 29 for a list of programmable configuration attributes and for more information about the ARINC-664 Configurator.

• The handle_tbl array of AR664_CFG_HANDLES contains the ARINC-664 VL/Port handle for each entry, which will allow you to address those ports later. See the definitions for AR664_VL_CFG and AR664_PORT_CFG in powerdna.h for details.

• You can add more VLs/ports later at runtime using the DqAdv664AddVL(), DqAdv664AddPort(), and DqAdv664ValidateVlPortCfg() function calls described in the PowerDNA API Reference Manual. The maximum number of
  active ports is 664; processing limits this to 128 ports at medium load, and 64 ports for heavy load for revision 1 boards.

• DqAdv664SetConfig() returns a set of VL/Port handles, and with these, you can optionally configure transmission VMap or reception aEvent modes; these modes are explained in Section 2.3.3.

• Finally, enable the operation to allow the card to receive or send messages as follows:

Send/Receive Messages

The DNx-ARINC-664 board can send or receive messages in three ways:

1. Immediate mode
2. Variable Data Map or VMap+
3. Asynchronous mode.

The difference between the modes is described below with code snippets in the following sections. Figure 2-1 is provided for reference:

• Immediate mode: each function call is directed to a single ARINC-664 port. The function call gets received data or puts transmit data and returns port status. Practical for use with tens of SMP/QUE/SAP/ICMP ports.
• VMap/VMap+: each variable-size data map contains multiple receive & transmit ARINC-664 ports that are refreshed simultaneously per function call. Designed to perform a bulk update of sampling ports of small data size in a single call and is ideal for frequently refreshed transmit ports. Each legacy VMap requires a fixed list of ARINC-664 ports to be configured before DqAdv664Enable and is practical for tens to a hundred ports. VMap+ allows ports to be set dynamically at runtime (VMap is only at configuration time) and is practical for refreshing hundreds of ports.
• Asynchronous Events or aEvent mode for ARINC-664 reception only: the IOM can forward messages received from the ARINC-664 bus directly to the PC but requires a separate listening thread on the PC.

Immediate Mode
To send messages, call DqAdv664SendMessage() using the ARINC-664 port handle. The following example shows how to do this for our previously-configured sampling port:

For this example, let’s assume that we also set up a VL to receive, which has a corresponding Port named myRxP1hdl.

To receive messages, call DqAdv664RecvMessage() for the port as described for the following sampling port:

If a message is available, it will be stored in the message_r buffer. The status variable returns the result of the send or receive. Refer to the API documentation for the meaning of the bits, along with how to interpret the written and available variables; the variables’ meaning depends on the port type. The immediate mode works on all platforms and is designed for debugging and testing.

VMap and Vmap+ Introduction
Rather than receiving or transmitting data from each port, it is possible to set up a variable-size data map to receive and transmit multiple messages at once.

VMap/VMap+ is described in detail in the “PowerDNx Protocol Manual”. Using a VMap/+ consists of the following function calls (shown in the next two sections):

• Initial configuration of a VMap/VMap+:
  • set up VMap parameters
  • add input/output channels (fixed for VMap, dynamic for VMap+)
  • start the VMap
• Operation:
  • schedule data to write upon the next refresh from channel(s)
  • schedule data to read up on the next refresh from channel(s)
  • refresh (see Figure 2-1)
  • read retrieved data from the input channel (returned in reply to refresh)
• Stop and close the VMap
  • Both (a) and (b) are performed in the PowerDNA Library on the PC and that data map is eventually built and sent to the IOM at (c) when the start command is called.
  • The number of input and output channels (up to 64) from (b) is thereafter fixed and in that VMap control even if no data is scheduled to be sent/received in (d)/(e) for that channel upon refresh (f).
  • The DaqBios command for VMap Refresh has the process shown in Figure 2-1 and the packet format shown in Figure 2-2:

Extended VMap can be configured to send up to 8 fragments of 1500 bytes (when initialized within a 1518 byte Ethernet frame) that allows for a maximum VMap payload of 11764 bytes that is further partitioned into up to 64 I/O “channels”.
For the DNx-ARINC-664, each added channel corresponds to an ARINC-664 port handle. The format of the payload is output channel size (and tx port handle for VMap+) array, input channel size (and ARINC-664 receiving port handle for VMap+) array, and output data of length specified in output channel size earlier.

For traditional VMap each ARINC-664 receive/transmit port handle added as an input/output channel is put into a transfer list. Scheduling data to write and be read can only be performed for those added ARINC-664 handles and only requires specifying the size to be written (and data in case of write) or read:

Figure 2-3 shows the VMap control+data portion of Figure 2-2’s Refresh command sent from PC to IOM. The output and input array indexes correspond to the channels added in (b) and set in (c) is always of fixed size until the VMap that they are assigned to is destroyed. For example, for 64 input + 64 output channels they use up the first 128+128 bytes of 11764 bytes, even if the data transferred for most channels is mostly 0, leaving only 11508 bytes for output channel data. The sizes for output channels and data to write are assigned in (d), and the sizes for input channels to return with the refresh’s reply are assigned in (e).

The reply from IOM to PC returns a packet with the size of the read data (up to in_size[] specified in the command) followed by the data itself for that channel. Up to 256 VMaps, each with 0-64 input and 0-64 output channels can be assigned at configuration time. However, for hundreds of ARINC-664 ports, of which only a few are frequently updated, traditional VMap is not as efficient as VMap+, since VMap+ gives control to which of thousands of ARINC-664 ports to refresh.

For VMap+, channels are added with a special flag that allows the ARINC-664 handle to be specified at (d) or (e) using a VMapPlus function call. As seen in Figure 2-4 the extra control information can create a larger header.

VMap+ is useful in providing finer-grained control over ARINC-664 ports. The VMAP+ is refreshed at a particular time or in a particular order, which provides more efficient use of bandwidth and IOM processing capability.

VMap and Vmap+ should be used when multiple ARINC-664 ports are to be updated simultaneously on the following platforms:

• ARINC-664 ports used for transmitting on PC in Slave mode
• ARINC-664 ports for both transmit and receive on UEIPAC

The examples that follow show how to use VMap and VMap+ in practice.

Variable Data Map (VMap)
This section exemplifies how to configure, operate, and close a VMap.

Configuration
To create a new VMap, call:

Any DNx-ARINC-664 handle provided by DqAdv664AddPort or DqAdv664SetConfig (or even DqAdv664AddVl) can be addressed as a VMap channel. Add a channel for any ARINC-664 handle by calling DqRtVmapAddChannel:

Start the operation of the DNx-ARINC-664 with DqAdv664Enable() to command the DNx-ARINC-664 to begin to use the ARINC-664 network if not already done so.

Start the VMap with the configuration and channels requested above, sending the configuration from PC to IOM over the network, by calling:

Operation

Now the VMap is configured, the operation involves preparing to Refresh the VMap as explained in steps (d) through (g) in the previous section.

Begin by using this convenience function to reset everything to 0 (otherwise you must reset all channels to 0 yourself):

To write data to a transmitting ARINC-664 port, first request it in the VMap packet:

The DqRtVmapWriteOutput call will return the number of bytes still available in the VMap packet (ret). When (ret!=len) your request has been denied; if (ret<0) then an error has occurred (for detail, call DqTranslateError(ret)). The VMap request has been prepared so it can be sent with DqRtVmapRefresh.

To read a message from an ARINC-664 port, first request it in the VMap packet:

The DqRtVmapRequestInput call will return the number of bytes still available in the VMap packet (ret) as with DqRtVmapWriteOutput. This VMap request has been prepared so it can be sent with the next DqRtVmapRefresh. Note that the above DqRtVmapWriteOutput and DqRtVmapReadInput only create requests but do not send the actual VMap packet to the IOM. To send the actual packet use the VMapRefresh call seen below:

Note that the Refresh command only operates on the data of an ARINC-664 port and does not currently retrieve the status, number of messages in queue, or SAP headers as the simple messaging mode does. Requesting data from a queuing port only receives a single message from the queue, not the whole queue. The VMap refresh command packet (Figure 2-1 and Figure 2-3) contains both the data transmitted, (i.e., including out_data) and any request for data to be returned with the VMap reply from the IOM.

To read the input received after a refresh you must call DqRtVmapReadInput:

Repeat the above sequence of DqRtVmapWriteOutput, DqRtVmapReadInput, DqRtVmapRefresh, and DqRtVmapReadInput until the simulation is complete.

Stop & Close
Once your simulation is complete, call DqAdv664Enable() to disable the DNx- ARINC-664 network operations, and then stop and clean up the VMaps with the calls:

For more information, refer to the sample code, “SampleAsync664”.

VMap+
To create an Extended VMap+ call (non-UEIPAC):

Add a VMap channel corresponding to an ARINC-664 handle or use any unique number to identify the channel. Add a VMap channel for any handle by calling:

You can then start the operation of the DNx-ARINC-664 with DqAdv664Enable() to allow the DNx-ARINC-664 to interact with the network. Start the VMap by calling:

To write data to a transmitting ARINC-664 port, first request it in the VMap packet: D

The DqRtVmapWriteOutput call returns the number of bytes still available in the VMap packet (ret). When (ret!=len) your request has been denied; if (ret<0) then an error has occurred (for detail, call DqTranslateError(ret)). The VMap request is prepared so it can be sent with DqRtVmapRefresh. To read a message from an ARINC-664 port, first request it in the VMap packet:

DqRtVmapPlusRequestInput returns the number of bytes still available in the VMap packet (ret) as with DqRtVmapWriteOutput. This VMap request has been prepared so it can be sent with the next DqRtVmapRefresh. Once all input and output channels are requested, perform the refresh:

Note that the Refresh command only accesses the ARINC-664 port’s message payload and does not retrieve the status, remaining messages in the queue, or SAP headers as the simple messaging mode does. Requesting data from a queuing port only receives a single message from the queue, not the whole queue.

The VMap refresh command packet (Figures 2-1 and 2-3) contains both the data transmitted (i.e., including out_data) and any request for data to be returned with the VMap reply from the IOM. The reply contains only ARINC-664 message data without any status, remaining messages in the queue, or SAP headers as seen with simple messaging mode. The status and number of messages may be retrieved with the DqAdv664PortMsgStatus and DqAdv664VLPortStatus commands. It is useful to run these commands to see which ports are worthwhile refreshing.

To read the input received after a refresh you must call DqRtVmapReadInput:

Repeat the sequence of DqAdv664VLPortStatus, DqRtVmapPlusWriteOutput, DqRtVmapPlusReadInput, DqRtVmapRefresh, DqRtVmapReadInput. Once your simulation is complete, call DqAdv664Enable() to disable DNx-ARINC-664 network operations, and then stop and clean up the VMaps with the calls:

Asynchronous Events or aEvent Mode
Asynchronous events were implemented to improve efficiency in receiving large quantities of data quickly from the ARINC-664 bus and transferring them to the PC. The UEIPAC does not use aEvent mode because all traffic is local.

Asynchronous events are described in detail in the PowerDNx Protocol Manual. In summary, configuring and using asynchronous events follows this process:

• Initial configuration:
  • create an independent IOM handle and port for aEvents only
  • configure the DNx-ARINC-664 with a list of ARINC-664 receive ports
  • start listening for events on that list
  • start a thread to process asynchronous events coming from IOM
• Operation on the DNx-ARINC-664:
  • receive a message from the ARINC-664 bus
  • find the receiving port in the aEvents list
  • encapsulate the message data in an aEvent packet
  • queue the IOM-CPU to send the aEvent packet
  • send the aEvent packet to the PC (see Figure 2-1)
• Operation on the host PC:
  • wake sleeping thread (started at d) to receive the aEvent packet
  • unencapsulated ARINC-664 message(s) from the aEvent packet
  • process ARINC-664 message(s), then sleep until the next packet
• Cleanup:
  • disable events and clear the aEvent port list

We have seen that Immediate and VMap/VMap+ function calls block the application on the PC while sending a command to the IOM, which in turn blocks the IOM while it polls the DNx-ARINC-664 for data for 1 to 64 receiving ARINC-664 port. We can see that these steps are no longer necessary with aEvents.

The following event modes are available:

• Send every ARINC-664 message as it is received from the ARINC-664 bus.
• Accumulate received messages in a buffer of up to 12 kB, and send them when the watermark is reached, for bandwidth efficiency.
• Accumulate received messages in a buffer of 12 kB, and send them when after a timeout is reached, for bandwidth efficiency.

See the “SampleAsync664” example for how to use asynchronous events. Note that, even though multiple multicast port handles within the same VL will be sent with aEvent mode, subscribing to send copies of this same data is neither bandwidth efficient nor necessary – one copy is always sufficient since it can be replicated in the aEvents processor thread, so subscribe to only port handle.

Stop Cleanly
To stop operation, call DqAdv664Enable() with a FALSE parameter as follows:

This stops operation of the DNx-ARINC-664 board without changing the configuration.

UEI ARINC-664 XML Configuration

• As described in Section 2.3.2, each DNx-ARINC-664 device is configured using an XML file.
• UEI provides a GUI-based ARINC-664 Configurator that allows users to create and edit ARINC-664 configuration XML files. See Figure 2-5.

A UEI ARINC configuration XML file contains the following tags and attributes:

• An initial XML declaration: <?xml version=”1.0″ encoding=”utf-8″?>
• A root tag that provides the following attributes:

Table 2-2 Summary of Configuration Attributes

One or more tags that define the following attributes:

Table 2-3 Summary of VL Attributes

respec- tively
bag| BAG as 1/2/4/8/16/32/64/128 milliseconds of bandwidth allocation gap
frag_en| Enable packet fragmentation: “yes” or “no”
n_subvl| Number of subVLs: 2 to 4 possible subVLs; 0/1 to disable subVLs
network_select| Network selection: “A”, “B”, or “AB” for redundant
IC_en| Enable Integrity checking: “yes” or “no”
RM_en| Enable Redundancy Management (when network_select=” AB”): “yes” or “no”
LMax| Largest Ethernet frame: from 64 to 1518 bytes for maximum frame size
skew_max| Maximum time difference in the arrival of over redundant ports: from 0 to 65535 milliseconds for receive ports
max_jitter| Maximum allowed jitter: from 0 to 65535 milliseconds for receive ports
ICMP_VLID| 16-bit VL ID of the paired VL to receive or return on
ICMP_en| Identify if there is an ICMP port on this VLID: “yes” or “no”

For each , one or more tags that define the following attributes:

Table 2-4 Summary of port Attributes

as rounded to (period / bag * bag)
d_size| Sampling port payload data size: 1 to 1471 bytes
depth| Queue depth for Queuing/SAP/ICMP messages : 1 to 360
src_port| Source 16-bit port number
dest_port| Destination 16-bit port number
endsys_src| See Note below
endsys_dest| See Note below
part_src| See Note below
part_dest| See Note below
multicast| See Note below

NOTE:

• For the expanded XML format the end-system and partition address are: EndSystem address as endsys_src and endsys_dst from 0 to 65535 Partition on EndSystem as part_src and part_dst from 0 to 256
  Multicast as “yes” or “no” to use a multicast or unicast address

• Compact format endsystem and partition addresses are represented as a multicast address 224.224.[upper 8 bits of vlid].[lower 8 bits of vlid] or unicast address 10.[upper 8 bits of endsys].[lower 8 bits of endsys].[part] for src_ip_address and dst_ip_address.

For more details, refer to the comments for AR664_VL/PORT_CFG in the section.

Tools and Diagnostics

This chapter provides diagnostic information, procedures, and tools for troubleshooting the DNx-ARINC-664:

• Diagnostic Panel for PowerDNA Explorer (Section 3.1)
• Device RTOS Processes (Section 3.2)
• ARINC-664 Network Packet Inspection (Section 3.3)

Diagnostic Panel for PowerDNA Explorer

PowerDNA Explorer is a GUI-based diagnostic application. The following section provides information specific to the DNx-ARINC-664. Please refer to the IOM user manual for a detailed description of the tool.

On Windows based systems, PowerDNA Explorer can be accessed as follows:

• Start » All Programs » UEI » PowerDNA Explorer

The DNx-ARINC-664 panel in PowerDNA Explorer provides the return results of the low-level API DqAdv664GetBusStats() and DqAdv664GetDeviceInfo() function calls. Bus usage statistics appear first, followed by the current firmware version, as shown in the following image:

When Network > Start Reading Input Data is active, DqAdv664GetBusStats() will be called a few times per second. This is useful when debugging a few ARINC-664 ports but should not be used with more than 64 active ARINC-664 ports.

PowerDNA Explorer’s View > Hardware Report provides additional device details:

This information can also be obtained using the RS-232 Serial Debug Port without using the PowerDNA Explorer diagnostic application by typing “devtbl l” using the serial debug terminal.

**Device RTOS Processes

**

This section describes the process by which the receiver stores or drops ARINC-664 messages from the time that they are received from the ARINC-664 network.

Reception

• The frame is received by Three-speed Ethernet Controller (TSEC) IC and subjected to a loose hash-based hardware filter (if not promiscuous). Silently discard the frame if VLID doesn’t match Section 1.6.2.2 VLID formats as configured with DqAdv664SetConfig.

• Interrupt Service Routine is called for a newly received network frame.

• Pre-filter: Check VLID is one of the Table of VLIDs that was configured for this card with DqAdv664SetConfig.

• Begin RX processing:

  • Record Timestamp

  • pkts_rcv++ (for bus statistics retrieved with DqAdv664GetBusStat)

  • VL (Ethernet MAC Address) Sanity Filter:
    Malformed Source/Destination Ethernet Address: link_err++ Unexpected Bus: bus_not_match++

  • IP Address Sanity Filter:

  • Malformed IPv4 ARINC-664 Header: ip_hdr_err++

  • Malformed IPv4 ARINC-664 Source/Destination Address: ip_ad-dr_err++

  • VL-specific Filter:

  • Bus for VL not enabled: bus_dis++ (done)

  • VL not enabled: vl_dis++ (done)

  • Frame Larger than LMax: ip_too_big++ (done)

  • Protocol not UDP/IP or ICMP echo: ip_hdr_err++ (done)

  • UDP port filter mismatch: port_dis++ (done)

  • Invalid IP Checksum: ip_chksum++ (continue)

  • Invalid UDP Checksum: udp_chksum++ (continue)

  • Integrity Checking (when enabled for A, B, or both):
    Receiver Initialized or Sequence Number is 0: (continue)
    Sequence Number is not PreviousSN+1 or +2: intg_drop++ (done)

  • Redundancy Management (when enabled in A&B mode):
    Receiver Initialized: (continue)
    SkewMax exceeded: rdnd_skewmax++ (continue)
    Already Received On Other Bus: rdnd_drop++ (done)

  • Packet Reassembly (when fragmented):
    No fragments found or fragments were discarded: ip_frag_err++ (done)

  • For all ports in receiving VL:

  • ARINC-664 Port not Enabled: port_dis++ (try next port)

  • Source MAC Address does not match EndSystem ID: (next port)

  • Source or Destination IP Address does not match: (next port)

  • Source or Destination UDP port does not match: (next port)
    If no packets processed: udp_port_err++ (done)

  • Perform Asynchronous Event processing (if enabled), or store to port’s message buffer.

  • Free network buffer.

ARINC-664 Network Packet Inspection

The following procedure can be used to inspect ARINC-664 network packets with Wireshark 1.10+. Wireshark is a free and open source network instrumentation tool.

Perform a Packet Capture

1. Prepare to capture packets

   • Bring up your capturing Ethernet Adapter’s Properties (you can type “ip” in Start Menu).
   • Uncheck all boxes, (e.g., Protocol Version 4 (TCP/IP v4), etc.) to avoid injecting data.
   • Connect the Ethernet CAT5e line into the ARINC-664 network.

2. Start WireShark

3. Start a capture. In the Menu, click Capture > Options (Ctrl+K)

   • Select LAN connection in Capture panel.
   • Uncheck “Update list of packets in real time” in right sidebar options.
   • Click Start.
   • Notice in the status bar you will see the number of packets captured (e.g., Packets: 314).

4. Stop the capture when done capturing
   In the Menu: Capture > Stop (Ctrl+E)

   • The packet capture will then begin rendering.

NOTE:
For first-time configuration, you can see packets better if you perform these commands:

• View > Coloring Rules > Disable “TTL low or unexpected”
• View > Name Resolution > (Uncheck All)

Analyze a Captured Packet
Click a captured packet as shown in the example below:

The following information is shown:

• Source MAC address (xx:xx:xx:xx:xx:20 indicates Bus A)

• Destination MAC address: ends in VLID.
  In the above capture 0x4826h = 18470
  Note: multicast IP addresses will also be, for example: 244.244.72.38 = 72*256+38 = 18470

• Source IP address in the format: 10...

• The destination IP address in the format:

  • Unicast VL will be 10...
  • Multicast VL is 244.244.<VLID={1,65535}>={0.1…244.244.255.255>

• Source UDP Port & Destination UDP Port: 1 to 65535. Note that this has nothing to do with PortID, even though this is the same in ARINC-664 ICD files.

• Data, which is the actual payload of the ARINC-664 packet. This is the most interesting part. This contains a primitive (e.g. int) or a data structure (format defined by aeroplane specification).

• VL Sequence Number: 0 if reset, increments 1 to 255 otherwise

The Source IP, Destination IP, Source UDP, and Destination UDP is a quadruplet that defines an ARINC-664 connection (conversation).

Filter a Captured Packet
To create a display filter to track an ARINC-664 connection, you can type a set of conditions to filter on into the Filter box (see image below).

For example, if you have determined that there is interesting data for a particular connection, you can filter by it:

• This will allow you to scroll through packets to inspect the payload. The payload is what is delivered to the application running on a virtual flight computer (such as the Altitude display in a Display Unit).
• To inspect the jitter of sampling packets (difference between configured and actual retransmit period), press Ctrl+Alt+6 or use the menu:
• View > Time Display Format > Seconds Since Previous Displayed Packet
• To switch back to “seconds since the start of capture”, use Ctrl+Alt+4.

Find Interesting Data

• Let’s say that you want to search for a value (e.g., the Altitude) decoded from a message on your 429 bus.
• To find a particular hex value, click Edit > Find Data > Hex Value

Statistics:

• Statistics > Summary will show averages of traffic
• Statistics > IO Graph will show a graph of traffic across the network

Statistics > Conversations will show when all connections (between various avionics components) start communicating and for how long.

Appendix

Accessories
The following cables and STP boards are available for the DNx-ARINC-664.

• DNA-CAT5E-CBL
  This is a 4-conductor round unshielded twisted-pair cable with 8-pin male TIA/EIA-568 connectors on both ends.

• DNA-DB9MF-CBL
  This is a 9-pin serial cable with male D-sub connectors on both ends. It is used to connect your PC’s serial port or terminal console to the RS-232 port.

• DNA-CBL-SYNC-10
  Sync-to-sync cable is used for synchronization with an external sync port.

• DNA-CBL-SYNC-RJ
  Sync-to-8P8C (RJ-45) cable for use with a synchronization breakout board.

www.ueidaq.com 508.921.4600.

© Copyright 2023 United Electronic Industries, Inc.

References

• United Electronic Industries (UEI) – DAQ, Test, HIL
• Terms of Use

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>