CC1352P: Transmit Power during Joining Process

Bill Kuckuk

Part Number: CC1352P
Other Parts Discussed in Thread: SIMPLELINK-CC13X2-26X2-SDK

I’ve got a quick question on the Tx Power. We are monitoring pMacPib->phyTransmitPower through a back-end serial interface and just noticed that it is reporting 5dBm while the line-powered Router is attempting to join a Zigbee network and it is sending Beacon Requests. Once it joins the network, it goes back up to 20dBm.

We haven’t instrumented the device to see if it is actually sending the Beacon Requests at this low level, but would like to know if this is an expected default behavior. If it is expected, is there a way to override it?

Thanks,

- Bill

over 3 years ago

0 Ryan Brown1 over 3 years ago

TI__Guru**** 202106 points

Hey Bill,

Thanks for letting us know about this behavior. Have you used ZMacSetTransmitPower((ZMacTransmitPower_t)TXPOWER); in stackInit of zstackstartup.c? What value is returned if you use ZMacGetReq(ZMacPhyTransmitPowerSigned, (byte *) &savedTXPower);? You may also consider changing the macPibDefaults -> phyTransmitPower in mac_cfg.c from 5 to 20 and let us know whether this alters your observations.

Regards,
Ryan

0 Bill Kuckuk over 3 years ago in reply to Ryan Brown1

Expert 1305 points

Hey Ryan,

Thanks for the quick response. I got the same 5dBm result by using the ZMacSetTransmitPower() rather than pMacPib->phyTransmitPower .

But changing macPibDefaults -> phyTransmitPower in mac_cfg.c from 5 to 20 now does indicate 20.

So this means that the Router is beaconing at 5dBm? Is there Zigbee requirement to do this?

- Bill

0 Bill Kuckuk over 3 years ago in reply to Bill Kuckuk

Expert 1305 points

Couple more questions.

Is the Router running at this reduced power through the entire Association process?

Can I programmatically change this value? To support multiple country requirements we need to change the MaxTxPower to meet the governing agency requirements. We need to be able to do this from one binary image, so changing the hard-coded default isn't going to work for us.

If this wasn't a Zigbee requirement and just a miss, would you advise joining at a reduced power from the active TX Max?

- Bill

0 Ryan Brown1 over 3 years ago in reply to Bill Kuckuk

TI__Guru**** 202106 points

Hi Bill,

Are you able to evaluate this setup with a spectrum analyzer to actually confirm the output TX power? If you set the transmit power to less than 5, would the serial interface still report 5 dBm? This is not a Zigbee requirement and I will need to work with the 15.4-Stack Team to determine whether this is an issue with the IEEE MAC layer.

Regards,
Ryan

0 Bill Kuckuk over 3 years ago in reply to Ryan Brown1

Expert 1305 points

When I set the default to 1, it then reports out 1 dBm on the serial interface.

It may take a couple of days to get into the lab to test this out on an analyzer. We'll let you know the results.

0 Ryan Brown1 over 3 years ago in reply to Bill Kuckuk

TI__Guru**** 202106 points

That's an interesting finding Bill, thanks for sharing. It appears that the normal 2.4 GHZ RF output is being used instead of the 20 dBm high PA option. If you physically removed the 2.4 GHz path on your board, would the device fail to send Beacon Requests? There could be some error which causes rfDriverCallback to not take effect until the device joins a network. Also, can I replicate this behavior with a default TI project and is the same behavior apparent on the v4.40 SIMPLELINK-CC13X2-26X2-SDK (I believe you are evaluating v4.10 currently)?

Regards,
Ryan

0 Bill Kuckuk over 3 years ago in reply to Ryan Brown1

Expert 1305 points

Hey Ryan,

I did some more testing and this now appears to be just a stack reporting issue. I found that the stack continues to report the default value (using ZMacSetTransmitPower() or pMacPib->phyTransmitPower) before and after joining a PAN. However, after joining a PAN, restarting and doing an NV_RESTORE the stack does report the correct TxPower.value.

We're still going to test this in the lab, but we haven't seen any issues with devices joining a network at long distances so I'm suspecting that the stack is using the correct value.

For now we can change our serial interface use the Tx Power we're commanding the stack to use rather than the value that the stack is telling us its using.

Again, we'll let you know the results of our analyzer test.

- Bill

0 Ryan Brown1 over 3 years ago in reply to Bill Kuckuk

TI__Guru**** 202106 points

Hi Bill,

Thanks for the additional information, this would definitely imply that the reported value depends on the restoration of NV memory which was saved before the restart. I'll close this thread for now but please let me know if your tests contradict the current assumption.

Regards,
Ryan

0 Ryan Brown1 over 3 years ago in reply to Bill Kuckuk

TI__Guru**** 202106 points

Hey Bill,

The Software Development Team was able to recreate this issue. NLME_ResetRequest from bdb_reportCommissioningState (bdb.c, line 1873), called during network commissioning, maps to ZMacReset (zmac.c) which will call MAP_MAC_MlmeResetReq and reset all PIB values (including tx power) to the stack defaults. A factory reset is required at this point in the code, but shouldn't reset the MAC PIB. I will let you know when a proposed workaround is available.

Regards,
Ryan

0 YiKai Chen over 3 years ago in reply to Ryan Brown1

Guru 735455 points

Want to get solution for this issue too.

0 Ryan Brown1 over 3 years ago in reply to YiKai Chen

TI__Guru**** 202106 points

Hi YK,

I will certainly update this thread with the recommended solution as soon as possible.

Regards,
Ryan

0 Bill Kuckuk over 2 years ago in reply to Ryan Brown1

Expert 1305 points

Hey Ryan,

Just to close this out, we ended up calling Zstackapi_sysSetTxPowerReq() with the desired TxPower before each attempt at calling Zstackapi_bdbStartCommissioningReq() with commissioning_mode = BDB_COMMISSIONING_MODE_NWK_STEERING;

So if the Router (and I'm guessing an End Device) fails to join the PAN on the first attempt, the TxPower will be reset before the second and subsequent attempts. Once on the network, the TxPower remains at the correct value and correctly restores on a power cycle.

- Bill

0 Ryan Brown1 over 2 years ago in reply to Bill Kuckuk

TI__Guru**** 202106 points

Thanks for the update Bill!

Regards,
Ryan

0 YiKai Chen over 2 years ago in reply to Ryan Brown1

Guru 735455 points

Ryan Brown1 Will TI provide formal patch or fix for this issue?

0 Ryan Brown1 over 2 years ago in reply to YiKai Chen

TI__Guru**** 202106 points

The issue is committed to be fixed for the v5.20 SDK and I will share more information when it becomes available.

Regards,
Ryan

0 YiKai Chen over 2 years ago in reply to Ryan Brown1

Guru 735455 points

Ryan Brown1 Thanks for the information.

Zigbee & Thread

Zigbee & Thread forum

CC1352P: Transmit Power during Joining Process