RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Computer Aided Monitoring and Programming > Voice/Control Channel Decoding Software


Voice/Control Channel Decoding Software - For discussion of software applications which decode digital voice formats and trunking control channels. Please use the HF Digital Signals forum for anything below 30MHz.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 05-07-2018, 3:24 AM
Member
   
Join Date: May 2018
Posts: 9
Default Motorola LRRP Protocol

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
Reply With Quote
Sponsored links
  #2 (permalink)  
Old 05-07-2018, 6:49 AM
Member
   
Join Date: May 2018
Posts: 9
Default

UPDATE
I found this thread in this forum:
https://forums.radioreference.com/vo...-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
Reply With Quote
  #3 (permalink)  
Old 05-07-2018, 8:18 AM
Forts's Avatar
Mentor
  RadioReference Database Admininstrator
Database Admin
Audio Feed Provider
Audio Feed Provider
 
Join Date: Dec 2002
Location: Strathroy, Ontario Canada
Posts: 5,580
Default

The other bytes could be used for heading, speed etc etc....
__________________
Middlesex County/Strathroy-Caradoc Fire Paging Alerts: http://groups.google.com/group/middlesex-fire
Reply With Quote
  #4 (permalink)  
Old 05-07-2018, 8:26 AM
Member
   
Join Date: May 2018
Posts: 9
Default

Quote:
Originally Posted by Forts View Post
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
Reply With Quote
  #5 (permalink)  
Old 05-07-2018, 11:32 AM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 4,618
Default

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


Quote:
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.
Reply With Quote
Sponsored links
  #6 (permalink)  
Old 05-08-2018, 1:07 AM
Member
   
Join Date: May 2018
Posts: 9
Default

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
Reply With Quote
  #7 (permalink)  
Old 05-08-2018, 7:22 AM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 4,618
Default

Quote:
Originally Posted by mmjc23 View Post
What do you mean about "Marker Bearing"?
The first byte is the marker/initiator, the second byte is the bearing/heading/direction.


Quote:
Are "66" and "34" respectively the initiator for the coordinates and TimeStamp?
Yes.
Reply With Quote
  #8 (permalink)  
Old 05-08-2018, 7:51 AM
Member
   
Join Date: May 2018
Posts: 9
Default

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
Reply With Quote
  #9 (permalink)  
Old 05-08-2018, 10:23 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 4,618
Default

Quote:
Originally Posted by mmjc23 View Post
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.


Quote:
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.


Quote:
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.
Reply With Quote
  #10 (permalink)  
Old 05-09-2018, 1:22 AM
Member
   
Join Date: May 2018
Posts: 9
Default

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.

Quote:
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
Reply With Quote
  #11 (permalink)  
Old 05-09-2018, 5:12 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 4,618
Default

Quote:
Originally Posted by mmjc23 View Post
Can you confirm that:
-bearing/angle must be multiplied by two (doubled)?
Yes.


Quote:
-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


Quote:
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.
Reply With Quote
  #12 (permalink)  
Old 05-11-2018, 1:06 AM
Member
   
Join Date: May 2018
Posts: 9
Default

Thank you very much slicerwizard!
Reply With Quote
  #13 (permalink)  
Old 06-04-2018, 6:24 AM
Member
   
Join Date: May 2018
Posts: 9
Default

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
Reply With Quote
  #14 (permalink)  
Old 06-04-2018, 8:46 AM
Member
   
Join Date: May 2018
Posts: 9
Default

Quote:
Originally Posted by mmjc23 View Post
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
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 6:44 PM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions