Enabling Ack and Power consumption.

Home Forums mDot/xDot Enabling Ack and Power consumption.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #22582
    Ajay K
    Participant

    In our custom application, we have enabled Acks and currently set the retry count to 5. We have the added the acks so we can get a guarantee that the message was delivered to the conduit. However i was wondering if this has a performance penalty or any kind of higher power draw as a result of the retries? We seem to notice that the mdots that are a larger distance from conduit seem to burn up batteries faster than the once that are relatively close by to the conduit.

    Thanks,
    Ajay.

    #22598
    Steve Kovarik
    Moderator

    Hello Ajay

    With Acks set to 5, any Acks not received by the LoRa endpoint will cause a
    retransmit. Multiple retransmissions can cause the endpoint to consume more
    power. Also if Adaptive Data Rate (ADR) is enabled, further distance LoRa
    endpoints can increase transmit power and spreading factor (increasing time on air)
    resulting in more power consumption.
    -Best Regards

    #22611
    Ajay K
    Participant

    Thanks Steve for your valuable inputs. We do have ADR enabled as well. Is there a reasonable ACK count that can be set which could reduce power consumption.

    Thanks,
    Ajay

    #22615
    Steve Kovarik
    Moderator

    Hi Ajay
    For fringe nodes consuming more power, the main factor (with ADR enabled) is
    that LoRa endpoints further away need to transmit at a higher power level
    and/or a longer on air time to overcome the greater distance.
    I would expect LoRa endpoints further away to consume more power to help
    ensure successful transmission. Regarding the use of ACKs, there is also
    trade-offs (power usage, network capacity) for ensuring data integrity.
    To get around this, some developers perform data integrity checks at the
    application level rather than the RF level. An alternative to enabling ACKs
    for all packets is periodic connectivity checking using “link check count”
    with “link check threshold”. This is used to detect when the network is not
    available or the session information has been reset at the server.
    Link count check defines a number of packets sent before a link check is
    performed. Link count threshold sets the threshold for the number of
    consecutive link check failures to tolerate before setting the join status
    to not joined.
    -Best Regards

    #22625
    Ajay K
    Participant

    Thanks Steve for taking the time to respond and with all the details mentioned in your response. I was just wondering are there any samples on the multitech/mbed site which uses the link checks as an alternative to acks for all packet transmissions.

    Thanks,
    Ajay.

    #22630
    Steve Kovarik
    Moderator

    Hi Ajay

    Looking at the mDot/xDot example programs, both the OTA and AUTO_OTA example
    programs have ACKs disabled, but network link checks are configured –
    if enough link checks are missed, the Dot will no longer be considered
    joined to the network and will attempt to rejoin before transmitting more data.
    https://os.mbed.com/teams/MultiTech/code/Dot-Examples/?platform=MTS-mDot-F411

    -Best Regards

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