Need Z-Stack 3.x.0 coordinator firmware capable of +10 dBm and +20 dBm output power on CC2652P and CC1352P based radio modules

[Hedda]

Request Z-Stack 3.x.0 coordinator firmware capable of Active mode TX at +10 dBm and +20 dBm RF output power on CC2652P and CC1352P based radios. Specifically request firmware preconfigured with 10 dBm transmit power as default as well as firmware preconfigured with 20 dBm transmit power working as default for example the new Sonoff Zigbee 3.0 USB Dongle Plus adapter by ITead.

Maybe maximum dBm transmission power for 2.4GHz Zigbee devices is different for FCC (North America) and CE (Western Europe) but sounds as if 10 dBm is the legal limit when a manufacturer is shipping commercially sold 2.4GHz Zigbee device products:

"The power output of the XBee-PRO RF Modules must not exceed 10 dBm. The power level is set using the PL command. The International Variant of this product is internally limited to 10 dBm." Though it should be noted that is specifically for a commercially sold product.

https://www.digi.com/resources/documentation/Digidocs/90000991/reference/r_certs_xb_europe.htm

However not sure if that same 10dBm transmission power limit applies to DIY devices and individual hobbyist who flash their own custom firmware as ETSI EN 300 328 V2.2.2 standard specification documentation states this:

"The RF output power for non-FHSS equipment shall be equal to or less than 20 dBm." which I can be interpreted that even 20 dBm is OK as long as the device does not rapidly change the carrier frequency among many distinct frequencies occupying a large spectral band.

https://www.etsi.org/deliver/etsi_en/300300_300399/300328/02.02.02_60/en_300328v020202p.pdf

Anyway, CC2652P and CC1352P do have an integrated power amplifier capable of 20 dBm output power, but currently, applications like Zigbee2MQTT and IoBroker (as well as zigpy based applications like the ZHA integration in Home Assistant and Jeedom Zigbee Plugin) can not utilize higher than 5 dBm amplification even if they enable it in their software (configuring transmit power setting to 20) since this configuration is hardcoded in firmware configuration before compiling and there is not yet a Koenkk community firmware for C2652P and CC1352P based Zigbee coordinator adapters/dongles with a higher transmit power configured.

The issue is that to be able to actually use 10dBm or 20dBm output TX power we need to flash a firmware that either allows it to be configured via software or separate firmware builds with different hardcoded default config for desired transmission power.

Btw, maybe also a good idea to update both README.md files with information about utilizing integrated power amplifiers?

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/README.md

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/bin/README.md

FYI, this was brought up in this discussion about capability and testing of new SONOFF Zigbee 3.0 USB Dongle Plus adapter:

https://github.com/Koenkk/zigbee2mqtt/discussions/8840

Originally posted by @chiakikato in https://github.com/Koenkk/zigbee2mqtt/discussions/8840#discussioncomment-1545985

I got two SBDongle and wrote CC1352P2_CC2652P_launchpad_coordinator_20210708. But two of them performance is almost same or a little bit worth to zzh! which say 5dBm.

I wonder if there are extra settings other than experimental: transmit_power: 20

or anything I can check?

Originally posted by @chiakikato in https://github.com/Koenkk/zigbee2mqtt/discussions/8840#discussioncomment-1549977

My test method is using TI Packet Sniffer to monitoring the zigbee signal RSSI. I confirmed setting 'transmit_power:' as 5 and above till 20 won't make difference on RSSI values. Of course, checked below 5 to get smaller RSSI result. Besides, I checked SONOFF dongle's RF switch control signal by oscilloscope. It looks no activity which means no 20dBm PA signal is not used.

I wonder the firmware is not compatible with SONOFF dongle.
I can see https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin mentioned the RF switch control pin part marked '?' now.

Originally posted by @chiakikato in https://github.com/Koenkk/zigbee2mqtt/discussions/8840#discussioncomment-1550021

I check the trace of SONOFF. DIO_29: 20dBm PA is connected. but DIO_28: is N.C. it uses PE4259 or compatible's SC-70 6P RF switch which does not have 3 RF signals input for 2.4GHz 5dBm, 2.4GHz 20dBm and SubGHz.
I think it is a reason DIO_28 is not connected.

Originally posted by @chiakikato in https://github.com/Koenkk/zigbee2mqtt/discussions/8840#discussioncomment-1550148

I set RF switch control as HIGH by external hardwired method and got -22~-19dBm worth result. It means the firmware's RF switch control has no problem. SONOFF RF antenna and/or RF circuit need to be doubted.

[Hedda]

FYI, Koenkk confirmed that the current +5 dBm confirmation is not a hardware limitation but a setting when building firmware:

Thus current power amplification confirmation if the firmware is the same with 5 dBm for both CC2652R/CC2652RB and CC2652P, therefore, you will currently not see any performance difference between any CC26x2.

Koenkk said that he will likely make a +9 dBm firmware (or +9.61 dbm firmware) for CC2652P so that they will still be both legal to use out-of-the-box and ITead can get FCC and/or CE certified (FCC and CE regulations compliance and certification according to ETSI EN 300 328 V2.2.2 standard specification for licence-free short-range devices operating on 2.4Ghz unlicensed bands).

https://github.com/Koenkk/zigbee2mqtt/discussions/9744

Configuring the firmware with +20 dBm is technically not harder as just a firmware configuration but it would make it illegal to use in most countries or at least not allow for getting the commercial product FCC and/or CE certified due to international restrictions set on transmission power on the 2.4 GHz frequency band by commercial devices.

Technically I believe that we as individuals might still be allowed to flash a Zigbee coordinator firmware configured to 20 dBm transmission amplification power to own CC2652P or CC1352P based product that we already purchased, it is just that ITead are now allowed to legally sell a CC2652P or CC1352P based commercial product that ship with a pre-configured firmware that uses 20 dBm transmission amplification power to users most countries that follow ETSI regulations.

[Shamshala]

Would be nice to get the feature of power setting anyway and just implement a notice in the zigbee2mqtt that anything above 9.61dBm is illegal, instead of hardwiring it into firmware.

I get the idea and problem behind this but I just hate these babysitting stereotypes...

[Hedda]

Would be nice to get the feature of power setting anyway and just implement a notice in the zigbee2mqtt that anything above 9.61dBm is illegal, instead of hardwiring it into firmware.

+1 Though alternatively that could be solved by the community by offering several different firmware images which only difference would transmit power dBm configuration, and then offer easy to use OTW flashing of all those via Zigbee2MQTT's UI.

FYI, Koenkk's Z-Stack-firmware repository recently added JSON file with index (index.json) of available/compatible firmware for each board and maybe that could be extended to add more versions of each firmware for each board(?):

https://github.com/Koenkk/Z-Stack-firmware/blob/master/index.json

https://github.com/Koenkk/Z-Stack-firmware/issues/310

By the way, technical terminology wording is that it is "hardcoded" in the firmware (as it is not "hardwired" the hardware).

Again, technically it will still be relatively easy to reflash the adapter with another firmware even if it ships with firmware that has hardcoded 9 dBm. The configuration is still only stored in the application firmware and not in the hardware.

[Hedda]

@guozi7788 Do you happen to have any inside news about ITead's testing of firmware with new default transmit power of 9dbm?

[Merwenus]

Doesn't the default firmware has a maximum of 30 devices?

[Hedda]

Doesn't the default firmware has a maximum of 30 devices?

Limitations on amount of direct children devices (devices connected directly to coordinator) are not related to this specific issue request in any way. This issue request is for firmware images with a higher RF output power output amplification transmission, as in the radio sending out a stronger signal when transmitting. This RF output power is measured in dBm or dBmW (decibel-milliwatts) is a unit of level used to indicate that a power level is expressed in decibels (dB) with a reference to one milliwatt (mW). Changing the dBm level configuration for RF output power does not affect limitations on connected direct children or any other configurations or limitations.

Please instead start new separate issue for unrelated issues (like bugs or configuration limitations that can be could potentially be changed) or better yet if you just have general questions then post in -> https://github.com/Koenkk/zigbee2mqtt/discussions

PS: See current configuration limitations -> https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/README.md

[guozi7788]

@Hedda We have modified the tx power table in our ZNP project to make it configurable between 6-20dbm.

Then we will synchronize the tx power table to Koenkk .

[Hedda]

We have modified the tx power table in our ZNP project to make it configurable between 6-20dbm.

Then we will synchronize the tx power table to Koenkk .

OK so the TX power output level will in the future be able to configurable in dBm for CC2652P via a software applications like Zigbee2MQTT, Home Assistant's ZHA integration and Jeedom's official Zigbee plugin (via zigpy-znp), and thus there should be no need for Koenkk to make separate firmware images woth different variants RF output power having fixed hardcoded dBm levels?

[guozi7788]

@Hedda The TX power can be configured through ZNP's SYS_SET_TX_POWER command. If software applications provide users with this interface, then the user can configure the TX power of CC2652P..

Since the ZNP firmware maked by Koenkk adapts to a variety of hardware, it may be necessary to distinguish in the firmware whether the current hardware supports 20dBm.

At 2021-12-16 20:42:57, "Hedda" @.***> wrote:

We have modified the tx power table in our ZNP project to make it configurable between 6-20dbm.

Then we will synchronize the tx power table to Koenkk .

OK so the TX power output level will in the future be able to configurable in dBm for CC2652P via a software applications like Zigbee2MQTT, Home Assistant's ZHA integration and Jeedom's official Zigbee plugin (via zigpy-znp), and thus there should be no need for Koenkk to make separate firmware images woth different variants RF output power having fixed hardcoded dBm levels?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[Hedda]

FYI, Koenkk has now uploaded an experimental firmware for CC2652P/CC1352P with a default set to 9 dBm (and a max of 20 dBm):

https://github.com/Koenkk/zigbee2mqtt/files/7728605/CC1352P_CC2652P_TX_POWER.zip

He mentions in https://github.com/Koenkk/zigbee2mqtt/issues/8885 that he does not have RF measurement equipment so cannot confirm RF output power.

Since the ZNP firmware maked by Koenkk adapts to a variety of hardware, it may be necessary to distinguish in the firmware whether the current hardware supports 20dBm.

All CC1352P and CC2652P hardware does support a maximum 20 dBm so those should all be able to use the same firmware, at least as long as the Zigbee adapter/module hardware are using the same pins, but that does not depend on TX power output, see:

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/bin/README.md

[ruimarinho]

What is the effect of tx_power on https://github.com/zigpy/zigpy-znp with and without this firmware?

[Hedda]

What is the effect of tx_power on https://github.com/zigpy/zigpy-znp with and without this firmware?

As it says, now 9 dBm TX power by default on CC2652P and CC1352P based dongle but it is configurable up to 20 dBm TX power.

@puddly Looking at zigpy-znp configuration example it sounds like if 19 dBm might be the highest can set for CC2652/CC1352?

https://github.com/zigpy/zigpy-znp/blob/dev/README.md#configuration

zha:
  zigpy_config:
    znp_config:
      tx_power: 19

Without this firmware and instead using master from this repo is set to only 5 dBm TX power and is not configurable via software.

[ruimarinho]

That’s precisely my question - with the current stable - because I’m almost certain the software configuration did manage to improve range in my case (almost double LQI).

[Hedda]

That’s precisely my question - with the current stable - because I’m almost certain the software configuretion did manage to improve range in my case (almost double LQI).

Placebo effect? All the other discussions and tests say the opposite. As I understand, with the current stable firmware release from the master branch (and even the latest in the develop branch) any changes to transmission power output will not be applied. See:

https://github.com/Koenkk/zigbee2mqtt/issues/8885

https://github.com/Koenkk/zigbee2mqtt/discussions/8840

https://community.home-assistant.io/t/sonoff-zigbee-3-0-usb-dongle-plus-by-itead-is-based-on-texas-instruments-cc2652p-can-be-pre-ordered-for-10-99/340705/

Maybe @chiakikato and/or perhaps @sjorge might have the right RF measurement equipment to verify RF output power now?

[sjorge]

I certainly don't have such equipment, not sure who might... perhaps @omerk as he has some very cool testing stuff for his zzh boards.

[Hedda]

@notenoughtech Do you Mat have any measuring equipment that could test TX power output on CC2652P dongle antenna port? Know that you are one of the first to discover this issue with a CC2652P dongle not performing any better than a CC2652R dongle:

NotEnoughTech's review of Sonoff CC2652P https://notenoughtech.com/home-automation/sonoff-zigbee-3-0-usb-dongle-plus/

(Mat also wrote -> https://notenoughtech.com/home-automation/testing-9-external-antennas-with-cc2531-zigbee-coordinator/ )

The RF output power is measured in dBm or dBmW (decibel-milliwatts) but is a unit of level used to indicate that a power level is expressed in decibels (dB) with a reference to one milliwatt (mW), so I guess it should be possible to just measure it in milliwatt, or?

https://www.electronicdesign.com/technologies/communications/article/21796484/understanding-wireless-range-calculations

https://www.controleng.com/articles/radio-math/

[notenoughtech]

Sadly I don't. For me the range and transfer wasn't as much of an issue. Just pairing. It would either pair or ignore pairing requests.

I'm yet to try the latest launchpad firmware. Work took over experiments and I'll do that over Xmas.

On Thu, 16 Dec 2021, 17:27 Hedda, @.***> wrote:

@notenoughtech https://github.com/notenoughtech Do you Mat have any measuring equipment that could test TX power output on CC2652P dongle antenna port? I know that you are one of the first to discover this issue with a CC2652P dongle not performing any better than a CC2652R dongle:

https://notenoughtech.com/home-automation/sonoff-zigbee-3-0-usb-dongle-plus/

This RF output power is measured in dBm or dBmW (decibel-milliwatts) is a unit of level used to indicate that a power level is expressed in decibels (dB) with a reference to one milliwatt (mW) so I guess it should be possible to just measure it in milliwatt?

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/Z-Stack-firmware/issues/323#issuecomment-996026722, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDRL2Y3NV7TGXRORYJXFDDURIOQXANCNFSM5HGBE2RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[omerk]

@sjorge I do have the equipment (used for development/testing of all @electrolama projects) and verifying that the transmit_power config option does what it should is on my "things to do when I find the time" list.

Measuring continuous TX power is very easy as TI's SmartRF Studio has the tools to put the radios into the correct mode but of course z2m does not work that way. To generate enough traffic to observe TX power, my idea is to set up a demo system and perform OTA upgrade on a device and capture ("max hold") the RF power observed on my spectrum analyzer. If anyone has a better test setup proposal, I'd be keen to hear about it.

I will say this though: There appears to be quite the confusion w.r.t to PA output power. This is not only a chip/firmware setting, the RF BOM should also match the reference design from TI depending on what power levels the hardware is targetting. TI has three reference designs for CC1352P/CC2652P, if you compare the RF balun/matching/filtering on the schematics you'll notice that they differ quite a bit:

• LAUNCHXL-CC1352P1: 868/915 MHz up to 20 dBm, 2.4 GHz up to 5 dBm - ignore for 2.4GHz PA use
• LAUNCHXL-CC1352P-2*: 868/915 MHz up to 14 dBm, 2.4 GHz up to 20 dBm - "+20dBm"
• LAUNCHXL-CC1352P-4*: 433 MHz up to 14 dBm, 2.4 GHz up to 10 dBm - "+10dBm"

(You'll also notice that these are all CC1352P based, CC2652P is essentially the same chip as CC1352P without the sub-GHz radio and TI does not have separate CC2652P based designs for this reason)

Why have +10dBm and +20dBm? Because if you care about compliance (specifically: ETSI EN 300 328 but other standards apply as well) you will find that max. power spectral density becomes a problem with settings over +10dBm or so (depending on what antenna will be used etc, there are a few factors that affect this figure).

Now, with regards to reports of "I increased transmit_power yet nothing happened/things got worse" -- welcome to the world of RF! You can't just increase power and expect things to get better as you need your radio hardware (including eveything else that sits between the chip and the antenna) and antenna to work properly, in unison. This is where the whole "which RF BOM does this board use?" thing becomes relevant.

I don't mean to turn this into a pitch but to highlight the importance of hardware: here's a sneak peek at the RF section of zzhp, utilising 0201 caps and inductors on a super tight layout for the best possible performance: (ballpoint pen tip for scale) Unlike (most low speed) digital circuits, size and layout matters a lot for RF circuits especially if you're keen to push the PA to its max output power.

[sjorge]

Now, with regards to reports of "I increased transmit_power yet nothing happened/things got worse" -- welcome to the world of RF! You can't just increase power and expect things to get better as you need your radio hardware (including eveything else that sits between the chip and the antenna) and antenna to work properly, in unison. This is where the whole "which RF BOM does this board use?" thing becomes relevant.

That reminds me, just increasing the coordinator's power might make a device that was out of range before hear it. But that doesn't mean the device can send a reply that the coordinator can hear.

Although tweaking hardware component/device to keep the noise they add on the receiving end as low as possible, just increasing power is not gonna make any difference for that direction.

Edit: Ooh the design of zzhp seems to have evolved a lot since last I saw! Exciting.

[io53]

I've only dabbled in the RF voodoo world, so I might not be correct. But I've understood that antenna is KEY to get good signals going.

Wouldn't a high quality antenna improve the LQ more than just cranking the power? I've been planning to do some non-scientific test with this one, when/if time and motivation strikes at the same time.

[Hedda]

Sadly I don't. For me the range and transfer wasn't as much of an issue. Just pairing. It would either pair or ignore pairing requests.

@notenoughtech I think for pairing problems it is most often not an issue of transmission power signal strength sent from the Zigbee Coordinator radio adapter + its antenna) but instead more often rather and the issue of signal reception capability of Zigbee Coordinator radio adapter + its antenna.

This is because signal reception quality plays a bigger role in why Zigbee coordinator adapters are so sensitive to electromagnetic interference (EMI), also called radio-frequency interference (RFI), and the reason why simply using a long USB extension cable and getting your Zigbee coordinator adapter as far as possible away from any electronic devices/appliances and their electrical cables/wires as possible will have a larger impact on LQI (Link Quality Indicator) and RSSI (Received Signal Strength Indication) values for Zigbee devices than only replacing the Zigbee Coordinator adapter with another model/type.

Location and orientation of the Zigbee Coordinator radio adapter + its antenna are really the key factors there to get improved signal reception, (other than proper hardware design + a good omnidirectional 2.4GHz antenna made for the purpose of course).

My guess is also that setting the TX power to 9 or 14 (and not to 19 or 20) will produce the best LQI and RSSI for CC2652P/CC1352P based adapters. The reason for that prediction is that the higher TX power is then the more its own transmission is also interfering with its own reception capability, as transmitting higher power will produce more signal noise.

Wouldn't a high quality antenna improve the LQ more than just cranking the power?

Yes. LQI and RSSI values indication of radio receiver sensitivity antenna gain (i.e. reception only and not transmission). So to achieve improved reception on your existing Zigbee Coordinator finding a better antenna for it and placing that antenna in a more optimation location and orientation should improve your LQI and RSSI values.

Note that if your radio board does not have proper electromagnetic shielding then it would probably be best to also use a short SMA antenna extension cable in addition to the USB extension cable to get the antenna away from the radio board as well.

[Arakon]

I've only dabbled in the RF voodoo world, so I might not be correct. But I've understood that antenna is KEY to get good signals going.

Wouldn't a high quality antenna improve the LQ more than just cranking the power? I've been planning to do some non-scientific test with this one, when/if time and motivation strikes at the same time.

For this to work, all the devices would also need a polarised antenna like this. Otherwise, you actually lose quality. Source: I've been using these kind of antennas in the past for quadcopter flying. What CAN help is using higher DB antennas of the same type (they're generally longer).

[notenoughtech]

I'd agree with you if not for the following:

• I'm aware of the cross talk and used usb extension cord kept the coordinator away.
• WIFI and ZigBee are on the opposite ends of the channel spectrum in my setup
• same device would pair a device A but not B while cc2531 had no issues in the same spot with devices A and B
• batteries with voltage over 3.1V were used (tested with multi meter)

Can't say I have the answers but at least I was logical in my approach 🤭🤭

On Fri, 17 Dec 2021, 08:24 Hedda, @.***> wrote:

Sadly I don't. For me the range and transfer wasn't as much of an issue. Just pairing. It would either pair or ignore pairing requests.

@notenoughtech https://github.com/notenoughtech I think for pairing problems it is most often not an issue of transmission power signal strength sent from the Zigbee Coordinator radio adapter + its antenna) but instead more often rather and the issue of signal reception capability of Zigbee Coordinator radio adapter + its antenna. It is because signal reception quality plays a bigger role why Zigbee coordinator adapters is so sensitive to electromagnetic interference (EMI), also called radio-frequency interference (RFI), and the reason why simply using a long USB extension cable and getting your Zigbee coordinator adapter as far as possible away from any electronic devices/appliances and their electrical cables/wires as possible will have a larger impact on LQI (Link Quality Indicator) and RSSI (Received Signal Strength Indication) values for Zigbee devices than only replacing the Zigbee Coordinator adapter with another model/type. Location and orientation of the Zigbee Coordinator radio adapter + its antenna are really the key factors there to get improved signal reception.

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/Z-Stack-firmware/issues/323#issuecomment-996526554, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDRL25FQIGINOZODTJ6IOTURLXVXANCNFSM5HGBE2RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[Hedda]

BTW, recommend hobbyist enthusiasts interested in inexpensive RF testing equipment tools to check out these two blog articles:

https://tinkerman.cat/post/rf-power-monitoring-tools-on-the-cheap/

https://tinkerman.cat/post/analyze-your-antennas-using-an-aai-n1201sa/

[notenoughtech]

I'll check it out. Since I'm about to kick off my overly complicated ZigBee heating... I may need it 😆😆

On Fri, 17 Dec 2021, 08:48 Hedda, @.***> wrote:

BTW, recommend hobbyist enthusiasts interested in inexpensive RF testing equipment tools check out these two blog articles:

https://tinkerman.cat/post/rf-power-monitoring-tools-on-the-cheap/

https://tinkerman.cat/post/analyze-your-antennas-using-an-aai-n1201sa/

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/Z-Stack-firmware/issues/323#issuecomment-996540238, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDRL237HFF4U6QISXSOV53URL2N7ANCNFSM5HGBE2RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[chiakikato]

Thanks to Koenkk and all other persons involve this issue. Here is my initial test result. I can see SONOFF stick working with over 5dBm performance.

With CC1352P2_CC2652P_launchpad_coordinator_20210708 firmware: LQI 36, RSSI -73dBm With Experiential CC1352P2_CC2652P_launchpad_coordinator_TX_POWER firmware: setting of transmit power: 5 LQI 39, RSSI -72dBm (This is tolerance with old firmware. i.e. same.) as above : 9 LQI 78, RSSI -58dBm
as above : 20 LQI 92, RSSI -52dBm

My test/measurement method is using TI's Packet Sniffer Ver 2.18.1 with TI's original CC2531 USB stick. as a sniffer Sniffer located 5meter away from SONOFF coordinator dongle.

I use channel 26 for this test to minimize other 2.4GHz radio signals. This test measured with zigbee2mqtt version 1.21.0

[Hedda]

With CC1352P2_CC2652P_launchpad_coordinator_20210708 firmware: LQI 36, RSSI -73dBm With Experiential CC1352P2_CC2652P_launchpad_coordinator_TX_POWER firmware: setting of transmit power: 5 LQI 39, RSSI -72dBm (This is tolerance with old firmware. i.e. same.) as above : 9 LQI 78, RSSI -58dBm as above : 20 LQI 92, RSSI -52dBm

Interesting, so my prediction that a 20 in transmit power would produce worse LQI and RSSI result did not hold true.

My guess is also that setting the TX power to 9 or 14 (and not to 19 or 20) will produce the best LQI and RSSI for CC2652P/CC1352P based adapters. The reason for that prediction is that the higher TX power is then the more its own transmission is also interfering with its own reception capability, as transmitting higher power will produce more signal noise.

@chiakikato Could you maybe for comparison do a quick test with 14 in transmit power using the exact same setup?

[digiblur]

@notenoughtech Do you Mat have any measuring equipment that could test TX power output on CC2652P dongle antenna port? Know that you are one of the first to discover this issue with a CC2652P dongle not performing any better than a CC2652R dongle:

NotEnoughTech's review of Sonoff CC2652P https://notenoughtech.com/home-automation/sonoff-zigbee-3-0-usb-dongle-plus/

(Mat also wrote -> https://notenoughtech.com/home-automation/testing-9-external-antennas-with-cc2531-zigbee-coordinator/ )

The RF output power is measured in dBm or dBmW (decibel-milliwatts) but is a unit of level used to indicate that a power level is expressed in decibels (dB) with a reference to one milliwatt (mW), so I guess it should be possible to just measure it in milliwatt, or?

https://www.electronicdesign.com/technologies/communications/article/21796484/understanding-wireless-range-calculations

https://www.controleng.com/articles/radio-math/

I actually found jumping from the CC2652R to the CC2652P iTead one made a difference in LQI a bit. But to be honest, it all gets irrelevant with a decent mesh of devices which to be honest is pretty damn simple with a couple $5 smart plugs to even jump across the yard to a neighbor's house. I am curious to see if actually increasing power causes more issues much like I've seen with adding higher gain antennas to things from creating the donut effect, raising the noise floor, to now devices being able to hear the coordinator but they are too weak to talk back to it.

[zen2]

Interesting, so my prediction that a 20 in transmit power would produce worse LQI and RSSI result did not hold true.

It think your prediction could be true depending on coordinator type. I use a TI CC1352P-2 dev board and you need to sold a resistor to use an external antenna. So by default, on this board, you use the internal antenna present on PCB and I presume that in this case your prediction could be true. In case I can make the test by using my old CC2531 as a sniffer.

@Hedda How do you proceed to check TX power and LQI ?

[Koenkk]

Firmware 20211217 allow settings the transmit power > 5dBm (9dBm by default), ITEAD (Sonoff) confirmed this is working (using a RF analyzer). Link: https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

[Merwenus]

Does update for Itead 3.0 Plus looks like the original firmware install? Or do I have to do something else too? Read somewhere that this thing need extra care but no idea if it is only for the dev firmwares or the stable too?

[Koenkk]

@Merwenus not sure what you mean, just flash and go 😄 (it of course needs to be tested for some time which I'm already doing for a day now, you can always revert to another firmware)

[digiblur]

Any router firmware capable of these outputs? @Koenkk

[chiakikato]

@Hedda, Here is the result.

I compared with SONOFF with experimental CC1352P2_CC2652P_launchpad_coordinator_TX_POWER, SONOFF with 20210708 and zzh! Sorry, I don't have enough skill to post the graph. Instead, I post CSV format. Copy and paste in Excel to see better image.

,SONOFF(new),,,SONOFF(new),,,zzh!, Setting,LQI,RSSI(dBm),,LQI,RSSI(dBm),,LQI,RSSI(dBm) 20,94,-51,,39,-72,,, 19,94,-51,,,,,, 18,92,-52,,,,,, 17,86,-54,,,,,, 16,89,-53,,,,,, 15,89,-53,,34,-74,,, 14,78,-56,,,,,, 13,84,-55,,,,,, 12,84,-55,,34,-74,,, 11,78,-57,,34,-74,,, 10,76,-58,,42,-71,,, 9,73,-59,,39,-72,,, 8,63,-63,,39,-72,,, 7,63,-63,,28,-76,,, 6,63,-63,,31,-75,,55,-66 5,42,-71,,31,-75,,, 4,39,-72,,28,-76,,, 3,31,-75,,28,-76,,, 2,26,-77,,26,-77,,, 1,21,-79,,23,-78,,, 0,13,-82,,21,-79,,39,-72 -1,18,-80,,,,,, -2,21,-79,,,,,, -3,23,-78,,,,,, -4,5,-85,,,,,, -5,0,-88,,5,-85,,, -6,0,-88,,,,,, -7,0,-93,,,,,, -8,0,-96,,,,,, -9,0,-88,,,,,, -10,0,-93,,0,-88,,,

With CC1352P2_CC2652P_launchpad_coordinator_20210708 firmware: LQI 36, RSSI -73dBm With Experiential CC1352P2_CC2652P_launchpad_coordinator_TX_POWER firmware: setting of transmit power: 5 LQI 39, RSSI -72dBm (This is tolerance with old firmware. i.e. same.) as above : 9 LQI 78, RSSI -58dBm as above : 20 LQI 92, RSSI -52dBm

Interesting, so my prediction that a 20 in transmit power would produce worse LQI and RSSI result did not hold true.

My guess is also that setting the TX power to 9 or 14 (and not to 19 or 20) will produce the best LQI and RSSI for CC2652P/CC1352P based adapters. The reason for that prediction is that the higher TX power is then the more its own transmission is also interfering with its own reception capability, as transmitting higher power will produce more signal noise.

@chiakikato Could you maybe for comparison do a quick test with 14 in transmit power using the exact same setup?

[tteck]

I use channel 26 for this test to minimize other 2.4GHz radio signals.

I thought channel 26 was low power?

[Koenkk]

@digiblur will update router fw later

[chiakikato]

I use channel 26 for this test to minimize other 2.4GHz radio signals.

I thought channel 26 was low power? Channel 26 is less chance of interference with WiFi signal as below link band chart.

https://img.community.ui.com/5f743aa0-9c43-44fb-8889-afd9eccba833/comments/d1ae2c9e-9162-47e2-abcc-12e54862b200/82ccb020-c270-45fc-995c-f837ada4f9c3

[codmpm]

Thanks @Hedda for pointing me to this. As there are other modules using the "RF-star CC2652P2" module, this should be applicable there also.

As a test setup I've used an innr wall socket and a 2.5dBi antenna connected to the cc2652 raspberry pi module which are aproximately 1.2m appart.

Zigbee2MQTT:info  2021-12-18 11:28:08: Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20210708,"transportrev":2},"type":"zStack3x0"}'

Gets me around 120-132 LQI.

Updated the firmware to 20211217 and got 162-172 LQI - nice! Obviously the "default" change of tx_power did do something.

Zigbee2MQTT:info  2021-12-18 11:36:05: Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20211217,"transportrev":2},"type":"zStack3x0"}'

But contrary to that, the transmission_power setting did nothing for me:

Zigbee2MQTT:info  2021-12-18 11:39:00: Set transmit power to '5'
163-174 LQI

Zigbee2MQTT:info  2021-12-18 11:40:54: Set transmit power to '10'
161-173 LQI

Zigbee2MQTT:info  2021-12-18 11:41:51: Set transmit power to '20'
162-173 LQI

I'm on Zigbee2MQTT version 1.21.0 (commit #70891eec) - do I need to update? Or is my module missing som external connections to get this to work? Happy to test and help where I can. Please point me in the right direction if I've missed something or had to test in another way.

Keep it up! Best Patrik

//update: Seems that 20211217 does not work reliably. Can't switch the socket anymore after 5-10 minutes without communication. No transmission_power set on this test.

Zigbee2MQTT:error 2021-12-18 12:04:04: Publish 'set' 'state' to '0x60a423fffe88148b' failed: 'Error: Command 0x60a423fffe88148b/1 genOnOff.off({}, {"sendWhenActive":false,"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 62205 - 1 - 19 - 6 - 11 after 10000ms)'
Zigbee2MQTT:info  2021-12-18 12:04:04: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'state' to '0x60a423fffe88148b' failed: 'Error: Command 0x60a423fffe88148b/1 genOnOff.off({}, {\"sendWhenActive\":false,\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":false,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Timeout - 62205 - 1 - 19 - 6 - 11 after 10000ms)'","meta":{"friendly_name":"0x60a423fffe88148b"},"type":"zigbee_publish_error"}'

Re-pairing the socket made it work again. Restarting zigbee2mqtt did not help.

[tteck]

I use channel 26 for this test to minimize other 2.4GHz radio signals.

I thought channel 26 was low power? Channel 26 is less chance of interference with WiFi signal as below link band chart.

https://img.community.ui.com/5f743aa0-9c43-44fb-8889-afd9eccba833/comments/d1ae2c9e-9162-47e2-abcc-12e54862b200/82ccb020-c270-45fc-995c-f837ada4f9c3

Yeah, I understand that. I was referencing that channel 26 is a "low power channel" that may have skewed the findings (which are unreadable) that you reached.

[chiakikato]

I use channel 26 for this test to minimize other 2.4GHz radio signals.

I thought channel 26 was low power? Channel 26 is less chance of interference with WiFi signal as below link band chart.

https://img.community.ui.com/5f743aa0-9c43-44fb-8889-afd9eccba833/comments/d1ae2c9e-9162-47e2-abcc-12e54862b200/82ccb020-c270-45fc-995c-f837ada4f9c3

Yeah, I understand that. I was referencing that channel 26 is a "low power channel" that may have skewed the findings (which are unreadable) that you reached.

@tteck Thank you. I just know ch25 and 26‘s regulation. I’ll test again.

[ruimarinho]

@Koenkk does this now mean setting TX power via API call will actually set the desired gain? In my case, via https://github.com/zigpy/zigpy-znp/blob/074f33f3832697828bb905d12a547b4b5bf564aa/zigpy_znp/commands/sys.py#L414-L426.

[Koenkk]

@ruimarinho yes

[Hedda]

Any router firmware capable of these outputs?

FYI, submitted a separate feature request for Zigbee router firmware with remotely configurable TX power output level -> #341

[Ey3scr34m]

Firmware 20211217 allow settings the transmit power > 5dBm (9dBm by default), ITEAD (Sonoff) confirmed this is working (using a RF analyzer). Link: https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

Has anything changed between CC1352P2_CC2652P_launchpad_coordinator_20211217.hex and CC1352P2_CC2652P_launchpad_coordinator_TX_POWER.hex which you posted before for testing purposes?

And what do I need to configure in configuration.yaml or inside ZHA itself to get the +20 dBm?

I tried:

zha:
  zigpy_config:
    tx_power: 19

But I can't see any gains on LQI.

Thanks for you work and any help is appreciated! :)

[ruimarinho]

@Ey3scr34m I think you'd ought to be doing this instead:

zha:
  zigpy_config:
    znp_config:
      tx_power: 19

However, I don't see any improvement either independently of how high or low I set tx_power to.

[Hedda]

Has anything changed between CC1352P2_CC2652P_launchpad_coordinator_20211217.hex and CC1352P2_CC2652P_launchpad_coordinator_TX_POWER.hex which you posted before for testing purposes?

Yes and no, that depends which exact version dates you are referring to for comparison, so see changelog and its commit history:

https://github.com/Koenkk/Z-Stack-firmware/blob/develop/coordinator/Z-Stack_3.x.0/CHANGELOG.md

and

https://github.com/Koenkk/Z-Stack-firmware/commits/develop/coordinator/Z-Stack_3.x.0/CHANGELOG.md

Summery:

• Z-Stack 3.x.0 20210708 firmware image is based on Texas Instruments SimpleLink 5.10.00.48 so contain upstream fixes as well.
• Z-Stack_3.x.0 20211114 firmware image is based on Texas Instruments SimpleLink 5.30.00.56 so contain upstream fixes as well.
• Z-Stack 3.x.0 20211207 firmware image is based on Texas Instruments SimpleLink 5.30.01.01 so contain upstream fixes as well.
• Z-Stack_3.x.0 20211217 firmware image is based on Texas Instruments SimpleLink 5.30.01.01 and only added 20 dBm support.

[Hedda]

I don't see any improvement either independently of how high or low I set tx_power to.

Maybe report to https://github.com/home-assistant/core/issues and https://github.com/zigpy/zigpy-znp/issues for zha/znp devs?

[ruimarinho]

@Hedda yep, reported and cross-linked the issue to this thread.

[chiakikato]

I use channel 26 for this test to minimize other 2.4GHz radio signals.

I thought channel 26 was low power? Channel 26 is less chance of interference with WiFi signal as below link band chart.

https://img.community.ui.com/5f743aa0-9c43-44fb-8889-afd9eccba833/comments/d1ae2c9e-9162-47e2-abcc-12e54862b200/82ccb020-c270-45fc-995c-f837ada4f9c3

Yeah, I understand that. I was referencing that channel 26 is a "low power channel" that may have skewed the findings (which are unreadable) that you reached.

@tteck Thank you. I just know ch25 and 26‘s regulation. I’ll test again.

Here is my test results. I tested with zzh! with 20211217 firmware, SONOFF with 20210708 and 21211217 firmware with CH11 and CH26 settings.

This test result (I tested more than these) shows a. SONOFF 20211217 performs much power than its 20210708 and zzh! 20211217. b. CH11 and CH26 has no difference on both 20211217 firmware.

[sintei]

@digiblur will update router fw later

@digiblur , any progress?