1
UAS Tracking Module Technical Review
Bryce Gruber∗ , Andrew Misiani∗ , Michael Turnbull† , Casey Martin† , Mason Reck†
School of ∗ Electrical Engineering and † Computer Science
University of North Dakota
Grand Forks, ND 58203
{bryce.gruber,andrew.misiani,michael.turnbull,
casey.martin,mason.reck}@und.edu
Abstract—This paper details the development history and
technical progress made by the University of North Dakota’s
joint computer science and electrical engineering senior de-
sign team #5. This team has been working with the Northern
Plains UAS Test Site to develop a small self-contained device
with a built-in GNSS receiver, radio, and logging hardware
to enable the test site to track a number of unmanned air-
craft remotely. The system must support multiple aircraft,
and streaming data in (near-)real-time to other networked
equipment on the ground.
I. I NDIVIDUAL & T EAM C ONTRIBUTION
The following table shows the members of the team,
and the section(s) of this document they were responsible
for. The actual work performed follows the information
given in those sections.
Bryce Gruber Air-side Hardware
Ground-side Hardware
Michael Turnbull Embedded/Air-side Software
Casey Martin Computer ground station S/W
Mason Reck Computer ground station S/W
Andrew Misiani Extended ground side S/W
II. P ROBLEM S TATEMENT & R EQUIREMENTS
The problem at hand is one of data organization. The
test site flies many different types of aircraft, each using
their own telemetry system and are largely incompatible
with each other. Therefore, no central real-time bank of
information on the locations of every currently in-flight
aircraft is available, making test coordination and safety
much more difficult. The test site, therefore, requested that
a small device that can be affixed to an aircraft be devel-
oped and produced in enough quantity to equip their entire
simultaneously-airborne fleet. The device will act entirely
independently of the aircraft avionics and power system;
determining its location through a self-contained GNSS
receiver, logging to a microSD card, and relaying data to
the ground segment over a separate radio link.
III. A IR -S IDE H ARDWARE
The hardware for the airside module is selected directly
in support of the requirements for the project. At its very
core, the goal of the project is to provide a tracking mod-
ule for a small UAS. As the final design product will be
placed on an aircraft, the goal should be to meet all the re-
quirements generated for the hardware, maximize the time
the module can stay on with one battery, and minimize the
overall mass of the final module.
There are a limited number of options available for
tracking over distance in general, and not all technologies
compare evenly when it comes to accuracy and accessi-
bility. In this case, the main tracking capabilities of the
airside tracking system will be powered by a GPS receiver.
Given the accessibility of the hardware, specifications, and
integration instructions, the chosen GPS module for the
air unit design was the NEO-M9N chipset by the com-
pany u-blox. This module can act as a receiver for up to
4 concurrent satellites at a single time with autonomous
tracking for up to 5 minutes and horizontal position accu-
racy within 2 meters. Overall, this chip provides location
data to a degree that is encouraging for data collection,
as will be seen in the circumstance of the Northern Plain
UAS Test Site.
Another important measurement is the altitude at which
the aircraft is operating. For this reason, a barometer is
included in the air module design. The BMP390 was cho-
sen for a few reasons. The first and most significant is the
accuracy that it brings to the mission at its price point. Ad-
ditionally, another major benefit is the form factor that the
integrated circuit is packed into. With only a 2-millimeter
by 2-millimeter footprint, this device can essentially be
invisible on a printed circuit board. The accuracy of this
device is within 0.25 meters.
All of the data generated by the specialized chips would
be useless without a central processor to format the data
into a single message readable by either machine or a hu-
man. Originally, the alternate proposal for the project was
2

to incorporate Remote ID into a tracking device. Even

though Remote ID is not an intentional capability of this
project, it seemed logical to include hardware that could
support the requirements of Remote ID if the legislation
becomes final. For this reason, an ESP32-S3-WROOM
was selected for the main processing unit. This unit is
a two-core processor that can support Wi-Fi and Blue-
tooth advertisements. With two different versions of the
WROOM chip, one with a PCB antenna and the other with
a connection point for an external antenna. In the case of
supporting Remote ID, the version built for an external
antenna is selected for extending the range of a Remote
ID advertisement signal. After combing the inflow of serial
data from the barometer and GPS integrated circuits into
a data packet, one for onboard storage and the other for
sending wirelessly to the ground station.

These devices, as UAS trackers, make the most sense

to be used as wireless devices. In order to do so, a
module that allows wireless communication between two
places must be used. Given that the MAVLINK data struc-
ture is optimized for instances involving UAS, a wire-
less transmitter capable of accurately sending data over
the MAVLINK protocol should be used. Additionally, the
ability to communicate over a long-range is a must. The
RFD900 Module takes the place of the solution to these
requirements. To prevent multiple point-to-point connec-
tions to be made between the ground station computer and
each aircraft, the RFD900x can utilize a mesh network
allowing multiple aircraft to send each of their data to a
single ground station all on the same telemetry network.
Fig. 1: General data flow of the air unit.
include a battery or power directly from the aircraft. Either
way, the required voltage is not expected to be met for
all of the modules in a single instance. A few select ICs
will be used to provide a constant voltage to each of the
individual components. This is important since, in both
cases, it is likely that both the battery and ship power
will change over time, causing variable voltage. Voltage
regulators will be used to combat this issue.

The user interface was one of the requested upgrades
that the design team was tasked with while most of the
other upgrades to the devices were optional. On the current
model that is being used as a UAS tracker, operators are
unsure of several different states that the tracking device
may be in. In this case, controllable LEDs will be used to
indicate different statuses. Unlike most of the previously
mentioned modules, a simple High/Low signal will be
used to turn on and off the LEDs as seen fit. In addition to
LEDs, a microSD card is added to quickly swap storage in
each device. The previous process included downloading
the data stored in the onboard flash data. This microSD
card solution allows the module to quickly switch data
storage instead of waiting to download and erase the previ-
ous data. The read and write action between the microSD
card and the ESP32-S3-WROOM can occur over SDA or
MMC.
Figure 1 shows the general data flow between all of the
main components on air side module.
Nearly all of the components will need to be powered
by a 5- or 3.3-volt source. Different power solutions may
It is estimated that, while powered over a 18650 lithium-
ion battery would be capable of providing power to the air
unit for an estimated hour and a half to two hours. These
calculations were performed by taking the estimated max
current draw from each of the ICs and comparing again
the current hours of the battery. Although this may seem
like a relatively short period, this amount of time is likely
long enough to endure the typical length of the flight of
the UAS used by the Northern Plains Test Site.
IV. A IR -S IDE S OFTWARE
The software running on the air segment is a custom
development for the hardware selected for the project.
As previously discussed, the hardware is based around
an ESP32-S3, which runs a real-time operating system
called FreeRTOS. The toolchain used is open-source and
distributed by Espressif, called ESP-IDF, and features a
cross-compiler, a multitude of static libraries and plat-
form drivers, flashing utility, and debugger. ESP-IDF al-
lows for making an extremely complex compilation pro-
cess (involving compilation of more than 800 C source
 3

files) trivially easy and automatically handles static linkage
between necessary components. It also provides access to
on-chip debugging capabilities, vastly improving the abil-
ity to troubleshoot software issues with direct access to
memory and CPU registers.
The primary compilation unit of an ESP-IDF project
is a “component.” A component is analogous to a li-
brary, though often integrates with other components and
must therefore be compiled in a certain order to allow
for ESP-IDF to link it (which is always done statically).
The entire system uses the Kconfig language and menu to
allow for ease of changing one value even across multiple
components; though the menu definition may only live in
one place, the #define-level option is available across the
entire project. In this project, several components are de-
fined – generally, one for each type of task that must be
performed.
Ten tasks are used in this project total to perform the
necessary functions described in the [REF] requirements
section. There are ten overall tasks, each one performing
a function that runs the same task for a long duration.
Generally, each task is implemented in its own component,
but tasks that perform similar functions (such as the four
LED indicators) are housed in one component for that
group. This is the case for the LED indicators and the
MAVLink message output, which uses separate tasks for
high- and low-rate periodic messages.
At a general level, the order of tasks performed by the
air segment software is as follows. After boot and ap-
plication entry (handled by the ESP32-S3 bootloader and
FreeRTOS kernel), the module first allocates space for a
shared data segment that will be shared between all tasks.
It then reads a static configuration file stored in SPI flash
memory for some necessary data points. Then, it sequen-
tially starts all the long-run tasks by calling the publicly
exposed functions from each of the components. Finally,
the main application entry point actually terminates, as it
is no longer needed.
• OLOGUSD: log to microSD card
As mentioned previously, all of these tasks reference a
single shared data segment in memory intended to provide
a single, undisputed source of truth information. Each task
only puts the most recent information it has into the shared
memory, and when a task reads from the shared truth data,
it always gets the most up-to-date information. This truth
data has been broken into several data structures, each one
protected by a mutual exclusion device (mutex), based on
data access patterns. The access patterns mentioned are
given in table I.
It should be noted that some of the tasks shown in this
table do not appear to read or write any data. Those tasks
(namely some of the LED indicator tasks) read the status
of other tasks directly from the FreeRTOS kernel using
builtin status checking functions, and act based on the in-
formation obtained from that source. As an example, the
indicator that shows whether the data broadcast is running
or not will illuminate if and only if the ONRMLMAVH
task is not suspended or deleted; it can check this without
having to lock any of the shared truth data mutexes.
V. G ROUND -S IDE H ARDWARE
The hardware used on the ground consists of two main
components, the receiving RFD900x, and the operator’s
computer. The telemetry network received can send data
through the serial protocol over USB to the operator’s
computer for analysis. This connection will be through an
FTDI cable.
The basic data flow can be shown in figure 2.

The full list of tasks that run continuously is given be-

low:

• INMEAGNSS: GNSS input

• ONRMLMAVH: high-rate MAVLink output
• ONRMLMAVL: low-rate MAVLink output
• OVISPWR: LED power indicator
• OVISFIX: LED GNSS fix status indicator
• OVISISMBCST: LED is-broadcast-running indicator Fig. 2: Current ground unit data flow
• OVISUSDLOG: LED is-microSD-logger-running in-
dicator A more advanced ground station is limited by the time
• IBARO: barometer input of the software developers and will not be implemented
• PWATCHHOME: identify takeoff event in the current version of the system. In the case of future
4

E
ST
H
L

M
AV

AV
SS

O
BC

LO

SD
H
N

LM

LM

CH
G

X
PW

SD

U
EA

FI

IS

RO
RM

RM

G
AT
IS

IS

IS

IS

LO
M

PW
N

OV

OV

OV

OV
IN

IB
Data

O
Aircraft Latitude W R R R R
Aircraft Longitude W R R R R
GNSS HDOP W R R R R R
Aircraft course W R R R
Horizontal speed W R R R R
Horizontal accuracy W R R R R
Speed accuracy W R R
Altitude (MSL) R R W R R
Altitude (relative) R R W R R
Vertical speed R R W R R
Vertical accuracy W
Absolute pressure R R W
Outside air temp. R W
Home latitude R W
Home longitude R W
Home altitude R W
NMEA sentence hist. W
Time at takeoff R R W
Airborne status R R W

TABLE I: Read-write analysis of each task to determine data structure groupings. An ‘R’ denotes that the task will
read that data; a ‘W’ for writing. Groups of data bundled into structures are shown with horizontal lines.

development, the design for a more advanced ground sta-
tion mimics the air unit to a degree. This allows for the
re-use of custom drivers developed for the air unit.
The upgraded ground station would consist of two more
additional modules, a NEO-M92 and BMP390 would be
added to give the location and relative altitude of the
ground station. Unlike the air module, data would be flow-
ing inward instead of outward. With all of this data to man-
age, another ESP32 would be used to control and package
the data before forwarding it onto the ground station.
VI. G ROUND -S IDE S OFTWARE
The ground station software takes in MAVLink data
from a standard USB receiver. It reads and displays the
data to the UAS operator before redirecting that data to a
specified server for use. The ground station uses a map to
show UAS location and allows the operator to configure
where the data is redirected. As a backup the ground sta-
tion also creates logs of the data in case the SD-card on
the module malfunctions.

Figure 3 shows the data flow of a future iteration of the
ground station.
The technology stack used to implement the ground sta-
tion is Python and Qt. It uses the pymavlink library to
process MAVLink data. Licensed under (L)GPL V.3 and
used by many other UAS projects and ground stations,
it allows us to ensure all reading and processing of data
is standard compliant. The GUI is written in QML(Qt)
and uses the PySide2 library allowing the back end to use
Python instead of C++ like normal Qt based applications.
Both QML and Python are interpreted languages that al-
low us to quickly make changes without compiling. As
the ground station just reads and redirects data the trade
off in performance is worth it.

The ground station must be able to handle multiple UAS

Fig. 3: Expected future iteration of ground unit data flow
at the same time. It must be able to tell which UAS a
MAVLink packet came from and only update that data. To
do this we use the system id of the MAVLink protocol to
create the UAS list. Every time the ground station receives
a packet it checks the system id first and tires to match it
with a UAS in the list if none is found, that new UAS is
added. The system id must be configured in the external
 5

module beforehand to make sure no two UAS have the

same id to prevent conflicts.

VII. E XTENDED - G ROUND S IDE S OFTWARE

The ground station should be capable of communicating

with the radio telemetry (RFD 900) to receive telemetry
data from the RFD900 to the computer in the ground as
well as reading the serial data from the telemetry network.
The ground station is then able to pass data to the opera-
tor’s/ backup computer which will read and store the data
being passed into it.

The module is also capable of determining its baromet-

ric altitude of the ground station as well as the location of
the ground control station and that of the UAV. The op-
erator’s output computer is able to send all the mentioned
data from above as directed/captured. Socket with socket
API is used to send messages across the network (local)
to computer or any physically connected to external net-
works. Python socket module is used for the server appli-
cation. The most common type of this socket is where one
side acts as the server and waits for connections from the
client/s or user. This is done through identifying /defining
a socket, binding it, listening for the data being passed,
accepting, connecting and sending at the same time re-
ceiving.