FGH100M-H / MM6108: 4 modules permanently lose TX/RX while MM6108/BCF still appears operational

Software Embedded
1

Hi Morse Micro team,
We are investigating a repeatable issue with Quectel FGH100M-H modules (MM6108 based) and would appreciate help determining whether we are dealing with an MM6108 firmware/BCF issue, external FEM/PA failure, or another RF-front-end failure mechanism.
Hardware/setup:

  • Host MCU: ESP32-S3

  • HaLow module: Quectel FGH100M-H

  • Interface: SPI

  • Operating band: 915 MHz region

  • Configured TX power: 18 dBm

  • One device operates as STA, the other as SoftAP

  • STA sends a small data packet approximately once per second

  • AP primarily transmits when a control operation is requested

  • External antenna is used

  • Power rails have been checked and remain within specification

  • We have also tested the system under demanding battery/motor operating conditions and have not been able to reproduce the radio failure from the power/motor side.
    Failure history:

    We have now experienced the same type of failure on four units.

    The interesting part is that these failures occurred during operation at one particular test location. The same hardware/design has been tested successfully in other locations, including long-range testing, without this permanent failure.

    The affected units initially communicate normally. After the failure occurs, HaLow communication is permanently lost.

    Afterward:

    • There is no TX communication
    • There is no RX communication
    • Power rails remain present/normal
    • There is no obvious supply short
    • ESP32-S3 remains operational
    • Communication with the MM6108 appears sufficiently functional for firmware/BCF initialization
    • BCF is successfully detected/loaded
    • However, the RF interface no longer provides usable TX or RX
    • Power cycling does not restore RF operation

    We originally developed the product using the older MorseMicro/mm-iot-esp32 repository. We recently discovered that this repository is now archived/deprecated and that ESP32 development has moved to MorseMicro/esp-halow.

    To eliminate our application firmware as the cause, we took an already-failed board and tested it using the latest esp-halow stack and the standard Morse Micro STA and SoftAP examples. The radio still could not establish communication.

    Therefore, simply moving the failed hardware to the current SDK/firmware does not recover it.

    We would particularly appreciate guidance on the following:

    1. Is it possible for the MM6108 to boot, communicate with the host and successfully process/load its BCF while the external PA/FEM or RF front end has permanently failed?
    2. Is there a recommended MM6108 diagnostic/test that can determine whether the internal MM6108 RF TX/RX path itself is functioning, independently of the external high-power FEM/PA used by the FGH100M-H?
    3. Are there any test modes/API commands that can generate a continuous or controlled RF carrier/packet transmission so that we can measure RF output directly with a spectrum analyzer?
    4. Is there any API/diagnostic register that reports FEM state, PA enable, TX power/calibration status, RF errors, or other information that could distinguish a failed external FEM from an MM6108 RF failure?
    5. Could an older/incompatible combination of MM-IoT-SDK, MM6108 firmware and module BCF incorrectly control an external FEM/PA — for example PA enable timing/polarity, RF switching, bias, gain/power calibration or TX duty — in a way capable of permanently damaging the external RF front end?
    6. Were there any known RF/FEM-related issues fixed between the older mm-iot-esp32 releases and the current esp-halow/MM-IoT-SDK releases?
    7. Does the MM6108/BCF provide any protection against excessive RF power arriving at the antenna/RX path, and is there a way to determine from software whether an RF-overstress event may have occurred?
    8. Are there any OTP/regulatory/firmware states that could leave the MM6108 apparently operational to the host but permanently prevent RF TX/RX? If so, how can we read/check those states?

    The fact that this has now happened to four modules, while the digital side remains operational and we cannot reproduce the failure through power/battery/motor testing, is why we are trying to determine exactly where the RF failure occurs.
    Any recommended diagnostic procedure for separating:

    MM6108 SoC failure vs. BCF/firmware issue vs. external FEM/PA failure

    would be greatly appreciated.

    Thanks.

2

Hi @Yousaf93

This does sound like FEM failure. Are you able to confirm that there is any transmission from the devices with a spectrum or power analyser?

This sort of failure can happen when there is a discontinuity in the antenna path. For example, when an SMA antenna/cable is connected to an RP-SMA port of the device. Though usually you will see degraded performance before total communication failure.

Analysing the environment with a spectrum analyser is probably the first thing you should do, as it appears specific to the environment.

3

Hi @ajudge , Thank you for the response.
Unfortunately we havent been able to replicate the same on our side and the issue happened only on the Demo units at field.
I confirm there is no sort of transmission on those.
For Antenna path we have matched the impedance and are using the TX915-JKD-20 from ebyte for the antenna .

The Spectrum analyzer shows nothing on the faulty units and shows normal for the units in test.
Can you guide on any other possibilty which might be causing this ,
It would help a great deal
Thanks

4

Speaking to our hardware engineers here at Morse, the most likely scenarios we can think of which would cause this would be:

  • an overvoltage event
  • an undervoltage event
  • Significant power being injected into the RF output of the module (including reflections due to significant impedance mismatches)

Keep monitoring the units that are functioning, and maybe review your designs against our hardware design guide (this doc targets mm8108 but the protection and supply recommendations will be similar).