<div dir="ltr"><div class="gmail_extra">On Mon, May 26, 2014 at 9:41 AM, John Warburton G4IRN <span dir="ltr"><<a href="mailto:qrz@dxdx.co.uk" target="_blank">qrz@dxdx.co.uk</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I am modifying one of my earlier LUA scripts and I would like to do the following over a two radio (and 2 x Win-Test) network:<br>
<br>
* Running a LUA script on Radio1, determine the Run / S&P status of Radio2.<br></blockquote><div><br></div><div class="gmail_extra">As of now you cannot determine the RUN or S&P status with a LUA script, only the station type (RUN/SUPPORT). But maybe you don't really need it.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I suppose you need to know if the frequency displayed in the status window (or returned by a LUA call) is "safe" to use as a pass frequency. Maybe it's not really a good frequency if the operator is busy chasing a multiplier. I made that mistake once: I passed an easy multpiler to the VFO frequency displayed in the status (Alt+J) window, not realizing that the other operator wasn't actually CQing there (he was temporarily chasing as spot).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">At a multi-op, it just isn't that practical for operators to constantly update PASSFREQ or manually switch to S&P mode every time they click on a spot. It's simpler for other operators to always pass multipliers to an established run frequency.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Win-Test actually knows the run frequency. This is established automatically whenever you press F1 or Alt+F5 (a "CQ" marker is optionally displayed in the band map). It would be nice if Win-Test could display <i>this</i> run frequency in the Alt+J window. Maybe an asterisk next to a VFO frequency could imply "Caution: operator not CQing there."</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Or maybe it could be returned by an enhancement to the wtStatus:GetStatus() method, e.g.</div><div class="gmail_extra"><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div class="gmail_extra">wtStatus:GetStatus("Stn1")["runFreq"] -- (not supported yet)</div></blockquote><div class="gmail_extra"><div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* Running a LUA script on Radio1 , determine the pass frequency (PassFreq) of Radio2 on a band that it is not currently tuned to.<br></blockquote><div><br></div><div>wtStatus:GetStatus("passFreq") always returns the pass frequency associated with the primary radio (switched via [*] key), never the secondary. It returns whatever you see under "PASS" in the Status window.</div>
<div><br></div><div>Unfortunately, wtStatus:GetFreq(band,mode) and $FREQnn do not work as you might expect if you have two radios on a computer. It always seems to return the current frequency of Radio 1, even if Radio 2 is made primary. For example, wtStatus:GetFreq(10,"CW") or $FREQ10 looks for the <i>station</i> that has a radio on 10m, then returns the frequency of Radio 1 (which may <i>not</i> be on 10m). This is mainly problem when an SO2R station is temporarily configured as a M/2 or M/S, with two radios per operator. With only one radio per computer, it's never a problem.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I suspect that neither of these is possible, however I thought it best to ask before I give up.<br>
</blockquote><div><br></div><div>Minor enhancements to GetStatus() could support new fields: "runFreq", "passfreqP" (primary), and "passfreqS". I also think it's very confusing for $FREQ10 or GetFreq(10) to return anything other than a 10m frequency, but that's how they work at present. I don't think there are too many people relying on that so the behavior could be changed without worrying about any compatibility issues, but maybe there are technical reasons that it had to work this way.</div>
<div><br></div><div>73,<br></div><div class="gmail_extra"><div>Bob, N6TV</div></div></div></div></div>