<div>I did find a solution, sort of, maybe I missed to mention it, or it was just buried in my mind-dump kind of writing<br></div><div>in the irc channel. What I did previously, was to try to mirror the functionality of the radio, as it is presented on the<br></div><div>radio, that is, VFO channels which on the hardware level work and operate in non-split mode always, default<br></div><div>to non-split modes in the corresponding channels in the chirp driver, when reading in data. Memory channels,<br></div><div>on the other hand default to split mode always, as that is how they operate and display.<br></div><div>This had me failing tests left and right for previously mentioned reasons.<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><div>After you mentioned that hams often prefer operating in non-split mode, I changed the driver to always default<br></div><div>to non-split mode no matter what's actually going on under the hood of the hardware.<br></div><div>And that seems to make it pass the tests.<br></div><div>I guess a conclusion to make from this could be that the tests check that memories that are put in as non-split,<br></div><div>are read out as non-split, but it does not test that split memories are read back as split, but I have not verified this.<br></div><div>When it comes to the tone modes, I have for now set it to support 'Tone', and removed 'Tone-&gt;' from cross_modes, etc.<br></div><div>Thanks for all the help on irc by the way.<br></div><div>For anyone interested, the driver, as well as some auxillary code is available at <a href="https://github.com/tlvb/px888k_reverse">https://github.com/tlvb/px888k_reverse</a><br></div><div>I do not yet consider it ready for inclusion in chirp, so I haven't sent in any patches yet, but it should be mostly<br></div><div>complete, and fine to test out. The driver depends on the patch for #4033 being applied (which depends on the patch<br></div><div>for #4031)<br></div><div>/Leo<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div>-------- Original Message --------<br></div><div>Subject: Re: [chirp_devel] support 'split'/'-'/''/'+' frequency modes on only some channels and still pass unit tests?<br></div><div>Local Time: September 21, 2016 6:15 PM<br></div><div>UTC Time: September 21, 2016 4:15 PM<br></div><div>From: tom@tomh.us<br></div><div>To: Leo Bärring &lt;leo.barring@protonmail.com&gt;, chirp_devel@intrepid.danplanet.com &lt;chirp_devel@intrepid.danplanet.com&gt;<br></div><div><br></div><div>On Tue, Sep 20, 2016 at 8:16 AM, Leo Bärring via chirp_devel<br></div><div>&lt;chirp_devel@intrepid.danplanet.com&gt; wrote:<br></div><div>&gt; So far so good. The problem is that what modes to support is declared once,<br></div><div>&gt; and for the whole radio,<br></div><div>&gt; so for rf.valid_duplexes I put all of them, and if the user tries to set a<br></div><div>&gt; mode that is not supported<br></div><div>&gt; for that particular memory, it is converted to one that is, e.g:<br></div><div>&gt;&gt; Memory#1: freq = 456.0, offset = 0.7, duplex = '+'<br></div><div>&gt; when stored to the memory map, turns into:<br></div><div>&gt;&gt; Memory#1: freq = 456.0, offset = 456.7, duplex = 'split'<br></div><div><br></div><div>Good, this is how we do it on many radios.<br></div><div><br></div><div>&gt; This of course messes up testing, because when reading back that memory from<br></div><div>&gt; the map, things will<br></div><div>&gt; have changed from when it was put there from a high level perspective.<br></div><div><br></div><div>We do this often enough that I think it must pass the tests. Which<br></div><div>test fails? When I test your code, it fails early due to invalid<br></div><div>default values (we discussed this), so I have not seen the failure<br></div><div>message related to offset/split. Can you provide the test log or code<br></div><div>to reproduce a failure in an offset/split test?<br></div><div><br></div><div>Tom KD7LXL<br></div></blockquote><div><br></div>