[chirp_devel] "Don't use chirp" warning on italian radio eshop
Hi all on the site page http://www.mediaglobe.it/shop/baofeng-uv5ra-duobanda-portatile-p-5055.html you can see that mediaglobe (one of the biggest radio e-seller in italy) says "do not use CHIRP". (translate the sentence in red with google) The same advice is also on the page of other baofeng models.
I was going to write them to tell that's not true but before this please: - Jim can you confirm they are wrong? please point me to the issue # if any - Dan do you mind me to write as "a chirp developer"?
Any other thought?
TNX 73 de IZ3GME Marco
On Sat, Sep 27, 2014 at 9:14 AM, Marco IZ3GME iz3gme.marco@gmail.com wrote:
Hi all on the site page http://www.mediaglobe.it/shop/baofeng-uv5ra-duobanda-portatile-p-5055.html you can see that mediaglobe (one of the biggest radio e-seller in italy) says "do not use CHIRP". (translate the sentence in red with google) The same advice is also on the page of other baofeng models.
I was going to write them to tell that's not true but before this please:
- Jim can you confirm they are wrong? please point me to the issue # if any
- Dan do you mind me to write as "a chirp developer"?
Any other thought?
TNX 73 de IZ3GME Marco
Marco,
Programming these new UV-5R variant radios with CHIRP isn't the problem. A user with a single radio and a single copy of CHIRP would never have an issue.
The problem doesn't occur until a CHIRP *.img file from a UV-5R variant that has an older firmware version is uploaded to one of these new radios with N5R-20 firmware (radios with 2 power levels) or N5R-30 firmware (radios with 3 power levels).
Up until now, CHIRP has always considered it "safe" (and it always has been "safe") to upload the "main" memory area across all compatible firmware versions. It is only been the "aux" memory area that CHIRP has careful only to upload when the firmware versions of the data and radio matched. BaoFeng/Pofung has changed the layout of the "main' memory area so it is not safe to "blindly" upload the "main" memory area any more.
What happens is when a CHIRP *.img file made from a radio with previous firmware version is uploaded into one of these radios with the new firmware, a 16 byte area of memory containing data becomes filled with 0xFF effectively erasing it. With this area of memory erased, the radio will no longer receive without the [MONI] (monitor) button being pressed. A similar scenario occurs to a different 16 byte area of memory if a CHIRP *.img file from one of these new radios is uploaded into a radio with an older firmware version.
Once the cause and affect of this issue became understood, CHIRP was updated to prevent these memory areas from being overwritten by not allowing the upload of incompatible *.img files. Issues #1773, #1751, #1849 and #1851 are all related to this memory layout change.
THESE RADIOS ARE NOT PERMANENTLY DAMAGED. They are easily restored to full working order. I have personally helped many new Baofeng/Pofung owners "recover" after an "old" *.img file has been cross loaded into their "new" radio. The procedure for this simple "recovery" process is available here: http://www.miklor.com/uv5r/UV5R-Recovery.php#N5R
Let me know if you need more detail about something or have additional questions.
Jim KC9HI
Thanks Jim for your summary, I'll wait for Dan and others then I'll write to mediaglobe before monday.
I'll keep you updated.
73 de IZ3GME Marco
On 27/09/2014 18:08, Jim Unroe wrote:
On Sat, Sep 27, 2014 at 9:14 AM, Marco IZ3GME <iz3gme.marco@gmail.com mailto:iz3gme.marco@gmail.com> wrote:
Hi all on the site page http://www.mediaglobe.it/shop/baofeng-uv5ra-duobanda-portatile-p-5055.html you can see that mediaglobe (one of the biggest radio e-seller in italy) says "do not use CHIRP". (translate the sentence in red with google) The same advice is also on the page of other baofeng models. I was going to write them to tell that's not true but before this please: - Jim can you confirm they are wrong? please point me to the issue # if any - Dan do you mind me to write as "a chirp developer"? Any other thought? TNX 73 de IZ3GME MarcoMarco,
Programming these new UV-5R variant radios with CHIRP isn't the problem. A user with a single radio and a single copy of CHIRP would never have an issue.
The problem doesn't occur until a CHIRP *.img file from a UV-5R variant that has an older firmware version is uploaded to one of these new radios with N5R-20 firmware (radios with 2 power levels) or N5R-30 firmware (radios with 3 power levels).
Up until now, CHIRP has always considered it "safe" (and it always has been "safe") to upload the "main" memory area across all compatible firmware versions. It is only been the "aux" memory area that CHIRP has careful only to upload when the firmware versions of the data and radio matched. BaoFeng/Pofung has changed the layout of the "main' memory area so it is not safe to "blindly" upload the "main" memory area any more.
What happens is when a CHIRP *.img file made from a radio with previous firmware version is uploaded into one of these radios with the new firmware, a 16 byte area of memory containing data becomes filled with 0xFF effectively erasing it. With this area of memory erased, the radio will no longer receive without the [MONI] (monitor) button being pressed. A similar scenario occurs to a different 16 byte area of memory if a CHIRP *.img file from one of these new radios is uploaded into a radio with an older firmware version.
Once the cause and affect of this issue became understood, CHIRP was updated to prevent these memory areas from being overwritten by not allowing the upload of incompatible *.img files. Issues #1773, #1751, #1849 and #1851 are all related to this memory layout change.
THESE RADIOS ARE NOT PERMANENTLY DAMAGED. They are easily restored to full working order. I have personally helped many new Baofeng/Pofung owners "recover" after an "old" *.img file has been cross loaded into their "new" radio. The procedure for this simple "recovery" process is available here: http://www.miklor.com/uv5r/UV5R-Recovery.php#N5R
Let me know if you need more detail about something or have additional questions.
Jim KC9HI
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
- Dan do you mind me to write as "a chirp developer"?
I do not mind and would appreciate you doing that!
Jim, should we put a special notice on the download page about this? Alternately, should we backport just that change on top of 0.4.0 and release an 0.4.1 to stop people from downloading and using 0.4.1?
--Dan
On Sun, Sep 28, 2014 at 10:37 AM, Dan Smith dsmith@danplanet.com wrote:
- Dan do you mind me to write as "a chirp developer"?I do not mind and would appreciate you doing that!
Jim, should we put a special notice on the download page about this? Alternately, should we backport just that change on top of 0.4.0 and release an 0.4.1 to stop people from downloading and using 0.4.1?
--Dan
Dan,
I don't know what the "backport" process involves, but rolling out a v0.4.1 that will prevent the cross loading of pre-N5R-20 firmware .img files with N5R-20 firmware radios (and the other way around) seems like the right thing to do.
Jim
On 28/09/2014 16:55, Jim Unroe wrote:
I don't know what the "backport" process involves, but rolling out a v0.4.1 that will prevent the cross loading of pre-N5R-20 firmware .img files with N5R-20 firmware radios (and the other way around) seems like the right thing to do.
I agree: rolling a new sub release seems the best option.
TNX 73 de IZ3GME Marco
I don't know what the "backport" process involves, but rolling out a v0.4.1 that will prevent the cross loading of pre-N5R-20 firmware .img files with N5R-20 firmware radios (and the other way around) seems like the right thing to do.
Okay, just to be clear, can you tell me exactly which changes would need to be made on top of 0.4.0? I can try to figure it out based on the issue numbers you provided, but thought maybe there was one specific change that would be easier to apply (and/or rewrite) just to get the firmware version protection, without a bunch of other changes.
Thanks!
--Dan
On Mon, Sep 29, 2014 at 6:43 PM, Dan Smith dsmith@danplanet.com wrote:
I don't know what the "backport" process involves, but rolling out a v0.4.1 that will prevent the cross loading of pre-N5R-20 firmware .img files with N5R-20 firmware radios (and the other way around) seems like the right thing to do.
Okay, just to be clear, can you tell me exactly which changes would need to be made on top of 0.4.0? I can try to figure it out based on the issue numbers you provided, but thought maybe there was one specific change that would be easier to apply (and/or rewrite) just to get the firmware version protection, without a bunch of other changes.
Thanks!
--Dan
I believe that #1773 should be the only issue number needed to provide the firmware version protection.
To deal with any of the other 3 issues, the user should just upgrade to the latest daily build.
Jim
I believe that #1773 should be the only issue number needed to provide the firmware version protection.
Okay cool. I just generated an 0.4.1-rc1 build in the chirp_daily spot. Could you give that a quick test to make sure it's right (and generally functional)? After that I'll put that on the download page so people start getting that.
Anything else critical for an 0.4.1 from anyone?
Sorry it took me a while to get to this... :/
--Dan
Dan,
My testing indicates that this works as expected. I say run with it.
Jim
On Tue, Oct 7, 2014 at 6:12 PM, Dan Smith dsmith@danplanet.com wrote:
I believe that #1773 should be the only issue number needed to provide the firmware version protection.
Okay cool. I just generated an 0.4.1-rc1 build in the chirp_daily spot. Could you give that a quick test to make sure it's right (and generally functional)? After that I'll put that on the download page so people start getting that.
Anything else critical for an 0.4.1 from anyone?
Sorry it took me a while to get to this... :/
--Dan
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
My testing indicates that this works as expected. I say run with it.
Cool, thanks!
I've generated the 0.4.1 build and updated the download page to point to it. Do you want to do the honors and send the release note to the users mailing list since this really only contains one change from 0.4.0 from you? If not, I'm happy to do it.
--Dan
On Wed, Oct 8, 2014 at 3:10 PM, Dan Smith dsmith@danplanet.com wrote:
My testing indicates that this works as expected. I say run with it.
Cool, thanks!
I've generated the 0.4.1 build and updated the download page to point to it. Do you want to do the honors and send the release note to the users mailing list since this really only contains one change from 0.4.0 from you? If not, I'm happy to do it.
--Dan
Done. Thanks Dan.
Jim
participants (3)
-
Dan Smith -
Jim Unroe -
Marco IZ3GME