cmd_per_advertisement

[Peter-Lin]

Hi
Now I try to port beetle from bluez to bluedroid.
I don't understand the command "cmd_per_advertisement" well.
Test command is : pad 0006 03c0 d202010123456789abcdef01
"010123456789abcdef" is DeviceID
Could you explain the flags (0006) and appearance (03c0) and d202xxxxxxx01?

Could I port this command by the following bluedroid function?

set_adv_data(int client_if, bool set_scan_rsp, bool include_name,
bool include_txpower, int min_interval, int max_interval, int appearance,
uint16_t manufacturer_len, char* manufacturer_data,
uint16_t service_data_len, char* service_data,
uint16_t service_uuid_len, char* service_uuid)

thanks

Daniel

[afjgeorge]

Hi Daniel,

The flag and appearance numbers are a little tricky to explain. The flags, at least in blue, look like they may be set by the stack when we define what properties we want:

bit 0 LE Limited Discoverable Mode
bit 1 LE General Discoverable Mode
bit 2 BR/EDR not supported
bit 3 Simultaneous LE and BR/EDR

The appearance flags define what kind of BT device we are. You can find these flags at https://devzone.nordicsemi.com/documentation/nrf51/4.4.0/html/group___b_l_e___a_p_p_e_a_r_a_n_c_e_s.html

We set flag 960, HID Generic Device. I believe hubby actually sets that appearance flag when its communicating through beetle, for our diagnostic testing in the docs we set it only because we're emulating the advertising packets that hubby would send.

That bluedroid API looks like it would be the right one. If you haven't yet, give a look in hci_beetle.c - this is the code that mostly maps the beetle API commands to bluetooth operations, and I think you might be able to map most of the API we use in there (which is to Linux's libbluetooth) to Bluedroid equivalents.

[Peter-Lin]

Hi Joe
So "000603c0d202010123456789abcdef01" is service_uuid?
I don't see the service_data may I don't care it and fill in NULL?
thanks

Daniel

[afjgeorge]

Hey Daniel,

The data you put into an advertising packet are actually sent to beetle from the hubby daemon, so you don't really need to generate any of that data yourself, just pass it on from what hubby gives you:

0006 - Bluetooth flags (defined above)
03c0 - Appearance bits (defined above)
d202 - Afero's "manufacturer ID"
010123456789abcdef - Afero device ID
01 - Afero device flags (01=dirty, 02=rebooted, and so on)

You won't really be generating any of this data in beetle, you'll just get what hubby sends you and then generate an advertising packet for it. But generating advertisements in beetle is only needed for peripheral mode, and I think to get beetle off the ground we should probably be focusing on central/hub mode to start with since that's the most functionality and we can get the whole stack (beetle, hubby, etc) working while we finish up peripheral mode.

I think we may be better off spending a little time on beetle elsewhere to get going. Please allow me a little time to explain - apologies if you know all this already but i thought it was worth mentioning just in case.

Beetle performs one main function in the Afero ecosystem: to pass communications between the Hub daemon ("hubby") and Afero BLE devices with ASR radios. Beetle itself is just a communication layer; it listens for advertising packets from Afero devices and passes them on to hubby, and it takes commands from hubby to connect to Afero devices and pass data to/from them.

Beetle doesn't do much on it's own; it acts mostly on commands sent to is from the hubby daemon. In the diagnostic tests you've seen, you've seen commands like padv, con, wri, and so on (see https://github.com/AferoCE/beetle/blob/master/docs/commands.md). These commands are sent to beetle from hubby, beetle doesn't do much of anything without hubby telling it what to do.

Beetle operates in two modes, which are also set by hubby: "central" mode, in which hubby acts like a hub, listening for and connecting with Afero devices, and "peripheral" mode, in which hubby acts like an Afero edge device and communicates to some other device running Afero Hub software.

In the documentation we posted on how to "test" a beetle instance, connecting to beetle directly and issuing commands by hand, what we are doing with those manual commands is emulating the commands that beetle might receive from hubby, so that we an test beetle's response to those commands.

In porting beetle to another platform, or to another Bluetooth stack, we'd probably not want to worry as much about generating advertising packets, as that's something that's only used in peripheral mode.

In porting beetle to work for Bluedroid, there are two places we need to focus on:

hci_beetle.c - this is the majority of the layer that takes commands from the command processor and turns them into Bluetooth commands. I dont know Bluedroid's API, but it does support HCI so we should be able to find a reasonable level of mapping between the BlueZ HCI calls in hci_beetle.c and Bluedroid. Actually, in Linux we talk to libbluetooth which then talks to BlueZ, so if your Android version has libbluetooth support this might be a little easier.

baby_gatt (_common.c, _central.c, and _peripheral.c). Beetle actually transfers data to Afero devices over the GATT protocol. In BlueZ, GATT services are provided by a BlueZ daemon called "bluetoothd", which we don't talk to. Instead of relying on bluetoothd, we implement our own GATT service in this layer called "Baby GATT". There are some BT specific calls in those files to actually communicate with the Afero device, but again, since we use libbluetooth for this interface, it may be less "BlueZ-specific" and may not be as daunting to port.

When you have a chance, can you look at these layers and see what you think?

Thank you,

Joe