• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 332 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.

CC2530: Zstack 3.0.2 loses RF frames

Joaquim Martinez
Expert 1245 points
Part Number: CC2530
Other Parts Discussed in Thread: CC2430, Z-STACK, SIMPLICITI, CC2538

Hi everybody,

I am using CC2530 with Zstack 3.0.2 for a project with several Routers and a single Coordinator. Normally they work alone (they are in movement), without RF communication between them, due to long distances, but sometimes they can work close one of each other. In order to join the network, each Router join it and they begin to work. Routers and Coordinators are always awake, and they never go to sleep. I have also End Devices, which are sending RF frames every 140ms under specific conditions. My problem is that Routers lose RF frames from ED. Please, refer to the attached image. Channel 1 and 2 are signals activated when ED send RF frames. Channel 3 is a toggle pin set in the MyApp_ProcessEvent( uint8 task_id, uint16 events ) -> SYS_EVENT_MSG event -> MSGpkt->hdr.event (afIncomingMSGPacket_t) -> AF_INCOMING_MSG_CMD event. Note Channel 3 is not toggled for more than 800ms, losing up to 5 frames. I atthache a sniffer capture of the ED frames.

ED setup is: CC2530, they don't use Zstack, they use BasicRF and the format frames are based on CC2430 ZStack-1.4.3-1.2.1 for compatibility, which works fine for a years. 

So my questions are:

1. Since ED setup is working fine with Routers based  on CC2430 ZStack-1.4.3-1.2.1, are there some incompatibility between ED and the Zstack 3.0.2 Zigbee PRO?

2. Is there any network param which is affecting Routers to lose frames?

3. I use some Osal Timers and I tried to disable all of them, because according to the second image there is some pattern when RF frames are lost, but he problem is still happening. 

Thanks.

Joaquim.

  • 0
    TI__Guru**** 202106 points

    Hi Joaquim,

    So all incoming packets are identical (except for perhaps the sequence numbers) yet some are being missed by the CC2530 ZC?  And Z-Stack 3.0.2 is capable of processing the packets which it is able to receive?  Based on this information it would appear that the Z-Stack CC2530 ZC is experiencing bottleneck from which it has exceeded its available RX buffer and misses packets while processing others.  The CC2530 is limited in RAM and there have been prior recommendations to stagger device joining (for example) as new Z-Stack 3.0 features create further overhead for the devices.  It does not help that messages are being broadcast every 140 ms, if you are able to limit this packet frequency to 1 second and can then accurately receive all messages then this confirms bottleneck with Z-Stack 3.0 and the CC2530.  

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1245 points

    Hi Ryan,

    Yes, al packets are identical and they are processed correctly. In my opinion, I think also there is some bottleneck. I increased the -DMAC_CGC_RX_MAX param (in f8wRouter.cfg file) from 5 to 10, but it didn't take effect. 

    I followed your recommendation to save RAM, but the problem already exists. 

    I can not increase the time to 1 second or more. I need a fast sending because the Routers are in movement. 

    I am considering to move to SimpliciTI or even MRFI, but I would like to continue with ZStack, because I would need to write my code almost from zero...

    Any idea about how can I do to process and do not lose any RF frame?

    Thanks.

    Joaquim.

  • 0 in reply to Joaquim Martinez
    TI__Guru**** 202106 points

    The recommendation to reduce packet interval was meant for testing to prove packet processing restrictions, not proposed as a long-term solution.  Due to the overhead involved with Z-Stack 3.0.2 you could try evaluating an older "simpler" solution from Z-STACK-ARCHIVE (HA or MESH for example).  Or if feasible then you could try to use a CC2538 or SimpleLink CC26X2 device instead.  Otherwise I do not have any further recommendations on how to accomplish this application with the CC2530 Z-Stack 3.0.2

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1245 points

    I already tried MESH, but the behaviour is the same. I'll look for others solutions. 

    Thank you very much for your help.

    Regards.

    Joaquim.

  • 0 in reply to Joaquim Martinez
    Expert 1245 points

    Hi Ryan,

    I found the problem and is not the Zstack, which can receive frames as faster as 70ms or more! 

    The problem is in the ED with Basic RF: when I build the frame to achieve the IEEE 802.15.4 Frame Format compatibility, the SeqNumber, and I don't know why exactly, is calculated as follows: SeqNumber = (SeqNumber + 1) % 10; is increased by 1 and the maximum allowed values is 9. This has alerted me, because in the sniffer this value stars from 0 to 255. So I changed the calculation to SeqNumber = (SeqNumber + 1) % 255; and no frames are lost! Please, refer to the attached image.

    Now, I well know that is not a ZStack problem, but as we have a lot of ED with this bug and is not possible to do a remote upgrade, I am debugging the ZStack 3.0.2 code in Routers and Coordinators, to investigate what is the condition which controls the SeqNumber so as to try to find the way to make some workaround, and how it affects to the frame acceptance or not. But the last called function, which I have access when a frame is received (I suppose it is called from Router-Pro.lib), is "afIncomingData" in the AF.c file. 

    In addition, I don't understand why this issue doesn't seem affect to CC2430 ZStack-1.4.3-1.2.1. How can affect a bad SeqNumber in the frame reception? 

    Please, could you help me to find some workaround for the SeqNumber issue? Is there any place in the Zstack where I can fix it?

    Many thanks.

    Joaquim.

  • 0 in reply to Joaquim Martinez
    TI__Guru**** 202106 points

    Hi Joaquim,

    Z-Stack has undergone several updates from 1.4.3-1.2.1 to 3.0.2 which most likely includes greater scrutiny and parsing of incoming packets based on sequence number.  Sequence numbers are processed from the pre-built Z-Stack libraries which are not accessible through the release version of Z-Stack.  I will message you separately for an alternative.

    Regards,
    Ryan