Afyon Kocatepe University IT Internship

2014 — End-to-end hardware/software integration in the university IT software unit: RFID readers, RS232, UID processing, databases, serial monitoring and Arduino-based access control.

I completed my 2014 internship in the software unit of Afyon Kocatepe University's IT Department. The initial subject was the RFID readers used in campus access-control systems. It soon became clear that the task was not simply to read a card identifier and display it. Electrical interfaces, serial communication, device protocols, UID representation, database records and user-facing software were different layers of the same data path.

This was one of the first institutional environments in which I could clearly distinguish application development from systems engineering. When something failed, the useful question was not only "which line of code is wrong?" but "at which boundary does the observed data stop matching the expected behavior?"

Starting with RFID and RS232

The first experiments used Promag MF7-20 RFID readers. I built and tested an interface around a MAX232 circuit so that the reader's RS232 output could be observed reliably from a computer. Power, TX/RX wiring and serial parameters were checked against the device documentation. By inspecting the raw stream in a terminal, I separated the UID carried between STX and ETX and tested how baud rate, parity and related parameters affected the received data.

The objective was not to hide the device behind a convenient SDK. I first needed to understand what bytes the hardware actually emitted. I then wrote C# tools using SerialPort to receive the stream, represent it in hexadecimal form and compare it with data observed in the terminal.

During the internship I also worked with other readers, including PCR310 and Verifone QX1000 devices. Their different communication behavior made a lasting point: code that is specific to a device should not be confused with the general data-processing logic that follows it.

Do Not Assume the Fault Is in Software

One early reader did not produce the UID format expected by the system. The problem was investigated across software, serial parameters, conversion logic, alternative circuits and different host computers. After manufacturer discussions and alternative hardware tests, replacing the reader finally produced the correct stream.

The important lesson was not merely that a device happened to be faulty. Integration problems require hypotheses to be eliminated layer by layer. Continuously changing application code before proving that the hardware path is correct only adds uncertainty.

With a working reader, a second issue became visible. An example UID received as F23ACBD2 corresponded to D2CB3AF2 in the existing database representation. I identified the byte-order difference, applied the conversion in the application layer and verified the result against the stored value.

That small case became an early example of a broader rule I still use: the same information can have different physical representations at protocol, memory and persistence boundaries.

Understanding Different Device Behaviors

For PCR310, I examined the request-response behavior of an existing sample and reproduced the relevant flow in C#. The application opened the serial port, issued the required request, received the anticollision result and converted the UID into the representation expected by the rest of the system.

The Verifone QX1000 work required looking below the software layer. When the expected pin arrangement did not establish communication, I traced the cable with a multimeter and determined the actual connection. I then wrote a C# application around the device's command-line utility and parsed its output into usable fields.

The common skill across these devices was not familiarity with any particular product. It was the ability to validate physical connection first, then protocol and framing, and only then application integration.

Serial-Port Tools Built from Operational Need

The terminal programs available during testing did not cover every workflow I needed, so I wrote my own serial-port terminal and monitoring utilities. Port name, baud rate, parity, data bits and stop bits could be managed while raw data and operation logs were retained for later inspection.

Logging was useful for more than showing an exception. When time, configuration and failure were recorded together, a communication problem could be reconstructed after the fact.

I later added a web-based observation layer over the files produced by the desktop terminal. Instead of reading the complete file on every request, the implementation tracked the previously consumed position and fetched only the appended portion. Raw byte data and textual logs were handled separately and the browser view was refreshed periodically.

In current systems terminology, this was a small data acquisition -> persistence -> remote observation path. I did not describe it that way in 2014, but the habit of separating responsibilities survived into much larger long-running systems later in my career.

Database Work and a Metadata-Driven Management Tool

Reading a card was only one part of the access-control problem. Card, user and authorization data also had to be managed consistently. I designed a SQL Server data model and built a Java desktop application to manage it.

Rather than binding the interface to one hard-coded table, I experimented with JDBC metadata. Table and column names, data types and primary-key information were discovered at runtime, and the table and edit views were generated from that metadata.

For a small internship application this was intentionally more general than strictly necessary. It introduced a design concern that stayed with me: avoid encoding schema assumptions in multiple places when they can be represented or discovered once.

UID Conversion and Data Processing

Several exercises involved 7-byte and 4-byte UID representations, byte-order differences and the formatting expected by existing records. I built conversion utilities that could accept raw identifiers, produce the system representation and show hexadecimal and binary forms for comparison.

I also experimented with cryptographic APIs in some access-control prototypes so identifiers were not treated simply as plain text. These were not modern key-management or access-control designs; they were early experiments in considering representation, storage and data protection within the same workflow.

From Software Output to Physical Access Control

Later in the internship I connected the RFID path to a physical mechanism. Using an Arduino UNO, a servo motor, an LED and the MF7 reader, I built a small access-control prototype in which the identifier received over serial communication was evaluated and the resulting state controlled the servo.

I then experimented with infrared remote control and developed a desktop application that communicated with the Arduino to operate and observe the door state.

This part of the work was especially useful from a mechatronics perspective. A wrong state decision was no longer just an incorrect value on a screen; it became physical actuator behavior.

What the Internship Represented Technically

By the end of the internship, work around three different readers had expanded into serial communication utilities, UID conversion, a card/user database, desktop and web monitoring, an Arduino-based access-control prototype and supporting data-processing tools.

This account is based on the detailed technical records I kept during the 2014 internship. The reader, serial, database and physical-control problems documented there became early examples of the integration and troubleshooting approach I later used in larger systems.

The lasting practices are specific: inspect raw data before making higher-level assumptions, do not classify a hardware failure as a software defect without evidence, make protocol boundaries explicit, automate repeated diagnostic work and try to close the loop from physical input to useful system behavior.

Afyon Kocatepe University IT Department