[chirp_users] Programming Yaesu Radios using CHIRP

[chirp.cordless at xoxy.net]

Well there's some truth there, but what truth I'm aware
of should not scare anyone off from using chirp with Yaesus.

Back in early 2014 I was doing some chirp code development
on FT-60s, fixing some bugs and with the eventual goal of
adding "Settings" control. Someone else has since done that.

Part of that process is mapping the memory by twiddling bits
in the image, uploading to the radio, and seeing through the
radio's button interface what changed. It went pretty smoothly
for a while, then I managed to brick *TWO* FT-60s. One of
which was repaired by sending it to the factory to replace
an eprom.

I'm not going to add any further detail here, my investigation
was pretty thoroughly documented in a thread on the chirp_devel
mail list with subject "How to brick an FT-60" starting 3/22/14.
See also Bug #1547: [FT-60] Chirp should check parity on download.

But normal use of chirp to program radios doesn't do this. The
user interface only lets you make limited, well understood
changes to the radio image bitmap. I still do that with mine.

-dan

> Date: Wed, 27 Mar 2019 22:05:06 -0600
> From: Larry Lovell <larry.lovell76 at gmail.com>
> Subject: [chirp_users] Programming Yaesu Radios using CHIRP
> To: Discussion of CHIRP <chirp_users at intrepid.danplanet.com>
> 
> Has anyone had a problem programming a Yaesu radio with CHIRP?
> Someone mentioned that their Yaesu was damaged and had to be sent to the
> factory because CHIRP had overwritten some code controlling the processor.
> It also had to be re-flashed.
> Since I don't fully understand how CHIRP works this doesn't make sense to
> me, but knowing manufacturing companies, they may share Channel Memory with
> processor memory and not think much about it.
> Thanks for your information.