Hi,
I've been reading Bluetooth Core spec v5.0, looking for a way to
optimize sending LE Advertising Report events through HCI.
It turns out that spec allows concatenating a few reports into a single
HCI frame: 7.7.65.2 says that "The Controller may queue these
advertising reports and send information from multiple devices in one LE
Advertising Report event. So far, so good.
The question I have is about the exact format of this event. Wording and
tables in the spec suggest that fields from concatenated reports should
be interleaved in the HCI frame, that is for num_reports = 2, fields
should be ordered as follows:
event_type[0]
event_type[1]
address_type[0]
address_type[1]
address[0]
address[1]
length[0]
length[1]
data[0]
data[1]
rssi[0]
rssi[1]
I don't this format is "natural", if I were to choose I would rather
simply concatenate a few reports. This is exactly what BlueZ (and other
projects too, like Zephyr) expects in tools/parser/hci.c:
static inline void evt_le_advertising_report_dump(int level, struct frame *frm)
{
uint8_t num_reports = p_get_u8(frm);
while (num_reports--) {
le_advertising_info *info = frm->ptr;
/* .... */
frm->ptr += LE_ADVERTISING_INFO_SIZE + info->length;
frm->len -= LE_ADVERTISING_INFO_SIZE + info->length;
frm->ptr += RSSI_SIZE;
frm->len -= RSSI_SIZE;
}
}
Who is right? Seems like most of implementations deviate from the
spec, but OTOH I haven't seen any HCI controllers sending num_reports
greater than 1...
cheers
--
Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
