What’s that icon at -1 meter? Its coordinates don’t match the last position in the upper left.
And it seems it’s DevAddr 2601149D:
I have been watching several hits on Local (Bourne End & Cookham) community GW in the N.West corner W/N.West of London at >200km and that is nothing to the ones going to Durham & TyneValley, Anglesey & West side of South Wales at >400km and can see several over in N.Ireland at >600km! 
(even a couple some km outside the nominal radio horizon!)
The bright red line (to the south) is the path over ground the balloon has moved already, and the other red line (to the north) goes to the ‘target’, i.e. the estimated landing location, based on a weather model. Some balloons carry photo and/or video cameras, for those balloons people in a “chase team” try to retrieve the balloon with the cameras + pictures. The target icon gives a rough indication of where they need to drive to.
1 Like
Oops, it just opened the parachute when I made a screen capture.
Given the range that the balloon was getting, it would have made sense to cut the SF to 10 to allow for more air time.
At the gap shown between transmissions (90 seconds ?) the 30second air time limit would have been reachded in 27 minutes.
And if the 1% legal duty cycle limit applies, then there needed to be a gap of 164 seconds between transmissions.
The flight seemed to be about 2+ hours ?
1 Like
Apprently because of the way the bands are allocated in the UK, the frequency of transmissions were engineered so that they were spread across the TTN channels so that in effect you could extend the legal limit on duty cycle from 1% to circa 3%.
Edit: the duty cycle was from 1% to circa 2%.
Where do you get 3% from? I thought it aggregated to 2%.
Your right, 2% was the stated figure, however it would have been possible on the same basis to exceed 2% a bit since there are other TTN channels that fall into a faily wide 0.1% duty cycle band.
Anyone know why the airtime for a 28 byte packet shows in this log as 1646.6ms ?
According to Semtechs standalone calculator, 1646.6ms is the air time for a 31 byte packet.
The Spreadsheet for LoRa airtime calculation (or a work-in-progress online version) and TTN’s calculator (use 15 for the input; it adds 13 bytes for the header) also show 1646.6 ms. That’s all I know. 
I found it, a dumb omission on my part .
Had not set the optimisation to ‘on’ in the calculator.
One think I have noticed is that the ait time does not alter dynamically as the payload length changes, the air time for a 28,29 and 30 byte packet is the same.
Yes, I’ve always boldly assumed that such are the wonders of LoRa. For different payload sizes you’ll see that for different SF values.