On 24/04/2020 17:14, Black Michael via wsjt-devel wrote:
Whaddya' mean no timeouts?
PollingTransceiver::PollingTransceiver (int poll_interval, QObject *
parent)
: TransceiverBase {parent}
, interval_ {poll_interval * 1000}
, poll_timer_ {nullptr}
, retries_ {0}
poll_timer_ = new QTimer {this}; // pass ownership to
// QObject which handles
// destruction for us
connect (poll_timer_, &QTimer::timeout, this,
&PollingTransceiver::handle_timeout);
I would be talking about rig_caps.timeout
Using that plus a fudge factor would allow more responsive behavior
for faster rigs and still allow for the slower ones.
And I would also expose the rig's timeout inside rigctld's rig_caps.
Mike
Mike,
that's not a timeout, its the polling interval. The thing that times out
is the QTimer object, every tick of that triggers a read of various rig
parameters like frequency and mode.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
