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.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
