QMDL: Qualcomm Diagnostic Log Format Explained — How to Capture and Analyze Field Data

You just finished a 6-hour drive test across three sites. The RRC log shows a handover failure on Site 2 at exactly 14:37. Your post-processing team is in Paris, you’re in Lyon, and they need the raw protocol data — now. You export the QMDL file, send it, and in 10 minutes they’ve decoded the handover sequence frame by frame. QMDL is the universal language of Qualcomm field data.

What is QMDL?

QMDL stands for Qualcomm Modem Diagnostic Log. It is the native binary format output by the Qualcomm DIAG protocol — a diagnostic interface built into every Qualcomm Snapdragon modem. When you capture a QMDL file, you are recording a raw binary stream from the Qualcomm diagnostic port, containing timestamped log packets for every active protocol layer: physical layer measurements, RRC signaling, NAS procedures, PDCP statistics, and more.

Two variants exist in the field. The standard .qmdl format is by far the most common — it is what every rooted Android device with a Snapdragon chipset produces when the DIAG port is opened. The extended .qmdl2 format carries additional metadata including absolute UTC timestamps, and is found on newer Snapdragon 8 Gen 2 and later platforms. For post-processing and sharing with operator teams, .qmdl remains the dominant choice because of its wide parser ecosystem and compatibility with QCAT (Qualcomm Code Activation Tool).

At the binary level, each record in a QMDL file is a DM (Diagnostic Monitor) frame. Every DM frame has a fixed-structure header carrying the log packet code, the frame length, and a QTimerTick timestamp, followed by a payload whose first two bytes are the log packet ID. That packet ID is the key to understanding what the frame contains.

The format is not an open standard. It originates from Qualcomm’s internal diagnostic toolchain and requires either the official QCAT software or a third-party parser that has reverse-engineered the framing and packet structure.

Key QMDL Log Packet IDs

Packet ID (hex)	Content	Protocol
0x1568	LTE RRC OTA message	RRC 36.331
0x5226	NR RRC OTA message	RRC 38.331
0x713A	LTE NAS OTA message	NAS 24.301
0x7030	5G NAS OTA message	NAS 24.501
0x184B	LTE ML1 serving cell meas.	PHY Layer 1
0x2584	NR ML1 serving cell info	PHY Layer 1
0x1472	LTE PDCP DL stats	PDCP Layer 2

QMDL vs QMDL2 vs HLOG

Not all log formats are equal. Understanding the differences between the three most common formats encountered in field work helps you choose the right capture strategy.

Feature	QMDL	QMDL2	HLOG
Format	Binary DM frames	Extended DM binary	Proprietary encrypted
Timestamp	Relative (QTimerTick)	Absolute UTC	Absolute UTC
Encryption	None	None	AEAD encrypted
GPS embedding	No	Optional	Yes
Supported chipsets	Qualcomm (all)	Snapdragon 8 Gen 2+	HiCellTek devices
Ecosystem compatibility	Wide (QCAT, parsers)	Limited	HiCellTek companion
File size	Large (raw)	Large	Compressed

The standard QMDL format wins for interoperability. Its relative QTimerTick timestamps require a conversion step (described in the parsing section below), but its parser ecosystem is wide enough that any major telecom vendor post-processing team can open and decode it without proprietary tooling. QMDL2 extends this with optional GPS embedding and absolute UTC time, but parser support outside QCAT is limited. HLOG is the encrypted, compressed format used by HiCellTek devices — ideal for secure field-to-office transfers, but requires the HiCellTek companion tool for decoding.

For operator trouble ticket submissions and multi-vendor post-processing, QMDL is the format that travels best.

How to Capture QMDL in the Field

Capturing QMDL requires an Android smartphone with a Qualcomm Snapdragon chipset, root access via Magisk, and the DIAG interface enabled on the device. Most field-grade devices with Qualcomm modems expose the DIAG port at /dev/diag.

The log mask is the single most important configuration parameter in any QMDL capture. The mask is sent to the modem via DM command 0x7C and tells the chipset exactly which packet IDs to include in the output stream. An incorrectly configured mask is the most common reason for arriving at post-processing with a QMDL file that contains no RRC messages — a mistake that wastes an entire day of field data. Before starting any long drive, always verify that the mask explicitly enables 0x1568 (LTE RRC), 0x5226 (NR RRC), 0x713A (LTE NAS), and 0x7030 (5G NAS) at minimum.

A typical 1-hour drive at full mask generates between 200 MB and 800 MB of raw QMDL data, depending on network activity, cell density, and the number of enabled packet IDs. For optimization campaigns, plan for 5 to 20 GB of QMDL per device per day.

Parsing QMDL — From Binary to Decoded Protocol

The raw QMDL binary cannot be read directly. Parsing requires four sequential steps that convert the binary stream into human-readable protocol messages.

Step 1 — DM frame extraction: the binary stream is framed using HDLC-like encoding, where 0x7E is the framing byte that marks the beginning and end of each DM frame. The parser must walk the stream, identify boundaries, and extract individual frames. Escaped bytes (0x7D sequences) must be unescaped before processing.

Step 2 — Packet ID lookup: once a frame is extracted, the first two bytes of the payload identify the log packet type. A lookup against a known packet ID table determines whether the frame contains an RRC OTA message, a NAS PDU, a PHY measurement record, or another log type.

Step 3 — ASN.1 decoding: for RRC and NAS frames (0x1568, 0x5226, 0x713A, 0x7030), the payload after the packet header contains an ASN.1 PER-encoded 3GPP message. Decoding this requires a spec-version-aware ASN.1 decoder compiled against the correct 3GPP release (36.331 for LTE RRC, 38.331 for NR RRC, 24.301 for LTE NAS, 24.501 for 5G NAS). The decoded output is identical to what professional field tools display — because the underlying protocol data is the same.

Step 4 — Timestamp conversion: DM frames carry a 32-bit QTimerTick value. Converting this to a wall-clock time requires knowing the chipset’s timer frequency, which is 19.2 MHz on most Snapdragon platforms. The formula is: wall_time = reference_UTC + (QTimerTick / 19200000). The reference UTC anchor is typically extracted from a GPS synchronization event or an NTP timestamp embedded in the capture session.

For teams who need to decode individual RRC or NAS messages extracted from QMDL without running a full parser stack, the online L3 protocol decoder for RRC and NAS messages supports direct paste of hex-encoded protocol payloads and produces structured ASN.1 output.

For engineers who prefer field-native real-time decoding without QCAT, the Android drive test tool with native DIAG access captures and decodes QMDL streams on-device during the drive, eliminating the post-processing round-trip for rapid fault identification.

QMDL in the Field Workflow — Practical Tips

Knowing the format is one thing. Using it efficiently in a real optimization campaign requires a set of operational practices that experienced field engineers develop over years of drive work.

File naming: always include the date, site ID, and drive segment in the file name — for example 2026-03-27_SITE-A_SEG1.qmdl. This makes correlation with GPS tracks and KPI exports trivial and avoids the file disambiguation problem that plagues post-processing teams receiving batches of captures from multiple engineers.

Log rotation: for drives longer than 30 minutes, configure your capture tool to rotate files every 30 minutes. Files exceeding 2 GB cause parsing failures in several common tools and slow down the initial scan step. Smaller files also allow parallel processing of different drive segments.

GPS correlation: QMDL files contain no GPS data by default. The standard approach is to capture a GPX track in parallel and correlate it with the QMDL timestamps after applying the QTimerTick-to-UTC conversion. Some Android drive test tools handle this correlation automatically and embed the GPS in a sidecar file. QMDL2 supports optional GPS embedding, which simplifies this step on supported chipsets.

Evidence for vendor tickets: per 3GPP TS 37.320 (UE test mode), QMDL logs with RRC message timestamps are accepted as primary evidence in vendor trouble ticket escalations. When preparing a ticket, extract the relevant 0x1568 or 0x5226 frames around the failure event, convert them to human-readable ASN.1, and attach both the raw QMDL segment and the decoded output. This combination eliminates ambiguity about what the UE actually sent and received.

Privacy and security: QMDL files contain the device IMSI and IMEI in NAS Attach and Registration Request packets. Before sharing any QMDL file outside your organization — with vendors, operators, or partners — strip or anonymize the NAS payloads containing these identifiers. Failure to do so constitutes a personal data leak under GDPR Article 4(1), as IMSI is a directly linkable subscriber identifier.

Storage planning: a typical LTE/NR optimization campaign generates 5 to 20 GB of QMDL per device per day. For a team of four engineers running a two-week campaign, this translates to 280 to 1,120 GB of raw data. Plan your field storage, transfer, and archival infrastructure accordingly before the campaign starts — not after.

Conclusion

QMDL is not just a file format — it is the most complete record of what happened between a device and a network at every protocol layer. Knowing how to capture it efficiently, parse it correctly, and extract the right packet IDs separates an engineer who says “I saw a handover failure” from one who can prove it with a timestamp-accurate RRC sequence.

The four packet IDs that cover 90% of field troubleshooting scenarios are 0x1568, 0x5226, 0x713A, and 0x7030. Master the log mask that enables them, understand the HDLC-like framing that structures the binary stream, and apply the QTimerTick conversion for accurate time correlation — and QMDL becomes a diagnostic instrument as precise as the network specification itself.

Question for the comments: what has been the most complex issue you resolved with QMDL analysis — and what packet ID was the key?