Closed ndoo closed 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.
Sorry this fell by the wayside. I get your reasoning, but have several questions
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:
SX126X_MAX_POWER 19
as defined in variant.hThe current behavior for XIAO BLE + E22-900M30S:
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.
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.