Re: [wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?
Hi Bill, Ok. Will report back to you. I do not have the radio here right now and I would like to obtain it again to make sure the error occurs again before spending any more of your time on it. 73 Phil W1PJE On Sat, Jul 6, 2019 at 19:59 Bill Somerville wrote: > On 06/07/2019 23:59, Phil Erickson wrote: > > Hi Bill, > > > > I'm trying to trace problems documented in this previous message to > > the list: > > > > https://sourceforge.net/p/wsjt/mailman/message/36701791/ > > > > I'm happy not to try and compile a debug version if you happen to > > have any insight there! > > > > 73 > > Phil W1PJE > > > Hi Phil, > > you didn't say if you located the trace log file? > > Does rig control work if you set WSJT-X to talk directly to the rig over > the CI-V interface serial port? > > Do you have any offset set in "Settings->Frequencies->Station Details"? > > Please answer these questions before including any more information > about your setup or this issue. > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- Phil Erickson phil.erick...@gmail.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?
Hi Bill, I'm trying to trace problems documented in this previous message to the list: https://sourceforge.net/p/wsjt/mailman/message/36701791/ I'm happy not to try and compile a debug version if you happen to have any insight there! 73 Phil W1PJE On Sat, Jul 6, 2019 at 6:54 PM Bill Somerville wrote: > On 06/07/2019 23:30, Phil Erickson wrote: > > It made a new executable in /usr/local/bin as expected, but when I ran > > it, there is no sign of the "..trace.log" file in /tmp. > > HI Phil, > > the name of the trace log file is: > > /tmp/WSJT-X_trace.log > > or if you pass a --rig-name=xxx command line argument it will be: > > "/tmp/WSJT-X - xxx_trace.log" > > What CAT problems are you trying to fix? Have you tried using rigctld > (wsjtx-rigctld built with WSJT-X), with that you can get Hamlib CAT > trace information by starting the wsjtx_rigctld daemon with a -v > option. Connect to wsjtx_rigctld by selecting "Hamlib Net rigctl" as the > rig in WSJT-X "Settings->Radio->Rig". > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- Phil Erickson phil.erick...@gmail.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?
Hi all, Please forgive the somewhat newbie question (although I've been doing compiles since SysV days in the early 80s), but I cannot for the life of me get the debug trace log mode to compile in correctly using the latest Debian Stretch installation on a Raspberry Pi. Hopefully someone can point out what I'm doing wrong. I'm having some CAT problems and wanted to get debug traces. I first installed the prerequisites with "apt-get install" following this page: https://www.kk5jy.net/wsjtx-build/ I downloaded v2.0.1 and executed: tar -zxvf wsjtx-2.0.1.tgz mkdir build cd build I then executed "cmake-gui" and set the following switches on: WSJT_TRACE_CAT=ON WSJT_HAMLIB_TRACE=ON WSJT_HAMLIB_VERBOSE_TRACE=ON WSJT_QDEBUG_TO_FILE=ON WSJT_QDEBUG_IN_RELEASE=ON That generated the "CMakeCache.txt" file attached below, except that I further edited it after "cmake-gui" to set the build to CMAKE_BUILD_TYPE:STRING=RelWithDebInfo After that, I made the application as usual: make sudo make install It made a new executable in /usr/local/bin as expected, but when I ran it, there is no sign of the "..trace.log" file in /tmp. Furthermore, examining the binary shows I think that the needed debugging flags were never set on compile based on the following: cd /usr/local/bin strings wsjtx | grep trace.log (returns no output) I expected the above command to return a match since if WSJT_QDEBUG_TO_FILE were really on at compile time, the following code from "main.cpp" ought to have been included: #if WSJT_QDEBUG_TO_FILE // Open a trace file TraceFile trace_file {temp_dir.absoluteFilePath (a.applicationName () + "_trace.log")}; qSetMessagePattern ("[%{time MMdd HH:mm:ss.zzz t} %{if-debug}D%{endif}%{if-info}I%{endif}%{if-warning}W%{endif}%{if-critical}C%{endif}%{if-fatal}F%{endif}] %{file}:%{line} - %{message}"); qDebug () << program_title (revision ()) + " - Program startup"; #endif The first statement after the "#if" means I should have been able to find "trace.log" in a string within the compiled program somewhere. But I didn't. Any suggestions? Where did I mess up? I've spent a long time on this one and I'm pretty stumped. By the way, I also tried a "Debug" build type and that didn't work either. 73 Phil W1PJE # This is the CMakeCache file. # For build in directory: /home/pi/src/wsjtx/build_debug # It was generated by CMake: /usr/bin/cmake # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. # EXTERNAL cache entries //Path to a program. CMAKE_AR:FILEPATH=/usr/bin/ar //Choose the type of build, options are: None(CMAKE_CXX_FLAGS or // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. CMAKE_BUILD_TYPE:STRING=RelWithDebInfo //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //CXX compiler CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING=-O2 -march=native -mtune=native //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //C compiler CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc //Flags used by the compiler during all build types. CMAKE_C_FLAGS:STRING=-O2 -march=native -mtune=native //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Enable/Disable output of compile commands during generation. CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF //Install path prefix, prepended onto install
[wsjt-devel] Icom IC-746 Pro CAT control logic failure? (WSJT-X v2.0.1)
Hi all, Our club (N1NC; Nashoba Valley Amateur Radio Club) had a VHF station for FT8 this past weekend for Field Day and ran into an insurmountable WSJT-X control problem. I tried searching the list but did not come up with a hit so seeking collective wisdom. Rig: Icom IC-746 Pro Interface: CI-V cable with known working USB interface Computer: Raspberry Pi running latest Raspbian Stretch OS, updated WSJT-X version: 2.0.1 CAT software used: rigctld-wsjtx (Hamlib) talking to the 746 Pro; "Hamlib" option selected in the "Radio" tab. Rigctld command line (verbose mode turned on so I could decode): rigctld-wsjtx -m 346 -c 0x66 -s 9600 -v [NB: Model 346 is 746-Pro, 0.7 "stable"] Rig's VFO A was set to 50.313020 MHz when starting, and the VFO B was set to 50.318000 MHz from some previous activity. The server trace shows that the serial line was fine - all responses in both directions (rig to computer, computer to rig) were fine at the hex code level. WSJT-X started up, the program got useful information and then went into its polling loop: rigctl(d): F 'currVFO' '50313020.00' '' '' rigctl(d): s 'currVFO' '' '' '' rigctl(d): f 'currVFO' '' '' '' rigctl(d): m 'currVFO' '' '' '' rigctl(d): t 'currVFO' '' '' '' <> The first line is "set frequency to the current dial frequency" which the rig did correctly. The second one is "get split VFO mode", in case things were set to split (they were not). Then the triplet loop is "get frequency", "get mode", and "get PTT status". No problems. But then, when I clicked "TUNE" in the program, the following command was sent by WSJT-X: rigctl(d): F 'currVFO' '100631020.00' '' '' This tried to set the rig to a frequency of 100+ MHz out of the blue. The rig responded properly with "Illegal command" (the first time it threw this error) as it's not allowed to go there in frequency. WSJT-X responded with rigctl(d): T 'currVFO' '0' '' '' which translates into "Wow, we're in error - make sure we turn PTT back to off" and then it went back to its polling loop. (Ironically, it never got to turn it ON due to the error so I guess it was being paranoid.) So where did this mysterious frequency come from? Notice that 100631020 - 50313020 = 50318000 So somehow, the logic screwed up, added the two VFO frequencies together, and tried to tune to that. This problem was repeatable across multiple rig power cycles, WSJT-X abort and restarts, computer power reboots, etc. Any wisdom here? I don't have the rig with me now but could re-obtain it. I ended up making a few contacts by setting "Radio" to NONE and manually pushing the PTT button during transmit, but I'd rather not do that again. 73 Phil W1PJE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel