I am trying to make a BLED112 behave like an iBEacon and also advertise few more GATT services. While advertising user data for iBeacon as in Bluegiga examples works fine, I do not know how to also advertise the list of available GATT services. Any ideas are highly appreciated!
Take a look at my website for some potential help regarding using the BLED112 and Bluegiga tools: http://www.sureshjoshi.com/tag/bluegiga/
Otherwise, you shouldn't really be explicitly advertising anything. If you've set up your gatt.xml correctly, the GATT characteristics are advertised inherently (it's a BLE thing, not an explicit thing).
Are you sure you're setting them up correctly? Take a look at my BLE113 examples, specifically dealing with gatt.xml and see if there is anything helpful there: https://github.com/sureshjoshi/ble113-firmware-examples
One approach would be to use the Bluegiga dual-mode advertising as a guide and instead of the Physical Web Beacon, advertise your GATT service there. Assuming you have a 128 bit service UUID of 112233-4455-6677-8899-00AABBCCDDEEFF your advertising data would look like this:
procedure gatt_service_advertisement()
# Beacon mode
beaconMode = 1
#Stop advertisement
call gap_set_mode(0,0)
# Length
service_adv(0:1) = $11
# Incomplete list of 128 bit UUIDs (use $07 if the list is complete)
service_adv(1:1) = $06
# GATT Service UUID - should be little endian I think
service_adv(2:1) = $FF
service_adv(3:1) = $EE
...
service_adv(16:1) = $11
service_adv(17:1) = $00
# Set advertisement interval to 100ms.
# Use all three advertisement channels
call gap_set_adv_parameters(160, 160, 7)
# Set advertisement data
call gap_set_adv_data(0, 18, service_adv(0:18))
#set to advertising mode - with user data
call gap_set_mode(4, gap_undirected_connectable)
end
You can use that procedure to alternate advertisements between iBeacon and your GATT service by calling it in a repeating timer like in the linked dual-mode example.
Another approach would be to advertise the GATT service in the scan response, but without knowing more about your particular use case, it's hard to say if that's an option for you.
Related
I'm checking this source for scanning BT LE advertisement messages with BlueZ:
https://github.com/edrosten/libblepp/blob/master/src/lescan.cc
Mainly it does this (pseudo):
hci_fd=hci_open_dev(dev)
hci_le_set_scan_parameters(hci_fd, static_cast<int>(scan_type), interval, window,
own_type, filter_policy, 10000);
struct hci_filter nf;
hci_filter_clear(&nf);
hci_filter_set_ptype(HCI_EVENT_PKT, &nf);
hci_filter_set_event(EVT_LE_META_EVENT, &nf);
setsockopt(hci_fd, SOL_HCI, HCI_FILTER, &nf, sizeof(nf)
hci_le_set_scan_enable(hci_fd, 0x01, filter_dup, 10000);
In case I set hardware filter (by setting filter_dup to 1, I'm not getting my desired messages immediately. They come only at a low-frequency (1/min). That's fine, as the hardware filtering disables the duplicates, and I guess there is a timeout after which it let's them in again. (This seems to be exactly 1 minute in my case).
Turning off the filtering causes a huge traffic arriving in, from which I would only need all messages from a specific mac-addressed device. Can I somehow add a whitelist to the scanning command?
Then it can give me all the packets from my desired device, and leave out all the rest.
How can I do this with BlueZ over HCI?
I think your best option is to filter the messages within your code. I don't know of anything in the API to have it filter messages on the hardware level like you describe.
There is a "whitelist" function in BLE, but that's related to specifying a list of addresses that you want to connect to and then you let the hardware automatically connect to just those addresses. (sounds like you actually want just the ad packets and not actually connect, though)
EDIT:
I think I was wrong... Look at the filter_policy to hci_le_set_scan_parameters. If it's 0x1 then I think it filters based on the whitelist. I don't know how to set the whitelist, though.
I found it very useful looking at the source code for hcitool and gatttool when trying to understand the bluez library C calls. https://github.com/bluez/bluez/blob/master/tools/hcitool.c has reference to an "acceptlist" which seems to be what you want.
I'm dealing with the following challenge. In my system, there are two devices. Tags and anchors. Tags have BLE module with the transmit power 0dBm and not Long Range feature (BLE 4.0). Anchors have BLE module with transmit power over 8dBm and Long range feature (BLE 5.0).
I want tags to only receive some commands. Bi-directional communication is not necessary. This way, I can utilize the transmit power of anchor (8dBm) and thus quite bigger range, if tag with 0dBm is only receiving.
I read something about Observer/Broadcaster principle, where connecting is not necessary. But somehow devices have to agree on what frequencies should they hop on, the step and so on.
I'm asking, is it possible for device to only receive commands without previous negotiation with the sender?
Thank you very much for help. I'm beginning with BLE standard and there is a lot to learn.
Yes, it is possible to send data via adverts/scanning only. This way, there's no connection that needs to be established, and therefore no connection parameter negotiation takes place. As for the frequency hopping agreement - this happens via the baseband (in other words you will not deal with this in the software yourself) and is generally not applicable for advertising/scanning (these happen on 3 frequency channels only and therefore it is likely that the observer will catch what the broadcaster is broadcasting).
However, keep in mind that because you are broadcasting/advertising the data as opposed to directly sending it, that data can be received by any observing/scanning BLE devices which is not desired for safety/security/privacy purposes.
For more information on BLE communication, I recommend the links below:-
Getting Started with Bluetooth Low Energy
Is it Possible to Send Data with BLE Broadcast Mode
Using BlueZ, which
is the official Linux Bluetooth stack
I'd like to know which of the below two methods are better suited for detecting a device's presence in the nearby.
To be more exact, I want to periodically scan for a Bluetooth device (not BLE => no advertisement packets are sent).
I found two ways of detecting it:
1.) Using l2ping
# l2ping BTMAC
2.) Using hcitool
# hcitool name BTMAC
Both approaches working.
I'd like to know, which approach would drain more battery of the scanned device?
Looking at solution #1 (l2ping's source):
It uses a standard socket connect call to connect to the remote device, then uses the send command to send data to it:
send(sk, send_buf, L2CAP_CMD_HDR_SIZE + size, 0)
Now, L2CAP_CMD_HDR_SIZE is 4, and default size is 44, so altogether 48 bytes are sent, and received back with L2CAP_ECHO_REQ.
For hcitool I just have found the entrypoint:
int hci_read_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to);
My questions:
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
shall I reduce the l2ping's size? What shall be the minimum?
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
To answer your questions:-
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
l2ping BTMAC is the more suitable command purely because this is what it is meant to do. While "hcitool name BTMAC" is used to get the remote device's name, "l2ping" is used to detect its presence which is what you want to achieve. The difference in power consumption is really minimal, but if there is any then l2ping should be less power consuming.
shall I reduce the l2ping's size? What shall be the minimum?
If changing the l2ping size requires modifying the source code then I recommend leaving it the same. By leaving it the same you are using the same command that has been used countless times and the same command that was used to qualify the BlueZ stack. This way there's less chance for error and any change would not result in noticeable performance or power improvements.
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
Yes your assumption is correct. According the Bluetooth Specification v5.2, Vol 4, Part E, Section 7.1.19 Remote Name Request Command:
If no connection exists between the local device and the device
corresponding to the BD_ADDR, a temporary Link Layer connection will
be established to obtain the LMP features and name of the remote
device.
I hope this helps.
I want to initiate pairing on Bluez with a Bluetooth Low Energy device.
While there are some posts on how to trigger the SMP procedures using GATT, there is not much available if you do not want to use GATT.
My use case is that I want to use an encrypted link for bluetooth-6lowpan which exchanges data over L2CAP credit based mode and not ATT/GATT.
Further, I would like to use the OOB mode for SMP pairing.
Pointers on how I could trigger SMP pairing either using command line or writing a C program is appreciated.
Thank you!
I don't think it's possible to perform BLE pairing without the use of GATT commands (from the command line only). The reason for this is that security in LE is GATT-action-based. In other words, the characteristic/service permissions dictate whether you need to pair with the device or not (i.e. to read the heart rate characteristic, the device might dictate that you need to be paired first). For this, the operation would be something like:
gatttool --sec-level=high --device=00:11:22:33:44:55:66 --char-read --uuid=0x2A37
This command will establish pairing first before reading the characteristic.
As for how to perform this using a C program, You can download the BlueZ source code and have a look at what passing this "sec-level" option does. I've quickly browsed through the code and found this in utils.c:-
chan = bt_io_connect(connect_cb, NULL, NULL, &tmp_err,
BT_IO_OPT_SOURCE_BDADDR, &sba,
BT_IO_OPT_SOURCE_TYPE, BDADDR_LE_PUBLIC,
BT_IO_OPT_DEST_BDADDR, &dba,
BT_IO_OPT_DEST_TYPE, dest_type,
BT_IO_OPT_CID, ATT_CID,
BT_IO_OPT_SEC_LEVEL, sec,
BT_IO_OPT_INVALID);
where sec is set with sec = BT_IO_SEC_HIGH;
I hope this helps.
I bought a HM-15 BLE bluetooth module and successefully connected to Arduino. I am able to sent At commands and I would like to use it for scanning for iBeacons and get their major and minor.
Using AT+DISC? I can see the beacon address but I cannot connect to it and now I am stuck on how to retrieve major and minor
Can you help me? Here is the datasheet of the module:
http://www.elecrow.com/download/bluetooth40_en.pdf
Thanks
Bluetooth beacons do not require a connection and you read the identifiers directly from the advertisement.
Read section 19, Start a discovery scan, and learn how to read and decode the bytes in the discovered peripherals. The exact byte layout varies for different beacon types. For AltBeacon, an open source beacon variant, you can see the byte layout here: https://github.com/AltBeacon/spec
To decode a proprietary beacon format, you will need to learn how that beacon layout differs from the example linked above.
Old question, but just for the record, you can use AT-DISI?
This will scan for beacons, including iBeacons and also AltBeacons. The response from HM-10 will include RSSI for each.
PS: I'm assuming HM-15 and HM-10 operate the same way. Probably not exactly a fully reasonable assumption.