CHIRP

I just got a new UV-6 and have same problem. My old UV-6 downloaded but only the memories tab was populated with info.

Same as Bugs #5615, #6173, #5905, #5887, #6447.
It's been a while since I have contributed. Let me know what you need. Seems like there was a port monitor program that you needed the output from.

I would like it to work. Tell me what can I give? What should I do?

Radio presenting the same problem, does anyone have a solution?

"Radio refused to send second block 0x1ec0."

Baofeng UV-6 always the same error "Radio refused to send second block 0x1ec0". Is perfectly working with the UV-6 UV-7 Baofeng software. But I need for Chirp. Please!

Jim Unroe wrote:

These radios are refusing to return the second part of the radio's firmware section of memory. CHIRP needs/uses this information to be able to adjust for the radio being programmed.

Jim KC9HI

I don't think this is the case.

I looked at the serial communication from chirp and compared to the software from baofeng.

I believe the problem is that chirp asks for the firmware twice.

The first time it asks at the beginning of the transaction it receives the firmware.

after receiving the channel information, the device sends 2 NULLs (I believe this is to hang up.) I think the logic of uv5r.py needs some updating.

The problem is not with the firmware.

I commented out these following lines in uv5r.py

LOG.debug("downloading aux block...")
# Auxiliary block starts at 0x1ECO (?)
for i in range(0x1EC0, 0x2000, 0x40):
data += _read_block(radio, i, 0x40, False)

and it works!!!

so ummm.... I think the UV-6 doesn't have any Aux blocks. so that was the problem. Just guessing tho.

I've not tried writing to it yet.

I believe the correct solution in to put a if statement in the code so if it is a UV-6 you don't try to download the AUX block.

Bryan Hatton wrote:

The problem is not with the firmware.

I commented out these following lines in uv5r.py

LOG.debug("downloading aux block...")
# Auxiliary block starts at 0x1ECO (?)
for i in range(0x1EC0, 0x2000, 0x40):
data += _read_block(radio, i, 0x40, False)

and it works!!!

so ummm.... I think the UV-6 doesn't have any Aux blocks. so that was the problem. Just guessing tho.

I've not tried writing to it yet.

I believe the correct solution in to put a if statement in the code so if it is a UV-6 you don't try to download the AUX block.

Actually the UV-6 that the driver was created with does have the AUX blocks. So it is a little more complicated than disabling the Auxiliary Blocks section of code for everybody. All the settings that get their data from the AUX block would have to be disabled as well. Please attach a image created from your radio using the patched driver so it can be examined.

Jim KC9HI

I have the serial traffic of both chirp and the manufactures program if that would be of any help.

So it works with my uv-6 and my uv-82hp

(what stuff in saved in the aux?) so I can better test it.

Bryan

here are the only things I have noticed tonight,

1. on the uv-6 under duplex if you select off (to make a listen only channel) it still transmits. I think this is a limitation of the radio.

2. the following error is produced during the upload (how ever it works fine):
   
   ERROR: Clone failed: Upload finished, but the 'Other Settings' could not be sent because the firmware version of the image () does not match that of the radio (�������UV6H011).

3. chirp adds functionality that the manufacturers program doesn't have, it allows 7 char name instead of 6 :-)

I've not seen any issues with my uv-82hp.

Bryan

Jim Unroe wrote:

Please test this custom driver module to see if it works for a Baofeng UV-6 that does not support Aux Memory. If you also have other Baofeng UV-5R like models (UV-5R, BF-F8HP, UV-82, UV-82HP, etc), test a few of them to make sure that their support is not broken. Then provide feedback.

Here is how you use the custom driver module.
1 save custom driver module to a convenient location (Do not right-click link. Click link and choose "Download" on the following page that appears. )
2 click "Help"
3 enable "Enable Developer Functions"
4 click "File"
5 click "Load Module"
6 locate and load custom driver module that was saved in step 1

The CHIRP background will now be red to indicate it is running with a custom driver module loaded. You can now test the custom driver module.

Note: The test driver module does not permanently change your CHIRP installation in any way. Every time you load CHIRP you must load this driver module to continue testing.

Jim KC9HI

It turned out to read the radios uv-6 and uv-82. I am not very good with the full testing program. Thank.

Testing would be to check to see that all of the UV-82 settings still appear and both radios can (still) download/upload. Also make sure that and "image" from each radio can be saved and restored.

Jim KC9HI

when loading in uv-6 error in the screenshot, while the data was loaded and read. with uv-82 everything is fine.