Prévia do material em texto

Koopatracker Development and Comparative Study 
By Benjamin Koopmann, Bachelor of Science in Computer Engineering 
 
 
 
A thesis Submitted in Partial 
Fulfillment of the Requirements 
for the Degree of 
Master of Science 
In the field of Electrical and Computer Engineering 
 
 
 
Advisory Committee: 
Dr. Tim York, Chair 
Dr. Brad Noble 
Dr. Jon Klingensmith 
 
 
 
 
Graduate School 
Southern Illinois University Edwardsville 
May 2023 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
@Copyright by Benjamin J. Koopmann May 2023 
All Rights Reserved 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ii 
 
ABSTRACT 
Koopatracker Development and Comparative study 
by 
Benjamin Koopmann 
Chairperson: Dr. Tim York 
 
 After using commercial solutions for high power rocketry, questions were raised about if 
solutions that require a ham radio license were still the highest performing option compared to 
new communications technologies such as LoRa. This study was focused on a set of test 
procedures developed to stress test each solution to determine if newer technologies could prove 
to be a more effective solution. Range, hilly environment, data reliability, battery life, and 
parameter testing occurred throughout this study to characterize the behavior and performance of 
three different solutions. Koopatracker, Meshtastic, and Altus Metrum were all tested to 
determine an optimum solution. Ultimately each network performed better than others and led to 
a set of recommendations based on these results. 
 
 
 
 
 
 
 
 
 
 
iii 
Dedication 
This thesis is dedicated to everyone who supported me through my educational career. Thank 
you to my friends and family that gave me encouraging words when I needed it, encouraged and 
supported me through the whole process. A specific thank you goes to my Mom, Dad, and my 
Brother who were my biggest supporters, I couldn’t have done it without you. To my best 
friends Dakota Mendoza, Kaleb Depew, Briana Witherell, and Morgan Downing, thank you for 
always being there with encouraging words, interesting articles to distract my mind, and help 
through my classes when I needed it most. Even though we are all going off to conquer the world 
in our own ways, the connection we made will always be dear to my heart and will never be 
forgotten. To Dr. Noble, Dr. York, and Dr. Klingensmith, Thank you for the support through my 
coursework and guidance on this thesis. It was an honor to be able to work with you three and it 
was an experience I won’t forget. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
iv 
Table of Contents 
Abstract ........................................................................................................................................... ii 
Dedication ...................................................................................................................................... iii 
List of Figures ................................................................................................................................ vi 
Problem I want to solve: ................................................................................................................. 1 
Why Current Solutions Fail......................................................................................................... 2 
Solutions for Comparison for this project ................................................................................... 4 
Literature Review............................................................................................................................ 6 
Inspiration for this project/Cougar Rocket Intro. ........................................................................ 6 
Meshtastic...................................................................................................................................11 
Altus Metrum ............................................................................................................................ 14 
Koopatracker ............................................................................................................................. 17 
Data Collection Method ................................................................................................................ 24 
Hardware Overview ...................................................................................................................... 25 
Koopatracker ............................................................................................................................. 25 
Testing Procedure .......................................................................................................................... 27 
Antenna Orientation .................................................................................................................. 27 
Weather ...................................................................................................................................... 30 
Driving procedure ..................................................................................................................... 30 
Battery Test Procedure .............................................................................................................. 31 
Range Test Paths ....................................................................................................................... 31 
Test path 1 .............................................................................................................................. 33 
Test Path 2 ............................................................................................................................. 34 
Test path 3: ............................................................................................................................. 35 
Test path 4: ............................................................................................................................. 36 
Test Path 5: ............................................................................................................................ 37 
Test path 6 .............................................................................................................................. 38 
Specifics of Koopatracker ......................................................................................................... 39 
Specifics of Meshtastic.............................................................................................................. 39 
Specifics of Ham Radio............................................................................................................. 40 
Results: .......................................................................................................................................... 40 
LoRa Configuration................................................................................................................... 40 
 
v 
Base Range Test with Varying Antenna ................................................................................. 44 
Official Range Test Results ................................................................................................... 46 
Hill Signal Quality ................................................................................................................. 47 
Real Life Launch ................................................................................................................... 48 
UAV Testing Results .............................................................................................................. 50 
Battery Life Testing ............................................................................................................... 50 
Data Reliability at maximum range .......................................................................................... 51 
Altus Metrumof not requiring an additional person to align the antenna. For 
our test, a 3db, 6db, and 9db antenna are used in various testing. 
Table 4: Antenna Comparison Results 
combinations during range testing. The figure below shows the results for this portion of the 
This chart will be the topic of conversation later in the Discussion portion of the paper, but 
before then an important decision must be made. For the range testing that will happen in the 
Transmitter 
Antenna 
Receiver 
Antenna 
Spreading 
Factor 
Bandw
idth 
Prea
mble 
Test 
Number 
Range 
(miles) 
Average 
Range 
3 3 10 250 15 1 1.5 
3 3 10 250 15 2 1.66 
3 3 10 250 15 3 1.53 
 1.563 
3 6 10 250 15 1 2.38 
3 6 10 250 15 2 2.45 
3 6 10 250 15 3 2.53 
 2.4533 
3 9 10 250 15 1 0.83 
3 9 10 250 15 2 0.62 
3 9 10 250 15 3 0.75 
 0.7333 
6 3 10 250 15 1 2.57 
6 3 10 250 15 2 2.63 
6 3 10 250 15 3 2.59 
 2.596 
6 6 10 250 15 1 3.13 
6 6 10 250 15 2 3.08 
6 6 10 250 15 3 3.38 
 3.1966 
6 9 10 250 15 1 0.57 
6 9 10 250 15 2 0.59 
6 9 10 250 15 3 0.51 
 0.5566 
46 
 
next section, what antenna to use? Initially the 6x6 combo seem like the best solution, but the 
important factor that must be considered is what is practical for our application, tracking rockets. 
Most rockets will not have enough room for the 6db antenna, so the 3db will be the most used 
system. Therefore, the transmitter will have a 3db antenna while the 6db antenna will be 
attached to receivers. The most surprising result in the study was the effect of the 9db antenna. 
My current theory is the antenna was too high in sensitivity and not mounted high enough for 
proper usage. If the UAV testing system was operational, this theory could be tested. The same 
antenna setup will be continued into the Meshtastic system because the modules use the same 
transmission protocol so the characteristics should be the same. 
Official Range Test Results 
After determining what the optimal configuration for the Koopatracker device should be, 
the official range testing can begin for each device. Performing this testing will occur as 
described in the test plan. Koopatracker and Meshtastic will use the same antenna configuration 
to ensure a fair test. Below is the result of the raw distance test results. The primary change in 
this testing versus other testing is the usage of the optimized devices along with implementing 
the full Koopatracker code implementation. This code will add additional information in the 
packets (making them larger). 
Table 5: Range Test Results 
 Test 1 Test 2 Test 3 Test 4 Test 5 Average 
Koopatracker 3.41 3.64 3.56 3.47 3.45 3.506 
Meshtastic 3.22 3.15 3.55 3.5 3.34 3.352 
Altus Metrum 4.46 5.18 4.99 5.18 4.85 4.932 
 
 
47 
 
The results shown above show the overall results from the 5 test runs for each of the 
transmitters. Overall, the Altus Metrum device had the highest average range at almost 5 miles. 
This was a good result, but the results be better if not for the odd behavior which will be 
discussed later. Koopatracker came in second, but Meshtastic was close as well. The difference 
between the second and third place result is close but still almost a quarter mile. An initial theory 
behind this difference is the optimization of the preamble but this will be discussed further 
below. 
One important note about these test results is that the ranges are on the ground, not in the 
air. During an actual rocket launch, the modules are flying around inside the rocket hundreds or 
possibly thousands of feet high. Therefore, launch results may be significantly higher than the 
ground testing. Extra altitude allows for enhanced line of sight for transmitters and receivers. 
Hill Signal Quality 
Transmission around hills is an important factor along with range for determining 
performance. During the decent and recovery portion of the rocket launch, hills are a common 
interference due to the site for most rocket launches. For lack of better words, most rocket 
launches happen in the middle of a corn field surrounded by yet more corn fields. A lot of rockets 
as they land will ultimately land somewhere on the ground and typically have some interference 
from surrounding ground and trees/vegetation. To complete this test, all the hills along the test 
paths were used to determine just how well the signal propagates around the obstacles by 
monitoring the output of the maps to determine if each receiver received location data from each 
of the hilly locations. Overall Altus Metrum successfully transmitted around the greatest number 
of hills and had the most success. Koopatracker and Meshtastic had some success but also had 
substantially more misses compared to the Altus Metrum device. An initial theory on this result 
48 
 
has to do with the Altus Metrum device containing a 5 watt transmitter, but this will be a topic of 
conversation later. 
Real Life Launch 
Throughout the testing process, two rocket launch events came about which allowed for 
the testing of these devices. An Altus Metrum device powered the main rocket along with a 
Koopatracker transmitter being added into the nosecone of the rocket. A total of Five launches 
were attempted over four launch days, but only three provided usable data for the Koopatracker. 
Unfortunately, one launch had a user error where the tracker was not enabled. A second launch 
resulted in an unexpected explosion. The third launch attempt did yield results, but the rocket 
was not able to be recovered due to weather devices. Fortunately, the third did still provide good 
results. The methodology for this testing was to implement the devices and test them in a live 
launch. Please note that these launch events happened early in the Koopatracker methodology, so 
the transmitter was not fully optimized yet. Each rocket launch had the intention of reaching 
apogee at approximately 5000 feet with nothing too fancy going on. 
During the first launch with usable data, the rocket launch went as expected. According 
to my notes and data, both Altus Metrum and LoRa maintained communication throughout most 
of the flight. Altus Metrum data only updates every 30 seconds versus the Koopatracker which 
was set to 10 second transmission intervals, which is an important factor when attempting to 
determine the landing location. This particular launch site, Argonia KS, was surrounded by 
larger hills compared to a lot of sights. Both devices lost connection when the rocket was 
approximately 100’ from the ground (according to Altus Metrum Data Recording). During the 
recovery portion of the flight (driving in vehicle in attempt to locate rocket), the Koopatracker 
was able to recover the lost signal quicker than the Altus Metrum device. At the time of signal 
49 
 
loss, the rocket was approximately 3.74 miles from the receiver (as calculated by GPS Data). 
Overall, this was a very successful launch for the Koopatracker because of its ability to keep up 
and recover quicker than the Altus Metrum. 
The objective of the second launch was the same as the first. Same launch motors, setup, 
etc. The primary difference in this launch is the rocket was only 2.53 miles from the launch site 
when it landed. Both devices provided location/status updates as expected. Overall, another 
smooth flight which provided good test data for both the Koopatracker and Altus Metrum. 
At this point, there was a catastrophic launch in which the module used was not able to be 
recovered, aka it was shot out of the rocket along with the parachute. More details below. After 
that launch, the third launch with success full data occurred. Although this test did not go as 
planned either as the rocket was not able to be recovered. The launch was like the prior two 
successful launches. Rocket reached apogee and started it’s decent likenormal. During this 
launch, the parachute was set to deploy a bit higher as part of a pre-determined test plan for the 
club. Shortly after the parachute was deployed, the legendary Kansas wind picked up and started 
carrying it away with the wind. By the time a chase crew could secure the surrounding motors 
(explosives) and get driving, the rocket reached 5.19 miles away from the launch site at an 
altitude of 500 feet. At this point both devices continued to have successful communications. 
Unfortunately, the 30 mph wind provided quite a head start. Through the chaos, the altus 
Metrum receiver was disconnected from the computer and quickly reconnected. The altus 
Metrum was unable to recover the connection, possibly due to the same bug shown above. The 
LoRa kept up until the chase team drove through the nearby town, when the signal was lost. 
Despite the team’s best efforts, the rocket was lost. The launch event was cancelled for the day 
due to extreme wind gusts. This round of testing proved that LoRa does better with line of sight 
50 
 
communications which inspired the idea of doing a uav powered antenna/relay system. As well 
as proving the potential range for technology. 
UAV Testing Results 
After showing the effective range of the LoRa technology powering the Koopatracker, and 
Meshtastic in the future, when the antenna was at a higher altitude for better line of sight an 
experiment was developed to raise the receiver/relay by using a quadcopter. The quadcopter 
could act as an antenna tower of sorts with adjustable heights. A test plan was developed and 
discussed earlier in this paper, but unfortunately the testing failed during the first launch attempt. 
Further details are provided in the chapter titled “Moment of Silence for the Electronic 
Graveyard”. Ultimately this testing did not happen, but the predicted outcome of this testing was 
substantially longer range while adding the possibility to fly closer to predicted landing zones for 
more reliable transmissions. 
Battery Life Testing 
One important factor to keep in mind for anything to do with rocket launches is battery life. 
Unfortunately delays commonly occur throughout launch windows and occasionally rocketeers 
must wait a few hours before being able to launch again. Also, if the rocket must wait to be 
recovered. Longer battery life can increase the chances of a successful recovery. This test was 
designed to showcase the average battery life under typical use case conditions. Further details 
on procedure described later. Table 6 below shows the results of the battery duration test. 
 
 
51 
 
Table 6: Battery Life Test Results 
 
Test 1 
HH:MM:SS Test 2 Test 3 Test 4 Test 5 Average 
Koopatracker 26:37:00 26:40:00 26:36:00 26:44:00 26:42:00 26:39:48 
Meshtastic 20:42:00 20:29:00 20:21:00 20:27:00 20:35:00 20:30:48 
Altus Metrum 12:08:00 12:19:00 12:22:00 12:14:00 12:12:00 12:15:00 
 
From the table above, a clear winner can be named. Koopatracker averaged 26 hours and 29 
minutes on a full battery. Meshtastic was closer with a 20 hour 30 minute average. Altus 
Metrum was in last place with a 12 hour 15 minutes battery life. Overall surpassed expectations. 
The Altus Metrum has two different sized battery which are available for purchase which would 
cut down the battery life but make the device small enough to fit on more rocket platforms. 
Further details will be discussed in the next chapter. 
Data Reliability at maximum range 
Having an impressive range only helps if the data received is usable. This experiment 
focused on the number of usable packets received at the maximum range. After finding the max 
range of the devices, the receiver was placed in the same spot for 10 minutes to record all 
packets received to determine the number of complete and unfragmented packets received. 
Table 7: Packet Reliability at Max Range Test 
 
Total Packets 
Received 
Packets 
Usable 
Packets 
Fragmented Reliability 
Koopatracker 60 43 17 71.60% 
MeshTastic 40 33 7 82.50% 
Altus Metrum 20 20 0 100% 
 
The Altus Metrum came out far ahead of the competition, as their method is all correct or no 
packet received. Meshtastic packets did not display the packets as fragmented, but rather 
52 
 
displayed an error saying fragmented packet. Koopatracker had packets that were fragmented 
but still displayed. Some of the packets were completely un-usable but others were usable with 
no fragmentation. 
Altus Metrum Odd Behavior 
One aspect of the Altus Metrum that still needs to be investigated is the behavior of not being 
able to regain a signal unless the transmitter is within 200 yards of the receiver. During the 
rocket launches and range test, this behavior becomes apparent any time the transmitter comes 
out of range. The receiver can no longer find the transmitter signal even though it was working 
in that range before. An odd behavior such as this can limit options for recovery. As the team 
attempts to recover the rocket, getting up to date gps coordinates are essential to increase the 
chance of a successful recovery. 
 
 
 
 
 
 
 
 
53 
 
Discussion 
Spending the time to develop the preliminary configuration for the LoRa and Meshtastic devices 
was a worthy investment. Overall, the results from those steps allowed the rest of the project to 
go smoothly. As the project continued onward, small changes were made, but the base 
configuration stayed the same with only less noticeable settings getting tweaked in the 
background. The spreading factor experiment showed that each adjustment did have a major 
impact on the range of the device, although this did come at the price of on-air time. To allow 
for this device to be easily changed to be used across other countries or frequency bands, the 
400ms restriction was put in place. Longer range may have been achievable but come at the cost 
of not being able to use it legally. Preamble adjustment helped to ensure the receiver and 
transmitter were synced together so the chances of having a more reliable connection was higher. 
During the antenna study, using the highest db antenna in any combination resulted in 
poor performance to the point of cutting out around line-of-sight range. Ultimately the 6x3 (6db 
on the receiver and 3db on the transmitter) option was selected or the rest of the experiments. 
Primarly due to the restrictions that a lot of rocket electronics bay require. Vertical space is very 
precious in high power rockets, so requiring another couple of inches for an increased antenna 
could have been a major downfall. For some rocket launches before the Koopatracker project 
officially began, the 3x3 configuration was used due to the fact it was the only antenna option 
available. One possible test for the future will include modifying the UAV test to include the 9db 
antenna to determine the minimum altitude for it to be effective. 
Results from the Official range test showed that the Meshtastic and Koopatracker were 
close together. Although Koopatracker came out on top, there are some theories behind why this 
could be. Meshtastic may be optimizing the transmitter in a way that allows for more reliable 
54 
 
packet reception (discussed in the Data Reliability study), but with the cost of increased range. 
Koopatracker was programmed in a way that allows packets that are completely un-usable to be 
forwarded to show that the desired device is close but at the far end of the range spectrum. Any 
combination of the 6db and 3db antenna were very close in terms of range, which was not 
expected but makes sense. 
Transmission around terrain with hills and other physical obstructions is a crucial part for 
model rocketry. Launch sites utilized are typically in very rural areas and contain some sort of 
hills or interruption. The Altus Metrum had near perfect reliability aroundthe hills used for our 
testing, which raises the question of why. Onboard the Altus Metrum is a 5-watt transmitter for 
433mhz. For comparison, the T-Beam has a 100mw transmitter onboard. The additional power 
along with lower frequency are my hypothesis as to why the Altus Metrum outperformed the T-
Beam. One interesting future experiment would be to connect a 5-watt amplifier to the T-Beam 
to determine the performance impact of the extra energy. 
Live rocket launch testing was my favorite part of the experiment (even though I couldn’t 
participate for all of them). Unfortunately, it did result in a couple of lost boards and a missing 
rocket, it showed a lot of potential for this technology. The T-Beam devices continued to work 
even with 2G’s of applied force. Once the T-beam devices were functional, it continued to 
function as normal until the rocket was found or user errors occurred. Achieving a 5-mile range 
during the runaway rocket raised the question of just how much impact would raising the 
antenna have on the performance. To answer this the UAV testing was developed. 
Unfortunately, the UAV testing failed, but not without learning some lessons along the 
way. A preliminary design for mounting the t-beam onto the quadcopter while allowing the 
device to hang 2 feet below the main body was developed and attempted to be implemented. If 
55 
 
time permitted, a second trial would occur to determine just how much better the performance 
would have been. 
 Battery life results far surpassed expectations for the t-beam, especially with the higher 
refresh rate for transmitting data. To the credit of the Altus Metrum, it does contain additional 
features that the T-Beam is not responsible for at this point, including acting as a data recorder, 
gyroscope, 5-watt transmitter, and a smaller battery. To give the Altus Metrum the best fighting 
chance, the largest officially supported battery was used. Another point has to be given to the 
Altus Metrum for being more compact and lighter than the T-Beam setup. Although when 
dealing with high power rocketry (such as the Cougar Rockets Activities), having a few extra 
grams can be used for important electronics. If changes had to be made for the T-Beam 
microcontroller package, adding a smaller battery option may be the option more ideal for future 
rocketry uses. 
 
 
 
 
 
 
 
56 
 
Overall Recommendations 
After performing the experiments it’s clear that there’s no single winner. The decision on 
which solution to use will depend on what kind of application is desired. For overall tracking 
abilities, the Koopatracker is the recommendation. This is primarily due to the ability to 
reconnect the transmitter and receiver after going out of range. Altus Metrum’s algorithm for the 
receiver can cause a situation like our launch where the receiver gets unplugged and suddenly the 
rocket cannot be recovered. It is unacceptable in my opinion to have a condition like this. Where 
the Altus Metrum is highly recommended if the rocket field is surrounded by hills or other 
physical interference. Throughout all of the testing, the Altus Metrum continued to receive the 
packets correctly regardless of the hills and other boundaries in the area. The Altus Metrum is 
also the choice for if the user already has a ham radio license. For those who do not have the 
license, going with the Koopatracker or the Meshtastic solution may be better. If the user wants a 
solution without needing to program and does not require a ham radio license, Meshtastic is the 
best solution. Although it may take some additional setup using a cell phone, the overall 
presentation and usability is best fitted for a beginner. 
 
 
 
 
 
 
57 
 
Moment of Silence for the electronic graveyard 
No experiment is perfect, including this one. Throughout the process of algorithm 
development and testing some chips unfortunately gave their electrons for this research. 
Throughout the duration of this research, numerous iterations of software were flashed onto the 
ESP32 boards. Although most boards handled this with ease, some did not. Two of the T-Beam 
boards used throughout this testing were placed into the electronic graveyard due to memory 
chips that refused to accept a software flash. This presented itself as a continual memory readout 
with the same value for all registers. Indicating the chip is not reading or writing to the memory 
correctly. Initially it was thought to be due to an issue with the code that was previously flashed, 
but that was proven to not be the cause. Flashing the code onto another board did not repeat the 
same error. Unfortunately, this issue could not be researched further before the deadline for the 
thesis. If time provided, additional research would occur to determine what caused the death of 
these boards. 
Although this may sound like a safe set of experiments, there is not always the case. As 
part of the optimal range testing, a Koopatracker module was attached to a UAV and flown to a 
height of 250 feet. Or at least that was supposed to happen. As part of the flight the board was 
attached to the landing gear of the UAV. This attachment allowed for the T-beam to be below the 
frame of the quadcopter, thus avoiding interference due to the UAV’s electronics and carbon 
fiber frame/propellers along with providing optimal antenna orientation. If the device was 
mounted on top of the UAV, interference due to high voltage electronics, other transmitters, and 
carbon fiber build could tamper with the results of this method. Designing a mounting system for 
under the UAV proved to provide fewer design complications versus on top (mostly due to the 
lack of spinning propellers and conflicting antenna). Unfortunately, part of this attachment 
method resulted in a rogue drone flight resulting in the UAV being damaged along with the 
58 
 
destruction of yet another t-beam. Upon takeoff, the mounting mechanism was lifted into one of 
the propellers of the quadcopter, causing the craft to become inverted while accelerating. Total 
damage to the quadcopter involved 3 broken propellers, a broken motor mount, damaged antenna 
array tower, and other cosmetic issues. At this point UAV testing was scrubbed. 
Following along with the theme of dangerous experiments, it’s time to discuss the failure 
that happened during the rocket launch portion of this research. Because the goal of these 
tracking methods is to track rockets, it seems logical to launch them in rockets for a real-life test. 
A member of the rocket club was participating in a high-power launch for an attempt to earn a 
high-power rocketry certificate. A rocket was built ahead of time and payload capacity and size 
were optimal to fit a t-beam with attached antenna. Before the rocket launch, a basic instruction 
manual was created to allow the group member use the Koopatracker system. Ultimately this 
exercise was supposed to be the best real-world test for this technology. Unfortunately, this 
flight did not go as planned. On the acceleration portion of the launch, communications with the 
module were working as expected. Signal strength and GPS coordinates updated and seemed to 
be accurate. Shortly after the rocket reached apogee, communication with the Koopatracker 
transmitter was lost. Initially this was thought to be a glitch in the system or simply out of range. 
All parachutes deployed normally, and the rocket was recovered. Unfortunately, at this point it 
was noticed a hole had appeared in the rocket that was not there during launch inside one of the 
chamber separators. After some investigation, it was determined that a crack formed inside the 
rocket between the parachute bay and electronics bay. Most high-power rocket launches include 
the use of black powder charges/explosions to ensure the rocket separates and propels variousobject to deploy the parachutes. When the charge for deploying the main parachute was initiated, 
pressure spread from this crack inside the electronics bay. Excess pressure from the electronics 
59 
 
bay along with newly formed crack caused the chamber separator to become detached from the 
rocket and fall out. This chamber separator was the primary mounting point for the Koopatracker 
transmitter t-beam. Other electronics in this chamber were still intact due to the wiring required 
to connect various sensors, batteries, and black powder charges. Ultimately the transmitter was 
forcibly evicted from its comfortable electronics bay at 5000 feet agl (above ground level). After 
the eviction, only the birds and universe could be called as a witness to what happened. It is 
theorized the antenna connector (known weak spot) was torn apart during freefall causing 
communication to be terminated. This theory has the highest probability due to transmission 
activity subsiding shortly after parachute deployment, although it could be incorrect. Fortunately, 
the rocket was successfully recovered and was able to be re-launched after rebuilding the 
damaged parts. The Koopatracker module in this rocket was not able to be recovered. Overall, 
this test was a 50% pass. Although it would be ideal to have data from the entirety of the flight, 
this test still proved that these modules successfully survived the rocket launch to the point of 
apogee. Even though this may seem minor, it showed potential for this technology. 
After failing the first rocket launch attempt, more opportunities arose for the testing of 
the Koopatracker system. During one flight, the module had a core failure on the ground which 
resulted in a botched test. As the rocket was being prepared, the module was powered on and the 
user verified the communications were active. During the stage of preflight, electronics are 
mounted into the electronics bay. In this case the module was mounted using electrical tape (oh 
yeah, we’re fancy like that). Unfortunately, the electrical tape held down the reset button, so the 
module didn’t power on for the duration of the flight. The Koopatracker version was very 
preliminary (before Koopatracker officially existed) so there were no measures in place to ensure 
accidents did not happen. Fortunately, visual observers in the area were able to assist narrowing 
60 
 
down the location of the rocket and the team was able to locate it. All does not end well for this 
board though. During the secondary launch of the day wind guests picked up and carried the 
rocket away faster than the team could track the rocket. Even with the long range of the LoRa 
technology, traveling around hills did not do the team any favor and caused the communication 
links to disconnect resulting in the loss of an entire rocket. 
As a honorable mention for almost failed experiments, we have to feature a robin which 
attempted to use the Altus Metrum board as a target for defecation. During the first round of 
communication testing the board was placed on a table outdoors to replicate a rocket landing in a 
field. After driving the first range test route I noticed bird droppings within 2 inches of the board 
which weren’t there before. After realizing a bird almost ruined the board, procedures were 
changed to include a plastic covering over the board which still allowed the transmitter antenna 
to be unobstructed. Fortunately the bird’s attempt failed and testing was able to proceed with a 
properly functioning board. 
 
 
 
 
 
 
61 
 
Conclusion 
Overall, the project developed a new form of tracking rockets along with completing a 
comparison study to determine it’s overall performance compared to other devices. As this 
project is continued upon and becomes more advanced, the methods developed have a good 
chance of impacting the current model rocket electronics market. Using a device like the Altus 
Metrum is a good option for someone who already has a ham radio license and wants something 
that’s fully integrated already. For beginners who want something simple with a GUI to set up, 
the Meshtastic/T-Beam combination would prove to be potent. Testing methods developed in 
this study will be useful for future experiments relating to model rocketry and wireless 
communication technologies. Unfortunately testing during this study resulted in multiple non-
functioning devices. Their sacrifice assisted in the development of a system that may introduce 
more people into the world of model rocketry. 
 
 
 
 
 
 
 
 
 
62 
 
Future Work 
As this study was being conducted, multiple new avenues for potential expansion became 
apparent. One comment I received on the Koopatracker setup was about how it would be easier 
to use if it had a gui application along with offline satellite maps for a visual location indicator. 
To continue that idea, a simple gui setup (similar to the Altus Metrum), with the ability to change 
major parameters of the device would allow for better usability. This is where Meshtastic has a 
major advantage. Although their radio may not be as optimized, their user interface was greatly 
improved compared to Koopatracker. 
In its current state, the Koopatracker relies on a pc connection for receiving information. 
If a solution to utilize the existing OLED display on certain t-beam boards, it could be more 
competitive compared to the Altus Metrum and Meshtastic device. This handheld solution 
would simply need to have a display to show the coordinates of the device along with a 
directional arrow and distance measurements. A handheld solution would allow for tracking 
teams to split up and not require so many devices. Simplifying the location process could be 
revolutionary for the model rocketry world. 
 Inspired by the FPV drone community, a solution for automatic directional antenna 
turrets aka automatic antenna trackers would be another avenue of future work. Because the 
transmitter sends the current gps location, automated software could be written to move a 2-axis 
gimbal to aim a high sensitivity directional antenna to achieve better range. If you combine this 
with a 5.8Ghz antenna, it provides a means of providing video connection at longer distances as 
well. For those who want to view the rocket’s live video feed and determine how the flight status 
from the location tracker is, having a system that moves the antenna automatically would be 
beneficial. 
63 
 
References 
 
[1] "Argonia Cup Competition Challenge," 1 5 2023. [Online]. Available: 
http://www.argoniacup.com/the-challenge/. 
[2] T. V. Milligan, "The Different Rocket Recovery Techniques," Peak Of Flight Newsletter Issue 447, 11 7 
2017. 
[3] "Amature Rockets and Radio," Altus Metrum, [Online]. Available: https://altusmetrum.org/Radio/. 
[Accessed 11 10 2022]. 
[4] K. Packard, "AltOS," 27 4 2023. [Online]. Available: https://altusmetrum.org/AltOS/doc/altos.pdf. 
[Accessed 26 11 2023]. 
[5] "Inreach Mini," Garmin. [Online]. [Accessed 2023 18 04]. 
[6] G. E. Athanasiadou, M. C. Batistatos, D. A. Zarbouti and G. V. Tsoulos, "LTE Ground-to-Air Field 
Measurements in the Context of Flying Relays," in IEEE Wireless Communications, vol. 26, no. 
1, pp. 12-17, February 2019, doi: 10.1109/MWC.2018.1800225.. 
[7] "T-Beam V1.1 ESP32 LoRa Module," LilyGo, [Online]. Available: https://www.lilygo.cc/products/t-
beam-v1-1-esp32-lora-module. [Accessed 27 1 2023]. 
[8] "Docs Introduction," Meshtastic, [Online]. Available: https://meshtastic.org/docs/introduction. 
[Accessed 13 9 2022]. 
[9] "Title 14 Chapter 1 Subchapter A Part 1 paragraph 1.1," National Archives: Code of Federal 
Regulations, 2 5 2023. [Online]. Available: https://www.ecfr.gov/current/title-14/chapter-
I/subchapter-A/part-1/section-1.1. [Accessed 8 5 2023]. 
[10] "Tripoli High Power Certicate Program: Certification Overview,"Tripoli, [Online]. Available: 
https://www.tripoli.org/content.aspx?page_id=22&club_id=795696&module_id=468541. 
[Accessed 9 12 2022]. 
[11] Slats, Laurens; , "A Brief History of LoRa®: Three Inventors Share Their Personal Story at The Things 
Conference," Semtech, 08 01 2020. [Online]. Available: https://blog.semtech.com/a-brief-
history-of-lora-three-inventors-share-their-personal-story-at-the-things-conference. [Accessed 
10 02 2023]. 
[12] Veeru, "Lora & LoRaWAN Explained! | What is LoRa? | History of LoRa! | Who invented LoRa? | 
How LoRa works?," ElectronicsInnovation, 05 07 2021. [Online]. Available: 
https://electronicsinnovation.com/lora-lorawan-explained-what-is-lora-history-of-lora-who-
invented-lora-how-lora-works/. [Accessed 11 02 2023]. 
64 
 
[13] B. Reynders and S. Pollin, "Chirp spread spectrum as a modulation technique for long range 
communication," 2016 Symposium on Communications and Vehicular Technologies (SCVT), 
Mons, Belgium, 2016, pp. 1-5, doi: 10.1109/SCVT.2016.7797659. 
[14] T. Schaub, "Spread frequency shift keying," in IEEE Transactions on Communications, vol. 42, no. 
234, pp. 1056-1064, February-April 1994, doi: 10.1109/TCOMM.1994.580214. 
[15] M. Bor and U. Roedig, "LoRa Transmission Parameter Selection," 2017 13th International 
Conference on Distributed Computing in Sensor Systems (DCOSS), Ottawa, ON, Canada, 
2017, pp. 27-34, doi: 10.1109/DCOSS.2017.10. 
[16] "Mesh Broadcast Algorithm," Meshtastic. [Online]. [Accessed 10 09 2022]. 
[17] "TeleMetrum," Altus Metrum, 03 08 2020. [Online]. Available: 
https://altusmetrum.org/TeleMetrum/. [Accessed 27 08 2022]. 
[18] J. Peng and L. Cheng, "Revisiting Carrier Sense Multiple Access with Collision Avoidance 
(CSMA/CA)," 2006 40th Annual Conference on Information Sciences and Systems, Princeton, 
NJ, USA, 2006, pp. 1236-1241, doi: 10.1109/CISS.2006.286654 
[19] C. Liechti, "PySerial Docs," PySerial, 10 2020. [Online]. Available: 
https://pyserial.readthedocs.io/en/latest/. [Accessed 10 09 2022]. 
[20] "QGIS: A Free and Open Source Geographic Information System," 2023. [Online]. Available: 
https://www.qgis.org/en/site/index.html. [Accessed 12 09 2023]. 
 
 
 
 
 
 
 
 
 
 
 
 
 
65 
 
Appendices 
 
Appendix A: KoopaTracker User Guide 
 
If you encounter issues or questions, Call Ben!!! 
Ben Koopmann 
618-402-XXXX 
 
Koopatracker User Guide (Simplified): 
Welcome to the Koopatracker, follow these instructions and hopefully your rocket recovery 
efforts will be successful. Before proceeding, ensure your computer has the following software: 
Putty, Arduino IDE, and an active internet connection (not required, but highly recommended). If 
a wifi signal is not available feel free to use your cell phone for the tracking portion. Specific 
versions of this software are not required so even older versions are okay. On the Arduino IDE, 
ensure you already have the esp-32 library installed to allow for flashing the boards if required. 
 
If you do not have the ESP-32 library installed, follow these instructions: 
1. Open Arduino IDE and open the preferences. (file -> preferences) 
66 
 
 
2. In the menu item “Additional Boards Manger URL’s, copy and paste the following link 
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-
pages/package_esp32_index.json 
 
 
3. Open the Board Manager through this path: Tools -> Board…. -> Board Manager 
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
67 
 
 
4. After opening the board manager, wait a minute for the board libraries to update and 
search in the bar for “esp32” 
 
5. Click the install button and wait for the boards to install. 
 
68 
 
 
 
If you need to re-flash a board Follow these instructions: 
1. Open the correct software package in the Arduino IDE Software. This is done by 
clicking file -> open and selecting the proper file. To find these files, use the supplied 
flash drive. 
2. Make any modifications required and save the file (ctl+s). 
3. Select the correct board type in the menu. This is done by selecting tools, Board…., 
ESP32 Arduino, TTGO LoRa32-OLED. This selection allows the IDE to determine what 
pins are connected to what components. 
 
69 
 
4. After the board is selected, select the correct serial port number by selecting one in tools -
> port and selecting the proper port. If there are multiple options, try one and if that 
doesn’t work, try again. Be sure to not have other Arduino products or microcontrollers 
plugged into the computer during this step to prevent accidental issues. It should error 
out before damaging other brand of microcontrollers, but always safe versus sorry. 
5. Finally click the arrow button on the main menu to flash the software onto the board. 
 
 
 
 
To make the network do things, follow the following instructions. 
 
First, get the transmitter operational. Take an 18650 battery from the storage box provided and 
find the positive and negative terminals. THIS IS VERY IMPORTANT AS THE T-BEAM 
DOES NOT HAVE REVERSE POLARITY PROTECTION. Insert the battery into the socket 
and look at the front of the board for lights. Within 15 seconds of the deice receiving power, a 
flashing light in the middle of the board should appear. Within 5 minutes of receiving power (or 
sooner) a flashing red light should appear around the GPS module. This red light under the GPS 
indicates an active GPS lock. If there are no lights, plug the device into a computer or power 
bank using a usb cable and allow the battery to charge. 
 
70 
 
Secondly, the receiver needs to be set up. 
To set up the receiver, insert a 18650 battery into the holder. AGAIN, BE CAREFUL WITH 
THE ORENTITION OF THE BATTERY. At this point the lights on the front of the board should 
turn on and start blinking. Once the lights are flashing, plug the flash drive into the board. Once 
the computer recognizes the device, open putty, or Arduino IDE. If the computer does not 
recognize the device, follow the steps above to install the board libraries on the computer. This 
will also install the proper drivers. To monitor the device via Arduino IDE, simply select the 
proper port and then select port monitor. See above for button locations. 
To monitor via putty, Select Serial for the connection method, use windows device manager to 
find the proper com port in use, then select the com port in putty. Once selected, change the baud 
rate to be 115200. Finally click connect. 
Now that your output is coming through on the computer connection, location is completed by 
copy and pasting the gps coordinates into a location service of your choice. If you have a wifi 
connection, use google maps online. If a mobile device is used, apple maps or google maps are 
recommended. 
**ALL Screenshots provided by Ben Koopmann via Arduino IDE 1.8.19 
 
 
 
 
 
71 
 
Appendix B: Altus Metrum Telemtrum User Guide 
If you encounter issues or questions, Call Ben!!! 
Ben Koopmann 
618-402-XXXX 
 
Altus Metrum User Guide (Simplified): 
Congratulations on making it a rocket launch successfully. This guide will allow you to 
configure the device for your rocket launch. Before proceeding with this user manual, ensure 
you have the Altus Metrum PC Software installed. If you don’t, go find it and install it. You’re 
an engineering student so this should be a simple task for you. If you can’t find it, I’m going to 
give you a calculus problem to solve before giving you the link. Be sure to have a charged 
battery and the USB cable handy before beginning the configuration stage. 
Initial Configuration: 
 To perform the initial configuration on the device, Plug the supplied battery into the 
device. Att his point the device should not come on. Thereis a failsafe switch that needs to be 
activated by merging the two wiring connections on the pins labeled S. For bench testing, 
simply use a supplied jumper and connect one end to each of the pins. For launch site testing, 
ensure there are no black powder charges or motors connected to the board. If the board is 
mounted inside the rocket, simply flip the switch on the side of the rocket. If the rocket has not 
been inserted yet, follow the bench testing instructions. 
 
72 
 
THE MOST IMPORTANT PART IS TO ENSURE THERE ARE NO EXPLOSIVE CHARGES 
CONNECTED TO THE DEVICE WHEN TURNING ON. REPEATING, MAKE SURE NO 
EXPLOSIVE CHARGES ARE CONNECTED WHEN TURNING ON THE DEVICE. 
Failure to check this could result in an accidental discharge and possible damage or injuries. If 
the pins are properly jumped, you should hear a loud beeping noise to indicate activation. 
 At this point plug in the supplied USB cable and click configure altimeter in the software 
package. Once the configuration menu appears, enter YOUR callsign into the telemetry setting 
and select a channel. Make sure the option for broadcast telemetry is enabled and set your 
parachute charges accordingly. 
 
Receiver Configuration: 
To configure the transmitter, connect the blue module to the supplied antenna. I can hear your 
voice already saying the cable isn’t long enough, trust me, it is. Once the connection is made, 
decide what kind of device you want to use for flight monitoring, either a phone or a computer. If 
you decide a phone, flip the switch on the blue module and connect to the module via Bluetooth. 
After that your on your own. At the time of writing this, using this feature has not been tested for 
rocket club purposes. 
Connecting the device to a pc is done by flipping the same switch to turn on the device, then 
connecting it to the pc using the supplied USB cable. Next open the altus Metrum flight software 
and click view idle. At this point it will flash you to select the correct USB device. Once a 
device is selected, the menu for monitoring the flight will begin. 
73 
 
 
ProQuest Number: 
INFORMATION TO ALL USERS 
The quality and completeness of this reproduction is dependent on the quality 
and completeness of the copy made available to ProQuest. 
Distributed by ProQuest LLC ( ). 
Copyright of the Dissertation is held by the Author unless otherwise noted. 
This work may be used in accordance with the terms of the Creative Commons license 
or other rights statement, as indicated in the copyright statement or in the metadata 
associated with this work. Unless otherwise specified in the copyright statement 
or the metadata, all rights are reserved by the copyright holder. 
This work is protected against unauthorized copying under Title 17, 
United States Code and other applicable copyright laws. 
Microform Edition where available © ProQuest LLC. No reproduction or digitization 
of the Microform Edition is authorized without permission of ProQuest LLC. 
ProQuest LLC 
789 East Eisenhower Parkway 
P.O. Box 1346 
Ann Arbor, MI 48106 - 1346 USA 
30423344
2023Odd Behavior ..................................................................................................... 52 
Discussion ..................................................................................................................................... 53 
Overall Recommendations .................................................................................................... 56 
Moment of Silence for the electronic graveyard ........................................................................... 57 
Conclusion .................................................................................................................................... 61 
Future Work .................................................................................................................................. 62 
References ..................................................................................................................................... 63 
Appendices .................................................................................................................................... 65 
Appendix A: KoopaTracker User Guide ................................................................................... 65 
Appendix B: Altus Metrum Telemtrum User Guide ................................................................. 71 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
vi 
List of Figures 
Figure 1: Folding Wing Prototype for SIUE Cougar Rockets .......................................................................... 1 
Figure 2: Picture of Cougar Rocket's Cherry Bomb. Approximately 13 ft. tall. .............................................. 6 
Figure 3: T-Beam configured for Meshtastic. .............................................................................................. 11 
Figure 4: Meshtastic Network Design ......................................................................................................... 13 
Figure 5: Altus Metrum with Battery and Antenna ..................................................................................... 14 
Figure 6: Altus Metrum Antenna and Receiver ........................................................................................... 15 
Figure 7: Altus Metrum Network Overview ................................................................................................ 16 
Figure 8: Koopatracker Network Overview ................................................................................................. 18 
Figure 9: Koopatracker Transmitter Algorithm Overview ........................................................................... 19 
Figure 10: Koopatracker Receiver program overview ................................................................................. 20 
Figure 11: Koopatracker Relay Program Overview ...................................................................................... 22 
Figure 12: Example Testing Configuration ................................................................................................... 28 
Figure 13: Image of Antenna for Comparison ............................................................................................. 29 
Figure 14: Starting locations for module testing. ........................................................................................ 32 
Figure 15: Satellite view of testing area start locations. ............................................................................. 32 
Figure 16: Test Path 1 Satellite View ........................................................................................................... 33 
Figure 17: Test Path 2 Satellite View ........................................................................................................... 34 
Figure 18: Test Path 3 Satellite View ........................................................................................................... 35 
Figure 19: Test Path 4 Satellite View ........................................................................................................... 36 
Figure 20: Test Path 5 Satellite View ........................................................................................................... 37 
Figure 21: Test Path 6 Satellite View ........................................................................................................... 38 
Figure 22: LoRa Modem Calculator Tool provided by Semtech .................................................................. 43 
 
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222373
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222376
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222377
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222378
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222379
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222381
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222382
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222383
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222386
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222387
https://d.docs.live.net/a9d7507983e8e9b2/_SIUE%20Classes/___Thesis/Papere/Final%20Paper/Koopatracker%20development%20and%20comparison%20study.docx#_Toc135222390
 
 
 
 
Problem I want to solve: 
 
As a member of the SIUE Cougar Rocket Club, I have been fortunate to have the 
opportunity to participate in competitive rocket launch events for the past 4 years. Our 
competition, The Argonia Cup, is a rocket launch event in which each team attempts to launch a 
rocket to a pre-designated altitude before deploying a payload which directs a package, aka golf 
ball, back to a target location on the ground [1]. Although the problem may seem simple, it is 
truly a complex engineering challenge. Teams have turned to methods ranging from building a 
quadcopter in the nose, to building a glider that fits into the body of the rocket. For example, the 
SIUE team has developed a payload bay which can accommodate a folding RC plane that will 
fold together to fit inside a 5” rocket tube. 
 
Even though the target is close to the launch pad, the rocket is launched with an elevation 
angle between 83 and 85 degrees. During the preliminary testing for this study, the rocket’s 
landing position was over 2.5 miles away with light wind. Although this distance does not seem 
Figure 1: Folding Wing Prototype for SIUE Cougar Rockets 
2 
 
too far, the actual challenge of recovering the rocket comes after the rocket reaches apogee, the 
landing phase. After the rocket reaches apogee and payload is released, a parachute deploys to 
slow the rocket down and bring the craft to the ground softly (at least in theory). Some teams 
designate most of their resources to the payload and rocket design, that recovery sometimes can 
be lacking and occasionally regulations prevent them from implementing some recovery 
methods. We learnedthis after the Cougar Rockets went through the same process ourselves. 
Issues like this are not limited to Argonia Cup Competitors, but rather this issue applies to all 
levels of rocketry. 
For rocketeers without a telemetry transmitter, tracking the rocket as it descends relies on 
visually watching the rocket land, listening for a buzzer, and searching the area for bright colored 
parachutes [2]. A primary concern with this method is most launch sites are around hills or 
vegetation/trees which impar visibility. Operating more advanced rocket flight controllers which 
transmit telemetry and location information require a ham radio license [3]. Such style of 
requirement adds extra steps and costs for people wanting to participate and join the hobby. My 
vision with this research project is to find an alternative that would provide similar tracking 
abilities without the requirement. 
Why Current Solutions Fail 
 
To help with the issue of tracking rockets after they land, modern rocket flight controllers 
include the ability to send telemetry information. This information that gets shared allows users 
to monitor critical statuses for the rocket such as Altitude, Parachute status, and Battery charge, 
etc. [4]. Included with these devices are typically a Graphical User Interface or other user 
interface to make understanding this information easier. Unfortunately, this ability comes at a 
cost and there are additional regulations and restrictions. Most controllers are built using a lower 
3 
 
frequency (433 MHz) and use higher powered transmitters to allow for more range with the 
unfortunate side effect of requiring a Ham radio license to operate in the USA [4]. This solution 
is okay for those that have the proper licenses and equipment, but it is not as user friendly for 
those attempting to enter the hobby. People already must get a license to build and launch high 
power rockets, adding another certificate could be enough to scare people away. 
For those building and launching smaller rockets, methods for tracking the rocket after 
landing involve auditory or visual aids. Bright colored parachutes are common in model rocketry 
due to the ease of visually tracking rockets in the air and scanning the ground when they land. 
Another addition which requires a battery to be involved in the rocket design, is a buzzer that 
sounds after a pre-determined amount of time. Having an auditory signal along with visual can 
assist in locating rockets that land within close proximity of the launch site. Unfortunately, this 
does not assist with high power rocketry where rockets can land up to miles away from the 
launch point. 
 Off the shelf rocket flight controllers contain sensors to collect information critical to the 
flight path of the rocket. Some of these metrics include barometers, accelerometer, gyroscopes, 
and GPS modules [4]. As an alternative option to purchasing rocket flight controllers, off-the-
shelf asset trackers generic trackers only have one purpose, transmit its location. Trackers such as 
this often utilize satellite connections or cellular connections for communications [5]. The 
unfortunate downside of these trackers is there is no additional information to monitor the status 
of the rocket flight and there are additional costs in purchasing a data/cellular plan. Solutions that 
involve using LTE/cellular connections will have signal issues above such an altitude. This is 
due to the range limitation in terms of altitude [6]. In addition, the refresh rate can be a lot slower 
4 
 
on such devices. Some hobbyists are interested in these solutions because of their lack of ham 
radio license but their support for the model rocketry groups is limited. 
Solutions for Comparison for this project 
 
In this research project, I will complete a comparison study with three solutions for 
tracking model rockets and gathering telemetry information. Two of these solutions will not 
require a ham radio license, and one solution that will carry a ham license requirement along 
with being a current off the shelf solution as a rocket flight controller. The two solutions without 
the ham radio license are based on similar hardware, but the firmware is different. Overall, a set 
of tests will be performed on each tracker to determine its usefulness for our task of tracking 
rockets. 
Koopatracker is a solution designed and built for this comparison study. Instead of being 
based on a traditional fully connected mesh style network, it is based on a 
transmitter/relay/receiver network. A dedicated transmitter acts as a beacon which transmits the 
location for others to hear. A relay board acts as a relay without adding additional packets into 
the network unless it receives a packet. The receiver acts as a base station for receiving and 
transcribing the information received for the user. More details on the communication network 
will be provided later in this paper. The hardware for this solution is based on an off-the-shelf 
board created by a company called LilyGo [7]. Using this hardware, a solution is built and tested 
which does not require a ham radio license and could be a powerful contender in the current 
market. 
Meshtastic is an off the shelf mesh network communication protocol based on the same 
hardware as the Koopatracker but uses a fully connected mesh network and a pre-existing open 
5 
 
source project [8]. Although the use case for this network is to transmit text messages to other 
phones connected to the other boards, it also works as a GPS tracker if the software is slightly 
modified. Meshtastic comes with additional overhead and delays which will be discussed later 
in the paper [8]. The software package also includes a phone app which can be used alongside 
the handheld unit (t-beam with oled screen). One major difference is there is no direct base 
station or receiver station for the GPS information in this network, meaning a computer or other 
device is not strictly necessary. A cell phone or laptop is required for the initial setup though [8]. 
This setup is best designed for those who want an out of the box experience without any 
programming. 
Most high-power model rockets require a flight controller. This controller acts as the 
brains along with sensors to determine when to deploy parachutes, charges, and even store 
critical information about the flight [4]. The third device that will be tested in this comparison 
study will be the Altus Metrum Telemega. An off the shelf rocket flight controller that has the 
additional feature of a radio transceiver for telemetry. The transceiver for this project is 
programmed to send flight information such as location (from a built in GPS module), altitude, 
and status of the parachutes [4]. The advantage of this system is all the critical information in one 
device. One major downside of this unit is that a ham radio license is required for operation due 
to the frequency and power output of the transmitter [4]. More information will be given in the 
next chapter. 
 
 
 
6 
 
Literature Review 
 
Inspiration for this project/Cougar Rocket Intro. 
One of the inspirations for this paper revolves around the SIUE Cougar Rockets club and 
our challenge to build and execute a rocket launch for our competitions. As part of our 
competition, we launch rockets up to 8000 feet agl (above ground level) and deploy a payload to 
deliver a golf ball back to a designated target [1]. When most groups think of a rocket club, the 
first thought is the small rocket kits commonly found at stores designed for short (sub 200 feet) 
launches. Our rockets must be a bit bigger to reach 8000 feet while carrying a large payload. 
Figure 2: Picture of Cougar Rocket's Cherry Bomb. Approximately 13 ft. tall. 
7 
 
Above in Figure 2 the Cougar Rocket named “Cherry Bomb” is displayed during it’s developmentphase. At the time, this rocket stood approximately 13 feet tall. This small rocket may not seem 
too complicated, but there’s a lot of engineering and design that goes on inside. Using the proper 
motors, this rocket will travel approximately 790mph up to around 10,000 feet. During the 
competition, this rocket won the club 4th in the nation for our Argonia Cup Competition. 
One of the interesting challenges of this competition and a lot of model rocketry is the 
rocket recovery portion of the launch. As our rocket drops the payload and the separation occurs, 
team members are mostly focused on the payload delivery method and not as much the empty 
rocket carcass falling to the ground. Fortunately, the rocket does have parachutes which will 
deploy and bring the rocket to the ground gently (or at least in theory). After worrying about the 
status of the payload it’s time to start the next stage of the rocket launch, the recovery. 
Recovering the payload is hopefully simple because it should land near the group, but the rocket 
is typically a challenge. Unfortunately, most of the competition teams had to go searching for 
both the payload and rocket (Cougar Rockets included). Locating the payload and rocket carcass 
must be the next priority. The task of locating these payloads and rocket parts is the main 
purpose of this paper. 
Understanding model rocketry and all the specialty terms and legal definitions are beyond 
the scope of this paper, but a brief overview will still be provided to lay the groundwork for 
future discussions on the topic. Legally, an amateur rocket is defined as an unmanned rocket 
whose motor has less than 200,000 pound-seconds of energy and cannot reach an altitude greater 
than 93.2 miles above the earth’s surface [9]. This definition leaves some ambiguity as building 
a rocket to reach even 10 miles seems like an activity that not everyone should be doing. To 
ensure only people with the correct knowledge are performing actions like this, certification 
8 
 
levels are set up to ensure people working on these designs are qualified. There are three tiers of 
rocket certifications: Levels 1, 2, and 3 (Very creative naming scheme) [10]. Individuals that 
want to obtain these rocket certificates must pass a written knowledge test along with 
successfully building, launching, and recovering a rocket of that specific size/requirements [10]. 
Competitions involving Cougar Rockets typically required a level 2 rocket due to the size and 
complexity of the build. 
Throughout this paper, terminology regarding HAM radio will be discussed. 
Transmitters and parts used throughout this comparison study require a HAM radio license to 
operate. Ham Radio Operators, aka Amateur Radio Operators, must obtain a license to operate 
radios which meet a specific set of requirements. The Altus Metrum device that will be used for 
this study falls into HAM jurisdiction because of the frequency and transmitter output power. 
Licenses to operate these devices fall into three categories: Technician, General, and Amateur 
Extra. Each license type requires the candidate to take a test to test their knowledge to ensure 
their operations will be safe and not interfere with other operations. Each license allows the 
users to utilize different parts of the band and transmit with more power. It is common for 
people to utilize this type of device to communicate with people around the world. Investigation 
into this technology was included due to the Altus Metrum’s telemetry transmission system. This 
high wattage transmitter utilizes a frequency restricted to this select band. 
 Recently a lot of commotion has been created by a new communication method created 
by Semtech called LoRa (Meaning Long Range) [11]. Advertised as having low energy 
consumption along with long range, LoRa quickly gained popularity. In 2012, Semtech created 
the first end devices capable of utilizing this protocol [11]. LoRa Networks are split into two 
classes. First is the LoRaWAN network protocol which is primarily used for IoT (Internet of 
9 
 
Things) devices [12]. This network structure has features seen in traditional networking protocols 
such as Mac Addresses and security and routing layers [12]. Most of these networks connect 
smart devices and sensors to the internet or other services. The secondary protocol, aka aloha 
peer to peer communications, allows for multiple devices to talk with each other without the 
requirement of an internet or other backplane connection. Examples of this style include 
standard peer to peer or chip to chip communications. 
 An explanation of how this Chirp Spread Spectrum frequency works is required to 
explain the parameters and terms that will be used later in this paper. Background on Chirp 
Spread Spectrum (aka CSS) can be traced to frequency-shift keying (aka FSK) [13]. Modems 
utilizing this FSK protocol have the ability to convert varying frequency shifts into digital logic 
[14] This is how FM radio works. LoRa takes this methodology and further advances it with 
CSS. Instead of the frequency being defined as x hertz is digital 1 and y hertz is digital logic 2, 
CSS works by sweeping between the two frequencies [13]. Parameters configured inside the 
radio determine the behavior of the sweep. The Spreading Factor adjusts the speed of the 
frequency sweep [13]. Bandwidth is the amount of range that occurs during the sweep [13]. In an 
ideal world, having a massive bandwidth value would provide better quality, but unfortunately 
bandwidth is limited so regulations will not allow that. Using a larger spreading factor allows 
for longer range and better signal quality by being easier to process, but it will take longer for the 
data to transmit [15]. Preamble of the signal is a series of signal sweeps to allow other receivers 
to recognize this signal as a LoRa transmission [15]. Following the preamble, another series of 
bits are sent named the sync message. This sync message allows the receiver to sync timing with 
the transmitter. In the configurations for this project, after the sync message is sent, the data 
packet will be sent followed by the crc for potential error correction. Each frequency shift sent 
10 
 
represents 8 bits of data with the data being encoded into the timing and behavior of the shift 
[15]. Optimizing the radio parameters for a user’s specific use case can have drastic effects on 
the result of the network. If higher speed is required, the spreading factor can be reduced, and 
bandwidth increased. If lower speed and ultra long range is required, the spreading factor can be 
turned up and bandwidth decreased. 
During the development phase of the Koopatracker network, a lot of research went into 
different types of mesh networks architectures. Three main network topologies came out of this 
comparison. Point to Point (not mesh network but still needed for comparison), Fully Connected 
Mesh, and Hybrid Mesh Architecture. Point to Point was added into the comparison because the 
devices typically used for Koopatracker are programmed for Point-to-Point communication. 
Point to Point is also known as Peer-to-Peer communication and typically is implemented with 
two devices talking to each other and no 3rd party devices. A fully connected mesh network has 
the characteristic of having all of the devices in the mesh connected to each other. This means all 
the devices will receive every message sent throughout the network. A hybrid mesh network 
allows for the network to be segmented and add some separation. Meshtastic utilizes a fully 
connected mesh network while the Koopatracker was built on a hybrid network topology or 
some may call it a relay network. In the latest version of the software, there are three parts of the 
network. First the transmitter is responsible for transmitting the telemetry data. Receivers area 
module connected to a computer. Relays act as an in between and forwards messages from 
transmitters to receivers. Another perspective is a range extender for the network. As 
Koopatracker was developed, the main goal was to have the entire network be quick and as little 
overhead as possible. 
11 
 
Meshtastic 
 
Meshtastic is an application and protocol developed to be an open-source decentralized 
mesh network that will run on low power devices such as the ESP32 or t-beam. The latter will be 
used for this project. A fully connected mesh architecture is used for this device with the 
inclusion that devices outside the typical range can be connected to the mesh using one node’s 
connection to the mesh. 
 
Figure 3: T-Beam configured for Meshtastic. 
Hardware for the Meshtastic network relies on small low power devices such as the t-
beam. Above in Figure 3 shows the t-beam used for this project. An ESP32 microcontroller is 
12 
 
hidden under the screen. Also attached to the board is a LilyGo LoRa transceiver and a Ublox 
GPS system [7]. On the back of the device, an 18650-battery holder and corresponding battery 
management system allows for the device to be self-powered [7]. The built in charging circuit 
takes the USB input to power the board and charge the battery [7]. One advantage of the t-beam 
is there are no phones or external devices required. The OLED screen attached to the device can 
display all the relevant information. 
The communication algorithm for the Meshtastic network has four layers [16]. First, 
Layer 0, is the LoRa Radio Layer [16]. This layer is responsible for converting the rest of the 
layers to the correct protocol for radio transmission. Another responsibility of this layer is to add 
the preamble and synchronization bits to the message before transmission along with 
distinguishing the specific network in use [16]. Layer 1 is responsible for unreliable zero hop 
messaging [16]. Unreliable meaning the message is sent out without the expectation of receiving 
an acknowledgement packet back from the mesh [16]. Layer 2 differs from layer 1 by requiring 
an acknowledgement packet. Layer 2 is also referred to as the Reliable Zero Hop Messaging 
Layer [16]. Sending a message with this layer will take additional time. A Layer 2 message adds 
the reliability feature ONLY for its immediate neighbors. If a response by another node is not 
received within a given amount of time, the node will attempt to re-send the packet up to a user-
defined maximum. After a message is received by another node via Layer 2 if re-transmission 
throughout the mesh is required Layer 1 will be utilized [16]Layer 3 is responsible for the 
network flooding protocol [16]. Initially, Meshtastic was built as a disaster radio network. One 
important requirement was adding the ability to send a message to every possible node in the 
network [16]. For example, if a disaster occurred and a new warning had to be sent out, the 
flood protocol would ensure as many devices as possible would receive the message. The first 
13 
 
node would send out the message, and all devices that received the message would then re-
transmit the message to all devices within its range. 
 
From the figure above, the advanced use case of this network can be observed. If the two 
nodes on the right represent the use case for most of the testing. One t-beam would be mounted 
inside the rocket while a mobile device was within range to receive the messages. In a more 
advanced setup, one mobile device can receive location data from multiple rockets. At this point, 
the mesh portion of the network can be more useful. In an ideal situation, the devices can pass 
around the location data for the other rockets to the other search teams. An addition like this 
would be revolutionary for the model rocket industry. 
 
 
 
Figure 4: Meshtastic Network Design 
14 
 
Altus Metrum 
 
Altus Metrum is a company which produces rocket flight controllers. Essentially, it’s a 
device which allows users to control parameters for a rocket launch. 
Such parameters that may need to be adjusted include the main/drogue parachute deployment 
altitude, motor ignitor sequencing, and black powder charge timing/altitude selection. All these 
parameters are vital for the safety and proper performance of high-power rocket launches. 
Figure 5: Altus Metrum with Battery and Antenna 
15 
 
 
From the two images above, the entire Altus Metrum system is shown. First the device 
itself is small. It contains an STM32 microcontroller, 433 MHz Transceiver, GPS, among other 
peripherals required for the rocketry related functionality [17]. The blue device attached to the 
antenna is the actual receiver. Users can connect to the receiver from their smartphone or laptop. 
Figure 6: Altus Metrum Antenna and Receiver 
16 
 
For this comparison study, the Altus Metrum TeleMetrum device for one point of 
comparison because it has become a standard in the model rocketry market. A software package 
is included with this device which allows working and monitoring this device to be very easy and 
somewhat user friendly. The main drawback of this device from a new user perspective is the 
specialized hardware and licensing required for operations in the USA. Because this device 
operates at 433 MHz, a specialized antenna (sold by the manufacturer) and receiver are required 
to interface with this software package along and transmitter combo [17]. Operating at 433 MHz 
and utilizing a 5-watt transmitter also installs a new requirement that users must have or obtain a 
ham radio license to use the telemetry system. [17] These components are to give the rocket team 
the best possible chance of finding the rocket once it lands. 
For this testing, the Altus Metrum Telemetrum will be referred to as just Altus Metrum. 
This decision was made due to the same transmission system being used across all variants of the 
board with the only difference being the amount of black powder charges it can utilize. The 
overall design of this telemetry system is mostly simple. There is a rocket which contains the 
Altus Metrum with a built-in telemetry system and transceiver [17]. A receiver and antenna are 
used on the ground to capture the signal and transfer it over to the mobile device. This mobile 
device can either be a mobile phone running the correct application, or it can be a laptop running 
Figure 7: Altus Metrum Network Overview 
17 
 
the specific software package provided by the manufacturer [17]. In the case for all relevant 
testing, the laptop option will be used due to potential compatibility issues with certain cell 
phones. 
Configuration for the Altus Metrum will be the manufacturer provided configuration. 
The only custom configuration input will be the ham radio license which is required for its 
operation. All relevant radio options will be enabled. The radio communication protocol 
documentation is vague due to being proprietary to the company. Overall, this device was used 
as the average user would for a high-power rocket launch. 
 
Koopatracker 
Throughout this project the Koopatracker system was developed and tested. 
Koopatracker takes inspiration from both the Altus Metrum and Meshtastic and creates a best of 
both worlds’ situation (at least in theory). The hardware used by the Metastatic network was the 
ideal package for most model rocket applications. It’s self-contained and has all of the essential 
components built in along with the ability to add more using the exposed GPIO. One hardware 
component removed for the Koopatracker was the OLED screen on the transmitter. On the 
receiver, displaying the information is of no because the device is sealed inside the rocket tube, 
so it consumes additional electricity. 
18 
 
 
Figure 8: Koopatracker Network Overview 
Overall networkarchitecture for the Koopatracker is built on a hybrid mesh system. One 
t-beam module inside the rocket will act as the transmitter and will only transmit telemetry 
information. Another t-beam will be connected to a computer which acts as receiver. While 
acting as a receiver, this device will be responsible for receiving the signal and sending the 
interpreted information back to the computer serial interface for the user. A third module will act 
as a relay. Essentially a device that receives the telemetry information from the rocket’s 
transmitter and re-transmits it for other receivers in the area. The above figure shows this 
mechanism in action. As rocket 2 passes over the hills, it’s signal range gets limited and does not 
reach the green receiver. The relay module can act as a message forwarding system to pass this 
19 
 
information back to the chase crew/receiver so the rocket can be recovered. In future use cases 
for this system, relay modules could be placed strategically around the area where the rocket 
launch to provide a wider coverage area for safety monitors and launch crew members. 
 
Figure 9: Koopatracker Transmitter Algorithm Overview 
20 
 
Koopatracker’s transmitter algorithm is shown above. Initially the program gets 
triggered by the device getting connected to battery power. A startup procedure then starts and 
preps and calibrates the sensors, transmitters, and GPS system. Part of this calibration is waiting 
for the GPS signal to have a valid lock. Before the system can start sending the signal, the 
transceiver listens to the channel it is about to transmit on and listens for another packet getting 
transmitted. After waiting for a pre-determined number of milliseconds plus a random value, the 
packet is then sent. After the packet is sent and the transmitter returns a success status, then the 
program waits for a pre-determined amount of time before gathering the new sensor data and 
repeating the collision avoidance procedure followed by sending data. The program only ends if 
the system looses power or if certain errors occur within the code. 
 
The receiver system must be a bit more advanced to account for more moving variables, 
aka rockets. Initially the device is powered on by the battery or USB cable getting connected. 
Again, the system prepares and calibrates the sensors, completes preliminary checks on the LoRa 
transceiver, and waits for a valid GPS signal in the background. Waiting for a valid GPS lock in 
Figure 10: Koopatracker Receiver program overview 
21 
 
the background is different compared to the Transmitter. A valid GPS lock is not required for all 
of the receiver features. Any left-over information in the incoming data queue is cleared, then 
the receiver starts listening for packets. It’s a boring life listening for messages that may never 
come, but after one does arrive the packet information is extracted and placed into a processing 
queue. Once the information is placed into the queue, the transmitter listens again for incoming 
messages. If another message is arriving, the new message is received, and information 
extracted and placed into the queue. This process is repeated until there is a break from 
incoming messages. Once there is a break, the transmitter temporarily stops listening to allow 
for the queued information to be sent back to the computer via USB serial interface. Having the 
queuing system helps to ensure the greatest number of packets are received. After the messages 
are sent to through the USB serial connection, the information is displayed to the user using a 
custom python script. The program running on the pc is closed when the user exits out of the 
program or serial is interrupted. Like the transmitter, the receiver code only shuts down after an 
error in the code or the system loses power. 
22 
 
Koopatracker’s relay system works similarly to the transmitter and receiver. The startup 
sequence is initiated by connecting power to the device. System sensors, transceiver, and GPS 
systems are readied. GPS lock is required for this program. Storage memory is allocated so the 
device is ready to go. The receiver system listens to the void to detect any packets from the 
rocket transmitters. Once a packet is detected, the telemetry information is extracted and placed 
into a queue. If new packets are detected, the process is repeated until there is a break. Once 
there is a break the packets must be sent back into the void to the receivers (in theory). When 
Figure 11: Koopatracker Relay Program Overview 
23 
 
packets are being retransmitted, incoming packets cannot be received. So only one packet can be 
re-transmitted with information before re-looping back into the receiving loop. Packet 
retransmission will happen again once new incoming transmission packets are not detected. 
To prevent all these devices from talking over each other, collision avoidance was added 
into every transmission code. If all the devices were to transmit over top one another, most 
receivers would not be able to decipher the information. (Future updates may change this) 
Before any transmission can occur, the device must listen (aka receive) signals from the channel 
to determine if another device is using this frequency [18]. It must listen for a hardcoded number 
of milliseconds plus a random number generated. Determining the maximum random number is 
based on the maximum transmission time for the largest possible packet. After waiting for this 
time, the transmission can continue. This system is based on the Carrier Sense Multiple Access 
with Collision Avoidance algorithm [18]. A similar algorithm is also used in the Meshtastic 
algorithm. 
To prevent an endless loop when multiple relay modules receive the same packet or each 
other’s packets, a parameter is passed through each packet sent from a relay to specify it’s 
source. One byte is added before any telemetry data is transmitted. Each module can receive 
checks for this byte during the processing of the information. In this case, 0b00 means it’s 
coming from a transmitter and 0b01 means it comes from a relay module. If a relay receives 
another relay packet, it will not forward it on. Future iterations of this code could change this to 
account for multi-hop networking capabilities. 
 
24 
 
Data Collection Method 
During the initial development stages for Koopatracker, data collection was a struggle. 
The location data received from the network was displayed with extra information along with 
being a txt file instead of a csv file that is easier to manipulate. To counter this, multiple avenues 
were investigated to find the optimal way for achieving this goal. Initially the method of taking 
received information from the network and having the microcontroller export the data to a csv 
file worked, but the solution was slower and not optimal for future use cases. Ultimately, the 
data format used for transmission changed so the transmitter would align the data correctly 
before transmission. It caused a minimal delay and the best outcome for allowing other features 
to utilize the information. 
After the data was being received from the network in an optimal data format, it was time 
to find a way to utilize the information. But first we had to get the data from the microcontroller 
to our python environment. This is where PySerial came into play [19]. PySerial is a library 
developed to simplify the process of connecting python applications to external serial sources. 
To achieve the physical connection, a USB cable was plugged in from the T-Beam device 
(Koopatracker device) into a port on the computer in use. PySerial, once configured, allowed for 
the data to be read into a python script for future use. 
 As data is gathered from the network via a python script, storing this data is stillnecessary to utilize this data in our later analysis of the performance. A MySQL database was 
configured to accept data inputs from the python script. This script was particularly useful 
because the data could be read in by multiple devices to one database (but separate tables). 
Multiple data inputs allowed for each sensor to forward its reading so analysis would show if 
there were any differences between the devices. 
25 
 
Now we have the stored data, some analysis would be helpful around this point. To start 
the analysis perspective, a tool called qgis will be utilized. Data from the above database can be 
queried and only information we want can be forwarded into a separate csv file. The primary 
information needed from the database is the time of capture and the latitude and longitude for 
locations. After the csv is generated (and is updated as the database is updated) it is then put in a 
common place where the qgis software can access it. Qgis is a tool which allows for plotting of 
locations on satellite maps and performing other GIS related analysis [20]. The software can 
read in a csv file that is live updating and plot the locations on the map. Using a tool like this 
allows for real time perspective on range performance. Having a real time view of range 
performance allows developers to predict what parameters may need to be adjusted for better 
performance. 
Hardware Overview 
Koopatracker 
The initial idea behind Koopatracker was an easy-to-use solution which only required 
hardware that was openly available for purchase. Aka users didn’t need special equipment or 
spend lots of money for a solution for rocket tracking. This is especially important when dealing 
with users that may be new to the hobby and do not want to commit multiple hundreds of dollars 
on something they may not use again. Koopatracker is built on a microcontroller product sold by 
LilyGo called T-Beam [7]. This microcontroller contains an ESP32 microcontroller with two 
cores, LoRa module for communications, and a GPS module for location information [7]. Also 
contained within this unit is a power control unit, battery charge controller and an 18650-battery 
holder, meaning this device is capable of being used without the need to be plugged into a 
computer [7]. One extra accessory added to this board is an OLED display to allow for statistics 
and information to be shared without a computer. 
26 
 
Meshtastic is based on the same microcontroller as Koopatracker. Due to its accessibility 
in purchasing and esp32 based microcontroller, the platform has gained popularity in IOT device 
Projects. Meshtastic does not require the OLED display be added onto the board, but it is 
recommended because of the information that could be shared using the display [8]. A note to 
keep in mind: Meshtastic is a software package for these boards, they do not manufacture these 
boards. This means the software is the main differential. One benefit of this is to see if modifying 
the parameters of the 
The company Altus Metrum is well known for their rocket flight controllers. These flight 
controllers can control certain aspects of the rocket’s flight such as when to deploy the drogue 
parachute, black powder charge ignition, and recording flight telemetry [17]. If this hardware 
fails during a flight, the results will be catastrophic. Hardware wise, it is more complicated than 
the T-Beam used above. A STM32 microcontroller is the brains of the operation along with 
altimeter and other sensors. Extra functionality this board contains compared to others is the 
ability to detonate black powder charges and the required sensors for telemetry. The board uses a 
5W 433Mhz transmitter to send the gathered telemetry back to the host [17]. A wire is soldered 
to the board to act as the antenna. 
 
 
 
 
27 
 
Testing Procedure 
To keep the testing procedure fair for all devices and networks, a standardized set of tests 
and procedures were developed. Some of these pre-determined tests include paths for range 
tests, antenna selection, and test vehicles. Careful thought must be given to ensure all tests are 
equal fights for all test subjects although this may not always be possible. For example, trying to 
keep a battery test fair when the t-beam devices and Altus Metrum are different sizes and use 
cases is more difficult. The following chapter will describe the final version of these procedures. 
Antenna Orientation 
Across all networks being tested, the biggest challenge was deciding on how to range test 
the devices. During a typical rocket launch, the transmitter is inside the rocket and sitting 
horizontally inside a field. To keep the testing proceedings fair to real life situations, similar 
procedures were put in place except for a transmitter sitting in a rocket tube. The module acting 
as the transmitter would sit horizontally on a table with the antenna having an unobstructed 
visual to the atmosphere. 
One exception to the antenna orientation was the antenna sensitivity comparison tests. 
This test focused on raw range estimations, as such for each antenna comparison, the antenna 
28 
 
and module were attached to a tripod with the orientation facing vertical for greater possible 
sensitivity. 
 
Figure 12: Example Testing Configuration 
29 
 
Although results from this test were used to determine which antenna would have a 
greater chance of recovering the rocket during real world situation, it could also be used for 
determining antenna configurations for other projects, so all fairness was granted. 
Figure 13: Image of Antenna for Comparison 
For this round of tests, three antennae were compared. All three are specified to be for 
915 MHz, as this is the primary frequency used for this testing. The far-left antenna has a gain of 
3db, middle is 6db and the right is a 9db. The primary difference between the 3db and 6db 
versus the 9db is the later is built for outdoor applications and is encased in a waterproof 
container to allow for various mounting conditions. 
 
30 
 
Weather 
In an ideal world, all of these tests would take place under the exact circumstance. For 
this research, weather would not always work in our favor. Due to delays, parts of these 
experiments had to be halted and continued other days. To ensure that these tests were fair, a set 
of rules were put in place for determining when to run a test. Sunny or partly clear skies were 
required to ensure the chances of rain were minimal. Temperatures had to be above 40 degrees 
but below 90 Fahrenheit to ensure device performance was not impacted due to cold or hot 
weather. During testing when UAVs would be involved, it was required for wind to be below 
20mph gusts to ensure a safe flight. Overall, these requirements were met enough to not have a 
major impact on testing, although certain weeks of the winter months did not allow for testing. 
Driving procedure 
For testing that involves driving, a set of procedures were developed to ensure the tests 
were fair. Unfortunately, these types of tests are hard to keep consistent due to public roadways 
having people that actually use them. Fortunately, the area used for testing had roadways that 
had somewhat consistent traffic patterns. To ensure tests were completed in a fair fashion, a pre-
testing route was driven to ensure no impacts would take place. Such impacts include pedestrians 
biking carelessly on the roads, automobiles causing road delays, wildlife, or other events that 
required roads to be closed. When driving the test routes, a consistent speed would be ideal, but 
this is not always possible due to speed limits and road types. We are still required to follow the 
law, even if we are doing it for science. To help counter these effects, the route would be 
repeated multiple times. Each route would be repeated 3 times pertest to ensure a fair test. An 
average speed of 40mph was set as the goal for testing. The same vehicle was used for all testing. 
A Mazda Miata without the roof or the bed of a pickup truck allowed for antenna to have 
unobstructed access to the outside and mitigating the risk of signal blocking and interference. 
31 
 
Along with allowing for a fair test, this also accounts for the speed of a strong wind blowing the 
rocket around, an important characteristic to watch on these tests. 
Battery Test Procedure 
During battery life testing, consistent environments are important for a fair test. Before 
testing, all batteries were fully charged using their supplied charger to their respective max 
charge. After all batteries signaled a full charge and all materials for the testing are prepared, 
duration testing can proceed. Batteries are plugged into their respective devices with similar 
parameters for operation. Devices are powered on and put into transmitter mode. For the case of 
the altus Metrum, flight mode is enabled to replicate the parameters of being inside the rocket 
upon launch. Koopatracker is to be configured as a transmitter to replicate the rocket module. 
Meshtastic is to be configured as a tracking module. A clock is placed next to the modules and 
video camera set up, so the three modules and clock are in frame. Press record before starting the 
modules. This ensures the exact duration can be calculated in post processing. These procedures 
helped to ensure a fair battery testing phase. 
Range Test Paths 
Before starting range testing, dedicated paths were determined to ensure all tests were fair. 
Initially there were two paths, but as devices started to successfully complete the longest 
distance, additional paths were added, and current positions were modified. In total, 5 test paths 
were created and used to determine the max range. After considering the amount of possible 
interference from the surrounding neighborhood, two starting locations were chosen and should 
be used according to the desired test. Below the satellite view of the decided locations are 
shown. All images were generated in QGIS via Google Maps Satellite Imagery. 
32 
 
 
As apparent in figure 1, the two yellow dots on the lower right corner of figure 1 depict the two 
starting locations picked for this experimentation. All test paths will take place to the south of 
those dots, so placing the transmitters or receivers on the top dot would result in additional 
Figure 15: Satellite view of testing area start locations. 
Figure 14: Starting locations for module testing. 
33 
 
interference. Test paths north of the neighborhood would result in interference due to houses and 
other obstructions. Figure 2 shows a closer view of the test location setup. The front yard of the 
house will be used for initial functionality testing along with the 6th path for excessive 
interference testing. The lower dot in figure 2 depicts the location for all other testing. When 
setting up testing locations, a plastic table will be used to elevate the devices off the ground to 
prevent accidental damage. 
Test path 1 
 
 
Figure 16: Test Path 1 Satellite View 
 
Test path 1 was designed to be short and simple to ensure basic functionality. A simple 
test path through the neighborhood will allow to confirm the modules are working at a baseline 
level. With the modules sitting in the front yard, the receiver should be within line of sight which 
should not be an issue for any of these long-range transmitters. There are no major altitude 
differences to keep in mind. 
 
34 
 
Test Path 2 
 
 
Figure 17: Test Path 2 Satellite View 
Test path 2 focuses on shorter distance testing. Along this road is wilderness and minimum 
interference. The primary interference sources would be blockage from trees. Line of sight is 
not achievable (primarily due to the trees), but elevation is approximately the same across the 
entire path. Total distance is approximately 1.56 miles. Path 2 provides a good test for overall 
functionality along with providing similar environmental variables given in a real rocket launch 
situation. 
 
 
 
 
 
35 
 
Test path 3: 
 
Figure 18: Test Path 3 Satellite View 
36 
 
Test path 3 introduces some of the first real challenges for these devices, hills and houses. As the 
devices passed the 1.5 miles test with ease, it was time to utilize what was originally the last test 
path for testing. Fortunately, after running this test, additional paths were required for further 
testing. During this path, a large hill interferes with the signal along with the path intersecting 
with the city. Resulting in a path that contained additional interference from surrounding 
environment along with physical obstacles for signal propagation. 
Test path 4: 
 
Figure 19: Test Path 4 Satellite View 
As additional stress tests were needed, test path 4 was born. This path continued on test path 3 
and continued through town into the country and around back roads back to the house. This test 
proved to be challenging for the devices, but additional stress was needed. The max distance for 
37 
 
this test was 3.4 miles. An additional challenge for this path was the inclusion of additional city 
driving. This resulted in additional vehicles, houses, and other obstacles distribing the possibility 
of line-of-sight transmissions. 
Test Path 5: 
 
Figure 20: Test Path 5 Satellite View 
Test path 5 was a distance test that was unintentional but also successful at the same time. At the 
time of testing, my truck needed an oil change, so I took my car to the local Valvoline shop. As I 
was driving through town, the modules were sitting in the back of my truck running while the 
technicians worked on my vehicle. After completing the oil change, I looked at the data and 
realized that the max range was found on the way to/from the oil change location. More details 
later in this paper. 
38 
 
Test path 6 
 
Figure 21: Test Path 6 Satellite View 
This test path explicitly included the most amount of natural interference possible, aka vegetation 
and trees. This was done to stress test the communication protocols to determine if operations 
could continue with added noise and low signal strength. Forcing the transmitter to be 
obstructed by the small community of houses and large trees prohibited line of sight 
performance. This test path was useful for deciding recommendations later in this paper. 
 
 
 
39 
 
Specifics of Koopatracker 
In an ideal world, all trackers would be set to a uniform set of protocols and rules, so testing is 
fair. Unfortunately, the world responded by saying life isn’t fair. Throughout testing, parameters 
for the Koopatracker network were tweaked to optimize performance. Factors changed include 
the spreading factor, payload breakdown, and bitrate. Payload breakdown will not have a major 
impact on performance, but the other two factors will impact performance, primarily range. 
After the range testing started, parameters did not change otherwise the previous testing would 
become invalid. 
Initially there was a plan to test this network using a UAV. Unfortunately, this plan was scrapped 
shortly after the mounting mechanism caused a catastrophic failure in the UAV propulsion 
system. Prior to the initial test run, a procedure was developed for aerial testing. Before the 
driver of the vehicle started moving, the uas would be flown to an altitude of 250 feet agl and 
initial communication confirmed. After confirmation, the driver would then start driving the 
desired course. The UAV system would be configured as a relay, meaning that in short distances 
the receiver and relay would both receive the packets. After the device lost communication with 
the receiver, the relay system would then be able toreceive the packet’s assuming reception was 
still possible. A second person would be necessary to ensure the uas flight has no issues and can 
take control of the system if the autopilot decides to act up. 
Specifics of Meshtastic 
Meshtastic was quite simple to set up from a configuration decision standpoint. We are not as 
focused on speed in this study, so slower transmission times were acceptable. For this test, the 
slod and long mode was selected. Long refers to the desired range of the network with choices 
either being short or long. Short distance is not necessarily beneficial for this testing, so long was 
the chosen one. After the network speed/range is selected, users can select the desired mode for 
40 
 
the network. In this case, the mode of tracking was selected so the network would act as a 
tracking system. Unfortunately, the tracking mode comes with a default refresh rate of 15 
minutes. A bit too long for this study unfortunately. Settings were then configured to refresh the 
locations for the network every 30 seconds. Not as fast as other options in this study, but still 
faster than the defaults. 18650 battery packs were always connected to the modules for testing. 
Overall, in reference to selecting test parameters compared to Koopatracker, this was the 
shortest. 
Specifics of Ham Radio 
The Altus Metrum rocket flight controller contains a built-in protocol for data transmission 
utilizing the 433 mhz spectrum. Data telemetry is already programmed into the module and little 
configuration is necessary for testing. While setting up the device, users must enter their ham 
radio license id to enable the feature. This requirement ensures that the user is properly certified 
to operate the device before enabling the transmitter. Once the ID is entered into the system, 
users must select an available channel then the device is ready for data transmission. As soon as 
the device is restarted the data recording and transmission begins. A SDR provided by the 
manufacturer is connected to a cell phone or pc running the proper software/app and data 
communication can continue. 
Results: 
LoRa Configuration 
For the first round of experiments was conducted to determine the initial LoRa 
configuration for the Koopatracker development. To do this, three main parameters that directly 
link to the data transmission must be considered: Spreading Factor, Bandwidth, and pramble. 
Spreading Factor primarily determines the amount of time spent transmitting the information by 
changing the speed that the signal frequency changes across the bandwidth of a channel. 
41 
 
Bandwidth determines the transmission link’s speed rating. Preamble will help with the usability 
of the data transmitted at longer/noisier ranges by better allowing the transmitter to detect each 
transmission. These tests will be completed using physical testing along with mathematical 
calculations to determine theoretical benefits. Using the results of this round of experiments, an 
initial configuration for these three parameters was able to be determined. 
Spreading Factor testing was the first experiment to be performed using the same test 
paths discussed later. An initial goal for this experiment was to determine the range impact 
would be using three different spreading factors. From prior research and knowledge, the 
hypothesis before testing was that higher spreading factor resulted in higher range. Parameters 
considered for this experiment were SF6, SF8, and SF10. Between each test round, the boards 
used were programmed with the new parameters. Below the range comparison is shown. Please 
note that these tests were performed before the more complicated data collection system was put 
in place. The rest of the parameters for the LoRa configuration were left at the default values. 
 
 
 
 
 
 
 
42 
 
Table 1: Spreading Factor Test Results 
Spreading Factor 
Test 
Number 
Max Range 
(miles) 
Average Max 
Range 
SF6 1 1.97 
 2 1.82 
 3 1.46 
 4 1.61 
 5 1.44 
 
 1.66 
SF8 1 2.48 
 2 2.31 
 3 2.65 
 4 2.53 
 5 2.55 
 
 2.504 
SF10 1 3.32 
 2 2.71 
 3 3.27 
 4 3.49 
 5 3.11 
 
 3.18 
This table describes the results of the spreading factor test. We can see an average 
increase of 0.844 miles between SF6 and SF8 versus a 0.676-mile increase in max range between 
SF8 and SF10. Overall, there is more variation in the results compared to what was expected. 
Initially the results were expected to be closer together, but environmental factors could be 
affecting the real-life range. Using the results of this experiment, we can now determine the 
initial condition of spreading factor 10 for future experiments. 
The impact of modifying the bandwidth primarily affects the data transmission speed. 
From prior research, the higher the bandwidth the lower the range [12]. Knowing the future 
implementation of the network, the more pertinent limitation will be the on-airtime restriction. 
With the legal limits of other potential implementations in mind, on airtime was to be limited to 
400ms [12]. To simulate the on-air impacts of various bandwidth settings, a tool created by 
Semtech (the manufacturer of LoRa transmitters) will be used, specifically the on-air time 
43 
 
characteristics function. Below in Figure 22 we can see what the results of various bandwidth 
will be given the initial condition of Spreading Factor SF10. The goal of this experiment is to 
find the lowest bandwidth (to optimize range) while maintaining the sub-400ms on airtime. 
 
Figure 22: LoRa Modem Calculator Tool provided by Semtech 
Above shows the output of the Modem Calculator Tool. The screenshot is provided to 
understand where the measurements came from. Bandwidth (highlighted in blue) contains a 
dropdown box that shows all of the possible bandwidth options for our application. 
 
 
44 
 
Table 2: Bandwidth Comparison Study Results 
Spreading Factor Bandwidth Coding Rate 
On Air-
Time 
10 500 3 193.02 
10 250 3 386.05 
10 12.5 3 722.1 
10 62.5 3 1554.19 
From the table above, we can see the major changes to On-Air time from the bandwidth changes. 
In an ideal situation where the project wouldn’t be used in other countries or on other 
frequencies, we could choose 62.5, but for our use case a bandwidth of 250 must be selected. For 
future experiments, a bandwidth value of 250 will be used. 
Preamble is a parameter used to “match” a radio transmission when extra noise is 
transmitted around the same frequency. Another way of describing it is giving the 
transmitter/receiver a better way of syncing the transmission and receiver. This parameter has an 
impact on the usability of the received packet at longer distances. Ultimately this will have an 
impact on the transmission time so we must re-run the calculations from above before we 
continue to range testing. 
Table 3: Preamble Effect on On-Air Time 
Spreading Factor Bandwidth Coding Rate Preamble 
On Air 
Time 
10 250 3 5 357.38 
10 250 3 10 377.86 
10 250 3 15 398.34 
10 250 3 20 418.82 
As we can see there is an impact for a higher preamble. Ultimately the preamble is set to 15 to 
maximize the benefit. For future experiments, preamble will be set to 15. 
Base Range Test with Varying Antenna 
Before the testing began, multiple 915mhz antenna were acquired to determine the 
optimal antenna combination. The primary inspiration for this experiment comes from 
45 
 
applications in the Cougar Rocket Club and their efforts to track the rockets using the T-Beam 
modules before the Inception of Koopatracker. At a competition, one team had a Yagi antenna to 
track their module while another team used a omnidirectional antenna and it raised the question 
of the performance difference between the methods. For our use case, an omnidirectional antenna 
is optimal due to the simplicity