[chirp_devel] Porting Sainsonic RST599

[Dan Smith]

> Do we try to maintain compatibility with original software for radios? I
> noticed that original software stores file in a "messed up" way with
> blocks order changed. Right now, I try to follow memory addresses and
> use sparse memmap by using its __setitem__ via subscripts and partially
> overwriting some data from there. Is it okay thing to do as I didn't see
> any other drivers doing that? It is easier to work with rather than
> doing some math for auxiliary block. It is way faster than copying
> entire memory full of unused segments and I can skip fetching non-set
> channels as I know bitmask.

In general, we store things as a raw dump of the memory in a file. This
is sometimes the same as factory software, but often is not. Whatever is
convenient is fine. We also often support read-only imports from factory
software, which is an easier option in many cases. But, whatever you
want to do is fine, as long as you can detect your model's files and
they don't cause any false positives with others. We also need to commit
to one format and not break stored files that people have from build to
build.

> Is there (or planned) general purpose table editor widget? It is
> somewhat ugly to edit FM presets as it is done now. And there is also
> Automatic Repeaters Offset settings, tone codes, and 4(!) lines of
> power-on welcome message with various font sizes and alignment. It looks
> somewhat cluttered now. Some generic table widget would be better. Did I
> miss it? Is there an example?

I don't think a table view of the settings would be something I'd find
more appealing, personally, and I think it would be hard to represent
some of the things we have to provide in that fashion. But, you're
welcome to work up a proof of concept and try to convince us that it's a
better approach.

> Is there an extensive list (wiki?) with all common namings? I mean like
> how to name things in that data blob as I see code outside of drivers
> uses some... like autorpt. What would I name frequency ranges? I guess
> more generic question is: are we trying to achieve cross compatibility
> like loading settings (besides channels) from other radios?

I'm not sure what you're asking exactly. The memory structure
definitions you provide to bitwise are really private names and don't
need to be standardized for any reason.

> Also I see some non-DRY code in drivers regarding charset filtering,
> block reading/writing and checking things (send something & expect
> 0x06). There are tons of similar looking code between Wouxon and
> Baofeng. How shall I approach it? Copy/paste and modify as necessary for
> now? I feel like since I'm writing the new one, I still can do it
> right. Perhaps it would be nice to have an extra class to derive from
> that would define ACK for write commands, and form read command via
> struct "<cHb" and check "Hb" part in return.

The problem here is that many of these drivers were written by multiple
people over many years. Since most of the drivers were written by people
borrowing radios, there was no opportunity to refactor a driver that
turned out to offer some commonality *and* test that both still worked
after that occurred. There is a ton of little stuff like that where
someone borrows a piece from a yaseu driver and a piece from a wouxun
driver to make a foobar driver. The potential for breakage trying to
refactor the two existing into something upon which the third can be
built on is high.

It would be nice if we had access to all the models we support so we
could clean things up whenever we find commonalities and test that we
didn't break anything. That's just not a reality.

If you have the ability to test multiple drivers after doing a refactor,
then that's great. But please don't speculatively refactor something
that "should work" and ask for it to be applied. Many of these radios
are very particular about timing and other related things and breaking
things and finding out about it in six months when someone with a rare
model realizes it's broken is a bad place to be.

--Dan