CHIRP

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

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

Is it possible this behavior is at all related to the behavior shown in the rejected "Bug #5771":https://chirp.danplanet.com/issues/5771 ?

Last update before I go to bed... I was reading "Bug #6013":https://chirp.danplanet.com/issues/5267 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...