You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repository and believe that this is not a duplicate.
Summary
chirpstack-gateway-bridge is unable to make use of the 27dBm limit of my country, when coupled with BasicStation. We should have some way to use a higher transmission power, when the local regulations permit it. There is presently no such workflow in Chirpstack and BasicStation.
What is the use-case?
Regions like AS923 cover many territories, with different local regulations. The AS923 default in BasicStation implementations is usually a conservative value (e.g. 14-16dBm), for maximum compatibility by default. Chirpstack doesn't support specifying a different value and neither is there a workflow for this in BasicStation.
I am from Singapore, where the maximum transmission power for LoRa gateways is 27dBm. However, the whole workflow from Chirpstack to BasicStation, doesn't support this higher limit and there is no official workflow for achieving this.
Note: I will be raising tickets with 3 different parties to create a complete solution:
Semtech/Lorabasics^
Kerlink
Chirpstack
^ If a well-known region ID is specified, then we can only lower the EIRP - which is not useful. I am trying to restart the discussion on lorabasics/basicstation#137, to determine what the reference implementation's solution is.
Implementation description
Since it affects Semtech's reference BasicStation implementation, Kerlink's version of BasicStation and Chirpstack, I feel that some level of direction needs to come from Semtech first. Perhaps the answer should involve specifying the non-default downlink EIRP via the max_eirp field of the router_config message. However, this field cannot be used to increase the maximum EIRP with today's BasicStation reference implementation, unless a custom region ID is passed. For example: to actually increase this limit, I need to specify "AS923_Custom" as the region instead of "AS923-1", before BasicStation should allow me to set max_eirp to 27.
I'm trying to ask whether Semtech would be open to allowing max_eirp to also serve as an override. So that we wouldn't need to specify a totally original region ID, as doing that seems like a hack.
Creating a completely new region ID for this purpose, would also discard all other logic that was created for supporting the region, if there's any. There presently isn't any logic for automatically enabling LBT for cases like Japan's AS923, but I think it's a possible design choice for Semtech since they actually implemented duty-cycle logic for only EU868.
What does the community here think? Does it make sense for max_eirp to be usable as an override?
To me, it is in the spirit of the original spirit of the classic Semtech Packet Forwarder, to be able to override this value as required. I cannot really imagine how they'll successfully profile the regulations of all the countries that use AS923.
Can you implement this by yourself and make a pull request?
It's technically possible.
The text was updated successfully, but these errors were encountered:
Summary
chirpstack-gateway-bridge is unable to make use of the 27dBm limit of my country, when coupled with BasicStation. We should have some way to use a higher transmission power, when the local regulations permit it. There is presently no such workflow in Chirpstack and BasicStation.
What is the use-case?
Regions like AS923 cover many territories, with different local regulations. The AS923 default in BasicStation implementations is usually a conservative value (e.g. 14-16dBm), for maximum compatibility by default. Chirpstack doesn't support specifying a different value and neither is there a workflow for this in BasicStation.
I am from Singapore, where the maximum transmission power for LoRa gateways is 27dBm. However, the whole workflow from Chirpstack to BasicStation, doesn't support this higher limit and there is no official workflow for achieving this.
Note: I will be raising tickets with 3 different parties to create a complete solution:
^ If a well-known region ID is specified, then we can only lower the EIRP - which is not useful. I am trying to restart the discussion on lorabasics/basicstation#137, to determine what the reference implementation's solution is.
Implementation description
Since it affects Semtech's reference BasicStation implementation, Kerlink's version of BasicStation and Chirpstack, I feel that some level of direction needs to come from Semtech first. Perhaps the answer should involve specifying the non-default downlink EIRP via the max_eirp field of the router_config message. However, this field cannot be used to increase the maximum EIRP with today's BasicStation reference implementation, unless a custom region ID is passed. For example: to actually increase this limit, I need to specify "AS923_Custom" as the region instead of "AS923-1", before BasicStation should allow me to set max_eirp to 27.
I'm trying to ask whether Semtech would be open to allowing max_eirp to also serve as an override. So that we wouldn't need to specify a totally original region ID, as doing that seems like a hack.
Creating a completely new region ID for this purpose, would also discard all other logic that was created for supporting the region, if there's any. There presently isn't any logic for automatically enabling LBT for cases like Japan's AS923, but I think it's a possible design choice for Semtech since they actually implemented duty-cycle logic for only EU868.
What does the community here think? Does it make sense for max_eirp to be usable as an override?
To me, it is in the spirit of the original spirit of the classic Semtech Packet Forwarder, to be able to override this value as required. I cannot really imagine how they'll successfully profile the regulations of all the countries that use AS923.
Can you implement this by yourself and make a pull request?
It's technically possible.
The text was updated successfully, but these errors were encountered: