Ho to achieve higher bandwidth with MM8108-EKH05 example firmware

In the EU, with one node at 2m inside a building I get a 1Mbit result from iperf2 consistently. The HaLow description on Wikipedia tell me that this can be higher, mainly based on channel bandwidth (already at EU max) and modulation type. Still, I don’t see how I can configure the modulation type in the example applications. From what I can tell, M8108 supports a wide range of modulation types.

Is this UDP or TCP, and upstream or downstream? The EU duty cycle limits are 2.8% upstream (STA to AP), so I would expect you could get in the order of ~250kbps TCP and ~800kbps UDP.

.\iperf-2.2.1-win64.exe -c 192.168.12.217 -u -p 5001 -t 100 -i 10

Client connecting to 192.168.12.217, UDP port 5001

Sending 1470 byte datagrams, IPG target: 0.00 us (kalman adjust)
UDP buffer size: 64.0 KByte (default)

[ 1] local 192.168.12.203 port 51827 connected with 192.168.12.217 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 10.00-20.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 20.00-30.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 30.00-40.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 40.00-50.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 50.00-60.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 60.00-70.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 70.00-80.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 80.00-90.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 90.00-100.00 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] 0.00-100.01 sec 12.5 MBytes 1.05 Mbits/sec
[ 1] Sent 8918 datagrams
[ 1] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 1] 0.00-53.56 sec 2.94 MBytes 460 Kbits/sec 0.000 ms 6839/2096 (0%)
[ 1] 0.00-53.56 sec 2 datagrams received out-of-order

So, there’s nothing to be gained here, not even with other modulation types?

Not with the EU duty cycle restrictions unfortunately.

With that said, it depends on your projects traffic profile. If you need a high throughput link for occasional data, you can configure your duty cycle mode to “burst” instead of “spread”. This allows you to consume your airtime in bursty chunks rather than spread out, but the total air time in a given hour is still the same.

In Belgium, with EU settings in the Halowlink2 , I understood that the duty cycle could be avoided by using LBT (listen before talk). The throughput drops because of the “listen” timing, but AFAIK the 2.8% and 10% duty cycle does not apply. But maybe I did not test long enough to trigger the duty cycle.

The setting is in the advanced config enabled menu ,

under Network - Wireless , the line in the Wireless Overview for the HaLow link, the edit button

And the following setting:

.. with "Use standard duty cycle ‘UNTAGGED’

Disabling this in EU/GB will rely on ACS/DCS to meet regulatory requirements for AFA (Adaptive Frequency Agility).

From my reading, CCA is required (LBT) for medium access, and based of the ETSI 304 200, stations’ DC is 2.8% and the APs’ DC is 10% even with polite spectrum access requirements being met, so I’d be sure to clarify with local regs/ compliance houses before recommending that