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

[Leo Bärring]

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
in the irc channel. What I did previously, was to try to mirror the functionality of the radio, as it is presented on the
radio, that is, VFO channels which on the hardware level work and operate in non-split mode always, default
to non-split modes in the corresponding channels in the chirp driver, when reading in data. Memory channels,
on the other hand default to split mode always, as that is how they operate and display.
This had me failing tests left and right for previously mentioned reasons.






After you mentioned that hams often prefer operating in non-split mode, I changed the driver to always default
to non-split mode no matter what's actually going on under the hood of the hardware.
And that seems to make it pass the tests.
I guess a conclusion to make from this could be that the tests check that memories that are put in as non-split,
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.
When it comes to the tone modes, I have for now set it to support 'Tone', and removed 'Tone->' from cross_modes, etc.
Thanks for all the help on irc by the way.
For anyone interested, the driver, as well as some auxillary code is available at https://github.com/tlvb/px888k_reverse
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
complete, and fine to test out. The driver depends on the patch for #4033 being applied (which depends on the patch
for #4031)
/Leo


-------- Original Message --------
Subject: Re: [chirp_devel] support 'split'/'-'/''/'+' frequency modes on only some channels and still pass unit tests?
Local Time: September 21, 2016 6:15 PM
UTC Time: September 21, 2016 4:15 PM
From: tom at tomh.us
To: Leo Bärring <leo.barring at protonmail.com>, chirp_devel at intrepid.danplanet.com <chirp_devel at intrepid.danplanet.com>

On Tue, Sep 20, 2016 at 8:16 AM, Leo Bärring via chirp_devel
<chirp_devel at intrepid.danplanet.com> wrote:
> 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'

Good, this is how we do it on many radios.

> 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.

We do this often enough that I think it must pass the tests. Which
test fails? When I test your code, it fails early due to invalid
default values (we discussed this), so I have not seen the failure
message related to offset/split. Can you provide the test log or code
to reproduce a failure in an offset/split test?

Tom KD7LXL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160921/58faff7e/attachment-0001.html