OK.this covers hamlib users only since there is no external program to provide power feedback. Perhaps OmniRig is another contender.
Io it adds an S-level on RX and Watts on TX to the status box in the lower left corner. I tested it on two rigs. My Omni VII works on both TX and RX and the ICOM 706MKIIG only on RX (appears you can't get the transmit power level on it). If there is no return nothing is added. I think there may be some question as to what all the rigs may return when in transmit mode but it appears most return watts from what I see. If anybody cares to try this and see how it affects them or if it breaks the interface it would be appreciated. Any funky readings please provide a trace log or at least a rig model# so I can see what it thinks it is providing. 73 Mike W9MDB From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Monday, August 03, 2015 10:40 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Power/S-Level On 03/08/2015 15:52, Michael Black wrote: Hi Mike, I'm working on patch to add power (attached) and S-level to the transmit/receive status entry in the lower-left corner of WSJT-X. This is a fairly ambitions project as the various ways of achieving rig control are difficult to rationalize to a single function. I'm successfully reading the value and storing it along with frequency and such but am a bit lost on how to get to the value from mainwindow.cpp. There are several issues. Firstly the rig control interface is all done through a common abstract base class called Transceiver. An instance of that is created by TransceiverFactory on behalf of Configuration. The Configuration class instance publishes a common and simple interface for rig control that is suitable for use in the GUI code from in the main GUI thread. Configuration wraps all the calls to the Transceiver instance in a thread safe way by using the Qt signal/slot mechanism. You are basically proposing a new signal to be emitted by the Transceiver class, this in turn needs to be re-emitted by Configuration so that MainWindow for example can connect a slot to it that displays the meter status. An additional complexity is that you will have to poll for the meter status. Currently rig polling is managed generically by PollingTransceiver which is a helper class which sits in the Transceiver class hierarchy above any Transceiver concrete implementation class (HamlibTransceiver, DXLabSuiteCommanderTransceiver, HRDTransceiver at present, OmniRigTransceiver is asynchronous and does not require polling). PollingTransceiver would probably have to be enhanced to run a separate timer for meter polling by running a parallel polling mechanism if different polling rates for the meter and the VFO(s) wre required - See below. TransceiverBase sits just below the Transceiver abstract base class in the hierarchy and provides generic utilities to any transceiver concrete implementation class and would be the place to coordinate signals containing meter status updates. It already does similar stuff to coordinate Transceiver status updates and failure notifications. Here's an example of reading the value from an Omni VII Mon Aug 3 14:47:00 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_get_level: vfo=currVFO level=1073741824 val=7 Mon Aug 3 14:47:00 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:687)Debug: virtual void HamlibTransceiver::poll() current power/level = 7 Mon Aug 3 14:47:03 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_get_level: power= 4W Mon Aug 3 14:47:03 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_get_level: vfo=currVFO level=1073741824 val=4 Mon Aug 3 14:47:03 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:687)Debug: virtual void HamlibTransceiver::poll() current power/level = 4 Mon Aug 3 14:47:06 2015 GMT(C:\JTSDK\src\wsjtx\HamlibTransceiver.cpp:49)Debug: Hamlib: tt588_get_level: level= S7 So in receive mode you'll see "Sn" and transmit mode you'll see "nW" of effective power (or whatever your rig interface returns). I'm not sure polling meter readings at the same rate as other transceiver state is the correct way to do this, one reason being that many rigs and other means of rig control do not have a way of getting this information, also the extra traffic may be an issue. If you were to take this approach then the TransceiverState class in Transceiver.hpp would need to updated with a new member to reflect a common number that represents a meaningful meter reading. Adding to the TransceiverState class would be much easier so long as you had a good way of representing no information (NULL) for the many unsupported rigs and other interfaces. Obviously this should be an option and will eventually handle any 0 returns by not adding anything to the message. Looking through a few rigs in hamlib it seems the RAWSTR and STRENGTH values are handled inconsistently. I have not looked that closely but there does seem to be differences between Hamlib back ends and probably through HRD also. DX Lab Suite Commander has no facility to query meter reading although it can and does display them in its own GUI. HRD can be queried but it is a mess of different protocols on a per rig basis, like DX Labs it already displays meter status through its GUI. Another issue may be that some rigs return the power control setting were others may return RF power at he meter bridge, given that we provide an audio level control the information is not necessarily useful and almost certainly ambiguous. Thoughts? My initial thoughts are that this is well outside of the scope of WSJT-X and should be handled by one of the more specialized rig control programs that we support such as HRD or DX Lab Suite Commander, these applications already have an on screen representation of things like meter readings. Since these applications tend to include logging there is a problem for those that want to use different logging applications that don't provide an interface for other clients to control the rig. IMHO we would do better to encourage the providers of those other applications that require rig control for their other aspects like logging to also provide a means of rig control for the basic subset of functions required for WSJT-X to do its job: Set/query frequency, optionally control PTT, optionally set mode and, optionally enable/disable and set/query a split transmit VFO. We don't require much but getting all that rationalized across all rigs and other rig control applications is non-trivial, adding another facet will increase the complexity considerably. 73 Mike W9MDB 73 Bill G4WJS.
patchpower
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
