LT-22222 with LPS8 gateway on Meshed AU915: repeated OTAA joins, no uplinks

[Sgrobler]

That would explain it all Thanks for taking the time to help me with this!
No idea how it got screwed up like that.
Don’t think I registered it in any of those frequency plans.
I had tried deleting it and re-registering. Once on www.thethingsnetwork.org and then on console.thethings.meshed.com.au.
I certainly dont see any of those settings from the TTN console:

[arjanvanb (Arjan)]

And the application’s Handler? And maybe you can try ttnctl yourself as well, to see if that gives you different results when not run from Europe?

[Sgrobler]

@arjanvanb

Something has been messed up big time?

You were right - Join Accept frequency was wrong.
Good news - problem solved. It all came down to the firmware in the device (LPS8 gateway) not being correct. Edwin at Dragino sent me a link to a new firmware and bingo - problem solved .

Many thanks to everyone for your comments and encouragement.

[arjanvanb (Arjan)]

For future reference, the following is okay now too. So, apparently, this is also affected by status packets or uplinks sent from the gateway to TTN?

https://www.thethingsnetwork.org/gateway-data/gateway/eui-a840411eb93c4150, which showed "frequency_plan": "AS_920_923" earlier, returns "frequency_plan": "AU_915_928" now:

{
  "eui-a840411eb93c4150": {
    "id": "eui-a840411eb93c4150",
    "description": "LPS8",
    "country_code": "au",
    "attributes": {
      "antenna_model": "915",
      "brand": "Dragino",
      "frequency_plan": "AU_915_928",
      "model": "LPS8",
      "placement": "indoor"
    }
  }
}

Note that the above is also lacking the location now (and owner details). Same goes for https://www.thethingsnetwork.org/u/sgrobler Did you set those details to be private? (If you made changes, then maybe that actually updated the details on the other network components, rather than the new gateway firmware?)

For ttnctl gateways status, when invoked from Europe, I still see Last seen: 2020-09-29 14:14:39 and Frequency Plan: EU_863_870 like earlier. But maybe that’s caused by my settings for the CLI, which somehow prefer the EU router? For future readers it may still be nice to see what the result is when invoked by a Meshed user.

For ttnctl gateways info, which already showed Frequency Plan: AU_915_928 earlier too, the location and owner have gone missing too.

[Sgrobler]

@arjanvanb

Did you set those details to be private?

Yes I did set those to private. I am fairly convinced it was the firmware that resolved the problem because I had previously deleted the gateway in ttn and re-created it, and it still didn’t work.

What is the significance/etiquette for setting details private/public?
My project is a one-off hobby project.

[arjanvanb (Arjan)]

@Sgrobler

My project is a one-off hobby project.

…but your gateway could help build the network even when that project is done!

Any TTN device can use any TTN gateway, regardless if its location is known. (Devices just transmit, gateways just forward, so the only requirement is a matching frequency plan.) If the location is public then it’s easier for people to debug, or to guess if there is coverage. And if the owner is public then one can even contact the owner in case of problems. That surely helps build the network, but: up to you.

@Sgrobler

Fri Oct 2 19:10:08 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"rxpk":[{"tmst":191817379,"time":"2020-10-02T11:10:08.978056Z","chan":8,"rfch":0,"freq":917.500000,"stat":1,"modu":"LORA","datr":"SF8BW500","codr":"4/5","lsnr":10.5,"rssi":-25,"size":23,"data":"ALsagpF6QUCouxqCMf9BQKifyfh1maA="}]}

Any chance you can show us a packet as sent with the new firmware? I doubt the details of the above uplink will make TTN use a different frequency plan. Maybe the contents of status messages differ though. Also, I hope that using a different endpoint to sent those messages to, does not affect anything.

[Sgrobler]

@arjanvanb

That surely helps build the network

I’ve reset it to public, but its off at the moment, while I get some sensors together.
I’ll post a packet when I get back on line

[arjanvanb (Arjan)]

@Sgrobler

I’ve reset it to public

Nice.

@Sgrobler

but its off at the moment

Ah, bummer. If you’re not running it 24/7 then it’s actually much better to not make its location pubic: others will surely expect gateways to be online day and night.

Even more, even when the location is not public, devices that use ADR may be instructed by the TTN network server to limit their transmission power or to switch to a better data rate, if your gateway had best reception for a series of packets. So, switching it off may already affect devices in your neighbourhood that suddenly see packet loss as the network has changed.

What are you trying to achieve by connecting it to the TTN community network but not running it 24/7?

[arjanvanb (Arjan)]

@arjanvanb

If you’re not running it 24/7 then it’s actually much better to not make its location pubic: others will surely expect gateways to be online day and night.

Giving it some more thought, maybe even then it’s better to have the location public: at least people may then sometimes see it as offline on, e.g., thethingsnetwork.org/map and ttnmapper.org instead of just having to guess what happened? Not sure what’s best here.

(Of course, the above is moot when trying to run gateways 24/7 when using the TTN community. Please consider doing that!)

[cslorabox]

@arjanvanb

What are you trying to achieve by connecting it to the TTN community network but not running it 24/7?

One might also legitimately ask what TTN is trying to achieve by having no way to distinguish between experiments and infrastructure.

Someone wanting to try out TTN realistically typically ends up needing to get a gateway, either because there isn’t good local coverage, or because they need the raw gateway view of what is going on to debug node issues.

And because we’ve told them they can’t use a single channel abomination, that has to be a real gateway.

But just buying a real gateway doesn’t mean it’s going in a roof top machine room with a nice antenna and 24/7 power.

More likely it’s sitting on a desk with a power cord stretch across the room to a free outlet and uplinked via a spare patch cable where the locking tab broke off the RJ45 three years ago.

Maybe it’s time that gateway registration (or better yet, the backhaul protocols themselves) gained some flag bits.

• Don’t count on me

• Don’t use my RSSI in the ADR algorithm (or at least, not unless the node is also registered to this account)

• I’ll probably drop downlink transmit requests, so chose any other gateway first

• I can only receive this channel/SF…

Expecting particular hardware be used is already a tall order; expecting that once plugged in for any purpose it stays powered and backhauled 24/7 is… a bit much.

But yes, that is currently the implicit ask.

[arjanvanb (Arjan)]

Nice idea to have those options in TTN Console! But then please disable the “Save” button and link to the Manifesto (and downloads of private stacks) until all have been unchecked.

[cslorabox]

@arjanvanb

But then please disable the “Save” button and link to the Manifesto (and downloads of private stacks) until all have been unchecked.

No.

The whole point is to allow those newly interested to experiment and learn by participating at the edge of TTN, and to usefully contribute uplink’s of other node’s traffic to it to the degree to which they are able, without the network being negatively impacted by the degree to which they are unable

It’s the “all or nothing” mindset you are promoting which isn’t actually workable for anyone but the most established users who can support hardware in real, permanent installations.

Otherwise, might as well just tell everyone unable to commit to being an infrastructure service provider from day one to get lost and try chirpstack instead.

[arjanvanb (Arjan)]

For the 4 example options that you’ve given, which I feel are mostly human choices which are easily avoided when getting to know the basics before connecting something*, I very much disagree.

But yes, one cannot expect the community network (or any network) to provide constant non-changing coverage.

*) If we would make it easier to find that information, or maybe even “mandatory” to read it.

[cslorabox]

@arjanvanb

easily avoided when getting to know the basics before connecting something

How can you try anything without connecting it?

Do you really want to steer people to using a server other than TTN, before trying TTN?

If you do that, a lot may never come back

Wheras a set of “this is an experiment” flags are something which can be easily un-checked, by people who’ve never needed to leave the fold in the first place.

[arjanvanb (Arjan)]

@cslorabox

The whole point is to allow those newly interested to experiment and learn

Ah, the whole point of those flags? (I read that as of TTN. Silly me.)

@cslorabox

a set of “this is an experiment” flags are something which can be easily un-checked

Yes, very nice!

[Sgrobler]

@arjanvanb

Any chance you can show us a packet as sent with the new firmware?

Wed Oct 7 13:33:25 2020 daemon.info lora_pkt_fwd[2610]: RXTX~ {"rxpk":[{"tmst":1872152540,"time":"2020-10-07T13:33:25.475624Z","chan":5,"rfch":1,"freq":917.800000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":10.0,"rssi":-30,"size":24,"data":"QHEQACaABAACvMVB5U/RCz+10APMynUM"}]} 

Some differences - do they explain the problem I had before?

Thanks for the discussion about public vs private etc. When I get my kit finished it will be set up permanently, so I will make my gateway public so it helps build the network.
Thanks again to everyone for your interest and assistance!

[arjanvanb (Arjan)]

@Sgrobler

Some differences - do they explain the problem I had before?

I don’t see anything referring to a frequency plan. Maybe it’s in the status messages? Or a change in some URL that the new firmware uses? I just read/remembered that AU915 and AS923 have their own endpoints on Meshed as well:

@Maj

AU915 UDP gateways should point to au915.thethings.meshed.com.au
AS923 UDP gateways should point to as923.thethings.meshed.com.au
AU915 and AS923 MQTT (and other) gateways should point to thethings.meshed.com.au (or router.au.thethings.network)

And as for:

@arjanvanb

For ttnctl gateways status , when invoked from Europe, I still see Last seen: 2020-09-29 14:14:39 and Frequency Plan: EU_863_870 like earlier.

I just read:

@Maj

Running ttnctl gateways info might show the incorrect band plan for your gateway. Don’t worry about this, it is incorrect. It’s because ttnctl doesn’t support the new V3 gateway offloader completely.

Though the latter is about info (which already showed AU915 for me), not about status (which showed EU868), maybe that still explains things.

Meanwhile, that very same gateways status, when using my EU868 TTN account, is giving me no results at all:

ttnctl gateways status eui-a840411eb93c4150
  INFO Discovering Router...                   
  INFO Connecting with Router...               
  INFO Connected to Router                     
 FATAL Could not get status of gateway. 
 GatewayID=eui-a840411eb93c4150
 error=Gateway eui-a840411eb93c4150 not found

But gateways info still looks good.

[Klingonbaby]

Can we get a copy of the link from Dragino ?

[Sgrobler]

Sure - here it is:

http://www.dragino.com/downloads/index.php?dir=LoRa_Gateway/DLOS8/Firmware/Test_Firmware/lgw--build-v5.4.1601176792-20200927-1122/

[Klingonbaby]

This is for the LT-22222-L firmware update ?