Force avoiding use of high spreading factors with ADR and LinkCheckMode enabled

[m7a]

Hello,

I am using EU868 region on a Heltec ESP32 LoRa (v2) board with TTN.

The application I am creating favors sending messages more often (and at constant intervals) rather than having them received at all costs. From airtime calculations I gather that I can use at most SF9. However, AFAIU TTN also supports SF10 and having ADR+LinkCheckMode enabled in the default configuration may chose to set SF10 (under bad connectivity conditions). If this happens, transmissions will take too much air time to stay within the fair use policy.

Hence my idea is to disable the use of SF10. Under normal conditions, messages will be received just fine at SF7 thus my current implementation forces SF7 by the following lines:

        case EV_JOINED:  
                LMIC_setLinkCheckMode(0);                                       
                LMIC_setAdrMode(false);                                         
                LMIC.datarate = DR_SF7;    

I can foresee this causing problems should SF7 ever not be enough. Hence I would like to enable ADR and LinkCheck while at the same time ensuring nothing beyond SF9 is ever being used to transmit messages.

A cursory look at the source code suggests I might try to directly disable the respective data rate from LMIC.channelDrMap[channel] by something along the lines of LMIC.channelDrMap[channel] &= ~(DR_SF10);. I am however, not sure if this would work correctly?

Hence my question: Is this possible with Arduino-LMIC? If yes, how would it be configured?

Thanks in advance

[chansheunglong]

If I understand your question correctly
Since i am on AS923 I will use that as an example (not sure about EU868)

Setup a channel that use SF7 to SF9
LMIC_setupChannel(0, 923200000, DR_RANGE_MAP(DR_SF9, DR_SF7), BAND_CENTI);

You can also force SF7 by calling LMIC_setDrTxpow(DR_SF7, 14) before sending data, which I think is better (?) than setting value inside LMIC's data struct

[chansheunglong]

But at least on AS923 joining require SF10, so maybe you have to modify the channel after join success. However, since you use ADR, you should always let the ADR system control the spreading factor, limiting to SF9 may not be a good option, not sure.
In your case, I feel like disable ADR and just field test and see which SF works, and set it, maybe easier.

But what are you sending and how often that SF9 is the limit? Consider only the 1% duty cycle in EU868 you can send a 12-byte very accurate floating-point GPS coordinate payload (with 13 byte overhead) every ~42​sec using SF10

[m7a]

In your case, I feel like disable ADR and just field test and see which SF works, and set it, maybe easier.

Yes, this is what I am doing at the moment. I was just wondering if there might be a technically better solution :) I am currently hard-coding SF7 and it seems to be just fine in terms of connectivity. The device in question is stationary and hence it would only need to change to a higher spreading factor under bad environmental conditions or when the primary gateway fails: A higher spreading factor might then be able to reach another gateway that is farther away.

I am using TTN and as per its "fair use policy" there is a restriction to transmit at most 30sec per 24h. My payload is currently three bytes (24 bit) sent every 180sec. According to the TTN airtime calculator (https://www.thethingsnetwork.org/airtime-calculator) transmission of three bytes at SF7 requires 52ms. At sending intervals of 180sec this corresponds to 24.96s/24h. At SF10 I get an airtime of 330ms per message which corresponds to transmitting every 950sec to stay within the fair use policy. As the application is expected to transmit at least every 600sec (from early discussions with the intended users of the application), SF10 cannot be used for the periodic submission of data.

[chansheunglong]

In your case I will use SF7 with link check, if link dead send with SF10 with ADR on with empty payload until acknowledged, then send the coordinate as fast as the law allow. Since primary gateway failed, it is a good enough reason to explain to client why they don't get the full performance.

For the GPS stuff:

In my case (which certainly is a rare case), I live in a relatively small country/city (political issue), the part before the d.p. does not relly change, in before I just send 2x 16 bit value and have the backend application add back the missing part.

The trick I use currently is sending the change in coordinate, for thr first fix it send the full coordinate, after that only send the difference between current and refrenc with 12 bit integer. If the difference is larger than what 2x 12 bit can represent, resend the full coordinate.

Some of my client are only using GPS to track an area which is like a city block (SF7 will do), in this case sending 2x 8 bit integer difference is also okay (moves within 25 meter circle). We also skip some uplink if there is no coordinate changes. This allows us to have real time performance using LoRaWAN with minimal air time, this is import as we have hunduards of sensors/tracker in an area.

But it will be painful to setup the server side...

TLDR, I think you already got the best solution.

[terrillmoore]

The join data rate will, in any case, be overridden by the AS923 join code (I believe). However, you'll need to do the set after join accept, because everything is reset based on what the network sends downlink.

Best bet is to set the datarate as you're doing, just before each transmission. Don't depend on it staying the same, because the network can send what it wants after each uplink, and therefore things can change.

[terrillmoore]

Thanks @chansheunglong for helping out!