April 2013 - Bluetooth-dev - lists.apple.com

Connect issue on iOS 6.1.3 & iPhone 5
by Long LI 22 Apr '13

22 Apr '13

_______________________________________________ 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: Any better solutions to BLE caching?
by Louis Gerbarg 19 Apr '13

19 Apr '13

_______________________________________________ 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: Any better solutions to BLE caching?
by Jason Conn 19 Apr '13

19 Apr '13

_______________________________________________ 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: BLE scan under simulator finds service twice
by Etan Kissling 19 Apr '13

19 Apr '13

Rick, The device name is cached by iOS according to a priority list: 1. Name read from Device name characteristic after a connect 2. Name from advertising packet 3. null Note that the name from the advertising packet should be a prefix of the final name in the Device name characteristic. Maybe the physical device already had the name cached, and does not send the second update, as it already retrieved the name. Your app should be able to deal with duplicates even when you don't request them. Etan On 19.04.2013, at 23:08, Rick Mann <rmann(a)latencyzero.com> wrote: > > On Apr 19, 2013, at 12:26 , Andras Kovi <allprog(a)gmail.com> wrote: > >> Rick, this is part of the normal operation. http://lists.apple.com/archives/bluetooth-dev/2013/Mar/msg00063.html >> I guess you can use isEqualTo: to check if the peripheral is new or not. > > Fair enough. But the odd thing is, I wasn't getting these two when run on the device; only on the sim. > > > > -- > Rick > > > > > _______________________________________________ > 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

Re: Any better solutions to BLE caching?
by Rick Mann 19 Apr '13

19 Apr '13

I built the project new under iOS 6. The deployment target is 6.1, base SDK is "latest (6.1)". On Apr 19, 2013, at 14:58 , Etan Kissling <kissling(a)oberon.ch> wrote: > Or could it be that your app's target framework in the Info.plist is still at iOS 5.x? > > Just an idea, although the screenshot states 6.1 in the top left corner. > > On 19.04.2013, at 23:56, Etan Kissling <kissling(a)oberon.ch> > wrote: > >> Rick, >> >> as the didUpdateName method is also missing in your screenshot: >> maybe an Xcode bug? :-) >> >> Etan >> >> On 19.04.2013, at 23:55, Rick Mann <rmann(a)latencyzero.com> >> wrote: >> >>> Wow. I looked for that using the method popup, and didn't see it, which lead me to believe you were speculating about the name. >>> >>> Proof: >>> >>> <Screen Shot 2013-04-19 at 14.55.33 .png> >>> >>> On Apr 19, 2013, at 14:25 , Etan Kissling <kissling(a)oberon.ch> wrote: >>> >>>> Rick, >>>> >>>> the accessory cannot respond to indications, but has to send them ;-) >>>> iOS does the job on the remote side, so it receives the indication when >>>> it is connected and your accessories emits the indication. >>>> >>>> The callback is in CBPeripheralDelegate: >>>> /*! >>>> * @method peripheralDidInvalidateServices: >>>> * >>>> * @param peripheral >>>> The peripheral providing this update. >>>> * >>>> * @discussion >>>> This method is invoked when the @link services @/link of <i>peripheral</i> have been changed. At this point, >>>> * all existing <code>CBService</code> objects are invalidated. Services can be re-discovered via @link discoverServices: @/link. >>>> */ >>>> - (void)peripheralDidInvalidateServices:(CBPeripheral *)peripheral NS_AVAILABLE(NA, 6_0); >>>> >>>> >>>> On 19.04.2013, at 23:07, Rick Mann <rmann(a)latencyzero.com> >>>> wrote: >>>> >>>>> >>>>> On Apr 19, 2013, at 02:36 , Etan Kissling <kissling(a)oberon.ch> wrote: >>>>> >>>>>> Excerpt from https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf >>>>>> The iOS device implements the GAP Service Changed characteristic, because the database contents can change at any time. The Bluetooth accessory should therefore support the Characteristic Value Indication of this characteristic and, upon receiving indications, invalidate its database cache accordingly. See the Bluetooth 4.0 specification, Volume 3, Part G, Section 7.1. >>>>> >>>>> Hmm. That excerpt seems to say that the *accessory* needs to respond to the indication by invalidating its own caches, rather than saying iOS will do the same thing. >>>>> >>>>>> Did not test this, but if it works, you should get a callback in the CBPeripheralDelegate (didInvalidateServices or something similar). >>>>> >>>>> So, there's no such delegate method, but I think the thing to do is get the value change indication for that specific characteristic. I'll try to implement that, and hopefully the caching won't prevent that characteristic from showing up. >>>>> >>>>> Actually, huh. I only change the service when I flash the BLE112, so I don't know how to properly send the update, without sending it every time the thing boots. >>>>> >>>>> >>>>> -- >>>>> Rick >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Rick >>> >>> >>> >> > -- Rick _______________________________________________ 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: Any better solutions to BLE caching?
by Etan Kissling 19 Apr '13

19 Apr '13

_______________________________________________ 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: Any better solutions to BLE caching?
by Rick Mann 19 Apr '13

19 Apr '13

On Apr 19, 2013, at 14:56 , Etan Kissling <kissling(a)oberon.ch> wrote: > as the didUpdateName method is also missing in your screenshot: > maybe an Xcode bug? :-) That's my guess. -- Rick _______________________________________________ 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: Any better solutions to BLE caching?
by Etan Kissling 19 Apr '13

19 Apr '13

_______________________________________________ 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: Any better solutions to BLE caching?
by Etan Kissling 19 Apr '13

19 Apr '13

_______________________________________________ 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: Any better solutions to BLE caching?
by Etan Kissling 19 Apr '13

19 Apr '13

_______________________________________________ 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