Edge Collective

Notes on wireless monitoring

Notes on wireless montioring (focused on LoRa).
)
Fig 1. Overview of a typical LoRaWAN architecture, via https://www.thethingsnetwork.org/docs/network/architecture/

LoRa

For wireless monitoring of assets, LoRa is a technology that emerged over 10 years ago that is now quite mature. There is a large online community of support, with plenty of documentation. It is used by both professionals and hobbyists. This means that you’re likely to find existing code to do most things of interest, and have forums on which to ask questions.

Business models

If trying to turn a profit on the hardware, then there are certain chips that are a little less accessible, but which have bigger ‘bang for the buck’ – the “STM32” family of chips. The development environment is more expensive to set up and less friendly, but deployment at scale might be optimized.

If the business is more focused on providing a service, collecting and interpreting data, and using proprietary algorithms, then it might be better to use hardware that is easier to tinker with, has a larger and existing codebase, and for which it will be easier to find developers.

Note that there exist off-the-shelf devices (cf. LSN50, Draguino) that have enclosures and which could begin by sending temperature and humidity readings, and also likely light and pressure, without too much tweaking or even much coding. This would give an option for deploying something wireless, quickly – especially if you have someone with coding / web development expertise on board, but don’t yet have an embedded developer.

FCC restrictions and rules

Note that there are FCC rules that apply to devices deployed in this manner. (See, e.g. https://www.sunfiretesting.com/LoRa-FCC-Certification-Guide/). LoRA operates in an ‘unlicensed’ band, but there are constraints on how much power you use can use when transmitting, the duty cycle and duration of transmission, and requirements to ‘frequency hop’. If you’re experimenting on a small scale with an initial deployment, this isn’t too much of a worry; but if you’re deploying at scale / professionally you’ll want to consider this. For any design you deploy an industrial context, you’ll need to get your final device FCC certified. (This appears to cost between $1K and $5K for a given final design.) Typically, I think, a system is developed, tested, and refined, and then FCC certified before large-scale deployment. Cf. https://linxtechnologies.com/wp/ufaqs/how-much-does-fcc-certification-cost/

LoRaWAN

The ‘LoRaWAN gateway’ architecture handles all of these requirements already. It is more complicated to set up than a few remote nodes, but it is an easier way to develop an FCC compliant system. (See, e.g. https://www.thethingsnetwork.org/docs/gateways/).

The tutorials and hardware provided by Adafruit (see, e.g., https://learn.adafruit.com/the-things-network-for-feather) are exceedingly well-documented. If you already have a particular suite of sensors you’re working with / have validated, this is the path I would take. You could e.g. develop the system / deploy it in stages:

Further Resources