8000 LoRaWAN Adaptive Data Rate Conflict · Issue #7 · pycom/pycom-micropython-sigfox · GitHub
[go: up one dir, main page]
Skip to content
8000
This repository was archived by the owner on Sep 16, 2024. It is now read-only.

LoRaWAN Adaptive Data Rate Conflict #7

Closed
Bucknalla opened this issue May 4, 2017 · 2 comments
Closed

LoRaWAN Adaptive Data Rate Conflict #7

Bucknalla opened this issue May 4, 2017 · 2 comments

Comments

@Bucknalla
Copy link

(sysname='LoPy', nodename='LoPy', release='1.6.13.b1', version='v1.8.6-593-g8e4ed0fa on 2017-04-12', machine='LoPy with ESP32', lorawan='1.0.0')

When ADR is enabled for the LoRaWAN class, the data rate is still expected to be set in the socket setsockopt() method.

s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, self.ack)

s.setblocking(True)

s.send(bytes([0x01, 0x02, 0x03]))

Where the LoRaWAN constructor is called as following:

lora = LoRa(mode=LoRa.LORAWAN, frequency=868000000, adr=True)

And the produced error is as follows:

Traceback (most recent call last):                                                                                      
  File "<stdin>", line 124, in <module>                                                                                 
  File "<stdin>", line 83, in transmit                                                                                  
OSError: [Errno 11] EAGAIN  

The ADR should not require the data rate to be set inside of the socket class as the gateway should provide feedback and control over data rate.

Thanks!
@jmarcelino
Copy link
jmarcelino commented May 4, 2017 •
edited
Loading

Hi @Bucknalla, ADR information is a bit scarce in the specifications but from what I understand there isn't any set rule on where ADR should start, for example the node can start trying ADR at the highest DR=5 (SF7BW125) and slowly lower until it achieves successful transmission, but it can also start at DR=3 (SF9) - if there is previous evidence SF7 won't work - which will make the connection process much quicker and robust, no need to wait for many missed packets.

So there is still value in keeping the data rate setting even when ADR is enabled. I may be wrong - definitely welcome any comments - but I see ADR as more as a "turn on link optimisation" and not so much as a fully automatic process.

Actually to me ideally it would be a run-time flag and not require a full re-init of the LoRa class. This would then better suit nodes which may be moving (ADR off) at times and be static (ADR on) at others

@danspndl
Copy link
danspndl commented Sep 3, 2018

Hi 👋
I'll close this issue because it has not had any recent activity. Thank you for your contributions!

@danspndl danspndl closed this as completed Sep 3, 2018
@salal-m salal-m mentioned this issue May 14, 2020
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jmarcelino @Bucknalla @danspndl
0