<div>Writing a driver for the Puxing PX-888K HT I'm wondering if there is a way to support that not all<br></div><div>channels support all duplex modes. More to the point, there are 128 regular memories, as well as<br></div><div>three special channels, VFO-A, VFO-B, and CALL.<br></div><div>The call channel is equal to the memory channels in all but storage location and how to access it<br></div><div>on the radio hardware: they always operate in 'split' mode, that is two numbers are stored,<br></div><div>rx and tx frequencies. The vfo channels on the other hand, always operate in '-'/''/'+' mode,<br></div><div>the rx frequency is stored and the tx frequency is determined by an offset and a sign.<br></div><div><br></div><div>So far so good. The problem is that what modes to support is declared once, and for the whole radio,<br></div><div>so for rf.valid_duplexes I put all of them, and if the user tries to set a mode that is not supported<br></div><div>for that particular memory, it is converted to one that is, e.g:<br></div><div>&gt; Memory#1: freq = 456.0, offset = 0.7, duplex = '+'<br></div><div>when stored to the memory map, turns into:<br></div><div>&gt; Memory#1: freq = 456.0, offset = 456.7, duplex = 'split'<br></div><div><br></div><div>This of course messes up testing, because when reading back that memory from the map, things will<br></div><div>have changed from when it was put there from a high level perspective.<br></div><div><br></div><div>One solution would be to only support one of the either split, or non-split modes. I'd like to avoid that,<br></div><div>and have so far instead opted for a more hacky solution, which is to store extra data about the chosen<br></div><div>mode in some junk/unused bytes of the memory map. This is of course not really a good solution either,<br></div><div>the assumption that the bytes used for the setting is not used by the radio hardware is made from reverse<br></div><div>engineering and a sample of one.<br></div><div>As of now, the setting is easily enabled/disabled from a single boolean, so one could enable it to pass testing,<br></div><div>and then disable it for real use with real hardware.<br></div><div><br></div><div>A related issue is what tone modes to support, on a radio that from a hardware perspective always operates<br></div><div> in 'cross' mode, there is no way to discern between e.g. 'Tone' and 'Cross'+'Tone-&gt;' which is also something<br></div><div>that is tested.<br></div><div>Again, the available solutions are either restricting the feature set, or hope that some thought-to-be-unused<br></div><div>locations do not store the hitherto unactivated spectacularly-blow-up-the-radio setting.<br></div><div><br></div><div>Another solution I didn't think of before beginning on writing this mail, so it has not been tested, would be to create<br></div><div>extra member fields in the radio class, this would have the effect of not storing the extra settings between<br></div><div>instantiations of the class, but on the other hand no risks are taken with the radio hardware either.<br></div><div><br></div><div>I could certainly use some advice on the matter...<br></div><div><br></div><div>// Leo<br></div><div class="protonmail_signature_block-empty"><br></div><div class="protonmail_signature_block protonmail_signature_block-empty"><div class="protonmail_signature_block-user protonmail_signature_block-empty"><div><br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div class="protonmail_signature_block-empty"><br></div>