[chirp_devel] [PATCH] [UV-5G] Add support for Radioddity UV-5G/UV-5X

[Ian McBride]

I have recently purchased a pair of UV-5X radios and I must say I am rather
disappointed in the approach in CHIRP and the OEM for implementing the
programmed channels in the UV-5X.  Baofeng/Pofung seems to be waking up to
the idea that people want to be able to program channels above 30 with
their own custom channels within the GMRS frequency set.  The approach
being taken in the code is that 1-30 are locked to what have become the
customary GMRS channels.

I read in issue 9235 (https://chirp.danplanet.com/issues/9235) that the
reason this is so is because it is a GMRS radio and that the TX channels
are locked this way.  I think this is the wrong approach.  If you look at
Part 95, GMRS is frequency limited and power and bandwidth regulated based
on frequency but it is not regulated to what channel in a radio has a
particular frequency.  I think the licensee would be better served if the
channel's power limit, bandwidth limit, and TX frequency were driven by the
RX frequency being set rather than the channel being written.  I have been
able to program channels over 30 by hacking around the OEM programming
software and editing the XML directly then loading it.  My radio has 1-30
as the "standard channels" with no CTCSS and then 31-52 as a repeat of the
1-22 with a CTCSS code for my radios in my family set.  I have no need of
repeater channels 23-30 with custom tones but there are people who are
looking for this.

I think a different logic approach should be considered.  On memory write,
the software would follow logic like this:

HIGH_POWER_SIMPLEX_FREQUENCIES = [462.5625, 462.5875, 462.6125, 462.6375,
462.6625,
462.6875, 462.7125]
LOW_POWER_SIMPLEX_FREQUENCIES = [467.5625, 467.5875, 467.6125, 467.6375,
467.6625,
467.6875, 467.7125]
HIGH_POWER_REPEATER_FREQUENCIES = [462.5500, 462.5750, 462.6000, 462.6250,
462.6500,
462.6750, 462.7000, 462.7250]

if the radio is a GMRS radio

if freq in repeater_frequency set

// high power repeater capable channels

// allow none/off/+ duplex

if duplex == '-' then log error and set to off

if duplex == 'split' then log error and set to off

if duplex == '+' then set offset to 50000

allow high and low power

allow wideband and narrowband TX

else if freq in low_power_simplex_frequency set

// low power simplex channels

// allow none/off duplex

if duplex == '-' then log error and set to off

if duplex == '+' then log error and set to off
if duplex == 'split' then log error and set to off

allow only low power
allow only narrowband TX

else if freq in high_power_simplex_frequency set

// high power simplex channels

// allow none/off duplex

if duplex == '-' then log error and set to off

if duplex == '+' then log error and set to off
if duplex == 'split' then log error and set to off

allow high and low power

allow wideband and narrowband TX

else

duplex = off
offset = 0

end if

end if

This set of rules follows the FCC regulations for GMRS in Part 95.  It
would make the radios infinitely more flexible than with what is in there
now.  This approach has the interests of the user at heart while
maintaining compliance.

I'd like to get some feedback on this before I open an issue and attempt to
implement this.  I think this would be a great issue to work on in CHIRP to
get some exposure to this type of application.  I'm a corporate application
developer by trade so we don't see a whole lot of GTK+ front ends
interfacing with python so it has my interest.  I also have the radio to
test it on.

Thank you for any consideration.

Ian McBride
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20210812/bfe580e0/attachment-0001.html