Apart from battery considerations, added advantage of ADR is the increased network capacity: when a specific spot has many LoRa devices sending at a high SF is fitted with an extra gateway, that gateway can reroute the traffic and drastically decrease ToA of the devices around the gateway.
Adaptive Data Rate (ADR)
This post has become obsolete as it was incorporated in the Spreading factor (SF), Time on Air and (Adaptive) Data Rate topic.
To save battery devices should minimize used spreading factor, and therefore time-on-air (ToA). When a LoRa device has ADR enabled, the network measures signal strength and replies to the device what SF to use from now on. LoRa devices can be set ADR ON or OFF. Switching ADR OFF is only advised for continually moving objects.
Apart from battery considerations, added advantage of ADR is the increased network capacity: when a specific spot has many LoRa devices sending at a high SF is fitted with an extra gateway, that gateway can reroute the traffic and drastically decrease ToA of the devices around the gateway.
Apart from battery considerations, added advantage of ADR is the increased network capacity: when a specific spot has many LoRa devices sending at a high SF is fitted with an extra gateway, that gateway can reroute the traffic and drastically decrease ToA of the devices around the gateway.
I notice this channel mask is always 0x00 0x07, or binary 0000000000000111, and this means if I interpret correctly only channels 1, 2 and 3 are available for uplink messages.
However in practise, I think there are 8 channels available for uplink messages, at least my software use all 8 and messages arrive correctly, and in the messages from KPN's backend system this is indicated by the parameter Channel which has values LC1.... LC8.
My question is: why is the channel mask in MAC command 0x03 indicating that only 3 channels are available while in fact there are 8? I would like to design a proper mechanism to use a certain channel or not, but this MAC command does not seem to provide helpful information.
Hi @rharte ,
Thank you for your question!
I reached out to Michiel Jol and i found out that we have a new productmanager for LoRa.
I sent an e-mail with your question to our new productmanager and i'm trying to get an answer to your question today. I've tried to answer the question myself, but this is a bit too technical for me 🙈
Thank you for your question!
I reached out to Michiel Jol and i found out that we have a new productmanager for LoRa.
I sent an e-mail with your question to our new productmanager and i'm trying to get an answer to your question today. I've tried to answer the question myself, but this is a bit too technical for me 🙈
Hi @rharte ,
I received a response from one of the technical specialists and I received the following answer:
'Once the device has answered all NewChannelReq messages, the network will also turn on those new channels in the channel mask.'
Does this information answer your question?
I received a response from one of the technical specialists and I received the following answer:
'Once the device has answered all NewChannelReq messages, the network will also turn on those new channels in the channel mask.'
Does this information answer your question?
So a NewChannelReq for ch3 which is already included in the channel mask? A NewChannelReq for ch4 I understand but then what about ch5..... ch8?
I think a lot of airtime goes wasted this way on handshake on these parameters, while they are the same for every channel anyway, and all 8 frequencies can be known upfront to all devices, right?
BTW, what is the value of the Redundancy field?
Do you mean that ChIndex field values are 3 and 4? If so, these 're settings for ch4 and ch5. Actually, it shall be impossible to change ch3 settings with NewChannelReq command.
I think a lot of airtime goes wasted this way on handshake on these parameters, while they are the same for every channel anyway, and all 8 frequencies can be known upfront to all devices, right?
This seems to be an example of The Art of Capacity Planning :-)
However in practise, I think there are 8 channels available for uplink messages, at least my software use all 8 and messages arrive correctly, and in the messages from KPN's backend system this is indicated by the parameter Channel which has values LC1.... LC8.
You're bragging that your device doesn't follow the specs, aren't you? 🙂
You're bragging that your device doesn't follow the specs, aren't you? :-)
😂 Well actually if you read the spirit of my post, I am trying hard to comply to the spec, but in the grey area of network behaviour where the LoraWan specification does not provide, I find it sometimes hard to follow the logic.
Luckily, KPN answers quickly and thoroughly on my detailed technical questions, so I gladly stand corrected when that means I receive another piece of the puzzle 😉
Hi @rharte ,
Thank you for your patience!
It took a little while, but I received extra information from the specialists again.
I hope this gives some more logic and clarity about the use of the different channels.
The answer:
The first LinkADRReq message is not for setting the channel mask, but for setting the data rate. The channel mask in this message still assumes the device knows only the first three channels and can therefore not enable the others. When a new channel is send to the device with the NewChannelReq mac-command, the device can immediately use this channel according to the LoRaWAN specifications. At the end, when all other channels are communicated to the device, the channel mask will enable all channels except channel 6, which we disable due to interferences.
This is all the case with ABP devices. According to the LoRaWAN specs, the network cannot assume the device knows all channels. Therefor the device communicates all channels 4-8 through the NewChannelReq messages, which indeed takes some time. That is why OTAA is the preferred method of joining the network. When using OTAA, all channel, adr and rx info is put in the JoinAccept message, such that the device knows all the network settings from the first downlink message.
Thank you for your patience!
It took a little while, but I received extra information from the specialists again.
I hope this gives some more logic and clarity about the use of the different channels.
The answer:
The first LinkADRReq message is not for setting the channel mask, but for setting the data rate. The channel mask in this message still assumes the device knows only the first three channels and can therefore not enable the others. When a new channel is send to the device with the NewChannelReq mac-command, the device can immediately use this channel according to the LoRaWAN specifications. At the end, when all other channels are communicated to the device, the channel mask will enable all channels except channel 6, which we disable due to interferences.
This is all the case with ABP devices. According to the LoRaWAN specs, the network cannot assume the device knows all channels. Therefor the device communicates all channels 4-8 through the NewChannelReq messages, which indeed takes some time. That is why OTAA is the preferred method of joining the network. When using OTAA, all channel, adr and rx info is put in the JoinAccept message, such that the device knows all the network settings from the first downlink message.
Reageer
Meld je aan
Heb je al een account? Inloggen
Welkom
Nog geen account? Maak een account aan
Inloggen of registreren met sociaal netwerk
Inloggen met Facebook Login with LinkedInof
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.