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.

Advertising and Connection handshake in CC2650 SensorTag

Other Parts Discussed in Thread: CC2650, CC2540, CC-DEBUGGER

Hi,

I am working on CC2650 SensorTag. I tried the SensorTag application. It worked fine.

For our application, we interfaced EEPROM device to it to log the movement sensor data. Now, in our application code, we have only movement sensor service and EEPROM read/write function added to it. The whole application is working fine. I just want to clear one thing which I didn't get.

When I observed the waveforms across the 10ohm resistor in the battery negative path to find out the battery power consumption, I observed that during advertising, the waveform on DSO show peaks during advertising event and EEPROM read/write events. But when it get connected to an iOS App, the waveform shows peaks at 30ms continuously and during EEPRO write event. So, I want to know what handshake take place during connection mode. Is it possible to change this time interval from 30ms to some other value? If yes, how?

Below are the screen shots taken during advertising and connected mode.

  • Hello Mamata,
    It seems like the connection interval is set to 30 ms?
    You can check the air traffic by for example using the CC2540 dongle with the SmartRF Protocol Packet Sniffer.
    Simply try to set the desired connection interval to a higher value from your SensorTag peripheral application.
  • Hello Eirik V,
    Thanks for reply.

    The parameters set in the code are as follows
    DEFAULT_ENABLE_UPDATE_REQUEST -: false
    DEFAULT_DESIRED_MIN_CONN_INTERVAL -: 10ms
    DEFAULT_DESIRED_MAX_CONN_INTERVAL -: 1000ms
    DEFAULT_DESIRED_SLAVE_LATENCY -: 0
    DEFAULT_DESIRED_CONN_TIMEOUT -: 1sec

    Thanks,
    Mamata N.
  • Try to set both min and max to the same desired value. IN this setup your master will chose an interval in between 10 ms and 1000 ms which might be 30 ms.

  • Hi Eirik V,

    I also tried setting both the intervals, maximum and minimum connection intervals, to 1000ms. But it's showing the same waveforms, pulses at every 30ms after getting connected to an iOS App, as mentioned earlier.

    Thanks,

    Mamata N.

  • Can you take a air sniffer trace of the connection?
  • Actually, I don't have CC2540 dongle. Is there any other way to trace it?

    Thanks,
    Mamata N.
  • Hello Mamata,

    You can run your peripheral device in debug mode and set  break points in the two following cases:

    periheral.c -> gapRole_processGAPMsg ->

    • case GAP_LINK_ESTABLISHED_EVENT
    • case GAP_LINK_PARAM_UPDATE_EVENT:

    Then read out the the connection interval from the connection parameter variables. Initially the connection parameters will be set upon entering the connection, but shortly after the connection is formed the master may initiate a update of the connection parameters.

    If you plan to work a lot with BLE I would strongly recommend you to enable sniffer capability on your computer by getting a hold of the CC2540 USB Dongle (http://www.ti.com/tool/cc2540emk-usb) or other equivalent. The dongle comes preprogrammed as a packet sniffer, but if you need to reprogram the dongle you will also need the CC-Debugger (http://www.ti.com/tool/cc-debugger)

  • Hi Eirik,

    Thanks a lot for your reply.

    I tried out the procedure as per your post. In case GAP_LINK_ESTABLISHED_EVENT, gapRole_ConnInterval found to be 24(*1.25 = 30ms). If I want to increase this interval, do I need to make corresponding changes in the iOS App or it can be done in cc2650 firmware?

    Thanks,

    Mamata N.

  • Hello Mamata,

    You will probably have to modify the iOS app. The slave (peripheral) should send an parameter update request since you set the DEFAULT_DESIRED_MIN/MAX_CONN_INTERVAL. This is probably rejected by the master (smartphone). You would be able to see this on a sniffer log of the connection.

  • Hi Eirik,
    Thank you very much for your replies.

    Now I am facing one problem. In our application, movement sensor's data is saved to EEPROM and in the connected mode, when a command is received from an iOS App for sensor's data, the device uploads data to it. For uploading the data, I have constructed one periodic clock of 190mS of which 185ms are consumed for reading eeprom(18bytes) and sending it over Bluetooth. Some times, while uploading data, the device(cc2650) get stuck after which it is not at all discoverable and needs a restart. So I tried it for 500mS also. But I am getting the same problem. When I observed the waveform on DSO across the 10ohm resistor in the battery negative path, it shows a plain dc 50mV(5mA current is drawn continuously) signal when it gets stuck. I just want to know is it possible that the reading EEPROM and sending it over Bluetooth clashes with the connection events which happens every 30mS causing this problem or if any other possibility please let me know.

    Thanks,
    Mamata N.
  • Hello Mamate,

    Approx 5 mA could indicate active mode with the MCU power domain powered and possibly some MCU activity. So it might be a SW issue. Just guessing here. You will need to dig further for us to be able to understand what the problem might be. You can decompose your program into several smaller parts. For example start by setting up the scheme to transmit some random data before you add the sensor functionality and EEPROM storage. You can also consider porting ot the latest TI-RTOS release in case there is a issue with the serial driver you use. Here you can find a porting guide for updating the ble appliaction to work with the latest release: https://github.com/ti-simplelink/ble-sdk-210-extra/tree/master/Projects/ble/simple_ble_peripheral_tirtos_2p15

    I would advise you to go through the CC2640/CC2650 Bluetooth low energy Software Developer’s Guide which you can find here: http://www.ti.com/tool/ble-stack

  • Hi Eirik,

    Thanks for your reply.

    I will go through the mentioned links. Your replies helped me a lot. Thank you very much.

    Mamata N.