What about Spreading factor and ADR


(Pierrot10) #1

Hello all,

This week-end I am going to test the range of LoRA.
I have to nodes and a gateway.

I read about Spreading Factor and ADR. As far I understood, more the SF is high, more I can go far with my node but with a higher battery consumption. I also read, the ADR mode can automatically set the SF.

Now if on my first node, I set SF7 with ADR activate. If the node will not be able to reach the gateway (or too far), I supposed the SF will increase to SF8 and until SF12 if I am far. And it will decrease to SF11, Sf10, Sf8… when I drive closer to my gateway?

But the fist things, I would like to know is the following:
Can I change the SF dynamically?
I explain. I do not want to use ADR (for now). My two nodes send messages each 2 mn to the gateway. I want to have the first node working with SF7, SF8 and SF9 and the second with SF10, SF11 and SF12.
Each two minute, I stop the car and I wait 6mn (2mn by SF).

My node 1 send message at SF7.
after sending, can I use this function or should it be use only at setup()?

LMIC_setDrTxpow(DR_SF8,14);

My node send a message at SF8

LMIC_setDrTxpow(DR_SF9,14);

and then I move with the car and stop again, and so on.

I am wundering if

LMIC_setDrTxpow(DR_SF8,14);

can be used at any time and how can I use effectively the second parameter (14)?

By the way, could you explain me what does exactely

LMIC.dn2Dr = DR_SF9;

Many thank for your help and have a nice day!!


(Arjan) #2

See Accelerate LMIC joins for testing antennae.

Now if on my first node, I set SF7 with ADR activate. If the node will not be able to reach the gateway (or too far), I supposed the SF will increase to SF8 and until SF12 if I am far.

Yes, but that will take a lot of time. First read the wiki: https://www.thethingsnetwork.org/wiki/LoRaWAN/ADR

Unless using confirmed uplinks, a node does not know if its message is received, even if it has set the ADR bit. And as you can only send at most 10 confirmed uplinks per day (testing aside), you’ll have to wait for the node to actively request a status update by setting ADRACKReq. Also, TTN needs data to calculate the best settings. See ADR is not working (nucleo - raspberry -italy) and ADR, Fair Use and LMIC.

Same thing: no, it won’t happen that fast. Even more, the wiki says:

Only static nodes should use ADR. ADR can also be used by a mobile node that is able to detect when it is “parked” on a fixed spot.

This sets the SF for RX2; see https://github.com/TheThingsNetwork/ttn/issues/155


#3

I captured this KPN client ADR behavior this morning


(Pierrot10) #4

Dear arjanvanb,

Thank a lot for this . It help.
The node will only move to test the distance. I am not going to use ADR and I understaoof that ADr is only for static node.

Could explain me why you set an different interval between different SF. I observed that bore the SF is high more the interval is hieght.

On my fisrt node, I planed to use SF7,8 and 9 with an interval of 2mn
On my interval, I planed to use SF10,11,12 with an intevral of 2mn, as well.
Should I have a larger interval between 10, 11 and 12?

It only for testing

Cheers


(Arjan) #5

Given the maximum allowed duty cycle a node needs to be silent for some minimum time interval after sending a packet. As sending at SF8 takes about twice the time of SF7, and SF9 about twice the time of SF8, and so on, the minimum interval depends on the SF that was just used. The code has a reference to the Google spreadsheet to calculate the values. (The example is sending 1 byte of data.)

The 2 minutes you’re using is probably good enough for your payload (what are you sending)? But could be a lot smaller for your tests at higher data rates (lower SF). (At SF7, after sending 1 byte, the interval is as small as 5 seconds!) Setting the interval too small might make LMiC reject your transmission. (Maybe LMiC even provides a way to use its calculations of the required silent time.)

Note that the code does not take the TTN Fair Access Policy into account, which limits daily usage when not testing.


(Pierrot10) #6

Dear arjancanb

Thank again for your clarification. Let ask you again a question

Below, using switch(dr) twice is quite verbose (or: ugly). But it allows you to easily only change the order, like to not to hop from SF7…SF12 sequentially, but in any order you like. Such as SF7, 12, 8, 11, 9, 10, or whatever you prefer.

I do not see the difference if I do not use the second swicth

If I keep the first swicth as the follwoing (look at DR_SF9)

switch(dr) {
      case DR_SF7:
        dr = DR_SF8;
        break;
      case DR_SF8:
        dr = DR_SF9;
        break;
      case DR_SF9:
        dr = DR_SF7;
        break;
      case DR_SF10: 
        dr = DR_SF11;
        break;
      case DR_SF11: 
        dr = DR_SF12;
        break;
      case DR_SF12: 
        dr = DR_SF7;
        break;
      default:
        dr = DR_SF7;
        Serial.println(F("DEFAULT; will send at SF7"));
        break;
    }        

the SD_SF9,10,11 and 12 will never be used?

Same if I do this

switch(dr) {
      case DR_SF7:
        dr = DR_SF9;
        break;
      case DR_SF8:
        dr = DR_SF10;
        break;
      case DR_SF9:
        dr = DR_SF8;
        break;
      case DR_SF10: 
        dr = DR_SF7;
        break;
      case DR_SF11: 
        dr = DR_SF10;
        break;
      case DR_SF12: 
        dr = DR_SF7;
        break;
      default:
        dr = DR_SF7;
        Serial.println(F("DEFAULT; will send at SF7"));
        break;
    }        

I can choose the order without a second swicth?
In the above case, SF12 will bever be used and SF7 will be selected in two case?

I can additonally add and choose an interval regarding the Spreading Factor in a case statement, or did I miss something?

Oh, by the way, you asked me what I am sending. For my test, I will send value of
latitude, longitude, temperatue, pression, altitude and humidity

Have a nice week-end


(Arjan) #7

I’ve edited my earlier example to make it easier to define the data rates and their order, and have LMiC determine when the next transmission is allowed. No more switch statements needed.

(But to answer your question: the old example did always need both switch statements, as they did different things. And in your first example, indeed case DR_SF10 and up would be dead code, which would never be used.)


(Pierrot10) #8

Thank a lot for this.
Today, I tried with one switch and it worked fine, but I will consider you modification on your erlier example.
http://smart-idea.io/measures/map_acccs.php
Thank a have a nice week-end.


(Arjan) #9

Nice! For future readers and just in case you did not know, see also https://ttnmapper.org. But that prefers to only use SF7.