# Does the RFM95 need a minimum delay between switching from Tx to Rx?

**URL:** <https://www.thethingsnetwork.org/forum/t/does-the-rfm95-need-a-minimum-delay-between-switching-from-tx-to-rx/7663>\
**Category:** End Devices (Nodes)\
**Created:** [June 3, 2017, 11:32am UTC](https://www.thethingsnetwork.org/forum/t/does-the-rfm95-need-a-minimum-delay-between-switching-from-tx-to-rx/7663 "2017-06-03T11:32:54Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**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 5, 2017, 12:11pm UTC](https://www.thethingsnetwork.org/forum/t/does-the-rfm95-need-a-minimum-delay-between-switching-from-tx-to-rx/7663/4 "2017-06-05T12:11:53Z")

</div>

> Header Disabled

Why?

And how did you get to 222 ms? If that’s 25 bytes _application_ payload (plus 13 bytes for the LoRaWAN header, so a total of 38 bytes), then the time-on-air for SF9 [is 267 ms](https://www.thethingsnetwork.org/forum/t/spreadsheet-for-lora-airtime-calculation/1190). Or, if it’s 25 bytes _total_, so 12 bytes of application payload, then 206 ms.

Also beware that nodes might have a random delay before they truly start sending? At least, [the specifications state](https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf#page=9), emphasis mine:

> **2.1 LoRaWAN Classes**  
> …  
> The transmission slot scheduled by the end-device is based on its own communication needs **with a small variation based on a random time basis** (ALOHA-type of protocol).

Finally, note that LoRaWAN explicitly defines when to expect a possible downlink (see `RECEIVE_DELAY1` and `RECEIVE_DELAY2`), so listening after 500 ms is too soon for LoRaWAN.

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/does-the-rfm95-need-a-minimum-delay-between-switching-from-tx-to-rx/7663)._