[chirp_users] Truth or Fiction

Dave B
Sun May 26 01:16:15 PDT 2019

On 25/05/2019 20:00, chirp_users-request at intrepid.danplanet.com wrote:


> They say they've seen bricked radios caused by CHIRP.? Said it's 
> because CHIRP wrote to areas they're not supposed to write to.? Said 
> that RT Systems "works with Yaesu" and that's why they support RT 
> Systems.? *Who would write the internal software for a radio where the
> programming software could brick it?*



Probably so they can load/update the entire firmware via the programming
port during production with minimal effort on their part.

However...  Any "Sensible" designer would have put procedures in place
in the final "User Release" firmware (as opposed to Production Test
firmware) so that someone has to put the radio in a firmware load mode,
perhaps like some other gadgets, by holding particular keys while it is
powered up.

Otherwise, leave it able to have memory data pulled and pushed, but
other areas protected, perhaps flagging a warning on any display, of
beeping, if anything tries to push data where it's not supposed to go,
but otherwise ignoring it.

But, these are products built down to a price, software/firmware
development is expensive in time, and time costs money, due to the team
of people involved.  Plus, they are probably working on a host of other
products too, so rightly or wrongly, only the bare minimum is done to
meet the project's specified needs, and that's all.   At the expense of
"sanitisation" code for any remote memory read/write functions over any
I/O port.

Remember, just one bit flipped in the wrong place could cause mayhem or
utterly brick a product.  Or cause no issue, if the internal code does
not use that location.   But, a later updated firmware might use that
location for something critical!

The RT systems people have probably paid Yaesu for the needed
information to do it the right way, or even purchased a software library
from them, so they are understandably trying to protect their
investment, in this case by (allegedly) perhaps spreading untruths about
competing software.  It's sadly not uncommon in the
professional/industrial world too.

Regarding CHIRP.  It's good, very good.  But by the nature of things
that are built as a result of reverse engineering someone else's
protocol without sight of any makers documentation, mistakes can be
made, or features/methods that are default if not touched are fine on
one product, but on another outwardly similar product, is the wrong way
to do things.

Heck, in my life where I've created code for products and customers,
where documentation DOES exist, there are often errors and omission in
the doc's that turn out to be a tripping point!   And that's for
products that cost many times more than any Ikensu radio!

Reverse engineering is not trivial either, lots of testing is needed,
with access to examples of (in this case) the particular make/model of
radio in question, and known working software (all at a cost.)  All that
takes time, LOTS of time, plus at a guess, I expect the developers
working on this are volunteers who as such are unpaid and have lives to
get on with too.

I have to say, they do a great job all things considered.

I myself have a HH radio I'd like to use with CHIRP (A Puxing PX-2R)
that CHIRP doesn't understand correctly, at this time.  A Bug has been
filed, with log files etc (January this year.)  But I'm not expecting a
rapid fix as other issues affect a lot more people.

I have the hardware, some Python knowledge, but I'm not up at the level
needed to do much with it, sadly.  I also don't get enough of "the right
sort of contiguous time" to dive in, learn, and have a go myself, but I
might re-visit the code, and see if I can learn what's going on, or
not.   But as always, that takes time, and I have many many other things
I need to be doing in the domestic and work world too.

Regards to All.

Dave B G0WBX

Created on and sent from a Unix like PC running and using free and open source software:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20190526/0fb631fe/attachment.html 

More information about the chirp_users mailing list