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

[mtindor]

As an extension to what I have told you before, I show you this table of the TIA-102.BAAC-A standard of the P25

View attachment 153812

Thanks. SAP=6 looks like nothing interesting then, and seems to always be paired up with a RESP line

2023-11-24 10:14:53 BEE00.348-3.1 RESP ACK; RX OK MFID=00 LogicalLinkID=4168650 Aff'd TG=26568

2023-11-24 10:14:53 BEE00.348-3.1 CONF DATA SAP=6 MFID=00 Blocks=1 LogicalLinkID=4168650 Aff'd TG=26568
2023-11-24 10:14:53 BEE00.348-3.1 0 049 3101AAAA AAAAAAAA AAAAAAAA 1B3A9B00 1............:..

No fun without SAP=4

 

[noamlivne]

Thanks. SAP=6 looks like nothing interesting then, and seems to always be paired up with a RESP line

2023-11-24 10:14:53 BEE00.348-3.1 RESP ACK; RX OK MFID=00 LogicalLinkID=4168650 Aff'd TG=26568

2023-11-24 10:14:53 BEE00.348-3.1 CONF DATA SAP=6 MFID=00 Blocks=1 LogicalLinkID=4168650 Aff'd TG=26568
2023-11-24 10:14:53 BEE00.348-3.1 0 049 3101AAAA AAAAAAAA AAAAAAAA 1B3A9B00 1............:..

No fun without SAP=4

Just to make sure...
Are you monitoring the output frequencies or the input frequencies?

 

[mtindor]

Just to make sure...
Are you monitoring the output frequencies or the input frequencies?

Output. Watching [weak] input frequencies rarely produces anything. It's a simulcast sites, and 99% of the time any radio is not near enough to my monitoring location for me to pick up its input. I will give it a try though. Not to mention, 'data' channels do not seem to be etched in stone and might be any of the frequencies on the system.

 

[noamlivne]

Output. Watching [weak] input frequencies rarely produces anything. It's a simulcast sites, and 99% of the time any radio is not near enough to my monitoring location for me to pick up its input. I will give it a try though. Not to mention, 'data' channels do not seem to be etched in stone and might be any of the frequencies on the system.

Oh... Outputs will not show you any valid LRRP data, AFAIK.
Hopefully you can find some closely located input frequencies of your P25 system, then you will have a chance to view the real LRRP data.

 

[mtindor]

Oh... Outputs will not show you any valid LRRP data, AFAIK.
Hopefully you can find some closely located input frequencies of your P25 system, then you will have a chance to view the real LRRP data.

I'm not counting on it. But I'm giving it a try. So far only SAP=0 stuff on the input.

What type of system are you monitoring? I'm currently monitoring a Harris Phase II P25 system, and the other system I will be checking out later is a Motorola P25 system (all Phase I talkgroups at this time).

 

[Red_Ice]

Thanks. SAP=6 looks like nothing interesting then, and seems to always be paired up with a RESP line

2023-11-24 10:14:53 BEE00.348-3.1 RESP ACK; RX OK MFID=00 LogicalLinkID=4168650 Aff'd TG=26568

2023-11-24 10:14:53 BEE00.348-3.1 CONF DATA SAP=6 MFID=00 Blocks=1 LogicalLinkID=4168650 Aff'd TG=26568
2023-11-24 10:14:53 BEE00.348-3.1 0 049 3101AAAA AAAAAAAA AAAAAAAA 1B3A9B00 1............:..

No fun without SAP=4

If you look at that first line, it tells you (RESP ACK; RX OK) that the ACK has been received, that is, the response to the ACK (RESP ACK) has been received correctly (RX OK).

 

[noamlivne]

I'm not counting on it. But I'm giving it a try. So far only SAP=0 stuff on the input.

What type of system are you monitoring? I'm currently monitoring a Harris Phase II P25 system, and the other system I will be checking out later is a Motorola P25 system (all Phase I talkgroups at this time).

SAP=0 is what I have here in my inputs and it contains a lot of valid LRRP data.
Monitoring a Motorola Phase II system here.

 

[mtindor]

And SAP=0 seems pretty unentertaining (although I think we don't know what all the data is other than the IPs).

2023-12-29 9:47:44 CONF DATA SAP=0 MFID=00 Blocks=4 LogicalLinkID=9800091
2023-12-29 9:47:44 0 1EF 51004500 00373CFB 00000F11 56440A27 Q.E..7<.....VD.'
2023-12-29 9:47:44 1 036 025C0A24 01D1C02E 42B50023 1A64A000 .\.$....B..#.d..
2023-12-29 9:47:45 2 18F 50046E4C 8E566017 CEA6FAC0 428CD16A P.nL.V`.....B..j
2023-12-29 9:47:45 3 17F 86223818 C4B8DCD6 40000000 93A7B7FA ."8.....@....... UDP; Src=10.39.2.92 Tgt=10.36.1.209 SrcPort=49198 TgtPort=17077

2023-12-29 9:51:57 CONF DATA SAP=0 MFID=00 Blocks=4 LogicalLinkID=9800091
2023-12-29 9:51:57 0 107 51004500 00373CFD 00000F11 56420A27 Q.E..7<.....VB.'
2023-12-29 9:51:57 1 0FB 025C0A24 01D1C02E 42B50023 D763A000 .\.$....B..#.c..
2023-12-29 9:51:57 2 17F 50046E4C 8E566017 CEA73DC0 428CD16A P.nL.V`...=.B..j
2023-12-29 9:51:57 3 1D4 86223818 C4B8DCD6 40000000 A2C73BA0 ."8.....@.....;. UDP; Src=10.39.2.92 Tgt=10.36.1.209 SrcPort=49198 TgtPort=17077

Those post from a radio about ever minute (every two minutes on this particular freq), the next minute on another freq.

 

[mtindor]

SAP=0 is what I have here in my inputs and it contains a lot of valid LRRP data.
Monitoring a Motorola Phase II system here.

Really? see my previous post. I just posted a SAP=0 -- from a Harris P25 system. See if you can recognize anything in that data that might indicate LRRP.

 

[Red_Ice]

No, there is no LRRP information there, there is only the IP information and its ports.

 

[mtindor]

No, there is no LRRP information there, there is only the IP information and its ports.

View attachment 153816

2023-12-29 9:51:57 CONF DATA SAP=0 MFID=00 Blocks=4 LogicalLinkID=9800091
2023-12-29 9:51:57 0 107 51004500 00373CFD 00000F11 56420A27 Q.E..7<.....VB.'
2023-12-29 9:51:57 1 0FB 025C0A24 01D1C02E 42B50023 D763A000 .\.$....B..#.c..
2023-12-29 9:51:57 2 17F 50046E4C 8E566017 CEA73DC0 428CD16A P.nL.V`...=.B..j
2023-12-29 9:51:57 3 1D4 86223818 C4B8DCD6 40000000 A2C73BA0 ."8.....@.....;. UDP; Src=10.39.2.92 Tgt=10.36.1.209 SrcPort=49198 TgtPort=17077

Yeah, but we really dont know what the rest is, right?

 

[noamlivne]

Really? see my previous post. I just posted a SAP=0 -- from a Harris P25 system. See if you can recognize anything in that data that might indicate LRRP.

Does not seem too informative for me, and DSDPlus writes that it is UDP. It should write LRRP.

To detect LRRP I try to find the string "1FA0" or "1F A0" which is 4001 - the indication of LRRP. But I saw others that are LRRP without it in my system, such as with 0FDC or 0F DC which is 4060.

The next thing I would look for are the indicative bytes that I mentioned in my opening message in this thread and that @wildlynx also mentioned a few messages above about his system (which is perhaps also Motorola), that tell us where the Date, Time, Coordinates, Direction and Speed raw values are written.

 

[mtindor]

Does not seem too informative for me, and DSDPlus writes that it is UDP. It should write LRRP.

To detect LRRP I try to find the string "1FA0" or "1F A0" which is 4001 - the indication of LRRP. But I saw others that are LRRP without it in my system, such as with 0FDC or 0F DC which is 4060.

The next thing I would look for are the indicative bytes that I mentioned in my opening message in this thread and that @wildlynx also mentioned a few messages above about his system (which is perhaps also Motorola), that tell us where the Date, Time, Coordinates, Direction and Speed raw values are written.

Ok. I'll begin after collecting some data from an actual Motorola P25 system instead of this Harris job.

Actually, to be honest, I likely won't pursue it further. If it can't be gleaned from the CC or VC repeater output, it's useless to most people. Not many want to sit around and attempt to grab lat/long info from weak mobile comms

Thanks

 

[Red_Ice]

Does not seem too informative for me, and DSDPlus writes that it is UDP. It should write LRRP.

To detect LRRP I try to find the string "1FA0" or "1F A0" which is 4001 - the indication of LRRP. But I saw others that are LRRP without it in my system, such as with 0FDC or 0F DC which is 4060.

The next thing I would look for are the indicative bytes that I mentioned in my opening message in this thread and that @wildlynx also mentioned a few messages above about his system (which is perhaps also Motorola), that tell us where the Date, Time, Coordinates, Direction and Speed raw values are written.

The first problem is in what you just said and that it is not being taken into account in the thread, I don't know if you have noticed the MFID, it always appears as 00, but look at this list which is in decimal numbers:

16 - Relm / BK Radio
32 – Cycomm
40 - Efratom Time and Frequency Products, Inc
48 - Com-Net Ericsson
56 – Datron
64 – Icom
72 – Garmin
80 – GTE
85 - IFR Systems
96 - GEC-Marconi
104 - Kenwood Communications
112 - Glenayre Electronics
116 - Japan Radio Co.
120 – Kokusai
124 – Cycomm
128 – Midland
134 - Daniels Electronics Ltd.
144 – Motorola
160 – Thales
164 - M/A-COM
176 – Raytheon
192 – SEA
200 – Securicor
208 – ADI
216 - Tait Electronics
224 – Teletec
240 - Transcrypt International

Como se puede ver, Motorola es el 144 o 0x90 y no el 0x00

 

[slicerwizard]

If you look at that first line, it tells you (RESP ACK; RX OK) that the ACK has been received, that is, the response to the ACK (RESP ACK) has been received correctly (RX OK).

I don't think so. An ACK means message received ok (ACK; RX OK). You don't ACK an ACK.

Confirmed data message senders need to know that the recipient got the message. The ACK does that. The sender doesn't ACK the ACK. Once the ACK is seen, the sender has no more interest in the transaction and gets the hell out of Dodge. The recipient doesn't need to see his ACK ACKed - he got his message nice and clean and he too now has no further interest in any more dialogue. If the sender didn't see the ACK, the sender will resend the message. Done and done. All bases covered.

 

[Red_Ice]

I think you are looking for a wrong concept since the data you are looking for is the ports of the IP addresses. In the example that I gave in my first contribution, I put only the LRRP data, but in that packet there was also IP data.


I think it is better to look for bytes 34 1F, I explain why, 34 is the byte that precedes the date and 1F is the byte with which not only the current year begins, but several more, taking into account that what date is 5 bytes and then comes the byte of the LRRP data (blue shading of the date), it is easier to find this data.

 

[Red_Ice]

I don't think so. An ACK means message received ok (ACK; RX OK). You don't ACK an ACK.

Confirmed data message senders need to know that the recipient got the message. The ACK does that. The sender doesn't ACK the ACK. Once the ACK is seen, the sender has no more interest in the transaction and gets the hell out of Dodge. The recipient doesn't need to see his ACK ACKed - he got his message nice and clean and he too now has no further interest in any more dialogue. If the sender didn't see the ACK, the sender will resend the message. Done and done. All bases covered.

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.

 

[noamlivne]

I think you are looking for a wrong concept since the data you are looking for is the ports of the IP addresses. In the example that I gave in my first contribution, I put only the LRRP data, but in that packet there was also IP data.

View attachment 153818
I think it is better to look for bytes 34 1F, I explain why, 34 is the byte that precedes the date and 1F is the byte with which not only the current year begins, but several more, taking into account that what date is 5 bytes and then comes the byte of the LRRP data (blue shading of the date), it is easier to find this data.

I agree.
I hope that "34 (1F)" is indeed the global Date indication for all the systems and not just for the two Motorola systems, in our examples.

 

[Red_Ice]

It must be taken into account that, at least in DMR, not all models in which LRRP data are obtained include date data, so it is possible that the same thing happens in P25.

 

[Red_Ice]

@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.