search

chirpstack / chirpstack-concentratord

Concentrator HAL daemon for LoRa gateways.
https://www.chirpstack.io/
MIT License
71 stars 50 forks source link

Duty cycle tracking causes downlink to be rejected for antenna gains < 2dBi #157

Closed aurel32 closed 2 months ago

aurel32 commented 2 months ago

What happened?

Thanks for adding duty-cycle tracking to chirpstack-concentratord v4.4.0. While the time part works fine, the power part does not work with the default power level in the EU868 region and an antenna gain below 2. Downlinks get rejected, even if duty cycle enforcement is not enabled.

What did you expect?

From the regulation a 16 dBm EIRP should be allowed for the M band and a 29 dBm EIRP should allowed for the P band.

Steps to reproduce this issue

Steps:

  1. Set the antenna gain to 0 or 1 dBi
  2. Schedule a downlink
  3. See it getting rejected

Could you share your log output?

MQTT logs:

chirpstack/eu868/gateway/xxxxxxxxxxxxxxxx/command/down {"downlinkId":691944082,"items":[{"phyPayload":"YMaLLQKgQwABLts0PT8=","txInfo":{"frequency":868100000,"power":16,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":7,"codeRate":"CR_4_5","polarizationInversion":true}},"timing":{"delay":{"delay":"1s"}},"context":"BIMWzQ=="}},{"phyPayload":"YMaLLQKgQwABLts0PT8=","txInfo":{"frequency":869525000,"power":29,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":12,"codeRate":"CR_4_5","polarizationInversion":true}},"timing":{"delay":{"delay":"2s"}},"context":"BIMWzQ=="}}],"gatewayId":"xxxxxxxxxxxxxxxx"}
chirpstack/eu868/gateway/xxxxxxxxxxxxxxxx/event/ack {"gatewayId":"xxxxxxxxxxxxxxxx","downlinkId":691944082,"items":[{"status":"DUTY_CYCLE_OVERFLOW"},{"status":"DUTY_CYCLE_OVERFLOW"}]}

Console logs (with an antenna gain of 1 dBi):

WARN  [libconcentratord::jitqueue] No duty-cycle band found for packet, downlink_id: 691944082, freq: 868100000, tx_power: 15
WARN  [libconcentratord::jitqueue] No duty-cycle band found for packet, downlink_id: 691944082, freq: 869525000, tx_power: 28

(Notice how the antenna gain has been subtracted at that level)

Your Environment

Component Version
Network Server v4.7.0
MQTT Forwarder v4.3.0
Concentratord v4.4.0

Analysis

The transmitted TX power is configured the following way:

Now comes the ETSI EN 300 220 regulation. The etsi_en_300_220.rs lists for each band maximum allowed duty cycle and the maximum TX power. In that file, the TX powers are actually ERP TX powers, so 2.15 dB lower (rounded to 2 dB) than the EIRP TX powers. In practice chirpstack-concentratord:

In short it tries to match the transmitter power to the regulation, while the regulation applies to the radiated power by the antenna. Therefore I think the regulation matching should be done by converting the EIRP to ERP (or vice versa) and before subtracting the antenna gain.

brocaar commented 2 months ago

Lets break this issue in two:

  1. Downlinks get rejected, even if duty cycle enforcement is not enabled.
  2. Currently there is no option do compensate for cable loss.

The minimum antenna gain should always be 2 dBi if I'm not mistaken, but what you try to achieve is to compensate for the potential cable loss (e.g. very long cable). Wouldn't it be better to add a separate option for this?

aurel32 commented 2 months ago

Lets break this issue in two:

1. Downlinks get rejected, even if duty cycle enforcement is not enabled.

2. Currently there is no option do compensate for cable loss.

Sounds good splitting the issue in two, but I am not sure we want an option to compensate for cable loss.

The minimum antenna gain should always be 2 dBi if I'm not mistaken, but what you try to achieve is to compensate for the potential cable loss (e.g. very long cable). Wouldn't it be better to add a separate option for this?

There are antennas with a gain smaller than 2 dBi, even if those are small antennas you usually do not want to have on a gateway (see for example https://www.mouser.fr/datasheet/2/418/9/ENG_DS_L9000149_01_A-3238949.pdf). I don't think there is a need to compensate for a cable loss, this is traditionally included in the antenna gain, and represents the difference between the power at the transmitter level and the radiated power. It is how chirpstack-concentratord interprets that to compute the transmit power to be send to the SX12xx chip and that part is correct and works fine.

I still believe that what is done for the power at the duty cycle tracking level is not correct. The inherent problem is that the SX12xx transmit power is matched with the radiated power of the regulation, and in addition EIRP vs ERP.

In my opinion, this is what should be done:

brocaar commented 2 months ago

Thanks, I'm not an expert in antennas, so this is very helpful information. Maybe updating the regulation config to EIRP might be even better, because then we are dealing with one unit, not two (there is no guarantee that future regulations will be in ERP only). Maybe we could define the values as tx_power_max: 14 + 2, just to make it explicit that we have added 2 on purpose (and a comment for the first entry). If we change it to 16 and when the context is forgotten, it might look as a mistake.

I will try to look into this later today / tomorrow. If you would like to create a PR for this, that would be great as well :)

brocaar commented 2 months ago

@aurel32 could you review these changes, I believe this is what you proposed:

https://github.com/chirpstack/chirpstack-concentratord/compare/fix_issue_157

aurel32 commented 2 months ago

@aurel32 could you review these changes, I believe this is what you proposed:

https://github.com/chirpstack/chirpstack-concentratord/compare/fix_issue_157

Thanks a lot for the quick fix. This definitely corresponds to what I described. I also tested the resulting chirpstack-concentratord-sx1302 binary and I confirm it works as expected.

brocaar commented 2 months ago

Thanks @aurel32 for testing. This has been released as v4.4.1.