Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add REGULATORY_GAIN configuration to remain within regulatory ERP limit #3836

Merged
merged 8 commits into from
Jun 20, 2024

Conversation

ndoo
Copy link
Contributor

@ndoo ndoo commented May 8, 2024

REGULATORY_GAIN_LORA is the total LoRa gain in dBm to subtract from the configured Tx power, to remain within regulatory ERP limit for non-licensed operators.

This value should be set at build-time in variant.h and is PA gain + antenna gain (if the Meshtastic device is built with a fixed antenna, e.g. PCB trace antenna or non-removable whip).

This is similar to antenna_gain/NL80211_ATTR_WIPHY_ANTENNA_GAIN/NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN setting in Linux Regulatory/OpenWrt/mac80211/nl80211/iw.

The final transmit power is (myRegion->powerLimit - REGULATORY_GAIN) or the user's configured loraConfig.tx_power, whichever is lower.

This is implemented in DIY XIAO BLE EBYTE E22-900M30S variant as an example.

@ndoo ndoo force-pushed the regulatory-gain branch 9 times, most recently from 75479d2 to 2afb70c Compare May 15, 2024 04:07
@ndoo ndoo force-pushed the regulatory-gain branch 6 times, most recently from 635b82a to 4b96d4a Compare May 22, 2024 10:09
@ndoo ndoo force-pushed the regulatory-gain branch 4 times, most recently from 7211faf to 9db514f Compare May 29, 2024 08:44
@ndoo ndoo force-pushed the regulatory-gain branch 2 times, most recently from 634edcf to b988ef8 Compare June 3, 2024 18:03
@ndoo
Copy link
Contributor Author

ndoo commented Jun 4, 2024

Hi there, is there any reason to wait on this PR? If myself or Unit Engineering continue to build and ship boards with built in PAs in front of the SX1262/other LoRa ICs, we need to introduce controls for non-licensed-hams to not be able to transmit at several watts above ISM regulatory limits.

@ndoo ndoo force-pushed the regulatory-gain branch 2 times, most recently from 9ef6f4b to b620d2c Compare June 4, 2024 23:59
ndoo added 5 commits June 6, 2024 14:42
Add REGULATORY_ prefix to LORA_REGIONCODE to prepare for more regulatory configuration options, and update comment block accordingly too.

Signed-off-by: Andrew Yong <[email protected]>
REGULATORY_GAIN is the total system gain in dBm to subtract from the configured Tx power, to remain within regulatory ERP limit for non-licensed operators.

This value should be set in variant.h and is PA gain + antenna gain (if system ships with an antenna).

This is similar to antenna_gain/NL80211_ATTR_WIPHY_ANTENNA_GAIN/NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN setting in Linux Regulatory/OpenWrt/mac80211/nl80211/iw.

Signed-off-by: Andrew Yong <[email protected]>
Specify REGULATORY_GAIN and SX126X_MAX_POWER to prevent exceeding regulatory and hardware limits (i.e. overloading the PA input) respectively.

Also update the build flag to define EBYTE_E22_900M30S instead of just EBYTE_E22, since all the builds on the Discourse topic [New 1W DIY variant: Xiao nRF52840 + Ebyte E22-900M30S](https://meshtastic.discourse.group/t/new-1w-diy-variant-xiao-nrf52840-ebyte-e22-900m30s/7904) are using this module.

That should make it clearer as well that the variant header file should be tweaked if DIY builds are using stronger (E22-900M33S, not commonly available at this time) or weaker (E22-900M22S, not popular for DIY builds due to lack of differentiation from ordinary SX1262 modules).

Retain EBYTE_E22 flag alongside EBYTE_E22_900M30S build flag to prevent possible regressions in code paths generally intended for EBYTE E22 modules.

Signed-off-by: Andrew Yong <[email protected]>
…gain controls

For example, Wi-Fi or BLE gain control (meshtastic#3962)

Signed-off-by: Andrew Yong <[email protected]>
@ndoo ndoo force-pushed the regulatory-gain branch from b620d2c to 08e1c2f Compare June 6, 2024 06:42
@caveman99
Copy link
Member

caveman99 commented Jun 16, 2024

Sorry this fell by the wayside. I get your reasoning, but have several questions

  • these are geared towards devices with fixed antennas so the gain of the whole system is known. How would a HAM override these limits so they can TX at full power?
  • Is this a requirement for certification of these devices? Cause flashing a modified firmare without this patch will revert to the previous behaviour. It's also different from the max output settings on certain boards to not saturate the PA.
  • In general most devices have antenna ports so this is not applicable, but adds a lot of complexity to the power settings code. My question would be, what is the compelling use case where this is absolutely required and would otherweise inhibit your ability to manufacture and sell devices?

@ndoo
Copy link
Contributor Author

ndoo commented Jun 16, 2024

Sorry this fell by the wayside. I get your reasoning, but have several questions

  • these are geared towards devices with fixed antennas so the gain of the whole system is known. How would a HAM override these limits so they can TX at full power?

Hello there, this is aimed at 2 sets of devices:

  1. Devices that have PAs thus needing to account for PA gain for output power remaining within the configured region (device manufacturer's responsibility), regardless of radiated power at antenna (user's responsibility).
  2. Devices that have PAs and/or fixed antennae (same as (1) but the radiated power is the manufacturer's responsibility alone)

Regarding licensed hams, the !devicestate.owner.is_licensed check in RadioInterface.cpp#481 where power is calculated bypasses the regulatory power limit calculation anyway, and this remains the same before and after this PR.

  • Is this a requirement for certification of these devices? Cause flashing a modified firmare without this patch will revert to the previous behaviour. It's also different from the max output settings on certain boards to not saturate the PA.

It would make retailing devices easier in countries like mine (Singapore) where devices can get regulatory labels based on the device in retail state (i.e. user replacing the firmware is a personal violation and not the retailer/manufacturer).

  • In general most devices have antenna ports so this is not applicable, but adds a lot of complexity to the power settings code. My question would be, what is the compelling use case where this is absolutely required and would otherweise inhibit your ability to manufacture and sell devices?

It would be important bring devices with PA into compliance once those variants' variant.h file is updated. I think the below calculations should make it clearer why this definition is important.

The current behavior for Station G2, taking region setting SG_923 as an example:

  1. User sets 20dBm, or, firmware sets 20dBm by default
  2. Meshtastic caps the transmit power to SX126X_MAX_POWER 19 as defined in variant.h
  3. Actual transmit power to the antenna is 19dBm (SX1262) + 17.5dBm (PA) = 36.5dBm (see table here)

The current behavior for XIAO BLE + E22-900M30S:

  1. User sets 20dBm, or, firmware sets 20dBm by default
  2. Actual transmit power to the antenna is 20dBm (SX1262) + 10dBm (PA) = 30dBm

Edit: In either case, there is no visual indication in the GUI or serial logs on what the actual transmitted power is, since the firmware is not aware of the PA gain. Unless the user looks at the product datasheet and works backward, it's not obvious to the user they have broken the regulatory limit.

The complexity is not much, it's just a quick subtraction when calculating power; the change to the code in src/mesh/RadioInterface.cpp is straightforward.

I'm not sure this is a "use case" from the POV of Meshtastic users, but it's more to prevent inadvertently breaking the law because the user bought a fancy device with built-in PA and then set 20dBm thinking it's the device's output power setting when it's just the Semtech chip's output setting (or the SX126X_MAX_POWER limit); it seems reasonable that the firmware should guard the user against that.

@caveman99 caveman99 merged commit f145b5f into meshtastic:master Jun 20, 2024
89 checks passed
@ndoo ndoo deleted the regulatory-gain branch August 12, 2024 11:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants