November 2012 - Bluetooth-dev

Re: Reading voltage value from BTLE device
by Etan Kissling 09 Nov '12

09 Nov '12

Constantijn, The problem seems to lie in your casting operation. As you are reading a float value into an integer, you will get a wrong number. This is because floating point values have a different bit representation than integer values. When you cast an int to a float, you won't reinterpret the same bit representation as a float. Instead you generate a new floating point value with the same value as your int, that was already wrong. One way to fix it would be to simply read into the float directly instead of doing the workaround with the int. Another option would be to cast like this: float result = *((float *)(&val)) in order to ensure that the value is not changed in the casting process. Etan On 07.11.2012, at 22:29, "Constantijn Schepens" <constantijnschepens(a)me.com> wrote: > Hi there, > > I am working with a custom bluetooth profile which is designed to store multiple voltage values in its GATT database. (BLE112 using BGScript to be specific) This all works correctly. My iPhone connects correctly as well as finds characteristics correctly. My issue arises when I try to read the values of my characteristics. I just am not managing to read the value that is in the GATT database. It always comes out with really large (but consistently so) numbers, yet I cannot understand why because I feel I am reading the correctly number of bytes. The GATT database stores these values (coming from an ADC) in 4 bytes. The code I am currently trying to use(based on the TemperatureSensor example) is: > > CGFloat result = NAN; > int32_t val = 0; > > {sensorZeroCharacteristic.value getBytes:&val length:sizeof(val)]; > result = (CGFloat)val; > > Can anyone see what I might be doing wrong or just have a better(correct) way of doing this? > > Thanks in advance! > 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

Re: Resetting CentralManager to re-detect previously detected devices
by Etan Kissling 09 Nov '12

09 Nov '12

Could you elaborate why exactly you need to receive multiple callbacks from the same device? I guess that you could also connect to it once you find it, and then issue another connect request when it disconnects, if you want to detect proximity to the device. Connect requests are performed in background and also when the peripheral is not in range they just sit there waiting for proximity. This way you don't have to scan for the device in order to detect if it is there. Hoping that this may help you. Etan On 07.11.2012, at 22:17, "Nick Moen" <NickM(a)npe-inc.com> wrote: > Thanks Andras, > I know for a fact that does work. When I receive the > didDiscoverCallBack, I connect to the device, then disconnect, and then > restart the BTLE scan. This all worked great prior to the update to > Xcode 4.5.1 and iOS 6. > > Nick > > -----Original Message----- > From: Andras Kovi [mailto:allprog@gmail.com] > Sent: Monday, November 05, 2012 6:02 PM > To: Rick Mann > Cc: Nick Moen; bluetooth-dev Bluetooth > Subject: Re: Resetting CentralManager to re-detect previously detected > devices > > Unfortunately that flag is ignored in background. This behavior has not > changed in iOS6. > > I haven't seen any "regular" way to implement what you would like. > However, there is a theoretical solution. I have not tried it yet but I > suppose it should work. > When you receive the didDiscoverCallback, the app gets about 10 seconds > to run. During this, you may restart the scanning by stopping it first > and then starting again. > > The question is whether restarting the scan clears out the cache while > the app is backgrounded. > > Cheers, > Andras > > On 2012.11.06., at 0:40, Rick Mann <rmann(a)latencyzero.com> wrote: > >> >> On Nov 5, 2012, at 14:40 , Nick Moen <NickM(a)npe-inc.com> wrote: >> >>> Has there been any update with iOS 6.0 that allows for the reset of > CentralManager so that that same device can be discovered multiple times > in the background? I have a device that I would like to trigger > multiple callbacks to didDiscoverPeripheral in the background. I know > there was no way to do this in iOS5 but I wanted to see if there were > any updates. >> >> There's the CBCentralManagerScanOptionAllowDuplicatesKey you can pass > to -scanForPeripheralsWithServices:options:. Dunno what that does in the > background, but if it's on in the foreground, you get advertising > packets as long as you scan. >> >> >> -- >> 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/allprog%40gmail.co > m >> >> 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/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: Reading voltage value from BTLE device
by Louis Mamakos 07 Nov '12

07 Nov '12

Is the characteristic value in the GATT database really a 32 bit integer? With the BLE112 implementation, if your BGSCript writes less than 4 bytes and the characteristic isn't defined as being a fixed length, the length may shrink to that which was written to GATT database. (Presumably the BGscript writing an integer to the characteristic and not a floating point value.) Louis Mamakos On Nov 7, 2012, at 4:26 PM, Constantijn Schepens <constantijnschepens(a)me.com> wrote: > Hi there, > > I am working with a custom bluetooth profile which is designed to store multiple voltage values in its GATT database. (BLE112 using BGScript to be specific) This all works correctly. My iPhone connects correctly as well as finds characteristics correctly. My issue arises when I try to read the values of my characteristics. I just am not managing to read the value that is in the GATT database. It always comes out with really large (but consistently so) numbers, yet I cannot understand why because I feel I am reading the correctly number of bytes. The GATT database stores these values (coming from an ADC) in 4 bytes. The code I am currently trying to use(based on the TemperatureSensor example) is: > > CGFloat result = NAN; > int32_t val = 0; > > {sensorZeroCharacteristic.value getBytes:&val length:sizeof(val)]; > result = (CGFloat)val; > > Can anyone see what I might be doing wrong or just have a better(correct) way of doing this? > > Thanks in advance! > 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/louie%40transsys.com > > This email sent to louie(a)transsys.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

Reading voltage value from BTLE device
by Constantijn Schepens 07 Nov '12

07 Nov '12

Hi there, I am working with a custom bluetooth profile which is designed to store multiple voltage values in its GATT database. (BLE112 using BGScript to be specific) This all works correctly. My iPhone connects correctly as well as finds characteristics correctly. My issue arises when I try to read the values of my characteristics. I just am not managing to read the value that is in the GATT database. It always comes out with really large (but consistently so) numbers, yet I cannot understand why because I feel I am reading the correctly number of bytes. The GATT database stores these values (coming from an ADC) in 4 bytes. The code I am currently trying to use(based on the TemperatureSensor example) is: CGFloat result = NAN; int32_t val = 0; {sensorZeroCharacteristic.value getBytes:&val length:sizeof(val)]; result = (CGFloat)val; Can anyone see what I might be doing wrong or just have a better(correct) way of doing this? Thanks in advance! 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

RE: Resetting CentralManager to re-detect previously detected devices
by Nick Moen 07 Nov '12

07 Nov '12

Thanks Andras, I know for a fact that does work. When I receive the didDiscoverCallBack, I connect to the device, then disconnect, and then restart the BTLE scan. This all worked great prior to the update to Xcode 4.5.1 and iOS 6. Nick -----Original Message----- From: Andras Kovi [mailto:allprog@gmail.com] Sent: Monday, November 05, 2012 6:02 PM To: Rick Mann Cc: Nick Moen; bluetooth-dev Bluetooth Subject: Re: Resetting CentralManager to re-detect previously detected devices Unfortunately that flag is ignored in background. This behavior has not changed in iOS6. I haven't seen any "regular" way to implement what you would like. However, there is a theoretical solution. I have not tried it yet but I suppose it should work. When you receive the didDiscoverCallback, the app gets about 10 seconds to run. During this, you may restart the scanning by stopping it first and then starting again. The question is whether restarting the scan clears out the cache while the app is backgrounded. Cheers, Andras On 2012.11.06., at 0:40, Rick Mann <rmann(a)latencyzero.com> wrote: > > On Nov 5, 2012, at 14:40 , Nick Moen <NickM(a)npe-inc.com> wrote: > >> Has there been any update with iOS 6.0 that allows for the reset of CentralManager so that that same device can be discovered multiple times in the background? I have a device that I would like to trigger multiple callbacks to didDiscoverPeripheral in the background. I know there was no way to do this in iOS5 but I wanted to see if there were any updates. > > There's the CBCentralManagerScanOptionAllowDuplicatesKey you can pass to -scanForPeripheralsWithServices:options:. Dunno what that does in the background, but if it's on in the foreground, you get advertising packets as long as you scan. > > > -- > 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/allprog%40gmail.co m > > 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: Bluetooth LE problems with new iOS devices?
by Etan Kissling 06 Nov '12

06 Nov '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: Bluetooth LE problems with new iOS devices?
by Borna Vojdani 06 Nov '12

06 Nov '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: First received advertisment data doesn't contain local name
by András Kovi 06 Nov '12

06 Nov '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: Bluetooth LE problems with new iOS devices?
by Michael Mallinson 06 Nov '12

06 Nov '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: First received advertisment data doesn't contain local name
by Etan Kissling 06 Nov '12

06 Nov '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