October 2012 - Bluetooth-dev

Re: Error when didDiscoverCharacteristicsForService
by Constantijn Schepens 26 Oct '12

26 Oct '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Error when didDiscoverCharacteristicsForService
by Etan Kissling 26 Oct '12

26 Oct '12

Constantijn, I would strongly suggest to get an air trace (cheap ble sniffers are available at TIs page - they also work with csr-based peripherals). This is because corebluetooth errors rarely describe the issue very precisely. With the air trace you can see the error packet from the device and use the core bluetooth spec to debug. To give further assistance, a bit more context is required. How are you calling the functions? What peripheral do you use? What is the GATT database on the peripheral? Cheers Etan On 25.10.2012, at 21:57, "Constantijn Schepens" <constantijnschepens(a)me.com> wrote: > Hi, > I am trying to connect a BluetoothLE device, I get as far as connecting a service, when I call discoverCharacteristic:ForService: I correctly get the callback didDiscoverCharacteristicsForService, but then when I attempt to check that no errors occured I get the following error: > > Error Domain=CBErrorDomain Code=1 "One or more parameters were invalid." UserInfo=0x1f062150 {NSLocalizedDescription=One or more parameters were invalid.} > > Anybody know what might cause this? I cannot find the error in reference material anywhere, it is like CBErrorDomain does not exist. > > I also tried to put all the characteristics associated with the service in an array as follows(intentionally before the error check): > > NSArray *foundCharacteristics = service.characteristics; > > but then when i check foundCharacteristics, the array is empty. I do not know if the two are connected, but I think it might be possible. Any ideas? > > Thanks! > Constantijn > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/kissling%40oberon.ch > > This email sent to kissling(a)oberon.ch _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Error when didDiscoverCharacteristicsForService
by Constantijn Schepens 25 Oct '12

25 Oct '12

Hi, I am trying to connect a BluetoothLE device, I get as far as connecting a service, when I call discoverCharacteristic:ForService: I correctly get the callback didDiscoverCharacteristicsForService, but then when I attempt to check that no errors occured I get the following error: Error Domain=CBErrorDomain Code=1 "One or more parameters were invalid." UserInfo=0x1f062150 {NSLocalizedDescription=One or more parameters were invalid.} Anybody know what might cause this? I cannot find the error in reference material anywhere, it is like CBErrorDomain does not exist. I also tried to put all the characteristics associated with the service in an array as follows(intentionally before the error check): NSArray *foundCharacteristics = service.characteristics; but then when i check foundCharacteristics, the array is empty. I do not know if the two are connected, but I think it might be possible. Any ideas? Thanks! Constantijn _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Best way to deal with multiples of the same characteristic for a service?
by Kevin Alcock 23 Oct '12

23 Oct '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Scanning for specific service IDs in the background
by Andras Kovi 19 Oct '12

19 Oct '12

Hi Zsombor, I'm glad your case solved. Yes, the peripheral stops sending the advertisement data in background and thus, the central will not return it if it is filtering by services. The rest is my thinking based on the observations: 1. The central caches the advertised peripheral without the services (since those are not listed in the packets). This means it assigns a UUID to it. 2. The peripheral comes back and starts advertising the services. 3. The central does not list the peripheral as it does not distinguish it from the already cached one, which it thinks does not fulfill the filtering criteria. 4. As a result, no callback is invoked on the central, and this is a problem. Bottom line: I think the central evaluates the peripheral only once in a single scan "campaign". Therefore, if scanning is restarted, the peripheral will be reevaluated and changes in the advertised services will be sensed. Solution: 1. the central needs to check if the advertisement changes over time 2. iOS devices in the peripheral role should keep on sending the advertisement packets 3. Scanning needs to be restarted every so often to fight this phenomenon. However, doing it from the background may be problematic. PS: I guess the assumption on the central side, that the peripheral should be evaluated only once, is correct in any normal case. There aren't many accessories that could change services in a short time. However, the design decision that was made for the peripheral role in iOS straightly invalidates this condition. Regards, Andras On 2012.10.19., at 21:40, Zsombor Papp <zsombor.papp(a)logicallabs.com> wrote: > Hi Andras, > > I did see your message to Joakim. It seemed to me that you were describing a scenario that was different from mine, in that in your case the peripheral is in the background. Is that correct? > > My observation, and what's described in that stackoverflow post, was that the central running in the background won't discover the peripheral even if the peripheral advertises the service UUIDs. > > However, I just tried this again and now I do get the didDiscoverPeripheral message. Also, I tried the scenario I believe you are describing (start advertising on the peripheral, send it to the background, and then start scanning on the central), and that works, too. So maybe this is not broken per se, just unreliable...? > > By the way, I wasn't quite sure what you meant by this: "the peripheral will be found but callback not happens". How do you know without the callback that the peripheral was discovered? > > Thanks, > Zsombor > > > On 10/17/12 1:09 PM, Andras Kovi wrote: >> Hi Zsombor, >> >> I described this issue a few weeks ago and haven't got any response yet. Here's my observation and I think you bumped in this issue: >> >> >> Begin forwarded message: >> >>> On 2012.09.28., at 22:14, Andras Kovi <allprog(a)gmail.com> wrote: >>> >>>> Hi Joakim, >>>> >>>> I just helped debugging an issue for Frederic and found a really interesting behavior. Please confirm or correct me. >>>> >>>> Observation: if the app is sent to background, the advertising continues but the advertisement data is not sent in the packages >>>> >>>> Effect 1: Backgrounded apps cannot be discovered by clients that filter for services. When a client uses scanForPeripheralsWithServices, the peripheral will be found but callback not happens in the app as the service filtering criteria will not be satisfied >>>> >>>> Effect 2: Backgrounded apps will never be discovered by clients that started scanning while the app was in background. If a client starts scanning while the app is in the background, CoreBluetooth finds the peripheral but callback does not happen. Then when the app comes to foreground and advertisement data is sent again, CoreBluetooth will not invoke the callback as it thinks it already provided the callback for that. (Discovery may happen only when the BLE address is changed (every 15 minutes or so)) >>>> >>>> I think this phenomenon can explain many recently reported issues too. >>>> >>>> Your help is much appreciated. >>>> >>>> Regards, >>>> Andras >> >> On 2012.10.17., at 21:25, Zsombor Papp <zsombor.papp(a)logicallabs.com> wrote: >> >>> Hi, >>> >>> I am finding that if I invoke scanForPeripheralsWithServices with a nil parameter for services, it works fine in the background, but if I specify a service UUID then it won't discover the service. This same behavior is mentioned here: >>> >>> http://stackoverflow.com/questions/9896562/what-exactly-can-corebluetooth-a… >>> >>> although that post is more than 6 months old now and describes iOS 5.0.1 behavior. Can anyone confirm that the same behavior/limitation still applies to iOS6? >>> >>> Thanks, >>> Zsombor >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com >>> >>> This email sent to allprog(a)gmail.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Scanning for specific service IDs in the background
by Zsombor Papp 19 Oct '12

19 Oct '12

Hi Andras, Thanks, Zsombor On 10/17/12 1:09 PM, Andras Kovi wrote: Hi Zsombor, I described this issue a few weeks ago and haven't got any response yet. Here's my observation and I think you bumped in this issue: Begin forwarded message: On 2012.09.28., at 22:14, Andras Kovi <allprog(a)gmail.com> wrote: Hi Joakim, I just helped debugging an issue for Frederic and found a really interesting behavior. Please confirm or correct me. Observation: if the app is sent to background, the advertising continues but the advertisement data is not sent in the packages Effect 1: Backgrounded apps cannot be discovered by clients that filter for services. When a client uses scanForPeripheralsWithServices, the peripheral will be found but callback not happens in the app as the service filtering criteria will not be satisfied Effect 2: Backgrounded apps will never be discovered by clients that started scanning while the app was in background. If a client starts scanning while the app is in the background, CoreBluetooth finds the peripheral but callback does not happen. Then when the app comes to foreground and advertisement data is sent again, CoreBluetooth will not invoke the callback as it thinks it already provided the callback for that. (Discovery may happen only when the BLE address is changed (every 15 minutes or so)) I think this phenomenon can explain many recently reported issues too. Your help is much appreciated. Regards, Andras On 2012.10.17., at 21:25, Zsombor Papp <zsombor.papp(a)logicallabs.com> wrote: Hi, I am finding that if I invoke scanForPeripheralsWithServices with a nil parameter for services, it works fine in the background, but if I specify a service UUID then it won't discover the service. This same behavior is mentioned here: http://stackoverflow.com/questions/9896562/what-exactly-can-corebluetooth-a… although that post is more than 6 months old now and describes iOS 5.0.1 behavior. Can anyone confirm that the same behavior/limitation still applies to iOS6? Thanks, Zsombor _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com This email sent to allprog(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com I did see your message to Joakim. It seemed to me that you were describing a scenario that was different from mine, in that in your case the peripheral is in the background. Is that correct? My observation, and what's described in that stackoverflow post, was that the central running in the background won't discover the peripheral even if the peripheral advertises the service UUIDs. However, I just tried this again and now I do get the didDiscoverPeripheral message. Also, I tried the scenario I believe you are describing (start advertising on the peripheral, send it to the background, and then start scanning on the central), and that works, too. So maybe this is not broken per se, just unreliable...? By the way, I wasn't quite sure what you meant by this: "the peripheral will be found but callback not happens". How do you know without the callback that the peripheral was discovered?

1 0

Re: CoreBluetooth Debugging Issue
by Etan Kissling 19 Oct '12

19 Oct '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

CoreBluetooth Debugging Issue
by Constantijn Schepens 19 Oct '12

19 Oct '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is it possible to run CBPeripheralManager in background?
by Khaos Tian 19 Oct '12

19 Oct '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Is it possible to run CBPeripheralManager in background?
by Jimmy Adler 19 Oct '12

19 Oct '12

Hi, I want to develop an application that acts as a peripheral such as a heart rate monitor would do. That is: I want it to continuously send out advertisement data and to be ready to accept incoming connections from CBCentralManagers. Is it possible to do this in the background, or does the application have to be active? I know it is possible to implement the CBCentralManager to run in the background, so the question is if there is similar support for CBPeripheralManager. Br, Jimmy _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0