On 04/08/2015 04:54, Michael Black wrote:
Hi Mike,
OK…this covers hamlib users only since there is no external program to
provide power feedback. Perhaps OmniRig is another contender.
No, OmniRIg has a very limited set of rig functions which is unlikely to
change and meter level isn't one of them.
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.
No interfaces are broken AFAICS. A few suggestions:
You need to allow for some non-success status from the Hamlib
rig_get_level() API, it probably returns errors for rigs with no
capability or where the function is not implemented.
Power is not a good variable name for something that holds either power
or signal strength, meter or meter_level would be my preference. Better
still would be to have two variables for power and signal strength and
have the concrete Transceiver implementation class decide which is
which. You can rely on state().ptt() returning the current Tx state in a
Transceiver implementation, it is correct even when VOX is used although
perhaps slightly out of sync due to delayed audio and VOX delay etc..
The MainWindow class is not the place to do conversions to S meter
levels, IMHO that should be done at source (e.g. where you call the
Hamlib API).
Don't use char arrays and sprintf() for strings that are destined for
the UI, Qt uses unicode strings and QString is by far the cleanest and
most efficient way to handle them in a Qt application. It is a huge
class but it is worth learning how it works if you are going to do any
Qt programming. I know it's not your code but you are adding more of the
same bad stuff. For example you could use something like:
if (m_transmitting)
{
// ...
// deal with nsendingsh which I don't fully understand :(
QString tx_status {msgsent};
if (m_tune)
{
tx_status = "TUNE";
}
else if ("Echo" == m_mode)
{
tx_status = "ECHO";
}
QString power;
if (m_meter_level >= 0) // what does negative mean here?
{
power = QString {"%1W"}.arg (m_meter_level);
}
tx_status_label->setText (QString {Tx: %1 %2"}.arg
(tx_status).arg (power).trimmed ());
}
else if (m_monitoring)
{
// ...
QString s_meter;
if (m_meter_level >= 0)
{
s_meter = QString {"S%1"}.arg (m_meter_level);
}
tx_status_label->setText (QString {"Receiving %1").arg
(s_meter).trimmed ());
// ...
}
73
Mike W9MDB
73
Bill
G4WJS.
*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.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
