Bug #344
closed
UV-5R - BFB291 and BFB293 Incompatibility
Added by John LaMartina about 12 years ago.
Updated almost 12 years ago.
I read the instructions above:
Description
Unlike prior versions of the UV5R Firmware releases BFB290 and prior, the newer releases (BFB291 and BFB293) currently need to be handled as two separate radios.
I am able to load a .img file created with a BFB291 radio to my BFB293 radio.
I am also able to do the reverse, load a BFB293 .img file to my BFB291 radio.
However, in BOTH cases, the RX was fine but the TX was Locked Out.
I then reloaded the BFB291's .img file back to the BFB291 radio, and the BFB293's .img file to the BFB293 radio and all went back to normal.
Attached are two debug.log files.
BFB291Debug.log is from the BFB291 radio after loading the BFB293 software with TX locked out.
BFB293Debug.log is from the BFB293 radio ...
The immediate fix would be to allow a BFB291 radio to accept a file created by a BFB291 only.
The same for a BFB293 radio.
John K3NXU
Files
Sorry... I failed to enter:
Model Affected = UV5R series
CHIRP version = 20121028
Platform = Windows
Further testing shows the following:
When loading a .img file created by a radio with BFB291 firmware to a BFB293 radio, or vice versa, the frequency limit appears to get reset to 480MHz rather than 520MHz.
This is what Locks Up the TX.
All other data, frequency, menus, etc transfer fine.
If the frequency limit can automatically be set to 520MHz, the TX Lock Up should disappear.
John K3NXU
- Status changed from New to Blocked
- Assignee set to Dan Smith
- Priority changed from Normal to Low
- Target version set to 0.3.0
- Chirp Version changed from 0.2.3 to daily
- Model affected changed from (All models) to UV5R
- Platform changed from Windows to All
Well, here's the problem...
There seems to be no real way to determine what the radio is running from the identification it returns during that phase of the clone. If you recall, when we first started down the path of supporting the newer radios, there was a lot of work to be done to try to get an algorithm nailed down that could reliably tell the difference between the two different levels. What remains is so loose, that I'm not sure I can tighten it any further without causing a lot of headaches for folks with weird revisions of effectively the same radio.
So I think the options are:
- Tell folks not to do this, and since it's not too fatal, maybe this is okay.
- Make the software not upload the auxiliary block with the settings and band limits in it by default (which is the only bit that seems to differ between the two in the actual image itself).
If we go with number 2, then I have to figure out a way to allow the user to select whether they want the aux block to be uploaded with the image, and attach a nasty warning about why it matters.
I just pushed r1759, which should let you see/edit the per-band TX lock. This may let you upload your 291 image into your older radio, then download it again and fix the band limits and the TX lock manually.
- Status changed from Blocked to Resolved
Fixed (violently) in r1763 by reading the aux block first and requiring a strict version match.
Just pushed an update which will cause this behavior:
- If the radio responds, we try to push the main part of the image (regular settings, memories, etc)
- After that is done, we check to see if the firmware of the image matches that of the radio
3a. If it does, we push the aux block with the "other settings"
3b. If it does not, we raise an error to the user letting them know that the main upload finished, but that it can't do the aux block
So, users can now upload old images into new radios (and vice versa) but they will get the error saying that the "other settings" can't be sent. In order to tweak those, they'd need to download a matching image of the radio.
I don't think that splicing the aux and main blocks of two images is something that we should expose to the user, both from a safety and complication standpoint. I think this is more than enough flexibility as it is. Agreed?
- Status changed from Resolved to Closed
Also available in: Atom
PDF