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

[thewraith2008]

CAP+ documentation does describe the use of DATA only channels that can be used along side the voice channels.
This is probably done so it doesn't congest the voice traffic side with countless lrrp (or other) DATA traffic responses.
Not sure how the MS keeps track of a DATA rest CH if one is used or how it knows which DATA CH to use if more that one is available. (where it's lrrp response would appear)

If this works the way I think it would, then the frequency for LCN 1 voice and LCN 1 DATA would be different.

 

[dave3825]

Where do you find this ghost frequency that is not part of the system ?

That one was found when the system was discovered and being mapped out. I had all the freqs from the FCC license and one just always tx data and did not carry any voice.

 

[merlin]

I sort of understand all this, of two CAP+ sites, I question any users with GPS enabled. I get nothing with LRRP.
I also get nothing in the data window, which bodes 2 questions for another thread.
TNX

 

[merlin]

That one was found when the system was discovered and being mapped out. I had all the freqs from the FCC license and one just always tx data and did not carry any voice.

Seems the FCC database is down again, I will look into this later, TNX

 

[RaleighGuy]

No... You need to check out only your local P25 site, the strongest one.
Let's say it has 1 Control channel and 6 "Talk" channels (one or a few of them can be a Data channel). Find the input frequency of those Talk channels (that can be easily calculated on the fly).
Check with DSDPlus to see if you indeed catch fast but strong signals there.
Check the raw data logs and windows of DSDPlus to see if real LRRP data flows there and check the LRRP Map for coordinates and hopefully correct UnitIDs, direction and speed.

Yes I did that there are 37 inputs on our simulcast system, all towers use same frequencies, I ran them using the FMP24 Scanlist and though I get multiple hits there was zero LRRP data. Too bad it didn't work, but I just don't think they transmit location data over the channels.

 

[maus92]

Yes I did that there are 37 inputs on our simulcast system, all towers use same frequencies, I ran them using the FMP24 Scanlist and though I get multiple hits there was zero LRRP data. Too bad it didn't work, but I just don't think they transmit location data over the channels.

Yes, it is an system option. Also, you would need to be in range of the subscriber radio to monitor an input / talk-in frequency.

 

[cg]

Information in the P25data file should show DATA next to the data channels. May help you get your scanlist smaller. I have also used data from the files
You also can generate & use the Event Log file to see how many channels are used for data.

 

[RaleighGuy]

Information in the P25data file should show DATA next to the data channels. May help you get your scanlist smaller. I have also used data from the files
You also can generate & use the Event Log file to see how many channels are used for data.

In my case virtually all read data since MCTs are used on normal channels, but location not shared.

 

[noamlivne]

DSDPlus 2.457 is published but I still cannot see who is the P25 device that is located.
Instead there is the Src IP.

I wrote to the DSDPlus team via email now. I hope they will address my remarks.

The UID should be taken from the "LogicalLinkID=" value (and the TG, which would be great, can be gleaned sometimes from the "Aff'd TG=" value)

2023.12.28 10:31:00 Sync:+P25p1 NAC:37F PDU CONF DATA SAP=0 MFID=00 Blocks=4 LogicalLinkID=2500748
2023.12.28 10:31:00 0 0D4 51004500 00340F92 00004011 6E470A5C Q.E..4....@.nG.\
2023.12.28 10:31:00 1 04E E6D10A3F 01740FA1 0FDC0020 E6C70D16 ...?.t..... ....
2023.12.28 10:31:00 2 1C6 2203FFFF EE341F9D 08861A66 0066216D "....4.....f-f!m
2023.12.28 10:31:00 3 0B4 00BECA1F 6B000000 00000000 7C9912AD ....k.......|... LRRP; Tgt=10.63.1.116 Src=10.92.230.209 2023-04-04 08:24:26 123.92113 123.79803
(the coordinates were redacted)

 

[thewraith2008]

If the IPv4 header SRC/DEST addresses are seen as the 24 bit addresses, do the below values (after the binary bits) mean anything?

0x0A     0x5C     0xE6     0xD1     - 10.92.230.209
00001010 01011100 11100110 11010001 - 6088401 (only the lower 24 bits)

0x0A     0x3F     0x01     0x74     - 10.63.1.116
00001010 00111111 00000001 01110100 - 4129140 (only the lower 24 bits)

 

[Red_Ice]

Hello noamlivne.

I think it has a small misconception, if you look at the following image you can see that in the first case it presents a SAP (Service Access Point) equal to zero and then I indicate the positions of the Tgt in yellow and the Src in green. In the second example, the SAP is equal to 4 and the GPS position is represented in yellow for latitude and in green for longitude.



As you can see, there are different data packages that are identified by SAP.

I hope I have been able to help you with this problem, greetings.

 

[mtindor]

Hello noamlivne.

I think it has a small misconception, if you look at the following image you can see that in the first case it presents a SAP (Service Access Point) equal to zero and then I indicate the positions of the Tgt in yellow and the Src in green. In the second example, the SAP is equal to 4 and the GPS position is represented in yellow for latitude and in green for longitude.

View attachment 153743

As you can see, there are different data packages that are identified by SAP.

I hope I have been able to help you with this problem, greetings.

I only get SAP=0 and SAP=6 on the system I monitor. No SAP=4 (and thus no geodata). Do you happen to know what the actual data is supposed to be related to that is being sent in the SAP=0 and SAP=6 related frames? On the SAP=6 frames that I receive, the data is always exactly the same each time (no matter what talkgroup or radioID is referenced). For SAP=0, obviously the IP source/dest change but I guess the rest of the data in the lines is unknown to mostly everyone.

Mike

 

[noamlivne]

If the IPv4 header SRC/DEST addresses are seen as the 24 bit addresses, do the below values (after the binary bits) mean anything?

0x0A     0x5C     0xE6     0xD1     - 10.92.230.209
00001010 01011100 11100110 11010001 - 6088401 (only the lower 24 bits)

0x0A     0x3F     0x01     0x74     - 10.63.1.116
00001010 00111111 00000001 01110100 - 4129140 (only the lower 24 bits)

Unfortunately, no. These numbers do not make sense in my system.

All the values that the DSDPlus programmers need to enter into the LRRP boxes on the map are written in "plain" text in the example I gave, and that can be taken from the DSDPlus.packetData file (or can be calculated in the case of the coordiantes and speed/direction ). In the meantime, only the Coordinates, and the date&time are shown correctly.

• The Coordinates: written (fictionally, in my example) - the programmers are calculating them fine and showing them fine;
• UID: the "LogicalLinkID=" value which represents the UID of the device located: 2500748, in my example - the programmers should strive to enter that in the LRRP Map box. Currently they enter the "Src IP" value instead, by mistake - and that is not logical;
• TGID: nice to have, appears as the "Aff'd TG=" value: 1285, in my example (not shown), which hopefully they can find a way to show in the LRRP Map boxes;
• Direction/Speed I think they are miscalculating them, though I do not have too many examples, and I am not sure how to calculate them myself.

 

[noamlivne]

Hello noamlivne.

I think it has a small misconception, if you look at the following image you can see that in the first case it presents a SAP (Service Access Point) equal to zero and then I indicate the positions of the Tgt in yellow and the Src in green. In the second example, the SAP is equal to 4 and the GPS position is represented in yellow for latitude and in green for longitude.

View attachment 153743

As you can see, there are different data packages that are identified by SAP.

I hope I have been able to help you with this problem, greetings.

Hi @wildlynx ,
Thank you for your answer.

I think that all our system's Data is SAP=0. We rarely have SAP=6 and it seems not to contain interesting info.

Please read my opening message in this thread and my message from today.
Both of those messages contain examples that are with SAP=0 and contain valid LRRP coordinates. The programmers of DSDPlus are calculating the coordinates and showing them excellent inside the box of the LRRP.exe map program. I have no complaints about that.

My issue is that they are not showing the UID (the device) that is located inside the box of the LRRP.exe map program. They are showing the Src IP value as the the UID which is incorrect. They should show the "LogicalLinkID=" value as the UID.

Hopefully they can fix it in their next version(s).

I hope you can check your system to see if the boxes in the LRRP.exe map program contain the (correct) UIDs. So in your example it should be 2113039 (and not something like 10.53.1.1).

 

[Red_Ice]

I only get SAP=0 and SAP=6 on the system I monitor. No SAP=4 (and thus no geodata). Do you happen to know what the actual data is supposed to be related to that is being sent in the SAP=0 and SAP=6 related frames? On the SAP=6 frames that I receive, the data is always exactly the same each time (no matter what talkgroup or radioID is referenced). For SAP=0, obviously the IP source/dest change but I guess the rest of the data in the lines is unknown to mostly everyone.

Mike

I do not know the TIA standard of P25 as deeply as I know the ETSI standard of DMR, in DMR SAP 0 corresponds to UDT and SAP 6 is reserved.

I tell you about the DMR because a long time ago I was able to work with the Krypto1000 and when studying a P25 signal with it, it showed the data packets in a similar way to what the DMR does and in both systems the data that is sent is addressed by two elements ( SAP and DPF), except in the cases where they carry GPS data, which is also influenced by three bytes placed in a certain position, the first of which is always 0D. Depending on these three factors we can find GPS information in different places.

I imagine that the creators of the DSD-FME will take these types of things into account and are doing a magnificent job that, logically, they will iron out little by little.

 

[Red_Ice]

Hi @wildlynx ,
Thank you for your answer.

I think that all our system's Data is SAP=0. We rarely have SAP=6 and it seems not to contain interesting info.

Please read my opening message in this thread and my message from today.
Both of those messages contain examples that are with SAP=0 and contain valid LRRP coordinates. The programmers of DSDPlus are calculating the coordinates and showing them excellent inside the box of the LRRP.exe map program. I have no complaints about that.

My issue is that they are not showing the UID (the device) that is located inside the box of the LRRP.exe map program. They are showing the Src IP value as the the UID which is incorrect. They should show the "LogicalLinkID=" value as the UID.

Hopefully they can fix it in their next version(s).

I hope you can check your system to see if the boxes in the LRRP.exe map program contain the (correct) UIDs. So in your example it should be 2113039 (and not something like 10.53.1.1).

It's true, maybe I didn't read correctly what you wanted to express.

In the example that I have given, it represents a UID (LogicalLinkID) equal to 3315230 and it is effectively not the same as the IP address 10.53.1.1 (0A350101), since it would have to be 3473665 (350101) since it is supposed to be equivalent to the host of this type A IP address.

In any case, I also give a small explanation in my response to mtindor, perhaps I could be wrong in these statements because, as I say to mtindor, I do not know the TIA standard very well.

 

[noamlivne]

It's true, maybe I didn't read correctly what you wanted to express.

In the example that I have given, it represents a UID (LogicalLinkID) equal to 3315230 and it is effectively not the same as the IP address 10.53.1.1 (0A350101), since it would have to be 3473665 (350101) since it is supposed to be equivalent to the host of this type A IP address.

In any case, I also give a small explanation in my response to mtindor, perhaps I could be wrong in these statements because, as I say to mtindor, I do not know the TIA standard very well.

Did you try to check the LRRP.exe map program with your live data? Did you see the boxes with the locations?
Did you manage to see the UID values appearing in each box correctly, or instead did you see the Src IPs that is there by mistake?

Regardless, I wonder if your system transmits also Direction/Speed within the LRRP data, and if it is shown correctly in the LRRP boxes?
Perhaps you know how to calculate them from the Raw data? It would be great if you can share that info here.

 

[Red_Ice]

I only get SAP=0 and SAP=6 on the system I monitor. No SAP=4 (and thus no geodata). Do you happen to know what the actual data is supposed to be related to that is being sent in the SAP=0 and SAP=6 related frames? On the SAP=6 frames that I receive, the data is always exactly the same each time (no matter what talkgroup or radioID is referenced). For SAP=0, obviously the IP source/dest change but I guess the rest of the data in the lines is unknown to mostly everyone.

Mike

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

 

[Red_Ice]

Did you try to check the LRRP.exe map program with your live data? Did you see the boxes with the locations?
Did you manage to see the UID values appearing in each box correctly, or instead did you see the Src IPs that is there by mistake?

Regardless, I wonder if your system transmits also Direction/Speed within the LRRP data, and if it is shown correctly in the LRRP boxes?
Perhaps you know how to calculate them from the Raw data? It would be great if you can share that info here.

As I have told you, the UID values do not add up in relation to the IP addresses, as for the LRRP data, they are correct, taking into account that the signal is distant and some errors enter.

As for the speed and azimuth data, they are not reflected in the frames I receive, each of this data is preceded by what I call a token (1 byte):

34 - Byte that precedes the date-time group (5 bytes) of when the mobile station sends its GPS data.
67 - Byte that precedes the latitude (4 bytes) and longitude (4 bytes), this byte is not always the same and I do not know the reason why it changes.
6C - Byte preceding the speed (2 bytes), this byte does not appear in any of the frames.
56 - Byte preceding the azimuth (1 byte), this byte does not appear in any of the frames.

 

[noamlivne]

As I have told you, the UID values do not add up in relation to the IP addresses, as for the LRRP data, they are correct, taking into account that the signal is distant and some errors enter.

As for the speed and azimuth data, they are not reflected in the frames I receive, each of this data is preceded by what I call a token (1 byte):

34 - Byte that precedes the date-time group (5 bytes) of when the mobile station sends its GPS data.
67 - Byte that precedes the latitude (4 bytes) and longitude (4 bytes), this byte is not always the same and I do not know the reason why it changes.
6C - Byte preceding the speed (2 bytes), this byte does not appear in any of the frames.
56 - Byte preceding the azimuth (1 byte), this byte does not appear in any of the frames.

Thank you very much for sharing your info and knowledge.
In my system the preceding bytes are a bit different, but the principal is the same.
I hope this will help the programmers improve their output.