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 about 2 years ago. Updated 6 months ago.

Status:New Start date:08/13/2018
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:chirp-daily
Chirp Version:daily Platform:All
Model affected:Baofeng UV-5R

Description

Daily-20180811-win32
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.

History

Updated by Paulo Alcobia about 2 years ago

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

Updated by CJ Chitwood about 1 year 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

Updated by CJ Chitwood about 1 year ago

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

Updated by CJ Chitwood about 1 year 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...

Updated by Bernhard Hailer 6 months 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-daily
  • Model affected changed from (All models) to Baofeng UV-5R
  • Platform changed from Windows to All

Also available in: Atom PDF

prevent spam