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.
Updated by Mike Hughes over 2 years ago
Just curious - what does the "r" and "c" in rToneFreq and cToneFreq stand for?
Thanks!
Updated by Mike Hughes over 2 years ago
I think I answered my own question with a little more search-fu:
https://forums.radioreference.com/threads/ctonefreq-in-chirp.378575/
My mnemonic will be C=calling; R=receiving
Sorry for commenting on a closed ticket. Newbie mistake. I saw the green bar stating 80% done before I noticed this was closed.
Updated by Mike Hughes over 2 years ago
Felt like I need to correct this since I found a more definitive source "(chirp/wiki/DevelopersToneModes)":https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModes which reverses the above assumptions:
A cross_mode of "Tone->Tone" means the radio will transmit one sub-audible and will use another tone to open the receive squelch. The tone values are in Memory.rtone and Memory.ctone respectively.
So rToneFreq is the code added when transmitting, and cToneFreq is the tone which opens the receive squelch. So I'll play the Uno Reverse card on my previous mnemonic.
Updated by Jim Unroe over 2 years ago
- Chirp Version changed from 0.4.0 to daily
Mike Hughes wrote:
Felt like I need to correct this since I found a more definitive source "(chirp/wiki/DevelopersToneModes)":https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModes which reverses the above assumptions:
A cross_mode of "Tone->Tone" means the radio will transmit one sub-audible and will use another tone to open the receive squelch. The tone values are in Memory.rtone and Memory.ctone respectively.
So rToneFreq is the code added when transmitting, and cToneFreq is the tone which opens the receive squelch. So I'll play the Uno Reverse card on my previous mnemonic.
This is not exactly correct.
rToneFreq is used to hold the value for a CTCSS tone. cToneFreq is used to hold the value of a second CTCSS tone when a radio supports split tones.
If a radio does not support split tones ("has_ctone = False" in the Radio Features section of the CHIRP driver for the radio), the rToneFreq field would provide the CTCSS tone for both TX and RX since they must always be the same. The cToneFreq field would be ignored because it is unused.
When a radio does support split tones ("has_ctone = True" or "has_ctone" is not specified because True is the default), then the rToneFreq field would be used to provide the TX CTCSS tone value and the cToneFreq field would be used to provide the RX CTCSS tone value.
This is a feature request and/or bug tracking system, not a forum. If you have additional questions and wish to discuss this further, you should move it to the chirp_users mailing list or the chirp_devel mailing list.
Jim KC9HI