[chirp_devel] Bug 937: FT-857D crashes due to problematic channel
http://chirp.danplanet.com/issues/937
I edited my FT-857D (US version) image with CHiRP (current tip pulled from hg) that causes my radio to crash and go into a restart loop when accessing the problematic channel. (Frequency is 449.325, TSQL, PL 136.5)
Originally the offending entry was copy and pasted from a Wouxun which made it show up with an odd split 449.325 and 444.325 instead of an offset of -5.0 Mhz.
However, I was able to make the problem occur just entering that info by hand without using copy and paste.
Also, does anyone know how to reset the FT-8[59]7 to get a truly clean image?
I did all three resets, which did reset all of the settings and made it appear as if all of the memories had been deleted, however, I see from looking at a dump of the image file the memories were just marked inactive and most of the data was still there. I was trying to get as pristine of an image as possible for isolating this.
Hi Robert I have spent some time analysing the image you sent but I don't see anything special in the offending memories. Please manually create on the radio a memory with the very same setting and then download & send the image so I can compare it to the one generated by chirp.
The master reset should be the one with [F] and [V/M] keys, as of my knowledge, but I don't really know if it clean memories area.
Anyway to clean up used memories you can double delete them in chirp: the first delete just inactivate them and the second write 0xFF in each byte.
73 de IZ3GME Marco
On 25/06/2013 03:34, Robert Terzi wrote:
http://chirp.danplanet.com/issues/937
I edited my FT-857D (US version) image with CHiRP (current tip pulled from hg) that causes my radio to crash and go into a restart loop when accessing the problematic channel. (Frequency is 449.325, TSQL, PL 136.5)
Originally the offending entry was copy and pasted from a Wouxun which made it show up with an odd split 449.325 and 444.325 instead of an offset of -5.0 Mhz.
However, I was able to make the problem occur just entering that info by hand without using copy and paste.
Also, does anyone know how to reset the FT-8[59]7 to get a truly clean image?
I did all three resets, which did reset all of the settings and made it appear as if all of the memories had been deleted, however, I see from looking at a dump of the image file the memories were just marked inactive and most of the data was still there. I was trying to get as pristine of an image as possible for isolating this.
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
The master reset should be the one with [F] and [V/M] keys, as of my knowledge, but I don't really know if it clean memories area.
FWIW, I've never seen a Yaesu/Vertex radio that does actually clean its memories on a reset. It's really annoying and makes it nearly impossible to get a clean memory image without a fresh-from-factory radio.
Ok, I believe I've found the answer and I believe is is a (latent) bug in the radio itself. A memory label of 4 characters or less will cause the radio to crash when accessing that memory. This is on a FT-857D, manufactured in 2012.
The default label the radio creates is 6 characters long CH-NNN, so there is probably never a case where it is possible to create a label on the radio with 0xFF's starting at a position less than the 7th character.
Most likely a work around should be added to Chirp to space pad labels to a minimum of 5 or 6 characters.
--Rob
Hi Robert! Can you please confirm that creating a short memory label on the radio itself fires up the bug? Anyway padding to 5 chars looks safe, I'm going to send a patch in minutes.
FYI on my early FT857 I have many memories labels of 2,3 and 4 characters and I never had a problem, this issue must be limited to only some production batches.
Thank you!!!
73 de IZ3GME Marco
On 25/06/2013 21:18, Robert Terzi wrote:
Ok, I believe I've found the answer and I believe is is a (latent) bug in the radio itself. A memory label of 4 characters or less will cause the radio to crash when accessing that memory. This is on a FT-857D, manufactured in 2012.
The default label the radio creates is 6 characters long CH-NNN, so there is probably never a case where it is possible to create a label on the radio with 0xFF's starting at a position less than the 7th character.
Most likely a work around should be added to Chirp to space pad labels to a minimum of 5 or 6 characters.
--Rob
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
On 6/26/2013 2:37 AM, IZ3GME Marco wrote:
Can you please confirm that creating a short memory label on the radio itself fires up the bug?
I haven't found a way to create a label on the radio that isn't space padded out to 8 characters.
It looks like it's the 0xff appearing in the 5th byte that triggers the bug on my radio.
Note: the radio creates a default label of CH-NNN (6 chars) that you have to change to spaces if you have less than 6 chars. (In my tests, the 7th and 8th bytes were spaces even though they weren't touched.)
I'm told FTBasicMMO (G4HFQ's software for the ft-8x7) has always space padded to 8 chars.
FYI on my early FT857 I have many memories labels of 2,3 and 4 characters and I never had a problem, this issue must be limited to only some production batches.
But are they space padded, or filled out with 0xff?
In your patch, the implied field names in the format strings won't work on Python versions < 2.7. Specifying field 0 will allow it work on Python 2.6
Change '{<:5}' to '{0:<5}'
Thanks for your help, --Rob
Hi Robert new patch is in on the way ...
73 de IZ3GME Marco
On 26/06/2013 16:26, Robert Terzi wrote:
On 6/26/2013 2:37 AM, IZ3GME Marco wrote:
Can you please confirm that creating a short memory label on the radio itself fires up the bug?
I haven't found a way to create a label on the radio that isn't space padded out to 8 characters.
It looks like it's the 0xff appearing in the 5th byte that triggers the bug on my radio.
Note: the radio creates a default label of CH-NNN (6 chars) that you have to change to spaces if you have less than 6 chars. (In my tests, the 7th and 8th bytes were spaces even though they weren't touched.)
I'm told FTBasicMMO (G4HFQ's software for the ft-8x7) has always space padded to 8 chars.
FYI on my early FT857 I have many memories labels of 2,3 and 4 characters and I never had a problem, this issue must be limited to only some production batches.
But are they space padded, or filled out with 0xff?
In your patch, the implied field names in the format strings won't work on Python versions < 2.7. Specifying field 0 will allow it work on Python 2.6
Change '{<:5}' to '{0:<5}'Thanks for your help, --Rob
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
participants (3)
-
Dan Smith -
IZ3GME Marco -
Robert Terzi