Transparent channel functionality is frequently used whenever there is a need to transfer data from a peripheral that outputs asynchronous data via serial port (RS232) to the client’s server (using Command 14/114 – Transparent Channel data) without special integration into the device. This knowledge article will describe some basic steps in troubleshooting transparent channel data reading.

To understand/check HEX values for different ASCII symbols refer to ASCII tables or use a converter. More information can be found here: https://en.wikipedia.org/wiki/ASCII

NOTE: This knowledge article is mostly intended for 2nd line technical support. If you find the issue to be difficult or if you do not fully understand the below explanations, please transfer the ticket to 2nd line supporters.

The most common issue our clients face with Transparent channel functionality is the wire connection. In common serial port connections transmitter wires (Tx) are supposed to connect to receiver wires (Rx) from both the accessory/peripheral’s side and the main device’s side. For our devices this isn’t the case – Rx needs to be connected to Rx and Tx need to be connected to Tx.

For a clearer understanding, please refer to the below diagram:

It would be best to ask the client to provide connection photos to ensure that the peripheral is connected to the device correctly.

If the connection is correct, then the next step is to check the protocol and communication information of the peripheral. Please ask the client to provide any datasheets or communication protocols, the below information should give you a general understanding of what to look for:

With most simple protocols the minimum specified information should be the baudrate, data bits, parity bit and stop bits. This information is also commonly written in the following form:

(data bits)-(parity)-(stop bits)

Or:

(baudrate)-(data bits)-(parity)-(stop bits)

For example, the most common serial port settings are 8 data bits with no parity bit and 1 stop bit, which can be written as:

8-N-1

The most commonly used baudrate is 9600 as well, which can be added in the following way:

9600-8-N-1

Here is an example of 7 data bits, even parity and 2 stop bits:

7-E-2

If the same was specified but with 600 baudrate and odd parity, it would look something like this:

600-7-O-2

Checking the peripheral output

The last thing that can be checked it the output of the peripheral itself. If the client has an RS232 to USB converter, then they can test the device with the Terminal tool (the same tool we use to collect logs) or with any other similar tool.

Information from the protocols can be specified in the settings of the tool (custom baudrate can also be used if needed). It is also recommended to get a log in HEX, as that will show raw data instead of it being processed into symbols.

Here is an example of an output a client has performed with 9600 baudrate, 8 data bits, none parity and 1 stop bit:

After using a HEX to ASCII converter with the data, we get the following results:

In this case we see that there is always a “#” symbol at the start and an “0D” symbol at the end (Carriage Return, not visible in ASCII), so we can use the following settings in Transparent channel:

NOTE: Technically there are more unchanging values between records in the above example (“23 32 32 7C 30 7C” at the start and “7C 30 0D” at the end), but if the client is unsure what data can change it’s best to choose start/end symbols that are as short as possible (the data can be trimmed/changed server-side). Additionally, beginning/ending symbols can be removed from the sent data to the server with the checkbox “Remove identification symbols from payload” (visible in the above screenshot, at the bottom of the window).