Difference between revisions of "LoraBatBox"

From RevSpace
Jump to navigation Jump to search
(Create LoraBatBox page)
 
(Add project header, many minor updates)
Line 1: Line 1:
 +
{{Project
 +
  |Name=LoraBatBox
 +
  |Omschrijving=Monitoring bat boxes with LoRa
 +
  |Status=Initializing
 +
  |Contact=bertrik
 +
}}
 +
 
This page is an idea for adding LoRa capability to a bat box.
 
This page is an idea for adding LoRa capability to a bat box.
  
A bat box is a flat wooden box with an opening on the bottom often mounted on a tree.
+
A popular kind of bat box is a flat wooden box with an opening on the bottom and mounted to a tree trunk or building.
 
Bats can use these to sleep during the day (they hunt at night for insects).
 
Bats can use these to sleep during the day (they hunt at night for insects).
 
To a bat, a bat box emulates a roost in a tree.
 
To a bat, a bat box emulates a roost in a tree.
 
Some kinds of bats can even use a bat box to raise their young.
 
Some kinds of bats can even use a bat box to raise their young.
  
To check if a bat box is in use by a bat, you can walk up to the box during the day and shine a light into it to see if there are any bats there.
+
To check if a bat box is in use by bats, you can walk up to the box during the day and shine a light into it to see if there are any bats there.
But I think it would be nice to investigate if this can also be done automatically!
+
But I think it would be nice to investigate if this can be done automatically, without disturbing them with a light!
  
 
== Introduction ==
 
== Introduction ==
 
The basic idea is to mount some piece of electronics in or on the bat box that monitors if there are any bats in there.
 
The basic idea is to mount some piece of electronics in or on the bat box that monitors if there are any bats in there.
Periodically (say once a day), the presence of bats is broadcast using a LoRa transmitter forwarding it to a LoRa gateway from the-things-network (TTN), eventually collecting all data in a central place.   
+
Periodically (say once a day), the presence of bats is broadcast using a LoRa (long range) radio transmitter to a central place (e.g. the internet).   
  
 
== Design choices ==
 
== Design choices ==
To sense the presence of bats, I plan to use a PIR (passive infrared) sensor to sense movement inside the bat box.
+
To sense the presence of bats inside the bat box, I plan to use a PIR (passive infrared) which can detect movement of warm bodies.
A PIR typically has a low current requirement (say 70 uA), so it can probably be turned on all the time.
+
A PIR typically has a low current requirement (say 70 uA), so it can probably be turned on most of the time.
 
Sleeping bats will like not trigger the movement detection, but that's OK I think, knowing when they enter or leave the bat box is probably enough info.
 
Sleeping bats will like not trigger the movement detection, but that's OK I think, knowing when they enter or leave the bat box is probably enough info.
  
Line 21: Line 28:
 
LoRa has a larger range than similar radio technologies, has relative immunity to narrow-band interference and allows for low-power transmissions.   
 
LoRa has a larger range than similar radio technologies, has relative immunity to narrow-band interference and allows for low-power transmissions.   
 
There are already several LoRa gateways provided by the-things-network (TTN) that can receive and forward the data for free (with a fair-use policy).
 
There are already several LoRa gateways provided by the-things-network (TTN) that can receive and forward the data for free (with a fair-use policy).
If the TTN LoRa network is down for some reason, no harm is done to the bats, possibly just a few days worth of data lost, and I think I can come up with a solution to that.
+
If the LoRa network is down for some reason, no harm is done to the bats, possibly just a few days worth of data lost, and I think I can come up with a solution to that.
  
As the main processor, I plan to use an STM32 processor:
+
As the main processor, I plan to use an STM32 processor board:
 
* already voltage compatible (3.3V) with an RFM95 LoRa transceiver, perhaps I can power it directly from a LiFePO4 cell
 
* already voltage compatible (3.3V) with an RFM95 LoRa transceiver, perhaps I can power it directly from a LiFePO4 cell
 
* low-cost, processor board can be found for about E2,- each
 
* low-cost, processor board can be found for about E2,- each
Line 34: Line 41:
  
 
== Operation ==
 
== Operation ==
The basic idea is to indicate whether movement was detected within an interval of 15 minutes.
+
The basic idea is to indicate whether movement was detected within intervals of 15 minutes.
 
So each day the electronics see 96 such intervals (24 hours, 4 intervals per hour).
 
So each day the electronics see 96 such intervals (24 hours, 4 intervals per hour).
Encoded using 1 bit per interval, we can send the result of one day in just 12 bytes (excluding overhead from the LoRaWAN protocol).
+
Encoded using 1 bit per interval, we can send the result of one day in just 12 bytes (excluding overhead from the LoRaWAN protocol, about 13 bytes).
  
If movement is detected, the electronics can just note this in internal memory, turn off the PIR and go to sleep for the rest of the 15 minute interval.  
+
If movement is detected by the PIR, the processor is woken up, notes the movement in internal memory and turns off the PIR so it can sleep for the rest of the 15 minute interval.  
 
This way, we conserve the maximum amount of energy in the battery and make it last as long as possible.
 
This way, we conserve the maximum amount of energy in the battery and make it last as long as possible.
 
(idea: use a solar panel to recharge).
 
(idea: use a solar panel to recharge).
Line 44: Line 51:
 
Once a day, at some random time, the bat box sends all the bits collected so far to the network application connected to the TTN.
 
Once a day, at some random time, the bat box sends all the bits collected so far to the network application connected to the TTN.
  
To do all of this, the LoraBatBox needs to know the time.
+
To do all of this, the LoraBatBox needs to know the time of course.
To keep the time, there is a real-time-clock (RTC) onboard the STM32 processor (which also consumes very low power).
+
To keep the time, we can use the real-time-clock (RTC) onboard the STM32 processor.
 
I plan to synchronize the time using the following algorithm:
 
I plan to synchronize the time using the following algorithm:
* in every "uplink" transmission from the bat box to the network, there is a field containing the UTC time from the point of view of the bat box (seconds since 1970/1/1)
+
* in every "uplink" transmission from the bat box to the network, there is a field containing the UTC time (seconds since 1970/1/1) from the point of view of the bat box
* upon reception, the network application compares the time field from the bat box with the actual time
+
* upon reception (a few seconds later), the network application compares the time field sent by the bat box with the actual time
 
* if the difference is beyond some threshold (say 2 minutes), it prepares a downlink transmission with the required offset to correct the time
 
* if the difference is beyond some threshold (say 2 minutes), it prepares a downlink transmission with the required offset to correct the time
  
So if a bat box powers up with no knowledge of the time at all, it'll start at UTC time 0.
+
So, for example if a bat box powers up with no knowledge of the time at all, it'll start at UTC time 0.
 
The network application will note a huge time error and prepare a downlink message with the correct offset.
 
The network application will note a huge time error and prepare a downlink message with the correct offset.
 
When the bat box receives the downlink message, it applies the offset to its clock and so updates itself to the correct time.
 
When the bat box receives the downlink message, it applies the offset to its clock and so updates itself to the correct time.
It doesn't really matter how much time there is between an uplink and a downlink, since the network sends a time *difference*.
+
It doesn't really matter how much time there is between an uplink and a downlink or when the downlink message is scheduled exactly, since the network sends a time *difference*, not an absolute time.
 +
Downlink messages are only sent when there is a large time error, so they should be relatively infrequent.
  
 
== Links ==
 
== Links ==
 
* https://developer.mbed.org/teams/Semtech/code/LoRaWAN-demo-76/
 
* https://developer.mbed.org/teams/Semtech/code/LoRaWAN-demo-76/

Revision as of 23:12, 13 February 2017

Project LoraBatBox
Monitoring bat boxes with LoRa
Status Initializing
Contact bertrik
Last Update 2017-02-13

This page is an idea for adding LoRa capability to a bat box.

A popular kind of bat box is a flat wooden box with an opening on the bottom and mounted to a tree trunk or building. Bats can use these to sleep during the day (they hunt at night for insects). To a bat, a bat box emulates a roost in a tree. Some kinds of bats can even use a bat box to raise their young.

To check if a bat box is in use by bats, you can walk up to the box during the day and shine a light into it to see if there are any bats there. But I think it would be nice to investigate if this can be done automatically, without disturbing them with a light!

Introduction

The basic idea is to mount some piece of electronics in or on the bat box that monitors if there are any bats in there. Periodically (say once a day), the presence of bats is broadcast using a LoRa (long range) radio transmitter to a central place (e.g. the internet).

Design choices

To sense the presence of bats inside the bat box, I plan to use a PIR (passive infrared) which can detect movement of warm bodies. A PIR typically has a low current requirement (say 70 uA), so it can probably be turned on most of the time. Sleeping bats will like not trigger the movement detection, but that's OK I think, knowing when they enter or leave the bat box is probably enough info.

I think the LoRa radio technology is perfectly suited as a transmission medium for sending the bat box occupancy data. LoRa has a larger range than similar radio technologies, has relative immunity to narrow-band interference and allows for low-power transmissions. There are already several LoRa gateways provided by the-things-network (TTN) that can receive and forward the data for free (with a fair-use policy). If the LoRa network is down for some reason, no harm is done to the bats, possibly just a few days worth of data lost, and I think I can come up with a solution to that.

As the main processor, I plan to use an STM32 processor board:

  • already voltage compatible (3.3V) with an RFM95 LoRa transceiver, perhaps I can power it directly from a LiFePO4 cell
  • low-cost, processor board can be found for about E2,- each
  • apparently has good low-power performance and sleep modes
  • has a 32 kHz crystal on board, so it can run an RTC

To power the electronics, I plan to use a LiFePO4 battery. A battery of this type has a voltage of around 3.3V, so it is capable of running the electronics directly, without a voltage regulator. It also has a quite large capacity (mAh per gram) and is relatively safe (doesn't catch fire easily, unlike some other lithium battery types).

Operation

The basic idea is to indicate whether movement was detected within intervals of 15 minutes. So each day the electronics see 96 such intervals (24 hours, 4 intervals per hour). Encoded using 1 bit per interval, we can send the result of one day in just 12 bytes (excluding overhead from the LoRaWAN protocol, about 13 bytes).

If movement is detected by the PIR, the processor is woken up, notes the movement in internal memory and turns off the PIR so it can sleep for the rest of the 15 minute interval. This way, we conserve the maximum amount of energy in the battery and make it last as long as possible. (idea: use a solar panel to recharge).

Once a day, at some random time, the bat box sends all the bits collected so far to the network application connected to the TTN.

To do all of this, the LoraBatBox needs to know the time of course. To keep the time, we can use the real-time-clock (RTC) onboard the STM32 processor. I plan to synchronize the time using the following algorithm:

  • in every "uplink" transmission from the bat box to the network, there is a field containing the UTC time (seconds since 1970/1/1) from the point of view of the bat box
  • upon reception (a few seconds later), the network application compares the time field sent by the bat box with the actual time
  • if the difference is beyond some threshold (say 2 minutes), it prepares a downlink transmission with the required offset to correct the time

So, for example if a bat box powers up with no knowledge of the time at all, it'll start at UTC time 0. The network application will note a huge time error and prepare a downlink message with the correct offset. When the bat box receives the downlink message, it applies the offset to its clock and so updates itself to the correct time. It doesn't really matter how much time there is between an uplink and a downlink or when the downlink message is scheduled exactly, since the network sends a time *difference*, not an absolute time. Downlink messages are only sent when there is a large time error, so they should be relatively infrequent.

Links