It is not recommended.

All products (TCXxx/CXxx/MXxx, etc.) support the following code formats:

QR Code / Data Matrix / PDF417

EAN-8 / EAN-13 / ISBN-10 / ISBN-13 / UPC-E / UPC-A

CODE39 / CODE93 / CODE128

Interleaved 2 of 5

Arduino, being a hardware platform based on microcontrollers, is fully supported, as explained in the previous question.

Yes, they are fully supported. PLC users typically use products with RS232 or RS485 interfaces. Determine the customer's hardware interface requirements and recommend the corresponding product. Provide the relevant communication protocol documentation.

Devices with TTL serial port/RS232/RS485/Wiegand interfaces can be used with microcontrollers. Recommend the corresponding product based on the customer's hardware platform and interface requirements.

Currently, our products support the following interfaces: RS232, RS485, TTL serial port, Bluetooth, WiFi, Wiegand, USB.

- RS232: Common asynchronous transmission interface with a maximum transmission distance of 15 meters.

- RS485: An improved version of RS232 with enhanced noise resistance, supporting multiple transceivers on one bus. Transmission distance is over 1 kilometer.

- TTL Serial Port: Often used for board-level SOC connections, characterized by low latency but poor interference resistance and short transmission distance.

- Bluetooth: Low-power 2.4G communication protocol. Advantages include low power consumption, full duplex, and ease of use. Disadvantages include poor interference resistance and effective transmission distance of within 10 meters.

- WiFi: High-fidelity wireless local area network. Disadvantages include susceptibility to other electromagnetic interference and high requirements for network environment.

- Wiegand: Commonly used in security access control fields. Advantages include encryption in the protocol, making data difficult to steal. Disadvantages include limited data transmission in a single transmission.

- USB: The most commonly used plug-and-play interface. Features include fast plug-and-play.

Our Wiegand interface supports TTL 3.3V/CMOS 3.3V/TTL 5V and does not support other voltage standards such as CMOS 5V.

Actual testing shows no issue with distances up to 45 meters. Theoretically, it can withstand transmission distances of 80 to 100 meters.

Wiegand products are commonly used in access control systems, where this issue is rare. For serial port devices, transmission distance is also a concern. Higher baud rates result in shorter transmission distances. If long-distance connections are required, a relay must be used in between.

Both are Wiegand protocols. The difference lies in the number of bytes transmitted; Wiegand 26 transmits 3 bytes each time, while Wiegand 34 can transmit 4 bytes. Our products support both forms, and users can configure them using the configuration tool.

Yes, it supports various cards including but not limited to ID cards, M1 cards, and Type A/Type B cards. The output result can be configured for full output or specific 4-byte output.

Our Wiegand interface supports both barcode and QR code scanning. Due to limitations of the Wiegand protocol, for Wiegand 26, the code for customers must be 6-8 digits (or within 3 bytes), and for Wiegand 34, the code must be 6-10 digits (or within 4 bytes).

Our network devices have a set timeout period, with the default being two seconds. If the interval between the server sending the return value to the device and scanning data exceeds this time, even if the return value is received, the device will consider this transmission as a failure. This phenomenon is generally caused by poor network environment. The solution is to appropriately extend the timeout period, but it should be noted that the maximum timeout period is 5 seconds.

Several reasons could lead to this situation:

1. Our Wiegand device reads the physical card number (although newer devices support reading other sectors, existing devices do not), while the customer's previous card reader may have read content from other sectors.
2. The decoding methods are different. Refer to the Wiegand output section and calculate to determine whether the customer's previous decoding method used PHID or direct output, then adjust ours accordingly.
3. Different lengths of data might be captured. For example, for ID cards, there are 10 digits in total, but we might output only four digits. If the captured length differs from what the customer is used to, it can lead to inconsistent outputs.
4. The customer's original card reader may have its encryption method rather than the standard Wiegand protocol.

1. First, determine if there is no response when scanning or if there is a response but no output.
2. If there is a response, it indicates that the device has recognized the QR code, but there might be issues with the transmission path or configuration. Consider the following:

- For devices with USB output, issues are rare. Ensure the USB port is functioning properly. If using software decoding devices, ask the customer to disable antivirus/firewall software and try again.

- For devices with Wiegand output, confirm if the scanned code is a pure numeric code of 6-10 digits. If not, it won't output. If conditions permit, ask the customer to check if there is output on the device's D0 and D1 ports using an oscilloscope. If there is no output, it might indicate hardware damage, and the device should be sent back for repair.

- For devices with serial port or TTL output, confirm if the baud rate is consistent. Refer to the 17th point for handling.

- For devices with Wi-Fi/Ethernet output, check if the server address and network name in the configuration are correct. Ask the customer to conduct local testing. Refer to point 35 for handling.

- For Bluetooth devices, it might be due to the customer not finding the right service. Refer to point 11 for handling.

- Regardless of the device type, ensure that the device's output method matches the customer's requirements.

3. If there is no response, first confirm whether the device is in normal mode rather than secondary development mode. In the secondary development mode, scanning data can only be obtained by calling the corresponding interface. If it is in normal mode, it's likely a hardware problem, and the customer should send it back for repair.

For older Wi-Fi devices, the server path should be filled in without the "http://" prefix. For example, if the self-built server domain name (or IP and port) is 127.0.0.1:1480, then fill in "/127.0.0.1:1480", without the "http://" prefix. For newer products like MX86 and TXwifi, the "http://" prefix is required; otherwise, configuration may not be successful.

1. First, confirm if the customer's scanner can correctly identify the scanning/swiping (i.e., whether there is sound or other feedback when scanning). If the scanner cannot recognize the scanning, provide the customer with an initial configuration code (i.e., open the configuration tool without any operation and directly generate a configuration code), and let the customer scan this code to connect to the device to see if it can connect to the device and if scanning has output. Then guide the customer to configure.
2. Check the customer's configuration. Ethernet device configuration is limited, only requiring correct server address, port number, and timeout. Ensure that the server address and port number are correct.
3. If the device configuration is correct, the success or failure of network device connection depends on the customer's network environment. In this case, it is difficult for us to directly judge, so inquire about the customer's usage environment and network conditions to ensure that the device can connect to the server through the network. It is recommended to suggest the customer set up a local server for testing or use a good device on our side to test whether it can connect to the customer's server (if the customer can connect to the external network, they can set up a server by themselves and let the customer use their device to connect to our server for testing, which can rule out device issues).
4. If after the above steps, the problem cannot be identified and resolved, it can be suspected as a hardware issue. The basic judgment method is to let the customer use a multimeter to measure the voltage between the module TX and RX terminals to the ground, which should be 3.3V. If not, it can be determined as a hardware problem and must be sent back for repair.

The Android system has anti-invalid input interference detection. If the trigger time of two keys is too short, it will be considered as illegal input. Therefore, the press and release time should be set to exceed 10ms using the configuration tool. It is not recommended to directly output via USB when using on Android; it is better to use serial port, Bluetooth, or secondary development.

1. Confirm if the customer's server can receive data. If it can, ask if the customer has modified the protocol mode. The feedback behavior of the network device is based on the protocol. It can only work properly in protocol mode.
2. The transmission success behavior configured in the configuration tool actually refers to the entire process from the scanner scanning data, uploading to the server, to receiving the return value from the server. If sending the success command directly, it cannot be considered a successful transmission behavior.

The default configuration is 1 stop bit and no parity bit. If the customer wishes to change this, they can use the configuration tool for adjustment.

Customers experiencing issues such as receiving all zeros, all FF, or garbled data via the serial port may consider the following:

• Check if the baud rate, stop bits, and parity bits are correctly set.
• Verify if the TX/RX pins of the serial port are connected correctly.
• Ensure proper grounding; check if the GND is connected.
• Use a multimeter to check if there are any short circuits or open circuits in the TX/RX pins of the cable.
• Consider if the cable length is excessively long.

In contrast to simple output mode where scanning the QR code on the scanner automatically retrieves its data, secondary development entails advanced customization for clients seeking more sophisticated functionalities, requiring interface accessibility. Devices supporting this mode are called secondary development-capable. Through calling relevant interfaces, clients can access additional functionalities. We provide SDKs or communication protocols to facilitate secondary development.

Customers utilizing secondary development typically possess strong development capabilities, and the SDK provided by us is straightforward. Issues in this area often arise from difficulties importing the SDK or using the demo correctly. When facing such problems, the following points should be considered:

• Our devices must be configured in secondary development mode using the configuration tool for development. When customers encounter difficulties in secondary development, inquire whether they have configured the device in secondary development mode.
• Understand the customer's environment, whether it's on a PC or Android. If it's on Android, issues may arise from lack of root access or incomplete root access. In such cases, customers can be instructed to grant permissions manually via adb (refer to the previous point).
• PC environments are more complex. First, understand the customer's development package version and system environment, then escalate the issue to the technical department for resolution.

For customers using the Android platform, both our software and hardware decoding devices are supported.

Software and hardware decoding both require rooting the Android board. Software decoding recognizes the device as a camera device, requiring additional permissions on the Android board. If using a serial port device, the Android board itself must have a serial port. Some Android boards lack drivers for USB-to-serial conversion, resulting in inability to use the device. When developing on Android using a serial port device, development can be done directly through the protocol.

Additionally, due to differences in the underlying systems of different Android development boards, some Android boards may not function properly. In such cases, it is best to contact the Android board supplier for resolution. It is advisable to ask the customer to send a sample for testing.

All our devices support secondary development, albeit with differing methods. We can provide clients with SDKs and demos in common programming languages like C/C++/VB/C#/JAVA. Additionally, we offer communication protocols for serial port and Wi-Fi. Note that development support is currently limited to Windows and Android systems, with Bluetooth devices having iOS samples and source code available. Other environments are temporarily unsupported. For serial port devices, development can be done directly through communication protocols. On Android, root access is required, and sometimes manual permission granting may be needed if root access is incomplete. Permissions required for our devices include: CHMOD –R 777/DEV/BUS.