long-range, wide -area sensor networks
- Wireless sensor networks with a 10 km range
- Monitor soil moisture, hydrology, weather, plant water relations, nutrients, EC, water quality, and more
- Pre-configured, programmed, wired and ready to install
- Online data viewing and management
- Smart phone apps for quick and easy data viewing
our LoRaWAN capabilities
Edaphic Scientific is a leading specialist in LPWAN or LoRaWAN systems – long-range, wide-area networks – for environmental monitoring and research projects. Our LPWAN or LoRaWAN systems cover applications ranging from agriculture, horticulture, aquaculture, mining, landfills, and scientific research.
Edaphic Scientific is a one-stop shop for all your monitoring requirements. We provide a complete monitoring solution for your project. We not only provide the LoRaWAN infrastructure, but we source a wide range of sensors from our extensive and unique product catalogue. Everything is configured, programmed, wired and ready to install. Alternatively, one of our trained staff can travel to your field site and assist you with the installation.
Edaphic Scientific is a specialist supplier and distributor of environmental research and monitoring equipment. Through a global network of suppliers, we are able to provide a comprehensive range of sensors at an affordable price. Our sensors include:
- Soil moisture, temperature and EC
- Soil water potential
- Weather and meteorology
- Groundwater including water level sensors
- Air quality sensors
- Dissolved oxygen
- Greenhouse gases including CO2 and CH4
- Plant water use, growth and canopy temperature
the LoRaWAN advantage
LoRaWAN is a wireless sensor network that can have a range between 0 and 10 km. This has significant advantages over other wireless technology, such as WiFi and Bluetooth, that can only operate over a few metres.
LoRaWAN also has an advantage over cellular, or modem, devices. Each cellular device requires its own SIM card, or modem, with associated data access fees. With a LoRaWAN system, it is possible to have many devices communicating to a single hub. Furthermore, in remote locations there may not be any cellular signal so a modem device cannot operate. A LoRaWAN system can potentially operate without a cell signal. Therefore, LoRaWAN can be more cost effective, versatile and reliable than 3G/4G/5G enabled devices.
LoRaWAN are low-powered systems. Our range of sensors, and the LoRaWAN infrastructure, require small amounts of power. Therefore, power can usually be supplied with small batteries or solar panels. The LoRaWAN system avoids the need for extensive and large solar panels and battery systems.
how does LoRaWAN work?
A SENSOR (for example, soil moisture, temperature or water level) is connected to a sensor node, called a HUB (part numbers: HUB-L1 or HUB-12S). A HUB can support between one and many SENSORS, depending on the configuration.
Each HUB has an antenna and communicates via a wireless distance of up to 10 km to a GATEWAY.
The GATEWAY then sends data to a secure, cloud based server via a modem or ethernet connection.
A PC or smart phone then accesses the data from the secure server via our data management platform or smart phone app. Data can be viewed in real-time, on these platforms, or downloaded into a CSV file for further data manipulation and analysis.
types of GATEWAYS
This is a high end, outdoor Gateway, suitable for use on large farms, research sites or in regional networks. The GATEWAY has a range of 10 km.
TTN (The Things Network) Indoor GATEWAY
The TTN can be mounted inside an office and which, because of the lower range, will be suitable for smaller farms, smaller research sites, or installations. Note that this unit could also be fitted with an external antenna and suitable length cable, to allow the antenna to be mounted higher and hence give increased range.
more information on HUBS
HUBS which use LoRa WAN Class A mode simply wake up at a nominated rate and transmit their data. Ways to avoid collisions (whereby 2 or more devices transmit at the same time) are left to the hardware designers.
In the case of the HUB-12 and HUB-L1 supported by Edaphic Scientific, each node can be programmed with a different Wait Time – think of this as equivalent to the GPRSCONNALIGN on an Adcon system. All you have to do when building a large network is to offset the time for each new device as you add it. If a server needs to send data back to the Node (for instance to make a configuration change) devices will listen at the end of their transmission for a message back from the Gateway. If one comes, they stay awake and download the incoming message (which could be a configuration change or firmware update or a command to turn on an output).
LoRa Class B by comparison allocates a time slot for each device – formalising the time slot approach we are using with the HUB-12 and HUB-L1. For this strategy to work properly, the time in the system needs to be accurately maintained. To support this, the new version of the GATEWAY (see above) adds a GPS receiver: as satellite navigation systems need an accurate time reference to work, the same technology can be exploited to create a time reference for LoRa WAN. We can expect that over time LoRa WAN Class B mode will become the norm for networks requiring reliable data transmission and hence become the norm in our areas of activity.
LoRaWAN Class A, Class B and Class C
LoRa WAN Class A mode simply wake up at a nominated rate and transmit their data.
LoRa Class B, by comparison, allocates a time slot for each device.
LoRa Class C is always on and is highly responsive but requires a larger power supply than Nodes with Class A and B modes.
The limitation of Class A and Class B devices is that a device can only receive information back from a Gateway either just after it makes a transmission (Class A) or in the designated time slot (Class B). What happens if a device needs to respond immediately – for instance to turn on an output or respond to an alarm?
In Class A and B, that is not possible and this is where Class C comes in to play. LoRa WAN Class A and B are specifically designed to minimise power consumption and hence maximise battery life: given that the major current drain in a radio system is the power used by the receiver, in both modes the receiver is kept switched off as much as possible.
Class C is designed for units which do not have any power limitations: the receiver is permanently on, so that it can always listen for incoming transmissions. That means rapid response to commands. For Class C operation to work, we need to power the nodes from a DC power source (plugpack etc.) or a suitably sized solar cell and battery. Once Class C is available in the Gateways, expect a flurry of LoRaWAN based control applications / products.
To ensure things are kept interesting, there has been a bit of action in the area of the LoRaWAN operating frequencies. The channel plan adopted by the government agencies in Australia and New Zealand is designated as “AU915” and allows for 8 sets of sub-bands, each offering 8 channels – 64 channels in total. New Zealand’s spectrum allocations were even changed to make sure that this channelling could be adopted in the country. Since most Gateways can only support 8 channels, Gateway operators nominate a sub band to work on, and most are currently using sub band 2. Eventually 64 channel gateways will be released, but they will only be viable in very heavily built up cities. Anyone wanting some extra protection/privacy could switch to one of the infrequently used sub-bands, where there will be less traffic.
But recently there has been a push for networks in Australia to use the AS923 channel plan, which was developed around the spectrum allocation plans found in the Asian countries, which operate on frequencies around 923 MHz rather than the 915 MHz of the AU915 plan. This move is driven by the commercial self interest of companies products who sell AS923 based and don’t want to support a separate set of equipment for Australia. Some AS923 pundits have gone as far as saying that AS923 is superior, which is not correct – just a convenient distortion if your chipset vendor has not added support for AU915 to their firmware. Fortunately, we are well on top of this and AS923 support is built in to the firmware of the HUB-12 and HUB-L1. So changing between AU915 and AS923 is a very quick and simple process: select the channel plan from the drop down list and then enter the required frequencies. For now, if you intend working with any existing LoRaWAN providers, you will need to first confirm with them whether they are running on AU915 or AS923 and then set the nodes accordingly.
introduction to the LoRa Alliance
manuals & docs