How do I determine whether my gate controller accepts 26-bit, 34-bit, 37-bit, or another credential format?
Determine the supported credential format by checking the controller’s exact model, manual, firmware, and card-format settings. Confirm the total bit length, facility-code field, card-number field, and parity layout. When documentation is unclear, present a known credential and inspect the controller’s raw event data rather than assuming that every Wiegand input accepts every format.
Identify the Exact Controller and Software Version
Start with the access controller or telephone entry system, not the proximity reader. Record the controller manufacturer, complete model number, circuit-board revision, firmware version, and management-software version. Controllers within the same product family may support different credential formats because of board-generation or firmware differences.
Look for the reader-port specifications in the installation or programming manual. Some controllers accept only a fixed group of formats, such as 26-bit and a few manufacturer-specific alternatives. Others include a format library or allow custom Wiegand definitions. A statement that the controller has a “Wiegand input” confirms the electrical interface only; it does not prove that every bit length or data layout can be decoded.
Check the Card-Format Menu in the Controller Software
Open the controller’s reader, credential, token, or card-format configuration screen. Depending on the system, formats may be listed globally, assigned to a specific reader, or activated for an individual door or gate. Record every enabled format before changing any settings.
A controller with fixed-format support may display choices such as standard 26-bit, 34-bit, or one or more 37-bit formats. A more flexible controller may ask for the total bit length, facility-code offset and length, card-number offset and length, parity locations, parity type, and bit or byte order. Some systems accept raw card numbers without separating a facility code, while others require a facility code to match before the credential can be enrolled.
Bit Length Does Not Fully Define the Format
Two credentials can both be 37 bits long and still use different internal layouts. One 37-bit format may devote most of the data to a card number, while another divides the data into facility-code and card-number fields. The same caution applies to 34-bit and other nonstandard formats. Matching only the total number of bits can produce the wrong displayed number or reject a valid credential.
Review Existing Credential Records
Check the original card or key-fob order, box label, credential programming sheet, access-control database, and previous invoices. Useful information includes the credential technology, format name, total bit length, facility or site code, card-number range, and any custom format or organization code.
The number printed on the card is not always the complete electronic value. It may represent only the card-number field, a sales-order number, or an external sequential number. Do not assume that a five-digit printed number means standard 26-bit. The facility code, parity bits, and other data may not be printed at all.
Use a Known Working Credential as a Test
Present a credential that currently opens the gate and inspect the controller’s event log, enrollment screen, diagnostic page, or raw-card-data display. Record the reported bit count, facility code, card number, hexadecimal value, and any “unknown format” or “invalid facility” message.
If the controller reports the correct bit count but shows an unknown credential, the format may already be decoded correctly and the card may simply be unenrolled. If it reports an unsupported length, format error, or a number that does not match the system records, the correct layout may not be enabled. Test several known cards from the same credential batch to confirm consistent results.
Some systems show only a combined decimal number instead of separate facility and card fields. Others remove parity bits before displaying the value. Preserve screenshots and export logs before changing format definitions so the original behavior can be restored.
Separate Reader Capability From Controller Capability
The reader must first detect the credential technology and transmit the credential data. The controller then interprets that data. A reader may support credentials up to a long bit length while the controller accepts only selected formats. Conversely, a controller may support custom formats but receive no usable data because the reader is configured for a different credential family or output mode.
A beep or LED change at the reader confirms that the credential was detected. It does not prove that the controller received the complete bit stream, recognized the format, matched the facility code, or located an enrolled card number.
Watch for Truncation, Bit Order, and Facility-Code Filtering
Older controllers may ignore excess bits, truncate a longer credential, or interpret only part of the data. A truncated card can display a repeatable number while creating duplicate-number risk. Other systems may reverse bit order or byte order, making the displayed number different from the printed credential record.
Facility-code filtering can also create confusion. A controller may understand the 26-bit layout but reject the card because the configured facility code does not match. Another controller may combine the facility code and card number into one value for enrollment. Verify how the specific system stores and compares credentials before ordering additional cards.
Technician’s Corner
Technical Field Note: “Wiegand compatible” describes the electrical signaling method, not the credential format library. Always verify both the reader interface and the controller’s decoding capability.
Technical Field Note: Do not enable several guessed formats at once without checking for overlapping interpretations. The same raw credential can sometimes be decoded into different card numbers under different format rules.
Technical Field Note: A credential that works at one entrance but fails at another may indicate different reader-port format settings, firmware, or controller generations rather than a defective card.
Technical Field Note: South Florida lightning, moisture, corrosion, and long pedestal wiring can distort Wiegand pulses. Inspect voltage, grounding, shielding, splices, and surge protection when the reported bit length changes between card presentations.
Before You Add or Replace Credentials
- Record the controller model, board revision, firmware, and software version.
- List every enabled fixed or custom card format.
- Confirm total bit length, facility-code field, card-number field, and parity rules.
- Compare controller logs with the original credential order and card range.
- Test several known credentials and confirm consistent displayed values.
- Verify that the reader outputs the required technology and data format.
Related Technical Categories
- Gate Access Controllers
- Proximity Card Readers
- Access Control Cards and Key Fobs
- Wiegand Card Readers
- OSDP Card Readers
- Telephone Entry Systems
Before selecting credentials or replacement hardware, verify the controller model, firmware, supported bit lengths, format layout, facility code, card-number range, parity, reader protocol, credential technology, voltage, connector or terminal type, and system generation. When documentation is incomplete, capture raw data from known cards before making a format decision.