On 25/05/2019 20:00, chirp_users-request@intrepid.danplanet.com wrote:
<Snipped>
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?*
------------------------------------------------------------------------
Hi.
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