I well remember the internal reactions when highlighting one of the LoRa 2014 HAB flights that went over the Bristol channel, s.west England, over The Channel and a long way down towards Marseille (tracked by HAB enthusiasts for >1Kkm IIRC) - sadly the wind took it on a slow arc away from s.east France, to the south, as otherwise it would have taken it roughly overhead the LoRa Tech team (former Cycleo) down in the Grenoble region. I subsequently had the priviledge to set up and participate on a call with Mr.A & Nicolas for a discussion of the how and the art of the possible wrt LoRa (before LoraWAN, and even before the public roll out of LMIC IIRC) & Long Range HAB . Fun times! 
(Blush) that was me. It went over the Britol channel because it was launched from Caerrphilly common, just North of Cardiff.
A simple foil party balloon, PICAXE microcontroller and LoRa device. I was the only one able to track with LoRa (from my shed in Cardiff) there were at the time only about two other HAB guys with LoRa receivers. It was tracked down to Marseilles via its FSK RTTY output.
I recall the surprise in the HAB community when I remarked that i was able to control what the foil party balloon was doing, send LoRa mode tests, turn off transmissions etc, whilst it was over 200km away.
Sorry Stuart - you are dead right! Was looking for my variant of that picture to add to post…I remember the PICAXE… even have one lost spares box that I picked up shortly after off the back of that story…
Now part of LoRa marketing folklore! 
The choice of PICAXE was as a result of my PICAXE in space exploits and experience. Whilst many were puzzled as to why a PICAXE was used for that HAB flight it was the obvious choice for me, there were no ‘Arduino’ libraries for LoRa at the time and neither was there a PICAXE one so I stuck with what I knew.
“Occasional loss” is the norm in radio communication, especially in shared spectrum.
There are some useful similarities between ultra long distances under line of sight conditions, and short ones under obstructed conditions and even those subject to interference (at least when it’s not same-slope LoRa interference)
Some of the achievements posted are likely more in the realm of “occasional success” than “occasional loss”
Indeed and when I pitch LoRa to potential audiences I always call out Long Range as a ‘proxy’ for deeper penetration into absorbant environments - loss through double/triple glazing? Loss through old stone walls in castles/stately homes/national monuments? Penetration through concrete walls of nuclear reactors & particle accelerators for monitoring (yes that is a use case! 
) Deliver sensor data through multiple floors of high rise housing or office blocks etc… All absorbant materials effectively do (simplistically) is pack an equivalent of a long free space loss into a shorter physical space!
3 Likes
There’s a balloon flying right now over the north sea being tracked through TTN gateways:
https://tracker.habhub.org/#!mt=roadmap&mz=11&qm=1_day&f=xttn&q=xttn
Probably using my https://revspace.nl/TTNHABBridge “middleware” to relay data from TTN to the habhub webpage.
The blue circle is the “radio horizon”, i.e. the range from the balloon to the horizon as the balloon sees it.
1 Like
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.