When you say 'scan response request', do you mean scan requests or scan response?
If scan requests, then I do not agree that you can customize any data in it before sending the request, as the spec dictates a fixed payload for it. If you were talking about scan response, then yes, the data can be changed and sent back to the device requesting for it. Do let me know if you don't agree with me on this.
The way I understand your application is that your Peripheral (advertising device) sends advertising data with Manufacture specific but scan response packet only when scan request comes from a particular Central device (as we have established now that scan request packets cannot be customized).
You can try by enabling/disabling passive scanning on the Central side. If passive scanning is enabled, then the Central device will only listen for advertising data but not send scan requests. If you receive the advertising packet with the right manufacturing data, stop the current scan, update scan settings by enabling active scanning and the restart scan. Now, your BLE stack will send the scan requests to the devices. On the other hand, something that you tried with whitelist should also work. For now, I can think of these two ways. You may have to handle much of the state changes in your firmware.
Yes, I have several peripherals that are advertising, and one central device that receives the advertising data from these devices. The protocol is similar to Apple iBeacon in that data is only sent during the advertisement packet within the 24/31 bytes available for it, and a GATT server is never required.
I am not sure why the spec requires a fixed scan response request. I am new to the BLE stack and protocol, so I refer to this diagram:
I want to customise the scan response request that the Central device emits, then I want to receive the scan response data.
However, it does seem that from reading that the scan response is not customisable, so I will have to find another way to transfer the data. Perhaps I will have to use GATT, but it seems like additional overhead that could be avoided.
The network I'm working with doesn't have to be BLE standard compatible - we're just using the BLE protocol in a private network to get local devices talking to each other. Only our devices will be allowed onto the network.
This topic is interesting, are there any examples of how to change the Scan Response packet?
I have an idea to implement:
Advertise slow, undirected, unconnectable (from time to time I'll update the broadcasted packet)
Some event happens on the device (state is now "Triggered").
Modify the Advertisement packet indicating Triggered state and advertise broadcast fast.
Keep advertising until a Central acknowledges reception of the Triggered broadcast.
I guess I could make the Central make a connection to acknowledge the Triggered broadcast but I was hoping to keep things very simple.
Perhaps I could have the Central send a Scan Request, can I intercept this on the PSOC? However I'd need some way to understand which Central sent the Scan Request as I will have the Device reset itself when it knows a particular Central knows about the Trigger state. As the Scan Request message from the Central is fixed I cant interpret them as an acknowledgement of the Trigger. I could use a Whitelist containing just the address of my particular Central to filter Scan Requests but I'd need some way of persisting this list across device restarts, I can see how this is achieved.
Update: I found that white listing will probably be a problem as my intended Central is a smartphone which uses Random Resolvable Addressing. So I'll need to build in a Bonding phase into my app. I'll have to research how PSOC Peripheral mode can handle this.
Any suggestions on this or an alternative approach are welcome.