µFR Serial Communication Protocol for µFR series devices

µFR Serial Communication Protocol for µFR series devices

µFR Series devices can establish communication over FTDI’s Virtual COM port, so devices are seen as standard COM port hardware.

Communication parameters #

Readers with FTDI serial interface #

µFR Classic and µFR Advance readers with a USB connection:

Serial communication: 1 Mbps, 8-N-1, Flow control: None;

The RTS pin is used to reset the device. When the RTS is set, the device is in a reset state. When the RTS is clear, the device is in a normal state.

µFR BaseHD readers with “µFR support” firmware installed (ex. XR and µFR XRc readers):

Serial communication (using VCOM FTDI driver): 250 kbps, 8-N-1, Flow control: None;

Readers without FTDI serial interface #

RS485 (connection without USB/RS-485 converter):

The variable baud rate can be set through a software tool. The current baud rate must be known when changing the baud rate. The default baud rate is 250 kbps.

µFR Classic Nano RS232 and Card Size RS232:

UART / TTL: 115200 bps, 8-N-1, Flow control: None.

115200 bps is the default baud rate. The variable baud rate can be set through the software tool.

PIN 4 on the connector is used to reset the device. If the voltage on this pin is high (3.3 V) then the device is in the reset state. If the voltage is low (0 V) then the device is in a normal working state.

If the device is connected to our RS232 to TTL converter, then the voltage level on pin 4 control over RTS. When the RTS is clear, the device is in a reset state. When the RTS is set, the device is in a normal state.

During the firmware update, the RTS pin has to be connected to pin 4 on the device.

Pinout for UART / TTL model is presented below:

For communication purposes between reader devices and host PC, D-Logic’s proprietary protocol called “µFR serial” is created.

All communication is initiated by the host (PC or other platforms) to which the device is connected.

Maximum data transferred by single command or received by one device response, from firmware version 3.9.44 is 256 bytes, and before is 192 bytes.

Generally, there are two types of packets:

• CMD – command sent by the host to device
• ANS – answer sent from the device to host

CMD can be a short or long set. CMD short set is always 7 byte long while CMD long set – called CMD_EXT can have variable length.

The answers are:

• ACK – Acknowledgment, everything is OK, the device is waiting for the next CMD or CMD EXT
• ERR – Error occurred, error byte defines ERR_TYPE
• RSP – Response from the device on CMD or CMD_EXT

Communication constants bytes defines the type of packet, which can be seen in the first three bytes of each packet.

The first byte of each packet is the HEADER byte. The second byte is always CMD_CODE. The third byte is the TRAILER byte.

Table1. Communication constants

CHECKSUM #

All checksums in this document are calculated in the same manner: a row of bytes is used for checksum calculation, each byte is XOR-ed with the next one until the end of the row. The final value is incremented with 0x07.

For example, a CMD packet has 7 bytes, where the 7th byte is the checksum of the previous 6 bytes:

CHECKSUM = (Byte1 XOR Byte2 XOR Byte3 XOR Byte4 XOR Byte5 XOR Byte6) + 0x07

CMD codes #

Each command has its corresponding value – look at COMMANDS OVERVIEW.

Error codes #

If an error occurs, the device will answer with the ERR packet. Each Error has its corresponding value which can be found in the table in Appendix: ERROR CODES.

CMD packet #

CMD packet can be short – 7 byte long or EXT-ended with variable length. In the case of EXT CMD packet, the fourth byte of CMD packet is greater than 0, containing integer value – length of CMD_EXT packet. When issuing CMD_EXT, always main CMD 7-byte long packet goes first. If everything as expected, the device will answer with the ACK packet, waiting for the CMD_EXT packet. On error, the device will answer with the ERR packet. CMD_EXT consists of various different parameters, depending on command type, so CMD_EXT does not have a fixed length and order of parameters.

CMD packet has the following structure:

CMD packet has the following structure:

• Byte 1: CMD_HEADER as defined in Table1.Communication constants, 0x55 
• Byte 2: CMD_CODE as defined in Table2. CMD_CODE values
• Byte 3: CMD_TRAILER as defined in Table1.Communication constants, 0xAA
• Byte 4: CMD_EXT_Length: If 0 then the “CMD EXT” is not used); ELSE value is the length of the whole CMD_EXT packet
• Byte 5: CMD_Par0: command parameter0, takes different values depending on the command
• Byte 6: CMD_Par1: command parameter1, takes different values depending on the command
• Byte 7: CHECKSUM – Checksum of Bytes 1 to 6 as explained above

CMD_EXT packet has the following structure:

CMD_EXT packet has the following structure:

Parameter bytes 1 to N – different parameters, values depends on the type of command

• CMD_EXT_CHECKSUM – Checksum of bytes 1 to N
• CMD_EXT_Length is the number of all bytes including CMD_EXT_CHECKSUM; e.g. length is N+1

ANSWER packet types #

The device can answer with the following packet types:

ACK – Acknowledgment packet

If the command and CMD packet are properly configured (structure and checksum) and an additional CMD_EXT packet needs to be sent, the device will answer with an ACK packet.

ERR – Error packet

If an error occurred, the device will answer with the ERR packet. Some commands can return the ERR_EXT set. In that case, the ERR_EXT packet comes immediately after the ERR packet.

RSP – Response packet

If a properly configured CMD or CMD_EXT packet is sent, the device will answer with RSP or RSP_EXT packet, which depends on the command issued. For example, if CMD needs an answer which is short enough for the RSP packet, there will be no RSP_EXT packet. Otherwise, if CMD or CMD_EXT needs an answer with more bytes, RSP_EXT will come immediately after the RSP packet. A common situation is when reading data with the LinearRead command, where the device will answer with a row of card data bytes.

ACK – Acknowledgment packet #

ACK packet has the following structure:

ACK packet has the following structure:

• Byte 1: ACK_HEADER as defined in Table1.Communication constants, 0x55
• Byte 2: CMD_CODE as defined in Table2. CMD_CODE values. Device ACKnowledges that the previous command is properly sent
• Byte 3: ACK_HEADER as defined in Table1.Communication constants, 0x55
• Byte 4: Byte 5, Byte 6: Not used in ACK packet, values are 0x00
• Byte 7: CHECKSUM – Checksum of Bytes 1 to 6 as explained above

ERR – error packet #

ERR packet has the following structure:

• Byte 1: ERR_HEADER as defined in Table1.Communication constants, 0xEC
• Byte 2: ERR_CODE as defined in Table3. ERROR CODES.
• Byte 3: ERR_TRAILER as defined in Table1.Communication constants, 0xCE
• Byte 4: If ERR_EXT exists, this byte contains the length of the ERR_EXT packet (including ERR_EXT checksum)
• Byte 5: Possible additional info on error can be defined in ERR_Val0
• Byte 6: Possible additional info on error can be defined in ERR_Val1
• Byte 7: CHECKSUM – Checksum of Bytes 1 to 6 as explained above

ERR_EXT and has the following structure:

• Byte 1: First Byte of ERR_EXT
• …
• Byte N: N-nth Byte of ERR_EXT
• Byte N+1: ERR_EXT_CHECKSUM, checksum of Bytes 1 to N, calculated as explained earlier.

RSP – response packet #

RSP packet has the following structure:

• Byte 1: RSP_HEADER as defined in Table1.Communication constants, 0xED
• Byte 2: CMD_CODE as defined in Table2. CMD_CODE values
• Byte 3: ERR_TRAILER as defined in Table1.Communication constants, 0xDE
• Byte 4: If RSP_EXT exists, this byte contains the length of the RSP_EXT packet (including RSP_EXT checksum)
• Byte 5: Possible additional info on RESPONSE can be defined in RSP_Val0
• Byte 6: Possible additional info on RESPONSE can be defined in RSP_Val1
• Byte 7: CHECKSUM – Checksum of Bytes 1 to 6 as explained above.

t

• Byte 1: First Byte of RSP_EXT
• …
• Byte N: N-nth Byte of RSP_EXT
• Byte N+1: RSP_EXT_CHECKSUM, checksum of Bytes 1 to N, calculated as explained earlier.