-
- 3.1. [Helium explained in under 4 Minutes - Video](#Heliumexplainedinunder4Minutes-Videohttps:www.youtube.comwatchvdOFWZZ58UYs)
- 3.2. [LoRaWAN](#LoRaWANhttps:lora-alliance.orgabout-lorawan)
- 3.3. Why Helium?
- 3.4. Providing Coverage
-
- 4.1. Working Modes
- 4.2. Triggers
-
- 8.1. Bluetooth Beacon
- 8.2. BLE Location Fix
-
- 10.1. Register Sensor
- 10.2. Activate Sensor
- 10.3. Payload Decoder
- 10.4. Console Flow
-
- 12.1. Limitation
- 12.2. Next Steps
- 12.3. StreamR (MQTT)
- 12.4. More sensors
- 12.4.1. Vision AI
- 12.4.2. Audio Sensors
-
- 13.1. Carbon Credits
- 13.1.1. DMRV
- 13.1.2. Grazing Strategies
- 13.1.3. Weather Data
- 13.1.4. Data Unions
- 13.1. Carbon Credits
BLCK Team @Azegele & @thestephse
- How can we use technology to support a synergetic relationship between herders and predators?
- What technologies might we use to incentivize nature stewards for their conservation efforts?
- Can new, emerging technologies be in true service to indigenous communities' cohabitation with wildlife?
- LoRa
- Helium Network
- GPS Tracker
- Bluetooth Beacons
- Helium documentation
- Helium Improvement Proposals (HIP)
- Chain Performance
- Chain Statistics
- Hotspot Manufacturer Verification
3.2. LoRaWAN
LoRaWAN is a low-power, wide area networking protocol built on top of the LoRa radio modulation technique. It wirelessly connects devices to the internet and manages communication between end-node devices and network gateways.
-Crypto incentivized network with almost 1 million gateways worldwide. -Return on Investment(ROI) cost of a gateway can made through Proof of Coverage (PoC) rewards and Data Credits(DC) consumption. -LoRaWAN Network Servers (LNS) , managed by Helium Foundation can be integrated in minutes.
One could also run their own LNS, instructions here
Deployed infrastructure can be used permissionless by other projects.
We picked various Hotels in the Maasai Mara and its bordering conservancies and simulated LoRa coverage if gateways would be deployed at those locations. As conflicts usually happened close to the borders, not many locations would be necessary to provide good coverage.
However, due to PoC (Proof of Coverage) mechanics deploying numerous gateways would be rather favored from our end, because additional earnings would cover investments in devices sooner. And in additional better and more resilient coverage can be achieved.
Schema Moko LW001 States & Payloads
The Moko LW001 has three different working modes:
a) Periodic b) Intervall c) Motion
Most efficient for battery life is the motion mode, which uses the integrated acceleration sensor to switch between states.
I) Stationary II) Start moving III) In movement IV) End movement
Triggers that change states:
1) Wakeup Threshold 2) Wakeup Duration 3) Motion Threshold 4) Motion Duration
Criteria 1) & 2) have to be met to change from state I) to II).
3) & 4) has to be met to change state from II) to III).
If they are not met anymore state will change from III) to IV).
Payloads are small byte-size data packets sent from the tracker. Helium is at this point only working with Class A sensors. Class A sensors can send Payloads and listen for a short period for an answer. This saves battery life but has the downside that one can not just send commands. A workaround is "Heartbeats". The sensor sends in defined intervals small payloads to make it possible to receive Downlink commands.
The LW001 can use three different ways to define its location.
A) GPS B) WiFi C) BLE
Localization via GPS should not require further explanation. Here we use it while the Cow is moving.
The tracker can listen SSIDs of WiFi networks or UUIDs of Bluetooth beacons. If the location of the beacon or WiFi Hotspots is known, one can calculate the tracker's location. (See also: BLE - Location Fix)
Changing its state from III) to IV) the tracker is "checking for lion presence" three times in an 1000 sec interval.
Conf working mode:
Motion
02020604
Heartbeat Interval:
600 sec
02050800000258
Motion Mode Setting:
0 = OFF 1 = ON
Bit 0 = Notify on start
Bit 1 = Fix on start
Bit 2 = Notify on trip
Bit 3 = Fix on trip
Bit 4 = Notify on end
Bit 5 = Fix on end110111 -> to decimal
02022437
Fix on start:
GPS
02022601
Amount fix start:
Once
02022601
Interval on trip:
1000 sec
020527000003E8
Strategy during trip:
GPS
02022801
Amount fix on end
3 02022A03
Interval on end:
100 sec 02032B0064
Strategy on end:
BLE 02022C02
Bluetooth beacons are hardware transmitters — a class of Bluetooth Low Energy (LE) devices that broadcast their identifier to nearby portable electronic devices. The technology enables smartphones, tablets and other devices to perform actions when in close proximity to a beacon. (Source: Wikipedia)
The LW001 can "listen" for Bluetooth beacons. The intended use is to calculate the tracker's location based on the signal strength and known locations of beacons.
We re-purposed this functionality. The logic behind this is:
IF the tracker can hear a beacon and this beacon is attached to a lion's collar THEN the lion must be within a radius around the tracker.
For this, we configured filters so that only beacons with defined Major are considered by the tracker. With Major settings, groups of beaconing tags can be created. In our case, all lion tags will have the same Major The payload that is sent from the tracker to TAGO c
- UUID
- RSSI
- BLE Fix Status
BLE Fix Success == Lion in range BLE Fix Failed == No lion in range
We can map the UUID to an individual lion and with RSSI estimate the distance of the lion to the cow.
Filter condition:
OR 02023400
Switch Filter A: ON 02023501
MAC Filter:
OFF
02043700
Major Filter:
ON Major 01 - 02 026380100010002
Minor Filter:
OFF 02063900
Raw Data Filter:
OFF 02083A00
UUID Filter: OFF 02053B00
RSSI Filter:
-125dBm 02023C83
The Helium Console is a web-based device management tool hosted by the Helium Foundation that allows developers to register, authenticate, and manage their devices on the Helium network. In addition to device management, Console provides prebuilt connections called Integrations to route device data via HTTPs or MQTT; or directly to cloud services like AWS IoT.
Source: https://www.aeq-web.com/lht65-sensor-registrieren-im-helium-lorawan-netzwerk/?lang=en
A new sensor can be inserted under the Devices menu item. All keys necessary for OTTA are already generated by Helium. You can adopt these keys by overwriting the manufacturer keys on the sensor. Of course you can also use the preconfigured keys from the manufacturer. This saves the reprogramming of the sensor. The following screenshot shows the registration process in the Helium console:
After the device has been created, it appears in the device list. It can take up to 20 minutes until the sensor is fully registered. You should therefore wait a while before switching on the sensor for the first time. The following screenshot shows the previously set up sensor:
About 20 minutes after registration, the respective sensor can be switched on. The sensor sends out a JOIN request. Each hotspot that has received the JOIN request forwards this packet to the network server. If the keys can be assigned to a device, a hotspot sends a JOIN accept packet with the session keys and a device address back to the sensor. The sensor accepts these keys and can send data into the Helium LoRaWAN from now on. To activate a LHT65, press the user button on the back for a few seconds:
LoRaWAN tries to send as few bytes as possible over the air. Therefore, sensor data is not transmitted in plain text, but compressed. An example: The temperature value "-12.50°C" would require around eight bytes in plain text. An encoder in the sensor can multiply the temperature value by 100 and provide an offset so that the value can be accommodated in a 16-bit integer (whole number value) without decimal places and negative signs. This means that only two bytes are required for the same information. The decoder in turn performs opposite operations to the encoder and converts the temperature value back to the original formatting. There is more information about the compression of the payload data in this article: The LoRaWAN Payload. A decoder is usually stored in the LoRaWAN network, but can often be integrated into the application.
For our integration with TAGO.io, we did not need a decoder, it's done by Tago. However to use a MQTT, it is necessary to run a decoder function in Console. (lw001-decoder.js)
TagoIO IoT Cloud Platform provides easy connection of electronic devices with external data to driver smarter decisions using contextual analysis.
Individual dashboard can be created and accessed via a WebApp or MobileApp.
Also unexperienced users can create geofences.
Events such as a cow entering a previously defined area or leaving it can trigger alerts, but also lion-beacons registered by the tracker. The alert can be an e-mail or SMS. However, we learned that often children help their parents with herding the cows or simply a herder would not possess a mobile phone.
We can use a LoRaWan-Based panic button to close this gap. If an alert is a trigger it would send a signal to the panic button which would in response start to vibrate.
Additional logic could be based on how often a button is pressed in response to vibration.
This is an inexpensive solution with a low entry barrier. Such panic buttons have a battery life of a couple of months and are re-chargeable.
We can use Helium to build a LoRaWan Network in the Masaai Mara National Reserve and its neighbouring conservacies.After meeting with SNI, KWT and our fellow hackathon paarticipants, we realised that there is a multitude of other possible applicatonin addition to our idea of tracking lions with GPS.
It was not necessary to reinvent the wheel as most of the things we need existed already, some slight adjustments and we'd be ready to implement it.
Tracking lions and/or cows with GPS could be just the first step in our journey in bringing IoT to the Wild.
We learned that it is not as simple as we sometimes prototype solutions on our screen. It is not feasibly possible to collar every single lion and conduct any further maaintenance on the trackers.
Prediction models could be one solution, if we collect enough data from lion movements which could be supplimented by or substituted with Vision or Audio Sensors.
- Starting a conversation with hotels and deploy gateways
- Map & verify coverage
- Run first test with tracker, BLE tag & Panic button.
StreamR is a Web3 protocol that makes it possible to share and consume data. Instead of keeping the sensor data private and locked away in silos, it can be monitized and shared with other parties in a secure way.
This can directly benefit the communities providing valuable data.
While running into limitations of our solution (not all lions will have a collar) and also talking with other teams of the hackathon, additional sensor applications came to mind. We ran a first test to use Vision AI Sensors that work on LoRa.
More under Edge AI
requires more research
We just started to explore this field, but see already plenty of possibilities how stakeholders around the Maasai Mara could use the LoRa Network in combination with IoT and Blockchain. We continue to explore, but think this should be the topic of another hackathon... - What do you think, SNI ?