Some background information:
The sensor im trying to read the characteristics from is part of the IoT-starterkit: Wunderbar. Originally the sensors where designed to connect with a mainboard which would than send the data received from the sensors to a cloud.
Sadly the mainboard is not working for me, so i used my raspberry Pi 3 to replace it.
Currently i'm able to read standard characteristics defined by bluetooth, such as the Battery level, Manufacturer Name String, etc..
My question is focused on reading characteristics of a Primary Service which is "unknown" to bluetoothctl.
I'm not sure whether the data can't be interpreted correctly or if i'm missing some kind of authentication.
Related
I have small question about HM-10 ble module and master role.
I tried 2 scenarios.
Android app as master and hm-10 as slave:
From android app I can connect to hm-10 and its characteristic .
Everything works OK.
I have problem with second scenario: HM-10 as master and my ble device (LEGO SBRICK) as slave.
What I've done:
AT+ROLE1 - Set up to Central
Mode AT+IMME1 - Start from RESET
AT+SHOW1 - Show discovered devices
AT+DISC? - Discover Devices
AT+CON connect
Now my question is:
SBRICK is listening for ble command on service X and characteristic Y.
How can I send data from my HM-10 to specific characteristic of my SBRICK device ?
I can not find AT command for that.
I hope I didn't miss something from ble specification.
Any help please...
I am afraid there isn't an AT command to set a specific characteristic value.
The HM10 is a serial-port emulation device - It has a BLE characteristic, which displays all serial data (except AT commands). You will likely be able to find the service and characteristics details in the documentation (although I had a quick look and couldn't see anything).
So, data written to the serial port should appear as the value of that characteristic. Data written to that characteristic should be delivered out of the TX serial port pin on the HM10 module.
If you want to interrogate the device to find out it's serial and characteristic values, try using a debugging app - I use Light Blue on iOS, which will show all services and characteristics present on a device and show their properties and details.
pfodApp now supports BLE devices including HM-10. The free pfodDesigner lets you create custom custom Android menus and then generate the Arduino code for your particular hardware.
pfodApp supports data logging and plotting also.
As a 3rd party is there a viable way to correctly interpret data from a Bluetooth Low Energy device for which there is not a published GATT profile specification?
The BLE device is a body scale that supports weight, BMI, body fat, and hydration level. My understanding is that there is no adopted GATT profile for body scales like there are for, say, blood pressure devices or heart rate monitors (https://developer.bluetooth.org/gatt/profiles/Pages/ProfilesHome.aspx).
Using the following tools:
iPod (iOS 6.1.3) with various BLE utility apps (Ti BLE Multitool, LightBlue, and BLE Utility)
Android (4.3) tablet (Dell Venue 8 3830) with nRF Master Control Panel, plus a custom Xamarin developed solution
I can scan for, locate, connect to, and read the GATT services available on the scale. All of the above tools give me the same service information. There are 5 services discovered on the scale:
Generic Access (0x1800)
Generic Attribute (0x1801)
Device Information (0x180A)
Battery Service (0x180F)
An unknown service with a custom 128-bit UUID
All of the above tools are able to read from the known services, like retrieving the battery information or the device name. My assumption is that the unknown service with the custom UUID is the service that provides the scale data.
This service has 5 unknown characteristics with custom UUIDs:
Characteristic 1 is Read/Write
Characteristic 2 is Read
Characteristic 3 is Read/Write
Characteristic 4 is Notify
Characteristic 5 is Read
Using the tools that were specified above to read from characteristics 1, 2, and 3, each returns it's own value, but that value never changes. For example, a read of characteristic 1 always returns a value of 20 octets 0x01-0x05-0x06-0x07-0x08-and 15 0x00 octets. Subsequent reads of characteristic 1 always return that value. Characteristic 2 reads always return a value of 20 octets 0x02-and 19 0x00 octets. And so on.
Reading characteristic 5 appears to either not return a value, or more commonly on Android, issue a pairing request. No common pairing code (like 0000 or 1234, etc.) is valid.
Characteristic 4 appears to be what actually transmits the scale data. Using the tools above I can enable notifications and the applications retrieve 13 octets. For example:
FF-16-09-00-03-04-01-00-83-6F-F4-18-0F
FF-16-09-00-03-04-01-00-3E-88-F4-18-E3
FF-16-09-00-03-04-01-00-C8-89-F4-18-6E
Obviously all of those values begin with the same set of octets. The main problem though is what do those octets represent and how do they translate to weight/bmi/hydration/body fat values, if in fact they do at all.
The scale is built with the Ti CC2541 chip (http://www.ti.com/product/cc2541).
Using Ti's SmartRF Protocol Packet Sniffer along with the CC2540 USB Evaluation Module Kit I can capture packets going between an iPhone 5S (iOS 7.1) and the scale. This has provided some additional insight, but mostly just shows what I've already observed using the other tools, though albeit it at a lower level. Any additional information provided by the packet sniffer still leads back to the same question: what do these sets of octets the scale is sending represent and how do they translate to weight/bmi/etc? I've utilized the Bluetooth Core Specification documentation and that has helped to understand what octets for standard functionality mean/do, but that isn't helping understand the actual scale data.
I'm very new to Bluetooth development and this exercise has basically resulted in a crash course in the technology. Any help is appreciated.
Thanks.
You must contact the manufacturer and ask for clarification about the custom service and characteristics.
Characteristic 5 seems to have higher security settings, hence why it triggers pairing when you try to read it. Most likely contains some sensitive data.
Characteristics 1,2,3 are likely for configuration, while 4 notifies the useful data.
Since these are all custom, there's simply no way to find out what they mean without information from the manufacturer.
It's like you create your own "We're out of yogurt" notification profile... one can only guess by looking at the data.
I have a little hw with a BLE module that communicates with an iOS device.
I would like to perform a discovery using iBeacon (so using iBeacon advertisement packets) and - obviously - connection (and data exchange) using CoreBluetooth, but there are some issues.
Before describing the issues, I have to tell you that I need to provide these information in discovery phase:
Serial number (needed for internal purposes) - 6 characters and 10
numbers.
A "hw version" to specify what type of product it is (each product
uses a different protocol).
The problem I have is basically how to perform the discovery phase and then connect to a particular discovered object:
A. In the iBeacon adv packet, I should use UUID field for serial
number and major/minor field for the hw version, but if I do so, the
devices will be basically not discoverable (iBeacon SDK for iOS
needs to know the UUID to look for before starting the monitoring
phase, so it cannot be different for every device).
B. In iOS, the iBeacon features are available through CoreLocation libraries,
the standard BLE features are instead available through CoreBluetooth.
If I use an iBeacon advertisement packet, the objects discovered by
CoreBluetooth libraries do not see any information of the package
(so, the problem is: "How do I know which is the object with serial
XYZ?").
I realized that a possible solution for my problem would be advertising both iBeacon and standard BLE packages, in a "round robin way" let's say.
I tried it (I advertised for 500msec the iBeacon Package and for 500msec the standard BLE one) and Standard BLE seems to be ok.
I still need to investigate more about how iBeacon discovery reacts to this, but as said it could be a solution.
OPTION 1: If you want to use an iBeacon advertisement, forget about encoding any info directly in the ProximityUUID. As you mention, you need to know this up front in iOS. Instead, make a lookup table to convert the iBeacon identifiers to Hardware Number / Serial Number. Like this:
Proximity UUID Major Minor HW/N S/N
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10001 0001 abcdef0000000001
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10002 0001 abcdef0000000002
This system would let you have 65536*65536 different serial numbers for a single UUID. You would need to store this table server-side and have a web service to look up the Hardware Number and Serial Number based on the UUID/Major/Minor.
My company offers a cloud service at http://www.proximitykit.com that lets you do exactly this. You can even use our web service API to programmatically add items to your lookup table. (It will probably be big.)
OPTION 2: Since you need CoreBluetooth after a connection is established, you might consider using CoreBluetooth for the whole thing. Your advertisement would be identical for all hardware types, but after connecting, the first data transfer to iOS from the device would contain the hardware number and serial number. You could then adjust the communication as needed based on the hardware number.
i know that iBeacon use only advertising channel. which means there is no need connection.
im trying to make my own beacon module which send and receive data.
im curious about what makes the packet in iBeacon format(prefix /UUID / minor/ major/ TX) in communication ?
is it firmware?
let's assume that
when i make my iPhone act as iBeacon , it will send the advertising packet. which means it sends data in iBeacon format. but after turn off the app for iBeacon, i try to use my iphone
to send some files to laptop via Bluetooth low energy mode as usual.
then it will send data in bluetooth standard format. is this right?
given that situation, my iphone can be both iBeacon and just normal phone capable of bluetooth low energy.
i think also the beacon module can be like that. how about the product recently released? like estimote, redbearlab and so on. after connection, do they receive data?
Every iBeacon product works a little differently, but it is common for a product to be connectable for configuration purposes over Bluetooth LE.
Radius Networks' RadBeacon, for example, has firmware that sends out its advertisement as needed to be a standard iBeacon. The same firmware will allow a connection over Bluetooth LE, exchanging data with an external client (the RadBeacon app for iOS). This connectability is outside standard iBeacon functionality, using proprietary techniques that are still part of the larger Bluetooth LE standard.
Your understanding is therefore correct.
Full disclosure: I am Chief Engineer at Radius Networks.
I'm trying to write part of a J2ME application and I'm responsible for reading NMEA data from a GPS device attached via bluetooth (to a Dell Axim X51 PDA).
I've paired the gps device with the PDA and I can run the sample program that comes with the gps device and it succesfully streams NMEA strings.
In system settings, in GPS settings, I've set up a COM port (8) for programs to use to obtain GPS data, however, when providing the details for the GPS hardware port there doesn't seem to be a matching baud rate to the one I had to use in the sample program? Does this matter? What does baud rate actually mean?
Now, as far as I understand the settings, I should now be able to read NMEA data over COM 8?
However, when I print out:
System.getProperty("microedition.commports")
COM8 does not appear in the list returned and if I try and open a connection on that port I get the following error:
java.io.IOException: GetCommState() failed; error code=21, (21) The device is not ready.
Any pointers on successfully setting up the COM port for reading, and actually reading from it would be most welcome. I'm pretty stumped and clueless as to what to do.
Don't know about that particular device, but the usual way of opening a bluetooth COM port in J2ME is using the JSR-82 API.
You would scan for devices within your vicinity, figure out which is your GPS (usually contains "GPS" in the friendly name), scan for services on that device (most GPSs only offer one), and open a BTSPP connection to that service.
There is a good chance the j2me implementation on your device doesn't support bluetooth COM ports at all. I would suggest confirming that first. It could be worth comparing the result of the system property call on other (recent) handsets.