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.
Related
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.
I'm trying to determine how Apple Airpods pair and connect as seamlessly as they do, but I couldn't find any in-depth technical explanation so I embarked on a journey to figure it out for myself. I have used an Ellysis Explorer Bluetooth sniffer to sniff both BLE and Bluetooth Classic packets from the Airpods and the iPhone I have used to connect with it.
The issue is that I lack the background knowledge in Bluetooth to fully understand what I am looking at so I'm hoping somebody can explain what is appearing on the BT sniffer in the snapshots below:
The below picture is a list of the BLE packets captured after the Airpods case has been opened but BEFORE connecting to the phone.
The below picture is a list of the Bluetooth Classic packets captured after the Airpods case has been opened but BEFORE connecting to the phone.
The below picture is a list of the Bluetooth Classic packets AFTER connecting to the phone captured on top of the previous ones.
Note that there are no new BLE packets picked up after connecting.
The 1st pic shows that both ears are sending advertising packets.
Then one of the ear is paging the other ear and exchanging information.
Then the iPhone is connected to one of the ear just like normal A2DP connection.
More captures while audio is just started playing would be helpful.
Before analysing packets you need to learn about CoreBluetooth framework. CoreBluetooth deals with scanning, connecting and writing and reading data from "Bluetooth Low Energy" (BLE) devices. BLEs (Peripherals) continuously broadcast a small packet of data when they are not connected with any device Central.
First images shows data which is being broadcasted by BLE, in your case an airpod.
I have an security cam which sends the video stream over 2,4 GHz to a receiver. I now want to know, if it's possible to receive this signal on iPhone and show the video stream. As WiFi is also sending on 2,4 GHz, the iPhone should be able to receive that signal. Or not?
Security Cam: http://www.jay-tech.de/jaytech/servlet/frontend/content.html?articleOID=d583e45:-495a2735:120c7c04348:446c&keywordOID=d583e45:946c233:1182e6a651d:e4e.
My iPhone is a iPhone 5s on iOS 8.1
If it's not possible over iPhone, is it may possible to catch the signal with any other device? I have this devices which I could use:
Raspberry PI, old WiFi USB Stick, Arduino Uno and a buch of cables for TV/Audio/Video etc
Thanks iComputerfreak
Sorry for my bad English, I'm German ;)
In short, no. To receive the signal, you'd need some dedicated hardware to receive the signal and encode it into a format that the iPhone could understand. It's not possible to arbitrarily capture wireless signals on a particular frequency and decode them in software - not on an iPhone, anyway.
Your best solution would be to look for some external hardware which operates on the same frequency, and can encode the video signal over a wifi network - I'd be surprised if such a device doesn't exist, though it may not be cheap. The iPhone can then simply receive the encoded video via wifi and use it like any other video stream.
Apologise for the probably use of the wrong word in my question but for the life of me I can't think of the right one.
Anyway, I've been playing about with the Bluetooth Low Energy and I'm trying to create something that is going to use the RSSI signal strength the BLE device emits. For this, I need it to emit its pulse multiple times per second.
Is there a way I can up the amount of times my devices either scan for a signal, or broadcast their signal through code on iOS devices?
No, there is no API for you to change the advertisement speed or radio power.
This aspect is fully controlled by the system. You can only start and stop the advertisement and add some metadata to the packets: device local name, advertised services, etc. Moreover, the contents of the advertisement packets will differ depending on whether your app is in the background or foreground and, additionally, in background it will be slowed down. These effects have been documented in various SO questions and in the header files.
If your clients are iOS applications, then they should use either the RSSI in the advertisement packets (centralManager:didDiscoverPeripheral:advertisementData:RSSI: method) or when connected, the readRSSI method on the peripheral object (just make sure you don't call it too often).
While I realize that AirPlay has inherent lag/latency, I'm wondering if there's a way for a (currently hypothetical) iPhone app to detect what that latency is. If so, how precise can that latency value be? I'm more curious in whether an app can "know" its own AirPlay latency, rather than simply minimize it.
The latency does not come from network jitter, but rather is decided by the source device (your iPhone).
Long story short:
It's always precisely 2s (down to the millisecond) with Apple devices.
There is no way to tweak it with public APIs.
Audio latency needs to be very accurate so that multiple outputs can play in sync.
Some explanations about AirPlay's implementation:
The protocol starts with several RTSP commands. During this handshake, the source transmits rtpTime, the time at which the playback starts, which is also your latency. The typical value is 88200 = 2s x 44100 Hz.
AirPlay devices can sync their clock with the source's with NTP to mitigate the network latency.
During playback, the source periodically sends a SYNC packet to adjust the audio latency and make sure that all devices are still in sync.
It's possible to change the latency if you use a custom implementation, but Apple usually rejects them.
Check this writeup for more information. You can also read the unofficial protocol documentation.
The short answer is: no, Apple does not provide a way to do this. Assuming you need your app to be approved in the App Store, you're sort of out of luck. If you can run your app on a jailbroken device you can search around for undocumented APIs that will let you do more.
If you need your app to be available in Apple's App Store, most things you can do network-wise are outlined in the "Reachability" sample app.
The only way I can think of to get a good guess would be to use Bonjour to identify the host (see sample code here https://developer.apple.com/library/ios/#samplecode/BonjourWeb/Introduction/Intro.html) and then ping the host.
However:
If there is more than 1 Airplay station you will need to guess or ask which the user is connected to, or maybe take an average.
The device may not respond to a ping at all (Apple TV and Airport Express both respond to ping, not sure about 3rd party devices.)
The ping may not reflect the actual latency of the audio
Instead of spending too much time on this, you should follow Apple's guidelines for preparing your audio for AirPlay and enriching your app for AirPlay: http://developer.apple.com/library/ios/#documentation/AudioVideo/Conceptual/AirPlayGuide/PreparingYourMediaforAirPlay/PreparingYourMediaforAirPlay.html#//apple_ref/doc/uid/TP40011045-CH4-SW1
Hope this helps! :)
You can query iOS's current hardware audio latency by -[AVAudioSession outputLatency],
According to the document for outputLatency:
Using an AirPlay enabled device for your audio content can result in a 2-second delay. Check for this delay in game content.
And according to my experience, this value changes when switching output device, eg:
Speaker: ~10ms
Bluetooth: ~100+ms
AirPlay: 2s