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
Related
I am involved working on new hardware LED products where we are selecting a Bluetooth chipset to use in multiple products controlled by iOS and Android apps, for at minimum the next 3-4 years. Also I am not the developer, a third party will be contracted for this project.
As part of background research, I wanted to ask for feedback from Stack Overflow communities' experience with programming for Bluetooth, more specifically with custom firmware and GPIO PWM for LED?
What kind of challenges did you come across?
Are there any granular details or features to look out for with the hardware?
**Edit: based on first answer-
Requirements:
BLE 5
I do need OTA update capability
Chip size not big constraint, plastic enclosure can accommodate up to 1 inch/25mm or bit more easily.
Not high temp application
Single-chip solution, that will be programmed with our firmware, controlling 4x PWM Channels is ideal for our LED strips, avoiding separate MCU
Cost per unit (lowest average cost/unit)- important factor at volume, TBD
**Qualities I can not gauge well myself, being a designer and not an experienced programmer:
Ease of integration/support (lowest cost of development)
Quality of the chip manufacturer's software tools
Quality of the chips documentation
I have found some questions related with Raspberry Pi that seem generally helpful, but those questions don't help me with features or the support and documentation as related to BT SOCs.
**Edit: Yes I we are only considering BLE, and the NORDIC Semiconductor link I have included below are BLE and BT 5.
NORDIC chips are on my short list, they seem well supported and capable of 3x or 4x PWM channels for example nRF52832 Nordic nRF52832 Spec info. or the newer model RF5340. Does anyone have experience with them?
I really appreciate any answers regarding development considerations with Bluetooth.
I will edit & clarify if needed.
If you wish to support iOS Apps, a BLE device is necessary, BT classic requires a special apple license (for your product) to be able to connect with iOS Apps.
But other than that, your specifications dont really help to rule out ANY chip.
The first question that comes to mind is what other features do you
have already on your specification list that could be satisfied with
a common solution. I.e. if you also need WiFi, don't choose two
separate BLE/WiFi Chips, buy a chip that can do both (it's both
2.4GHz RF). If you need OTA updates for your firmware, choose a chip manufacturer with extensive and well documented tooling.
Consider special requirements:
Do you need a very small chip?
Does it need to be run at high temperatures (i.e. inside a light bulb)?
Do you need to run at ultra-low-power?
Does it need a high performance RF transceiver?
Decide whether you need a single-chip solution, that will be programmed with your firmware, or if your firmware will run on a dedicated microcontroller which is connected to the BLE chip.
Unless you have absolutely no special requirements to narrow down the selection, I'd base my decision along these criteria (not ordered):
Ease of integration (lowest cost of development)
Cost per unit (lowest average cost/unit)
Quality of the chip manufacturer's software tools
Quality of the chips documentation
GPIO-PWM Output should be possible with almost any programmable BLE chip.
I have a couple of questions concerning BLE beacons:
1) Are beacons based on nRF51822 chip the best solution? Or are there any other chips better than nRF51822? I want to take up BLE beacon development and struggling to find the right hardware for these needs. As a novice developer I want the beacon to be as cheap as possible in order not to waste money in case of a failure.
2) Is it possible to buy pure Eddystone beacon (not iBeacon)? The reason for choosing Eddystone is that Eddystone is capable of broadcasting URLs that are essential for me.
The second question stems from my failed attempts to find a pure Eddystone beacon on Chinese electronics sites like alibaba.com or aliexpress.com where the only firmware available is iBeacon. But iBeacon is not an option because it can't broadcast URL the way Eddystone does.
Apart from the above questions It would be great if someone wrote a quick guide for taking up BLE development with Eddystone and covered basic topics like: chip to use, beacon model, best website to buy beacons at, etc.
Thanks in advance,
Pavel
1) I've worked with Estimote beacons and Chinese beacons from Amazon and in my opinion, they do not differ in terms of accuracy too much. Especially for prototyping, I'd buy cheaper ones to test if your use case can be satisfied with BLE beacons. If it is too inaccurate with Chinese beacons, chances are that it won't work with more expensive ones either.
2) Why do you need the URL broadcast? If the app is going to use the url, it would have to be connected to the internet. Therefore, you can just query the beacon's IDs to a web service to get back an URL and use that. Personally, I think this is a better approach as you can configure the web service from anywhere to change the url for beacons where as if you want to change the URL of the Eddystone, you have to go to the beacon to configure it.
The nRF51822 is a common implementation, is flexible, well understood and can be very inexpensive. Be aware though that development costs, add on circuitry for power and/or peripherals, and packaging can easily eclipse the Bluetooth chip when you get to production cost savings.
If you want to buy an off the shelf beacon, most models supporting Eddystone also support iBeacon, simply because supporting both adds no additional hardware cost. Newer Radius Networks and Estimote beacons all support both. And, yes, cheaper generic Chinese suppliers often have bulk manufactured inventory from before Eddystone existed at only support iBeacon.
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 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.
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.