(Apologies in advance for a very long message)
Hi,
The Uniden HomePatrol, when used in Activity Log mode, stores all the raw data it receives along with the translated output (somewhat - see more on this below). I've found that (at least on P25 systems), it does not translate all of the data it receives, and for what reason I don't know - hopefully a future firmware release will remedy that. I have been mildly successful in figuring out the decode of some of these strings "by hand", but need a bit of advice and/or help in getting further on with them.
I've tried looking for a document somewhere that has the actual P25 standard spelled out, as in, "for this codeword, start with 6 bytes of such-and-such, then 2 bytes for the sysid, then 2 bytes RFSS" etc but haven't found anything. Surely it must exist. Is it something I have to purchase from somewhere?
Anyway, the primary one I'm trying to tackle is Adjacent Status Broadcast (what the HP logs call it - my PRO96COM logs call it "Neighbor Status Broadcast"; I'm sure you know what I mean). I did a lot of tracking over the summer on various P25 systems and logged tons with my HP, but since it doesn't decode these codewords (symbols? what's the correct term?), I feel I have a large amount of data that I don't have and should be able to get somewhat easily.
I wasn't using PRO96COM until very recently, and can't go back to these other systems for at least another 9 months (halfway across the country as they are). I did manage to run both PRO96COM and the HP on another local P25 system, and here are some samples of their neighbor/adjacent sites.
HP1:
PRO96COM:
The above aren't from the same date and time. However, it was somewhat easy to figure out the relevant parts of the hex string by simple comparison on the PRO96COM version - bytes 8, 9, and 10 are the sysid; bytes 11 and 12 the RFSS, and 13 and 14 the site; 15-18 the LCN (with some mathematics to be done to make it fit the bandplan/LCN format). Using that, I was able to figure out that the ones on my HP log above are sites 01-74 and 01-71, with control channels on LCNs 02-0252 and 02-0078 (8444 and 8270 un-div'd/mod'd dec), all respectively. The last three byte pairs, I presume, relate to what the PRO96COM lines are telling me about the neighbor's status and capacity.
Where I have hit a hurdle is with some of my HP logs from one of the faraway systems I can't go back to with PRO96COM easily (Newfoundland Provincial Radio P25 for what it's worth). Its adjacent status broadcast appears to be in a totally different format from the above:
HP:
I included the previous couple of lines because I am suspecting that the line starting with "3C," is the actual beginning of the adjacent status broadcast and that "00," is a continuation of the data, since it doesn't have a time listed beside it.
The sysid for this system is 00C, which makes me think the 14th-16th bytes in the "3C" line is the sysid (and thus where I should start, to get the RFSS and site ID/etc) - but if that's the case, the RFSS and site ID make no sense (implying that RFSS 129, site 60, is a neighbor to RFSS 33, site 01 (this site) - when I have not found anything but ##-01 sites in this system anywhere in the province).
I need help understanding how to pick out RFSS, site, and LCN from that last code snippet. If this helps, here's the RFSS Status Broadcast from that same site, from the HP:
HP:
I was able to figure out from this one that the "00," line contains the RFSS (hex 21), site (hex 01), Tx LCN (03C8), and Rx LCN (0356) in the first 10 bytes. "00C" is much further ahead on that one, midway thru the "3A," line.
For what it's worth, I did run Unitrunker on the Newfoundland system, and never saw any neighboring sites announced. I'm wondering if this is an adjacent status message that doesn't follow "normal" protocols?
I'd love to see what PRO96COM would do on this system, but I don't go back there till September again, and I'm not sure if anyone in range of the system has the necessary hardware to run the software.
Any help would be appreciated on the above. While I'm at it, I should also mention the wacky way the HP lists bandplans/tables. I've mentioned this in other threads, but if one or more of you kind souls might tutor me on P25 decoding, maybe you can help me with this part too
From the above Newfoundland P25 system, which has a known bandplan of base 150.8 MHz, 5kHz steps:
HP:
For what it's worth, 30.16 is exactly 1/5 of 150.8. "Tofs" (transmit offset) doesn't work as 128 "channels", as we've seen above that Tx LCN for the above site is 968, Rx LCN 854 - an offset of only 114 channels. In another thread somewhere, I actually get coherent on a coordination between Tofs and the actual transmit offset, based on the near-to-me ATCO system:
HP:
PRO96COM:
The values for the ATCO system, in the HP data, are 8192+(number of channels the TX offset actually is). Proof - 3.99/0.0025 = 1596; 1596+8192 = 9788. Again in the ATCO data, the base freq (which PRO96COM reports correctly as 138.0) is listed as 27.6 - one-fifth of the real base.
I also figured this out for a UHF system previously, that the HP is reporting double the proper Bfrq for a 400 MHz system. Thread: http://forums.radioreference.com/uniden-scanners/221734-hp1-acitvity-log-help-understanding.html - my question to you here is, does the actual hex string give the value in something other than the actual frequency, or is the HP software using bad math, or what?
The ultimate goal here is I would like to be able to take these hex strings and understand the data in them, especially for the ones above that aren't getting decoded in my HP logs. Again, any help you can offer will be greatly appreciated (even if it's a "here, look at this PDF with the protocols in it")!
Hi,
The Uniden HomePatrol, when used in Activity Log mode, stores all the raw data it receives along with the translated output (somewhat - see more on this below). I've found that (at least on P25 systems), it does not translate all of the data it receives, and for what reason I don't know - hopefully a future firmware release will remedy that. I have been mildly successful in figuring out the decode of some of these strings "by hand", but need a bit of advice and/or help in getting further on with them.
I've tried looking for a document somewhere that has the actual P25 standard spelled out, as in, "for this codeword, start with 6 bytes of such-and-such, then 2 bytes for the sysid, then 2 bytes RFSS" etc but haven't found anything. Surely it must exist. Is it something I have to purchase from somewhere?
Anyway, the primary one I'm trying to tackle is Adjacent Status Broadcast (what the HP logs call it - my PRO96COM logs call it "Neighbor Status Broadcast"; I'm sure you know what I mean). I did a lot of tracking over the summer on various P25 systems and logged tons with my HP, but since it doesn't decode these codewords (symbols? what's the correct term?), I feel I have a large amount of data that I don't have and should be able to get somewhat easily.
I wasn't using PRO96COM until very recently, and can't go back to these other systems for at least another 9 months (halfway across the country as they are). I did manage to run both PRO96COM and the HP on another local P25 system, and here are some samples of their neighbor/adjacent sites.
HP1:
Code:
11/29/2011 06:28:20 "3C,BC00003E94014A20FC60E284" Adjacent Status Broadcast
11/29/2011 06:28:20 "3C,BC00003E940147204E60A36D" Adjacent Status BroadcastPRO96COM:
Code:
BC 00 00 3E 94 01 41 01 38 60 97 FD 12/01 13:17:55 Neighbor Status Broadcast - SysID: e94 Zone: 1 Site: 65 Control: 0-0312(138.78000) Status: Connected Cap: Voice,Registration
BC 00 00 3E 94 01 46 01 38 60 C6 D0 12/01 13:17:55 Neighbor Status Broadcast - SysID: e94 Zone: 1 Site: 70 Control: 0-0312(138.78000) Status: Connected Cap: Voice,Registration
BC 00 00 3E 94 01 47 20 4E 60 A3 6D 12/01 13:17:55 Neighbor Status Broadcast - SysID: e94 Zone: 1 Site: 71 Control: 2-0078(138.19500) Status: Connected Cap: Voice,RegistrationThe above aren't from the same date and time. However, it was somewhat easy to figure out the relevant parts of the hex string by simple comparison on the PRO96COM version - bytes 8, 9, and 10 are the sysid; bytes 11 and 12 the RFSS, and 13 and 14 the site; 15-18 the LCN (with some mathematics to be done to make it fit the bandplan/LCN format). Using that, I was able to figure out that the ones on my HP log above are sites 01-74 and 01-71, with control channels on LCNs 02-0252 and 02-0078 (8444 and 8270 un-div'd/mod'd dec), all respectively. The last three byte pairs, I presume, relate to what the PRO96COM lines are telling me about the neighbor's status and capacity.
Where I have hit a hurdle is with some of my HP logs from one of the faraway systems I can't go back to with PRO96COM easily (Newfoundland Provincial Radio P25 for what it's worth). Its adjacent status broadcast appears to be in a totally different format from the above:
HP:
Code:
09/13/2011 18:25:09 "38,B800FF2C6C002C6C00018665" System Service Broadcast
09/13/2011 18:25:09 "3C,37FD0023300C813C23014ECB"
"00,03EC03447100000033014FF2 Adjacent Status BroadcastI included the previous couple of lines because I am suspecting that the line starting with "3C," is the actual beginning of the adjacent status broadcast and that "00," is a continuation of the data, since it doesn't have a time listed beside it.
The sysid for this system is 00C, which makes me think the 14th-16th bytes in the "3C" line is the sysid (and thus where I should start, to get the RFSS and site ID/etc) - but if that's the case, the RFSS and site ID make no sense (implying that RFSS 129, site 60, is a neighbor to RFSS 33, site 01 (this site) - when I have not found anything but ##-01 sites in this system anywhere in the province).
I need help understanding how to pick out RFSS, site, and LCN from that last code snippet. If this helps, here's the RFSS Status Broadcast from that same site, from the HP:
HP:
Code:
09/13/2011 18:25:09 "3A,37FD0021100C813A0000EA14"
"00,210103C8035671007F1EBC00 RFSS Status Broadcast Extened Sid:00Ch Sub:33 Site:1 LcnT:968 LcnR:854I was able to figure out from this one that the "00," line contains the RFSS (hex 21), site (hex 01), Tx LCN (03C8), and Rx LCN (0356) in the first 10 bytes. "00C" is much further ahead on that one, midway thru the "3A," line.
For what it's worth, I did run Unitrunker on the Newfoundland system, and never saw any neighboring sites announced. I'm wondering if this is an adjacent status message that doesn't follow "normal" protocols?
I'd love to see what PRO96COM would do on this system, but I don't go back there till September again, and I'm not sure if anyone in range of the system has the necessary hardware to run the software.
Any help would be appreciated on the above. While I'm at it, I should also mention the wacky way the HP lists bandplans/tables. I've mentioned this in other threads, but if one or more of you kind souls might tutor me on P25 decoding, maybe you can help me with this part too
From the above Newfoundland P25 system, which has a known bandplan of base 150.8 MHz, 5kHz steps:
HP:
Code:
09/13/2011 18:25:10 "34,B4000502002801CC3480445A" Identifier Update for VHF/UHF Bands Iden:0 Bw:5 Tofs:128 Csp:40 Bfrq:30160000For what it's worth, 30.16 is exactly 1/5 of 150.8. "Tofs" (transmit offset) doesn't work as 128 "channels", as we've seen above that Tx LCN for the above site is 968, Rx LCN 854 - an offset of only 114 channels. In another thread somewhere, I actually get coherent on a coordination between Tofs and the actual transmit offset, based on the near-to-me ATCO system:
HP:
Code:
11/29/2011 06:28:21 "34,B4002598F01401A52480400E" Identifier Update for VHF/UHF Bands Iden:2 Bw:5 Tofs:9788 Csp:20 Bfrq:27600000
11/29/2011 06:28:21 "34,B400158F901401A5248077F5" Identifier Update for VHF/UHF Bands Iden:1 Bw:5 Tofs:9188 Csp:20 Bfrq:27600000
11/29/2011 06:28:22 "34,B400058F781401A52480CC3B" Identifier Update for VHF/UHF Bands Iden:0 Bw:5 Tofs:9182 Csp:20 Bfrq:27600000PRO96COM:
Code:
B4 00 25 98 F0 14 01 A5 24 80 40 0E 12/01 13:17:57 Identifier Update - ID: 02 Base: 138.00000 Spacing: 0.00250 Bandwidth: 0.01250 TX Offset: 3.99000
B4 00 05 8F 78 14 01 A5 24 80 CC 3B 12/01 13:17:57 Identifier Update - ID: 00 Base: 138.00000 Spacing: 0.00250 Bandwidth: 0.01250 TX Offset: 2.47500
B4 00 15 8F 90 14 01 A5 24 80 77 F5 12/01 13:17:57 Identifier Update - ID: 01 Base: 138.00000 Spacing: 0.00250 Bandwidth: 0.01250 TX Offset: 2.49000The values for the ATCO system, in the HP data, are 8192+(number of channels the TX offset actually is). Proof - 3.99/0.0025 = 1596; 1596+8192 = 9788. Again in the ATCO data, the base freq (which PRO96COM reports correctly as 138.0) is listed as 27.6 - one-fifth of the real base.
I also figured this out for a UHF system previously, that the HP is reporting double the proper Bfrq for a 400 MHz system. Thread: http://forums.radioreference.com/uniden-scanners/221734-hp1-acitvity-log-help-understanding.html - my question to you here is, does the actual hex string give the value in something other than the actual frequency, or is the HP software using bad math, or what?
The ultimate goal here is I would like to be able to take these hex strings and understand the data in them, especially for the ones above that aren't getting decoded in my HP logs. Again, any help you can offer will be greatly appreciated (even if it's a "here, look at this PDF with the protocols in it")!
