[chirp_devel] receive-only channels?
is there a way to indicate that a channel is receive-only? The FT-4 is tri-band for receive, but (clearly) does not transmit on the FM broadcast frequencies. In UHF and VHF, the receive-only frequency ranges are larger than the allowed TX frequencies of rthe European and US versions. My current code is schizophrenic: my valid_bands list has the full receive-only band for FM broadcast but only the TX-allowed bands for VHF and UHF I would like to permit a user to program the RO frequencies but to know that TX will be disabled on that channel, and for the test suite to work with this.
is there a way to indicate that a channel is receive-only? The FT-4 is tri-band for receive, but (clearly) does not transmit on the FM broadcast frequencies. In UHF and VHF, the receive-only frequency ranges are larger than the allowed TX frequencies of rthe European and US versions. My current code is schizophrenic: my valid_bands list has the full receive-only band for FM broadcast but only the TX-allowed bands for VHF and UHF
If you support the duplex "off" that means no TX is allowed. I'd say that if they program something in the RX-only range, just ignore the duplex and offset they provide, and force the memory back to "off" duplex.
I would like to permit a user to program the RO frequencies but to know that TX will be disabled on that channel, and for the test suite to work with this.
Similarly, they can choose "off" as the duplex if they want to tx-disable a channel. We could just make the tests not freak out if your radio supports "off" and we set a memory that comes back with that duplex.
That said, I'm not really sure it's that important to communicate to the user that a frequency they have programmed will not be transmit-able by the radio, as this could also depend on whether or not they have done the MARS/CAP mod. With the latter mod, the frequencies at the edges of bands that are normally only supported for receive become valid for transmit. Conveying that "this whole band is receive-only" does not seem substantially different to me and thus my choice would be to just leave it as ambiguous.
--Dan
Thanks, Dan. I will look at forcing the "off". (As a newbie Ham, it did not even occur to me that "duplex==off" must meand "TX disabled".) I will run the tests and see what happens, and patch the test code to make it work. I think you will want to review any changes I make to the test code very carefully before accepting them.
With respect to the MARS/CAP mod: It appears that this basically turns the FT-4XR or FT-4 XE into the "Asian" version, which in effect removes the regulatory restriction and lets you use the radio's entire UHF and VHF capability. A user could then select the "Asian" version if they mod the radio.
That was going to be my next question. I propose to add two new radios: FT-4XE and FT-4(Asian). Since I don't understand the aliasing scheme, I intended to subclass the FT-4 class and modify only the frequencies (and the step size), so the number of lines of code is truly tiny. However, this will add these radio names to the list of Yaesu radios as full top-level peers, not aliases or something. Is this acceptable?
On Thu, Mar 14, 2019 at 1:16 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
is there a way to indicate that a channel is receive-only? The FT-4 is
tri-band for receive, but (clearly) does not transmit on the FM broadcast frequencies. In UHF and VHF, the receive-only frequency ranges are larger than the allowed TX frequencies of rthe European and US versions. My current code is schizophrenic: my valid_bands list has the full receive-only band for FM broadcast but only the TX-allowed bands for VHF and UHF
If you support the duplex "off" that means no TX is allowed. I'd say that if they program something in the RX-only range, just ignore the duplex and offset they provide, and force the memory back to "off" duplex.
I would like to permit a user to program the RO frequencies but to know
that TX will be disabled on that channel, and for the test suite to work with this.
Similarly, they can choose "off" as the duplex if they want to tx-disable a channel. We could just make the tests not freak out if your radio supports "off" and we set a memory that comes back with that duplex.
That said, I'm not really sure it's that important to communicate to the user that a frequency they have programmed will not be transmit-able by the radio, as this could also depend on whether or not they have done the MARS/CAP mod. With the latter mod, the frequencies at the edges of bands that are normally only supported for receive become valid for transmit. Conveying that "this whole band is receive-only" does not seem substantially different to me and thus my choice would be to just leave it as ambiguous.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
Thanks, Dan. I will look at forcing the "off". (As a newbie Ham, it did not even occur to me that "duplex==off" must meand "TX disabled".)
It's not the best of names, obviously, but like everything else it came about because one driver wanted to support it and engineering/respecting a new boolean would have been a lot more work. In reality the duplex field is "What do I do when I transmit?"
I will run the tests and see what happens, and patch the test code to make it work. I think you will want to review any changes I make to the test code very carefully before accepting them.
Thanks for being willing to try that. The test code needs a major overhaul, and I have plans to do that, but ... you know how that goes.
With respect to the MARS/CAP mod: It appears that this basically turns the FT-4XR or FT-4 XE into the "Asian" version, which in effect removes the regulatory restriction and lets you use the radio's entire UHF and VHF capability. A user could then select the "Asian" version if they mod the radio.
Do note that with other Yaesus, once you make that mod, they identify themselves on the serial line as a different model.
That was going to be my next question. I propose to add two new radios: FT-4XE and FT-4(Asian). Since I don't understand the aliasing scheme, I intended to subclass the FT-4 class and modify only the frequencies (and the step size), so the number of lines of code is truly tiny. However, this will add these radio names to the list of Yaesu radios as full top-level peers, not aliases or something. Is this acceptable?
Aliases are purely a shortcut to make one driver show up under two names (like MANY of the chinese radios). If you want anything at all to be different (other than VENDOR and MODEL), you want a subclass.
--Dan
participants (2)
-
Dan Clemmensen -
Dan Smith