TTNMapper integration and TTNv3

[wdebbaut]

@jpmeijers
I have been searching for an integration of the TTNMapper in V3, our current lorawan stack running here at Leuven. I stumbled upon this issue in Github : https://github.com/TheThingsNetwork/lorawan-stack/issues/1995
We tried to fill out the appropriate fields in the Webhook part of the v3 console just as @jpmeijers did, but we get no result when searching for our private gateways ID’s on https://ttnmapper.org/advanced-maps/ , as one would suggest because the gateway ID is sent in the metadata.
We previously sent this GPS data Cayenne LPP encoded and works perfect when forwardered with v2 with an experiment name.

Is this issue being resolved in TTNv3? Or am I missing out something?

[kersing (Jac Kersing)]

I was under the impression TTNmapper maps the public network. As the public network runs stack V2 my guess would be that the gateways don’t show because they’re not part of the public network. But that is just a guess…

[wdebbaut]

Correct @kersing , but the theory is that the TTNMapper application receives all of the TTN gateways IDs (public and private) by means of the metadata sent. For instance, two of our private V3 gateways in the webhook application (the new HTTP integration) are sending the following json metadata:

"rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "dingnet-gw-imec-n12-1",
          "eui": "1DEE087DF8E9D50B"
        },
        "timestamp": 737328667,
        "rssi": -115,
        "channel_rssi": -115,
        "snr": 2.8,
        "uplink_token": "CiMKIQoVZGluZ25ldC1ndy1pbWVjLW4xMi0xEggd7gh9+OnVCxCb/MrfAg==",
        "channel_index": 3
      },
      {
        "gateway_ids": {
          "gateway_id": "dingnet-gw-imec-n12-2",
          "eui": "1DEE06FEA3272CEE"
        },
        "timestamp": 670379851,
        "rssi": -114,
        "channel_rssi": -114,
        "snr": -5,
        "uplink_token": "CiMKIQoVZGluZ25ldC1ndy1pbWVjLW4xMi0yEggd7gb+oycs7hDL3tS/Ag==",
        "channel_index": 3
      }

One can clearly see the gateways ids that are forwarded to @jpmeijers application and eventually are rendered to visualise them. One hicup though, the GPS location data is not sent yet. That is maybe why they are not mapped!
Nevetheless, I posted this one to @jpmeijers because he might comment on the issue published on the Github concerning v3 for his TTN Mapper integration.

[jpmeijers]

Hi @wdebbaut

V3 support for TTN Mapper is still a work in progress. And as you can see regarding all the issues I filed on the TTN repo this is not a trivial task.

Then also what @kersing says is very true. TTN Mapper is meant to map the public community network. If you start sending a private network’s data and gateways to it the map that will be generated won’t be a true representation of the public community network’s coverage. If you want to map a private network you will need to run a private mapper instance.

I’ll elaborate a bit more at a later stage. Thought I’d answer quickly before you waste too much time.

[wdebbaut]

A great many thanks @jpmeijers for the quick answer.
As a result, I immediately stopped my endeavors for mapping our private TTNv3 lorawan gateways here at our Leuven university college. We will watch the repo at Github for any further developments.

I switched my tracking node back over to the public TTNv2. Now, one can see the community public gateway closeby again:

    "gateways": [
        {
          "gtw_id": "mobile_gateway2",
          "gtw_trusted": true,
          "timestamp": 112149116,
          "time": "2020-04-10T16:46:04Z",
          "channel": 7,
          "rssi": -54,
          "snr": 9.5,
          "latitude": 50.889427,
          "longitude": 4.7408013
        }
      ]

Our contribution to the TTN open community is remade by these https://ttnmapper.org/experiments/?experiment=sensebox_leuven
Could you advise me a mapper instance to run?

Alles van die beste en 73s …
ON3ZOE, Wim.