µ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.
µ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;
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 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:
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
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
Each command has its corresponding value – look at COMMANDS OVERVIEW.
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 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:
Mandatory 7 byte CMD packet structure
CMD_EXT packet has the following structure:
Parameter bytes 1 to N – different parameters, values depends on the type of command
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 packet has the following structure:
ACP packet structure
ERR packet has the following structure:
Mandatory 7-byte ERR
ERR_EXT and has the following structure:
RSP packet has the following structure:
Mandatory 7-byte RSP
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.