I would like to know what is the difference between attributes and service in GATT in BLE specification, and where we can find attributes, are they in service, characteristics or in descriptors?
In summary ... services, characteristics, and descriptors ... are attributes :-)
The BLE standard provides the ATT protocol that defines the concept of attributes. All attributes are defined inside a table and they have a handle, a type (with a UUID), a value (and permissions).
On top of ATT protocol in the BLE stack, you have GATT and GAP. The GATT protocol defines services, characteristics, and descriptors and each of them is an attribute.
For example, a characteristic is an attribute with a handle, a type (a UUID that tells us that the attribute is a characteristic) and a value (the characteristic properties with a handle to the attribute value and so on). Inside the characteristic, you have an attribute that is the value of the characteristic and one or more descriptors that are themselves attributes.
You can see the attribute concept as the abstract type you can define concrete types like service, characteristic and descriptors.
I can suggest seeing the following video (intro on BLE) by Nordic.
Related
on bluetooth.org I saw that one BLE characteristic can have multiple field. I now searched for a while but did not get an answer about the byte order.
For example this characteristic:
https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.gatt.service_changed.xml
It has two fields. Is "Start of Affected Attribute Handle Range" the higher 16 bit or the lower?
Regards
Maz
GATT fields are always (or at least should always be) little-endian. This is discussed in the Bluetooth Core Spec.
From v4.2 of the spec, Vol 3, Part G (which covers GATT), page 523:
2.4 Profile Fundamentals
...
• Multi-octet fields within the GATT Profile shall be sent least significant octet first (little endian).
Be very careful reading this spec because there are pieces that are in network order (big-endian), but GATT attributes are always supposed to be in little-endian.
(The only reason I a say "should always be," is that the one rule of bluetooth devices is that you will always find some device in the field that breaks the rules.... But the spec is clear.)
Sorry if this is quite basic, I am new to DICOM.
I know a DICOM file has multiple parts like: Patient, Study, Series and Instance (Image).
Now to communicate with a device it needs a Transfer Syntax, which tells the mode of communication, like Little-Endian, Big-Endian, JPEG-Lossless, lossy etc.
So, does each of the DICOM file parts (Patient, Study, Series and Instance (Image)) have their own transfer syntax? Like Patient can communicate as Little-Endian, Study might use JPEG-Lossless or MPEG-4 (if it is video) etc?
OR does the entire DICOM file just use one transfer syntax.
A single transfer syntax is used through all the entire DICOM file (except for the first group with ID=0002, which is written with low endian/explicit VR transfer syntax)
When sending DICOM messages through a network then you can have a different transfer syntax for each message: there you can define different Presentation Contexts during the association negotiation, and each Presentation Context can have a different Transfer Syntax.
After the association negotiation, you can transmit messages with different transfer syntaxes by selecting the proper presentation context/transfer identifier in the message header
Your question does not entirely make sense with how DICOM is organized.
DICOM is composed of various SOP Classes. A SOP Class is Service-Object-Pair. Example services are the Storage Service Class (a service for network storage of messages (typically modality images) or the Media Service Class (for writing of files to media or just saving them to disk).
The Object portion of the SOP Class is defined in an IOD (Information Object Definition). IODs are defined by multiple Modules. The Modules in turn are composed of DICOM tags. Each Module usually groups tags together, and are typically related to an "Entity" in the DICOM model. The module might be associated with the Patient, Series, or Image level of the DICOM model. The IOD consists of all the tags defined in the various Modules. When encoding the IOD, the context of the module that the tags are defined in doesn't matter.
The DICOM Service defines how the tags within an IOD are encoded. Both a DICOM message for network transfer services (in its Group 0x0000 elements) and a DICOM file for media (in its Group 0x0002 elements) contain meta data that describe the encoding and a data set which contains the IOD tags. The group 0x0000 elements in a DICOM Message are always encoded in Implicit VR Little Endian, and the Group 0x0002 elements in a DICOM file are always encoded in the Explicit VR Little Endian transfer syntax. The datasets are always encoded in a single transfer syntax.
Hope this helps a bit.
I have a BLE device with multiple characteristics addressed by default addresses as defined here
Things like Manufacturer Name String, Hardware Revision String, Serial Number String etc.
Using the UUID class I've attempted several different ways to construct a UUID that RxAndroidBle would accept and read from these characteristics.
The one I though would work most was this:
UUID GATT_DSR1_MANUFACTURER_NAME = new UUID(0L, 0x2A29L);
but I just get back onError callbacks.
RxBleConnection.readCharacteristic only accepts UUID or a BluetoothGattCharacteristic which is created with a UUID...
Creating UUIDs
(copied from How to correctly use UUID.fromString method? )
In the BLE specification there are two kinds of UUIDs.
Fully qualified 128 bits long which are usually assigned for a specific vendor of the BLE device for non-standard functionality: UUID.fromString("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx");
Also fully qualified (but defined by standard) UUIDs which have the same prefix and postfix: UUID.fromString("F000xxxx-0451-4000-B000-000000000000"); UUID.fromString("0000xxxx-0000-1000-8000-00805f9b34fb") where xxxx is the place to fill the four characters you get from the SensorTag Bluetooth Core specification. For convenience the standard UUIDs are usually referenced with the four characters identifier.
Your 0x2A29L stands for "2A29" String as the xxxx.
Obtaining BluetoothGattCharacteristic
On Android there is no possibility to create a working BluetoothGattCharacteristic with a UUID. It is still possible to call RxBleConnection.discoverServices() and get it from the result though.
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.
Do we have to go through the Device tree bindings documentation of a linux kernel when you start working on it.
Is there no standard set of fields in the device tree which are followed by all distros/kernel sources?
Secondly I need some guidance regarding adding nodes for devices on gpio bus using device tree. I have already consulted http://devicetree.org/Device_Tree_Usage.
stackoverflow-query here should point you to documentation on device tree. And yes it is a good idea to go through the documentation before you dive into using it.
As for your gpio devices (I assume you already have a gpio controller in place in your dts/dtsi file in place), there should be plenty under arch/arc/boot/dts . Pick one :)!
Eg: gpio1_8 for mmc dts and gpio1 controller dtsi
Device Tree Binding for peripherals in an SoC:
As an example for the v5.1 kernel, here are the device tree bindings listed for various peripherals available on an SoC.
Link:
https://elixir.bootlin.com/linux/v5.1/source/Documentation/devicetree/bindings
Device Tree Binding for a particular peripheral in an SoC:
To explain a bit about the device tree binding for a particular peripheral let's take an example of an SPI for a very popular TI OMAP family.
Link:
https://elixir.bootlin.com/linux/v5.1/source/Documentation/devicetree/bindings/spi/omap-spi.txt
The text in this particular link introduces basically the key-value pairs. The 'key' is the device tree property and the 'value' is the possible place holder values for the corresponding 'key'. As an example, in the above link the "compatible" property, which holds one of the value as "ti,omap2-mcspi".
Another example is the "dma-names" property which holds txN, rxN .
Now, in the below link you can clearly see how these device tree properties are used in the real device trees:
https://elixir.bootlin.com/linux/v5.1/source/arch/arm/boot/dts/omap3.dtsi#L365
mcspi1: spi#48098000 {
compatible = "ti,omap2-mcspi";
reg = <0x48098000 0x100>;
...
}
The value "ti,omap2-mcspi" for the key "compatible" is one of the available value in accordance with the device tree binding document for omap-spi.txt (as seen in the second listed link).
So now based on SoC and the peripheral used, the device tree property can be written consulting the device tree binding document.