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
