Hi Archie, On Tue, Dec 15, 2020 at 12:33 AM Archie Pusaka <apusaka@xxxxxxxxxx> wrote: > > From: Archie Pusaka <apusaka@xxxxxxxxxxxx> > > This is to leverage the filtering by RSSI feature on those controllers > which supports advertisement packet filtering. To avoid changing the > existing API and breaking it, a new opcode is required. > > Reviewed-by: Manish Mandlik <mmandlik@xxxxxxxxxxxx> > Reviewed-by: Miao-chen Chou <mcchou@xxxxxxxxxxxx> > Reviewed-by: Yun-Hao Chung <howardchung@xxxxxxxxxx> > > Signed-off-by: Archie Pusaka <apusaka@xxxxxxxxxxxx> > --- > > doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt > index 1aa43d6c3c..d5c7169630 100644 > --- a/doc/mgmt-api.txt > +++ b/doc/mgmt-api.txt > @@ -3800,6 +3800,58 @@ Add Extended Advertising Data Command > Busy > > > +Add Advertisement Patterns Monitor With RSSI Threshold Command > +============================================================== > + > + Command Code: 0x0056 > + Controller Index: <controller id> > + Command Parameters: Pattern_Count (1 Octet) I'd move the pattern_count after the rssi if the rssi is not per pattern, well in case the rssi is per pattern then it should be put inside the Pattern directly. > + RSSI_Data { > + High_Threshold (1 Octet) > + High_Threshold_Timer (2 Octets) > + Low_Threshold (1 Octet) > + Low_Threshold_Timer (2 Octets) > + Sampling_Period (1 Octet) > + } > + Pattern1 { > + AD_Type (1 Octet) > + Offset (1 Octet) > + Length (1 Octet) > + Value (31 Octets) > + } > + Pattern2 { } > + ... > + Return Parameters: Monitor_Handle (2 Octets) > + > + This command is essentially the same as Add Advertisement Patterns > + Monitor Command (0x0052), but with an additional RSSI parameters. > + As such, if the kernel supports advertisement filtering, then the > + advertisement data will be filtered in accordance with the set > + RSSI parameters. Otherwise, it would behave exactly the same as the > + Add Advertisement Patterns Monitor Command. > + > + Devices would be considered "in-range" if the RSSI of the received adv > + packets are greater than High_Threshold dBm for High_Threshold_Timer > + seconds. Similarly, devices would be considered lost if no received > + adv have RSSI greater than Low_Threshold dBm for Low_Threshold_Timer > + seconds. Only adv packets of "in-range" device would be propagated. > + > + The meaning of Sampling_Period is as follows: > + 0x00 All adv packets from "in-range" devices would be > + propagated. > + 0xFF Only the first adv data of "in-range" devices would be > + propagated. If the device becomes lost, then the first > + data when it is found again will also be propagated. > + other Advertisement data would be grouped into 100ms * N > + time period. Data in the same group will only be > + reported once, with the RSSI value being averaged out. > + > + Possible errors: Failed > + Busy > + No Resources > + Invalid Parameters > + > + > Command Complete Event > ====================== > > -- > 2.29.2.684.gfbc64c5ab5-goog > -- Luiz Augusto von Dentz