United Airlines DMR Tier 3 DMR Trunked System

[werinshades]

My understanding, from what @ChicagoRadio736 stated above, is that he had to manually program it into his SDS100/SDS200/BCD536HP scanners. Previously I tried programming this system into my SDS100 and it would not track, even if I was sitting next to O'Hare. It would be helpful if @ChicagoRadio736 can share with us his manual programming instructions, as Sentinel does not have any of this info. I feel that analyzing this system with the data acquired via DSD+ and tweaking it (with great help from @Wsjones) is a great way to spread the knowledge.

I'm sure he self-programmed with the information from the database and is reporting it as working on his scanners. The only thing I could see as needed to be changed is if the two frequencies that are "reported" are found to be in use, run the LCN Finder in the Analyze menu and see if an LCN can be detected which can only be done if voice traffic is detected. I don't use DSD, and not sure if the settings don't coincide with Uniden scanners. But, until a scanner user who's within close proximity reports a change needs to be made, I'd hold off. Besides @kevino was the database administrator who initiated the entry and would also run it past him too. Two users with scanners reporting it working might be a better judge if any changes need to be made.

 

[ChicagoRadio736]

I simply used the information in the database that Kev provided I did nothing special, and it tracks perfectly no issues at all.

 

[ChicagoRadio736]

I
477.0125: LCN 2129, 477.2125: LCN 2145, 477.3125: LCN 2153

What sites are these associated with I can run the LCN finder and see what happens. I work across the street from O'Hare in Rosemont. Site 1 or 2?

 

[mwjones]

If it's trunking properly on 2 scanners, why does it need to be changed?

Scanners aren't dependent on the fine-tooth details, whereas programs like DSDPlus are, that's why they need to be updated. Also, the capture that @kbk777 provided showed additional frequencies on two sites, that if they aren't added into scanners could result in some missed communications.

My understanding, from what @ChicagoRadio736 stated above, is that he had to manually program it into his SDS100/SDS200/BCD536HP scanners. Previously I tried programming this system into my SDS100 and it would not track, even if I was sitting next to O'Hare. It would be helpful if @ChicagoRadio736 can share with us his manual programming instructions, as Sentinel does not have any of this info. I feel that analyzing this system with the data acquired via DSD+ and tweaking it (with great help from @Wsjones) is a great way to spread the knowledge.

Sentinel has a known issue where the database does not download/update Capacity Max systems, and thus do not show up in there as part of their weekly updates (something that others and I have brought up to @JoeBearcat in multiple threads), it is not a RadioReference problem, but a Uniden problem. That would explain the manual programming that @ChicagoRadio736 had to do.

That said, if it is manually programmed correctly into Sentinel, it will work just fine, although I've seen mention that some scanners don't like the 7-digit Radio/Talkgroup ID's, so make sure you're on the latest firmware in the scanner and it should work.

 

[mwjones]

I
477.0125: LCN 2129, 477.2125: LCN 2145, 477.3125: LCN 2153

What sites are these associated with I can run the LCN finder and see what happens. I work across the street from O'Hare in Rosemont. Site 1 or 2?

.0125 and .2125 are site 2, .3125 is on site 1. The LCN's listed are correct.

 

[werinshades]

Scanners aren't dependent on the fine-tooth details, whereas programs like DSDPlus are, that's why they need to be updated. Also, the capture that @kbk777 provided showed additional frequencies on two sites, that if they aren't added into scanners could result in some missed communications.


Sentinel has a known issue where the database does not download/update Capacity Max systems, and thus do not show up in there as part of their weekly updates (something that others and I have brought up to @JoeBearcat in multiple threads), it is not a RadioReference problem, but a Uniden problem. That would explain the manual programming that @ChicagoRadio736 had to do.

That said, if it is manually programmed correctly into Sentinel, it will work just fine, although I've seen mention that some scanners don't like the 7-digit Radio/Talkgroup ID's, so make sure you're on the latest firmware in the scanner and it should work.

I understand what you're saying and suggested that the two "reported" missing frequencies be checked for activity and to document the proper LCN, I'm not sure what other changes would be needed since the system is being monitored by scanners without issues. I don't monitor the system regularly, but others do. I think the issue has more to do with self-programming via Sentinel or Proscan more than anything.

 

[kbk777]

I understand what you're saying and suggested that the two "reported" missing frequencies be checked for activity and to document the proper LCN, I'm not sure what other changes would be needed since the system is being monitored by scanners without issues. I don't monitor the system regularly, but others do. I think the issue has more to do with self-programming via Sentinel or Proscan more than anything.

This is a good discussion, especially for a newbie like me who’s trying to gain that prerequisite knowledge so I can better understand this technology. I will modify my DSD+ configuration and report back. I am happy to dig deeper and help discover more systems. Thanks all!

 

[werinshades]

This is a good discussion, especially for a newbie like me who’s trying to gain that prerequisite knowledge so I can better understand this technology. I will modify my DSD+ configuration and report back. I am happy to dig deeper and help discover more systems. Thanks all!

I'm glad you found 2 missing frequencies, might be helpful if any conversations were being missed. Hopefully the LCN's can be confirmed and submitted. These types of systems have been causing issues since MotoTRBO was introduced on Uniden scanners.

I programmed the system down by me near Midway, and unfortunately can't get an accurate decode on it. I'm also getting a CON+ rest channel, so I'll be of no help.

 

[mwjones]

I understand what you're saying and suggested that the two "reported" missing frequencies be checked for activity and to document the proper LCN, I'm not sure what other changes would be needed since the system is being monitored by scanners without issues. I don't monitor the system regularly, but others do. I think the issue has more to do with self-programming via Sentinel or Proscan more than anything.

The information I submitted earlier this evening was the three missing frequencies, but also just a bit of housekeeping, correcting the System ID, Site ID's and fixing an incorrect License, along with other minor things. The proper LCN's were already documented in the system notes, they just weren't assigned to the correct sites, and the capture that @kbk777 shared back in the earlier message showed all three in use (DSDPlus logs by "Logical Slot Numbers" LSN's, and the LSN's when calculated match the "Logical Channel Numbers" LCN's that Uniden uses, hence why they can be considered verified. Since each frequency has 2 "slots" there are 2 LSN's for every 1 LCN. (meaning one frequency can carry two conversations, be them voice or data or control channel) at the same time.

Quick lesson on most Tier III systems, both Standard and Non-Standard (including Capacity Max) - These systems typically run a "bandplan" much like a P25 system does, but unlike a P25 system, that bandplan is not transmitted over the air (which is why you only need to program the control channels on a P25 system, since it gets the bandplan and can decode the rest), only the channel assignments for traffic. In Tier III terms, the channel assignments are sent as LSN's. The good news is that with a bit of math, once you match one or two frequencies to the LSN's that they use, you can calculate the bandplan, which will line up with all frequences.

In the case of this system, there is actually 2 bandplans, the first has a base frequency of 450.4125 (which is LSN 3 and 4, or LCN 1), the second is a base frequency of 460.0 (which again is LSN 3 and 4, or LCN 1). On both bandplans they are using 12.5KHz spacing between results, so LSN 5 and 6 or LCN 2 would be 450.425 and 460.0125 respectively.

Some people use a spreadsheet to lay out the bandplan once it's determined, others, like me use the DMR frequency calculator, which makes quick work of mapping the bandplan to what is being seen in DSDPlus.

When @kbk777 was monitoring Site 1, I observed a few entries as (see the highlighted part for the LSN's):

2024/04/15 15:39:46 Freq=476.337500 DCC=0 RAS Group call; TG=6730136 [[ORD AcftMove Ops] Aircraft Move Teams] Ch=4307 4s
2024/04/15 15:39:46 Freq=476.337500 DCC=0 RAS Group call; TG=6730111 [[ORD Zone 11?] Ramp: F Gates] Ch=4308 2s

Using my decoder, I was able to get the frequency, and since the LSN's received and LCN's that were already posted were consistent, I could submit it to RRDB as:

Site Frequency Table:

LCN       LSNs or CH IDs    Frequency    Color Code
2153   4307/4308        477.3125    0 ***ADD***

The same could be said for the two frequencies on Site 2:

2024/04/15 15:42:29 Freq=460.725000 DCC=0 RAS Group call; TG=6730141 [[ORD Cust Svc T5] Customer Service: Terminal 5] Ch=4259 7s
2024/04/15 15:42:29 Freq=460.725000 DCC=0 RAS Group call; TG=6730148 Ch=4260 24s
2024/04/15 15:47:02 Freq=460.725000 DCC=0 RAS Group call; TG=6730122 [[ORD Baggage 122] Baggage Operations] Ch=4291 2s
2024/04/15 15:47:02 Freq=460.725000 DCC=0 RAS Group call; TG=6730105 [[ORD Zone 5] Ramp: C Even Gates?] Ch=4292 2s

Which resulted in this being submitted:

Site Frequency Table:

LCN       LSNs or CH IDs    Frequency    Color Code
2129   4259/4260        477.0125    0 ***ADD***
2145   4291/4292        477.2125    0 ***ADD***

I strongly believe in "quality not quantity", and I only submit data if I have a high confidence of its accuracy. Likewise how I submit it is formatted in a way that leaves little room for a misunderstanding by the fine database admins (based on many lessons learned). Scanners may give you functional data, but its tools like DSDPlus that give you the complete picture, and I have begun to rely on it more heavily in the past few years (I own 6 SDR Radios, so yes, it is a big deal for me), but still leverage my SDS100/200 for parts of assembling that big picture and verifying what I get.

 

[werinshades]

The information I submitted earlier this evening was the three missing frequencies, but also just a bit of housekeeping, correcting the System ID, Site ID's and fixing an incorrect License, along with other minor things. The proper LCN's were already documented in the system notes, they just weren't assigned to the correct sites, and the capture that @kbk777 shared back in the earlier message showed all three in use (DSDPlus logs by "Logical Slot Numbers" LSN's, and the LSN's when calculated match the "Logical Channel Numbers" LCN's that Uniden uses, hence why they can be considered verified. Since each frequency has 2 "slots" there are 2 LSN's for every 1 LCN. (meaning one frequency can carry two conversations, be them voice or data or control channel) at the same time.

Quick lesson on most Tier III systems, both Standard and Non-Standard (including Capacity Max) - These systems typically run a "bandplan" much like a P25 system does, but unlike a P25 system, that bandplan is not transmitted over the air (which is why you only need to program the control channels on a P25 system, since it gets the bandplan and can decode the rest), only the channel assignments for traffic. In Tier III terms, the channel assignments are sent as LSN's. The good news is that with a bit of math, once you match one or two frequencies to the LSN's that they use, you can calculate the bandplan, which will line up with all frequences.

In the case of this system, there is actually 2 bandplans, the first has a base frequency of 450.4125 (which is LSN 3 and 4, or LCN 1), the second is a base frequency of 460.0 (which again is LSN 3 and 4, or LCN 1). On both bandplans they are using 12.5KHz spacing between results, so LSN 5 and 6 or LCN 2 would be 450.425 and 460.0125 respectively.

Some people use a spreadsheet to lay out the bandplan once it's determined, others, like me use the DMR frequency calculator, which makes quick work of mapping the bandplan to what is being seen in DSDPlus.

When @kbk777 was monitoring Site 1, I observed a few entries as (see the highlighted part for the LSN's):



Using my decoder, I was able to get the frequency, and since the LSN's received and LCN's that were already posted were consistent, I could submit it to RRDB as:

Site Frequency Table:

LCN       LSNs or CH IDs    Frequency    Color Code
2153   4307/4308        477.3125    0 ***ADD***

The same could be said for the two frequencies on Site 2:



Which resulted in this being submitted:

Site Frequency Table:

LCN       LSNs or CH IDs    Frequency    Color Code
2129   4259/4260        477.0125    0 ***ADD***
2145   4291/4292        477.2125    0 ***ADD***

I strongly believe in "quality not quantity", and I only submit data if I have a high confidence of its accuracy. Likewise how I submit it is formatted in a way that leaves little room for a misunderstanding by the fine database admins (based on many lessons learned). Scanners may give you functional data, but its tools like DSDPlus that give you the complete picture, and I have begun to rely on it more heavily in the past few years (I own 6 SDR Radios, so yes, it is a big deal for me), but still leverage my SDS100/200 for parts of assembling that big picture and verifying what I get.

I got all that again as I said, however with all due respect to your knowledge, I would prefer to have locals who monitor the system on a regular basis (one of which is a database administrator), verify prior to a submission is published. I'm aware of these systems, the challenges to getting it right. As I mentioned, a user who lives on the outskirts of O'Hare is reporting no issues with the database submission. As @kbk777 has reported, he has difficulty self-programming the system in his scanner, not because of the information, but unfamiliarity with the process to do so. I'm not challenging your knowledge or the DSD+ findings, but I'm aware of discrepancies at times between Uniden's LCN finder and DSD+. Since most here utilize scanners, that's where the focus should be. The two frequencies that were not listed will probably be added once it's verified with an LCN. Thanks for the information, and the capable Illinois folks can take it from here.

 

[ChicagoRadio736]

.0125 and .2125 are site 2, .3125 is on site 1. The LCN's listed are correct.

You talking about site 1 and 2 that's documented in the database, correct?

 

[ChicagoRadio736]

Ok site 2 shows frequency 477.0125 as in use with LCN 2129 and frequency 477.2125 as in use with LCN 2145. I'm working on site one now. SDS100

 

[ChicagoRadio736]

Great work guys with the information!!!!

 

[ChicagoRadio736]

OK site 1 took a couple hours to find the LCN for frequency 477.3125 it shows in use with LCN 2153. So, all three frequencies reported not in use in fact are in use. Database needs to be updated great work guys!

 

[kevino]

OK site 1 took a couple hours to find the LCN for frequency 477.3125 it shows in use with LCN 2153. So, all three frequencies reported not in use in fact are in use. Database needs to be updated great work guys!

I updated the United Airlines (Tier 3) Trunking System, Various, Illinois database page this morning, hopefully it all looks correct as per the submission of @mwjones. Please advise if there are any additional tweaks that need to be made to that page.

The plan now is to merge the three O'Hare sites to United Airlines DT3 Trunking System, Various, Multi-State , it's just a matter of doing this correctly. One possible issue is that there's also a Site 1 at LAX, something we'll need to work out. It also appears that region information needs to be determined for each airport (other than O'Hare) and added to the UAL 'nationwide' system page.

 

[mwjones]

I updated the United Airlines (Tier 3) Trunking System, Various, Illinois database page this morning, hopefully it all looks correct as per the submission of @mwjones. Please advise if there are any additional tweaks that need to be made to that page.

Thanks Kevin. Everything looks good from my perspective, with the exception of below...

The plan now is to merge the three O'Hare sites to United Airlines DT3 Trunking System, Various, Multi-State , it's just a matter of doing this correctly. One possible issue is that there's also a Site 1 at LAX, something we'll need to work out. It also appears that region information needs to be determined for each airport (other than O'Hare) and added to the UAL 'nationwide' system page.

I'm not yet sure if this is a single system or not. I was in LA in March (and will be in Denver next month, and maybe later this summer will get to Houston to see former co-workers and friends) and was picking up traffic on Site 1 of the other system, although the Neighbor Lists were really messed up (Site 1 said its neighbor was Site 2, which doesn't exist, and Site 12 says its neighbor is Site 11, which also doesn't exist).

What we need is more data, as we know Newark, New Jersey (EWR) should be on one of these systems with likely multiple sites, and most of the 900MHz sites will be due for rebanding because of Anterix's 3MHz broadband grab, where they're getting 936.5-939.5MHz, but have to pick up the tab for those affected to move out of it.

As far as the "Region" is concerned, Capacity Max systems do not use the Region prefix, as they behave more like Connect+ systems do, and only the site number will apply. That's why I was unsure on how you enter the Region codes in the submission, since I don't know the DB Admin interface - most Capacity Max systems don't show the region at all on the user side. I see they're currently showing as Region "0" (and for that again, my lack of understanding the DB Admin interface is why I said "0 (or blank)" for the regions). I will modify the "template" I use for submissions for when I'm cleaning up systems to mark Regions as "empty" or "delete" when it should be removed.

Sadly, when I left Continental/United in late 2011, I was not on good terms with the guys in the radio shop (a few stories for other days, involving things like Zetron consoles and OpenSky systems), and knowing as an insider how much the Continental ground support teams were despised by the United teams, I doubt any of them are still there after 13 years anyway, so I can't reach out to them for insider insight.

 

[kevino]

Thanks Kevin. Everything looks good from my perspective, with the exception of below...



I'm not yet sure if this is a single system or not. I was in LA in March (and will be in Denver next month, and maybe later this summer will get to Houston to see former co-workers and friends) and was picking up traffic on Site 1 of the other system, although the Neighbor Lists were really messed up (Site 1 said its neighbor was Site 2, which doesn't exist, and Site 12 says its neighbor is Site 11, which also doesn't exist).

What we need is more data, as we know Newark, New Jersey (EWR) should be on one of these systems with likely multiple sites, and most of the 900MHz sites will be due for rebanding because of Anterix's 3MHz broadband grab, where they're getting 936.5-939.5MHz, but have to pick up the tab for those affected to move out of it.

As far as the "Region" is concerned, Capacity Max systems do not use the Region prefix, as they behave more like Connect+ systems do, and only the site number will apply. That's why I was unsure on how you enter the Region codes in the submission, since I don't know the DB Admin interface - most Capacity Max systems don't show the region at all on the user side. I see they're currently showing as Region "0" (and for that again, my lack of understanding the DB Admin interface is why I said "0 (or blank)" for the regions). I will modify the "template" I use for submissions for when I'm cleaning up systems to mark Regions as "empty" or "delete" when it should be removed.

Sadly, when I left Continental/United in late 2011, I was not on good terms with the guys in the radio shop (a few stories for other days, involving things like Zetron consoles and OpenSky systems), and knowing as an insider how much the Continental ground support teams were despised by the United teams, I doubt any of them are still there after 13 years anyway, so I can't reach out to them for insider insight.

Any chance that LAX Site 1 is actually Site 11?

 

[mwjones]

Any chance that LAX Site 1 is actually Site 11?

That's what's interesting... I was in Los Angeles in March, and it is showing OTA as Site 1 (and Site 2 is its neighbor, but the Control Channel is LSN 1, which is the default if it's not defined):

2024/03/09 14:47:35 Freq=938.250000 Current network: L719:1 United Airlines
2024/03/09 14:47:35 Freq=938.250000 Current site: L719:1-1 L1-1 Los Angeles (LAX 935)
2024/03/09 14:47:37 Freq=938.250000 DCC=0 RAS L719:1-1 neighbor: Site L719:1-2; CC=1

But the second site is showing as Site 12, with a neighbor of Site 11 (again the Control Channel for Site 11 is LSN 1)

2024/03/09 14:42:44 Freq=859.087500 Current network: L719:1 United Airlines
2024/03/09 14:42:44 Freq=859.087500 Current site: L719:1-12 L1-12 Los Angeles (LAX 854)
2024/03/09 14:42:45 Freq=859.087500 DCC=0 RAS L719:1-12 neighbor: Site L719:1-11; CC=1

Being that Site 12 didn't log any traffic for the hour or so I was monitoring, and others have reported the same, it might be that Site 12 is there and Site 11 may replace Site 1, since 5 of the 6 frequencies on Site 1 are going to be shifted to Anterix, and I know in Houston they're going to switch to 800MHz at some point, so they may do the same in LAX as well.

Granted a "Large" system size would make me think it is more than O'Hare on that system, so it could be two systems, split across the country (when I was at Continental, our VoIP Network for the mainland US was 6 "cores" and a couple hundred Sites, so diversity and redundancy may be in play here too), or it could be one System that has a duplicate site number (I've seen that before on the Target NXDN system, which has at least 3 Site 1's the last time I was in range of 2 of those 3), but you'd think the duplicate would be showing isolated, and neither of them are. Looking at the Connect Plus system, Dulles, Newark and San Francisco are still showing on that system, but I don't know if that means that they haven't converted yet, or if nobody's discovered them yet (and a quick glance also shows that there may be other sites in Guam and Cleveland as well, although I think they've scaled back what they do at Cleveland from the days when I was supporting them). That's why I would like to see more site numbers, to help fill in the missing holes. Alas, none of those locations are in my travel plans, so it won't be me contributing them to RRDB.