I've been playing with the Bluetooh sample from the Xcode RFCOMM_SPP which is what would do the job for me so I modified it but the discover devices does not pick a few simpler SPP devices(like a GPS)
I had a similar issue when doing the Android version and after digging I found out if I set up a proper UUID manually I'm on easy street and that got me rolling there really cool
Now back to the MAC I'm trying to see if the same process can be applied I see they have this IOBluetoothSDPUUID which picks a pre-cooked UUID, my guess is that if I do there what I did in Android I'd be able to see and interface with the GPS.
Is it possible to set a UUID manually like adding it to the h files? Or is it blocked for "Made for Apple" devices like in the iPhone?
Are you programming for the MAC or iOS devices (iphone / ipad )
Bluetooth SPP profile is not supported (publicly) on iOS devices.
see this http://support.apple.com/kb/HT3647?viewlocale=en_US
So if you want to do something custom on these devices using non public interfaces, the only way is joining the MFi program
Related
I am currently having some issues with connecting to my peripheral. The bluetooth module in our peripheral does not seem to be advertising a name initially. I've have found that once I connect to the peripheral for the first time it will update the name and my scanner is then able to see the correct name.
I have no understanding why this is the case. I have also tried it using the Swift app we are developing, as well as a range of Bluetooth scanners on iOS and Android so I do not believe that this is an OS or programming error on the scanner side.
Is there a specific parameter that should be set on the peripheral. As I am just the app developer I do not have very much understanding about how the module is handing the process.
Any help would be much appreciated.
Just to confirm the scanner does not see a name for the peripheral until it has connected once. After this it will start displaying the name. Once the peripherals name is changed the old name is still being displayed until I have connected to it once again.
To display the name of device you need to see in advertisementData Dictionary which contains several keys depending on your device, in callback of didDiscoverPeripheral from CentralManager.
- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary<NSString *, id> *)advertisementData RSSI:(NSNumber *)RSSI
You can look for key CBAdvertisementDataLocalNameKey.
If you do not see the name, you can make changes in your firmware to include a name in GATT characteristic .
You can use LightBlue app to verify once. This is a good app on app-store to test your BLE device.
I am developing an app that controls a product's operation. The communication is via BLE. My configuration is
App - Peripheral (iOS, Android)
Product - Central (uses Laird BT900 module)
iOS as a peripheral works fine (pairing and bonding) ; Android PIN pairing works fine, but subsequent bonding (or reconnect when in range) there are a lot of issues and termination of connection. I am using the supported list of devices for Android BLE and I also understand that there are many known issues that come with different manufacturers/chipset vendors
The issue I am getting is, as seen by nrfConnect, is with descriptors. Android app doesnt show descriptors when seen in nrfConnect whereas iOS shows. I do not know what is the difference
Is it a common practice to use a phone as a peripheral ? Or is it a risk - because this is a medical device.
Are there any best practices for Android as a peripheral ?
I have following back up plans in case Android issue is not resolved. I think following would work on any BLE supported phones without having any issues with the variability.
Plan A : PIN pairing on every connection with the product. This is the most secure and most annoying
Plan B : Implement just works pairing with a app layer password before taking control of the product.
Question : Is just works safe and encrypted ? Is it snoop-safe or MITM-safe ?
Thanks in advance!
A few thoughts from your questions:
1a. (From my Android experience) I think its uncommon to have the phone be the peripheral. To my knowledge all iOS devices support peripheral mode but only a very small subset of Android devices are able to support it. I say this because I've been experimenting with BTLE beacons using the AltBeacon library. From this work I have discovered that only certain Android phones can broadcast BTLE advertise packets. Given that BTLE advertising is the first step in initiating a BTLE session I imagine that this prevents many Android phones from being compatible with peripheral mode.
If all of your users can use an iOS device, then you're set, otherwise this may be a problem.
1b) I can't speak to the specific risk of using a mobile device with your medical device, that depends on what the medical device is doing and how you're using the mobile app.
2) See 1a
3) The specific encryption scheme you used is also based on your product's risk profile. I would say that Just Works is not an ideal solution. The just works pairing process is not snoop-safe and can be re-initiated via a MITM. Other than that I can't speak to the strength of BTLE encryption.
I need to get the friendly device name from a ble sensor. I want to find the device and tell the user they are connected to "My Home Sensor" for example. I can find the device, but I don't know how to find that data.
In regular bluetooth, I believe I can use BLUETOOTH_DEVICE_INFO or winsock.
Is there a bluetooth low energy equivalent to bluetooth's BLUETOOTH_DEVICE_INFO?
If possible, could you please provide an example for how to get the information (i.e. device name)?
I'm using Windows 8.1, c++ and visual studio 2013. I've been referencing windows dev docs, but I haven't found anything useful yet.
Thanks!
Assuming that you are able to get connected with the GATT Server, when you parse the GAP profile of the device, you will find an attribute for Device Name under Generic Access Profile (GAP).
This is a list of all the standard GATT Services and their UUIDs. UUID for GAP is 0x1800.
You can look for the list of all the standard Characteristics and their UUIDs. For the Device Name Characteristic, it is 0x2A00.
This explains that the Device Name characteristic is a part of the GAP.
I have requirement of getting an unique identification number programmatically from all j2me supported phones.
As we already know getting IMEI / IMSI in S40 devices is almost not possible, bluetooth MAC address / obex push profile UUID may help. But for this, bluetooth should be turned on in mobile. And I don't know how many devices will support jsr82.
Is there some other unique id which will differentiate j2me devices?
Use the value of System.currentTimeMillis() when the user first starts the app. Unless two users start their app at precisely the same millisecond (v. unlikely), this will be unique.
Just now i got answer from other source:
There are no other unique IDs than IMEI, Bluetooth or WLAN (when available) MAC addresses. Redesign your solution not to depend on such entirely, or so that some ID you generate/assign yourself is sufficient (possibly in conjuntion with a username/password combination).
Any other ideas?
I want to know if the developer team which made the emulator have some information to make bluetooth work in the Android emulator, indicate some links about it, if they have some date for release or if they'll make it works in the future.
as far as I know there is no support in the emulator for bluetooth. And I will have to teach android and bluetooth in some classes. And the students will need to code stuff and test (guess it) in the android emulator.
So I came up with a bare-bone reimplementation of the android bluetooth API on top of tcp. You can find it on here on github.
Basically, you run a tcp-server on your machine, and the emulators will connect through it.
Instead of using the classes in the package android.bluetooth, you just need to use the classes in the package dk.itu.android.bluetooth (and other 2 little modifies).
As for now it supports:
switch on/off the "radio"
discovery devices (only other android emulators)
creating bluetooth services
connecting to bluetooth services
It's not much, but until we got some more from the android guys, I guess there is nothing else around.
Hope it'll be useful, cheers!
The documented bluetooth limitation appears inconsistent with the qemu -bt option. So, how is bluetooth enabled in the emulator so the -bt options can be used, or at least to know that bluetooth is supported?
The target/board/.../BoardConfig.mk having "BOARD_HAVE_BLUETOOTH := true" doesn't provide a bluetooth icon or enable bluetooth. So, how do we turn on bluetooth on the android qemu emulator?
What does it mean that bluetooth is not supported given the -bt option for emulating USB devices that were provided in 2008? The post and limitations are outdated.
The functional limitations of the emulator include:
No support for placing or receiving actual phone calls. You can simulate phone calls (placed and received) through the emulator console, however.
No support for USB connections
No support for device-attached headphones
No support for determining network connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insert/eject
No support for Bluetooth
http://developer.android.com/tools/devices/emulator.html#limitations