DMR -- trunked system timeslots / entering into the DB

I often update a fairly large TRBO Connect+ system. There are currently around 24 sites, and each site has a minum of 3 repeaters [six timeslots, 5 for voice and one for CC].

Normally I would just enter in the freq without any regard for LCN, but ideally unless something is done in the backend to change the way this information is stored, I feel it is best to use the LCN field to idicate the over-the-air channel number and to duplicate frequencies.

For instance:

Site A has four repeaters, and over the air channel numbers are 13-20.

13 452.00000
14 452.00000

15 452.10000
16 452.10000

17 452.20000
18 452.20000

19 452.30000
20 452.30000

That seems a lot more logical, and correct, as it actually designates the timeslot's over the air channel number [using the LCN field to do it]. Yeah, it duplicates the frequencies, and that may be a nono.

But it makes a lot more sense than just putting in 452.0000, 452.10000, 452.2000 and 452.30000 in no particular order.

I'd like to know Tom and Lindsay's opinion regarding how this should be done. It wasn't until more recently that I was able to start gathering the extra useful information about over the air channel numbers and such. Now that we can do that, we need to account for that in the DB somehow -- either via the method I suggest above or some other.

Mike

Hello,

Those numbers look suspect. The Connect Plus CPS only allows up to 15 repeaters per site, numbered 1 through 15. These numbers are transmitted over the air along with a separate data field for the timeslot. Every system I have monitored, or seen a codeplug, always starts at LCN 1 and increases sequentially.

DMR Tier 3 trunked systems also use separate LCN and Timeslot fields because that is what is in the DMR standard.

Capacity Plus uses channel numbers to denote a repeater and timeslot. The CPS reflects this, and pairs the channels as 1/2, 3/4, 5/6, etc...,The RRDB displays Capacity Plus LCNs as 1, 3, 5, etc.., without duplicating them. I think this is reasonable.

DSDPlus is using Capacity Plus style channel numbers for all types of DMR, which is not correct. Looking at the raw data and comparing it to the DSDPlus display shows this.

73 Eric

You guys flesh this out and Tom and I will accommodate when it makes sense...

EricCottrell said:

Hello,

Those numbers look suspect.

Click to expand...

Eric,

The numbers are suspect because they are made up. But, on on particular Con+ site I do indeed get:

Con+, 145, 3, 13, 461.58750, 0.0, 1
Con+, 145, 3, 14, 461.58750, 0.0, 2
Con+, 145, 3, 15, 461.86250, 0.0, 3
Con+, 145, 3, 16, 461.86250, 0.0, 4
Con+, 145, 3, 17, 452.22500, 0.0, 5
Con+, 145, 3, 18, 452.22500, 0.0, 6
Con+, 145, 3, 19, 451.78750, 0.0, 7
Con+, 145, 3, 20, 451.78750, 0.0, 8

(that's my dsdplus.frequencies file, but that was created by me based upon what DSDPlus was reporting). It reported 13-20 as the channels.

Now I"ll go and thoroughly read / digest your response. Just wanted to get this out in the open.

Mike

mtindor said:

(that's my dsdplus.frequencies file, but that was created by me based upon what DSDPlus was reporting). It reported 13-20 as the channels.

Click to expand...

There's your problem. You can't use the format DSD+ uses in the DB as it will jack things all up. Just like Eric was saying, a frequency and a timeslot. I guess the DSD+ author does it that way to make the software easier to use despite it being incorrect. With DSD+ it's assigning each timeslot as a channel like Eric says.

Thanks for the explanation, Eric.

Correct or not, I like how the DSDPlus author has chosen to designate the timeslots in use per site in that fashion. It is less confusing and makes more sense [to me].

I guess things are good the way they are in the database from my perspective now that we've discussed it.

Mike

WayneH said:

There's your problem. You can't use the format DSD+ uses in the DB as it will jack things all up. Just like Eric was saying, a frequency and a timeslot. I guess the DSD+ author does it that way to make the software easier to use despite it being incorrect. With DSD+ it's assigning each timeslot as a channel like Eric says.

Click to expand...

I understood completely what was going on in DSDPlus. I had no beef with it. It just made me think that in the database there should be some more detail about the systems rather than just a simple LCN<-> frequency pairing. But I guess that would only be eye candy at this point. And I do understand why there should be unique LCN<--> frequency pairing. So I reverted back the changes I made to one specific system that I work on a lot.

As for it being right or wrong, I'm quite certain the author of DSDPlus knows exactly how it is designated in CPS and that a conscious decision was made to use channel numbers in that way to make it make more sense to the common folk [like myself].

If i'm monitoring a site with 10 repeaters, it sure is a lot easier to make sense of 1 through 20 designating activity versus 1-1, 1-2, 2-1, 2-2, 3-1, 3-2 designating activity.

I hope admins who don't know any better don't go and edit sites that have correct LCN order thinking that the LCN order doesn't matter. For the most part, most of the DMR systems I've added have been fairly LCN agnostic since it was difficult to know the LCN order without a lot of work [which is especially problematic when you are DXing a system and doing so on a weekend when it is very unbusy]. DSDPlus, with the way it designates the timeslots, allows one to figure out the LCN order a bit easier. DSD and the original DSD+ didn't have the perty interface.

Incidentally, for sites which I know there are x # of frequencies in use but I only know the LCN of the repeater with the CC on it, I will probably designate the unconfirmed ones as 99, 97, 95, etc. backwards.

Mike

mtindor said:

It just made me think that in the database there should be some more detail about the systems rather than just a simple LCN<-> frequency pairing.

Click to expand...

Create a ticket in Mantis. More or less it's an education problem though.

I hope admins who don't know any better don't go and edit sites that have correct LCN order thinking that the LCN order doesn't matter.

Click to expand...

This is my beef with it. Based on threads I see on DSD+ you're getting people who have no familiarity with the protocols running the software and misinterpreting how things work. That's what I mean about it being wrong; it's the wrong way to go about it. If all someone does is deal with DSD+ then it's fine but in an effort to create a common, proper platform for disseminating information it doesn't work to display the data that way. It may make it easier to understand but that should be on the user's end to understand how things work first.

WayneH said:

Based on threads I see on DSD+ you're getting people who have no familiarity with the protocols running the software and misinterpreting how things work. That's what I mean about it being wrong; it's the wrong way to go about it. If all someone does is deal with DSD+ then it's fine but in an effort to create a common, proper platform for disseminating information it doesn't work to display the data that way. It may make it easier to understand but that should be on the user's end to understand how things work first.

Click to expand...

All,

I'm inclined to say there isn't much we should do as far as database backend changes right now, or entering a certain special way in the database as it stands now.

Until a scanner comes out which will decode DMR trunking, we can&#8217;t be certain how it will accommodate DMR systems, and if we create a database backend to handle the data as generated by DSD and other programs of that ilk, we may find ourselves having to completely erase what&#8217;s been entered and start over.

At this point, keep putting it in the Wiki (make sure to note how the data was collected) until we have more to go on as far as a potential scanner format, if ever. DMR is an international standard, more or less, and uses the AMBE vocoder, so there is at least a sliver of hope. If a DMR-capable scanner is found to be a pipe dream once we get down the road a piece, we can review the options and go from there.

Hello,

It is more a data representation issue. Yes, we can make it easier on the DSD+ users now, but that just delays the confusion until later when someone comes out with a DMR trunker program or a DMR scanner is released, as Tom has mentioned.

Or the case where someone reads the frequency file from a former Connect Plus radio, a great find bought on eBay BTW, and submits data from the file using the Motorola repeater numbers.

The Wiki idea sounds good.

73 Eric