> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/foodcore-sensors/admin/device-management/spread-factor-sf.md).
# Spread Factor (SF)
Understanding Spreading Factor (SF)
### Overview
Spreading Factor (SF) is a critical parameter in LoRaWAN communications that influences the range, reliability, data rate, and battery consumption of a LoRa device. This document provides technical insights into SF, its operational implications, and guidance for optimizing sensor performance within commercial environments such as cold rooms and kitchens.
| | |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|  |  |
***
### What is Spreading Factor (SF)?
Spreading Factor defines the duration a LoRaWAN device takes to transmit data. It essentially determines how many chips are used per symbol in modulation. Higher SF values increase the transmission range and reliability of a signal, but at the cost of lower data rates and greater battery usage.
Key Range:
* SF7 to SF12
Typical Use Cases:
* SF7-SF9: Optimal performance, fast data rate, lower power consumption.
* SF10-SF12: Used when signal penetration is difficult or range is extreme. Increases reliability but reduces battery life.
***
### Ideal Operating Range
For most indoor commercial kitchen or cold storage deployments:
* Recommended SF Range: SF7 to SF9
* Ideal SF: SF7 (strong signal, efficient battery usage)
High SF (e.g., SF11-12) is generally indicative of signal degradation, which may be due to environmental interference or distance from the gateway.
***
### Technical Explanation
| Spreading Factor | Data Rate (bps) | Range | Power Consumption |
| ---------------- | --------------- | ------ | ----------------- |
| SF7 | High | Short | Low |
| SF8 | Moderate | Medium | Moderate |
| SF9 | Lower | Medium | Increased |
| SF10-SF12 | Very Low | Long | High |
* Higher SF = Longer transmission time = Higher energy consumption
* Lower SF = Quicker communication = Better battery efficiency
***
### Visualizing in Didge
Refer to the following images for insights on SF:
1. Battery vs SF Scatter Plot:
* Devices operating at SF11 (orange dots) show increased battery drain.
* Clusters at SF7-SF8 indicate healthy deployments.
2. Device Table in DIGG:
* Devices listed with SF11 are highlighted in red.
* Typical voltages are around 2.7V. As SF increases, expect faster battery drop.
***
### Causes of High Spreading Factor
* Distance from the gateway
* Thick walls or refrigeration barriers
* Metal enclosures or RF interference
* Sensor placement inside shielded zones (e.g., inside freezers)
***
### Consequences of High SF
* Battery drain: Higher SF leads to more frequent and longer transmission bursts.
* Delayed updates: Lower data rate reduces message throughput.
* Network congestion: Longer airtime increases collision risk.
***
### Recommendations to Improve SF
* Optimize Gateway Placement:
* Place the gateway near the center of monitored zones.
* Ensure line-of-sight where possible.
* Use External Antennas:
* Especially for freezers and enclosed units.
* Avoid Obstacles:
* Metal racks, refrigeration compressors, and walls can affect signal.
* Monitor Regularly via DIGG:
* Use the Battery & Signal tab to identify underperforming devices.
* Replace or relocate any unit with persistent SF > 10.
***
### Summary
Spreading Factor is a key performance metric for LoRaWAN sensor communication. Ensuring that sensors operate within the SF7 to SF9 range leads to:
* Longer battery life
* Reliable signal
* Higher data throughput
Proper network planning and periodic review of DIGG dashboards can significantly improve operational stability in sensor-reliant environments.
***
Document Owner: MFC Safe Technical Team
Version: 1.0
Date: July 2, 2025
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.didge.io/home/foodcore-sensors/admin/device-management/spread-factor-sf.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
