Setting tx_power on Z-Stack's 20211217 experimental firmware does not yield improved change

[ruimarinho]

As part of an effort by the community driven by @Hedda (https://github.com/Koenkk/Z-Stack-firmware/issues/323), Koenkk has published an experimental firmware which finally allows setting TX power on CC2562P and CC1352P based radio modules.

I've flashed my coordinator with this firmware and since I'm using ZHA + znp in HASS, I've been experimenting setting various tx_power levels.

I can see on HASS logs that the SetTxPower call https://github.com/zigpy/zigpy-znp/blob/074f33f3832697828bb905d12a547b4b5bf564aa/zigpy_znp/commands/sys.py#L414-L426 is successful, but I don't actually observe any change in LQI on any device. I assume the new default of this firmware (+9dBm) is what's getting applied and not the software-based sys command.

Would you be able to give this a look @puddly? Thank you!

Edit: I'm wondering what would be the impact of https://github.com/zigpy/zigpy-znp/issues/11 before this firmware got published.

[Hedda]

Maybe also a separate feature request form setting 20 dBm on CC1352P and CC2652P? This is now the highest in Zigbee2MQTT.

Also noted that 19 dBM is highest setting for CC253x as mentioned in https://github.com/zigpy/zigpy-znp/issues/11 but CC13x2 and CC26x2 should allow up to 20 dBm?

[puddly]

LQI for TI coordinators is just the RSSI linearly remapped to 0-255. Does the power amplifier increase this? Or does it only affect transmit power?

What does the coordinator LQI from the perspective of a nearby router look like with the change? For each link, there really are two LQIs.

[ruimarinho]

Does the power amplifier increase this? Or does it only affect transmit power?

I wouldn't know the answer to this. Maybe @Hedda or @Koenkk can help. My impression based on flashing hardcoded +20dBm firmwares on a router is that the LQI changes (more than doubles in some cases), so I suspect to the answer to your question is yes, it affects LQI.

What does the coordinator LQI from the perspective of a nearby router look like with the change?

I am reporting the LQI from the router because on TI coordinators, to my knowledge, endpoints connected via the router will always report the router's LQI. In this case, the LQI from the router did not change with or without the tx_power setting there.

[Koenkk]

Or does it only affect transmit power?

Only transmit power (it is shouting harder, not hearing better 😉 )

[Hedda]

LQI for TI coordinators is just the RSSI linearly remapped to 0-255. Does the power amplifier increase this? Or does it only affect transmit power?

As mentioned, LQI/RSSI on the Zigbee coordinator side is not affected at all, but LQI/RSSI on Zigbee devices connected to it are however very much affected as they are on the receiving side when Zigbee coordinator is transmitting a stronger signal to them.

So the presumed issue in zigpy-znp now is that while flashing Koenkk's 20211217 firmware to the CC2652P based "Sonoff Zigbee 3.0 USB Dongle Plus” by ITead does vastly affect transmission strength when testing it in Zigbee2MQTT with 20 dBm as transmit power configured, changing tx_power configuration to 19 dBm as transmission power output setting in the current Home Assistant's ZHA release and testing it to see if it improves LQI/RSSI on connected Zigbee devices does currently not seem to affect their reception as if transmission strength was not increased when comparing to not changing default tx_power configuration settings.

FYI @chiakikato tested with Zigbee2MQTT (not ZHA/zigpy-znp) and posted result as a graph in https://github.com/Koenkk/Z-Stack-firmware/issues/323

His test result shows that 20211217 20 dBm firmware on Sonoff with CC2652P performs much better than with 20210708 and zzh:

[MattWestb]

As sad of some in Z2M thread more power can making more interferences and and also the chip is being less stable then warming up more and the best is having good routers and one good receiver in all routers (= also in the coordinator).

Solabs have some very good paper with dense network testing that describing much of the problematic and in the end its the best making one good working backbone with good routers for getting all working well.

[Adminiuga]

Or does it only affect transmit power?

Only transmit power (it is shouting harder, not hearing better 😉 )

on the same note, for the far end hearing a stronger signal (better RSSI) does not necessarily equate to getting a better LQI.

So while nobody disputes the graph with higher RSSIs, I'd rather see the bit error rate for a test stream for each TX power level.

[chiakikato]

Or does it only affect transmit power?

Only transmit power (it is shouting harder, not hearing better 😉 )

on the same note, for the far end hearing a stronger signal (better RSSI) does not necessarily equate to getting a better LQI.

So while nobody disputes the graph with higher RSSIs, I'd rather see the bit error rate for a test stream for each TX power level.

This is the values of LQI on zigbee2mqtt recorded from the end device located 6meters away from coordinator. This is recorded at the same time with my RSSI measuring test.

Before @https://github.com/tteck tell me I didn't know ch25 and ch26 has low power output. This result shows my End device output lower power with following it rule. Other than this, coordinator output signal power does not affect to receiving LQI, of course.

[tannisroot]

Made a firmware image based off 20211217 with the default TX power set to 20 instead of 9, and at least for me it helped improve LQI with ZHA. I forgot to get LQI data with 9 dbm but from what I can remember, LQI score improved from as low as +20 to as high as +70. Almost all links that were "red" before are now yellow for me. So it's possible that tx_power is not working properly for some reason, but I might be wrong. Firmware for others to try: sonoff_20dbm.zip

[puddly]

@tannisroot Give this script try with a router that is in range of the coordinator:

import sys
import asyncio
import logging

import zigpy.topology
zigpy.topology.DELAY_INTER_DEVICE = 0

from zigpy_znp.tools.common import setup_parser
from zigpy_znp.zigbee.application import ControllerApplication

LOGGER = logging.getLogger(__name__)

async def test_network(radio_path, *, tx_power, nwk):
    config = ControllerApplication.SCHEMA(
        {"device": {"path": radio_path}, "znp_config": {"tx_power": tx_power}}
    )
    app = await ControllerApplication.new(config, start_radio=True, auto_form=True)

    device = await app._get_or_discover_device(nwk=nwk)

    while not device.is_initialized:
        await asyncio.sleep(0.1)

    LOGGER.info("Scanning topology")
    await app.topology.scan()

    # Find the neighbor entry for the coordinator
    neighbor = next(n for n in device.neighbors if n.device is app.zigpy_device)

    LOGGER.critical(
        "[tx_power=%s] LQI from coordinator to device: %s",
        tx_power,
        neighbor.neighbor.lqi,
    )
    LOGGER.critical(
        "[tx_power=%s] LQI from device to coordinator: %s", tx_power, device.lqi
    )

    await app.shutdown()

async def main(argv):
    parser = setup_parser("Test LQI")
    parser.add_argument("-n", "--nwk", type=str, required=True)

    args = parser.parse_args(argv)

    for tx_power in range(0, 20 + 1, 5):
        await test_network(args.serial, tx_power=tx_power, nwk=int(args.nwk, 16))

if __name__ == "__main__":
    asyncio.run(main(sys.argv[1:]))  # pragma: no cover

It'll print the LQI in each direction if you search through the logs:

$ python test_network.py /dev/serial/by-id/... --nwk=C85C
...
2021-12-27 22:23:49.055 ubuntu __main__ CRITICAL [tx_power=0] LQI from coordinator to device: 129
2021-12-27 22:23:49.056 ubuntu __main__ CRITICAL [tx_power=0] LQI from device to coordinator: 109
...
2021-12-27 22:23:54.395 ubuntu __main__ CRITICAL [tx_power=5] LQI from coordinator to device: 140
2021-12-27 22:23:54.395 ubuntu __main__ CRITICAL [tx_power=5] LQI from device to coordinator: 112
...
2021-12-27 22:24:00.351 ubuntu __main__ CRITICAL [tx_power=10] LQI from coordinator to device: 163
2021-12-27 22:24:00.352 ubuntu __main__ CRITICAL [tx_power=10] LQI from device to coordinator: 116
...
2021-12-27 22:24:05.662 ubuntu __main__ CRITICAL [tx_power=15] LQI from coordinator to device: 182
2021-12-27 22:24:05.663 ubuntu __main__ CRITICAL [tx_power=15] LQI from device to coordinator: 112
...
2021-12-27 22:24:11.186 ubuntu __main__ CRITICAL [tx_power=20] LQI from coordinator to device: 201
2021-12-27 22:24:11.187 ubuntu __main__ CRITICAL [tx_power=20] LQI from device to coordinator: 109
...

It works for me with the unmodified 20211217 build on my CC1352P so I suspect either there's a bug with the Sonoff build or the topology scan didn't run after you restarted ZHA.

[puddly]

See my response in the Z-Stack issue: https://github.com/Koenkk/Z-Stack-firmware/issues/323#issuecomment-1001797561. I can verify that the TX power setting takes effect so while the LQI may not increase, the transmit power does.

[diginfo]

@tannisroot Give this script try with a router that is in range of the coordinator: It works for me with the unmodified 20211217 build on my CC1352P so I suspect either there's a bug with the Sonoff build or the topology scan didn't run after you restarted ZHA. When I run it, it crashes:

zigbee python3 scan.py /dev/ttyUSB0 -n 17BE
2022-10-21 22:53:24.669 a0d7b954-ssh zigpy.device INFO [0x0000] Requesting 'Node Descriptor'
2022-10-21 22:53:24.683 a0d7b954-ssh zigpy.device INFO [0x0000] Got Node Descriptor: NodeDescriptor(logical_type=<LogicalType.Coordinator: 0>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice|AlternatePanCoordinator: 143>, manufacturer_code=0, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=11265, maximum_outgoing_transfer_size=160, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=True, *is_coordinator=True, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=False, *is_security_capable=False)
2022-10-21 22:53:24.683 a0d7b954-ssh zigpy.device INFO [0x0000] Discovering endpoints
2022-10-21 22:53:24.694 a0d7b954-ssh zigpy.device INFO [0x0000] Discovered endpoints: [2, 1]
2022-10-21 22:53:24.695 a0d7b954-ssh zigpy.device INFO [0x0000] Initializing endpoints [<Endpoint id=2 in=[] out=[] status=<Status.NEW: 0>>, <Endpoint id=1 in=[] out=[] status=<Status.NEW: 0>>]
2022-10-21 22:53:24.695 a0d7b954-ssh zigpy.endpoint INFO [0x0000:2] Discovering endpoint information
2022-10-21 22:53:24.708 a0d7b954-ssh zigpy.endpoint INFO [0x0000:2] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=2, profile=49246, device_type=2080, device_version=0, input_clusters=[0], output_clusters=[])
2022-10-21 22:53:24.708 a0d7b954-ssh zigpy.endpoint INFO [0x0000:1] Discovering endpoint information
2022-10-21 22:53:24.724 a0d7b954-ssh zigpy.endpoint INFO [0x0000:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=1024, device_version=0, input_clusters=[0, 6, 10, 25, 1281], output_clusters=[1, 32, 1280, 1282])
2022-10-21 22:53:24.724 a0d7b954-ssh zigpy.device INFO [0x0000] Already have model and manufacturer info
2022-10-21 22:53:24.724 a0d7b954-ssh zigpy.device INFO [0x0000] Discovered basic device information for <ZNPCoordinator model='CC1352/CC2652, Z-Stack 3.30+ (build 20220928)' manuf='Texas Instruments' nwk=0x0000 ieee=00:12:4b:00:25:e1:60:69 is_initialized=True>
2022-10-21 22:53:24.724 a0d7b954-ssh zigpy_znp.zigbee.application WARNING Your network is using the insecure Zigbee2MQTT network key!
2022-10-21 22:53:24.724 a0d7b954-ssh zigpy_znp.zigbee.application INFO Permitting joins for 0 seconds
2022-10-21 22:53:24.775 a0d7b954-ssh zigpy.application WARNING Received relays from an unknown device: 0x17BE
2022-10-21 22:53:24.775 a0d7b954-ssh zigpy.application WARNING Unknown device AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x17BE)
Traceback (most recent call last):
  File "/config/pac/bash/zigbee/scan.py", line 57, in <module>
    asyncio.run(main(sys.argv[1:]))  # pragma: no cover
  File "/usr/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in run_until_complete
    return future.result()
  File "/config/pac/bash/zigbee/scan.py", line 53, in main
    await test_network(args.serial, tx_power=tx_power, nwk=int(args.nwk, 16))
  File "/config/pac/bash/zigbee/scan.py", line 22, in test_network
    device = await app._get_or_discover_device(nwk=nwk)
AttributeError: 'ControllerApplication' object has no attribute '_get_or_discover_device'