• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 2281 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 Unfiltered Discovery Scan

Jeremy Jass
Prodigy 125 points
Other Parts Discussed in Thread: CC2541

Working on a project that is built on the SimpleBLECentral example project.  Currently stuck trying to get it to return an advertiser whenever it is discovered, regardless of whether the address has already been discovered in the current scan.

I found the GAP parameter "TGAP_FILTER_ADV_REPORTS" that sounds like it does exactly what I'm looking for.  From 'gap.h':

#define TGAP_FILTER_ADV_REPORTS       35  //!< Filter duplicate advertising reports. Default TRUE.

So in 'simpleBLECentral.c' in the 'SimpleBLECentral_Init' function I override the default and force TGAP_FILTER_ADV_REPORTS to FALSE using the 'GAP_SetParamValue' function.  With breakpoints immediately before and after the scan I checked the value of TGAP_FILTER_ADV_REPORTS using 'GAP_GetParamValue' to ensure it hadn't been overwritten after my assignment, but it appears to remains FALSE.

I also set TGAP_GEN_DISC_SCAN to 3000 to allow for 3s scans, and TGAP_GEN_DISC_SCAN_INT and TGAP_GEN_DISC_SCAN_WIND to 160 (160 * 0.625 = 100ms) to ensure that during those 3s there is a lot of scanning going on.  I currently have our advertiser cranked up to advertise every 100ms and with these scan characteristic it can detect multiple advertisers reliably within the first second of the 3s window, so I'm sure the CC2541 is receiving more then one message when in an environment with a single advertiser.

The scan is initialized by 'GAPCentralRole_StartDiscovery( DEVDISC_MODE_ALL, FALSE, FALSE);' and I'm pulling data directly from the 'GAP_DEVICE_INFO_EVENT' case in the 'simpleBLECentralEventCB' function, but I'm only seeing a single detect for each unique advertiser per scan request.

From what I can tell 'GAPCentralRole_StartDiscovery' is my call into the stack, and the 'GAP_DEVICE_INFO_EVENT' is the first output I should get whenever an advertiser is discovered, so I'm at a loss as to what is going on or how to achieve the desired behavior where I will be able to see multiple 'GAP_DEVICE_INFO_EVENT's for an advertiser within the same scan.

Thanks

  • 0
    TI__Mastermind 23440 points

    Hi Jeremy,

    Unfortunately you have stumbled upon a known feature. The command you describe works as advertised (sic) but not through all the stack layers. The crux is that the advertisements are only reported more than once per scan duration if the advertisement data changes between advertisement events.

    There is a bug report filed for this, and a solution exists, but unfortunately this code is inside the precompiled libraries.

    What is it you wish to achieve?

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    Prodigy 125 points

    Thanks for taking the time to reply.  What I'm trying to achieve is to establish a more reliable RSSI to range relationship.  I've been collecting data all weekend, and it appears that trying to make an assumption about range based on the RSSI metric from a single advertising packet isn't at all consistent.  However, in the bigger picture there is definitely a range to RSSI relationship, just a single sample by itself is unlikely to reflect the average.  If we could capture a few samples instead of just one, we could start running averages, throwing out outliers, and try to establish a better relationship.

    I could try stopping the discovery and restarting it every time an advertiser is discovered, but my intuition is that would be a lot more overhead which would work against trying to acquire as many samples as possible within in the 3s window.  The window could be extended slightly, but as the advertisers are potentially moving, going too far beyond 3s would be ineffective.

    As a longer term solution, would inserting an incrementing counter into one of the advertising data fields be sufficient to trigger a data change and allow multiple packet to pass through the stack?  With our current advertiser design this isn't actually possible, but we are already working on a next generation one and I could get that added to the list of features and try to get it accelerated.

    Or maybe there is another solution that I haven't thought of.  Let me know if you have any thoughts or suggestions.

    Thanks,

    Jeremy

  • 0 in reply to Jeremy Jass
    TI__Mastermind 23440 points

    Hi Jeremy,

    I don't think there's anything you haven't thought of. Hopefully this can be configured 'properly' in the next release, but until then you'd be best off just using very short scan cycles.

    BR,
    Aslak

  • 0 in reply to Aslak N.
    Prodigy 100 points
    Just pinging you folks because I saw this feature lying around. It would be helpful to my application as well. As a side note, it seems to be implemented in btool v1.40.5 & the v1.40 sdk but btool thinks tgap_filter_adv_reports is 33 -- seems like the C# code is not in parity w/ the SDK.

    1.41 here we come!
  • 0 in reply to nom de plume
    Prodigy 100 points

    Unfortunately, btool still is not in parity with the sdk, as TGAP_GAP_TESTCODE corresponds with tgap_filter_adv_reports. Once this is taken into consideration, everything works as expected.