meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
3.07k stars 741 forks source link

Add REGULATORY_GAIN configuration to remain within regulatory ERP limit #3836

Closed ndoo closed 1 month ago

ndoo commented 2 months ago

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 commented 1 month ago

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.

caveman99 commented 1 month ago

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

ndoo commented 1 month ago

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.