DSDPlus Trying to analyze the Packet Data of P25 in version DSD+ 2.441 (LRRP/Location)
- Thread starter noamlivne
- Start date
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,896
- Reaction score
- 896
There are a few GitHub repos out there that can help with getting your head around some of these MOT services and putting the pieces together.
Sadly some programmers have a real problem adding meaningful comments to their code to help understand the structure of this type of data.
The other issue can be understanding some of the programming languages, especially when no comments exist or are vague.
For me, Java and Python make no sense to me.
Sadly some programmers have a real problem adding meaningful comments to their code to help understand the structure of this type of data.
The other issue can be understanding some of the programming languages, especially when no comments exist or are vague.
For me, Java and Python make no sense to me.
Although FL is written in C, I don't have too many problems understanding it, at least for the most part, since I program in C# and in many ways it is similar, until now my studies had been directed towards the result provided by the DSD and the ETSI , now I have started studying the TIA standards, I think I will have to visit GitHub more frequently so I can also cover that branch.
billy2047
📶 🕨 Ø T₁ ÆS Ⱬ ⬜ ᴴ L |→| 𝅘𝅥 💾 🛰️ 🔋
I've also logged a lot of data transmission on a conventional P25 repeater. Although I have no idea what it means other than RX OK and Aff'd TG.. Does anyone know how to decode the data? Thanks!
A few pages ago in this thread (DSDPlus - Trying to analyze the Packet Data of P25 in version DSD+ 2.441 (LRRP/Location)) it was written that SAP=1 is encrypted. So probably nothing can be done with that
adamfancher
Member
Hi all,
So I took a good look through this thread and it was a really good read.....That being said I'm still having a little trouble deciphering my data....
I've been capturing some data packets in my area and am trying to make heads or tails of them:
The first thing I'd like to be able to pick out is GPS coordinates, however from what I've gleaned not all packets have them.
My understanding from previous messages in the thread is that there are four bytes each for latitude and longitude which can be directly converted into a floating point calculation equal to the coordinates in degrees.
For my area, I'd be looking for a string of bytes starting with 0xC29 and another starting with 0x422, but am unable to locate these values in the packets I'm seeing.
I also took a look at the packets indicated in a previous post where certain bytes were highlighted in yellow and green denoting the bytes in a SAP=0 packet and those didn't yield real numbers.
If anyone can shed any light on GPS coordinates or any additional info on what data is shown it'd be much appreciated!
Thanks in advance.
So I took a good look through this thread and it was a really good read.....That being said I'm still having a little trouble deciphering my data....
I've been capturing some data packets in my area and am trying to make heads or tails of them:
The first thing I'd like to be able to pick out is GPS coordinates, however from what I've gleaned not all packets have them.
My understanding from previous messages in the thread is that there are four bytes each for latitude and longitude which can be directly converted into a floating point calculation equal to the coordinates in degrees.
For my area, I'd be looking for a string of bytes starting with 0xC29 and another starting with 0x422, but am unable to locate these values in the packets I'm seeing.
I also took a look at the packets indicated in a previous post where certain bytes were highlighted in yellow and green denoting the bytes in a SAP=0 packet and those didn't yield real numbers.
If anyone can shed any light on GPS coordinates or any additional info on what data is shown it'd be much appreciated!
Thanks in advance.
Not all systems are setup to transmit GPS locations via packet data.
It looks that you are monitoring the an output channel. If that is the case, you won't find LRRPs there. Monitor the input channel(s).
You are a little bit wrong with the packet. It's an ICMP reply (destination network unreachable) packet with an original IP packet, see below.In this other data packet, the ARS ports appear in the second IP addresses, although it is not indicated and they do have the same values for the SAP and the DPF but they do not transmit the three bytes of LRRP data indicators.
IP header
45 00 00 3c
58 46 00 00
40 - packet TTL
01 - protocol, ICMP
b3 4a - the header checksum
0c 00 27 11 - source
0c 00 30 24 - destination/target
ICMP header
03 - type, destination unreachable
00 - code, destination network unreachable
5d b7 - checksum
content
00 00 - unused
00 00 - next hop MTU?
IP header and first 8 bytes of original datagram's data
45 00 00 3c
00 4F 00 00
40 - TTL
11 - protocol, UDP
0a 42 - checksum
0c 00 30 24 - src
0d 00 27 11 - dst / tgt
UDP Header
0f a5 - src port, ARS
0f a5 - dst port, ARS
00 14 - data length
7f ea - UDP header checksum
53 7d 19 d9 - payload of UDP Packet
Maybe someone had answered before, but there are my 2 cents.In the third case we see the same SAP and DPF and ports 4001, with an LRRP indication, but it does not include that data, making it difficult to follow that theory.
It's LRRP Triggered Location Start Response.
0B - CMD
08 - data length
22 - identity token
04 - identity token length
00 00 26 86 - identity token payload
37 16 - looks like bearing
1. DMR T3 CAPMAX
2. On Data Revert / Enhanced Data Revert channel
3. Only one radio involved (Src=106) , which is a radio shop radio - basically sending GPS info
4. If the loads of school buses / multiple schools have GPS, it must be using some other method / application
I see mostly GPS, but apparently (according to DSDPlus FL) there is some Short Data stuff being sent. Not sure what it is all about.
Src=106 is the radio sending GPS
Src=16776906 is the Short Data stuff
Don't know that anyone will find it of interest. I'm not a coder or a radio tech or anything. I'm still trying to figure out a lot of what is contained within the 'Raw Data' lines, but certainly much of that has already been determined and posted by others previously in this thread.
What interests me is that after the 5 bytes for YR-MO-DAY-HR-MIN-SEC there is a single byte that is either/only a 51 or a 55. Then the 4 bytes for Latitude and 4 bytes for Longitude come after it. And then of course all the data after that is unknown to me. Wonder why that "separation byte", for lack of a better description, is sometimes 51 and other times 55 but seemingly never anything else.
If anyone cares to look at the 1R-log.txt, you can get it here
2. On Data Revert / Enhanced Data Revert channel
3. Only one radio involved (Src=106) , which is a radio shop radio - basically sending GPS info
4. If the loads of school buses / multiple schools have GPS, it must be using some other method / application
I see mostly GPS, but apparently (according to DSDPlus FL) there is some Short Data stuff being sent. Not sure what it is all about.
Src=106 is the radio sending GPS
Src=16776906 is the Short Data stuff
Don't know that anyone will find it of interest. I'm not a coder or a radio tech or anything. I'm still trying to figure out a lot of what is contained within the 'Raw Data' lines, but certainly much of that has already been determined and posted by others previously in this thread.
What interests me is that after the 5 bytes for YR-MO-DAY-HR-MIN-SEC there is a single byte that is either/only a 51 or a 55. Then the 4 bytes for Latitude and 4 bytes for Longitude come after it. And then of course all the data after that is unknown to me. Wonder why that "separation byte", for lack of a better description, is sometimes 51 and other times 55 but seemingly never anything else.
If anyone cares to look at the 1R-log.txt, you can get it here
lwvmobile
DSD-FME
LRRP Token.
Code:
2025.08.27 13:43:07 +DMR slot2 BS DATA DCC=0 Data Header DPF=[13:SD-Def] TG=16776944 Src=16776906 Conf=0 SAP=[10:Short Data] Blocks=2 Format=Unicode UTF-16BE PadBits=0
2025.08.27 13:43:07 SYS_Parms: SysCode=01.0000001.00001
2025.08.27 13:43:07 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:43:07 +DMR slot2 BS DATA DCC=0 Rate 1/2 Data 57 00 52 00 50 00 4A 00 34 00 37 00 W.R.P.J.4.7.
2025.08.27 13:43:07 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:43:07 +DMR slot2 BS DATA DCC=0 Rate 1/2 Data 34 00 00 00 00 00 00 00 4.......Looks like a callsign to me. W.R.P.J.4.7.4
lwvmobile
DSD-FME
LRRP Data with mismatched ports (4001 and 30000)
Code:
2025.08.27 13:27:17 +DMR slot2 BS DATA DCC=0 Data Header DPF=[2:UcData] Tgt=13 Src=106 Conf=0 SAP=[4:IP Data] Blocks=6 Pad=1 Last=0 Seq=0
2025.08.27 13:27:17 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:27:17 SYS_Parms: SysCode=01.0000001.00001
2025.08.27 13:27:17 +DMR slot2 BS DATA DCC=0 Rate 1/2 Data 45 00 00 43 9C 7E 00 00 40 11 C4 B5 E..C.~..@...
2025.08.27 13:27:17 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:27:17 +DMR slot2 BS DATA DCC=0 Rate 1/2 Data 0C 00 00 6A 0D 00 00 0D 0F A1 75 30 ...j......u0
2025.08.27 13:27:17 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:27:17 SYS_Parms: SysCode=01.0000001.00001
2025.08.27 13:27:17 +DMR slot2 BS DATA DCC=0 Rate 1/2 Data 00 2F E2 1A 0D 25 22 03 00 00 01 34 ./...%"....4
2025.08.27 13:27:17 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:27:17 +DMR slot2 BS DATA DCC=0 Rate 1/2 Data 1F A6 37 16 C0 55 39 6E 9B A9 C6 BA ..7..U9n....
2025.08.27 13:27:17 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:27:17 SYS_Parms: SysCode=01.0000001.00001
2025.08.27 13:27:17 +DMR slot2 BS DATA DCC=0 Rate 1/2 Data 84 45 42 57 82 07 2E 1D 1C 6C 00 3C .EBW.....l.<
2025.08.27 13:27:17 +DMR slot1 BS DATA DCC=0 Idle
2025.08.27 13:27:17
2025.08.27 13:27:17 Raw data: 45 00 00 43 9C 7E 00 00 40 11 C4 B5 0C 00 00 6A 0D 00 00 0D 0F A1 75 30 00 2F E2 1A 0D 25 22 03 00 00 01 34 1F A6 37 16 C0 55 39 6E 9B A9 C6 BA 84 45 42 57 82 07 2E 1D 1C 6C 00 3C 56 1D 70 00 00 65 42 00 08 B3 7D C5
Code:
PDU: 450000439C7E00004011C4B50C00006A0D00000D0FA17530002FE21A0D252203000001341FA63716C055396E9BA9C6BA8445425782072E1D1C6C003C561D70000065420008B37DC5
SRC(24): 00000106; IP: 012.000.000.106; Port: 4001;
DST(24): 00000013; IP: 013.000.000.013; Port: 30000;
UDP Protocol; Datagram Len: 47; UDP Checksum: E21A; LRRP;
Time: 2025.08.27 17:27:00
Lat: 40.38192 Lon: -80.53793 (40.38192, -80.53793)
Radius: 16983m
Speed: 0.2353 m/s 0.8471 km/h 0.5263 mph
Track: 58°Wow, you have it all figured out. Nice. Thank you for that. I had figured the data after the lat/long might be something useful -- more info about direction and things. But I really didn't have the abilities to pin it down.
It's a pain that it occurs on the Data Revert channel, but fortunately it looks like nothing else on the system uses GPS (or at least nothing that would be sent over a repeater output). If it's just the radio shop stuff using the Data Revert, then I don't feel compelled to monitor it anymore. An of course that lat/long is directly behind the radio shop, and you nailed the callsign. That's the company.
Thanks for sharing all of that info!
Mike
I know that I was "punished" for my own mistakes on this forum, I think excessively, but I believe I can contribute to the forum.
@mtindor indicates that Src=16776906 is the short data; in reality, it represents this data:
16776906 = FFFECA
In reality, it represents this data:
And regarding the log, it indicates that you don't know how to extract more than the length. I'll show you some of the data extracted from the two different packages I analyzed:
Yes, thank you. Very helpful [to me] to understand what all of that data was. I appreciate you taking the time to explain and give a graphical representation.
Sí, gracias. Me fue muy útil entender qué eran todos esos datos. Agradezco que te hayas tomado el tiempo de explicarlo y presentar una representación gráfica.
mike
Similar threads
SDS100/SDS200:
Uniden SDS100 GPS Guide (2025)
