• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 360 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652P: Packet loss when zigbee transmission speed is high

Galaxy Yue
Prodigy 540 points
Part Number: CC2652P

Hi Team，

Note: This is a question about zigbee. Since the forum selection box only has "bluetooth forum" as an option, it is classified into the Bluetooth forum.

simplelink_cc13xx_cc26xx_sdk_6_40_00_13

Application scenario: a coordinator and a sub-device, used as a transparent transmission module.

Test rate: Send one packet of data every 30ms, zcl payload carries 64 bytes of data.

During the test, packet loss was discovered.

The printed LOG on the sending end shows that all the data was sent successfully and there was no packet loss.

Use the packet capture tool to capture the packet and verify that it was indeed sent successfully.

Therefore, it is determined that packet loss occurred at the receiving end. In the function void afIncomingData(...), add log printout and confirm through LOG that the packet is lost.

The serial port baud rate during my test was 230400bps.

I also tried to shield the serial port output of the receiving end to optimize the timeliness of CPU operation,

but there were still packet losses (although the data was not output from the serial port,

but the internal MCU The data will be detected, the data changes regularly, and LOG will be printed when abnormal).

1. According to my testing, the data was lost in the underlying protocol stack of the receiver, the function void afIncomingData(...) did not receive relevant information, and the next layer is not open source, so I cannot analyze it here. Can you help analyze the source code and see if it can be optimized?

2. Do you know how much the relevant customers can achieve when using the transparent transmission function?

Best Regards，

Galaxy

  • 0
    TI__Prodigy 540 points

    Hi Team，

    One additional point: the sub-device RxonWhenIdle has been set to true, and there is no problem of packet loss due to device sleep. Moreover, whether the sub-device sends to the coordinator or the coordinator sends to the sub-device, under the conditions of 30ms per packet and 64 bytes per packet, packets will be lost. If set to 50ms per packet and 64 bytes per packet, it is normal.

    Best Regards，

    Galaxy

  • 0 in reply to Galaxy Yue
    TI__Mastermind 31050 points

    Hi,

    Can you share the sniffer log?

    What is the purpose of the testing? Is it for RF regulatory compliance?

    If yes, I recommend to use SmartRF Studio 7 to perform such tests. Use packet TX and packet RX.

    What is the end application? Is such a high data throughput truly required?
    I ask this, because Zigbee is meant for a low power, low datarate (i.e throughput) network.

    Thanks,
    Toby

  • 0 in reply to Toby P
    TI__Prodigy 540 points

    Hi Toby，

    1. The log has been added.

    2. The purpose of the test is that if the project has requirements, the transparent transmission rate must reach 2k bytes/s. I looked at the data packets. The application layer is 64 bytes + other data, a total of 112 bytes. Calculated by sending one packet in 30ms, per second. About 30kbps, which is already a big discount compared to the 250kbps rate of Zigbee. In theory, it is completely achievable.

    3. The project requirement is to meet the transmission rate based on the current protocol stack. It has been found to be related to the protocol stack. Please research and find out the reason. I think there is no need to use SmartRF Studio 7 for testing.

    7635.嗅探器日志.zip

    Best Regards，

    Galaxy

  • 0 in reply to Galaxy Yue
    TI__Guru**** 206977 points
    Galaxy Yue said:
    Therefore, it is determined that packet loss occurred at the receiving end. In the function void afIncomingData(...), add log printout and confirm through LOG that the packet is lost.

    Thank you for clarifying that packets are not lost over-the-air.  It is much more plausible that you are losing packets at the receiver due to bottleneck.

    Galaxy Yue said:
    About 30kbps, which is already a big discount compared to the 250kbps rate of Zigbee. In theory, it is completely achievable.

    This does not account for the limitations of the devices processing the packets.  At 48 MHz with 30 ms intervals, the CC2652P has 1440 cycles in between each incoming packet for MAC processing -> NWK processing -> APS processing -> application processing -> print out -> wait for the next packet and repeat.  

    Galaxy Yue said:
    If set to 50ms per packet and 64 bytes per packet, it is normal.

    Now the CC2652P has 2400 cycles for the process above, which is apparently sufficient.  Options to improve behavior include:

    • Increase the packet interval (more processing cycles in between packets) while also increasing the packet size (for more data bytes per packet, but keep in mind that the current packet is 112 bytes and the MAX_MAC_FRAME_SIZE is 127, so at max you are limited to 80 data bytes per packet)
    • Reduce or entirely remove print logs as they are overly taxing on the main core

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Prodigy 540 points

    Hi Ryan，

    My client made the following three question:

    1. You mentioned that "CC2652P has 2400 cycles for the above process, which is obviously enough." Since it is enough, why is packet loss happening? Do you want to check the problem instead of asking me to increase the sending interval?

    2. The improvement methods you mentioned include deleting logs and even canceling the output of transparent data from the serial port to avoid overburdening the MCU. As I said before, I have tried them all and there is no improvement.

    3. The improvement method you mentioned is to increase the data volume of a single packet by 80 bytes. This is a good method. I have also verified it, but the result is that if I transmit 64 bytes in a single packet and send it at an interval of 50ms, there will be no packet loss. , if I change to transmit 80 bytes per packet and send it at the same interval of 50ms, packets will be lost. So at present, it seems that the transparent transmission rate has not been significantly increased. It is recommended that you check why the receiving end of the protocol stack loses packets.

    Best Regards，

    Galaxy

  • 0 in reply to Galaxy Yue
    TI__Guru**** 206977 points

    1. "Obvious" meaning that 50 ms = 2400 cycles was sufficient according to the original message.

    2. If this was stated previously, it had not been sufficiently explained.  More details are necessary concerning how to determine that packets are being missed.

    3. Perhaps this too has been bottlenecked for the extra time it takes to receive and process the added bytes.  You would need to provide more tangible steps to reproduce the issue, including a detailed list of changes from the default SimpleLink Zigbee projects which are needed to recreate this behavior.  

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Prodigy 540 points

    Hi Ryan,

    I have turned off APS ACK, non-sleeping end device, rxOnWhenIdle is true.

    So can you help me to reduce packet loss when transparent transmission rate is high.

    Best Regards，

    Galaxy

  • 0 in reply to Ryan Brown1
    TI__Prodigy 540 points

    When more devices join the network at the same time, the network access notification messages are more likely to be lost. At the worst, 32 devices join the network at the same time, and the network access notifications of 15 devices are lost.

    Best Regards，

    Galaxy

  • +1 in reply to Galaxy Yue
    TI__Guru**** 206977 points

    Hi Galaxy, 

    You would be able to increase buffer sizes, such as NWK_MAX_DATABUFS_* in nwk_globals.c and MAC_CFG_* in *_cnf.opts, but this would only delay the eventual packet reception failure.  Ultimately the packet throughput capabilities are too high, especially with multiple devices joining, and must be diminished to give the CPU time to further process incoming data.  You should also stagger device joins, possibly by delaying the join time of powered-on devices between a randomized zero to ten seconds, so that the ZC TC does not have to handle multiple requests simultaneously.  I can offer no further advice or assistance on this topic.

    Regards,
    Ryan