Skip to content

Low-level commands

Use Case

Beyond the standard read and write operations, you want to perform card-type-specific operations, e.g. increment or decrement counters.

Implementation overview

What are low-level commands?

Low-level commands are designed for a specific card type. They let you make use of the full feature scope of your project cards. While they're powerful, they also come with certain drawbacks you should be aware of:

  • High development effort: Even for simple operations, you need to run a series of commands, which increases complexity.
  • Potential performance loss: This is the case for certain card types and especially if the host protocol is slow. Performance loss is due to the large number of commands per operation, the time to wait for the each response, and the fact that large data volumes must be transmitted in several batches.
  • Card-type-specific implementation: Your application won't work with a different card type.
  • Custom retry mechanisms and error handling: In contrast to our card-type-independent command group VHL, you need to take care of this yourself, especially with regard to potential connection loss due to particularities of the reader's operating volume.

  • Extensive knowledge of card type required: We assume you are familiar with the specification for the relevant card type.

    We cannot provide card-type-specific support.

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.

  • The reader acts as a pass-through and doesn't intervene in the communication with the card: It directly forwards your commands to the card and all card responses back to the host.
  • Control reader feedback (e.g. LED and beeper) and other hardware functionality directly via the host.
Diagram showing a host application sending low-level commands to a project card via a BALTECH reader

Exceptional cases requiring a configuration

In the vast majority of cases, you won't need to configure the reader. You only need to create a configuration if one or both of the following applies:

  • Your host protocol isn't enabled in the factory settings.

  • You want to control access permissions and set up authenticated and encrypted communication. In this case, you need to configure Authentication and Encryption.

    Details
    • For non-Ethernet readers, use AES.
    • For Ethernet readers, use PKI.

Requirements

Firmware

If you want to use a different firmware, please get in touch.

Supported interfaces

  • USB HID (recommended with the SDK)
  • USB virtual COM port (recommended when not using the SDK, required for RDP)
  • RS-232/UART
  • Ethernet (host as client only)

Alternatives

Use APDU via VHL if you want to interact with ISO 14443-4 cards.

Your workflow

Set up SDK

The easiest way to send low-level commands via BRP is the BALTECH SDK, available for Windows, macOS, and Linux.

My platform's not supported

If you can't use the SDK, you can create the BRP command frames yourself. Please refer to the BRP specification and example frames.

To set up the SDK:

  1. Download 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

Reader hardware control

There are various commands to control the reader hardware. You can e.g. 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. You can now install the readers (and, if necessary, deploy the configuration) as described here.

Troubleshooting & support

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

Title