On 24/03/2016 19:22, Dave 'Doc' Corio wrote: > I can confirm that the issue is still there. When I move the > frequency up using the indicator on the wide graph, then move it back > down, the VFO often gets "stuck" on VFO "B" instead of completing the > change back to "A". Again, it is not consistent, and happens maybe once > or twice out of 4 changes. Hi Dave,
I need to get a trace of the Hamlib traffic to see what is happening. To do this you need to set some CMake options on the WSJT-X build. The easiest way to do this is to use the cmake-gui tool as follows: cmake-gui <path-to-build-tree> where <path-to-buld-tree> is the root directory of the WSJT-X build tree. I'm not sure exactly where the build tree root is when using the JTSDK but I suspect Greg will reply with the information. The options you need to set are: WSJT_QDEBUG_TO_FILE=ON WSJT_TRACE_CAT=ON WSJT_HAMLIB_TRACE=ON WSJT_QDEBUG_IN_RELEASE=ON once those are set, click the "Configure" button. That adds another option which you also need to set: WSJT_HAMLIB_VERBOSE_TRACE=ON then click "Configure" and then "Generate". Do the wsjtx build again and then do whatever is needed to reproduce the issue then quit the application. It will have created a trace file: %TEMP%\WSJT-X_trace.log Send me that file for analysis please. 73 Bill G4WJS. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
