hytera USB packet structure


Hello everybody,
I've spent the last couple of months reading through the etsi
documents trying to figure out the packet structure of the 'forward to
pc' option on a hytera radio.
Having done some detective work and comparing packets I can decode
radio ID, LLID, and extract SMS data by bit bashing. I would prefer to
actually understand the whole packet structure so I can decode it
properly rather than blindly extracting the useful data.

The packet does at first appear to be a standard etsi packet,
containing all the blocks.
The issue I'm having is the documents and all open source software I
can find deal with the air side blocks, not a network packet.

Take for example the first 8 bits in the packet : "00001001", which
could be any of the following :
1) 1001 = Idle Data
2) Privacy Flag=0, Reserved Flag=0 and FLCO=001001 making up the first
line in a Full LC header.
3) 001001=8 bit ISO/IEC 8859-7
4) 1001 = SAP 9 = Short Data Services over PDP

Without figuring out some basics, like blocktype I can't work out
which interleaving to use (bptc, hamming etc)

Then there is the LLID. All ETSI documents say it should be
24bits+24bits, but I see the CAI in each address making it 28 or 32
bits for each.

I've attached a text file with some example recieved data split into
colums to make comparision easier for myself.

Im not asking for a full packet decode (although I wouldn't say no!),
just a push in the right direction on how to figure out the packet
type (It must be the first thing transmitted right?)
I realise this isn't a DVSwitch question, but I cant think of a more
knowledgeable group of people on the DMR protocol. If you think there
would be a better place to ask this, please let me know!

Thank you for taking the time to read this, I really hope you can help.


Eric - KF7EEL

From what I have seen with several radios, the IP header is usually in the next block(s) after the header, followed by the data. I have only worked with SMS and GPS  air protocol, ETSI 102 361-1.

All the data that I have decoded has been encoded at 1/2 rate, so BPTC works for decoding. What did you use to capture the data in your txt file?


Hi Eric, thanks for taking the time to help.
Could you have a quick look at my attachment? you might recognise something there I've missed.
GPS is my next protocol, I have captures of that too.
I believe these are standard etsi packets, I think I've just read too much etsi and confused myself :)

These where captured in hex using wireshark. The USB is recognised as a network adapter.


Hi Eric, If you are more familiar with GPS Packets, have you seen a hytera one? Could you tell me the data structure?
I might be miss reading it, but currently I don't see the etsi format of 3+25+24 bits.
I do see a 'N' and a 'W' but the numbers between don't match. Maybe two's compliment?

Eric - KF7EEL

I haven't seen a Hytera GPS packet, but would like to as I may be able to add it to hblink for decoding. All the data types that I have seen have been at 1/2 rate, so BPTC works. When I started investigating a few months ago with wireshark, all the DMR data was encapsulated in an MMDVM packet. I was sniffing traffic from my hotspot to try to decode GPS data. When I finally got something figured out, I built an application for hblink that decodes the data (BPTC, happened to be built into dmr_utils3 python library).

I have seen data from Anyone, TYT, Motorola, and a few others, all encoded at 1/2. Setting SMS settings on my Anyone for H-SMS (believe that is for Hytera) results in SMS encoded at 1/2.

I am guessing that the data you seek is encoded at 1/2 rate. You can enable a setting in PiStar to all least decode the packet header, that would point you in the right direction.

There are also a couple lines in my hblink fork that you can uncomment that will display the raw decoded packets.


Thanks, I'm happy to privately send a GPS packet if it will assist either of us. maybe HBLink could support radio data directly in the future, sound like it could be a case of just listening and responding on a few UDP ports.

I do not have a PiStar, MMDVM etc. Just a standard hytera radio with 'forward to PC' enabled.

I am familiar with dmr_utils3 as I happen to also be writing my 'connector' in python, however am yet to incorporate it into my packet analysis. The initial 9 bytes do appear to align correctly. Hopefully a job for tonight.

Eric - KF7EEL

The BPTC function in dmr_utils3 has at least the last 2 bytes commented out. I'll send you a function for what I have in the next day or so.

Heiko DL1BZ

Hi Kev,

there's a simple answer. The Hytera-IPSC is proprietary. Unlike the "over the air" interface, which follows a clear specification (ETSI), the network side is not subject to such a specification. In hamradio digital voice we mostly use the homebrew protocol, also called MMDVM. Hytera, whose devices are intended for commercial purposes, use their own protocols. Developers usually only get access to this information mostly after they sign an NDA. Which also means that you cannot and may not publish this information that easily. That's why I have to tell you, your search is unlikely to be successful. You will probably not find what you are specifically looking for.
Hytera-IPSC and MMDVM are similar, but also differ in many places. There are already protocol converters Hytera IPSC <> MMDVM, but only for the Hytera repeaters. However, these were previously closed source. But there is an interesting project: https://github.com/OK-DMR/Hytera_Homebrew_Bridge

73 Heiko, DL1BZ


Hi Heiko,
I don't believe hytera's (or motorola's for that matter) radios use ipsc in their 'forward to pc' option on their mobile and handheld radios.
IPSC is a repeater protocol.