MM6108 / FGH100M-H — exposing TSF to the host for time sync

Software Embedded
1

Hello,

I’m working on a project for a large customer in acoustic sensing that requires correlating audio captured simultaneously at multiple sensor nodes. Our hard requirement for inter-node timestamp alignment is ≤25 µs, sustained across a 5-minute capture. ≤2 µs would be preferred.

TLDR; can the MM6108 toggle a hardware pin on TSF, 1-pps style or similar? Test results suggest it would provide a path to sub-µs synchronization between nodes.

The Long Version

We’ve tentatively selected HaLow for the link and I have two nodes running on the bench with . I have a specific request about TSF access, and some initial measurements.

Setup

  • Quectel FGH100M-H (MM6108) on Seeed XIAO ESP32-S3, SPI host interface
  • morsemicro/halow 2.11.2-esp32-2, ESP-IDF v5.5.1
  • Morse firmware 1.17.8, chip ID 0x0306, BCF bcf_fgh100mhaamd
  • Both nodes associated as STAs, US channel 48 / op_class 3
  • GL-MT3000 AP with USB dongle from Morse dev kit

What we found

Command ID 0x0028 is not declared in the embedded SDK’s enum morse_cmd_id (it jumps from
TWT_AGREEMENT_REMOVE 0x0027 to MPSW_CONFIG 0x0030), but your shipping firmware does implement it. Issuing it over morse_cmd_tx() returns success and a 20-byte payload:

Bytes Field Verified as
0–7 u64 TSF — tracks the AP’s timebase; matched elapsed wall-clock over several hours
8–15 u64 chip-local timestamp — matched time since chip reset
16–19 u32 unidentified

I probed known-good (0x0002) and known-bad (0x0ffe) command IDs as controls; they behaved correctly, so I’m confident the 0x0028 result is real and not an artifact.

Timing measurement results (300 samples):

Quantity Residual stdev Peak-to-peak
chip_ts − TSF — both latched inside the MM6108 0.33 µs 1.8 µs
chip_ts − host_time — across the SPI command 385 µs 3,800 µs

The chips’ internal time pair is excellent — 0.33 µs, comfortably inside our 25 µs budget. But we
cannot get that quality across to the host: the command round-trip takes ~4.5 ms and carries ~385 µs
of jitter, which is 15× our budget. Selecting only the fastest 10% of calls improves it to ~10 µs
stdev but still 39 µs peak-to-peak.

In other words, the timing quality we need already exists inside your silicon — we just have no
low-jitter path to it.

Can the MM6108 firmware toggle a GPIO on a TSF event (a 1 PPS-style output, or a pulse on a
configurable TSF boundary)?

A single hardware edge would solve this completely. We’re already capturing external pulses with the ESP32’s hardware timers, so it looks like a TSF-derived hardware pulse would let every node align its local sample clock to the AP’s timebase with sub-microsecond error. If it proves reliable, it would potentially save me a lot on the BOM.

I understand this is likely a custom-firmware item, but it also seems like it would be valuable to many customers.

Secondary questions

  1. Is 0x0028 supported? It works but is undeclared in the embedded SDK. Can we rely on it across
    firmware releases, or is it internal and subject to change? If it’s supportable, exposing it in
    the mmwlan API would be useful to more than us.
  2. What is the third field (bytes 16–19) in the 0x0028 response?
  3. Are TSF and chip_ts latched atomically? Our 0.33 µs residual suggests yes, but I’d rather not
    assume it.
  4. rx_timestamp_us. The RX descriptor carries a per-frame timestamp (struct morse_skb_rx_status), and your Linux driver surfaces it, but the ESP32 SDK’s skbq.c copies
    RSSI/frequency/bandwidth/noise out of the descriptor and drops the timestamp. Is there a reason, or would you consider exposing it? That would give us a second route to the same goal.
  5. Is there an application note on time synchronisation between HaLow nodes? We may be solving a problem you’ve already addressed.

Happy to share our test firmware or run additional measurements if that helps.

Thanks,

Philip Odom
Firia Labs