|
Jimmy,
Regarding the incorrect data length that you observed:
SCAN_RSP data uses an additional length header in front of the advertising data. Are you sure that
this 17th byte does not contain a 0x10 value, which would indicate a length of 16 bytes for the payload?
The advertising data format is described in the Bluetooth Core Specification Version 4.0 Volume 3
Part C Section 11.
Regarding SCAN_RSP data in general:
SCAN_RSP data should not be used for dynamic data, but for static data. Advertisement data is there
for dynamic data. I'm not sure how often iOS will query for updated SCAN_RSP data and how often it
will deliver the advertisement report to your app.
Again quoting the spec, Bluetooth Core Specification Version 4.0 Volume 1 Part A Section 4.2.2.2
confirms the guideline of what data to put where:
"Advertising devices may receive scan requests from listening devices in order to get additional user
data from the advertising device. Scan responses are sent by the advertising device to the device
making the scan request over the same advertising physical channel. Whereas the broadcast user
data sent as part of the advertising packets is typically dynamic in nature, scan response data
is generally static in nature. "
Summary:
- service data ="" advertising data (so that iOS can know if the device supports your requested service
before it has to request the SCAN_RSP data)
- static data like device name => scan_rsp data (takes longer to acquire)
- dynamic data like changing temperature values => advertising data
Regarding the expected behavior of the Filter_Duplicates parameter:
Unfortunately, the wording from the Bluetooth Spec is not very clear here, and I have not yet tested
HW with changing advertising reports in conjunction with a backgrounded app on an iOS device.
Therefore, you will have to go with try and error here, unless someone else can confirm or deny whether
repeated advertising reports are delivered to the app.
The Bluetooth Core Specification Version 4.0 Volume 2 Part E Section 7.8.11 explains the LE Set Scan
Enable Command.
Cheers
Etan
Hi Etan,
thanks for your answers!
I belive that I have found the issue. Using a PC for sniffing the packets I saw that the datalength of the packet was set to 17 bytes, while the packet only contained 16 bytes, so it is most likely the fault of the 3:rd party device which is sending the packet.
I assume that IOS does not deliver the packet until it thinks all the data is available, which it will never be if there is to little payload in the data :)
Since I don't have insight in the code on the device I have forwarded my suspicion to my customer and they will handle the discussion with the 3:rd party supplier to correct the issue in the HW!
You did mention that there can be dynamic data in the scan response and that this will only be discovered once while in background mode.
I noticed that with another HW I tested with, when I had the scanning option set to "not allow duplicates", I would still get updated advertisment packets with the changed dynamic data after a couple of minutes when activating the HW again (controlled by accelerometer
in the device) is this the same behavior that I should expect to see when running in the background, or will I never get the updates at all when running the app in the background?
Best regards,
Jimmy
On Jan 9, 2013, at 1:48 PM, Etan Kissling wrote:
Jimmy,
one more update for my last message:
The only scanning option that you have on iOS is whether you want to receive multiple advertisements for the same device.
If this is disabled, I'm not sure whether or not SCAN_RSP data is already included when the first advertisement is received.
Note that background scanning will always only send the first advertisement for each device to your app.
Regarding device name in SCAN_RSP data:
A video of one of the projects I worked for in action, where the peripheral name is broadcasted as SCAN_RSP data, can
be watched under the following link. Note how it takes several seconds for all the names to load, even after the peripheral
has already been discovered.
http://www.youtube.com/watch?v=uqGF-Mtja-E&feature=player_embedded
(device list starts at 0:20)
Etan
On 09.01.2013, at 11:15, Etan Kissling <email@hidden>
wrote:
You cannot specify scanning options on iOS using public APIs. However, iOS supports active scanning.
Note that you should put static data in your scan_rsp part as additional packets have to be exchanged to retrieve them. Dynamic data should be put in your advertisement data.
I have not tested it but it may be reasonable that iOS does not send a SCAN_REQ for each and every advertisement report of the same device. Also, as the SCAN_RSP data arrives at a later point in time than the original advertisement data, you may not see it
at all.
What I tested in the SCAN_RSP data until now is only a partial device name. This works perfectly (but is not available on the first received advertisement yet) and is overridden as soon as you connect to the device with the name stored in the GAP service.
As the name is managed by iOS, other rules may apply for custom SCAN_RSP data.
I also suggest using the TI packet sniffer for ~50$ to see when the iphone actually sends these scan_req packets.
Etan
On 09.01.2013, at 09:59, "Jimmy Adler" <email@hidden> wrote:
I have an issue detecting kCBAdvDataManufacturerData from a 3:rd party device using BT LE. I get the kCBAdvDataLocalName advertisement, but not the one containing the Data.
When using a PC testapplication I'm able to get the kCBAdvDataManufacturerData by setting the scan_interval to 10ms and scan_window to 10ms and using active scanning.
Problem is that as far as I can see, these parameters are not accessible on the IOS device, or can the paramters be sent in when starting the scan using the options dictionary in some way?
Is this problem solvable without having access to and altering the code in the device?
Best regards,
Jimmy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|