Localization using ToA values

Hi there!

I’m a university student from Furtwangen, Germany, and I’m currently writing my Master’s Thesis about evaluating options for localization in LoRaWAN.

At the moment, I’m looking into Time of Arrival (ToA) data to be able to multilaterate end device locations using the timestamps the gateways get when they receive LoRa packets from said end devices.
However, when looking at the device event details in my TTN console (specifically, the keys data.uplink_message.rx_metadata.received_at), there seems to be a massive difference in timestamps there.
Sometimes, this difference can reach one or around one second, which makes estimating device distance to said gateways with ToA (and speed of light) calculations impossible.
Can this be a setup issue with the gateways (as in, they’re not time-synced accurately enough) or what am I doing wrong?

Example rx_metadata:

"rx_metadata": [
          "gateway_ids": {
            "gateway_id": "68068734-f17f-4ec2-ac0d-5ec7332d5e4e",
            "eui": "3436323825005F00"
          "time": "2023-05-14T17:58:42.907916Z",
          "timestamp": 3837405089,
          "rssi": -114,
          "channel_rssi": -114,
          "snr": -6.75,
          "location": {
            "latitude": 48.0474728410219,
            "longitude": 8.21604073047638,
          "channel_index": 5,
          "received_at": "2023-05-14T18:00:11.311072430Z"
          "gateway_ids": {
            "gateway_id": "hfu-lr8-001",
            "eui": "503035414A154750"
          "time": "2023-05-14T18:00:01.415399Z",
          "timestamp": 3106550092,
          "rssi": -97,
          "channel_rssi": -97,
          "snr": 7.5,
          "location": {
            "latitude": 48.04827624596974,
            "longitude": 8.208827033494345,
          "channel_index": 5,
          "received_at": "2023-05-14T18:00:11.313968629Z"
          "gateway_ids": {
            "gateway_id": "eui-a840411fcbc04150",
            "eui": "A840411FCBC04150"
          "time": "2023-05-14T18:00:10.828676939Z",
          "timestamp": 3411843324,
          "rssi": -129,
          "channel_rssi": -129,
          "snr": -9,
          "location": {
            "latitude": 48.0510773011533,
            "longitude": 8.20900770884946,
          "received_at": "2023-05-14T18:00:11.320176521Z"
          "gateway_ids": {
            "gateway_id": "eui-a84041203275aeac",
            "eui": "A840412032751337"
          "time": "2023-05-14T18:00:11.189132928Z",
          "timestamp": 2468010284,
          "rssi": -101,
          "channel_rssi": -101,
          "snr": 8,
          "received_at": "2023-05-14T18:00:11.313311649Z"


Not necessarily an issue, but yes, most gateways don’t use an accurate time source. Some might use NTP to sync, some GPS, some nothing at all.
LoRaWAN gateways for Class A and C work alright without a precise wall clock time so these times will be useless for ToA calculations unless you know the gateway has an accurate time source.

Thanks a lot for your quick reply! I read that services such as LoRa cloud by Semtech can use ToA as a factor for Localization, so I was curious about this fact. Seems like I’ll need to use RSSI and SNR values, after all.

Just be aware that using RSSI and SNR for distance measurements is very crude as so much depends on where a node might be located, where the gateway and its antenna is located, objects in the way etc.

What sort of resolution or accuracy of location were you after ?

1 Like

There is a generation of gateways that has provides additional timing information as part of the concentrator hardware. Those are more expensive and rarely used on TTN.

1 Like

I’m basically only looking to get “as accurate as possible” as my thesis’s topic is to evaluate the options that are at all possible with the existing setup of TTN and TTN Mapper. My second approach besides using “crude” RSSI or SNR values is to basically use fingerprinting with existing TTN Mapper data.

Yeah, I figured. At the moment, I’m using MikroTik LR8 wAP and some Dragino Gateways that I put up in the town of my university.

As Jac says more expensive GW’s needed to support this capability but also as a ‘value added’ service over and above LoRaWAN connectivity you should also be aware that there can be (is!) additional licensing and software/service costs involved that are required to generate ROI and help provide this as a commercial service! :wink:

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.