• Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 556 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.

RFD Performance

Zaphod
Prodigy 155 points


Hello,

I need to have a moblie device connected to a Laptop, and obviously the trivial way is to use an endpoint and not a Router (since an endpoint is supposed to be mobile by nature). Low power consumption, needless to say, is not the driver for using an endpoint in this case (since it is connected to a Laptop).

All tests I performed indicate there is huge latency (1-4 seconds for a message to get sent from the endpoint once a button is pressed) when the device is registered as an endpoint. When I do the same thing on a device registered as a Router I get excellent performance - nearly instantly the messge gets sent.

 I tried various ZCD_NV_POLL_RATE / ZCD_NV_QUEUED_POLL_RATE / ZCD_NV_RESPONSE_POLL_RATE configurations (for example 100ms, 50ms, 50ms respectively), yet in vain - the latency is still the same.

 Does anyone know if this is what could be expected from an endpoint? or there is a way to significantly improve its performance? (I'm looking for a performance similar to a Router - well below 1 second to send out a data packet)?

Thanks in advance,

Zaphod.

  • TI__Mastermind 19535 points

     Hi Zaphod,

     Check out the following Application Note. This can help you understand. 

     AN057 – Measuring Power Consumption on eZ430-RF2480

    This document will present power consumption measurements and battery lifetime calculations based on the hardware and software in the eZ430-RF2480 Demonstration Kit.

    PDF Download .pdf (swra177.pdf, 456 Kbytes)

    Download associated code files (swra177.zip, 11 Kbytes)

    LRPF Rocks the world 

  • in reply to Morten Braathen
    Prodigy 155 points

    Thanks Rocks,

    I read through, but either I missed the point or the answer is not there. I am referring to the time it takes for a ZED to send out a packet (and not poll for incoming data), or in other words - the time it takes from the moment of the ZED packet tx and until the receiving device indicates data packet rx.

    In the document it says "... Turning it on (APP ACKS) will change things quite a bit, since the active period will look quite different. In this case, the end device will have to request the acknowledgement packet from the receiver after having transmitted the packet. It must also wait to send the request until the recipient has actually received the packet."

    This is perfectly understood, and we don't really mind if the ZED has to wait longer to request the ACK, only the time it takes for it to shoot out the message. This is the point - we can clearly see that it takes a long time (sometimes 3-4 seconds) for a packet to exit the ZED.

    So why is an endpoint taking so much time to simply initiate a packet transfer? If it is related to wake-up time - then again it should happen fast since CC2480 boasts at its fast sleep-to-wake switch time?

    Thanks again,

    Zaphod.