I have to create a custom Service and Characteristic on the smartphone so the peripheral device could write into these new smartphone characteristic. Is this possible using react-native-ble-plx? Is it possible to monitor the managers characteristics? Is there an example of this?
I've already monitored the peripheral devices characteristic successfully, but some developers told me that the communication is faster when you monitor your own characteristic.
Related
I am able to register a device on Cumulocity IoT and send measurements from the device to Cumuloicty via MQTT. Now I want to send measurement from Cumulocity to that registered device using MQTT. How can I achieve this ?
I tried going through all the documents available on cumulocity but its not mentioned clearly in those docs how we can achieve this flow. I tried the control tab in device which lets us send some single and bulk operations but did not get to a solution.
All communication from Cumulocity IoT to devices is technically covered through operations. Even if maybe in your case the content of the operation is a measurement value, set point or something like this.
The structure of the operation doesn't matter for Cumulocity IoT. Your device in the end needs to understand it.
If you have for example a case where device A sends a measurement (to Cumulocity IoT) and you want device B to receive this measurement you will need to create an operation for device B out of the measurement of device A.
This can be quite easily achieved utilizing the built-in streaming analytics in Cumulocity IoT (see https://cumulocity.com/guides/apama/overview-analytics/). Fastest approach would be the Analytics Builder.
I am working on BLE application on a embedded platform where there are frequent connect/disconnect events. The issue I am seeing is re-connection takes too long. The high frequency of connect/disconnect is a part of usage scenario so I can't change that. What I can do is make the re connection more efficient. I noticed, the bulk of re-connection is spent of service/characteristic discovery of other devices.
I still want to make sure the service/characteristic of the connecting device hasn't been changed. In stead of discovering all the service , can we instead use a characteristic that has the hash of all the service/characteristic on the device? So each device can compare the received hash with the stored one. Only in case of mismatch perform full service discovery. Is there a precedent of doing it in BLE?
Bluetooth Low Energy (BLE) allows devices to leave their transmitters off most of the time to achieve its “Low Energy”.
I would expect a central device to subscribe to notifications from the peripheral. That way the peripheral only turns on and transmits when there are updates.
The other approach would be to put the data (or hash) in the advertising data (manufacturer data or service data) like many sensor beacons do. That way you might not need to connect at all or only connect if needed.
I just want to figure out. If i have the BLE(cc2541) and android APP. BLE has characteristics for notification, read, write and other. Can i write value to notification characteristics from BLE, read it with android APP, and then write to same notification characteristics from android APP to BLE?
It all depends on the firmware in the device.
I have a cc2541 with jnhuamao firmware and get notifications and read and write to the device with the same characteristic.
The service has Uuid 0000ffe0-0000-1000-8000-00805f9b34fb called SimpleKeyService
The characteristic has Uuid 0000ffe1-0000-1000-8000-00805f9b34fb with the properties Read, WriteWithoutResponse and Notify.
When reading about hardware/device independence this statement from wikipedia (http://en.wikipedia.org/wiki/Device_independence#Desktop_computing) states that:
The application software does not need to know anything about the hardware on which it was to be used. Instead it discovers the capabilities of the hardware through the standardized abstraction layer, and then use abstracted commands to control the hardware.
I wanted to know about the lower level interaction between the BIOS routine/device driver/HAL/OS and the device controller about discovering the hardware capabilities.
Kindly help me out to understand the communication between these entities that takes place which helps in hardware independence.
Hardware devices, normally, connect to the main controller through a standard bus of some kind.
For example - PCI, PEX, USB.
Each connected device on the bus will be allocated with a device #, bus #, function #, etc, by the bus controller.
Modern bus contollers either provide the main controller with the ability to perform a scan, or send an event when a device is hot plugged into the bus.
Per each discovered device, it is possible, using the bus controller standard commands (such as read/write registers of a device, by device ID, bus number, etc), to interrogate the device for details such as:
Manufacturer ID
Device ID
Class (controller / networking device / Human interface / imaging device / and so on)
Per bus type, all these details must be available in the same way for every connected HW device, thus enabling the OS to use an abstraction layer.
Once a device has been discovered and identified, the OS will call all the specific bus registered device drivers' probe function, which use the details mentioned above to decide if can handle it.
When a device driver probe succeeds, an instance of the driver is allocated and can be used directly by the application that needs to access the HW.
For example:
USB PC CAM connects to USB port. An event is sent to the main CPU by the USB bus controller. The CPU will use the standard USB bus controller functions to learn the manufacturer & device ID/s, device class, functions, etc, and will call all the USB registered device drivers probe functions.
If an appropriate device driver is installed (registered), it will successfully create an instance of the device and a video application (such as skype) can use it directly, through DLLs supplied by the driver SW.
Hope this helps.
I'm developing an embedded USB device which needs to be available to two different hosts.
The first is a normal PC, where it will be used as a MSC (mass storage) device, and the second is a specific hardware which the USB device needs to comunicate with a CDC profile.
during the enumeration, the USB device send descriptor table where it declares its capabilities.
Is there a way in the enumeration process to know to which host the device was connected to ?
The simplest solution perhaps would be to implement a "USB Composite Device", where the single device presented both the MSC and CDC class interfaces simultaneously. The host PC would see both interfaces, but you could simply leave one unused. The "specific hardware" would probably simply ignore the MSC class if it had no support for it.