Universal Data Driver | Mirasys Help Center

The Universal Data Driver (UDD) is a driver that can be configured to work with different clients. Currently, the Universal Data Driver is a configurable text data capture and transaction management interface for Mirasys VMS. It has several communication interfaces to interact with text data sources. The incoming messages can be text strings, XML-formatted messages, or raw binary data that are handled with additional custom libraries. As a result, the UDD can store the incoming data in the text channel and generate events that are used as alarm triggers. Text data content can later be searched using the Spotter text search plugin and be used to synchronize video and audio playback.

Communication channels

The UDD has the following communication channels:

TCP client channel - the UDD connects as a client to the TCP server.
TCP server channel - the UDD as server listens for incoming TCP clients.
UDP server channel - the UDD as server listens for incoming UDP messages.
Serial channel - RS-232 communication.
HTTP client channel - the UDD connects as a client to the HTTP server.
HTTP server channel - the UDD as server listens for incoming HTTP clients.
RTSP client channel - the UDD connects as a client to the RTSP server.
Ajax channel - communication with Ajax System events.

In addition, the UDD has proxy models when the external proxy services are configured to send the data to one of the existing UDD communication channels.

Configuration

The UDD text channel configuration has two parts:

Configuration parameters in the System Manager UI (described later on this page)
Configuration parameters in the XML file

The configuration XML file has the following format:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <!-- Channel parameters section -->
  <channelConfig>
    <!-- The message delimitter in the HEX string format 0x...
    If it is empty, then the whole data packet is the message-->
    <linefeed value="0x0D0A"/>
    <!-- The ignored bytes in the HEX string format 0x...
    These bytes will be skipped from the incoming message-->
    <ignored value=""/>
    <!-- The clear-screen bytes sequence in HEX string format 0x..
    When these bytes are received, the ClearScreen action will be called-->
    <clearscreen value=""/>
    <!-- The acknowledge bytes sequence in HEX string format 0x..
    If this parameter is not empty, then this acknowledgment message
    will be sent for all TCP channels after the incoming message is received-->
    <acknowledge value=""/>
    <!-- The integer value of the encoding code page for the Windows API.
    It is needed for converting Unicode strings from XML to VMS UTF-8 format.
    If it is empty, then default CP_UTF8=65001 will be used -->
    <codePage value=""/>
  </channelConfig>
  <!-- Logging parameters section -->
  <logging>
    <!-- The logging level (by default it is 2 - ERROR and INFO messages)
     - 0 - no writing to the VMS log
     - 1 - only ERROR messages
     - 2 - ERROR and INFO messages.-->
    <level value="2"/>
    <!-- Enable or disable additional debug logging for the text channel -->
    <additionalDebug value="no"/>
  </logging>
  <!-- Validation section -->
  <validation>
    <!-- The validation type can be one of the following:
     - xsd - in this case, the value must be the XSD file name
     - regex - in this case, the value must be C++11 Regex -->
    <xsd value="Galaxy.xsd" />
    <!-- <regex value="[a-zA-Z0-9[:space:]\\:]*" /> -->
  </validation>
  <!-- Mapper section. The version of the mapper can be specified
  (2 - latest mapper version) or not (in this case old mapper will be used) -->
  <uddXmlMapper version="2">
    <!-- Message section. Define a list of arguments from the incoming message.
    The arguments extraction will be done based on the messageType value.
    If it is "xml", the XPath is used to extract the argument.
    If it is "text", the additional "parsing" attribute is checked:
     - If it is "regex", then the C++11 Regex is used to extract the argument
     - Otherwise, the text value is used "as is" -->
    <messageType value="xml">
    ...
    </messageType>
    <!-- The constants section.
    This section is valid only for the mapper version 2 or higher.
    It contains a list of arrays with the values that will be used for mapping -->
    <constants>
      <array name="<ARRAY_NAME>" params="<PARAM_ID_1>,...,<PARAM_ID_N>">
        <value>ARRAY_VALUE</value>
      </array>
      ...
    </constants>
    <!-- The rules section.
    It contains rules for incoming arguments and what actions need to be done -->
    <rules>
      ...
    </rules>
  </uddXmlMapper>
</root>

Additional description for the parameters in the “channelConfig“ section:

“linefeed” value - the message delimiter/separator. Typically, Windows applications terminate messages with carriage return and linefeed CR+LF = 0x0D0A is used. Unix systems (like IP cameras) typically use only linefeed LF = 0x0A. In some cases, messages are not separated, i.e. source system is sending data in bursts. In that case, the linefeed value should be left empty (“”) and use text type parsing to match the incoming character stream.
“ignored“ value - the ignored bytes. The UDD can ignore selected characters or byte values to clean the data and help with parsing. Tag ignored lists all the characters that should be filtered out before passing them to the UDD parsing phase. The most common ignored value is the NULL byte (0x00).
“clearscreen“ value - the clear-screen bytes sequence. When the text channel is active and the text data window is open in Spotter, all incoming messages are echoed in it. If the user would like to control the view, it is possible to clear the window when needed. This can be done by sending the clearscreen string to the text channel.

You can save any number of XML files with different parameters and then use these files in UDD text channel configurations.

The examples of the UDD configuration files can be found in the VMS folder (\Program Files\DVMS\DVR\UDDConfigExamples).

Logging Parameters

The logging parameter in the XML file has the logging level - one of the following values:

0 - no writing to the VMS log
1 - only ERROR messages
2 - ERROR and INFO messages.

To enable additional message writing and storing input data packets, you should add the <additionalDebug> element into the logging element with the attribute value="yes". The incoming data packets will be written into the DVR folder to the file named “Debug_UDD_Packets.bin”. And the additional text channel info will be written into the “Debug_UDD_Log.txt” file in the same folder.

Parameters for HTTP Server Channel

Additional parameters can be configured for the HTTP server channel in the XML configuration file. These parameters should be placed in the special section <HTTPServer></HTTPServer>. The following parameters are supported:

"processingType" attribute - the attribute to determine what part of the incoming HTTP request will be processed:
- All - the whole message.
- Headers - only HTTP headers from the incoming message.
- Uri - only HTTP URI string from the incoming message.
- Content - only HTTP content from the incoming message.
<Response> element - the HTTP response message content wrapped in CDATA. In addition, this element has the "send" attribute:
- If the attribute "send" has a value of “no”, the driver will send an HTTP response message without content.
- If the attribute "send" has a value of “yes”, the driver will send an HTTP response message with the specified content.

Example of additional parameters configuration for HTTP server channel:

...
<Additional>
  <HTTPServer processingType="All">
    <Response send="yes"><![CDATA[Response content]]></Response>
  </HTTPServer>
</Additional>
...

Data Validation and Mapping

The data validation and mapping of input message to the actions (text data, text event, metadata) parameters are done using XML configuration files.

Data Validation

The data validation is defined in the “validation“ section of the XML configuration file. The validation type can be one of the following:

xsd - in this case, the value of the validation parameter must be the XSD file name:

<validation>
  <xsd value="ValidationSchema.xsd" />
</validation>

This validation is suitable for the input messages in the XML format. In this case, the validation is done against the specified XSD schema file. If the "value" attribute is empty, the common validation will be used: only checking that the incoming message has a correct XML format.

regex - in this case, the value must be C++11 Regex:

<validation>
  <regex value="[a-zA-Z0-9[:space:]\\:]*" />
</validation>

This validation is suitable for the input messages in the text format.

In addition, UDD has a validation type “None“ (no validation) and “Custom“ (using a custom validation DLL). These types are defined in the text channel parameters in the System Manager UI, and they are not configured in the XML.

Input Arguments

When UDD receives the input stream using one of the supported communication channels and splits them to the separate messages, the next task is to extract specific arguments (some values) from the incoming messages to use them later for data mapping. Here they will be referred to as input arguments.

XPath expressions

For example, we have the input XML message from 3rd party system with a temperature value:

<Data>
  <Sensor name="Sensor1">
    <Temperature>15<Temperature/>
  </Sensor>
</Data>

And we need to do some actions - for example, generate an event if the temperature is higher than 30 degrees. To do the mapping, we need to extract this temperature value from the incoming XML message and save it in some input argument with ID=1. For such extraction, we have the “messageType“ section in the XML file where the rules of extraction of arguments are defined. For XML messages, we are using the XPath expressions to extract the values. So, for our example, this section will be the following:

<messageType value="xml">
  <message format="XPath" />
  <param number="1" value="/Data/Sensor/Temperature"/>
</messageType>

As you can see, the value attribute in the “messageType“ element is “xml“ - it means that the incoming message is in the XML format, and the message format attribute value is “XPath” - it means that the XPath expression is used for the argument extraction. The “param“ element in the “value” attribute has the XPath expression, and in the “number” attribute, it has the input argument identifier. This identifier is needed later for the data mapping.

The XPath expression allows the extraction of the attribute value or element content value from the incoming XML message. The more detailed information about XPath can be found here:

XML Path Language (XPath)

In addition, you can find the list of XPath examples here:

XPath Examples

Text regular expressions

When using text data, regular expressions can be used to extract input arguments. For example, we have the input data with the following text:

Car number 3 enter to zone 1

And we need to extract the car number and zone number as input arguments. For this case, we can do the following rules with regular expressions:

<messageType value="text" parsing="regex">
  <message number="1" value="Car">
    <param number="1" value="Car number ([0-9]+) enter to zone ([0-9]+)" group="1" />
    <param number="2" value="Car number ([0-9]+) enter to zone ([0-9]+)" group="2" />
  </message>
</messageType>

The value attribute in the “messageType“ element is “text“ - it means that the incoming message is in the text format, and the “messageType“ parsing attribute value is “regex” - it means that the regular expression is used for the argument extraction. The “param“ elements in the “value” attribute have the Regex, and in the “number” attributes, it has the input argument identifiers. These identifiers are needed later for the data mapping. A regular expression can contain several groups (expressions in the "(", ")" symbols). The "group" attribute in the parameter definition specifies the group number that will be assigned to the parameter after regular expression matching. If the "group" attribute is not specified, then group = 0 is used by default - it means that the result of matching the whole expression will be assigned to the parameter.

Regular expression format

UDD uses C++ 11 Regex for the regular expression mechanism (please find description here: MSDN: Regular Expressions (C++))
It supports multiple regular expression grammars - more information can be found using this link: STL: Regular Expressions.

Regular expression for XML data parsing

The user can use a regular expression for XML message parsing. For example, we have the following incoming XML:

<?xml version="1.0" encoding="utf-8"?>
<Event>
  <Type>Object removed</Type>
</Event>

And we need to extract the type of event from the message. In internal representation the "<Type>Object removed</Type>" text will look like this:

&lt;Type&gt;Object removed&lt;/Type&gt;

because the XML tag symbols are replaced with escape sequences. So, to extract the type of event, instead of the ".Type.([a-zA-Z0-9]+)" expression, the "....Type....([a-zA-Z0-9]+)" expression should be used. The following special symbols will be replaced during internal representation conversion:

< - &lt;
> - &gt;
& - &amp;
' - &apos;
" - &quot;

Data Mapping

After extracting the input arguments from the incoming messages, we need to compare them with some values and do the actions. In the UDD configuration file, this is done with the list of parameter rules in the “rules“ section of the “uddXmlMapper“.

For example, we have an incoming XML message like this:

<Data>
  <Sensor name="Sensor1">
    <Temperature>15<Temperature/>
  </Sensor>
</Data>

And we already defined input argument extraction rules like this:

<messageType value="xml">
  <message format="XPath" />
  <param number="1" value="/Data/Sensor/Temperature"/>
</messageType>

So, we have extracted the input argument with ID=1, and it is the temperature value. Now we can define a list of rules that we will generate one event if the temperature is more than 30 degrees, and a second event if the temperature is less than or equal to 30 degrees. The rules can be the following:

<uddXmlMapper version="2">
  ...
  <rules>
    <message number="1" value="Data" alwaysShowText="yes" handleParameters="all">
      <param reference="1" value="30" operator="gt">
        <action type="event" value="Temperature more than 30 degrees" />
      </param>
      <param reference="1" value="30" operator="le">
        <action type="event" value="Temperature less than or equal to 30 degrees" />
      </param>
    </message>
  </rules>
</uddXmlMapper>

There can be more than one type of message and their rules, but typically, UDD is configured to handle messages only in one format. However, one message format usually has several rules and actions defined.

The message “value“ attribute should be the same as the “value“ attribute of the message element in the input arguments extraction section, or it should be the root element value if the incoming message is in XML format. In our example, the root XML element is “Data“ in the input message.

The “message” element has several special attributes:

“alwaysShowText” attribute with the value "yes" or “no“. If this attribute is defined and the value is “yes“, then the incoming message will be shown in the text channel even if the parameter comparison fails.
“handleParameters“ attribute - if it has the value “all“, then it means that for the incoming message, all rules are run through. By default, UDD stops processing if the first rule is matched.

Each message in the rules section has several parameters - “param“ elements. The parameters have the “reference” attribute - this is the reference to the input argument (it’s ID number). So, the parameter syntax means: let’s compare the input argument with this reference number with the value in the parameter, and the comparison operator is defined in the “operator“ attribute. The following operators are supported in UDD:

eq - equal (=) operator - it is the default operator type.
neq - not equal (!=) operator.
gt - greater than (>) operator.
ge - greater than or equal (>=) operator.
lt - less than (<) operator.
le - less than or equal (<=) operator.
contains - check if the input argument string value contains the parameter value.
contained - check if the parameter value is contained in the input argument string.

By default, all values are considered as strings. But in addition, you can define with the “type“ attribute of the parameters what type should be used for the comparison. Currently, the following types are supported:

type="integer"
type="float"
type="string"

For the operator “eq“, the additional comparison mode is supported when the value from the input message is compared with multiple values in an XML file using the “OR” logic operator. So, if ANY value from the list is equal to the input value, then the parameter is “True“, and the action is generated. The following syntax in the XML configuration file parameters is supported in this case:

<root>
  ...
  <uddXmlMapper version="2">
    ...
    <rules>
      <message number="1" value="Message" alwaysShowText="yes">
        <param number="1" reference="1" operator="eq" value="[[File_with_values.txt]]">
          <action number="1" type="event" value="Event 1 received" />
        </param>
        <param number="2" reference="1" operator="eq" value="value1|value2|value3|value4">
          <action number="1" type="event" value="Event 2 received" />
        </param>
      </message>
    </rules>
  </uddXmlMapper>
</root>

So, here we can see 2 parameters:

In the first parameter, the “value“ attribute contains the file name: value="[[File_with_values.txt]]". The driver will read values from this file (values must be comma- or line-separated).
In the second parameter, the “value“ attribute contains the list of values separated by “|“: value="value1|value2|value3|value4".

In both cases, we will have a comparison of the input value with multiple values using the OR logic operator.

If the conditions defined in the parameters are “True“, then the actions are triggered. In the example, the action for the first parameter is defined like this:

<action type="event" value="Temperature more than 30 degrees" />

Here, the “Temperature more than 30 degrees“ event will be generated in the text channel if the conditions are “True”. The following action types are supported by UDD:

event - action to generate a text channel event.
data - action to send text data to the text channel.
metadata - action to store the metadata in the VMS database.

For metadata, the additional attributes can be used:

"metadatatype". If it is specified, it allows the configuration of the metadata type:
- "xml" - XML metadata format
- "udpvca" - special UDP VCA metadata format
- "textevent" - text event metadata format (will be used by default if the metadata type is not specified)
- "other" - other metadata format
“metadatachannel” - the channel number that will be stored for the metadata.

The parameters can also have an associated search tag. If a search tag type attribute has been omitted, it is set by default to be SEARCH_TAG_TYPE_TEXT:

<searchtag value="Alarm cam001" />

It is possible to combine multiple input argument references in one parameter using the Boolean operators AND or OR. In one parameter, only one type of Boolean operator can be used:

<param reference="1" value="camera" operator="eq">
  <and reference="2" value="10" operator="eq">
  <and reference="3" value="motion" operator="eq">
  <action type="event" value="Motion detected on camera 10" />
</param>

The Version 2 Mapper

In the mapper version 2, the following changes were made:

The macro-substitution elements were added
The VMS camera mapping was added

Macro-substitution and arrays

As a part of the macro-substitution mechanism, the constant arrays were introduced. They are placed in the “uddXmlMapper” section and have the following format:

<uddXmlMapper version="2">
  <constants>
    <array name="ArrayName1" params="ParamId">
      <value>value1</value>
      <value>value2</value>
      <value>value3</value>
    </array>
    ...
    <array name="ArrayNameN" params="ParamId">
      <value>value1</value>
      <value>value2</value>
      <value>value3</value>
    </array>
  </constants>
</uddXmlMapper>

The array itself has a unique name that will be used in macro-substitution in the rules section. In addition, each array has the “params“ attribute, where the list of parameter identifiers is written, separated by a comma. In the array itself, it has a list of “value” elements where the array values are defined. Let’s check with the configuration example how it is working:

<uddXmlMapper version="2">
  <messageType value="xml">
    <message format="XPath"></message>
    <param number="1" value="/Event/Type" />
  </messageType>
  <constants>
    <array name="EventType" params="ParamEvent">
      <value>videoloss</value>
      <value>defocus</value>
      <value>parking</value>
    </array>
  </constants>
  <rules>
    <message number="1" value="Message" alwaysShowText="yes">
      <param reference="1" value="$EventType" operator="eq" id="ParamEvent">
        <action type="event" value="The '$EventType' received" />
      </param>
    </message>
  </rules>
</uddXmlMapper>

In this configuration, we extract the event type value from the incoming XML message, then we compare this argument (event type) with the constant values defined in the “EventType“ array. This array is connected with the parameter with identifier “ParamEvent“, and it will be used for macro-substitution. So, if we are talking about the old mapper format, the same rules can be replaced with the following number of rules without macro-substitution:

<uddXmlMapper>
  <messageType value="xml">
    <message format="XPath"></message>
    <param number="1" value="/Event/Type" />
  </messageType>
  <rules>
    <message number="1" value="Message" alwaysShowText="yes">
      <param reference="1" value="videoloss" operator="eq">
        <action type="event" value="The 'videoloss' received" />
      </param>
      <param reference="1" value="defocus" operator="eq" >
        <action type="event" value="The 'defocus' received" />
      </param>
      <param reference="1" value="parking" operator="eq" >
        <action type="event" value="The 'parking' received" />
      </param>
    </message>
  </rules>
</uddXmlMapper>

As you can see this constant arrays just simplify the configuration rules and allow decreasing the XML configuration file size.

VMS camera mapping

The constant array values can have a special attribute “camera“ like this:

<array name="Entrance" params="Param1">
    <value camera="Camera 1">Gate</value>
    <value camera="Camera 2,Camera 3">Office</value>
</array>

In this “camera“ attribute user can specify a list of camera names (the same camera names as in the VMS profile), and UDD automatically adds special camera text data to the following places:

If the value from the array is used in the text, the text message in the text channel will have the specified camera names in the square brackets after the main message:

Message...
[Camera 1]

If the value from the array is used for event generation, then the event text will have specified camera names in the square brackets after the main event text:

Event text ... [Camera 1]

In addition, such an event will have a special “Camera Name“ search tag class with the camera names as search tags.

If the user double-clicks the text message with the camera name in the text search plugin in Spotter, it will open the camera with the same name if it is available in the profile.

Events Cache

With dynamically generated events in the V9 system, we can have a situation where the event indexes are changed when the user changes the XML configuration file. To avoid this situation, the event cache mechanism is implemented for the UDD. It automatically saves all events with assigned indexes to the XML files in the recorder folder. The file name has the following format:

UDD_<Configuration_File_Name>.evcache

So, for different configuration files, we will have different event cache files.

When new events are generated (for example, when a user changes the XML file and re-adds a text channel), the UDD looking to the cache file first, and if an event with the same name already exists, it returns the current index. If no such event is in the cache, then it uses the first free index and saves it to the cache.

System Manager Configuration

In the System Manager application to configure the UDD text channel, go to the VMS Servers tab and double-click Text channels to open the Text Channel Settings dialog for the selected recorder, click the Add channels button, and in the model list select one of the UDD models:

Depending on the model, the text channel parameters are different. For example, for the “UniversalDataTcpModel “, you will have the following parameters:

Text channel - UniversalDataTcpModel parameters

Common Parameters

The following parameters are common for all models:

Validation - validation type that is selected for the incoming message. The following validation types are supported:
- XSD - XML validation against XSD schema.
- Text - Regex validation of text messages.
- Custom - custom validator DLL will be used for validation (and transforming the data if needed).
- None - validation is not used, and the incoming data will be passed to handling without validation/transformation.
Configuration file - the name of the XML configuration file in the DVR folder of VMS (<name>.xml)
Custom validator - the name of the custom validator DLL in the DVR folder of VMS (<name>.dll)
Send the “End“ event after N - The additional “End“ event will be generated after N seconds from the normal event. If the value is 0, then no “End“ event will be generated.
Forward incoming message to - the address of the host in format <IP_Address>:<TCP_Port>, where the UDD will forward the incoming message using TCP connection.

And each model has its own specific parameters that are described below.

TCP Server Model Parameters

For this model, only one parameter is specific:

TCP Port number - the port where the UDD will listen for incoming TCP connections.

UDP Server Model Parameters

For this model, only one parameter is specific:

UDP Port Number - the port where the UDD will listen for incoming UDP packets.

TCP Client Model Parameters

The model has the following specific parameters:

Address - IP address or DNS name of the TCP server host.
TCP Port number - port of the TCP server host.

HTTP Client Model Parameters

The model has the following specific parameters:

Address - IP address or DNS name of the HTTP server.
HTTP Port - HTTP port of the server.
Username - user name for the HTTP authentication.
Password - password for the HTTP authentication.
Authentication Scheme - type of the HTTP authentication scheme.

HTTP Server Model Parameters

The model has the following specific parameters:

HTTP Server Port - the port where the UDD will listen for incoming HTTP connections.

RTSP Client Model Parameters

The model has the following specific parameters:

Address - IP address or DNS name of the RTSP server.
RTSP Port - RTSP port of the server.
Username - user name for the RTSP authentication.
Password - password for the RTSP authentication.

Proxy Model Parameters

UDD supports proxy services, which are used to communicate with 3rd party systems with their own protocols. The proxy service is a separate Windows service with its own installer. After installation, it is configured to send the data to a specific port of the UDD text channel.

The model has the following specific parameters:

Proxy Service - list of supported proxy services.
Device Address - the device or 3rd party system address that is passed to the proxy service for connection.
Device Port - the device or 3rd party system port that is passed to the proxy service for connection.
Username - the device or 3rd party system user name that is passed to the proxy service for the authentication.
Password - the device or 3rd party system password that is passed to the proxy service for the authentication.
Incoming TCP port - the port where the UDD will listen for incoming TCP connections from the proxy service.

Intrepid Proxy Model Parameters

This model is done specifically for the Intrepid proxy service. It has the following parameters:

Network Address - the address of the Intrepid system.
Network Port - the port of the Intrepid system.
Subserver Devices (comma separated) - list of devices connected to the Intrepid system.
Incoming TCP port - the port where the UDD will listen for incoming TCP connections from the proxy service.

Pelco Thermography Proxy Model Parameters

Pelco thermography data proxy model parameters

This model is done specifically for the Pelco Thermography proxy service. It has the following parameters:

Camera Address - address of the Pelco Thermography camera.
Camera Port - HTTP port of the Pelco Thermography camera.
DVMS Channel Port - the port where the UDD will listen for incoming TCP connections from the proxy service.
Template configuration - XML file name with configuration parameters for the Pelco Thermography proxy service.

Ajax Model Parameters

This model was done for the integration with Ajax systems. It has the following parameters:

AWS Region
AWS Event Queue Name - name of the Events queue that is used for storing alerts and events of the Ajax security system in Amazon SQS.
AWS Access Key ID - used to sign the requests sent to Amazon SQS.
AWS Secret Access Key - used for programmatic (API) access to Amazon SQS.
AWS Request Timeout (ms) - socket read timeouts for HTTP clients on Windows.
AWS Max number of messages - the maximum number of messages to return.
AWS Wait time (sec) - the duration (in seconds) for which the call to the queue waits for a message to arrive in the queue before returning.
Ajax User Role - the type of user account.
Ajax Username - login for access to Ajax Endpoint.
Ajax Password - hash for access to Ajax Endpoint.
X-API-KEY - a unique identifier for authenticating all requests to the Enterprise API.
Validation - supported only by custom validation.
Configuration file- the name of XML file for showing Ajax events after the validation.
Custom validator - the name of the library for validation of Ajax events.
Send the “End” event after N - recommended to leave 0.
Forward incoming message to - recommended to leave blank.

UniversalDataSerialModel parameters

The model has the following specific parameters:

Port number - serial port number.
Serial port parameters:
- Baudrate
- Databits
- Stopbits
- Parity
- Flow control
- DTR
- RTS
- Output CTS
- Output DSR
- Read cycle timeout in milliseconds.