This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Active scanning with enabled filter causes sending SCAN_REQ to every advertiser

Hi everybody,

I saw topics with similar naming like mine, but none of them actually describes my issue.

I develop some simple scanner and advertiser solution.

On advertiser side I've implemented ADV_SCAN_IND and SCAN_RSP packets. In ADV_SCAN_IND I've put some custom UUID to easy find my advertisers if there is many BLE devices around. In SCAN_RSP there is my custom data (0xFF - manufacture data).

On scanner side I've turned on active scanning with turned on filtering by UUID (same solution as it is in some sample code).

I've observed some strange behaviors:

1. Scanner side invokes "filter match" callback when ADV_SCAN_IND packet is received with correct UUID...and then "filter no match" callback when SCAN_RSP packet is received which contains my own custom data. To avoid this would I need to put UUID data also in SCAN_RSP packet? Or maybe some scanner configuration should be changed?

2. Even if in ADV_SCAN_IND there is no matching data (no UUID field), my scanner sends SCAN_REQ anyway...I think is pointless to waste time for sending SCAN_REQ for different advertisers.

- Can I configure my scanner in a way that it will send SCAN_REQ only to devices which contain correct data in first ADV_SCAN_IND?

- Can I avoid invoking "no filter match" callback for devices which have correct data only in ADV_SCAN_IND packets?

Best regards,

Adam

Parents
  • Hello,

    I understand that in your case, you only want to use active scanning if it is one of your own devices, and therefore it is a waste of time to send a scan request for devices that you know aren't relevant. However, this is the way that bluetooth works. If you enable active scanning (which will send scan requests), then you will send scan requests for all advertising packs that you receive (that claim to have a scan response packet). The reason for this is partly that you don't have much time between the initial advertisement and the scan request, so there is no time to involve the CPU to decide whether or not to send it. 

    Also, in many cases these filters are used to determine whether you want to connect to a device or not. And in those cases, you may not know whether the data that you are looking for is in the initial advertising packet or in the scan response packet. So you would have to send a scan request even though the initial scan response packet didn't match the filter. 

    - Can I configure my scanner in a way that it will send SCAN_REQ only to devices which contain correct data in first ADV_SCAN_IND?

    No

    - Can I avoid invoking "no filter match" callback for devices which have correct data only in ADV_SCAN_IND packets?

    No.

    I am not completely sure what exactly you want to do, but I imagine that you want to use the UUID to find your devices, and then look at the scan response packet from those devices only. Perhaps something like this can work:

    1: save the address of all the devices that match the UUID in the original advertising packet in an array.

    2: Whenever you receive a scan response, see if the address matches any of the addresses in the array, and proceed to interpret the data only if the address is present.

    I guess you could add the UUID in your scan response packet as well, but I suspect that the reason you are using a scan response packet in the first place is because you couldn't fit the UUID and the vendor specific (custom) data in the same advertising packet (but I may be wrong). If you can fit them in the same packet, see if you can fit everything into the initial advertising packet, and then you can skip the scan response packet altogether.

    Best regards,

    Edvin

Reply
  • Hello,

    I understand that in your case, you only want to use active scanning if it is one of your own devices, and therefore it is a waste of time to send a scan request for devices that you know aren't relevant. However, this is the way that bluetooth works. If you enable active scanning (which will send scan requests), then you will send scan requests for all advertising packs that you receive (that claim to have a scan response packet). The reason for this is partly that you don't have much time between the initial advertisement and the scan request, so there is no time to involve the CPU to decide whether or not to send it. 

    Also, in many cases these filters are used to determine whether you want to connect to a device or not. And in those cases, you may not know whether the data that you are looking for is in the initial advertising packet or in the scan response packet. So you would have to send a scan request even though the initial scan response packet didn't match the filter. 

    - Can I configure my scanner in a way that it will send SCAN_REQ only to devices which contain correct data in first ADV_SCAN_IND?

    No

    - Can I avoid invoking "no filter match" callback for devices which have correct data only in ADV_SCAN_IND packets?

    No.

    I am not completely sure what exactly you want to do, but I imagine that you want to use the UUID to find your devices, and then look at the scan response packet from those devices only. Perhaps something like this can work:

    1: save the address of all the devices that match the UUID in the original advertising packet in an array.

    2: Whenever you receive a scan response, see if the address matches any of the addresses in the array, and proceed to interpret the data only if the address is present.

    I guess you could add the UUID in your scan response packet as well, but I suspect that the reason you are using a scan response packet in the first place is because you couldn't fit the UUID and the vendor specific (custom) data in the same advertising packet (but I may be wrong). If you can fit them in the same packet, see if you can fit everything into the initial advertising packet, and then you can skip the scan response packet altogether.

    Best regards,

    Edvin

Children
No Data
Related