Wiegand specification

Wiegandcall_made is a de-facto standard for read-only connections between a card reader and an access control system. This page describes how we've implemented Wiegand in our firmware.

Interface overview

The interface basically consists of 2 types of wires:

  • Data wires
    They are used to transmit messages such as card numbers, PIN/keypad entries, and tamper alarm.
  • I/O wires
    They are steered by the controller and used to control LEDs and other hardware components.

Below, you'll find a description of their default configuration. If you need configuration changes, you'll need to order a custom configuration in most cases. For values that you can change yourself via the device settings form in BALTECH ConfigEditor, the corresponding option is indicated.

Data wires

There are 2 data wires for the transmission of data read from the card:

  • WGND_D0 for "0" bits
  • WGND_D1 for of "1" bits

In idle state, both wires are held high. During data transmission, asynchronous low pulses are generated, 1 pulse for each bit on the corresponding data line. Such pulses do not overlap nor do they occur simultaneously.

Time spans

Pulse Width Time (PWT)

This is the duration of a low pulse.

Pulse Interval Time (PIT)

This is the pause between 2 low pulses.

The time spans are indicated in the following example diagram for the bit sequence 0-1-0:

Diagram showing the pulses and time spans on Wiegand data wires of a BALTECH reader for the bit sequence 0-1-0

Message length

This is the number of bits per message. The message length you need depends on the frame format:

For standard Wiegand frames with 2 parity bits, the message length is calculated as follows:
(payload length [in bytes] * 8 [bits]) + 2 parity bits
Thus, a typical message lengths is 34 bits (for 4-byte card numbers). The device settings form in BALTECH ConfigEditor supports up to 58 bits (for 7-byte card numbers).

For raw binary frames without parity bits, this value can be set to any bit length. However, don't expect such frames to be supported by all controllers.

  • Configuration Value: MessageLengthcall_made
    This value corresponds to the BitLength option in the device settings form of BALTECH ConfigEditor.

  • Default: 255 (0xFF); this means that the message length depends on the length of the data returned by the Autoread functionality.

Frame format

A standard Wiegand frame consists of several bytes of data which come along with 2 parity bits. The first parity bit (P1) is even parity, calculated over the first half of the data and sent as the first bit of the frame. The second parity bit (P2) is odd parity, calculated over the second half of the data and sent as the last bit of the frame. In between the parity bits, the data itself is transmitted. This structure is illustrated below for a frame with a message length of 34 bits:

Diagram showing the pulses and time spans on Wiegand data wires of a BALTECH reader for the bit sequence 0-1-0

To support custom frame formats, this value can be set to Raw. The data will then be sent without parity bits.

Bit order

Host message format

The reader converts data read from the card to ASCII decimal and from there into the format expected by the host (learn more).

This value is automatically set to binary when Wiegand device settings are deployed. Note that ACCESS200 readers are shipped with Wiegand device settings by default.


Some readers are equipped with a keypad for PIN entries. Key entries are also transmitted via the Wiegand interface, but the output format differs from the format described in chapter Frame format.

  • Configuration value: PinMessageFormatcall_made

  • Default:

    When you keep the factory device settings, this value is set to SingleDigit4Bit (0x04). This means that a single raw Wiegand 4-bit message is sent every time the user has pressed a key. The 4 bits are encoded according to the following table:

    key 4-bit encoding
    0 0000
    1 0001
    2 0010
    3 0011
    4 0100
    5 0101
    6 0110
    7 0111
    8 1000
    9 1001
    * 1010
    # 1011
    F1 1111
    F2 1111

    When you create your own device settings using the form in BALTECH ConfigEditor, this value will be set to SingleDigitWithSwappedBcc (0x03). This means that the format will be changed to an 8-bit message: The lower 4 bits represent the key code, the upper 4 bits represent the bit-inverted value.
    Example: Key 2 is represented as 11010010.

It's also possible to delay the output to the host until an n-digit PIN has been entered completely. If you want to implement this, please order a custom configuration.

I/O wires

Readers have 2 I/O ports Input_0 and Input_1 via which the host can control reader LEDs and other hardware components.

For a list of all I/O ports and associated pins in ACCESS200 readers, please see the hardware specification.

Default behavior

In idle state, Input_0 is held high. The red LED is on. If the host sets Input_0 to low, this causes the reader to emit the following default feedback:

  • Beeper beeps for 300 ms.
  • The LED switches to green until the host switches back to high.

Input_1 is unused in default configuration. You can use it if you want to configure custom patterns for LEDs, beeper, or relay.

Diagram showing the default Wiegand input pulses of a BALTECH reader when a valid card has been detected

Custom patterns

You can implement custom feedback patterns using the device settings form of BALTECH ConfigEditor. Here, you can leverage both i/o ports and define individual LED and beeper patterns for when a port is set and cleared (learn more).

Screenshot: Define LED/beeper patterns for i/o events in BALTECH ConfigEditor

In addition, certain reader variants can be configured to switch the door relay. If you want to implement this, please order a custom configuration.

Tamper and heartbeat

ACCESS200 readers support a tamper detection. By default, this sensor is not activated. If required, the reader can be configured to enable the sensor and send a Wiegand message every time the sensor is triggered. It's also possible for the reader to send periodic heartbeat messages, i.e. static messages to indicate that the reader is still alive.

If you want to implement tamper detection and/or heartbeat messages, please order a custom configuration.