Non Blocking Send & Ack/Receive timeout.

Home › Forums › mDot/xDot › Non Blocking Send & Ack/Receive timeout.

Tagged: ,

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • February 28, 2017 at 12:37 pm #17543
    Ajay K
    Participant

    The Uplink is achieved via non-blocking send call and I have ack enabled for the transmits. With the acks’ enabled, would I be able to transmit another packet in succession or the mdot api would prevent me from sending another packet until an ack is received. If the ack is received, would I have to wait for the receive timeout to occur before I can send another packet?

    If the packet transmits are not possible until acks and receive timeout have not occurred, What are the timeout intervals in seconds/ms for the acks and receive window in the latest libmdot-mbed5 or libmdotdev-mbed5?

    Thanks,
    Ajay.

    February 28, 2017 at 12:55 pm #17545
    Mike Fiore
    Blocked

    Ajay,

    Trying to send another packet while the mac layer is still sending or opening RX windows for the previous packet will fail. You should get an error about the radio being busy or something similar.

    If you’re using a nonblocking send, you should always get an event that fires after the TX/RX is done. The mDotEvent class demonstrates this for you.

    The “timeout values” would be based on when your receive windows are configured to open.

    Cheers,
    Mike

    February 28, 2017 at 2:51 pm #17561
    Ajay K
    Participant

    Thanks Mike for taking the time to respond. I do derive from the mDotEvent class to handle the receive packets. However I was wondering if should set out a timeout (a finite time to wait) in my main thread to ensure that the receive window and the ack window are accommodated for and worst case an mDot Event doesn’t fire, especially when there is no downlink packet to expect or for some reason the send fails or the recv fails.

    Thanks,
    Ajay

    February 28, 2017 at 3:13 pm #17562
    Mike Fiore
    Blocked

    Ajay,

    Events should fire even if the TX or RX fails. However, if you want to set a global timeout, you should just set it to accomodate the transmission time + the 2 RX windows that will potentially open. I think something like 5s would be OK for regular packets, but you’d probably want to do some testing and validation before picking a specific value. For example, the RX1 window after a join request in EU868 doesn’t open until 5 seconds after transmission is complete if the device is in public mode.

    Cheers,
    Mike

    February 28, 2017 at 3:56 pm #17563
    Ajay K
    Participant

    Thanks Mike, the LORA network is being used in private mode. So worst case 5 seconds per uplink is what you think I should wait for an inbound packet and ack, before I timeout on the main thread? Obviously I am guessing the spread factor effects this timeout and we will be having ADR enabled as well, so this time may change in your opinion?

    Based on your last comment, the receive windows are not opened until a transmit is complete, in my case since Ack’s are enabled, until an ack is received correct?

    Just one other question, although not related to the receive timeouts, if I enable ADR, I should still be setting a default Spread factor right/data rate right? I currently set SF10 the longest range by default for the US915 frequencies.

    Thanks,
    Ajay.

    February 28, 2017 at 4:04 pm #17564
    Mike Fiore
    Blocked

    Ajay,

    I am not saying a 5s timeout is a worst case number that will cover every possible scenario. It depends on a lot of settings. If you have ACK retries enabled, that will obviously affect how long your timeout should be as the Dot can make multiple attempts (each with its own RX1 and RX2 windows) before giving up. Also ADR, like you mentioned, may change the datarate. You can use the Dot library to estimate time on air with different datarate settings and payload sizes.

    You will have to analyze your settings and determine what the maximum timeout is based on those settings. I can’t provide you with a “magic number” for your timeout.

    Hope this helps!

    Cheers,
    Mike

    February 28, 2017 at 5:32 pm #17576
    Ajay K
    Participant

    Thanks Mike for your response. I guess during testing we can figure out this better as what the optimal timeout could potentially be. However we are hoping we reduce the wake time to a more considerable number, so we don’t burn thru’ the battery. I wasn’t aware we could enable ack retries.

    Thanks,
    Ajay.

    March 2, 2017 at 3:55 pm #17639
    Ajay K
    Participant

    Hey Mike,

    I was just thinking, you must be figuring out at your end when to call the txTimeout and the receive window timeout right? Can I just not use those timeouts as to how long I need to wait before giving up in my main thread This is just to keep a fail safe in the event worst case the mac events don’t fire. However we will be doing testing at our end for various ranges and see what the timeout windows as you suggested earlier. But my guess is the mdot code base must have either a calculated timeout or a hard timeouts set? Would you be able to share that information?

    Thanks,
    Ajay

  • Author
    Posts
Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.