The BRD8022A provides a way to do current measurement (the same way is possible with the BRD8023A for WFM200).

The snapshot below provides the top overview of the BRD8022A board where U1 is the WF200:

In the blue circle, there is a way to do current measurement of the WF200. The schematic of this part is described below :

The R616 is a 0.1 Ohm resistor which connects the VMCU with the VMCU_NCP (WF200).
The J1 could be used to solder a HE10 connector (2.54mm) useful to do measurements.
So using R616 and J1, there are two ways to do WF200 current measurements during Tx, Rx or averaged on DTIM3:

• using a Voltmeter on J1-1 and J2-2, you could monitor the R616 voltage and then compute the current consumption.
• using a Ampere meter in serial between J1-1 and J1-2 after removing the R616 resistor. 

Removing the R616 resistor, you could alternatively use a monitored power supply using J1, like described in the snapshot below:

We recommend this way, if you want to measure the average lowest current consumption of 22uA during the sleep state.

To better understand the current consumption provided in the WF200 datasheet, I recommend to read the following KBA : https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/03/05/kba_wfx200_dtim3-tmpo

Moreover, to get the average sleep current consumption of 22uA, you should :

• use the SPI interface because with the Raspberry Pi, the SDIO clock is not switched off  during the sleep state (this increases the current consumption).
• remove the SDIO/SPI pull-up resistors highlighted in yellow in the above top view (these pull-up are not needed with the Raspberry Pi because the host has internal pull-up on the interface like required by the standard).

In order to do WF200 current measurements in Tx, Rx or in sleep state, we have used the Keysight DC power analyzer N6705C set in 2-wire sensing for short supply cables (voltage is monitored at supply output terminals) else set in in 4-wire sensing for longer twisted supply cables (voltage is monitored at the load and automatically compensate for any voltage drop within supply cables).

In the datasheet, the current consumption of 337 μA in DTIM3 provides the WFx200 average current consumption when there is no TX/RX of data frame (only receiving Beacon with the DTIM interval and using the sleep state).
So with this consumption, the WFx200 stays associated  with the Wi-Fi Access Point ready to transmit or receive data frame and it goes in sleep state between two Rx beacons with a current consumption of only 22 μA.

The 337 μA current are measured in DTIM3 when the WFX200 receives only one over 3 beacons with a beacon interval of 102ms and a beacon time duration of 1ms.

The Platform Data Set (PDS) file is used by the customer to fine tune the WFx200 usage according to his design or/and application.

When the TEST_FEATURE_CFG field is in the PDS file then it allows to do RF tests with the WFx200 (without WLAN protocol).
You could get some details on this at the end of the README.md with an example enabling RF Tx in CW (tone) on channel 11:
https://github.com/SiliconLabs/wfx-firmware/tree/master/PDS#test_featurepdsin-minimal-file-for-continuous-tx-testing

If using the Linux Lower MAC driver, we have the possibility to update some part of the PDS, on fly (for example to modify the test_feature channel):
https://github.com/SiliconLabs/wfx-firmware/tree/master/PDS#sending-a-pds-file-during-execution

On Linux (using the Lower MAC driver), we also provide python scripts allowing to automate RF measurements . Please read the readme in: https://github.com/SiliconLabs/wfx-linux-tools/tree/master/test-feature

With the Full MAC, it is also possible to update the PDS (using the API) and so to do RF measurements.

The customer could reduce the maximum Tx power used by the WFx200 using setting in the Platform Data Set (PDS) file.

Thank to this file, the customer could set some specific parameters for his application. This PDS file is loaded with the firmware in the WFx200.
The customer could set the maximun Tx power using the field MAX_OUTPUT_POWER_QDBM:

In order to get this max Tx power in the PDS file taken into account by the WFx200, it should be reloaded (on Linux use the script wfx_driver_reload). It is not an adaptative setting.
More details on PDS are available on the README.md: https://github.com/SiliconLabs/wfx-firmware/tree/master/PDS

To set the Wi-Fi Tx bitrate, use iw

802.11n :

sudo iw dev wlan0 set bitrates ht-mcs-2.4 <MCS index>

802.11bg :

sudo iw dev wlan0 set bitrates legacy-2.4 <legacy rate in Mbps> ht-mcs-2.4 <MCS index>

• <MCS index> possible values: 0 up to 7
• <legacy rate in Mbps> possible values: '1.0', '2.0', '5.5', '11.0', '6.0', '9.0', '12.0', '18.0', '24.0', '36.0', '48.0', '54.0'

For all details on iw, refer to https://wireless.wiki.kernel.org/en/users/documentation/iw

Can the WF200 Linux driver (available at https://github.com/SiliconLabs/wfx-linux-driver) be used with Android?

In theory, yes, since the driver is compatible with Linux kernel from 4.4.1 up to 4.19.

Has it been tested? Not yet.

Linux applications use 

• hostapd in AP mode
• wpa_supplicant in STATION mode

Android uses different applications for AP/STATION management, therefore testing would be required to make sure there is no unexpected behavior in an Android application.

For Linux applications

The WF200 Linux driver (available at https://github.com/SiliconLabs/wfx-linux-driver) is API compliant with all kernel versions from 4.4.1 up to 4.19.

• Compilation is verified with latest versions of LTS branches.
• Intensive lab tests performed with versions 4.4.39 & 4.4.50
• Tests extended to 4.14/1.19

NB: The goal is to have the wfx-linux-driver added to the mainstream Linux kernel in the future.

The Zentri DMS API lets you manage your devices and products via a REST API. Every action you can perform in the DMS web user interface can also be performed using this API.

The API calls are detailed in this tutorial, with heaps of cURL examples:

https://dms.zentri.com/docs/api

For those prefer Python, here is a quick example on how to issue the same REST API's using a Python script.This  simple script should retrieve all products you have access to, and print the product ID and code/title.

You will need to pass your API token as an argument when running the script. Token can be retrieved/created at:

https://dms.zentri.com/account/tokens

import requests, json, sys
CODE_OK         = 200
server_url      = 'https://dms.zentri.com:443'

def GetProducts(token):
    url = '%s/api/products' %server_url
    headers = {
        "Content-type"   : 'application/json',
        "Authorization"  : 'Bearer %s' %str(token),
    }

    r = requests.get(url, headers=headers)
    if(r.status_code == CODE_OK):
        try:
            products = json.loads(r.text)
            for product in products:
                print product['id']
                print product['code']
                print product['title']
                print '-------------------'
        except TypeError:
            print("Invalid JSON response")
            return (None, None)
    else:
        print("---------- ERROR (%d) ----------" %r.status_code)

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print "Please pass the API token"
        sys.exit(1)
    else:
        GetProducts(sys.argv[1])

WF200 Drivers and Firmware are available from Github

For Linux applications

Driver: https://github.com/SiliconLabs/wfx-linux-driver

Firmware: https://github.com/SiliconLabs/wfx-firmware

Tools: https://github.com/SiliconLabs/wfx-linux-tools

For RTOS Applications

Driver & Firmware: https://github.com/SiliconLabs/wfx-fullMAC-driver

Tools: https://github.com/SiliconLabs/wfx-fullMAC-tools

Linux Kernel events tracing

When working on a Linux system, it can be convenient to use the kernel events tracing mechanism, (described in details in Documentation/trace/events.txt in the Linux kernel sources).

We will only focus on a very simple use case here.

Listing possible event traces

All traceable events are listed under the  /sys/kernel/debug/tracing/events/ hierarchy of directories

Access to kernel event tracing is reserved to privileged users, so all instructions below need to be executed with root privileges

# ls -l /sys/kernel/debug/tracing/events/

Typical result:

alarmtimer  cfg80211  compaction  ext4  filelock  header_event  irq       mdio     napi  oom             power   raw_syscalls  rpm     skb    sunrpc   timer   workqueue block       cgroup    cpuhp       f2fs  filemap   header_page   jbd2      migrate  net   page_isolation  printk  rcu           sched   smbus  swiotlb  udp     writeback bpf         clk       dma_fence   fib   ftrace    i2c           kmem      mmc      nfs   pagemap         qdisc   regmap        scsi    sock   task     vmscan  xdp bridge      cma       enable      fib6  gpio      ipi           mac80211  module   nfs4  percpu          random  regulator     signal  spi    thermal

The first step is obviously to identify the events you want to trace within these. 

For example, let's look at the mmc events structure: 

# tree /sys/kernel/debug/tracing/events/mmc

The following hierarchy is present, with files and subfolders:

/sys/kernel/debug/tracing/events/mmc
├── enable
├── filter
├── mmc_request_done
│   ├── enable
│   ├── filter
│   ├── format
│   ├── id
│   └── trigger
└── mmc_request_start
    ├── enable
    ├── filter
    ├── format
    ├── id
    └── trigger

Each folder containing an enable file can be activated/de-activated by writing a 1 or a 0 to the corresponding enable file.

Each filter file corresponds to a list of filters applied to the corresponding event.

Each format file lists all possible parameter (which can be used in filters) and shows the print format for the corresponding trace.

Event traces format

format files list all possible parameters and show the print format:

# cat /sys/kernel/debug/tracing/events/mmc/mmc_request_done/format

name: mmc_request_done
ID: 643
format:
        field:unsigned short common_type;       offset:0;       size:2; signed:0;
        field:unsigned char common_flags;       offset:2;       size:1; signed:0;
        field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
        field:int common_pid;   offset:4;       size:4; signed:1;

        field:u32 cmd_opcode;   offset:8;       size:4; signed:0;
        field:int cmd_err;      offset:12;      size:4; signed:1;
        field:u32 cmd_resp[4];  offset:16;      size:16;        signed:0;
        field:unsigned int cmd_retries; offset:32;      size:4; signed:0;
. . . 
        field:unsigned int retune_period;       offset:124;     size:4; signed:0;
        field:struct mmc_request * mrq; offset:128;     size:4; signed:0;
        field:__data_loc char[] name;   offset:132;     size:4; signed:0;

print fmt: "%s: end struct mmc_request[%p]: cmd_opcode=%u cmd_err=%d cmd_resp=0x%x 0x%x 0x%x 0x%x cmd_retries=%u stop_opcode=%u stop_err=%d stop_resp=0x%x 0x%x 0x%x 0x%x stop_retries=%u sbc_opcode=%u sbc_err=%d sbc_resp=0x%x 0x%x 0x%x 0x%x sbc_retries=%u bytes_xfered=%u data_err=%d tag=%d can_retune=%u doing_retune=%u retune_now=%u need_retune=%d hold_retune=%d retune_period=%u", __get_str(name), REC->mrq, REC->cmd_opcode, REC->cmd_err, REC->cmd_resp[0], REC->cmd_resp[1], REC->cmd_resp[2], REC->cmd_resp[3], REC->cmd_retries, REC->stop_opcode, REC->stop_err, REC->stop_resp[0], REC->stop_resp[1], REC->stop_resp[2], REC->stop_resp[3], REC->stop_retries, REC->sbc_opcode, REC->sbc_err, REC->sbc_resp[0], REC->sbc_resp[1], REC->sbc_resp[2], REC->sbc_resp[3], REC->sbc_retries, REC->bytes_xfered, REC->data_err, REC->tag, REC->can_retune, REC->doing_retune, REC->retune_now, REC->need_retune, REC->hold_retune, REC->retune_period

Enabling/disabling event traces

To enable mmc/mmc_request_done:

# echo 1 > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/enable

To disable mmc/mmc_request_done:

# echo 0 > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/enable

Filtering events

Filtering events is done by writing a filter to the filter file

Filters can be set on each parameter listed in the format file, whether it is a numeric

# echo "cmp_opcode != 53" > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/filter

or a string

# echo "name == mmc1" > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/filter

or a combination

# echo "(cmd_opcode != 53) && name == mmc1" > /sys/kernel/debug/tracing/events/mmc/mmc_request_done/filter

The relational-operators depend on the type of the field being tested:

The operators available for numeric fields are:

==, !=, <, <=, >, >=, &

And for string fields they are:

==, !=, ~

The glob (~) accepts a wild card character (*,?) and character classes
([). For example:

  prev_comm ~ "*sh"
  prev_comm ~ "sh*"
  prev_comm ~ "*sh*"
  prev_comm ~ "ba*sh"

Clearing filters

To clear the filter for an event, write a '0' to the event's filter
file.

To clear the filters for all events in a subsystem, write a '0' to the
subsystem's filter file.

Following event traces during execution

# cat /sys/kernel/debug/tracing/trace_pipe &

Following this, any enabled event will be traced into the console 

 Event tracing may not work with kernel versions < 4.9, due to a limitation in the event tracing mechanism. Functions with event tracing located too far way from the start of a module may not get their events traced. A workaround consists in moving source code files using event tracing at the beginning of the list of object files used to link the module. This is corrected in higher kernel releases.