Hi I am developing an application where an ATSAMB11 device has to send pressure data (from 0 to 6 bar with 5mbar steps) through BLE. I was just wondering if I should implement a custom service and characteristics or I can use the blood pressure service that is already implemented for atsamb11. I am asking because if I use the blood pressure service, it would be much easier as it is furnished with examples and I could write my program over it. Whereas if I have to create my custom service, I don't know where to start and what I need to write. (I precise that it's the first time that I'm working on BLE)
Another option would be to send the data through the custom serial chat service(which is also implemented and have an exemple), but I think that doing so is not the right way to use BLE. Indeed, why would everyone bother about different services and profiles if they could send anything through custom serial chat.
If you can use the standard blood pressure service, do that. Custom services are only used if there is no matching standard profile or the standard profile lacks some functionality one wants.
Related
We're trying to determine whether to use separate GATT characteristics or combine multiple properties into one custom characteristic.
The benefits of combining is fairly clear: one transaction, many properties.
But even with multiple characteristics (one property per), the transaction seems quick enough.
Is this entirely an arbitrary decision? Or are there best practices?
This is highly relevant and depends on the system you're trying to implement. My recommendation is to go for many separate characteristics. The reason is that you will be simplifying the application both on the GATT server side (where all the characteristics are stored) and the GATT client side. For example, if you use multiple characteristics, this means that you have to add extra intelligence to your GATT client side to separate the data in those characteristics. If the data side is variable, then this will be even more complicated. If in the future you have to update this combined characteristic with new features, the task will probably be relatively more complex for both the client and the server side compared to having many characteristics as things will be more categorised and compartmentalised.
Another thing to consider is testing. When you create your GATT server application, you'd want to test it with one or many different GATT client implementations (e.g. iOS device, Linux machine, etc). For that, it will be a lot easier if the remote device is not getting a combined characteristic and trying to make sense of the data.
Finally, please note that as you said, the transaction in Bluetooth is relatively quick and you will not be getting a huge difference when using multiple characteristics vs one. The reason is that by default the characteristic length is 20 and the Bluetooth packet length is 27 (unless you're using a Bluetooth 4.2 feature known as Data Length Extension, which not all phones support). Therefore, even if you use characteristic lengths greater than 20, the Bluetooth stack/baseband will divide the characteristic into chunks and send them over air, therefore not achieving the improved throughput that you aimed for.
I hope this helps.
I am trying to start a project in which I would create my own app on iOS using Swift to communicate with an Arduino 101 to control multiple LEDs. I have used this project as a base point.
After getting this to work with my custom app, I wanted to figure out how to make this work with multiple LEDs instead of just one. Currently, I am just performing writeCharacteristic to send a 1 or a 0 to the Arduino depending on which button I press (ON/OFF). However, for the new project, I need to be able to select one of the lights (select one of four output pins), and write a 1 or a 0 to turn it on and off. I didn't know what approach I should take to do this.
I don't need any code, just suggestions on how I can make this work through swift/Arduino code.
Thanks.
It's all explained in the manual.
https://www.arduino.cc/en/Reference/CurieBLE
Service design patterns
A characteristic value can be up to 20 bytes long. This is a key
constraint in designing services. Given this limit, you should
consider how best to store data about your sensors and actuators most
effectively for your application. The simplest design pattern is to
store one sensor or actuator value per characteristic, in ASCII
encoded values.
So either create a separate BLEBoolCharacteristic instance for each LED or combine the switch state of all leds in the same BLECharacteristic. For example you could encode 8 LED states in a single byte (1 LED per bit).
Do whatever you prefer. But read manuals...
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
I have several Microsoft bands, to be used as part of a group health initiative. I intend to develop a single app on a tablet which will pull the data from the bands. This will be a manual process, there will not be a constant connection to the tablet and no connection to Microsoft Health.
Does anyone know if this is possible?
Thanks
Emma
The general answer is no: Historical sensor values are not stored or buffered on the Band itself.
It does however depend on what sensors you are interested in. The sensor values are not buffered, so you can only read the current (realtime) value of the sensors.
But sensors such as pedometer and distance are incrementing over time, so these values will make sense even though you are only connected once in a while. Whereas for, e.g., the heart rate and skin temperature, you will only get the current (realtime) value.
So it depends on your use case.
I have no hands on experience with BLE and beacons at this point, and am having a hard time figuring out the viability of using them in a particular manner. Wondering if anyone can provide some high level feedback about the viability of this use case:
The goal is to use beacons to track a running race. Runners with their smartphones would be able to log times when they hit various beacons spread throughout an indoor course. Pretty simple scenario.
The problems that I foresee are 1) the ability to continuously scan for beacons at sub second intervals, and 2) the ability to then determine closest range to the beacon at sub second intervals.
I've tried parsing through the estimote and kontakt.io SDKs and am not certain that what I want to do is entirely possible or feasible with these particular beacons (or any for that matter). Further, would there be any device (the smartphones) specific limitations that would apply?
Thanks!
If you are using Estimote SDK you can set this property on BeaconManager.
See BeaconManager#setForegroundScanPeriod. SDK Docs