Project

General

Profile

Actions

Bug #7953

open

Baofeng UV-B5 unusable when written to by chirp

Added by Tom Haslett almost 4 years ago. Updated almost 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
06/07/2020
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
(All models)
Platform:
All
Debug Log:
I read the instructions above:

Description

Hi,

I tried to use chirp to program an old UV-B5 I had. Reading from the radio was not an issue. It seemed to cause some very strange behaviour once the radio was written to however. The radio was unusable until I did a reset each time I tried. (Hold menu when powering on, select All).

Once written to by chirp, the things I noticed:

  • Unable to TX
  • VFO seems to jump in 10MHz steps (when going up). It seems to go up to 999 and then 0? smaller steps when going down.
  • Memories sometimes accessible, sometimes not. (No tx anyway)

Nothing seems to fix the problem other than resetting / wiping the radio.

  • I tried reading from the radio in chirp again, the memories are there.
  • I tried reading from the standard software, memories are there(from chirp). Writing again from the standard software did not change anything. I was hoping this would fix what ever the issue is.
  • I also tried various chirp versions dating back to Jan 2019, same behaviour on all of them. I was not able to get an older one like 0.4.1 to work at all. Happens on my Linux and Windows machines.
  • I tried resetting the radio, reading from the radio into chirp, making no changes I wrote back to the radio. The issue re-appears. When chirp writes to the radio, this happens.

When using just the standard software (which is terrible as per the norm) and not involving chirp, it works just fine.

If there is anything I can provide, please let me know?


Files

Actions #1

Updated by Jim Unroe almost 4 years ago

  • Status changed from New to Feedback

I was able to read from, modify and write to my old UV-B5 just fine using the most recent CHIRP daily build. TX functioned prior to making any changes, after making some changes and uploading to the raido and after restoring the original "backup image" made prior to making any changes.

If you continue to have this issue, I would suggest that supply 3 images. The 1st image from the radio after it has been reset. The 2nd image would be the channels and settings that you upload to your radio. The 3rd image downloaded from your radio immediately after the 2nd image was uploaded.

Jim KC9HI

Actions #2

Updated by Tom Haslett almost 4 years ago

Thanks, I have provided the images as suggested.

1: Factory reset and read by chirp. Saved to img.
2: Some random repeaters from a query, saved to img.
3: 2 was uploaded to the radio, then read back into chirp and saved to an img.

The issue was present as soon as 2 was uploaded once again. Hopefully this can be seen in 3?

Actions #3

Updated by Jim Unroe almost 4 years ago

Hi Tom,

Thank you for attaching the image files. From looking that them I now know exactly what the problem is. Unfortunately I have no idea at this time what the root cause of the problem is.

The image sent to the radio has the correct band limits for the radio (136-174 MHz and 400-470 MHz), but something is overwriting bytes 2 though 8 of the 8 bytes that store the band limits.

There are other minor differences between the #2 and #3 file. For example the (A) VFO frequency change from 400.000 MHz to 473.490 MHz and the selected channel number changed. I assume you turned some knobs or pressed some buttons prior downloading back to CHIRP. Would you send #2 to the radio again and immediately (without turning any knobs or pressing any buttons on the radio) download back to CHIRP and attach it as #4?

Thanks,
Jim KC9HI

Actions #4

Updated by Tom Haslett almost 4 years ago

Correct, I did press some buttons to see if 'the issue' had returned.

4 has been attached. Uploaded '2' to the radio, then read back to chirp and saved. Radio not touched.

Actions #5

Updated by Jim Unroe almost 4 years ago

Tom,

Thanks for the additional file. Everything between the #2 and #4 file is identical except for the 7 overwritten bytes.

I can't believe CHIRP is doing it or it would the same thing would happen when I upload to my UV-B5. I'm still going to see about getting a serial capture log of an upload to my UV-B5 validate that the correct 8 bytes are being sent to the radio.

Would you mind trying an upload with the factory software to see if the same thing occurs after and upload?

Jim

Actions #6

Updated by Jim Unroe almost 4 years ago

Tom,

CHIRP does indeed send the correct band limits to the radio. So something after the band limits are sent to your radio is overwriting the band limits during the remainder of the cloning process or right at the time the upload is completed.

Does your UV-B5 have 29 menus like mine or is it one with only 27 menus?

Jim

Actions #7

Updated by Tom Haslett almost 4 years ago

Hi Jim,

"Would you mind trying an upload with the factory software to see if the same thing occurs after and upload?' - When I use the factory software everything appears to be fine. When I use chirp, cause 'the issue', then use the factory software, the issue remains. Is that what you mean?

Mine is a 27 menu version.

Actions #8

Updated by Jim Unroe almost 4 years ago

Tom,

I'm not sure where to go from here. We probably need a serial port capture of CHIRP uploading to your radio. Do you have access to a Windows 7 32-bit or older computer that you could install CHIRP and Microsoft's Portmon program?

Jim

Actions #9

Updated by Tom Haslett almost 4 years ago

Hi Jim,

No I only have Linux and some Windows 10 machines. It looks like I can use something like socat or interceptty to capture the serial port traffic, I have some something similar before using socat.

I will see if I can get that going and report back.

Actions #10

Updated by Tom Haslett almost 4 years ago

So I managed to get it going. Below is how I did it in case it helps anyone in future:

interceptty /dev/ttyUSB0 /dev/ttycbg | tee ~/uvb5.txt

Attached is the output, does this look like what PortMon would provide? Is it helpful?

Actions #11

Updated by Jim Unroe almost 4 years ago

Tom Haslett wrote:

So I managed to get it going. Below is how I did it in case it helps anyone in future:

interceptty /dev/ttyUSB0 /dev/ttycbg | tee ~/uvb5.txt

Attached is the output, does this look like what PortMon would provide? Is it helpful?

Nice. It is not in the Portmon format that I am used to, but after studying it some I was able to find what I was looking for. CHIRP does send the complete set of band limits to your radio as expected (lines 5066-5073).

5066 < 0x60 (`)
5067 < 0x13 ([DC3])
5068 < 0x40 (@)
5069 < 0x17 ([ETB])
5070 < 0x00 ([NUL])
5071 < 0x40 (@)
5072 < 0x00 ([NUL])
5073 < 0x48 (H)

Looking at the remainder of the upload I don't see anything that would indicate that CHIRP was overwriting the band limits.

Essentially what is happening to your radio is that something is changing lines 5069 to 5073 to "0xff" corrupting your radio's band limits.

I noticed that my CHIRP development computer didn't have the latest CHIRP daily build installed so I updated CHIRP and repeated the tests with my UV-B5. Nothing has changed here. My UV-B6 still functions and operates normally.

One difference I did see between your radio and mine (besides the number of menus) was that the band limits in your are set to VHF: 136-174 MHz and UHF: 400-480 MHz (well at least until they get corrupted) and the band limits in my radio are set to VHF: 136-174 and UHF: 400-520 MHz.

Actions #12

Updated by Tom Haslett almost 4 years ago

Hi Jim,

It almost sounds like the radio itself could be doing this to itself? Is the 27 menus a significant difference? Perhaps this is a new version with something different about it?

It doesn't sound like there is anywhere to go from here, let me know if there is anything else I can provide. Thank you for looking into this!

Tom - M6THZ.

Actions

Also available in: Atom PDF