Sona™ IF573 - Wi-Fi 6E + Bluetooth® 5.4 Module

Yes, If you decide to use NetworkManager, then systemd-networkd should be removed from the system. We would recommend changing Yocto systemd PACKAGECONFIG to not build it into image.

Wi-Fi MIMO requires the use of two Wi-Fi antennas, hence 2 antennas is the minimum.

If the application the IF573 is used in demands the use of Bluetooth as well a third antenna is required.

For performance reasons the Bluetooth part of the IF573 has its own antenna.

Yes, the Sona-IF573 supports Virtual Simultaneous Dual Band (VSDB) operation.

In an AP and STAion (APSTA) kind of application it is necessary to bring up up the access point (AP) in one band before connecting as a STAtion in the other band.

Infineon does not support monitor mode on any of the chips that Ezurio choose, i.e. IF573, LWB(5) and LWB(5)+ series.

Need to add libgpiod, libgpiod-dev and libgpiod-tools.

libgpiod containing libgpiod.so* files

libgpiod-dev containing /usr/include for the header files and /usr/lib for the shared lib's solink file and corresponding pkgconfig metadata.

libgpiod-tools containing gpiodetect, gpioget, …

No need to have extra AC coupling capacitors in these pins due to already in M.2 card itself.

After building a default image for the NXP i.MX8 LPDDR4 DVK device tree is such that M2 slot provides PCIe connectivity.

However, SDIO device tree is generated and available in the image.

The parameter "fdtfile=" in U-Boot needs to be changed.

Change "fdtfile=imx8mp-evk-revb4.dtb" to "fdtfile=imx8mp-evk-usdhc1-m2.dtb" by:

u-boot=> setenv fdtfile imx8mp-evk-revb4-usdhc1-m2.dtb
u-boot=> saveenv

Reference:

root@imx8mp-lpddr4-evk:~# ls /dev/mmc*
/dev/mmcblk2       /dev/mmcblk2boot0  /dev/mmcblk2boot1  /dev/mmcblk2p1     /dev/mmcblk2p2     /dev/mmcblk2rpmb
root@imx8mp-lpddr4-evk:~# mount /dev/mmcblk2p1 /media/
root@imx8mp-lpddr4-evk:~# ls /media | grep usdhc
imx8mp-evk-revb4-usdhc1-m2.dtb
imx8mp-evk-usdhc1-m2.dtb

The Ezurio Sona IF573 can work in Access Point mode, but there are limitations depending on the band used.

2.4 GHz Band

The IF573 will work in AP mode or AP/Sta mode in the 2.4 GHz.

5 GHz Band

The IF573 will work as AP mode or AP/Sta mode in the U-NII-1 bands (5.170 GHz to 5.250 GHz). The IF573 does not have the RADAR chip that is needed for DFS to be used as an AP in the other U-NII bands.

6 GHz

The IF573 is classified as an Indoor Client Access Class device. This means that it cannot be used in AP or AP/Sta mode in the 6 GHz band. It can only be used as a client.

One of the new features in Wi-Fi 6 is a longer guard interval. The guard interval is used to help mitigate multipath or overlapping transmissions. This is done by adding a delay between symbols (set of 0s and 1s). The shorter the guard interval theoretically the faster the throughput but you are more susceptible to multipath due to metal and other reflective surfaces.

Wi-Fi 4 and 5 supported two guard intervals:

• Short - 0.4 microseconds
• Long - 0.8 microseconds

Wi-Fi 6 supports 3 guard intervals:

• Normal - 0.8 microseconds
• Double - 1.6 microseconds
• Quadruple - 3.2 microseconds

In Wi-Fi 6 the 1024-QAM allows up to a 4x longer symbol duration than in Wi-Fi 5, so the efficiency is still similar to Wi-Fi 5 even with Quadruple guard interval.

What guard interval should I use for various use cases?

A general rule of thumb should be:

• Normal - Use this in a clean open area without a lot of metal. This would also best be used outdoors. Normal Guard Interval is the best choice when throughput is of the utmost importance.
• Double - This is a good compromise between Normal and Quadruple. It will not provide as good of throughput as Normal but will reduce the likelihood of multipath in areas that are smaller or have some metal.
• Quadruple - This would be used in small areas or areas with a lot of metal. This would also be the best choice in areas with a lot of clients to reduce the overhead of retrying packets.

All of the Wi-Fi 6 features are supported in the 2.4 GHz band in a Wi-Fi 6 radio.

This was not the case in Wi-Fi 5. It reverted back to Wi-Fi 4 in the 2.4 GHz channels.

To better help to utilize the spectrum Access Classes have been added. This better defines how specific devices operate in specific environments.

There are currently 4 Access Classes in Wi-Fi 6E:

• Standard Power (Indoor/Outdoor)
• Low Power
• Client (Indoor/Outdoor)
• Very Low Power (Indoor/Outdoor)

Standard Power (Indoor/Outdoor)

• This is the only access class that supports Access Points to be used outdoors.
• Can also be used indoors as long as all the requirements are met.
• Has a max power of 36 dB EIRP.
• Access Points must be coordinated through an Automated Frequency Coordination (AFC) service to make sure that it does not interfere with other devices in the area.
• Limited to UNII-5 and UNII-7 bands.
• Not used in all countries/regions. Please check the requirements of your specific country/region for more details.

Low Power (Indoor)

• Also referred to as LPI.
• Max Power is expressed as Power Spectral Density (PSD)
• PSD is 5 dBm/MHz. This means the power is higher as the channel gets wider. In general PSD is:
• 20 MHz wide channel - 18 dBm EIRP
• 40 MHz wide channel - 21 dBm EIRP
• 80 MHz wide channel - 24 dBm EIRP
• 160 MHz wide channel - 27 dBm EIRP
• Can operate in UNII-5, UNII-6, UNII-7 and UNII-8 bands but only indoors.
• There are certain device restrictions in place to make sure that devices are only used indoors:
• Cannot use a removable antenna. It must be integrated to the device.
• Devices cannot have a weatherized enclosure.
• Devices must be line powered and cannot use a battery.

Very Low Power (Indoor/Outdoor)

• Also known as VLP.
• Can operate in UNII-5, UNII-6, UNII-7 and UNII-8 bands either indoors or outdoors.
• Designed for mobile devices.
• Power Spectral Density limit is -8 dBm/MHz.

Clients (Indoor/Outdoor)

• Can operate in UNII-5, UNII-6, UNII-7 and UNII-8 bands either indoors or outdoors.
• Power must be 6 dB lower than the max EIRP of the Access Point it is associated to.

Wi-Fi 6E has added up to 1.2 GHz of new usable spectrum. It is broken up to these specific bands:

• UNII-5 - 5.925 GHz to 6.425 GHz.
• UNII-6 - 6.425 GHz to 6.525 GHz
• UNII-7 - 6.525 GHz to 6.875 GHz
• UNII-8 - 6.875 GHz to 7.125 GHz

Note: Not all countries/regulatory regions use all of the spectrum allowed. Please check the requirements of your specific regions.

Wi-Fi 6E is a new band that was added with the introduction of Wi-Fi 6. This allows the use of 6 GHz spectrum.

What are the benefits of Wi-Fi 6E?

• More capacity - The use of 6 GHz allows for up to 1.2 GHz of new spectrum.
  
  Note: Not all countries/regulatory regions use all of the spectrum allowed. Please check the requirements of your specific regions.
• More Channels - With the additional frequencies this allows for more channels:
  • Up to 59 20 MHz wide channels.
  • Up to 29 40 MHz wide channels.
  • Up to 14 80 MHz wide channels.
  • Up to 7 160 MHz wide channels.
• No Legacy Devices - The 6 GHz band requires the use of Wi-Fi 6E and OFDMA, so no legacy devices will be able to use the channels. Meaning that there is not any slowdown due to having to support older devices.
• No interference from Microwave Ovens - The 6 GHz band is outside of the frequencies of microwave ovens, so it is not susceptible to interference from them.

What are the drawbacks of Wi-Fi 6E?

• Range - The 6 GHz has a shorter wavelength than 2.4 GHz or 5 GHz, so it will not broadcast as far.
• Interference - With a shorter wavelength, it is not as good at penetrating walls and other obstructions as 2.4 GHz and 5 GHz can.

This may be caused by a non-standard pin-out on your SOM platform M.2 connector. Most likely it is the SUSCLK pin not being tied to a 32kHz clock source.

• 1) The host platform MUST provide a 32KHz clock to the SUSCLK pin on the M.2 interface on pin 50 of the M.2 connector.

Additionally:

• 2) The host platform MUST provide control for the W_DISABLE2# pin on the M.2 interface if Bluetooth is to be supported. This signal is connected to BT_REG_ON and is a hardware reset/power enable for the Bluetooth core. This signal is pulled down internally, holding the BT core in reset by default.

• 3) The host platform SHOULD provide control for the W_DISABLE# on the M.2 interface for optimal power control. There is a pull-up on this signal on the M.2 card that allows the Wi-Fi core to power up automatically if control is not provided.

• 4) The host platform MUST implement RTS/CTS hardware flow control if Bluetooth is to be supported. These signals must be controlled in conjunction with W_DISABLE2#/BT_REG_ON to put the radio into firmware download mode.

This is most likely caused by the "PCIEASPM" kernel config option being set to "SuperPowerSave." To fix this, set this option to "Performance" in menuconfig before building your kernel.

Additional Information

The PCIEASPM kernel configuration option in Linux stands for PCI Express Active State Power Management. This feature is used to manage the power consumption of devices connected through the PCI Express (PCIe) interface, which is commonly used for a wide range of components including Wi-Fi devices.

Overview of PCIEASPM:

1) Purpose:

• The main goal of PCIEASPM is to reduce power consumption when the PCIe devices are not in full use. This is particularly important in battery-powered devices like laptops but is also beneficial in reducing overall energy consumption in servers and desktops.

2) Functionality:

• Active State Power Management (ASPM) manages the power usage of PCIe devices by dynamically adjusting the power state based on current usage. It has several states, from L0 (fully on) to L1 (low power) and L2 (off).
• The states are managed automatically by the operating system and hardware, depending on the current needs of the device.

3) Configuration Options:

• PCIEASPM can typically be configured with three settings:
  • Default: The default setting uses the BIOS or firmware settings for ASPM.
  • Powersave: This setting aggressively uses ASPM to save power, which might lead to increased latency in devices.
  • Performance: This setting minimizes the use of ASPM to reduce potential latency, at the cost of higher power consumption.

4) Considerations:

• While ASPM is designed to save power, it can sometimes cause issues with Wi-Fi hardware, leading to instability or performance degradation.
• In some cases, users may choose to disable ASPM entirely if it causes compatibility issues with Wi-Fi PCIe devices.

5) Setting PCIEASPM:

• The PCIEASPM setting can be configured when compiling the kernel or passed as a boot parameter (e.g., pcie_aspm=off to disable it).

6) Impact on Performance:

• The impact of ASPM on system performance can vary. While it can save power, the transition between power states can introduce latency. For high-performance computing, the added latency might be undesirable.

Conclusion:

The PCIEASPM setting is a part of the Linux kernel's approach to power efficiency and management. It's particularly relevant for systems where power saving is a priority, but it should be used with an understanding of the potential trade-offs in terms of compatibility and performance.

There was a change in kernel 5.19 and higher, lrd-11 is built against the kernel 6.1 kernel backports), where there is a requirement to add cfg80211 to your image as a module (m) in the base platform kernel configuration. It must not be left out and must not be included as built-in (y). Networking support->Wireless->cfg80211 - wireless configuration API

There was a change in kernel 5.19 and higher, lrd-11 is built against the kernel 6.1 kernel backports), where there is a requirement to add cfg80211 to your image as a module (m) in the base platform kernel configuration. It must not be left out and must not be included as built-in (y).

• Networking support->Wireless->cfg80211 - wireless configuration API

I am seeing an error: error: 'struct net_device' has no member named 'ieee80211_ptr' while trying to build the lrd-11.0 release in Yocto.

This is due to a change in kernel 5.19 and higher, (lrd-11.0 is built against 6.1 kernel backports), where there is a requirement to add cfg80211 to your image.

To accomplish this:

1. Edit your kernel configuration by entering

   bitbake -c menuconfig virtual/kernel

2. Edit Networking support/Wireless and set cfg80211 to "M" for module
3. Save your changes.
4. Run your build again.

Yes, Laird Wifi modules can be integrated with OpenWRT like with other Linux operating systems.

See Lairds "Guide" Section for an example:

https://www.ezurio.com/documentation/application-note-how-to-integrate-the-60-series-wifi-module-with-openwrt

No. The creation of 6GHz soft APs is not supported due to the complexity of regulations and testing for APs in the 6GHz band.

Yes, it's mandatory to do this. 

While you design IF573 PCB module, need to have a GPIO to control BT_REG_ON; with M.2 module, wire to W_DISABLE2. During BT firmware download, need to have reset signal to indicate the firmware loading event.

Here is an example of the script to download BT firmware.

#!/bin/sh
# de-assert BT_REG_ON (assert W_DISABLE2# on M.2 interface)
gpioset 5 7=0
sleep 0.1

# Start firmware download in background

brcm_patchram_plus --no2bytes --autobaud_mode --baudrate 921600 \
                   --use_baudrate_for_download --enable_hci \
                   --patchram /lib/firmware/cypress/CYW55560A1.hcd /dev/ttymxc0 &

# assert BT_REG_ON (de-assert W_DISABLE2# on M.2 interface)
sleep 0.1
gpioset 5 7=1

The Sona-IF573 is the first Laird Wifi module that introduces "Fast Virtual Simultaneous Dual Band Operation" that allows for being connected in the 2.4GHz band as a client as well as in the 5GHz band.

It is also thinkable to open a soft AP in one band while being connected as a client in the other.

In 2.4GHz and 5GHz bands, the answer is yes. However, in 6GHz band, according to the WiFi 6E spec, only SAE or OWE is supported, not included PSK.

There are several patches from Infineon for SAE mode and 6GHz band related. Unless you want to patch all of these by yourself, otherwise need to use Laird summit supplicant to make it work properly.

Yes, this will be supported in IF573.

No, the traditional btattach implementation for BT serial interfaces that relies on vendor specific modules in the kernel is not sufficient because it has no mechanism to incorporate BT_REG_ON/W_DISABLE2# control.

Yes, it's mandatory to enable CTS/RTS in UART, otherwise BT firmware won't be loaded.

Transition mode is to support WPA2 and WPA3 at the same time. In 6GHz band, WPA2 is no longer supported, but just WPA3, and no support of transition mode as well.

According to WI-Fi alliance, only H2E mode is supported in WPA3. It's no longer possible to use HNP (hunt/peck).

In the Regulatory Tools package you receive there are many files. The filename structure is:

{radio-type}-{toolchain}-{version}.tar.bz2

For example, the file mfg60n-arm-eabihf-10.135.0.6.tar.bz2 would be for our 60 Series radio running on a system with a GNU Embedded Application Binary Interface (High Float) running version 10.135.0.6 of the Laird firmware. 

An easy way to determine your toolchain is to use the command:

ls -l /ld-linux*

For Regulatory Testing you will be required to load a special firmware to put the radio into "Test Mode". The code for our Wi-Fi modules is available-by-request by opening a case with our Support Team at https://www.lairdconnect.com/resources/support.