• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 57 subscribers
  • Views 1265 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2530ZNP ~10ms delay between router sending and coordinator receiving message. Can I speed this up?

Frank Boschker
Prodigy 40 points
Other Parts Discussed in Thread: Z-STACK, TIMAC, CC2530, MSP430F5438, CC2520

Hi all,

I have a CC2530ZNP router and coordinator (basic comms - AFZDO) set up and want to measure the minimal time from sender to receiver. I noticed that it takes approximately 10ms between sending a  message and receiving it. Also I want the interval of consecutive messages to be in the 5ms range.

In short:

- what is the delay between sending and receiving messages (latency) and

- what is the minimal time interval between messages (max frequency)?

 

Digging through the files I found a note saying:

"On a coordinator in a trivial test setup, it takes approximately 10mSec from sending AF_DATA_REQUEST to when we receive AF_DATA_CONFIRM."

 

So, is it possible to speed this up or is it inherrent to the protocol used in the Zigbee stack. If so, can I alter this and how?

(settings used are: manual polling (poll_rate = 0), spi bus freq = 4MHz)

  • 0
    Mastermind 9802 points

    It's inherent in Zigbee - when sending the transmitter must wake up, listen to see if the channel is busy, and then transmit the packet. One way to make it go faster is to send bursts instead. Instead of sending two bytes every 5mSec, send 40 bytes every 100mSec.

     

    --Derek

  • 0
    TI__Mastermind 19350 points

    I was a little disappointed to see the 10 msec latency - actually I was incredulous and set out to replicate the observation. So I installed the ZAP-MSP430-1.0.3 and compiled the sample apps for HA light and switch and put a little toggle of the P8.5 (easily found on the EXP5438 running the CC2530ZNP by SPI) when the switch sent the toggle command to the ZNP and when the light received the ZCL callback, and sure enough, it was a 10-12 msec lag on an otherwise clear channel! I suspected the ZCL overhead, so I used that test endpoint (static endPointDesc_t sampleSw_TestEp) and filled it in with a real simple descriptor that is just copy and paste from GenericApp so that I could invoke AF_DataRequest() on the ZAP switch host and bypass ZCL stuff ... but I got the measured the same latency on the scope.

    So I compiled the MSP5438 builds of the GenericApp from the Z-Stack 2.4.0 and added a similar toggle of P8.5 and the scope timed the latency at only a little more than 4 msec.

    Thus, even directly running on the Z-Stack incurs almost the maximum latency that you are looking for - so what will happen on a noisy channel and/or when more than 1 hop is involved? Even a simple application on the TIMAC might not be able to promise a message every 5 msec no matter what the channel conditions - 802.15.4 is very polite. So can the network work be accomplished differently, as Derek suggests?

    Finally, it would be interesting to know what is the end-to-end latency for a simple 1-hop unicast on the ZNP Mini-kit - I am guessing that it will fall in the middle of the two measurements above.

     

     

  • 0 in reply to Dirty Harry
    TI__Mastermind 19350 points

    I wasn't comparing apples to apples ... I went back to the experiment on the 2.4.0 build of the CC2530 GenericApp target, and got a simple, 1-hop unicast latency of 9.5-11 msec which is now right in-line with the MSP5438 host to CC2530ZNP latency of 10-12 msec - the ZNP interface only adds about 0.5 msec on either end.

    So in conclusion, it looks like if you want fast messaging or high OA throughput, you might not want to use the CC253x family (which are 8051-based SOC's) but the MSP430F5438 to CC2520. Also, there is a 3-chip ZNP solution available if you need this speed and ZNP - an MSP430F5438 (or similar) host talking by UART/SPI to a ZNP built for a second MSP430F5438-to-CC2520.

  • 0 in reply to Dirty Harry
    Prodigy 40 points

    Thank you guys for the quick response, really helpful!

     

    What Derek proposed also crossed my mind, but the thing is, I want to send triggers over the air via a wireless communication protocol. After investigation of the different possibilities, I chose Zigbee, mainly due to its low latency compared to Bluetooth. Sadly, the event handling ruines the latency.

    The triggers are the messages sent over the air. They should be fast (<5ms) and can have a frequency of 200Hz. Sending a burst will no give you proper triggering. I could, however, send a message with the information about the "to be send" trigger. The receiver then interprets this and constructs the trigger itself.

     

    The remark about that the latency is mainly due to the device waking up raises some questions. What I observed was that when I send a message the SRDY  goes from high to low for 1ms and returns to high again. Right at that moment the sendmessage() command is issued and it takes about 6ms before the waitformessage() command is send (again the SRDY shortly goes low). Then the confirm message is received and the sender is ready to repeat the loop, taking up a total of about 10ms. What is bothering me is the time it takes between the sendmessage() and waitformessage(). Apparently is the receiver (coordinator) takes a long time to give the "line" free for the trasmitter (router) to use. The conformation on the other hand is fast (immediate response). What is happening inside the chip before stuff can be send? Is there a meeting going on before they deside to grant the send request? ;)

     

    I will investigate this some more. Keep this thread alive, and spam me with helpful inputs/insights! Thanks in advance.

     

    Frank

  • 0 in reply to Frank Boschker
    Prodigy 195 points

    Hey everybody,

    I happen to face the same problem. I also want to minimize the latency between sender and receiver.

    I wasn't yet able to dig deeper into the Z-stack but is there absolutely no way to slim down the Z-stack to a minimum or bypass some routines since I actually do not really need the network functionality all the time? I've got just one sender that frequently streams its data to the receiver and that as fast as possible without any acknowledgement.

    Since the 802.15.4 standard actually specifies each coordinator device to realise "Guaranteed Time Slots" (GTS) which should be way below 10mSec (e.g. with the 15mSec beacon mode) I was wondering why a simple A to B message needs that long.

    Furthermore I'm also a little bit confused about the beacon mode implementation if there's any. While the source code (application_configuration.h) gives the opportunity to choose from 3 different beacon modes (0-no,1-fast,2-slow) for 'afRegisterGenericApplication()' the 'CC2530-ZNP Interface Specification (SWRA312)' says on page 42 ' For ZigBee the only applicable value is 0.' So why is that?

     

  • 0 in reply to Frank Thomas
    TI__Mastermind 19350 points

    You would bypass the NWK/APS layer of the Z-Stack by interacting directly with ZMAC modules and function calls. You will have to add your own code to zmac_cb.c to intercept incoming messages when you are in some one-hop, rapid messaging mode.

    The A-to-B message time being discussed is Application layer on A to Application layer on B and that is why it is different for different speed processors running the Z-Stack. The OA (over-the-air) message is compact and tight, since it is driven by the same 802.15.4 radio. Thus, the TIMAC meets GTS deadlines on any platform supported.

    The Z-Stack, upon which the ZNP is built, does not support beacon mode - only the TIMAC does.