Baykar — Computer Engineering Intern

My 2015 internship at Baykar began in the software unit at the company's Ikitelli facility in Istanbul and later continued in the field environment at Kesan, where I could work in the presence of real UAV systems. For me, this was less a conventional software internship than an early exposure to the way embedded software, avionics, measurement, electronics and operator-facing software interact in a mission-oriented engineering system.

The internship records note that some embedded and interface work could not be documented in detail because of confidentiality. Public descriptions therefore omit identifying architecture, circuit details, mission data and internal interfaces while retaining the engineering methods and results that can be described safely.

Technical Selection Process

The technical assessment before the internship was not a short interview centered on one programming language. It covered core computer engineering together with embedded systems, aviation and critical-system concepts.

Operating-system synchronization, mutexes, microcontrollers, embedded software and algorithmic reasoning were part of the assessment. One type of algorithm problem required systematically enumerating four-digit numbers whose digits satisfied a linear relation. The important part was not merely producing output by brute force, but modeling the search space and explaining why the solution was complete.

The scope also extended to avionics standards, the MIL-STD family, critical software, the history of UAV technology in Türkiye and internationally, aviation and the defense industry.

That breadth established an important principle before the internship even began: software in a critical system cannot be understood through language syntax alone. Timing, operating systems, hardware, communications and engineering standards are part of the software problem.

TMS570 and lwIP Embedded Networking

One of my first substantial assignments in Ikitelli used a Texas Instruments TMS570 development board. I worked on configuring the lwIP network stack and establishing reliable TCP and UDP communication, including echo scenarios on the target.

A TCP or UDP echo program can look trivial on a desktop. On a microcontroller it depends on the network stack, drivers, memory, interrupt behavior and hardware configuration all being correct at the same time. The assignment therefore became much more demanding than the apparent application-level requirement suggested.

Rather than stopping at a copied sample, I worked through the configuration and runtime behavior to determine where the path was failing. I kept extensive technical notes and recorded the experiments. When the implementation was completed, the source code and the working notes were retained as part of the engineering work.

After the development-board work in Ikitelli was completed, the internship continued in Kesan. The environment shifted from an embedded-networking problem to direct exposure to operational UAV systems, broadening the work from a controlled board-level task to a larger systems context.

From Ikitelli to Kesan

At Kesan, I could observe how embedded software, electronics, communication interfaces and ground-side applications fit together in a real system. My internship report also records the transition from development boards and communication exercises in the first week to UAV software, embedded work and interface/graphics development in the field environment.

Debugging changed character there. On a development board it was possible to focus mainly on code and configuration. In an avionics system, source code, PCB behavior, physical signals and system-level effects could not be separated so easily.

Hardware-Software Debugging Around an SPI/I2C Conversion Path

One assignment involved investigating a software problem associated with the SPI/I2C conversion behavior of an avionics communication component used in an active UAV system.

The issue could not be resolved by reading C code in isolation. While tracing the embedded software, I used Altium Designer to understand the relevant portions of the electronic design and followed the relationship between software-controlled peripherals and the physical circuit. Tektronix oscilloscope and signal-analysis equipment were used to compare the actual communication behavior with what the software expected.

I deliberately omit circuit topology, signal values, board identities and distinguishing architecture. The useful engineering point is the debugging path itself: C source -> peripheral -> PCB -> physical signal.

The problem was traced across those boundaries and the relevant software behavior was corrected. This became one of the early experiences that taught me not to treat a log line or exception as final evidence when software controls physical hardware. In a physical system, measured behavior has priority over assumptions.

Telemetry Software: Multi-Axis Visualization

The most extensive individual software project I completed during the internship was a desktop tool for examining telemetry data. I implemented it in C# on .NET Windows Forms and built the graphics layer with GDI+ and custom UserControl components.

The first engineering problem was scale. Many telemetry variables had to be inspected over a common time domain, but their physical ranges could differ by orders of magnitude. Putting every series on one Y axis made some signals unreadable. I therefore developed a multi-axis charting component that allowed variables with different ranges to be compared over the same timeline.

I treated the chart as a reusable module rather than a one-off drawing surface. Navigation through time ranges, simultaneous display of selected variables and report-oriented use were considered together with the rendering logic.

Turning Telemetry into Data That Could Be Investigated

Visualization alone was not enough. I added analysis functions that helped locate behavior worth investigating.

The software could identify minimum and maximum points, highlight unusual or extreme values, examine selected time intervals and compare telemetry variables. I also implemented correlation-based analysis to provide a quantitative indication of how two data series moved together.

Correlation was not used as a claim of causality. Its purpose was to narrow the engineering investigation and supplement visual comparison with a measurable relationship.

That approach remained with me in later signal-processing and data-analysis work: a plot is not the conclusion. It is a tool for deciding which interval, variable or interaction deserves closer analysis.

From an Internship Prototype to Ground-Control Software

The most important outcome of the telemetry work was that it did not remain a standalone student demonstration. The relevant part of the application was modularized and integrated into the existing telemetry software, becoming part of the software used in the ground-control environment of the active UAV program.

This made the distinction between working code and integrable code very concrete. An algorithm may be correct in isolation, but an existing system also imposes interface boundaries, data-lifecycle requirements, performance expectations, error behavior and user-interaction constraints.

It was my first direct experience of moving from a prototype into a component that had to fit a real engineering system.

Programming Standards and Static Code Analysis

One of the best-documented public parts of the internship involved programming standards and static analysis. I began by studying ANSI, ISO and particularly MISRA C rules and prepared a technical document on the subject.

This sequence also matters when I describe the project today. I started the static-analysis project by studying and documenting MISRA C rules rather than adding analysis as a quality gate near the end. I then made realization of the applicable MISRA checks one of the first priorities in the software I was developing. The rule was documented first; repeatable parts were then turned into executable checks, so documentation, implementation, and analysis belonged to the same development workflow.

I then implemented a C-based source-code analyzer that automated part of those checks. It did more than search for strings. While processing source characters, it tracked whether the current context was a comment, string or character literal, preprocessor line or normal code.

Context mattered because identical character sequences mean different things in different regions of a source file. // inside a string is not a comment. An assignment operator inside a condition requires different handling from a normal assignment. A switch rule cannot be evaluated reliably without tracking structure and state.

The project later evolved into a larger C# desktop analysis tool. I added file-system monitoring, navigation across source files, file/line-based findings, filtering, background analysis, cross-thread UI updates, external-process management and timeout handling.

I also integrated results from tools such as cppcheck and splint by executing them as processes and normalizing their output into the same result model. This allowed multiple analysis sources to be reviewed in one interface.

That work is an early form of a principle I still apply in secure software engineering: a repeatable rule should not depend solely on a reviewer remembering it. Where practical, it should become an automated and auditable check.

Metadata-Driven Database Utility in Java

In the final part of the internship I also developed a general-purpose Java database-management utility. It used JDBC metadata to discover tables, columns and primary keys, and generated editing behavior according to the discovered schema.

This was not a sensitive part of the UAV system. Its value was different: within the same internship I had to move between embedded C, C# desktop software and Java/database programming while preserving a systematic approach to data and state.

Looking Back

Calling this simply a "software internship in the defense industry" would miss what made it formative for me. Work that started with embedded networking on TMS570 and lwIP led to the field environment at Kesan, direct examination of real UAV systems, avionics debugging that crossed code, PCB and physical-signal boundaries, and a telemetry module that was integrated into the existing ground-control software.

The experience demonstrated that reliability in a critical system is not a single code-quality metric. Algorithms, operating-system behavior, concurrency, communication, electronics, measurement, data analysis and the operator interface belong to the same system.

The detailed internship report I kept in 2015 preserves the public portion of the work day by day. This summary brings its embedded networking, avionics debugging, telemetry and static-analysis work together in their engineering context.

2015 technical internship report (PDF)

Related Technical Context

The public technical context of this experience connects directly to microcontrollers, operating systems and computer architecture.

The wider system context connecting the internship's flight-control, embedded-networking, telemetry, static-analysis, and debugging work is developed in Avionics Systems and Unmanned Aerial Vehicles.