Motorola LRRP Protocol

[mmjc23]

Hello guys,

I'm new with Motorola Tetra radios.

My Tetra infrastructure, is able to decode all Tetra communications of the Tetra Motorola radios but not GPS Positions.
The radios are configured to send the GPS position in the LRRP format.
My infrastructure decodes the GPS position sent by the radios as "Simple location system", but it is not able to extract the coordinates.

How can I decode the GPS position? These are examples of the received packets:
80130D232F664119DE9406FC778356A1
801313232F341F8893000F663F7EBBBB07CB07555672
80130D232F664119DE3906FC780056A1

Thank you in advance

 

[mmjc23]

UPDATE
I found this thread in this forum:
https://forums.radioreference.com/voice-control-channel-decoding-software/359575-lrrp-decoding.html

Now, I can extract Latitude and Longitude from received packets.
If I delete the last 2 bytes from received string then I can extract Latitude and Longitude from the last 4 bytes by calculation:

Received packet
801313232F341F8893000F663F7EBBBB07CB07555672
Delete 2 bytes at the end
801313232F341F8893000F663F7EBBBB07CB0755
Extract the last 4 bytes for Longitude (and delete them from received string)
Hex: 07CB0755 - Dec: 130746197 * (360/4294967295) = 10,95901963556163
Extract the last 4 bytes for Longitude
Hex: 3F7EBBBB - Dec: 1065270203 * (180/4294967295) = 44,64495847575482

But...what about other Bytes in receviced packets?
Why GPS strings have different lengths?
Do the "80130" and "80131" bytes at the beginning of the string identify a different protocol type?

Thank you very much

 

[Forts]

The other bytes could be used for heading, speed etc etc....

 

[mmjc23]

The other bytes could be used for heading, speed etc etc....

Thank you Forts,
Is there a document where I can find LRRP specifications and then decode all others bytes?
Why should the latitude be multiplied by (180/4294967295) and the longitude by (360/4294967295)?

Thank you

 

[slicerwizard]

Message Length (13)
8013 0D

Marker Unknown
23 2F

Marker Lat Lon (45.77417, 9.82434)
66 4119DE94 06FC7783

Marker Bearing (322)
56 A1


Message Length (19)
8013 13

Marker Unknown
23 2F

Marker Timestamp (yyyy yyyy yyyy yymm mmdd ddds ssss ssss ssss ssss) 2018/02/09 18:12:31 UTC
34 1F8893000F

Marker Lat Lon (44.64495, 10.95901)
66 3F7EBBBB 07CB0755

Marker Bearing (228)
56 72

Hex: 07CB0755 - Dec: 130746197 * (360/4294967295) = 10,95901963556163

You do not get 17 digits of precision from a 32 bit value. Nor do GPS receivers deliver that level of accuracy.

 

[mmjc23]

Thank you very much slicerwizard

What do you mean about "Marker Bearing"?
Are "66" and "34" respectively the initiator for the coordinates and TimeStamp?

Thank you

 

[slicerwizard]

What do you mean about "Marker Bearing"?

The first byte is the marker/initiator, the second byte is the bearing/heading/direction.

Are "66" and "34" respectively the initiator for the coordinates and TimeStamp?

Yes.

 

[mmjc23]

Thank you slicerwizer...thank you very much

Ok..."Marker Bearing" is the angle direction (excuse me...but...my english is not good)
So I suppose there is not an indicator for position Validity; or...
In my Log I can find these strings:
8013 04 232F 37 12
8013 13 232F 34 1F8892FEC0 66 3F7EA77707CB185B 568D
8013 0A 232F 37 12301F8892FBB9
Can I consider the initiator "37" (or "3712") as an invalid position?

In your opinion, can I cycle on the string in search of the initiators or am I likely to find the initiator inside the data or inside the unknown markers?

Thanks for your support and patience

 

[slicerwizard]

So I suppose there is not an indicator for position Validity;

Unlikely, as in the messages that have lat/lon data, there are no extra fields that look like a radius.

or...
In my Log I can find these strings:
8013 04 232F 37 12
8013 13 232F 34 1F8892FEC0 66 3F7EA77707CB185B 568D
8013 0A 232F 37 12301F8892FBB9
Can I consider the initiator "37" (or "3712") as an invalid position?

It might be. Hard to say though.

In your opinion, can I cycle on the string in search of the initiators or am I likely to find the initiator inside the data or inside the unknown markers?

The initiators could easily be found in data fields. Proceed carefully from left to right.

 

[mmjc23]

OK...Since the strings containing the initiator "37" (or "3712") do not seem to contain the GPS coordinates, I will consider these strings as invalid positions.

The initiators could easily be found in data fields. Proceed carefully from left to right.

You're right...I will proceed from left to right and when I meet one of the initiators I take the number of bytes expected for that data.

Can you confirm that:
-bearing/angle must be multiplied by two (doubled)?
-formulas for calculating latitude and longitude are:
--Latitude * (180/4294967295)
--Longitude * (180/4294967295)

Thank you very much again slicerwizard
I do not know where you found all this information to decode the LRRP protocol

 

[slicerwizard]

Can you confirm that:
-bearing/angle must be multiplied by two (doubled)?

Yes.

-formulas for calculating latitude and longitude are:
--Latitude * (180/4294967295)
--Longitude * (180/4294967295)

No. Latitude has only half the range (+/-90) as longitude (+/-180), so the formulas differ.

For latitude, +/-2M (0x8000 0000) has to be scaled to +/-90, so multiply by 0.00000004190952

For longitude, +/-2M (0x8000 0000) has to be scaled to +/-180, so multiply by 0.00000008381903

Thank you very much again slicerwizard
I do not know where you found all this information to decode the LRRP protocol

I just looked at the raw bytes for some local DMR LRRP transmissions. Knowing the approximate locations makes it possible to figure out the lat/lon formulas. Knowing the precise locations on divided highways makes it possible to figure out direction. Figuring out timestamps takes multiple samples over a few days. And most of the data can be crosschecked against what DSD+ displays for DMR LRRP messages. You're dealing with TETRA LRRP transmissions, but they appear to use the same markers and formulas, so you should be ok.

 

[mmjc23]

Thank you very much slicerwizard!

 

[mmjc23]

Hello slicerwizard,

I have a problem with LRRP Timestamp
The radio shows the correct UTC time in the GPS Position menu, but it is not calculated correctly.

Position sent at 04/06/2018 - 08:46

34 1F89888BA0
1F89888BA0 = 00011111 10001001 10001000 10001011 10100000

yyyy = 00011111100010 = 2018
mm = 0110 = 6
dd = 00100 = 4
ss = 01000101110100000 = *35744‬ -> 09:55:44

Any idea?
Thank you

 

[mmjc23]

Hello slicerwizard,

I have a problem with LRRP Timestamp
The radio shows the correct UTC time in the GPS Position menu, but it is not calculated correctly.

Position sent at 04/06/2018 - 08:46

34 1F89888BA0
1F89888BA0 = 00011111 10001001 10001000 10001011 10100000

yyyy = 00011111100010 = 2018
mm = 0110 = 6
dd = 00100 = 4
ss = 01000101110100000 = *35744‬ -> 09:55:44

Any idea?
Thank you

Hello slicerwizard,

I think I found the formula...

1F89888BA0 = 00011111 10001001 10001000 10001011 10100000
b0 b1 b2 b3 b4

year = Math.Floor(b0 * 256 + b1 / 4)
month = Math.Floor((b1 And &H03) * 4 + (b2 / 64))
day = Math.Floor((b2 / 2) And &H1F)
hour = Math.Floor((b2 And &H01) * 16 + (b3 / 16))
minute = Math.Floor((b3 And &H0F) * 4 + (b4 / 64))
second = b4 And &H3F