[chirp_devel] support 'split'/'-'/''/'+' frequency modes on only some channels and still pass unit tests?

[Leo Bärring]

Writing a driver for the Puxing PX-888K HT I'm wondering if there is a way to support that not all
channels support all duplex modes. More to the point, there are 128 regular memories, as well as
three special channels, VFO-A, VFO-B, and CALL.
The call channel is equal to the memory channels in all but storage location and how to access it
on the radio hardware: they always operate in 'split' mode, that is two numbers are stored,
rx and tx frequencies. The vfo channels on the other hand, always operate in '-'/''/'+' mode,
the rx frequency is stored and the tx frequency is determined by an offset and a sign.

So far so good. The problem is that what modes to support is declared once, and for the whole radio,
so for rf.valid_duplexes I put all of them, and if the user tries to set a mode that is not supported
for that particular memory, it is converted to one that is, e.g:
> Memory#1: freq = 456.0, offset = 0.7, duplex = '+'
when stored to the memory map, turns into:
> Memory#1: freq = 456.0, offset = 456.7, duplex = 'split'

This of course messes up testing, because when reading back that memory from the map, things will
have changed from when it was put there from a high level perspective.

One solution would be to only support one of the either split, or non-split modes. I'd like to avoid that,
and have so far instead opted for a more hacky solution, which is to store extra data about the chosen
mode in some junk/unused bytes of the memory map. This is of course not really a good solution either,
the assumption that the bytes used for the setting is not used by the radio hardware is made from reverse
engineering and a sample of one.
As of now, the setting is easily enabled/disabled from a single boolean, so one could enable it to pass testing,
and then disable it for real use with real hardware.

A related issue is what tone modes to support, on a radio that from a hardware perspective always operates
in 'cross' mode, there is no way to discern between e.g. 'Tone' and 'Cross'+'Tone->' which is also something
that is tested.
Again, the available solutions are either restricting the feature set, or hope that some thought-to-be-unused
locations do not store the hitherto unactivated spectacularly-blow-up-the-radio setting.

Another solution I didn't think of before beginning on writing this mail, so it has not been tested, would be to create
extra member fields in the radio class, this would have the effect of not storing the extra settings between
instantiations of the class, but on the other hand no risks are taken with the radio hardware either.

I could certainly use some advice on the matter...

// Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160920/462f6190/attachment-0001.html