Please find below useful information and links to get started with the WGM160P Wi-Fi module:
Examples running on the WGM160P are provided on GitHub: https://github.com/SiliconLabs/wfx-fullMAC-tools
They use the FMAC driver also available on GitHub: https://github.com/SiliconLabs/wfx-fullMAC-driver
The driver documentation is available on docs.silabs.com: https://docs.silabs.com/wifi/
In addition, you can find the WGM160P Wi-Fi commissioning example getting started: https://docs.silabs.com/wifi/wf200/content-source/getting-started/silabs/wgm160/getting-started
Make sure the WGM160P you have has the correct bootloader: https://github.com/SiliconLabs/wfx-fullMAC-tools/blob/master/Examples/SiliconLabs/shared/wgm160p/bootloader/README.md
Another useful WGM160P getting started using Micrium OS could be found here:
For WF200, WFM200 or WGM160P, the firmware uses by default the Relative CCA mode which automatically set the CCA level.
This default mode is not recommended to pass the CE RF certification and for this certification the Absolute CCA mode shall be selected.
If you are using the Full-MAC API this could be set with SL_WFX_CCA_THR_MODE_ABSOLUTE using this https://docs.silabs.com/wifi/wf200/rtos/latest/group-g-e-n-e-r-a-l-d-r-i-v-e-r-a-p-i#ga033dca6edbef96e4042d500a10dff9d8
if you are using Lower MAC and Linux driver wfx then you could modify the CCA mode sending a specific frame after the firmware download like this (within a root session only):
# Absolute CCA mode : echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x01\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
In order to revert CCA mode in default mode Relative, you could do this below or to reload the firmware:
# Relative CCA mode : echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x00\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
Note in the above path, the * in "phy*" could be replaced by an index depending of your target.
This is also indicated in the UG395 in section 8.3 but it could be useful for WF200 or WGM160P.
Off course, the 2.4GHz coexistence is a sharing and so the throughput and/or packet delay could be impacted for both or for one device. It will be difficult to target high throughput and short delay with two or more devices sharing the 2.4 GHz. If you target moderate Wi-Fi throughput like 5 or 10 Mbps then the sharing should be easy. If you target low Wi-Fi throughput then may be the PTA is not always useful but the interface could be connected for future usage in case of need.
We recommend to add Test Points on used PTA signals to debug and check the configuration on both devices is Ok.
Note with EFR32 using BLE or Zigbee, only the 3 wires PTA interface is currently available but the 4 wires could be connected for future usage. You could refer to these Application Notes below :
Wi-Fi Knowledge Base
WGM160P : get started with open software using FullMAC driver
Please find below useful information and links to get started with the WGM160P Wi-Fi module:
Another useful WGM160P getting started using Micrium OS could be found here:
https://www.silabs.com/community/wireless/wi-fi/forum.topic.html/wgm160p_getting_startedwithmicriumosandfullma-vRQD
WF(M)200 : Relative and Absolute CCA Modes for RF certifications
For WF200, WFM200 or WGM160P, the firmware uses by default the Relative CCA mode which automatically set the CCA level.
This default mode is not recommended to pass the CE RF certification and for this certification the Absolute CCA mode shall be selected.
If you are using the Full-MAC API this could be set with SL_WFX_CCA_THR_MODE_ABSOLUTE using this https://docs.silabs.com/wifi/wf200/rtos/latest/group-g-e-n-e-r-a-l-d-r-i-v-e-r-a-p-i#ga033dca6edbef96e4042d500a10dff9d8
if you are using Lower MAC and Linux driver wfx then you could modify the CCA mode sending a specific frame after the firmware download like this (within a root session only):
# Absolute CCA mode :
echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x01\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
In order to revert CCA mode in default mode Relative, you could do this below or to reload the firmware:
# Relative CCA mode :
echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x00\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg
Note in the above path, the * in "phy*" could be replaced by an index depending of your target.
This is also indicated in the UG395 in section 8.3 but it could be useful for WF200 or WGM160P.
WF(M)200 RF Coexistence and PTA usage with another 2.4GHz device
This short KBA provides some key links related to RF coexistence recommendations with WF200, WFM200 and WGM160P.
WF(M)200 implements a PTA arbiter which allows to improve the RF coexistence with another 2.4GHz device. This is very useful when the product is small with co-located antenna. The following link provides an application note on this topic: https://docs.silabs.com/wifi/wf200/content-source/application-note/wifi-coexistence
Even when implementing managed coexistence with PTA mechanism, you should take care to unmanaged coexistence principles : https://docs.silabs.com/wifi/wf200/content-source/application-note/wifi-coexistence#unmanaged-coexistence
Off course, the 2.4GHz coexistence is a sharing and so the throughput and/or packet delay could be impacted for both or for one device. It will be difficult to target high throughput and short delay with two or more devices sharing the 2.4 GHz. If you target moderate Wi-Fi throughput like 5 or 10 Mbps then the sharing should be easy. If you target low Wi-Fi throughput then may be the PTA is not always useful but the interface could be connected for future usage in case of need.
We recommend to add Test Points on used PTA signals to debug and check the configuration on both devices is Ok.
Note with EFR32 using BLE or Zigbee, only the 3 wires PTA interface is currently available but the 4 wires could be connected for future usage. You could refer to these Application Notes below :
A general learning-center Wi-Fi coexistence page: