Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send with ack retry count parameter #217

Open
jpmeijers opened this issue Jun 22, 2017 · 2 comments
Open

Send with ack retry count parameter #217

jpmeijers opened this issue Jun 22, 2017 · 2 comments
Assignees
Labels

Comments

@jpmeijers
Copy link
Collaborator

This is a feature request. See discussion #214.

Add a parameter to the sendBytes() function to override the default retry count of 7 when an acknowledgement is requested.
ttn_response_t sendBytes(const uint8_t *payload, size_t length, port_t port = 1, bool confirm = false, uint8_t sf = 0, uint8_t retries = 7);

Currently the RN2483 will retry 7 times before the blocking call to sendBytes() returns. For high spreading factors this can take a long time. For SF12, 51 byte packets: 30 minutes. Blocking for a long time, doing nothing means a big waste of energy. During this time the MCU could have been in sleep mode.

@andrzejtokarski
Copy link

Having the main loop hang while waiting for the response seems a general waste of the CPU time. The situation being parallel by nature having multiple processors.
Did you guys consider another version of this method that returns after initial OK and a different one for polling the result?
I'm thinking: something similar to the Adafruit GPS library, where serial reading & parsing is done in the main loop and the state is stored by the library.

@johanstokking
Copy link
Member

Having asynchronous request/response would be very nice indeed. The problem with this serial I/O is that we still have to read from the serial somewhere, and threading is not supported on Arduino platforms. Interrupts with serial I/O neither. SerialEvent may have been an option, but it's not supported on Leonardo (i.e. The Things Uno) and requires it in the sketch which is not very user friendly.

Returning on OK, and reading the actual result "the next time" there is serial I/O is possible. Then you'd need to poll the library, and if you go to low power state, make sure you don't break the serial interface. We can consider this, but we have to be very careful with not going out of sync with request and response messages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants