Trunked DMR Color Codes Missing

[DaveNF2G]

I notice that the Connect Plus and Capacity Plus MotoTRBO systems in the RRDB do not show Color Code data. This is a problem for users who want to program DMR radios to monitor these systems.

Even though transceivers used by ham operators cannot directly trunktrack these systems, they can still scan them in conventional mode. For most of these radios, however, the Color Code is required in order to receive any traffic.

 

[mciupa]

The DB Admin's could put those in the Miscellaneous System Information text area. This is in fact what I do.

Here is an example: CF Toronto Eaton Centre Trunking System, Toronto, Ontario - Scanner Frequencies

Perhaps their received submissions do not include that information.

 

[RayAir]

Even if they do show a color code for a cap+ or Con+ system sometimes the color codes are different on some or all repeaters. It's best to verify the CC for each frequency with DSD.

They need more space in the DB for some of these systems or a more detailed call out in the Wiki.

A local multi site Con+ uses a few different color codes on different freq's across multiple sites. These are 10 and 15 repeater sites so it would require more space in the database or an extra notation next to the freq if the CC is different.

 

[ka3jjz]

We already have such data in the wiki, stored by frequency - in fact we have dedicated templates for just such data

Mike

 

[DaveNF2G]

It's nice that such info is in the Wiki, but when I consult the RRDB for system information, I expect all relevant data to be there. Why should anyone have to conduct two separate searches for info on one system?

In my area, I have yet to see more than one CC per system. I wonder if some of the "multiple CCs" reports are based on poor decoding.

 

[ka3jjz]

That's entirely possible Dave.

I suspect that while it's certainly possible to put info like the color code (and slot, let's not forget that) into the database, I suspect that it would take a pretty large effort to modify all the forms for all the impacted entries, plus a good deal of reworking of the web service to use this data (Tom can address this better than I can). And let's not forget this little nugget - it would have to be done, not just for DMR trunks, but for conventional DMR as well (and yes, the wiki can also handle this condition with a different template). And that would take an entirely new form to handle, along with related web service changes. However, having said that....

Keep in mind that, at least as it stands now, no scanner can handle DMR out of the box, I have my doubts about having that happen any time soon. Heck, we should at the very least, post a warning to that effect (much as we do now for Phase 2 systems), and while it was agreed that it's a doable idea, I have serious doubts that anything will happen with that anytime soon, either.

Mike

 

[RayAir]

I've added about 150 unid Con+ TGIDs to the Wiki.
I'll see about completing a template for the larger Con+ sites near Detroit.

They do use different color codes on some site frequencies.
This was verified with a working set up of DSD+ 2.8 and using Hytera PD782's to passively monitor.

There's no standard for color codes on Cap+ either. All repeaters can use the same or not. I've seen it both ways. Again, no bad decodes b/c I'm using an XPR 7550 to identify traffic across these.

RRDB is a reference, not a blueprint.

Always verify the info yourself.

 

[Voyager]

Even if they do show a color code for a cap+ or Con+ system sometimes the color codes are different on some or all repeaters. It's best to verify the CC for each frequency with DSD.

Isn't that contrary to the basis for RR? If you have to verify CC based on non-listing, the same argument could be made for not listing the frequency. After all, it should be verified the same, shouldn't it? :roll:

 

[RayAir]

Isn't that contrary to the basis for RR? If you have to verify CC based on non-listing, the same argument could be made for not listing the frequency. After all, it should be verified the same, shouldn't it? :roll:

Sure

 

[jcardani]

In addition, in the event that a consumer scanner is released that will decode DMR, the color code information needs to be in RR since Sentinel and EZ Scan software relies on data in RR to program the scanners.

You would need, at a minimum, the frequency, channel number, and talk group information for trunked DMR and the frequency, slot number and talk group information for conventional DMR.

 

[DaveNF2G]

This thread seems to echo the debate in another thread about favoring particular models of scanner.

RRDB users look here for radio monitoring information to be used in whatever type of gear they have. The interface for particular models of scanner can ignore fields that those scanners cannot use. There is no real justification for omitting data that some users actually need from the DB.

 

[DaveNF2G]

Keep in mind that, at least as it stands now, no scanner can handle DMR out of the box, I have my doubts about having that happen any time soon. Heck, we should at the very least, post a warning to that effect (much as we do now for Phase 2 systems), and while it was agreed that it's a doable idea, I have serious doubts that anything will happen with that anytime soon, either.

Mike

There are no communications receivers that can handle CTCSS/DCS/NAC out of the box, either. The information is there because there are other types of receives that can use it.

I'm not even sure there are any that can decode P25, except for AOR's pricey DV-1.

 

[ka3jjz]

There's another point to consider, and one that deserves at least a little attention. There is a movement in the ham community toward digital mode repeaters. I think those hams that are on DMR are probably using refitted commercial gear, but the time will come when one of the manufacturers with come out with a DMR capable H/T and/or mobile (if there isn't one already). As the database can't handle color codes and other DMR related concepts yet, none of the software currently out on the market for programming ham radios will, either (both RT Systems and Chirp can access the RRDB, for example).

It's clear that with a little thought, one would realize that such changes would require a massive effort not just by Tom and his staff, but by the various software manufacturers - scanner, ham, etc. - that would seek to use it, assuming one day that a DMR radio for non-commercial (i.e. consumers, ham) use ever came out on the market.

To me, the database is, as an application, in danger of becoming limited and obsolete. It appears to be very inflexible and unable to adapt to new concepts and data without a major headache. And it being married to so many programming packages only increases the size of the headache. Without a plan to upgrade, it will become less and less useful as new trunk system designs - even those we haven't seen yet - come into play in the future. Mike

 

[ka3jjz]

Well would you look at this - AFAIK these are the first DMR capable ham radios -

Kirisun TP660V DMR HT, Kirisun TP660U

TYT MD-380 - Universal Radio

It's already begun, folks...Mike

 

[jcardani]

The Connect Systems CS750/CS751 has been out for a while also:

(It's a product under the Amateur Radio category)

Connect Systems

 

[Voyager]

Adding Color Codes for DMR, RAN codes for NXDN, and NAC codes for P25 is no different than the argument for CTCSS/CDCSS for analog frequencies. While not every scanner supports CTCSS/CDCSS, they are shown in the RR database. Same difference. There are currently no scanners that support Open Sky, but those systems are listed.

It might be a lot of work, but no more work than adding CTCSS/CDCSS was (Or P25 system types, or P25 Phase II, or X2).

One thing is certain - the longer you wait the more difficult the task will be. RR should just do it now and get it over with. (and not just for DMR, but for P25 and NXDN as well)

 

[ka3jjz]

I'm afraid that's not quite the whole story, at least where DMR is concerned. With a conventional DMR frequency, as I understand it, you can have a bunch of users - up to 2k, if memory serves me. Here is just one example from the wiki...

Iowa Dept of Human Service - the RR Wiki

This would require an entirely new form in the database, as well as the web service. I do agree, however, that something - even a plan to do it - should be done as soon as possible. The longer it's not done, the more difficult it will be.

I think at least some folks are putting the color code in the PL slot in the db. That's a start, but it needs to be consistently applied.

Mike

 

[mikey60]

I'm afraid that's not quite the whole story, at least where DMR is concerned. With a conventional DMR frequency, as I understand it, you can have a bunch of users - up to 2k, if memory serves me.

I would argue that with DMR, there really is no such thing a "Conventional DMR". Since DMR by definition uses Talkgroup IDs I would almost consider even a single frequency DMR system to be a trunked system. I understand that it operates like two separate repeaters, but you can still have multiple discrete users on each time slot and have them not hear each other.

Technically P25 conventional could be considered the same way, although I can't say I've seen it used that way..

To get back to the color code issue though. One example of a three frequency trunked Capacity Plus MOTOTrbo system that has a different color code for each frequency is the Detroit Zoological Society(Detroit Zoological Society Trunking System, Royal Oak, Michigan - Scanner Frequencies). I have the system programmed into my DMR radio and can scan it. It takes a bit of setup to do, but it works. Adding the color code for DMR trunking systems would have to get down to setting the color code at the frequency level on each site to be effective.

Mike

 

[ka3jjz]

I would argue that with DMR, there really is no such thing a "Conventional DMR". Since DMR by definition uses Talkgroup IDs I would almost consider even a single frequency DMR system to be a trunked system. I understand that it operates like two separate repeaters, but you can still have multiple discrete users on each time slot and have them not hear each other <snip>

No argument there, Mike - I use that term somewhat loosely simply because that's the way it is currently (perhaps incorrectly) represented in the db. I suppose you could make the case that a single freq DMR could be thought of like a SCAT system - however, the original point still stands. It would still require a new form, and mods to the web service to load properly.

I had mentioned ham radios that were DMR capable earlier - there is yet another class of radio that can handle DMR, and that's a SDR (with the right software).

It appears to me that while the statement that no out of the box scanner can handle DMR is completely true, there ARE radios that can - and as such, it seems that the more you think about it, the more it seems obvious that this data should be in the database right now, regardless of whether scanners can handle this data or not.

I pose this query to the database folks - are there any plans afoot to begin to upgrade the database to handle stuff like color codes, slots, etc? It seems the old tried and true answer that no scanners handle this is rather short-sighted, given that we know that ham radios and SDRs can, quite apart from any commercial radios that are also DMR capable.

Mike

 

[DaveNF2G]

DMR Tier II is not trunked. The talkgroup/slot concept is about who is using which of the two (and there are only two) time slices on the frequency. MotoTRBO is a proprietary form of DMR, which is an open standard.

DMR Tier III is trunked, mostly with Motorola's proprietary TRBO variants.

All tiers use color codes to distinguish sites and/or systems. DMR radios (commercial and ham oriented) require color code information to scan or search a system, even if no talkgroup information is known.

DMR is quite different from the analog and P25 that we are used to. CTCSS/DCS/NAC are optional. One can still monitor without that info. But DMR cannot be monitored without knowing the color code (unless you are using an SDR and software like DSDPlus).