Neighbor Lists

[mwjones]

I've been gathering a lot of data recently using DSDPlus, and have been submitting updates based on that data. I recently submitted a list of updates to 27 sites on a statewide system, and as I'm watching the admin work their way through the list, I've started noticing some variances in how that data is presented. So what is the preferred format that the admins prefer?

I've seen on various P25 systems (where "1" is the RFSS, followed with a 2-digit site number):

• "102-Site Name 1, 103-Site Name 2,..."
• "1-02 (Site Name 1), 1-03 (Site Name 2),..."
• "102, 103,..."
• "1-02, 1-03,..."

In my latest update, I submitted the entries with the second format "1-02 (Site Name)" particularly in light of this being a 100+ site statewide system, and am now seeing that the admin is copy/pasting those in, and clearly maxing out the neighbor list field, as the entries are either being chopped off or they're having to go back and abbreviate (which is plentiful in sites that have 11 or more neighbors).

Please advise, and I'll update my submission templates (that I use for formatting and submitting the data to RRDB which I then cut and paste into the submission form) accordingly.

 

[dlwtrunked]

I've been gathering a lot of data recently using DSDPlus, and have been submitting updates based on that data. I recently submitted a list of updates to 27 sites on a statewide system, and as I'm watching the admin work their way through the list, I've started noticing some variances in how that data is presented. So what is the preferred format that the admins prefer?

I've seen on various P25 systems (where "1" is the RFSS, followed with a 2-digit site number):

• "102-Site Name 1, 103-Site Name 2,..."
• "1-02 (Site Name 1), 1-03 (Site Name 2),..."
• "102, 103,..."
• "1-02, 1-03,..."

In my latest update, I submitted the entries with the second format "1-02 (Site Name)" particularly in light of this being a 100+ site statewide system, and am now seeing that the admin is copy/pasting those in, and clearly maxing out the neighbor list field, as the entries are either being chopped off or they're having to go back and abbreviate (which is plentiful in sites that have 11 or more neighbors).

Please advise, and I'll update my submission templates (that I use for formatting and submitting the data to RRDB which I then cut and paste into the submission form) accordingly.

Add to that, I have seen professionals do them as 1.2, 1.3 after the WACN.Sys_ID. which is (IMHO) much cleaner. But I do not see that as changing as people will use whatever the scanner manufacturer displays.

 

[mwjones]

Add to that, I have seen professionals do them as 1.2, 1.3 after the WACN.Sys_ID. which is (IMHO) much cleaner. But I do not see that as changing as people will use whatever the scanner manufacturer displays.

Valid point. On another Statewide system with DSDPlus I saw two sites that listed a site on a metro-area system as their neighbor (Different WACN.SysID), and the metro-area system site listed them as reciprocal neighbor, but the neighbor list in RRDB doesn't reflect it on either system.

That's why I wanted to start this discussion. While other trunked system types may have neighbor lists, their site structure is much simpler although it still applies what is the proper format (I see a lot of NXDN and Connect Plus systems showing simple comma delimited lists of site numbers, like the third example I used).

 

[wa8pyr]

I've been gathering a lot of data recently using DSDPlus, and have been submitting updates based on that data. I recently submitted a list of updates to 27 sites on a statewide system, and as I'm watching the admin work their way through the list, I've started noticing some variances in how that data is presented. So what is the preferred format that the admins prefer?

I've seen on various P25 systems (where "1" is the RFSS, followed with a 2-digit site number):

• "102-Site Name 1, 103-Site Name 2,..."
• "1-02 (Site Name 1), 1-03 (Site Name 2),..."
• "102, 103,..."
• "1-02, 1-03,..."

In my latest update, I submitted the entries with the second format "1-02 (Site Name)" particularly in light of this being a 100+ site statewide system, and am now seeing that the admin is copy/pasting those in, and clearly maxing out the neighbor list field, as the entries are either being chopped off or they're having to go back and abbreviate (which is plentiful in sites that have 11 or more neighbors).

Please advise, and I'll update my submission templates (that I use for formatting and submitting the data to RRDB which I then cut and paste into the submission form) accordingly.

Neat, clean and minimal is preferred.

For the neighbor list on a site within a networked trunking system, names aren't really necessary; just the RFSS and site numbers (ie 102, 103, 105, 109, 212, 326, etc).

 

[GTR8000]

For P25 systems, I prefer x.y where x = RFSS and y = Site ID. If a P25 system only has a single RFSS/Zone, then the Site ID alone is enough.

Using the decimal between RFSS and Site ID makes the distinction very clear, whereas using 103, 104, etc. can be unclear on larger systems that have RFSS 1, Site 3 and RFSS 1, Site 103

1.3 and 1.103 are unmistakable.

 

[mwjones]

Neat, clean and minimal is preferred.

For the neighbor list on a site within a networked trunking system, names aren't really necessary; just the RFSS and site numbers (ie 102, 103, 105, 109, 212, 326, etc).

I understand that concept, but it doesn't answer the cross-system neighbors question. Here's the relevant snippets from my DSDPlus.P25data:

  Network: BEE00.1CE  ; Missouri Statewide Wireless Interoperable Network (MOSWIN)

    Site: 1.23   NAC=1C3    ; Lawson

    Neighbor: BEE00.2B0-4.1      ; MO Kansas City

    Site: 1.24   NAC=1C4    ; Independence

    Neighbor: BEE00.2B0-4.1      ; MO Kansas City

  Network: BEE00.2B0  ; Metropolitan Area Regional Radio System (MARRS)

    Site: 4.1    NAC=2B0    ; MO Kansas City

    Neighbor: BEE00.1CE-3.23     ; Willow Springs
    Neighbor: BEE00.1CE-3.24     ; Caulfield  West Plains

How would this be conveyed to others (nevermind that the RFSS for the neighbors is wrong on the Kansas City site since sites 3.23 and 3.24 are several hundred miles away)?

 

[GTR8000]

For Lawson's peers, could be listed as: 2B0-1.23 and for Independence: 2B0-4.1

No reason to over-complicate it.

 

[wa8pyr]

For Lawson's peers, could be listed as: 2B0-1.23 and for Independence: 2B0-4.1

No reason to over-complicate it.

What he said. . . .

 

[mtindor]

I understand that concept, but it doesn't answer the cross-system neighbors question. Here's the relevant snippets from my DSDPlus.P25data:

  Network: BEE00.1CE  ; Missouri Statewide Wireless Interoperable Network (MOSWIN)

    Site: 1.23   NAC=1C3    ; Lawson

    Neighbor: BEE00.2B0-4.1      ; MO Kansas City

    Site: 1.24   NAC=1C4    ; Independence

    Neighbor: BEE00.2B0-4.1      ; MO Kansas City

  Network: BEE00.2B0  ; Metropolitan Area Regional Radio System (MARRS)

    Site: 4.1    NAC=2B0    ; MO Kansas City

    Neighbor: BEE00.1CE-3.23     ; Willow Springs
    Neighbor: BEE00.1CE-3.24     ; Caulfield  West Plains

How would this be conveyed to others (nevermind that the RFSS for the neighbors is wrong on the Kansas City site since sites 3.23 and 3.24 are several hundred miles away)?

2B0-4.1
NL: 1CE-3.23, 1CE-3.24

1CE-3.23
NL: 2B0-4.1

1CE-3.24
NL: 2B0-4.1

Now if you were monitoring a 1CE site and it listed a combination of 1CE and 2B0 peers:

NL: 3.23, 3.24, 2B0-4.1

The AEP P25 system, being multistate, has multiple System IDs with many sites listing neighbors in bordering SysIDs

1F7-15.15

NL: 17.17, 32.32, 39.39, 1F6-12.12, 1F6-18.18, 1F6-26.26, 1F6-29.29, 1F6-34.34

- of course 17.17, 32.32, and 39.39 are in 1F7 so I don't list that in the NL

So in my particular case, I list native peers (those with same SysID) first, without the SysID, and then I tack on the non-native peers.

Mike