• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 1560 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.

Is "DEFAULT_SVC_DISCOVERY_DELAY" after link establishment required ?

smitesh mali1
Intellectual 900 points

Other Parts Discussed in Thread: CC2650, CC2640

hello,

In "SampleBLECentral" demo example after link establish event "DEFAULT_SVC_DISCOVERY_DELAY" 

1000 ms delay is given before giving Service discovery command.

Is this delay required ?

can i reduce or remove this in my application ?

Regards,

Smitesh mali

  • 0
    TI__Mastermind 23440 points

    Hi,

    It's not really required, no. Just change it to an osal_set_event(..).

    Best regards,
    Aslak 

  • 0 in reply to Aslak N.
    Intellectual 300 points

    What is the current replacement call for osal_set_event() when working with the CC2650 and TI-RTOS ?  Or if there is none, what unit should I include in the project?

    This is to eliminate the apparently unnecessary use of a clock and a delay in the sample code SimpleBLECentral  Role event handler, case GAP_LINK_ESTABLISHED_EVENT: when connecting to a device.

  • 0 in reply to Happy Dawg
    TI__Guru** 105180 points
    Hello,

    Please see the "Porting from CC254x to CC2640" chapter in the CC2640 SW Developer's Guide, SWRU393. There is a sub section on Event Processing.

    Best wishes
  • 0 in reply to JXS
    Intellectual 300 points
    I am trying to speed up the connection between two CC2650 boards significantly, in the SimpleBLECentral to SimpleBLEPeripheral setting.
    I get a great result, until the last step, then it is slow as molasses.
    I lower DEFAULT_SCAN_DURATION_MS to 250 ms instead of 4,000.
    As soon as a device is detected that has the desired service (our device, of course), I AddService and immediately CancelDiscovery.
    I connect to the device, and so far so good.

    Then I negotiate the MTU... and that absorbs about 7 seconds. Glacial.

    I can set the clock delay prior to negotiating to 50, 200, 400 or 1,000 (the original setting) and it seems to make no difference.
    About 7 seconds after initiating this final step, I see the GAP_LINK_PARAM_UPDATE_EVENT.

    I can eliminate the clock entirely, and call the final step directly --- no change. Still about 7 seconds.

    What parameters can I adjust to make this as fast as the sub-1 second process to that point?
  • 0 in reply to Happy Dawg
    Intellectual 300 points
    In SimpleBLEPeripheral there is a GAP parameter one can set, TGAP_CONN_PAUSE_PERIPHERAL, which is described in SWRU393 as "Minimum time upon connection establishment before the peripheral starts a connection update procedure. In seconds (default 5 seconds)" In the sample it is set to 6 seconds. Slashing this to 1 second removes 5 seconds from the 7-second delay.
    That is the only documentation I found on the parameter. Where can I find further discussion of the ramifications of such a significant reduction in the delay?
    If it is possible to have the BLE handle this automatically, is there a document that describes what needs to be done, and the tradeoffs?