The Baja Run
This was the longest and strangest flight stratolink-3 has flown. It launched from the San Francisco Bay, floated south down the coast and across into Baja, then went completely silent for about thirty six hours. It came back the next afternoon deep inside Sonora, Mexico, kept flying, and put down its last fix near Albuquerque, New Mexico, more than two days after launch. This report walks through what happened, what the data shows about why the tracker went quiet, and what I am changing for the next launch.
The flight, start to finish
The balloon climbed cleanly to its float altitude of around 9,500 m and settled into a steady drift. The early track ran south along the California coast, past Los Angeles, and down to the border near Tijuana. Then the trail went cold.
18:20 UTC, May 17 · GPS freeze begins · 6,924 m
02:23 UTC, May 18 · last fix before blackout · near Tijuana, 32.01°N 117.72°W
[ about 35 hours of silence ]
13:58 UTC, May 19 · reappears · deep in Sonora, 31.00°N 111.71°W
22:28 UTC, May 19 · final fix · near Albuquerque, 34.78°N 106.13°W · 9,814 m
When it came back, it had moved about 580 km east in net terms across that silent stretch, then turned and ran fast to the northeast over the following hours. The full confirmed track covers roughly 2,000 km, even though the straight line from launch to last fix is only about 1,500 km, which tells you the path was anything but straight.
Two different failures, often confused
It is tempting to lump the quiet stretches together as the tracker not working. The data shows they were two distinct problems with two different causes, and separating them is the whole key to fixing them.
Problem one: the frozen GPS fix
Early in the climb, around 18:20 UTC, the reported satellite count jumped to 32 and the altitude locked at exactly 6,924 m. It then reported that same altitude across fifty four consecutive readings without changing by a single metre.
A real GPS receiver does not see thirty two satellites from one constellation, and a balloon climbing through the atmosphere does not hold the exact same altitude for an hour. Both are signatures of a stale fix, where the receiver lost its lock but kept reporting the last good position instead of reporting that it had no fix. The value 32 was almost certainly a sentinel or overflow, not a true count. The receiver was not lost in the sense of having no data. It was lying quietly, repeating an old answer.
Fifty four readings, one altitude, an impossible satellite count. The position was frozen, not missing. The fix is to make the tracker say "I do not know" instead of repeating its last guess, which I cover in the next section.
Problem two: the overnight blackout
The long silence had nothing to do with GPS. It was power. There is no battery on board, because a battery would not survive the cold at altitude. Instead the tracker runs on a supercapacitor charged by the solar panel, and the voltage the data labels as battery is really that supercapacitor. A supercapacitor handles the cold beautifully, where a battery would fail outright, but it holds far less energy, so it leans heavily on the sun. In the five minutes after the last fix near Tijuana, as night fell, that stored charge drained away.
02:28 UTC · cap 3.37 V · solar 3.29 V · temp −26°C · lux 8,738
02:43 UTC · cap 3.33 V · solar 3.03 V · temp −32°C · lux 1,388
02:58 UTC · cap 3.32 V · solar 2.17 V · temp −38°C · lux 79
As the sun set, the solar panel stopped delivering current and the supercapacitor drained from a healthy 5.38 V down to 3.32 V within minutes, tracking the falling light almost exactly. With nothing left to draw on, the tracker went quiet. It stayed dark through the night and the next morning, then woke the following afternoon once the sun was high enough to recharge the capacitor. When it did, it picked up right where physics had carried it, hundreds of kilometres to the east.
The blackout tracked the sun almost perfectly. The supercapacitor fell from 5.38 V to 3.32 V in minutes as the light faded, and recovery came the next afternoon when the sun returned to recharge it. This was a stored-energy limit at night, not a radio or GPS failure.
Why it could even come back
The tracker reports through LoRa to a network of ground gateways, and the received signal was already faint at the edges, with strength readings down around −110 to −120. Over remote stretches of Baja and the Gulf there were simply no gateways in range to hear it. Once the balloon drifted back over more populated terrain, and once it had power again, its packets reached a gateway and the mission came back to life on the map.
What I am changing
Each of the failures above points to a concrete, inexpensive change. None of these require new hardware beyond what is already in the design.
-
Make the tracker admit when it is lost
The firmware should report a real fix-quality flag and never repeat a stale position. If the receiver loses lock, it should send a clear "no fix" rather than the last known altitude. Logging the true satellite count and the HDOP value, both of which were missing from this flight, would have flagged the frozen fix immediately.
-
Carry more charge into the night
The supercapacitor was the right call for the cold, where a battery would have failed outright, but it holds far less energy and so depends on the sun. Adding capacitor capacity, trimming nighttime power draw, and squeezing more from the solar panel during the day would all extend how far past sunset the tracker can keep talking.
-
Sip power at night, do not gulp
A low-power night mode that wakes briefly, sends one position, and sleeps again would let the tracker ride out the dark hours on a nearly empty supercapacitor instead of going fully silent. The hardware already exposes a sleep setting; the firmware needs to use it aggressively after sunset.
-
Buffer positions while out of range
When no gateway is in range, the tracker should store its fixes and send the backlog once it reconnects. That would have filled in part of the silent stretch retroactively rather than leaving a clean 35 hour hole.
-
Record the diagnostics that were blank
This flight logged no HDOP, no power mode, and no firmware version. Those fields cost nothing to send and would have turned guesswork into certainty. Every future packet should carry them.
-
Plan for the dark stretches
The flight path crossed long spans with no ground coverage. Knowing that in advance, I can lean harder on the satellite path for position rather than the ground network, and set expectations that some legs will simply be quiet until the balloon drifts back into range.
The reconstruction angle
The thirty six hour gap is exactly the kind of silence the reconstruction engine is built for. Because there is a confirmed fix on both sides of it, the path between is a bridge anchored at both ends rather than a guess that fans out forever. The honest result for this particular gap is wide, because the balloon's small net movement over a day and a half means it almost certainly looped or stalled around a slow weather system before drifting east, and the system correctly shows that stretch as a region of where it could have been rather than a confident line. The full method is written up separately in the engine technical note.
The balloon never failed. It flew for more than two days and crossed two thousand kilometres. What failed was the tracker's ability to keep talking through a cold night and out of radio range, and its honesty about a frozen fix. Both are firmware and packaging problems, both are cheap to fix, and the next launch will carry every change above.