Sure, i agree with you. But over all with the constrains of the fair use policy SF11 and SF12 are making absolutely no sense . Correct me if im wrong, but 13 bytes of header and 1 byte of payload is 14 bytes. Sending with SF11 makes 30min intervals, SF12 makes 60. So building a device with 15 min intervals and ADR activated is risky
I did write some code for LMIC that adjusted the TX interval to keep within the FUP, but there was little (as in zero) interest in it.
Can you re-read this and give it some thought / investigation because you seem to have totally missed the point:
To expand on it just in case it’s not obvious, there is no point setting the SF to a value that stops the device being heard - you can make the change in firmware easily enough in the main loop - but it will then be a small lump of plastic that transmits but won’t be heard.
So you can solve the problem of airtime at the expense of ultimate functionality. The remedy is about reducing SF by getting the devices closer to a gateway - which is most likely done by adding gateway(s).
Or reduce the uplink interval. Any reason why that can’t be done?
Far be it that anyone other than you, me, @andonoc and a select few keep to FUP so not entirely surprising.
Care to share?
1 Like
Don’t recall this being called out before - may have missed. A nice to have (even a must have?) for TTN connected LMIC based designs, if easily integrated into general firmware without breaking changes? Which library version/implementation had you developed/tested with?
The FUP control came about as a result of dealing with the duty cycle issue in the LMIC low power library;
Once the duty cycle problem had a work around it was not difficult to estimate the air time at each transmission using the current SF and payload size and adjust the sleep interval accordingly.
Whilst not difficult to do, you had to want to implement the code, and most people are not really interested in keeping to the FUP.
The FUP was not implemented until, by default, 5 transmissions after join.
But both scenarios require the same action. Using SF12 is not sustainable and missing packets are not sustainable, the remedy is always adding another gateway and that needs time.So i think the “miss some packets” scenario is better then causing trouble by exceeding the FUP because it needs no urgent action.
It’s always hard to agree with a strategy without any context, which is why I asked what the downside of uplinking less frequently would be.
But there still seems to be a conceptual problem that you’ve sort of acknowledged. If a device has ended up on SF12 as a result of ADR and you force it to SF10, it seem quite likely that you will experience more than the occasional missed packet - quite likely all of them in fact.
@LoRaTracker is the man to know what the reduction in range is likely to be.
Implementing a change to LMIC and testing seems likely to take as long as buying a TTIG and finding somewhere to host it.
How is your own gateway situated? What antenna does it have? Can it have its antenna in a better position?
Understanding that you may well stop your device stone dead, the simple answer is to put LMIC_setDrTxpow(DR_SF10,14); just before LMIC_setTxData2(1, payload, sizeof(payload), 0); to hot wire the SF. AFAIK the power value isn’t implemented but is required.
With LMIC, the changes to cope with FUP, are hardly difficult.
Why ?
Also @andonoc SF isnt ‘just’ about range - it impacts sensitivity which can be a factor in range, but also penetration and another factor often overlooked wrt LoRa modulation capability is the impact of steping SF on noise immunity. IIRC e.g. where legacy modulations need +ve SNR’s LoRa can operate below the local noise floor with a capability that varies with the chosen SF. ADR can therefore adjust SF not only to reflect a suitable RSSI + netweork determined safety headroom, it can also adjust to reflect the presence of impinging noise and poor noise floor. Again IIRC where SF7 is good down to approx -7 SNR, the improved sensitivity of higher SF’s (longer signals allowing more time to disciminate and corellate target symbols) means SF12 is good down to approx -20 SNR. So even if there is a good RSSI and some headroom, if the local RF environment is troublesome a higher SF may still be recommended to compensate. Force to SF10 where system is flagging SF11 or SF12 may mean you have another variable that will kill reception…best advice is therefore adjust timing to suite higher SF under FUP 
Fewer packets but much greater chance of getting through, and depending on how application constructed and controlled less need for recovery or retries (helping to also limit spectrum use by minimising on air time overall).
The data sheet sensitivity difference for a LoRa device is that SF12 has 5dBm more sensitivity than SF10. 6dBm extra sensitivity would be double the range.
1 Like
In the code I published for the LMIC low power library, which worked around the duty cycle problem and allowed the node, a SEEED XIAO SAMD21 in this case to go into a very low current deep sleep (5uA), the FUP adjustment was tied up with the deep sleep code.
However in a normal LMIC setup there is a line like;
const unsigned TX_INTERVAL = 30;
Now you might question why the code examples for the libraries are such a major breach of FUP, but if you make TX_INTERVAL a global variable, you can adjust it at every transmission to take account of the SF in use (LMIC.dndr) and the payload length in use (sizeof(payload)).
An exact calc of air time is not so simple, since the air time could be the same for a 20 byte packet as it is for a 22 byte packet due to the vagries of how LoRa works. However, if you take the length of the minimum packet and the maximum packet you can have an average air time per payload byte and with these constants its not difficult to estimate air time, then its easy enough to adjust the TX_INTERVAL to keep close to the FUP.
A Temperature sensor sending every 10 minutes 2 bytes is limited to SF9 with FUP. So, from what i understand, i should NOT allow the device to go to SF10. So if i lose complete connectivity i know to add another gateway or reposition the node. What is strange on my approach? How did you handle those situations?
If the node is in a location where it can end up using SF12, set the send interval to 60 minutes or so.
Do you really need to know temp that often? What is your application?
1 Like
spring frost detection for orchards
I found the ADR margin setting in the device settings! I go to play around with these numbers
8 minutes. But many temperatures don’t change that fast or need updating that fast …
OK, so send the temperature every hour and more frequently as it changes as it gets closer to the frost level and only when there is a significant change (relative to the accuracy & precision of the temperature sensor). FUP is over 24 hours, so more frequent uplinks as there are significant changes in the wrong direction, can be accommodated.
Like many threads, you’ve got access to some people that have solved many problems like this so many times we confuse them with hot dinners, but getting enough information to advise is like pulling teeth. Be more open to both providing information without us asking or feeling that the proposed solution won’t work.
I send ‘normal’ weather temperatures as one byte with 1 decimal place - which, given the accuracy of the average sensor, is more than sufficient. I can alter the range using the port numbers. But TBH, providing overlapping coverage for anything that’s being monitored that can cost money is a no-brainer.
So I’d ask what the temperature sensor is, hoping against hope that you just tell us what it is on your next post.
And if this is a commercial orchard, or one you get a reasonable crop from, installing a gateway on cellular is a next-day-delivery away - you can then figure out a longer term plan but you will have some breathing room.
If your install is for commercial use, shhhh, I didn’t tell you this, but you could use your one gateway and your temperature sensor off FUP by registering for a Discovery instance on TTI.
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 _ _ . . _ _
1 Like