Hi Karel,
Out of concerns for the users privacy we have chosen not to support directed Target Addresses.
Thanks, Joakim
On Aug 9, 2012, at 6:45 PM, karel wrote:
Etan, Pierre,
thanks for your input. I am not sure however whether what you have
said relates to
information (Target Addresses) sent in Advertisements.
Advertisements purposely have
no security and that is their purpose. There are valid cases where
the Target Addresses
are used. Referring to section 5.1.5 of the Glucose Profile,
without their use a worker
would have to put all the glucose meters on an RF shielded box,
take them out a few at
a time and scan them until he/she finds the one(s) they are
looking for.
Joakim, sorry for the direct CC. Can you give me any insight to
this issue?
Thanks
Karel
(2012/08/09 22:44), Etan Kissling wrote:
Another problem with UUIDs is, that iOS generates only UUIDs for
devices that it has
been connected to. Therefore, it is not possible to
distinguish between multiple unknown
devices, if no previous connection has been made. However, as
soon as the UUID is
generated, you are not able to get rid of it without doing a
"Reset all Settings", making
debugging hard.
Always expect the CBPeripheral.UUID value to be zero, before
feeding it to a CBUUID
constructor. Otherwise, you will run into memory access
violations.
(Radar 12055261)
One possible solution would be to have a characteristic
that holds a serial number
and putting that value inside your advertisement data.
However, I did not test this method.
Etan
On 09.08.2012, at 12:36, Pierre Bouchet < email@hidden>
wrote: Hi Karel,
I think CoreBluetooth doesn't allow you to access the
bluetooth device address for security reasons. The idea is
to only identify BLE devices by the UUID that the
framework generates for them on the iOS device. So I
suppose it simply discards the addresses sent by your
device.
see: http://lists.apple.com/archives/bluetooth-dev/2012/Apr/msg00046.html
and: http://lists.apple.com/archives/bluetooth-dev/2012/Apr/msg00038.html
PB
2012/8/9 karel <email@hidden>
On scanning for
my device advertising with ADtypes
0x01 «Flags»
0x07 «Complete List of 128-bit Service Class
UUIDs»
0x17 or 0x18 «Public Target Address» or «Random
Target Address»
I get the NSDictionary results below which show only
entries for AD entry of ADtype=0x07
I guess I'm am using iOS V5.something so the «
XX Target Address » features
may not be defined and thus don't pop up in the
AdvData in the callback, but in any case, is there a
header file I could modify or some parser filter
list to which I could add the required 0x17 / 0x18 ?
http://developer.apple.com/library/ios/#documentation/CoreBluetooth/Reference/CBCentralManagerDelegate_Protocol/translated_content/CBCentralManagerDelegate.html
mentions the "advertisementData" contains
CBAdvertisementData* keys ( kCBAdvDataServiceUUIDs,
kCBAdvDataLocalName etc), but
I can't find any documentation on any of this.
Help!!
#didDiscoverPeripheral
#2012-08-09 17:21:03.771 TandDTest1[8669:707] key:
kCBAdvDataServiceUUIDs, value: (
#
"Unknown (<d0d0d0d0 00000000 00000000
deadf154>)"
#
)
#didDiscoverPeripheral
#2012-08-09 17:21:03.774 TandDTest1[8669:707] key:
kCBAdvDataServiceUUIDs, value: (
#
"Unknown (<d0d0d0d0 00000000 00000000
deadf154>)"
#
)
The following is from a Scan response
#2012-08-09 17:21:03.775 TandDTest1[8669:707]
key: kCBAdvDataLocalName, value:
SimpleBLEPeripheral
#2012-08-09 17:21:03.777 TandDTest1[8669:707] key:
kCBAdvDataTxPowerLevel, value: 0
Regards
Karel
|