Skip to content

Troubleshooting during development

The following list helps you troubleshoot typical issues that come up when developing a custom application.

If you come across a hardware issue and want to return a reader, please use our RMA form.

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


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.


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.


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.

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


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.

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.

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


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.

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.