I've been developing a Mac OS X application that sends commands continuously over Bluetooth Low Energy to a hardware device. Under Yosemite, the app worked well, with a measured roundtrip latency of 7-12 ms for a command transmission. The command is sent to a custom BLE service in a steady interval of minimum 2 seconds and maximum 0.2 seconds.
Now, I haven't been developing in the last months (the app isn't live yet), then upgraded to El Capitan, and now the same app has a latency of 500-1500 ms, which renders the whole thing absolutely unusable. I am assuming the upgrade to El Capitan is the cause, but I cannot know for sure.
What I checked:
I tested on multiple MacBook Pros running El Capitan, and the latency is always that bad.
The commands have a high latency regardless of the service they're sent to (e.g., the device information service), and it varies a lot with every message sent.
It doesn't matter if I'm using our own application, a third party application named "LightBlue" to send hex strings, or Apple's own "Bluetooth Explorer" Developer Tools (can be downloaded in Developer Resources).
Can anyone hint me to what could cause this, or maybe just tell me that in their environment it all works fine?
To reproduce, connect to any Bluetooth Low Energy capable device with your Mac, and send a hex string of data to it. You'd have to log it somehow or turn on an LED or so, to see if there is significant latency.
Any help is greatly appreciated!
It looks like Connection Parameters used by El Capitan are not what they used to be under Yosemite.
Under OS X, CoreBluetooth decides what Connection Parameters are used for a given device, regardless of the client application. Unfortunately, rules CoreBluetooth relies on to compute the parameters is somewhat opaque and dependent on device (exposed services, DIS, AD). Some rule probably changed in El Capitan.
Some directions you should start looking to:
Apple Bluetooth Accessory Design Guidelines details some rules about connection parameters accepted by apple Centrals,
A latency problem may also be because of a high slaveLatency connection parameter. It helps saving battery life on peripheral, but makes to Central->Peripheral latency somewhat unpredictable. You may reduce the Slave Latency your device accepts,
Sniffer logs or peripheral-side debug would certainly help to understand what parameters actually changed between Yosemite and El Capitan.
In the end Apple DTS helped me solve the problem. They hinted me at the "preferred connection parameters" that were set incorrectly in my firmware.
On earlier versions of Yosemite, those values had no effect (same as on iOS), but since some OS update they are read on Yosemite and El Capitan. Not setting the parameters at all solved the problem.
In my case, the values were set by default:
Connection interval:
minimum 7.5ms,
maximum 50ms
Slave latency: 0ms
Connection supervision timeout: 10000
These values somehow caused the high latency. Here's a screenshot of the settings I had to untick inside the Cypress PSoC Creator 3.3 (I'm using a PSoC 4 BLE).
Related
I am trying to use my mac (MacBook Pro (Retina, 15-inch, Mid 2014) to connect to a device for an application I am trying to write however when setting up my CBCentralManager I am always returned with The platform doesn't support Bluetooth Low Energy. If i check my system information under bluetooth it clearly says that My computer does support Bluetooth low energy by this statement (Bluetooth Low Energy Supported: Yes).
What am I missing here is this me messing something up or is this something seriously wrong with my computer?
Also what can I do to bypass this annoying only Low Energy Devices and just start scanning for peripherals, seems kinda silly that it wont let me set a property to skip Low Energy.
Thanks for your time.
Sometimes the Bluetooth hardware can get messed up. Try a reboot and if that doesn't work a PRAM reset.
The setup:
OSX Yosemite.
Ableton Live 9 (Suite).
Crossover/Wine (14.0.3).
Connected device is a Novation Launchpad Mini (USB).
The problem:
The install of Ableton and most of its use work well. I have compiled and successfully installed wineasio.dll (wineasio.dll.so) to obtain low latency audio, again this works extremely well.
But what I am finding is the communication between the LP and Live is somewhat sporadic. examples of this are, having to list the LP in the midi in/out section of live multiple times just to get it to behave correctly (mostly), pads/lights randomly lighting/becoming non responsive, active tracks not showing (lighting up)
There is no pattern in all this. bug what i can say this setup works without problems in windows and OSX (obviously)
before you ask I'm having to use WINE as one of my favourite VST's is only windows based.
if someone can recommend a VM based solution (with low latency audio/ Midi) i will welcome it.
I'm currently working on 2 applications (one on iOS and the other on Mac) that are communicating using Bluetooth Low Energy (Bluetooth 4.0).
I develop these applications using CoreBluetooth on iOS 8 and OS X Yosemite.
I'm facing the following issue :
On my Mac, if the Wifi is turned OFF or if it is connected to a 5 Ghz wifi network, I have a stable Bluetooth connection between the iPhone and the Mac. No problem.
If my Mac is connected to a 2.4 Ghz Wifi network and if I have at least one Bluetooth device connected like a keyboard, trackpad, mouse... (using Classic Bluetooth), I have a stable Bluetooth connection between the iPhone and the Mac. No problem.
If my Mac is connected to a 2.4 Ghz Wifi network, the Bluetooth connection becomes unstable : the connection is stopped almost every 10 seconds and in Xcode I get an error message telling that the connection had an unexpected timeout.
I spent days on the Internet to try to figure out what I can do.
The best answer I found was this answer : CoreBluetooth and Wifi interference
But it means that I have to tell to my app's users to run this script and reboot their computer which is not for me a viable solution for production.
I also heard something about dealing with classical bluetooth peripherals (maybe to simulate one) or Wifi interfaces, but I found no solutions involving these kinds of manipulations.
Does anyone have an idea about something that I can do ? A workaround about the OSX Bluetooth management, the Wifi interfaces ?
I really need help about this issue.
Thank you very much in advance for your help.
My question is regarding credit card readers configured in Keyboard mode under OS X. I've noticed that the same reader running under OS X (I'm running 10.9.4, but the same holds true for previous versions) reads out swipe data about twice as fast in Windows 7 as it does on the Mac. For example, if I swipe a card using my MagTek Dynamag reader in to Text Edit (or any app) on the Mac, it can take a good 4-5 seconds to fully output the track data (the track is quite long because it's encrypted). If I run the same swipe using the same computer and reader using my VMWare Fusion Windows 7 virtual machine, the swipe outputs in a text file in about half the time (2-3 seconds). Even with whatever overhead is introduced by running a virtual machine, the output rate is still MUCH faster under Windows.
I originally just thought it was the reader that was slow until I tested it in Windows. Does anyone know what is causing the slower output rate on the Mac? Is it merely a setting or something more involved (such as USB drivers)? Thanks for any help!
I believe this may be a combination of the OS USB drivers and the polling interval setting on the device. Some of the MagTek devices, Dynamag and IPAD included, have a polling interval setting which dictates how quickly the data is ouputted to ensure there is no "skipping" when the data is read.
Reference:
Dynamag Tech Reference - actual page 8
"Programmable USB Interrupt In Endpoint polling interval"
USB HID Swipe Reader - actual page19
"The device has an adjustable endpoint descriptor
polling interval value that can be set to any value in the range of 1ms to 255ms. This property
can be used to speed up or slow down the card data transfer rate."
I'm using RN-41-APLX bluetooth evaluation board (based on RN-41-APL, very similar to RN-41 but also supports Apple devices) as a member of MFi.
I was able to establish connection and transfer some data to and from dev board with out-of-the-box configuration.
The problem is, in data sheet for RN-41 it is set, that SPP profile supports 240kbps speed, but when I transfer 10kB from iPod touch with Roving test iOS application installed, it takes 5 seconds to transfer.
Since UART speed is 230kbps, I think the bottle neck is the bluetooth link speed, but I can not find any way to change it. Can anybody help with that?
Thanks in advance!
I've run into this problem myself about this chip (well, the RN42 technically) and posted my findings here:
RN42 Bluetooth disconnects on iOS within seconds of streaming data
Short summary:
When the RN42 is used to communicate with an iOS device, it cannot
communicate faster than 2.5-3kB/s... If it's used to communicate with
an Android or computer or anything else, it can transfer at 35kB/s
(over SPP).
Hope it helps!
-SJ