SDS100/SDS200: Trouble programming a Tier III DMR system; LSN vs. LCN?

[W4KRR]

I’m trying to program a DMR Tier III trunking system into an SDS100, using Sentinel Software.
DSD Plus shows this as the system:
Ch TX Freq
451 453.8000
452 453.8000
1447 460.0250
1448 460.0250
1497 460.3375
1498 460.3375
1527 460.5250
1528 460.5250

With this arrangement, DSD Plus tracks conversations just fine.
I programmed this in the Sentinel Software:
Frequency LCN Color Code
453.8000 1 Color Code 1
460.0250 2 Color Code 1
460.3375 3 Color Code 1
460.5250 4 Color Code 1

DSD Plus tracks the system just fine. The SDS100 never stops on a conversation. It shows signal strength on the control channels, but never stops scanning. (I have set it to ID Search Mode).
This might have something to do with LCN (Logical Channel Numbers) vs. LSN (Logical Slot Numbers).

Anyone know what I might be doing wrong?

 

[mtindor]

Shouldn't this work just fine?

453.8000 451 Color Code 1
453.8000 452 Color Code 1
460.0250 1447 Color Code 1
460.0250 1448 Color Code 1
460.3375 1497 Color Code 1
460.3375 1498 Color Code 1
460.5250 1527 Color Code 1
460.5250 1528 Color Code 1

Is that supposed to be the Fort Lauderdale site of Broward Co Government trunked system? If so, please submit an update for that system/site via the Submit button on that trunked system's page, as the information that you have gleaned from DSDPlus is different from that which is in the database.

 

[W4KRR]

mtindor, I tried it the way you listed it above; It didn't work. I didn't know if the Over-the-Air (OTA) channel numbers were valid information in Uniden Sentinel. I assumed it was looking for LCN 1, LCN 2, etc.

Yes, this is the Fort Lauderdale site of Broward Co Government trunked system

The DSD Plus program provides the Over-the-Air (OTA) channel numbers as I have listed; the user has to provide the proper frequencies to go with them. I got the frequency information from FCC records for this particular site. The information that is listed in the RR database is what I have, except that DSD Plus doesn't show 453.3625 or 460.1875 as being in use.

Note that the RR database doesn't show LCN's or OTA channel numbers for this particular system, the question is; does the programming require LCN's or OTA channel numbers?

 

[mtindor]

Ok. If you didn't actually confirm for yourself that when you saw 451 active, that you heard the traffic on 453.800 (and so on), then you probably don't have the right pairings. Do not go by FCC records. If you could ever trust FCC records for actual channel order, it would be purely a fluke.

It is possible that 453.3625 and 460.1875 were set put busied out by the maintainers of the system, or repurposed for some other use, or simply didn't show up in DSDPlus because the system may not have been active enough to trigger those additional frequencies to be used.

I'll be learning as you go along. I have no TIII here to work with. I don't think the programming is the same as DMR, but more likely similar to NXDN systems. You have channel numbers (the OTA ones) and DSDPlus likely displays them correct. You just have to work on determining what frequency is truly active with audio when you see a talkgroup active on a particular channel number.

Of course, you could always just program in all of the frequencies that you believe are active on the system, into the SDS100, and run LCN Finder on that site and let it eventually determine the LCN or channel number associated with each frequency. That's probably what somebody had done in the past already for that site. The LCN finder should do the job. but you'll want to run the LCN Finder in the SDS100 on the site when the site is most busy. And if you know for a fact that one or more of the frequencies listed in the RRDB for that site aren't active on the site, then don't program them into the SDS100 yet. Run the LCN finder with only frequencies you know / have seen / have heard traffic on. Because you'll know the LCN finder will be able to find the proper number for them. For frequencies that you program in (but aren't active on the system), the LCN finder will not completely finish finding all LCNs/channel numbers because it can only determine those when a frequency is active with trunked voice traffic.

 

[Ubbe]

To get Unidens LCN instead of LSN that RR uses you divide the even number for a frequency with two.

The system seems to use a bandplan with a base frequency of 450.975MHz and stepsize 0.0125MHz and LCN 1 starts at 451.0000MHz and 453.800 then have LCN 226 and 460.525 uses LCN 764.

Whenever you see LSN numbers in RR you divide the even number in half to get the LCN that Uniden scanners uses.
If you have an unknown LCN for a frequency you substract the base frequency from it and divide by 0.0125 to get the LCN.

/Ubbe

 

[mtindor]

To get Unidens LCN instead of LSN that RR uses you divide the even number for a frequency with two.

The system seems to use a bandplan with a base frequency of 450.975MHz and stepsize 0.0125MHz and LCN 1 starts at 451.0000MHz and 453.800 then have LCN 226 and 460.525 uses LCN 764.

Whenever you see LSN numbers in RR you divide the even number in half to get the LCN that Uniden scanners uses.
If you have an unknown LCN for a frequency you substract the base frequency from it and divide by 0.0125 to get the LCN.

/Ubbe

I knew that was the correlation for standard DMR, but since I'd never monitored a TIII system I didn't know if it was the same. And it didn't help [me] that the database shows "CH ID" for DMR TIII systems and then shows LSN/LCN information for non-TIII DMR systems. Thanks for the clarification. Looks like the info in the DB for that site might be off-by-one with the LCN then.

Wouldn't it then be this? :

453.3625 191 CC 1
453.8000 226 CC 1
460.0250 724 CC 1
460.1875 737 CC 1
460.3375 749 CC 1
460.5250 764 CC 1

Instead of (what is in the DB) :

453.3625 190 CC 1
453.8000 225 CC 1
460.0250 449 CC 1
460.1875 736 CC 1
460.3375 748 CC 1
460.5250 763 CC 1

I think the OP should try the ones in bold. in his SDS.

Mike

 

[W4KRR]

Ubbe, I believe you're the one who came up with the formula that allowed me to determine the frequency based on the OTA channel number thrown out by DSD Plus. When I put those frequencies in DSD Plus, it works just fine, and the frequencies correspond to what is in the RR database, and the FCC data.

I will have to experiment with the proper info to put under the "LCN" column in the Sentinel software.

So, what does Uniden Sentinel require, the LSN, LCN, or OTA number (at least as far as Tier III systems are concerned)? And would the order they are entered really matter, as long as they're numbered correctly? Wouldn't any unused frequencies just be ignored?

UP Man, what say you???

 

[mtindor]

Uniden wants the LCN. Each LSN pair is tied to an LCN (which is the higher numbered LSN of the pair divided by 2).

DSDPlus uses LSNs.

Separated into LSN pairs (those are two simeslots, associated with one LCN). Take the higher numbered LSN of the pair, divide by 2, and you get the LCN.

451 453.8000
452 453.8000 LCN = (452 / 2) = 226

1447 460.0250
1448 460.0250 LCN = (1448 / 2) = 724

1497 460.3375
1498 460.3375 LCN = (1498 / 2) = 749

1527 460.5250
1528 460.5250 LCN = (1528 / 2) = 764

The frequencies might be in the FCC data, but there is no part of the FCC data that would indicate the LCN.

Please put in what I suggested in bold in my previous post and see how it works. Despite my momentary lapse of cluefulness (due to lack of DMR TIII monitoring around here), I have a pretty good track record of providing legitimate help. So it should be worth trying my suggestion from my previous post.

 

[W4KRR]

Mike, I put in the data as suggested by you in bold above. It works, partially, depending on what frequency the conversation gets sent to. On some of the frequencies, there is no audio, and the scanner doesn't stop scanning. Likewise, I also tried entering the data using the LCN's presented in the RR database. Same results; it works partially, depending on which frequency gets the conversation.

However, the DSD PLus program works properly with these frequencies, so they must be correct. I also tried entering each frequency twice, with each LCN (191, 192; 225, 226, etc.) , this method didn't seem to work at all.

 

[mtindor]

Ok. To be honest, since I don't have any local TIII to program into my SDS, I don't know if it's an issue with Uniden's TIII implementation or if it's an issue with frequency<>LCN pairing. I'm not suggesting that Uniden's don't work on TIII 100%, but at the same time I can't say that they do.

As long as its programmed in as an actual DMR trunked system (not conventional), and as long as you have it in ID Search mode, and as long as you have what's listed in bold programmed in, and as long as the CC for each of the active frequencies truly is color code 1 (they can be different on the same site), it should properly trunktrack and voice follow 100% of the time.

One of the frequencies in the database ( 460.0250 449 CC 1 ) seems to have an LCN that is way off, whilst all of the other frequencies on that site seem to have an LCN that is off-by-one.

I'm really not sure how the database implementation and my implementation could both work partially. Either what I have in bold is correct, or what is in the DB is correct (minus 460.025's LCN), but it couldn't possibly be tracking traffic using both implementations.

This is all based upon the LSNs (channel numbers) in DSDPlus being current/accurate (forget about the frequencies). I say that because you never know when a system maintainer might change system characteristics. If you have sat on the current control channel with DSDPlus recently, and it reveals activity on LSNs (channel numbers) 451/452, 1447,1448, 1497/1498, and 1527/1528, then what I have in bold should be accurate and it should trunk 100% of the time.

So I'm at a loss at this point, unless one or more of the active frequencies on the system has less signal strength at your antenna input or has local interference wreaking havoc with it, causing inability for it to decode the actual voice. Is the signal strength on the SDS pretty good for that system?

 

[W4KRR]

Thanks for your help, Mike. I will have to do more experimentation.

Just to sum up:
Labeling the frequencies as LCN 1, 2, 3, 4, etc. from top to bottom doesn't work at all (DMR Tier III).
DSD+ outputs OTA (Over-the-Air) channel numbers as determined by the system administrator (DMR Tier III, as well as NXDN trunked systems).
DSD+ outputs LCN numbers (1, 2, 3, 4, etc. ) for Connect Plus systems. (Capacity Plus also?)

Even though NXDN systems also use OTA channel numbers, I have always used LCN numbers (1, 2, 3, 4, etc. ) when programming Uniden scanners, and it seems to work fine. So I guess channels are implemented differently for DMR Tier III systems.

 

[mtindor]

TYPE    DSDPLUS            SCANNERS    RRDB
CON+    channel # = LSN        want LCN    want LCN
CAP+    channel # = LSN        want LCN    want LCN
DTIII   channel # = LSN        ????????    ????????
NXDN    channel # = LCN        want LCN    want LCN
IDAS    channel # = LCN        want LCN    want LCN

For NXDN / IDAS, when an admin sets up a site, the backend wants the "NXDN channel ID", which is the channel number from DSDPlus. Since NXDN/IDAS are single timeslot, no conversion is needed by the admin. The site info will show it as "CH ID". The "CH ID" from the RRDB is the "LCN" that the scanner wants and the channel number that DSDPlus shows.

For CAP+ / CON+, when an admin sets up a site, the backend wants the LCN, which is the channel number from DSDPlus, divided by 2 and rounded up. Although, once the information is added to the DB the site info will show both LCN and LSN info. The "LCN" from the RRDB is the "LCN" that the scanner wants. The LSN from the RRDB is the channel number that DSDPlus shows.

I would guess scanners want the LCN for DTII, but I'm unsure. And when an admin adds a DTIII site in the DB, the backend asked for the DTIII Channel # and displays it as CH ID in the site info. I'm unclear whether the RRDB is expecting the LCN as the channel number or the LSN as the channel number, and I'm unclear what the scanner wants.

Incidentally, for the Uniden scanners, are you programming DTIII as a "MotoTRBO Trunked" system ? I'm guessing that you are, and that you are supposed to. Although I find it interesting that Uniden calls it "MotoTRBO Trunked" since MotoTRBO is proprietary nomenclature to Motorola and a DMR trunked systems are not all made by Motorola.

Gotta love it.

Mike

 

[RF23]

Do other nonUniden scanners also use only the LCN?

 

[hiegtx]

Do other nonUniden scanners also use only the LCN?

If you are referring to the Whistler & former GRE scanners, they do not use the LCN at all. They receive the DMR transmission using the emission code, but do not track the systems. Since no tracking is done, LCN does not come into play.

 

[garys]

I thought that the formula was DSD numb divided by 2 minus 1?

 

[W4KRR]

=
Incidentally, for the Uniden scanners, are you programming DTIII as a "MotoTRBO Trunked" system ? I'm guessing that you are, and that you are supposed to. Although I find it interesting that Uniden calls it "MotoTRBO Trunked" since MotoTRBO is proprietary nomenclature to Motorola and a DMR trunked systems are not all made by Motorola.

Gotta love it.

Mike

Yes; programming as a "MotoTRBO Trunked" system. The display on the top of the scanner screen even says "DMRT3" as it scans through the control channels.[/QUOTE]

 

[mtindor]

I thought that the formula was DSD numb divided by 2 minus 1?

Nosir. No -1 involved. Although I need to make the formula more clear. You can either say the LCN is the even numbered LSN divided by two OR the odd numbered LSN divided by two and rounded up (both of which would give you the same LCN).

ch 1 / lsn 1 lcn 1
ch 2 / lsn 2 lcn 1
ch 3 / lsn 3 lcn 2
ch 4 / lsn 4 lcn 2
ch 5 / lsn 5 lcn 3
ch 6 / lsn 6 lcn 3
etc

At least that is how it goes on Con+/Cap+.

Mike

 

[garys]

Yes, you're right. I went back and read the thread on the forum to refresh my memory. It was rounding DOWN, not subtracting. That might be why my 436HP won't track properly. There is only one system near me using Hytera, and it's only busy when there is a big event going on.

I'll have to go back and check my DSD+ frequencies file for that system.

Thanks!

 

[mtindor]

That's interesting that somewhere they talk about rounding down. That would not work well. LSN 5 is LCN 3. But if you did 5/2 and rounded down, you would get 2.5 (and then rounded down it would be 2 -- which is wrong). So you want to divide odd number LSNs by 2 and round up, or better yet just divide the even number by 2 and be done with it. Keep it simple.

Mike

 

[Ubbe]

On some of the frequencies, there is no audio, and the scanner doesn't stop scanning.

Check that all service types are enabled, just as a test, and set color codes to search. Only use restrains like color codes if it's absolutly neccesary, like if another DMR system uses the same frequency.

It could also be that the scanner have receive problems with one of the frequencies. The filter settings normal/invert/wide are set per site so try one setting at a time and if that doesn't work you could try and set IFX to all site frequencies, or log which frequencies that do work to try and find the problematic one that might need a IFX setting.

/Ubbe