RFID Systems | Tags, Readers, RS232, UID, Access Control and Security

Comprehensive RFID systems notes covering tags, readers, antennas, RF coupling, LF/HF/UHF, UID handling, RS232, anti-collision, middleware, databases and security, grounded in my 2014 AKU IT access-control internship.

During my 2014 internship at the Afyon Kocatepe University IT Department, I worked directly with RFID readers, serial communications, and access-control systems. Following the full path from an RF read and UID representation to database authorization and a physical door-control decision made the software-hardware boundary concrete in everyday debugging.

RFID was not merely “reading a card over radio” for me during that internship. I was tracing how raw data from a physical reader moved through an electrical interface, serial communication, parsing, UID representation, database lookup, authorization logic, the user interface, and ultimately a physical door-control action. I was still studying Computer Engineering at the time, and this internship was one of the first institutional projects where the boundary between software and a physical system became explicit in daily debugging.

I worked with multiple readers including Promag MF7-20, PCR310, and Verifone QX1000; investigated RS232 wiring and MAX232 level conversion; analyzed serial parameters, STX/ETX framing, UID byte order, request-response behavior, and database integration. In one case, after repeatedly checking software, port configuration, circuits, and different computers, replacing the reader finally produced the correct data. That experience gave me a rule that later became even more important in critical systems: a layer should not be assumed correct until it has been independently verified.

These notes therefore treat RFID not as a peripheral composed of a card and reader, but as an end-to-end engineering chain spanning the RF physical layer, protocol, device/host interface, event processing, data model, security, and physical action.

Unit 1: RFID from a systems-engineering perspective

What is RFID?

Radio-Frequency Identification is a family of technologies for automatically identifying a card, tag, or physical object through radio-frequency communication. In a basic interaction, a reader creates an RF field or transmits a query, and a tag responds according to its technology and protocol with an identifier or stored data.

The difference from a barcode is not simply that RFID is wireless. Depending on the system, RFID can:

work without direct line of sight,
identify multiple tags in the same field,
support writable tag memory,
automate identification events,
maintain a machine-readable relationship between a physical asset and a digital record.

The trade-off is a new set of problems: RF propagation, collision, unintended reads, privacy, cloning, reader placement, and protocol interoperability.

Is RFID an identity system?

RFID is often an input to an identity system, not the entire identity and authorization system.

These statements are not equivalent:

card UID = 04A1B2C3

and

this card belongs to this user and is currently authorized to open this door

The second statement requires card state, assignment, subject identity, permissions, time constraints, and—where required—additional authentication.

The automatic-identification chain

A useful end-to-end model is:

physical tag
→ RF link
→ reader
→ device protocol
→ host interface
→ parsing / normalization
→ application logic
→ database
→ decision
→ log / alert / physical action

A large part of my internship work lived in the middle of this chain: obtaining reader data reliably, converting the UID into the correct representation, relating it to database state, and turning the result into an application or physical-control decision.

Unit 2: Core components of an RFID system

Reader

A reader is not just a device that “returns a card number.” On the RF side it communicates with tags; on the application side it transfers data to a computer or controller.

Depending on the protocol and product, a reader may:

create the RF field,
interrogate tags,
perform anti-collision/arbitration,
read or write memory regions,
perform error checking,
report timing/antenna metadata,
connect over serial, USB, Ethernet, or another host interface.

The boundary I worked on most directly in 2014 was the reader-to-computer interface. The RF transaction was generally handled inside the reader; the software problem was understanding the host-side data framing and device behavior.

Antenna

The antenna controls how RF energy is radiated and received. Gain, directivity, polarization, mounting, and surrounding materials can change the read zone substantially.

A compatible reader does not guarantee a successful deployment. The same reader can behave very differently when the antenna geometry, orientation, cable loss, or surrounding metal changes.

Back end and middleware

Enterprise RFID systems commonly place processing between readers and business tables:

device adapters,
event collection,
duplicate filtering,
validation,
authorization,
logging,
database access.

This layer matters because a tag can be observed repeatedly while it remains in the RF field. Treating every RF observation as a separate business event can corrupt access or inventory data.

Unit 3: Active, passive, and semi-passive tags

Passive tags

A passive tag has no continuously available internal power source. It harvests operating energy from the reader field and communicates within that limited energy budget.

Consequences include:

potentially low cost and small form factor,
no battery-maintenance cycle,
constrained computation and memory,
read range and reliability that are sensitive to the RF environment.

Active tags

An active tag has its own energy source. That can support greater range, periodic transmission, additional processing, or sensors. Battery lifetime, maintenance, size, and cost then become system requirements.

Semi-passive tags

Semi-passive designs can use a battery for internal circuitry while still relying on energy from the reader for parts of the communication process. Vendor terminology varies, so the engineering question should be the actual power and communication model, not only the marketing category.

Tag selection is a system decision

Selection should follow requirements such as:

read distance,
data capacity,
object speed,
proximity to metal or liquid,
temperature/humidity,
battery lifetime,
unit cost,
security,
write frequency.

The tag with the longest range is not automatically the best tag.

Unit 4: Frequency bands and electromagnetic coupling

LF, HF, and UHF

RFID systems operate in several frequency families. Common examples include:

LF around 125/134 kHz,
HF at 13.56 MHz,
UHF in the regional 860-960 MHz family,
microwave bands for some specialized systems.

The allowed channels and power limits depend on region and current regulation. Frequency affects antenna size, coupling, propagation, data rate, environmental sensitivity, and achievable range.

Inductive coupling

In LF/HF near-field systems, magnetic coupling between reader and tag coils can dominate. A passive tag can harvest energy from this field and return data through techniques such as load modulation.

Practical behavior depends on:

coil geometry,
resonance,
quality factor,
tag orientation,
nearby metal.

Backscatter

In UHF passive RFID, a tag can harvest energy from the reader's RF field and encode information by changing the reflection characteristics of its antenna. The reader observes the resulting backscattered signal.

This can enable longer read distances but makes link budget, orientation, multipath propagation, shadowing, and regional RF constraints more important.

Read range is not a constant

A catalogue value is not a field guarantee. Real range depends on:

reader transmit power,
antenna gain,
cable loss,
tag antenna efficiency,
orientation,
nearby metal/liquid,
interference/noise,
regulatory power limits.

Field validation is therefore part of engineering, not a final acceptance detail.

Unit 5: Standards and interoperability

ISO/IEC 14443 and proximity cards

The ISO/IEC 14443 family is a major reference for 13.56 MHz proximity cards and contactless smart-card systems. Different parts of the family address physical properties, RF interface, and protocol behavior.

An application developer must still distinguish the air interface from the reader's host interface. A reader can terminate ISO/IEC 14443 internally and expose only a UID or processed fields over serial/USB.

ISO/IEC 15693

The ISO/IEC 15693 family covers contactless vicinity objects/cards. “Proximity” and “vicinity” represent different interface/use models, not merely alternative marketing terms.

ISO/IEC 18000 and UHF RFID

The ISO/IEC 18000 family defines RFID air interfaces for item management. UHF Type C systems are covered by ISO/IEC 18000-63.

The historical and current contexts should not be conflated. The standards available in 2014 were not identical to those in the current revision. As of 2026, ISO/IEC 18000-63:2021 is the published edition and a new edition is in the publication process.

GS1 EPC Gen2

GS1 EPC Gen2 is a major UHF air-interface protocol family for supply-chain and object-identification applications. The current GS1 Gen2 release in 2026 is 3.0.1; that should not be projected backward into a 2014 implementation.

What standard compatibility does not guarantee

Supporting the same RFID standard does not guarantee:

identical UID formatting,
the same host protocol,
the same security policy,
the same driver/API behavior.

The differences I encountered among several readers during the internship were practical examples of this separation.

Unit 6: UID, byte order, and representation

A UID is a byte sequence

RFID identifiers are often rendered as hexadecimal text in user interfaces. At protocol level, however, the value is a sequence of bytes.

For example:

F2 3A CB D2

may be displayed as:

F23ACBD2

In one of the systems I worked with, the reader produced F23ACBD2 while the database stored the corresponding value as D2CB3AF2. The problem was not “the wrong card”; it was a representation/byte-order boundary.

Protocol order is not automatically CPU endianness

These are separate concepts:

byte order on the wire,
device display convention,
integer conversion in software,
canonical database representation.

The system should document exactly where a conversion occurs.

UID length must not be generalized

Some readers in my 2014 work exposed a four-byte value as eight hexadecimal characters. That was a device/application contract, not a universal RFID rule.

I kept that distinction explicit in the later keyboard-wedge/HID RFID reader note.

Canonical representation

A clean application boundary can normalize input as:

raw bytes -> validation -> canonical uppercase hex -> database comparison

Presentation can add separators, but persistence and equality should not depend on UI formatting.

Unit 7: RS232 and reader-host communication

Separate the RF and host boundaries

An RFID reader has two different communication boundaries:

card <-> reader : RF protocol
reader <-> computer : host protocol

The host side may be RS232, RS485, USB, Ethernet, keyboard-wedge/HID, or a vendor SDK.

Most of my 2014 integration work was at this second boundary.

Serial parameters

A serial connection requires agreement on:

baud rate,
data bits,
parity,
stop bits,
flow control.

A mismatch can result in no input or apparently random bytes.

MAX232 and electrical levels

Microcontroller UART logic levels are not the same as classical RS232 electrical levels. A level translator such as MAX232 can provide the physical conversion.

This is an important software-debugging distinction: successfully opening a COM port says nothing about whether the electrical interface is correct.

Framing

Some readers use control bytes such as STX/ETX:

STX | payload | ETX

A serial DataReceived callback must not be treated as a packet boundary. A frame can be split across callbacks or multiple frames can arrive together.

A robust implementation uses an accumulator/parser or state machine.

Inspect the raw stream first

During the internship I often verified raw serial traffic before building higher layers. The terminal answers the first diagnostic question:

What does the device actually send?

My Serial-Port Monitoring and Control Software grew out of this need.

Unit 8: Real reader integration during the AKU IT internship

Promag MF7-20

One of the early tasks was obtaining and interpreting the RS232 output of a Promag MF7-20 reader. Power, TX/RX paths, port parameters, and the raw frame all had to be checked together.

When the expected UID could not be obtained, I tested software, configuration, circuits, and different computers. Replacing the reader finally produced correct data.

The lasting lesson was not simply that one reader was faulty:

changing upper-layer software repeatedly before validating lower layers increases uncertainty instead of reducing it.

PCR310

For PCR310 I studied the behavior of an existing sample application and reconstructed the request-response flow in C#. The sequence involved opening the port, issuing a request, receiving anti-collision results, and converting the UID into the representation expected by the application.

The engineering task was understanding the device protocol, not merely translating Visual Basic syntax into C#.

Verifone QX1000

With Verifone QX1000, the expected wiring did not produce communication. I used a multimeter to determine the actual cable connections and then parsed the output produced by the device's command-line tool from C#.

This was another practical reminder that a documented or assumed physical layer should still be verified on the actual hardware.

Separate device-specific and device-independent code

The readers behaved differently while the business need remained the same: identify a tag.

A cleaner architecture is:

DeviceAdapter
   ↓
NormalizedTagRead
   ↓
AccessControl / Business Logic

Business logic should not need to know serial commands, vendor framing, or device-specific byte order.

Unit 9: Multiple tags, anti-collision, and event modeling

More than one tag in the field

When several tags respond in the same reader field, the RF protocol needs a collision-arbitration mechanism. Modern RFID families use anti-collision procedures to identify tags individually.

Application-level duplicate events are a different problem.

Why does the same UID repeat?

A card held in the read zone can generate repeated observations:

04A1B2C3
04A1B2C3
04A1B2C3
...

Treating all of them as separate access events can be wrong.

Depending on the application, the software may need:

debounce,
minimum repeat interval,
card-present/card-removed state,
reader-zone-based deduplication.

Event context

A useful observation record can include:

readerId
antennaId
uid
timestamp
rawFrame
quality/rssi (when available)
device/protocol status

This preserves the difference between identity and observation context.

Ordering

In networked deployments, device timestamp and server-receive timestamp can differ. If ordering is operationally significant, the source and trust model of time must be explicit.

Unit 10: Middleware, database, and authorization

UID is not the user

A maintainable data model separates tag identity from the person or asset:

Tag(uid, status, type, ...)
    ↓
TagAssignment(tagId, subjectId, validFrom, validTo, ...)
    ↓
Person / Asset
    ↓
Permission

A lost card can then be revoked without deleting the person.

Database-manager work

My Access-Control Database Manager during the internship moved the project beyond displaying reader data and into persistent identity/authorization management.

Typical domain entities include:

tag/card,
user or asset,
reader,
door/zone,
permission,
access event,
device state.

Authorization decision

Even a simple access decision is more than a UID lookup:

is the card known?
→ is the card active?
→ is the subject active?
→ is access allowed for this door?
→ is the time policy satisfied?
→ is the system in a valid state?
→ allow / deny

The result and reason should be auditable.

Data integrity

A duplicate UID record, wrong card assignment, or mutable access history can become a security issue. Database constraints and audit design therefore matter:

uniqueness,
referential integrity,
controlled updates,
audit trail,
timestamps.

Unit 11: End-to-end RFID access-control implementation

The 2014 prototype

The RFID Access-Control System linked a physical reader to a physical actuator:

RFID card
→ RFID reader
→ serial data
→ UID parsing
→ authorization
→ Arduino UNO
→ servo motor
→ physical access

This made a software decision directly visible in the physical world.

Command is not state

Sending an OPEN command does not prove that a door physically opened. A reliable system distinguishes, when hardware permits:

command,
acknowledgement,
physical state feedback.

I later encountered the same principle in more complex avionics and robotics systems. Those later experiences are not presented as part of the 2014 note; the current revision only uses them to show the continuity of the systems-engineering principle.

Arduino and servo

Arduino UNO served as the controller that converted a software authorization decision into servo motion. Even in a small prototype, separating business logic from physical actuation makes failure boundaries easier to reason about.

Fail-safe behavior

Physical access systems should define behavior under failure:

What happens if communication is lost?
What if the card cannot be validated?
What if the database is unavailable?
What if the actuator does not execute the command?

Fail-open versus fail-closed behavior depends on the safety and security context.

Unit 12: Keyboard-wedge/HID RFID readers

Not every reader exposes a serial protocol

Some readers present the result to Windows as if they were keyboards. After handling the RF transaction internally, the device can “type” an eight-character hexadecimal identifier.

The software boundary then becomes:

RFID card
→ RF handling inside reader
→ keyboard-wedge / HID-like input
→ Windows input path
→ character sequence
→ UID parser

The application is no longer decoding the RF protocol.

Focus

A normal KeyDown handler can be enough for a focused kiosk form. More complex applications may evaluate:

IMessageFilter,
WndProc,
Raw Input,
low-level hooks only when truly required.

The correct boundary depends on focus guarantees and whether the software must prove which physical keyboard-class device produced the input.

Turkish Q/F keyboard layouts

One of the readers I used emitted a four-byte UID as eight hexadecimal keystrokes. The A-F key mapping behaved differently across Turkish Q and F layouts, so the application needed explicit mapping logic.

This detail illustrates a broader point: device “data” can be transformed by operating-system input layers before it reaches application code.

A current, deeper treatment is available in Reading a 4-Byte RFID UID Through a Keyboard-Wedge/HID Reader in .NET.

Unit 13: RFID security and privacy

A UID is not a secret key

The most important rule is:

a readable UID alone is not strong proof of identity.

A simple prototype can whitelist UIDs, but higher-risk systems must consider cloning, emulation, unauthorized reading, and stronger authentication.

Attack surface

RFID security spans more than the air interface:

tag
↕
RF channel
↕
reader
↕
host protocol
↕
middleware
↕
application
↕
database

Possible threats include:

unauthorized reading/tracking,
cloning or emulation,
replay,
relay,
reader spoofing,
tag spoofing,
jamming/denial of service,
malicious host-protocol input,
authorization manipulation in the database.

Reader security and tag security

A malicious reader extracting data from a legitimate tag is a different threat from a malicious tag deceiving a legitimate reader. A threat model should cover both directions.

Lightweight cryptography

Passive tags can be constrained by power, memory, gate count, and execution time. This is why lightweight cryptography has been an important RFID research area.

“Lightweight” should not mean “weak.” Protocol design, key management, randomness, and side-channel resistance still matter.

Side channels

Even a mathematically sound cipher can leak information through implementation behavior such as:

timing,
power consumption,
electromagnetic emanations.

RFID devices are a good example of why hardware and software security cannot be designed independently.

Back-end security

A secure tag cannot compensate for an insecure back end. Access-control systems still require:

least privilege,
strong administrator authentication,
SQL-injection prevention,
audit logging,
secure network transport,
secret/key management,
controlled authorization changes.

The broader software-security perspective is covered in Secure Software Engineering.

Unit 14: Reliability, performance, and debugging

Preserve raw evidence when needed

If a card appears to be “read incorrectly,” storing only the normalized UID can hide the cause. Diagnostic records can include:

raw bytes,
parse result,
port/reader identity,
timestamp,
protocol state,
error code.

That makes it possible to separate parsing defects from hardware faults.

Timeout and retry

Serial and network protocols require explicit:

deadlines,
timeouts,
retry policies,
cancellation behavior.

Retry safety depends on operation semantics. Retrying READ UID is not equivalent to retrying OPEN DOOR.

Latency and throughput

An access system can care about both aggregate throughput and single-user response latency.

A useful decomposition is:

total latency = RF read + reader processing + host transfer + validation + DB + control output

Optimization should follow measurement of these components rather than guesswork.

Multiple readers

Scaling from one to many readers introduces:

connection lifecycle,
concurrency,
reader identity,
duplicate events,
time ordering,
backpressure,
fault isolation.

A debugging sequence I kept

The faulty-reader investigation in 2014 left me with a reusable order:

physical connection
→ electrical level
→ port/link
→ raw protocol
→ parser
→ normalization
→ business logic
→ database/UI

Skipping layers tends to produce unnecessary code changes.

Unit 15: RFID, databases, networks, and IoT

Edge to back end

A modern RFID deployment can be viewed as an edge-to-backend system.

The reader/gateway may:

collect physical observations,
filter or aggregate events,
buffer locally,
forward events to the back end.

The back end may:

map identity,
enforce authorization,
preserve history,
provide analytics,
integrate with enterprise systems.

Network failure

If readers are network connected, the design should decide:

whether events can be lost,
whether the reader buffers offline,
whether reconnection causes duplicates,
whether access decisions can be made locally.

At that point the RFID problem becomes a distributed-systems problem.

Database design

RFID event streams coexist with relational identity and authorization data. Data modeling therefore involves:

write rate,
query patterns,
indexes,
retention,
archival.

I cover the relational side in Database Management Systems and the network side in Computer Networks.

RFID and IoT

An RFID tag does not need to speak IP directly to participate in an IoT system. RFID often contributes physical identity and observations:

physical object
→ RFID identity/event
→ gateway/backend
→ digital state

Sensor-enabled RFID can extend this from identity into temperature or other measurements.

Unit 16: Software-defined radio and observing RFID

Why SDR matters

Software-defined radio moves significant RF processing into programmable digital signal processing. For RFID research, this can help with:

observing waveforms,
modulation/demodulation experiments,
protocol analysis,
experimental reader implementations.

GNU Radio and USRP

GNU Radio can compose signal-processing blocks in software, while USRP-class hardware provides programmable RF sampling and transmission interfaces.

I did not build the RFID readers in my 2014 AKU internship using SDR. My work was on existing readers, host communication, parsing, database integration, and physical access control. I keep that distinction explicit: this section explains a technical way to observe the RFID physical layer; it is not presented as personal internship experience.

Signals-and-systems perspective

A deeper RF treatment requires concepts such as:

spectrum,
bandwidth,
modulation,
sampling,
noise,
filtering.

The mathematical basis is covered separately in Signals and Systems.

Unit 17: RFID application domains

Physical access control

Access control was the application I worked on most directly in 2014. The engineering objective is not merely to read a card, but to produce a secure, traceable physical-access decision.

Asset and inventory tracking

UHF RFID can identify large numbers of objects in warehouses, production, supply chains, and logistics. Reader placement, tag density, and item materials become significant design variables.

Libraries

RFID can support item identity, shelf workflows, and checkout/return operations. Metal shelving and high tag density can affect deployment behavior.

Healthcare

RFID can be used to relate medication, samples, devices, or patients. Here an incorrect association can become a patient-safety issue rather than only an inventory error.

Manufacturing

Tags on parts, pallets, or carriers can bind physical production flow to MES/ERP records. The value comes from synchronization between physical state and digital process state.

Transportation and logistics

Container and vehicle tracking introduce outdoor operation, moving targets, large read zones, harsh environments, and multi-reader coordination.

Unit 18: Engineering lessons from my AKU IT internship

Where computer engineering met a physical system

I was a Computer Engineering student in the summer of 2014. The AKU IT internship was one of the projects where programming, algorithms, operating systems, and databases met actual hardware in one end-to-end system.

The same problem could include:

electrical connection,
serial protocol,
byte-level data,
C#/Java application logic,
SQL Server/database state,
GUI,
Arduino,
servo motor.

The lasting value was therefore not learning one RFID product. It was learning to think end to end.

Areas I worked on most directly

The historical project record highlights:

Promag MF7-20 RS232/UID analysis,
MAX232-based connection and raw serial observation,
protocol troubleshooting across multiple readers,
reconstructing PCR310 request-response behavior in C#,
Verifone QX1000 wiring and output parsing,
UID byte-order normalization,
serial-port terminal/monitoring tools,
access-control database management,
keyboard-wedge/HID UID capture,
Arduino/servo-based physical access control.

Related records include:

Relationship to later work

The first publication date of these notes is 2014. My Baykar internship was in 2015 and my AKINSOFT & AKINROBOTICS period came later. I therefore do not rewrite those later experiences into the 2014 context.

From today's perspective, however, the engineering continuity is clear:

2014 AKU IT
RFID / RS232 / UID / DB / GUI / physical access
        ↓
2015 Baykar
embedded networking / avionics / telemetry / debugging
        ↓
2016-2019 AKINSOFT & AKINROBOTICS
robot control / sensors / actuators / telemetry / autonomy / GUI

The technologies changed, but the central question did not:

through which boundaries does physical-world data travel in software, and into which physical or operational decision does it eventually turn?

Conclusion

An RFID system is not just a tag UID displayed on a screen.

The tag participates in the RF physical layer.

The reader converts that interaction into device-level data.

Serial, USB, or network transport carries the data to software.

A parser turns raw bytes into an event.

Normalization gives the identifier a canonical representation.

The database relates the tag to a person or asset.

Authorization decides whether an operation is permitted.

Logging makes the decision explainable later.

When an actuator is involved, the decision returns to the physical world.

The enduring value of working with RFID during my 2014 internship at the Afyon Kocatepe University IT Department was seeing this complete chain on real hardware. Later embedded, avionics, robotics, digital-forensics, and critical production work repeated the same principle at larger scale: if a system cannot trace data from its physical source to its final effect, it is difficult to explain or trust.

References

Xinxin Fan (Ed.), Radio-Frequency Identification (RFID): Emerging Technologies, Applications and Improvement Strategies, Nova Science Publishers, 2014.

ISO/IEC 14443 series, contactless proximity cards/objects.

ISO/IEC 15693 series, contactless vicinity objects/cards.

ISO/IEC 18000 series, RFID air interfaces for item management.

GS1, EPC Radio-Frequency Identity Generation-2 UHF RFID Standard.

My Afyon Kocatepe University IT internship

RFID Access-Control System

Reading RFID Keyboard-Wedge/HID UID in .NET