Posted on June 10, 2014 at 20:17Hi Graziella
I had just discovered the same thing, and was going to post my discovery here. So my first set of questions relate to the use of the standard vs Vendor Specific commands:
1 Why do you implement Vendor Specific commands that more or less duplicate the standard commands? Here you suggest using the BLUEHCI_GAP_START_GENERAL_DISCOVERY_PROC (0xFC97) command that is similar to the standard HCI_LE_SET_SCAN_PARAMETERS (0x200B) and HCI_LE_SET_SCAN_ENABLE (0x200C) pair.
2 More importantly, how can I tell which commands work and which do not? The calls to the two standard commands return BLE_STATUS_SUCCESS yet don't work.
Next, please provide guidance on how to do the discovery process. The missing LE Advertising Report Event should return the contents of the Advertisng Data packets, but the EVT_BLUE_GAP_DEVICE_FOUND event that follows the BLUEHCI_GAP_START_GENERAL_DISCOVERY_PROC command returns only the Peripheral address.
3 How can I read the Peripheral's Advertising Data? Do I have to connect to the device, then read some attributes, then disconnect if it is not the device I want? (If so, how do I do this?) Or is there some other way to find the Advertising Data?
4 You say that the BlueNRG supports both passive and active scanning. How? The standard HCI_LE_SET_SCAN_PARAMETERS call has an active/passive parameter, but BLUEHCI_GAP_START_GENERAL_DISCOVERY_PROC does not (the documentation says it does active scanning - but what is the point if I can't access the Advertising Data?).
Again, I assume that someone at ST Micro must have written a real application that implements a realistic Central. So:
5 Will you please publish the source code of an application that implements a realistic Central device? It is very inefficient to figure this out experimentally.
Thanks - Charles
