Tom,

Thanks for the agreement on the direction, and I'll be happy to implement any way that makes sense.

The import_logic function _import_tone() isn't setting rtone to 88.5, it's setting it it to ctone, which csv import set to 88.5 because there isn't any such column in the csv, and then because the CSV pseudo radio is defined as having both rtone and ctone: # If copying from a radio with separate rtone/ctone to a radio # without, and the tmode is TSQL, then use the ctone value

I figured that's there for the case of real radios with separate rtone/ctone and don't want to break that. I considered having the csv import logic do the same check for a "cToneFreq" column I did in my suggested patch, and then if not present, set rf.has_ctone = False in the CSV pseudo-radio's features.

But I thought the symmetric "if there's only one of [ rtoneFreq, cToneFreq ] use it for both" approach would cover a multitude of user confusion. As you said, if one tone value is supplied, it's likely to be a better default for the other than 88.5.

If you still want it in import_logic, outline an approach that doesn't break the general case and I'll get to work on it.

-dan

On Apr 23, 2014, at 11:11 PM, Tom Hayward - esarfl@gmail.com wrote:

On Apr 22, 2014 12:49 PM, chirp.cordless@xoxy.net wrote:

...

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.

Makes sense to me. The rTone value is a much more useful default than 88.5.

This could probably be done in import logic, not CSV.

Tom KD7LXL