[chirp_devel] New TH-UV8000 Driver

[Dan Smith]

(re-adding the list which got dropped)

> On Jul 3, 2019, at 11:21 AM, Jim Unroe <rock.unroe at gmail.com> wrote:
> 
> On Wed, Jul 3, 2019 at 10:22 AM Dan Smith <dsmith at danplanet.com> wrote:
>> 
>> (Jim, question for you below)
> 
> OK
> 
>>> +    def _get_fm_memory(self, mem, _mem):
>>> +        mem.name = "----"
>>> +        rx = self._memobj.fm_stations[mem.number + 2].rxfreq
>>> +        if rx == 0xFFFF:
>>> +            mem.empty = True
>>> +            return mem
>>> +        else:
>>> +            mem.freq = (float(int(rx)) / 40) * 1000000
>>> +            mem.empty = False
>>> +
>>> +        mem.offset = 0.0
>>> +        mem.power = 0
>>> +        mem.duplex = "off"      # inhibits tx
>>> +        mem.mode = self.MODES[1]
>>> +        dtcs_pol = ["N", "N"]
>>> +        mem.ctone = 88.5
>>> +        mem.rtone = 88.5
>>> +        mem.tmode = ""
>>> +        mem.cross_mode = "Tone->Tone"
>>> +        mem.skip = ""
>>> +        mem.comment = ""
>>> +        return mem
>> 
>> I'm not really sure how I feel about this. I think the other radios that support editing the (broadcast) FM presets do so via RadioSetting values instead of calling them channels. Doing this makes editing them a little more like regular channels, but they include a bunch of other gorp (like tones) that will never apply, and they involve the usual band checking for the radio which defeats the ability of the memory editor UI being able to range check things properly.
>> 
>> Jim, any opinions here? For consistency I'd tend to lean towards just putting these into RadioSettings to be consistent with the other radios.
>> 
> 
> I think using RadioSetting values is the right way to do (broadcast) FM presets.
> 
> Jim KC9HI

I agree. Rick ^^.

--Dan