Afyon Kocatepe University IT Department — Computer Engineering Intern

I completed my computer-engineering internship in the software unit of Afyon Kocatepe University's IT Department in the summer of 2014. The work began with the integration of RFID readers used in campus access-control systems. Electrical interfaces, serial communication, device protocols, UID representations, database records and user-facing software were examined as interconnected layers of an end-to-end data-processing path.

The internship provided an institutional setting for evaluating application development and systems integration together. Diagnostic work traced data from its physical source through serial communication, protocol interpretation and the database representation.

RFID Readers and RS232 Communication

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 work began with verification of the byte sequence emitted by the reader and the structure of the serial frame. 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.

Hardware and Software Fault Isolation

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 investigation established a systematic approach to fault isolation across hardware, connection parameters, data conversion and application logic. Changes to application behavior were guided by verification of the physical communication path.

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.

Device Protocols and RFID Reader Integration

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 Diagnostics and Monitoring Software

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 Management and JDBC Metadata

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.

Processing UID data required a distinction between the physical card identifier, the serial-protocol frame and the numeric representation used by the application. Four-byte and seven-byte identifiers were examined in terms of length, byte order and textual representation, with converted values checked against existing records.

The integration work combined frame-boundary identification, classification of communication errors and verification of transformed output. These steps provided a repeatable approach to evaluating hardware-software interfaces across the available readers.

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.

Technical Scope of the Internship

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.

Integration Verification and Traceability

Verification extended from comparing raw serial data with terminal output to checking database representations and the response of the physical actuator. Communication parameters, encoding, data transformations and device behavior were evaluated as distinct parts of the integration chain.

The serial-monitoring utilities, JDBC-metadata-based management application and Arduino prototype represent complementary applications of the engineering experience acquired during the internship. The related project pages and academic course provide further technical context.

Afyon Kocatepe University IT Department

Related Projects from 2014

• RFID Access-Control System
• Serial-Port Monitoring and Control Software
• Access-Control UID Software
• Access-Control Database Manager
• Remote-Controlled Access System

Academic Foundations of RFID Systems

The practical RFID work involved Promag MF7-20, PCR310 and Verifone QX1000 readers, RS232 communication, UID conversion, and an access-control prototype.

The device-independent treatment of RF coupling, LF/HF/UHF, ISO/IEC and GS1 standards, anti-collision, middleware, security, performance, and verification is developed in the RFID Systems course. The separation keeps historical implementation evidence here and general technical material in the academic note.