Re: Is it possible to change scan parameters for BT LE scans?
Re: Is it possible to change scan parameters for BT LE scans?
- Subject: Re: Is it possible to change scan parameters for BT LE scans?
- From: Jimmy Adler <email@hidden>
- Date: Thu, 10 Jan 2013 11:07:58 +0100
Hi Etan,
On Jan 10, 2013, at 10:45 AM, Etan Kissling wrote:
> 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.
Yes, this is what I used to find out that the length was wrong, the raw message sent was: 11ff....
So 0x11 for 17 bytes length, 0xFF for ManufacturerData and then an additional 15 bytes (according to the length it should be 16).
Of course in the IOS interface I never get to see the 0x11 or the 0xFF, since the packet is parsed by IOS and mapped to kManufacturerData and a payload. And since the payload is to short, the packet never reaches me :)
> 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.
Ok, will do some trial and error once I get correct HW. Worst case I will keep the thread awake in the background, this application will most likely be delivered outside of appstore using Enterprise dev program anyway, so it shouldn't be an issue.
> The Bluetooth Core Specification Version 4.0 Volume 2 Part E Section 7.8.11 explains the LE Set Scan
> Enable Command.
>
>
> You can acquire a copy of the Bluetooth spec under www.bluetooth.org/spec .
Thanks, got the nice 2200 page document when I was troubleshooting this previously, it's a lovely read ;)
Thanks again,
JImmy
>
> On 09.01.2013, at 14:23, Jimmy Adler <email@hidden> wrote:
>
>> 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
>>>
>>
>
_______________________________________________
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