CHIRP

The plot thickens. I thought that I had the solution by turning off "Smart Tone Modes". Nope.
Then, I discovered another problem. If I have the "Tone Mode" set to "Tone", it doesn't matter what I have saved for a "Tone Sq" frequency, it always writes 88.5Hz to the radio. Double checking, I open the IMG file and find all the various "Tone Sq" frequencies are present and properly configured. But when I download from the radio, it displays only 88.5Hz for channels with "Tone Mode" set to "Tone". I went back to CHIRP daily-20160830 and it does the same thing.

Hi Jeff,

CHIRP tries to help you by setting the Tone Mode and Cross Mode columns based on the Tone/ToneSql and/or DTCS Code/DTCS RX Code selections that you have made. If you don't like this behavior, then select View in the menu bar and disable "Smart Tone Modes".

When the Tone, ToneSql, DTCS Code and DTCS Rx Code columns are unused, they display default values (88.5 for CTCSS and 023 for DTCS). These values are ignored by CHIRP when the setting is unused. If you don't want to see these unused values, then click View in the menu bar and enable "Hide Unused Fields" (which should be the default for new CHIRP installations). When enabled, a cell is blank when it is not used based on the current Tone Mode and Cross Mode column settings.

When Tone Mode is set to Tone, only the Tone column is used (TX only). The ToneSql column is ignored.
When Tone Mode is set to TSQL, only the ToneSql column is used (TX and RX). The Tone column is ignored.

The "CHIRP Guides, Examples & Spreadsheets":http://www.miklor.com/COM/UV_CHIRP.php#guides of the Miklor website has links to some references for the columns of the CHIRP spreadsheet style memory editor (one is hosted here on the CHIRP website). They may help you to understand how the columns relate to one another.

Jim KC9HI

Sigh. The deeper I dig, the worse things get.

I setup about 100 channels for "Tone Mode" set to "Tone" and plugged in the required tone frequencies. I saved the file and everything looked good. I then made some minor changes to the "Settings". When I went back to the "Memories" page, all my receive tone frequencies had been changed back to 88.5Hz. I tried it independently on two different machines, with CHIRP daily-20160830 and CHIRP daily-20160926. Both did the same thing and about 3 hrs down the drain.

CHIRP tries to help you by setting the Tone Mode and Cross Mode columns based on the Tone/ToneSql and/or DTCS Code/DTCS RX Code selections that you have made. If you don't like this behavior, then select View in the menu bar and disable "Smart Tone Modes".

Thanks for the prompt reply. Yes, I found that setting and realized that it might be a problem. Except for my first rant, "Smart Tone Modes" has been turned off.

When the Tone, ToneSql, DTCS Code and DTCS Rx Code columns are unused, they display default values (88.5 for CTCSS and 023 for DTCS). These values are ignored by CHIRP when the setting is unused. If you don't want to see these unused values, then click View in the menu bar and enable "Hide Unused Fields" (which should be the default for new CHIRP installations). When enabled, a cell is blank when it is not used based on the current Tone Mode and Cross Mode column settings.

When Tone Mode is set to Tone, only the Tone column is used (TX only). The ToneSql column is ignored.
When Tone Mode is set to TSQL, only the ToneSql column is used (TX and RX). The Tone column is ignored.

That's where I'm having a problem. The "ToneSql" column is not being ignored. What's happening is that the tone frequency values saved in the "ToneSql" column are being replaced by the default values, if the "Tone Mode" is set to "Tone". This makes it impossible to configure a channel for carrier squelch, and still have a tone decode frequency saved in case it is needed.

Perhaps it would be helpful if I explain the problem and why I consider this behavior to be a bug. When I program a radio, I usually set most channels to carrier squelch. This is because PL decode tends to be slow to respond, chopping off the first and possibly second syllable of each transmission. However, with electronic noise being on the rise, it's not unusual to have the radio "blow squelch noise" when entering, for example, a room full of computers. Users would then simply enable the PL decode on their radio while they are in the noisy area. In order to do this with a radio programmed with the PL defaulted to 88.5Hz, the user would need to first set the PL frequency, and then change the squelch mode. Many radios, such as the Baofeng UV-5R series, will change the radio setting to what is saved in memory, if the user decides to change channel. This means that the PL frequency and squelch mode has to be set every time the user does anything except maybe transmit.

Please note that setting all the channels to "TSQL" is not a usable workaround because many repeaters do not encode PL. Usually, it's to prevent having the repeater stick on the air because of intermod, where the encoded tone is identical to the decoded tone.

What I'm asking for is that disarm and remove what I consider to be either a misfeature or bug, where the ToneSql frequency setting is changed if the mode is changed. At a minimum, if there's a non-default value saved in the ToneSql and Tone fields, do NOT change it when any other setting is changed. At best, have the "Smart Tone Modes" setting disarm any and all interaction between the tone modes and frequencies.

Thanks much...
Jeff L AE6KS

That's where I'm having a problem. The "ToneSql" column is not being ignored. What's happening is that the tone frequency values saved in the "ToneSql" column are being replaced by the default values, if the "Tone Mode" is set to "Tone". This makes it impossible to configure a channel for carrier squelch, and still have a tone decode frequency saved in case it is needed.

This is a limitation of your radio. Unlike a Kenwood or Icom, it does not have a tone squelch enable/disable switch. Instead, it stores the tone value or a zero value. There is no way to store a tone and have it disabled. The radio just wasn't designed to do it. There's nothing Chirp can do about it.

The common workaround with this type of radio is to create two channels, one with tone squelch and one with carrier squelch.

Thanks. That explains what is happening. I should have guessed that a $40 radio would cut corners somewhere. (The most irritating cut was substituting an LED light for what should have been a shaft encoder for changing channels).

I just did a quick check of the available Baofeng radios (UV-5R, UV-5X, UV-6R, UV-5R v2+) and all of them have the same problem. I also tried to program a channel manually from the keypad and ended up with the same problem. OK, it's the radio, not the Chirp software. I also checked a more expensive TYT DM-UVF10 which does NOT have the problem. The rest of the available handheld radios are Motorola and Kenwood, which aren't applicable.

As you suggested, using two channels is a usable but awkward workaround. Baofeng radios have 128 channels which I typically populate with about 100 channels. About 50 of those are receive only, which would not need to be duplicated. Some of those could also be dropped to make room for other duplicated channels. Not pretty, but methinks it could be made to work.

Thanks again.