since SF11 and SF12 are not allowed, if my mobile mote (bike tracker) occasionally transmits at SF11 or SF12 is considered as “fixed hardcoded rate”?
Occasionally is once per day? Three times per day?
I don’t use ADR and it’s not applicable to mobile motes, but I have the idea of ‘white zones’. I indent to map the area and to store ‘white zones’. If the device is on white zones, it will TX with less SF or/and power. The default SF I indent to use is SF10
Alternatively I have the idea to store GW locations. In that case the worst case scenario is 200m of coverage so I will try with SF7 when my mote is <200m of GW.
I doubt anyone can give an authoritative answer other than: no, always using SF11 or SF12 is simply not allowed. Period.
On the other hand, with the ideas you already described yourself, you won’t be always using SF11 or SF12?
Circumventing this by randomly using, say, SF7 every now and then, while you don’t expect that to be received at all, may feel like just causing more traffic. But as SF12 uses about 25 times more resources for the radio than SF7 (it depends a bit on the application payload size), both in terms of eating your maximum daily airtime and consuming your battery (for the radio part), you may still benefit from trying to use better data rates:
Using so-called Blind ADR may save both airtime and battery. Like:
A single message on SF12 uses almost the same airtime (hence battery) as the total airtime for 4 separate messages on SF8, SF9, SF10 and SF11.
When not using SF11 either, instead of sending a single message on SF12, you could send a total of 6 when using 2 × SF8, 2 × SF9 and 2 × SF10.
Sacrificing one of the SF10 transmissions allows for, e.g., 4 × SF8, 3 × SF9 and 1 × SF10, their total airtime still being the same as a single transmission on SF12. Are you seeing a pattern?
Not my cup of tea, but using SF12 for devices that are moving while transmitting, may also not be as good as you may expect:
So, the SF11-SF12 rule is easily circumvented, with possibly great benefits. Also, of course, other radio technologies may be a better fit for vehicle tracking.
(Please post any responses/queries regarding the quotes above to those existing topics.)
I knew about blind ADR it’s my ‘White Zones’ version or the GW mapping.
SF12 / SF11 will be transmitting only if GPS fix is absent and the bike is stationery. My area has not many GW, that is the reason I think about SF11/12. I know I can transmit many more times with less SF, but in my initial test I can’t reach GW’s.
So once per day @SF11/12 I suppose it’s fine (6bytes are enough)
BTW maybe you like this graph, some days ago I realized with your calculator that the Time on Air is not linear with the bytes.
This is iirc an effect of the forward error correction. The time increments based on step increases in the coding block, just an extra bit/byte in payload forcing a new block even if not full up until just before the next step… TTN/TTI LoRaWAN uses 4/5 coding.
I have an application that is aiming to get sight on RF propagation of LoRaWAN signals. For this purpose, the node is transmitting at a 10-minute interval at SF7 while once per hour at SF12.
I see no limitation in the scheduled use of different SF. The use of ADR is not mandatory.
Hi @clv, thanks for the link to this paper. It has some of the best explanations of LoRa modulation that I have read. I recommend it to everyone who has any interest in engineering at the radio level of LoRaWAN.
It is somehow explained in the paper from EPFL: the fixed-length blocks for LoRa is the combination of two things:
One LoRa symbol SFx carries x bits, and you are only sending full symbol.
The interleaving scheme used in combination with the FEC will force the number of LoRa Symbol to be a multiple of certain value (e.g. 5 for 4/5, 8 for 1/2)
