# Connection Types

Table 1-1 in section 1.4 includes a list of connection types available for each device. The following subsections provide details developers will need to communicate with the device using each connection type.

#### How to Use Network Connections (Ethernet or 802.11 Wireless Only) <a href="#bookmark52" id="bookmark52"></a>

**How to Use Ethernet Connections (Ethernet Only)**

When the device is connected to a network via a 10/100 Ethernet port, it will attempt to contact a DHCP server to acquire a dynamic IP address during power-up. See the network administrator to determine the IP address the DHCP server assigned to the device. After determining the IP address, use port 5000 to communicate with the device.

**How to Send Commands Using the Network Connection**

The messages exchanged between the host and the device on the TCP/IP connection do not require any wrappers or encoding: The binary data flowing through the connection is identical to the message format defined in section 2 Messages, Commands, Responses, and Notifications and in section 4 Command Set. A C0 at the beginning of a message’s usage table means that without any preparation other than binding to the port, the host begins sending the command by sending a single binary byte 0xC0.

For example, to send Command 0x00:0x10 - Get Product ID to the device over TCP/IP, the host should send a stream consisting of single binary byte 0xC0, followed by single binary byte 0x01, followed by single binary byte 0x01, followed by single binary byte 0xC1, and so on following the sequence in Table 4-1. The device will then send a response over the same connection according to the sequence in Table 4-2.

#### How to Use RS-232 Connections (RS-232 Only) <a href="#id-3.2_how_to_use_rs-232_connections_-rs-23" id="id-3.2_how_to_use_rs-232_connections_-rs-23"></a>

The messages exchanged between the host and the device on the RS-232 connection require a small wrapper and must be ASCII encoded hexadecimal (‘0’ through ‘F’ only). The message format is defined in section 2 Messages, Commands, Responses, and Notifications and in section 4 Command Set. ASCII encoding means when the device intends to send C0 at the beginning of a message’s usage table, it should send two ASCII bytes, where ‘C’ is ASCII 0x43 and ‘0’ is ASCII 0x30. When the device is using default settings, the host should send a line feed (0x0A) to signal the end of the message. The device’s responses and notifications will be wrapped and encoded the same way.

For example, to send Command 0x00:0x10 - Get Product ID to the device over the RS-232 connection, the host should send a stream consisting of ASCII ‘C’ (0x43), ASCII ‘0’ (0x30), ASCII ‘0’ (0x30), ASCII ‘1’ (0x31), ASCII ‘0’ (0x30), ASCII ‘1’ (0x31), ASCII ‘C’ (0x43), ASCII ‘1’ (0x31), and so on following the sequence in Table 4-1, then a line feed (0x0A). The device will then send a response over the same connection according to the sequence in Table 4-2, then a line feed (0x0A).

The devices only use TXD and RXD; hardware handshaking is not available. The default serial settings are 9600 bps, No parity, 8 data bits, and 1 stop bit.

The device can optionally be configured by the manufacturer to expect / transmit a Starting Byte and an ASCII CRC checksum in this order: \<Starting Byte> \<Message in ASCII> \<CRC in ASCII> \<Ending Byte>. The device’s default setting is “raw mode,” where the device only expects / transmits the Ending Byte, which is set to Line Feed (0x0A). Other popular choices when ordering a device may include Starting Byte=STX (0x02); Ending Byte=ETX (0x03) or CR (0x0D).

#### How to Use USB Connections (USB Only) <a href="#id-3.3_how_to_use_usb_connections_-usb_only" id="id-3.3_how_to_use_usb_connections_-usb_only"></a>

The device conforms to the USB specification revision 2.0, and is compatible with revision 1.1. It also conforms to the Human Interface Device (HID) class specification version 1.1, and communicates as a vendor-defined HID device. This document assumes the reader is familiar with USB HID class specifications, which are available at [*www.usb.org*.](http://www.usb.org/)

Developers can easily create custom software to communicate with the device using any framework that can communicate with a USB port. For example, developers can use the standard Windows USB HID driver with Visual Basic or Visual C++. MagTek has developed demonstration software that communicates with the device via this method, and developers can use it to test the device and to provide a starting point for developing other software. Because the device’s USB implementation is operating system agnostic, the device can be used with other platforms as well, such as Linux. For more information, see the MagTek web site, or contact your reseller or MagTek Support Services.

The device is a full speed high-powered USB device that identifies itself with vendor ID 0x0801 and product ID 0x001B. The device does not draw power from the USB port, and does not support USB Suspend or remote wakeup.

### **About HID Usages**

#### About Reports

USB HID devices send and receive data using reports. Each report can contain several sections, called usages, each of which has its own unique four-byte identifier. The two most significant bytes of a usage are called the usage page, and the least two significant bytes are called the usage ID. Vendor-defined usages must have a usage page in the range 0xFF00 - 0xFFFF, and it is common practice for related usage IDs to share the same usage page. For these reasons, all usages for this device uses vendor-defined usage page 0xFF20.

HID reports used by the host can be divided into three types:

* Feature Reports, which can be further divided into Get types and Set types. The host exclusively uses this type of report to send messages to the device.
* Input Reports are used by the device to send asynchronous responses or notifications to the host when a related feature report completes, or automatically when the device’s state changes. This is common when an operation depends on cardholder action.
* Output Reports. Output reports are part of the USB HID standard, but are not used by this device.

#### About the Report Descriptor

The list of the device’s available reports and their structure is sent to the host in a report descriptor, usually just after the device is connected to the USB port. Generally the details of the report descriptor are abstracted by the developer’s HID API; however, should it become necessary to examine a report descriptor byte-by-byte, a full inventory of the report descriptor for these devices is provided in Table 3-1.

## Table - USB HID Report Descriptor

<table data-header-hidden><thead><tr><th valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">Item Tag (Value)</td><td valign="top">Raw Data</td></tr><tr><td valign="top">Usage Page (Vendor-Defined 33)</td><td valign="top">06 20 FF</td></tr><tr><td valign="top">Usage (Vendor-Defined 1)</td><td valign="top">09 01</td></tr><tr><td valign="top">Collection (Application)</td><td valign="top">A1 01</td></tr><tr><td valign="top">Report Size (8)</td><td valign="top">75 08</td></tr><tr><td valign="top">Logical Minimum (0)</td><td valign="top">15 00</td></tr><tr><td valign="top">Logical Maximum (255)</td><td valign="top">26 FF 00</td></tr><tr><td valign="top">Report ID (5)</td><td valign="top">85 05</td></tr><tr><td valign="top">Usage (Vendor-Defined 5)</td><td valign="top">09 05</td></tr><tr><td valign="top">Report Count (63)</td><td valign="top">95 3F</td></tr><tr><td valign="top">Feature (Data,Var,Abs,NWrp,Lin,Pref,NNul,NVol,Buf)</td><td valign="top">B2 02 01</td></tr><tr><td valign="top">Report ID (2)</td><td valign="top">85 02</td></tr><tr><td valign="top">Usage (Vendor-Defined 32)</td><td valign="top">09 20</td></tr><tr><td valign="top">Report Count (63)</td><td valign="top">95 3F</td></tr><tr><td valign="top">Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Buf)</td><td valign="top">82 02 01</td></tr><tr><td valign="top">Report ID (3)</td><td valign="top">85 03</td></tr><tr><td valign="top">Usage (Vendor-Defined 33)</td><td valign="top">09 21</td></tr><tr><td valign="top">Report Count (5)</td><td valign="top">95 05</td></tr><tr><td valign="top">Output (Data,Var,Abs,NWrp,Lin,Pref,NNul,NVol,Bit)</td><td valign="top">91 02</td></tr><tr><td valign="top">End Collection</td><td valign="top">C0</td></tr></tbody></table>

**How to Send Commands Using USB HID**

The general sequence the host should use to send a message to the device is as follows:

* The host sends a Set Feature Report with Report ID 0x05, containing the command message in binary format (bytes) as data.
* The device asynchronously sends an Input Report with Report ID 0x02, containing the defined response to the originating command in binary format (bytes) as data. Depending on the command, the response may or may not contain a Data Field Data Object (Tag C4 or E0).

The general sequence the device uses to send a message to the host is as follows:

* The device’s state changes, a cardholder or operator takes action, or new information becomes available.
* The device asynchronously sends an Input Report with Report ID 0x02, containing the notification message in binary format (bytes) as data.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.magtek.com/hardware/oem-readers-and-components/oem-readers/odynamo/documentation/programmers-manuals/programmers-manual-commands/connection-types.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.