Bug #6013


Baofeng UV-5R - Tone Mode column values set to TSQL after table refresh if the value is set to Cross.

Added by Paulo Alcobia over 5 years ago. Updated almost 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Chirp Version:
Model affected:
Baofeng UV-5R
Debug Log:
I read the instructions above:


Baofeng UV5R .img file is attached. this doesn't happen with a generic radio CSV.
To reproduce this bug create a frequency entry and set the tone mode to Cross (that means having CTSS for trans mission and Tone Squelch together) the Cross mode column should change to "Tone->Tone" and both the "tone" and "ToneSQL" columns should show a tone when the changes are applied.

Then, saving the file and reopening it will trigger the but: the tone mode column will show "TSQL" instead of "Cross" the "Tone" and "Cross Mode" columns will be cleared.

Pressing the either the "Special channels" or "Show Empty" buttons will also have the same effect.

Programming the radio works if the values are still correct in the screen. But reading it back from the radio shows "TSQL" instead.

This means that every time you want to edit a single entry on your radio and you have many cross tone settings like I do, you have to go to every entry and set the Tone mode and the Tone column for every entry affected before sending back to the radio.

Actions #1

Updated by Paulo Alcobia over 5 years ago

Apparently, it happens whenever a .img file is being used but not with .csv

Actions #2

Updated by CJ Chitwood over 4 years ago

I have this same issue on Linux (Debian Stretch 9.something) with multiple versions of CHIRP from as far back as 20170124 to the latest 20190824. I have the UV-B5. I've noticed it's more than just when cross mode is used, or at least it used to be. Testing with the latest available daily (20190824) I can't force it to happen except when using cross. Tone, TSQL, and (none) seem unaffected.

For me, ANY change to the table that causes a shift in memories (e.g. deleting a row, adding a row, cut-and-pasting, whatever) would trigger this bug.

Not only does the mode change to TSQL, but the tone frequency also reverts to 88.5. It makes me think a value is "off by one" in a table or a matrix somewhere, and a refresh or shift in the memories gets the data read one column off -- but just for the "tone mode" and "tone" column, as if they're shifted to the right (because the value that WAS in tone column is now in the tsql column I think, but they're usually the same for me anyway so I'm not certain and when I went to test I couldn't verify -- see next paragraph).

Worse, this doesn't seem to always be reproducible. I was able to a moment ago, now I can't, and nothing's changed. I opened a valid file I used yesterday, edited a few lines, and saved as a new test.img file. I closed, reopened, and the bug was seen. The same steps mere minutes later to test my statement in the previous paragraph did not reproduce the bug at all. :confused:

This was also a bug as far back as 20170124, the latest available CHIRP in the Debian repositories. I'm running Linux Debian Stretch (9.something), if it matters.

I wish to provide debug files, but for some reason this latest version isn't producing them. Is there a special command line flag I need to use to force debug file output?

Thanks and 73 de KE4EDD

Actions #3

Updated by CJ Chitwood over 4 years ago

Is it possible this behavior is at all related to the behavior shown in the rejected "Bug #5771": ?

Actions #4

Updated by CJ Chitwood over 4 years ago

Last update before I go to bed... I was reading "Bug #6013": and while I suspect it's entirely unrelated (disabling "Smart Tone Modes" changed nothing that I could see) it got me to thinking from a different angle.

I've noticed that if I have differing settings for the Tone and ToneSql columns, save the file, close it, reopen it, the settings are kept properly.

If I set BOTH Tone and ToneSql to the same frequency (typical in my area for repeaters that emit the same as they require for keying them up), then save, close, reopen, then the setting is changed from CROSS to TSQL, the Tone is reverted to 88.5, and only the ToneSql retains the setting it had before.

This may be normal, if perhaps the use of ToneSql setting will also cause the radio to transmit the tone when keyed up, but this is counterintuitive. ToneSql implies that the tone must be received to break the squelch on the radio, Tone implies that the tone will be transmitted but not required for breaking squelch on reception, and Cross implies both will occur; changing it to "TSQL" on reload when they're both the same is just confusion.

Good night, all...

Actions #5

Updated by Bernhard Hailer almost 4 years ago

  • Subject changed from Tone Mode column values set to TSQL after table refresh if the value is set to Cross. to Baofeng UV-5R - Tone Mode column values set to TSQL after table refresh if the value is set to Cross.
  • Priority changed from High to Normal
  • Target version set to chirp-legacy
  • Model affected changed from (All models) to Baofeng UV-5R
  • Platform changed from Windows to All

Also available in: Atom PDF