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 <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
Hi Michał,
> On 23 Jan 2019, at 12.24, Michał Lowas-Rzechonek <[email protected]> wrote:
> 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.
See Vol 2, Part E, section 5.2 (page 728 in the pdf):
“
• Arrayed parameters are specified using the following notation: ParameterA[i]. If more than one set of arrayed parameters are specified (e.g. ParameterA[i], ParameterB[i]), then, unless noted otherwise, the order of the parameters are as follows: ParameterA[0], ParameterB[0], ParameterA[1], ParameterB[1], ParameterA[2], ParameterB[2], ... ParameterA[n], ParameterB[n]
“
Johan
Johan,
On 01/23, Johan Hedberg wrote:
> > 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]
>
> See Vol 2, Part E, section 5.2 (page 728 in the pdf):
> “
> • Arrayed parameters are specified using the following notation:
> ParameterA[i]. If more than one set of arrayed parameters are
> specified (e.g. ParameterA[i], ParameterB[i]), then, unless noted
> otherwise, the order of the parameters are as follows: ParameterA[0],
> ParameterB[0], ParameterA[1], ParameterB[1], ParameterA[2],
> ParameterB[2], ... ParameterA[n], ParameterB[n]
> “
Oh boy. Thanks a lot, I missed this.
Not the clearest wording in the world :|
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND