In which case you wont be dependent on just one sensor, right? (Single point of failure) But also if the orchard of any decent size and area then likely you will be literally ‘heatmapping’ by using at least 2, pref up to 4 or maybe even 8 sensors per acre approx., to then also determine which direction any chill is coming from or if simply a still cold night looking at wide area coverage to then trigger either blowers to move air, or possibly add in some space heating (keep it green folks!) to minimise any potential frost effects. what you then do is have each sensor update approx every hour or so but ensure they are not all updating at same time but rather spread in time across the locality so that you avoid/identify any localised temp phenomena (shelltered or exposed areas getting colder faster etc.) and get an impression of overall condition much faster than the one hour update would imply by virtue of sampling across the sensors - getting back to that 15 or even 10 min update you were thinking of and without any sensor even getting close to FUP. Saw that with a client in Kent with ~25 sensors spread over an approx 100 acre mixed fruits orchard deployment (they had 20 across the orchards specifically for the temp monitoring but then also had 5 for monitoring conditions close to a series of bee hives on site so simply aggregated in that data also 
and another client in the Napa Valley CA - where they were restricted by US dwell time limits to no better than SF10 - who had 30 sensors initially spread over just under 52 acres IIRC, both worked a treat providing the data and early warnings the clients wanted (the later getting greater value out of the small handful of GW’s they and neighbours had initially deployed by later adding soil condition monitoring and various other sensors into the mix over time!)
I have a recollection of a discussion where the user had many of the sensors at the edges of the plantation (I think it was a vineyard) with some co-ordination of the timing of the uplinks as they wanted to monitor how gusts of air moved into the area.
However at this point in time we seem to have a DIY LMIC based device, possibly only one, with no gateway in reasonable range. So without more detail, all I hear is Lalo Schifrin’s _ _ . . _ _ . . doodle-do doodle-do _ _ . . _ _
Sorry for the long delay, and thank you for the good and extensive feedback!!!
I have not much time but i will report in a rush what happens after changing the ADR margin:
I changed the margin from 15 to 5 on 3 of 19 nodes
node 9 went from SF11 to SF10 with only a little more packets lost
node 16 went from SF12 to SF7 without significant packet loss
node 17 went from SF10 to SF8 without significant packet loss
It seems that i can affect the SF this way and keep tack of the FUP
Can i ask what you think about this way to keep track of the FUP?
I think with 19 devices in an orchard you’ll need to have a chat with @rish1 about commercial use.
I also think messing with the ADR margin which is carefully tuned by the supreme experts of TTI is somewhat hackish and likely to come unglued. Particularly as you appear to have inspired some considerable changes in the SF,
You should also look at the statistical variance of the node RSSI - before making a change as after it will only report the successful ones of course! - and you will likely see at least +/-5+ dbm variance just sitting there over time, you then need to consider how the local environment will change as time goes by - cold will be associated with condensation/fog or rain/and yes that frost/ice you are keen to avoid! A damp tree especially in bud/leaf will represent a fair attenuation even in the ~900Mhz bands though not as bad as would be the case for 2.4Ghz, with an array of them as woodland or orchard averaging out to a lot of attenuation overall (penetratin in woods/forestry much discussed historically on the Forum over time so best start there - Forum search is your friend!) so suspect whilst ok ‘now’ even a small change will start to loose you lots of messages… 15db network headroom is slightly conservative but has been arrived at across lots of users/device/applications. I often see 8-10, sometime 12 as margin but those are typcally private networks where the deployment, conditions, application, (and risks) are well understood and allowed for/accepted. Dont think I have ever seen a ‘real’ network deployed reliably wih just 5db margin! YMMV!
can i ask you what can happen? google found some posts about loosing connectivity. If that happens i have to bring them near the gateway and readjust the ADR margin and bring up a new gateway in a better location. or do i understand it wrong?
I dint know this is a problem. there are many things to measure and the orchards are spread around a valley
Thank you, its good to have a reference
It seems much easier to tweak the margin a little and keep track of the SF. A second gateway is in the mail and now i know much better in what location i can hang it
A reference sure, but DONT ignore the given context:-
With respect your questions and implied level of LoRa/LoRaWAN understanding and experience (correct me if I am wrong!) suggests
…may no be the case, yet!
Obviously one of the best ways to gain experince is to try, and TTN is in part about learning and testing LoRaWAN for your own use cases…just dont do anything that may be disruptive to other users. You have been given some free but none-the-less very valuable guidance and advice by Forumites with a lot of varied experience and I would recommend you follow what has been suggested and accumulate some real data and experience before starting to make breaking changes… 
Exactly what you have put, you’ll lose connectivity and have to add gateways, which, funnily enough, brings up full circle back to you adding more gateways, so 26 posts in, you’ve come to the same conclusion as the answer in post 2.
Totally irrelevant - if you gain a pecuniary advantage by the use of LoRaWAN via TTN and you aren’t just doing some initial Proof of Concept work, then that would be commercial use which should be on TTI. How far aware the orchards are makes no difference to the server use. And having many things to measure definitely makes a difference to the server use.
And then there is the breach of FUP, which isn’t an issue on a paid for TTI instance. Apart from the LoRa Alliance requirement that service providers restrict habitual use of SF11 & 12. So additional gateway it is then.