If you have ever opened a QXDM capture from a misbehaving modem, you know the feeling. Thousands of messages scroll past. NAS, RRC, MAC, PHY — layers upon layers of protocol activity, most of it routine, all of it potentially relevant. Somewhere in there is the answer to why the device dropped its data session at 3am, but finding it is going to take a while.
I have spent a lot of time staring at QXDM logs over the years, working on cellular telematics devices with Qualcomm modems. It is one of those skills that takes years to develop and never quite feels routine. Every capture is a puzzle, and the pieces are scattered across protocol layers with names that read like alphabet soup.
Recently I started throwing these captures at AI tools, mostly out of curiosity. The results have been good enough that it has changed how I approach modem debugging.
The Problem with QXDM Analysis#
For anyone unfamiliar, QXDM is Qualcomm’s diagnostic tool for capturing and viewing messages between the modem firmware and the cellular network. It logs everything — the full conversation between your device and the tower, from the initial attach procedure through bearer setup, data sessions, handovers, and disconnects.
The challenge is not getting the data. QXDM gives you all of it, sometimes too much. The challenge breaks down into three parts:
Sheer volume. A ten-minute capture from an active device can contain tens of thousands of messages. Most of them are routine — measurement reports, keep-alives, status updates. The interesting stuff, the messages that explain why something went wrong, might be a handful of entries buried in the middle.
Domain knowledge. Even once you find a relevant message, understanding what it means requires fairly deep knowledge of 3GPP specs, Qualcomm-specific implementations, and how various information elements interact. What does this particular reject cause code mean? Why did the network send this configuration? Is this RRC reconfiguration normal for this carrier? These are not questions you can answer without experience or a lot of spec reading.
Cross-layer correlation. Cellular problems rarely live in a single protocol layer. A data session failure might start with an RRC reconfiguration at the radio layer, propagate through a NAS reject at the network layer, and surface as a PDN connectivity failure at the application layer. Understanding the full picture means mentally stitching together messages across layers and time — which is tedious and error-prone even when you know what you are looking for.
What AI Actually Does Well Here#
I want to be specific about where AI tools have helped, because the value is not evenly distributed across these problems.
Filtering Signal from Noise#
This is the biggest win. I export a QXDM capture to a text format and feed it to Claude Code. Then I say something like “find the sequence of events leading up to the data session drop at timestamp X.” The AI is very good at scanning through thousands of messages, ignoring the routine stuff, and pulling out the relevant sequence.
What used to be 20 minutes of scrolling and filtering becomes a few seconds. The AI identifies the key messages, presents them in order, and usually gets the selection right. I still sanity-check it against the raw capture, but it narrows the search space to the point where I am reviewing a handful of messages instead of thousands.
Explaining What Messages Mean#
This is where the domain knowledge gap gets smaller. I can point at a NAS message and ask “what does this reject cause code mean and what typically causes it?” or look at an RRC reconfiguration and ask “is this a normal handover configuration for LTE Band 4?” and get a useful answer.
It is not perfect. There are Qualcomm-specific quirks and carrier-specific configurations where the AI clearly does not have enough training data. But for the standard 3GPP stuff — cause codes, message types, information elements, state transitions — it knows enough to save me from digging through specs every time.
The practical value here is huge for teams where not everyone has ten years of cellular experience. A less experienced engineer with an AI tool can now make meaningful progress on QXDM analysis instead of being completely blocked until a senior person is free to help.
Call Flow Reconstruction#
When I need to understand a complete attach sequence or troubleshoot a handover failure, I ask the AI to reconstruct the call flow from the capture. It pulls out the relevant messages in order, labels the direction (UE to network vs network to UE), and summarizes what is happening at each step.
This is work I can do myself, but it takes time. The AI does it fast and formats it in a way that is easy to follow. I then use that reconstructed flow to spot where things diverged from what I expected. “The attach procedure looks normal until step 7, where the network responded with X instead of Y” — that kind of analysis goes from a 30-minute exercise to a 2-minute conversation.
Comparing Good and Bad Captures#
This is maybe the most useful thing I have found. When I have a device that works and one that does not, both on the same network, I export both QXDM captures and ask the AI to compare them. “What is different about the attach procedure between these two captures?”
Manually diffing two QXDM captures is painful. The timestamps do not align, the message ordering might differ slightly, and there is so much common noise that the real differences are hard to spot. The AI handles this well — it abstracts away the routine messages and highlights the meaningful differences. “In the working capture, the network assigned QoS profile X; in the failing capture, it assigned Y. That is your divergence point.”
This has cut down investigation time on some issues from hours to minutes.
Where It Still Struggles#
Qualcomm-specific internal messages. QXDM captures include Qualcomm proprietary diagnostic messages that are not part of the 3GPP standard. The AI generally does not know what these mean, and when it tries to interpret them, it is often wrong. I have learned to explicitly tell it to skip those and focus on the standard protocol messages.
Carrier-specific behavior. Different carriers configure their networks differently, and what is normal on one carrier might be unusual on another. The AI does not always know these differences. When I ask “is this behavior normal?” the answer I get is whether it is normal per spec, not whether it is normal for a specific carrier deployment.
Very large captures. There is a practical limit on how much data you can feed to the AI in one session. A multi-hour QXDM capture exported to text can be enormous. I usually have to pre-filter or split the capture before the AI can process it, which means I need to have some idea of what time range to look at. This is not a deal-breaker, but it means the AI is not quite a “just throw the whole thing at it and get answers” solution for very long captures.
Subtle timing issues. When a problem is related to timing — a message arrived too late, a timer expired, a race condition between layers — the AI sometimes misses it. It is good at the logical sequence of events but less good at spotting when the timing of those events is the problem.
How I Actually Use It#
My workflow for a QXDM analysis session now looks like this:
- Reproduce the issue or get a capture from the field
- Export the relevant time window to text
- Feed it to Claude Code with context about what the problem is
- Ask for the event sequence leading up to the failure
- Follow up with specific questions about messages or behaviors I do not understand
- If I have a working device for comparison, feed both captures and ask for differences
Steps 4 through 6 are iterative. I go back and forth, asking follow-up questions, requesting deeper analysis of specific messages, and occasionally correcting the AI when it misinterprets something. The whole thing is a conversation, not a one-shot query.
The result is that I get to the root cause faster, I learn things about the protocol stack along the way, and I can communicate findings more clearly to the team because the AI helps me articulate what happened in plain language.
The Bigger Point#
QXDM analysis is one of those skills that has traditionally been a bottleneck. Only a few people on any team really know how to do it well, and those people are always overloaded. AI does not eliminate the need for expertise — you still need to know what questions to ask and when the AI is wrong. But it brings the floor up. It lets less experienced engineers make progress on problems that used to require senior attention.
For me personally, it has made cellular debugging less of a grind. The tedious parts — the scrolling, the filtering, the spec lookups — are the parts the AI handles best. That leaves me more time for the parts that actually require thinking.
If you work with QXDM captures and have not tried feeding them to an AI, take a capture you have already analyzed manually and see if the AI reaches the same conclusion. You might be surprised how well it does.