Forcing TX power on the MM8108-EKH05

Software Embedded
1

Hello,

I’m currently developping a system using the MM8108-EKH05 on the TX side and the MM8108-EKH19 on the RX side.
I’m having a hard time setting the transmission power to the maximum available (26dbm).

I am currently stuck at exactly 14 dBm (25 mW).

Here is my configuration:

  • Country Code: Set to "US" in config.hjson.

  • BCF: Set to bcf_mf15457.mbin and successfully flashed via OpenOCD/Python script.

  • Channel: 28 / 916 MHz.

  • Power Supply: USB-C 5V 3A.

  • Measurement: Mini-Circuit Power Sensor (50 - 6000 MHz).

I’v tried using mmwlan_override_max_tx_power(26); too but i’m getting the same result.

here is my void app_init(void) for more context

void app_init(void)
{
    printf("\n\n--- RPI -> STM32 -> HALOW ---\n\n");

    SPI_Slave_Init();

    HAL_SPI_Receive_IT(&hspi1, spi_rx_buffer, SPI_PAYLOAD_SIZE);

    // low QoS config
    struct mmwlan_qos_queue_params fpv_qos = {
        .aci = 3,         // ACI 3 = Voice (TOS 0xC0 - LwIP)
        .aifs = 2,        // inter-trame waiting time
        .cw_min = 1,      
        .cw_max = 1,  
        .txop_max_us = 0 
    };

    mmwlan_set_default_qos_queue_params(&fpv_qos, 1);
    mmwlan_set_power_save_mode(MMWLAN_PS_DISABLED);

    app_wlan_init();

    mmwlan_override_max_tx_power(26);

    mmipal_set_link_status_callback(link_status_callback);

    printf("connection to the OpenWrt AP...\n");

    app_wlan_start();

    mmwlan_ate_override_rate_control(MMWLAN_MCS_1, MMWLAN_BW_8MHZ, MMWLAN_GI_NONE);
    printf("8 MHz / MCS 1 setted.\n");


    while (!is_network_ready) {
        mmosal_task_sleep(10);
    }

    struct udp_pcb *pcb = init_udp_pcb();
    if (pcb != NULL) {
    	pcb->tos = 0xC0;
        udp_broadcast_tx_start(pcb);
    }

    (void)get_mode;
    (void)udp_broadcast_rx_start;
}

Thank you for your help,
Nathan.T

2

Hi Nathan,

mmwlan_override_max_tx_power will only limit the TX power, it will never increase it past the default value in the regulatory database:

The US Max Tx EIRP (dBm) for all channels is 36, so setting 26 will actually be reducing the TX power. Can you try removing the override and measuring the power?

As an aside, mmwlan_override_max_tx_power should be called between app_wlan_init and app_wlan_start, rather than after app_wlan_start (see note in docs above)

Cheers

3

Thanks for the response.

The function is indeed called between init and start in my code :). However, even with the override removed completely, the TX power remains physically capped at 14 dBm on the power meter.

Is it possible that, since I purchased the eval kit in the EU, the maximum power is hardcoded/locked in the hardware for regulatory reasons, even though I configured the country code to US? Or should I be using a different BCF file than bcf_mf15457.mbin?

Thanks again for your help.

4

Weird, I must have gotten my wired crossed when reading the code :sweat_smile:

Assuming you updated the country code in the mmconfig (which should be the case if you are associating to a US based AP) there shouldn’t be any EU restrictions as far as I know.

Can you confirm how/where you are measuring the power? That should help with diagnosing on our side

5

Thanks for the clarification!
​Regarding the measurement, I performed a conducted measurement: I connected the EKH05 directly via its SMA connector to a PWR-6LGHS USB Power Sensor (50 MHz - 6 GHz, -45 to +10 dBm) using a 20 dB attenuator to not fry the equipment. The reading consistently sits at exactly 14 dBm.
​To confirm this wasn’t a measurement artifact, I also did some Line-of-Sight (LOS) tests outdoors (in a mostly openfield terrain). I completely lost the connection at ~250m, which seems logical with 14 dBm.
​To address the mmconfig: yes, I did set “wlan.country_code”: “US” in my config.hjson and flashed it to the Config Store using the program-configstore.py tool.

​Is there any other parameter that could clamp the PA hardware internally?

6

I’m checking with my colleagues on the power side as it’s not my area of expertise.

One other sanity check for your setup etc, have you measured the power output from the EKH19? What did that read?

7

Hi,
Thanks for suggesting that sanity check.
Running a ping flood, the EKH19 is emitting between 20-22 dBm. Which is coherent with what iw dev wlan0 info is returning (txpower 20.00 dBm), altough when trying to set it with iw dev wlan0 set txpower fixed 2600 it doesn’t get changed.

However, my EKH05 remains strictly capped at 14 dBm.

8

If you provide the serial number of the EKH05 board, we can check the production database for the test results of your unit.

Not that it should make a difference here, but can you confirm the version of mm-iot-sdk you are using?

Also any other details to help investigate would be useful. EG trace of power measurement, dump of mmconfig etc

9

Here are the details:

  • MM8108-EKH05 V2 - Serial: 0-02BBGV, HW Version 2.1.

  • SDK version: release 2.10.4

Screenshot of the power measurement:

EKH05_TX_power
EKH05_TX_power631×545 54 KB

config.hsjon dump

{
     /* You can specify a list of key/value strings in this section to write to config store */
     /*this is equivalent to the write-string command */
    "strings" : {
        //"wlan.operating_mode": "AP",
        "wlan.operating_mode": "STA",
        /* The Wi-Fi SSID \*/
        "wlan.ssid": "MM8108_EKH19",
        //"wlan.ssid": "",
        /* The Wi-Fi password, not required if wlan.security is open */
        //"wlan.password": "EKH19_PW",
        //"wlan.password": "",
        /* The Wi-Fi security to use, valid values are sae, owe and open */
       //"wlan.security": "sae",
        "wlan.security": "open",
        /* The 2 letter country code to ensure the correct regulatory domain is used */
        "wlan.country_code": "US",

        "wlan.channel": "28",

       /* If true use DHCP, else the static IP configuration will be used */
        "ip.dhcp_enabled": "false"
        /* These settings are ignored if DHCP is used, but mandatory if using static IP */
        "ip.address": "192.168.12.50",
        "ip.netmask": "255.255.255.0",
        "ip.gateway": "192.168.12.10",
        //"ip.gateway": "255.255.255.255",

        /* These settings are for IPv6, ip6.ip_addr is only required if ip6.autoconfig is */

        "ip6.autoconfig": "true",
        // "ip6.ip_addr": "FE80::2",
        /* The following settings are required only for the udp_broadcast app */
        /* Only used in "tx" mode. If set to zero packets will be sent forever. */
        "udp_broadcast.packet_count": "10",
        /* Only used in "tx" mode */

        "udp_broadcast.packet_interval_ms": "1",
        "udp_broadcast.port": "1337",
        /* The udp broadcast mode, valid values are "tx" or "rx" */
        "udp_broadcast.mode": "tx",
        /* Used in "rx" mode to specify the device’s index into the received data array
          (see the documentation in udp_broadcast.c) */
        "udp_broadcast.id": "0"  
    },
    "hex_strings" : {     
    },
    "files" : {
        "bcf_file": "$MMIOT_ROOT/morsefirmware/mm8108/bcfs/bcf_mf15457.mbin" 
    }
}
10

@DNT can you update to the latest IoT SDK version and add a call to mmwlan_get_vif_channel_info to confirm the channel configuration?

We have checked the production test results for your unit and it all looks good. E.G. we have power results at 25dBm:

image
image439×493 28.3 KB

Another thing to check, is the device associated when you are measuring the TX power?

11

Hello,
Yes, the measurements were taken with the device associated to the AP. Here is the output of mmwlan_get_vif_channel_info:

Operating Class (op_class)       : 4
S1G Channel Number (s1g_chan_num): 28
Bandwidth MHz (pri_bw_mhz)       : 2 MHz
Primary 1MHz Index (pri_1mhz_idx): 3

Which is strange, since the EKH19 (AP) is configured for 8MHz bandwidth on channel 28. Could this fallback to 2MHz be the reason why the TX power is clamped to 14 dBm?

update: I just verified the actual TX transmission BW over the air using a spectrum analyzer, and the physical bandwidth is indeed 8 MHz, despite the mmwlan_get_vif_channel_info reporting 2 MHz.

It seems there is a desync between the actual PHY state and the SDK state. Could this be tricking the software into applying the 2 MHz regulatory limits while the radio is physically operating at 8 MHz?

12

The channel on the STA side is 28, which means the operating channel is 8MHz. The pri_bw_mhz is the bandwidth of the primary channel, which is the (sub)channel used for sending important management and signalling frames. The primary channel is always 1 or 2 MHz for HaLow, so this is all as expected.

Can you try run a 60s UDP iperf client (with the iperf server running on the EKH19) and report the power measured and the tput results?
Try running the iperf example application without any modifications to override of power/bandwidth etc, with the mmconfig configuration updated to be a udp_client and with the relevant AP details.
Relevant sections to modify:

The intention here is to use an application we can run, to flood the medium with traffic and see what power you observe, with throughput as a proxy for utilisation - which we can then compare internally

13

Hi,

Apologies for the delayed reply, I was away on leave for the past few weeks.

Following your instructions, I ran the stock iperf application in UDP client mode over the 8 MHz channel (channel 28) to flood the medium.

Here are the measurements captured on the power meter:

  • Average TX Power: 15 to 16 dBm

  • Peak TX Power: reached a transient peak at ~18 dBm

As this project is now reaching its deadline, I’ll be freezing my setup and wrapping up further hardware tests. I hope these figures provide useful data points for your internal comparison.

Thank you again for your support throughout the investigation your reactivity was much appreciated.

Best regards