TTN coverage monitoring/recording with non-covered areas

hi,
i’m not sure if anyone here can help me think of a solution or even has created a solution for making the coverage/ measured non coverage of a ttn v3 area?

i have found the ttn-mapper system and even bought a network field-tester: the Rakwireless RAK10701 to test and upload all sessions toward ttn-mapper. where the gateways receive the message this makes a wonderful map available on ttn-mapper.

as we try to check and view the non reachable parts of our project (meetjestad.net) and try to find a good solution for this:
i could/can download my succesfull messages from ttn-mapper, and i can take my GPS trackeralong creating a GPX file, so i know where i was on a certain time.

as the RAK-device tests every XX seconds i know where i was on certain times.
i’m not a good programmer. but is think that a processing where a combination of both datafiles would make it able to create a new file where all tries to connect to the ttn-network which failed would be made visible. the rak device doesn’t log this.

has anyone any thoughts about this? would love some help :slight_smile creating an even better view where we tried to reach the network and add more gateways would help.

as we are a small volunteer project into open-source any help is appreciated.

Hi @Lichtschilder, fellow TTN user here from Veenendaal :wave: I’ve been to a meeting in Amersfoort myself as well :slight_smile:

I am not aware of existing solutions to your mentioned problem, and it sounds like quite a bit of a hassle to reverse-engineer the uplink positions of the RAK module by combining it with your tracker data.

Now this is a bit of (not completely shameless) self-promotion, but I’ve been working on my own mapper since last December, and currently @Jeff-UK has three of mine in testing. The interesting part for you here is that this mapper logs all its uplinks & GPS location to a daily file on the device, which are available for download through WiFi.

It’s still a bit early days and the device is not publicly available yet, but the price of the device should be about competitive with the RAK module, and for meetjestad I will be happy to negotiate about that / send instructions over for you to build yourself.

Hit me up privately if that sounds good to you… but maybe someone already knows of an easy solution without requiring a new device!

1 Like

You need a few more XX to keep in the FUP.

Field testers are also not good for the network, as all LoRa devices (Gateways and nodes) have duty cycle limits. For every uplink the field tester sends, the gateway needs to send a downlink. Thus the gateway that serves many nodes reach it duty cycle normally way before a node, you start to block other user traffic. And FUP calls for less than 10 downlinks per day, there by if you do a test ever 99 sec (XX seconds max) with in 16 min 30 sec you exceed FUP.

You will need to store all the points on the device for later comparison of successful point to unsuccessful points.

It’s run off an Arduino sketch and is based on an nRF52840 + SX1262 so you could very likely port your Mappy source to it without toooooo much excitement.

Duuude… no thank you. Making a to me known board unbreakable to all sorts of user & LW abuse is already tough enough. Unless someone pays me a couple grand for it, but that doesn’t sound very meetjestad.

thanks, have sent a message!

Hi Johan,
thanks for the response and my XX was a variable large enough to not oversend or receive :slight_smile: agree that i would love to leave the space available :slight_smile:

we would love to make all volunteers who have built and placed to see their measurements.
but that’s quite difficult at the moment.
device who stores all i better and more usable any help would be appreciated.

So tell us what the challenges are and see if there is a solution available - that’s what we are here for!

we lost quite a few working gateways, and therefore a lot of local sensors.
trying to find where new gateways should be placed.

that means that we need to to some testing as well: there is no difference in not-tested vs tested without coverage. therefore i was thinking to test by rolling around in my wheelchair-bike and collect the data.

we had volunteers who created a new meetjestad node and placed in the desired location thinking that the whole area is covered: concluding that their node is broken. when testing near a gateway they will work properly in >90% of the tests.

working on adding gateways and fixing broken ones is in progress too.

how would you do this?

willing to buy and build is there, but i’m not able to spent lots: muscledisease and had to stop working my job as a result of that. trying to find some good energy by helping out in meetjestad on my better days now.