Preparing telecom logs

Preparing telecom logs

Use this guide if you’re debugging a cellular modem, baseband, or radio stack: VoLTE/VoNR call setup, IMS registration, RRC connection issues, NAS attach failures, handover anomalies.

Accepted log types

Qualcomm baseband captures upload directly. No conversion, no vendor tool. Upload the capture exactly as it came off the device, and logcat.ai decodes it for you.

Other vendors’ binary traces still need a text export first; the steps are below.

A note on .hdf, because the extension is used by two unrelated formats: a Qualcomm capture saved as .hdf uploads directly, while a Samsung Shannon CP dump saved as .hdf does not. Nothing is decided by the extension, so you do not have to work out which you have. Upload it; a capture we can read is read, and one we cannot is refused with the reason.

Upload alongside the corresponding device-side logs:

  • Qualcomm baseband capture. Straight from the device, in its native form.
  • Decoded modem text. MediaTek ELT or Shannon DM exports, for those vendors.
  • Radio buffer logcat. adb logcat -b radio output.
  • Kernel dmesg. Modem subsystem driver events on the application processor side.

What you get from a Qualcomm capture

  • Signal over time. Serving and neighbour cell identity, strength and quality, per cell.
  • The control-plane exchange. Attach, authentication, bearer setup, release and detach, each message named and in order.
  • The modem’s own debug text, searchable.

A large share of any capture is a vendor trace format that needs a symbol database we do not have. Those records are kept but not decoded, and the analysis tells you how much of the capture that was. A low decoded share means we could not read it, not that nothing happened.

For the full accepted/rejected list, see Supported file types.

Converting vendor captures to text

Qualcomm: no conversion needed

Upload the capture directly. A decoded text export also works if that is what you already have, but it is no longer a prerequisite, and the native capture carries more than a text export does: the measurements stay numeric and queryable rather than becoming lines of prose.

MediaTek: MTKLogger and ELT

MTKLogger (DebugLoggerUI) captures binary mdlog traces, often as .mcl. Use the MediaTek ELT decode tool:

  1. Open the mdlog / .mcl capture in ELT.
  2. Export the decoded protocol layers as plaintext.
  3. Upload the resulting text file.

Samsung: Shannon DM

Samsung CP captures (Sysdump output, often saved as .hdf, which is not the Qualcomm format of the same name) are decoded with Shannon DM (or QXDM/QCAT depending on the chipset variant):

  1. Open the binary capture in Shannon DM.
  2. Export the decoded NAS/RRC/PHY/MAC messages as plaintext.
  3. Upload the text file.

What’s not accepted

These are rejected at ingest in their native form:

  • MediaTek: .mcl, raw mdlog directories
  • Samsung Shannon: raw Sysdump bundles and CP dumps (again, a Samsung .hdf is not the Qualcomm one)

For these, if you don’t have the vendor decode tool, the trace is not analyzable by logcat.ai : the encoding is proprietary and only the vendor’s tooling can produce a readable export.

Qualcomm captures are no longer on this list. They are decoded directly.

Example questions to ask

Ask from the Research tab once the file is analyzed. Reach for Quick Search when you already know what you’re after, Deep Research when you need the root cause.

Quick Search for fast, cited lookups:

  • “Find all RRC connection rejects with cause.”
  • “Did the IMS registration succeed before the call?”
  • “Which bands did the modem camp on?”
  • “Show all call drops.”

Deep Research for multi-step root-cause investigations:

  • “Trace the attach failure through NAS messages.”
  • “Why did the VoLTE call drop at 14:32?”
  • “Correlate the modem reset with the kernel events on the AP side.”
  • “What caused the device to lose signal at 14:20?”

See Quick Search and Deep Research for how the two modes differ.

Next

  • Deep Research: multi-step protocol investigations across NAS, RRC, SIP, and AP-side logs.
  • Quick Search: fast lookups when you know the symptom.
  • Delta Comparison: compare a working capture against a failing one.