2652P Coordinators ignore 'transmit_power' settings

[OlsiIgitt]

What happened?

I tested two different Zigbee Gateways (see below) with the newest coordinator firmware. I wanted to increase the RF power to 20 dBm, but all my PIR sensors reported a low link quality correspondig to the setting 'transmit_power: 5', probably. For experiments I tried several settings of transmit_power: -20 ... +20. The results were always identical! Z2M debug log reports my settings as stated, but the coordinators seem to ignore these settings. When I compare link quality results with my Conbee II stick, the the signals are lower by a factor of 3 or so for my Sonoff & Zigstar sticks. So my conclusion is: Operation power is 5 dBm for my ZStack devices (Conbee manufactures states 10 dBm).

What did you expect to happen?

Different settings of 'transmit_power' should result in different gateway signal strengths. Following the discussions related to this issue from September to December last year, I thaught that this problem should no longer exist, right?

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.25.0

Adapter firmware version

CC1352P2_CC2652P_launchpad_coordinator_20220219

Adapter

Zigbee 3.0 USB Dongle Plus & ZigStar LAN Gateway

Debug log

No response

[Koenkk]

Increasing the transmit power won't increasing the linkquality of devices aka you can shout harder but it won't make your ears better.

[OlsiIgitt]

Hi Koen, it seems that you do not take me very seriously, since you closed the thread so quickly.

aka you can shout harder but it won't make your ears better.

That is certainly correct; but YOU can hear me better when I shout louder. And the PIR devices don't report about the ear capabilities of the coordinator gateway, but rather about it's own loudness perception. The louder I shout the longer the distances at which YOU to hear me! Logical, isn't it?

But let's go away from the Zigbee PIR sensors. Now follow the facts.

I have split an USB cable to measure the supply current of the sticks. Namely Texas Instruments states for the CC2652P that the supply current will increase from 9.6 mA for 5 dBm up to 85 mA for +20 dBm. This large difference can be measured easily by current measurement - and we are away from the auxiliary measuremnt of the PIR devices!

Here are my test results: 1) Sonoff Zigbee 3.0 USB dongle with setting 'transmit_power: 5': Current from USB supply = 26.5 mA 2) Sonoff Zigbee 3.0 USB dongle with setting 'transmit_power: 20': Current from USB supply = 26.5 mA 3) Zigstar LAN Gateway with setting 'transmit_power: 5': Current from USB supply = 172 mA 4) Zigstar LAN Gateway with setting 'transmit_power: 20': Current from USB supply = 172 mA

As you can see, the results are identical for each stick, respectively. The setting of transmit_power has no influence on the RF radiation power, as I stated in this thread. This corresponds to my earlier observations with my PIR sensors.

I tested it out on: Windows 10 on a ZBox (Zotac) machine Windows 7 on a VM (VirtualBox on my main PC) Windows 10 on a VM (VirtualBox) Ubuntu 21.10 on a VM (VirtualBox) Always the same result!

I am desperate; no idea what the reason could be...

I want to try again on my laptop (Thinkpad x220); honestly, i don't expect any changes.

[Koenkk]

The transmit power setting has been verified by ITEAD using the official launchpad and a spectrum analyzer. Doc: FirmwarePowerVerification.pdf

@mercenaruss could it be something with the zigstar hardware?

[OlsiIgitt]

Thanks for reopening, and thanks for the link:

1) Is the firmware 'CC1352P2_CC2652P_launchpad_coordinator_TX_POWER.hex' identical with 'CC1352P2_CC2652P_launchpad_coordinator_20220219' regarding RF power?

2) Is this RF issue possibly a matter of hardware revision of the circuit board? My Sonoff stick says: 'Zigbee 3.0 USB Dongle Plus, 2021-07-29, V1.3'.

[Koenkk]

1. Yes, note that the default transmit power is 9dbm
2. I don't know, you should contact Sonoff about this.

[OlsiIgitt]

...

I want to try again on my laptop (Thinkpad x220); honestly, i don't expect any changes.

I have done it: Windows 7x64, node v12.22.4, ZigbeeMQTT v1.25.0, zigbee-herdsman 0.14.20. Clean installation without any problems; Connecting to the Sonoff coordinator without any problems... at the first go. Unfortunately, as expected, the result was the same: changing over transmit_power from 5 (default) to 20 resulted in no change of emitted RF power, again.

1. Yes, note that the default transmit power is 9dbm

May already be, but I am pretty sure that my sticks will only fire with 5 db, independent on the setting - default or not. This can be derived from a comparison with my Conbee II results (10 dBm).

I don't know, you should contact Sonoff about this.

I will try...

[OlsiIgitt]

Might be that I have found the reason for this issue? See my doc: CC2652P - PA-Bit in FCFG Registers.pdf

I riffled through the TI documentation 'Technical Reference Manual SWCU185E': I found that the PA-Bit (0x294) should set to 1 for having support of 20 dBm. -> page 1

(1) Then I read the content of my Sonoff stick, and found PA = 0 => No support of 20 dBm!!! -> page 2

(2) In next step I tried to set the PA bit, but had no success because of error "Erasing info page not supported via serial bootloader". -> page 3

Could it be that (1) is the reason why my sticks ignore the setting 'transmit_power: 20' in Z2M?

How to overcome problem (2)?

[Koenkk]

Interesting finding, I'm not sure if this field can be controlled by the FW. Here is the FW tested by Sonoff (default 9dbm), could you check it? CC1352P2_CC2652P_launchpad_coordinator_TX_POWER.hex.zip

[OlsiIgitt]

...

Here is the FW tested by Sonoff (default 9dbm), could you check it?

I did: Same result => no change of RF output signal with varying power parameter; and low RF signal (~5dBm ?). I read again the User_ID PA Bit (see picture); it_s still zero. This time with the TI info when hovering with the mouse over the User_ID field.

Can you do something with the information?

[Koenkk]

I searched a bit in the fw code but couldn't find where I can set this. Isn't this something readonly of the chip?

Just to be sure, can you provide me the herdsman debug logging when starting z2m so that I can verify that the transmit power is set?

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files.

[OlsiIgitt]

...

Just to be sure, can you provide me the herdsman debug logging when starting z2m so that I can verify that the transmit power is set?

In the normal log I could find entries like '.... set transmit_power: xx', with xx = 5, 20, etc. Does the herdsman log contain more information about power setting?

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable the herdsman debug logging.

How can I enable this logging in Windows???

[OlsiIgitt]

OK, I reactivated my Virtual Machine with Ubuntu again: Here is the standard log file: log.txt log.txt And here is the herdsman debug log file: herdsman debug.log

The question remains: How can I enable this logging in Windows???

[Koenkk]

For Windows this can be enabled by setting the appropriate environment variable. I've checked your logging and can confirm the transmit power is set:

Given that the firmware is fine (since ITEAD verified it using an RF analyser), it seems the hardware is the issue here.

[OlsiIgitt]

Is there anyone out there who has a Sonoff Zigbee 3.0 USB stick? And is sure that it will fire with high RF power of 20 dBm?

If yes, could you please read out the USER_ID byte 0x294 with SmartRF flasher from the info page (see screen shot above)?

[OlsiIgitt]

...

For Windows this can be enabled by setting the appropriate environment variable

I've searched all the docs, but didn't find anything about an "appropriate environment variable". I only found information for Linux and for HomeAssistant settings.

Can you please give me the name of that variable? And its setting value range? true / false? 1 / 0 ? set xxx = yyy ???

[Impact123]

In CMD you can use

set DEBUG=zigbee-herdsman*

in PowerShell you can use

$env:DEBUG='zigbee-herdsman*'

before running npm start

[OlsiIgitt]

...

I don't know, you should contact Sonoff about this.

I did it, started on 23th of April. The communication with Sonoff/Itead is very slow; until today there is no satisfactory answer for this issue.

Again: Is there anyone out there who has a Sonoff Zigbee 3.0 USB stick? And is sure that it will fire with high RF power of 20 dBm?

[GizmoBT]

You read PA the wrong way. 0x294 = 00 isn't the PA bit. If I remember my school lessons correctly, 0x294 = the bits 0 to 7 in the TI documentation. 0x295 = the bits 8 to 15, 0x296 = the bits 16 to 23 and 0x297 = the bits 24 to 31. PA is the bit 25. So in you're SmartRF, 0x297 = 32 in hexadecimal = 00110010 PG_REV (31 - 28) = 0011 VER (27 - 26) = 00 PA (25) = 1 RESERVED (24) = 0

The PA bit is set to 1.

[OlsiIgitt]

Did you find any indication anywhere in the document that the bit arrangement is inverted? uusually in a 32-bit arrangement of four bytes bit 0 is the lowest bit, i.e. "rightmost" and bit 31 is the highest bit, i.e. leftmost.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[OlsiIgitt]

I am still in contact with Sonoff/ITEAD; because of the vacation season it takes all the longer...

[OlsiIgitt]

I said earlier:

Did you find any indication anywhere in the document that the bit arrangement is inverted?

I contacted the TI E2E design support forum with that issue and got the hint that all instruction and data memory accesses are little endian (Section 2.4.4 of the TRM: https://www.ti.com/lit/swcu185).

@GizmoBT: So, you are right and I was wrong! Following the TI byte endianness, 0x32 in byte 0x297 means "PA bit = 1"; apologies for my error.

---

Furthermore, i learned in the forum from a TI expert:

"The CC2652P supports PA so the bit would read as one, the CC2652R does not support PA so the bit would be zero. It cannot be changed which is why the bit is read-only."

@Koenkk: So, we don't need to research in this direction anymore; the PA bit cannot be written, the PA bit is always set In CP2652P memory!

[OlsiIgitt]

No reaction from Sonoff, and Radu from ZigStar says: "firmware".

In the mean time I tried Z-Tool (from TI) and send "level = 20" via SYS_SET_TX_POWER" command to the Sonoff USB stick, but the result remains the same: The stick will not send with high RF power amplitude. It's output power is far below that of my Conbee II stick.

@Koenkk: It is curious that the same behavior can be observed with both sticks, the Sonoff stick and the Zigstar stick - i.e. from completely different manufacturers. The only thing both sticks have in common is that they run with firmware "CC1352P2_CC2652P_launchpad_coordinator_20220219". I have browsed a little in the TI documentation "CC2652P Technical Reference Manual" (https://www.ti.com/lit/swcu185). There I found interesting hints about the differences in the commands CMD_SET_TX_POWER (chapter 25.3.3.2.16) and CMD_SET_TX20_POWER (chapter 25.3.3.2.17): "It is not allowed to use CMD_SET_TX20_POWER if the 20 dBm PA was not configured in the radio setup command; in this case, CMD_SET_TX_POWER ... should be used." and vice versa. Has this statement been taken into account in the firmware?

[Koenkk]

@mercenaruss does the output power work correctly with your own firmware?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[mercenaruss]

@mercenaruss does the output power work correctly with your own firmware?

What will be correct procedure to test it? Of course from your point of view

You can test this 2 firmwares and let us know @OlsiIgitt CC1352P2_CC2652P_launchpad_coordinator_20220524.zip

This firmware have Default TX power: 20dBm. znp_CC1352P_RFS_20220302.zip

.

[OlsiIgitt]

What will be correct procedure to test it? Of course from your point of view

My opinion for the easiest test is:

1) Use a Zigbee sensor, e.g. a PIR, which reports the link quality (= signal amplitude/intensity). Place it several meters away from the coordinator.

2) Set RF transmit power to +10 dBm; note the reading of sensor link quality.

3) Set RF transmit power to +20 dBm; note the reading of sensor link quality.

4) Compare the readings of steps 2 and 3; is reading of 3 much higher than that of step 2? => All ok; are readings of 2 and 3 the same? Then there is the problem I described.

You can test this firmware @OlsiIgitt [CC1352P2_CC2652P_launchpad_coordinator_20220524.zip] (https://github.com/Koenkk/zigbee2mqtt/files/9298316/CC1352P2_CC2652P_launchpad_coordinator_20220524.zip)

Ok, I will test it in the next days...

[OlsiIgitt]

You can test this 2 firmwares and let us know @OlsiIgitt [CC1352P2_CC2652P_launchpad_coordinator_20220524.zip]

This package contains the file "firmware_20220524.patch". What shall I do with that?

[OlsiIgitt]

@mercenaruss

You can test this 2 firmwares and let us know @OlsiIgitt CC1352P2_CC2652P_launchpad_coordinator_20220524.zip

This firmware have Default TX power: 20dBm. znp_CC1352P_RFS_20220302.zip

I have tested both - and the newest version CC1352P2_CC2652P_launchpad_coordinator_20220726 as well.

No change!!!

The ZigStar USB stick will always send with the same RF amplitude - independently on the setting "transmit_power" in "advanced" section.

I have tested 2 settings "transmit_power: 0" and "transmit_power: 20" and compared the received "link quality" signals of my PIR sensors.

[OlsiIgitt]

What will be correct procedure to test it? Of course from your point of view

My opinion for the easiest is:

1) Use a Zigbee sensor, e.g. a PIR, which reports the link quality (= signal amplitude/intensity). Place it several meters away from the coordinator.

2) Set RF transmit power to +10 dBm; note the reading of sensor link quality.

3) Set RF transmit power to +20 dBm; note the reading of sensor link quality.

4) Compare the readings of steps #2 and #3; is reading of #3 much higher than that of step #2? => All ok! Are readings of #2 and #3 the same? Then there is the problem I described.

Am 10.08.22 um 10:39 schrieb Radu:

@mercenaruss does the output power work correctly with your own firmware? What will be correct procedure to test it? Of course from your point of view

You can test this firmware @OlsiIgitt CC1352P2_CC2652P_launchpad_coordinator_20220524.zip ..