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.

CC2540: BLE connection loss between master and slave with wide temperature differential (> 50C) at 4 second connection interval

Part Number: CC2540
Other Parts Discussed in Thread: CC2640

Is there any configuration setting that I can change that will make communication reliable between a master at 85C and a slave at -40C with a 4 second connection interval?  It works well when the temperature differential is < 50C.

Thanks,

Richard

  • Hello Richard,
    The root cause can be an offset of more than 40 PPM of the LS 32 kHz crystal due to temperature variation.
    Increase the sleep clock accuracy configuration in the BLE stack with HCI_EXT_SetSCACmd( uint16 scaInPPM ). Default setting is 40 ppm. You can also evaluate the 32 kHz crystal frequency on your board and adjust load cap in case your offset is more than the crystal specification (PPM) at room temp.
  • Hi Eirik,

    Thanks for the quick reply! I am a little unclear as to how to apply the 40 PPM number? The 32768Hz XTAL meets this at room temperature, but follows a parabolic curve with temperature variations. I believe that all XTALS of this type (even the XTALS on the SensorTags) follow similar curves? That being said, they still fall within the +/-500 PPM limit of the BLE specification. I am under the impression that the BLE link layer dynamically adjusts the RX-window size to compensate for sleep clock (temperature) differences between a master and a slave? With a master at 85C, and a slave at -40C you could expect to see a typical sleep clock difference of over 200ppm. How does your 40 PPM statement apply to this?

    Thanks,
    Richard
  • Hello Richard,
    The RX Window (widening) and is a number of microseconds the slave should start listening prior to the 'actual' clock tick, because clocks will always drift on both sides of a connection. Both sides of a connection can set the Sleep Clock Accuracy parameter, which is dependent on the hardware, for the calculation of when how early the slave should wake up for the RF event. This defines the initial RX window for a connection event. If the slave misses a connection event from the master it will go into RX earlier as described above, but not necessarily early enough if both the clock drift/offset is to large. Certain connection parameters can also make it worse (long connection interval, slave latency).

    The default slave clock accuracy (SCA) setting is 40 PPM and I was simply using that as an initial reference to make sure your setup is ok for room temp. You should definitely try to increase the SCA (maximum 500 PPM).

    You can measure the PPM of the 32 kHz crystal on your boards at the expected temperatures by outputting the clock signal to a pin and using a frequency counter. Refer to TRM section 11.3.3 Map 32-kHz System Clock (LF Clock) to DIO/PIN to see how it is configured in software.

    It is also possible to output the LNA active and TX active signals to pins to profile the RX/TX timing. Please see the "CC2640 Range Extender Control" page on our ble forum (ti.com/ble-wiki).
  • Hi Eirik,

    Yes, we do have a static sleep clock difference of over 50 PPM.  I was under the impression that the BLE link layer (both master and slave) adaptively adjusted the position of RX and TX windows to compensate for master/slave sleep clock differences.  Doing this allowed the link layer to adjust for static clock differences like we are seeing in our testing.  Isn't this the case?

    Thanks,

    Richard

  • Hello Richard,

    Please refer to the Adopted Bluetooth Core Specification Core Version 5.0, Chapter "4.5.7  Window Widening". The document is found here:

    https://www.bluetooth.com/specifications/adopted-specifications

    The connection event anchor point on the slave is adjusted every time the slave receives a connection event packet from the master (even if the CRC fails). If the slave miss a connection event it will set slave latency to 0 (listen to every connection event packet from this instant) and increase the RX window (window widening) by a factor equal to the accuracy offset (slave + master possible drift based on configured clock accuracy) times the number of missed events. There is no "automatic effective connection interval time calibration" ( I made that name up :) ) that can repair an offset larger than the configured slave clock accuracy + master clock accuracy.

    Also refer to the app note "Crystal Oscillator and Crystal Selection for the CC26xx and CC13xx Family of Wireless MCUs" which states "The Bluetooth low energy stack is by default set to 40-ppm accuracy. If a customer product is designed to operate over large temperature ranges, the customer must adjust this accuracy"

    http://www.ti.com/lit/an/swra495e/swra495e.pdf