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 as it came off the device.

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. The content decides which one it is, so you do not have to. 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, including from the signal records newer modem firmware writes. A serving cell’s level is stated over the readings taken while it was serving.
  • Radio performance figures. For LTE and 5G: uplink transmit power and power limiting, the channel quality and rank the device reported, radio link monitoring, block error and retransmission figures, and 5G downlink throughput, including from newer modem firmware.
  • The control-plane exchange. Attach, authentication, bearer setup, release and detach, each message named and in order, with rejections attributed to the side that sent them. Signalling is decoded for 4G (LTE) and 5G (NR), including IMS SIP messages; 2G and 3G signalling is recognized and counted, but not decoded.
  • Registration and bearer state. The LTE mobility (registration) state the modem reports, each bearer’s state and QoS class, and the serving cell’s identity (frequency, band, network and tracking area), each as the capture records it, so you can ask when the device was registered or which bearers it held.
  • IMS SIP messages and eCall data. Each SIP message the modem logged, with its direction, method or response status, every header in order, its body types and any Reason cause, so you can follow call setup and registration. When an emergency call carries an eCall minimum set of data, that is read too: the vehicle identification number, position and recent positions, heading, vehicle type, number of occupants, incident time, and whether the call was automatic or a test.
  • The modem’s own debug text, searchable. Its trace messages read as text wherever the capture carries that text itself.

Records come back at three depths, and the analysis says how much of the capture landed in each: fully decoded; read in part (the record’s kind and any text it carries, but not every field; a trace message counts here when its text was not in the capture or its firmware); and retained and searchable but not interpreted, because its layout is not published. A low fully-decoded share means we could not read those records, not that the capture was quiet. Control-plane messages are reported as how many were found and how many we could name; the difference is messages that were ciphered or of a kind we cannot route to a decoder.

The capture’s dashboard

Each Qualcomm capture gets a dashboard of its own: headline numbers; how much of the capture could be read, and whether a message database would restore anything; signal per cell over time; which cell served when; the cells ranked by level, quality or strength, each tagged serving or neighbour; radio performance by family; signalling messages by name and direction, with rejections by sender; and the most frequent record types, each marked with whether it is read. A chart the capture has no records for says so instead of disappearing. Two further cards appear only when they matter: where the modem’s narration came from, when narration makes up most of the capture, and records over time by technology, when the record rate drops out.

The capture’s Logs tab

The Logs tab lists the capture’s decoded records on one timeline; on a very large capture it says how much of the capture the timeline holds. It opens at the capture’s first clock. Records that state no time of their own are counted, and the tab shows them with one click. When the modem’s clock was never set at all, its records are placed on the device’s clock from the timed records around them, where the two keep a steady offset; otherwise they stay untimed. When a finding on the dashboard names a time, click it to open the tab at that moment with the records around it. Filter by kind, technology, layer, direction, message type, firmware function and read state; each value shows how many records it holds under your other filters. Search the records’ text, drag across the density strip to narrow the time range, and open any record for what was decoded from it and its raw bytes. A large capture may take a few minutes to prepare the first time the tab opens.

Compressed narration and message databases

Some modem firmware writes its debug text in a compressed form that only the message database built with that firmware can turn back into words. When a capture carries compressed narration, the analysis and the dashboard say how many records are affected and which database they need: by its GUID when the capture names it, otherwise by the last four characters of the GUID its records carry. They also say when the database on file is from another build.

Upload that database (a .qsr4 file from your firmware build; see size limits) on the References page: choose Add reference file, then Baseband message databases. Every later capture it fits is restored to readable text automatically, and captures you have already uploaded are listed so you can re-run them. You can also put the database in the same archive as your captures. It is added to your References before the captures in that archive are analyzed, so they are restored on their first run, and it is not analyzed as a log. This needs the telecom log analysis capability. A database is used only when it is named by the capture, or for records carrying the end of its GUID and whose messages match it, so a database from another firmware build is not applied. A capture that names several different databases is not restored.

Firmware images and withheld messages

Some trace messages are withheld by the chipset vendor: no message database holds their text, so on their own they say only that a message fired. A firmware image (the modem’s .elf from the same build) lets logcat.ai name the function in your firmware that emitted each of those messages. Upload it on the References page with Add reference file, then Modem firmware images (see size limits); each image is then listed in the page’s files table by its build and can be deleted. The image is used only for captures of exactly the same build, alongside that build’s message database; an image from any other build is never applied. Only what attribution needs is kept, and the image itself is discarded.

Baseband analysis needs the telecom log analysis capability on your account. See Why was I limited?.

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 you already have one, but the native capture carries more: its measurements stay numeric and queryable.

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.

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.