I built a custom ARM device based on the nRF52 SOC that handles BLE 5. I wrote a custom app in SWIFT/X-Code/IB using Core Bluetooth framework and am unable to stream data from the ARM device any faster than about 12 kbs. Using packet sniffers I can see that the ARM device sent all of the packets in realtime, but the iPhone doesn't read them any faster than a few times per second. On rare occasion the iPhone reads everything quickly. The Bluetooth connection negotiates to a 12-24 ms latency. I am using Nordic nRF52 SDK version 16. The iPhone is not connected to any other BLE devices at the time.
Has anyone else had this issue? If it is helpful, I can post the code used on the ARM device and the XCode code.
As your using the nordic board there are several things to check to "speed up the process". Firstly I assume you are sending via notifications. Secondly you need to know what forms your data rate. They are:
Number of bits per notification
Connection interval
Events per connection interval
Data communication type
Also you can queue up-several packets to store until they are sent via the notification(filling a buffer).
So some useful settings. First and foremost maximise the data you are sending per packet. E.g if you are sending 10 bytes of data send more, this will be limited to the maximum data size on the nordic board (247). Then increase the GAP length. So some settings I recommend to start are:
Go to sdk_config.h
Change NRF_SDH_BLE_GAP_EVENT_LENGTH to 400(think the default is 6)
Increase the MTU size to 247
Then run on the board, you will probably get an error saying change ram and start location. This will be printed to a terminal. You can do this by going:
Project
Options
Common
Press up arrow till under project
Linker
Section placement macros.
From there change your ram start and allocation variables to what is printed in the terminal / putty / debugger. Also not sure about the APIs for iphone apps but android has a function to set the bluetooth hardware into high power mode, this increased my throughput whilst transferring data, just disable it after data transfer. The APIs your using may have a similar function.
For reference code there is an example called maximum_throughput in the sdk, this should be a good reference point.
I see questions surrounding issues such as "Device Unsupported" in many posts on this website and on the internet, so I feel like the problems I am having are not unique.
What perplexes me (and trust me I have searched all day) is that I recently bought a new Macbook Pro computer (surely the BT on this thing is LE), upgraded to Mavericks, and am using Xcode 5. But no matter, what sample code I download, whether from the BT SIG or CSR, etc., I always get the same basic errors (on the iOS Simulator):
Something to the effect of "Device Unsupported" AND
Something about how it can't run because it's not powered on (and I did try to work around by wrapping the central.state call in an if block)
So, are the people like me who are starting to code Bluetooth today just screwed if we don't have LE devices? Did all of the BT code prior to 4.0 fall off the face of the earth or get deprecated?
Is there a simple way to force my code to run in some type of "non-LE" mode?
As for the code I'm using, I downloaded the Quick Start kit from the BT SIG, but nothing works, even simple scan programs that I have found. Ugh, any ideas out there?
My ultimate goal is to write something that will run without errors, load on my iPhone 4, and scan and pair with my car's stereo and grab all of the peripheral advertisements that it is sending out to see what all I can do with (to) the stereo.
Thanks all.
While your computer does have Bluetooth Low Energy/Bluetooth 4.0/Bluetooth Smart (they are all different names for the same thing) capabilities, these are not available to the simulator. A while ago you could add an additional BT4.0 dongle to the Mac and then access that from the simulator, but this is no longer supported - see Does the iPhone simulator in Xcode support Bluetooth Low Energy?
You can develop BT4.0/BLE code in Xcode for OSX with just your computer, but if you want to develop and test iOS code you will need a BLE capable iOS device (iPhone 4S or later, iPad mini/3rd gen/Air or an iPod Touch 5th generation)
Access to non BT4 devices is only via the Apple MFI program, with the exception of a few generic profiles, such as handsfree & A2DP streaming - but these are exposed to your program as audio devices, not as Bluetooth devices.
If you have an iPhone 4S (not iPhone 4) then you can use the LightBlue app from the App Store to see if your car stereo is advertising any BLE services (which it probably isn't).
crawdaddy18, Bluetooth Smart/4.0/LE are fundamentally different technologies then what we'll call Bluetooth Classic (2.0/2.1/EDR/BR...this is the stuff you are referring to with your car audio example). If you want to see what's going on with your car stereo, see what profiles it supports (should be listed in the documentation). Then take a look here:
https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx#Profiles
This page lists all of the 'classic' profiles. You should find the ones that match your car on the list. You'll then know what functionality your car stereo supports.
Then, it's off to the races with OS documentation to look at the object models for classic Bluetooth. Usually these are either supported by an object model that represents the profile or are wrangled through RFCOM somehow...but each OS is a bit different.
But most of the tools that are out there, including the Application Accelerator, are geared to let you explore LE (Smart) devices out there. If you want to use something like the Application Accelerator to view non-LE devices, you'll have to re-jigger the code to switch the object models that you use in the OS' SDK. The reason that most recent tools you are finding now are geared towards the LE side of things is that that is where the massive growth in appcessories (and the Bluetooth industry) is heading. But there are TONS of sample code out there to help to create an app to scan and connect to classic Bluetooth devices as well.
I have a Bluetooth Low Energy (BLE) app that communicates with a BLE device through open connection. I am using CoreBluetooth library. After I upgraded my iPhone to iOS 7 and XCode to XCode 5. I recompiled my Bluetooth Low Energy app and found it no longer working. The connection is successful. The services and characteristics are discovered with no problems. Even the reading of the characteristics seems fine. But writing to a characteristic which should trigger some action on the BLE device has not any effect.
If I use XCode to download the same app to another iPhone with iOS 6, everything works fine. So I can determine the problem may be something with iOS 7 instead of XCode 5’s recompiling. It’s also possible XCode 5 prepares a different app for iOS 6 device even from a same project because I can see the app’s appearances are different on two devices.
So what’s changed from iOS 6 to iOS 7 that makes writing to characteristics failed?
I ran into the same problem, the issue is with the the firmware not your iOS Code. iOS6 was more relaxed with the characteristics types, but iOS7 is more stringent.
The WriteWithoutResponse flag for the Characteristic has to set explicitly to work with iOS7
I had used RedBear's Biscuit for Arduino at my startup to test our product, which worked wonderfully with iOS6 but when the app migrated to iOS7, the writes would fail quietly.
More detailed discussion is here (see update from Mattj949) # https://redbearlab.zendesk.com/entries/25031402-BLE-Mini-and-iOS-7
There are some Apple Threads on this issue, http://lists.apple.com/archives/bluetooth-dev/2013/Aug/msg00046.html and http://lists.apple.com/archives/bluetooth-dev/2013/Aug/msg00050.html
I would like to start developing for iOS. Coming from an Android developing background, I know that the more types of devices you can get your hands on, the better testing will be, as all devices have wildly different specs, and what may work perfectly in your test device may not even run in another one, let alone look good.
I know that testing on the actual device is very important, as there are many limitations on what you can test on an emulator, so I've decided to get an actual device.
However, there are also tons of devices available in the iOS world! There's the iPod touch, the iPad and the iPhone, each in several different generations and configurations (8GB version vs 16GB version, WiFi version, 3G version, etc.). Not also the screen sizes, but also the aspect ratio is very different across devices, and also the included sensors.
I think that getting an application to run in varied devices should not be difficult, but is it necessary to actually test on all the device types you plan to support? Apple is not renown for its low price, and I would like to keep the starting costs as low as possible.
So, to conclude: Is it necessary/recommended to test on as many device types as you can in the iOS development world?
A small clarification: I'm specially asking if it is possible for there to be compatibility issues related to a specific device/family-of-devices that I would not be able to catch either by testing on the emulator nor a totally different device.
Generally speaking, the major differences in capabilities between testing on the simulator and testing on a device are:
The simulator does not use exactly the same sandboxing as the device. So, for instance, if your provisioning profile is missing your Passbook credentials, this problem will show up on a physical device but not on the simulator.
The simulator doesn't generally support GPS, multitouch, push notifications, Bluetooth, and some other specific features.
On a non-retina display, the simulator view for an iPhone 5+ or (especially!) a retina iPad will be nigh unusable at 100% because its size will exceed the size of your screen.
There are a few, very rare, crashes that occur only on the simulator and a few that occur only on the device.
The simulator does not always support the earliest iOS versions your app supports. For instance, the current version of Xcode (which you must use if you want to build for the latest iOS version) only has simulators from 5.0+ available.
Certain profiling with Instruments is, as far as I can tell, only available in the Simulator.
Now, in my specific case, I try to test on one of each screen resolution I support and one of each major OS version I support.
This boils down to the following array of test devices:
(480x320) iPhone 3GS running 4.3.3
(1136x640) iPod 5gen running the latest 6.x
(960x640) iPhone 4S running 6.0
(1024x768) iPad 1st gen running 5.0
(2048x1536) iPad 4th gen running the latest 6.x
Note that the iPad mini is the same resolution as the iPad 1st gen.
(My choices are skewed towards later iOS versions since I like to implement integration with all of Apple's snazzy optional features as they roll them out. It would probably be a more balanced assortment if one of the 6.x devices were running 5.1 instead.)
If you don't need to support 4.x, I would personally advise against it, since iTunes Connect no longer collects crash reports for it and the simulator no longer offers it. Of course, only you can decide whether you really need to or not, and if you do, focus a lot of your testing there as Xcode does not warn you if you are using APIs that were only introduced in 5.0, which will crash any device running 4.x.
Please note that there are ways to (with significant preparation) downgrade the version of iOS on a device, so if you really want to test more versions than you have devices for, you can (with a lot of effort). But you're probably better off cultivating a strong pool of beta testers for this, anyway.
Whilst it's obviously great to test on all possible devices, the iOS ecosystem is much tighter than Android, so you can narrow down the field somewhat.
You can start by limiting your target iOS versions. That will anyway cut out a number of older devices. iOS6 share of all iOS devices is now probably around 75% 4 months after release; iOS5+iOS6 upwards of 90%. If you are just now starting to develop for iOS, you could probably just target iOS6.
That means your minimum hardware platform is iPad2 / iphone3GS / ipodTouch4
Total list of devices
iPad: 2 3 4 mini
iPhone: 3GS 4 4S 5
iPod: 4 5
Ten devices.
But you won't need to test them all. You could sensibly narrow it to...
iPad: mini + one of the retina models
iPhone: 3GS + 5
for everyday testing.
Obviously if you do want to be more back-compatible, just replace the lower-end testing model for a lower-spec device (iphone 3, iPad 1).
The difference in storage capacity (8GB vs 16GB for example) will be mostly immaterial.
There are some hardware features you will have to pay special attention to, depending on your project. The obvious one is retina vs non-retina displays. Hardware features for location services is particularly nuanced between models.
Lowendmac have a pretty thorough iphone comparison chart...
I think that getting an application to run in varied devices should
not be difficult, but is it necessary to actually test on all the
device types you plan to support?
That depends a lot of what kind of apps you intend to build. For example, universal apps run on both small- and large-screen devices but may present themselves differently on each, so you'd want to be able to try both. Many apps target iPad specifically, so obviously testing on small devices isn't necessary. iPod Touch and iPhone are very similar, so testing on one or the other is often sufficient.
In short, you don't have to own every version of every device, and you don't probably don't have to test on every single version of iOS that's ever been released. But you do want to get your product tested on as many different devices and operating system versions as you can. So, cultivate a group of beta testers who will help you out by trying your app on their devices. The iOS developer program lets you add up to 100 test devices to your account precisely so that you can get your app tested in lots of different circumstances.
Testing on the iPod touch is generally not worth it.
In the iOS world, there is generally the iPhone/iPod, the iPhone 5/iPod 5th generation, and the iPad.
So, that is a total of 3 screen sizes.
If you plan on targeting more than the latest OS (iOS 6), that is where the complexity of testing comes in. Simply targeting iOS 5, and iOS 6 nearly doubles the amount of targets you need to test for.
I try and keep it simple. I test on my iPhone 5, and my iPad. Both of those run iOS 6. For iOS 5 and the small iPhone, I rely on the simulator.
I develop for both Android and iOS, so I get where this question is coming from. I have the luxury of being able to develop on most of the different iOS devices and I would say that in most cases I would feel comfortable testing on the least advanced device my user will be using. If it runs smooth on a iPOd 3rd gen then it is going to run very smooth on an iPhone 4S, 5, etc. For the different screen height for the iPhone 5, the simulator works very good with laying it out.
Things you will need to consider is if your apps have the option to use certain feature only a phone would have, like making calls. Also if you want to make a iPad or universal app, it would be very handy to have an actual iPad, but the simulator does work very good.
My objective here is to create a connection between a device running iOS to a device running Mac OS X, via bluetooth. I know that I might be able to use CoreBluetooth for this but I don't understand how since I don't see a method to setup a service on the iOS device and broadcast it as an available service for a device running Mac OS X. In other words, I simply want to setup a connection to get the iOS device to send data to the Mac OS X device. Also, how would I go about to specify how to setup properties of the service. I've tried researching this stuff but most of the documentation makes little sense to me. The data transfer is small so bluetooth is good enough for the job. I'm trying to avoid Bonjour for this, and the Game center framework for P2P since OS X can't handle that (I think).
In iOS6 the iPhone 4S, 5 and New iPad can work both as Peripheral and as Central in Bluetooth Smart / Low Energy mode.
Try downloading "LightBlue" APP from APP Store. It let's you put the iPhone4S or 5 into Peripheral mode with random Services which you can then read from the Mac (if you have a newer one with BT Low Energy, I use the Retina for that but also the new iMac and Mac Mini got BT Low Energy).
You are correct that Core Bluetooth only give access to Bluetooth Low Energy which doesn't allow for the MFI chip.
Just ran across this today... and just wanted to give another answer to anyone needing to communicate to a non-Bluetooth LE device from your Mac.
The way to go is with IOBluetooth, and IOBluetoothUI.
They are both frameworks for the Mac, and they allow you to communicate with both old bluetooth, and Bluetooth LE 4.0, I believe. Also, I'm pretty positive you can act as a Central and Peripheral Device using this framework.