Question: CPS 2024.01.22.01 and programming for Talk Groups

[vk3vm]

Hi Folks,

I have been away from The GD-77 for a little while and OpenGD77 work ... But now have the time to look at it again - so please excuse me if things have changed and this is effectively a deprecated question !

This was the way that I believed that a Repeater Talk Group had to be Programmed in:

• Digital Contact: Create one of these for your Talk Group" (i.e. 505) as a Group Call

• TG Lists: Ideally create a TG List (I.e. TG 505 VK) That contains your "Group Call Digital Contact" i.e. Contains the "Digital Contact" 505 created in the first step

• Channel: Program in a channel (i.e. say repeater Tx on 439.900 and Listens on 434.900, Digital, TS2, With TG List assigned to the one you created in the previous step (i.e. "TG 505 VK") and Contact Assigned to The Group Call contact (i.e. 505 - Group) that you created in the first step

• Zone: Assign the channel to an appropriate zone (not discussed further here as irrelevant to the immediate discussion).

I have noted that with the latest CPS that assignment of Digital Contact and TG List to Channel are now MUTUALLY EXCLUSIVE !

This I can foresee creating issues with resources such as the "Parrot" on 9990 that can require a group call (or sometimes a private call) with a response on TG 9.

Have I missed something here in all the recent advances?

Thanks and 73

Steve I
VK3VM/VK3SIR

[G4EML]

Contact and TG List are mutually exclusive on a channel.
You either define a contact and that is what will always be used when making a call. Or you define a TG List which allows you to select the contact to be used from the list.
Unlike most DMR radios the TG List is used for both Tx and Rx.
This is probably the main feature that OpenGD77 has over other radios. It allows you to just define one channel for each repeater with a list of all commonly used talk groups. There is no longer any need to create a channel for each talkgroup.

By default the radio will receive any incoming talkgroup so you will always hear a reply.

Colin G4EML

[vk3vm]

Colin,

Thanks for the reply.

> By default the radio will receive any incoming talk-group so you will always hear a reply.

I had observed this and I highly appreciate the confirmation.

I reserve my judgement on whether I think this is a good practise. I can foresee that this change in approach - deviating heavily from "Moto-based" practise - could potentially introduce greater misunderstanding in the DMR world.

I will be watching progress closely.

73

Steve I
VK3VM/VK3SIR

[VK3KYY]

Colin,

Thanks for the reply.

> By default the radio will receive any incoming talk-group so you will always hear a reply.

I had observed this and I highly appreciate the confirmation.

I reserve my judgement on whether I think this is a good practise. I can foresee that this change in approach - deviating heavily from "Moto-based" practise - could potentially introduce greater misunderstanding in the DMR world.

I will be watching progress closely.

73

Steve I
VK3VM/VK3SIR

This is not new

The OpenGD77 firmware and CPS has used this TG method for at least 3 years

VK2FLY who is one of the VK DMR network admins told me that he thinks a large number of operators on the VK DMR network use OpenGD77

[vk3vm]

Roger,

It is good to make contact again (and hope to catch up in person soon ... I think that a good coffee is long overdue).

I have not programmed a GD-77 radio from scratch nor had to make mods for a while - which is possibly why I have not noted this.

With the GD-77''s here (and the GD-77S) I have been just able to drop in new firmware with pre-existing code plugs just working - until the last iteration.

[ The GD-77S has been somewhat of a mess for a while as the CPS appears to no longer offer modification of key parameters ]

Great work as always Roger. Matt VK2FLY is completely on the ball !!!

Yet there is still this niggle in the back of my mind that that further discussion is needed regarding mutual exclusivity between "old ways" (i.e. Separate Public User ID with matching receive group) and the way that things are done now (stacking on to the Received Group).

I hope that I make sense !

73

Steve I
VK3VM/VK3SIR

[VK3KYY]

Yet there is still this niggle in the back of my mind that that further discussion is needed regarding mutual exclusivity between "old ways" (i.e. Separate Public User ID with matching receive group) and the way that things are done now (stacking on to the Received Group).

I hope that I make sense !

73

Steve I
VK3VM/VK3SIR

If you sent the DMR Filter to TG, you will only receive signals on the TG you have selected for Tx, which AFIK is pretty much the same as normal radios, except that you don't need to make multiple Rx Group lists each with one TG in them.

The TG filter setting will be saved and survive a reboot etc.

Re: GD-77S

Its been a very long time since we tried to get any of these radios working perfectly using the official GD-77 codeplug, especially all the radios still in production don't use the GD-77 codeplug when running the manufacturer's firmware.

So the installation instructions are now to either use a codeplug from another OpenGD77 radio, or make a new OpenGD77 codeplug from scratch.

[vk3vm]

Hi Folks,

I am returning to this again after having to work through the issue of "How come I am hearing Talk Group 91 when I am on Talk Group 505" (or similar) frequently with many-many Amateurs over the last few months.

[ The solution is always to go BACK to Single Talk Group, a single contact MATCHING the Talkgroup as a TG List, and then with a single TG List assigned to a channel. ]

Again yes I know the Quick Menu (the Red button on the GD-77 near the antenna) and then the DMR Filter option changed to TG fixes most matters with constructing codeplugs as described.

On that front (and as an observation gleaned through personally helping many through issues behind the scenes), perhaps OpenGD77 is now mature enough to reconsider returning "settings" capabilities to the CPS?

Yet what is also clear is that OpenGD77-developer-imprimatured guide documentation and primers are very much required (and that I and others around here can help with).

I see so many "newbies" guided into "Single Channel" codeplugs out there with basically everything stacked into a single channel...

If it comes from and is worked-with through "official sources" - like the developers here, with their simplistic recommendations and with their imprimatur - then there is a greater chance of better practises that are easier to comprehend filtering through our community.

These are observations and suggestions.

73

Steve I
VK3VM/VK3SIR

[ZL2MGS]

"I see so many "newbies" guided into "Single Channel" codeplugs out there with basically everything stacked into a single channel... "

I would hazard a guess that for most of us this (many TGs on a single channel) is a major reason for installing OpenGD77 - if it wasn't for this there certainly would be significantly less reasons for myself to prefer it over the factory firmware. Why would anyone want to create and manage a separate channel and TG List for each TG a repeater carries, when they could create a single channel for the repeater and then just add TGs (contacts) to a single TG List as required? I have somewhere close to 20 repeaters in one single owner network, all carrying the same TGs and therefor all using the same TG List - if the admin of that network wants to change a particular TG (eg., move it to the other TS) or add/delete a TG I've only got to change a single contact and/or TG List and the job's done on my radio for the entire country. If a new repeater joins that network, I've only got to add one channel and point it to the existing TG List - it couldn't be easier.

OpenGD77 is a very powerful tool that significantly improves the radios it is compatible with in terms of ham usage but, as with any powerful tool, it requires careful reading of the instruction manual and the support forums to gain the most benefit from it. I personally would not like to see settings taken back into the CPS - with OpenGD77 installed my TYT UV390 has become pretty much the perfect DMR compliment to my FT-817 (within the HT's hardware limitations) and any move to take settings back from the radio to the CPS would be giant leap backwards.

[vk3vm]

Hi ZL2MGS (and I would use your first name if I could easily locate it),

All good and fair comments - Yet there are a few things that I must add or elaborate on:

Stacking EVERYTHING ongto a single channel defeats the purpose and intent of DMR and similar systems including D-Star and Fusion; Digital systems as employed by and available to AR Operators have the capability to be seperated into different "pipelines" (which we term "Talk Groups"). Instead of One Channel, One topic it can be one channel and 64K-odd topics to select from

I note that most DMR-BM talk groups beyond 91 and XLX links can be rather quiet ... Yet on D-Star and Fusion many more "Talkgroups" are constantly and consistently carrying traffic

Then there is the potential of the issue of discrimination between and identifying which talk group is actually active (and this is an issue that I see often). On PiStar and WSPD systems most hotspots are configured in rather basic ways so that you effectively lock the units into a talk group (i.e. Kerchunk the device to set the TG until it times out) ... Yet things are much more complicated when one has actually configured hotspots to auto-respond to multiple talkgroup triggers ...

It can be considerably more complex when using real hardware and multi-repeater clusters (which are beyond Amateur application).

Issues such as which TG are you actually respoding on can arise, Are you responding on the right TG? .... That is a considerable issue with "Stacking".

As for programming from the front panel and the request to re-integrate KEY management functions (i.e Quick Menu if not all functions) ... I forgot to add that many people that I also assist are visually impared.

Many of us are also getting older and akready need multiple pairs of specs for various tasks

Look its a comment that I perhaps hear the most ... "Why can't I set function whatever from within the CPS"? I am doing the developers a disservice if I do not feed this back !

What I also see as a VERY experienced Licence Assessor is new HAMs head straight for the DMR and digital radios - without adequate training in the complexities. Providing any facility that makes life easier and functions easier to find assists the community

Likewise, what are the developer/maintainers intended ways of developing codeplugs? Everyone says "go learn by yourself". This has also led to a huge amount of chaos out there (and not necessarily associated with this project) that some of us have to try to fix. I agree that just supplying codeplugs is not the best strategy (as around 95% that I have come across can be considered abysmal and realistically not fit for purpose).

Having recommended and imprimatured models from the development team perhaps is perhaps a much healther development strategy for all of us .

73

Steve I
VK3VM/VK3SIR