On Sat, Nov 2, 2024 at 7:24 PM Michael K Johnson <mcdanlj@gmail.com> wrote:
On Sat, Nov 2, 2024 at 7:12 PM Dan Smith via Developers <developers@lists.chirpmyradio.com> wrote:
We can't do that without separate subclasses that claim them. The (driver) tests are driven from the images. The sample images are for the tests, so whenever we add new code I like to avoid a change to an existing image as a sort of proof that the new code still works with the old image (insofar as the tests would tickle something). I don't really think we need an update to the image in the tree (unless there's a reason in which case we need to handle that case). If you really want to change it, please put it in a separate commit after and separate from any code changes.

Yeah, I just also saw your preference to not make a whole new set of radios classes for this unless absolutely necessary. Didn't know how you wanted to balance that.

This turned out to be important, which won't surprise you at all.

The old firmware has an all-0xFF block 0xCA0-0xCA7 in which several new settings have been placed. One of those settings, a 4-bit setting 56.SCAN BAND, is undefined for 0xF. I have used that as a sigil for keeping all the settings in 0xCA0-0xCa7 hidden unless a defined value for scan band is found.

Making a PR now.