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.

CC2650 speed up data rate or receive event handling or disable notifications?

Other Parts Discussed in Thread: CC2650, CC2640

I'm using the SmartRF06 Eval board, CC2650EM, and the SimpleBLEPeripheral app.  I've got the CC2650 module paired up with my Android device, and I've made an App that has a seek bar (slider).  When the seek bar moves, it sends a value (1 byte) to the CC2650.  The CC2650 then adjusts a digipot using SPI.  The problem is that the seekbar fires it's actionlistener so fast that a lot of the data isn't processed, so rather than a smooth adjustment of the digipot, it pretty much just jumps to a value.  When I say "so fast" i don't think it's so fast in the electronic world (maybe 10 times a second tops).  So probably about 100ms between transmissions.


I'm using the GATT profile, and a characteristic that's read only on the CC2650 (UUID 0000fff1-0000-1000-8000-00805f9b34fb).  On the Android side I write the value to the gatt characteristic with write type, WRITE_NO_RESPONSE.  So it shouldn't be expecting an acknowledgement. (?)


I've already disabled the LCD screen, increased the SPI speed, and the difference is slightly noticeable but still not where I want it to be.  I'm thinking it's something in the module code rather than the Android.  Do I need to disable notifications on the CC2650 for that characteristic?  What kind of speeds can I expect using GATT?  Any ideas?

I would like to add, it looks like it's receiving all of the data.  I swipe the seekbar from one end to the other, and in about the course of one minute the voltage over the digipot slowly adjusts between it's minimum and maximum range.  I've done this before with an arduino and a $10 bluetooth module, so it's not the digipot...

  • Hello. To find the source of the latency, I would recommend looking at a combination of an over-the-air capture and a SPI logic capture. Are you actually seeing data transferred over-the-air at 100 intervals? Speaking of this, are you configuring the connection interval to 100 ms? Note that various Android devices will allow connection updates differently. You may not actually be connected at 100 ms.

    Assuming you are sending data every 100 ms, you should then verify you are getting to process in your application write callback every 100 ms. 100 ms is more than enough time for the stack to post an even to the application so this should not be an issue. You can check this by toggling a GPIO in the application processing.

    Lastly, if everything looks fine until this point, the delay is likely in your implementation of the SPI driver. Are you using NPI to implement SPI as the hostTestApp project does? You can verify this by taking a logic capture of the SPI lines.
  • Excellent tip, so I toggle an LED when SimpleBLEPeripheral_processCharValueChangeEvt is called. I adjust the seek bar so it transmits 10 or so values, and the LED will toggle about once a second processing all values. So it gets all the data and stores it in a buffer/memory somewhere, and it just takes a long time for that event to trigger.

    The above change event is also where I call my function to transmit using SPI. As far as SPI implementation is concerned, I don't know what you mean by NPI. I'm implementing the driver in accordance with section 6.3.3 in the SimpleLink™ Bluetooth® low energy
    CC2640 wireless MCU Software developer's guide.

    Thoughts?
  • Problem solved, in SimpleBLEPeripheral.c I changed these two values, the first from 80 to 8 and the second from 800 to 40. It now updates fast.

    // Minimum connection interval (units of 1.25ms, 80=100ms) if automatic
    // parameter update request is enabled
    #define DEFAULT_DESIRED_MIN_CONN_INTERVAL 8

    // Maximum connection interval (units of 1.25ms, 800=1000ms) if automatic
    // parameter update request is enabled
    #define DEFAULT_DESIRED_MAX_CONN_INTERVAL 40