Low mac access for FGH100M H

WIFI/BT
1

Hello,

I am a research using SDR solution to test different PHY stack. I bought the FGH100M H to test the 802.11ah SDR implementation and I would like further more to benchmark it. For exemple sending quick custom frames without association.

I tried some tricks to do it but I would like to have access to drivers or ATE commands. Like it is explained in the datasheet I ask the support for those closed resources. Maksim from the FAE Department at Quectel Wireless Solutions redirected me here.

Sincerely,

Adam

2

Hi adaml,

Thank you for your interest in the FGH100M-H.

Sorry we don’t have stuff about ATE commands. Quectel cannot get the details about the PHY design about the chip.

If you have any question abou thow to test the WiFi connection, we can discuss it here.

3

Thanks for your response, for the moment i’m using scan feature (from morse micro sdk) to send “custom” frame (with data inside SSID) but there is still a MMWLAN_SCAN_MIN_DWELL_TIME_MS that annoy me.

Sincerely,

Adam

4

And What is questions? dwell time is also mentioned in WiFi technology.

5

My main interest in FGH100M-H is to send custom or direct frame (by passing the MAC) to do RF testing. So the dwell time don’t let me benchmark the response time of my SDR app.

6

That does seem quite unlikely, unfortunately. The low-level MAC/PHY interface you are looking for is essentially Morse Micro’s internal IP — only they have full visibility into the MM6108’s command set and firmware state machine. Quectel’s driver is basically a wrapper around that, and they are unlikely to expose raw frame injection or let you bypass the upper-MAC dwell/scan logic without Morse’s direct involvement.

You might want to keep an eye on the FCH100XM (or similar hostless/MCU-oriented variants) in the future. Those are designed to run more like a self-contained MCU rather than a standard Linux network interface, which could give you tighter control over timing and state management. But to be honest, even in that form factor, the underlying RF/MAC primitives will still be buried inside the firmware blob. You will not get the raw PHY access you are looking for without an NDA or a direct engineering engagement with Morse Micro.

If your goal is purely RF benchmarking (power, spectrum, PER), it may be worth checking whether the existing morse driver parameters — thin_lmac, duty_cycle_mode, enable_hw_scan, etc. — can be tuned to minimize the scan dwell. It is not “true” low-MAC access, but it might get you close enough to the latency numbers you need for your SDR app.

1 Like
7

non-signaling / ATE-style RF testing through the morsectr.

The key prerequisite is replacing the normal mm6108.bin firmware with mm6108-dvt.bin (the DVT/test firmware).

TX test flow (continuous packet generation):

  1. insmod dot11ah.ko and insmod morse.ko country=JP

ifconfig wlan0 up

morsectrl -i wlan0 channel -c 863500 -o 1 -p 1 -n 0  → set freq / bandwidth

morsectrl -i wlan0 txrate enable -b 1 -m 0 ...  → set MCS rate

morsectrl -i wlan0 txscaler 0  → adjust TX power (±15 dB)

morsectrl -i wlan0 rpg start -s 1000 -c -1  → start continuous TX

morsectrl -i wlan0 rpg stop  → stop before changing channel/mode

RX test flow:

  1. ifconfig wlan0 up

morsectrl -i wlan0 channel -c 863500 -o 1 -p 1 -n 0

morsectrl -i wlan0 rpg start -l  → enter RX packet-sniff mode

morsectrl -i wlan0 rpg stats  → read packet count

morsectrl -i wlan0 rpg reset  → clear counters

So while this is not true raw-frame injection (you are limited to the built-in RPG patterns), it is essentially the low-level RF test interface you were asking about. The rpg start command bypasses normal MAC association/scanning, so the dwell-time issue you mentioned should not apply in this DVT mode.

1 Like
8

Thanks a lot,

I will give it a try, i’m not using the linux sdk (esp32 sdk) hope there is some command like that too.