[chirp_devel] support 'split'/'-'/''/'+' frequency modes on only some channels and still pass unit tests?
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
On Tue, Sep 20, 2016 at 8:16 AM, Leo Bärring via chirp_devel chirp_devel@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
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@tomh.us To: Leo Bärring leo.barring@protonmail.com, chirp_devel@intrepid.danplanet.com chirp_devel@intrepid.danplanet.com
On Tue, Sep 20, 2016 at 8:16 AM, Leo Bärring via chirp_devel chirp_devel@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
participants (2)
-
Leo Bärring -
Tom Hayward