Well yes, basic RF stuff that is.
Appreciate that a tracker at altitude is capable of causing significant disruption over a wide area both to TTN and other comms. At ground level mistakes in design may go unoticed, but at altitude its different.
Consider getting the assistance of an experience RF guy to check out and test that your tracker is legally compliant and not causing interferance.
Yes, I understand. I will try to deal with all of this.
Dear:
I believe that the losses due to free space are not being taken into account.
The probes reach a maximum of 50km, but let’s say it is 40km away and with the frequency of 808MHz, there would be 123.25dB losses, so I don’t think it is violating international transmission power standards
European regulations limit the effective power emmitted by the transmitter.
Free space losses are not relavent or taken into account.
Just curious: these two examples agree on 2.5dB per step in the SF. But shouldn’t the percentage be different for 2.5dB vs 5dB?
Yes I understand this now.
Oh yes I’m also interested in this.
To double distance you need four times the power, or 6dB more power.
So if sensitivity increases by 5dB, as it does if you switch from SF10 to SF12, your going to get just less than twice the distance, i.e 78% more, (approximatly) .
And remember: the earth is round. If you are on the ground and the balloon is 10.000m high you can “see” it about 400km. Using SF7/125kHz the maximum theoretical free space distance is already abt 350km. imho SF9/125kHz is more then enough to reach all gateways that can be “seen”
You would think so.
However those currently using TTN for high altitude balloon tracking might be seeing every flight as a ‘record attempt’ so they may be using settings that can be received by most of the gateways in Western Europe, when the ballon is at high altitude.
Yes, as pointed by LoraTracker I was missing a little factor two in my calcul 
Jakub, in my high alititude flights from the United Kingdom, we have no issues getting our data picked up with SF8 and SF7. With direct line of sight, the spreading factor does not make a difference at all(from experience). Over the Netherlands, we have had nearly 400 gateways pick up our packet. See picture below. We have had good coverage over Belarus, Romania and Slovakia. At least 2 gateways pick up transmissions there.
You are better off transmitting more regularly at high data rates, while sticking to the 30s TTN airtime limit. Even if some packets are lost, you will have some that get through.
Interesting, thanks for the info. I will try to adapt my blind ADR sequence according to this.
Adaptive Datarate(ADR) works only when the device is static(i.e. in one place). An example could be a device mounted in a carpark. It automatically optimises the datarate to the highest possible datarate without loss of packets. Higher datarate = shorter transmission = lower power consumption.
However, on a dynamically moving balloon, ADR does not make sense because the balloon will be in and out of range of the gateway very quickly.
Medad
That depends on the timescale of the motion compared to the timescale of the ADR
Not really very quickly given your altitude.
Too fast for conventional ADR? Probably. Too fast for the idea behind ADR? Not in the slightest.
@Jakub_Nagy was referring to blind ADR - something I suggested in the other thread - it’s not ADR controlled by the network, it’s run at the device level to try to maximise opportunities to get an uplink through - if you are over an area with some but not many gateways, sending on different DRs could get more info through - if you are over Europe or other well served area, make best use of DR7 with more uplinks to the limit.
Sorry Nick, for the benefit of wider user community I would council against this! Whether the ‘limit’ in this case is the legal duty cycle limit or the TTN FUP (unenforced as yet) limit matters not. Spectrum is a shared resource and just because you CAN run up to the limit doesnt mean you SHOULD run up to it. If everone took that view we would all struggle. Applications should be engineered with the minimum number of uplinks that are practical with a little extra to allow for e.g. lost packets (perhaps due to inconsiderate users who are pushing the limits! 
). I know balloonists are keen to try and reach as many gateways and as far away as possibe to get (bragging rights on?) track completeness (yes being provocative ) but in terms of saturating GW capacity and area coverage spectrum these appllications can be the worst. A local node hitting 1 or 2 or even a handful of ‘local’ GW’s, at the useage limit is bad enough but when these Tx’s get seen by many hundreds of GW’s on a regional and even near continental scale (400+ in case above?) this is antisocial!
Community users…please do not run up to the limits other than in emergency situations. (Note to self: must practice what I preach!..)
Context is everything. So not this team, not even a little bit, what Medad does with HAB has considerable merit and I put the “to the limit” in to reinforce that despite the usefulness of his upper atmosphere data if we can find a way to get hold of it, no one is saying flood the network.
For values of useful, it’s the sort of data that ESA / NASA etc would find handy.
For his targeted 100 byte payload, the balloon can do 6 an hour whilst it is daylight as it is entirely solar powered - so perhaps 8 hours maximum of tx time. With the spotty coverage, this would enable time to backfill data points from when it knew it was out of coverage. For the one the university society launches every few months, this isn’t a network killer application.
Data / payload is definitely one of my things since I was stuck getting pub pints poured (volume, temp, gas pressure) from a national chain, making for many millions of data points a day, so if you have a squint at some of the my recent posts, you’ll see I’ve shared lots of ideas to help Medad get the payload as small as possible.
If anyone else wants help getting their payload right sized so they can hit the right balance of number of statistically significant data points vs number of uplinks, I’m here for you.
Please do not consider LoRaWAN for emergency use. The use of this technology in an unlicensed band makes for potential extremely unreliable communication and as such is not suited for emergencies. In the past TTN explicitly stated its network should not be used for anything where lives could be endangered.
Our flights have similar characteristics.Though our current single packet (including location, speed, temp, pressure, humidity, spectral data and voltage) is only around 20 bytes. When sending one current and one past packet it would be 40 bytes.
This is also the same case for us, though we plan to do larger scale launches with multiple probes in the future. First off I was thinking about getting the max range possible. But in our case range over land doesn’t matter at all (we don’t need to brag with that). Long range only matters oversea and over oceans, when trying to reach land. But there there’s nothing to saturate.
So, we’ll try to not just have the max range, but to not saturate gtws over Europe and US and meanwhile retain long range overseas. Maybe increasing the resolution of the internal gtw map in our memory would help to do this. Maybe instead of storing areas with gtws, we could store the gtw densities in these given areas.
Maybe this is also the answer, maybe even a better answer.
Since we are currently a larger team of people we can try all of these and find the most optimal solution.
Is there some thread for this or was that private?