The 12-Bit Card That Shows Three Different Numbers
Sunrise Senior Secondary School is merging two attendance systems before board practicals. The old RFID reader prints each card as a fixed 12-bit pattern; one card reads 1011 0110 1001. The vendor's manual says the reader supports three display modes: unsigned binary, packed BCD (three decimal digits), and 12-bit two's complement for a temperature sensor add-on. The school's database currently stores roll numbers 001 to 999 as text and also keeps a staff flag. A new fee counter needs to store a balance that can be negative, down to about -800 rupees. The computer teacher must choose one encoding for the card payload and one for the fee balance, and must explain to the principal why the same 12 bits can show three different decimal values. A clerk has already typed the card pattern into a spreadsheet as decimal 2921 and printed labels; those labels are now stuck on 40 cards.
1. Interpret 1011 0110 1001 in each of the three modes. Show the place-value or grouping work, and state which mode produced the clerk's value 2921.
Read the worked answer
Treat the 12 bits as three nibbles: 1011 0110 1001 = B69 in hexadecimal.
- Unsigned: 1×2048 + 0×1024 + 1×512 + 1×256 + 0×128 + 1×64 + 1×32 + 0×16 + 1×8 + 0×4 + 0×2 + 1×1 = 2921. This matches the clerk's label, so the spreadsheet used unsigned mode.
- Packed BCD: split as 1011 | 0110 | 1001. The nibbles 0110 and 1001 are valid digits 6 and 9, but 1011 is 11, which is not a decimal digit. A BCD reader should flag the pattern as invalid; it must not be 'decoded' as 11 6 9.
- 12-bit two's complement: the leading 1 means negative. Value = 2921 − 4096 = −1175, which lies inside the range −2048 to +2047.
The reasoning point is that a bit pattern has no intrinsic meaning; the interpretation rule does. Since 2921 > 999, the clerk's label cannot be a valid roll number, and the card should be treated as an opaque identifier rather than a number to do arithmetic on.
2. The fee counter must store balances from −800 to +800, and roll numbers 001–999 with a staff flag. For each requirement, state a suitable encoding and justify the bit width. Explain why packed BCD is a poor choice for the card payload even though it represents decimal digits neatly.
Read the worked answer
For roll numbers 001–999 plus a staff flag: 10 bits represent 0–1023, enough for 999 values, and one extra bit carries the flag, so 11 bits suffice; 12 bits is convenient but wastes code space. Packed BCD uses 4 bits per decimal digit = 12 bits for exactly three digits 000–999, but it has no sign and only 1000 of the 4096 codes are valid, so about 75% of patterns are errors.
For balances −800 to +800: 11-bit two's complement gives −1024 to +1023, so 11 bits suffice; 12-bit two's complement also works and matches the card width if a common format is wanted. BCD cannot represent the negative balance without a separate sign nibble, so it is a poor fit.
The deeper design point: the card payload should ideally not encode the roll number at all. Use an opaque UID plus a database lookup. That removes the ambiguity and lets the school change roll-number formats without reissuing every card.
3. The clerk's labels show 2921 for every card pattern beginning with 1. What risk does this create when 40 cards are scanned at the gate, and what single check would catch the error?
Read the worked answer
Any pattern whose first bit is 1 gives an unsigned value of at least 2048, so if the clerk's rule is applied to all cards, many labels will be four-digit numbers that cannot be valid roll numbers. Scanners that compare against 001–999 will either reject the card or, worse, truncate and match the wrong student. With 40 cards already labelled, the risk is mis-attendance and duplicate identification at the gate.
The single check is: after reading, validate that the decoded value is in 0–999 and that the card's issuing scheme is known. A stronger check is a database lookup of the full 12-bit UID, plus a parity or checksum bit if the reader supports one. Never infer the encoding from the first digit.