Replies: 1 comment
-
It's not something i am aware of, I have only Motorola ADK "Text Messaging Protocol Specification" version 01.02, this is definitely newer. I'd expect the newer version of protocol to follow the same structure, so you can try to parse it in similar way the older protocol does it, check the tests of TextMessagingService (which is OOP representation of TMS PDUs) https://github.com/OK-DMR/ok-dmrlib/blob/master/okdmr/tests/dmrlib/motorola/test_tms.py Can you share payloads please? You can e-mail me if you'd prefer |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi Marek, I'm trying to decode a Hyetra text message protocol sent on a dedicated channel (tier 3). From what I can tell, the format of the long text message does not match with the TMP format in ok-dmrlib, so I assume it is something different.
There are two versions of the protocol, the first one starts with a magic of 0x0101, the second one with 0x0201. Air interface PDUs are using confirmed data format with SAP 9 and a second header appended at the end of all data blocks. The last data block contains unknown data (no valid DBSN, CRC9, CRC32). Message CRC32 is in the second to last data block.
In both cases, the text payload length (16 bits) can be found starting with byte offset 36 and 38 respectively so the difference is two bytes between the two versions. Source address starts at offset 17 or 19. Destination address at offset 25 or 27. G/I indicator is at offset 24 or 26. Actual message payload starts at offset 38 or 40 depending on version. Radio docs say this format can support a 500 character message max. vs. the 46 max. for UDT SMS on control ch.
Is this protocol like anything you ever encountered?
Beta Was this translation helpful? Give feedback.
All reactions