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

[noamlivne]

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:


This is my P25 data, for example, and obfuscated a bit for privacy reasons:

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

66 is the indication of the Location.
You take the first value, convert it from Hex to Dec, multiply it by 180 and divide it by 4294967295, and you get the Lat (at least in my part of the world).
You take the second value, convert it from Hex to Dec, multiply it by 360 and divide it by 4294967295, and you get the Lon (at least in my part of the world).

6B is maybe the indication of the Speed.
I am not sure how this is calculated exactly. (Maybe simply convert Hex to Dec and you get the speed).

56 is maybe the indication of the Direction.
I am not sure how this is calculated exactly. (Maybe simply convert the Hex to Dec and divide by 2 and you get the direction).

 

[cg]

Are you seeing this on the input to the Control channel or the inputs to the voice channels?

 

[noamlivne]

Are you seeing this on the input to the Control channel or the inputs to the voice channels?

On the input of the "voice" channels, but maybe that is how my system works.
You can monitor the CC output frequency and note to yourself at which channel most of the fast Data instances appear.
Then go to the input of that channel (for example 45 MHz below) and check if indeed you get the bursts there.
I would recommend starting with the strongest site around you.

 

[Red_Ice]

Hello noamlivne, you are on the right track but the formulas you propose can lead to errors depending on the part of the planet you are in, you must keep in mind that the latitude (north/south) is measured in +-90, so It must be taken into account that if when generating the formula it presents us with a result greater than 90 we will have to subtract 180 and it will give us that latitude in negative or south, the same happens with the longitude, but in this case 360 is subtracted in the case that the formula gives us a result greater than 180 and a negative or west latitude would appear.

What you show as azimuth could be, but in terms of speed we would be missing a byte.

I hope that this contribution clarifies this series of data a little more, particularly for me, I am getting some disjointed and unreliable results.

 

[noamlivne]

Hello noamlivne, you are on the right track but the formulas you propose can lead to errors depending on the part of the planet you are in, you must keep in mind that the latitude (north/south) is measured in +-90, so It must be taken into account that if when generating the formula it presents us with a result greater than 90 we will have to subtract 180 and it will give us that latitude in negative or south, the same happens with the longitude, but in this case 360 is subtracted in the case that the formula gives us a result greater than 180 and a negative or west latitude would appear.

What you show as azimuth could be, but in terms of speed we would be missing a byte.

I hope that this contribution clarifies this series of data a little more, particularly for me, I am getting some disjointed and unreliable results.

Yep, indeed I am only talking from the experience of my local system, in my local geographical area.
If you need help and do not mind sharing your data, you can send me a private message or post it here. Perhaps I will have some input, especially with regards to the old Thread and Pics I mentioned above.

 

[noamlivne]

DSDPlus Team are following up on my request.

My coordinates are fine, but the DeviceID, Speed, and Direction are incorrect.
I emailed them again. Hopefully they will find the issues.

Anyway, if someone wants to try: find inputs of your P25 system (45 MHz up or down, for example) and check to see if you see LRRP data shown in the raw data windows/file and on the LRRP map.

 

[maus92]

Location data is typically transmitted on the talk-in frequency being used by the subscriber unit for use in the dispatch function. Aggregated location data *might* be transmitted over a data connection for use in mapping programs that field supervisors may use, but this is not common - yet. Perhaps an APX Next or Wave type app may leverage location data in the future using LTE / 5g / wifi data.

 

[noamlivne]

In my system I only get individual (quite rare) locations from subscribers. Unfortunately I do not get aggregated locations.

 

[dave3825]

I have a Cap+ system that announces Lrrp over the rest channel.





But a separate freq that's not part of the trunked system carries the actual gps data.

 

[mtindor]

I have a Cap+ system that announces Lrrp over the rest channel.

View attachment 152662



But a separate freq that's not part of the trunked system carries the actual gps data.

View attachment 152664

That's an interesting finding. I've run across many sites over the years with just LRRP Control messages. I assumed that there simply was no LRRP data to be gathered. Now I'll have to make note of those sites when I run across them again and look for another channel that might be passing the actual info I like to see. Thanks for sharing!

m

 

[noamlivne]

Try to do the same with a P25 system. That is a new feature for DSDPlus.
In the P25 system, the LRRP will hopefully be transmitted in the Input frequencies of the system.
You should get at least the coordinates if all works well, but the UID, direction and speed are incorrect in my case, and hopefully the DSDPlus team will take care of it.

 

[mtindor]

Try to do the same with a P25 system. That is a new feature for DSDPlus.
In the P25 system, the LRRP will hopefully be transmitted in the Input frequencies of the system.
You should get at least the coordinates if all works well, but the UID, direction and speed are incorrect in my case, and hopefully the DSDPlus team will take care of it.

I'm gonna try that the best I can. For the P25 systems that I can monitor, the mobiles are rarely close enough for me to pick up. But worth a try.

M

 

[maus92]

In my system I only get individual (quite rare) locations from subscribers. Unfortunately I do not get aggregated locations.

You most likely would not - that would probably happen over a LTE data connection and displayed on a MDT, or maybe a command post during a large incident. Also, we're talking about P25 in this case. DMR is different as it is not public safety grade, aka less "secure."

 

[maus92]

Try to do the same with a P25 system. That is a new feature for DSDPlus.
In the P25 system, the LRRP will hopefully be transmitted in the Input frequencies of the system.
You should get at least the coordinates if all works well, but the UID, direction and speed are incorrect in my case, and hopefully the DSDPlus team will take care of it.

Is the speed in different units than you expect? Or is it wildly off?

 

[RaleighGuy]

That's an interesting finding. I've run across many sites over the years with just LRRP Control messages. I assumed that there simply was no LRRP data to be gathered. Now I'll have to make note of those sites when I run across them again and look for another channel that might be passing the actual info I like to see. Thanks for sharing!

m

Unfortunately, my area is not broadcasting GPS, one system does as you said, have a separate frequency, but it only shows the MCT messages (like your top photo) but not GPS data. The other system uses a single voice channel for the data calls, which changes every few minutes, but again only the MCT.

You'd think it would show bus, fire or EMS GPS data as they track it on a larger map, but I'm not seeing it.

 

[RaleighGuy]

Try to do the same with a P25 system. That is a new feature for DSDPlus.
In the P25 system, the LRRP will hopefully be transmitted in the Input frequencies of the system.
You should get at least the coordinates if all works well, but the UID, direction and speed are incorrect in my case, and hopefully the DSDPlus team will take care of it.

In a large city there is little to no input that can easily be monitored when there are over 100 input frequencies.

 

[noamlivne]

Is the speed in different units than you expect? Or is it wildly off?

Wildly off.

 

[noamlivne]

In a large city there is little to no input that can easily be monitored when there are over 100 input frequencies.

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.

 

[tuky]

Hello, can You help me:
1) I cannot write to dsdplusfastlane@gmail.com because in the last version (2.444) I have many errors (in red character) but the system works well.
2)In LRRP the small balls are yellow and green: why this difference?
ThankYou

 

[merlin]

I have a Cap+ system that announces Lrrp over the rest channel.

View attachment 152662



But a separate freq that's not part of the trunked system carries the actual gps data.

View attachment 152664

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