BeeWatch: LoRaWAN Environmental Monitoring – Blog 11: Summary Conclusion

26 Apr 2023

BeeWatch: LoRaWAN Environmental Monitoring – Blog 11: Summary Conclusion

Bees are definitely an important part of the ecosystem and play a key role as a pollinator of plant life, including that of crops, while also producing honey. The emergence of colony collapse disorder has revealed the complex challenges which bees are facing, including the Varroa mite, increased pesticide usage and climate change. This challenge was about using technology to help “save the bees” and my proposal was a system called BeeWatch which would mainly perform monitoring that would help ascertain environmental conditions and hive activity.

Project Scorecard
Incidental Findings & Learnings
Conclusion

Project Scorecard

This is, perhaps, the first “full” design challenge I have participated in. Compared to the “experimenting with” series, this had a bit more latitude as well as a bit more work. Looking back on my project proposal introduced in Blog 1 gives me an opportunity to reflect on the progress of this long and rather complicated project which will be split into Core Deliverables, Stretch Goals and Ancillary Goals.

Core Deliverables

Proposed: Detail an unboxing of the challenge kit.
Result: Achieved
Key Outcomes: Blog 2 consists of a full unboxing in photos of the components included in the kit and discusses some of the required items that are not included.

Proposed: Monitor environmental conditions (temperature, humidity, particulate matter).
Result: Achieved
Key Outcomes: The Omron 2JCIE-EV01-AR1 Environmental Sensor Shield was repurposed from a prior RoadTest to provide temperature, humidity, brightness and barometric pressure measurements. A Sensirion SPS30 was selected as the particulate monitor sensor, combined with a MT3608 boost converter for the required 5V supply. Both were successfully integrated with the Arduino MKR WAN 1310 as of Blog 5 and Blog 6.

Proposed: Run monitoring station using PV and battery power.
Result: Achieved
Key Outcomes: The low power consumption of the MKR WAN 1310 and Omron Environmental Sensing platform meant that the environmental sensor could (theoretically) run for over 6 months from a pair of 18650 cells, meaning the use of solar power was not paramount as in Blog 5. However, the heavier particulate monitor requirements meant that solar PV power was necessary, thus a system was designed in Blog 6, deployed and verified functional in Blog 7.

Proposed: Connect station using LoRaWAN technology.
Result: Achieved
Key Outcomes: Purchase and deployment of a LoRaWAN gateway (not inexpensive!) proved necessary to obtain a connection with The Things Network, which was completed in Blog 4. Once regionalisation issues that were causing transmissions on incorrect frequencies were addressed for AU915 region, it was found that the Arduino MKR WAN 1310 is quite reliable, not once needing to be reset throughout the whole project once deployed outside. Frame counts over 15,700 were recorded.

Proposed: Measure power consumption of Arduino MKR WAN 1310 and Arduino Pro Nicla Vision.
Result: Achieved
Key Outcomes: In Blog 5, SMU-based measurements of MKR WAN 1310 current consumption at 3.7V shows a transmission current of 125mA, quiescent current of 13.72mA and a deep-sleep current of 60.4µA. In Blog 10, FNB58-based USB power measurements of the Nicla Vision showed current consumption at 5V ranging from 174mA on MJPEG streaming over Wi-Fi down to 19.2mA when in deep sleep.

Proposed: Receive data using MQTT and log results.
Result: Achieved
Key Outcomes: In Blog 7, I show how the MQTT integration works with The Things Network and include a Python paho-mqtt-based solution to connect with this integration and log the data. I also included the code for a very crude text-based parser that extracts values of interest from the JSON-object log and also demonstrate the use of the Storage API integration in case data is missed within the previous day.

Proposed: Examine RF-related aspects of LoRa and LoRaWAN.
Result: Achieved
Key Outcomes: Considerations about antennas were first raised in Blog 2, with a full consideration of LoRa and LoRaWAN connectivity in Blog 3. A LoRaWAN gateway was set up in Blog 4, while the data reported from the operational systems concluding in Blog 10 contains long-term SNR and RSSI metrics as recorded from my systems. Airtime considerations were also explored in the use of a second MKR WAN 1310 in Blog 6 and thought experiments in Blog 9.

Stretch Goals

Proposed: Use audio and infrared time-of-flight to measure proxies of hive activity.
Result: Achieved
Key Outcomes: Sample code was extended from OpenMV examples in Blog 9 to use the Nicla Vision board to connect to an MQTT server over Wi-Fi to report percentage time obscured for a hypothetical passageway as measured by the infrared time-of-flight sensor and audio amplitude metrics. Alteration to buffer sizes and processing of audio data would be required to make it more accurate.

Proposed: Process images to detect bees.
Result: Partially Achieved on a Simplified Problem
Key Outcomes: In Blog 10, I decided to simplify the vision classification problem to identifying the letter “B”, generating a dataset based on the fonts on my computer and training classifier and transfer-learning models using Edge Impulse. Inferencing was completed on computer, on device in Arduino mode and in OpenMV mode which is considered a partial success. However, the classification model was found to be very brittle and sensitive to position and scale. This is likely due to poor input data diversity and as bounding box method was not used, with further work necessary to produce practical solutions.

Proposed: Visualise data on a dashboard.
Result: Attempted, but Failed
Key Outcomes: An attempt was made in Blog 10 to use Grafana, however, while MQTT connection was successful, it seemed as if the data could not be properly parsed. A time-series database server (e.g. InfluxDB) appeared necessary upon further investigation. A second attempt was made using ThingSpeak and while a Webhook connection was successful, data ingestion was unsuccessful. While reverting to NodeRED could be a possibility, there was not sufficient time to implement the necessary infrastructure.

Ancillary Goals

Proposed: No bees harmed in the production of this project.
Result: Achieved
Key Outcomes: Project didn’t actually use any bees, so therefore, did not harm any bees directly.

Proposed: No PCBs made due to potential time constraints.
Result: Achieved
Key Outcomes: Project was achievable using breadboards alone – even when placed outdoors. Creative use of double-sided mounting tape was used to secure the battery on one of the breadboards. Veroboard was, in the end, only used to support the battery holders although the result may look a little amateurish.

Proposed: Simulate a hive condition, at least partially.
Result: Achieved
Key Outcomes: Monitoring electronics was placed in an outdoor box and left to monitor for over a month without intervention as in Blog 7. The system survived wind, rain, hail and shine (quite literally, as two hailstorms were encountered during this month) just fine.

Proposed: Finish project on time!
Result: Achieved
Key Outcomes: This was a tough one, but it was helped by the extension of deadline due to delays in getting the kit out in the first place. I have ruled a line in the sand and consider the project complete, given the only remaining items are stretch-goals, not core deliverables.

Incidental Findings & Learnings

This project was quite a long one and in the process, I was able to learn a few practical things which I didn’t expect to. I’ve tried to collect some of these incidental findings and learnings in a list:

In Australia, AU915 is the “official” regional band plan for LoRaWAN. However, AS923 is also “acceptable” and its use is a bit of a legacy hangover from when devices with AU915 were uncommon and commercial implementations had imported AS923 gear and run it here as it fits within our 900MHz ISM band allocation. While using the official AU915 band plan is recommended and removes limitations such as downlink frequency “clashes”, there are unexpected disadvantages too.
LoRaWAN gateways on The Things Network maps may seem close enough for connection, but often they may not work simply because they are installed primarily to support a single mission (e.g. in-building sensors) and thus could be an indoor gateway with poor position. The best gateway coverage generally involves a high-gain antenna placed outdoors, up high, connected to an “outdoor” type gateway that has one of the more sensitive gateway concentrator chips (not the SX1308).
Packet brokers allow for LoRaWAN gateways from different networks to exchange frames depending on the broker policy. In some cases, this may mean that deployed devices can roam out of native coverage with your home network (e.g. The Things Network) into a commercial network operated by a company but have the data “brokered” back to TTN, thus mutually extending coverage.
Because of this, use of AS923 at my location would allow me to access TTN via packet broker through our local Sydney Water utility’s gateways. Use of AU915, however, has no gateways within range (except the one I established myself). Because of this, I have decided to run the gateway continually as a service to the community in case there are other desperate LoRaWAN tinkerers within 10km or so of me as gateways are not cheap.
The Things Network fair use policy applies a 30s per day airtime limitation and limits downlinks to 10 per day. This means that transmission of larger datasets (e.g. images) is just not practical. However, as this limit is per-device, it may be possible to sideskirt this by using multiple devices or having one device assume the identity of multiple devices by backing up the radio’s status (i.e. mac, keys, fcnt) and restoring a different set on rotation. The amount of data transferrable really depends on the signal quality as well, because higher data rates require higher signal-to-noise ratios. Use of an airtime calculator is definitely advised.
Unacknowledged transmissions is the norm with LoRaWAN – the acknowledgment downlinks are just too costly, especially in regions where duty cycle limits are imposed and for gateways where downlink transmissions essentially render the gateway “blind” to uplinks for the duration of the downlink.
For the MKR WAN 1310, backing up the radio status before sleeping is not required – in fact, just putting it to sleep between transmissions lowers the sleep current to below 61µA which is easily sustained. In fact, backing things up is increased hassle due to needing to manage the wearout of memory devices. Through sleep and wake cycles, the LoRaWAN session is not re-joined, thus avoiding needless joins clogging up the network.
A particulate monitor sensor has a mechanical fan inside which requires a 5V supply. As this is not available from the MKR WAN 1310 board when running from battery, a switching boost converter is necessary. Running a particulate monitor sensor in discontinuously powered mode saves a lot of energy by only enabling the boost when it needs to run, however, time is needed to stabilise the readings and a counter is needed to engage the auto-cleaning cycle after a certain amount of time.
Flyscreen, magnets, inverted plastic tubs and paving slabs seem to form an environmentally-resistant chamber sufficient to allow breadboards to survive being placed outside in wind, rain, hail and shine conditions without failures for longer than a month. I never expected breadboards to manage the thermal cycling and remain reliable!
While MQTT is supposed to be reliable and the code is supposed to automatically reconnect, hangs in connection have been experienced. Perhaps it is best to have our own timeout and reconnect strategy in critical applications.
This was my first use of MicroPython on a microcontroller and while it feels a bit unnatural, being able to use Python syntax and some libraries common to regular desktop Python is a nice convenience. This does, likely, come at the price of performance though.
This was my first exposure to OpenMV and it seems to make computer vision on embedded devices quite a bit easier with its visual preview of what the camera is seeing, comparing to “flying blind” with Arduino. The examples are also very valuable, but it seems memory and processing limitations of the embedded hardware are apparent.
This was also my first use of Edge Impulse, which seems to make training and deploying of AI models rather easy in terms of its workflow. Unfortunately, the 20-minute CPU time job limit of the free tier seems to be quite limiting as to the size of the dataset and complexity of the models it can develop and I think having something that can work locally without a lot of hassle in set-up may be more valuable.
While I did simplify my expectations of my AI models to detect letters, and the metrics seemed to suggest it would be 90% accurate, in reality the result was very brittle. The way AI perceives images just doesn’t align with what is intuitive for a human – what was obviously a B, it could unashamedly categorise as notB!
Deploying such models to boards is possible and inferencing is possible with under 0.8W of power consumption. This is quite a decent result, although for 24/7 usage, the power will add up.
Sometimes getting services to talk together is not just as simple as sharing a connection protocol (e.g. MQTT) as there are many intricacies as to how the data is parsed, stored, reduced and queried. I was seduced by the allure of Grafana, having seen it used by others, but I may have bitten off more than I could chew having never used it before.
Finally, I learned to do projects at my own pace – as some others rushed ahead, life had got in the way for me a few times, but I tried to catch up whenever I can and make sure I turn out the project as I promised it, so that I could sleep well at night. It may not win me a prize this time, but learning all about a practical LoRaWAN deployment, MQTT, MicroPython, OpenMV and Edge Impulse through practical use of the MKR WAN 1310 and Nicla Vision is a prize in itself.

Conclusion

As the deadline approaches, I feel that the past few months have been a monumental effort in-between my other commitments to build BeeWatch. This involved many technologies I only had a conceptual understanding of, to which I now have practical experience of, and other technologies which I am encountering for the first time. In the end, I feel I have succeeded in all of the core promises I had made in my proposal and even begun to make some headway into stretch goals. Regardless, time did catch up with me in the end, so this is where the project will have to end.

Finally, to celebrate, here’s a honeybee on a wristwatch as imagined by DeepAI’s text2img model in a cyberpunk style: