Conventional P25 hotfix

[taclane]

Recent DMR changes have allowed for dynamic conventional talkgroup assignments based on over-the-air group IDs. While this may presently work for DMR, conventional p25 is not configured to manage this though the channelfile.csv as OTA talkgroups for simplex systems are often left as the default TG 1.

This leaves the bulk of recent DMR changes undisturbed, and allows conventional p25 to return to the previous behavior where "virtual" talkgroups are arbitrarily assigned via channel frequency. While it may be possible to use OTA p25 conventional talkgroups in some meaningful way in the future, t-r is not presently configured to do so.

Several log messages have also been demoted to the debug level to minimize clutter.

This should directly address #1061

[ZeroChaos-]

Why intentionally override the metadata in the packets? Even on conventional you can have multiple talk groups and certainly care about the difference between security and maintenance talk groups.

[taclane]

Why intentionally override the metadata in the packets? Even on conventional you can have multiple talk groups and certainly care about the difference between security and maintenance talk groups.

With conventional P25, the frequency typically is "the talkgroup". Remapping p25 by channel is the only effective way to manage a system like:

Freq.	Name	Type	TG
451.500	PD Dispatch	P25	1
452.000	PD OPS	P25	1
452.250	Fire	P25	1
453.375	EMS	P25	1

While it may be possible that the channelfile.csv system can be improved to better accommodate a typical situation like the above, there is no available workaround when all the channels in a conventional p25 system report back as the default TG 1.

[robotastic]

Ah! I didn't realize that Conventional P25 didn't really make use of the talkgroup ID and went by frequency/channel instead. Thanks for fixing this.

[taclane]

Ah! I didn't realize that Conventional P25 didn't really make use of the talkgroup ID and went by frequency/channel instead. Thanks for fixing this.

It can, but often does not in fielded systems. A huge chunk of conventional p25 are "digitized" analog systems where the thing that discriminates traffic is the frequency in use.

Some of this is even further codified in publications like the NIFOG, where conventional p25 channels must be left on TG 1. There is no practical way to monitor something like that by TG alone when you have a few dozen frequencies all reporting as the default value.

Single channel p25 systems with multiple talkgroups do exist, but they wouldn't be well-served by the present channelfile.csv implementation. We'd need a better hybrid approach to support that in future.