Storing Mototrbo information

[ka3jjz]

As we now have roughly 2 dozen trunking articles that have to do with Mototrbo (you can see this by looking at how many articles link to the DMRTracker template), I think it's time we consider how to more accurately display this information.

The first question has to do with color codes. There are some systems that seem to only use 1 color code, others have 1 assigned for each frequency. I think we need to figure out some way of displaying these multiple color codes better than just listing them in the infobox. Without the frequency reference, it's a little misleading.

There is an EDACS/LTR template (ELTRfreqs) that we have already that might be recoded for this purpose, but it's kinda wide - we'd run right into the infobox. Perhaps limiting down to 4 frequencies per row for 8 rows (32 physical freqs, but as I understand it, actually 64 logical freqs since there are 2 slots per frequency).would work.

The other one is talkgroups. Now I'll be the first to admit that I don't fully understand TRBO trunking, but just showing the talkgroups is, I suspect, somewhat inaccurate. If we could get a better handle on this, we might be able to design something that displays TRBO talkgroups more accurately.

Thoughts? Mike

 

[wa8pyr]

As we now have roughly 2 dozen trunking articles that have to do with Mototrbo (you can see this by looking at how many articles link to the DMRTracker template), I think it's time we consider how to more accurately display this information.

The first question has to do with color codes. There are some systems that seem to only use 1 color code, others have 1 assigned for each frequency. I think we need to figure out some way of displaying these multiple color codes better than just listing them in the infobox. Without the frequency reference, it's a little misleading.

There is an EDACS/LTR template (ELTRfreqs) that we have already that might be recoded for this purpose, but it's kinda wide - we'd run right into the infobox. Perhaps limiting down to 4 frequencies per row for 8 rows (32 physical freqs, but as I understand it, actually 64 logical freqs since there are 2 slots per frequency).would work.

The other one is talkgroups. Now I'll be the first to admit that I don't fully understand TRBO trunking, but just showing the talkgroups is, I suspect, somewhat inaccurate. If we could get a better handle on this, we might be able to design something that displays TRBO talkgroups more accurately.

Thoughts? Mike

Mike,

I've been mulling this over, and I think if we go with a frequency section followed by a talkgroups section we should be in good shape.

Fields for the frequency section:

Channel
Color code
Slot
Frequency

Fields for the frequency section:

Talkgroup
User

Since there isn't really a defined way for scanners to handle this, only software like DSD+ and possible future developments along that line, I think the above would keep it generic enough but still provide enough info to be moved to the database should a more permanent monitoring option with defined requirements come along.

 

[ka3jjz]

OK I put together a template that generates a table - here's the test article

Walter E. Washington Convention Center (DC) DMR Bandplan - The RadioReference Wiki

It's a bit clumsy but certainly better than doing the actual table coding every time.

There are 8 or 9 other articles that could stand this to be done - the others seem to have only a single color code, and unless we can get slot information, I kinda doubt the template would be very useful right now for them.

Since there's a max of 32 physical frequencies, in a multi site situation, I'd probably make 1 page per site, then list each site on the trunk system's home page. If there are 3 or 4 sites to the system, it would get unwieldy rather quickly.

Do we need to repeat the warning about scanners not being able to copy this system out of the box? I'd imagine so - this page, like any others, could be found in a Google search without every going through either the wiki or database to access it...

Comments solicited...Mike

 

[AK9R]

Good work, Mike.

Yes on the warning.

 

[DaveNF2G]

Let's not lose sight of the fact that a single-repeater TRBO system looks just like a trunked system but with only one frequency pair.

In fact, I'm not even sure that the expression "MotoTRBO Trunking" is accurate enough. So far, the trunked systems I have seen have been Capacity Plus. Conventional systems are either "plain" TRBO (DMR) or Connect Plus.

 

[com501]

Connect Plus is definitely trunked, it fits the definition of trunked more so than CapPlus does, as it has a control channel. ConnectPlus systems can have more than 100 sites. Trunking 'type' can be connect plus (control channel) or capacity plus (no control channel).

IP site connect looks to the end user like conventional, just very WIDE area conventional. (some systems cover several countries) DMR-MARC anyone? So really, FOUR types of Trbo.

I think your sheet is a good start. I can't think of anything else to add from a hobbyist standpoint, you have captured the essence of necessary knowledge for someone to monitor the system. The comments section will capture other info such as (encrypted), (control channel), (data only), etc.

At some point (as with my system) you will run into more than 16 potential channels, as I am running 16 voice paths and 10 data paths. Not sure how you want to handle that type of info.

Nice job!

 

[ka3jjz]

There's room in the template for a full 32 (physical) channel display, so unless MotoTRBO systems can run more than 32 freqs per site, it should be good to go. It can be expanded if needed

Mike

 

[wa8pyr]

Good work, Mike.

Yes on the warning.

Ditto!

 

[bc780l]

DMR Channel Info

To comprehensively identify all receive requirements which might be needed on future radios, we need:
- Color Code
- Time Slot
- Group ID (which is missing in your template)

DMR Decode does provide all three. It would be good to add the Group ID to the database.

No one knows when a scanner will come out to handle DMR, but for those using existing DMR radios for scanning, all three are needed IF one wishes full differentiation of the options. (Which perhaps leads to another "warning" that if one is using a transmit-capble radio, all channels must have the transmit inhibited!!!). For example a Connect Systems CSI-700 works great as a scanner and is priced right! Soon (January 2015+) they'll have a multi-mode radio (analog, P25, DMR, dPMR, NXDN, DStar, Fusion) which is mentioned on their web site at connectsystems dot com.

Good work on proactive planning.

 

[bc780l]

On review of my note, "Talk Groups" were mentioned, so I assume you're referring to the "Group ID" as DMR refers to them, so it's covered with a separate list, unless you're in a single channel-pair system with only one Group ID (which is actually the case on many non-networked DMR systems). So would you want a separate list for that or include it on the same line, and then provide the list of multiple Group IDs?

 

[DaveNF2G]

Yes, I believe Talk Group = Group ID. Some of the decoding software evidently does not follow the DMR specs exactly, so we end up with nomenclature issues.

 

[ka3jjz]

There's room in the template for a full 32 (physical) channel display, so unless MotoTRBO systems can run more than 32 freqs per site, it should be good to go. It can be expanded if needed

Mike

Ooops, I forgot that each channel can have 2 slots - so I'm going to have to have 64 entries in the template to accomodate all 32 physical freqs.

Not a big deal - lots of copy/paste....Mike

 

[ka3jjz]

I've coded a standardized template called 'TRBOSYS', and have been slowly integrating it into the wiki for documenting DMR systems.

It does a pretty fair job of laying out slots, color codes, frequencies and so on, and there's a section for comments - which could be used to document whether that frequency / slot was using encryption, for example. Frankly I should have coded it to repeat the frequency across both slots (drat!) but that's what copy / paste is for.

You can see an example of the coding here - it's not as hard as folks make it out to be - it's a little tedious, but with a little careful attention, it seems to work pretty well...

Fisher Wireless Teamtalk Connect (Southern CA) Mt Oso DMR Bandplan - The RadioReference Wiki

You will notice that some frequencies are red / blue just like the database. It's not real accurate, of course, since you can't tell which slot the data was being heard on, so as a default I put it on both. It's easy enough to remove the coloring once it's learned which slot is involved.

I'm on the last system - but it has several sites yet to be documented. Almost there....Mike

 

[bc780l]

Group ID?

I don't see Group IDs listed. Wouldn't we wish to track those? Even in non-trunking systems, Group IDs are required components.

 

[ka3jjz]

Trbosys is designed just to address storing the freq/color code/slot and user information for DMR trunks only. The group IDs - if they are unknown - are all kept on separate articles.

For example...

Maryland Live! Casino - The RadioReference Wiki

There are 2 articles linked there - one for the unknown talkgroups (group IDs), the other for the bandplan. This is so they can develop seperately

AFAIK we don't have anything in the wiki - yet - to track conventional DMR frequencies. If something shows up, something can be developed for them.

As far as I understand it, group IDs on DMR trunks can jump around both by frequency and/or slot- much as a standard Moto talkgroup jumps from freq to freq. So documenting group IDs in this manner wouldn't be worth much.

Mike

 

[bc780l]

Yes, listing trunking talk groups as you say is fine, but talk groups are also used on conventional systems, too. Usually they're the same talk group for everyone on a conventional system, but not always. Similar to the default talk group "1" on P25 systems, but there's no default on DMR conventional, with some real oddballs that I've seen so far. Further, different talk groups can be used in routing/linking between conventional systems.

 

[ka3jjz]

It would be interesting to have such information documented in the wiki, but so far, AFAIK, no one has attempted to document this.

If you have such info, please feel free to present it. We might be able to develop a template (or something similar) to standardize documenting this, just as is being done for documenting DMR trunks.....Mike

 

[bc780l]

True--no one has apparently attempted to document group ids. Why? So far no real need since DMRdecode, DSD+, etc., don't need the ids--but those software packages report the group ids. Who knows if future scanners (they will come) will require them--P25 scanners don't require (or even have capability) of decoding P25 group ids in conventional/non-trunking, so why will they in DMR? Will still clearly need to know CC and TS. And of course, if you're programming a real radio as more folks are for DMR, hopefully with transmit inhibited as appropriate!, CC, TS, and GID are needed. It's really no different than showing CTCSS 127.2 or DTS D753N or NAC 157 or RAN 14 as is used today in the database.

I question putting CC, TS, and GID in Wiki vs. simply listing in the regular frequency listings. Simple display with existing fields would suffice, i.e., in the conventional Tone column, already used for CTCSS, DTSS, NAC, and RAN, use a standardized format, e.g., "CC5/TS2/G8088" (representing Color Code 5, Time Slot 2, Group ID 8088). You will have multiple listings for the same frequency, depending on what's being used, but it's clear and concise. For trunking, we already have Group, and comments in the control channel blocks can identify CC/TS as needed. This might, however, become problematic whenever/if ever new scanners come out and automated download for programming will expect unique fields. In that case, modify the database to have the required new fields (when that time comes, or standardize now so programs can adapt later ...).

The only quick example I can provide now for multiple talk groups for routing on conventional channels is what's provided by DMR-MARC in their talk group database used for world-wide amateur talk group standards at DMR-MARC Network My commercial examples are much more simple, but are addressed as above, all of which could be listed in the database as most conventional and trunking systems are today without extra effort, I'd think.

Sample Conventional System
155.5555 E c5/t2/g8088 West Link DMR
155.5555 E c5/t2/g9099 East Link DMR
155.5555 D c5/t2/g1 All Call DMR

Just comments from the peanut gallery ... no need for Wiki if it can be succinctly displayed normally.

 

[ka3jjz]

Ah but the question is 'displayed where?'. Currently the database can't handle displaying the slots per frequency, and should the color code vary for each frequency in the system (I know, some say it's not supposed to, but that's what the database has, in some cases), it can't display that, either.

And more to the point, since no scanner can currently handle TRBO, putting it in the database is a moot point - even if professionals use it for programming (they do), the web service is currently unable to handle the additional requirements.

The wiki remains the only option. If / When scanners get this capability, they don't necessarily need the web service to program it. Many packages have a copy / paste utility that would do the job, at least until the web service is modified - and that's not going to be a small job. Mike