I have a idea that requires connecting an ios device to a Raspberry Pi without the end user having to do anything special. The device will not be connected to an existing wifi network so BT or wifi hotspot seem to be my only options, BT preferred.
I'm aware that Apple does require some sort of BT hardware approval which I wont have I'll be using generic BT hardware. Once a connection is established I then want to be able to request data or call API's running on the Raspberry PI.
Does any of this sound achievable and are there any links that may help.
There are two flavours of Bluetooth: the so-called Bluetooth Classic, and the newer Bluetooth Low Energy (also called Smart Bluetooth or Bluetooth 4.0, though this is actually incorrect as BT 4.0 includes both Classic and Low Energy).
On iOS, Bluetooth Classic devices do indeed need to go through specific processes (MFi), or use an existing BT protocol supported by iOS to be used.
However, you can connect to any Bluetooth Low Energy (BLE) device, without any need for MFi, approval, or support by iOS. This is done though the Core Bluetooth framework.
As long as Bluetooth is enable in the iDevice, you can connect to a BLE device without any user interaction (though UX usually dictates doing so, so a user can actually select a specific device if there are many "matching" devices in range).
Related
I am writing an app for iOS that needs to receive data from a Bluetooth device (classic Bluetooth, not BLE). I need a pretty fast data transfer, 1Mbit/s or faster if possible. This already works using SPP in Android.
Apple only supports some Bluetooth profiles as listed here: https://support.apple.com/en-us/HT204387 I think these profiles are the only ones supported without being in the MFi program. MFi is too difficult to deal with so I would really like to avoid it. SPP is of course not available.
Of these profiles, PAN and maybe A2DP and HFP seem likely to be usable for bulk data transfer. A2DP or HFP would be a hack as they are really not designed for non-audio data. This seems to leave PAN.
How can an iOS app transfer data from a classic Bluetooth device using PAN? I would like the app to connect and somehow establish a data connection. This may be over IP (like tethering or reverse tethering using PAN) or non-IP. I want something which behaves a lot like the SPP profile, in other words a bidirectional serial link between the two sides.
Note: The Bluetooth device on the other side of this can do anything that is needed (I am writing the device firmware at the same time using a bluetooth stack, probably the TI dual-mode stack). Extra bounty if you can give me example of PAN tethering using any Bluetooth stack (TI, Synergy, dotstack etc).
See also: Is possible to communicate via Bluetooth PAN in iOS with tethered devices
I have a specific requirement to communicate an iOS device with a wifi/bluetooth enabled device. At this moment, I'm confused with some points and requires an expert advice.
Can I use adhoc wifi method for communicating? but in this case, can I connect to another network? On my research, I found no so I'm opting for Bluetooth.
If I go in bluetooth communication,
Do the device need MFI licensing or can we use classic bluetooth?
From few blogs I found out that Bluetooth low enrgy devices with 4.0 can be used to communicate with ios without licensing. Will this work?
PS: My requirement is to send strings of data to and fro from the ios and other wifi/bluettoth enabled devices.
An iOS device can only be connected to a single Wi Fi network at a time, so an Ad-hoc network connection probably won't work for you.
If you join the MFi program you can use the Wireless Accessory Configuration (WAC) feature to simply the process of connecting your device to the user's existing network.
If you use Bluetooth Low Energy/Bluetooth Smart/Bluetooth 4.0 then you don't need to go through the MFi program, but you are limited to iPhone 4S and later and iPad 3 and later. If you use "classic Bluetooth" (Say Bluetooth 2.1 Serial Port Protocol) then it will work with all devices but you need to go through MFi.
Bluetooth Low Energy isn't great for high data volumes (say video streaming) but is fine for smaller amounts of data (you talk about "strings" so it will probably be suitable for you).
The other advantage of BLE is that it is independent of the iOS device's Internet connection so the user can cary the BLE device around and maintain communication regardless of their WiFi connection.
I'm developing a stereo headset with Bluetooth using the classic profiles (HFP, A2DP, AVRCP) as one would expect Ina stereo headset. However, I want to deploy a remote control app for iOS, and use it simultaneously to the other classic links, but the dual-mode chipset I'm working with in my design does not behave as I'd expect;
The headset is setup as a peripheral, letting the iOS device act as central. As such, the peripheral advertise its BLE services (with my specific 128-bit UUIDs) and all is good. I can browse the peripheral from any central, but only when I'm not connected with classic profiles (e.g., while not streaming audio).
My device does not seem to be able to advertise BLE, while connected with HFP and/or A2DP! However, I have seen demos of the same chipset acting as BLE central, scanning and connecting to other BLE peripherals, while simultaneously streaming audio via A2DP. However, in that setup the device was acting as A2DP sink connected to an iPhone, while scanning/connecting via BLE to a third unit acting as BLE peripheral. Hence, not point-to-point with both Classic and Smart Bluetooth to the same device.
Is there a dual-mode constraint that one cannot act as peripheral while supporting/connecting to Bluetooth Classic profiles? And that only Central-mode is supported in that case?
FYI, I'm using CSR's 8670 chipset.
UPDATE
New answer added. My apologies for not clarifying/cleaning-up my previous answer until now -- time flies!
Well, after digging down into specs and trying to understand things more clearly, I've found the answers I was looking for, even though I would have preferred to more optimistic answers... ;(
Nevertheless, let's get to it; the Bluetooth spec for 4.0 (BLE) says that;
Dual-mode gadgets cannot act as BLE peripheral and advertise its
presence while still being connectable in "Classic" Bluetooth using
BR/EDR.
Furthermore, CSR source-code examples for the CSR8670 dual-mode chipset I'm using all behave in the same say; BLE advertisements as peripheral are disabled when any classic BT-link is connected. Instead, the CSR source code promote that the device should act as the BLE central instead, allowing other BLE peripheral units to advertise and connect to it, all fully doable while streaming audio (acting as A2DP sink).
This does not suite my setup at all since;
BLE centrals consume more power than BLE peripherals, and my device needs to conserve energy
The dual-mode "combo"-problem of combining a BR/EDR-device with BLE peripheral functionality just moved to the phone instead, which will not work any better since we cannot expect Apple (or anyone else) to violate the BLE spec.
Instead, the recommended approach is let my stereo headset skip BLE entirely and use GATT over BR/EDR instead, also known as advertising via "vanilla", which makes sense really; I mean, I already have an ACL-link setup between two devices, why should I need to kick any sort of discovery mechanism?
Again, the Bluetooth SIG comes in handy;
https://developer.bluetooth.org/TechnologyOverview/Pages/GATT.aspx
GATT and ATT are not transport specific and can be used in both BR/EDR
and LE. However, GATT and ATT are mandatory to implement in LE since
it is used for discovering services
So, the SIG says "yes" to using BR/EDR as transport for GATT, but the question then instead becomes; how can I then get access to that connected BR/EDR device from within my iOS-app, where the typical scenario is to use CBCentral to scan, discover and connect to a CBPeripheral? The answer is simple; you cannot, since iOS 7.0 does not (yet?) support GATT for BR/EDR;
https://www.bluetooth.org/tpg/showDeclaration.cfm?3A000A5A005C5344535D5414403B0C0D0E2405022413010E57503F202A5A72
So, to sum things up; if you want to have a peer-to-peer setup between two dual-mode Bluetooth devices, using BOTH Bluetooth Classic profiles AND Bluetooth Smart services/characteristics, you should use GATT over BR/EDR, which is no-go for Apple-devices, but might be supported by Android (don't know, will port app to Android eventually though, but regardless it's not a big deal for Android since worst-case will imply a fallback to SPP and a simple byte-protocol to do the work that I need to get done).
That's that. Hope that I've helped someone ;)
/Markus
You learn as long as you live, I suppose, and this question's answer is NOT that it's not supported which I claimed earlier (based on what I thought I knew).
The short and clean answer to dual-mode and headset development on CSR-chipsets is simply that it was a constraint in the CSR bluetooth stack on earlier SDKs.
The Bluetooth SIG has never not supported dual-mode acting as Peripheral while being connected via classic links to the same device. On the contrary, it clearly spec. how such interoperability should be carried out -- but that doesn't always mean that all BT-stack implementations out there are capable of such functionality.
Hence; Using the latest devtools and the latest Bluetooth firmwares/stacks from CSR has resolved all issues and dual-mode is now fully, and actually quite nicely I might add, supported on the CSR8670/75 chipsets.
I am also using the CSR8670 device.
It have it working. Both a BLE peripheral and audio.
You need to be using ADK 4.0.0 by CSR.
Bluetooth 4.1 and Bluetooth 4.0 are different. For what you said about Bluetooth 4.0 is correct, but your chip can do Bluetooth 4.1.
4.1 allows such connections.
I also added "Dual mode" flags to the advertising packet.
There are a few conditions, such as a connection Interval of at least 90 miliseconds highly recommended so you dont mess with the audio.
Good luck!
I would like to build an app that requires bluetooth connection. The Bluetooth HC05 module is connected to Arduino. I want to know what framework (or other related things) that I need to build an app that can connect to this Bluetooth module.
Still have no idea how to start. Anyone could help?
Unfortunately the answer might be "you can't do that".
iOS only supports the following Bluetooth profiles: HFP, PBAP, A2DP, AVRCP, PAN, HID and MAP. None of those can be used inside an app to communicate to your Arduino.
For the useful profiles like Serial Port Profile (SPP) and all arbitrary bluetooth communication you have to add an authentication chip to your Arduino. Unfortunately you can't buy these chips unless you have a MFi membership. And you won't get into the MFi program unless you are a company with a concrete product (mass market scale) in mind.
Fortunately, we now have Bluetooth Low Energy. Bluetooth LE can easily be used in iOS apps, without all the MFi hassle. So you should get a Bluetooth 4.0 module for your Arduino.
The framework that is used for Bluetooth 4.0 communication is called CoreBluetooth. You will find documentation, sample code and WWDC videos in the iOS Developer Center. Start with the Core Bluetooth Programming Guide
Aim
I want to pass data from iOS device to a PC using Bluetooth. The data should look as a keyboard input to the desktop. I have been doing some background research about the same and thought of using any HID keyboard emulator dongle. One can pass the data over using the Bluetooth and the dongle will show it as keyboard input to the PC.
Outcome of some related research:
Initially I tried to pair an ios device with a windows PC directly. I was unsuccessful. After some research and reading many questions, it turns out that an ios device can only be paired with a MFI( Made for ipad/ipod/iphone) compliant device/accessory, i.e those which have signed NDA with Apple and have joined the MFI program. It can also ofcourse be paired with a Mac.
Question:
With the release of Bluetooth 4.0, it seems that this restriction
can be overcome and it can be paired with any device compliant with
BLE 4.0. Is it so?
If one can use a Bluetooth to HID keyboard emulator dongle using BLE 4.0, is it possible to pair an iOS device which support BLE 4.0 with it and how?
Has anyone tried any particular HID keyboard emulator dongle supporting
BLE 4.0? If yes then any preferences. I came across Bluegiga USB Dongle but not sure if it will solve the purpose.
I would be thankful for your input.
Even with a Bluetooth 4.0-compliant device, communication via standard ("high energy") Bluetooth with an iOS device is still only allowed with MFi-compliant devices. Bluetooth Low Energy communication with iOS devices is the part that's now completely open and unrestricted by Apple. If you wish to send data to another computing device (Windows, Mac, Android, etc.), Bluetooth LE is what you're going to need (short of someone reverse-engineering the Bonjour over Bluetooth PAN connections).
As of iOS 6.0, iOS devices can make themselves look like Bluetooth LE peripherals, so desktop computers set up as Bluetooth LE central devices can connect to them. You could put together your own profile for communication, since you'd control the iOS and Windows sides of things, or you could make your iOS device mimic a standard keyboard, heart rate sensor, etc.
As far as compatible dongles, the answers to this question list several Bluetooth LE dongles that are known to work with Core Bluetooth on the Mac. The CSR ones seem to be the most frequently cited there and among other people I've talked to. I can't speak for Windows support, but I'd assume there would be driver support there, and I hear Windows 8.1 expands support for Bluetooth LE.
I do have the BLED112 (the Bluegiga USB dongle), and that shows up as a comm port when its drivers are installed. You might talk to that in a slightly different way than you would one of these other Bluetooth LE dongles. I know Bluegiga uses it on the Windows side to capture a little more data than I think you'd normally get from one of these other dongles. The other dongles might present a more universal interface for interacting with Bluetooth LE on the Windows side.