ANT Forum

I need to know a little bit more about the use case before I can assist.

How long is the device powered on or off?
How much data does it need to transmit/receive?
How often does it need to transmit/receive?
How much of the power draw is contributed from components other than the CC2571?
Idle current consumption of the CC2571 should be about 0.5uA, are you seeing much higher numbers than that?      

Thanks for your response, I will try to answer your questions:

The device is always off until the user press the button, at that moment from idle (cc2571) I try to send a "broadcastdata" as soon as possible (just make the channel open and it takes about 400-500ms).

Once push button, we are sending for 4 seconds at 20Hz. A total of 80 frames broadcasta.

Our low-power microcontroller is in sleep mode and consume only 0.3uA.

Right, I see 0.5uA into idle mode,

I would like to know the minimum response time once we left idle mode because we do not get less than 400-500ms, and our request is 10ms.

thank you very much      

How are you measuring time between channel open and the first message being broadcast? There should be some latency between the message being broadcast over the air and the EVENT_TX response.

There is only one setup which can possibly achieve such an aggressive latency target.

1) Your receiver must be in continuous scanning mode so it can asynchronously pick up all messages.

2) You must be using the fastest serial communications setting for your chosen implementation (57600 Baud UART or FAST SPI).

3) You must pre-configure your transmit channel before needing to open the channel, including the broadcast message you intend to send.

4) The speed at which you can open the channel is dependent upon the channel period, if you do not require bi-directional communication I would recommend using a TX-Only channel. This will allow you to open the channel initially with an extremely low channel period (~100-300 Hz). For power consumption you can then lower the channel period back to 20 Hz after the first broadcast.

5) Are each of those 80 broadcast frames different? Due to the nature of wireless, there is a strong likelihood of dropping some messages at the receiver end.

Using ANTware II and a C7 module on a USB board I will see from channel open to EVENT_TX at ~300 Hz channel period a ~15ms delay reported in the logs. This is higher than the actual latency due to the resolution at which the PC can timestamp messages, and the actual delay is much lower than even this and should be measured at the board level. There was recently another posting related to latency which can be found here.

Cheers      

Thank you for your answer.

Of course, the settings are as you describe, but still, I have 400-500ms of lag when I go to Idle.

My problem is not EVENT_TX time (15ms), my problem is the time it takes the system to send the first frame of RF, which is not the same.

I have observed with an oscilloscope that when we enter idle mode the crystal oscillator (32.768kHz) is off, and so when you return to active mode, the crystal must be turned on and according to the datasheet (cc2540.pdf) this crystal takes 400ms to stabilize (matches with time delay) and this effect is clearly seen in the oscilloscope, can this be the reason? Can you help me fix this?

Thank you very much      

Are you using SPI or UART?

If you are using UART, are you asserting the SLEEP signal, the SUSPEND signal, or both to enter IDLE or SUSPEND states?

If you are using SPI, are you asserting nSMSGRDY to enter the ACTIVE power state?

What is the ACTIVE state (SLEEP & SUSPEND signals disabled for UART) current consumption you are seeing when no channels are open?

We are doing an investigation of whether the CC2571 chipset is capable of fulfilling both your latency and power consumption requirements, but we are fairly certain that your latency is being throttled by the external crystal startup time.      

Thank you very much for your research, I expect good news.

Regarding your question:

We only asserting SLEEP signal to enter IDLE mode (we use UART).
In the ACTIVE state we measured an average consumption of 13-8mA.

Pending the results of the investigation, a greeting      

After some research and discussion with TI, I can offer some firm and some possible solutions for you.

If you wish to continue using the CC2571, you may be able to use a crystal with a lower wakeup time, most likely crystals with lower ESR and/or capacitive load.
Another possible option would be to ground Q1 via a cap and then connect an external 32.768 kHz clock to Q2 via AC coupling.
For additional hardware support please contact TI for assistance but we have not tested any of these methods ourselves.

If you are able to consider chipsets other than the CC2571, we have tested the nRF24AP2 and it has very fast startup times which would easily have you broadcasting within a couple milliseconds.
The AP2 defaults to the internal RC clock which is very fast compared to an external clock, but testing the external crystal on an AP2 module revealed very fast startup times as well.
By using the external crystal the base current draw may be low enough for your application, and using byte synchronous SPI if possible will also lower your current consumption for the AP2.

If current consumption on the AP2 still would not be acceptable, the AT3 chipset should also give the latency requirement you need at a lower active current than the AP2 but this has not been tested.

Cheers      

Thanks for your effort and research.

We chose the CC2571 only by the power +4 dB, since the AP2 not have this feature. (for us it is easier to integrate the AP2, since we have built in 3 previous projects and therefore we can use our experience, we have to wait to AP5).

Of the options that you propose to solve the problem for the CC2571, we have tested the second option (via Q1 to ground cap and Then connect an external 32.768 kHz clock to Q2 via AC coupling), and response times have dropped considerably, obtaining times below 10ms.

Currently our Push-button gets send within 10ms “Sendbroadcastdata” coming from IDLE mode and coverage of more than 50m away, and estimated duration of the battery 2032 more than a year, this is enough for us.

[img size=150][/img]
Thanks again for the investigation.
[img size=320]http://www.thisisant.com/images/fbfiles/images/pulant.JPG[/img] [img size=320]http://www.thisisant.com/images/fbfiles/images/pulant.JPG[/img]