On 02/08/2014 04:48, jeff millar wrote:
Hi Bill...
Hi Jeff,
replying off list ...
I had some time after work and was able to create a log file showing
the error clearly.
OK, well it seems that there is no response to the very first CAT
command sent after PTT is asserted. The first response is a simple echo
of the command sent since the C-IV bus is one-wire and outgoing commands
are read back in.
I can't get any useful information from the log other than that so I
think we need to try some experiments with your set up. Can you set "PTT
Method" to "VOX" (don't change the rig), this will allow the program to
go through the motions of transmitting without actually engaging PTT on
the rig. Carry out the same test as before and send me the
wsjtx_trace.log file again please. If there is no error; click "Tune"
again to return to RX mode and terminate the program.
Sorry this is taking so long to diagnose.
jeff, wa1hco
73
Bill
G4WJS.
On 08/01/2014 08:11 AM, Bill Somerville wrote:
On 01/08/2014 12:28, jeff millar wrote:
Hi Bill...
Hi Jeff,
Thanks for the ideas. I'm off to vacation for a week and will not
have access to the desktop or radio for that time. I will try your
debugging build next weekend.
OK, enjoy the break, we can pick this up later.
The input level is reported and control with pulse audio volume
control or the pull down audio control on the top bar. I'm watching
the slider position for Input Audio and stepping the code. one more
click on "step into" causes the input level go from about 20% to 100%.
The audio controls do work on my VM so I will see if I can reproduce
that behaviour.
That line of code is emitting a Qt signal and in this case it is
crossing a thread boundary so it is not a simple function call that
is going on. QtCreator may not follow that signal to any connected
slots in the target thread(s), I don't use QtCreator for debugging so
I'm not 100% sure on the mechanics. If I can reproduce it; I will set
break points on the target slots and see if I can track down what is
happening here.
If it were the signal emission in the MainWindow constructor; then it
is quite possible that the previous line is the one that is causing
the issue you see. The previous line is emitting another signal which
is starting the audio input stream, again via an inter-thread signal
to slot connection. It is quite possible that the target thread
doesn't run and dequeue the message until the line you cite runs. You
can trace this in debug by setting a break point on SoundInput::start
which is the target slot of the MainWindow::startAudioInputStream
signal. Then step through that to see what line causes the level reset.
This probably boils down to the fact that Qt creates a new stream
(and stream name) for every audio connection and the we have no
control of the stream name. This means that levels set via the system
or pavucontrol are not remembered between runs. You will probably
have to set the RX level via the WSJT-X level slider rather than the
system. IIRC the slider in WSJT-X doesn't change the stream slider,
we do our own gain processing on the audio received. I would think
that given two different digital level controls (pulseaudio and ours)
in series; it is probably best to have one or the other at 0dB anyway
as each stage of attenuation is likely to introduce artefacts so only
using one of them is best.
We have raised an issue report to Qt on this but AFAIK no one has
picked it up and submitted a fix. On Windows since 7 the levels are
associated with the executable name that set them. In pulseaudio the
levels are associated with the stream name so not being able to set
the stream name is IMHO a Qt defect.
jeff, wa1hco
Hope this helps & 73
Bill
G4WJS.
On 08/01/2014 05:10 AM, Bill Somerville wrote:
On 01/08/2014 04:42, jeff millar wrote:
Hi Jeff,
Sorry you are having some issues with the current WSJT-X code.
First problem: Most of the time, when starting a transmission or
using the Tune button, WSJTX throws a "Rig Control Error Hamlib
error: Invalid parameter while getting current VFO frequency".
This occurs about 1 sec after starting a transmission. But
sometimes it runs ok for a while without throwing errors. The
Test CAT button doesn't show a problem. I can browse the bands
with the band select button without seeing the problem.
So I can see what is going on here can you build a version that has
CAT diagnostics enabled. Details of a way to do that are in this
posting:
https://sourceforge.net/p/wsjt/mailman/message/32650244/
Once built; run the application to reproduce the issues then close
it. The file wsjtx_trace.log is created in the directory that the
binary was in. Compress and send me that file (directly is probably
best) and I'll have a look at what is going on.
Second problem: Whenever WSJTX starts up it somehow resets the
input level to 100%. I traced this down to this line in
mainwindow.cpp
Q_EMIT initializeAudioOutputStream (m_config.audio_output_device
(), AudioDevice::Mono == m_config.audio_output_channel () ? 1 : 2,
m_msAudioOutputBuffered);
any ideas?
That line is the initialisation of the audio output stream, that
has to be done before it can be used. That should only effect TX
audio so I am surprised that it is having any impact on RX audio.
Unfortunately I only have Linux on a VM and the audio drivers for
the VM do not support input audio so I cannot debug this issue here.
When you say "resets input level to 100%" where are you seeing that?
jeff, wa1hco
I'm running WSJTX, r1.4, r4224 on Ubuntu 14.04. Hamlib is V3.0.
IC-746PRO. PTT method by RTS.
Application output from qtcreator...
ig_set_conf: serial_handshake='None'
rig_set_conf: ptt_pathname='/dev/ttyUSB1'
rig_set_conf: ptt_type='RTS'
rig:rig_open called
read_string(): Timed out 0.200237 seconds without reading a
character.
read_string(): Timed out 0.200235 seconds without reading a
character.
read_string(): Timed out 0.200244 seconds without reading a
character.
read_string(): Timed out 0.200218 seconds without reading a
character.
rig:rig_close called
rig:rig_close called
rig:rig_cleanup called
QDialog::exec: Recursive call detected
Got a buffer underflow!
Got a buffer underflow!
Got a buffer underflow!
Got a buffer underflow!
The only issue I see with that output is the read_string() time
outs which implies that the CAT module is not getting any response
from the rig from a command sent to it at some point, the
diagnostic trace should help with that too.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
