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.

CC2541 Restarting Device Discovery

I am attempting to continuously scan for advertisers.  If I restart discovery immediatly uopn receiving "GAP_DEVICE_DISCOVERY_EVENT" sometimes there is up to a 1.2 second delay before I receive any new advertisements.  Sometimes there is no delay at all.  

The advertisers are changing the advertising data, and I have verified the delay in receiving occurs at the start by having two receivers running simultaneously with their Discovery periods out of phase with one another.

Is there any way to know when it is ok to start discovery again so that this delay does not occur?

  • Hello. Can you paste a snippet of the code you are using to restart discovery?

    Also, note that there is a random jitter in advertising intervals so variance is expected. You can increase the duty cycle of your scanning by modifying the scanning window / interval parameters.
  • /**********************************
    INSIDE HERE:
    static void observerEventCB( observerRoleEvent_t *pEvent )
    {
    uint8 we_seem_to_have_restarted_discovery = FALSE;
    uint8 i;
    switch ( pEvent->gap.opcode )
    {
    .
    .
    .
    .
    case GAP_DEVICE_DISCOVERY_EVENT:
    if (current_state != GAPROLE_CONNECTED)
    {
    initdiscovery();
    }
    break;

    ..
    .
    ********************************************
    THEN:
    void initdiscovery()
    {

    GAPObserverRole_StartDiscovery( DEFAULT_DISCOVERY_MODE,
    DEFAULT_DISCOVERY_ACTIVE_SCAN,
    DEFAULT_DISCOVERY_WHITE_LIST );
    }
    /*************************************
    WHERE:
    // Discovey mode (limited, general, all)
    #define DEFAULT_DISCOVERY_MODE DEVDISC_MODE_ALL

    // TRUE to use active scan
    #define DEFAULT_DISCOVERY_ACTIVE_SCAN FALSE

    // TRUE to use white list during discovery
    #define DEFAULT_DISCOVERY_WHITE_LIST FALSE

    ******************************************************
  • That looks correct. I would recommend increasing the scanning duty cycle (via the window and interval parameters).
  • I've tried counts of 32, 80, 100, 125, 160, 240 on the interval and window. That doesn't seem to make a difference.

    One thing I have noticed is that if I set the scan duration to 10 seconds, the pause happens much less frequently.

    If I have the scan duration set to 5 seconds, it will happen almost 1/4th of the time. At 10 seconds, it's less than 1/10th of the time.
  • Very frequently, no matter what scan duration or interval/window settings I use, the device (i.e.stack??) resets when I restart discovery. This occurs with stack versions 1.4.0 and 1.4.1. Is there supposed to be a minimum delay before I restart discovery? I am using peripheral/observer role.
  • I see same issue. when restarting discovery, the advertising is stuck....
    any idea?
    should delay?
  • If someone can post a modified version of the simpleBLEcentral project that can be used to replicate this, clear steps to replicate, and a way to catch the error, I can look into this.
  • I had to work around it.  Basically, the peripheral/observer role apparantly cannot advertise while simultaneously scanning for advertisements. 

    I am not using a modified version of the "simpleBLEcentral project", so I cannot meet your requirements for "looking into this."

  • Hi Tim,
    Like Charles said I'm also using the peripheral/observer role.
    I am also having a whitelist discovery (for 10000ms, restarting when finished)
    Seems like once every few times after restating using StartDiscovery, the advertisement is not working for that 10000ms duration, on the next restart it starts to advertise once again.

    I tried to stop advertising before restarting discovery and start advertising right after the rediscovery however it only reduces the amount of times the advertisement is stuck but not totally fixed the issue.

    Hi Charles,
    can you advise about the work around?

  • Hi Iddo,

    I just do not advertise and listen simultaneously. I suppose I'm going to have to find a different bluetooth LE solution for the next generation
    of the product I am doing, because I have to be able to do that.

    Regards,

    Charles
  • That is correct. You will not be able to advertise and scan simultaneously (as in using the radio to do both simultaneously). You should be able to do some sort of time-multiplexing to quickly switch between advertising / scanning indefinitely.
  • Hi Tim,

    So what is the peripheral\observer role?

    I am able to use it and both advertise & scan (probably not at the exact time - if such thing happens I guess I miss a reception).

    but still, that profile (peripheral-observer) which probably implements the quick switching you mentioned, has an issue or some kind of bug since both Charles and I encounter an issue using that profile when it stops advertising\scanning for some reason once in a while.

    I will try to generate an example app which shows that issue but I am not sure it will happen since it might be connected to some other features I am using - whitelist, other osal-events that can put some more work on the chip at those situation it "crashes".

    Any documentation about the right way to start discovery - do I have to stop advertising at the same time? 

    Any documentation about using the whitelist feature - do I have to stop both scanning & advertising when adding an address to whitelist?

    In general I kind of lack basic documentation for those features which leaves me implementing stuff in trial & error mode..... any help about finding information will be very appreciated!

    Iddo

  • We currently are working on a whitelist wiki example / demo.

    The advertising / discovery switching is kind of a corner case so no documentation exists for this right now. I can add it to the backlog.