# LMiC's TX\_COMPLETE event takes 20-30 seconds to fire **URL:** \ **Category:** End Devices (Nodes)\ **Created:** [June 29, 2016, 9:08am UTC](https://www.thethingsnetwork.org/forum/t/lmics-tx-complete-event-takes-20-30-seconds-to-fire/2639 "2016-06-29T09:08:44Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [June 29, 2016, 5:27pm UTC](https://www.thethingsnetwork.org/forum/t/lmics-tx-complete-event-takes-20-30-seconds-to-fire/2639/5 "2016-06-29T17:27:10Z")
> [@matthijs](#): > > > It looks like the device is waiting for a TX window. Is it possible to remove this? > > No, because then you would violate the duty cycle regulations for the frequencies used. I _think_ Diederik does not want to transmit more often\*, but just wants to sleep more? But indeed, it seems that the `EV_TXCOMPLETE` not only takes receive windows into account, but also duty cycles†, and then keeps the device awake. But even then, 20-30 seconds seems _far_ too long for about 21 bytes to send something like `T:12.34H:12.34B:12.34` on SF7, where a 1% duty cycle yields something like 7 seconds waiting time after sending? Or are the float values much longer than `12.34`, @DiederikRhee? * * * \* Even though the current sleep of 64 seconds seems very low for temperature readings, and yields a daily air time [far above the TTN Fair Access Policy](https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-day-fair-access-policy-nodes-per-gateway/1300) when sending 20+ bytes. So yes, send less often, and send binary, like already suggested. † While, officially, a _different_ frequency could be used for the next transmission much sooner? --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/lmics-tx-complete-event-takes-20-30-seconds-to-fire/2639)._