Skip to content

Troubleshooting during development

I'm debugging my application and need more information about an error.

Details

Please see our error codes overview to learn how to search for more information.

Something's wrong in the communication between my app and the reader.

Details

If you use the SDK, you can use its logging mechanism to analyze the communication.

If you're using an FTDI USB to serial converter cable, see the issue Communication interruptions occur when using an FTDI USB to serial converter cable below.

Unidirectional polling via RS-232/UART is no longer working.

Details

Issue
You've probably started BALTECH ID-engine Explorer or another tool of BALTECH ToolSuite while testing the RS-232/UART interface. When these BALTECH tools scan for RS-232/UART ports, the reader switches to BRP, i.e. unidirectional communication is stopped.

Solution
Close all BALTECH tools and do a power-on reset on the reader.

Communication interruptions occur when using an FTDI USB to serial converter cable

Details

Issue
Communication with the reader may be interrupted when transmitting large amounts of data (i.e. BRP frames) via serial interface using a USB to serial converter cable with an FTDI chip such as the following:

As a result, you may get a communication error when using our SDK, or you may experience connection issues with our software tools.

Solution
Reduce the Latency Timer in the FTDI chip to 2 ms. To do so:

  1. In Windows Device Manager, right-click on the USB Serial Port (COMx) entry for the adapter.
  2. Go to Properties > Port Settings > Advanced....
  3. In the Latency Timer dropdown, select 2.

Screenshot: Latency timer set to 2 ms in Windows Device Manager advanced settings of a COM device

For more details about the Latency Timer value, please refer to this FTDI application note.

Reader not detected on Linux (USB virtual COM port)

Details

Issue 1
The reader may not be configured for virtual COM port.

Solution 1
1. Check for this issue: 

lsusb -d 13ad: -v | grep CD
2. If the reader is not yet configured for virtual COM port, do so as described here.

Issue 2
The reader is configured for and connected via USB virtual COM port (CDC), but it's not detected on Linux. No /dev/ttyACM* device file is created.

Solution 2

  1. Check if the reader is recognized by USB: 

    lsusb -d 13ad:
    If nothing is displayed, check the physical connection.

  2. Check if the required kernel module cdc_acm is available. On most standard distributions, you can use the following commands:

    cat /lib/modules/$(uname -r)/modules.builtin | grep cdc_adm.ko # (1)
lsmod | grep cdc_adm # (2)

    1. If this returns a result, the module is built into the kernel.

    2. If this returns a result, the moodule needs to be loaded using sudo modprobe cdc_acm.

    If neither of these commands return a result, the module is missing. Recompile the kernel with the module enabled.

  3. Check kernel messages for errors: 

    dmesg | grep ttyACM

  4. If the device file exists but you can't access it, verify that the udev rules are correctly set up.

Reader not detected on Linux (USB HID)

Details

Issue The reader is connected via USB HID, but it's not detected on Linux. No /dev/hidraw* device file is created.

Solution

  1. Check if the reader is recognized by USB: 

    lsusb | grep 13ad
    If nothing is displayed, check the physical connection.

  2. Check if the required kernel module usbhid and the config option hidraw are available. On most standard distributions, you can use the following command:

    cat /lib/modules/$(uname -r)/modules.builtin | grep -i 'CONFIG_HIDRAW=\|CONFIG_HID=

    If this doesn't return a result, the module is missing. Recompile the kernel with the module and config option enabled.

  3. Check kernel messages for errors: 

    dmesg | grep hidraw

  4. If the device file exists but you can't access it, verify that the udev rules are correctly set up.

Ethernet readers can no longer be found via SLP after a few minutes

Details

Issue
This may happen if the routers/switches have IGMP snooping enabled, but there's no IGMP querier in the network.

Routers/switches use IGMP snooping to forward multicast SLP requests from the host to the readers. For this to work, an IGMP querier is needed: It sends periodic requests into the network that cause the host to regularly renew its membership in the relevant multicast group. If there's no IGMP querier and thus no renewed membership, the routers/switches will stop forwarding the host's multicasts to the readers after a timeout. Thus, the readers won't respond to SLP requests anymore.

Solution
There are 2 ways to solve this issue:

  • Disable IGMP snooping on the routers/switches. Look for an option containing the key word(s) IGMP, IGMP Snooping, or Multicast. For details, please check the operation manual.

  • Set up an IGMP querier in your network. For details, please check the operation manual for your routers/switches.

Title