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.
Related
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.
This is my first question in Stackoverflow :)
I'm trying to make few modifications to the Ti Sensortag but I have few questions please:
1- is it possible to make the sensortags communicate with each-other without a gateway?
(lets Say I put Sensor1 in bedroom 1 and sensor 2 in bedroom 2 can I make them exchange readings without the need for a gateway?)
2- can I install a micro USB over the interface connector to be able to use a portable battery pack? (photo of the interface connector)
thanks
You'll get better more in depth responses on the TI support forums as Ifor has said.
However, I can tell you the answer to #1... Regular bluetooth allows for things like piconets, but Low Energy does not. With LE you have a client/server (master/slave) connection between two devices only. It may be possible to modify the firmware on the sensortags to allow them to make connections to other sensortags, but then they'd have to give up whatever connection they currently had to do so. The master devices can connect to multiple slave devices, but the slave device can only be connected to one master.
As the sensortags are currently designed, I think they only work as a slave (server) device.
Press releases say that the new 4.1 spec allows for a single BLE device to act in both roles--central and peripheral eliminating the need for a gateway. A 4.1 update is, in theory, possible with 4.0 radio hardware like the SensorTag has. I personally haven't seen an example of this however and SensorTag processing resources may be a limiting factor to a dual role.
The Battery Pack connector breaks out VDD_EXT and GND and the SensorTag hardware schematic is available. Analysis by a hardware design engineer should be able to determine the suitability of a USB source powering option.
http://processors.wiki.ti.com/index.php/SensorTag_User_Guide
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.
Does anyone know how a bluetooth device could pick up the discoverable devices' device IDs in range?
I am ideally looking for the simplest solution that involves the smallest implimentation of the bluetooth protocols.
A starting point would be good, I just wish to create a device that can store all the device ids of nearby bluetooth devices with minimal power consumption, preferably just using radio frequencies and not SDP and whatever else.
If you can't help me with this, please can you help me find good reading material for low level bluetooth (step by step) communication. The reading online is so high level that I cant work out what is actually sent, when.
Laalto nailed the answer from the Bluetooth spec/stack POV, but your question implies your looking for a stand-alone Bluetooth device - not just a laptop app scanning surrounding devices.
I can only speak for the BT chips that the company I work for manufactures (Cambridge Silicon Radio - CSR) but our chips can do that pretty much out of the box. Our chips have an on-board Virtual Machine sandbox that allows access to the firmware functions and Bluetooth stack of the chip. You can easily write a C code app to run in the virtual machine sandbox, on chip, that periodically scans for discoverable devices around, grab their ids and then download them when connected via USB or Serial, or maybe over BT when a device connects to the listener directly.
www.csr.com and www.csrsupport.com for chips, dev-kits, design references, etc.. etc...
You probably want a module with the extra HW (UARTs, USB etc...) as well as just the chip but you could implement this with something the size of a BlueTooth USB or probably smaller.
It would really help to know more about what your trying to achieve, why you want something that just scans the surrounding bluetooth devices and how big the device needs to be.
Sorry if this sounds like advertising. For balance: Broadcom make BT chips too!
The Bluetooth specs from http://www.bluetooth.org are a good starting place for low-level information. You need an account to access the specs, but you can create one for free.
Basically what you need to do is to go into Inquiry mode periodically and grab the response packets as they arrive. The more time you spend in Inquiry mode, the more likely you will discover devices in range: discoverable devices enter the Inquiry Scan mode only relatively rarely; it takes some time (10.24s at least with older Bluetooth versions) to scan all the possible frequencies in the Inquiry/Inquiry Scan frequency hopping schemes. And even then you can have suboptimal radio conditions.
For implementation I suggest you at least start with existing Bluetooth libraries such as BlueZ and do not attempt to create your own from scratch.