Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am interested in Bluetooth 4.0. Where to start adventure with it? If you have any materials, links, books I'll be very grateful. If you could share this knowledge. I would to use BT 4.0 to connect a PC (no matter what system) with a smart phone (eg. Windows Phone).
Right, I tried to quickly put together some relevant information that might help you. There is a big chance I have missed thing because this is a broad topic.
I am pretty sure you will find help here when you will have more specific questions.
Basically when it comes to Bluetooth (Smart, 4.0) devices and programming / connecting to them we can talk about two things:
Bluetooh Clients and Servers
Servers:
usually provide some data to clients. Think about a Heart rate monitor that captures someones heartrate and "stream" it so anyone who connects to the server will be able to read the data.
Clients:
On the other hand clients connect to servers (how obvious) to collect their data, or in some cases to write to them.
Bluetooth Profiles
Bluetooth devices (servers) have so called GATT (generic attribute) Profiles. These profiles describe a kind of unique set of Services. Each Service has different Characteristics. These characteristics hold the actual values.
Think about a Heart rate monitor (HRM). Thats a server. It measures heart rate so clients that connect to it can read / collect it's data. Heart rate monitors have a specific Heart rate monitor GATT profile which describes services and inside the services there are the heart rate specific characteristics like: heart rate measurement, body sensor location, etc.
When a client wants to read these values it has to connect to the HRM, discover it's services and characteristics, then read the values from the discovered characteristics.
Async
It might be obvious but Bluetooth programming (implementing server / client connection and data transfer) is async. It means the client sends something then waits till the server answers then can the it progress to the next step.
Your whole software has to be implemented keeping async programming design in mind.
Documentation
I have to say I found the iOS documentation and support very useful when I developed my first bluetooth app.Android was somewhat more difficult for me because of the lack of examples I found. Also general bluetooth 4.0 support only became available since Android 4.3. (different bluetooth chip manufacturers in different Android phones had different low level bluetooth stack so to use them one had to write native bluetooth code for each different chip with their own SDK - prior to Android 4.3)
Bluetooth.org
I would suggest to start with this:
https://developer.bluetooth.org/DevelopmentResources/Pages/Quick-Start-Kit.aspx
https://developer.bluetooth.org/TechnologyOverview/Pages/Technology-Overview.aspx
https://developer.bluetooth.org/DevelopmentResources/Pages/default.aspx
https://developer.bluetooth.org/gatt/Pages/default.aspx
iOS
It won't hurt if you read about Core-bluetooth framework, which is the iOS approach even if you don't plan to develop on iOS. Since it is well documented it might give you a better overall understanding:
https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/AboutCoreBluetooth/Introduction.html
Android
Same for android:
http://developer.android.com/guide/topics/connectivity/bluetooth-le.html
Windows 8
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207007%28v=vs.105%29.aspx
I've found "Bluetooth Low Energy: The Developer's Handbook" by Robin Heydon very useful. It deals with all the little details so you can understand how things are working on the lower level.
As a reference, I've found the Bluetooth specification PDF very useful (though it's sometimes hard to find what you need). It looks like they just released a 4.1 version here: https://www.bluetooth.org/en-us/specification/adopted-specifications
EDIT: both references aren't specific to any particular implementation, so I'm not sure how much they'd help if you wanted to learn something specific like iOS BLE or Android BLE.
Related
I was always wonder what would it be my first question on StackOverflow since everything I'm looking for is already asked. (Find only one similar here Bluetooth data transfer between two countries )
BACKGROUND STORY:
From when it comes I’m a fan of Nokia N-GAGE. It’s a Nokia’s phone from 2003 with dedicated games. In its heyday 2003-2007, it has single-player, multi-player via Bluetooth and using a dedicated internet service N-GAGE ARENA for compete with people all over world.
N-GAGE ARENA servers were disabled about 2008 and as far i understand It isn't even worth trying to resurrect such a infrastructure. Mainly because it requires modifying the code of each game and that's illegal.
Multiplayer mode using Bluetooth work fine, but requires opponent 5m away max.
Nokia sold 1mln copy of this phone, and still are people all over world collecting n-gage games. I have a dream, I want to reactivate the possibility of playing multiplayer with people from all over the world.
PROBLEM DESCRIPTION:
I want to use the Bluetooth multiplayer mode by extending the usual N-GAGE to N-GAGE Bluetooth connection with an additional 3 elements. Two N-GAGEs, instead of connecting directly to each other as host-join, connect via a PC / smartphone applications that communicates with the server that transmits full data sent from the game of one user to game of the opponent.
I admit that I do not have full knowledge of technical limitations. In my opinion, as a software engineer, it is theoretically possible, but I want to consult you, people more familiar with the subject. Maybe someone is working on a similar project and can comment.
WHAT DO I KNOW:
The application would have to transmit all data from the Bluetooth connection so as not to disturb the illusion of a direct connection between N-GAGEs.
The application must enable the selection of an opponent on the basis of the game. The choice itself could be made on the basis of some kind of chat in which users first define what they are playing, who’s the host, and then the connection is made.
WHAT DO I WANT TO KNOW:
Does what I describe is even possible?
Is such capturing Bluetooth connection and forwarding is even possible?
Does the development of technology in these 15 years allow me to transfer Bluetooth connection real time through 2 additional devices and Internet connection?
I WOULD BE GREATFUL FOR:
Any technical tips, literature that can help me to understand my limitations.
Any constructive criticism. Of course before I start doing such a project I have to confirm that isn't a utopia. For me It’s a side project, I’m able to spend years on it, but don’t want to get to dead end after all effort.
Does what I describe is even possible?
Yes, yes it does. Your hardest part will be setting up a tranceiver to interpret the I/O. Your failure point would be super-encrypted messages and making transmission difficult...
If it's clear I/O you can signal this through any server and output it back to the tranciever to output. Confusing but possible just not sure of the design or how bluetooth sends its data.
Is such capturing Bluetooth connection and forwarding is even possible?
If a connection is possible then forwarding it is too. Considering this piping the transports.
Does the development of technology in these 15 years allow me to transfer Bluetooth connection real time through 2 additional devices and Internet connection?
Bluetooth real-time no... with added network latency, you're looking at anything from 1-200ms~. you may be able to improve it?
Overall I think if you can:
Connect the device to PC, and have PC talk back to device through blue-tooth
Read the data that goes in and out
Encryption proves little or none at all to be able to signal the data properly, tricky to explain you'll know though if there's a wall.
All should be possible it doesn't overly go against the grains but do more homework this is very valid.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm developing an IoT application. There is a microcontroller which controls the sensors. Smartphones connect them and perform some actions. I want smartphones to connect multiple devices and control them and in the meantime I dont want internet access of the smartphones to disconnect. What I want to ask is which wireless protocol would be good for this job. Should I use WiFi, Bluetooth, Wifi-Direct or anything else ?
Actually, according to my searches, "WiFi-Direct" seems good option to me, but I wanted ask to you whether it is a good options or not. In addition, please state which specific module can be used such as "HC-06" "ESP8266" and why? while stating which protocol is good for me. Thanks in advance :)
It's a hard question. Answer is depends on many aspects:
What range do you want you sensors support (how far they should stay connected)?
How many sensors do you want to support?
How your sensors are powered up (power line or battery)?
What smartphones do you want to support?
How much data and how frequently they send?
And other...
Let me cover these topics a little more:
Range
This is the easiest one. Bluetooth (depending on class, usually it's II) have a range about 10m (30ft). Wi-Fi (and Wi-Fi Direct which is almost the same) have range about 30m (100ft). So if all your sensors located on a user's body (like wearables) or at the desk (like mice, keyboard) then Bluetooth is fine. If devices are spread over larger area (like temp-sensors in each room), then Wi-Fi based protocol is better.
Number of devices
This is also quite easy. Bluetooth is capable of connecting not more than 8 devices. One of them is master and up to 7 slave devices. Wi-Fi can handle theoretically up to 255 devices, but in practice it's less (due to interference). Usually if you have more then 20-25 devices you need another access point.
Power
If your devices are connected to a power-line (like smart wall sockets or smart light bulbs) then they easily be connected using Wi-Fi. But if it's a button-cell battery then it better be Bluetooth Low Energy (BLE) (a.k.a Bluetooth Smart or Bluetooth 4.0). However there are examples where TV remote control running on 2 AAA batteries uses Wi-Fi Direct.
Smartphones support
Android can do anything, but iPhone is a headache. It does not support Wi-Fi Direct, it does support Bluetooth, but only limited number of BT profiles. If you need to support other BT profiles you need to participate in Apple MFi program and got a license and certification from Apple. Another option is to use Bluetooth Smart technology (BLE). More information about Apple restrictions are here and in the FAQ.
I won't advice about concrete chip-sets, because there are so much choices on a market, also I don't know your budget. However you can try to look at well know brands like Broadcom, Texas Instruments, Marvell and etc. - they provide a chip-sets for any choice and gust.
If you need to support iPhone and all other requirements (range, amount of sensors, etc.) are OK with Bluetooth, I would recommend to use Bluetooth Smart (BLE) as a simplest choice.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Are there any other methods or protocols other than GATT which can be used under BLE (single mode chips) which are better suited to higher-throughput tasks?
From what I understand the answer to my question is no, but I would like some validation and clarification.
I would like to implement services which involve more than simply manipulating (short) characteristics via BLE. Such services might include file transfer, audio streaming, and basically services which are standard in previous versions of bluetooth.
A convenient solution would be to use the File Transfer Profile (over GOEP) or similar for file transfer. For audio, A2DP seems suitable. However, these do not seem to be possible using BLE.
After reading the core spec v4 from bluetooth.org (specifically Vol. 3), it seems like the only applicable protocol which I can use and adapt (via profiles) for such purposes is GATT, which seems very awkward to use.
Also, according to Overview and Evaluation of Bluetooth Low Energy: An Emerging Low-Power Wireless Technology, it seems like the effective throughput is low:
Whereas the physical layer data rate is 1 Mbps, the maximum application layer throughput
is equal to 236.7 kbps.
However (when measuring real-world performance using TI CC254x via GATT):
... In the described conditions, the maximum application layer throughput we have measured is 58.48 kbps. This
low result can be explained by the following two facts: (i) whereas, in theory, up to eleven such
notifications can be transmitted within a connection event of 7.5 ms, only four notifications are
allowed per connection event, as aforementioned; and (ii) we have observed that less than four
notifications are actually transmitted in most connection events during the experiment (however, the
same phenomenon occurs less frequently for connection intervals greater than 7.5 ms). These
observations show that high throughput has not been a primary goal in the design of the BLE
implementation used in the evaluation.
I realize the above text is specific to the implementation on the TI chip, but such limitations could also apply to other implementations above GATT as well.
If you are writing your own profiles, then you can do whatever you want by opening an L2CAP channel and sending data in any format, without implementing GATT. L2CAP would let you get the max throughput, and be suitable for streaming data as opposed to reading characteristics.
Please see what we have been doing for a long time: IPv6 over BTLE, which is still one IETF draft in the 6LoWPAN WG, and the proposal has been approved in Bleutooth SIG. Here is the news in BLuetooth Technical Updates: 19 Feb, 2013.
IPv6 Over Low Energy New Work Proposal Approved
The IPv6 Over LE New Work Proposal (NWP) submitted by Bluetooth SIG
members is approved. This NWP proposes that permitting IPv6 over the
Low Energy transport will enable new use cases (in home and industrial
automation as well as smart metering) not covered by GATT profiles.
The proposed work meets the requirements defined by the Internet
Engineering Task Force (IETF) as well as complements the work done in
the IP for Smart Objects (IPSO) alliance. The Internet Working Group
will develop a Functional Requirements Document (FRD) based on the
approved NWP. If you are an Adopter member and want to participate in
the FRD development process, please contact the Internet Working Group
Chair.
There is stuff coming up, if you're a member of the SIG look up the Tech Specs section of bluetooth.org
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have an external sensor (personal, mobile). For example, a thermometer. I'd like to connect it to an ordinary mobile phone (no OS, just JavaME) and write JavaME application which reads data from that sensor and displays them on the screen.
My understanding was that I could connect sensor to phone using the audio jack (headphone jack), because every phone has that jack. But I didn't find any info how to read data through that jack.
So, my questions are:
1) Is it possible to connect an external sensor to phone's headphone jack and read data from it in JavaME application? How? Code example?
2) What are the other ways to connect an external sensor to JavaME phone? Bluetooth? Sms?
Thanks for your help!
JSR 256 Mobile Sensor API specification is targeted to handle functionality like you describe.
This specification will define a generic sensor API for the J2ME
applications, delivered and licensed as an optional package. The API
will offer unified way of managing sensors, connected to the mobile
devices, and easy access to the sensor data. The J2ME applications
will be able to configure and control sensors transparently from
underlying connectivity protocols, e.g. activate, deactivate sensor,
launch sensor discovery, start data sampling, etc...
...The number of the sensors embedded or connected to the mobile
devices emerging very rapidly. A sensor can comprise of many kind of
devices from microphone and camera with pattern recognition to heart
rate monitor and thermometer. Sensors and the data they provide may
differ greatly from each other. The communication model and protocol
are usually different for different sensors as well.
The application that wishes to utilize sensor data typically performs
following operations with a sensor:
- Sensor detection (discovery).
- Sensor activation and calibration.
- Data capture (sampling initiation, data fetch, data processing
(including e.g. filtering, calculations)).
- Sensor deactivation...
Above specification is in use since 2006; if memory serves a couple of mobile phone models support it - search the web for these if you're interested in more details.
AFAIK the J2ME Sensor API (JSR 256) does not provide such functionality. The Sensor Web specification by OGC (Open Geospatial Consortium) may be closer to what you're looking for.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am looking at writing some software that will allow me to listen to music whilst talking with someone on skype. The problem is that if you do this with speakers the music also gets transferred to the other user, which is what I want to avoid.
So I was thinking about writing something that will, by listening to the output of my music application, cancel out those sounds from the microphone input sent to skype.
I have searched Google a bit, but maybe someone here can kickstart this project with some pointers/ideas/etc...
EDIT: has anybody used JACK before?
What you want to do is basically the same as Echo cancellation in telephony.
http://www.voip-info.org/wiki/view/Asterisk+echo+cancellation is simple introduction. Also have a look at the pages for the mark and mark2 echo canceller there and the mentioned TI application note.
Also this site:
http://www.embeddedstar.com/articles/2003/7/article20030720-1.html
explains the mechanics quite well.
You'll have to intercept both the music player's output and the microphone input, and then pass the samples via some sort of IPC into your DSP process. JACK actually does this, but setting things up (e.g. ALSA->JACK bridge, if your music player and/or Skype does not natively support JACK as sound interface) does require some skill.
I guess it could work fairly well, but it probably requires quite some CPU. Especially XRUNS (audio buffer under- or overrun) can be really bad for your echo canceller, i.e. you might need realtime linux kernel patches. Implementation is not trivial, either. Also having stereo sound from your music player will reduce your cancellation success.
HTH
Generally when it comes to noise cancellation, it is due to 2 things in precedence order:
Hardware - either a MIC/headphone with noise cancellation feature or the internal sound card MIC that already built in that feature.
Software - a good example is Skype, AFAIK SKype allow you to fine tuning audio quality but unfortunately the tuning part so far only existed in Windows platform. Where in Linux, you can choose the option of "Allow Skype To Automatcally Adjust My Mixer Levels" checkbox at Preference > Sound Devices.
My understanding is when it come to noise cancellation, you have to deal with the sound car driver programming, currently there is couple of noises noted into future Ubuntu software release that carry the said feature, there is here mentioned.