# Best practices to limit application payloads **URL:** \ **Category:** Application Development\ **Created:** [February 21, 2016, 4:13pm UTC](https://www.thethingsnetwork.org/forum/t/best-practices-to-limit-application-payloads/1302 "2016-02-21T16:13:39Z")\ **Posts on this page:** 1\ **Showing post:** 1
**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:** [February 21, 2016, 4:13pm UTC](https://www.thethingsnetwork.org/forum/t/best-practices-to-limit-application-payloads/1302/1 "2016-02-21T16:13:39Z")
Application payloads should really be limited, if only to comply with [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) of 30 seconds per day for uplinks, and 10 _messages_ per day for downlinks. Let’s compile a checklist of best practices to achieve that: - Always, _always_, **always** use binary encoding to send your data. See [The Things Uno MQTT Workshop](https://github.com/TheThingsNetwork/examples/blob/master/workshops/TheThingsUno/README.md#get-your-data) for an introduction to TTN’s payload functions to help you decode it. - Do not send a precision that is higher than your use case needs, or your sensors offer. Like a GPS unit might be less accurate than you think; see [Best practices when sending GPS location data](https://www.thethingsnetwork.org/forum/t/best-practices-when-sending-gps-location-data/1242). - Combine sensors in a single device, or when collecting data that is not needed realtime then consider sending in small batches. As the LoRaWAN protocol always adds [at least 13 bytes of overhead](https://www.thethingsnetwork.org/forum/t/spreadsheet-for-lora-airtime-calculation/1190/4) to the application payload, and also needs some air time to send some more housekeeping data, a 55 bytes application payload might only need 2 to 2.5 times more air time compared to 8 bytes. See [Spreadsheet for LoRa airtime calculation](https://www.thethingsnetwork.org/forum/t/spreadsheet-for-lora-airtime-calculation/1190), and compare different payload sizes with different spread factors. - When a single node has multiple sensors for which to expect similar readings, maybe a single (multi-byte) value of one sensor plus (smaller) offsets for the other sensors can decrease the data size. - Only send (in short intervals) when the data has changed more than some threshold. (But consider sending more often whenever the data changes, if only as that makes it easier to detect faulty sensors that emit readings that change randomly.) - If it’s about finding lost things or reading data on command (rather than tracking continuously), assuming a LoRaWAN Class A device (where an end-device can receive some data right after sending some), and when not expecting the device to move out of range: ~~make the device send a small “alive” packet quite often, and only if the application responds in some specific way, send a measurement. (This might also preserve battery life.)~~ _(it seems [even “alive” packets need quite some air time](https://www.thethingsnetwork.org/forum/t/spreadsheet-for-lora-airtime-calculation/1190/12) and would quickly hit the maximum daily Fair Access Policy limit; to be continued…)_ But note that the application should then only reply in a specific way when data is needed, and [keep silent if not](https://speakerdeck.com/wienke/the-things-network-2016-update#28): - When sending battery level, there is no need to include that in every single packet. - If your node can send different message types: [use the LoRaWAN “port” to define what payload is sent](https://www.thethingsnetwork.org/forum/t/measuring-coverage-gateway/1051/33). - If you have old and new nodes that use different encodings of their data: as one can always determine the node’s ID from the LoRaWAN header, one does not need to send any software version if one keeps a proper administration of node IDs and their installed software. * * * † Beware that FCntUp [might also be increased for non-application uplinks](https://www.thethingsnetwork.org/forum/t/use-fcntup-as-a-pulse-counter/36090/6), like for responses to MAC commands. --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/best-practices-to-limit-application-payloads/1302)._