On 08/07/2015 20:24, Steven Franke wrote:
Mike and Bill,
Hi Steve,
On Jul 8, 2015, at 6:58 PM, Bill Somerville <g4...@classdesign.com
<mailto:g4...@classdesign.com>> wrote:
On 08/07/2015 19:43, Steven Franke wrote:
Bill,
Hi Steve,
I just updated back to r5700 and the problem that I described
yesterday occurred after the first transmission. I captured the
following from the trace file:
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical:
Hamlib: kenwood_transaction: Unknown command or rig busy 'FA00024924600'
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical:
Hamlib: kenwood_transaction: Retrying shortly
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical:
Hamlib: kenwood_transaction: Unknown command or rig busy 'FA00024924600'
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical:
Hamlib: kenwood_transaction: Retrying shortly
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical:
Hamlib: kenwood_transaction: Unknown command or rig busy 'FA00024924600'
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical:
Hamlib: kenwood_transaction: Retrying shortly
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical:
Hamlib: kenwood_transaction: Unknown command or rig busy 'FA00024924600'
This behaviour was why we improved the command verification and added
more automatic retries for Kenwood rigs in Hamlib. It looks like we need
even more automatic retries. I would like to know what is making the rig
give busy responses to this CAT command. Is this perhaps while the auto
ATU is tuning? Another instance of this was related to the rig
announcing band or mode changes, I believe that was on the TS-440s which
has a fairly limited CPU capability.
The rig is not auto-tuning (i.e. it is not running the routine that
tries to find the settings that give a match), although since it was
requested to change bands from 15m to 12m and if things had worked
properly, it would have looked up the saved matching-network settings
and setting the matching-network relays accordingly.
The rig is not announcing any changes (as far as I know).
This time (and one of the 4 times that I observed this yesterday)
there was no dialog box. The other 3 times, a dialog box appeared,
asking me if I wanted to re-configure the radio. In all 5 cases, TX
Enable turned from red to white. In the two cases when the dialog
box failed to appear, the rig continued to hop in receive mode. In
the cases when the dialog box appeared, the rig stopped changing
bands, whereas the software continued to “hop”.
Would it be more helpful if I switch on “WSJT_TRACE_CAT_POLLS”?
It will help to clarify what happened before this issue. You probably
need to turn on a few options. If you are using a debug configuration
build (CMAKE_BUILD_TYPE=Debug) then turn on the following CMake options:
WSJT_HAMLIB_TRACE=ON
WSJT_QDEBUG_TO_FILE=ON
WSJT_TRACE_CAT=ON
WSJT_TRACE_CAT_POLLS=ON
WSJT_HAMLIB_VERBOSE_TRACE=ON
if you are using a release configuration build (the default), add
this too:
WSJT_QDEBUG_IN_RELEASE=ON
These will write verbose trace to /tmp/WSJT-X_trace.log
OK, I’ve done this. I’ve placed the trace log here:
https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace.log
The error event occurs at 19:13:53.
Thanks for that. That's not behaviour I've seen before, prior cases have
been where an "IF;" just after changing bands would need some retries.
The instance right at the end of the trace is also weird, it has gone
busy after a switch from TX to RX command. That last case has no
following trace, did you edit the trace file?
Mike's suggestion of increasing the timeout is a good first step, would
you like me to build a Mac DMG with that in? Either that or I can send
you a patch for Hamlib.
Note that I have not updated hamlib recently.
I don't think there is any recent Hamlib change that would have
caused this.
Steve k9an
73
Bill
G4WJS.
Steve k9an
73
Bill
G4WJS.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
