[chirp_devel] Proposal to make use of TSQL in csv import friendlier

[chirp.cordless at xoxy.net]

Hi,

I recently tried creating a TSQL channel for a couple of the local repeaters
I was told transmit the PL tone. My spreadsheet only has the rToneFreq
column. It ended up with a PL tone of 88.5.

I don't need an explanation, I've found the documentation of this
behavior in http://chirp.danplanet.com/projects/chirp/wiki/MemoryEditorColumns
although I note that my FT-60, defined as "rf.has_ctone = False",
doesn't have a ToneSql column in the editor.
But it looks like I could add a cToneFreq column to my spreadsheet
and get this working.

And I see where the input rtone value is overwritten with the default ctone
value in import_logic.py, because the FT-60 doesn't have a cTone and
the csv pseudo-radio does. I understand the general case, and
don't want or need to break it.

But I'd like to propose a very specific change to csv import, such
that if exactly one of the columns rToneFreq and cToneFreq exists
in the csv file, that the value in that column be used for both rtone
and ctone. This solves the TSQL problem without requiring another
essentially informationless column in the spreadsheet. It also generally
mirrors the behavior in other cases where one is used for the other
if only one is provided or exists.

I can see a couple of approaches. I'll be happy to open the bug and
submit the patch, but I wanted to see how the direction and specific
approach would be accepted. I'm adding a _clean_tmode
method to the generic CSVRadio class in generic_csv.py

===============
   def _clean_tmode(self, headers, line, mem):
       # If there is only one of [ rToneFreq, cToneFreq ] columns in the
       # csv file, use it for both rtone & ctone. Makes TSQL use friendlier.
       _file_has_rTone = 0
       _file_has_cTone = 0
       for header in headers:
           if header == "rToneFreq":
               _file_has_rTone = 1
           elif header == "cToneFreq":
               _file_has_cTone = 1
       if _file_has_rTone and not _file_has_cTone:
           mem.ctone = mem.rtone
       elif _file_has_cTone and not _file_has_rTone:
           mem.rtone = mem.ctone

       return mem
=============================
The requirement that one of them exists should avoid problems
with a child class that doesn't supply a _clean_tmode()
and inherits this one - I think.

I understand that it's possible somebody that has a radio that
supports Tone->Tone doesn't realize they need two columns, but
with the current code they won't get what they want either.  It's
more likely that someone who just wants TSQL and provides the
tone ends up with 88.5 instead.

Shall I move forward with this?

-dan