Also known as: FID, feature-set ID, vendor FID
The DMR Feature-set ID (FID) is the second octet of a CSBK, and it
tags the block as either standard ETSI signalling or a vendor extension.1 ETSI TS 102 361-4
reserves FID 0x00 for standard trunking; the major MotoTRBO and Hytera trunking products tag
their proprietary CSBKs with a vendor FID.2 A decoder must read the FID before the
opcode, because a vendor block’s 6-bit opcode can collide with a standard one — dispatching on
opcode first would misread a proprietary block as, say, a standard TalkGroup Voice Channel Grant
and emit a bogus grant.
The recognised FIDs
GopherTrunk maps four vendor FIDs onto three trunking feature sets, with everything else treated as standard ETSI:
| FID | Vendor | Trunking product |
|---|---|---|
| 0x00 | ETSI standard | Dedicated-control Tier III |
| 0x10 | Motorola | Capacity Plus / Capacity Max |
| 0x06 | Motorola | Connect Plus |
| 0x08 | Hytera | XPT |
| 0x68 | Hytera | XPT (alternate feature-set tag) |
How each vendor is handled
The handling deliberately differs by how much of each vendor’s signalling has been validated
against real signals. Capacity Plus / Capacity Max (FID 0x10) carry their voice grants in the
same ETSI-shaped 8-octet payload as standard trunking, so those blocks decode straight through the
standard ParseTVGrant / ParsePVGrant parsers and publish normally; the
Capacity Plus rest channel is tracked from its system-info CSBK, whose
site-ID field doubles as a pointer to the current rest channel’s LCN.
Connect Plus (FID 0x06) and Hytera XPT (FID 0x08 / 0x68) use materially different
proprietary signalling. Their CSBKs are recognised and logged at debug level, but they are not
force-parsed as standard grants — doing so would emit garbage, since their payload layouts are not
the ETSI ones. On-air capture validation of the Connect Plus and XPT
payload formats is the remaining follow-up; until then, the honest posture is to surface that a
recognised vendor block arrived without pretending to understand its contents. Publishing a vendor
grant does not change the voice path — the protocol stays “dmr-tier3” because vendor trunking
alters the control layer, not the voice codec, so the recorder and vocoder are unaffected.
Why order matters
The single reason FID dispatch comes first is opcode collision. The 6-bit CSBKO space is small and
vendors reuse values freely, so a Connect Plus block with opcode 0x30 is not a Private Voice
Channel Grant even though the standard set assigns that value to one. Reading the FID first routes
the block to the right handler before any opcode-based parsing runs; only after a block is confirmed
to carry FID 0x00 (or a vendor whose grants are known to match the ETSI layout) is the standard
opcode table consulted. This ordering is what keeps a mixed-vendor RF environment from producing
phantom grants.
Relevance to SDR
internal/radio/dmr/tier3/vendor.go defines the FID constants, VendorFromFID mapping, and
handleVendorCSBK, which switches on the recognised vendor: Motorola grants flow through the shared
grant parsers and the Capacity Plus rest channel is latched from the broadcast/Aloha system-info,
while Connect Plus and Hytera blocks are logged as recognised-but-unparsed. Dispatching on FID
before opcode is the guard that lets GopherTrunk sit on a real trunked system carrying several
vendors’ traffic and only act on the blocks it can decode correctly.
Sources
-
Digital mobile radio — Wikipedia, on DMR trunking and the MotoTRBO and Hytera product families. ↩
-
ETSI TS 102 361-4 (DMR Tier III) — ETSI, which reserves FID 0x00 for standard trunking and leaves other values to vendors. ↩