Bug #9349
closedToneSql/ cToneFreq not importing into radio .img file.
0%
Description
When I import a csv into a radio image the ToneeSql field is not imported.
I can import successfully into a new file which is set as .csv by CHIRP, but then I can't upload that to the radio
Files
Updated by Jim Unroe over 2 years ago
- Status changed from New to Feedback
Hi Niamh,
CHIRP, as provided by your example CSV file, is working as expected and as designed.
1,GB3AP,145.6125,-,0.6,Tone,94.8,94.8,23,NN,NFM,5,,,,,, 2,GB3AR,145.7,-,0.6,Tone,110.9,110.9,23,NN,NFM,5,,,,,,
When Tone Mode is set to Tone (as shown above), only the Tone column (rToneFreq in the CSV file) is used. Any value in the ToneSql field (cToneFreq in the CSV file) is ignored. If the Hide Unused Fields setting of CHIRP is enabled (the default for new CHIRP installations), the ToneSql field will be blank. The radio will use the CTCSS tone from the Tone column as the TX CTCSS tone. Carrier squelch will be used for RX.
1,GB3AP,145.6125,-,0.6,TSQL,94.8,94.8,23,NN,NFM,5,,,,,, 2,GB3AR,145.7,-,0.6,TSQL,88.5,110.9,23,NN,NFM,5,,,,,,
If you want a value in the ToneSql column, then you must set the Tone Mode to TSQL (Tone in the CSV file) as shown above. You can populate the rToneFreq field in the CSV file with the default 88.5 or the same value as the cToneFreq field. It doesn't matter either way. The radio will use the CTCSS tone from the ToneSql column (cToneFreq in the CSV file) for both the TX and RX CTCSS tone. CHIRP will ignore the value in the Tone column (rToneFreq in the CSV file) and the Tone field will be blank if the Hide Unused Fields setting is enabled.
For more details about how the CHIRP columns are used and selective squelch columns affect one another, take a look at these reference guides.
"CHIRP Programming Reference":http://kc9hi.dyndns.org/uv5r/programming/CHIRP%20Guide.pdf
"Understanding CHIRP's columns":https://chirp.danplanet.com/projects/chirp/wiki/MemoryEditorColumns
Jim KC9HI
Updated by Bernhard Hailer about 2 years ago
- Status changed from Feedback to Closed
- Target version deleted (
chirp-legacy) - Model affected changed from (All models) to CSV
- Platform changed from Windows to All
Answer provided
Updated by Rob Bailey over 1 year ago
Can you reconsider this design decision?
The Kenwood TM-D710, for example, is able to store separate Encode and Decode tones (even if they're the same), and even if a channel's tone mode is encode only ("Tone") rather than encode/decode ("TSQL"). This is a VERY useful feature, because it allows me to store a channel as "Tone" with the appropriate tone(s) in the encode and decode tones. In that mode, the radio will only encode the encode tone. But then if there is interference, I can change the radio over to "TSQL" by pressing a button, and the radio will encode the encode tone and decode the decode tone.
Currently, however, CHIRP prevents using this feature because if a channel is "Tone", CHIRP ignores the decode tone --- that is, it doesn't send it to the radio and in fact it doesn't even store it "correctly".
Perhaps a way to restate this is that in that radio, at least, there are no "unused" fields when it comes to the encode and decode tones. They're always available to use if you switch the radio from Tone to TSQL on the fly.
Just my 2ยข.
Thanks!