Skip to main content
The Dark Art of Postmortem DebuggingRead
Modem and connectivity
01 / Evidence
Qualcomm DIAG capture
14:32
1830 MHz
2130 MHz
3520
04.0
06.0
08.0
10.0
07.41
reconfiguration, target 2130 MHz, T304 = 1000 ms
07.42
PRACH preamble 1 of 10 on target, no response
08.41
T304 expiry, radio link failure
08.60
cell search, strongest 1830 MHz at -112 dBm
09.71
RRCConnectionReestablishmentReject
Illustrative. Synthetic data.
02 / Answer
One sentence

The handover was ordered. The device never arrived.

T304 ran out before random access on the target cell completed, the link failed, and re-establishment was rejected: a failed handover, not a coverage hole.

1.0 s from the reconfiguration to the drop. 10 preambles, no response.

Upload the baseband capture as it came off the device. logcat.ai decodes it, reads RRC, NAS and MAC as protocol state rather than text, and follows the failure across the proprietary boundary into RIL, IMS and the telephony framework, in one investigation.

Try playground
Solutions / Modem and connectivity
Baseband / RIL / IMS / Telephony
01 / Evidence
Qualcomm DIAG capture, decoded on upload
14:32
1830 MHz
2130 MHz
3520 MHz
MHz across
time down
04.0
05.0
06.0
07.0
08.0
09.0
10.0
07.41 reconfiguration, target 2130 MHz
08.41 T304 expiry, radio link failure
09.71 reestablishment rejected
14:32:06.98
RRC
MeasurementReport, event A3: 2130 MHz at -101 dBm, serving at -109 dBm
14:32:07.41
RRC
RRCConnectionReconfiguration, mobilityControlInfo: target carrier 2130 MHz, T304 = 1000 ms
14:32:07.42
MAC
retune complete, PRACH preamble 1 of 10 on target
14:32:07.70
MAC
no RandomAccessResponse in window, preamble 2 of 10, power +2 dB
14:32:08.33
MAC
preamble 10 of 10, no RandomAccessResponse
14:32:08.41
RRC
T304 expiry, radio link failure, cause: handoverFailure
14:32:08.60
RRC
cell search, strongest candidate 1830 MHz at -112 dBm
14:32:09.50
RRC
RRCConnectionReestablishmentRequest on 1830 MHz, cause: handoverFailure
14:32:09.71
RRC
RRCConnectionReestablishmentReject
14:32:09.72
NAS
EMM: service lost, re-attach pending
Illustrative. Synthetic data.
02 / Answer
One sentence

The handover was ordered. The device never arrived.

T304 ran out before random access on the target cell completed, the link failed, and re-establishment was rejected: a failed handover, not a coverage hole.

1.0 s from the reconfiguration to the drop. 10 preambles, no response.

Upload the baseband capture as it came off the device. logcat.ai decodes it, reads RRC, NAS and MAC as protocol state rather than text, and follows the failure across the proprietary boundary into RIL, IMS and the telephony framework, in one investigation.

Try playground
The idea: a dropped call is the place on the waterfall where the ribbon of signal stops, and the answer is the one line that says why.
02 / Evidence
41,212 lines, one of them the fault
14:31
PHY / MAC / RRC, every entry, 100 ms per row
50.0
52.0
54.0
56.0
58.0
measurement report every 400 ms
CQI / PMI / RI, every subframe
HARQ ACK / NACK
RLC status PDU
measurement report
measurement report
CQI / PMI / RI
HARQ ACK / NACK
14:31:55.37 RRC: RRCConnectionReestablishmentReject, line 30,118 of 41,212
The idea: the fault is one row in a field of routine rows that all look alike, and it is on every layer's waterfall at once, in a different vocabulary each time.
Illustrative. Synthetic data.
Why it is hard
Four reasons

Why modem stack debugging is hard

Device-side connectivity crosses chipset baseband, RIL, IMS, framework, and audio HAL, and a single fault touches all of them.

01
Protocol complexity
NAS, RRC, SIP, RTP, GTP: hundreds of message types across multiple protocol layers, each with their own state machines and failure modes.
02
VoLTE and VoNR call setup failures
A single VoLTE or VoNR call touches RRC connection setup, NAS attach, IMS registration, SIP INVITE, and RTP negotiation. Failure at any point kills the call.
03
Needle in a haystack
Thousands of repetitive PHY/MAC entries, periodic measurement reports, and routine signaling: the actual issue is often buried in a sea of normal traffic.
04
Cross-layer correlation
When the modem reports a failure, is it a radio issue, a network reject, a SIM problem, or an Android framework bug? Connecting events across layers requires deep expertise.
03 / The manual way
~2 days, 3+ tools, senior engineer required
day 1
09:00
Open QXDM / QCAT
Load DLF, filter NAS + RRC messages manually
11:30
Open logcat separately
Search for IMS / telephony tags manually
14:00
Open vendor thermal tool
Cross-reference kernel thermal zone timestamps
day 2
09:00
Manual timestamp alignment
Correlate events across 3+ tools by eye
13:00
Build the timeline
Paste findings into a spreadsheet or doc
16:30
Write root cause report
Summarize findings for the team
Traditional telecom debugging requires multiple specialized tools, manual timestamp correlation, and deep domain expertise. Time runs down this column the way it runs down the waterfall.
Illustrative. Synthetic data.
With logcat.ai
~5 minutes, 1 platform, any engineer

Two days of manual work, or five minutes.

logcat.ai collapses the entire workflow into a single question.

00:00
Upload your logs
QCAT exports, logcat, dmesg, bugreport, all in one upload.
00:01
Ask your question
"Why did the VoLTE call drop at 14:32?"
05:00
Get the full cross-layer root cause
Deep Research traces RRC, NAS, SIP, IMS, and kernel events automatically.
Compare multiple log sets side-by-side withDeltato find regressions across firmware versions.
04 / Evidence
Three files, one time axis
time
Modem export
Logcat radio
IMS SIP trace
14:32:03
14:32:04
14:32:05
14:32:06
NAS: Attach Request sent
NAS: Auth Response OK
NAS: Attach Reject, cause #19
NAS: Detach Request
RIL: requestSetup
RIL: setRadioPower ON
RIL: registration failed
RIL: dataCallListChanged
INVITE sip:+000@ims.example
100 Trying, 183 Progress
503 Service Unavailable
BYE, session terminated
one moment, seen in three files
Investigation steps
01
Checking if attach reject correlates with RIL state
NAS cause #19 matches RIL registration failure
02
Was the SIP session affected by the NAS rejection?
503 Unavailable 900 ms after the attach reject
03
Tracing root cause propagation
Modem firmware, NAS, RIL, SIP: a single fault chain
Illustrative. Synthetic data.
Delta
Multi-file comparison

Cross-layer correlation with Delta

See how Delta correlates events across modem logs, logcat radio, and kernel dmesg to find the real root cause.

Result

A modem firmware timeout propagated through NAS, RIL and IMS. One fault dropped the VoLTE session.

3 layers traced. Every finding cites the line it came from.
Learn more about Delta
05 / Built for telecom engineers
Powered by Deep Research

Purpose-built analysis that understands 4G LTE and 5G NR protocols.

Four capabilities, each read the way the waterfall is read: the evidence on the left, what it returns on the right.

01
Deep Research
Multi-step AI investigation within a single log file. Ask questions like "trace the attach failure through NAS messages" and the AI iteratively searches, analyzes, and builds a complete investigation.
ask
trace the attach failure through NAS messages
02
Delta cross-layer analysis
Upload multiple files (modem export, logcat, and dmesg) and Delta correlates events across all layers. See how a modem-layer event connects to the Android framework.
files
modem export + logcat radio + dmesg
03
Protocol-aware analysis
logcat.ai understands NAS message flows (EMM/ESM and 5GMM/5GSM), RRC state transitions, SIP dialog sequences, and their interdependencies across LTE and 5G NR, as protocol state rather than as text patterns.
reads
EMM / ESM, 5GMM / 5GSM, RRC, SIP
04
AI root cause analysis
Pattern recognition across thousands of log lines identifies the root cause rather than the symptom. Trained on real-world telecom failure patterns.
returns
the cause, not the symptom
06 / Who uses this
Device-side modem and connectivity teams

Built for device-side modem and connectivity teams.

01
Modem integration engineers
Chipset and OEM engineers debugging NAS attach failures, handover issues, RRC connection problems, and modem firmware crashes across the proprietary boundary.
A question they ask
"why did the handover to 2130 MHz fail after the firmware update?"
02
VoLTE, VoNR and IMS engineers
Engineers working on VoLTE and VoNR call setup, IMS registration flows, SIP signaling, and voice quality across the IMS framework and chipset audio HAL.
A question they ask
"why did the INVITE get a 503 after registration succeeded?"
03
Field test engineers
Drive test and field validation engineers analyzing coverage investigations, handover performance, and device-network interaction across regions.
A question they ask
"which cells on this route dropped the call, and at which step?"
Example questions are illustrative.
07 / What we analyze
Four sources, one investigation

Upload plaintext modem-stack logs from any of these sources.

Each source is one layer of the same stack. Upload them together and the investigation reads across all of them.

01
Modem diagnostic logs
Plaintext modem diagnostic logs from any vendor: Qualcomm QCAT exports, MediaTek MTKLogger output, Samsung Shannon modem logs, or any tool that produces decoded NAS, RRC, PHY, and MAC messages.
NAS / RRC / PHY / MAC
Qualcomm DIAG captures upload as they came off the device; decoded for you.
02
Logcat radio logs
Android logcat output focused on telephony: RIL messages, TelephonyManager events, IMS registration, and modem trace data.
RIL / IMS / telephony
adb logcat -b radio
03
dmesg kernel logs
Linux kernel logs from the modem subsystem: driver initialization, firmware loading, crash traces, and hardware-level modem events.
driver / firmware / crash
the layer under the baseband
04
IMS, VoLTE and VoNR captures
Network packet captures containing SIP signaling, IMS registration flows, and VoLTE/VoNR call setup messages for voice-over-IP debugging.
SIP / RTP
pcap, pcapng
08 / Procedure
Vendor tools, then upload
01
Qualcomm (DIAG)
1Capture diagnostic logs using QXDM Professional
2Upload the capture as it came off the device; it is decoded on upload
3Optional: a QCAT text export (Tools, Convert log to TXT) is accepted too
4Either form is recognised by content, not by extension
02
MediaTek (MTKLogger)
1Capture modem logs using MTKLogger (DebugLoggerUI on Android 10+). Access via *#*#3646633#*#*
2Modem logs (mdlog) are in binary format. Decode using MediaTek ELT tool
3Export decoded logs as plaintext
4Upload the exported text file to logcat.ai
03
Samsung (Shannon / Exynos)
1Capture CP logs via Samsung SysDump. Dial *#9900# and run CP-based log
2Decode logs using ShannonDM (Exynos) or QXDM/QCAT (Snapdragon)
3Export decoded logs as plaintext
4Upload the exported text file to logcat.ai
04
Radio logcat
1Connect device via ADB
2Run: adb logcat -b radio > radio.log
3Upload the saved log file to logcat.ai
Vendor tool workflows may change across versions. Refer to your vendor's documentation for the latest steps.
How to export
Captures in, cited answers out

How to export your logs

Step-by-step guides for capturing the right logs for analysis. A Qualcomm baseband capture is uploaded as captured; other vendors' proprietary formats are exported to plaintext with their own tools first. We also accept Android logcat, kernel (dmesg) logs, and bugreports to assist with investigation.

The exception

A Qualcomm baseband capture needs no export step. Upload it as it came off the device and it is decoded for you, with no conversion and no vendor tool.

Recognition is by content, not by file extension.
09 / Analyzers for the connectivity stack
Packet captures, modem crashes, and the logs around them
Each with its own analyzer. The modem page reads them together.
10 / Frequently asked questions
Common questions about modem-stack log analysis

The questions we get asked, with the plain answer beside each.

01
What log formats do you support?
A Qualcomm baseband capture as it came off the device, decoded on upload, and any plaintext log file: modem diagnostic exports from Qualcomm QCAT, MediaTek MTKLogger, Samsung CP logs, Android logcat (including radio buffer), dmesg/kernel logs, and pcap captures. For every vendor but Qualcomm, the log must be in human-readable text format.
02
Do I need specific vendor tools?
For a Qualcomm baseband capture, no. Upload it as it came off the device and we decode it for you. For other vendors you will still need their tools to capture and export modem diagnostic logs as plaintext: MediaTek ELT, Samsung ShannonDM, and so on. Either way, logcat.ai itself requires no special tools or plugins. If you already have plaintext logs from logcat, dmesg, or other sources, you can upload those directly.
03
Can you analyze binary/proprietary log formats?
Some of them. Qualcomm baseband captures upload directly, as they came off the device, and are decoded for you with no conversion step and no vendor tool. Other proprietary binary formats (MediaTek MCL, Samsung, and the rest) still need exporting to plaintext with their own vendor tools first, and we work with any plaintext output regardless of which tool produced it. Recognition is by content, not by file extension.
04
What modem protocols can you analyze?
Our AI understands NAS (EMM/ESM for LTE, 5GMM/5GSM for NR), RRC, SIP/IMS, MAC/PHY layer messages, and their interactions. It can trace issues across protocol layers and identify root causes. This is not an exhaustive list. The AI works with any plaintext protocol messages including GTP, RTP, PDCP, RLC, and others as long as they appear in your logs.
05
How does Deep Research work for modem-stack logs?
Deep Research performs multi-step AI investigations within your log file. It iteratively searches for relevant events, follows protocol flows across baseband and framework, and builds a comprehensive analysis, similar to how an expert engineer would manually trace through the logs, but in seconds.
06
What is Delta and how is it different from Deep Research?
Deep Research investigates a single log file in depth: it searches, analyzes, and follows protocol flows within one file. Delta is a multi-file comparison engine: you upload two or more log files (e.g., modem export + logcat radio + kernel log) and Delta correlates events across all of them. Use Deep Research when you have one file and a question. Use Delta when you need to connect events across multiple files, compare behavior between devices, or track down cross-layer issues.
07
Is my log data secure?
Your log data is encrypted in transit (TLS 1.3) and at rest (AES-256), processed in your own tenant, and never used to train AI models. Modem and baseband logs can carry vendor and network details; they are never shared between users. Files are deleted after 90 days, or immediately from your dashboard. Enterprise plans offer on-premise deployment for regulated or air-gapped environments.
11 / Your capture
Frequency across, time down, the answer beside it
00.0
now
the line your capture turns on
The rest of this waterfall is yours. Upload the baseband export, the radio logcat or the kernel trace and read the answer beside it.
Illustrative. Synthetic data.
Start
Baseband, RIL, IMS, telephony

Start analyzing your modem stack logs.

Upload your baseband exports, logcat radio output, or kernel traces and let logcat.ai do the heavy lifting across the device-side stack.

Try playground