Autoread with bidirectional communication via BRP

Use case

  • You want to read a number from the card.
    (For all other read operations, use VHL.)
  • You want to control reader feedback (e.g. LED and beeper) via the host.
  • You want to update the firmware or configuration via the host.
  • You don't mind retrieving read results from the reader (this is not time critical).

Implementation overview

What is Autoread?

The reader scans for cards and reads them autonomously (learn more).

How it works

This implementation is based on BALTECH Reader Protocol (BRP). To keep your effort low, we provide an SDK for the most common platforms.

  • Configure the reader for your cards type(s). You can use our GUI tools BALTECH ToolSuite to conveniently create and deploy the configuration (including wireless deployment options).
  • The reader autonomously polls for cards and reads them.
  • Once it has read a card, the reader buffers the read result in an internal queue for 5 seconds, so the host can retrieve it. (If the host is implemented as an Ethernet server, this step requires the reader to open a connection first.)
  • Define reader feedback (e.g. LED and beeper) as part of the reader configuration. Alternatively, control the feedback (and other hardware functionality) directly via the host.
Diagram showing a BALTECH reader in Autoread mode with bidirectional communication for USB, RS-232, and Ethernet client connections
Diagram showing a BALTECH reader in Autoread mode with bidirectional communication for Ethernet server connections

Supported interfaces

  • USB HID (recommended with the SDK)
  • USB virtual COM port (recommended when not using the SDK, required for RDP)
  • RS-232
  • Ethernet (client and server)


Use Autoread unidirectional if:

  • You can't use the SDK.
  • You don't want to actively retrieve read results.

Your workflow

Configure the reader

To prepare readers for access from your application, create a configuration for the readers. Alternatively, you can order a configuration from us.

Required equipment

  • A Windows computer with BALTECH ToolSuitecall_made installed
  • A test reader you can connect to your computer.
    If the productive reader type doesn't provide a USB connection, we recommend you use an ID-engine ZB to create and test the configuration.
  1. Create a configuration file.

    If you work with the SDK, you can also use one of the demo configurations in the app notes as a template. To do so, derive and edit a copy of it.

  2. Add device settings to enable the host protocol and (as an option) define reader feedback (e.g. LED and beeper).

    You can also define feedback in your application with the UI command groupcall_made.

  3. To set up an encrypted channel, add security settings (for more details, see our encryption overview).

  4. Transfer your draft configuration to the test reader to later test your application.

  5. Ethernet only: If you want to assign a static IP address, create a separate IP configuration. Otherwise, readers will obtain an IP address dynamically via DHCP.

Set up SDK

The easiest way to use BRP is the BALTECH SDK, available for Windows, macOS, and Linux.

Alternative for unsupported platforms

If you can't use the SDK, you can create the BRP command frames yourself. Please refer to the BRP specification and example frames. You may also want to look into implementing unidirectional communication instead, as it's usually quicker to implement.

To set up the SDK:

  1. Downloadcall_made the SDK from our website.
  2. Get familiar with its components. We recommend you get started by trying out the app notes.
  3. Integrate the SDK into your application.
  4. Set up a protocol stack to be able to run commands.

Run commands

Card interaction

Polling stops working during your tests?

Then Autoread may have been disabled automatically. This happens when you run a VHL or low-level command, but also when you start BALTECH ID-engine Explorer (as it uses VHL internally). So if you stop receiving read results in your application, please close ID-engine Explorer. Then perform a power-on reset on the reader or run the AR.SetModecall_made command again.

For more tips on troubleshooting, please have a look at our troubleshooting guide.

Reader hardware control

There are various commands to control the reader hardware. You can control reader feedback (e.g. LED and beeper), reboot the reader, check its firmware version, etc.

What's next?

That's it for the development part. The next step is to create project settings with card-specific information and integrate the readers with your application. For the full workflow, please refer to this step-by-step guide.

Is this done by someone else?

Then please hand them your configuration. Make sure you finalize the configuration first.

Troubleshooting & support

Got stuck somewhere along the way? Don't worry, we'll help you troubleshoot: