---
title: "Periodics & Bursting"
canonical: "https://farmconnect.docs.rubiconwater.com/space/FER/2054651905/Periodics%20%26%20Bursting"
format: markdown
---
> Macro (toc)
Each driver installed in the FerIT has a standard set of variables used for timing basic functionality, (Periodic Period, Burst Period and Burst Mask)
- The **Periodic Period** is the frequency in which any local processing will occur for this driver, for example a modbus poll or a volume accumulation calculation. This period typically operates at a higher frequency than **Burst Period **to provide meaningful real time updates to a user via DeviceConnect or FerIT Display.
- A **Burst Period** is the frequency in which data collected or calculated in the periodic period is sent to the remote driver (Radio) for bursting over the wireless network. Configuring this allows the user to display more resolution in remote user interfaces such as FarmConnect or ScadaConnect.
- The **Burst Mask **is a predetermined set of variables for a single driver that are queued up to be sent over the radio network together at the defined **Burst Period**. These masks can be found in the specific drivers variable documentation found here: [FerIT Drivers](https://bitbucket.org/rubiconwater/ferit-documentation/src/master/md/).
The FerIT has multiple different ways in which these Periodics Periods and Burst Periods can be managed for use with different products or depending on the size of the network to ensure stability.
The two main methods are:
- **Standard Bursting** – As described above each drivers independently manage and trigger periodics/bursts
- **Burst Profiles** – Managed periodic/bursting, dynamically updated across all or multiple drivers controlled by a single point of truth typically the App Driver.
> ℹ️ P400 FerIT devices act differently to other variants
> ℹ️
> ℹ️ All individual driver periods are disabled in a P400 device, and the **MDLC driver** will control the trigger of bursts
> ℹ️
> ℹ️ That means only the **MDLC Driver Burst Period** needs to be set on these device types
# Standard Bursting (default)
The standard burst profile lets each driver manage their own **Periodic **& **Burst **periods.
Each driver will independently manage their processing and burst timing, then pass the **Mask** to the radio driver. The radio driver will then create the payload message and transmit.
When using the default burst profile, the burst period in each individual driver (including the app driver) should be set to suit the applications needs. Most drivers default to **15 or 30 minutes** for both Periodic and Burst Periods. For situations such as event control, critical sensors may need a faster **Periodic Period** such that data is more real time and can be acted upon promptly.
When a burst period is reached, each driver will trigger its periodic functionality (eg. Modbus Poll) independently of **Periodic Period**, this ensures the latest sensor data is collected, and send to the remote driver for burst.
For LoRa variants it is important to note that the amount of data that can be sent in one payload is limited based on region and the connected data rate of the node. If drivers are in sync and attempt to burst at the same time remote driver may separate the data into multiple burst packets.
#### **To set the burst periods (if defaults not appropriate)**
1. Connect to the FerIT node using Device Connect
2. One-by-one, go into each installed driver tab and look for the Burst Period variable
3. Set the Burst Period variable to the desired setting
4. Trigger a reset the device (though DeviceConnect), This calls the save to flash command and the new burst period will be in effect after the reboot.
# Alternate Burst Profiles
Selecting and enabling other burst profiles is handled via the FerIT App Driver tab in DeviceConnect
Selecting a burst profile will immediately reset any profile related config back to the defaults of the selected profile
> ⚠️ To use an alternate burst profile FerIT firmware must be 1.7.2 or greater.
## Key Config Variables
| **Variable Title** | **Description** |
| --- | --- |
| Burst Profile | The profile to use:
`"Standard" as described above`
`"Irrigaiton" adjusts burst frequency with "Low Flow" status of flowmeter ` |
| Burst / Period Sync Type | Which drivers will have their Burst/Periodic periods synchronized to the profile rules/logic. For Irrigation bursting leave this as the default (All) unless advised by engineering or support.
`"None" no drivers syncronised - disabled`
`"All" All drivers syncronised on state change`
`"Only Flow" Only flow meters syncronised on state change`
`"Irrigation Sensors" All Irrigation Sensors (Flow, level, pressure) on state change`
`"Only Remote Task" Remote task only`, i.e. LoRa/P400 driver only
> ℹ️ P400 and LoRa driver will always get sync’ed unless “None” being selected, since FerIT firmware version 2.1.0.
> ℹ️ P400 FerIT devices will always default to and should be left at - ‘Only Remote Task’ |
1. Select the Burst Profile to use
2. Refresh the related profile configuration to see the default values
3. Edit the defaults as required
4. Trigger a reset the device (though DeviceConnect).
## Irrigation Bursting
The Irrigation bursting profile updates the bursting period based on the IRRIGATION STATUS of the device. This burst profile is only relevant to installs with a flow meter.
The purpose of this mode is to minimise network bandwidth when a device is NOT IRRIGATING
The IRRIGATION STATUS is set by the LOW FLOW state of the meter. All FerIT flow meter drivers have this low flow status alarm, as well as a low flow threshold that can be configured.
**Key Profile Config Variables**
| **Variable Title** | **Description** |
| --- | --- |
| Irrgt Burst Period | The burst period to syncronise with drivers when the FerIT has detected an IRRIGATING state
**Default: 30 minutes** |
| Irrgt Periodic Period | The **Periodic Period **to syncronise with drivers when the FerIT has detected an IRRIGATING state
**Default: 30 minutes** |
| Delay Till Irrgt | Delay before transitioning from NON-IRRIGATING to IRRIGATING
**Default: 0 (inactive)** |
| Not-Irrgt Burst Period | The burst period to syncronise with drivers when the FerIT has detected an NON-IRRIGATING state
**Default: 12 Hours** |
| Not-Irrgt Periodic Period | The **Periodic Period **to syncronise with drivers when the FerIT has detected an IRRIGATING state
**Default: 30 minutes** |
| Delay Till not-Irrgt | Delay before transitioning from IRRIGATING to NON-IRRIGATING
**Default: 0 (inactive)** |
### **Low Flow Configuration:**
Flow meter drivers will perform a low flow calculation **after** polling the meter for flow data. The low flow threshold for these meters must be set through DeviceConnect in the flow meter driver.
The low flow threshold can either be velocity or flow based, depending on the meter. Additionally some meter types have in-built low flow calculation. For these meters the low flow threshold must be configured in the meter directly. Check the meter manuals for enabling and setting up the the low flow threshold on these meter types
### **Current Supported Meters:**
| **Flow Meter** | **Low Flow Status** | **Low Flow Type** |
| --- | --- | --- |
| Aquamonix I300 | FerIT Calculation & Meter Alarm | Velocity |
| Aquamonix I500 | FerIT Calculation & Meter Alarm | Velocity |
| Mace Flow Series 2 | FerIT Calculation | Flow Rate |
| Mace Flow Series 3 | FerIT Calculation | Flow Rate |
| Siemens MAG8000 | FerIT Calculation | Flow Rate |
| Bermad M10 | FerIT Calculation | Flow Rate |
| Pulse Flow Meters | FerIT Calculation | Flow Rate |
| Rubicon Sonaray | Meter Alarm | Flow Rate |
| Rubicon SmartMeter | FerIT Calculation | Flow Rate |
### **Example:**
Mace Flow Series 3 settings example and expected functionally:
- **App Burst Period:** 30min (Ignored)
- **Mace FS3 Burst Period:** 60min (Ignored)
- **Mace FS3 Periodic Period:** 5min
- **Mace FS3 Low Flow Cut-off: **0.05ML/d
- **Burst Profile: **Irrigation
- **Burst Period Sync Type: **ALL
- **Periodic Period Sync Type:** None
- **Irrigation Burst Period:** 10min
- **Irrigation Periodic Period: **30min (Ignored)
- **Delay til Irrigation: **0 (no delay)
- **Non Irrigation Burst Period:** 12hours
- **Non Irrigation Periodic Period: **30min (Ignored)
- **Delay til non-Irrigation: **0 (no delay)
With the above settings the bursting and periodic functionality would behave such that, the Mace FS3 will always be polled every 5 minutes for modbus data. This is controlled by the **Mace Driver Periodic Period** as **Periodic Period Sync Type** is set to none, so a standard arrangement is used. This modbus poll will read the current flow rate from the meter. When the flow rate is is greater than 0.05 ML per day. The FerIT will Trigger a burst of all drivers every 10 minutes as the **Burst Profile** is set to irrigation and the **Bust Period Sync Type ** is set to all. When the 5 minute periodic detects a flow rate less than 0.05 ML per day, The FerIT will do a burst to transition states and also a burst of the low flow alarm. The Bursts will then only occur every 12 hours as per the **Non Irrigation Burst Period** Setting, However the modbus polls will still occur every 5 minutes in case flow resumes and the device needs to transition back to the irrigating state.
# Extended Bursting
The extended bursting functionality has similar functionality to the standard bursting. Each driver will contain a fixed **Extended Burst Mask** and an adjustable **Extended Burst Period**, during which less dynamic information can be delivered. This is typically done at a much slower rate, such as once a day. The mask is static and used for information that may not change often but is still important to track and monitor from a diagnostics perspective.
The extended bursting mode operates independently of any alternative burst profiles. Therefore, the period of the extended burst will not be affected by any synchronization changes that the alternative burst profile may make
> ⚠️ Extended Bursting is only present in FerIT firmware must be 1.13.0 or greater.
> ⚠️
> ⚠️ Extended Bursting is only a LoRa Firmware feature, will not have any effect on P400 nodes which burst the entire table.
# Non-Periodic Data Bursting
In addition to periodic bursting, certain drivers might also incorporate change-of-state or alarm bursting. This involves transmitting bursts of data for individual or predefined groups of variables when specific conditions arise. It's important to note that bursts of this nature will not impact the timing of any periodic bursting and will still occur independently of any burst profiles. These bursts are considered critical and will be confirmed LoRa Uplinks with retries to ensure delivery to the host application.