We have deployed close to 900 of our Weatherbee units across India for a certain e-commerce player. These are low-maintenance, battery powered, non-mechanical (no moving parts), lightweight weather stations that intelligently measure and relay hyper-local temperature, humidity, atmospheric pressure, and rain information.
We have been working with LoRaWAN® since its early years, and our initial version of Weatherbee also used the LoRaWAN® stack and SoCs from Microchip. As we have mentioned in this blog post, the technology is insanely great for battery powered sensors like ours, giving us multi-year lifetime out of Duracell AA cells while still transmitting multiple kilometers wirelessly. The issue with LoRaWAN® was (and continues to be), the availability of a sufficient density of gateways and network that could pick up these sensor signals across the country. We had tied up with a major Indian telecoms network that provided us their LoRaWAN® network as a service, but their coverage was limited to the main cities and as we found it recently, reducing in density. While setting up our own LoRaWAN® gateway at each location was plausible, it was impractical considering the cost, configurations and the lack of sensor density per gateway that could ever justify its deployment.
To provide our end-customers the coverage they required, we built our support for NB-IoT using Nordic Semiconductor’s nrf9151 and SIM cards (topic for another post). For coverage, we integrated with another major national carrier in India that had a nation-wide NB-IoT coverage and an NIDD platform. NB-IoT is essentially the GSM world’s answer to LoRaWAN®. And NIDD is essentially a carrier signaling channel socket alternative to TCP connections that we normally have on GSM based devices. Its (almost) nation-wide coverage is a huge advantage. While it competes well with LoRaWAN® on battery consumption, LoRa still has an edge! LoRa/WAN truly is an amazing innovation from Semtech. Today, however, a majority of our deployed Weatherbee units run on NB-IoT.
Now, all Weatherbee units have to be mounted outdoor, at the highest possible point with a clear view of the skies, for obvious reasons. Also, a good proportion of our deployments are close to premises owned/ operated by our end-customer. And most of these premises have in-house Ethernet/ WiFi. We have deployed hundreds of WiFi based sensors and they have run reliably for years, but all of them were for indoor, in-premise applications like cold-room temperature sensors.
That’s when we wondered if we could combine the best parts of our solutions and develop a more robust, economical and scale-able innovation? The desirable parts were:
- Retain the same easy-to-deploy sensor units (Weatherbee in this instance, but it could be ANY sensor)
- Leverage LoRa® radio for the last-mile transmission (it gives the longest wireless range and battery consumption economics)
- Use Ethernet or WiFi for the back-haul connectivity to our servers (most reliable, at no additional cost but available only in-premise)
Enter LoRa P2P
So, we designed a new board that used a powerful ESP32-s3 SoC from Espressif and ISC-SX1262 module from IndieSemic that features the sx1262 SPI chip from Semtech.
This opened up a LOT of possibilities for us. For one, we could reuse all our libraries and code that we had been using for our WiFi devices. The sx1262 modules support upto +22 dBm max power (that is +4dBm more than the Microchip’s WLR089U) module specs. The S3 can run at 240Mhz, has a lot of GPIOs, native USB and best of all, still support a single digit uA deep-sleep current!
We added connectors and circuitry required to even connect an e-Paper display or any SPI sensor or device. Our circuits also feature a power-gating on all connected interfaces that allow us to completely power down the peripherals and power them up only when required.
We also designed an Ethernet breakout board featuring W5500 controller SoC that could be simply plugged in to the main board to make it Ethernet capable (along with LoRa, LoRaWAN, WiFi and BLE!)
What is the difference between LoRa® and LoRaWAN®
LoRa refers specifically to the physical radio frequency (RF) modulation technology while LoRaWAN is a communication protocol and open standards that uses LoRa for its RF modulation, multiple entities in its eco-system such as gateways and network servers that seamlessly enable all compliant devices and services to exist and communicate with the application servers. These standards are maintained by a community called the LoRa Alliance.
For an end sensor-node, the hardware remains the same for LoRa or LoRaWAN. You need a sensor, microcontroller, power source, a LoRa radio chip/ SoC. For LoRaWAN, we need to implement compliant firmware stacks depending on the country the end-device is going to be used in, provision with the credentials on both the network server and the device and just turn them on. Nothing else is required.
However, as mentioned, the only issue here is that unless the entire rest-of-the-infrastructure is in place, our sensor is just transmitting stuff into thin air and there is no mechanism to relay it to our servers. Where such infra exists, this is a great choice and that is exactly how we roll.
What do we do when a location may have just one or two sensor nodes and there is no justification to put up a full-fledged LoRaWAN gateway etc? That is one place where LoRa P2P shines in.
As the name suggests, if you have two identical nodes supporting LoRa radios, they can talk to each other. However, since is just RF, the onus is on us to create a communications protocol on top of this bare-bones radio to ensure compliance to RF standards for the region, make multiple sensors play fair with each other and to get the data to an IP network and thus to our servers.
There exist many ready-made projects/ protocols that help achieve this [eg: Meshtastic]. We decided to make one of our own since we wanted a tighter integration and a hub and spoke architecture.
The result? A deployment that looks as follows:
- Plug the gateway unit in to one of the free slots in-premise on an available internet switch/ router. Supply it power from a wall-power adaptor.
- Turn it on
- Fix the sensor node in its vicinity (say, within 1 Km range). This could of course be just battery powered.
- Turn it on
- Done!
Also, the LoRa gateway that we deploy is similar in cost to a sensor node; that reduces our capital expense. While running, it consumes low-power and negligible internet bandwidth resulting in a low operating expense. That’s a win-win for all involved.
This, for instance is a temperature sensor node that displays its output on an e-paper display
This is the compact lightweight LoRa gateway that reads such sensor data over LoRa radio and transmits them on over Ethernet/ WiFi:
The device is about as long as a finger and as wide as about two. It is lightweight and can be stuck on a wall using a double sided tape or two wall screws. Then plug in the ethernet cable to a free port on the internet router OR pair it to an exiting WiFi using the USB cable and our serial interface and that’s all what is required to get this going.
No additional configuration. Just plug and play. Our gateway protocol automatically handles device discovery, acknowledgements, queueing and of course data relay to our servers.
So if you need sensor data from multiple sensors but only have a limited location with WiFi/ Ethernet availability, extend your sensor range by having a LoRa P2P based ecosystem like the one we have.
Do reach out to us at info@tinkerbee.in to know more!
Note: Semtech®, the Semtech logo, LoRa®, and LoRaWAN® are registered trademarks or service marks of Semtech Corporation or its affiliates.