Enabling Ack and Power consumption.
Tagged: MDot Acks enabled, power draw
- This topic has 5 replies, 2 voices, and was last updated 7 years, 2 months ago by
Steve Kovarik.
-
AuthorPosts
-
February 14, 2018 at 11:37 am #22582
Ajay K
ParticipantIn 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.February 15, 2018 at 12:17 pm #22598Steve Kovarik
ModeratorHello 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 RegardsFebruary 16, 2018 at 2:57 pm #22611Ajay K
ParticipantThanks 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,
AjayFebruary 16, 2018 at 4:55 pm #22615Steve Kovarik
ModeratorHi 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 RegardsFebruary 18, 2018 at 2:43 pm #22625Ajay K
ParticipantThanks 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.February 19, 2018 at 10:30 am #22630Steve Kovarik
ModeratorHi 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
-
AuthorPosts
- You must be logged in to reply to this topic.