LoRaWan Channel about packet_forwarder HOT 3 CLOSED

Common gateways have only one SX1301 chip.
Each SX1301 can listen to 8 different channels simultaneously (with independence on using one or two sx125x chips). you can't listen to 16 channels with simple gateways (Kerlink IOT Station....).

If you want to use 16 channels in EU868 you need a gateway with 2 x SX1301 chips (Cisco, Kerlink iBTS...).
If you want to use 64 channels in US915 you need a gateway with 8 x SX1301 chips (Kerlink iBTS, Tektelic...).

from packet_forwarder.

We purchased a LoRaGo Port (Sandbox Electronics, 8 channels) and mated it to a Raspberry Pi 3 B.
We modified the TTN ic880a installation bash script to perform the install. We used this collection of Semtech lora_gateway and Semtech Packet_Forwarder to become operational.
Our lack of knowledge means that

• we are not certain the global_conf.json that originates from TTN is correct for our installation, 915 MHz, Canada.
  On our two STM LoRa Discovery modules, we used the US 915 MHz Hybrid configuration when building our firmware.
  We initially used the Semtech NA Network Server but have now setup up LoRa Server and are now using that.
  We believe we have had ABP working, but OTAA is problematic (sometimes works??) and we are trying to figure out why.
  Thus, we want to know a lot more about what all the entries in the gloabl_conf.json file mean and do, even though some of them we can surmise as to what they represent.
  In addition, in LoRa Server, there is a configuration option in Channel Management, where the user can presumably define the required channels for use.
• I defined 0, 1, 2, 3, 4, 5, 6, 7 and OTAA did not produce any frame logs in the LoRa Server interface.
• I went back and added 64, thus, 0, 1, 2, 3, 4, 5, 6, 7, 64. Was this the correct thing to do? I am now seeing frame logs for our OTAA End Node.

I would appreciate guidance and thoughts about this, thank you.

from packet_forwarder.

In an effort to improve our customer support experience and in recognition that our support backlog on GitHub has historically exceeded the capacity of our engineering team, we have taken the difficult decision to focus on the most contemporary issues reported and to close all others without confirmation of resolution.

Our belief is that issues which have remained unresolved and unaltered for extended periods of time are less likely to continue to pose a significant problem to the user than when they were originally filed. More contemporary issues however may still be relevant and hence are more appropriate to prioritize.

For those users who remain interested in resolution of a reported issue that was closed, we are encouraging usage of our developer portal forums [https://forum.lora-developers.semtech.com/] and commercial support portal [https://semtech.force.com/ldp/ldp_support?__hstc=212684107.579a13689e43099691e328c9248e6ecc.1623103335314.1624470656297.1624635514661.6&__hssc=212684107.6.1624635514661&__hsfp=4176385453] as the preferred avenues to receive support. We will continue to monitor the GitHub issue trackers as well, but want to encourage all users to take advantage of the increased community presence on the developer portal. For commercial customers, we highly recommend using the commercial support portal which is uniquely tailored to service such support requests.

from packet_forwarder.