SAFR SCAN provide debug logs to help in troubleshooting issues. This is particularly useful when troubleshooting issues with access cards such as working on card format. This artcle includes explanation of the different log records which should help in interpreting access card read logging. It also explains some of the behavior of SAFR when reading cards and transmitting the credentials to a panel.
Below are example logs of a card only transaction with 2 card formats defined (one custom 26 bit that would not match the card and other is standard Wiegand-26 that does match the card in use).
Log with incorrect 26 bit Custom Format in position 1
This case fails because we get a number based on the custom format but does not match any credentials in local stored identities.
2025-Feb-26 15:52:38.029232: INFO/accessCredential(547610234128): processPcscCardread(): cardFormatData.format=Custom, cardFormatData.layout=AFFFFFNNNNNNNNNNNNNNNNNNNA, cardFormatData.parity=, cardFormatData.byteOrder=normal
ATR[20]:3b 8f 80 01 80 4f 0c a0 00 00 03 06 40 00 00 00 00 00 00 28
UID[4]:0f 93 58 c0
PACS[4]:0f 93 58 c0
PACS padding_bits: 6Reports that we used the custom format (and shows the format AFFFFFNNNNNNNNNNNNNNNNNNNA).
PACS line is the hex value of the data we read.
2025-Feb-26 15:52:38.029719: INFO/accessCredential(547610234128): processPcscCardread(): Received Custom: FacilityCode=3, CardID=468657,
Decimal numbers we got using the provided card format.
2025-Feb-26 15:52:38.031449: INFO/accessControl(547610234128): Access Denied: The scanned card is not recognized
Log with Wiegand 26 in position 1
This case succeeds. The card number is successfully read from the card and matched to an existing identity.
2025-Feb-26 15:55:17.445756: INFO/accessCredential(547610234128): processPcscCardread(): cardFormatData.format=Wiegand-26, cardFormatData.layout=, cardFormatData.parity=, cardFormatData.byteOrder=normal
ATR[20]:3b 8f 80 01 80 4f 0c a0 00 00 03 06 40 00 00 00 00 00 00 28
UID[4]:0f 93 58 c0
PACS[4]:0f 93 58 c0
PACS padding_bits: 6Card read. PACS line shows the hex value we got. cardFormatData reports the card format that was used.
We use this card format to convert the binary data to decimal card# and facility in order to match person record.
Note: If set to "Pass thru mode" and performing single-factor card read, we don't try to convert / don't need card format. We just send what we got on the card in binary format.
But for face only or dual factor modes, we need to convert the card data to decimal so we can compare to person record and find the face.
2025-Feb-26 15:55:17.446037: INFO/accessCredential(547610234128): processPcscCardread(): Received Wiegand-26: FacilityCode=31, CardID=9905,
Reports the card id and facility we got from above card read.
2025-Feb-26 15:55:17.446554: INFO/accessCredential(547610234128): Use credentialData.accessCardRawBytes for cardDataOut. CardDataOut[4]:0f 93 58 c0 Padding_bits: 6
Reports what we send over the wire.
When reading from card, what we transmit is exactly the binary value we read from the card.
Note: If face only we get card# and facility from person record and use the card format in position 1 of the card formats list.
2025-Feb-26 15:55:17.446766: INFO/accessCredential(547610234128): sendCardDataOut(): Sending out 26 bits of Wiegand-26 card data to wiegand-out...OK
Confirm that we sent data via Wiegand.
If OSDP was also enabled, we would have reported that also.
If neither Wiegand or osdp is enabled, we report "No outputs (OSDP-PD, Wiegand, RIO, etc) are enabled so no card data will be sent out."
2025-Feb-26 15:55:17.482547: INFO/accessControl(547166848656): 23:55:17.427: Global State Change: previousState=idle; currentState=detectedAccessGranted
And this reports what we showed to user. If panel feedback was enabled, we would wait for panel to respond before deciding to show granted or denied.