CC2652P: Low temperature test problem

Hi senjin,

What version of SimpleLink F2 CC13XX/CC26XX SDK are you using to perform this test (7.41.00.17 if I recall correctly)?  Can this be recreated with default Zigbee examples (on/off commands for example), does the packet interval affect behavior, and does the issue occur when using a ZR instead of a non-sleepy ZED?  Does this happen when using either the default TX output (<5 dBm) or high PA is enabled (>5 dBm), and for any specific IEEE channels?

senjin said:

put the equipment into the programmable temperature test box, set the temperature at-40 degrees Celsius, start the test box, and start the data test immediately. When the temperature drops to-15 to-30 degrees Celsius, the data transmission quality of ZC and ZED becomes worse, and the connection is finally disconnected.

I want to emphasize that if I wait for the temperature to drop to -20, -30, or-40 Celsius degrees,  then start sending the data, this problem does not occur.

What consists of the "data test"?  Is this Zigbee network commissioning as well, and what Z-Stack API are used to send data?

Regards,
Ryan

Hi  Ryan,

1, SDK: simplelink_cc13xx_cc26xx_sdk_7_41_00_17

2, The zb example does not have the transparent transfer function I need and I cannot use the example to test.

3, The packet interval not affect behavior, I tries to increase the interval to 100ms, and is still fail.

4, Using ZR instead of ZED,  it also failed

5, Set tx power to 0dbm, or 20dmb, failed again.

6, Use different channels, not yet, will be feedback tomorrow.

7, the "data test" has 6 bytes of zcl payload, the fisrt 4 bytes are unsigned int type, used as serial number, the receiver through the serial number, to determine whether there is a packet loss,  and calculate how many packets are sent. The remaining two bytes, also serial numbers, are of the unsigned char type.

8, send API: zclGeneral_SendTransportCmd(), The software logic is to take a packet as a unit, when sending data, save the data in a buffer, and then in app _ loop(), take a packet of data from the buffer and send it. Wait for the the result, and then send the next packet of data.

The sent result obtained via "case zstackmsg_CmdIDs_AF_DATA_CONFIRM_IND” in fuction zclSampleSw_processZStackMsgs().

Thanks Senjin.  Based on your description I imagine that the behavior can be replicated simply by sending any Zigbee packets, such as on/off ZCL commands, and that frequent messages are not critical (i.e. could be at intervals on the scale of seconds).  It helps to know that sleepy devices or the high PA are not critical towards causing the problem.

I will try to replicate this behavior locally.  What I still don't understand is how starting to send data at -20 to -40 degrees Celsius does not cause the issue ,but starting at room temperature and decreasing to -40 degrees Celsius will.  Is this related to the time at which you power on or commission the device?

What is the procedure for recovering the device?  Does the device recover and rejoin if you bring the board back up to temperature without any hardware/software reset?  Is the device application in a crashed state at this point or can you confirm that the application is still running but not sending/receiving any Zigbee packets?  When using a sniffer log does it appear that transmission, reception, or both is affected on the device (i.e. are there any MAC ACKs or OTA signs of life from the device)?

Regards,
Ryan

Ryan, today, I picked a new channel 25, tested again, but still failed, the channel I used was 11.

step
1. Put the end-device and coordinator into the programmable temperature box, power up the two device, and the end-device and coordinator send data to each other. There is only one end-device in the network.
2. Set the target temperature of the programmable temperature box to -40 ° C and start to cool down.

When I test, I send the data from the host computer to the zigbee module through the serial port, and then the zigbee module passes the data to another zigbee module, and the other party receives it, and then the data passes the data to the host computer. Normally, a packet of data is 64 bytes, but when tested at high and low temperatures, the packet size shrinks to 6 bytes. 

When the problem occurs, in most cases, the end device and the coordinator are still running, and I can observe the state light flashing, indicating that the data is received from the serial port. when  the end device drops off the network,  it will try rejoin regularly, but failed every time, unless the coordinator is restarted, then the rejoin success.

In a few cases, the coordinator crashed, and I observed that the state light is out all the time, and the data is sent to it through the serial port with no reaction. I think that after the device was restarted, it did not start normally.

During the above test, the temperature is kept low. After the temperature rises, whether it can recover, I will reply to you tomorrow.

About sniff log related questions, I will also reply to you tomorrow.

Hi Senjin,

I was able to recreate your observations.  I don't believe that the F2 device variant is important at this point.

• Using default CC2652RSIP and CC1352P7-4 LaunchPads in either ZC or ZR roles
• The CC1352P7 is inside the temp chamber and CC2652RSIP is outside of the chamber
• After commissioning and starting the devices at room temperature, the temp chamber would be configured for -40 °C
• Regardless of whether the CC1352P7 was a ZC or ZR, it would eventually fail to communicate at around -30 to -40 °C
• The UART interface is still active at this time, so the application is still operational
• The device could be reset at this point and would rejoin/restart the Zigbee network at -40 °C
• One time the test was started with the CC1352P7 at -10 °C and the device seemed to do fine at -40 °C under this condition
• If I remove the CC1352P7 out of the -40 °C temp chamber condition without resetting the device, it will recover Zigbee communication after warming up.

I am sharing this information with HW and R&D Teams to get their thoughts on the behavior.

Regards,
Ryan