Looking for Stratolink 3

On June 26, I sent Caleb and Shepherd a screenshot of a new ping from Stratolink 3. We hadn't had a fresh position since May 29, when it was near Málaga. The first thing I wanted to know was whether the webhook had caught any telemetry.

It hadn't. We had a join request from two days earlier, at 02:18:34 UTC on June 24. The device was trying to authenticate with the network. No latitude, longitude, altitude, or sensor readings. But something we had let go in San Francisco 38 days earlier was still transmitting.

The join request is super tiny, so there wasn't much to work with. Packet Broker had anonymized the receiving gateway. I couldn't look up its identity or coordinates. The useful bits were the exact time, a weak radio signal, and the name cometsystem-cloud.

That name was the only hint I was working off to identify the network. It pointed to COMET, an IoT sensor company based in Czechia. I started there, using Czechia as a rough footprint for the receivers and adding the distance our radio might reach around it.

We had already received SF7 packets from about 250 km away during the flight. A simple link budget put an idealized range closer to 340 km. Adding those distances around Czechia gave a possible area covering essentially all of central Europe, lol. Still a fairly large place to look for a balloon.

The June Czechia footprint experiment, with 250 and 340 kilometre range buffers and the ground and elevated sunrise lines. — The first footprint and daylight calculations, replotted. Czechia was a starting assumption about the network, not a known receiver location.

Where the 340 km estimate came from

The calculation used SF7 at 125 kHz, an assumed receiver sensitivity of about -124.5 dBm, and a 14 dBm transmitter. Antenna gains and small loss allowances gave a maximum free-space path loss of about 141.9 dB. At 868.1 MHz, that corresponds to 343 km. It assumes favorable antennas, a clear path, and no fade margin. This is a reach estimate, not a distance measured from the June packet.

The obvious problem was that a Czech company could have customers anywhere. Its office gave us a place to start drawing, but it didn't tell us where the receiver actually was. The time of the packet seemed more promising.

Sunrise at 10,000 meters

The payload runs on solar panels and supercapacitors. After a night without enough stored energy, it needs sunlight before it can start up again. Caleb pointed out that the timing could help, so I overlaid day and night at the moment the packet arrived.

Sunrise is a little different up there. At 10,000 meters, the horizon is about 3.2 degrees below horizontal. The payload can see the sun while someone directly beneath it is still in darkness. The two dawn lines on the map account for that difference.

I then used the earlier flight data, from when we were receiving packets more regularly, to calculate the time between sunrise and our first received packet. Two mornings gave roughly 100 and 170 minutes. I used that interval as an estimate of how long the payload needed to get going, then worked backward from the June packet to find where sunrise would have been that much earlier.

Three dawn curves showing how an assumed zero, 100 or 170 minute delay shifts the inferred sunrise location eastward. — The June delay experiment, replotted. A longer assumed startup delay moves the estimate east.

At the time I described this as the payload's cold-start time at altitude. There is a catch: it was the time until the first received packet. The payload might have started earlier and transmitted somewhere no gateway could hear it. The calculation mixed the behavior of the power system with the availability of receivers.

The next versions allowed a wider range of startup delays. I combined that with a rough receiver footprint, radio range, and an assumed latitude band. By late morning, I had sent this overlap map to the chat.

The original June 26 overlap experiment combining assumed gateway coverage, available sunlight and latitude, with weighted regions extending into eastern Europe. — The map I sent on June 26. Its 50% and 90% contours describe the model's chosen weights, not verified probabilities of the balloon being there.

The red dot looks much more definite than the inputs were. The model had a favorite location because I had given it a preferred latitude, a receiver footprint, and a startup-delay distribution. Changing any of those moved the result. The useful part was seeing how those assumptions overlapped, and which ones were doing most of the work.

The missing month

Meanwhile, Caleb was working on the much bigger question: how could it have got back to this part of Europe?

His reconstruction at the top of this post followed a possible route east from Spain, across Asia and the Pacific, around a little swirl above Canada, and back across the Atlantic. I thought the swirl was fun. A trip around the world in less than 40 days would be pretty ridiculous for something we had released from a park.

The reconstruction was built to arrive near Czechia on June 24. That endpoint came from the network assumption I was trying to narrow down, so it couldn't also prove the assumption correct. We had a way the flight could fit together, but still needed a position from the balloon.

I was also trying to understand why we would hear so little along the way. The tracker chooses its radio region using GPS position, and this flight had already had trouble with stale GPS data. My best guess in the chat was that it could be holding on to an old position and transmitting on the wrong regional settings. I also wondered whether it had switched back too late to be heard over North America. Both were possibilities to investigate; the join request didn't contain the state needed to tell us.

Later that afternoon, Caleb found public gateway candidates through TTN Mapper. I ran another version using their locations instead of the broad footprint. This pulled the estimate back toward western Ukraine.

The later June experiment with individual public gateway candidates. Its weighted region moves west when the assumed receivers change. — The public-gateway experiment from later that afternoon, with its original inputs and clarified labels. None of these candidates was identified as the receiver of the June packet.

I sent it with the qualifier that I was assuming the gateways from TTN Mapper. If the packet had come through COMET's private network, it could be farther east. We had changed the possible receiver set and got a substantially different answer without receiving anything new from the balloon.

Rechecking the radio range

Another assumption in the later maps deserves a closer look. The June signal was weak: -121 dBm RSSI and -7.25 dB SNR. Some of the calculations treated that as a reason to put the balloon near the edge of the receiver's range.

The earlier flight data gives us a useful check. There are 49 SF7 receptions with a fresh GPS position, a known receiver location, and an SNR reading. Eleven were at least as weak as the June signal. Their distances range from about 22 to 252 km. One packet was heard at -10 dB only 22 km away.

A present-day comparison of 49 earlier SF7 receptions. Signals at or below the June SNR occur between 22 and 252 kilometres from the receiver. — A new comparison using the earlier received flight data. Each point is a reception, so one transmission heard by several gateways can appear more than once.

So the weak signal couldn't give us a narrow distance ring. Antenna orientation, receiver noise, and the rest of the radio link mattered too. Without the receiver's location, even a perfect distance estimate would leave us with a circle around an unknown point.

The circumnavigation is still a possible reconstruction. The sunrise geometry gave us something to calculate, but the receiving network and startup delay kept moving the answer around. I would very much like another packet with actual coordinates in it.

The positions we did receive are in Stratolink 3's flight. Shepherd's Baja Run covers the earlier part of the flight.