Metadata about the gateway

End Devices (Nodes)
1

Hello, I’m new here, so I’m sorry in advance for all the possibly dumb questions that I’ll ask.

So the general idea would be to create a bird tracker with LoRaWAN end devices using other people’s gateways. I’ve got some end devices that I can play with, they are up and running, and I receive the data. What I don’t get is where can I see the data about gateway and ideally RSSI as well. How one can do that?
The absolutely ideal would be to receive the data about all the gateways that received the data, but I understand that that is not possible right?

2

This is certainly possible. Received LoRaWAN packets are de-duplicated by the TTN backend and processed into messages that you can receive over MQTT or over HTTP. They contain a list of gateways that received the message, and each gateway has some metadata about it (like position) and you also get an signal strength indicator and signal/noise number for each gateway. Signal strength gives an indication but is probably not directly usable to interpolate a position because signal strength is influence by many more things than just distance.

I am interested in bird/bat tracking too. I wrote to some companies/projects making bird/bat trackers, seeing that most of them still use age-old low-frequency technology requiring their own dedicated network of receivers, also relatively big antennas on the transmitters. I could offer help in investigating LoRaWAN for their use case, but never got a reply unfortunately, and left it at that. I’d be happy to help.

A typical message as seen in the TTN console looks like the example below.
The rx_metadata field contains the gateway metadata.

{
  "name": "as.up.data.forward",
  "time": "2022-04-06T14:45:04.075900778Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "heltec-proto-1",
        "application_ids": {
          "application_id": "particulatematter"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "heltec-proto-1",
        "application_ids": {
          "application_id": "particulatematter"
        },
        "dev_eui": "0000AC855C1C5210",
        "join_eui": "70B3D57ED001A09B",
        "dev_addr": "260B43CA"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "heltec-proto-1",
      "application_ids": {
        "application_id": "particulatematter"
      },
      "dev_eui": "0000AC855C1C5210",
      "join_eui": "70B3D57ED001A09B",
      "dev_addr": "260B43CA"
    },
    "correlation_ids": [
      "as:up:01FZZNC3E7KADQ7GJT2KXQWP87",
      "gs:conn:01FZ7SBHA1HCCDNCR5N200MJZT",
      "gs:up:host:01FZ7SBJ0G734KCTDYS6QAPGWT",
      "gs:uplink:01FZZNC37P526P89Y8VYMKN5YM",
      "ns:uplink:01FZZNC37QPFA6EFCTM29794MK",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FZZNC37QS8GAC4WPDZ8JY735",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FZZNC3E78AGP7DZ1VZ5ZPDQ9"
    ],
    "received_at": "2022-04-06T14:45:04.071781276Z",
    "uplink_message": {
      "session_key_id": "AX+NMmBTme0l7/Oo7d6tbg==",
      "f_port": 1,
      "f_cnt": 6585,
      "frm_payload": "AQIBMQICAPsKaIsLZwCCDHMm+w==",
      "decoded_payload": {
        "analog_in_1": 3.05,
        "analog_in_2": 2.51,
        "barometric_pressure_12": 997.9,
        "relative_humidity_10": 69.5,
        "temperature_11": 13
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "dego-rak7258",
            "eui": "60C5A8FFFE76621A"
          },
          "timestamp": 651478700,
          "rssi": -69,
          "channel_rssi": -69,
          "snr": 12.3,
          "location": {
            "latitude": 51.65939477,
            "longitude": 5.82390838,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChoKGAoMZGVnby1yYWs3MjU4Eghgxaj//nZiGhCsjdO2AhoMCO/OtpIGEMr1q5sDIOCfoPn64bYB"
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 8
          }
        },
        "coding_rate": "4/5",
        "frequency": "867100000",
        "timestamp": 651478700
      },
      "received_at": "2022-04-06T14:45:03.863712750Z",
      "consumed_airtime": "0.133632s",
      "locations": {
        "user": {
          "latitude": 51.659607,
          "longitude": 5.823676,
          "source": "SOURCE_REGISTRY"
        }
      },
      "network_ids": {
        "net_id": "000013",
        "tenant_id": "ttn",
        "cluster_id": "ttn-eu1"
      }
    }
  },
  "correlation_ids": [
    "as:up:01FZZNC3E7KADQ7GJT2KXQWP87",
    "gs:conn:01FZ7SBHA1HCCDNCR5N200MJZT",
    "gs:up:host:01FZ7SBJ0G734KCTDYS6QAPGWT",
    "gs:uplink:01FZZNC37P526P89Y8VYMKN5YM",
    "ns:uplink:01FZZNC37QPFA6EFCTM29794MK",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FZZNC37QS8GAC4WPDZ8JY735",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FZZNC3E78AGP7DZ1VZ5ZPDQ9"
  ],
  "origin": "ip-10-100-4-73.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01FZZNC3EB6EJF509GMD9G2Z55"
}
1 Like
3

Hey, I’m glad to hear, that it should be possible. I’ll have to learn more about the MQTT/HTTP data access as well. About the project - I’ve got a friend ornithologist who’d like to set up some test transmitters this summer, so I’m trying to get it done by then.
Unfortunately the TTN console message I see differs a little - with the fact there is no rx_metadata field. An example below (I’m looking in the Event details tab - am I looking at the wrong place somehow?):

{
  "name": "as.up.join.forward",
  "time": "2022-04-06T15:06:58.586002666Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "eui-f8e895b3a9206a45",
        "application_ids": {
          "application_id": "bird-tracking-lu"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "eui-f8e895b3a9206a45",
        "application_ids": {
          "application_id": "bird-tracking-lu"
        },
        "dev_eui": "F8E895B3A9206A45",
        "join_eui": "D5AEF57D196D1F39",
        "dev_addr": "260BACF4"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "eui-f8e895b3a9206a45",
      "application_ids": {
        "application_id": "bird-tracking-lu"
      },
      "dev_eui": "F8E895B3A9206A45",
      "join_eui": "D5AEF57D196D1F39",
      "dev_addr": "260BACF4"
    },
    "correlation_ids": [
      "as:up:01FZZPM74NT0MCZDFG1M4FXB5B",
      "gs:conn:01FZS2FM0SHRAD7BAH2GZZ3SZM",
      "gs:up:host:01FZS2FM0XK0MK69H58DGH7C8F",
      "gs:uplink:01FZZPM5BVTS10QV8NGZ2F2QA6",
      "ns:uplink:01FZZPM5BWJER5MQ0YE0A24VKH",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FZZPM5BW3DFPSCP7ZK5TEETH",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FZZPM74MJK81N4E5ACC1A8GN"
    ],
    "received_at": "2022-04-06T15:06:58.581283048Z",
    "join_accept": {
      "session_key_id": "AX//ahWCXVuw6zhFGf8eCw==",
      "received_at": "2022-04-06T15:06:56.764623310Z"
    }
  },
  "correlation_ids": [
    "as:up:01FZZPM74NT0MCZDFG1M4FXB5B",
    "gs:conn:01FZS2FM0SHRAD7BAH2GZZ3SZM",
    "gs:up:host:01FZS2FM0XK0MK69H58DGH7C8F",
    "gs:uplink:01FZZPM5BVTS10QV8NGZ2F2QA6",
    "ns:uplink:01FZZPM5BWJER5MQ0YE0A24VKH",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FZZPM5BW3DFPSCP7ZK5TEETH",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FZZPM74MJK81N4E5ACC1A8GN"
  ],
  "origin": "ip-10-100-15-143.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01FZZPM74SR3DRMG42W551WEZB"
}
4

That’s join request info being passed to the application server.

It is not possible, it’s included as standard, no buttons to press, nothing to configure.

If you look at the details for an uplink you’ll see that the gateways are listed.

From the documentation link bottom right of every console page: https://www.thethingsindustries.com/docs/reference/data-formats/#uplink-messages and for a general overview: https://www.thethingsnetwork.org/docs/lorawan/

At some point one of you will think of the idea of getting a geolocation using the signal strength - the short version is you sort of can, but not with any particularly accuracy. Check the Semtech website for tools to help with that. Or put a GPS chip & a larger battery on the device - you won’t have to turn it on as the birds will be exactly where you left them.

1 Like
5

What kind of transmitter are you thinking about?

There a community of people who release (“launch”) helium balloons and track their position, for fun, see https://ukhas.org.uk/
I think they have similar goals so have a look at their wiki. There are also trying to transmit data with low-power and often with light weight trackers. Their trackers use RTTY, 4FSK and sometimes LoRa, typically in the 434 MHz frequency band. LoRaWAN in europe uses 868 MHz. A higher frequency usually means that the antenna can be smaller.

Radio reception in the 868 MHz band is typically “line-of-sight”, so if the transmitter and receiver can see each other, they can probably communicate. Over larger distances, this is limited by the curvature of the earth. If you receive a packet, it’s probably within the “radio horizon” of the gateway, so knowing which gateway received the packet can act as a very crude location fix if you’re not using GPS.

6

I don’t think we do, certainly the Pico Balloons are lightweight but have solar panels about the size of a small birds wing span - so something running on a coin cell would be better.

Also the balloons are running with GPS on-board which has a whole new level of power requirement.

Our trackers are mostly LoRa on 434MHz, so not applicable for discussion here.

7

@descartes Thanks, yeah, the idea is to have some kind of geolocation, it’s not that important right now that it wouldn’t be too precise.
My bad, right now I have only join-accept messages, I guess I’ll have to look into it. I have already set up small transmitter that was used for something else previously and the transmitter as far as I understood should be sending some kind of data once an hour (more like just 1 byte of data or something), but I guess it is missing something then.

@bertrik the chip in use that I just mentioned is pretty much this one with a battery and some kind of antena: https://www.murata.com/products/connectivitymodule/lpwa/overview/lineup/type-abz-078#anchor-1
It should be light enough for the purpose, not sure about the range and that kind of things, but I guess the plan is to see test it out, and then see where to improve.

8

That’s an older SX1276 based module that uses more power which will mean less battery life but very much a module that is well respected aka reliable.

Some testing with range would be a “REALLY GOOD IDEA” as there are limits to how much you can get a coin cell to deliver in terms of power when transmitting so experimenting is called for - a supercap will help as well as keeping the payload small.

And for larger deployments, looking at using the lower power chip sets using the SX1262 with the less congested 434MHz and some directional antennas high up which works rather well for tracking High Altitude Balloons over tens of kilometers or more (I’ve managed +125km with a basic antenna and, for a short period, picked up a balloon technically out of range with a directional one by pointing it vaguely in the right direction). And if it’s not LoRaWAN, you can optimise other aspects but this would be off-topic for this forum. I’d try both.

The lightest GPS I know of / have is the Uputronics uBlox MAX-M8C which is 1.5g but is still 9.7mm x 10.7mm in size so not exactly tiny. Figuring out power consumption is another matter.

What size birds are you tracking?

9

@descartes thanks for the suggestions, and 125km sound pretty wild, the bright side for birds that they are high up a lot, so maybe some of the effects that are happening there might sometimes apply.

Starlings would be the birds (you know, very common, easy to add the transmitters as they mostly nest in crowds), around 4grams of transmitter is as far as it should go. The set up that I have is pretty small, I think it would be fine size wise, about the battery life - well, we’ll see.

10

And why exactly are you interested in the RSSI ?

11

So LoRaWAN has been arround for maybe 7 years, its well known, and has been used for GPS type tracking applications. .

If bird tracking were feasible or practical with LoRaWAN you might expect that by now it would have been done. Were you able to find any examples ?

12

One would think that if there are multiple gateways in a report, that would give a strong (if imperfect) hint which one the moving node is likely closest to.

SX1262 is in theory a win on power, yes.

As for 434 MHz that may make sense for ultra long range if deploying ones own gateways, but if hoping to be picked up by ordinary TTN gateways one would have to use the frequency band which they supports, which is usually the 868 or 915 MHz one in a given locality.

That would be from stratospheric altitudes several kilometers up. It’s unlikely that anything biological in active flight (not enough oxygen!). A quick search suggests the maximum observed altitude for a bird is 37000 feet / 11278 meters - which is rather impressive in terms of oxygen depletion but not much in the realm of high altitude ballooning. Granted in theory that yields a horizon of 378 km, but I don’t think you’re going to get anywhere near that kind of range from your starlings. Still, maybe the numbers are better than I thought at first glance.

Anyway, crudely speaking there are two ways to do location:

  • Use a large number of gateways and compare RSSI to guess which is closest
  • Have the end device determine its own location (GPS etc) and then try to occasionally get a message with that information through to some gateway.

The latter is the case where 434 MHz could make sense, but one needs to consider both the mass and power draw of the GPS receiver and also the degree to which transmitting full GPS coordinates challenges LoRa packet duration in the longer-range spreading factors.

I suspect that choosing a technology really starts with knowing something about your target creature. How are starlings thought to behave? Are they migratory? Do they move around in the same local area? All sorts of tracking schemes have been used - satellite based ones, walk around with a directional antenna ones, for really low mass but crazy migratory distance creatures like butterflies even putting coded stickers on them and hoping someone at the other end catches them now and then and manually inputs the code to the same tracking website.

13

An example of a bird tracker perhaps;

https://marshallradio.com/ww/product/marshall-gps-system-for-parrot-users/

That for parrots apparently, 9g, battery life up to 7 days. $1560+.

To get down to 4g would be a formidable challenge.

The significant issue with GPS trackers is the amount of power the GPS needs and uses to get fixes. A good low power GPS, giving a fix every 10 minutes, with a decent antenna and a good view of the sky would use around 20mAhr of battery life per day.

A 50mAhr lithium battery weighs around 1.5g and would have a life of around 2.5 days.

So the real question to address, if you want to use a GPS, is the weight you want consistent with the rate at which you want to transmit fixes and the required battery life ?

14

And here is an example of a small asset tracker from @onehorse of this forum;

1 Like
15

Which sort of brings it back round to the OP using that Murata module as per the Gnat and it was us lot that mentioned the GPS. Unless you want the bird back, the Semtech solution for three or more gateways for RSSI general location tracking seems OK - I’d get something within a km or so of the actual position when I tried it two years back.

Certainly my “record” is with a high altitude balloon, the point being that line of sight works very well so if you have birds in flight and/or a really good antenna location you can do a lot with just one receiver - which does open up the possibilities of using a 434MHz gateway (or three even) - as trying things out is the essence of research.

16

I would agree, GPS sounds good, but its quite a big problem when you want it small.

Certainly my “record” is with a high altitude balloon

Mine too, back in Jan 2015, 269km furthest. And 242km two way, a record for a LoRa link at the time (according to you know who at Semtech).

17

Tested for a few day on one node, were fairly accurate but at times 300m to 2 km off. So you will need to disregard some of the data. Oh and the node were stationary, so it excludes some of the variables like using additional gateways and big variants and time of arrival (time of flight).

18

That is perhaps to be expected. The changing orientation of the antenna and\or objects in the path can easily change signal levels by 10dBm or more. That represents a ‘distance’ change of 3 times or more, so 1km can become 3km.

19

Addressing a few of the questions here.

GPS is not really an option exactly because of the weight (the example for parrots is rather pricey as well, and the hope would be so that the battery would last at least a few months - as far as I understand the used one I am in possession of is capable of that). The @LoRaTracker example is similar to the one I have.
About the birds as @cslorabox asked.
The birds are migratory and that’s exactly what would be the idea - to have more data about the migration routes. There is some but it’s mostly from birds that get back, but only like 10-20% do get back. So that’s the point of using random gateways on the road. They migrate to UK, so that’s better than Africa from the point of view about the amount of gateways there are. This means that absolute accuracy is not that important, but there is more general question - where on the way do they get lost/die? As I mentioned birds are mostly tracked with systems that you need the bird back, and after that the locations are calculated form all sort of sensory data, so this is also not too accurate anyways.

20

It is not the RSSI they use as much as time stamps, trilateration.

As far a I can figure out the timestamp you see is from the network server, so the latency between the gateway and network server, have a roll to play here .But then again I have no written the SW for the gateways, maybe someone like @kersing can help on this.

So then you can have a node sending one byte and see which gateway collects the data. Give you a fair indication of the contrary or region your bird is in.

Read up on trilateration, you only need the timestamps and gateway location to get a good idea of where the node is.