Caption:
Refocusing on code to fix app–carrier connection issues and protect our timeline.

Description:
After trying multiple times to connect the carrier to the app with no success, we realized we were just repeating the same steps and hoping for a different result. Instead of continuing to retry the upload, we stepped back and carefully reviewed our code together. We walked through it line by line, checking how the carrier was initializing, how it was attempting to connect to the network, and where the communication process might be breaking down. As we talked through the logic, we started to see that the issue was likely in how the connection was being configured rather than in the hardware itself. That shift in thinking helped us move from frustration to clarity. It became less about “why isn’t this working” and more about “where exactly is the breakdown happening.”

PLTW Step:
Identify Problem and Plan because we redefined the issue from a general connection failure to a specific coding and configuration problem, and then created a focused plan to address it.

Outcome:
We stopped wasting time on repeated attempts, gained a stronger understanding of our system, and set ourselves up to restore communication without falling behind schedule.

Caption:
Resolving open-network complications to restore full system connectivity.

Description:
Once our code was functioning correctly, our next obstacle was connecting both the phone and the carrier to the U-46 guest WiFi. Although the network does not require a password, that actually created confusion during setup. Because it is an open network, some devices require additional confirmation steps or security acknowledgments before completing the connection. At first, it appeared as though the WiFi was working, but the carrier was not fully authenticating onto the network, which prevented communication with the app. We had to carefully review each device’s network status, refresh connections, and ensure both systems were truly connected rather than just displaying the network name. This forced us to slow down and think more critically about how open networks handle access and permissions.

PLTW Step:
Test and Evaluate because we verified that our software was operating correctly and then systematically diagnosed an environmental connectivity issue affecting system performance.

Outcome:
By confirming that both the phone and carrier were fully authenticated on the U-46 guest network, we restored communication and cleared a major barrier to continued testing.

Caption:
Attempting controlled home-network testing to diagnose persistent command errors.

Description:
After finally getting both the phone and the carrier connected to the U-46 guest WiFi, we expected the system to respond smoothly. Instead, every time we pressed a control button such as pause, forward, backward, left, or right, the app returned an error message. The connection looked stable, but the commands were not executing, which suggested that the issue was deeper than simple pairing. We began to question whether the open guest network might be limiting certain types of communication or data exchange between devices.

To isolate that variable, we brought the laptop home so we could test the system on a secured, encrypted home network. Our thinking was that a private network would remove possible guest-network restrictions and allow clearer device-to-device communication. However, once home, we ran into another complication. The school-issued laptop was restricted by administrative controls, which prevented us from freely connecting to our own home WiFi network. What was meant to be a clean comparison between networks turned into another lesson about external system constraints.

This experience reinforced how layered engineering problems can be. Even when code compiles and devices appear connected, network permissions and institutional controls can silently interfere with functionality. Instead of assuming failure in our programming, we treated each barrier as a data point that helped narrow the true source of the issue.

PLTW Step:
Test and Evaluate because we attempted to isolate environmental variables by moving from an open guest network to a secured home network in order to determine whether WiFi restrictions were causing the command errors.

Outcome:
Although we could not complete testing on our home network due to laptop restrictions, we clarified that the malfunction likely involves network-level permissions rather than flaws in our core code, which gives us a more focused direction moving forward.

Caption:
Eliminating institutional restrictions to isolate the true source of connectivity failure.

Description:
After realizing the school-issued laptop was limiting our ability to test on a private network, we made the decision to remove that constraint entirely. Instead of continuing to work around administrative blocks, we shifted our testing environment to our own personal devices at home. Over the weekend, we attempted to reconnect the carrier using our personal laptops and even personal Chromebooks to ensure that school controls were no longer a factor.

This step was important because it allowed us to separate system performance from institutional restrictions. If the commands failed again, we would know the issue was not caused by school WiFi policies or device permissions. By recreating the setup on multiple personal devices, we were intentionally increasing the reliability of our results. Rather than relying on a single trial, we tested across different hardware platforms to see whether the behavior remained consistent.

Although the process required additional time, it strengthened our troubleshooting approach. We were no longer guessing at possible causes but deliberately isolating variables one at a time. Each attempt helped narrow the scope of the malfunction and clarified whether the breakdown was happening at the network level, the device level, or within the communication protocol itself.

PLTW Step:
Test and Evaluate because we systematically removed external restrictions and recreated the setup across multiple personal devices to determine whether institutional controls were influencing system performance.

Outcome:
By transitioning to personal laptops and Chromebooks, we eliminated school-imposed limitations as a variable, allowing us to focus more precisely on diagnosing the root cause of the command execution errors.