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. > > 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 > > 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. ------------------------------------------------------------------------------ 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
