Non-blocking join

Home Forums mDot/xDot Non-blocking join

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #22418
    EG
    Participant

    Is it correct that the joinNetworkOnce api call for an OTA join blocks until the gateway responds (~5 seconds for the public network configuration)?

    Is it possible to perform a non-blocking OTA join on the xDot through the binary libXdot library? Ideally, I’d like to send a join, put the MCU to sleep with an RTC wakeup (or be woken up via interrupt), and then check for the join response. My goal is to use as little power as possible during the join process.

    The send provides a non-blocking option, so I’m hoping the join does as well.

    Thanks.

    #22421
    Jason Reiss
    Keymaster

    The dev version of the library has this as an option.
    It will be included as a feature in the next release.

    https://os.mbed.com/teams/MultiTech/code/libmDot-dev-mbed5/

    /**
    * Set auto sleep mode
    * Auto sleep mode will automatically put the MCU to sleep in between receive windows
    * Note: The MCU will go into a stop mode sleep in between rx windows. This means that
    * peripherals such as timers will not function during the sleep intervals.
    * @param enable – Flag to enable auto sleep mode
    */
    void setAutoSleep(bool enable);

    #22422
    EG
    Participant

    Just to be clear – it will also sleep between send and rxw1?

    #22424
    Jason Reiss
    Keymaster

    Yes it will sleep after end of tx until the start of rx1.

    #22426
    EG
    Participant

    Thanks, that’s perfect!

    #22462
    EG
    Participant

    I did some testing with the tip of the dev branch today and it looks as if the mcu remains on throughout rx and tx rather than going to sleep and waking up via txdone/rxdone interrupts. Is that true? If so, do you have any plans to change this? This can consume a lot of power, especially during the long dr0 toa.

    #22463
    Jason Reiss
    Keymaster

    We have no plans in the near term. This would be a lower level change that we can look into for a future release.

    Thanks for the feedback.

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