• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 658 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.

Question about CC2640's 32K oscillator accurate

MagicQ
Prodigy 80 points
Other Parts Discussed in Thread: CC2640

Hello,

I have a question about 32K oscillator.

In my last question https://e2e.ti.com/support/wireless_connectivity/f/538/p/456444/1651951#1651951

  • 0
    Prodigy 80 points
    I don't know why the message lost. please see following.

    Therefore, I have another question. Is there the accumulative error for the 32K oscillator.


    In other words, the CC2640 can work finely +250/-250PPM, but my oscillator is 251PPM.

    In this case, the connection will be broken quickly or be broken serveral hours later?


    I mean whether can I believe the 32K oscillator is OK after the master has connected the slave one or two hours.


    And another question, the HCI_EXT_SetSCACmd() function can set the scale PPM. I think the power consumption of value 500 is more than value 40. Is right?
  • 0 in reply to MagicQ
    TI__Guru** 106705 points
    Hi,

    The BLE sleep clock accuracy requirement is +/- 500 ppm. If your 32 kHz clock is slightly higher than this, you will most likely still be able to maintain a connection due to "random" margin. The error is not accumulative because the master and slave will syncronize every time they talk to each other. Longer periods between connection events, due to slave latency for example, will of course increase the chance of breaking the link with inaccurate clock.

    The best way to verify you 32 kHz clock is to map the clock signal to an IO and measure the frequency with a counter.

    Using a less accurate clock (and thus adjusting the HCI_EXT_ SetSCACmd()) requires more power consumption than using a more accurate clock. This is because the radio has to spend more time in active RF at each connection event to be sure to catch the packet sent from the master.

    Cheers,
    Fredrik