I'm trying to detect when I am connecting/connected to a car via bluetooth. I am currently using AVAudioSession and the properties currentRoute and outputs to determine what types of routes are connected. However, the port type 'carAudio' only correlates to when the phone connects to the car via Aux or some sort of Cable, but when connecting via bluetooth with a car's audio system the output route is always A2DP.
I understand that most cars now implement bluetoothA2DP, but I was wondering if there was some way for me to detect whether or not the bluetooth type connection is from a car, as opposed to some bluetooth headphone/speakers. (Also for both input and output, I never seen to detect BluetoothHFP)
I believe this is possible as apps like Spotify supports this functionality, and works perfectly when I connect my spotify app to the bluetooth, however my code cannot detect this connection.
Related
I realise most of the searches are quite old on this topic and not after Core Bluetooth now supports more than just BLE connections (https://developer.apple.com/videos/play/wwdc2019/901?time=556).
Simply by running the RxBluetoothKit example app I am able to discover my speaker and inspect its services. However I am unsure how to actually get the speaker to pair with the phone, after a while the speaker disconnects. I am struggling to get information on the protocol and/or how to proceed.
Or is this still not possible: "And so if you're calling connect on a BR/EDR device, if your app is in foreground, then we'll try to make a connection out to that device for you." - it seems like querying and communication with an already paired device is what they were getting at in the talk.
Thanks in advance.
I have an application that needs to record voice from Bluetooth headset. It needs work like Siri or Google Assistant. When I press button in App, it records voice from Bluetooth MIC rather than build in Mic. Is that possible?
My understanding is
1) either the Bluetooth is an Apple certificated External Accessory
2) or the Headset can implement a HFP like protocol to active a HFP link ?
Any hints?
If all you need is recording, it's quite straight if your bluetooth device is paired with iOS. All bluetooth headset with microphone will work well.
When you start to record, I think you have already changed your audio session category to play and record.
Then you can check all your available input route with
-[AVAudioSession availableInputs]
and iterate to find the bluetooth, then set it with
-[AVAudioSession setPreferredInput:error:]
Sometimes it will fail, you need to check the output parameter error to find if there is something wrong.
I am implementing an IOS game using Bluetooth, Wifi and Game Center; Bluetooth is a two person game using GKPeerPickerController, the Wifi version runs on the local network and is a 4 to 6 player game that needs auto discovery and thus I am configuring my own GKSession, the Game Center game uses GKMatch to spread the game across the web.
All of this works well except where Bluetooth and Wireless are available in the situation where I want to play a multi-player game on the local wireless network. The fact that bluetooth is turned on slows down and interferes with the auto discovery process. It works like a dream when Bluetooth is turned off but it would be wrong to programmatically turn off bluetooth.
My Question: Is there anyway to tell a GKSession to ignore Bluetooth and restrict itself to the local wifi. The GKPeerPickerContoller has a connectionTypesMask which allows you to specify Bluetooth or Wireless but with 4 to six players this would get very chatty, the GKSession does not seem to have this option.
I am building an assistive iOS app for a kid that uses a switch to control his computer (a simple button that can send only one massege to the computer).
I am looking for a way to connect my app to a switch that can send click events to my app.
It can through by BT, IR or even through the earphone connection (headset port).
(BTW he can not use the iOS screen as the switch).
Any ideas ?
A BT connection requires you to be a certified MFi developer, and that requires money and a real company.
The headphone port would be a great place to interface with. You could wire a simple switch over the microphone line and ground line which, I think, would create a square wave duty cycle for on and off. I've done something similar where we used the headphone port to communicate to a microcontroller through a sound wave that was then converted to 16 bit packets and used to control additional hardware and also give feedback from that hardware.
Another option is a wifi connection, an arduino with a wifi shield and the button on that.
Edit:
The more I think about it, the more I would say use the headphone port. It will be super cheap, the programming to detect the presses will be really easy, and this will probably be the fastest way to achieve your solution. Provided you can solder.
I'm going to suggest going down a different path. Instead of trying to connect the switch directly to the iPhone, use something like an Arduino board with both physical switch and ethernet I/O ports plugged into the local network, and create what amounts to a physical I/O server.
The Arduino handles the physical interfacing and your iPhone app only has to handle the communications protocol to the Arduino over Wi-Fi.
One inexpensive solution would be to use the mic or mic input on the headset port. Connect the switch up to some sort of tone generator (555 timer or Arduino, plus piezo speaker or headset cable). Have the app run an input Audio Queue, and pass the Audio Queue input buffers to a DSP narrow band filter or an FFT. Monitor the frequency band of the tone generator for any significant energy burst above the background noise level. Potentially use multiple separate tone frequencies for more than one switch.
Added: Another simple alternative might be to use the switch to activate a solenoid or small motor (scavenged from an old motorized toy or similar) to tap a capacitive pen or ball of conductive foam on the iPod Touch display. No MFi, WIFI or audio DSP coding required.
How does a car's system handle calls from an iPhone? The device is plugged through into the car's system using the dock connector at the bottom of the iPhone. Now when a call comes through the car intercepts it and you can press a button (usually on the steering wheel) to answer and then speak through the inbuilt microphones of the car and listen through the speakers in the car. All of this is done through connecting the device into a dock.... how does this work?
P.S: Is it possible to initiate calls from an outside system as well?
P.P.S: All of this is done without an App being installed on the iPhone itself though...
Any bluetooth devices that implement HFP or HSP bluetooth profiles will be able to receive the call from iPhone.To display the info( Caller ID or Contact name) on the car kit, the device has to implement PBAP or MAP bluetooth profiles.No App is required on iPhone.