Full Link Control, namely: Group Voice, Unit-Unit, Talker Alias (header + blocks1,2,3), GPSInfo, Terminator with LC
SHORT LC
✅
Short Link Control, namely: Activity, Null
SLOT
✅
Slot Type
SYNC
✅
Synchronization patterns
Data Header
✅
Confirmed/Unconfirmed, Response, Defined Short Data
PI Header
✅
Privacy (PI) Header, without further understanding of transported data
Rate 1 Data
✅
Rate 1 data (confirmed and unconfirmed) and last block data (confirmed and unconfirmed)
Rate 1/2 Data
✅
Rate 1/2 data (confirmed and unconfirmed) and last block data (confirmed and unconfirmed)
Rate 3/4 Data
✅
Rate 3/4 data (confirmed and unconfirmed) and last block data (confirmed and unconfirmed)
Full/Short Link Control
✅
FLC/SLC PDUs
UDP/IPv4
✅
UDP/IPv4 compressed header/packet
ETSI Information Elements
All listed elements are supported as standalone enum/class representation, which allows for decoding/encoding and
describing data (discovery):
Access Types (AT), CRC Mask, CSBKO (CSBK Opcode), DPF (Data Packet Format), DT (Data Type), FID (Feature Set ID), FLCO (
Full LC Opcode), LCSS (LC Start/Stop), PI (Pre-emption and power control indicator), SLCO (Short LC Opcode), SYNC (
Synchronization pattern), Activity ID, Additional Information Field, Answer/Response, CTO (Channel Timing Opcode), DI (
Dynamic Identifier), Position Error, Reason Code, Service Options, Talker Alias Data Format, Defined Data Format (DD),
Selective Automatic Repeat reQuest (SARQ),
Re-Synchronize Flag (S), Send sequence number (N(S)), SAP identifier (SAP), Supplementary Flag (SF), Unified Data
Transport Format (UDT Format), UDP Port Identifier (SPID/DPID), IP Address Identifier (SAID/DAID)
Hytera
Protocol Name
Encoding / Decoding
Hytera Simple Transport Reliability Protocol (HSTRP)
✅
Hytera Radio Network Protocol (HRNP)
✅
Hytera DMR Application Protocol (HDAP)
✅
Radio Registration Service (RRS)
✅
Location Protocol (LP)
✅
Radio Control Protocol (RCP)
✅
Text Message Protocol (TMP)
✅
Not all opcodes in all protocols are implemented, however it will fail with descriptive message, which opcode is
missing in particular operation (decoding, description, encoding)
Motorola
Protocol Name
Encoding / Decoding
Location Request Response Protocol (LRRP)
✅
Automatic Registration Service (ARS)
✅
Text Messaging Service (TMS)
✅
Motorola has MBXML (Motorola Binary XML) which is used to represent LRRP/ARRP documents, ok-dmrlib contains abstract
MBXML implementation with various tools, LRRP implementation tested with both examples and real-world data
LRRP is supported as [bytes] <-> [mbxml document(s)] -> [xml representation], currently serialization of xml
document to bytes is not supported
There are some catches, when you want to serialize MBXML token with common name, look through the test_mbxml and
test_lrrp modules, to see how to select specific (correct) token programatically
Available CLI tools
dmrlib-pcap-tool - PCAP/PCAPNG traffic description and data extraction
dmrlib-dmr-burst - Describe full Tier-II burst (33 bytes)
dmrlib-dmr-header - Describe DMR Data Header
dmrlib-dmr-ipudp - Describe DMR UDP/IPv4 Compressed data (header + user payload)
dmrlib-hytera-hstrp - Hytera Simple Transport Protocol
dmrlib-hytera-hrnp - Hytera Radio Network Protocol
dmrlib-hytera-lp - Hytera Location Protocol
dmrlib-hytera-rcp - Hytera Radio Control Protocol
dmrlib-hytera-rrs - Hytera Radio Registration Service
dmrlib-hytera-tmp - Hytera Text Message Protocol
Additional notes
Almost every class/enum supports BitsInterface (de-serialization from on-air bits, serialization to transmission bits)
, or for byte-aligned protocols (Hytera, Motorola) BytesInterface (with explicit endianness support)
Every FEC/CRC implemented supports both calculation, verification and (if possible) also self-correction
Working with Vocoder and Data/Control Bursts is supported, along with handling rates 1, 1/2 and 3/4
CRCs interface classes may require appropriate CRC Mask to be provided when generating or verifying
Through dmr-kaitai handling of ETSI, Hytera and MMDVM/Homebrew UDP data is
supported
To inspect on-wire traffic PcapTool (provided in cli as dmrlib-pcap-tool script) supports PCAP/PCAPNG files with
various functions on describing bursts, port/data filtering, data extraction, ...
Everything is tested, specifically now we have 95% pytest coverage for whole ok-dmrlib codebase
Not everything is probably documented as it should be, but the usage should always be very clear, when you look at
tests of particular component
I am not a tech guy that much so I need some help with installing it. Could you please leave your email address or another contactable form so I can contact you?
Hi, I'm trying to implement in MMDVMHost the DMR tier III reverse channel commands for MS de-key and MS power control.
I use ok-dmrlib to generate the 32 bit PDUs, but the radios do not respond to the commands so there seems to be some issue with my code.
I figured out by myself that in VBPTC3211 I have to invert the parity bits row to odd in the set_parity() method and changed it accordingly. I'm not so sure about CRC7 configuration.
I wonder if you could help me troubleshoot my ok-dmrlib code below. Otherwise, the EMB fields are set with LCSS 0, PI 1 and correct colour code. The PDU is only transmitted in voice burst F so that seems fine as well.
ba = bitarray('0100')
CRC7_conf = BitCrcConfiguration(
width_bits=7,
polynomial=0x27,
init_value=0x00,
final_xor_value=0x7A,
reverse_input_bytes=False,
reverse_output_bytes=False,
)
crc7_calc = BitCrcCalculator(CRC7_conf, True)
crc7_nm = crc7_calc.calculate_checksum(ba)
print(crc7_nm)
ba = ba + crc7_nm
out = VBPTC3211.encode(ba)
print(out)
pad = bitarray('0000')
padl = bitarray('0000')
pad.extend(out)
pad.extend(padl)
all_bytes = bits_to_bytes(pad)
readable = all_bytes.hex(',').split(',')
x = str()
for i in readable:
x += "0x" + i + ', '
print(x)
Hi, I want to do generic data transmission over tier 2 with mmdvm for RF.
But sadly I have no idea how to start because of missing documentation. If I would know, at which files to look, for connecting to mmdvm, to transmit/receive generic data, I probably could figure it out by myself, but I don't know where to look.
More documentation or even better some simple examples, for example just sending hello world and receiving it, would be much appreciated.
Thx
Can you help me understand the CRC 32 Bit used in this code,
For data sample "d6790062620003bf000700000000000000000000" your CRC32 is "210b9a3d"
As per my understanding of your code, we are doing the following steps -
1. First is byte swap
o/p: 79d662000062bf03070000000000000000000000
2. Then for each byte, we are doing bit reverse
o/p: 9E6B46000046FDC0E00000000000000000000000
3. And applying crc32 with polynomial: 0X04C11DB7
But as I follow the above steps on my code using the same data sample my CRC32 bits come to be different. The other things like CC, and Data/Payload look good while decoding but my CRC Comes out to be different.