Set spreading factor

[lloureiro]

Hello,

on FiPy, how can i set spreading factor?

Is on this place? lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868) ?

But how declare it? Where can i found documentation about LoRa Params?

Thanks

[bitvijays]

@robert-hh Hope you are doing well and had a good weekend. Thank you for your support.

In one of the reply, you mentioned that "the data rates for join should be handled automatic. It starts with the highest data rate (lowest sf), and if that fails, the data rate is lowered until eventually a join happens. Join always succeeds here, so it is hard test it."

Is there a way to test this? like debug messages?

The scenario being near my house, there are no TTN Gateway, so, i bought a Indoor gateway (which works fine).

So, I tested sending data using different spreading factor using s.setsockopt(socket.SOL_LORA, socket.SO_DR, data_rate). When I set it to SF12BW125, the gateway far away was also able to receive the message. I was wondering if there's a way to set SF12 for the join request, so that the far gateway gets my Join request. (avoiding buying of a Indoor gateway) and increasing the reach-ability.

Kind regards,
bitvijays

[lloureiro]

@robert-hh It works! I increased SF on join. Thanks a lot for your help

[lloureiro]

@robert-hh Its is done automatically :( lora.has_joined() always returns false. There is a way to see logs messages in FiPy?

[robert-hh]

@lloureiro So you register with the MAC address of the device. If the server assigns a device address which is used the next time, then the first join should have succeeded. But why do you repeat the join then? Usually a join is needed not very often.

[lloureiro]

@robert-hh No, it changed when received response from TTN.

[robert-hh]

@lloureiro All the device in the list have different addresses. Do you use so many different devices for testing?
Please be aware that you have to register a device at TTN before a join request can succeed.

[lloureiro]

@robert-hh Thank you so much Robert.
I still have another question. How can i control the frequency of join request when do lora.join()?
Because it seems to much join messages sent :(

I only did:

lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)

[robert-hh]

@jcaron The told tale: "If anything else fails, read the instructions" applies here too. I had not respected the optional argument 'dr' argument of the join method. That allows setting the inital data rate for join. If set to 5 (EU868), the device will always use that and repeat the join request every 10 seconds. If set for instance to 1, the device will start with SF11 and repeat that every 100 seconds, but adds a join request at SF7 in between. But the SF11 request will not change.
I do not know if that is the intended behavior, but at least the initial question is answered.

Part of the log data below.

08:35:05 868.14/5 SF11BW125 823.3 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:34:57 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:33:35 868.14/5 SF11BW125 823.3 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:33:27 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:32:06 868.14/5 SF11BW125 823.3 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:30:41 868.14/5 SF12BW125 1482.8 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:29:37 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:29:27 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:29:17 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:29:07 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:28:57 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:28:47 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:28:37 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:28:27 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:28:17 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:28:07 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:27:57 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:27:47 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:27:37 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:26:04 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:25:54 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:25:44 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:25:34 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:25:24 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:25:14 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:25:04 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:24:54 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:24:44 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:24:34 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:22:03 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:21:53 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:21:43 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:21:33 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:21:23 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:21:13 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:21:03 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:20:53 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:20:43 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:20:33 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:20:23 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:20:13 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:20:03 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:19:53 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:19:43 868.14/5 SF7BW125  61.7 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes
08:17:26 868.14/5 SF12BW125 1482.8 app eui:70B3D57ED000A30C dev eui:70B3D5499B070000 payload size:23 bytes

[robert-hh]

@jcaron obviously yes.

[jcaron]

@robert-hh you could probably just set a different address in your join so it won’t be accepted?

[robert-hh]

@lloureiro Reading the spec and forum notes, the data rates for join should be handled automatic. It starts with the highest data rate (lowest sf), and if that fails, the data rate is lowered until eventually a join happens.
Join always succeeds here, so it is hard test it.

[rcolistete]

@robert-hh said in Set spreading factor:

@lloureiro You can set it via the socket data rate:
s.setsockopt(socket.SOL_LORA, socket.SO_DR, data_rate)
data_rate = 5 -> SF7BW125
data_rate = 0 _> SF12BW125

Remember :

• to not enable ADR, so the initial 'data_rate' will be maintained in LoRaWan;
• data rate codes depend on the LoRaWan region (US915, EU868, etc).

[lloureiro]

@robert-hh Thanks Robert. But i need set it before join :(
this is only possible after join, right?

while not lora.has_joined():
    print('No OTAA join yet...sf_11_2.258')
    print(machine.temperature())
    pycom.rgbled(0x110000)
    time.sleep(0.1)
    pycom.rgbled(0x000000)
    time.sleep(2.4)


# create a LoRa socket
pycom.rgbled(0x00FF00)  # Green
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
print('Vamos')
# set the LoRaWAN data rate
s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0)

[robert-hh]

@lloureiro You can set it via the socket data rate:
s.setsockopt(socket.SOL_LORA, socket.SO_DR, data_rate)
data_rate = 5 -> SF7BW125
data_rate = 0 _> SF12BW125

[robert-hh]

@lloureiro Yes, I just tried to change it with sf, but it does not. But I'm sure that I changed it for a test, and I see messages with SF12. I try and tell you

[lloureiro]

@robert-hh but...

"Get or set the spreading factor value in raw LoRa mode (LoRa.LORA). The minimum value is 7 and the maximum is 12:"

If you define on intit:

"In LoRa.LORAWAN mode, only adr, public, tx_retries and device_class are used. All the other params will be ignored as they are handled by the LoRaWAN stack directly."

I tried : lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868, sf=11) but on ttn console, message appear with : "data_rate": "SF7BW125" Spreading factor 7

[robert-hh]

@lloureiro For LoraWan yes. I am pretty sure that I have set the spreading factor during my tests and it changed the signals.

[lloureiro]

@rcolistete Using LoRaWan. And found no way to set spreding factor.

[lloureiro]

@robert-hh But there is now way to set spreading factor value on LoRaWan??