<div dir="ltr"><div>Thanks, Dan. I will look at forcing the &quot;off&quot;. (As a newbie Ham, it did not even occur to me that &quot;duplex==off&quot; must meand &quot;TX disabled&quot;.) 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.</div><div><br></div><div>With respect to the MARS/CAP mod: It appears that this basically turns the FT-4XR or FT-4 XE into the &quot;Asian&quot; version, which  in effect removes the regulatory restriction and lets you use the radio&#39;s entire UHF and VHF capability. A user could then select the &quot;Asian&quot; version if they mod the radio.<br></div><div><br></div><div>That was going to be my next question. I propose to add two new radios: FT-4XE and FT-4(Asian).</div><div>Since I don&#39;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?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2019 at 1:16 PM Dan Smith via chirp_devel &lt;<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; 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<br>
<br>
If you support the duplex &quot;off&quot; that means no TX is allowed. I&#39;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 &quot;off&quot; duplex.<br>
<br>
&gt; 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.<br>
<br>
Similarly, they can choose &quot;off&quot; as the duplex if they want to tx-disable a channel. We could just make the tests not freak out if your radio supports &quot;off&quot; and we set a memory that comes back with that duplex.<br>
<br>
That said, I&#39;m not really sure it&#39;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 &quot;this whole band is receive-only&quot; does not seem substantially different to me and thus my choice would be to just leave it as ambiguous.<br>
<br>
--Dan<br>
_______________________________________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br>
</blockquote></div>