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