DSDPlus Trying to analyze the Packet Data of P25 in version DSD+ 2.441 (LRRP/Location)

[slicerwizard]

Effectively the ACK is the recognition, but the RESP corresponds or requests a response, a confirmation of having received that message and responds that the RX OK message is received, not that it has recognized that station.

OMG. The ACK is the response!

Confirmed data transmissions get a response - ACK/OK or NAK/Retry.

It's right there. The message in question is a RESPonse and that response is ACK.

RESP is a response, not a request for a response. The request for a response is "Conf Data" - the sender specifies that a confirmation response is required.

BTW, your claim that the one transmission is both a request for a response sent by the message originator and the recipient's response is quite frankly, ludicrous.

 

[noamlivne]

@noamlivne, I imagine that you have the formulas to extract the LRRP, they posted them here a long time ago, but those formulas are not complete and depending on where the issuer is, they will be wrong.

Yes, I know how to extract the Date, Time and Coordinates (and thankfully also the DSDPlus programmers know how to do it - and they do it excellently).
What I do not know for sure is how to calculate the Direction and Speed.
Unfortunately, in my system there are not too many instances of Direction and Speed so I cannot check for sure, but when they do appear it seems that DSDPlus does not calculate them correctly. But that needs to be checked by other users with other systems as well.

 

[mtindor]

Looking at the Packet Data window and files of the new DSD+ version, one can notice raw LRRP (location) data that is sent in the input frequencies of the P25 system. At least this is the case at my local system. See details below.

This is not relevant for the output frequencies of the system where the LRRP data is lacking and probably not really useful.

I noticed that LRRP data is sent when the SrcPort is the traditional 4001 (LRRP) port, but also in other cases where the SrcPort is some kind of random(?) number. I find it by looking at the packets and finding my raw Hex Lat and Lon values that I get familiar with when skimming the packets.

Hopefully the authors of DSDPlus Fastlane (and DSD FME, @lwvmobile , and SDRTrunk, @DSheirer ) can automate this long process of manually calculating the location, and showing it on a map.

I based my findings on the thread DSD+ I can see LRRP and ARS. Why there are no GPS positions? and especially on the entries DSD+ I can see LRRP and ARS. Why there are no GPS positions? and DSD+ I can see LRRP and ARS. Why there are no GPS positions? and the pics from the users @SignalPatcher and @G125. For example, this is probably relevant to DMR LRRPs:
View attachment 151376

This is my P25 data, for example, and obfuscated a bit for privacy reasons:
View attachment 151377
In my case:
34 is the indication of Date.
1F9EDEEA39 is the Year Month Day Hour Minutes Seconds (I think). I did not get an accurate result (maybe the clock in the P25 system is incorrect) but you can see that if you convert this Hex value to Dec value, for example at Hexadecimal to Decimal Converter you see that the Binary representation of the first 11 digits (11111100111) is 2023 (which is the current year).

Using your "search for date" theory on a local WVSIRN site in West Virginia (Motorola P25):

2023-12-06 10:36:34 BEE00.170-3.1 CONF DATA SAP=0 MFID=00 Blocks=6 LogicalLinkID=98215 Aff'd TG=2207
2023-12-06 10:36:34 BEE00.170-3.1 0 18F 510045C0 0052A143 0000FF01 3FD80A33 Q.E..R.C....?..3
2023-12-06 10:36:34 BEE00.170-3.1 1 087 02FA0A48 C25A0300 D57C0000 00004500 ...H.Z...|....E.
2023-12-06 10:36:34 BEE00.170-3.1 2 1A6 0036E721 00003F11 BC4C0A48 C25A0A33 .6.!..?..L.H.Z.3
2023-12-06 10:36:34 BEE00.170-3.1 3 0E7 0174E5F6 0FA10022 DE970D18 2203FFFF .t....."...."...
2023-12-06 10:36:34 BEE00.170-3.1 4 084 CC341F9F 0CF92166 3982FB41 C6B04CFB .4....!f9..A..L.
2023-12-06 10:36:34 BEE00.170-3.1 5 0BE 6B14565E AAAAAAAA AAAAAAAA 9C5EEFEE k.V^.........^.. IPv4; ICMP; Src=10.51.2.250 Tgt=10.72.194.90


On a local WVSIRN site here (Motorola P25):

1F9FOCF921 = 11111100111 1011 01111 01110 101000 111001

11111100111 1100 00110 01111 100100 100001
2023        12   6     15    36     33

It was date stamped on my computer as 2023-12-06 10:36:34 (which is UTC-5)

Looks like you have it correct (at least in my case) about Year/Month/Day/Hour/Minutes/Seconds

The difference between the hour (10 UTC-5) in my logs and (15) would be that they likely display the time in UTC on the system.

So nice sleuthing on that part! Now onward to see if I can figure out if the next bit is lat/long info and to see if I can find a clue as how to properly decode it.

Mike

 

[Red_Ice]

Using your "search for date" theory on a local WVSIRN site in West Virginia (Motorola P25):

2023-12-06 10:36:34 BEE00.170-3.1 CONF DATA SAP=0 MFID=00 Blocks=6 LogicalLinkID=98215 Aff'd TG=2207
2023-12-06 10:36:34 BEE00.170-3.1 0 18F 510045C0 0052A143 0000FF01 3FD80A33 Q.E..R.C....?..3
2023-12-06 10:36:34 BEE00.170-3.1 1 087 02FA0A48 C25A0300 D57C0000 00004500 ...H.Z...|....E.
2023-12-06 10:36:34 BEE00.170-3.1 2 1A6 0036E721 00003F11 BC4C0A48 C25A0A33 .6.!..?..L.H.Z.3
2023-12-06 10:36:34 BEE00.170-3.1 3 0E7 0174E5F6 0FA10022 DE970D18 2203FFFF .t....."...."...
2023-12-06 10:36:34 BEE00.170-3.1 4 084 CC341F9F 0CF92166 3982FB41 C6B04CFB .4....!f9..A..L.
2023-12-06 10:36:34 BEE00.170-3.1 5 0BE 6B14565E AAAAAAAA AAAAAAAA 9C5EEFEE k.V^.........^.. IPv4; ICMP; Src=10.51.2.250 Tgt=10.72.194.90


On a local WVSIRN site here (Motorola P25):

1F9FOCF921 = 11111100111 1011 01111 01110 101000 111001

11111100111 1100 00110 01111 100100 100001
2023        12   6     15    36     33

It was date stamped on my computer as 2023-12-06 10:36:34 (which is UTC-5)

Looks like you have it correct (at least in my case) about Year/Month/Day/Hour/Minutes/Seconds

The difference between the hour (10 UTC-5) in my logs and (15) would be that they likely display the time in UTC on the system.

So nice sleuthing on that part! Now onward to see if I can figure out if the next bit is lat/long info and to see if I can find a clue as how to properly decode it.

Mike

The speed and azimuth do not appear although the azimuth could be 188, but it is not correct information since the speed byte does not appear for its calculation, as for the latitude/longitude it corresponds to 40.43787633544716/-80.59405123828772 (3982FB41 C6B04CFB ).

 

[mtindor]

The speed and azimuth do not appear although the azimuth could be 188, but it is not correct information since the speed byte does not appear for its calculation, as for the latitude/longitude it corresponds to 40.43787633544716/-80.59405123828772 (3982FB41 C6B04CFB ).

View attachment 153819

BINGO! That would definitely be the right lat/long.

 

[Red_Ice]

In this case they have corrected the problem of the geographical area since the formula varies if the result is greater than 90 in latitude and 180 in longitude.

 

[noamlivne]

The speed and azimuth do not appear although the azimuth could be 188, but it is not correct information since the speed byte does not appear for its calculation, as for the latitude/longitude it corresponds to 40.43787633544716/-80.59405123828772 (3982FB41 C6B04CFB ).

View attachment 153819

I also have issues with the Direction and Speed. I hope someone will be able to figure it out and give DSDPlus team the right formula to show it correctly.
Regardless, @mtindor can you show me the box that appears in the LRRP.exe program. Do you have the correct UID there?

 

[Red_Ice]

The UID does not match the host of the Src IP address. As for the formulas, I seem to remember that I sent them to them privately, I don't remember now if it was to them or to those at DSD FL.

 

[mtindor]

BINGO! That would definitely be the right lat/long.

Now I just have to remember where i acquired that data -- from CC repeater, VC repeater, or mobile. Pretty sure it wasn't from a mobile input.

 

[Tidalwave]

I get the following from a CC repeater.

2023-12-11 8:54:30 BEE00.447-1.1 CONF DATA SAP=0 MFID=00 Blocks=5 LogicalLinkID=13020520 Aff'd TG=60308
2023-12-11 8:54:30 BEE00.447-1.1 0 029 51004500 0047483B 00008001 7251C0A8 Q.E..GH;....rQ..
2023-12-11 8:54:30 BEE00.447-1.1 1 10B 62A50AC8 52140303 7D4F0000 00004500 b...R...}O....E.
2023-12-11 8:54:30 BEE00.447-1.1 2 1EB 002B0F46 00003F11 EC520AC8 5214C0A8 .+.F..?..R..R...
2023-12-11 8:54:30 BEE00.447-1.1 3 1B4 62A50FA5 0FA50017 9D5A000D F0200831 b........Z... .1
2023-12-11 8:54:30 BEE00.447-1.1 4 1FD 33303230 35323000 00AAAAAA ACD8FD85 3020520......... IPv4; ICMP; Src=192.168.98.165 Tgt=10.200.82.20

But I have one less Block and it seems the missing block is the one that has LRRP info. Just thought it would be interesting to compare systems.

 

[noamlivne]

I get the following from a CC repeater.

2023-12-11 8:54:30 BEE00.447-1.1 CONF DATA SAP=0 MFID=00 Blocks=5 LogicalLinkID=13020520 Aff'd TG=60308
2023-12-11 8:54:30 BEE00.447-1.1 0 029 51004500 0047483B 00008001 7251C0A8 Q.E..GH;....rQ..
2023-12-11 8:54:30 BEE00.447-1.1 1 10B 62A50AC8 52140303 7D4F0000 00004500 b...R...}O....E.
2023-12-11 8:54:30 BEE00.447-1.1 2 1EB 002B0F46 00003F11 EC520AC8 5214C0A8 .+.F..?..R..R...
2023-12-11 8:54:30 BEE00.447-1.1 3 1B4 62A50FA5 0FA50017 9D5A000D F0200831 b........Z... .1
2023-12-11 8:54:30 BEE00.447-1.1 4 1FD 33303230 35323000 00AAAAAA ACD8FD85 3020520......... IPv4; ICMP; Src=192.168.98.165 Tgt=10.200.82.20

But I have one less Block and it seems the missing block is the one that has LRRP info. Just thought it would be interesting to compare systems.

I am afraid you will not get LRRP locations if you monitor the the output of the repeater.
You will have to find the input frequencies of the repeater and hope to catch some local strong signals. Because your site is at the 851 - 860 MHz range, your input frequencies will probably be 45 MHz lower.

 

[mtindor]

I am afraid you will not get LRRP locations if you monitor the the output of the repeater.
You will have to find the input frequencies of the repeater and hope to catch some local strong signals. Because your site is at the 851 - 860 MHz range, your input frequencies will probably be 45 MHz lower.

I don't know if he will find them on the CC, but perhaps on the VC. I'm pretty sure that what I collected was from voice channel traffic (the repeater output of voice comms).

 

[noamlivne]

I don't know if he will find them on the CC, but perhaps on the VC. I'm pretty sure that what I collected was from voice channel traffic (the repeater output of voice comms).

AFAIK, LRRP locations do not pass through the repeater, at least not in my system.
But if you catch them in the output (voice channels) then you are lucky and I wish our system would do the same.

 

[Tidalwave]

Correction. I have DSD+ set to follow DATA calls as priority. Trying to grab an input would be a very long wait i would think.

 

[noamlivne]

Correction. I have DSD+ set to follow DATA calls as priority. Trying to grab an input would be a very long wait i would think.

Yep. It is really hunt and peck after the active input frequency that sends the data. They can change overtime. It can be challenging.

Even with a .scanlist file of input frequencies and FMP24 I do not think that it will be useful because the FMP scanner will not stop/detect the active frequency for enough time, IMHO.

Maybe in the future something like SDRTrunk will be able to "sit" on the range of input frequencies and catch the P25 LRRP locations...

 

[mtindor]

Yep. It is really hunt and peck after the active input frequency that sends the data. They can change overtime. It can be challenging.

Even with a .scanlist file of input frequencies and FMP24 I do not think that it will be useful because the FMP scanner will not stop/detect the active frequency for enough time, IMHO.

Maybe in the future something like SDRTrunk will be able to "sit" on the range of input frequencies and catch the P25 LRRP locations...

Oh man, you mentioned SDRTRunk. You're going to cause me to go down that road I could potentially put in all the INPUT freqs for my local simulcast as just single channel P25 entries, and it would monitor them all at the same time. The CC almost never changes, so I could leave it out. Then I'd have to configure SDRTrunk to log all of that data. Maybe another day. But ya almost convinced me

 

[mtindor]

The speed and azimuth do not appear although the azimuth could be 188, but it is not correct information since the speed byte does not appear for its calculation, as for the latitude/longitude it corresponds to 40.43787633544716/-80.59405123828772 (3982FB41 C6B04CFB ).

View attachment 153819

@wildlynx Is there any chance you could pass along the formula / procedure used to translate ( 3982FB41 C6B04CFB ) into the lat/long coords that you gave? I'm sure somebody has that info posted somewhere here on the forums. But it'd be great if you could share that with me.

 

[Red_Ice]

@wildlynx Is there any chance you could pass along the formula / procedure used to translate ( 3982FB41 C6B04CFB ) into the lat/long coords that you gave? I'm sure somebody has that info posted somewhere here on the forums. But it'd be great if you could share that with me.

I got the base formulas from this same forum, although they were wrong and I have no problems sharing them with you. I just sent them to you.

 

[noamlivne]

@wildlynx Is there any chance you could pass along the formula / procedure used to translate ( 3982FB41 C6B04CFB ) into the lat/long coords that you gave? I'm sure somebody has that info posted somewhere here on the forums. But it'd be great if you could share that with me.

You can also look at my opening message of this thread and the included links.

 

[thewraith2008]

You may find this GitHub useful with regards to MOT LRRP and it's structure.
I believe this should apply to both P25 and DMR.

It should be noted the use of VLQ encoding with some of the fields used in LRRP and probably ARS, TMS, Telemetry DATA packets.
Not decoding this encoding is probably why you are seeing strange values or not been able to determining the next token position in the data stream.

The IPv4 headers (with TCP or UDP protocols) should not be over looked as a source of identifying DATA packet types.
While I can't speak much for P25, the DMR standards say some of these header fields (not used by DMR) are fixed, but I have seen this is not always the case.