Meshed-handler

TTN Network and Services
17

Thanks for your quick response @Maj. We greatly appreciate the fact that Meshed hosts TTN in Australia for the use of everyone.

To answer your question regarding the integration authorization request, we were just referring to the notification that came up when we were attempting to look at the Australian console. This notification requires us to accept the terms that I had questions about.

Thanks again for your help with this.

18

Hi @Maj. Are you able to tell us when the My Devices Cayenne integration will be available on the Australian console?

19

Hmm… I’m sure it used to be there. I have asked the TTN Core team to take a look.

20

It’s there now. Thanks for following this up @Maj.

21

meshed-handler is currently offline when I’m looking at one of my applications from console.thethingsnetwork.org When looking from console.thethings.meshed.com.au it states ‘App … not registered to a handler’ Moreover, meshed-route is no longer an option to select for a Handler. Is there a status/monitoring site for all the services, handlers, integration providers? Is anyone else experiencing the same issues with meshed-handler?

22

Yes, mehed-handler is currently down. See Australia - Meshed Handler Down.

25

@Maj Andrew, is there still problems with the server?
Integrations are still not shown on the meshed console.

26

Yes, I have the same problem

image

27

Yes looks like Integrations are still a problem. Restarting the integrations had no effect. I’ll ask the TTN Core team to look into it.

28

Resolved now

2 Likes
29

Ohh, I just found this post, while writing a query with the subject “There are no available integrations for handler meshed-handler. Check back later!” Luckily the related post search system sent me here.

I tell you, that until now, I had been using the gateway, in AU915 (from Argentina), with meshed-router, but in the application I used the Brazilian router, and in that way, it saved the “problem” that meshed-router did not offer integration.

Having known that this hidden console for meshed-router existed … should be documented and referenced in the main console …

The scheme of using the application with the router of Brazil, worked well with the integration until August 4, when it stopped working. Since then I am looking for the reason for the failure.

Now I will configure everything from the specific console for meshed-router and I tell you the result.

Regards

Hugo

30

Hi @hmullerenersa. There are problems with cross-region routing. You should try and use the handler that is in the same region as your gateway. So use either:

  1. ttn-handler-brazil and ttn-router-brazil
    or
  2. meshed-hander and meshed-router

Probably Brazil is a better match for you.

We have seen problems before where routing stops working, usually between meshed-router and asia-se-hander or eu-handler, but probably with any handler. The TTN Core team are aware of the issue, but it’s unlikely to get fixed, since V3 will probably address this.

1 Like
31

Hi Andrew
What a pleasure to receive a response from you, yesterday I discovered that the meshed-router was located in Australia, physically speaking, and that there was a separate console for this router.
In my experience, I started using the handler in Australia, because here in Argentina we use the AU915 frequency plan.
On the other hand, I used the Brazilian router, ttn-router-brazil because until yesterday, I was the only one that offered me integrations with Cayenne and DataStorage, as I was using the standard TTN console (the only one I knew until yesterday), I didn’t see the integrations when choosing the router meshed-router.
Well, after knowing the existence of the alternative console (https://console.thethings.meshed.com.au/), I set option 2 and it is working!
My configuration, which worked correctly, was meshed-handler + ttn-router-brazil but on Sunday, August 4, it suddenly stopped routing.
Initially I thought I had been penalized by FUP, because as I am in the development phase, I may have exceeded the limits during the tests, but I also read a very interesting post from you that confirmed that there were no penalties currently or bans.

I take advantage of your knowledge to clarify a great doubt:
If my gateway and devices are working on AU915, can I choose any combination of handler + router, preferably from the same node, or should I choose how I did that of the meshed-router due to the assigned frequency plan?
Or put another way, when the gateway connects, does it download directives for the channels it must activate and deactivate, based on the frequency plan of the handler?
It is a great doubt that I have. If the frequency plan is only defined in the gateway or if it must be matched in the handler and router.

Thanks in advance, I hope my doubt has been understood.

regards

32

No, depending on the software on the gateway it will use the local configuration file (global_conf.json usually) or it will download the channel plan based on the configuration (Frequency plan variable) you specified in the console.for the gateway. The frequencies used do not depend on the handler chosen.

33

Hi Jac
I currently use two Kerlink Gateways, one iBTS and one iFemtoCell. Both have the global_conf.json file with the AU915 frecuency plan.

I don´t understand that mechanism use, and what kind of gateway do this, to download frequency plan and from where is downloaded eventually. Can you give me some example to understand better this frequency plan update mechanism

So, then I can register my gateway on any handler with their correspondent router, based on the minor network transit time independently of the frequency plan used?

Thanks in advance

Hugo

34

@hmullerenersa In El Salvador (Central Americas) We are giving the users the instruction to use the router with less network hops to reduce network latency. In our case the closer router is the US router.

In general the gateways only Forward packets to the cloud infraestructure, the frequency depends on two things:

global_config.js defines the frequencies that the Gateway operates both for Uplink and Downlink, the frequencies are globally defined by the LoRaWAN alliance for each region, and you should expect that they are not going to change soon.

The “Frecuency Plan” selected on the Gateway Configuration on The Things Network Console.

The region must match between this two settings and the end-nodes to be able to route packets. It doesn’t matter if the region used uses a different band-plan it is going to answer to the node with the frequencies applicable for the specified Frecuency Plan.

Because the answers for down-links are time-critical you should would want to use the region that is physically closer to your physical location.

We hope that some day we could have a back-end for Central Americas located in Guatemala or Panama because they are the two countries with better global connectivity, meanwhile we are instructing the local gateway owners to use US-WEST even if the region uses a different band-plan.

2 Likes
35

Kerlinks do not update the configuration so you need to make sure the configuration is right. Examples of gateways downloading the frequency plan are The Things Gateway (original), The Things Indoor Gateway (TTIG) and some Raspberry Pi based gateways. The source of the frequency plan is the account server.

Yes. Please do. Network delays should be as small as possible to prevent them interfering with the LoRaWAN timing.

1 Like
36

Hi Jac
Thanks you very much, for clarifying the concepts.

With respect to select the network with small delays, I try to ping all servers, with the surprise that all have ICMP blocked.

ROUTER ROUTER uri IP Ping time
Digitalcatapult-uk-router ttn.thingsconnected.net 52.56.216.89 ping timeout
meshed-router thethings.meshed.com.au 52.62.83.250 ping timeout
switch-router ttn.opennetworkinfrastructure.org 86.119.29.227 ping timeout
ttn-router-asia-se asia-se.thethings.network 13.76.41.40 ping timeout
ttn-router-brazil brazil.thethings.network 191.235.82.46 ping timeout
ttn-router-eu eu.thethings.network 52.169.76.255 ping timeout
ttn-router-jp asia-se.thethings.network 13.76.41.40 ping timeout
ttn-router-us-west us-west.thethings.network 13.66.229.235 ping timeout

So, considering that it is not possible to ping or tracert, what method do you suggest to select the optimal router?

Thanks in advance.

Hugo

37

The infrastructure is hosted in the azure cloud which does not support ping. Selecting the closest one geographically should work. See the suggestions of @hackerspacesv

38

As you can see on this map. For the Central Americas region it doesn’t make a lot of sense to connect to any other endpoint rather than the one located in the US.