V3 Download global_conf.json

On the V3 console under the gateway overview, I notice a handy Download global_conf.json button

For me, the Download functionality does create the global_conf.json file but the contents appears to show “gateway_ID” : “value” in the json but the value produced is the Gateway EUI and not Gateway ID shown on the console. This seems inconsistent to me.

I guess it doesn’t matter if the EUI and the ID are the same, but I deliberately made mine different.
Is this a defect or just my misunderstanding?

The config file needs an 8-byte EUI given as hex digits to comply with protocol requirements.

What you chose to call your gateway isn’t really relevant at raw traffic level.

I fully appreciate the EUI needs to be compliant hex digits, it is just that when the global_conf.json is generated, it is storing the EUI in the field called gateway_ID.
I just find it confusing. Why capture a field Gateway ID on the console but not store it in the json. It strikes me the fields are muddled.

Well, that is what the field in the config file that needs to contain the valid EUI is called.

Why capture a field Gateway ID on the console but not store it in the json.

What did you put in there? If it’s not a compliant EUI it should probably be “Gateway Name” or something.

Thanks @cslorabox

I’m really not trying to make a big deal about this - it’s just about the semantics of Gateway ID
In the global_conf.json it means Gateway EUI but on the v3 console UI it does not.


People observing this for the first time might think it strange that in the global_conf.json gateway_ID doesn’t hold my-new-gateway when the json file is generated.

@hphillip: That’s indeed an interesting observation.

The term Gateway ID has 2 meanings (only) in this context.

  • ID of the gateway that’s used to register it on TTS (ex: my-new-gateway)
  • A field that’s part of the legacy UDP gateway spec (which is actually the EUI).

For the latter, TTS does not control the spec. It’s part of the open source packet forwarder reference that is being used for years now.

For new users, this may be confusing indeed. But it’s just one of those Legacy things.

PS: If you’re new to LoRaWAN, I’d recommend using a Gateway that supports the LoRa Basics Station Protocol as that is more future proof. You can look around in the forum for more information on that.

1 Like