Silicon Labs documentation on Wi-Fi 6 + BLE Linux Driver version 2.15.0.

Documentation source: https://docs.silabs.com/wifi91xrcp/2.15.0

# Wi-Fi 6 + BLE Linux Driver

## Developing with SiWT917 in RCP Mode

The SiWT917, in Radio Co-processor (RCP) mode, offers low-level Wi-Fi and Bluetooth Low Energy for systems that have a higher-end 32/64-bit applications processor running a Linux-based operating system. The SiWT917 interfaces to a processor using SDIO host interfaces, with the networking and wireless stacks/profiles running on the host processor. SiWT917 provides multiple operating modes including Wi-Fi Client, Wi-Fi Access Point, Wi-Fi Client + Access Point, Wi-Fi + Bluetooth Low Energy (BLE), and BLE-only mode.

To get started, download the latest [**SiWT917 Open Source Driver**](https://github.com/SiliconLabs/si91x-rcp-driver) and see the [Getting Started Guide](../wifi91xrcp-getting-started/).

## Getting Started with SiWT917 in RCP Mode

This guide describes how to get started with the SiWT917 Linux driver in RCP mode.

> **Note:** The output images in this guide are for illustration purposes only. Details such as board names and version numbers may not exactly match the product.

### Hardware Requirements

The hardware requirements are as follows:

- Wi-Fi Access Point (802.11 b/g/n/ax)
- One of the following Host radio boards
- [SIWX917-RB4346A](https://www.silabs.com/development-tools/wireless/wi-fi/siwx917-rb4346a-wifi-6-bluetooth-le-soc-4mb-flash-radio-board?tab=overview) - SiWx917 Wi-Fi 6 and Bluetooth LE 4 MB Flash Co-Processor Radio Board (hereafter referred to as SiWx917 radio board)
- [SiW917Y-RB4357A](https://www.silabs.com/development-tools/wireless/wi-fi/siw917y-rb4357a-wi-fi-6-bluetooth-le-4mb-flash-radio-board-for-rcp-and-ncp-modules?tab=overview) - SiWx917 Wi-Fi 6 and Bluetooth LE 4 MB Flash Co-Processor Radio Board (hereafter referred to as SiWx917 radio board)
- SiW917Y-RB4357C - SiWx917 Wi-Fi 6 and Bluetooth LE Co-Processor Radio Board (hereafter referred to as SiWx917 radio board)
- [SI-EB8045A](https://www.silabs.com/development-tools/wireless/wi-fi/expansion-adapter-board-for-co-processor-radio-boards?tab=overview) - EXP Adapter Board for SiWx917 Co-Processors (hereafter referred to as adapter board)
- [SI-EB8045B](https://www.silabs.com/development-tools/wireless/wi-fi/raspberry-pi-hat-adapter-board-for-co-processor-radio-boards?tab=overview) - EXP Adapter Board for SiWx917 Co-Processors (hereafter referred to as adapter board)
- Laptop/PC with SDIO slot or any embedded platform with Linux Board support package for BRD8045A.
- SDIO adapter connector 8046A for BRD8045A.
- [Raspberry Pi 4](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/) with Raspberry Pi 4 OS for BRD8045B.

> **Note:** If the laptop has a full SDIO slot, procure a [micro SD](https://www.amazon.in/TCOS-TECH-MicroSD-Adapter-Converter/dp/B08W9SG5SC/ref=sr_1_3?keywords=Micro+SD+Adapter&qid=1707723732&sr=8-3) adapter.
> If the Laptop/PC does not have an SDIO slot, a SDHC/SD/MMC to CardBus Adapter like the one available at [http://www.hwtools.net/cardreader/SDCBA_C01.html](http://www.hwtools.net/cardreader/SDCBA_C01.html) can be used.

### Software Requirements

The software requirements are as follows:

- [SiWx91x RCP Driver](https://github.com/SiliconLabs/si91x-rcp-driver)
- Supported Linux Kernel versions are mentioned in the [Release Notes](../wifi-917-rcp-release-notes-overview/) – should enable the open source [Enable SDIO stack](../wifi91xrcp-developers-guide-software-configuration/enable-sdio-stack#enabling-the-sdio-stack).
- DHCP Server (for Wi-Fi Access Point mode)
- Bluetooth supported commands bluetoothctl and bluetoothd must be present.
- Compatible Bluetooth Host Stack, e.g., the Open Source BlueZ Stack v:5.56
- [wpa_supplicant](https://w1.fi/wpa_supplicant/) (for Wi-Fi Client mode)
- [hostapd](https://w1.fi/hostapd/) (for Wi-Fi Access Point mode)

### Software Package Contents

The driver package is delivered in the format: **SiWT917.w.x.y.z.zip**, where the naming convention is as follows:

'w' is Major version

'x' is Minor version

'y' is Patch number

'z' is Build number

The driver package contains the following files/folders:

- Readme.txt
- Makefile
- release
- Firmware
- rsi (contains driver source code)
- apps

The drivers can be found under each product in our [github repo](https://github.com/SiliconLabs/si91x-rcp-driver).

### Setup Diagram

There are two variants of SiWx917 RCP Evaluation boards:

|Board|Description|Contents|
|---|---|---|
|**SIWX917_RB4346A, SI-EB8045A & BRD8046A**|SiWx917 Wi-Fi 6 and Bluetooth LE Co-Processor EXP Expansion Kit|1x BRD4346A SiWx917 Wi-Fi 6 and Bluetooth LE Co-Processor Radio Board<br/><br/>1x BRD8045A Adapter Board for Co-Processors<br/><br/>1x BRD8046A EXP-to-SDCard Adapter board|
|**SIWX917_RB4346A, SI-EB8045B**|SiWx917 Wi-Fi 6 and Bluetooth LE Co-Processor Raspberry Pi Expansion Kit|1x BRD4346A SiWx917 Wi-Fi 6 and Bluetooth LE Co-Processor Radio Board<br/><br/>1x BRD8045B Adapter Board for Co-Processors|

1. SIWX917_RB4346A, SI-EB8045A & BRD8046A  
   ![SiWx917-EB4346A](/wifi91xrcp-getting-started/2.15.0/images/siwx917-eb4346a.png)
2. SIWX917_RB4346A, SI-EB8045B  
   ![SiWx917-EB4346B](/wifi91xrcp-getting-started/2.15.0/images/eb4346-b.png)

#### i.MX6 Wandboard Connectivity Diagram with SiWx917_RB4346A + SI-EB8045A + BRD8046A

![MX6 Wandboard Connectivity Diagram with SiWx917-EB4346A](/wifi91xrcp-getting-started/2.15.0/images/imx6-wand-eb4346-a.png)

> **Note:** Above setup diagram shows the connectivity of SiWx917-EB4346A with the [i.MX6 Wandboard](https://www.technexion.com/products/system-on-modules/evk/wandboard-imx6/) host (referance platform) using a SDIO adapter board 8046A.

#### RPi4 connectivity diagram with SIWX917_RB4346A + SI-EB8045B

![RPi4 connectivity diagram with SiWx917-EB4346B](/wifi91xrcp-getting-started/2.15.0/images/rpi4-eb4346-b.png)

See the [SiWT917 RCP Getting Started Guide with Raspberry Pi](https://www.silabs.com/documents/public/application-notes/AN1444_SiWT917_RCP_Getting_Started_Guide_with_Raspberry_Pi.pdf) for more details, Steps to flash Demo RPi4 image and configure in STA mode.

> **Note:** Above setup diagram shows the connectivity of SiWx917_EB4346B with Raspberry Pi4 host platform using Raspberry pi 40 pin header.

### Compilation Steps

This section describes the steps to be followed to compile the driver for different platforms. The steps are outlined below:

1. Extract the package using the following command:  
   ```c  
    # unzip  SiWT917.w.x.y.z.zip   
   ```
2. Navigate to the package folder and run the following command in order to copy all the files present in Firmware folder to `'/lib/firmware'`:  
   ```c  
      # cd SiWT917.w.x.y.z/   
      # cp Firmware/* /lib/firmware   
   ```
3. There are two ways in which you can build the driver.  
   1. [Compile from the local path](#compile-from-local-path)  
   2. [Compile from kernel source](#compile-from-kernel-source)

#### Compile from Local Path

1. Configure build flags in driver source. Open Makefile at driver path 'SiWT917.w.x.y.z/' and configure build flags.  
   ```c  
      # vim Makefile   
   ```
2. Below are the build flags to be set based on the usage of driver. Selecting the required options shall reduce the binary size which is important for kernel modules particularly on embedded platforms.  
   1. **KERNELDIR** : Provide the kernel source path here. For example on X-86 below path is used.    
      ```c    
      KERNELRELEASE=$(Shell uname -r)     
      KERNELDIR=/lib/modules/$(KERNELRELEASE)/build     
      ```  
   2. **CONFIG_RSI_COEX_MODE** : Enable this flag when Wi-Fi and BLE coexistence mode is used.  
   3. **CONFIG_RSI_BT_ALONE** : Enable this flag when only BT LE only mode is used.
3. Build the driver using make command.  
   ```c  
     # make clean; make   
       
   ```

##### Compile on an Embedded Platform

For embedded platforms, add the Kernel path for target platform and toolchain path as cross compilation option to the **"make"** command.

For example, if the target platform is iMX6 add the kernel path as below :

```c
KERNELDIR=home/test/Wand/armv7-multiplatform/KERNEL 
```

For example, if the target platform is ARM and tool chain path is _**"/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-none-linux-gnueabi-"**_, then the command is:

```c
## make ARCH=arm CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-none-linux-gnueabi- 
```

#### Compile from Kernel Source

1. Copy the driver 'rsi' to <kernel_source_path> /drivers/net/wireless/.  
   (Ex : linux-5.7.0/drivers/net/wireless/rsi )
2. Navigate to the rsi directory and move Makefile_ker to Makefile.  
   ```c  
   # cd linux-5.7.0/drivers/net/wireless/rsi/  
   # mv Makefile_ker Makefile   
   ```
3. Run 'make menuconfig' command from kernel source directory. (Ex : linux-5.7.0 )  
   ```c  
   # make menuconfig   
   ```
4. Navigate to 'Device Drivers->Network device support->Wireless LAN'.
5. Select 'Redpine Signals Inc' devices.
6. Select the SDIO bus support. You will see the below screen with all the build options mentioned above. Select the required options.![SDIO Bus](/wifi91xrcp-getting-started/2.15.0/images/image1.jpg)

**Note:** When `Redpine Signals Wi-Fi STA PLUS AP support` is enabled , run `make oldconfig`, followed by `make prepare`.

1. To build the driver, run the following command:  
   ```c  
   # make M=drivers/net/wireless/rsi   
   ```

On successful compilation, make will generate rsi_91x.ko , and rsi_sdio.ko according to the configuration.

### Installing the Driver

#### Installing Modules

After a successful compilation, the driver generates the following modules in the 'SiWT917.w.x.y.z/release' folder according to the configuration. They are outlined below:

- rsi_91x.ko
- rsi_sdio.ko

To change the directory, run the following command:

```c
	# cd SiWT917.w.x.y.z/release/
```

To install the driver, run the following commands.

1. Install the dependencies:  
   ```c  
   #modprobe mac80211  
   #modprobe bluetooth  
   ```
2. Insert rsi_91x.ko with the required module params (configuration):  
   ```c  
   #insmod rsi_91x.ko dev_oper_mode=<mode> rsi_zone_enabled=<val> ...   
   ```

Module params are used by the driver to take initial configuration required. If not provided, default configuration is used. For most of the applications, default values of these module params will be sufficient. Supported module params with their configurable limits are explained in the Developer's Guide in section [Common Parameters](../wifi91xrcp-developers-guide-software-configuration/common-software-parameters#configuring-common-software-parameters)

In the above command example, module param **rsi_zone_enabled** is to enable debug prints in dmesg. Default value of rsi_zone_enabled value is 1, which prints errors (only) in terminal. Please refer [Debug Prints](../wifi91xrcp-developers-guide-software-configuration/debug-prints#debug-prints), to enable more debug prints.

**dev_oper_mode** : Device operating mode indicates the possible combination of the wireless protocols that can configured with the device.

The table below provides the operating mode details with its constraints.

<table>
  <thead>
<tr>
<th colspan="1" rowspan="1"><div>S.No</div></th>
<th colspan="1" rowspan="1"><div>Operating Mode</div></th>
<th colspan="3" rowspan="1"><div>Protocol Support</div></th>
<th colspan="1" rowspan="1"><div>Maximum No. of Clients for WLAN AP</div></th>
<th colspan="1" rowspan="1"><div>Maximum No. of BT Connections</div></th>
<th colspan="1" rowspan="1"><div>Maximum No. of BLE Connections</div></th>
</tr>
  </thead>
  <tbody>
<tr>
<td colspan="1" rowspan="1"><div></div></td>
<td colspan="1" rowspan="1"><div></div></td>
<td colspan="1" rowspan="1"><div>STA</div></td>
<td colspan="1" rowspan="1"><div>AP</div></td>
<td colspan="1" rowspan="1"><div>BT LE</div></td>
<td colspan="1" rowspan="1"><div></div></td>
<td colspan="1" rowspan="1"><div></div></td>
<td colspan="1" rowspan="1"><div></div></td>
<td colspan="1" rowspan="1"><div></div></td>
<td colspan="1" rowspan="1"><div></div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>1</div></td>
<td colspan="1" rowspan="1"><div>1</div></td>
<td colspan="1" rowspan="1"><div>√</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>2</div></td>
<td colspan="1" rowspan="1"><div>2</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>√</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>10 clients</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>3</div></td>
<td colspan="1" rowspan="1"><div>3</div></td>
<td colspan="1" rowspan="1"><div>√</div></td>
<td colspan="1" rowspan="1"><div>√</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>8 clients</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>4</div></td>
<td colspan="1" rowspan="1"><div>8</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>√</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>2 (Can be as 2 BLE peripherals or 2 BLE Centrals or 1 Central+1peripheral connections)</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>5</div></td>
<td colspan="1" rowspan="1"><div>9</div></td>
<td colspan="1" rowspan="1"><div>√</div></td>
<td colspan="1" rowspan="1"><div>X</div></td>
<td colspan="1" rowspan="1"><div>√</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>N/A</div></td>
<td colspan="1" rowspan="1"><div>2</div></td>
</tr>
  </tbody>
</table>

If any invalid mode is passed to the module, driver returns error and exit. You can check the error message debug logs.

**Note:**

For mode 8, build flag CONFIG_RSI_BT_ALONE should be enabled in the driver Makefile.

For mode 9, build flag CONFIG_RSI_COEX_MODE should be enabled in the driver Makefile.

1. For the SDIO interface, run the following command:  
   ```c  
   #insmod rsi_sdio.ko sdio_clock=<clk_val>   
   ```  
   In this case, `clk_val` can have a value ranging from 1 to 50 (in MHz).

After a successful installation, a new wireless interface shall be created or WLAN and/or BLE as per the dev_oper_mode selection.

a. If **WLAN** is selected, run one of the following commands to verify the interface details.

To see the name of the Wi-Fi interface created after successful driver installation:

```c
## ifconfig -a 
```

You should expect an output like the sample shown below with all other available interfaces included.

```c
   wlan0  flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
   inet6 fe80::8da:1aff:fe1e:d1c8  prefixlen 64 scopeid 0x20<link>        
   ether 88:da:1a:1e:d1:c8  txqueuelen 1000  (Ethernet)
   RX packets: 3 bytes 372 (372.0 B)        
   RX errors 0 dropped 0 overruns 0 frame 0
   TX packets: 6 bytes 696 (696.0 B)        
   TX errors 0 dropped 0 overruns 0 collisions:0  
```

The `iw` utility can also be used to retrieve the interface and physical device details:

```c
   # iw dev <interface_name> info  
```

The sample output for this command is shown below.

Interface wlan0

```c
  ifindex 5    
  wdev 0x100000001    
  addr 88:da:1a:1e:d1:c8
  type managed
  wiphy 1 channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
```

As can be seen, in this case, phy<X> is termed as wiphy 1.

b. If **BLE** is selected, run the following command to verify the interface details.

To see the name of the BLE interface created after successful driver installation:

```c
  # hciconfig -a 

   hci0:  Type: BR/EDR  Bus: USB       
   BD Address: 88:DA:1A:00:00:C2  ACL MTU: 1021:3  SCO MTU: 64:3
   UP RUNNING
   RX bytes:1006 acl:0 sco:0 events:55 errors:0
   TX bytes:0 acl:0 sco:0 commands:55 errors:0
   Features: 0xbf 0xfe 0x0d 0xfe 0xdb 0xff 0x5b 0x87
   Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
   Link policy: RSWITCH SNIFF
   Link mode: SECONDARY ACCEPT
   Name: 'lapt64'
   class: 0x0c010c
   service Classes: Computer, Laptop
   HCI Version:  (0x9) Revision: 0x0
   Manufacturer: internal use (65535) 
```

### Configuring the Driver

#### Configure in Wi-Fi Station Mode

This section provides the steps to configure Wi-Fi station mode using startup script or Manual commands using wpa_supplicant. Both procedures are given below. The user can choose any method.

Before installation, the user needs to stop the existing network manager and unblock WLAN from rfkill. Run the following commands to stop the network-manager on different Linux distribution.

1. For Ubuntu:  
   ```c  
    # service network-manager stop   
   ```
2. For Fedora/Raspberry Pi4 OS:  
   ```c  
   # service NetworkManager stop   
   ```
3. To stop rfkill blocking WLAN:  
   ```c  
    # rfkill unblock wlan (or) #rfkill unblock all   
   ```

##### Startup Script for Wi-FI Station Mode

User can use the script at path 'SiWT917.w.x.y.z/release' to run Wi-Fi STA mode after [Configure Station Using WPA supplicant](#configure-station-using-wpa-supplicant).

```c
   #./start_SiWT917.sh  STA
```

See the [Startup Script](../wifi91xrcp-developers-guide-software-tools/) section for more details about Startup script file to configure in different operating modes.

##### Manual Configuration of Wi-Fi Station Mode

- For station mode connectivity, ensure that the dev_oper_mode is set in installation as given below and interface is detected after the installation. See the [Installing the Driver](#installing-the-driver) section.  
  ```c  
   dev_oper_mode = 1  
  ```
- Install the modules manually using the below commands to configure in Wi-Fi STA mode, debug zone=0x601 and SDIO clock=50 Mhz  
  ```c  
    #insmod rsi_91x.ko dev_oper_mode=1 rsi_zone_enabled=0x601  
    
    #insmod rsi_sdio.ko sdio_clock=50  
  ```

##### Configure Station Using WPA Supplicant

a) Create a **sta_settings.conf** file with the information below. Also, fill the information like SSID, psk etc corresponding to the AP you intend to connect in this file. Sample sta_settings.conf file is available within the 'SiWT917.w.x.y.z/release' directory of release package with basic configurations required. The user may use this file and edit the information as explained below for Open and WPA2-PSK (CCMP) secure modes. For the details of all configurations available please refer to the open source supplicant wpa_supplicant.conf file.

```c
   ctrl_interface=/var/run/wpa_supplicant
   update_config=1 
```

Also, add network block to the sta_settings.conf file as per the AP security. An example network block for different security modes is listed below.

**i. For Open (non-Secure) mode:**

```c
   network={
   ssid="\<SSID of Access Point\>"
   key_mgmt=NONE
   priority=3
   }  
```

**ii. For WPA2-PSK (CCMP) mode:**

```c
   network={
   ssid="\<SSID of Access Point\>"
   key_mgmt=WPA-PSK
   psk=\<passphrase specified in the Access Point\>
   proto=WPA2
   pairwise=CCMP
   group=CCMP
   }
```

The pass phrase can be input either in ASCII or Hexadecimal formats:

**ASCII Format:** psk="very secret passphrase"

**Hexadecimal Format:** psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c7

See the section [Configuring the Driver in Wi-Fi Station Mode](../wifi91xrcp-developers-guide-operating-modes/wifi-station-mode#configuring-the-driver-in-wi-fi-station-mode) for more security mode configurations and running Wi-Fi STA mode using Network manager.

b) To start the supplicant, run the following command:

```c
## wpa_supplicant -i <interface_name> -D nl80211 –c sta_settings.conf –dddt > supp.log & 
```

For example :

```c
## wpa_supplicant -i wifi0 -D nl80211 –c sta_settings.conf –dddt > supp.log &
```

- "–i" option specifies the Wi-Fi interface name
- <interface_name> - This name as listed in iw dev output (here wifi0)
- "-D" specifies the driver interface to be used. In open source driver it is nl80211.
- "-c" specifies the supplicant configuration file.
- "-d" specifies the log level of supplicant. You can apend more d's to it for more detailed logs.

c) To check the scan results, run the following command:

```c
 # wpa_cli -i <interface_name> scan_results
```

For example, above command will give scan results output as follows.

```c
   bssid         / frequency   / signal level    /  flags/ ssid
   50:d4:f7:1e:5a:40   2457           -21  [WPA2-PSK-CCMP][ESS]    TP_LINK
   04:79:70:72:03:e7   2412           -31      [ESS]              honor_9i    
   38:A4:ED:DE:BB:00   2412           -26  [WPA2-PSK-CCMP][ESS]   Range
```

d) To check whether the connection is successful or not, run the following command:

```c
## iwconfig <interface_name> 
```

For example, if the connection is successful, we will see the output below.

```c
   wlan0      IEEE 802.11bgn  ESSID:"Range"  Nickname:""        
        Mode:Managed Frequency:2.412 GHz AccessPoint:38:A4:ED:DE:BB:00
        Bit Rate:39 Mb/s   Tx-Power=16 dBm  
        Retry short limit:7  RTS thr:2353 B Fragment thr:2352 B
        Encryption key:off 
        Power Management:off          
        Link Quality=80/80  Signal level=-28 dBm  Noise level:0 dBm          
        Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0          
        Tx excessive retries:0  Invalid misc:0   Missed beacon:0
```

If the connection is successful, then the connected Access point SSID along with the MAC address is displayed as shown above. If it is not connected to an Access point, a message **"Not Associated"** is displayed as shown below.

```c
   wlan0    IEEE 802.11  ESSID:off/any 
     Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm 
     Retry short limit:7   RTS thr:off   Fragment thr:off   
     Encryption key:off
     Power Management:off 
```

e) IP address for the device can be set in two ways either get IP address dynamically from AP or set static IP address. To obtain dynamic IP address from AP, run the following commands:

```c
## dhclient <interface_name> -r
## dhclient <interface_name> -v 
```

To set static IP address to STA, run the following command:

```c
## ifconfig <interface_name> <IP_address> 
```

f) To check whether IP is assigned or not, run the following command:

```c
## ifconfig  <interface_name>
```

Output:

```c
   wlan0:    flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500        
         inet 192.168.1.114  netmask 255.255.255.0  broadcast 192.168.1.255        
         inet6 fe80::224:d7ff:fe56:54dc  prefixlen 64  scopeid 0x20<link>       
         ether 00:24:d7:56:54:dc  txqueuelen 1000  (Ethernet)
         RX packets 31160  bytes 31082515 (29.6 MiB)       
         RX errors 0  dropped 0  overruns 0  frame 0        
         TX packets 23356  bytes 3367496 (3.2 MiB)        
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 
```

g) To check data transfer by pinging another station, run the following command:

```c
   # ping <IP_address>

   Ex : ping 192.168.1.1
```

#### Configure in Wi-Fi Station + BLE Mode

This section describes Startup script and manual ways to configure the driver to run both as a Wi-Fi Station and in BLE mode.

##### Startup Script for Wi-Fi Station + BLE Mode

User can use the script at path rsi to run Wi-Fi STA + BLE mode.

```c
   #./start_SiWT917.sh  STA_BLE 
```

See the [Startup Script](../wifi91xrcp-developers-guide-software-tools/) section for more details about Startup script file to configure in different operating modes.

##### Manual Configuration of Wi-Fi Station + BLE Mode

Ensure that the dev_oper_mode is set as below.

```c
dev_oper_mode = 9 (Wi-Fi STA + BLE)
```

Run the following commands to install the modules manually. These commands configure the Wi-Fi STA + BLE mode, debug zone=0x601 and SDIO clock=50 Mhz

```c
    #insmod rsi_91x.ko dev_oper_mode=9 rsi_zone_enabled=0x601

    #insmod rsi_sdio.ko sdio_clock=50
```

Once the installation completed and interface of Wi-Fi and Bluetooth are detected follow below procedure to install Wi-Fi and BLE.

1. For Wi-Fi STA, follow the instructions given in [Configure Station Using WPA Supplicant](#configure-station-using-wpa-supplicant) to configure in Wi-Fi STA mode.
2. Also for Bluetooth LE protocol, follow the instructions in the [Configure Using HCI Commands](../wifi91xrcp-developers-guide-operating-modes/ble-mode#configure-using-hci-commands) section.

### Uninstalling the Driver

To uninstall the driver, follow the procedure below.

If wpa supplicant method is used to connect in STA mode, run the following command to kill wpa supplicant:

```c
 # killall wpa_supplicant 
```

To kill hostapd application, run the following command:

```c
 # killall hostapd
```

To remove the driver, run the following command:

```c
 # rmmod rsi_sdio
 # rmmod rsi_91x 
```

After uninstalling the driver, the created wireless interface disappears.

## Release Notes

### Wi-Fi 6 + BLE (RCP)  2.15.0 (April 8, 2026) - Release Notes

The SiWT917 RCP Driver is a SoftMAC driver that interacts with the Linux wireless MAC layer, MAC80211. It consists of simple and efficient kernel modules that currently support SiWT917 RCP chipsets and can be ported to any embedded platform, in addition to the X-86 platform.

Click [here](https://github.com/SiliconLabs/si91x-rcp-driver/tags) for SiWT917 releases.

#### Release Summary

<table>
    <thead>
        <tr>
            <th>Release Item</th>
            <th>Version</th>
            <th>Release Date</th>
            <th>Release Notes</th>
            <th>Key Features</th>
            <th>Bug Fixes</th>
            <th>Chip Enablement</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Wi-Fi</td>
            <td>2.15.0</td>
            <td>April 8, 2026</td>
            <td><a href="wifi-917-rcp-wifi-release-notes">Release Notes</a></td>
            <td>
                <ul>
                    <li>Added kernel support till 6.12.</li>
                    <li>Added support for module refresh (external low-power XTAL option support).</li>
                </ul>
            </td>
            <td>
                <ul>
                    <li>Fixed delay issue while creating the VAP.</li>
                    <li>Fixed beacon and broadcast reception issues in congested environments.</li>
                    <li>Fixed an issue where the module was incorrectly identifying early beacons from the AP, leading to excessive power consumption during long-run tests.</li>
                    <li>Improved Wi-Fi RSSI Accuracy for high attenuation levels.</li>
                    <li>Fixed Beacon reception issues in congested environment.</li>
                    <li>Disabled RF turnoff till the end of packet on air when the packet is dropped.</li>
                </ul>
            </td>
            <td>OPN : SIWT917Y100XGAXA<p>Board: SiW917Y-RB4357C</p>
            </td>
        </tr>
        <tr>
            <td>Bluetooth LE</td>
            <td>2.15.0</td>
            <td>April 8, 2026</td>
            <td><a href="wifi-917-rcp-ble-release-notes">Release Notes</a></td>
            <td>None</td>
            <td>
                <ul>
                    <li>Fixed a BLE disconnection issue that occurred when the DUT attempted to connect to an access point while configured for the China (SRRC) region only.</li>
                    <li>Fixed an issue where the output transmit power was higher in end-to-end mode compared to PER test mode across all temperatures.</li>
                    <li>Fixed an issue where the central device was unable to establish a BLE Advertising Extension (AE) connection when operating with LE Coded PHY rates.</li>
                    <li>Fixed a SiWx917Y BLE test power mismatch where SRRC ('cn') region output was 2 dB higher than 'us'.</li>
                    <li>Functional fixes for RSSI accuracy.</li>
                </ul>
            </td>
            <td>OPN : SIWT917Y100XGAXA<p>Board: SiW917Y-RB4357C</p>
            </td>
        </tr>
        <tr>
            <td>Multiprotocol</td>
            <td>2.15.0</td>
            <td>April 8, 2026</td>
            <td><a href="wifi-917-rcp-multi-protocol-release-notes">Release Notes</a></td>
            <td>
                <ul>
                    <li>Added KC and SRRC region selection support in PER mode for Wi-Fi and BLE.</li>
                </ul>
            </td>
            <td>None</td>
            <td>OPN : SIWT917Y100XGAXA<p>Board: SiW917Y-RB4357C</p>
            </td>
        </tr>
    </tbody>
</table>

#### Using This Release

[What's in the Release?](#what-s-in-the-release) | [Release Details](#release-details) | [Installation and Use](#installation-and-use) | [Help and Feedback](#help-and-feedback)

##### What's in the Release?

- [si91x-rcp-driver](https://github.com/SiliconLabs/si91x-rcp-driver)
- The si91x-rcp-driver release consists of the following components  
  - Firmware - SiWT917 Firmware Binary  
  - rsi - SiWT917 RCP driver source code  
  - apps - contains driver tools source code  
  - release - contains kernel modules and script files
- This software is meant only for use with designs based on SiWT917 Silicon

##### Release Details

<table>
    <thead>
        <tr>
            <th>Item</th>
            <th>Details</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>
                <p>Release Date</p>
            </td>
            <td>
                <p>April 8, 2026</p>
            </td>
        </tr>
        <tr>
            <td>
                <p>Firmware Version</p>
            </td>
            <td>
                <p>1711.2.15.1.0.0.4</p>
            </td>
        </tr>
        <tr>
            <td>
                <p>Package Name</p>
            </td>
            <td>
                <p>SiWT917.2.15.0.4</p>
            </td>
        </tr>
        <tr>
            <td>
                <p>Linux Kernel Version support</p>
            </td>
            <td>
                <p>From v3.18 to v6.12</p>
            </td>
        </tr>
        <tr>
            <td>
                <p>Host interfaces supported</p>
            </td>
            <td>
                <p>SDIO</p>
            </td>
        </tr>
        <tr>
            <td>
                <p>Operating Modes Supported</p>
            </td>
            <td>
                <p>Wi-Fi STA, Wi-Fi AP, Wi-Fi STA+BLE, Wi-Fi STA+AP, BLE</p>
            </td>
        </tr>
    </tbody>
</table>

##### Installation and Use

To get started with the SiWT917 Linux driver in RCP mode, see our [Getting Started Guides](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/).

To kick start your development and debugging with the SiWT917 Linux driver in RCP mode, see our [Developers Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/).

To review Security and Software Advisory notifications and manage your notification preferences:

1. Go to [https://community.silabs.com/](https://community.silabs.com/).
2. Log in with your account credentials.
3. Click your profile icon in the upper-right corner of the page.
4. Select **Notifications** from the dropdown menu.
5. In the Notifications section, go to the **My Product Notifications** tab to review historical Security and Software Advisory notifications.
6. To manage your preferences, use the **Manage Notifications** tab to customize which product updates and advisories you receive.

For recommended settings, configurations, and usage guidelines, see the [Recommendations](#recommendations) section.

To learn more about the software in this release, dive into our [online documentation](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developing-in-rcp-mode/).

##### Help and Feedback

- Contact [Silicon Labs Support](https://www.silabs.com/support).
- To use our **Ask AI** tool to get answers, see the search field at the top of [this page](https://docs.silabs.com/).  
  > **Note:** **Ask AI** is experimental.
- Get help from our [developer community](https://community.silabs.com/s/?language=enUS).

#### Supported Hardware OPNs

<table>
    <thead>
        <tr>
            <th>Hardware</th>
            <th>Ordering Part Number (OPN)</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>OPNS</td>
            <td>QFN OPN: SIWT917M100XGTBA.<p>Module OPN: SIWT917Y100XGNBA Module with RF-PIN, SIWT917Y100XGABA Module with Antenna.</p>
                <p>Module Refresh OPN : SIWT917Y100XGAXA Module Refresh (This module will be available after launch)</p>
            </td>
        </tr>
        <tr>
            <td>Expansion kits </td>
            <td>SiWx917-EB4346A (based on Radio board SiWx917-4346A + 8045A Co-Processor Adapter board or 8045B Co-Processor Raspberry Pi Adapter board).<p> Module Board: SiW917Y-RB4357A (SiWT917Y Module Wi-Fi 6 and Bluetooth LE Co-Processor Radio Board).</p>
                <p> Module Board: SiW917Y-RB4357C (SiWx917 Module Refresh Wi-Fi 6 and Bluetooth LE Co-Processor Radio Board)</p>
            </td>
        </tr>
    </tbody>
</table>

#### Features Supported

[Wi-Fi](#wi-fi) | [BLE](#ble) | [Multi-protocol](#multi-protocol)

##### Wi-Fi

- #### Operating Modes:  
  - Wi-Fi STA (802.11ax, 802.11n),  
  - Wi-Fi 802.11n AP,  
  - Wi-Fi STA (802.11ax, 802.11n) + 802.11n AP,  
  - Wi-Fi STA (802.11ax, 802.11n) + BLE,  
  - BLE
- #### Host Interface :  
  - SDIO 2.0
- #### Power save  
  - Deep Sleep  
  - Connected Sleep  
  - Host-based wake-up
- #### Wi-Fi Protocols  
  - IEEE 802.11 b/g/n/ax (2.4 GHz)
- #### Wi-Fi Station mode  
  - #### Scan    
    - Selective Scan    
    - Active/Passive Scanning  
  - #### Wi-Fi  Security    
    - Open Mode    
    - WPA2 Personal, WPA2 Enhancements    
    - WPA2 Enterprise    
    - WPA3 Personal    
    - Mixed Mode (WPA/WPA2)    
    - WPA3 Personal Transition Mode (WPA2/WPA3)  
  - #### Wi-Fi STA Rejoin  
  - #### Wi-Fi STA Roaming    
    - BG Scan    
    - OKC (Opportunistic Key caching)    
    - PMK (Pairwise Master Key) caching    
    - Pre-Authentication  
  - #### Wi-Fi Protocol Power save    
    - Deep sleep (unconnected state)    
    - Max PSP    
    - Enhanced Max PSP    
    - Fast PSP    
    - TWT  
  - #### QoS    
    - WMM-QoS  
  - #### Wi-Fi 6 Feature    
    - MU-MIMO (DL)    
    - OFDMA (UL/DL)    
    - iTWT,TWT I-Frame & TWT Enhancements    
    - BSS coloring    
    - MBSSID
- #### Access Point (AP) mode  
  - 8 Client Support  
  - Wi-Fi Security    
    - Open Mode    
    - WPA2 Personal    
    - WPA2 Enterprise    
    - WPA3 Personal (H2E method only)    
    - WPA Mixed mode (WPA/WPA2)  
  - Hidden SSID Mode  
  - Auto Channel Selection
- #### WPA2 Enterprise security  
  - Method    
    - PEAP/TTLS/TLS/FAST
- #### Wi-Fi Concurrency  
  - AP+STA (Same channel)  
  - Scan in AP mode
- #### Wi-Fi Band/Channels  
  - 2.4GHz CH1-11 (US)  
  - 2.4GHz CH1-13 (Europe)  
  - 2.4GHz CH1-14 (Japan)
- #### Known Security vulnerabilities handled  
  - WPA2 KRACK Attacks  
  - Fragment and Forge Vulnerability

##### BLE

- Security
- Accept list
- LE PHY(1Mbps, 2Mbps) & Coded PHY(125Kbps, 500kbps)
- Simultaneous scanning on 1M and Coded PHY
- LE dual role topology
- LE data packet length extensions( DLE)
- Asymmetric PHYs
- LE channel selection algorithm 2 (CSA#2)
- Bluetooth 5.4 Qualified

##### Multi-protocol

- Wi-Fi STA + BLE
- #### PTA Coexistence  
  - 3 wire coex acting as Wi-Fi Station with external Bluetooth  
  - 3 wire coex acting as Wi-Fi Station with external Zigbee/OT

#### Recommendations

[Wi-Fi](#wi-fi-1) | [BLE](#ble-1) | [Multi-protocol](#multi-protocol-1)

##### Wi-Fi

- Set the recommended Power Save Profile (PSP) type to Enhanced Max PSP.
- Disable power save for higher throughput values or use FAST PSP power save mode as per application requirement.

##### BLE

- In BLE, the recommended range of Connection Interval in  
  - Power Save (BLE Only) - 100 ms to 1.28 s.
- In BLE, during Connection, the configuration of Scan Interval and Scan Window with the same value is not recommended. The suggested ratio of Scan Window to Scan Interval is 3:4.
- In BLE, if a device is acting as Central, the scan window must be less than the existing Connection Interval. The suggested ratio of Scan Window to Connection Interval is 2:3.
- In BLE mode, if scanning and advertising are in progress on the SiWx91x module and it subsequently gets connected and moves to the central role, scanning stops else if it moves to the peripheral role, advertising stops. To further establish a connection to another peripheral device or to a central device, the application should give a command for starting advertising and scanning again.
- Recommend using XTAL clock for BLE instead of RC clock.

##### Multi-protocol

- For concurrent Wi-Fi + BLE, and while a Wi-Fi connection is active, we recommend setting the ratio of the BLE scan window to BLE scan interval to 1:3 or 1:4.
- Wi-Fi + BLE Advertising  
  - All standard advertising intervals are supported. As Wi-Fi throughput is increased, a slight difference in on-air advertisements compared to configured intervals may be seen.  
  - BLE advertising is skipped if the advertising interval collides with Wi-Fi activity.
- Wi-Fi + BLE scanning  
  - All standard scan intervals are supported. For better scan results, we recommend setting the ratio of the BLE scan window to BLE scan interval to 1:3 or 1:4.  
  - BLE scanning will be stopped for intervals that collide with Wi-Fi activity.
- Wi-Fi + BLE Central/Peripheral Connections  
  - All standard connection intervals are supported.  
  - For a stable connection, use optimal connection intervals and max supervision timeout in the presence of Wi-Fi activity.
- Wi-Fi + BLE Central/Peripheral Data Transfer  
  - To achieve higher throughput for both Wi-Fi and BLE, use medium connection intervals, such as 45 to 80 ms with maximum supervision timeout.  
  - Ensure Wi-Fi activity consumes lower intervals.

#### Known Issues

[Wi-Fi](#wi-fi-2) | [BLE](#ble-2) | [Multi-protocol](#multi-protocol-2)

##### Wi-Fi

None

##### BLE

- BLE connected power consumption has increased following the transmit power alignment fix. The increase is approximately 8% at the 200ms connection interval and approximately 29% at the 1.28 sec connection interval.

##### Multi-protocol

None

#### Limitations and Unsupported Features

[Wi-Fi](#wi-fi-3) | [BLE](#ble-3) | [Multi-protocol](#multi-protocol-3)

##### Wi-Fi

None

##### BLE

None

##### Multi-protocol

None

### RCP 917 - Wi-Fi Release Version 2.15.0 (April 8, 2026) - Release Notes

**[Wi-Fi 6 + BLE Linux Driver(RCP)](.)**

The SiWT917 RCP Driver provides Wi-Fi 6 connectivity in various operating modes, including Station and Software Access Point (SoftAP).

Click [here](https://github.com/SiliconLabs/si91x-rcp-driver/tags) for SiWT917 releases.

#### Release Summary

[Key Features](#key-features) | [Bug Fixes](#bug-fixes) | [Chip Enablement](#chip-enablement)

##### Key Features

- Added kernel support till 6.12.
- Added support for module refresh (external low-power XTAL option support).

##### Bug Fixes

- Fixed delay issue while creating the vap.
- Fixed beacon and broadcast reception issues in congested environments.
- Fixed an issue where the module was incorrectly identifying early beacons from the AP, leading to excessive power consumption during long-run tests.
- Improved Wi-Fi RSSI Accuracy for high attenuation levels.
- Fixed Beacon reception issues in congested environment.
- Disabled RF turnoff till the end of packet on air when the packet is dropped.

##### Chip Enablement

- OPN : SIWT917Y100XGAXA,  Board: SiW917Y-RB4357C

#### Key Features

[New Features](#new-features) | [Enhancements](#enhancements) | [Removed Features](#removed-features) | [Deprecated Features](#deprecated-features)

> **Note:** See [Features Supported](.#features-supported) for a list of supported features.

##### New Features

- Added support for module refresh (external low-power XTAL option support).

##### Enhancements

- Updated Kernel support till 6.12

##### Removed Features

None

##### Deprecated Features

None

#### Bug Fixes

<table>
    <thead>
        <tr>
            <th>ID</th>
            <th>Issue Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>
                1614239
            </td>
            <td>
                Fixed delay issue while creating the vap.
            </td>
        </tr>
        <tr>
            <td>
                1405635
            </td>
            <td>
                Fixed beacon and broadcast reception issues in congested environments.
            </td>
        </tr>
        <tr>
            <td>1518842</td>
            <td>Fixed an issue where the module was incorrectly identifying early beacons from the AP, leading to excessive power consumption during long-run tests.</td>
        </tr>
        <tr>
            <td>1435733</td>
            <td>Improved Wi-Fi RSSI Accuracy for high attenuation levels.</td>
        </tr>
        <tr>
            <td>1310207</td>
            <td>Fixed Beacon reception issues in congested environment.</td>
        </tr>
        <tr>
            <td>1397227</td>
            <td>Disabled RF turnoff till the end of packet on air when the packet is dropped.</td>
        </tr>
    </tbody>
</table>

#### Chip Enablement

<table>
    <thead>
        <tr>
            <th>Chip Family</th>
            <th>OPNs / Boards / OPN Combinations</th>
            <th>Supported Modes</th>
            <th>Supported Host Interfaces</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>
                SiWx91x
            </td>
            <td>
                <ul>
                    <li>OPN: SIWT917Y100XGAXA</li>
                    <li>Boards: SiW917Y-RB4357C</li>
                    <li>For External Hosts SI-EB8045B , SI-EB8045A + BRD8046A</li>
                </ul>
            </td>
            <td>
                <ul>
                    <li>RCP</li>
                </ul>
            </td>
            <td>
                SDIO
            </td>
        </tr>
    </tbody>
</table>

#### Known Issues

- The set rate cannot be used for setting non-MCS and non-basic rates in kernels above 4.13.16.
- Tx and Rx Rate information is not being updated in WLAN interface stats reported by the iwconfig tool.
- Auto Channel Selection in AP with WORLD region will not work.
- In Concurrent Mode, Wi-Fi performance may be reduced if more than four clients are connected to DUT-AP.
- Deep sleep is disabled by default. Users can enable it using the default_deep_sleep_enable module_param mentioned in the TRM.
- TWT device (STA) may not go to sleep in between TWT intervals in case of burst data traffic where data transfer happens over multiple TWT service periods.
- WoWLAN feature is not supported.
- In AP mode, performance is expected to degrade with the addition of the number of clients.
- Hardware Beacon Miss event observed using MBSSID mode.
- Around 38% of packet loss observed in RF chamber while running UDP-bidirectional traffic.
- Wi-Fi client receives deauthentication from the access point when trigger TWT with announced mode is enabled.
- In AP mode, in congested environments where channel occupancy exceeds 85%, connected stations may experience disconnections due to high congestion.

#### Limitations and Unsupported Features

- Broadcast TWT is not supported.
- AMSDU TX is not supported.
- Fragmentation is not supported.
- AMSDUs within AMPDU is not supported.
- 802.11k is not supported
- 40 MHz bandwidth is not supported.
- Low Power mode is not supported.
- In iTWT mode, downlink data traffic should be limited. Disconnections may be observed if AP fails to send all the buffered data in the next TWT Service Period.
- The number of Non-Transmitting BSSIDs processed is limited by the beacon length that can be processed by the stack (which is 1024 bytes). Beacons greater than 1024 Bytes in length will not be processed.
- UL MU-MIMO is not supported.
- WPA3 AP supports only the H2E algorithm.
- PMKSA caching is not supported in WPA3 AP mode.
- Wi-Fi performance may be reduced in dense environments.
- 802.11j is not supported.
- Background scan(Scan after DUT-STA connection) and power-save features are not supported for the station mode vap in concurrent mode.
- In Wi-Fi concurrent mode, Both DUT AP and Testbed AP should be in the same channel. The Channel in the hostapd configuration file needs to be updated manually to the same channel as the Testbed AP.
- In Wi-Fi concurrent Mode, DUT-STA doesn't reconnect to testbed AP if the testbed AP changes the channel(Only if DUT-AP is up), also DUT-AP stays in the same channel and continues to beacon.
- WPS mode is not supported.
- GPIO-based power save is not supported.
- For SiWT917Y modules, Channels 12, 13 and 14 are not supported in AP mode.
- For SiWT917Y modules, Gain table update is not supported.
- For SiWT917Y modules, Country code configuration is not supported in AP mode.
- Monitor mode is not supported in 802.11ax.

### RCP 917 - Bluetooth LE Release Version 2.15.0 (April 8, 2026) - Release Notes

[**Wi-Fi 6 + BLE Linux Driver(RCP)**](.)

The SiWT917 RCP Driver provides feature-rich Bluetooth 5 connectivity with multi-connection capabilities, advanced advertising extensions, and power optimization for diverse IoT applications.

Click [here](https://github.com/SiliconLabs/si91x-rcp-driver/tags) for SiWT917 releases.

#### Release Summary

[Key Features](#key-features) | [Bug Fixes](#bug-fixes) | [Chip Enablement](#chip-enablement)

##### Key Features

None

##### Bug Fixes

- Fixed a BLE disconnection issue that occurred when the DUT attempted to connect to an access point while configured for the China (SRRC) region only.
- Fixed an issue where the output transmit power was higher in end-to-end mode compared to PER test mode across all temperatures.
- Fixed an issue where the central device was unable to establish a BLE Advertising Extension (AE) connection when operating with LE Coded PHY rates.
- Fixed a SiWx917Y BLE test power mismatch where SRRC ('cn') region output was 2 dB higher than 'us'.
- Functional fixes for RSSI accuracy.

##### Chip Enablement

- OPN : SIWT917Y100XGAXA,  Board: SiW917Y-RB4357C

#### Key Features

[New Features](#new-features) | [Enhancements](#enhancements) | [Removed Features](#removed-features) | [Deprecated Features](#deprecated-features)

> **Note:** See [Features Supported](.#features-supported) for a list of supported features.

##### New Features

None

##### Enhancements

None

##### Removed Features

None

##### Deprecated Features

None

#### Bug Fixes

<table>
    <thead>
        <tr>
            <th>ID</th>
            <th>Issue Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>
                1427321
            </td>
            <td>
                Fixed a BLE disconnection issue that occurred when the DUT attempted to connect to an access point while configured for the China (SRRC) region only.
            </td>
        </tr>
        <tr>
            <td>
                1567221
            </td>
            <td>
                Fixed an issue where the output transmit power was higher in end-to-end mode compared to PER test mode across all temperatures.
            </td>
        </tr>
        <tr>
            <td>
                1618999
            </td>
            <td>
                Fixed an issue where the central device was unable to establish a BLE Advertising Extension (AE) connection when operating with LE Coded PHY rates.
            </td>
        </tr>
        <tr>
            <td>
                1515072
            </td>
            <td>
                Fixed an issue in SiWx917Y BLE testing where the 'cn' (SRRC) region showed 2 dB higher output power compared to the 'us' region..
            </td>
        </tr>
        <tr>
            <td>
                1388472
            </td>
            <td>
                Fixed issues with BLE RSSI accuracy across various temperatures.
            </td>
        </tr>
    </tbody>
</table>

#### Chip Enablement

<table>
    <thead>
        <tr>
            <th>Chip Family</th>
            <th>OPNs / Boards / OPN Combinations</th>
            <th>Supported Modes</th>
            <th>Supported Host Interfaces</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>
                SiWx91x
            </td>
            <td>
                <ul>
                    <li>OPN: SIWT917Y100XGAXA</li>
                    <li>Boards: SiW917Y-RB4357C</li>
                    <li>For External Hosts SI-EB8045B , SI-EB8045A + BRD8046A</li>
                </ul>
            </td>
            <td>
                <ul>
                    <li>RCP</li>
                </ul>
            </td>
            <td>
                SDIO
            </td>
        </tr>
    </tbody>
</table>

#### Known Issues

- BLE disconnections are expected with the RC clock in power save.
- BLE connected power consumption has increased following the transmit power alignment fix. The increase is approximately 8% at the 200ms connection interval and approximately 29% at the 1.28 sec connection interval.

#### Limitations and Unsupported Features

- For BLE, if the connection is established with a small connection interval (less than 15 ms), simultaneous roles (i.e., Central + Scanning and Peripheral + Advertising) are not supported.
- BLE maximum two concurrent connections are supported(1 Central connection and 1 Peripheral connection) or (2 Central connections) or (2 Peripheral connections).
- The advertising Extension feature is not supported.
- Isochronous channels feature is not supported.
- The connection subrating feature is not supported.
- LE power controller feature is not supported.
- The EATT feature is not supported.
- Periodic Advertising with response(PAwR) feature is not supported.
- BLE Audio is not supported.
- The dynamic adjustment of TX power while extended advertising is active is not supported.
- Peripheral Latency feature is not supported.
- Restricted the option for users to modify BLE Gain tables for the SiWT917Y module.

### RCP 917 - Multi-Protocol Release Version 2.15.0 (April 8, 2026) - Release Notes

[**Wi-Fi 6 + BLE Linux Driver(RCP)**](.)

The SiWT917 RCP Driver provides Wi-Fi and BLE co-existence and packet traffic arbitration (PTA) features.

Click [here](https://github.com/SiliconLabs/si91x-rcp-driver/tags) for SiWT917 releases.

#### Release Summary

[Key Features](#key-features) | [Bug Fixes](#bug-fixes) | [Chip Enablement](#chip-enablement)

##### Key Features

- Added KC and SRRC region selection support in PER mode for Wi-Fi and BLE.

##### Bug Fixes

None

##### Chip Enablement

- OPN : SIWT917Y100XGAXA,  Board: SiW917Y-RB4357C

#### Key Features

[New Features](#new-features) | [Enhancements](#enhancements) | [Removed Features](#removed-features) | [Deprecated Features](#deprecated-features)

> **Note:** See [Features Supported](.#features-supported) for a list of supported features.

##### New Features

- Added KC and SRRC region selection support in PER mode

##### Enhancements

None

##### Removed Features

None

##### Deprecated Features

None

#### Bug Fixes

None

#### Chip Enablement

<table>
    <thead>
        <tr>
            <th>Chip Family</th>
            <th>OPNs / Boards / OPN Combinations</th>
            <th>Supported Modes</th>
            <th>Supported Host Interfaces</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>
                SiWx91x
            </td>
            <td>
                <ul>
                    <li>OPN: SIWT917Y100XGAXA</li>
                    <li>Boards: SiW917Y-RB4357C</li>
                    <li>For External Hosts SI-EB8045B , SI-EB8045A + BRD8046A</li>
                </ul>
            </td>
            <td>
                <ul>
                    <li>RCP</li>
                </ul>
            </td>
            <td>
                SDIO
            </td>
        </tr>
    </tbody>
</table>

#### Known Issues

##### Multi-protocol

- MU retries in DL MU-MIMO are more in CoEx
- Observed Wi-Fi throughput inconsistency (TPUT in Kbps) for STA(Wi-Fi Tx)+BLE Mode while doing BLE scan.
- Observed BLE disconnection while initiating connection with an access point configured in CHINA region.

#### Limitations and Unsupported Features

- BLE may disconnect with Wi-Fi + BLE configuration and Wi-Fi continuous data transfer when the low BLE supervision timeout is configured. When the supervision timeout is configured with the value of 16 seconds, no disconnections are observed.
- In Wi-Fi +BLE configuration with Wi-Fi disconnects, a BLE reconnection issue is observed (Refer the section '[Recommendations](.#recommendations)'  for stable connections).

## Developer's Guide

### Overview

The SiWT917 RCP Driver is a SoftMAC driver that interacts with the Linux wireless MAC layer i.e., MAC80211. The driver is a group of simple and efficient kernel modules, which currently supports SiWT917 RCP chipsets and can be ported to any embedded platform in-addition to X-86 platform. It supports the following protocols:

- Wi-Fi (Client and Access Point mode)
- Bluetooth Low Energy

It supports the following protocol combinations :

- WLAN STATION
- WLAN ACCESS POINT
- BT LE MODE
- WLAN STATION + BT LE MODE
- WLAN STATION + WLAN ACCESS POINT (Concurrent Mode)

### Operating Modes

#### Overview

This section describes the various operating modes supported by the SiWx91x RCP Driver for Radio Co-processor (RCP) mode:

- [Wi-Fi Station Mode](wifi-station-mode) is used to operate the radio in Wi-Fi client mode.
- [Wi-Fi Station + BLE Mode](../wifi91xrcp-getting-started/#configure-in-wi-fi-station-ble-mode) or **Co-ex Mode** is used to operate the radio in Wi-Fi client and BLE modes simultaniously.
- [Wi-Fi AP Mode](wifi-ap-mode) is used to operate the radio in Wi-Fi Access Point.
- [Wi-Fi Station + AP Mode](wifi-station-plus-ap-mode) or **Concurrent Mode** is used to operate the radio in Wi-Fi client and Wi-Fi Access Point simultaniously.
- [Wi-Fi Monitor Mode](wifi-monitor-mode) is used to capture the Wi-Fi Traffic .
- [BLE Mode](ble-mode)  is used to operate the radio in Bluetooth Low Energy (BLE).

#### Configuring the Driver in Wi-Fi Station Mode

This section provides the steps to configure Wi-Fi station mode in different security modes (WPA3 & Enterprise mode), Selective scan using wpa_supplicant, and Configure station using the Network Manager CLI.
Refer to the [Configure in Wi-Fi Station Mode](../wifi91xrcp-getting-started/#configure-in-wi-fi-station-mode) section for details on open and WPA2-PSK security modes, as well as steps to configure Wi-Fi Station mode using a startup script or manual commands.

- For WPA3 security mode:  
  To connect in WPA3, compile the  [latest supplicant](../wifi91xrcp-developers-guide-wifi-configuration/roaming-configuration#configure-and-compile-latest-supplicant) (following the instructions in latest supplicant) with the following flags enabled in the wpa_supplicant .config file.  
  ```c  
   CONFIG_SAE=y  
   CONFIG_IEEE80211W=y   
  ```  
  Use the following network block in sta_settings.conf file for WPA3 configuration  
  ```c  
   pmf=2  
   network={  
   ssid="<SSID of Access Point>"  
   key_mgmt=SAE  
   psk=<passphrase specified in the Access Point>  
   ieee80211w=2  
   }  
  ```  
  > **Note**: WPA3 Enterprise security mode is not supported in this release.
- For WPA2-EAP TLS (Enterprise mode) mode:  
  ```c  
   network={  
          ssid="<SSID of Access Point>"  
          key_mgmt=WPA-EAP  
          eap=TLS  
          anonymous_identity="tlsuser"  
          identity="test"  
          password=<passphrase specified in the Access Point>  
          ca_cert="/etc/certs/wifiuser.pem"  
          client_cert="/etc/certs/wifiuser.pem"  
          private_key_passwd=<private key password>  
          private_key="/etc/certs/wifiuser.key"  
          pairwise=CCMP TKIP  
          group=CCMP TKIP  
          proto=WPA2 WPA  
          priority=20  
          }  
  ```  
  In EAP-TLS, copy the client certificates in a path and configure the path in network block, as shown above. See the [Wi-Fi Enterprise Security](../wifi91xrcp-developers-guide-wifi-features/wifi-enterprise-security) section for Radius Server configuration.
- For WPA2-EAP PEAP (Enterprise mode) mode:  
  ```c  
   network={  
          ssid="<SSID of Access Point>"  
          key_mgmt=WPA-EAP  
          eap=PEAP  
          anonymous_identity="peapuser"  
          identity="test"  
          password=<passphrase specified in the Access Point>  
          pairwise=CCMP TKIP  
          group=CCMP TKIP  
          proto=WPA2 WPA  
          priority=20  
          }  
  ```
- For WPA2-EAP TTLS (Enterprise mode) mode:  
  ```c  
   network={  
          ssid="<SSID of Access Point>"  
          key_mgmt=WPA-EAP  
          eap=TTLS  
          anonymous_identity="ttlsuser"  
          identity="test"  
          password=<passphrase specified in the Access Point>  
          pairwise=CCMP TKIP  
          group=CCMP TKIP  
          proto=WPA2 WPA  
          priority=20  
          }  
  ```

**For Hidden / Stealth SSID:**

To connect to an Access Point whose SSID is not broadcast (Hidden), add the following line to the network block.

```c
scan_ssid=1 
```

For example **:**

```c
   network={
          ssid="<SSID of Access Point>"
          scan_ssid=1
          key_mgmt=NONE
          }
```

**For Selective Scan:**

To enable the selective scan, add freq_list parameter outside the network block. freq_list is a space-separated list of frequencies in MHz which limits the frequencies that will be scanned.

```c
   freq_list=2412 2437 2462 
```

Example config file that will only scan on channel 1 and 36.

```c
   freq_list=2412 5180
   network={
          ssid="<SSID of Access Point>"
          key_mgmt=NONE
          }
```

##### Configure Station Using the Network Manager

Below are the specific commands that can be used for connection using the Network Manager CLI(nmcli):

1. To check the network manager status (started or stopped), run the following command:  
   For fedora,  
   ```c  
   # service NetworkManager status  
   ```  
   For ubuntu,  
   ```c  
   # service network-manager status   
   ```
2. If the network manager is inactive or not started, start it with the following command:  
   For fedora,  
   ```c  
   # service NetworkManager start    
   ```  
   For ubuntu,  
   ```c  
   # service network-manager start  
   ```
3. To view the currently available network connections, run the following command:  
   ```c  
   # nmcli con show   
   ```  
   sample output:  
   ```c  
   NAME        UUID                                       TYPE                    DEVICE   
   eth0        96a5deb0-5eb0-41e1-a7ed-38fea413f9c8       802-3-ethernet          eth0  
   wlan0       91451385-4eb8-4080-8b82                    802-11-wireless         wlan0    
     
   > **Note**: Here wlan0 is the interface created and the interface name may vary between the host used.  
   ```
4. To view the list of access points, run the following command:  
   ```c  
   # nmcli dev wifi list   
   ```  
   Sample output is shown below.  
   ```c  
      SSID            MODE   CHAN  RATE       SIGNAL  BARS     SECURITY       
      ASUS            Infra     11    54 Mbit/s  100     ▂▄▆█   WPA2     
      test123         Infra     8     54 Mbit/s  32      ▂▄__    WPA1 WPA2   
      cisco           Infra     1     54 Mbit/s  30      ▂___    WPA1 WPA2   
      test            Infra     13    54 Mbit/s  25      ▂___    ---        
      Dlink           Infra     1     54 Mbit/s  0       ____     WPA2        
      TP-LINK_E11946  Infra     7     54 Mbit/s  83      ▂▄▆█   WPA1 WPA2   
   ```
5. To connect to an AP with WPA/WPA2 security, run the following command:  
   ```c  
   # nmcli dev wifi connect <SSID> password <password> <interface_name>  
   # For example :  nmcli dev wifi connect ASUS password 12345678 wlan0   
   ```  
   In this case, ASUS is the AP’s SSID, password is 12345678, and interface_name is wlan0.
6. To connect to an AP without security, run the following command:  
   ```c  
   # nmcli dev wifi connect <SSID> <interface_name>    
   # nmcli dev wifi connect test wlan0   
   ```  
   Here, 'test' is the SSID and interface_name is wlan0.
7. To retrieve the status of devices and connections, run the following command:  
   ```c  
   # nmcli dev status  
   ```  
   Sample output:  
   ```c  
   DEVICE    TYPE       STATE           CONNECTION  
   wlan0     wifi       connected       my-ssid  
   eth0      ethernet   unavailable       --    
   ```  
   As can be seen, the STATE corresponding to wlan0 interface shows connected.
8. To enable a connection on interface (i.e., to make it active), using nmcli, run the following command. connection_name can be obtained from the command above.  
   ```c  
   # nmcli con up id <connection_name>  
   ```
9. To disable an interface using nmcli, run the following command:  
   ```c  
   # nmcli dev disconnect <interface_name>  
   ```

#### Configuring the Driver in Wi-Fi AP Mode

This section provides steps to configure Wi-Fi AP mode using hostapd application.

- Follow the steps below to run AP mode with hostapd application.

1. Before running hostapd make sure wpa_supplicant or hostapd is not running in the background. Run the following command to stop wpa_supplicant if it is running:  
   ```c  
   # killall wpa_supplicant  
   # killall hostapd  
   ```
2. Install hostapd.  
   ```c  
   # apt-get install hostapd  
   ```

The below section provides the steps to configure Wi-Fi Access Point mode using startup script or manual commands. You can choose any one of the methods below.

##### Startup Script to Run Wi-Fi AP Mode

Navigate to the rsi folder and use the script to run Wi-Fi AP mode after [configuring hostapd](../wifi91xrcp-developers-guide-operating-modes/wifi-ap-mode#configure-hostapd).

```c
   #./start_SiWT917.sh  AP
```

See the [Startup Script](../wifi91xrcp-developers-guide-software-tools/) section for more details about startup script file to configure in different operating modes.

##### Manual Steps to Run Wi-Fi AP Mode

- For AP mode connectivity, ensure that the dev_oper_mode is set in installation as given below and interface is detected after installation. See the [Installing the Driver](../wifi91xrcp-getting-started/#installing-the-driver) section.  
  ```c  
   dev_oper_mode = 2  
  ```
- To install the modules manually, run the following commands, to configures in Wi-Fi AP mode, debug zone=0x601 and SDIO clock=50 Mhz  
  ```c  
    #insmod rsi_91x.ko dev_oper_mode=2 rsi_zone_enabled=0x601  
    
    #insmod rsi_sdio.ko sdio_clock=50  
  ```

##### Configure hostapd

Create a hostapd configuration file (for example: ap.conf) and add below:

1. Create an **ap.conf** file with below information. Sample .conf files (ap_open.conf,ap_wpa.conf) are available within scripts directory of the release package with basic configurations required. You can use this file and edit the information as explained below. For the details of all available configurations, see the open source **hostapd.conf** file.
2. Set interface name:  
   ```c  
   interface=<interface_name>  
   Ex: interface=wlan0  
   ```
3. Set driver name:  
   ```c  
   driver=nl80211   
   ```
4. Set country name code in ISO/IEC 3166-1 format. This is used to set regulatory domain. Set as needed to indicate country in which device is operating. This can limit available channels and transmit power.  
   For example, IN for India, UK for United Kingdom, US for the United States of America.  
   ```c  
   country_code=IN   
   ```
5. Set your SSID: In the example below, we have set `Test_AP` as the SSID:  
   ```c  
   ssid=Test_AP   
   ```
6. Set operation mode ( b = IEEE 802.11b, g = IEEE 802.11g)  
   ```c  
   hw_mode=g   
   ```
7. Set Beacon Interval:  
   ```c  
    beacon_int=100  
   ```  
   > **Note**: You may select required beacon interval within the range of 56-1000 ms. For value less than 56 ms or more than 1000 ms, the driver will return an error. The defaut value is 100 ms.
8. Set the channel number.  
   ```c  
       channel=6  
   ```  
   > **Note**: You may select a required channel of operation or you may opt for Auto Channel Selection (ACS). For ACS, you have to follow the procedure below.  
   >   
   > - Compile hostapd with below flag set in its .config file.  
   >   ```c  
   >   CONFIG_ACS=y  
   >   ```  
   > - Also user has to add below configurations to hostapd.conf file.  
   >   ```c  
   >   channel=0  
   >   acs_num_scans=5 (Default Value, user may select)  
   >   ```
9. Set wpa mode to 2:  
   ```c  
   wpa=2   
   ```
10. Set your passphrase (Wi-Fi password):  
    ```c  
      wpa_passphrase=MyWiFiPassword  
    ```
11. Set key and auth options for WPA2:  
    Set the key management algorithm as shown.  
    ```c  
      wpa_key_mgmt=WPA-PSK  
    ```  
    Set cipher suites i.e., encryption algorithms:  
    ```c  
     wpa_pairwise=TKIP   
     rsn_pairwise=CCMP   
    ```  
    Shared Key Authentication :  
    ```c  
     auth_algs=1  
    ```  
    Save and close the file.  
    TKIP stands for Temporal Key Integrity Protocol and CCMP is AES in Counter mode with CBC-MAC .
12. Start the hostapd application:  
    ```c  
     # hostapd ap.conf –dddt > log_file &   
    ```
13. To check if AP mode is successfully started or not, run the following command:  
    ```c  
     # iw dev  
    ```  
    For example, if the AP is successfully started, expect the below sample output i.e., with SSID and channel information.  
    ```c  
       phy#10  
       Interface wlan0      
       ifindex 13  
       wdev 0xa00000001  
       addr ec:f6:4c:a0:3f:10  
       ssid rsi_ap_wpa  
       type AP  
       channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz  
    ```  
    And If AP failed to start, output does not show SSID and channel information as shown in below sample output :  
    ```c  
       phy#10  
       Interface wlan0  
       ifindex 13  
       wdev 0xa00000001  
       addr ec:f6:4c:a0:3f:10  
       type managed  
    ```
14. Run DHCP server script, located in scripts folder, to assign IPs to the client.  
    ```c  
     # sh dhcp_server.sh <interface_name>  
    ```  
    > **Note**:  dhcp_server.sh script uses dhcpd.conf file for required configurations. You can modify this file as needed.

In the scripts folder, several hostapd config files are provided to start the AP in various modes, such as open (ap_open.conf), WPA/2-PSK (ap_wpa.conf). You could use these configuration files instead of creating new ones.

> **Note**: For other hostapd configurations, such as ACL policy and keep alive, see the [Configuring Wi-Fi Access Point Parameters](../wifi91xrcp-developers-guide-wifi-configuration/ap-parameters#configuring-wi-fi-access-point-parameters) section.

#### Configuring the Driver in Wi-Fi STA + AP Mode (Wi-Fi Concurrent Mode)

Wi-Fi STA + AP Mode also known as Wi-Fi Concurrent mode is the mechanism in which Si917 driver can be operated in AP and Client modes simultaneously.
You can create two virtual interfaces, one in client mode and the other in AP mode.

The below section provides the steps to configure Wi-Fi STA + AP Mode mode using startup script or manual commands. You can choose any of the following methods.

##### Startup Script to Run Wi-Fi STA + AP Mode

Navigate to the rsi folder, and use the script to run the Wi-Fi STA + AP Mode (concurrent mode).

```c
   #./start_SiWT917.sh  AP_STA
```

See the [Startup Script](../wifi91xrcp-developers-guide-software-tools/) section for more details about startup script file to configure in different operating modes.

##### Manual Steps to Run Wi-Fi STA + AP Mode

Below are the manual steps to operate the device in Wi-Fi STA + AP mode (concurrent mode).

1. Before compiling the driver, make sure you enable the CONFIG_STA_PLUS_AP flag in Makefile.

See the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) section for driver compilation.

1. Navigate to the release folder and insert the driver.  
   ```c  
   # cd release  
   # insmod rsi_91x.ko dev_oper_mode=3 rsi_zone_enabled=0x601  
   # insmod rsi_sdio.ko   
   ```
2. Add new virtual interface upon the base interface wlan0.  
   ```c  
   # iw dev wlan0 interface add wlan1 type <IFTYPE>  
     
   In this case, IFTYPE : __ap for AP VIF.  
                 managed for station VIF.  
   ```

> **Note**: Here, wlan0 should be the SiWT917_STA interface, and wlan1 should be the SiWT917_AP interface.

1. Currently supporting STA + AP or AP +STA combinations only.

> **Note**: Make sure the third-party AP, and SiWT917_AP should be in same channel.

1. To bring up the Wi-Fi station, configure the `sta_settings.conf` file as described in the [Configure Station Using WPA Supplicant](../wifi91xrcp-getting-started/#configure-station-using-wpa-supplicant) section, then run the following command to start wpa_supplicant:  
   ```c  
   # wpa_supplicant -i wlan0 -c sta_settings.conf -D nl80211 -dddt > slog.txt&  
   ```
2. To bring up the access point (AP), configure the `ap.conf` file as described in the [Wi-Fi AP Mode](../wifi91xrcp-developers-guide-operating-modes/wifi-ap-mode#configuring-the-driver-in-wi-fi-ap-mode) section, then run the following command to start hostapd:  
   ```c  
   # hostapd ap_wpa.conf -dddt > hlog.txt&  
   ```

> **Note:** Make sure you add proper interface name in ap_wpa.conf.

See the [SiWT917 RCP Wi-Fi Concurrent Mode Application Note](https://www.silabs.com/documents/public/application-notes/AN1445_SiWT917_RCP_Wi-Fi_Concurrent_Mode.pdf) for more details.

Limitations:

1. More than two virtual interfaces (VIF) are not supported.
2. Background scan(Bg-scan) and powersave features are not supported for the station mode vap in concurrent mode.**Do not enable bgscan_simple in `sta_settings.conf` file.**
3. Both interfaces should be in the same channel. The channel configured in the hostapd configuration file should be the same as that used by the 3rd party AP.
4. Bring up RSI-STA first to avoid performance issues caused by continuous scanning.

#### Configuring the Driver in Wi-Fi Monitor Mode

The Steps for operating the device in Monitor Mode are outlined below.

1. To install the driver, run the following commands:  
   ```c  
   # insmod rsi_91x.ko rsi_zone_enabled=1 dev_oper_mode=1 driver_mode_value=7  
   ```
2. Insert the SDIO interface ko.  
   ```c  
      # insmod rsi_sdio.ko  
   ```
3. Make sure that interface is down. If not, run the following command to bring down the interface:  
   ```c  
   # ifconfig <interface_name> down  
   ```
4. To change the default interface to monitor, run the following command:  
   ```c  
     # iwconfig < interface_name> mode monitor               OR                       
     # iw dev <interface_name> set type monitor     
   ```
5. To bring up the interface, run the following command:  
   ```c  
   # ifconfig <interface_name> up   
   ```
6. Set the channel in which you want to capture the on air packets.  
   ```c  
     # iwconfig <interface_name> channel < channel no>                     OR        
     # iw dev <interface_name> set channel <channel no>   
   ```
7. Use any network packet analysis tool to see captured packets.  
   ```c  
     # wireshark &     OR  
     # tcpdump &   
   ```

> **Note**: Install wireshark in the system, if it is not found.

#### Configuring the Driver in BLE Mode

This section provides the steps to configure BLE mode. BLE mode supports a maximum of three connections, that is, as main for two secondary connections (or) as main for one secondary connection and can connect to other main as secondary.

The below section provides the steps to configure BLE mode using startup script or manual commands. You can choose any one of the methods below.

##### Startup Script to Run BLE Only Mode

Navigate to the rsi folder and use the scriptto run BLE only mode.

```c
   #./start_SiWT917.sh  BLE
```

See the [Startup Script](../wifi91xrcp-developers-guide-software-tools/) section for more details about startup script file to configure in different operating modes.

##### Manual Steps to Run BLE Only Mode

- For BLE usage, ensure that the dev_oper_mode is set in installation as given below and BLE interface is detected after installation. See the [Installing the Driver](../wifi91xrcp-getting-started/#installing-the-driver) section.  
  ```c  
     dev_oper_mode = 8  
  ```

###### Configure Using HCI Commands

- To bring up the HCI interface, run the following command:  
  ```c  
  # hciconfig -a <hciX> up   
  ```
- After the device is up, you can advertise, scan and connect with other BLE devices. The device can be configured using hcitool or hciconfig.
- Advertise, Scan, Connect Commands  
  1. Enable Advertise.    
     ```c    
     # hciconfig –a <hciX> leadv     
     ```  
  2. Disable Advertise.    
     ```c    
     # hciconfig –a <hciX> noleadv    
     ```  
  3. Initiate Scan - The following command displays the scan responses and advertising information:    
     ```c    
     # hcitool –i <hciX> lescan    
     ```  
  4. Main Mode Connected State - Ensure that the remote device is in Advertise mode, then run the following command:    
     ```c    
     # hcitool –i <hciX> lecc <remote_MAC_Addr>    
     ```    
     The "remote_MAC_Addr" parameter above is the MAC address of the remote device, e.g., ec:f6:4c:a0:3f:10.  
  5. Secondary Mode Connected State - Ensure that our device is in Advertise mode, then run the following command:    
     ```c    
     # hcitool –i <hciX> lecc <device_MAC_Addr>    
     ```    
     The "device_MAC_Addr" parameter above is the MAC address of the of the EVB/module, e.g., ec:f6:4c:a0:3f:10  
  6. The above advertise, scan, and connect procedure can be followed for multiple secondaries.

### Features

#### Software Features

##### Overview

This section describes the various software features supported by the SiWT917 RCP Driver for Radio Co-processor (RCP) mode:

- Checking the software [version](check-version).
- Getting [SDIO Stats](sdio-stats).
- Getting [Wi-Fi Station Stats](wifi-station-stats).

##### Check the Software Version

Run the following command to check the driver and LMAC version:

```c
   # cat /sys/kernel/debug/phy<X>/version
```

You can expect results similar to those below.

```c
   Driver : SiWT917.2.10.0.5
   LMAC   : 1711.2.10.0.0.5
```

Driver version :

```c
   Driver : SiWT917.w.x.y.z  [Ex : SiWT917.2.10.0.5]
   where the naming convention is as follows:
   'w' is Major version
   'x' is Minor version
   'y' is Patch number
   'z' is Build number 
```

LMAC Version :

```c
   LMAC : ab.w.x.y.c.z [Ex : 1711.2.10.0.0.5]
   where the naming convention is as follows:
   'a' is CHIP ID
   'b' is Rom Version (Reserved)
   'w' is Major version
   'x' is Minor version
   'y' is Patch number
   'c' is customer ID
   'z' is Build number 
```

##### Get SDIO Stats

Run the following command to get the SDIO-specific information, such as the number of interrupts or the buffer full status.

```c
   # cat /sys/kernel/debug/phy<X>/sdio_stats
```

You can expect results similar to those below.

```c
   total_sdio_interrupts: 1855
   sdio_msdu_pending_intr_count: 1890
   sdio_buff_full_count: 0
   sdio_buff_semi_full_count: 0
   sdio_unknown_intr_count: 0
   BUFFER FULL STATUS : 0
   SEMI BUFFER FULL STATUS : 0
   MGMT BUFFER FULL STATUS : 0
   BUFFER FULL COUNTER : 0
   BUFFER SEMI FULL COUNTER : 0
   MGMT BUFFER FULL COUNTER : 0
```

##### Get Wi-Fi Station Stats

Run the following command to check the driver status, management packet stats, and data packet stats:

```c
##### cat /sys/kernel/debug/phy<X>/stats
```

You can expect results similar to those below.

```c
   ==> RSI STA DRIVER STATUS <==
   DRIVER_FSM_STATE: (9)
   total_mgmt_pkt_send :        114        total_mgmt_pkt_queued :         0          total_mgmt_pkt_freed :         0
   total_data_vo_pkt_send:        4        total_data_vo_pkt_queued:         0          total_data_vo_pkt_freed:        4
   total_data_vi_pkt_send:        0        total_data_vi_pkt_queued:         0          total_data_vi_pkt_freed:        0
   total_data_be_pkt_send:        230      total_data_be_pkt_queued:         0          total_data_be_pkt_freed:        230
   total_data_bk_pkt_send:        0        total_data_bk_pkt_queued:         0          total_data_bk_pkt_freed:        0 
```

In this case, the value of `DRIVER_FSM_STATE` is shown in the table below:

|DRIVER_FSM_STATE|Value|
|---|---|
|FSM_FW_NOT_LOADED|0|
|FSM_CARD_NOT_READY|1|
|FSM_COMMON_DEV_PARAMS_SENT|2|
|FSM_BOOT_PARAMS_SENT|3|
|FSM_EEPROM_READ_MAC_ADDR|4|
|FSM_EEPROM_READ_RF_TYPE|5|
|FSM_RESET_MAC_SENT|6|
|FSM_RADIO_CAPS_SENT|7|
|FSM_BB_RF_PROG_SENT|8|
|FSM_MAC_INIT_DONE|9|

#### Wi-Fi Features

##### Overview

This section describes the various Wi-Fi protocol features supported by the SiWT917 RCP Driver for Radio Co-processor (RCP) mode:

- [Wi-Fi Enterprise Security](wifi-enterprise-security) to authenticate network users through a RADIUS server or other authentication servers.
- [Wi-Fi Protected Setup](wifi-protected-setup) or **WPS**, a standard for easy and secure wireless network setup and connections.
- [Roaming and Background Scan](roaming-and-background-scan) to enable mobility within a Wi-Fi Extended Service Set (ESS).
- [Power Save Modes and Configuration](power-save-modes-and-configuration) for creating low power Wi-Fi devices.
- [Target Wake Time](target-wake-time) or **TWT**, a Wi-Fi 6 protocol power save scheme.
- [802.11w](802-11-w) or **PMF** to protect control and management frames and a set of robust management frames against forgery and replay attacks.
- [Wi-Fi PER Mode](wifi-per-mode) to test the Wi-Fi transmit and receive performances of the SiWT917 radio.

##### Wi-Fi Enterprise Security

###### Installation and Configuration of FreeRADIUS Server

The following packages are required to install the freeradius server 3.09:

- libtalloc-devel
- openssl-devel

The steps for downloading as well as installing the freeradius tar ball are as follows:

```c
     # tar zxvf freeradius-server-3.0.9.tar.gz
     
     # cd freeradius_3.09
     
     # ./configure
     
     # make
     
     # make install 
```

Configure the freeradius server by following the steps below:

Edit the `users` file, which contains the **“identity”** and **“password”**.

```c
##### vim /usr/local/etc/raddb/users
```

- Add the following line at the start of the `users` file.

test Cleartext-Password := "password"

For example, “user1” is an identity and “test123” is the password that has to be entered at client side i.e., in the sta_settings.conf file.

Edit 'eap' file, which contains the paths consisting of certificates and information about the EAP- Methods supported.

```c
##### vim  /usr/local/etc/raddb/mods-enabled/eap
```

> If Free-radius version is below 3.x “eap”, it will be located in raddb folder and will be named as “eap.conf”.

In tls-config tls-common section, changes are made to point to our certificates which are placed in /etc/certs folder.

```c
  tls-config tls-common {
  
  #private_key_password = whatever
  
  private_key_password = Wi-Fi
  
  #private_key_file = ${certdir}/server.pem
  
  private_key_file = /etc/certs/wifiuser.pem
  
  #certificate_file = ${certdir}/server.pem
  
  certificate_file = /etc/certs/wifiuser.pem
  
  #ca_file = \${cadir}/ca.pem
  
  ca_file = /etc/certs/wifiuser.pem
  
  #dh_file = ${certdir}/dh
  
  dh_file = /etc/certs/dh
  
  }
```

To start the Radius server, run the following command in the terminal:

```c
   # radiusd -X
```

For openssl versions of range  1.0.2 release - 1.0.2h release  (or) in range 1.0.1 - 1.0.1t release (or) in range 1.1.0 - 1.1.0a release.
Edit **radiusd.conf** file.

```c
  #vim /usr/local/etc/raddb/radiusd.conf
```

and change `allow_vulnerable_openssl` to `yes` or `CVE-2016-6304`:

```c
  allow_vulnerable_openssl =yes 
  
  OR
  
  allow_vulnerable_openssl ='CVE-2016-6304'
  
  In this case, `CVE-2016-6304` is the OpenSSL Vulnerability ID that the radius server will allow.
```

###### Configuring Station to Connect to an EAP Enabled AP

Navigate to the driver folder and copy the certs folder to /etc/ in your system, as it contains all the certificates required.

```c
  # cp -rvf certs /etc/
```

Navigate to the driver folder and compile it, ensuring that the below options are enabled in wpa_supplicant.conf file.

```c
   # vim wlan/supplicant/linux/wpa_supplicant/.config 

   CONFIG_DRIVER_NL80211=y
   CONFIG_IEEE8021X_EAPOL=y
   CONFIG_EAP_MSCHAPV2=y
   CONFIG_EAP_TLS=y
   CONFIG_EAP_PEAP=y
   CONFIG_EAP_TTLS=y
   CONFIG_EAP_FAST=y
   CONFIG_EAP_LEAP=y
   CONFIG_PKCS12=y
   CONFIG_TLS=internal
```

Compile the driver.

```c
##### make
```

Navigate to the release folder and start the device in station mode.

```c
   # insmod rsi_91x.ko and

    insmod rsi_sdio.ko 

   # service NetworkManager stop 
   # iw phy phyX interface add wifi0 type managed

X is the phy number it will vary, following command can be used to find the X value.
$ iw list |grep phy 
```

Run the supplicant after configuring sta_settings.conf according to the required EAP method. The network blocks listed below can be used as a reference.

```c
##### wpa_supplicant -i wifi0 -D nl80211 -c sta_settings.conf -ddddt > log &
```

To connect using EAP-PEAP method, sta_settings.conf should be described, as shown below:

```c
   network={
          ssid="SSID of Access Point"
          key_mgmt=WPA-EAP
          eap=PEAP
          anonymous_identity="peapuser"
          identity="test"
          password="password"
          }
```

To connect using EAP-TTLS method, sta_settings.conf should be described, as shown below:

```c
   network={
          ssid="SSID of Access Point"
          key_mgmt=WPA-EAP
          eap=TTLS
          anonymous_identity="ttlsuser"
          identity="test"
          password="password"
          }
```

To connect using EAP-TLS method, sta_settings.conf should be described, as shown below:

```c
   network={
          ssid="SSID of Access Point"
          key_mgmt=WPA-EAP
          eap=TLS
          anonymous_identity="tlsuser"
          identity="test"
          password="password"
          ca_cert="/etc/certs/wifiuser.pem"
          client_cert="/etc/certs/wifiuser.pem"
          private_key_passwd="Wi-Fi"
          private_key="/etc/certs/wifiuser.key"
          }
```

To connect using EAP-FAST method, sta_settings.conf should be described, as shown below:

```c
   network={
          ssid="SSID of Access Point"
          key_mgmt=WPA-EAP
          eap=FAST
          anonymous_identity="fastuser"
          identity="test"
          password="password"
          phase1="fast_provisioning=1"
          pac_file="/etc/p1.pac"
          phase2="auth=m**schapv2"
          ca_cert="/etc/certs/wifiuser.pem"
          private_key_passwd="wifi"
          }
```

EAP-LEAP has been used when Freeradius is the RADIUS Server. This has been verified with only Cisco AP.

To connect using EAP-LEAP method, **sta_settings.conf** should be described, as shown below:

```c
   network={
          ssid="SSID of Access Point"
          key_mgmt=WPA-EAP
          eap=LEAP
          identity="user1"
          password="test123"
          }
```

To connect using EAP-LEAP for CCX, **sta_settings.conf** should be described, as shown below:

```c
   network={
          ssid="SSID of Access Point"
          key_mgmt=WPA-CCKM
          eap=LEAP
          identity="user1"
          password="test123"
          pairwise=TKIP
          group=TKIP
          proto= WPA2 WPA
          scan_ssid=1
          priority=2
          }

##### radiusd -X 
```

###### Configuration of AP and RADIUS Server to Use EAP Methods

Hostapd is used as the RADIUS Server. The AP and the server are co-located (in the same system).

The following packages which must be installed are as follows:

- libnl-devel
- libsqlite3x-devel
- openssl-devel

###### Configuration of the AP (heading level 7)

1. For AP mode connectivity, ensure that the dev_oper_mode is set in installation as given below and interface is detected after installation. See the [Installing the driver](../wifi91xrcp-getting-started/#installing-the-driver) section.  
   ```c  
   dev_oper_mode = 1  
   ```
2. Navigate to the scripts folder and Ensure that all basic configurations such as interface, ssid, country_code, beacon_int, channel etc. are updated in hostapd_eap.conf as mentioned in [Wi-Fi Access Point (AP) Mode](../wifi91xrcp-developers-guide-operating-modes/wifi-ap-mode) section.
3. Before starting the AP in EAP mode, ensure that in hostapd_eap.conf the following entities are enabled:  
   ```c  
   ieee8021x=1  
   own_ip_addr=192.168.2.1 /* IP address of AP */  
   /* RADIUS authentication server */  
   auth_server_addr=127.0.0.1  
   auth_server_port=1812  
   auth_server_shared_secret=testing123 /* shared secret must be the same as in /etc/certs/hostapd.radius_clients file */  
   ```
4. Run the following command to start the device in the AP mode:  
   ```c  
   # hostapd hostapd_eap.conf -ddddt  >log &  
     
   # sh dhcp_server.sh  wifi1   
     
   where wifi1 is the interface name   
   ```

###### Configuring hostapd as RADIUS Server (heading level 7)

The steps for configuring hostapd as RADIUS server are as follows:

1. Copy the certs folder available in scripts folder to /etc location, which will contain the certificates, hostapd.radius_clients, hostapd.eap_user and dh files.
2. Navigate to the scripts folder and copy the certs folder to the /etc location in your system.  
   ```c  
   # cp -rvf certs /etc/   
   ```
3. Check whether the interface in hostapd_server.conf is same or not as the name of AP interface name.  
   **Example:**  
   ```c  
   # vim hostapd_server.conf   
   ```  
   interface = wifi1, so that RADIUS server will listen on that interface name.
4. Start the RADIUS server in a new terminal after starting AP.  
   ```c  
   # hostapd hostapd_server.conf -ddddd  
   ```

> **Note**:
> 
> - All the Credentials will be in /etc/certs/hostapd.eap_user file. A sample hostapd.eap_user file is present in the certs folder in the scripts folder.
> - The /etc/certs/hostapd.radius_clients file contains the IP required to communicate the shared secret between AP and RADIUS server. Here it is co-located, hence it is the loop-back address.

###### Steps to Connect EAP-TLS Using wpa_supplicant v 2.6 and Above

###### Installing FreeRADIUS Server (heading level 7)

1. Download FreeRADIUS Server from the link below:  
   Link: [https://freeradius.org/](https://freeradius.org/)  
   **Note:** Try to download the latest release.
2. After downloading, the file name looks like this  
   ```c  
   freeradius-server-release_x_x_x.tar.gz  
   ```
3. Untar the above file  
   tar -xvf freeradius-server-release_x_x_x.tar.gz
4. Enter the directory after untar and run the following command:  
   ```c  
    cd freeradius-server-release_x_x_x/  
    ./configure  
   ```
5. It will check the necessary prerequisites for the installation. You may get errors like libtalloc not found. Install them with:  
   ```c  
   dnf install libtalloc*  
   ```
6. After a successful execution of configuration with no errors, provide the make install command.
7. Connect the radius server installed machine (laptop or PC installed with radius server) to the target AP with a LAN cable.
8. Get the IP address from the AP by using the following commands:  
   ```c  
   dhclient <interface name> -r  
   dhclient <interface name> -v  
   ```
9. Open the AP configuration settings in the browser, as shown below:  
   ![AP Configuration Settings](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/ap-configuration-settings.png)  
   Refer to the image above to configure the AP settings.  
   **Note:** Block contains 'radius server shared secret ', Enter the shared Secret. Which is used to configure secret in  client.conf as explained below.  
   Enter the IP address, which is obtained by dhclient.  
   Radius server Port number is 1812
10. After a successful configuration, go to directory: cd /usr/local/etc/raddb
11. Configure two files:  
    **clients.conf**  [In this case, the "client" is the access point (AP) that connects to the Radius server.]  
    **users**  [In this case, the "user" is the mobile phone or station that connects to the above AP].
12. Open file /usr/local/etc/raddb/clients.conf. Configure network block as follows:  
    client private-network-1 {  
    ```c  
      ipaddr = <IP of AP>/24     // example : 192.168.1.1/24  
      
     secret = <shared secret>  //  shared secret configured in AP  
      
     }  
    ```  
    Save and close the file.  
    Example:  
    ![Clients File Configuration](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image19.png)
13. Open the **/usr/local/etc/raddb/users** file and configure identity in the file, as shown below.  
    < identity > Cleartext-password :=< password for client >  
    Example: user1 Cleartext-password :="12345678"  
    ![Users File Configuration](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image20.png)  
    **Note:** Above **'user1'** is the identity, **12345678** is the password to be entered in the station settings file or supplicant configuration file.  
    Save and close the file.
14. Generate certificates using the process given in the section below and copy certs to /etc folder.  
    Configure the network block for EAP-TLS in the supplicant configuration file, as shown below.  
    The following information is configured in the configuration file below:  
    - SSID of AP,  
    - Identity  
    - Password  
    - Path for ca_cert, client_cert, private_key, and private_key_passwd which are generated using the process given below.  
    #Enable this block for EAP-TLS  
    ```c  
                         network={  
      
                                 ssid="<SSID>"  
      
                                 key_mgmt=WPA-EAP  
      
                                 eap=TLS  
      
                                 anonymous_identity="tlsuser"  
      
                                 identity="<user>"  
      
                                 password="<password>"  
      
                                 ca_cert="/etc/certs/ca.pem"  
      
                                 client_cert="/etc/certs/client.pem"  
      
                                 private_key_passwd="whatever"  
      
                                 private_key="/etc/certs/client.key"  
      
                                 pairwise=CCMP TKIP  
      
                                 group=CCMP TKIP  
      
                                 proto=WPA2 WPA  
      
                                 priority=20  
      
                          }  
    ```

Example:

![Certificates Config Example in Supplicant Config File](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image21.png)

15.Configure the certificate in the server by editing the following entries in the **/usr/local/etc/raddb/mods-enabled/eap** file.

```c
     tls-config tls-common {

                          private_key_password = whatever

                          private_key_file = /etc/certs/server.key

                          certificate_file = /etc/certs/server.pem

                          ca_file = /etc/certs/ca.pem

                        }
```

Example:

![Server Certificates Config Example](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image22.png)

1. To start the Radius server, run the following command:  
   ```c  
     radiusd -X  
   ```

17.Connect the STA by running supplicant. STA should get connected to the AP if all the configurations are proper.

###### Generate Certificates

1. Navigate to the /**usr/local/etc/raddb/certs** folder.
2. To remove all the previous certs, run the following command:  
   ```c  
   # rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt*  
   ```
3. **Generate the CA certificate**  
   ```c  
   # vi ca.cnf  
   ```  
   You can edit "input_password" and "output_password" fields to be the password for the CA certificate.  
   default_days and default_crt_days are the limits for validity of the certificates. The user can modify as per the requirement.  
   ```c  
   # make ca.pem  
   ```  
   This step creates the CA certificate.  
   ```c  
    # make ca.der  
   ```  
   This step creates the DER format of the self-signed certificate, which can be imported into Windows.
4. **Generate the SERVER CERTIFICATE**  
   The following steps will let you create a server certificate for use with TLS-based EAP methods, such as EAP-TLS, PEAP, and TTLS.  
   ```c  
   # vi server.cnf  
   ```  
   You can edit the "input_password" and "output_password" fields to be the password for the server certificate.  
   default_days and default_crt_days are the limits for validity of the certificates. You can modify these per specific requirements.  
   ```c  
   # make server.pem  
   ```  
   This step creates the server certificate.  
   ```c  
   # make server.csr  
   ```  
   Ensure that the certificate contains the XP extensions needed by Microsoft clients.
5. **Generate the CLIENT CERTIFICATE**  
   Client certificates are used by EAP-TLS, and optionally by EAP TTLS and PEAP.  The following steps outline how to create a client certificate that is signed by the server certificate created above. You will have to have the password for the server certificate in the "input_password" and "output_password" fields of the server.cnf file.  
   ```c  
   # vi client.cnf  
   ```  
   You can edit the "input_password" and "output_password" fields to be the password for the client certificate.  You will have to give these passwords to the end user who will be using the certificates.  
   default_days and default_crt_days are the limits for validity of the certificates. The user can modify as per the requirement.  
   ```c  
   # make client.pem  
   ```  
   This step creates the client certificate.  
   > **Note**:  
   >   
   > **i)** User can configure input_password and output_password in all three cnf files.  
   >   
   > **ii)** default_days and default_crt_days are the limits for validity of the certificates. The user can modify as per the requirement
6. After creating all the certs, copy them to the /etc folder:  
   ```c  
   # cp certs/ /etc -rf  
   ```

##### Wi-Fi Protected Setup

Wi-Fi Protected Setup (WPS) is a standard for easy and secure wireless network setup and connections. The OSD driver supports the following configuration method:

- Push Button Method

WPS uses the following terms to describe the entities participating in the network setup:

**Access Point:** WLAN access point

**Registrar:** A device that controls a network and can authorize addition of new devices. This may be either in the AP ("internal Registrar") or in an external device, e.g., a laptop, ("external Registrar")

**Enrollee:** A device that is being authorized to use the network

It should also be noted that the AP and a client device may change roles (i.e., AP acts as an Enrollee and client device as a Registrar) when WPS is used to configure the access point.)

###### STA Mode WPS Configuration

A WPS Configuration file is used for setting up a connection with a remote Access Point. A sample WPS configuration file is given below for reference.

```shell
ctrl_interface=/var/run/wpa_supplicant
update_config=1
uuid=12345678-9abc-def0-1234-56789abcdef0
device_name=RSI_P2P_DEVICE
manufacturer=Redpine Signals, Inc.model_name=M2MCombo
model_number=9117
serial_number=03
device_type=1-0050F204-1
os_version=01020300
config_methods=display push_button keypad  
```

The steps for configuring WPS in Client mode are as follows:

1. Start the driver in Client mode.
2. To start the supplicant, run the following command without any network block:  
   ```shell  
   # wpa_supplicant -i <vap_name> -D nl80211 -c <wps_conf_file> -ddddt   
   ```
3. For Push Button method:  
   - Push the button on the Access Point  
   - run the following command for the n-Link® STA    
     ```shell    
     # wpa_cli -i <vap_name> -p <path of ctrl sockets> wps_pbc <bssid>      
     ```  
   - This is the Access Point's MAC address. If the BSSID is not known, the input parameter will be the string named "any"  
   - Wait for the STA to parse all the WPS Access Points.

###### AP Mode WPS Push Button Configuration

WPS support is not enabled in default Hostapd application. Enable the below configuration in hostpad build configuration (.config) and compile hostpad.

```shell
CONFIG_WPS=y
CONFIG_WPS_UPNP=y 
```

Enable the changes below in hostpad configuration file.

```shell
wpa_key_mgmt=WPA-PSK
wpa_psk_file=/etc/hostapd.psk
eap_server=1<br>wps_state=2
ap_setup_locked=1<br>uuid=12345678-9abc-def0-1234-56789abcdef0<br>device_name=SiWx917_n-Link
model_name=OneBox-Mobile
serial_number=000000000001<br>device_type=1-0050F204-1
os_version=01020300<br>config_methods=display push_button keypad
```

The steps for configuring WPS in AP mode are as follows:

1. Start the driver in AP mode.
2. Start the Hostapd with configuration file as input (ex: ap.conf), as given below.  
   ```shell  
   # hostapd ap.conf –dddt > log_file &   
   ```
3. Run the following command for push button. This pbc mode lasts up to two minutes, within two minutes a client needs to be connected else AP will move out of WPS-PBC.  
   ```shell  
   # hostapdcli wps_pbc  
   ```
4. For station in WPS-PBC user can follow the steps in [STA mode WPS configuration](../wifi91xrcp-developers-guide-wifi-features/wifi-protected-setup#sta-mode-wps-configuration) section and try connecting with AP .

##### Roaming and Background Scan

Background scanning and roaming can be verified using wpa_supplicant.

> **Note**: Use supplicant version greater than 2.6 for better roaming performance.

To use this feature, ensure that the flag **CONFIG_BGSCAN_SIMPLE** is enabled in the supplicant build configuration file (.config).
See the [Roaming](../wifi91xrcp-developers-guide-wifi-configuration/roaming-configuration#configure-and-compile-supplicant-for-roaming) section for suppilcant configuration.

This will enable building BGSCAN SIMPLE module, which is responsible for requesting background scans for the purpose of roaming within ESS. If this option is not enabled, rebuild wpa_supplicant binary with this option.

‘bgscan’ parameters use the following format:

```c
bgscan="simple:<short_bgscan_intrvl_in_secs>:<signal_strength_thrshld>:<long_bgscan_intrvl_in_secs>"
```

This line should be present either inside a network block or outside of all network blocks based on the requirement.

```c
Ex: bgscan=”simple: 30:-45:300”
```

> **Note**: If you do not require bgscan, disable it in the supplicant config and do not include configurations above in the wpa_supplicant.conf file. This will only work if you are not connected through the network manager.

###### Configuring Background Scan Parameters through debugfs

For Bgscan, f/w requires some of the parameters to be configured. The configuration is populated with default values unless you configure them through debugfs. Run the following commands to configure bgscan parameters:

1. To verify the bgscan and parameters, run the following command:  
   ```shell  
   # cat /sys/kernel/debug/phy<X>/bgscan   
   ```
2. To enable background scan and configure its parameters from debugfs, run the following commands:  
   ```shell  
   # echo 1 10 10 20 20 100 1 3 1 6 11 > /sys/kernel/debug/phy<X>/bgscan  
   ```

The input parameters of the background scan command are explained below.

- **<background_enable>:** To enable/disable the background scan.  
  - 0 - Disable  
  - 1 - Enable
- **<bgscan_threshold>:** The Background scan threshold is referred to as the RSSI Upper Threshold. At every background scan interval , the n-Link® module decides whether to initiate or not to initiate a background scan based on the connected Access Point’s RSSI. The module initiates a background scan if the RSSI of the connected Access Point is below this threshold. The input value should be the absolute value in dBm.
- **<rssi_tolerance_threshold>:** If the difference between the current RSSI value of the connected Access Point and the RSSI value of the Access Point from the previous background scan is greater than the RSSI Tolerance Threshold, the module performs a background scan. Assigning a large value to this field will eliminate this method of triggering background scans.
- **< periodicity >:** This parameter specifies the interval between the background scans. The unit of this field is seconds. Setting the value of this field as 0 will disable background scans.
- **<active_scan_duration>:** This parameter determines the duration of the active scan in each channel during the Background scan process. The recommended value for this parameter is 20 ms for quicker background scan operation and uninterrupted throughput. The maximum allowed value for this parameter is 255 ms.
- **<passive_scan_duration>:** This parameter determines the duration of the passive scan in each DFS channel. If an active scan is enabled in a DFS channel and a beacon or probe response is received during that period, the module converts the passive scan into an active scan and waits through the duration specified by the <active_scan_duration> parameter. During a passive scan, if any beacon is received in a channel, the recommended value for this parameter is 100 ms. The active scan in DFS channel can be enabled through Background scan probe request. Active scanning will be performed only if channel switch IE (Information Element) is not present in the received beacon or probe response packets. The maximum allowed value for this parameter is 255 ms.
- **<two_probe_enable>:** If this feature is enabled, the Client sends two probe requests to the Access Point. This is useful when scanning is carried out in channels with high traffic. The valid values are as follows:  
  - 0 – Disable  
  - 1 – Enable
- **<num_of_bgscan_channels>:** Specifies the number of Background scan channels. The n-Link® module supports up to 24 channels.
- **<channels_to_scan>:** The list of channels in which Background scan has to be performed.

1. To disable background scan , periodicity should be zero.  
   ```shell  
   # echo 1 10 10 0 20 70 0 3 1 6 11 > /sys/kernel/debug/phy<X>/bgscan   
   ```
2. To check the list of bgscan channels configured to device, run the following command. This will display the list of bgscan channels configured to device with DFS indication also.  
   ```shell  
   # cat /sys/kernel/debug/phy<X>/bgscan   
   ```

###### Setting Bgscan SSID through debugfs

If the background scan is running, you can set the bgscan SSID to send two probe requests, one without and one with SSID by following the steps below.

1. Run the following command to set the bgscan SSID:  
   ```shell  
   # echo <bgscan_ssid_name> > /sys/kernel/debug/phy<X>/bgscan_ssid   
   ```
2. Run the following command to check whether the bgscan SSID is getting set or not:  
   ```shell  
   # cat /sys/kernel/debug/phy<X>/bgscan_ssid  
   ```
3. After setting bgscan_ssid, run the following command to update bgscan parameters with two probes enabled:  
   ```shell  
   # echo 1 10 10 30 20 70 1 6 1 2 3 4 5 6 >/sys/kernel/debug/phy<X>/bgscan  
   ```
4. Follow the instructions above to update the bgscan parameters.
5. The sniffer capture will show two probe requests, one with and one without SSID.

##### Power Save Modes and Configuration

This section describes the power save features of the SiWx91x RCP Driver for Radio Co-processor (RCP) mode.

###### Power Save Modes

The SiWx91x device support two types of power save modes. They are outlined below:

- **Ultra-low Power (ULP) Mode:** A majority of the module is powered off except for a small section which has a timer and interrupts logic for waking up the module. The module cannot respond to the Host processor's commands/requests unless and until it gets wake up because of timeout or because of an interrupt asserted by Host processor. The sleep entry/exit procedures in this mode are indicated to the Host processor either through a packet based or signal based handshake. This mode is supported only for SDIO host interface.

Out of two ULP Handshake Modes (signal (GPIO) based or Packet (message) based), GPIO based mode is more effective in power save. If target platform does not have free/spare GPIO, they can use message based mode.

> In Wi-Fi, only Client (Station) mode supports power save. By default, the module will be in power save disable state, user has to enable it explicitly.

###### Device Sleep Mode

For each of the above power save modes, the module supports following sleep modes. They are outlined below:

- **Deep Sleep:** The module is in deep sleep mode when it is not connected to an Access Point. The Deep Sleep is defined by the <deep_sleep_wakeup_period> parameter of the PS command.
- **Connected Sleep**: In the connected state, the module can operate in Max PSP or U-APSD. These profiles are used by the module to decide when to enter and exit from power save modes on the fly. They have to be selected based on the performance and power consumption requirements of the end product.
- **Fast PSP**: This profile is a variant of the Traffic Based PSP which exits power save mode even for a single packet and enters the power save mode if no packet is transferred for the <monitor_interval> amount of duration.  This profile is enabled independently for the Transmit and Receive directions if the <tx_threshold> and <rx_threshold> parameters are assigned zero, respectively, while assigning a non-zero value to the <monitor_interval> parameter.

###### Wakeup Procedures and Data Retrieval

Device acting as station in power save mode, the module wakes up at periodic intervals or due to certain events (like pending transmit packets from the Host). At every wake up, the module has to poll the Access Point and check whether there are any pending Rx packets destined for the module. The module uses different protocols to retrieve data from the Access Point based on the protocol supported by the Access Point. These data retrieval methods (protocol-based) are used to further classify the power save profiles described in the previous section into Max PSP, Periodic U-APSD and Transmit based U-APSD.

The MAX PSP and U-APSD modes are explained below:

- **Max PSP:** In this mode, the module wakes up at the end of sleep period (Listen or DTIM interval) and retrieves pending Rx packets from the Access Point by sending a PS-POLL packet. It also transmits any packets received from the Host processor and then goes back to sleep. The parameters listed below are used by the module to decide the period of sleep during power save, in the same order of priority:  
  - <listen_interval_duration>  
  - <dtim_interval_duration>  
  - <num_beacons_per_listen_interval>  
  - <num_dtims_per_sleep>
- **U-APSD:** Two types of U-APSD power save modes are supported as explained below. For using U-APSD, <enabled_U-APSD> module param has to be set to 1. Also <max_sp_len> module param needs to be configured as required while installing the modules. In addition to these configurations, <U-APSD_wakeup_period> can be configured using debugfs ps_params command to select one of the two variants of U-APSD as explained below.  
  1. **Periodic U-APSD:** This mode is enabled by default if power save enabled by iw dev command (as given below) and takes <U-APSD_wakeup_period> as 100. This can  be configured using the ps_params command with the non zero value in  <U-APSD_wakeup_period> parameter . For this mode, the wakeup period can be assigned with a value ranging between 10 and 100 milliseconds. If it is supported by the Access Point, then in this mode, the module wakes up at the end of each sleep period and transmits pending data or a QoS Null packet in order to retrieve the data from the Access Point. The sleep period is governed by the parameter set in the ps_params command in addition to the <U-APSD_wakeup_period>. The sleep period has the minimum of the values programmed using the above command. If the Access Point does not support U-APSD, the module tries to mimic this mode by waking up at the end of the sleep period and transmits pending data and a PS_POLL packet to retrieve the data from the Access Point.  
  2. **Transmit based U-APSD:** If <U-APSD_wakeup_period> parameter is set to 0 in the ps_params command, then Transmit based U-APSD mode is enabled. In ULP mode, the Transmit based U-APSD mode can be used only when the signal-based handshake is enabled (and not in packet-based handshake mode). In this mode, the module wakes up from sleep when the Host sends a packet to be transmitted and then retrieves the pending packets from the Access Point by transmitting the packet. The module also wakes up if there is no packet transmitted for the sleep duration programmed in the ps_params command. If the Access Point does not support U-APSD, the module mimics this mode by waking up whenever there is a packet to be transmitted. It generally transmits the packet and then retrieves the pending data from the Access Point by sending a PS_POLL packet.

###### Configuring ULP device power save for SDIO interface

Install the driver as follow to enable ULP power save

```shell
##### insmod rsi_91x.ko rsi_zone_enabled=1 dev_oper_mode=<value> ps_sleep_type=2 ulp_handshake_mode=<value1> 
```

For No handshake                 : ulp_handshake_mode = 0

For GPIO based handshake   : ulp_handshake_mode = 1

For Packet based handshake : ulp_handshake_mode = 2 (Default)

```shell
##### insmod rsi_sdio.ko
```

###### Configuration of ULP GPIO Handshake and GPIO Numbers

For GPIO handshake driver requires two GPIO pins. These pins need to be configured by the user as module params.

Install the driver as follow to enable GPIO handshake

```shell
##### insmod rsi_91x.ko ps_sleep_type=<value> ulp_handshake_mode=1 ulp_gpio_read=X ulp_gpio_write=Y 
```

- For ULP power save : ps_sleep_type = 2

**ULP GPIO handshake supported for sdio interface only.**

- In this case, `X` and `Y` are the platform GPIO’s used for the GPIO handshake.
- Platform GPIO `X` should be connected with UULP3 /UULP0 in the rsi_EVB (a particular PIN can be selected using sleep_ind_gpio_sel module param).
- Platform GPIO `Y` should be connected with UULP2 in the rsi_EVB.

###### Enabling Power Save

Power save can be enabled or disabled through command line using iw commands. By default 802.11 default power save is enabled if Coex mode is enabled. U-APSD is enabled based on AP’s U-APSD configuration.

Following are the commands used in power save configuration.

1. Enable the power save:  
   ```shell  
   # iw dev <interface_name> set power_save on   
   ```
2. Disable power save:  
   ```shell  
   # iw dev <interface_name> set power_save off   
   ```
3. Check the power save status:  
   ```shell  
   # iw dev <interface_name> get power_save  
   ```  
   - In this case, `interface_name` will vary from one host to the other.  
   - To find out the `interface_name`, run the following command:    
     ```shell    
     # iw dev    
     ```

###### Configure Power Save Parameters/Profiles through debugfs Dynamically

Driver supports dynamic configuration of power save type and profile parameters using debugfs as explained below.

To update power save parameter, run the following command:

```c
echo <sleep_type> <tx_threshold> <rx_threhold> <tx_hysteresis> < rx_hysteresis> <monitor_interval> <listen_interval_duration> <num_beacons_per_listen_interval> <dtim_interval_duration> <num_dtims_per_sleep> <deep_sleep_wakeup_period> <U-APSD_wakeup_period> >/sys/kernel/debug/phy<X>/ ps_params
```

The input parameters of the power save command are explained below.

- **<sleep_type>:** This parameter is used to select the sleep mode  2- ULP sleep mode.
- **<tx_threshold>:** If a non-zero value is assigned, this parameter is used to set a threshold for the Transmit throughput computed during the <monitor_interval> period so that the module can decide to enter (throughput ≤ threshold) or exit (throughput > threshold) the power save mode. The value is in Mbps and Supported TX threshold is 0 to 10Mbps
- **<rx_threshold>:** If a non-zero value is assigned, this parameter is used to set a threshold for the Receive throughput computed during the <monitor_interval> period so that the module can decide to enter (throughput ≤ threshold) or exit (throughput > threshold) the power save mode. The value is in Mbps and Supported RX threshold is 0 to 10Mbps
- **<tx_hysteresis>:** The decision to enter or exit power save mode based on the Transmit throughput alone can result in frequent switching between the power save and non-power save modes. If this is not beneficial, the <tx_hysteresis> parameter can used to make the module re-enter the power save mode only when the throughput falls below the difference between the <tx_threshold> and <tx_hysteresis> values. The value is in Mbps and minimum value is 0 Mbps. This parameter should be assigned a value which is less than the value assigned to the <tx_threshold> parameter.
- **<rx_hysteresis>:** The decision to enter or exit power save mode based on the Receive throughput which alone can result in frequent switching between the power save and non-power save modes. If this is not beneficial, the <rx_hysteresis> parameter can be used to make the module re-enter the power save mode only when the throughput falls below the difference between the <rx_threshold> and <rx_hysteresis> values. The value is in Mbps and minimum value is 0 Mbps. This parameter should be assigned a value which is less than the value assigned to the <rx_threshold> parameter.
- **<monitor_interval>:** This parameter specifies the duration (in milliseconds) over which the Transmit and Receive throughputs are computed to compare with the <tx_threshold>, <rx_threshold>, <tx_hysteresis> and <rx_hysteresis> values. The maximum value of this parameter is 30000 ms (30 seconds).
- **<listen_interval_duration>:** This parameter specifies the duration (in milliseconds) for which the module sleeps in the connected state power save modes. If a non-zero value is assigned to this parameter it takes precedence over the other sleep duration parameters that follow (<num_beacons_per_listen_interval>, <dtim_interval_duration>, <num_dtims_per_sleep>). The maximum duration for which the device supports sleep is 4095 times the duration of the beacon interval considering the listen interval parameters of the access point. The maximum value for this parameter can be 65535, but the duration should be the deciding factor in the beacon interval of the access point. This parameter is considered only after the module is connected to the access point. For example, if the beacon interval of the AP is 100 ms and listen interval of AP is 8 beacons, then the maximum time the device can sleep without any data loss is 800 ms (8 * 100). Hence, the listen_interval_duration can be up to 800 ms.  
  **Note: Listen interval duration greater than one sec (> 1sec ) is not supported**
- **<num_beacons_per_listen_interval>:** This parameter specifies the number of beacon intervals for which the module sleeps in the connected state power save modes. Here, the device will wake up for the nth beacon, where n is the listen interval value programmed by the user. If a non-zero value is assigned to this parameter it takes precedence over the other sleep duration parameters that follow (<dtim_interval_duration>, <num_dtims_per_sleep>). This parameter is used only when the above parameter is assigned to 0. The maximum value for this parameter is 4095. The value for this parameter also has to be chosen keeping in mind the listen interval of the access point. . This parameter is considered only after the module is connected to the access point.
- **<dtim_interval_duration>:** This parameter specifies the duration (in milliseconds) for which the module sleeps in the connected state power save modes. The device will wake up for the nearest DTIM beacon after the time which the user has programmed expires. This parameter can be used when DTIM information is not available. If a non-zero value is assigned to this parameter, then it takes precedence over the other sleep duration parameter that follows (<num_dtims_per_sleep>). This parameter is used only when the above parameters are assigned 0. The maximum value for this parameter can be 10000 ms. This parameter is considered only after the module is connected to the access point.
- **<num_dtims_per_sleep>:** This parameter specifies the number of DTIM intervals for which the module sleeps in the connected state power save modes. This parameter has least priority compared to the ones above and is used only if the above parameters are assigned to 0. The maximum value for this parameter is 10. This parameter is considered only after the module is connected to the access point.
- **<deep_sleep_wakeup_period>:** This parameter specifies the duration (in milliseconds) for which the module sleeps in the Deep Sleep mode. The value of 0 is invalid for ULP mode and should not be used. The maximum value for this parameter can be 65535.
- **<U-APSD_wakeup_period>:** This parameter specifies the duration (in milliseconds) for which the module sleeps after connection if the AP supports U-APSD. For value 10-100 milliseconds it will work as periodic U-APSD and for value 0 it will work as transmit based U-APSD.

> **Note:**  In Wi-Fi + BLE coexistence mode, User need to give both Wi-Fi power save command and BLE power save command in order to enable power save. See the [BLE Power Save Modes](../wifi91xrcp-developers-guide-ble-features/ble-power-save-modes) section for information about BLE power save modes.

##### Target Wake Time

Target Wake Time (TWT) allows an AP to manage activity in the BSS, minimize contention between STAs, and reduce the required amount of time that an STA utilizing a power management mode needs to be awake. This is achieved by allocating STAs to operate at nonoverlapping times and/or frequencies and concentrate the frame exchanges in predefined service periods.

TWT (Target Wake Time) setup is only supported in 11ax (HE) connectivity. Follow the steps below to enable TWT.

###### TWT Setup/Teardown

Follow the steps below for TWT setup and teardown.

1. Enable **CONFIG_TWT_SUPPORT** define, which is included in both driver Makefile and apps Makefile (apps/Makefile).
2. Compile the driver, as desribed in the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) section.  
   ```c  
    #make clean;make  
   ```
3. Navigate to the release folder and insert the driver.  
   ```c  
    # cd release  
    # insmod rsi_91x.ko driver_mode_value=1 rsi_zone_enabled=<val> ...  
    # insmod rsi_sdio.ko  
   ```
4. To connect to the third access point (AP), run the following command:  
   ```c  
    # wpa_supplicant -i <interface_name> -D nl80211 -c <sta_settings.conf> -ddddt > log1 &   
   ```
5. To start or stop the TWT session, run the following command. This will trigger the TWT Setup/Teardown frame.  
   ```c  
    # ./onebox_util rpine0 twt_config <wake_duration> <wake_duration_tolerance> <wake_int_exp> <wake_int_exp_tolerance> <wake_int_mantissa> <wake_int_mantissa_tolerance> <implicit_twt> <unannounced_twt> <triggered_twt> <negotiation_type> <twt_channel> <twt_protection> <twt_flow_id> <restrict_twt_outside_tsp> <twt_retry_limit> <twt_retry_interval> <twt_req_type> <twt_enable> <wake_duration_unit>  
   ```  
   Example:  
   ```c  
    # ./onebox_util rpine0 twt_config 255 255 15 15 650 10 1 1 0 0 0 0 1 1 6 10 1 1 0   
   ```

- **wake_duration**: This is the nominal minimum wake duration of TWT. This is the time for which DUT will be in wake state for Transmission or reception of data. Allowed values range is  0-255.
- **wake_duration_tol**: This is the tolerance allowed for wake duration in case of suggest TWT. Received TWT wake duration from AP will be validated against tolerance limits and decided if TWT config received is in acceptable range. Allowed values are 0-255.
- **wake_int_exp**: TWT Wake interval exponent. It is exponent to base 2. Allowed values are 0 - 31.
- **wake_int_exp_tol**: This is the allowed tolerance for wake_int_exp in case of suggest TWT request. Received TWT wake interval exponent from AP will be validated against tolerance limits and decided if TWT config received is in acceptable range. Allowed values are 0 - 31.
- **wake_int_mantissa**: This is the TWT wake interval mantissa. Allowed values are 0-65535.
- **wake_int_mantissa_tol**: This is tolerance allowed for wake_int_mantissa in case of suggest TWT. Received TWT wake interval mantissa from AP will be validated against tolerance limits and decided if TWT config received is in acceptable range. Allowed values are 0-65535.
- **implicit_twt**: If enabled (1), the TWT requesting STA calculates the Next TWT by adding a fixed value to the current TWT value. Explicit TWT is currently not allowed.
- **un_announced_twt**: If enabled (1), TWT requesting STA does not announce its wake up to AP through PS Poll's or U-APSD trigger frames.
- **triggered_twt**: If enabled(1), atleast one trigger frame is included in the TWT Service Period(TSP).
- **negotiation_type**: If disabled(0), the TWT requesting STA supports individual TWT. Broadcast TWT is currently not supported.
- **twt_channel**: Currently this configuration is not supported. Allowed values are 0-7.
- **twt_protection**:  If enabled (1), TSP is protected. This is negotiable with AP. Currently not supported. Only zero is allowed.
- **twt_flow_id**: This is TWT flow ID.  
  - Range: 0-7 ( should be same for setup and teardown, otherwise error will be triggered).  
  - 0xff: To teardown all active sessions. This is valid only in Teardown TWT case.
- **restrict_tx_outside_tsp**: If enabled (1), any Tx outside the TSP is restricted. Else, TX can happen outside the TSP also.
- **twt_retry_limit**: This is the maximum number of retries allowed, if the TWT response frame is not recieved for the sent TWT request frame. Allowed values are 0 - 15.
- **twt_retry_interval**: The interval, in seconds, between two twt request retries. Allowed values are 5 - 255.
- **req_type**: This is the TWT request type.  
  - 0 - Request TWT  
  - 1 - Suggest TWT  
  - 2 - Demand TWT
- **twt_enable**: If enabled, TWT setup frame is triggered or if disabled, TWT Teardown frame is triggered.  
  - 0 - Disable  
  - 1 - Enable
- **wake_duration_unit**: This parameter defines unit for wake_duration. Allowed values are 0 (256 uS) and 1 (1024 uS).

The following command provides the status of the ongoing TWT session:

```c
##### ./onebox_util rpine0 twt_status
```

TWT Command status

|**Sr.No**|**STATUS**|**DESCRIPTION**|
|---|---|---|
|1.|TWT_DEVICE_NOT_IN_CONNECTED_STATE|Occurs when device is not connected to AP.|
|2.|TWT_SETUP_ERR_SESSION_ACTIVE|Occurs when users try to give TWT setup command when there is an already active TWT session.|
|3.|TWT_TEARDOWN_ERR_FLOWID_NOT_MATCHED|Occurs when TWT teardown command is given with a flow ID that does not match existing session flow ID.|
|4.|TWT_TEARDOWN_ERR_NOACTIVE_SESS|Occurs when teardown command is given while there is no active session.|
|5.|TWT_SETUP_SESSION_IN_PROGRESS|Occurs when users try to give TWT setup command when there is an already TWT session in progress.|
|6.|TWT_SESSION_SUCC|TWT session setup success. TWT session is active.|
|7.|TWT_UNSOL_SESSION_SUCC|Unsolicited TWT setup response from AP accepted. TWT session is active.|
|8.|TWT_SETUP_AP_REJECTED|TWT Reject frame recieved in response for the sent TWT setup frame.|
|9.|TWT_SETUP_RSP_OUTOF_TOL|TWT response parameters from AP for TWT Suggest request is not within tolerance set by User.|
|10.|TWT_SETUP_RSP_NOT_MATCHED|TWT response parameters from AP for TWT Demand request does not match parameters given by User.|
|11.|TWT_SETUP_UNSUPPORTED_RSP|Unsupported TWT response from AP.|
|12.|TWT_TEARDOWN_SUCC|TWT session teardown success.|
|13.|TWT_AP_TEARDOWN_SUCC|TWT session teardown from AP success.|
|14.|TWT_SETUP_FAIL_MAX_RETRIES_REACHED|TWT setup request retried maximum number of times as configured by user.|
|15.|TWT_INACTIVE_DUETO_ROAMING|TWT session inactive due to roaming.|
|16.|TWT_INACTIVE_DUETO_DISCONNECT|TWT session inactive due to disconnect.|
|17.|TWT_INACTIVE_NO_AP_SUPPORT|TWT session inactive as connected AP does not support TWT.|

###### Reschedule TWT

To suspend and resume the current TWT session dynamically, follow the steps below to reschedule TWT. 

1. To check whether the TWT session is active or not, run the following command:  
   ```c  
    # ./onebox_util rpine0 twt_status  
   ```
2. If the TWT session is active, run the following command to reschedule TWT:  
   ```c  
    #./onebox_util rpine0 reschedule_twt twt_flow_id twt_action suspend_duration  
   ```  
   **twt_flow_id:** Active twt-session flow ID.  
   **twt_action:** This are type for twt_action  
   - 0 - Suspend indefinitely  
   - 1 - Suspend for duration  
   - 2 - Resume immediately

 
**suspend_duration:** Suspend TWT for a given interval. The value should be non-zero only when twt_action is 1. Otherwise, it should be zero.  

1. To check the reschedule_twt session status, run the following command:  
   ```c  
    # ./onebox_util rpine0 twt_status  
   ```

##### 802.11w (PMF)

This section describes the configuration of 802.11w (PMF).

###### Configuring and Compiling Driver for PMF in Client Mode

1. compile wpa_supplicant by Enable  CONFIG_IEEE80211W=y in wpa_supplicant .config file.
2. Enable WPA-PSK-SHA256 as key_mgmt in network block in supplicant sta_settings.conf  
   - `pmf=1/2` - PMF is enabled/required correspondingly.    
     ```shell    
     pmf=2    
     network = {    
           ssid="SSID of Access Point"    
           pairwise=CCMP    
           group=CCMP    
           key_mgmt=WPA-PSK-SHA256    
           psk="12345678"    
           proto=WPA2    
           priority=1    
           }    
     ```
3. Configure AP as MFP Capable/Required.

###### Configuring and Compiling Driver for PMF in AP Mode

1. Compile hostapd by enabling `CONFIG_IEEE80211W=y` in hostapd config file.
2. Enable WPA-PSK-SHA256 as key_mgmt in `hostapd_ccmp.conf`.
3. Ensure that the options below are enabled apart from your configuration.  
   ```shell  
   # This field is a bit field that can be used to enable WPA (IEEE 802.11i/D3.0)**  
   # and/or WPA2 (full IEEE 802.11i/RSN):  
   # bit0 = WPA  
   # bit1 = IEEE 802.11i/RSN (WPA2) (dot11RSNAEnabled)  
   wpa=2  
     
   # ieee80211w: Whether management frame protection (MFP) is enabled  
   # 0 = disabled (default)  
   # 1 = optional  
   # 2 = required  
   ieee80211w=2  
   wpa_key_mgmt =WPA-PSK-SHA256  
   group_mgmt_cipher=AES-128-CMAC  
   ```

##### Wi-Fi PER Mode

SiWx91x RCP driver supports Wi-Fi PER mode transmit and E2E mode receive functionality. Follow the steps below to verify both functionalities. 

###### PER Transmit

1. See the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) section and compile the driver, as follows:  
   ```shell  
   # make clean; make  
   ```
2. Navigate to the release folder and run the following commands to set the driver to PER mode.  
   ```shell  
   # cd release  
   # insmod rsi_91x.ko dev_oper_mode=1 driver_mode_value=2 rsi_zone_enabled=0x601  
   # insmod rsi_sdio.ko sdio_clock=10  
   ```
3. Run the following command to check 11N PER transmit:  
   ```shell  
   # ./transmit <base_interface> <Transmit_power> <Data_rate> <Pkt_length> <Transmit_mode> <Channel_no> <11ax_enable> <Rate_flags> <Aggr_enable> <no_of_packets> <delay> <Regulatory_domain>  
   ```

Description of each field:

|SI No|Parameters|Description|values|
|---|---|---|---|
|1|base_interface|Interface Name (string like rpine0).| |
|2|Transmit_power|Controls the transmit power in dBm units|-7 to 18<br/><br/>127 → The packet will be transmitted at the maximum power from the Transmit power table|
|3|Data_rate|Set the transmit data rate|1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54, mcs0, mcs1, mcs2, mcs3, mcs4, mcs5, mcs6 and mcs7|
|4|Pkt_length|Transmit packet length in bytes| |
|5|Transmit_mode|Burst or Continuous mode|0 → Burst mode<br/><br/>1 → Continuous mode|
|6|Channel_no|Channel number on which packets are transmitted|IEEE802.11 channels|
|7|11ax_enable|Enable / Disable 11ax mode|1 → 11ax mode enabled<br/><br/>0 → 11n Mode enabled|
|8|Rate_flags|- To enable/disable Short GI & Greenfield.<br/><br/>- Also to set the channel width of the transmitted packets|Bit 0  (Short_GI for HT mode)/(Short_preamble in 11b)<br/><br/>Bit 1  : (GreenField for HT mode)/(preamble enable for 11b)<br/><br/>Bit 4-2 : CH_BW flags<br/><br/>Bit 5 : This bit has to be set when the user selects 11J channel<br/><br/>Bit 15-6 : Reserved|
|9|Aggr_enable|Enable / Disable Aggregation of transmitting packets|0 → Disable<br/><br/>1 → Enable|
|10|no_of_packets|- Number of packets to be transmitted in Burst mode.<br/><br/>- The transmission stops after the no. of packets specified by this parameter are transmitted in the Burst mode.<br/><br/>- If this value is 0, then the transmission will not stop until the user gives the **"./transmit 0"** command in order to stop the transmissions.<br/><br/>- This parameter is ignored in the case of Continuous mode of transmission.| |
|11|delay|- To specify a delay (in us) between any two packets in burst mode.<br/><br/>- If 0, then the packets will be transmitted without any delay.<br/><br/>- Is ignored in the case of Continuous mode of transmission| |
|12|Regulatory_domain|Set the regulatory Domain|0 → US (FCC)<br/><br/>1 → Europe (ETSI)<br/><br/>2 → Japan (JP)<br/><br/>3 → World Domain<br/><br/>4 → Korea(KC)<br/><br/>5 → WORLD_SAFE(Applicable only for the SiW917Y module)<br/><br/>6 → China(SRRC)(Applicable only for the SiW917Y module)<br/><br/>255 → World Domain|

**Example**

```shell
##### ./transmit rpine0 127 5.5 750 0 11 0 0 0 0 0 255
```

The above command starts continuous transmission with the following configuration:

|**Parameter**|**Value**|
|---|---|
|Transmit gain|2 dbm|
|Data rate|5.5 Mbps|
|Packet Length|750 bytes|
|Transmit mode|1 (continuous mode).|
|Channel number|11|
|External PA|disabled|
|Rate flags|1 (Short GI is enabled with 20 MHz Channel width)|
|Aggregation|disabled (ignored in continuous mode)|
|Number of packets to be transmitted|0 (ignored in continuous mode)|
|Delay between the packets|0 (ignored in continuous mode)|

1. Run the following command to check 11AX PER transmit:  
   ```shell  
   # ./transmit <base_interface> <Trasmit_power> <Data_rate> <Pkt_length> <Transmit_mode> <Channel> <11ax_en> <Rate_flags> <Aggr_enable> <no_of_packets> <delay> <Regulatory_Domain> <coding_type> <nominal_pe> <he_ppdu_type> <beam_change> <BW> <UL_DL> <STBC> <Tx_BF> <GI_LTF> <DCM> <NSTS_MIDAMBLE> <spatial_reuse> <BSS_color> <HE_SIGA2_RESERVED> <RU_ALLOCATION> <N_HELTF_TOT> <SIGB_DCM> <SIGB_MCS> <USER_STA_ID> <SIGB_COMPRESSION_FIELD> <USER_IDX>  
   ```

Description of each parameter is as below:

|**Parameters Name**|**Description**|**Expected Values**|
|---|---|---|
|coding_type|Indicates whether BCC or LDPC to be used|0 - BCC<br/><br/>1 - LDPC|
|nominal_pe|Indicates Nominal T-PE value|0 - 0us<br/><br/>1 - 8us<br/><br/>2 - 16us|
|HE_PPDU_TYPE|0 - HE SU PPDU<br/><br/>1 - HE ER SU PPDU<br/><br/>2 - HE TB PPDU<br/><br/>3 - HE MU PPDU|
|Beam Change|Indicates the spatial mapping of pre-HE and HE fields|0 - pre-HE and HE fields are spatially mapped in the same way<br/><br/>1 - pre-HE and HE fields are spatially mapped differently|
|BW|Indicates the BW for the PPDU|**SU PPDU:**<br/><br/>0 - 20 MHz<br/><br/>1 - 40 MHz<br/><br/>2 - 80 MHz<br/><br/>3 -160 MHz (Only 20 MHz is supported in H/W)<br/><br/>**ER SU PPDU:**<br/><br/>0 - 242-tone RU<br/><br/>1 - upper<br/><br/>106-tone RU|
|UL_DL|Indicates whether the PPDU is UL/DL|Set to 1,if PPDU is Sent by Station to AP<br/><br/>Set to 0,if PPDU is sent by AP|
|STBC|Indicates whether STBC is used for PPDU transmission|0 - no STBC<br/><br/>1 - STBC only if DCM field is set to 0|
|TxBF|Indicates whether beamforming matrix is applied to the transmission|0 - No beamforming matrix<br/><br/>1 - beamforming matrix.<br/><br/>Set to "0" by default.|
|GI_LTF|Indicates the GI and LTF size|**SU/ER_SU:**<br/><br/>0 - 1x HE-LTF and 0.8us GI<br/><br/>1 - 2x HE-LTF and 0.8us GI<br/><br/>2 - 2x HE-LTF and 1.6us GI<br/><br/>3 - 4x HE-LTF and 0.8us GI if both DCM and STBC fields are 1, else 4x HE-LTF and 3.2us GI<br/><br/>**MU:**<br/><br/>0 - 4x HE-LTF and 0.8us GI<br/><br/>1 - 2x HE-LTF and 0.8us GI<br/><br/>2 - 2x HE-LTF and 1.6us GI<br/><br/>3 - 4x HE-LTF and 3.2us GI<br/><br/>**TB:**<br/><br/>0 - 1x HE-LTF and 1.6us GI<br/><br/>1 - 2x HE-LTF and 1.6us GI<br/><br/>2 - 4x HE-LTF and 3.2us GI<br/><br/>3 - Reserved|
|DCM|Indicates whether DCM is applied to Data Symbols|0 - no DCM<br/><br/>1 - DCM|
|NSTS_MIDAMBLE|Indicates the Nsts and Midamble Periodicity|If Doppler is set to 0<br/><br/>BIT[15:13] = Number of space-time streams-1<br/><br/>If Doppler is set to 1<br/><br/>BIT[14:13] = = Number of space-time streams-1<br/><br/>BIT[15] = 0 for MIDAMBLE Periodicity of 10<br/><br/>BIT[15]= 1 for MIDAMBLE Periodicity of 20<br/><br/>Default Doppler value is 0.|
|Spatial Reuse|Indicates whether spatial reuse is allowed during the transmission of the PPDU| |
|BSS color|Color value of BSS| |
|HE_SIGA2_RESERVE|This should be set to 1|The value should be between 0 to 511|
|RU_ALLOCATION|Indicates the RU Allocation Subfield for 20 MHz BW|The value should be between 0 to 255|
|N_HELTF_TOT|Indicates the number of HE-LTF to be transmitted|The vale should be between 0 to 7|
|SIGB_DCM|Indicates whether DCM is applied to SIG-B Symbols**|The value should be 0 to Enable and 1 to Disable|
|SIGB_MCS|Indicates the MCS for SIG-B Symbols|Range of 0-5<br/><br/>6,7 - Reserved|
|USER_STA_ID|Indicates the Station ID of the intended user|The value should be between 0 to 2047|
|SIGB_COMPRESSION_FIELD|The value should be 0 or 1|
|USER_IDX|Indicates the index of the intended user|0 - 1st user<br/><br/>1 - 2nd user .....<br/><br/>8 - 9th user<br/><br/>9 - 63 - Reserved|

**Example:**

```shell
##### ./transmit rpine0 127 mcs0 4000 0 6 1 0 1 0 0 255 0 2 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0
```

1. Run the following command to stop PER transmit:

```shell
##### ./transmit rpine0 0
```

###### Wi-Fi Receive

The **"receive"** utility present in the **"release"** folder can be invoked for displaying the following information.

- Total number of CRC PASS packets
- Total number of CRC FAIL packets and
- Total number of FALSE CCAs

###### Receive Command Usage (heading level 7)

```shell
##### ./receive <rpine-interface> <filename> <channel_number> <start/stop> <channel_width> [user_mask]
```

**<rpine_interface>:** This parameter specifies the Base Interface (string like rpine0).

**<file_name >:** Name of the file into which the statistics will be logged, in addition to being displayed on the console.

**<channel_number>** Channel number in which the statistics need to be logged. On-air testing in DFS,; The channels should be avoided till the module is certified for DFS. Cabled tests can be made to run in these channels.

**<start/stop>:** Parameter to start or stop logging the statistics. Enter 0 to start logging and 1 to stop logging. 

**<channel_width>:** Operating bandwidth of the channel. See the table below.

**[user_mask]:** This is an **OPTIONAL** parameter and is a bitmap through which we can select group of stats defined in below section.

|**Value**|**Channel Width**|
|---|---|
|0|20 MHz|
|2|Upper 20 MHz of 40 MHz|
|4|Lower 20 MHz of 40 MHz|
|6|Full 40 MHz|
|8|20 Mhz mode for 11J channel|

**<user_mask>:** The receive stats are divided in 5 groups. You can select any of the groups or multiple groups of stats by using user_mask value.

Giving 0 or Not argument will result in the old format.

Below table is a grouping of stats:

crc_pass and crc_fail are the common stats to all the groups.

If you do not provide the user_mask value or 0, the default stats are displayed.

<table>
  <thead>
<tr>
<th colspan="1" rowspan="1"><div>BIT</div></th>
<th colspan="1" rowspan="1"><div>STATS</div></th>
</tr>
  </thead>
  <tbody>
<tr>
<td colspan="1" rowspan="8"><div>0</div></td>
<td colspan="1" rowspan="1"><div>cca_stk</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>cca_stk</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>cca_not_stk</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>pkt_abort</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>false_rx_stat</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>cca_idle</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>cal_rssi</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>no_of_ack_sent</div></td>
</tr>
<tr>
<td colspan="1" rowspan="6"><div>1</div></td>
<td colspan="1" rowspan="1"><div>false_under_sat</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>bss_broad_cast_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>bss_multicast_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>bss_da_matched_multicast_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>eof_pkts_drop_count</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>mask_pkts_drop_count</div></td>
</tr>
<tr>
<td colspan="1" rowspan="9"><div>2</div></td>
<td colspan="1" rowspan="1"><div>11B_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>11G_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>11N/mcs pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>11AX_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>HE_SU_PPDU_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>HE_ER_SU_PPDU_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>HE_TRIG_PPDU_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>HE_MU_PPDU_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>11AC_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>3</div></td>
<td colspan="1" rowspan="1"><div>Tx done count</div></td>
</tr>
<tr>
<td colspan="1" rowspan="21"><div>4</div></td>
<td colspan="1" rowspan="1"><div>Total_tx_pkts(mgmt/internal mgmt)</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>rx_packets</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>tx_retries</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>gf_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ht_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>leg_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>leg_prty_pkts</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ht_crc_fails</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>sp_rejected</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>lp_rejected</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ch1_sig_pow</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ch1_noise_pow</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ch2_sig_pow</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ch2_noise_pow</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ch3_sig_pow</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>ch3_noise_pow</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>rssi</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>lna_bb_gain</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>avg_val</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>max_retries</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>max_consecutive_pkt_dropped</div></td>
</tr>
  </tbody>
</table>

Example 1: If user_mask value = 2 , below output is expected:
![Output with user_mask value 2](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image-usrmsk2.png)

Example 2: If user_mask value = 9 , below output is expected:
![Output with user_mask value 9](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image-usrmsk9.png)

Example 3: If user_mask value = 4 , below output is expected:
![Output with user_mask value 4](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image-usrmsk4.png)

If no user_mask value is given default stats are displayed as in below image:
![Output with no user_mask value](/wifi91xrcp-developers-guide-wifi-features/2.15.0/images/image-usrmsk.png)

Once the above command is given on command line, periodically(For each sec) the stats will be displayed on the terminal.

###### Receive E2E Stats

1. See the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) and [Installing the Driver](../wifi91xrcp-getting-started/#installing-the-driver) sections for Wi-Fi E2E Connection.
2. Navigate to the release folder and run receive utility for E2E receive stats.

```shell
##### cd release 
##### ./receive rpine0 <filename> <ch_num> <start/stop> <ch_width>
```

> **Note :** Make sure to disable power save while running E2E Receive stats

#### BLE Features

##### Overview

This section describes the various Bluetooth Low Energy (BLE) protocol features supported by the SiWT917 RCP Driver for Radio Co-processor (RCP) mode:

- [BLE Power Save Modes](ble-power-save-modes) for creating low power Bluetooth devices.
- [BLE PER Mode](ble-per-mode) to test the BLE transmit and receive performance of the SiWT917 radio.

##### BLE Power Save Mode

Vendor-specific HCI commands configure the device in power save mode. The module supports Low Power (LP) and Ultra-Low Power (ULP) modes. These are explained in more detail in the [Power Save Modes and Configuration](../wifi91xrcp-developers-guide-wifi-features/power-save-modes-and-configuration#power-save-modes-and-configuration) section of Wi-Fi Powersave mode. The LP and ULP modes are supported with the SDIO interface.

Run the following command to enable the BLE power save.

```c
hcitool -i <hciX> cmd 0x3F 0x0003 <sleep enable/disable> <sleep mode> <sleep duration>
```

< hciX > - hci interface

< sleep enable/disable > - 0x01 -sleep enable, 0x00 - sleep disable

< Sleep mode > -
0x02 – ULP (Ultra Low Power) mode

< Sleep Duration> - used for sleep duration in Standby mode (in milliseconds) and Range is 0x00 – 0xFF

Example:

```c
hcitool -i hci0 cmd 0x3f 0x0003 0x01 0x02 0xff
```

> **Note:**  In Wi-Fi + BLE coexistence mode, give both BLE and Wi-Fi power save commands to enable power save. See the [Power Save Modes and Configuration](../wifi91xrcp-developers-guide-wifi-features/power-save-modes-and-configuration#power-save-modes-and-configuration) section for  Wi-Fi Powersave mode related information.

##### BLE PER Mode

SiWx91x RCP Driver Supports BLE PER Mode Transmit and Receive functionality. Follow the steps below to verify both functionalities.

1. Follow the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) in the above section and compile the driver as follows.  
   ```shell  
   # make clean; make  
   ```
2. Navigate to the release folder and run the following command to set the driver to PER mode:  
   ```shell  
   # cd release  
   # insmod rsi_91x.ko dev_oper_mode=8 driver_mode_value=2 rsi_zone_enabled=0x601   
   # insmod rsi_sdio.ko sdio_clock=50  
   ```

###### BLE PER Transmit

- Run the following command to check the BLE PER transmit:  
  ```shell  
  # ./ble_transmit <Access_Addr> <pkt_length> <ble_rate> <rx_channel_index><tx_channel_index> <scrambler_seed> <no_of_packets> <payload_type><le_channel_type> <tx_power_index> <tx_mode> <hopping_type> <ant_sel><inter_pkt_gap> <pll_mode> <rf_type> <rf_chain>  
  ```

Description of each field:

|**SI No**|**Parameters**|**Description**|**Values**|
|---|---|---|---|
|1|Access Address|It is a 32-bit address in hexadecimal format|00112233|
|2|pkt_length|Length of the packet, in bytes, to be transmitted.| |
|3|ble_rate|1Mbps - 1 ,2Mbps - 2 , 125Kbps - 4, 500Kbps - 8|
|4|rx_channel_index|Receive channel index, as per the Bluetooth standard|0 to 39|
|5|tx_channel_index|Transmit channel index, as per the Bluetooth standard.|0 to 39|
|6|scrambler_seed|Initial seed to be used for whitening. It should be set to ‘0’ in order to disable whitening. In order toenable the whitening scrambler seed should be given, which is used on the receive side.| |
|7|no_of_packets|Number of packets to be transmitted|It is valid only when the is set to Burst mode.|
|8|payload_type|Type of payload to be transmitted|‘0’ – Payload consists of all zeros<br/><br/>‘1’ – Payload consists of all 0xFF’s<br/><br/>‘2’ – Payload consists of all 0x55’s<br/><br/>‘3’ – Payload consists of all 0xF0’s<br/><br/> |
|9|le_channel_type|advertising channel - 0<br/><br/>data channel - 1| |
|10|tx_power_index|This field corresponds to the transmit power index,The range for tx_power_index is 1 to 63(0 and 32 are invalid)|- If rf_chain is BT_HP_CHAIN<br/><br/>o 1 -12 BLE HP Mode<br/><br/>o 127 magic number for selecting maximum possible power output<br/><br/>- If rf_chain is BT_LP_CHAIN<br/><br/>o 1 - 31 BLE- 0 dBm mode<br/><br/>o 33 - 63 BLE- 10 dBm Mode|
|11|tx_mode|Burst mode - 0<br/><br/>Continuous mode - 1| |
|12|hopping_type|no hopping -0<br/><br/>fixed hopping - 1<br/><br/>random hopping - 2| |
|13|ant_sel|onchip antenna - 2<br/><br/>u.f.l - 3| |
|14|inter_pkt_gap|Number of slots to be skipped between two packets - Each slot will be 1250usec| |
|15|pll_mode|PLL_MODE0 – 0<br/><br/>PLL_MODE1 – 1<br/><br/>PLL_MODE2 – 2| |
|16|rf_chain|WLAN_HP_CHAIN - 0<br/><br/>BT_HP_CHAIN -	2<br/><br/>BT_LP_CHAIN -	3| |

**Example**

Continuous Mode :

```shell
#./ble_transmit 71764129 250 1 38 38 2 0 0 1 10 1 0 3 0 0 1 3
```

```c
Transmit a BLE-1Mbps advertising packet with access address of 0x71764129 and packet length of 250 bytes on 2478 MHz with the following parameters.

Access_Addr - 71764129
pkt_length - 250
ble_rate -1
rx_channel_index -38
tx_channel_index -38
scrambler_seed - 2
no_of_packets - 0
payload_type - 0
le_channel_type -1
tx_power_index -10
tx_mode - 1
hopping_type - 0
ant_sel -3
inter_pkt_gap -0
pll_mode -0
rf_type - 1
rf_chain - 3
```

Burst Mode:

```shell
#./ble_transmit 71764129 250 1 38 38 0 0 0 1 10 0 0 3 0 0 1 3
```

```c
Transmit a BLE-1Mbps advertising packet with access address of 0x71764129 and packet length of 250 bytes on 247 8MHz with the following parameters.

Access_Addr - 71764129
pkt_length - 250
ble_rate - 1
rx_channel_index -38
tx_channel_index -38
scrambler_seed - 0
no_of_packets - 0
payload_type - 0
le_channel_type -1
tx_power_index - 10
tx_mode - 0
hopping_type - 0
ant_sel -3
inter_pkt_gap -0
pll_mode -0
rf_type - 1
rf_chain - 3
```

- Run the following command to stop BLE PER transmit:

```shell
#./ble_transmit 0
```

###### BLE PER Receive

- Run the following command to keep the device in BLE PER receive mode:

```shell
#./ble_receive <access_addr> <data_legth_indication> <scrambler_seed> <ble_rate> <rx_channel_index> <tx_channel_index> <le_channel_type> <hopping_type> <ant_sel> <loop_back_mode><pwrsave_options> <pll_mode> <rf_type> <rf_chain>
```

Description of each field:

|**SI No**|**Parameters**|**Description**|**Values**|
|---|---|---|---|
|1|Access Address|It is a 32-bit address in hexadecimal format|00112233|
|2|data_length_ind ication|0 – Disable(37 Bytes)<br/><br/>1 –Enable(255 Bytes)| |
|3|scrambler_seed|Initial seed to be used for whitening. It should be set to ‘0’ in order to disable whitening.| |
|4|ble_rate|1Mbps - 1 ,<br/><br/>2Mbps - 2 ,<br/><br/>Long Range(LR) - 4| |
|5|rx_channel_index|Receive channel index, as per the Bluetooth standard|0 to 39|
|6|tx_channel_index|Transmit channel index, as per the Bluetooth standard|0 to 39|
|7|le_channel_type|advertising channel – 0<br/><br/>data channel – 1| |
|8|hopping_type|no hopping -0<br/><br/>fixed hopping - 1<br/><br/>random hopping - 2| |
|9|ant_sel|onchip antenna - 2<br/><br/>u.f.l – 3| |
|10|oop_back_mode|Disable – 0 Enable – 1| |
|11|pwrsave_options|Disable – 0 Enable – 1| |
|12|pll_mode|PLL_MODE0 – 0<br/><br/>PLL_MODE1 – 1<br/><br/>PLL_MODE2 – 2| |
|13|rf_type|External RF – 0<br/><br/>Internal RF – 1| |
|14|rf_chain|WLAN_HP_CHAIN - 0<br/><br/>WLAN_LP_CHAIN - 1<br/><br/>BT_HP_CHAIN -	2<br/><br/>BT_LP_CHAIN -	3| |

**Example**

```shell
#./ble_receive 71764129 0 0 1 37 37 0 0 3 0 0 0 1 3
```

```c
Receive a BLE-1 Mbps advertising packet with 0x71764129 access address and 250byte packet length on 2478 MHz with the following parameters.

scrambler_seed : 0
hopping_type: disable
ant_sel : u.f.l
loop_back_mode : Disabled
pwrsave_options : Disabled
pll_mode : PLL_MODE0
rf_type : Internal RF
rf_chain: BT_LP_CHAIN
```

- To get the receive stats, run the following command:

```shell
#./bt_util bt_stats <file name > < Number of Pkt>
Ex: #./bt_util bt_stats aa 0
```

- The following command can be given to stop the reception.

```shell
#./ble_receive 0
```

### Tools

#### Startup Script

To load the driver, use the script start_SiWT917.sh script. This script file will help to compile the driver and bring up SiWx91x RCP module in different modes.

To use the start_SiWT917.sh script, connect SiWx91x module to the host platform and run the following command.

```c
   # ./start_SiWT917.sh <mode>
```

Different modes supported:

```c
   • STA
   • AP
   • AP_STA
   • BLE
   • STA_BLE
```

**Note:**

- This script file is compatible with platforms that support native compilation, such as Raspberry Pi and x86 platforms.
- The file "start_SiWT917.sh" is responsible for compiling the driver, if necessary, based on the selected mode.
- When using the SiWx91x STA mode or modes where STA is involved , the script will prompt the user to select the type of access point they want to connect to. Based on the user's input, the script will then ask for the access point's credentials. It is important to provide the correct SSID and password for the selected access point type. Please see the following image for guidance:  
  ![Station Mode AP Connection Settings](/wifi91xrcp-developers-guide-software-tools/2.15.0/images/automated-sta.png)
- When using the SiWx91x AP mode, the script will prompt the user to select their preferred mode. By default, the SiWT917 AP mode will use the SSID and password provided in the hostapd configuration files located in the release folder (ap_wpa.conf and ap_open.conf). To use a custom SSID and password, update the credentials in the respective configuration file before running the script. See the following image for guidance:  
  ![AP Mode - Select Preferred Security Mode](/wifi91xrcp-developers-guide-software-tools/2.15.0/images/automated-ap.png)
- If the script throws a messsage, such as “Please ensure wpa_supplicant application is present in system” or “Please ensure hostapd application is present in system” or both, then install them and place the binaries in the release directory.  
  - To install wpa_supplicant, run the following command:    
    ```c    
    # apt-get install wpa_supplicant    
    ```    
    > **Note**: For the steps to install a particular wpa_supplicant version, see the [Configure and Compile Supplicant](../wifi91xrcp-developers-guide-wifi-configuration/roaming-configuration#configure-and-compile-latest-supplicant) section.  
  - To install hostapd, run the following command.    
    ```c    
    # apt-get install hostapd    
    ```

#### Wi-Fi Tools

##### Overview

This section describes the various tools available for the Wi-Fi network protocol:

- [iw](iw) tool for configuring and retrieving the various parameters of a Wi-Fi network interface.
- [rfkill](rfkill) tool for enabling and disabling wireless devices.
- [iPerf](iperf) tool for active measurement of the maximum achievable bandwidth on IP networks.

##### Using The iw Tool

**iw** is a new nl80211 based CLI configuration utility for wireless devices. It is used to set/get various parameters of a wireless network interface. This section covers the usage of 'iw' when used with the driver. For more information, see the relevant Linux man pages. The list of supported commands via "iw" tool are listed below.

|Scan| |
|---|---|
|Description|This command is used to scan for the Access points nearby our device.|
|Default Value|-|
|Input Parameters|Interface name on which scan has to be performed|
|Output Parameter|List of APs scanned|
|Reset Required|No|
|Usage|$ iw dev < interface_name > scan|
|Example|$ iw dev wifi0 scan|

|**Connect**| |
|---|---|
|Description|This command is used to connect devices to the Access points in open mode.|
|Default Value|-|
|Input Parameters|SSID, BSSID, key_index, key of AP.|
|Output Parameter|None|
|Reset Required|No|
|Usage|Open mode: iw dev \<interface_name\> connectSSID_NAME $BSSID.|
|Example|iw dev wifi0 connect TEST_AP ec:f6:4c:a0:3f:10<br/><br/>The above command connects to TEST_AP access point in open mode|

|**Disconnect**| |
|---|---|
|Description|This command is used to disconnect our device from the connected network.|
|Default Value|-|
|Input Parameters|Interface name|
|Output Parameter|-|
|Reset Required|No|
|Usage|iw dev <interface_name> disconnect|
|Example|$ iw dev wifi0 disconnect<br/><br/>The above command disconnects our device from the connected Access point.|

|Link Status| |
|---|---|
|Description|This command is used to get the connection status of our device.|
|Default Value|-|
|Input Parameters|Interface name.|
|Output Parameter|Connection status.|
|Reset Required|No|
|Usage|iw dev <interface_name> link|
|Example|iw dev wifi0 link|

|**Interface Info**| |
|---|---|
|Description|This command is used to get information about the device .|
|Default Value|-|
|Input Parameters|Interface name.|
|Output Parameter|Interface mac address, type, operating mode etc.|
|Reset Required|No|
|Usage|iw dev <interface_name> info|
|Example|iw dev wifi0 info|

|**Station Dump**| |
|---|---|
|Description|This command is used to station statistic information such as the amount of tx/rx bytes, the last TX bitrate (including MCS rate)|
|Default Value|-|
|Input Parameters|Interface name.|
|Output Parameter|Connected Stations/AP mac address,tx bytes, rx bytes, signal level etc,. will be displayed.|
|Reset Required|No|
|Usage|iw dev <interface_name> station dump|
|Example|iw dev wifi0 station dump|

|Set Power save mode| |
|---|---|
|Description|This command is used to set power save mode on/off in station mode.|
|Default Value|-|
|Input Parameters|Interface name.|
|Output Parameter|No|
|Reset Required|No|
|Usage|iw dev <interface_name> set power_save <on | off>|
|Example|iw dev wifi0 set power_save <on | off>|

|**Get Power save mode**| |
|---|---|
|Description|This command is used to get power save mode on/off in station mode.|
|Default Value|-|
|Input Parameters|Interface name.|
|Output Parameter|Shows whether power save mode is on | off in station mode|
|Reset Required|No|
|Usage|iw dev <interface_name> get power_save|
|Example|iw dev wifi0 get power_save|

|Set Rate| |
|---|---|
|Description|This command is used to fix data rate.|
|Default Value|-|
|Input Parameters|Interface name, rate|
|Output Parameter|-|
|Reset Required|No|
|Usage|iw dev <interface_name> set bitrates legacy-<2.4|5> <legacy rate in Mbps><br/><br/>For mcs rates, in iw versions below 3.14 use:<br/><br/>iw dev <interface_name> set bitrates mcs-<2.4|5> <mcs rate in Mbps><br/><br/>In iw versions above 3.14 use:<br/><br/>iw dev <interface_name> set bitrates ht-mcs-<2.4|5> <mcs rate in Mbps><br/><br/>Above command(s) with no rate specified is used to set things to normal (auto rate).<br/><br/>Ex: iw dev <interface_name> set bitrates mcs-<2.4|5> OR iw dev <interface_name> set bitrates ht-mcs-<2.4|5><br/><br/>**Note:** 1. Driver supports only single rate to be set using above commands. Multiple rate setting is not supported.<br/><br/>2. For kernel version greater than 4.13.16 setting bitrate legacy will take only basic rates.<br/><br/>3. iw version can be obtained using below command  # iw --version|
|Example|iw dev wlan0 set bitrates legacy-2.4 12<br/><br/>iw dev wlan0 set bitrates mcs-2.4 1<br/><br/>iw dev wlan0 set bitrates ht-mcs-5 4|

|**Set country code**| |
|---|---|
|Description|This command is used to set the country code.|
|Default Value|-|
|Input Parameters|country_code|
|Output Parameter|-|
|Reset Required|-|
|Usage|iw reg set <country_code>|
|Example|iw reg set IN  (For India) , iw reg set JP (For Japan), iw reg set GE (For Germany)|

|**Get country code**| |
|---|---|
|Description|This command is used to get the country code.|
|Default Value|-|
|Input Parameters|-|
|Output Parameter|country domain|
|Reset Required|-|
|Usage|iw reg get|
|Example|output : country IN: DFS-JP (2402 - 2482 @ 40), (N/A, 20)<br/><br/>(5170 - 5250 @ 80), (N/A, 20)<br/><br/>(5250 - 5330 @ 80), (N/A, 20)<br/><br/>DFS (5735 - 5835 @ 80), (N/A, 20)|

|**Set Tx Power**| |
|---|---|
|Description|This command is used to set the Tx Power.|
|Default Value|-|
|Input Parameters|tx power value|
|Output Parameter|-|
|Reset Required|-|
|Usage|iwconfig <interface_name> txpower <NmW|NdBm|off|auto>|
|Example|iwconfig wlan0 txpower 11|

> For the list of channels allowed in the current regulatory domain, see [Wikipedia - List of WLAN channels](https://en.wikipedia.org/wiki/List_of_WLAN_channels).

##### Using the rfkill Tool

The driver has support for `rfkill` command. Before using the rfkill tool, install the rfkill package.

1. To list out the wireless interfaces in the system, run the following command:  
   ```c  
   #  rfkill list   
   ```
2. To block the SiWx917 Wi-Fi interface, run the following command:  
   ```c  
   # rfkill block <interface_number_listed_in_rfkill_list>   
   ```
3. To unblock the SiWx917 Wi-Fi interface, run the following command:  
   ```c  
   # rfkill unblock <interface_number_listed_in_rfkill_list>    
   ```

##### Measuring Wi-Fi Throughput with iPerf

You can measure Wi-Fi performance through UDP/TCP protocols by using the `iperf` application. To evaluate the throughputs in Wi-Fi client mode, connect a second PC/Laptop to the Access Point. Download and install the iperf application from [https://iperf.fr](https://iperf.fr/)  on the second PC/Laptop.

See the [SiWT917 RCP Wi-Fi Throughput Application Note](https://www.silabs.com/documents/public/application-notes/AN1446_SiWT917_RCP_Wi-Fi_Throughput.pdf) for measuring Wi-Fi throughput with `iperf`.

#### BLE Tools

##### Overview

This section describes the various tools available to use with the Bluetooth Low Energy (BLE) protocol:

- [hciconfig and hcitool](hciconfig-and-hcitool) for configuring and retrieving the parameters of a Bluetooth network interface.
- [Bluetooth Manager](bluetooth-manager) for connecting to and exchanging data with the BLE devices in your vicinity.

##### Using the hciconfig and hcitool Commands

The hcitool and hciconfig commands are used to control and configure parameters for the Bluetooth interface. The most frequently used HCI commands are explained here. For other HCI commands, see the Bluetooth specification, Volume 2, Part E, Chapter 7, from [www.bluetooth.org](http://www.bluetooth.org/).

|Reset| |
|---|---|
|Description|This command is used to issue a soft reset to the Bluetooth module|
|Default Value|-|
|Input Parameters|None|
|Output Parameter|None|
|Reset Required|No.|
|Usage|hcitool -i <hciX> cmd 0x03 0x03|

|**Read Local Version Information**| |
|---|---|
|Description|This command is used to read the local version information|
|Default Value|-|
|Input Parameters|None|
|Output Parameter|Run the `btmon` command in another terminal before running this command. So, the below parameters will be available. HCI version HCI revision LMP version Manufacturer name LMP subversion|
|Reset Required|No.|
|Usage|hcitool -i <hciX> cmd 0x04 0x01|

|**Read Local Supported Commands**| |
|---|---|
|Description|This command is used to read the local controller supported HCI commands.|
|Default Value|-|
|Input Parameters|None|
|Output Parameter|List of supported commands (64 bytes of bit field)|
|Reset Required|No.|
|Usage|hcitool -i <hciX> cmd 0x04 0x02|

|**Get Local BD Address**| |
|---|---|
|Description|This command is used to get the local BD Address|
|Default Value|-|
|Input Parameters|None|
|Output Parameter|6 Byte BD Address|
|Reset Required|No.|
|Usage|hcitool -i <hciX> cmd 0x04 0x09|

###### List of supported HCI commands

###### **For OGF  0x02** (heading level 7)

|**HCI Commands(OCF)**|**Supported**|**Comments(Macro's Defined in the source code)**|
|---|---|---|
|HCI_Hold_Mode|Yes|/* HCI link policy command OCF types */HCI_OP_HOLD_MODE|
|HCI_Sniff_Mode|Yes|HCI_OP_SNIFF_MODE|
|HCI_Exit_Sniff_Mode|Yes|HCI_OP_EXIT_SNIFF_MODE|
|HCI_QoS_Setup|Yes|HCI_OP_QOS_SETUP|
|HCI_Role_Discovery|Yes|HCI_OP_ROLE_DISCOVERY|
|HCI_Switch_Role|Yes|HCI_OP_SWITCH_ROLE|
|HCI_Read_Link_Policy_Settings|Yes|HCI_OP_READ_LINK_POLICY|
|HCI_Write_Link_Policy_Settings|Yes|HCI_OP_WRITE_LINK_POLICY|
|HCI_Read_Default_Link_Policy_Settings|Yes|HCI_OP_READ_DEF_LINK_POLICY|
|HCI_Write_Default_Link_Policy_Settings|Yes|HCI_OP_WRITE_DEF_LINK_POLICY|
|HCI_Flow_Specification|Yes|HCI_OP_FLOW_SPECIFICATION|
|HCI_Sniff_Subrating|Yes|HCI_OP_SNIFF_SUBRATING|

###### **For OGF 0x03** (heading level 7)

|**HCI Commands(OCF)**|**Supported**|**Comments(Macro's Defined in the source code)**|
|---|---|---|
|HCI_Set_Event_Mask|Yes|HCI_OP_SET_EVENT_MASK|

###### **For OGF 0x04** (heading level 7)

|**HCI Commands(OCF)**|**Supported**|**Comments(Macro's Defined in the source code)**|
|---|---|---|
|HCI_Reset|Yes|HCI_OP_RESET|
|HCI_Set_Event_Filter|Yes|HCI_OP_SET_EVENT_FLT|
|HCI_Flush|Yes|HCI_OP_FLUSH|
|HCI_Read_PIN_Type|Yes|HCI_OP_READ_PIN_TYPE|
|HCI_Write_PIN_Type|Yes|HCI_OP_WRITE_PIN_TYPE|
|HCI_Create_New_Unit_Key|Yes|HCI_OP_CREATE_NEW_UNIT_KEY|
|HCI_Read_Stored_Link_Key|Yes|HCI_OP_READ_STORED_LINK_KEY|
|HCI_Write_Stored_Link_Key|Yes|HCI_OP_WRITE_STORED_LINK_KEY|
|HCI_Delete_Stored_Link_Key|Yes|HCI_OP_DELETE_STORED_LINK_KEY|
|HCI_Read_Local_Name|Yes|HCI_OP_READ_LOCAL_NAME|
|HCI_Write_Local_Name|Yes|HCI_OP_WRITE_LOCAL_NAME|
|HCI_Read_Connection_Accept_Timeout|Yes|HCI_OP_READ_CA_TIMEOUT|
|HCI_Write_Connection_Accept_Timeout|Yes|HCI_OP_WRITE_CA_TIMEOUT|
|HCI_Read_Page_Timeout|Yes|HCI_OP_READ_PAGE_TIMEOUT|
|HCI_Write_Page_Timeout|yes|HCI_OP_WRITE_PAGE_TIMEOUT|
|HCI_Read_Scan_Enable|yes|HCI_OP_READ_SCAN_ENABLE|
|HCI_Write_Scan_Enable|yes|HCI_OP_WRITE_SCAN_ENABLE|
|HCI_Read_Page_Scan_Activity|Yes|HCI_OP_READ_PAGE_SCAN_ACTIVITY|
|HCI_Write_Page_Scan_Activity|Yes|HCI_OP_WRITE_PAGE_SCAN_ACTIVITY|
|HCI_Read_Inquiry_Scan_Activity|Yes|HCI_OP_READ_INQUIRY_SCAN_ACTIVITY|
|HCI_Write_Inquiry_Scan_Activity|Yes|HCI_OP_WRITE_INQUIRY_SCAN_ACTIVITY|
|HCI_Read_Authentication_Enable|Yes|HCI_OP_READ_AUTH_ENABLE|
|HCI_Write_Authentication_Enable|Yes|HCI_OP_WRITE_AUTH_ENABLE|
|HCI_Read_Class_of_Device|Yes|HCI_OP_READ_CLASS_OF_DEVICE|
|HCI_Write_Class_of_Device|Yes|HCI_OP_WRITE_CLASS_OF_DEVICE|
|HCI_Read_Voice_Setting|Yes|HCI_OP_READ_VOICE_SETTING|
|HCI_Write_Voice_Setting|Yes|HCI_OP_WRITE_VOICE_SETTING|
|HCI_Read_Automatic_Flush_Timeout|Yes|HCI_OP_READ_AUTO_FLUSH_TOUT|
|HCI_Write_Automatic_Flush_Timeout|Yes|HCI_OP_WRITE_AUTO_FLUSH_TOUT|
|HCI_OP_READ_NUM_BROADCAST_RETRY|NO| |
|HCI_OP_WRITE_NUM_BROADCAST_RETRY|NO| |
|HCI_Read_Hold_Mode_Activity|NO|HCI_OP_READ_HOLD_MODE_ACTIVITY → Not defined in the code|
|HCI_Write_Hold_Mode_Activity|No| |
|HCI_Read_Transmit_Power_Level|Yes|HCI_OP_READ_TX_PWR_LEVEL|
|HCI_Read_Synchronous_Flow_Control_Enable|No|HCI_OP_READ_SYNCHRONOUS_FLOW_CTRL_EN|
|HCI_Write_Synchronous_Flow_Control_Enable|No| |
|HCI_Set_Controller_To_Host_Flow_Control|No|HCI_OP_SET_CNTRLER_TO_HOST_FLOW_CTRL|
|HCI_Host_Buffer_Size|Yes|HCI_OP_HOST_BUFFER_SIZE|
|HCI_Host_Number_Of_Completed_Packets|No|HCI_OP_HOST_NUM_COMPLETED_PKTS|
|HCI_Read_Link_Supervision_Timeout|Yes|HCI_OP_READ_LINK_SUPERVISION_TOUT|
|HCI_Write_Link_Supervision_Timeout|Yes|HCI_OP_WRITE_LINK_SUPERVISION_TOUT|
|HCI_Read_Number_Of_Supported_IAC|Yes|HCI_OP_READ_NUM_SUPPORTED_IAC|
|Set_AFH_Host_Channel_Classification|Yes|HCI_OP_SET_AFH_HOST_CH_CLASSIFICATION|
|HCI_Read_Inquiry_Scan_Type|Yes|HCI_OP_READ_INQUIRY_SCAN_TYPE|
|HCI_Write_Inquiry_Scan_Type|Yes|HCI_OP_WRITE_INQUIRY_SCAN_TYPE|
|HCI_Read_Inquiry_Mode|Yes|HCI_OP_READ_INQUIRY_MODE|
|HCI_Write_Inquiry_Mode|Yes|HCI_OP_WRITE_INQUIRY_MODE|
|HCI_Read_Page_Scan_Type|Yes|HCI_OP_READ_PAGE_SCAN_TYPE|
|HCI_Write_Page_Scan_Type|Yes|HCI_OP_WRITE_PAGE_SCAN_TYPE|
|Read_AFH_Channel_Assessment_Mode|Yes|HCI_OP_READ_AFH_CH_ASSESSMENT_MODE|
|Write_AFH_Channel_Assessment_Mode|Yes|HCI_OP_WRITE_AFH_CH_ASSESSMENT_MODE|
|HCI_Read_Extended_Inquiry_Response|Yes|HCI_OP_READ_EXT_INQUIRY_RESP|
|HCI_Write_Extended_Inquiry_Response|Yes|HCI_OP_WRITE_EXT_INQUIRY_RESP|
|HCI_Refresh_Encryption_Key|yes|HCI_OP_REFRESH_ENCRYPTION_KEY|
|HCI_Read_Simple_Pairing_Mode|Yes|HCI_OP_READ_SIMPLE_PAIRING_MODE|
|HCI_Write_Simple_Pairing_Mode|Yes|HCI_OP_WRITE_SIMPLE_PAIRING_MODE|
|HCI_Read_Local_OOB_Data|Yes|HCI_OP_READ_LOCAL_OOB_DATA|
|HCI_Read_Inquiry_Response_Transmit_Power_Leve|Yes|HCI_OP_READ_INQUIRY_RESP_TX_PWR_LEVEL|
|HCI_Write_Inquiry_Transmit_Power_Level|Yes|HCI_OP_WRITE_INQUIRY_RESP_TX_PWR_LEVEL|
|HCI_Send_Keypress_Notification|Yes|HCI_OP_SEND_KEY_PRESS_NOTIFICATION|
|HCI_Read_Default_Erroneous_Data_Reporting|NO|HCI_OP_READ_DEF_ERRONEOUS_DATA_REP|
|HCI_Write_Default_Erroneous_Data_Reporting|No|HCI_OP_WRITE_DEF_ERRONEOUS_DATA_REP|
|HCI_Enhanced_Flush|Yes|HCI_OP_ENHANCED_FLUSH|
|HCI_Read_Logical_Link_Accept_Timeout|No|HCI_OP_READ_LOGICAL_LINK_ACCEPT_TOUT|
|HCI_Write_Logical_Link _Accept_Timeout|No|HCI_OP_WRITE_LOGICAL_LINK_ACCEPT_TOUT|
|HCI_Set_Event_Mask_Page_2|Yes|HCI_OP_SET_EVENT_MASK_PAGE_2|
|HCI_Read_Location_Data|No|HCI_OP_READ_LOCATION_DATA|
|HCI_Write_Location_Data|No|HCI_OP_WRITE_LOCATION_DATA|
|HCI_Read_Flow_Control_Mode| |
|HCI_Write_Flow_Control_Mode| |
|HCI_Read_Enhanced_Transmit_Power_Level|Yes|HCI_OP_READ_ENHANCED_TX_PWR_LEVEL|
|HCI_Read_Best_Effort_Flush_Timeout|No|HCI_OP_READ_BE_FLUSH_TOUT|
|HCI_Write_Best_Effort_Flush_Timeout|No|HCI_OP_WRITE_BE_FLUSH_TOUT|
|HCI_Short_Range_Mode|No|HCI_OP_SHORT_RANGE_MODE|
|HCI_Read_LE_Host_Support|No|HCI_OP_READ_LE_HOST_SUPPORT|
|HCI_Write_LE_Host_Support|No|HCI_OP_WRITE_LE_HOST_SUPPORT|
|HCI_Set_MWS_Channel_Parameters|No| |
|HCI_ Set_ External_Frame_Configuration|No| |
|HCI_Set_MWS_Transport_Layer|No| |
|HCI_Set_MWS_Scan_Frequency_Table|No| |
|HCI_Set_MWS_PATTERN_Configuration|No| |
|HCI_Set_Reserved_LT_ADDR|No| |
|HCI_Read_Local_Version_Information|No| |
|HCI_Read_Local_Supported_Commands|No| |
|HCI_Read_Local_Supported_Features|No| |
|HCI_Read_Local_Extended_Features|No| |
|HCI_Read_Buffer_Size|No| |
|HCI_Read_BD_ADDR|No| |
|HCI_Read_Data_Block_Size|No| |
|HCI_Read_Local_Supported_Codecs|No| |

###### **For OGF 0x05** (heading level 7)

|**HCI Commands(OCF)**|**Supported**|**Comments(Macro's Defined in the source code)**|
|---|---|---|
|HCI_Read_Failed_Contact_Counter|Yes|HCI_OP_READ_FAILED_CONTACT_COUNTER|
|HCI_Reset_Failed_Contact_Counter|Yes|HCI_OP_RESET_FAILED_CONTACT_COUNTER|
|HCI_Read_Link_Quality 0|Yes|HCI_OP_READ_LINK_QUALITY|
|HCI_Read_RSSI|Yes|HCI_OP_READ_RSSI|
|HCI_Read_AFH_Channel_Map|Yes|HCI_OP_READ_AFH_CH_MAP|
|HCI_Read_Clock|Yes|HCI_OP_READ_CLK|
|HCI_Read_Encryption_Key_Size|Yes|HCI_OP_READ_ENCRYPTION_KEY_SIZE|
|HCI_Read_Local_AMP_Info|No|HCI_OP_READ_LOCAL_AMP_INFO|
|HCI_Write_Local_AMP_Info|No|
|HCI_Read_Local_AMP_ASSOC|NO|
|HCI_OP_READ_LOCAL_AMP_ASSOC|
|HCI_Write_Remote_AMP_ASSOC|No|HCI_OP_WRITE_REMOTE_AMP_ASSOC|

###### **For OGF 0x06** (heading level 7)

|**HCI Commands(OCF)**|**Supported**|**Comments(Macro's Defined in the source code)**|
|---|---|---|
|HCI_Read_Loopback_Mode|No| |
|HCI_Write_Loopback_Mode|No| |
|HCI_Enable_Device_Under_Test_Mode|Yes|HCI_OP_ENABLE_DEV_UNDER_TEST_MODE|
|HCI_Write_Simple_Pairing_Debug_Mode|Yes|HCI_OP_WRITE_PAIRING_DBG_MODE|
|HCI_Enable_AMP_Receiver_Reports|No| |
|HCI_AMP_Test_End|No| |
|HCI_AMP_Test|No| |
|HCI_Write_Secure_Connections_Test_Mode|No| |

##### Using the Bluetooth Manager

The steps given below explain the usage of the Bluetooth Manager in Fedora Core 18 on an x86 platform for pairing Bluetooth devices and transferring files.

1. Once the Bluetooth modules have been installed as mentioned in section [Configuring the Driver in BLE Mode](../wifi91xrcp-developers-guide-operating-modes/ble-mode) **,** hit the "Windows" button on the keyboard. You will see Bluetooth symbol at the bottom-right corner of the screen, as shown in the given below figure.  
   ![Bluetooth Symbol at bottom-right](/wifi91xrcp-developers-guide-ble-tools/2.15.0/images/image8.png)
2. This will open the Bluetooth Manager as shown in the figure below:  
   ![Bluetooth Manager Window](/wifi91xrcp-developers-guide-ble-tools/2.15.0/images/image9.png)
3. Click on **Search** to start inquiry.  
   ![Search for devices](/wifi91xrcp-developers-guide-ble-tools/2.15.0/images/image10.png)
4. Select a particular device, like your smartphone, right click and select **Pair** tab to pair with that device.  
   ![Pair a device](/wifi91xrcp-developers-guide-ble-tools/2.15.0/images/image11.png)
5. After successfully pairing with the device, right-click on the device and select **"Send a file"** button to send data to the device. You will be presented with a dialog box to select the file that you wish to send.  
   ![Send a file](/wifi91xrcp-developers-guide-ble-tools/2.15.0/images/image12.png)

### Configuration

#### Software Configuration

##### Overview

This section describes the various software configurations supported by the SiWT917 RCP Driver for Radio Co-processor (RCP) mode:

- [Kernel Configuration](kernel-configuration)
- [Common Software Parameters](common-software-parameters) to enable, disable, or configure various features of the driver.
- [Enable SDIO Stack](enable-sdio-stack)
- [Debug Prints](debug-prints) enabling or disabling

##### Configuring the Kernel

To ensure that the driver software works on every platform, the kernel can be compiled with mandatory components/options to enable various features of the SiWx91x RCP Driver :

- [Enabling the SDIO Stack](enable-sdio-stack)
- [Enabling Wireless Extension Tools](../wifi91xrcp-developers-guide-wifi-configuration/enable-wireless-extension-tools)
- [Enabling the Bluetooth Stack](../wifi91xrcp-developers-guide-ble-configuration/enable-bluetooth-stack)

The steps used for Kernel Compilation are as follows. Super user permissions are needed to make these changes:

1. Navigate to the kernel source folder.
2. Execute the **"make"** command.
3. Execute the "**make modules**" command.
4. Execute the **"make modules_install"** command.
5. Execute the **"make install"** command. This ensures that the customized kernel is installed, and the boot loader is updated appropriately.
6. Reboot the system to boot up with the customized kernel.

##### Configuring Common Software Parameters

The following sections describe common software configuration parameters that enable/disable or configure various features of the SiWT917 RCP Driver.

> **Note**: The following `insmod` command may be used to configure multiple parameters at the same time. Note that this only applies to the parameters below that are configuring using `insmod`.
> 
> Replace `module_param` with the module parameter to be configured and <value> with the corresponding value that needs to be assigned.
> Module parameters in this section are grouped according to the corresponding feature.
> 
> **insmod rsi_91x.ko [module_param = <value>], [module_param = <value>], ... , [module_param = <value>]**

###### Power Save Features

1. **insmod rsi_91x.ko lp_handshake_mode = < value >** Low power mode handshake type selection.  
   - 0 - No handshake Mode (Default)  
   - 1 - GPIO Handshake Mode
2. **insmod rsi_91x.ko default_deep_sleep_enable = < value >** : Enable/disable deep sleep.  
   - 0 - Disable deep sleep (Default)  
   - 1 - Enable deep sleep

###### Developer Mode Configuration Parameters

1. **insmod rsi_91x.ko power_save_opt = < value >**: Module parameter to configure Power Save options.  
   - 0 - Disable Duty Cycling & Undestined Packet Drop  
   - 1 - Enable Duty Cycling  
   - 2 - Enable Undestined Packet Drop  
   - 3 - Enable Duty Cycling & Undestined Packet Drop (Default)
2. **insmod rsi_91x.ko standby_assoc_chain_sel = < value >** : LP/HP Chain Selection in standby associated mode  
   - 0 - HP Chain Enabled  
   - 1 - LP Chain Enabled(Default)
3. **insmod rsi_91x.ko feature_bitmap_9116 = < value >** :  
   - For 3.3V, set FEATURE_BITMAP_9116=0  
   - For 1.8V, set FEATURE_BITMAP_9116=2  
   - For 3.3V and 5 Mhz bandwidth, set FEATURE_BITMAP_9116=32 (For testing purposes only)  
   Default value is 0.
4. **insmod rsi_91x.ko anchor_point_gap = < value >**  
   Default value is 1.
5. **insmod rsi_91x.ko sleep_clk_source_sel = < value >**: Sleep clock source selection has the following possible values with each representing a different source.  
   - 0 - Use RC clock as sleep clock  
   - 1 - Use 32 KHz clock from external XTAL OSCILLATOR  
   - 2 - Use 32 KHz bypass clock on UULP_GPIO_3  
   - 3 - Use 32 KHz bypass clock on UULP_GPIO_4  
   Default value is 0.
6. **insmod rsi_91x.ko rsi_91x.ko sleep_ind_gpio_sel = < value >** : sleep indication from device to host.  
   - 0 - UULP_GPIO_3  
   - 1 - UULP_GPIO_0  
   Default value is 0.
7. **insmod rsi_91x.ko host_intf_on_demand = < value >** : Host Interface on Demand Feature has the following possible values.  
   - 0 - Disable Host Interface on Demand Feature  
   - 1 - Enable Host Interface on Demand Feature  
   Default value for Host Interface on Demand Feature Options is 0, which indicates that Host Interface on Demand Feature is disabled.
8. **insmod rsi_91x.ko ext_opt = < value >** : Extended Options

<table>
  <thead>
<tr>
<th colspan="1" rowspan="1"><div>ext_opt</div></th>
<th colspan="1" rowspan="1"><div>ANT_SEL_0(VC3)</div></th>
<th colspan="1" rowspan="1"><div>ANT_SEL_1(VC2)</div></th>
<th colspan="1" rowspan="1"><div>ANT_SEL_2(VC1)</div></th>
</tr>
  </thead>
  <tbody>
<tr>
<td colspan="1" rowspan="1"><div>0</div></td>
<td colspan="3" rowspan="1"><div>Reserved</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>1</div></td>
<td colspan="1" rowspan="1"><div>ULP GPIO 4</div></td>
<td colspan="1" rowspan="1"><div>ULP GPIO 5</div></td>
<td colspan="1" rowspan="1"><div>ULP GPIO 0</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>2</div></td>
<td colspan="3" rowspan="1"><div>Virtual Switch</div></td>
</tr>
<tr>
<td colspan="1" rowspan="1"><div>3</div></td>
<td colspan="3" rowspan="1"><div>Reserved</div></td>
</tr>
  </tbody>
</table>

Default value for Extended options is 0.

1. **insmod rsi_91x.ko pta_config = < value >** : PTA 3-Wire Co-Existence has following options.  
   - 0 - PTA_CONFIG_DISABLED(default)  
   - 1 - PTA_CONFIG_1 Aggressive Grant  
   - 2 - PTA_CONFIG_2 Protect Response Tx  
   - 3 - PTA_CONFIG_3 Protect both Tx and Response Tx  
   Default value is 0.

###### Miscellaneous Features

1. **insmod rsi_91x.ko driver_mode_value = < value >**: Enable sniffer mode support. Default value is 1.  
   - 1 - End to end mode  
   - 7 - Sniffer mode
2. **insmod rsi_sdio.ko sdio_clock = < value >**: Set the SDIO clock while while installing the driver (only for SDIO interface). The range is 1- 50 MHz.  
   Default value is 50 MHz.  
   > **Note:** This parameter can only be used with the `rsi_sdio.ko` kernel module.
3. **insmod rsi_91x.ko ulp_gpio_read = < value >**: In GPIO handshake, this param configures Host GPIO read pin. It will vary from platform to platform.  
   Default value is 0xFF.
4. **insmod rsi_91x.ko ulp_gpio_write = < value >**: In GPIO handshake, this param configures Host GPIO write pin. It will vary from platform to platform.  
   Default value is 0xFF.

> **Note**:
> 
> See the [Common Wi-Fi Parameters](../wifi91xrcp-developers-guide-wifi-configuration/common-wifi-parameters) section for Configuring Common Wi-Fi Parameters.
> 
> See the [Common BLE Parameters](../wifi91xrcp-developers-guide-ble-configuration/common-ble-parameters) section for Configuring Common BLE Parameters.

##### Enabling the SDIO Stack

If SDIO is the interface to the Host processor, ensure that the SDIO stack related modules are compiled in the kernel. If the SDIO stack modules are not present, follow the steps below to enable SDIO support in the kernel.

1. Navigate to the Linux kernel source folder. This is usually in /usr/src/kernels/Linux-< kernel-version >.
2. Execute the **'make menuconfig'** command to open the Kernel Configuration menu.  
   ![Kernel Configuration Menu](/wifi91xrcp-developers-guide-software-configuration/2.15.0/images/image2.png)
3. Scroll down to the **"Device Drivers --->"** option and press Enter.
4. In the new menu, scroll down to the **"MMC/SD/SDIO card support --->"** option and press **'M'** to modularize the **"MMC/SD/SDIO card support"** feature and hit Enter.  
   ![MMC/SD/SDIO card support menu](/wifi91xrcp-developers-guide-software-configuration/2.15.0/images/image3.png)
5. In the new menu, press **'M'** to modularize the following options  
   ```c  
   MMC block device driver  
   Secure Digital Host Controller Interface support  
   SDHCI support on PCI bus  
   ```  
   ![Modularize MMC/SD/SDIO card support](/wifi91xrcp-developers-guide-software-configuration/2.15.0/images/image4.png)
6. Press the Tab key to select Exit and press Enter. Repeat this till you are asked whether you want to save the configuration.
7. Select "Yes" and press Enter. If the above options are already selected, the menuconfig screen will exit immediately.

See the [Kernel Configuration](kernel-configuration) section for the commands to compile the kernel.

##### Debug Prints

You can enable debug prints (observed in dmesg) in the driver in the following two ways:

1. By assigning module param while installing the driver.
2. Through debugfs after installing the driver.

Both are explained below.

1. Assigning module param:  
   ```c  
   # insmod rsi_91x.ko rsi_zone_enabled=0x601   
   ```  
   In this case, `rsi_zone_enabled` is a bitmap value which is explained below.
2. Through debugfs:  
   ```c  
   # echo <value> > /sys/kernel/debug/phy<X>/debug_zone  
   ```

`rsi_zone_enabled` and `\<value\>` are bitmap values as explained below.

|BIT|ZONE|
|---|---|
|BIT(0)|ERROR ZONE|
|BIT(1)|INFO ZONE|
|BIT(2)|INIT ZONE|
|BIT(3)|MGMT TX ZONE|
|BIT(4)|MGMT RX ZONE|
|BIT(5)|DATA TX ZONE|
|BIT(6)|DATA RX ZONE|
|BIT(7)|FSM ZONE|
|BIT(8)|ISR ZONE|
|BIT(9)|INT MGMT ZONE|
|BIT(10)|MGMT DEBUG ZONE|

For example, to enable both INFO ZONE and ERROR ZONE, set BIT(1) and BIT(0) to arrive at a bitmap value of `0x03`.

#### Wi-Fi Configuration

##### Overview

This section describes the various Wi-Fi protocol configuration settings supported by the SiWT917 RCP Driver for Radio Co-processor (RCP) mode:

- [Common Wi-Fi Parameters](common-wifi-parameters) to enable, disable, or configure various Wi-Fi features.
- [Access Point Parameters](ap-parameters) to configure access point settings.
- [Regulatory Region Mapping](regulatory-region-mapping) to map country codes to regulatory region codes.
- [Enabling Wireless Extension Tools](enable-wireless-extension-tools) in the Linux kernel configuration file.
- [Region-based Maximum Power](region-based-maximum-power)
- [Roaming](roaming-configuration) configuration using the WPA supplicant tool.
- [WLAN Gain Table](wlan-gain-table) to program region-based maximum power values for the Wi-Fi network interface.
- [802.11ax ER-SU](802-11-ax-er-su) to configure Extended Rates SU (ER-SU) support.
- [802.11ax Wi-Fi Data Rate](802-11-ax-wifi-data-rate) to configure the 802.11ax Wi-Fi data rate.
- [802.11ax GI and LTF](802-11-ax-gi-and-ltf)

##### Configuring Common Wi-Fi Parameters

The following sections describe common Wi-Fi configuration parameters that enable/disable or configure various Wi-Fi features of the SiWT917 RCP Driver.

> **Note**: The following `insmod` command may be used to configure multiple parameters at the same time. Note that this only applies to the parameters below that are configuring using `insmod`.
> 
> Replace `module_param` with the module parameter to be configured and <value> with the corresponding value that needs to be assigned.
> Module parameters in this section are grouped according to the corresponding feature.
> 
> **insmod rsi_91x.ko [module_param = <value>], [module_param = <value>], ... , [module_param = <value>]**

###### Power Save Features

1. **insmod rsi_91x.ko enabled_uapsd = < value >** : Enable the U-APSD power save mode and set the relevant parameters. If the Access Point does not support U-APSD power save, the module tries to mimic this mode.  
   - 0 - Disable U-APSD mode  
   - 1 - Enable U-APSD mode  
   Default value of enabled_uapsd = 0.
2. **insmod rsi_91x.ko max_sp_len = < value >** : U-APSD Service Period Length- This field indicates number of packets delivered by AP to station after receiving one trigger frame. This field value ranges between 0-3 as described below.  
   - 0-All buffered packets will be delivered. (Default)  
   - 1-Two buffered packets will be delivered.  
   - 2-Four buffered packets will be delivered.  
   - 3-Six buffered packets will be delivered.  
   > **Note**: This parameter is valid only when **enabled_uapsd** is set.

###### Miscelleneous Features

1. **insmod rsi_91x.ko lmac_bcon_drop = < value >** : LMAC beacon drop feature options.  
   - 0 - Disable LMAC BEACON DROP Feature  
   - 1 - Enable LMAC BEACON DROP Feature  
   Default value for LMAC BEACON DROP Feature option is 1 - Enable LMAC BEACON DROP Feature.
2. **Hardware Beacon Miss Threshold**  
   - Default Value: 20  
   - Input Parameters: Non-zero value  
   - Output Parameter: None  
   - Reset Required: No  
   - Command: **./onebox_util rpine0 hw_bmiss_threshold < value >**  
   - Example: `./onebox_util rpine0 hw_bmiss_threshold 30`
3. **Keep Alive Period**  
   - Default Value: 90  
   - Input Parameters: Non-zero value  
   - Output Parameter: None  
   - Reset Required: No  
   - Command: **./onebox_util rpine0 keep_alive < value >**  
   - Example: `./onebox_util rpine0 keep_alive 100`
4. **Get RSSI**: Run the following command to retrieve the current RSSI from the LMAC.  
   - Default Value: None  
   - Input Parameters: None  
   - Output Parameter: None  
   - Reset Required: No  
   - Command: **./onebox_util rpine0 get_rssi**
5. **Broadcast Filtering**  
   - Default Value: None  
   - Input Parameters:    
     - beacon_drop_threshold - value in    
     - msec filter_bcast_in_tim - 1 to enable, 0 to disable    
     - filter_bcast_tim_till_next_cmd - 1 to Enable, 0 to disable  
   - Output Parameter: None  
   - Reset Required: No  
   - Command: **./onebox_util rpine0 < filter_bcast beacon_drop_threshold > < filter_bcast_in_tim > < filter_bcast_tim_till_next_cmd >**  
   - Example: `./onebox_util rpine0 filter_bcast 5000 1 0`

> **Note**:
> 
> See the [Common Software Parameters](../wifi91xrcp-developers-guide-ble-configuration/common-ble-parameters) section for Configuring Common Software Parameters.
> 
> See the [Common BLE Parameters](../wifi91xrcp-developers-guide-ble-configuration/common-ble-parameters) section for Configuring Common BLE Parameters.

##### Configuring Wi-Fi Access Point Parameters

The following sections describe access point settings that may be updated in the `hostapd.conf` file.

###### Common Access Point Parameters

- **Hidden ssid**: To disable SSID broadcast in beacons for the AP, use the following configuration in the hostapd configuration file.  
  ```c  
   ignore_broadcast_ssid=0   
  ```
- **DTIM Interval**: To set dtim interval in beacons for AP using hostapd, use the following configuratuon in the hostapd configuration file.  
  ```c  
   dtim_period=5  
  ```
- **SHORT GI**: To enable Short GI using hostapd, use the following configuratuon in the hostapd configuration file.  
  ```c  
   ht_capab=[SHORT-GI-20]   
  ```
- **Beacon Interval**: To set beacon interval for  AP using hostapd, use the following configuratuon in the hostapd configuration file.  
  ```c  
   beacon_int=200  
  ```  
  > **Note:** Range of Beacon interval value is 56 ms to 1000 ms.

###### Access Control List Parameters

1. Use the following configuration in the hostapd configuration file. **Enable macaddr_acl** according to your choice  
   ```c  
   macaddr_acl = 0/1/2  
   ```

- For macaddr_acl = 0  
  ```c  
   deny_mac_file = /etc/hostapd.deny  
  ```
- For macaddr_acl = 1  
  ```c  
   accept_mac_file = /etc/hostapd.accept   
  ```
- For macaddr_acl = 2  
  - It will use external RADIUS server.

Follow the steps in [Wi-Fi AP Mode](../wifi91xrcp-developers-guide-operating-modes/wifi-ap-mode) section.

###### U-APSD Advertisements

Use the following configuration in hostapd configuration file.

```c
   uapsd_advertisement_enabled = 1/0
```

- 1 - Enable U-APSD
- 0 - Disable U-APSD

###### AP Mode Keep Alive Time

The following configuration in the hostapd configuration file is useful in configuring AP keep alive time, after which AP sends a QoS null to confirm if client (STA)  is still connected.

```c
 ap_max_inactivity = 300 
```

If ap_max_inactivity is not enabled, the value is assigned to be 300 s by default. You can configure the time, as needed.

###### Country IE

Use the following configuration in the hostapd file to set the regulatory country code and include it in the beacon.

```c
country_code=US
ieee80211d=1
```

`country_code` is used to set the regulatory domain. It should be set to indicate the country in which the device is operating. For more country codes, see the [Wireless Tools](../wifi91xrcp-developers-guide-wifi-tools/iw#using-the-iw-tool) section.

`ieee80211d` is enabled to advertise the country_code. If not enabled, the default value is 0.

##### Regulatory Region Mapping

Mapping of country code to regulatory region code.

|Sr.No|Country|Country code|Region code|
|---|---|---|---|
|1|Australia|AU|ETSI|
|2|Austria|AT|ETSI|
|3|Belgium|BE|ETSI|
|4|Brazil|BR|WORLD|
|5|Canada|CA|FCC|
|6|Chile|CL|WORLD|
|7|China|CN|WORLD|
|8|Colombia|CO|FCC|
|9|Czech Republic|CZ|ETSI|
|10|Denmark|DK|ETSI|
|11|Finland|FI|ETSI|
|12|France|FR|ETSI|
|13|Germany|DE|ETSI|
|14|Hong Kong|HK|WORLD|
|15|India|IN|WORLD|
|16|Indonesia|ID|WORLD|
|17|Ireland|IE|ETSI|
|18|Israel|IL|ETSI|
|19|Italy|IT|ETSI|
|20|Japan|JP|TELEC|
|21|Republic of Korea|KR|WORLD|
|22|Luxembourg|LU|ETSI|
|23|Malaysia|MY|WORLD|
|24|Mexico|MX|FCC|
|25|Morocco|MA|WORLD|
|26|Netherlands|NL|ETSI|

If there are multiple PHYs, or several instances of CFG80211 used by different modules, run the following commands to determine the correct PHY.

$  cat /sys/class/ieee80211/

By running the command below, you will get a list of all PHYs that are currently active.

$ cat /sys/class/ieee80211/phyX/macaddress

where 'X' is the number of the phy's which are obtained from the previous command.
The module MAC address (xx:xx:xx:xx:xx:xx) has to be used in the field 'macaddress'.
Generic iw commands listed below are also supported.

See the man page of the utility for more information about their usage.

```c
   iw phy <phyname> info
   iw dev <devname> del
   iw reg get
   iw reg set <ISO/IEC 3166-1 alpha2
   iw dev <devname> scan dump [-u]
   iw phy <phyname> set name <new name>
```

The commands that are supported only in the Access Point mode are as follows:

```c
   iw dev <devname> set channel <channel> [HT20]
   iw dev <devname> set freq <freq> [HT20]
   iw dev <devname> station del <MAC address>
   iw dev <devname> station get <MAC address> 
```

##### Enabling Wireless Extension Tools

Wireless Extension tools, such as **'iwconfig'** and **'iwpriv'** are required for configuring the driver. Make sure that the wireless extensions are enabled in the Linux kernel configuration file.

Enable these options in the kernel configuration file, re-compile the kernel, and cross compile the driver.

```c
   CONFIG_WIRELESS
   CONFIG_WIRELESS_EXT
   CONFIG_WEXT_PRIV
   CONFIG_WEXT_SPY
   CONFIG_WEXT_PROC
   CONFIG_WEXT_CORE
   CONFIG_HOSTAP
```

See the [Kernel Configuration](../wifi91xrcp-developers-guide-software-configuration/kernel-configuration) section for the commands to compile the kernel.

##### Region-based Maximum Power

The firmware internally maintains two tables for maximum power: worldwide table and region-based table. The worldwide table is populated by the firmware with maximum power values that the chip can transmit that meets target specifications like EVM. The region-based table has default gain value set.

1. When certifying with user antenna, Region has to be set to Worldwide and sweep the power from 0 to 21 dBm. Arrive at max power level that is passing certification especially band-edge.
2. These FCC/ETSI/TELEC/KCC Max power level should be loaded in end-to-end mode via WLAN User Gain table.  This has to be called done every boot-up since this information is not saved inside flash. Region-based user gain table sent by application is copied onto region-based table.  SoC uses this table in FCC/ETSI/TELEC/KCC to limit power and not to violate allowed limits.
3. For Worldwide region, the firmware uses Worldwide table for Tx.  For other regions(FCC/ETSI/TELEC/KCC), Firmware uses min value out of Worldwide & Region based table for Tx.  Also, there will be part to part variation across chips and offsets are estimated during manufacturing flow which will be applied as correction factor during normal mode of operation.
4. Users who have FCC/ETSI/TELEC/KCC certifications on their own antenna, have to use this frame. All other users should ignore this frame.  Inappropriate use of this frame may result in violation of FCC/ETSI/TELEC/KCC or any certifications and Silicon labs is not liable for that.

See the [WLAN Gain Table](../wifi91xrcp-developers-guide-wifi-configuration/wlan-gain-table) section for steps to program region-based maximum power of the WLAN device

See the [BLE Gain Table](../wifi91xrcp-developers-guide-ble-configuration/ble-gain-table) section for steps to program the region-based maximum power of the BLE device.

##### Configuring and Compiling the Latest Supplicant for Roaming

###### Configure and Compile Latest Supplicant

Download the supplicant from [wpa_supplicant](https://w1.fi/wpa_supplicant/)

Extract the supplicant using the following command.

```c
##### tar xvf wpa_supplicant-2.6.tar.gz

##### cd wpa_supplicant-2.6/wpa_supplicant

##### cp defconfig .config 
```

Enable the following parameters in the supplicant configuration file (.config) for roaming.

```c
   CONFIG_DRIVER_NL80211=y 
   CONFIG_LIBNL20=y
   CONFIG_LIBNL32=y
```

Save the configuration file and exit.

Compile the supplicant using "make" command in the following path.

```c
   # cd wpa_supplicant-2.6/wpa_supplicant
   
   # make clean
   
   # make 
```

After successful compilation, the supplicant executable will be found in the same path. Copy the supplicant executable to the driver release folder.

```c
   # cp wpa_supplicant SIWT917.w.x.y.z/release.
```

###### Roaming

###### Configure and Compile Supplicant for Roaming (heading level 7)

Follow the steps provided in the [Configure and Compile latest Supplicant](#configure-and-compile-latest-supplicant) section.

Enable the following parameters in the supplicant configuration file (.config file) for roaming.

```c
   ```
   CONFIG_BGSCAN_SIMPLE=y
   NL80211_CMD_ROAM=y
   CONFIG_BGSCAN=y 
   ```
```

###### Configure Connection Quality Monitoring (CQM) RSSI and Hysteresis using iw Command (heading level 7)

For more information about the iw tool, see the [Wireless Tools](../wifi91xrcp-developers-guide-wifi-tools/iw#using-the-iw-tool) section.

```c
   # iw dev <devname> cqm rssi <threshold|off> [<hysteresis>] 
   
   Set the connection quality monitor RSSI threshold. 
   
   
   Example: 
   # iw dev wlan0 cqm rssi -45 4 
```

For more information about the background scan and set parameters configuration, see the [Background Scan & Roaming](../wifi91xrcp-developers-guide-wifi-features/roaming-and-background-scan#roaming-and-background-scan) section.

###### Installing Netlink Libraries

libnl CFlags should be enabled with CONFIG_LIBNL32=y in supplicant and hostpad .config file [The above configuration settings should be set to "y" in case NL80211 is used].

If libnl libraries are not installed in the platform, follow any of the two methods given below.

1. Run the following command to install the required libnl libraries through yum/dnf/apt-get/:  
   ```c  
   # yum install libnl*  
   ```
2. Alternately, if you are unable to install libnl libraries using above method, follow the steps below where we download libnl source package and compile.  
   1. Create a directory in the location where Tool chain and BSP are present.    
      ```c    
      # mkdir build     
      ```  
   2. Download the libnl 3.2.xx.tar.gz[Referring 3.2.27.tar.gz as an example here ] library and extract it in the build directory.    
      ```c    
       # cd build    
       # tar xvf 3.2.27.tar.gz    
      ```  
   3. Configure the libnl library for target platfrom.    
      ```c    
        # CC=/path to the toochain/bin/arm-linux-gnueabihf-gcc    
        # ./configure --host=arm-linux-gnueabihf -prefix=<complete path to build directory>    
      ```    
      In this case, headers will be installed in ${prefix}/include/libnl3.  
   4. Make and install the libraries in the destination directory or else they will be installed in /usr/local/lib and /usr/local/include/libnl folders of host machine by default.    
      Follow the example given below:    
      ```c    
        # make DESTDIR=$(arm-cortex_a8-linux-gnueabihf-gcc -print -/<path to build directory>/build/)    
            
        # make install     
      ```  
   5. Exporting the path for build directory in the command line or add these flags in the supplicant and hostapd config files under CONFIG_DRIVER_NL80211= y variable.    
      ```c    
       # export LDFLAGS='-L/<path to build directory>/lib/libnl'     
      ```    
      OR  
   6. Add these flags in the supplicant and hostapd .config files under CONFIG_DRIVER_NL80211= y variable.    
      ```c    
       CFLAGS += -I/<path to build directory>/include/libnl3    
       Ex: LIBS += -L/<path to build directory>/lib/libnl    
       LIBS : Contains a list of additional libraries to pass to the linker command.     
      ```

##### WLAN Gain Table

Follow the steps below to program the region-based maximum power for the WLAN device.

See the [Region-based Maximum Power](../wifi91xrcp-developers-guide-wifi-configuration/region-based-maximum-power#region-based-maximum-power) section for more details.

1. Compile and insert the driver, as described in the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) and [Installing the Driver](../wifi91xrcp-getting-started/#installing-the-driver) sections.
2. Navigate to the rsi/release folder.
3. Copy the contents of appropriate gain tables based on the antenna to wlan_gain_table.txt in the release folder.
4. Run the following commands:  
   ```c  
   #./onebox_util rpine0 update_wlan_gain_table  
   ```  
   With the above commands, gain tables programming will start and a successful programming should show below output in dmesg logs.  
   ```c  
     ******************Successfully completed programming n gain tables*****************   
   ```  
   In this case, 'n' is the number of structures given in wlan_gain_table.txt file.
5. The following is the reference **Gain table structure** format while updating the file.  
   ```c  
   //!************************************************************  
   //! INSTRUCTIONS SHOULD BE FOLLOWED TO EDIT BELOW GAIN TABLES:  
     
   //!************************************************************  
     
   //! 1. Each value should be seperated by ',' and space characters.  
     
   //! 2. Multi-line comments not supported. (e.g. /*comment*/)  
     
   //! 3. A space before comment is needed, for in-line comments. (e.g. < Data > // < Comment >)  
     
   //! 4. Hexa-decimal numbers not supported.  
     
   //! 5. No space between value and ',' character.  
     
   //! 6. Table with size more than 128 bytes is not supported.  
     
   //! 7. Supported table names and their maximum supported size are  
     
   //!     For 2 GHz and 20 MHz ---  
   _RS9116_HP_MODE_REGION_BASED_RATE_VS_MAXPOWER_SINGLE_BAND_NONHPM  MAX_LENGTH = 128  
     
   //!    NOTE: No support for other table names.  
     
   //! 8. Gain table Format:  
     
   //!  
     
          //!    <TABLE NAME>[] = { //<COMMENTS if any>  
          //!    <NO.of Regions>,  
          //!        <REGION NAME 1>, <NO.OF CHANNELS IN THIS REGION>,  
          //!            <CHANNEL NUMBER 1>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>, <MAX POWER FOR 11ax RATE>,   
          //!            <CHANNEL NUMBER 2>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>,  <MAX POWER FOR 11ax RATE>,  
          //!            .  
          //!            .  
          //!            <CHANNEL NUMBER m-1>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>, <MAX POWER FOR 11ax RATE>,  
          //!            <CHANNEL NUMBER m>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>, <MAX POWER FOR 11ax RATE>,  
          //!        <REGION NAME 2>, <NO.OF CHANNELS IN THIS REGION>,  
          //!            <CHANNEL NUMBER 1>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>, <MAX POWER FOR 11ax RATE>,  
          //!            <CHANNEL NUMBER 2>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>, <MAX POWER FOR 11ax RATE>,  
          //!            .  
          //!            .  
          //!            <CHANNEL NUMBER m-1>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>, <MAX POWER FOR 11ax RATE>,   
          //!            <CHANNEL NUMBER m>, <MAX POWER FOR b RATE>, <MAX POWER FOR g RATE>, <MAX POWER FOR n RATE>, <MAX POWER FOR 11ax RATE>,   
          //!        <REGION NAME 3>, <NO.OF CHANNELS IN THIS REGION>,  
          //!        .  
          //!        .  
          //!        <REGION NAME y>, <NO.OF CHANNELS IN THIS REGION>,  
          //!    }; //<COMMENTS if any>  
          //! 9. Supported Region names:  
          //!     FCC, ETSI, TELEC, KCC  
          //!  
   ```

**Note:**

- The maximum size for the Wi-Fi Gain table is 128 bytes.
- In each entry, list 2× the max power value desired (for example, for 17.5 dB Tx power, input 35). Consider the desired power value in steps of 0.5 dB.
- If the max. TX power is the same for all the channels, then use 17 (0x11) as the number of channels and specify a single channel entry with 255 as channel ID.
- If the max TX power is NOT the same for all channels, then indicate the number of channels and specify the TX power values for all the channels one by one.
- For TELEC, there is also a third gain table format: When 0x2n is used as the number of channels, then specify n channel entries, where  
  each entry sets the TX power limit for all channels that are higher than the channel ID specified in the previous entry (or from channel 1 for the first entry) and lower or equal to the specified channel ID. For example, if 4 channel entries are defined with channel IDs 2, 10, 13 and 14  then, the first entry sets the limits for Wi-Fi channel 1-2. The second entry sets the limits for Wi-Fi channel 3-10, and the third entry sets the limits for Wi-Fi channel 13 and the fourth entry sets the limits for Wi-Fi channel 14.

**Example Wi-Fi Gain Table Structure:**

```c
   // "*********Silicon SiWx91x Sample Gain Table Structure*********"

          _RS9116_HP_MODE_REGION_BASED_RATE_VS_MAXPOWER_SINGLE_BAND_NONHPM[128] = {
          4,//NUM_OF_REGIONS
          FCC, 0xB,//NUM_OF_CHANNELS
          //rate,  11b, 11g, 11n, 11ax
            1,      33,  24,  21,  20,
            2,      34,  28,  28,  24,
            3,      40,  30,  32,  30,
            4,      40,  33,  36,  31,
            5,      40,  35,  36,  32,
            6,      40,  35,  36,  31,
            7,      40,  34,  36,  30,
            8,      38,  32,  36,  32,
            9,      38,  34,  34,  28,
            10,     34,  30,  30,  22,
            11,     34,  24,  22,  20,
          ETSI,0x11,
            255,    36,  36,  36,  24,
          TELEC,0x24,
            2,      34,  28,  32,  24,
            10,     34,  36,  36,  24,
            13,     34,  26,  24,  24,
            14,     36,   0,   0,   0,
          KCC, 0x11,
            255,    36,  36,  36,  36,
          };
```

The above Wi-Fi Gain Table applies the following max TX power limitations:

- FCC:  
  - 802.11b: +16.5…+20 dBm depending on channel  
  - 802.11g/n/ax: +10…+18 dBm depending on channel
- ETSI:  
  - 802.11b/g/n: +18 dBm  
  - 802.11ax: +12 dBm
- MIC:  
  - Channel 1-2: +12...+17 dBm (depending on Wi-Fi standard)  
  - Channel 3-10: +12...+18 dBm  
  - Channel 11-13: +12...+17 dBm (depending on Wi-Fi standard)  
  - Channel 14: Only 802.11b supported with +18 dBm max TX power
- KCC:  
  - +18 dBm (for 802.11b/g/n/ax and all channels)

##### 802.11ax ER-SU (Extended Rates SU) Support

To enable ER-SU (Extended Rates SU) support, use module parameters and debugfs. Accordingly, auto-rate table will be changed, as shown below.

|**config_er_su Value**|**Description**|**Auto Rate Table Change**|
|---|---|---|
|0|Don't use ER-SU rates even though AP supports ER-SU transmissions|No change|
|1|Use ER-SU rates along with other non-ER SU rates if AP supports|Add ER-SU rate along with non ER-SU rates|
|2|Use only ER-SU rates in auto rate if AP supports|Add only ER-SU rate|

> **Note:**
> 
> - Auto rate table should be updated to firmware on dynamic change from the user or from AP.
> - Fixed rate should also be configured based on config_er_su.
> - config_er_su=2 uses ER-SU rate and limits ER-SU rate to mcs2.
> - config_er_su=1 still uses non ER-SU rates.

###### Enabling ER-SU PPDU Transmission Support

The driver can enable ER-SU PPDU transmission support through module param and update it dynamically through debugfs. Follow the steps below to enable ER-SU.

1. Compile the driver as described in the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) section.  
   ```c  
   #make clean;make   
   ```
2. Navigate to the release folder and run the following commands to insert the driver.  
   ```c  
   # cd release  
   # insmod rsi_91x.ko driver_mode_value=1 rsi_zone_enabled=0x601 config_er_su=1/2  
   # insmod rsi_sdio.ko  
   ```
3. To connect to the third access point (AP), run the following command:  
   ```c  
   # wpa_supplicant -i <interface_name> -D nl80211 -c <sta_settings.conf > -ddddt > log1 &  
   ```  
   See the [Configure Station using WPA Supplicant](../wifi91xrcp-getting-started/#configure-station-using-wpa-supplicant) section for different options in wpa_supplicant.
4. To dynamically change the config_er_su value, use the command below after connection.  
   ```c  
   # echo 2 >/sys/kernel/debug/phyX/config_er_su  
   ```
5. To check the config_er_su value, use the command below.  
   ```c  
   # cat /sys/kernel/debug/phyX/config_er_su  
   ```
6. To use the fixed rate in ER-SU, follow the steps described in the [Configuring the 802.11ax Wi-Fi Data Rate](../wifi91xrcp-developers-guide-wifi-configuration/802-11-ax-wifi-data-rate#configuring-the-802-11ax-wi-fi-data-rate) section.

##### Configuring the 802.11ax Wi-Fi Data Rate

You can fix the 11ax rate by using debugfs, as mentioned below. On higher kernel versions (above 5.10.0), you can set the 11ax rate by using debugfs and iw tools.

###### Fixing the 11ax Rate through debugfs

1. Fixed 11ax rate can be executed using echo command as shown below.  
   ```c  
   # echo 0 >  /sys/kernel/debug/phyX/ax_rate  
   ```  
   In this case:  
   - phyX is the physical device number that you can obtain by iw dev command,  
   - Rate '0' indicates the mcs0 of 11ax  rates  
   - Rate, '1' indicates the mcs1 of 11ax rates and follows till mcs7, where mcs stands for modulation and coding scheme.
2. Run the following command to read the current rate:  
   ```c  
   # cat /sys/kernel/debug/phyX/ax_rate  
   ```
3. The output on the command line is as shown below  
   ```c  
   # Current ax_rate is 0x00  
   ```
4. Run the following command to disable the fixed rate:  
   ```c  
   # iw dev wlan0 set bitrates  
   ```

###### Fixing 11ax Rate by Using iw for Kernel Versions Above 5.10

1. Run the following command to set the 11ax rate:  
   ```c  
   # iw dev <interface name > set bitrates he-mcs-<2.4 | 5 | 6> <NSS:MCS index>  
   ```  
   **Example:**  
   ```c  
   # iw dev wlan0 set bitrates he-mcs-2.4 1:0  
   ```  
   In this case:  
   - NSS is the number of spatial streams.  
   - This command is supported on kernel version greater 5.10 and iw  version 5.9.

###### Fixing the Rate by Using iw for 11n Mode

1. Run the following command to set the legacy rate:  
   ```c  
   # iw dev <interface name > set bitrates legacy-<2.4 | 5> < legacy rate in Mbps>  
   ```  
   **Example:**  
   ```c  
   iw dev wlan0 set bitrates legacy-2.4 11  
   ```  
   > For kernel version 4.12 and above which do not support the legacy rate setting, run the following command:  
   ```c  
    # iw dev <interface name > set bitrates legacy-<2.4 | 5> < One basic rate  in Mbps > < Non basic rate in Mbps>  
   ```  
   **Example:**  
   ```c  
   # iw dev wlan0 set bitrates legacy-2.4 1 12  
   ```
2. Run the following command to set the mcs rate:  
   ```c  
   # iw dev <interface name s> set bitrates ht-mcs-<2.4 | 5> <MCS index>  
   ```  
   **Example:**  
   ```c  
   #iw dev wlan0 set bitrates ht-mcs-2.4 1  
   ```
3. Run the following command to disable the fix rate:  
   ```c  
   # iw dev wlan0 set bitrates  
   ```

##### Configuring 802.11ax GI and LTF

When driver is inserted, you can configure guard_interval (i.e., GI and LTF) value by using module param and through debugfs after driver insertion.

The below table shows the value of guard_interval when the he_ppdu type is HE_SU. Dynamic configuration of GI_LTF after connection will happen only when the user fixes the 11ax  rate.

|**guard_interval Value**|**LTF and GI Values**|
|---|---|
|0|1x(3.2) HE_LTF and 0.8 GI|
|1|2x(6.4) HE_LTF and 0.8 GI|
|2|2x(6.4) HE_LTF and 1.6 GI|
|3|4x(12.8) HE_LTF and 3.2 GI|

###### Configuring GI and LTF through debugfs

- Dynamic configuration of GI and LTF after connection will happen only when the user fixes the 11ax  rate.
- Run the following command to configure the guard_interval value:  
  ```c  
   # echo <value> >  /sys/kernel/debug/phyX/GI_LTF  
  ```  
  **Example:**  
  ```c  
   # echo 1 >  /sys/kernel/debug/phyX/GI_LTF  
   # echo 2 >  /sys/kernel/debug/phyX/GI_LTF  
  ```
- Run the following command to fix the 11ax rate:  
  ```c  
   # echo <rate_index> >/sys/kernel/debug/phyX/ax_rate  
  ```  
  In the command above, replace phyX with a physical device number that you can obtain by iw dev command and < rate_index > with the guard_interval value mentioned in the table.  
  **Example:**  
  ```c  
   # echo 0 >/sys/kernel/debug/phyX/ax_rate  
   # echo 1 >/sys/kernel/debug/phyX/ax_rate  
  ```  
  > **Note:** For kernel versions above 5.10, use the iw command below instead of the debugsfs command above to set the 11ax rate:
- Set HE MCS rate with iw dev(11ax rate).  
  ```c  
    #iw dev <interface name > set bitrates he-mcs-<2.4 | 5 | 6> <NSS:MCS index>  
  ```  
  In this case, `NSS` is the number of spatial streams.  
  **Example:**  
  ```c  
   iw dev wlan0 set bitrates he-mcs-2.4 1:0  
  ```  
  This command is supported on kernel versions greater than 5.10 and iw  version 5.9
- Command to read guard_interval value.  
  ```c  
   # cat  /sys/kernel/debug/phyX/GI_LTF   
  ```

###### Configuring Guard Interval through Module Parameter

1. Insert the driver with guard_interval module param.  
   ```c  
   # insmod rsi_91x.ko dev_oper_mode=1 rsi_zone_enabled=0x601 guard_interval=<value>  
   # insmod rsi_sdio.ko  
   ```  
   **Example:**  
   ```c  
   # insmod rsi_91x.ko dev_oper_mode=1 rsi_zone_enabled=0x601 guard_interval=1  
   # insmod rsi_91x.ko dev_oper_mode=1 rsi_zone_enabled=0x601 guard_interval=2  
   ```  
   In this case, <value> is the guard_interval value mentioned in the table at the beginning of [this](#) section.

#### BLE Configuration

##### Overview

This section describes the various Bluetooth Low Energy (BLE) protocol configurations supported by the SiWT917 RCP Driver for Radio Co-processor (RCP) mode:

- [Common BLE Parameters](common-ble-parameters) to enable, disable, or configure various BLE features.
- [BLE Gain Table](ble-gain-table) to program region-based maximum power values for the BLE network interface.
- [Enable Bluetooth Stack](enable-bluetooth-stack)

##### Configuring Common BLE Parameters

The following sections describe common BLE configuration parameters that enable/disable or configure various BLE features of the SiWT917 Open Source Driver (OSD).

> **Note**: The following `insmod` command may be used to configure multiple parameters at the same time. Note that this only applies to the parameters below that are configuring using `insmod`.
> 
> Replace `module_param` with the module parameter to be configured and <value> with the corresponding value that needs to be assigned.
> Module parameters in this section are grouped according to the corresponding feature.
> 
> **insmod rsi_91x.ko [module_param = <value>], [module_param = <value>], ... , [module_param = <value>]**

1. **insmod rsi_91x.ko bt_rf_type = < value >**: This variable selects the BT RF TYPE which the module has to operate. The following are the possible values:  
   - 0 - EXTERNAL RF  
   - 1 - INTERNAL RF (Default)  
   For example, bt_rf_type = 1 sets bt rf type to Internal RF.
2. **insmod rsi_91x.ko ble_tx_pwr_inx = < value >** :This module param selects the BLE_TX_PWR index value. Default Value for BLE Tx Power Index is 30. The following are the possible values:  
   **For LP Chain :** **Power Index Range:** 1 to 63  
   - **1 to 31:** BLE mode with 0 dBm output power.  
   - **33 to 63:** BLE mode with 10 dBm output power.  
   **Note:** Modules do not support LP chain 10 dBm mode.  
   **For HP Chain :** **Power Index Range:** 1 to 25, 40 to 91, and 127  
   - **1 to 25:** BLE mode with output power approximately equal to the selected power index, with a step size of 1 dB    
     - **Notes:**      
       - Power index vs output power for ICs and modules in this range (1 to 25) is identical.      
       - Output power saturates between power index 22 and 25.  
   - **40 to 91:** BLE mode with output power approximately equal to _(selected power index - 40) / 2_, with a step size of 0.5 dB  
   - **127:** Maximum power supported as per country region regulations.  
   For example, you can set the value as shown here.  
   ```c  
   ble_tx_pwr_inx=0x1e  
   ```  
   ### Power Index vs Output Power Tables  
   Following are the Power Index vs Output Power in dBm for ICs and Modules  
   **Note:** Output power varies from board to board..  
   #### i. Modules in LP Chain  
   |Power Index|Output Power (dBm)|  
   |---|---|  
   |31|-0.7|  
   |30|-0.7|  
   |29|-0.8|  
   |28|-0.8|  
   |27|-0.9|  
   |26|-1.0|  
   |25|-1.1|  
   |24|-1.2|  
   |23|-1.2|  
   |22|-1.3|  
   |21|-1.4|  
   |20|-1.6|  
   |19|-1.7|  
   |18|-1.8|  
   |17|-2.0|  
   |16|-2.2|  
   |15|-2.5|  
   |14|-2.7|  
   |13|-3.0|  
   |12|-3.4|  
   |11|-3.7|  
   |10|-4.2|  
   |9|-4.7|  
   |8|-5.4|  
   |7|-6.1|  
   |6|-7.1|  
   |5|-8.3|  
   |4|-9.8|  
   |3|-12.0|  
   |2|-15.1|  
   |1|-20.1|  
   #### ii. ICs in LP Chain (Power Index 1-31)  
   |Power Index|Output Power (dBm)|  
   |---|---|  
   |31|-0.9|  
   |30|-0.9|  
   |29|-1.0|  
   |28|-1.0|  
   |27|-1.1|  
   |26|-1.1|  
   |25|-1.2|  
   |24|-1.3|  
   |23|-1.4|  
   |22|-1.4|  
   |21|-1.5|  
   |20|-1.6|  
   |19|-1.8|  
   |18|-1.9|  
   |17|-2.1|  
   |16|-2.2|  
   |15|-2.4|  
   |14|-2.7|  
   |13|-2.9|  
   |12|-3.2|  
   |11|-3.6|  
   |10|-3.9|  
   |9|-4.4|  
   |8|-5.0|  
   |7|-5.6|  
   |6|-6.5|  
   |5|-7.6|  
   |4|-9.1|  
   |3|-11.1|  
   |2|-14.1|  
   |1|-19.1|  
   #### iii. ICs in LP Chain (Power Index 33-63)  
   |Power Index|Output Power (dBm)|  
   |---|---|  
   |63|6.7|  
   |62|6.6|  
   |61|6.5|  
   |60|6.4|  
   |59|6.3|  
   |58|6.2|  
   |57|6.1|  
   |56|5.9|  
   |55|5.9|  
   |54|5.7|  
   |53|5.5|  
   |52|5.3|  
   |51|5.1|  
   |50|5.1|  
   |49|4.8|  
   |48|4.5|  
   |47|4.4|  
   |46|4.0|  
   |45|3.5|  
   |44|3.0|  
   |43|2.5|  
   |42|1.9|  
   |41|1.6|  
   |40|0.8|  
   |39|0.2|  
   |38|-1.0|  
   |37|-2.3|  
   |36|-4.2|  
   |35|-6.4|  
   |34|-9.8|  
   |33|-15.7|
3. **insmod rsi_91x.ko ble_power_save_options = < value >**: This variable selects the BLE_PWR_SAVE_OPTIONS mode value. The following are the possible values.  
   - BIT(0) - BLE_DUTY_CYCLING  
   - BIT(1) - BLR_DUTY_CYCLING  
   - BIT(2) - BLE_PWR_SAVE_4X_MODE  
   Default value is 2 i.e. BIT(1)- BLR_DUTY_CYCLING is set.
4. **insmod rsi_91x.ko ble_roles = < value >**: This varialble sets the number of BLE roles allowed.  
   - BIT[3:0] represents the number of central roles allowed.  
   - BIT[7:4] represents the number of peripheral roles allowed.  
   Default value is set to 19.
5. **insmod rsi_91x.ko bt_bdr_mode = < value >**: BDR mode in classic.  
   - BIT(0) - BDR only selection  
   - BIT(1) - BDR in LP chain selection  
   Default value is bt_bdr_mode = 0.
6. **insmod rsi_91x.ko bt_rf_tx_power_mode = < value >**:  
   Default value is 0.
7. **insmod rsi_91x.ko bt_rf_rx_power_mode = < value >**:  
   Default value is 0.
8. **insmod rsi_91x.ko bt_feature_bitmap = < value >**: The bt_feature map can be assigned a value as explained below.  
   - BIT[0] - For Enabling role switch from host set this bit to 1  
   - BIT[1] - For Enabling sniff from host set this bit to 1  
   - BIT[5] - For Enabling BT Spoof MAC address i.e to use HARDCODE_MAC_ADDR in BT this bit should be set to 1  
   - BIT[7:3] -  Reserved  
   Default value is 0.

> **Note**:
> 
> See the [Common Software Parameters](../wifi91xrcp-developers-guide-ble-configuration/common-ble-parameters) section for Configuring Common Software Parameters.
> 
> See the [Common Wi-Fi Parameters](../wifi91xrcp-developers-guide-wifi-configuration/common-wifi-parameters) section for Configuring Common Wi-Fi Parameters.

##### BLE Gain Table

To program region-based maximum power for the BLE device, follow the steps below.

See the [Region-based Maximum Power](../wifi91xrcp-developers-guide-wifi-configuration/region-based-maximum-power#region-based-maximum-power) section for more details.

1. Compile and insert the driver as described in the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) and [Installing the Driver](../wifi91xrcp-getting-started/#installing-the-driver) sections.
2. Navigate to the rsi/release folder.
3. Run the following command:  
   ```c  
    # ./bt_ble_gain_table_update <protocol ID>  
   ```  
   For example:  
   ```c  
    # ./bt_ble_gain_table_update 0  
   ```  
   In this case, 0 is the Protocol ID value for BLE.  
   The commands above start the table programming and should display the following logs.  
   ```c  
     ******************Successfully completed programming n gain tables*****************   
   ```  
   In this case, `n` is the number of structures given in wlan_gain_table.txt file.
4. Below is the reference **Gain table structure** format while updating the file  
   ```c  
   //!************************************************************  
   //! INSTRUCTIONS SHOULD BE FOLLOWED TO EDIT BELOW GAIN TABLES:  
   //!************************************************************  
   //! 1. Each value should be seperated by ',' and space characters.  
   //! 2. Multi-line comments not supported. (e.g. /* comment */)  
   //! 3. A space before comment is needed, for inline comments. (e.g. <Data> //<Comment>)  
   //! 4. Hexadecimal numbers not supported.  
   //! 5. No space between value and ',' character.  
   //! 6. Max power gain table with size more than 10 bytes is not supported.  
   //! 6. Offset gain table with size more than 128 bytes is not supported.  
   //! 7. Supported table names and their maximum supported size are  
   //!     For BLE Max Power Table        --- RS9116_BLE_REGION_BASED_MAXPOWER_XX           MAX_LENGTH =  10  
   //!     For BLE Offset Table           --- RS9116_BLE_REGION_BASED_MAXPOWER_VS_OFFSET_XX MAX_LENGTH =  128  
   //!    NOTE: No support for other table names.  
   //! 8. Update above mentioned respected generic tables with the required data  
   //! 9. Supported Region names:  
   //!     FCC, ETSI, TELEC, WORLDWIDE, KCC  
   //!  
   ```

Following is the format of BLE Gain Tables:

**BLE HP Chain Max Power Gain Table format:**

```c
   //!    <TABLE NAME>[] = { //<COMMENTS if any>
   //!    <REGION NAME 1>, <MAX POWER>,
   //!    <REGION NAME 2>, <MAX POWER>,
   //!    .
   //!    .
   //!    <REGION NAME N>, <MAX POWER>,
   //!    }; //<COMMENTS if any>
   //!    
```

**Note:**

- The maximum size for the BLE Max Power Gain Table is 10 bytes
- In each entry, list the max power value desired in dBm (that is, 1dB steps)

**BLE HP Chain Offset Gain Table format:**

```c
   //!    <TABLE NAME>[] = { //<COMMENTS if any>
   //!    <NO.of Regions>,
   //!        <REGION NAME 1>, 
   //!        <NO.OF CHANNELS IN THIS REGION>,
   //!            <CH NUMBER 1>, <POWER OFFSET FOR 1 M>, <POWER OFFSET FOR 2 M>, <POWER OFFSET FOR 125 kbps>, <POWER OFFSET FOR 500 kbps>,
   //!            <CH NUMBER 2>, <POWER OFFSET FOR 1 M>, <POWER OFFSET FOR 2 M>, <POWER OFFSET FOR 125 kbps>, <POWER OFFSET FOR 500 kbps>,
   //!            .
   //!            .
   //!            <CH NUMBER m>, <POWER OFFSET FOR 1 M>, <POWER OFFSET FOR 2 M>, <POWER OFFSET FOR 125 kbps>, <POWER OFFSET FOR 500 kbps>,
   //!        <REGION NAME 2>, 
   //!        <NO.OF CHANNELS IN THIS REGION>,
   //!            <CH NUMBER 1>, <POWER OFFSET FOR 1 M>, <POWER OFFSET FOR 2 M>, <POWER OFFSET FOR 125 kbps>, <POWER OFFSET FOR 500 kbps>,
   //!            <CH NUMBER 2>, <POWER OFFSET FOR 1 M>, <POWER OFFSET FOR 2 M>, <POWER OFFSET FOR 125 kbps>, <POWER OFFSET FOR 500 kbps>,
   //!            .
   //!            .
   //!            <CH NUMBER m>, <POWER OFFSET FOR 1 M>, <POWER OFFSET FOR 2 M>, <POWER OFFSET FOR 125 kbps>, <POWER OFFSET FOR 500 kbps>,
   //!        .
   //!        .
   //!        <REGION NAME y>, 
   //!        <NO.OF CHANNELS IN THIS REGION>,
   //!         .
   //!         .
   //!    }; //<COMMENTS if any>
```

**Note:**

- The maximum size for the BLE Offset Gain Table is 128 bytes
- Each listed power offset value represents the desired additional power back off, that should be applied (on top of the absolute limits  
  listed in the Max Power Gain Table), expressed in dB (that is 1 dB steps).
- The offset value specified for channel number 255 represents all channels except those that are explicitly specified.

**LP Chain 0 dBm and +8 dBm Gain Tables format:**

```c
   //!    <TABLE NAME>[] = { //<COMMENTS if any>
   //!    <NO.of Regions>,
   //!        <REGION NAME 1>, 
   //!        <NO.OF CHANNELS IN THIS REGION>,
   //!            <CH NUMBER 1>, <POWER INDEX FOR 1 M>, <POWER INDEX FOR 2 M>, <POWER INDEX FOR 125 kbps>, <POWER INDEX FOR 500 kbps>,
   //!            <CH NUMBER 2>, <POWER INDEX FOR 1 M>, <POWER INDEX FOR 2 M>, <POWER INDEX FOR 125 kbps>, <POWER INDEX FOR 500 kbps>,
   //!            .
   //!            .
   //!            <CH NUMBER m>, <POWER INDEX FOR 1 M>, <POWER INDEX FOR 2 M>, <POWER INDEX FOR 125 kbps>, <POWER INDEX FOR 500 kbps>,
   //!        <REGION NAME 2>, 
   //!        <NO.OF CHANNELS IN THIS REGION>,
   //!            <CH NUMBER 1>, <POWER INDEX FOR 1 M>, <POWER INDEX FOR 2 M>, <POWER INDEX FOR 125 kbps>, <POWER INDEX FOR 500 kbps>,
   //!            <CH NUMBER 2>, <POWER INDEX FOR 1 M>,  <POWER INDEX FOR 2 M>, <POWER INDEX FOR 125 kbps>, <POWER INDEX FOR 500 kbps>,
   //!            .
   //!            .
   //!            <CH NUMBER m>, <POWER INDEX FOR 1 M>, <POWER INDEX FOR 2 M>, <POWER INDEX FOR 125 kbps>, <POWER INDEX FOR 500 kbps>,
   //!        .
   //!        .
   //!        <REGION NAME y>, 
   //!        <NO.OF CHANNELS IN THIS REGION>,
   //!         .
   //!         .
   //!    }; //<COMMENTS if any>
```

**Note:**

- The maximum size for the LP chain 0 dBm and +8 dBm gain tables is 128 bytes.
- In each entry, the desired power indices is listed. The valid range is 1 to 31 for the 0 dBm table and 33 to 63 for the 8 dBm table.
- The offset value specified for channel number 255 represents all channels except those that are explicitly specified.

Example BLE Gain Table structures:

HP Chain Max Power Gain Table structure:

```c
   RS9116_BLE_REGION_BASED_MAXPOWER_XX[] = {
       // REGION_NAME  MAX_POWER
       FCC,        18,
       ETSI,       8,
       TELEC,      10,
       WORLDWIDE,  18,
       KCC,        10,
   };
```

HP Chain Offset Gain Table structure:

```c
   RS9116_BLE_REGION_BASED_MAXPOWER_VS_OFFSET_XX[] = {
       5, //NUM_OF_REGIONS
       FCC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    0,     0,      6,       0,
           0,       0,     0,      6,       0,
           37,      1,     3,      6,       0,
           38,      2,     4,      6,       1,
           39,      3,     18,     6,       2,
       ETSI,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    0,     0,      0,       0,
           0,       0,     0,      0,       0,
           19,      0,     0,      0,       0,
           39,      0,     0,      0,       0,
       TELEC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    0,     0,      0,       0,
           0,	    0,     7,      0,       0,
           1,       0,     7,      0,       0,
       WORLDWIDE,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    0,     0,      0,       0,
           0,       0,     0,      0,       0,
           19,      0,     0,      0,       0,
           39,      0,     0,      0,       0,
       KCC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    0,     0,      0,       0,
           0,	    0,     0,      0,       0,
           19,      0,     0,      0,       0,
           39,      0,     0,      0,       0,
   };
```

The Max Power and Offset Gain Tables above set the maximum TX power limits for the BLE HP chain. Following are the max TX power limitations for the BLE HP chain:

- FCC  
  - 1 M PHY:    
    - Ch 37: +17 dBm    
    - Ch 38: +16 dBm    
    - Ch 39: +15 dBm    
    - All other channels: +18 dBm  
  - 2 M PHY:    
    - Ch 37: +15 dBm    
    - Ch 38: +14 dBm    
    - Ch39: 0 dBm    
    - All other channels: +18 dBm  
  - 500 kbps PHY:    
    - Ch 38: +17 dBm    
    - Ch 39: +16 dBm    
    - All other channels: +18 dBm  
  - 125 kbps PHY:    
    - +12 dBm on all channels
- ETSI  
  - +8 dBm on all channels
- TELEC/MIC:  
  - Ch 0-1, 2 M PHY: +3 dBm  
  - All other channel and PHY combinations: +10 dBm
- KCC:  
  - +10 dBm on all channels

LP Chain +8 dBm Gain Table structure:

```c
   RS9116_BLE_REGION_BASED_MAXPOWER_VS_OFFSET_XX[] = {
       5, //NUM_OF_REGIONS
       FCC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    63,    63,    63,       63,
           0,       63,    63,    63,       63,
           19,      63,    63,    63,       63,
           39,      63,    35,    63,       63,
       ETSI,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    63,    63,    63,       63,
           0,       63,    63,    63,       63,
           19,      63,    63,    63,       63,
           39,      63,    63,    63,       63,
       TELEC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    63,    63,    63,       63,
           0,	    63,    63,    63,       63,
           19,      63,    63,    63,       63,
           39,      63,    63,    63,       63,
       WORLDWIDE,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    63,    63,    63,       63,
           0,       63,    63,    63,       63,
           19,      63,    63,    63,       63,
           39,      63,    63,    63,       63,
       KCC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    63,    63,    63,       63,
           0,	    63,    63,    63,       63,
           19,      63,    63,    63,       63,
           39,      63,    63,    63,       63,
   };
    
```

LP Chain 0 dBm Gain Table structure:

```c
   RS9116_BLE_REGION_BASED_MAXPOWER_VS_OFFSET_XX[] = {
       5, //NUM_OF_REGIONS
       FCC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    31,    31,    31,       31,
           0,       31,    31,    31,       31,
           19,      31,    31,    31,       31,
           39,      31,     8,    31,       31,
       ETSI,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    31,    31,    31,       31,
           0,       31,    31,    31,       31,
           19,      31,    31,    31,       31,
           39,      31,    31,    31,       31,
       TELEC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    31,    31,    31,       31,
           0,       31,    31,    31,       31,
           19,      31,    31,    31,       31,
           39,      31,    31,    31,       31,
       WORLDWIDE,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    31,    31,    31,       31,
           0,       31,    31,    31,       31,
           19,      31,    31,    31,       31,
           39,      31,    31,    31,       31,
       KCC,
       4, //NUM_OF_CHANNELS
       //chan_num   1 M   2 M   125 kbps  500 kbps
           255,	    31,    31,    31,       31,
           0,       31,    31,    31,       31,
           19,      31,    31,    31,       31,
           39,      31,    31,    31,       31,
   };
```

The reference Gain Table above allows the use of BLE LP chain with +8 dBm and 0 dBm mode max power settings. However, for FCC region, channel 39 (2480 MHz), and 2 Mbps PHY, the TX power is restricted to - 7 ~ - 5 dBm to comply with FCC band-edge regulations.

##### BLE Country Region

Currently, users are restricted to configuring the same region for both BLE and Wi-Fi. This new enhancement provides the flexibility to set the BLE region independently before connecting to an Access Point (AP). Once the connection to the AP is successfully established, the BLE region will automatically adjust to match the region supported by the connected AP

**Note:** This configuration is supported exclusively on the SiW917Y module.

Follow these steps to update the BLE country region:

1. Compile and insert the driver as outlined in the [Compilation Steps](../wifi91xrcp-getting-started/#compilation-steps) and [Installing the Driver](../wifi91xrcp-getting-started/#installing-the-driver) sections.
2. Navigate to the release folder.
3. Run the following command to request the `BLE_COUNTRY_REGION_UPDATE` command:

###### Set BLE Country Region Command (heading level 7)

```c
./bt_util ble_country_region <country_region>
```

**Supported Country Region Codes:**

|Region|Value|
|---|---|
|FCC|0|
|ETSI|1|
|TELEC|2|
|WORLDWIDE|3|
|KCC|4|
|WORLDSAFE|5 (Applicable only for the SiW917Y module)|
|SRRC|6 (Applicable only for the SiW917Y module)|

**Example:**

```c
#./bt_util ble_country_region 2
```

Users can expect the similar console output

```c
Set country region 
***** Received Country region From LMAC is = 2 *****
```

###### Get BLE Country Region Command (heading level 7)

```c
./bt_util ble_country_region get_ble_country
```

Users can expect the similar console output

```c
Read country region 
***** Received Country region From LMAC is = 2 *****
```

##### Enabling the Bluetooth Stack

If Bluetooth is required, it must be ensured that the Bluetooth modules are compiled in the kernel. If the Bluetooth modules are not present, follow the steps below to enable Bluetooth support in the kernel.

1. Navigate to the Linux kernel source folder. This is usually in /usr/src/kernels/linux-< kernel-version >
2. Execute the **'make menuconfig'** command to open the Kernel Configuration menu.
3. Scroll down to **"Networking support --->"** and hit Enter.  
   ![Networking support menu](/wifi91xrcp-developers-guide-ble-configuration/2.15.0/images/image5.png)
4. In the new menu, scroll down to the **"Bluetooth subsystem support --->"** option and press **'M'** to modularize the **"Bluetooth subsystem support"** feature and hit Enter.  
   ![Bluetooth subsystem support menu](/wifi91xrcp-developers-guide-ble-configuration/2.15.0/images/image6.png)
5. In the new menu, press **'M'** to modularize the following options:  
   - RFCOMM Protocol support (enable the "RFCOMM TTY support" feature under this).  
   - BNEP Protocol support (enable the "Multicast filter support" and "Broadcast filter support" features under this).  
   - CMTP Protocol support  
   - HIDP Protocol support  
   ![Modularize Bluetooth subsystem support options](/wifi91xrcp-developers-guide-ble-configuration/2.15.0/images/image7.png)
6. Hit the Tab key to select Exit and hit Enter. Repeat this till you are asked whether you want to save the configuration.
7. Select "Yes" and hit Enter. If the above options are already selected, the menuconfig screen will exit immediately.

See the [Kernel Configuration](../wifi91xrcp-developers-guide-software-configuration/kernel-configuration) section for the commands to compile the kernel.

## Additional Topics

### Glossary

- [Glossary](https://docs.silabs.com/wiseconnect/latest/wiseconnect-glossary)
### BRD4346A Radio Board User Guide

- [BRD4346A Radio Board User Guide](https://www.silabs.com/documents/public/user-guides/ug570-brd4346a-user-guide.pdf)
### BRD8045A Adaptor Boards User Guide

- [BRD8045A Adaptor Boards User Guide](https://www.silabs.com/documents/public/user-guides/ug569-brd8045-user-guide.pdf)
### Discussion Forum

- [Discussion Forum](https://community.silabs.com/s/?language=en_US)
### Technical Support

- [Technical Support](https://www.silabs.com/support)
### App Notes

#### Application Notes

This section describes the application notes that provide information of interest to users developing with the SiWT917 RCP Open Source Driver.

##### SiWT917 RCP Getting Started Guide with Raspberry Pi

Click [here](https://www.silabs.com/documents/public/application-notes/AN1444_SiWT917_RCP_Getting_Started_Guide_with_Raspberry_Pi.pdf) to view this application note.

This Application note provides detailed steps to set up the SiWT917 RCP Open Source Driver on a Raspberry Pi device for establishing Wi-Fi and/or BLE connectivity using the SiWT917 Wi-Fi 6 and Bluetooth LE Co-Processor Raspberry Pi Expansion Kit (**SiWT917_EB4346B**).

##### SiWT917 RCP Wi-Fi Concurrent Mode Application Note

Click [here](https://www.silabs.com/documents/public/application-notes/AN1445_SiWT917_RCP_Wi-Fi_Concurrent_Mode.pdf) to view this application note.

This application notes provides detailed steps to set up and evaluate the SiWT917 RCP Open Source Driver in Wi-Fi concurrent mode. Concurrent mode allows the device to operate in both access point (AP) and station (STA) modes simultaneously.

##### SiWT917 RCP Wi-Fi Throughput Application Note

Click [here](https://www.silabs.com/documents/public/application-notes/AN1446_SiWT917_RCP_Wi-Fi_Throughput.pdf) to view this application note.

This application notes describes the procedure for measuring the Wi-Fi throughput of the SiWT917 Wi-Fi 6 and Bluetooth LE [Expansion Kits](../wifi91xrcp-getting-started/#hardware-requirements) on a Linux PC or laptop.

##### SiWT917 RCP Low Power Application Note

Click [here](https://www.silabs.com/documents/public/application-notes/an1506-siwx917-rcp-low-power.pdf) to view this application note

This application note covers the SiWT917 Power Save modes, guidance on selecting the appropriate Power Save mode based on application requirements, and an analysis of current consumption across various operational modes in RCP mode. It also provides instructions on configuring the SiWT917 RCP Open Source Driver in different Power Save modes, including example commands and power optimization techniques to minimize current consumption.

##### SiWT917 RCP Manufacturing Utility Application Note

Click [here](https://www.silabs.com/documents/public/application-notes/an1507-siwt917-manufacturing-utility.pdf) to view this application note

This application note provides information about the manufacturing procedure and the utility in SiWT917 RCP Open Source Driver. Manufacturing refers to programming production-specific information into the device.

#### AN1444: SiWT917 RCP Getting Started Guide with Raspberry Pi

##### AN1444: SiWT917 RCP Getting Started Guide with Raspberry Pi

This document provides detailed instructions for setting up the SiWT917 Single Band Wi-Fi + Bluetooth Low Energy Development Kit using a Raspberry Pi board to enable Wi-Fi support. It includes steps for flashing the RPI4 OS image and configuring the SiWT917 in Wi-Fi STA mode to connect to a router.

###### Key Points

- Setup Requirements
- Flashing RPI4 OS
- Wi-Fi STA bring-up

###### Contents

- [Introduction](intro)
- [Prerequisites](prerequisites)
- [Functional Description SiWT917 on Raspberry Pi4](functional-description)
- [Usage Guidelines](usage-guidelines)
- [Summary/Conclusion](summary-conclusion)
- [Terminology](terminology)
- [Refrences and Related Documentation](references-and-related-documentation)
- [Troubleshooting](troubleshooting)

##### Introduction

This guide provides detailed and comprehensive instructions for setting up the SiWT917 Single Band Wi-Fi + Bluetooth Low Energy Development Kit using a Raspberry Pi board.

The primary goal is to enable Wi-Fi functionality on the development kit. The guide includes step-by-step procedures for flashing the RPI4 OS image onto the Raspberry Pi, ensuring that the operating system is correctly installed and ready for use.

Additionally, it covers the configuration of the SiWT917 in Wi-Fi Station (STA) mode, which allows the device to connect to a Wi-Fi router. This setup enables seamless wireless communication and enhances the overall functionality of the development kit.

##### Prerequisites

Following are the details for the prerequisties required for both hardware and software.

###### Hardware Requirements

Following are the details for hardware requirements.

<table>
    <thead>
        <tr>
            <th>S.N.</th>
            <th>Hardware Components</th>
            <th>Quantity</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1.</td>
            <td>
                SiWT917 RCP Wi-Fi 6 Single Band + BLE 5.4 Wireless Radio.
                <p><strong>Radio board:</strong>
                    <a href="https://www.silabs.com/development-tools/wireless/wi-fi/siwx917-rb4346a-wifi-6-bluetooth-le-soc-4mb-flash-radio-board?tab=overview" target="_blank">BRD4346A</a>
                </p>
                <p><strong>Adapter board:</strong>
                    <a href="https://www.silabs.com/development-tools/wireless/wi-fi/raspberry-pi-hat-adapter-board-for-co-processor-radio-boards?tab=overview" target="_blank">BRD8045B</a>
                </p>
            </td>
            <td>1</td>
            <td>
                <ul>
                    <li><strong>SiWx917_RB4346A:</strong> Wi-Fi 6 and Bluetooth LE Co-Processor Radio board</li>
                    <li><strong>BRD8045B:</strong> Adapter board for Raspberry Pi Expansion Kit</li>
                </ul>
            </td>
        </tr>
        <tr>
            <td>2.</td>
            <td>PC/Laptop/Embedded Platform with Linux OS</td>
            <td>1</td>
            <td>
                <a href="https://www.raspberrypi.com/products/raspberry-pi-4-model-b/" target="_blank">Raspberry Pi 4</a> with
                <a href="https://www.silabs.com/SiWT91x_RCP/SiWx917_RCP_RPI4_kernel-6_1_v-1.0.img.zip" target="_blank">SiWT917 RPi image</a>
            </td>
        </tr>
        <tr>
            <td>3.</td>
            <td>Standard WLAN Access Point</td>
            <td>1</td>
            <td>For example, TP-Link AX1500 Wi-Fi 6 Router</td>
        </tr>
        <tr>
            <td>4.</td>
            <td>Monitor, mouse, and keyboard</td>
            <td>1</td>
            <td>To access the console or UI of Raspberry Pi 4</td>
        </tr>
        <tr>
            <td>5.</td>
            <td>Ethernet/HDMI cables</td>
            <td>1</td>
            <td>To connect Raspberry Pi 4 with the monitor</td>
        </tr>
    </tbody>
</table>

> **Note**: For more information, refer to [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/).

###### Software Requirements

Following are the details for software requirements.

<table>
    <thead>
        <tr>
            <th>S.N.</th>
            <th>Software Components</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1.</td>
            <td>SiWT917 RCP Driver</td>
            <td>
                <a href="https://github.com/SiliconLabs/si91x-rcp-driver" target="_blank">si91x-rcp-driver</a>
            </td>
        </tr>
        <tr>
            <td>2.</td>
            <td>Kernel Version from 3.18 to 6.12</td>
            <td>For example, in this test case, the system's kernel version is 6.12</td>
        </tr>
        <tr>
            <td>3.</td>
            <td>
                <a href="https://w1.fi/wpa_supplicant/" target="_blank">wpa supplicant</a>
            </td>
            <td>For example, wpa_supplicant 2.10</td>
        </tr>
        <tr>
            <td>4.</td>
            <td>
                <a href="https://w1.fi/hostapd/" target="_blank">hostapd</a>
            </td>
            <td>
                <strong>Note:</strong>
                <ul>
                    <li>Hostapd application version used is v.2.10</li>
                    <li>If hostapd is not present in the system, use the command below to install</li>
                </ul>
                <p><strong>Command:</strong> apt install hostapd</p>
            </td>
        </tr>
    </tbody>
</table>

##### Functional Description SiWT917 on Raspberry Pi4

SiWT917 enables Raspberry Pi with Wi-Fi capability. We will enable W-Fi support on the Raspberry Pi 4 board using the SiWT917 Single band Wi-Fi + Bluetooth low energy using the SDIO interface.

![Setup Diagram](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-setup-diagram.png)

In the above figure the user needs to connect the SiWT917 RCP module to a Raspberry Pi 4 running Raspberry Pi 4 OS through the Raspberry Pi connector (40 PIN header). The Raspberry Pi should have a kernel version installed between 3.18 to 6.12. To evaluate STA mode, an external standard wlan access point is needed.

###### Advantages

Wi-Fi capability on target platform, which can be used to use for network connectivity.

###### Use Cases

Enabling Wi-Fi support on the target platform will be used as STA Mode.

##### Usage Guidelines

###### Configuration Parameters for Driver Package

1. Download the RPI OS image from the below link : [SiWx917_RCP_image_with_RPI4.img](https://www.silabs.com/SiWT91x_RCP/SiWx917_RCP_RPI4_kernel-6_1_v-1.0.img.zip).
2. Download the RPI Imager tool: [RPI-Imager](https://downloads.raspberrypi.org/imager/imager_latest.exe).
3. Connect the empty SD card (atleast 32 GB size) to the Windows machine via the SD memory card slot/SD card reader/SD card adapter.
4. Launch the RPI imager. It will pop up the window as shown below.  
   ![RPI image homepage](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step4-rpi-imager.png)
5. Choose the OS and select **Use custom** icon.  
   ![Choose OS](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step5.png)
6. Select the RPI-4B image from the directory where the image is downloaded. Select the **Choose Storage** button and it will pop up the SD card partition.  
   ![Choose Storage](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step7.png)
7. Now click on the **Write** button.  
   ![Write to SD card](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step8.png)
8. It will prompt for confirmation. Click, **Yes**.  
   ![Confirm format the existing image](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step9.png)
9. The image will start flashing onto the selected SD card partition. Wait until the card flashing is done.  
   ![Start Flashing](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step10.png)
10. Once the flashing is complete. A window will pop up showing that the write was successful.  
    ![Write successful](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step11.png)
11. Remove the SD card from the SD card reader and insert it on RPI-4B Pi.

###### Connecting SiWT917 to Raspberry Pi 4 and Accessing Console

Connect the SiWT917_BRD8045B and radioboard to the 40 pin header of Raspberry Pi 4, as shown below.

![Setup diagram](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-setup-diagram-chapter5.png)

1. Connect the 5V power adapter/power up through USB to the Type C USB port of the RPi4 board.
2. Connect the ethernet cable from the ethernet port on RPi to the Windows/Linux PC.
3. Static IP is assigned to RPI and the IP of the RPi4 is 192.168.30.10
4. Give the IP address for the Linux/Windows PC in the same subnet of 192.168.30.X  
   For example:  
   - If Linux PC: ifconfig eth0 192.168.30.15  
   - If Windows PC: Configure the network settings with 192.168.30.15
5. Check the ping to RPi4 board IP 192.168.30.10(Exp: ping 192.168.30.10).
6. Log in to the RPi4 Console using ssh/putty (By default, the IP address of the RPi4 is 192.168.30.10). or
7. User can access the RPi4 using the HDMI connector cable connected to the HDMI supported monitor.
8. After powering up, it will ask for username and password.  
   - **Username**: pi  
   - **Password**: test123

###### Steps to Bring up in STA Mode

1. Download the [si91x-rcp-driver](https://github.com/SiliconLabs/si91x-rcp-driver).
2. Place the driver in any local path of the RPi4 home directory.  
   **Example**: <system_path> : cd /home/pi/  
   > **Note**: **"<system_path>"** is the location where the user has downloaded/placed the SiWT917 driver in the system.
3. Unzip the driver using the following command.  
   ```sh  
   # unzip SiWT917.x.x.x.x.zip  
   ```
4. Now user needs to enter super user mode by giving the following command and providing the correct username and password.  
   ```sh  
   # sudo su  
   ```

The subsection below provides the steps to configure Wi-Fi STA using startup script or manual commands. User can choose any method.

###### Using Startup Scripts

User can use the script at path “<system_path>/SiWT917.x.x.x.x/release/” to run Wi-Fi concurrent mode.

**Example**: ./start_SiWT917.sh STA

For more details about the startup script file, refer to the [Startup Script](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-software-tools/#startup-script) section of [SiWT917 RCP Developer’s Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/).

###### Using Manual Steps

1. Compile the driver using the following commands at path `<system_path>/SiWT917.x.x.x.x/`  
   ```sh  
   #make clean; make  
   ```  
   > **Note**: For compiling from kernel source or for other embedded platforms like iMX6 platform, the user can refer to the section [Compilation Steps](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/#compilation-steps) of the [SiWT917 RCP Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started).  
   Before installing the driver, install the dependencies using the following commands :  
   ```sh  
   # modprobe mac80211  
   # modprobe bluetooth  
   # modprobe rfcomm  
   ```
2. Before installation, the user needs to stop the existing network manager and unblock WLAN from rfkill. The commands below are used to stop the network-manager on different Linux distributions.  
   - For Ubuntu, use the following command:    
     ```sh    
     # service network-manager stop    
     ```  
   - For Fedora/Raspberry Pi, use the following command:    
     ```sh    
     # service NetworkManager stop    
     ```  
   - To stop rfkill blocking WLAN, use the following command:    
     ```sh    
     #rfkill unblock wlan (or) # rfkill unblock all    
     ```
3. Go to the driver package and copy all the files present in the `<system_path>/SiWT917.x.x.x.x/ Firmware` folder to `/lib/firmware` by following the commands below.  
   ```sh  
   # cd <system_path>/SiWT917.x.x.x.x/  
   # cp Firmware/* /lib/firmware  
   ```
4. After compiling the driver go to the `<system_path>/ SiWT917.x.x.x.x/release` folder and give the following commands:  
   ```sh  
   # insmod rsi_91x.ko dev_oper_mode = 1 rsi_zone_enabled = 0x601  
   # insmod sdio.ko sdio_clock = 50  
   ```
5. Check for the interface created using the command below:  
   ```sh  
   # ifconfig -a  
   ```
6. For example, if the driver is loaded successfully and wireless interface is created, then the user will see the following output:  
   ```sh  
   wlan0: flags = 4098<BROADCAST,MULTICAST> mtu 1500  
   ether 94:b2:16:98:ac:dc txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B)  
   RX errors 0 dropped 0 overruns 0 frame 0  
   TX packets 0 bytes 0 (0.0 B)  
   TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0  
   ```  
   > **Note**: In this test case, the wireless interface created after loading of a driver is **wlan0**. The interface name may vary across the systems.
7. Bring up the third-party access point in the desired channel and security. For this test case setup, the **TP-Link AX1500 Wi-Fi 6 Router** is configured with the following credentials, as shown in the figure below.  
   ![AP configuration](/wifi-siwt917-rcp-getting-started-guide-with-raspberry-pi/1.3/images/an1444-step7-sta-mode.png)
8. Edit the network block present in the `<system_path>/SiWT917.x.x.x.x/release/ sta_settings.conf` file which is present in the `<system_path>/ SiWT917.x.x.x.x/release` folder with the credentials of the third-party WLAN access point. For this test case, the network block is updated in the following manner:  
   ```sh  
   ctrl_interface=/var/run/wpa_supplicant  
   update_config=1  
   #Enable this network block for CCMP/TKIP mode  
   network={  
   ssid="Tplink"  
   pairwise=CCMP TKIP  
   group=CCMP TKIP  
   key_mgmt=WPA-PSK  
   psk="12345678"  
   # bgscan="simple:15:-45:20"  
   proto=WPA2 WPA  
   }  
   ```
9. For more details regarding how to update the network block for other security modes in `system_path>/ SiWT917.x.x.x.x/release/sta_settings.conf` file, the user needs to follow the section [Configure station mode using wpa_supplicant](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-operating-modes/wifi-station-mode#configuring-the-driver-in-wi-fi-station-mode).
10. Run wpa_supplicant to connect SiWT917-STA to the TAP.  
    ```sh  
    #wpa_supplicant -i <interface name> -D nl80211 -c   
    <system_path>/SiWT917.x.x.x.x/release/sta_settings.conf -dddt > log &  
    **Example : wpa_supplicant -i wlan0 -D nl80211 -c /home/   
    SiWT917.x.x.x.x/release/sta_settings.conf -dddt &gt; supp.log &amp;**  
    ```
11. To check whether the connection is successful or not use the following command:  
    ```sh  
    # iwconfig  
    ```
12. If the connection is successful, then the connected Access point SSID along with the MAC address is displayed as shown below.  
    ```sh  
    wlan0 IEEE 802.11 ESSID:"Tplink"  
    Mode:Managed Frequency:2.412 GHz Access Point: B0:A7:B9:C4:52:CA  
    Bit Rate=39 Mb/s Tx-Power=16 dBm  
    Retry short limit:7 RTS thr=2353 B Fragment thr=2352 B  
    Encryption key:off  
    Power Management:off  
    Link Quality=80/80 Signal level=-28 dBm  
    Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0  
    Tx excessive retries:0 Invalid misc:18 Missed beacon:0  
    ```
13. If it is not connected to an Access point, a message "Not Associated" is displayed as shown below.  
    ```sh  
    wlan0 IEEE 802.11 ESSID:off/any  
    Mode: Managed Access Point: Not-Associated  
    Tx-Power=0 dBm Retry short limit:7 RTS thr:off Fragment thr:off  
    Encryption key:off  
    Power Management:off  
    ```
14. After successful connection check the IP address using the below commands  
    ```sh  
    # dhclient wlan0 -r  
    # dhclient wlan0 -v  
    ```
15. To check if the SiWT917-STA has been assigned with an IP address from the third-party WLAN access point , the user can give the following command:  
    ```sh  
    #ping <IP_adrress of TAP>  
    Example: ping 192.168.0.1  
    ```
16. For example, if SiWT917-STA has successfully got IP, we will see the following output.  
    ```sh  
    PING 192.168.0.1 (192.168.0.1) from 192.168.0.228 wlan0: 56(84) bytes of data.  
    64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=26.8 ms  
    64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=10.8 ms  
    64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=4.00 ms  
    64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=6.25 ms  
    64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=1.77 ms  
    64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=5.05 ms  
    64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=2.18 ms  
    64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=5.63 ms  
    64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=2.72 ms  
    64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=3.01 ms  
    64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=2.32 ms  
    64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=3.14 ms  
    --- 192.168.0.1 ping statistics ---  
    12 packets transmitted, 12 received, 0 % packet loss, time 11019 ms  
    rtt min/avg/max/mdev = 1.766/6.133/26.773/6.665 ms  
    ```
17. For example, if SiWT917-STA has not assigned with an IP address, we will see below output for the ping command.  
    ```sh  
    # ping: connect: Network is unreachable  
    ```

##### Summary/Conclusion

This document provided detailed instructions for the compilation, installation, and bring up of SiWT917 RCP module in STA mode using a Raspberry Pi 4 board.

##### Appendix A: Terminology

Common acronyms and abbreviations used in this document:

- **AP -** Access Point.
- **STA -** Station.
- **TAP -** Third party WLAN Access Point.
- **SiWT917-STA -** Station interface that is created for SiWT917 RCP after loading the driver.
- **SiWT917-AP -** Access Point interface that is created for SiWT917 RCP after loading the driver.

##### Appendix B: Refrences and Related Documentation

- Refer to [SiWT917 RCP Developers Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/) and [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/).
- Refer to the following link for the purchase of Raspberry Pi board: [https://www.raspberrypi.com/products/](https://www.raspberrypi.com/products/).

##### Appendix C: Troubleshooting

- Ensure that dev_oper_mode is configured as per the mode selected. (for STA mode: dev_oper_mode = 1).
- If unknown symbols are observed in the dmesg logs, run the commands below and reload the driver.  
  - modprobe mac80211  
  - modprobe bluetooth  
  - modprobe rfcomm

#### AN1445: SiWT917 RCP Wi-Fi Concurrent Mode

##### AN1445: SiWT917 RCP Wi-Fi Concurrent Mode Application Note

This document details the operation of the SiWT917 RCP Wi-Fi module in concurrent mode. It includes step-by-step instructions for setting up and evaluating the module. Concurrent mode enables the device to function simultaneously as an Access Point (AP) and a Station (STA), allowing users to create separate virtual interfaces for each mode.

###### Key Points

- Setup Requirements
- Detailed steps for concurrent mode

###### Contents

- [Introduction](intro)
- [Prerequisites](prerequisites)
- [Functional Description SiWT917 on Raspberry Pi4](functional-description)
- [Usage Guidelines](usage-guidelines)
- [Summary/Conclusion](summary-conclusion)
- [Terminology](terminology)
- [Refrences and Related Documentation](references-and-related-documentation)
- [Troubleshooting](troubleshooting)

##### Introduction

The SiW917 from Silicon Labs supports WiFi Concurrent mode, enabling the device to operate in both Station (STA) and Access Point (AP) modes simultaneously. This dual functionality enhances the versatility and flexibility of WiFi-enabled devices, making them suitable for a wide range of applications.

Devices can connect to the internet to send data to a cloud server (STA mode) while also allowing local devices to connect directly for configuration or control (AP mode).

For more information, refer to the [SiWT917 RCP Developers Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/) and [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/#getting-started-with-si-wt917-in-rcp-mode) implemented for SiWT917 RCP family of modules, which uses netlink sockets.

##### Prerequisites

Following are the details for the prerequisties required for both hardware and software.

###### Hardware

Following are the details for hardware requirements.

<table>
    <thead>
        <tr>
            <th>S.N.</th>
            <th>Hardware Components</th>
            <th>Quantity</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1.</td>
            <td>
                SiWT917 RCP Wi-Fi 6 Single Band + BLE 5.4 Wireless Radio.
                <p><strong>Radio board:</strong>
                    <a href="https://www.silabs.com/development-tools/wireless/wi-fi/siwx917-rb4346a-wifi-6-bluetooth-le-soc-4mb-flash-radio-board?tab=overview" target="_blank">BRD4346A</a>
                </p>
                <p><strong>Adapter board:</strong>
                    <a href="https://www.silabs.com/development-tools/wireless/wi-fi/raspberry-pi-hat-adapter-board-for-co-processor-radio-boards?tab=overview" target="_blank">BRD8045B</a>
                </p>
            </td>
            <td>1</td>
            <td>
                <ol>
                    <li><strong>SiWx917_RB4346A:</strong> Wi-Fi 6 and Bluetooth LE Co-Processor Radio board</li>
                    <li><strong>BRD8045B:</strong> Adapter board for Raspberry Pi Expansion Kit</li>
                </ol>
            </td>
        </tr>
        <tr>
            <td>2.</td>
            <td>PC/Laptop/Embedded Platform with Linux OS</td>
            <td>1</td>
            <td>
                <a href="https://www.raspberrypi.com/products/raspberry-pi-4-model-b/" target="_blank">Raspberry Pi 4</a> with
                <a href="https://www.silabs.com/SiWT91x_RCP/SiWx917_RCP_RPI4_kernel-6_1_v-1.0.img.zip" target="_blank">SiWT917 RPi image</a>
            </td>
        </tr>
        <tr>
            <td>3.</td>
            <td>Standard WLAN Access Point</td>
            <td>1</td>
            <td>For example, TP-Link AX1500 Wi-Fi 6 Router</td>
        </tr>
        <tr>
            <td>4.</td>
            <td>Third party Station</td>
            <td>1</td>
            <td>
                <strong>Note:</strong> Use third-party stations such as phones, tablets, PCs, or laptops capable of connecting to Wi-Fi 6 access points.
                <strong>Example:</strong> OnePlus Nord mobile was used for this test.
            </td>
        </tr>
        <tr>
            <td>5.</td>
            <td>Monitor, mouse, and keyboard</td>
            <td>1</td>
            <td>To access the console or UI of Raspberry Pi 4</td>
        </tr>
        <tr>
            <td>6.</td>
            <td>Ethernet/H0DMI cables</td>
            <td>1</td>
            <td>To connect Raspberry Pi 4 with the monitor</td>
        </tr>
    </tbody>
</table>

> **Note**: For more information, follow the: [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started).

###### Software

Following are the details for software requirements.

<table>
    <thead>
        <tr>
            <th>S.N.</th>
            <th>Software Components</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1.</td>
            <td>SiWT917 RCP Driver</td>
            <td>
                <a href="https://github.com/SiliconLabs/si91x-rcp-driver" target="_blank">si91x-rcp-driver</a>
            </td>
        </tr>
        <tr>
            <td>2.</td>
            <td>Kernel Version from 3.18 to 6.12</td>
            <td>For example, in this test case, the system's kernel version is 6.12.</td>
        </tr>
        <tr>
            <td>3.</td>
            <td>
                <a href="https://w1.fi/wpa_supplicant/" target="_blank">wpa supplicant</a>
            </td>
            <td>For example, wpa_supplicant 2.10.</td>
        </tr>
        <tr>
            <td>4.</td>
            <td>
                <a href="https://w1.fi/hostapd/" target="_blank">hostapd</a>
            </td>
            <td>
                <strong>Note:</strong>
                <ul>
                    <li>Hostapd application version used is v.2.10.</li>
                    <li>If hostapd is not present in the system, install it using the command below.</li>
                </ul>
                <p><strong>Command:</strong> apt install hostapd</p>
            </td>
        </tr>
    </tbody>
</table>

##### Functional Description SiWT917_EB4346B with Raspberry Pi 4 Platform

![Setup Diagram](/wifi-siwt917-rcp-wi-fi-concurrent-mode/1.4/images/an1445-setup-diagram-an1445.jpg "Setup Diagram")

In the figure above, the user needs to connect the SiWT917 RCP module to a Raspberry Pi 4 running Raspberry Pi 4 OS through the Raspberry Pi connector (40 PIN header) . The Raspberry Pi should have a kernel version installed between 3.18 to 6.12. To evaluate concurrent mode, an external third-party AP and STA are needed.

###### Use Cases

- We can use this feature in devices that need wireless third-party access point for internet access and need an admin interface to control and configure the services provided by it.
- Create a bridge/hub with internet access to provide internet access to multiple IoT devices like a Wi-Fi extender.

##### Usage Guidelines

###### Steps to bring up in Concurrent Mode

1. Download the [SiWT917 Driver](https://github.com/SiliconLabs/si91x-rcp-driver).
2. Unzip the driver using the following command.  
   ```sh  
   # unzip SiWT917.x.x.x.x.zip  
   ```
3. Next the user needs to enter the root-user mode by giving the following command and providing the correct username and password.  
   ```sh  
   # sudo su  
   ```  
   The section below provides the steps to configure Wi-Fi Concurrent mode using a startup script or by manual commands. The user can choose either method.

###### Using Startup Scripts (heading level 7)

Use the script at the path “<system_path>/SiWT917.x.x.x.x/release/” to run Wi-Fi concurrent mode.

```sh
##### ./start_SiWT917.sh AP_STA
```

For more details about the startup script file, refer to the [Startup Script](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-software-tools/#startup-script) section of [SiWT917 RCP Developer’s Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/).

###### Using Manual Steps (heading level 7)

1. To enable the concurrent mode, the user need to compile the source by enabling the **CONFIG_STA_PLUS_AP** in Makefile at `<system_path>/SiWT917.x.x.x.x/`.  
   ```sh  
   #Uncomment below line for using Concurrent mode CONFIG_STA_PLUS_AP = y  
   ```  
   > **Note**: `<system_path>` is the location where the user has downloaded/placed the SiWT917 driver in the system.
2. After enabling **CONFIG_STA_PLUS_AP** flag in Makefile, save the file and compile the driver follow.  
   ```sh  
   #make clean; make  
   ```  
   > **Note**: For compiling from kernel source or for other embedded platforms like iMX6 , the user can refer to the section [Compilation Steps](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/#compile-on-an-embedded-platform).
3. Before installing the driver, install the dependencies using the following commands  
   ```sh  
   # modprobe mac80211  
   # modprobe bluetooth  
   ```
4. Before installation, the user needs to stop the existing network manager and unblock WLAN from rfkill. The commands below are used to stop the network-manager on different Linux distribution.  
   - For Ubuntu, use the following command:    
     ```sh    
     # service network-manager stop    
     ```  
   - For Fedora/Raspberry Pi, use the following command:    
     ```sh    
     # service NetworkManager stop    
     ```  
   - To stop rfkill blocking WLAN, use the following command :    
     ```sh    
     #rfkill unblock wlan (or)     
     # rfkill unblock all    
     ```
5. Go to the driver package and copy all the files present in the `<system_path>/SiWT917.x.x.x.x/` **Firmware** folder to `/lib/firmware` by following the commands below.  
   ```sh  
   # cd <system_path>/SiWT917.x.x.x.x/  
   # cp Firmware/* /lib/firmware  
   ```
6. After compiling the driver go to `<system_path>/ SiWT917.x.x.x.x/release` folder and give the following commands.  
   Enter the following command :  
   ```sh  
   # insmod rsi_91x.ko dev_oper_mode = 3 rsi_zone_enabled = 0x601   
   # insmod sdio.ko sdio_clock = 50  
   ```
7. Check for the interface created using the following command:  
   ```sh  
   # ifconfig -a  
   ```  
   For example, if the driver is loaded successfully and the wireless interface is created ,then the user will see the following output :  
   ```sh  
   wlan0: flags=4098<BROADCAST,MULTICAST> mtu 1500   
           ether 94:b2:16:98:ac:dc txqueuelen 1000 (Ethernet) RX packets 0 bytes 0   
           (0.0 B)   
           RX errors 0 dropped 0 overruns 0 frame 0   
           TX packets 0 bytes 0 (0.0 B)   
           TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0  
   ```  
   > **Note**: In this test case, the wireless interface created after loading of the driver is “wlan0". The interface name may vary across the systems.
8. Bring up the third-party access point in the desired channel and security. For this test case setup, the **TP-Link AX1500 Wi-Fi 6 Router** is configured with the following credentials as shown in the below figure.  
   ![TP-Link AX1500 Wi-Fi 6 Router](/wifi-siwt917-rcp-wi-fi-concurrent-mode/1.4/images/an1445-step8.jpg "TP-Link AX1500 Wi-Fi 6 Router")
9. Edit the network block present in the `<system_path>/SiWT917.x.x.x.x/release/ sta_settings.conf`file present in the `<system_path>/ SiWT917.x.x.x.x/release` folder with the credentials of the third-party WLAN access point. For this test case, the network block is updated in the following manner:  
   ```sh  
   ctrl_interface = /var/run/wpa_supplicant  
            update_config = 1  
            #Enable this network block for CCMP/TKIP mode  
            network = {  
            ssid = "Tplink"  
           pairwise = CCMP TKIP  
           group = CCMP TKIP  
           key_mgmt = WPA-PSK psk = "12345678"   
           # bgscan = "simple:15:-45:20"   
           proto = WPA2 WPA   
           }  
   ```  
   For more details regarding how to update the network block for other security modes in `<system_path>/ SiWT917.x.x.x.x/release/sta_settings.conf file`, the user needs to follow the section **Configure Station Using WPA Supplicant** of the [SiWT917 RCP Developer’s Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/).
10. Run wpa_supplicant to connect SiWT917-STA to the TAP.  
    ```sh  
    #wpa_supplicant -i <interface_name> -D nl80211 -c   
            <system_path>/SiWT917.x.x.x.x/release/sta_settings.conf -ddddt > log &       
            Example : wpa_supplicant -i wlan0 -D nl80211 -c /home/   
            SiWT917.x.x.x.x/release/sta_settings.conf -ddddt > supp.log &  
    ```
11. To check whether the connection is successful or not use below command:  
    ```sh  
    # iwconfig  
    ```  
    If the connection is successful, then the connected access point SSID along with the MAC address is displayed as shown below.  
    ```sh  
    wlan0 IEEE 802.11 ESSID:"Tplink"   
    Mode:Managed Frequency:2.412 GHz Access Point: B0:A7:B9:C4:52:CA   
    Bit Rate = 39 Mb/s Tx-Power = 16 dBm   
    Retry short limit:7 RTS thr = 2353 B Fragment thr=2352 B   
    Encryption key:off   
    Power Management:off   
    Link Quality = 80/80 Signal level = -28 dBm   
    Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0   
    Tx excessive retries:0 Invalid misc:18 Missed beacon:0  
    ```  
    If it is not connected to an access point, a message **Not Associated** is displayed as shown below.  
    ```sh  
    wlan0 IEEE 802.11 ESSID:off/any   
    Mode: Managed   
    Access Point: Not-Associated Tx-Power = 0 dBm Retry short limit:7 RTS thr:off Fragment thr:off   
    Encryption key:off   
    Power Management:off  
    ```
12. After successful connection, check the IP address using the below commands  
    ```sh  
    # dhclient wlan0 -r   
    # dhclient wlan0 -v  
    ```
13. To check if the SiWT917-STA has assigned an IP address from the third-party wlan access point, the user can give the following command:  
    ```sh  
    #ping <IP_adrress of TAP>   
             Example : ping 192.168.0.1  
    ```  
    For example, if SiWT917-STA has successfully received an IP, we will see the following output.  
    ```sh  
    PING 192.168.0.1 (192.168.0.1) from 192.168.0.228 wlan0:   
    56(84) bytes of data.   
    64 bytes from 192.168.0.1: icmp_seq = 1 ttl = 64 time = 26.8 ms   
    64 bytes from 192.168.0.1: icmp_seq = 2 ttl = 64 time = 10.8 ms   
    64 bytes from 192.168.0.1: icmp_seq = 3 ttl = 64 time = 4.00 ms   
    64 bytes from 192.168.0.1: icmp_seq = 4 ttl = 64 time = 6.25 ms   
    64 bytes from 192.168.0.1: icmp_seq = 5 ttl = 64 time = 1.77 ms   
    64 bytes from 192.168.0.1: icmp_seq = 6 ttl = 64 time = 5.05 ms   
    64 bytes from 192.168.0.1: icmp_seq = 7 ttl = 64 time = 2.18 ms   
    64 bytes from 192.168.0.1: icmp_seq = 8 ttl = 64 time = 5.63 ms   
    64 bytes from 192.168.0.1: icmp_seq = 9 ttl = 64 time = 2.72 ms   
    64 bytes from 192.168.0.1: icmp_seq = 10 ttl = 64 time = 3.01 ms  
    64 bytes from 192.168.0.1: icmp_seq = 11 ttl = 64 time = 2.32 ms   
    64 bytes from 192.168.0.1: icmp_seq = 12 ttl = 64 time = 3.14 ms   
    --- 192.168.0.1 ping statistics ---   
    12 packets transmitted, 12 received, 0 % packet loss, time 11019 ms   
    rtt min/avg/max/mdev = 1.766/6.133/26.773/6.665 ms  
    ```  
    For example, if SiWT917-STA has not assigned with an IP address, we will see the following output for the ping command.  
    ```sh  
    # ping: connect: Network is unreachable  
    ```
14. Create the AP vap, using the following command:  
    ```sh  
    # iw dev wlan0 interface add wlan1 type __ap  
    ```
15. Check the interface name created by using the following command:  
    ```sh  
    # ifconfig -a  
    ```  
    If the interface is successfully created , we will get the following output :  
    ```sh  
    wlan1: flags = 4098<BROADCAST,MULTICAST> mtu 1500   
    ether 94:b2:16:98:ac:dd txqueuelen 1000 (Ethernet)   
    RX packets 0 bytes 0 (0.0 B)   
    RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B)   
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0  
    ```  
    > **Note**: In this test case the interface name for SiWT917-AP is created as "wlan1". The naming convention is system specific. The user can get the same name or a different name depending upon the target host.
16. Configure the fields present in ap_open.conf or ap_wpa.conf file and bring up RSI-AP as follows that is, change the **interface** field value present in `<system_path>/SiWT917.x.x.x.x/release/ /ap_open.conf` file or `<system_path>/SiWT917.x.x.x.x/release/ap_wpa.conf` file with the new interface name created for AP vap.  
    For example, we brought the RSI-AP in open security mode with the following credentials.  
    ```sh  
    interface = wlan1   
    driver = nl80211   
    ctrl_interface = /var/run/hostapd   
    ctrl_interface_group = 0   
      
    ssid=bionic_test ignore_broadcast_ssid = 0   
    hw_mode = g channel = 1 beacon_int = 100  
    dtim_period = 2   
    max_num_sta = 4   
    rts_threshold = 2347   
    fragm_threshold = 2346   
    auth_algs = 1   
    # Country Related   
    #ieee80211d = 1   
    country_code = IN   
    wmm_enabled = 1   
    wmm_ac_bk_cwmin = 4   
    wmm_ac_bk_cwmax = 10   
    wmm_ac_bk_aifs = 7   
    wmm_ac_bk_txop_limit = 0   
    wmm_ac_bk_acm = 0   
    wmm_ac_be_aifs = 3   
    wmm_ac_be_cwmin=4 wmm_ac_be_cwmax = 10   
    wmm_ac_be_txop_limit = 0 wmm_ac_be_acm = 0   
    wmm_ac_vi_aifs = 2   
    wmm_ac_vi_cwmin = 3   
    wmm_ac_vi_cwmax = 4   
    wmm_ac_vi_txop_limit = 94   
    wmm_ac_vi_acm = 0   
    wmm_ac_vo_aifs = 2   
    wmm_ac_vo_cwmin   = 2   
    wmm_ac_vo_cwmax = 3   
    wmm_ac_vo_txop_limit = 47   
    wmm_ac_vo_acm = 0   
    eap_server  = 0  
    ```  
    Then bring up the ap_vap with the following command:  
    ```sh  
    # hostapd ap_open.conf -dddt >log1 &  
    ```
17. To check whether the AP is up or not, use the following command:  
    ```sh  
    # iw dev  
    ```  
    For example, if bringing up of the AP mode is successful, we will see the following output.  
    ```sh  
    phy#1   
    Interface wlan1   
        ifindex 12      
        wdev 0x400000002 addr 94:b2:16:98:ac:dd   
        ssid bionic_test   
        type AP   
        channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz   
        txpower 20.00 dBm   
    Interface wlan0   
        ifindex 9 wdev   
        0x300000001   
        addr 94:b2:16:98:ac:dc   
        ssid Tplink type managed   
        channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz   
        txpower 20.00 dBm  
    ```  
    In the example above, we can see for **Interface wlan1** ,the type is **AP**. The user can now check the SiWT917-AP is up with the ssid **bionic_test** .
18. Run the dhcp server for AP vap.  
    ```sh  
    # sh dhcp_server.sh wlan1  
    ```
19. Connect third-party STA to SiWT917-AP. For example, you can see the below image:  
    ![Connection to third-party STA](/wifi-siwt917-rcp-wi-fi-concurrent-mode/1.4/images/an1445-step19.jpg "Connection to third-party STA")

###### Limitations

Following are the limitations:

- Always start SiWT917-STA first, let the SiWT917-STA connection happen to TAP, and then start the SiWT917-AP mode.
- In concurrent mode, if SiWT917-STA interface goes down, then SiWT917-AP interface must be put down to restart the SiWT917-STA mode.
- SiWT917-STA cannot use radio for scanning once it is acquired by SiWT917-AP for beacon emission for regular interval.
- Background scan(bg-scan) and power save features are not supported for the station mode vap in concurrent mode.
- SiWT917-AP will always operate in channel in which the SiWT917-STA [corresponding to other VAP] connects. For example, if the station connects in channel 6, then AP mode should be created in channel 6, irrespective of the channel configured; however, SiWT917-AP and SiWT917-STA can operate in different security modes.

##### Summary/Conclusion

By following the steps outlined in this document, the user can bring up SiWT917 RCP module in concurrent mode with any Linux based host platform.

##### Appendix A: Terminology

Common acronyms and abbreviations used in this document:

- **AP -** Access Point.
- **STA -** Station.
- **TAP -** Third party WLAN Access Point.
- **SiWT917-STA -** Station interface that is created for SiWT917 RCP after loading the driver.
- **SiWT917-AP -** Access Point interface that is created for SiWT917 RCP after loading the driver.

##### Appendix B: Refrences and Related Documentation

1. Refer to [SiWT917 RCP Developers Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/) and [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/).
2. Refer to [Concurrent mode](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-operating-modes/wifi-station-plus-ap-mode).

##### Appendix C: Troubleshooting

- Make sure the third-party AP is up while connecting to it. Also make sure to add the valid credentials depending on security type in the `<system_path>/SiWT917.x.x.x.x/release/sta_settings.conf` file while running the supplicant.
- Make sure that the AP should be brought in same channel in which the STA is connected to the third-party AP.

#### AN1446: SiWT917 RCP Wi-Fi Throughput

##### AN1446: SiWT917 RCP Wi-Fi Throughput

This document details the measurement of SiWx917 RCP throughput performance, including the observed throughput in various protocols such as TCP and UDP, for both uplink and downlink throughput of SiWx917 across different operating modes.

###### Key Points

- Setup Requirements and Diagram
- Supported Protocols
- Expected results

###### Contents

- [Overview](.)
- [Introduction](intro)
- [Prerequisites](prerequisites)
- [Functional Description SiWT917 on Raspberry Pi4](functional-description)
- [Usage Guidelines](usage-guidelines)
- [Configure iperf and Test](configure-iperf-and-test)
- [Expected Results](expected-results)
- [Summary/Conclusion](summary-conclusion)
- [Terminology](terminology)
- [References and Related Documentation](references-and-related-documentation)
- [Troubleshooting](troubleshooting)

##### Introduction

In the Wireless communication, the term **Throughput** is defined as the number of data units transferred within a specified amount of time over a communication channel and reflects how the network is performing. In general, throughput is measured in bit/s or bps that is, the number of bits transferred in one second.

Many applications need to transfer a burst of data quickly over their Wi-Fi link before returning to sleep or wait state. The user measures the throughput that can be sustained by their device. This document provides information about the measurement of SiWT917 throughput performance, and the throughput observed in different protocols like TCP and UDP, uplink and downlink.

For more information, refer to the [SiWT917 RCP Developers Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/) and [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/). implemented for SiWT917 RCP family of modules, which uses netlink sockets.

##### Prerequisites

Readers of this document are expected to be familiar with the Standard WLAN AP configuration, iperf tools, IP addressing, and DHCP.

###### Hardware

Following are the details for hardware requirements.

<table>
    <thead>
        <tr>
            <th>S.N.</th>
            <th>Hardware Components</th>
            <th>Quantity</th>
            <th>Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1.</td>
            <td>
                SiWT917 RCP Wi-Fi 6 Single Band + BLE 5.4 Wireless Radio.
                <p><strong>Radio boards:</strong>
                    <a href="https://www.silabs.com/development-tools/wireless/wi-fi/siwx917-rb4346a-wifi-6-bluetooth-le-soc-4mb-flash-radio-board?tab=overview" target="_blank">BRD4346A</a>
                </p>
                <p><strong>Adapter board:</strong>
                    <a href="https://www.silabs.com/development-tools/wireless/wi-fi/raspberry-pi-hat-adapter-board-for-co-processor-radio-boards?tab=overview" target="_blank">BRD8045B</a>
                </p>
            </td>
            <td>1</td>
            <td>
                <ul>
                    <li><strong>SiWx917_RB4346A:</strong> Wi-Fi 6 and Bluetooth LE Co-Processor Radio board</li>
                    <li><strong>BRD8045B:</strong> Adapter board for Raspberry Pi Expansion Kit</li>
                </ul>
            </td>
        </tr>
        <tr>
            <td>2.</td>
            <td>PC/Laptop/Embedded Platform with Linux OS</td>
            <td>2</td>
            <td>
                <ol>
                    <li><a href="https://www.raspberrypi.com/products/raspberry-pi-4-model-b/" target="_blank">Raspberry Pi 4</a> with
                        <a href="https://www.silabs.com/SiWT91x_RCP/SiWx917_RCP_RPI4_kernel-6_1_v-1.0.img.zip" target="_blank">SiWT917 RPi image</a>
                    </li>
                    <li>Dell Latitude 3520 with Ubuntu 20.04</li>
                </ol>
            </td>
        </tr>
        <tr>
            <td>3.</td>
            <td>Standard WLAN Access Point</td>
            <td>1</td>
            <td>To connect with Raspberry Pi 4</td>
        </tr>
        <tr>
            <td>4.</td>
            <td>Monitor, mouse, and keyboard</td>
            <td>1</td>
            <td>To connect Raspberry Pi 4 with the monitor</td>
        </tr>
        <tr>
            <td>5.</td>
            <td>Ethernet/HDMI cables</td>
            <td>1</td>
            <td>ASUS TUF Gaming AX5400 Dual-band Wi-Fi 6</td>
        </tr>
    </tbody>
</table>

> **Note**: For more information, refer to [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/).

###### Software

Following are the details for software requirements.

|S.N.|Software Components|Description|
|---|---|---|
|1.|SiWT917 RCP Driver|[si91x-rcp-driver](https://github.com/SiliconLabs/si91x-rcp-driver)|
|2.|Kernel Version from 3.18 to 6.12|For example, In this test case, the system's kernel version is 6.12|
|3.|[wpa supplicant](https://w1.fi/wpa_supplicant/)|For example, wpa_supplicant 2.10.|
|4.|Measurement Tool - iperf|Refer to the section [Configure iperf and test](configure-iperf-and-test).|

##### Functional Description SiWT917 on Raspberry Pi4

Throughput refers to how much data can be transferred in a certain amount of time. It is used to measure the performance of wireless networks.

![Throughput Setup Diagram](/wifi-siwt917-rcp-wi-fi-throughput/1.3/images/an1446-throughput-setup-diagram.jpg)

###### Advantages

By measuring throughput, users can determine network performance, which will help in designing their end-products.

###### Use Cases

Throughput test helps to calculate the application performance like audio/video data using the SiWT917 RCP module.

##### Usage Guidelines

###### Configuration Parameters for Driver Package

1. Download the [si91x-rcp-driver](https://github.com/SiliconLabs/si91x-rcp-driver)
2. Unzip the driver using the following command.  
   ```sh  
   # unzip SiWT917.x.x.x.x.zip  
   ```
3. Enter the super user mode by giving the following command and providing the correct username and password.  
   ```sh  
   # sudo su  
   ```

The following section provides the steps to configure Wi-Fi station mode using startup script or manual commands. Users can choose any method.

###### Using Startup Scripts (heading level 7)

Users can use the script at path `<system_path>/SiWT917.x.x.x.x/release/` to run Wi-Fi station mode.

```sh
##### ./start_SiWT917.sh STA
```

> **Note**: `<system_path>` is the location where the user has downloaded/placed the SiWT917 RCP driver in the system.

###### Manual Steps (heading level 7)

###### Compiling the Driver (heading level 8)

Change the working directory to the driver package directory and follow the compilation steps below.

1. Go to the driver package and copy all the files present in the `<system_path>/SiWT917.x.x.x.x/Firmware` folder to `/lib/firmware` by following the commands below.  
   ```sh  
   # cd /SiWT917.x.x.x.x/Firmware/   
   # cp Firmware/* /lib/firmware  
   ```
2. Configure the build flags in the driver source by navigating to the driver.  
   ```sh  
   # cd <system_path>/SiWT917.x.x.x.x/  
   ```
3. Build the driver using the make command.  
   ```sh  
   # make  
   ```

For compiling from kernel source or for other embedded platforms like the i.MX6 platform, the user can refer to the [SiWT917 RCP Getting Started Guide](http://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started) under section **Compilation steps**.

After compilation is completed, the driver generates the following modules in the “release” folder according to the configuration.

- rsi_91x.ko
- rsi_sdio.ko

These are outlined in the following section.

###### Driver Installation (heading level 8)

To install the driver, use the following commands:

1. Before installing the driver, install the dependencies using the commands below:  
   ```sh  
   # modprobe mac80211   
   # modprobe bluetooth   
   # modprobe rfcomm  
   ```
2. Insert rsi_91x.ko with the required module params (configuration) as shown below:  
   ```sh  
   # insmod rsi_91x.ko dev_oper_mode=<mode> rsi_zone_enabled=<val> . .   
            Example: insmod rsi_91x.ko dev_oper_mode=1 rsi_zone_enabled=0x1  
   ```

Select dev_oper_mode as 1. For all other supported modes, refer to [SiWT917 RCP Developer’s Guide](http://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/).

In the above example, the module param **rsi_zone_enabled** is used to program the verbosity of the debug logs. More information can be found under [Debug Prints](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-software-configuration/debug-prints#debug-prints).

Now install `rsi_sdio.ko` by entering the below command :

```sh
##### insmod rsi_sdio.ko sdio_clock = 50 Mhz
```

After a successful installation, a new wireless interface will be created as per the dev_oper_mode selection and it can be seen using the **ifconfig** command.

```sh
##### ifconfig -a
```

Expect an output like the sample shown below with all other available interfaces included.

```sh
wlan0 flags = 4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
               inet6 fe80::8da:1aff:fe1e:d1c8 prefixlen 64 scopeid 0x20<link> 
               ether 94:b2:16:98:ac:dc txqueuelen 1000 (Ethernet) 
               RX packets: 3 bytes 372 (372.0 B) 
               RX errors 0 dropped 0 overruns 0 frame 0 
               TX packets: 6 bytes 696 (696.0 B) 
               TX errors 0 dropped 0 overruns 0 collisions:0
```

> **Note**: WLAN interface (wlan0) name may vary across the systems.

###### Installation of the Wi-Fi Client Mode (heading level 8)

This section provides the steps to configure the Wi-Fi client mode using wpa_supplicant.

1. Before running wpa_supplicant, stop the existing network manager and unblock WLAN from rfkill. The commands below are used to stop the network-manager on different Linux distributions.  
   For ubuntu, we need to use the following command:  
   ```sh  
   # service network-manager stop  
   ```  
   For Fedora/Raspberry Pi, we need to use the following command:  
   ```sh  
   # service NetworkManager stop  
   ```  
   To stop rfkill blocking WLAN, we need to use the following command:  
   ```sh  
   # rfkill unblock wlan (or) #rfkill unblock all  
   ```
2. Bring up the Standard WLAN access point in the desired channel and security. For our setup, we have configured our **ASUS TUF Gaming AX5400 Dual-band Wi-Fi 6** with the following configuration as shown in the figure below.  
   A few key parameters need to be enabled.  
   - 11ax feature should be enabled to get high throughput.![ASUS TUF Gaming AX5400 Dual-band Wi-fi 6 configuration](/wifi-siwt917-rcp-wi-fi-throughput/1.3/images/an1446-installation-of-the-wi-fi-client-mode.jpg)
3. Edit the network block present in the `sta_settings.conf` file in the **release** folder with the credentials of the **ASUS TUF Gaming AX5400 Dual-band Wi-Fi 6** access point. For our setup, we have updated in the following block.  
   ```sh  
   ctrl_interface=/var/run/wpa_supplicant   
            update_config = 1   
            #Enable this network block for CCMP/TKIP mode   
            network = {   
                       ssid = "SSID"       
                       pairwise = CCMP TKIP   
                       group = CCMP TKIP   
                       key_mgmt = WPA-PSK   
                       psk = "12345678"   
                       proto=WPA2 WPA   
                       }  
   ```  
   For more details on how to update the network block for other security modes in the `sta_settings.conf` file, users must follow the [SiWT917 RCP Developer’s Guide](http://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/).
4. Start the supplicant using the following command:  
   ```sh  
   # wpa_supplicant -i wlan0 -D nl80211 –c sta_settings.conf –dddt > supp.log &  
   ```  
   - **–i** option specifies the Wi-Fi interface name.  
   - **<interface name> -** This name as listed in iw dev output.  
   - **-D** specifies the driver interface to be used. In open-source driver, it is nl80211.  
   - **-c** specifies the supplicant configuration file.  
   - **-d** specifies the log level of supplicant. You can append more d's to increase the verbose.
5. To check whether the connection is successful or not, use the following command:  
   ```sh  
   # iwconfig wlan0  
   ```  
   For example, if connection is successful, we will see the output below:  
   ```sh  
   wlan0 IEEE 802.11bgn ESSID:"SSID" Nickname:""   
                  Mode:Managed Frequency:2.412 GHz Access Point: B0:A7:B9:C4:52:CA   
                  Bit Rate:39 Mb/s Tx-Power = 16 dBm   
                  Retry short limit:7 RTS thr:2353 B Fragment thr:2352 B   
                  Encryption key:off   
                  Power Management:off   
                  Link Quality = 80/80 Signal level = -28 dBm Noise level:0 dBm   
                  Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0   
                  Tx excessive retries:0 Invalid misc:0 Missed beacon:0  
   ```  
   If the connection is successful, then the connected Access point SSID along with the MAC address is displayed as shown above. If it is not connected to an Access point, a message "**Not Associated**" is displayed as shown below.  
   ```sh  
   wlan0 IEEE 802.11 ESSID:off/any   
                  Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm   
                  Retry short limit:7 RTS thr:off Fragment thr:off   
                  Encryption key:off   
                  Power Management:off  
   ```
6. The IP address for the SiWT917-STA can be set in two ways: either get the IP address dynamically from AP or set a static IP address. To obtain a dynamic IP address from AP, use the following commands:  
   ```sh  
   # dhclient wlan0 -r   
   # dhclient wlan0 -v  
   ```  
   To set the static IP address to SiWT917-STA, use the following command:  
   ```sh  
   # ifconfig wlan0 192.168.0.14  
   ```
7. To check whether IP address is assigned or not, use the following command:  
   ```sh  
   # ifconfig wlan0  
   ```  
   Output:  
   ```sh  
   wlan0: flags = 4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500   
                   inet 192.168.0.14 netmask 255.255.255.0 broadcast 192.168.1.255   
                   inet6 fe80::224:d7ff:fe56:54dc prefixlen 64 scopeid 0x20<link>   
                   ether 94:b2:16:98:ac:dc txqueuelen 1000 (Ethernet)   
                   RX packets 31160 bytes 31082515 (29.6 MiB)   
                   RX errors 0 dropped 0 overruns 0 frame 0   
                   TX packets 23356 bytes 3367496 (3.2 MiB)   
                   TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0  
   ```

Now, users can perform data transfer tests like ping, iperf, and so on.

##### Configure iperf and Test

**Iperf** was developed as a modern tool for measuring maximum TCP and UDP bandwidth. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, and datagram loss. Iperf can run as a client or a server according to the arguments passed to the iperf command.

Install iperf using the following commands:

```shell
##### sudo apt-get install iperf (for Ubuntu) 
##### sudo yum install iperf (for Fedora)
```

Or download and install the iperf application (for Windows) from [https://iperf.fr](https://iperf.fr/)

To run an iperf test, the iperf application should be installed on the PC/laptop and the Raspberry Pi 4 integrated with SiWT917 as follows:

![Throughput Setup Diagram](/wifi-siwt917-rcp-wi-fi-throughput/1.3/images/an1446-throughput-setup-diagram.jpg)

The above diagram shows SiWT917 RCP configured as SiWT917 STA and connected to “ASUS TUF Gaming AX5400 Dual-band Wi-Fi 6” over Wi-Fi. We will measure the uplink and downlink bandwidth using both TCP and UDP.

###### TCP Rx

> **Note**:
> 
> - IP of SiWT917-STA is 192.168.0.14
> - IP of PC/laptop connected to access point is 192.168.0.2

Run the following commands to run TCP data transfer:

- For Raspberry Pi 4 integrated with SiWT917 RCP: iperf -s -i 1
- For Dell Laptop Latitude 3520: iperf -c 192.168.0.14 -i 1 -t 10

![Command run result](/wifi-siwt917-rcp-wi-fi-throughput/1.3/images/an1446-7-1.jpg)

###### TCP TX

Run the following commands to run TCP data transfer:

- For Dell Laptop Latitude 3520: **iperf -s -i 1**
- For Raspberry Pi 4 integrated with SiWT917 RCP: **iperf -c 192.168.0.2 -i 1 -t 10**

![Command run result 2](/wifi-siwt917-rcp-wi-fi-throughput/1.3/images/an1446-7-2.jpg)

###### UDP Rx

Run the following commands to run UDP data transfer:

- For Raspberry Pi 4 integrated with SiWT917 RCP: **iperf -s -u -i 1**
- For Dell Laptop Latitude 3520: **iperf -c 192.168.0.14 -i 1 -t 10 -u -b -50M**

![Command run result 3](/wifi-siwt917-rcp-wi-fi-throughput/1.3/images/an1446-7-3.jpg)

###### UDP Tx

Run the following commands to run UDP data transfer:

- For Raspberry Pi 4 integrated with SiWT917 RCP: **iperf -c 192.168.0.2 -i 1 -t 10 -u -b 50M**
- For Dell Laptop Latitude 3520: **iperf -s -u -i 1**

![Command run result 4](/wifi-siwt917-rcp-wi-fi-throughput/1.3/images/an1446-7-4.jpg)

##### Expected Results

Application data throughput up to 50 Mbps (Hosted Mode) in 802.11ax.

<table>
    <thead>
        <tr>
            <th rowspan="3">S.N.</th>
            <th rowspan="3">Operating Mode</th>
            <th rowspan="3">Actual Operation Mode (Dependent on User Test Case)</th>
            <th rowspan="3">Band (GHz)</th>
            <th rowspan="3">Channel Width</th>
            <th colspan="4">Protocol</th>
        </tr>
        <tr>
            <th colspan="2">TCP</th>
            <th colspan="2">UDP</th>
        </tr>
        <tr>
            <th>Uplink</th>
            <th>Downlink</th>
            <th>Uplink</th>
            <th>Downlink</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1.</td>
            <td>Wi-Fi_STA Only</td>
            <td>STA mode</td>
            <td>2.4</td>
            <td>20</td>
            <td>46.2</td>
            <td>52.6</td>
            <td>61.1</td>
            <td>66.2</td>
        </tr>
        <tr>
            <td>2.</td>
            <td>Wi-Fi_AP Only</td>
            <td>AP mode</td>
            <td>2.4</td>
            <td>20</td>
            <td>38</td>
            <td>41.9</td>
            <td>45.6</td>
            <td>52.8</td>
        </tr>
        <tr>
            <td>3.</td>
            <td rowspan="2">STA+AP</td>
            <td>STA mode</td>
            <td>2.4</td>
            <td>20</td>
            <td>34.3</td>
            <td>47.5</td>
            <td>52.7</td>
            <td>57.7</td>
        </tr>
        <tr>
            <td>4.</td>
            <td>AP mode</td>
            <td>2.4</td>
            <td>20</td>
            <td>25</td>
            <td>22.7</td>
            <td>33.4</td>
            <td>49.8</td>
        </tr>
        <tr>
            <td>5.</td>
            <td>Wi-Fi_STA + BT LE</td>
            <td>STA mode + BLE (Advertising mode)</td>
            <td>2.4</td>
            <td>20</td>
            <td>51</td>
            <td>53.4</td>
            <td>64</td>
            <td>37.9</td>
        </tr>
    </tbody>
</table>

> **Note**:
> 
> 1. The above mentioned throughput numbers are verified using SDIO on Raspberry Pi 4 in shielded chamber.
> 2. Wi-Fi throughput varies with the environment of the test setup: range, obstacles, type of obstacles, interference, and performance of the target platform.
> 3. For operating _mode, refer the following table for operating mode configuration.
>    |S.N.|Protocols Support|Operating Mode|
>    |---|---|---|
>    |1|Wi-Fi_alone_STA|1|
>    |2|Wi-Fi_alone_AP|1|
>    |3|BLE|8|
>    |4|Wi-Fi_STA + BLE|13|

##### Summary/Conclusion

By following the above procedures, SiWT917 RCP-STA can connect to a standard access point and check the Wi-Fi throughput.

##### Appendix A: Terminology

- **NL 80211 -** the new 802.11 netlink interface public header
- **TCP -** Transmission Control Protocol
- **UDP -** User Datagram Protocol
- **DHCP -** Dynamic Host Configuration Protocol
- **Uplink -** Data transfer from station (SiWT917 RCP) to access point
- **Downlink-** Data transfer from access point to station (SiWT917 RCP)
- **SiWT917-STA -** Station interface that is created for SiWT917 RCP after loading the driver
- **SiWT917-AP -** Access Point interface that is created for SiWT917 RCP after loading the driver

##### Appendix B: References and Related Documentation

Refer to [SiWT917 RCP Developers Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-overview/) and [Getting Started Guide](https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-getting-started/).

##### Appendix C: Troubleshooting

1. Ensure that the IP address is assigned for both PC/laptop (AP) and PC/laptop (SiWT917 RCP-STA) before running an iperf test.
2. Ensure that the STA is connected to the AP using the command **iwconfig**.
3. While running iperf, the server should start first, and then the client.
4. For SDIO detection:  
   ```sh  
   # cat /sys/bus/sdio/devices/mmcXXXXX/vendor  
   ```

#### AN1506: SiWx917 RCP Low Power

##### AN1506: SiWx917 RCP Low Power Application Note

Power is critical for any battery-operated wireless device. Based on the user application, the wireless device can be idle for more time or for a very short time. During this idle period, the wireless devices can be set to sleep to conserve battery power. The SiWT917 wireless device is an optimal ultra-low power wireless (WLAN and Bluetooth) solution for developing applications requiring long battery life.

This application note describes the SiWx917 Power Save modes, how to choose Power Save modes based on application requirements, and current consumption analysis during various operational modes in RCP mode. It also explains how to configure SiWT917 in different Power Save modes using example commands and power optimization techniques that reduce SiWT917’s current consumption.

###### Key Points

- SiWx917’s current consumption during various operational modes
- Choosing Power Save modes as per application requirements
- Supported commands and their usage
- Current measurement methods
- Power optimization techniques

###### Contents

- [Power Domains](power-domains)
- [Power States](power-states)
- [Active State Operational Modes](active-state-operational-modes)
- [Sleep State Operational Mode](sleep-state-operational-mode)
- [Power Save Mode](power-save-mode)

##### Power Domains

The following block diagram illustrates various power domains of the SiWx917 chip in RCP mode.

![A diagram of a computer AI-generated content may be incorrect.](/wifi-siwx917-rcp-low-power-application-note/1.1/images/an1506-image1.png "SiWx917 Power Domains")

The power domains of SiWx917 in RCP mode are:

- ThreadArch® Network Processor (hereafter referred to as "NWP"): The multi-threaded processor that runs wireless and network stacks on independent threads.
- Power Management Unit (hereafter referred to as PMU): Responsible for supplying power required by various sections of SiWx917.
- Wireless Modem (Radio): Includes Wi-Fi, Bluetooth, Analog front-end, 4 GHz RF transceiver, and integrated power amplifier subsystems.

##### Power States

The SiWT917 can be in one of the following power states:

- **Active state**: All the power domains are powered-on.
- **Sleep state**: The PMU and SRAM domains are powered-on, and the remaining power domains are powered-off. The SRAM's contents are retained.
- **Off state**: Most sections in the PMU are powered-off. More details about this state will be added in the next version.

The operational modes in Active state are explained in detail in [Active State Operational Modes](active-state-operational-modes) section. The operational mode in Sleep state is explained in detail in [Sleep State Operational Mode](sleep-state-operational-mode)

##### Active State Operational Modes

The SiWx917 can be in any of the three operational modes in its Active state. Each operational mode consumes a different amount of current.

- Transmit Mode
- Receive Mode
- Listen Mode

###### Transmit Mode

In the Transmit Mode, all the power domains of the SiWx917 are powered-on, except the receiver sections of the Base Band Processor (BBP), Analog Front End (AFE), and RF Front End (RFFE) domains. This is the highest power-consuming mode.

![Transmit Mode in Active State](/wifi-siwx917-rcp-low-power-application-note/1.1/images/an1506-image2.png "Transmit Mode in Active State")

###### Receive Mode

In the Receive Mode, the transmit sections of the BBP, AFE, and RFFE are powered-off.

![Receive Mode in Active State](/wifi-siwx917-rcp-low-power-application-note/1.1/images/an1506-image3.png "Receive Mode in Active State")

###### Listen Mode

This mode is a subset of the receive mode. In Listen Mode, the transmit sections of BBP, AFE, and RFFE are powered-off. Certain receive portions of the BBP and AFE are powered-off as no packet reception is in progress.

![Listen Mode in Active State](/wifi-siwx917-rcp-low-power-application-note/1.1/images/an1506-image4.png "Listen Mode in Active State")

##### Sleep State Operational Mode

The SiWx917’s Sleep state operational mode is called Ultra-low Power Mode with RAM Retention.

![Ultra-Low Power Mode with RAM Retention](/wifi-siwx917-rcp-low-power-application-note/1.1/images/an1506-image5.png "Ultra-Low Power Mode with RAM Retention")

- In the Ultra-low Power mode with RAM Retention, the Wireless Modem, NWP, Security, and Host Interface power domains are powered-off. The SRAM contents and its current state are retained.
- The PMU has control over the other sections of the chip.
- The always-on logic domain operates on a lowered supply and a 32 kHz low-frequency clock to reduce power consumption.
- The SiWx917 RCP's Host Interface is inactive and thereby the interface is activated each time SiWx917 wakes up.

##### Power Save Mode

The SiWx9117 modules broadly support Ultra-low Power mode as outlined below:

- Ultra-low Power (ULP) Mode: A majority of the module is powered off except for a small section which has a timer and interrupts logic for waking up the module. The module cannot respond to the Host processor's commands/requests unless and until it gets wake up because of timeout or because of an interrupt asserted by Host processor. The sleep entry/exit procedures in this mode are indicated to the Host processor through a packet-based handshake.
- In Wi-Fi, only the Client (Station) mode supports power save. By default, the module will be in a power save disable state. The user has to enable it explicitly.

###### Device Sleep Mode

For each of the above power save modes, the module supports the sleep modes outlined below:

- **Unconnected Sleep**: In Unconnected Sleep, the module is not connected to an access point (AP). This is defined by the <deep_sleep_wakeup_period> parameter of the PS command.
- **Connected Sleep**: In the connected state, the module can operate in Max PSP. These profiles are used by the module to decide when to enter and exit from power save modes on the fly. They have to be selected based on the performance and power consumption requirements of the end product.

###### Wakeup Procedures and Data Retrieval

When in power save mode, the module wakes up at periodic intervals or due to certain events (like pending transmit packets from the Host). At every wakeup, the module has to poll the access point and check whether there are any pending RX packets destined for the module. The module uses different protocols to retrieve data from the access point based on the protocol supported by the access point. These data retrieval methods (protocol-based) are used to further classify the power save profiles described in the previous section into Max PSP.

- **Maximum Power Save Polling (Max PSP)**: In this mode, the module wakes up at the end of the sleep period (Listen or DTIM interval) and retrieves pending RX packets from the sccess point by sending a PS-POLL packet. It also transmits any packets received from the Host processor and then goes back to sleep. The parameters listed below are used by the module to decide the period of sleep during power save, in the same order of priority:  
  1. <listen_interval_duration>  
  2. <dtim_interval_duration>  
  3. <num_beacons_per_listen_interval>  
  4. <num_dtims_per_sleep>

**Max PSP**:

- Whenever the AP receives data frames that are destined for a station (here, SiWx917), it buffers the frames.
- The AP informs the station by setting the corresponding station's AID in the TIM element of the next immediate beacon.
- On the next wakeup (based on DTIM or listen interval), the station receives the beacon and checks for the TIM.
- If the AID of the station is set, it sends a Power Save Polling (PS-Poll) frame with its AID to the AP to retrieve a data frame.
- The AP acknowledges the PS-Poll frame and transmits a data frame with the "More Data" field set to 1 in case there are more data frames buffered for the station.
- After receiving a data frame, the SiWx917 station sends it to the host.
- The station sends a PS-Poll frame to retrieve each data frame from the AP.
- While sending the last data frame to the station, the AP shall set the "More data" field to "0".
- After receiving the last data frame, the station goes back to sleep state.

The Max PSP saves more power but produces lower throughputs. If receiving a bulk amount of data, sending a PS-Poll frame to retrieve each frame affects the throughput and induces a considerable amount of delay.

- **Fast Power Save Polling (Fast PSP)**: This profile is a variant of the Traffic-based PSP, which exits power save mode even for a single packet and enters the power save mode if no packet is transferred for the <monitor_interval> amount of duration. This profile is enabled independently for the Transmit and Receive directions if the <tx_threshold> and <rx_threshold> parameters are assigned zero, respectively, while assigning a non-zero value to the <monitor_interval> parameter.

**Fast PSP**:

- Whenever the AP receives data frames that are destined for a station (here, SiWx917), it buffers the frames.
- The AP informs the station by setting the corresponding station's AID in the TIM element of the next immediate DTIM beacon.
- On the next wakeup (based on DTIM or listen interval), the station receives the beacon and checks for the TIM.
- If the AID of the station is set, the station exits power save mode, switches to active mode, and sends a Null data frame with PWR MGT bit set to "0" to the AP to retrieve all the data packets from AP.
- After receiving a data frame, the SiWx917 station sends it to the host.
- After receiving the last data frame, the station waits for the monitor interval time configured and checks for data frames from AP.
- If no data is to be received, the station goes back to sleep state by sending a Null data frame with the PWR MGT bit set to "1" to the AP.

The Fast PSP saves less power and produces better throughput when compared to the Max PSP. If both throughput and power save are important for your application, use Fast PSP.

###### Configuring ULP Device Power Save

Install the driver as follows to enable ULP power save.

```bash
  # insmod rsi_91x.ko rsi_zone_enabled=1 dev_oper_mode=<value> ps_sleep_type=2 ulp_handshake_mode=2
```

```bash
  # insmod rsi_sdio.ko
```

###### Enabling Power Save

The following are the commands used in the power save configuration.

1. Enable the power save:  
   ```bash  
   # iw dev <interface_name> set power_save on  
   ```
2. Disable power save:  
   ```bash  
   # iw dev <interface_name> set power_save off  
   ```
3. Check the power save status:  
   ```bash  
   # iw dev <interface_name> get power_save  
   ```  
   Here, the interface_name will vary from host to host. We can get the interface name with the following command:  
   ```bash  
   # iw dev  
   ```  
   For BT coexistence with Wi-Fi, give BT the power save command.  
   ```bash  
   # hcitool -I hci0 cmd <vendor command> <power save related> <power save ON/OFF> <ULP(0x02)/LP(0x01) power save> <sleep duration>  
   ```  
   Example:  
   ```bash  
   hcitool -i hci0 cmd 0x3f 0x0003 0x01 0x02 0xff  
   ```

###### Configure Power Save Parameters/ Profiles Through Debugfs Dynamically

The driver supports dynamic configuration of power save type and profile parameters using debugfs as explained below.

To update the power save parameter, use the following command:

```bash
##### echo <sleep_type> <tx_threshold> <rx_threhold> <tx_hysteresis> < rx_hysteresis> <monitor_interval> <listen_interval_duration> <num_beacons_per_listen_interval> <dtim_interval_duration> <num_dtims_per_sleep> <deep_sleep_wakeup_period> <uapsd_wakeup_period> >/sys/kernel/debug/phy<X>/ ps_params
```

The input parameters of the power save command are explained below.

- **<sleep_type>**: This parameter is used to select the sleep mode between LP (1) and ULP (2) modes.
- **<tx_threshold>**: If a non-zero value is assigned, this parameter is used to set a threshold for the Transmit throughput computed during the <monitor_interval> period so that the module can decide to enter (throughput ≤ threshold) or exit (throughput > threshold) the power save mode. The value is in Mbps and supported TX threshold is 0 to 10 Mbps.
- **<rx_threshold>**: If a non-zero value is assigned, this parameter is used to set a threshold for the Receive throughput computed during the <monitor_interval> period so that the module can decide to enter (throughput ≤ threshold) or exit (throughput > threshold) the power save mode. The value is in Mbps and supported RX threshold is 0 to 10 Mbps.
- **<tx_hysteresis>**: The decision to enter or exit power save mode based on the Transmit throughput alone can result in frequent switching between the power save and non-power save modes. If this is not beneficial, the <tx_hysteresis> parameter can be used to make the module re-enter the power save mode only when the throughput falls below the difference between the <tx_threshold> and <tx_hysteresis> values. The value is in Mbps and the minimum value is 0 Mbps. This parameter should be assigned a value which is less than the value assigned to the <tx_threshold> parameter.
- **<rx_hysteresis>**: The decision to enter or exit power save mode based on the Receive throughput which alone can result in frequent switching between the power save and non-power save modes. If this is not beneficial, the <rx_hysteresis> parameter can be used to make the module re-enter the power save mode only when the throughput falls below the difference between the <rx_threshold> and <rx_hysteresis> values. The value is in Mbps and the minimum value is 0 Mbps. This parameter should be assigned a value which is less than the value assigned to the <rx_threshold> parameter.
- **<monitor_interval>**: This parameter specifies the duration (in milliseconds) over which the Transmit and Receive throughput's are computed to compare with the <tx_threshold>, <rx_threshold>, <tx_hysteresis>, and <rx_hysteresis> values. The maximum value of this parameter is 30000 ms (30 seconds).
- **<listen_interval_duration>**: This parameter specifies the duration (in milliseconds) for which the module sleeps in the connected state power save modes. If a non-zero value is assigned to this parameter, it takes precedence over the other sleep duration parameters that follow (<num_beacons_per_listen_interval>, <dtim_interval_duration>, <num_dtims_per_sleep>). The maximum duration for which the device supports sleep is 4095 times the duration of the beacon interval considering the listen interval parameters of the access point. The maximum value for this parameter can be 65535, but the duration should be the deciding factor in the beacon interval of the access point. This parameter is considered only after the module is connected to the access point. For example, if the beacon interval of the AP is 100 ms and the listen interval of AP is 8 beacons, then the maximum time the device can sleep without any data loss is 800 ms (8 * 100). Hence, the listen_interval_duration can be up to 800 ms.
- **<num_beacons_per_listen_interval>**: This parameter specifies the number of beacon intervals for which the module sleeps in the connected state power save modes. Here, the device will wake up for the nth beacon, where n is the listen interval value programmed by the user. If a non-zero value is assigned to this parameter, it takes precedence over the other sleep duration parameters that follow (<dtim_interval_duration>, <num_dtims_per_sleep>). This parameter is used only when the above parameter is assigned to 0. The maximum value for this parameter is 4095. The value for this parameter also has to be chosen according to the listen interval of the access point. This parameter is considered only after the module is connected to the access point.
- **<dtim_interval_duration>**: This parameter specifies the duration (in milliseconds) for which the module sleeps in the connected state power save modes. The device will wake up for the nearest DTIM beacon after the time which the user has programmed expires. This parameter can be used when DTIM information is not available. If a non-zero value is assigned to this parameter, then it takes precedence over the other sleep duration parameter that follows (<num_dtims_per_sleep>). This parameter is used only when the above parameters are assigned 0. The maximum value for this parameter can be 10000 ms. This parameter is considered only after the module is connected to the access point.
- **<num_dtims_per_sleep>**: This parameter specifies the number of DTIM intervals for which the module sleeps in the connected state power save modes. This parameter has least priority compared to the ones above and is used only if the above parameters are assigned to 0. The maximum value for this parameter is 10. This parameter is considered only after the module is connected to the access point.
- **<deep_sleep_wakeup_period>**: This parameter specifies the duration (in milliseconds) for which the module sleeps in the Deep Sleep mode. For LP mode, a value of 0 for the <sleep_duration> parameter programs the module to be in Deep Sleep mode indefinitely until it is woken up by the Host processor via the host interface. The value of 0 is invalid for ULP mode and should not be used. The maximum value for this parameter can be 65535.  
  **Beacon Interval**
- The SiWx917 wakes every Beacon Interval (BI) configured in the AP. The more the Beacon Interval, the less frequent the SiWx917 wakes, thereby reducing the current consumption.
- The following figure illustrates the BI-based wakeup of SiWx917 for AP’s BI = 100 ms and DTIM period =3. In this case, the SiWx917’s wake interval = 100 ms.

![A diagram of a graph AI-generated content may be incorrect.](/wifi-siwx917-rcp-low-power-application-note/1.1/images/an1506-image6.png "Beacon Interval-based Wakeup")

###### DTIM Interval (heading level 7)

The SiWx917 wakes every DTIM Interval, as per DTIM period configured in the AP. The less the DTIM Interval, the less the RX latency to retrieve the buffered frames from AP.

The following figure illustrates the BI-based wakeup of SiWx917 for AP’s BI = 100 ms and DTIM period = 3. In this case, the SiWx917’s wake interval = 300 ms.

![A diagram of a graph AI-generated content may be incorrect.](/wifi-siwx917-rcp-low-power-application-note/1.1/images/an1506-image7.png "DTIM Interval-based Wakeup")

###### Target Wake Time (TWT)

Target Wake Time (TWT) is a feature introduced in Wi-Fi 6 (802.11ax) designed to improve the efficiency of wireless communication and a power-saving feature in Wi-Fi that allows devices to negotiate when and how frequently they wake up to transmit or receive data, improving battery life and overall network efficiency. It allows the access point to schedule wake timings for its connected stations, ensuring that no two Wi-Fi stations wake at the same time. This method helps avoid packet collisions, thus reducing retransmissions and, in turn, reducing the station's current consumption.

Here are some key benefits of TWT:

- **Reduced Power Consumption**: By adopting sleep times, TWT significantly extends battery life for devices.
- **Minimized Contention**: Scheduled uplink access reduces congestion among devices, ensuring smoother communication.
- **Optimized Performance**: TWT helps in maintaining efficient operation even in crowded network environments.

###### TWT Setup/Teardown

Follow the steps below for TWT Setup/Teardown in an open source driver.

1. Enable CONFIG_TWT_SUPPORT in both driver Makefile(rsi folder) and apps Makefile(apps/Makefile).
2. Compile the driver as follows.  
   ```bash  
   #make clean;make  
   ```
3. Insert the driver.  
   ```bash  
   #insmod rsi_91x.ko driver_mode_value=1 rsi_zone_enabled=<val> ...  
     
   #insmod rsi_sdio.ko  
   ```
4. Connect to third AP by following the command below.  
   ```bash  
   # wpa_supplicant -i <interface_name> -D nl80211 -c <sta_settings.conf> -ddddt > log1 &  
   ```
5. Go to the release folder.

To start or stop the TWT session, give the twt_config command command, which will trigger TWT Setup/Teardown frame:

```bash
##### ./onebox_util rpine0 twt_config<wake_duration><wake_duration_tolerance><wake_int_exp><wake_int_exp_tolerance><wake_int_mantissa><wake_int_mantissa_tolerance><implicit_twt><unannounced_twt><triggered_twt><negotiation_type><twt_channel><twt_protection><twt_flow_id><restrict_twt_outside_tsp><twt_retry_limit><twt_retry_interval><twt_req_type><twt_enable><wake_duration_unit>
```

**Example**:

```bash
##### ./onebox_util rpine0 twt_config 255 255 15 15 650 10 1 1 0 0 0 0 1 1 6 10 1 1 0
```

- **wake_duration**: This is the nominal minimum wake duration of TWT. This is the time for which DUT will be in wake state for Transmission or reception of data. Allowed values range is 0-255.
- **wake_duration_tol**: This is the tolerance allowed for wake duration in case of suggest TWT. Received TWT wake duration from AP will be validated against tolerance limits and decided if TWT config received is in acceptable range. Allowed values are 0-255.
- **wake_int_exp**: TWT Wake interval exponent. It is exponent to base 2. Allowed values are 0 - 31.
- **wake_int_exp_tol**: This is the allowed tolerance for wake_int_exp in case of suggest TWT request. Received TWT wake interval exponent from AP will be validated against tolerance limits and decided if TWT config received is in acceptable range. Allowed values are 0 - 31.
- **wake_int_mantissa**: This is the TWT wake interval mantissa. Allowed values are 0-65535.
- **wake_int_mantissa_tol**: This is the tolerance allowed for wake_int_mantissa in case of suggested TWT. Received TWT wake interval mantissa from AP will be validated against tolerance limits and decided if TWT config received is in acceptable range. Allowed values are 0-65535.
- **implicit_twt**: If enabled (1), the TWT requesting STA calculates the next TWT by adding a fixed value to the current TWT value. Explicit TWT is currently not allowed.
- **un_announced_twt**: If enabled (1), TWT requesting STA does not announce its wake up to AP through PS-POLLs or UAPSD trigger frames.
- **triggered_twt**: If enabled (1), at least one trigger frame is included in the TWT Service Period (TSP).
- **negotiation_type**: If disabled (0), the TWT requesting STA supports individual TWT. Broadcast TWT is currently not supported.
- **twt_channel**: Currently this configuration is not supported. Allowed values are 0-7.
- **twt_protection**: If enabled (1), TSP is protected. This is negotiable with AP. Currently not supported. Only zero is allowed.
- **twt_flow_id**: This is TWT flow ID.  
  - Range : 0-7 ( should be the same for setup and teardown. Otherwise, an error will be triggered).  
  - 0xff : To teardown all active sessions. This is valid only in Teardown TWT case.
- **restrict_tx_outside_tsp**: If enabled (1), any TX outside the TSP is restricted. Else, TX can happen outside the TSP also.
- **twt_retry_limit**: This is the maximum number of retries allowed if the TWT response frame is not recieved for the sent TWT request frame. Allowed values are 0 - 15.
- **twt_retry_interval**: The interval, in seconds, between two TWT request retries. Allowed values are 5 - 255.
- **req_type**: This is the TWT request type.  
  - 0 - Request TWT  
  - 1 - Suggest TWT  
  - 2 - Demand TWT
- **twt_enable**: If enabled (1), TWT setup frame is triggered or if disabled (0), TWT Teardown frame is triggered.
- **wake_duration_unit**: This parameter defines unit for wake_duration. Allowed values are 0 (256 μS) and 1 (1024 μS).

The following command provides the status of the ongoing TWT session.

```bash
##### ./onebox_util rpine0 twt_status
```

**TWT Command Status**

|Sr.No|STATUS|DESCRIPTION|
|---|---|---|
|1.|TWT_DEVICE_NOT_IN_CONNECTED_STATE|Occurs when the device is not connected to AP.|
|2.|TWT_SETUP_ERR_SESSION_ACTIVE|Occurs when user tries to give TWT setup command when there is already an active TWT session.|
|3.|TWT_TEARDOWN_ERR_FLOWID_NOT_MATCHED|Occurs when TWT teardown command is given with a flow ID that does not match existing session flow ID.|
|4.|TWT_TEARDOWN_ERR_NOACTIVE_SESS|Occurs when teardown command is given while there is no active session.|
|5.|TWT_SETUP_SESSION_IN_PROGRESS|Occurs when user tries to give TWT setup command when there is a TWT session already in progress.|
|6.|TWT_SESSION_SUCC|TWT session setup success. TWT session is active.|
|7.|TWT_UNSOL_SESSION_SUCC|Unsolicited TWT setup response from AP accepted. TWT session is active.|
|8.|TWT_SETUP_AP_REJECTED|TWT reject frame recieved in response for the sent TWT setup frame.|
|9.|TWT_SETUP_RSP_OUTOF_TOL|TWT response parameters from AP for when TWT suggest request is not within tolerance set by user.|
|10.|TWT_SETUP_RSP_NOT_MATCHED|TWT response parameters from AP for when TWT demand request does not match parameters given by user.|
|11.|TWT_SETUP_UNSUPPORTED_RSP|Unsupported TWT response from AP.|
|12.|TWT_TEARDOWN_SUCC|TWT session teardown success.|
|13.|TWT_AP_TEARDOWN_SUCC|TWT session teardown from AP success.|
|14.|TWT_SETUP_FAIL_MAX_RETRIES_REACHED|TWT setup request retried maximum number of times as configured by user.|
|15.|TWT_INACTIVE_DUETO_ROAMING|TWT session inactive due to roaming.|
|16.|TWT_INACTIVE_DUETO_DISCONNECT|TWT session inactive due to disconnect.|
|17.|TWT_INACTIVE_NO_AP_SUPPORT|TWT session inactive as connected AP does not support TWT.|

###### Reschedule TWT

Users can suspend and resume the current twt-session dynamically. Follow the steps below to reschedule TWT.

1. Check whether the TWT session is active or not using the command below.  
   ```bash  
   # ./onebox_util rpine0 twt_status  
   ```
2. If the TWT session is active, use the command below to reschedule TWT.  
   ```bash  
   # ./onebox_util rpine0 reschedule_twt twt_flow_id twt_action suspend_duration  
   ```
3. **twt_flow_id**: Active twt-session flow id.  
   **twt_action**: These are the types for twt_action:  
   - 0 - Suspend Indefinitely  
   - 1 - Suspend for duration  
   - 2 - Resume Immediately**suspend_duration**: Suspend TWT for a given interval. This should be a non-zero value only when twt_action is 1. Otherwise, it should be zero.
4. Check the reschedule_twt session status with the command below.  
   ```bash  
   # ./onebox_util rpine0 twt_status  
   ```

#### AN1507: SiWx917 RCP Manufacturing Utility

##### AN1507: SiWx917 RCP Manufacturing Utility Application Note

Manufacturing means programming production-specific information into the device. This application note provides information about the manufacturing procedure and the utility in SiWx917 RCP (referred to as SiWT917).

###### Key Points

- SiWx917 Manufacturing utility procedure
- Manufacturing information and device calibration
- Supported commands and its usage

###### Contents

- [Introduction](intro)
- [Requirements](requirements)
- [Setup Image](setup-image)
- [Installation](installation)
- [Working Commands](working-commands)
- [Troubleshooting](troubleshooting)

##### Introduction

Customer manufacturing software tool for SiWx917 RCP (SiWT917) can be used to update manufacturing information and perform device calibration on the fly. This document will provide information about the features and functionalities of the application.

##### Requirements

**Hardware**:

- [BRD4346A](https://www.silabs.com/development-tools/wireless/wi-fi/siwx917-rb4346a-wifi-6-bluetooth-le-soc-4mb-flash-radio-board?tab=overview) - SiWx917 Wi-Fi 6 and Bluetooth LE Co-Processor Radio Board (hereafter referred to as SiWx917 radio board)
- [BRD8045B](https://www.silabs.com/development-tools/wireless/wi-fi/raspberry-pi-hat-adapter-board-for-co-processor-radio-boards?tab=overview) - EXP Adapter Board for SiWx917 Co-Processors (hereafter referred to as adapter board)
- [Raspberry Pi 4](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/) with Raspberry Pi 4 OS for BRD8045B
- Windows /Linux/ Raspberry PI
- LAN cable

**Software**:

- [SiWx91x RCP Driver](https://github.com/SiliconLabs/si91x-rcp-driver)
- [Commander CLI](https://artifactory.silabs.net/ui/native/hwtools-releases/Software/Simplicity-Commander/1v16p15/)

##### Setup Image

![Setup Image](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-setup.png)

##### Installation

1. Download and unzip the [release package](https://github.com/SiliconLabs/si91x-rcp-driver).
2. Install the driver without loading the firmware using the following steps:  
   1. Search for the following line in Makefile and uncomment it:    
      _EXTRA_CFLAGS += -DNO_FIRMWARE_LOAD_SUPPORT_    
      ![Uncomment line](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image3.png)  
   2. Save the changes made in Makefile and compile the driver using the make command:    
      `#make clean;make`  
   3. After successful compilation, install all the dependencies.  
   4. Insert the modules using the following arguments:    
      1. modprobe mac80211    
      2. modprobe cfg80211    
      3. modprobe Bluetooth  
   5. Insert the kernel modules rsi_91x.ko and rsi_sdio.ko using the following commands:    
      1. `insmod rsi_91x.ko dev_oper_mode=1 rsi_zone_enabled=0x601 skip_fw_load=1`    
      2. `insmod rsi_sdio.ko`
3. Ensure that the driver is inserted correctly using dmesg. Use `dmesg` command to observe the prints.
4. The print should show "FIRMWARE LOADING SKIPPED", indicating that the driver did not load any firmware.  
   ![Firmware loading skipped](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image4.png)
5. Once the driver is installed, download the [Simplicity Commander](https://artifactory.silabs.net/ui/native/hwtools-releases/Software/Simplicity-Commander/1v16p15/) onto your host.
6. Unzip the commander to the directory of your choice.
7. Navigate to the release directory (driver path) where the mfg application is present after using the make command (for example, `SiWT917.x.x.x.x/release/`).
8. Open a terminal and run the application using `./mfg`. The output should be as shown below:  
   ![./mfg output](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image5.png)
9. Open another terminal and navigate to the path where the commander-cli was previously extracted as per step 6.  
   ![Navigate to commander-cli](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image6.png)
10. Type the commands described in section 5 to perform read or write operations for the different memory regions from the commander-cli path.

##### Working Commands

> **Note**:
> 
> 1. Before proceeding, make the connections as shown in [Setup Image](setup-image).
> 2. Get the IP address of the DUT using ipconfig or ifconfig.
> 3. For any command that is used, the port number always remains 51917.

###### Init

This command is used to generate an activation code. Once generated, the firmware will burn this activation code into flash.

**Command syntax**: `commander manufacturing init --mbr <filename.bin|default> --data <updated-mbr-fields> -d < OPN Number > [--skipload] [--pinset n]`

**Example**:`commander manufacturing init –host 192.168.10.100:51917 –serialinterface –device SiWG917M100MGTBA`

|Fields|Description|
|---|---|
|`init`|Generate the activation code.|
|`--mbr <filename.bin | default>`|Binary file to read the MBR data from. If "default", the MBR data will be populated from a template for the connected device.|
|`--data <filename>`|JSON containing MBR fields to update the MBR with.|
|`-d <full opn>`|Provide OPN number (for example, SiWG917M100MGTBA).|
|`--pinset <index>`|By default, pinset value is 0.|
|`--skipload`|Skip loading the TA provisioning firmware.|

![Init Command](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image7.png)

###### Read

This command is used to read the specified memory region from the DUT and save it to a file.

**Command syntax**:`commander manufacturing read <tambr|taipmu|m4mbrcf|m4mbrdf|m4ipmucf|m4ipmudf|efuse|efusecopy|efuseipmu> --out <filename.bin|filename.json> -d <OPN Number>`

**Example**:`commander manufacturing read tambr –output –host 192.168.10.100:51917 --serialinterface --device SiWG917M100MGTBA`

|<region>|Information|
|---|---|
|`tambr`|Read the TA flash MBR data available for memory region.|
|`m4mbrcf`|Read the common flash M4 MBR data.|
|`m4mbrdf`|Read the dual flash M4 MBR data.|
|`m4ipmucf`|Read the common flash M4 ipmu data.|
|`m4ipmudf`|Read the dual flash M4 ipmu data.|
|`--out <filename>`|Store the read data in. "*.bin", or "*.json" if a JSON parser is available for this memory.|
|`taipmu`|Read the TA flash ipmu data available for memory region.|
|`efuse`|Read the OTP data.|
|`efusecopy`|Read the efusecopy data in flash.|
|`efuseipmu`|Read the ipmu data from OTP/eFuse.|
|`-d <full opn>`|Provide OPN number (for example, SiWG917M100MGTBA).|

![Read Command](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image8.png)

###### Write

This command is used to write to the specified memory region in DUT. If the file is provided in binary form, it will be flashed verbatim. If it's provided as JSON, it will be considered an update to the flash content.

**Command syntax**: `commander manufacturing write <region> --data <filename.bin|filename.json> -d < OPN Number > [--skipload] [--pinset n]`

**Example**:`commander manufacturing write tambr –data resources/jlink/Si917/ta_mbr_SiWG917M100MGTBA.bin --pinset 0 --host 192.168.10.100:51917 --serialinterface --device SiWG917M100MGTBA`

|Field|Description|
|---|---|
|`--data <filename.bin|filename.json>`|Provide MBR file.|
|`-d <full opn>`|Provide OPN number (for example, SiWG917M100MGTBA).|
|`--pinset <index>`|By default, pinset value is 0. Select pinset for external flash configurations.|
|`--skipload`|Skip loading the TA provisioning firmware.|

![Write Command](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image9.png)

###### Provision

This command is used to flash the MBR content for a selected region or to recover the board. MBR (filename.bin) files are present at the following path.

Path: "Commander_win32_x64_1v15p3b1357\Simplicity Commander\resources\jlink\Si917"

**Command syntax:** `commandermanufacturing provision --mbr <filename.bin|default> -d <OPN Number>`

**Example:**`commander manufacturing provision –mbr resources/jlink/Si917/ta_mbr_SiWG917M100MGTBA.bin --pinset 0 --host 192.168.10.100:51917 --serialinterface --device SiWG917M100MGTBA`

!["Provision Command"](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image10.png)

###### Channel and Power (Radio)

This command is used to set the channel and power to the device.

**Command syntax**:`commander manufacturing radio [--channel <1-14>] [--power <1-31/127>] [--phy <xMBPS,MCSn,CW>] [--vmcu18] [--noburst] [--internalant] [–stop|–start] [–serialinerface ] [–skipinit] -d <OPN Number>`

**Example**: `commander manufacturing radio –channel 1 –power 10 –phy 1MBPS –start –host 192.168.10.100:51917 –serialinterface -d SiWG917M100MGTBA`

|Field|Description|
|---|---|
|`start`|Turn ON the radio transmission.|
|`stop`|Turn OFF the radio transmission.|
|`noburst`|Transmission will happen continuously instead of being in bursts.|
|`internalant`|Select virtual internal switch. By default, the external antenna switch is used.|
|`vmcu18`|Selects parameters for operation at 1.8 V.|

![Channel and Power Command](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image11.png)

###### Xocal

This command adjusts the tuning to compensate for the specified frequency offset and initiates the radio based on the current configuration, which must be set before this command.

**Command syntax**: `commander manufacturing xocal [--ctuneoverride <ctune value>] [--offset <frequency offset in kHz>] [–-store] [–storeinefuse] [–serialinerface ] [–skipinit] -d <OPN Number>`

**Example**:`commander manufacturing xocal –host 192.168.10.100:51917 –store --serialinterface -d SiWG917M100MGTBA`

|Field|Description|
|---|---|
|`store`|Computed values are stored in flash.|
|`storeinefuse`|Computed values are stored in eFuse.|

![Xocal Command 1](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image12.png)

![Xocal Command 2](/wifi-siwx917-rcp-manufacturing-utility-application-note/1.1/images/an1570-image13.png)

##### Troubleshooting

- If any timeout occurs, remove the modules and re-insert them before trying to re-run the application.
- Verify if the right commander-cli is present according to the system architecture.
- Ensure that the right IP address has been specified while running the commands.
- If write is being performed after a previous write is already done, the `--skipload` flag must be added at the end to prevent firmware loading.
- The flag used to skip device init is `–-skipinit`.
- XOCAL and RADIO commands should be run first after installing the driver or else it will result in a timeout or error.
- During the initial write command, the `--skipload` flag must not be used.
- Ensure that you are using the right bin for the specified purpose. Bin files are usually present in `<path-to-commander>/resources/jlink/Si917/`.