Does LoRaWAN/TTN/TTI make sense to track migrating birds?

Use Cases
1

I’m researching whether it makes sense to track migrating birds using public LoRaWAN networks, whether free or paid. (This is in the context of https://motus.org, which is an int’l collaboration that has set-up hundreds of VHF and UHF beacon tracking towers.)

I’m mostly seeing case studies or reports about tracking cattle or wildlife in a park. That makes total sense to me as one can set-up local gateways and thereby not worry about per-packet costs or fair use policy type of stuff. Migrating birds fly across continents, however.

The two big stumbling blocks I see are per packet costs or allowance and data rates. (I am intimately familiar with LoRa and somewhat with LoRaWAN.) Migrating birds cover a pretty large area pretty fast, so transmitting location once an hour doesn’t seem sufficient. For reference, current VHF or UHF beacons transmit once every few seconds (20 at most). Part of the reason is that the birds are mostly out of reach of a tower so the brief moments where they are in range need to be captured. (The tradeoffs here change slightly with LoRa vs. traditional VHF/UHF beacons.) But if a bird ends up close to a tower and roosts then sending a message every minute (say) would be crazy/expensive/violate fair use. I don’t see any per-packet prices on the TTI site, so I can’t evaluate how the costs would rack up. How are people dealing with this type of issue?

The other stumbling block is uploading collected data. The trackers attached to the birds may have GPS or other location technology, or other sensors and the attraction of public networks is that when the bird flies by a tower it could upload the collected data. I’m not sure how to engineer that, however. Assuming that 99%+ of packets transmitted by a bird tracker will not be heard how can a tracker detect that it’s actually close to a tower and then switch to uploading the collected data? Presumably such an upload would violate TTN fair-use but presumably if one pays for the packets one can do such a burst upload.

Some of the studies I’ve found place private gateways near roosting/nesting sites or other places where the birds being studied are known to fly by and that makes total sense and is something I expect to do as well. But for that type of set-up public LoRaWAN networks are not needed and even LoRaWAN has marginal value IMHO. The point of looking at public networks is to complement such private gateways. Maybe that doesn’t make sense…

I really appreciate any input.

(NB: to make things a bit more interesting, all the above has to happen within extremely tight power constraints: the tags I’m building weigh less than 1 gram.)

2

I’m sure you’ve already read the prior discussions on this very topic on here.

Perhaps you should code your firmware not to be so profligate if sending every minutes is crazy/expensive.

Mostly not at all, given that the the reason for the absence of the per-packet prices is because there aren’t any. There are several other prices that aren’t charged that aren’t listed as well.

It’s got a GPS module on it???

This isn’t entirely supported by your design approach - perhaps you could tell us what you’ve tried already to save us suggesting things you already done.

And as most of the solar powered high altitude balloon floaters run to 10g or so, I for one will love to hear about your 1g tracker.

3

Thanks for the reply!

I’ll contact TTI sales to understand what packet rates are allowable, etc. I’ve been following TTN for years (but due to there being no activity in my area have never set-up a gw) so the fair-use limitations are perhaps too ingrained in my thinking…

Possibly. It’s all a power & weight tradeoff. But for example GitHub - trichl/TickTagOpenSource has GPS on a 1.3g tag (no RF).

But maybe your question was aimed at storing the known locations of gateways in flash and then determining whether it’s worth transmitting based on that coverage info? I wonder how much flash that would take for birds that migrate from northern Europe to northern Africa, for example.

LOL! For this specific project I’ve been focusing on the energy budget so far. I know I have power to TX LoRa (not obvious at all). I’m comfortable with range from prior experience. I understand the bw/sf/cr/sensitivity space. I’m also familiar with the LoRaWAN protocol although I’ve never actually used it.

The power budget allows for perhaps 200x 400ms transmissions per day, more if there is sun, at the very most 200 at night. (400ms chosen due to max time allowed in the US.)

Strategy #1 would be to transmit at a fixed rate. Say every 10 minutes for a total of 144 transmissions per day. Each packet can have current position and randomly sampled data from what the tag has stored (past positions, accelerometer info, etc).

Strategy #2 would be #1 plus ask for an ACK every now and then so the server can tell the tag which data has been received so the tag can delete it.

Strategy #3 would be to transmit a short packet every minute and always ask for an ACK. If there’s a response, then transmit a burst of packets with as much stored data as the power budget allows. Or more likely some fixed number of packets and then wait for another ACK.

There’s a bit of “I don’t know what I don’t know” (or am simply overlooking) here…

The ingredients I’m using for the base tag:

  • stm32wle5
  • flex PCB with stiffener or 0.2mm-0.4mm thin PCB
  • Lithium Titanate (LTO) battery to get enough pulse current for TX (0.16grams 0.8mAh)
  • thin film solar cell
  • BQ25504 energy harvesting
  • 0.2mm nitinol wire antenna
  • 0402 passives, for 900Mhz presumably an IPD (haven’t done that yet)

The GPS side is still to be worked out. The ublox CloudLocate stuff and the LR1121 are on my short list. The antenna is an issue (as is the power, obviously).

Fun stuff to hand-assemble…

4

That’s a self-fulfilling prophecy - there’s no activity so I won’t setup a gateway.

How do you propose to track it if there is a possibility of it not having a GPS on it?

It wasn’t a question, it may have been lost in translation so, yes, it has a GPS so it can figure out where it is and transmit appropriately - the geolocation data will be relatively miniscule.

Extended trials have conclusively demonstrated that this is not technically possible.

I’m afraid your strategies lack flexibility - there is no need to transmit if the device is not moving and all those acks aren’t going to help with your fantastic power budget for solar on hardware that just won’t fit in to 1g. There is no way you have RF budget or a reliable link for CloudLocate or LR1110.

What size birds are you proposing to track?

5

If you had taken a little time to get familiar with LoRaWAN you would have known ACKs do not scale. At all. So option 2 and 3 work with a single tracker in range of a gateway, maybe up to ten of them and then things fall apart.

When calculating battery budget, keep in mind you are required to receive for a number of seconds after each transmission. Otherwise your implementation isn’t LoRaWAN compliant, won’t work on TTN and won’t be accepted by the Telcos running networks.

Also, LoRaWAN uses different frequency plans for different countries. So how are you going to know which one can legally be used at that location and make sure you are transmitting with the right credentials for that LoRaWAN network server instance? (Keeping multiple sets of credentials is far from trivial)

If you can’t adhere to a FUP you are pushing too much data to the airwaves and being a very unsocial neighbor. That might not matter while birds are migrating, but it is a very valid concern when they’ve settled in a certain region.
Also, keep in mind Lora is long range and will be received by (almost) any gateway above the horizon from the view of a flying bird. So potentially you are ‘spamming’ the airwaves and gateways for hundreds of kilometers. (Check the ranges obtained with balloons to get a grip on this aspect)

I love pushing the boundaries with technologies, however LoRaWAN doesn’t seem a great technology for your use case.

1 Like
6

Thanks for assuming that I didn’t spend time or don’t know what I’m talking about if what I’m suggesting doesn’t immediately meet your acceptance criteria. The kindness of the replies here is overwhelming.
I understand the asymmetry in the communication just fine. My descriptions above may have been too terse to make it clear that I don’t expect frequent downlinks.
It seems that in general the problem of uploading stored data is a difficult one to solve with LoRaWAN due to the relative lack of feedback whether any gateway is receiving anything.

Thanks for pointing that out, I overlooked the duration of the RX window.

That’s what I’m concluding as well, I thought I was just missing the obvious solutions.

7

Some devices are even engineered to ‘sleep’ between the RX & TX windows (with a little buffer margin for timing errors) saving even the power that would be used holding in RX mode until the window, though doing that often appears to intoduce other problems of its own.

8

Apologies for the harsh response. However you mentioned yourself not having practical LoRaWAN experience. In my 8 years hands on working with the technology I’ve seen many examples of people being optimistic where they should be pessimistic and vice versa.

I’ve seen workshops fail because 15 participants turn on/reset their OTAA devices at the same time causing the gateway to run out of airtime and frustrating the participants. (Optimistic number of participants, an additional gateway would have resolved the issues)

In other cases people take LoRaWAN devices onto a light aircraft and ‘spam’ gateways for about 300km around their location. (Pessimistic thinking about range)

So knowing the theory isn’t a substitute for hands on experience with the technology.

Wrt to the receive windows, you don’t need to listen continuously after transmission as mentioned by Jeff, however you still incur a significant power drain because of having to receive. Depending on the SF used for transmission it might be 50% of the power spend transmitting.

9

I’m trying to follow-up on the RX window issue. Looking at An In-depth look at LoRaWAN® Class A Devices | DEVELOPER PORTAL I find

1094×527 21.4 KB

To make sure I understand correctly, using an example TX packet with a 16-byte payload:

  • sent at DR1 (usa902-928, sf9/125khz) → 222ms TX
  • RX1: assuming DR9 (sf11/500khz) → 20.4ms RX wake-up time
  • RX2 fixed DR8 (sf12/500khz) → 41ms RX wake-up time

So the RX probably adds 50% to the total energy budget when using relatively low power, i.e. TX power about the same as RX power.
EU seems to be worse if I’m interpreting correctly because RX2 is fixed at a slower symbol rate and requires 164ms of wake-up time, which basically doubles the total power.
Dunno whether there’s a way to opt out of RX2…

Below the figure I pasted the original document has this statement:

The energy drain linked to Rx1 and Rx2 when no downlink message is detected is negligible compared to the energy required for the transmission of the uplink

So either my example above is totally off or my definition of negligible is different from the authors of that doc… I guess they assume TX means at least 17dBm or so…

How much of a practical issue is that? The majority of migration is north-south. North america and south america seem to mostly have the same band plan. Europe uses the same band plan by and large and north africa seems to follow that. (On the TTI site north africa is shown in grey, dunno whether that means there’s no TTI coverage.) I assume there’s something altogether I’m missing.

Is that a reason to respond with derogatory statements?

I don’t doubt that “knowing the theory isn’t a substitute for hands on experience with the technology” as you say and I didn’t state that I’m an expert at LoRaWAN.

I’ve looked at TTN about 4-5 times since I first signed up here in ~2018 and each time decided that it doesn’t fit what I need by a long shot due to the obvious limitations (fair use, downlinks). I’m in SoCal and there is no TTN worth mentioning within hundreds of miles of me, why would I have set something up that doesn’t work for my uses (unless I’m into crypto)?

Even if I had, determining the RX window power consumptions requires purely theoretical research into the docs. Isn’t this type of gotcha exactly what a forum can really help with? People with complementary experience pointing out what someone is overlooking?

10

Very few gateway in North Africa, you will need to build network for the areas you want to track. The same goes for the Americas.

Although if a bird flies high, or flying on top of a hill, you might or will catch gateways potentially 100 miles away. You are going to find there are lots of valleys in the world.

The only way you are going to figure out if anything works, is to build a few nodes and try them.

PS. I know there is a project in South Africa tracking vultures via LoRaWAN, they weigh in 4.2 to 7.2 kg (9.3–15.9 lb), there for the node can be a bit more bulky.

1 Like
11

Surely 226.3ms???

The spec says no. Perhaps worth reading it?

We go with the information you provide, this is new info so the comment was totally reasonable.

The first sentence reflects a fact you stated about yourself. The second is an observation from Jac’s extensive experience. Neither can be catagorised as derogatory.

The point being made which I did above is that this query would have been so much easier if you’d tried LoRaWAN. In terms of use cases, the FUP is a limitation on a service provided for free. Downlinks are a limitation in the core design, it was always thought of as an asymmetric protocol.

Coming & asking for input is fine. But you’ve said twice now that you haven’t tried LW because no one else has in your area which is the exact opposite of what TTN community is about.

Hard to help if questions go unanswered - like weight/size of birds which impacts tracker size & weight.

12

Yup. The Motus network (map of stations below) has been expanding in central and south america and being able to deploy stations with just an omni (as is typical for LoRaWAN) vs. 3x 166Mhz 9-element Yagis would make it a lot easier to convince local researchers to go through the effort. I’m less plugged into the efforts in Africa so I don’t know what the status is there.
image

Understood. The one twist is that the real-world range tests I’m aware of transmit at max power, which I don’t expect to be able to do due to battery instantaneous power constraints. I expect to be 12dB-18dB down from what I believe you have in mind when you talk of 100 miles, so I’m looking at 1/8th-1/4 the range.

Yup. I have a 0.8g prototype that uses 433Mhz FSK, I’m here trying to figure out what parameters I should tweak to maximize my chances to make a successful 915Mhz LoRaWAN prototype.

Do you have any link, name, or keyword for me? I can find quite some stuff about vulture conservation in S.A. but not LoRaWAN. I am aware of a LoRaWAN project tracking vultures in Portugal/Spain by U of East Anglia, Miromico and Movetech (Characterisation of a new lightweight LoRaWAN GPS bio-logger and deployment on griffon vultures Gyps fulvus | Animal Biotelemetry | Full Text). The one S.A. mention I found is Vulture movement ecology and preventing their poisoning - WUR but no details and unclear whether LoRa or LoRaWAN, looks like the project may be still underway.

Something interesting is that from what I can tell the Portuguese project used a transmission strategy along the lines of what I tried to describe in my strategy #3: the trackers send what they call welcome messages periodically always asking for an ACK expecting that the majority go unheard/unacked. When they get an ACK they switch to upload mode and send a burst (relatively speaking) of messages (no DL requested) with the data stored on the tag. After some number of data messages they expect another ACK before proceeding (the paper is understandably sketchy about the details).

The tags are available down to 4g by Miromico, not clear whether that weight includes battery or is just the electronics. It’s also 2021 era tech and some things have improved since. I’m trying to see how far down I can push the weight and what the tradeoffs look like. Basically the lighter weight the tag the more species it applies to (the general guideline is that the tag must weigh less than 5% of body mass). Some of the current VHF/UHF tags used weigh 0.65g and go on song birds. Some tags even go down to 0.16g for hummingbirds and butterflies. Nope, I don’t expect to get there with GPS and LoRaWAN :slight_smile:

Do you have any details or data for me?

WRT GPS I know that there are interesting recent improvements but have not been able to find real-world data or test myself (damn 24 hours per day limitation). But there are other ways to determine location in the context of bird migration: it’s not all about meter-level accuracy. The LR1121 listens to WiFi beacons (as I’m sure you’re aware), some tags listen to GSM beacons (not a great strategy in the US anymore but likely viable in the EU for a good while), and there’s the obvious localization obtained by knowing the coordinates of the gateway that received a packet (a bat tag project used SigFox plus GPS and found the data derived from SIgFox (gateway location + RSSI) to be very usable for a range of inquiries.

So far what I have gathered is:

  1. The Portuguese vulture tracking shows that using LoRaWAN for the purpose is possible and they evidently used some perhaps unusual TX strategies. Their tags were way heavier than I’m looking for and while they talk about public LoRaWAN network I don’t believe they actually ended up connecting to any (a bit hard to tell in the paper).

  2. The RX windows are a bigger power concern than I realized and I need to research that some more. The LoRaWAN std says RX2 is fixed and typ. SF12. Looks like that can be configured to SF9 on TTN. Dunno about EveryNet or others. Need to set up gw+node to try this out.

  3. The CPU power consumption by the stack is something I haven’t considered. Sounds like LMIC may not be the way to go (MiniPill LoRa - STM32 Low Power Node - #33 by leo_korbee). Motivation to try it out, but first I have to figure out which stack to use, is MCCI Arduino LoRaWAN the easiest place to start using an stm32wle5?

Thanks for the pointers so far!

1 Like
13

Nothing I can share as it’s commercial in confidence - but if you consider you have to send a packet with the GPS signal in it rather than decode on the device …

What sort of birds migrate at house height? How many cross urban areas?

Whereas ToF gateways are useful, but at their price, it’s likely you’ll be deploying them. Previous tests (search forum, I know you haven’t because you’d have found the previous bird tracking topic) on RSSI triangulation showed some useful results.

The phrase chalk & cheese comes to mind, mostly as it can’t drive an SX1262. For LMIC I’d try SAMD or an ATmega4808 with an SX1276 but that’s not as power friendly. For STM32WL the obvious if not entirely optimal without some tuning would be LoRaMAC-node given that ST provide a package for it - which is like “having your brains smashed out by a slice of lemon wrapped round a large gold brick” - aka a Pan Galactic Gargle Blaster - STM32 development environment only, not Arduino.

Extended trials have conclusively demonstrated that this can only be fully understood by hands on experience.

14

Yup, that’s what I was afraid of.

You clearly seem to know everything, would you care to provide a link or some keywords to this topic? And why do you feel the need to insult me in the process? My very first action on the forum was to look precisely for existing threads but I didn’t find anything useful. I’m sure with the right keywords your thread appears as the first result, but it didn’t for me. With the many years of topics on this forum I find that the search is really difficult to get results with, compounded by the fact that a lot of discussions are outdated due to newer versions of stuff.

Update: is Metadata about the gateway - #27 by onehorse what you’re referring to? I was fooled by the topic title. What I got out of the thread is a reminder that TTN gateway location may be wildly inaccurate, a link to a GPS antenna effectiveness comparison, and the knowledge that a Lukas in Switzerland has a 1g GPS + LoRaWAN tracker but it’s secret and he disappeared. Did I miss something relevant to this discussion?

I prefer to eat cheese! But thanks for pointing out that MCCI Arduino doesn’t like sx1262’s. I don’t mind writing a driver but it would be real good to start with something that already works as first step. When I pull up any ST library source code on my browser there’s a big red “do not use if you value your sanity” watermark across the screen… I guess I’ll have to ignore that for the first step :roll_eyes:

15

That would be because my commitment to the TTN community runs to reading every single post for the last four years.

For the bird tracking discussion, the search term “bird tracking” brings this topic first and the topic I was referring to second.

16

Thanks. I had updated my last post with that, prob same time you posted.

17

Apart from me not referring to RSSI geo-locating but actually about bird tracking, please do not make material edits to a post as it distorts the flow of the thread making nonsense of the following contributions.