From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: linux-bluetooth@vger.kernel.org
Subject: [PATCH BlueZ v2 02/12] doc/btmon: Add dedicate sections for timestamp and frame number
Date: Fri, 20 Feb 2026 12:31:06 -0500 [thread overview]
Message-ID: <20260220173120.3418666-2-luiz.dentz@gmail.com> (raw)
In-Reply-To: <20260220173120.3418666-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds sections for how timestamp and frame numbers are generated
and explaim the difference between a frame number and a line number.
---
doc/btmon.rst | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/doc/btmon.rst b/doc/btmon.rst
index e51001921ab1..de05a5fcd6df 100644
--- a/doc/btmon.rst
+++ b/doc/btmon.rst
@@ -442,6 +442,41 @@ Example of protocol layering in ACL data::
Authentication requirement: Bonding, MITM, SC (0x2d)
Max encryption key size: 16
+Timestamp Notes
+---------------
+
+When reading btsnoop files with ``-t`` or ``-T``, timestamps reflect the
+wall-clock time recorded in the btsnoop file. The precision depends on
+the source:
+
+- **Live capture** (``btmon`` monitor channel): Microsecond precision
+ from the kernel.
+- **btsnoop files**: The btsnoop format stores timestamps as
+ microseconds since epoch, so full microsecond precision is
+ preserved. Trailing zeros in the display (e.g., ``14:38:46.589000``)
+ indicate the original capture source had millisecond granularity.
+
+The default timestamp mode shows seconds elapsed since the first
+packet in the trace, which is useful for measuring intervals between
+events without needing to know the absolute time.
+
+Frame Numbers vs Line Numbers
+-----------------------------
+
+btmon assigns sequential **frame numbers** (``#N``) to HCI packets.
+These are stable identifiers for specific packets regardless of output
+formatting. However, when processing btmon text output with tools like
+``grep`` or ``sed``, the relevant unit is **line numbers** in the output
+file. The two are unrelated:
+
+- A single frame may produce many output lines (header + decoded
+ fields).
+- Frame numbers only apply to HCI traffic (``<`` and ``>``). MGMT
+ (``@``) and system notes (``=``) do not have frame numbers.
+- When referencing specific packets, prefer frame numbers (``#487``)
+ over line numbers, as frame numbers are stable across different
+ terminal widths and formatting options.
+
Practical Reading Guide
-----------------------
--
2.52.0
next prev parent reply other threads:[~2026-02-20 17:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 17:31 [PATCH BlueZ v2 01/12] doc/btmon: Add missing documentation Luiz Augusto von Dentz
2026-02-20 17:31 ` Luiz Augusto von Dentz [this message]
2026-02-20 17:31 ` [PATCH BlueZ v2 03/12] doc/btmon: Add connection tracking section Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 04/12] doc/btmon: Add a dedicated section for analyze mode Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 05/12] doc/btmon: Add a section for automated trace analysis Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 06/12] doc: add btsnoop protocol manpage Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 07/12] doc/btmon: Add reference to btsnoop documention Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 08/12] monitor: Annotate ACL/SCO/ISO data with device address Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 09/12] monitor: Print connection type in Disconnect Complete Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 10/12] monitor: Add connection lifecycle to analyze summary Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 11/12] monitor: Prefix data packets with proper type Luiz Augusto von Dentz
2026-02-20 17:31 ` [PATCH BlueZ v2 12/12] doc/btmon: Update documentation to reflect lastest changes Luiz Augusto von Dentz
2026-02-20 18:25 ` [BlueZ,v2,01/12] doc/btmon: Add missing documentation bluez.test.bot
2026-02-20 20:20 ` [PATCH BlueZ v2 01/12] " patchwork-bot+bluetooth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260220173120.3418666-2-luiz.dentz@gmail.com \
--to=luiz.dentz@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox