Feature #1577
closed[csv] Friendlier defaults for missing cToneFreq/rToneFreq columns in csv import
80%
Description
Currently if an imported csv file doesn't have a column for rToneFreq or cToneFreq, Chirp provides a default of 88.5 Hz. If one of these columns is present, it seems like a better choice, in the sense of capturing the user's intention, would be to use the value that is supplied for both rTone and cTone.
A specific problem that this would fix is the case of a TSquelch tone mode when only rTone is supplied. In the current code, the missing cTone defaults to 88.5 Hz. Then, if the target radio doesn't support separate cTone/rTone properties for a memory channel, the function _import_tone() in import_logic.py will set rTone to cTone, without concern that the rTone is a user supplied value and the cTone is a default constant 88.5 Hz. This is a fallout of the fact that the pseudo-radio instantiated for the csv import is defined as having separate rTone/cTone, and this must be coalesced into one value for the target radio.
In general, 88.5 is a legal value that serves to prevent variable bounds problems when a value isn't supplied, but using the tone frequency that is supplied for a channel for the missing tone frequency is more likely to be what the user intended.
Specifically: check for the existence of csv headings "rToneFreq" and "cToneFreq" in the header line. If exactly one is present, use the value in that column for both rTone and cTone for each channel imported.