Hi Bill, please see my updates in line. 73 Simon G0FCU.
On Wed, 30 Sep 2020 at 21:29, Bill Somerville <g4...@classdesign.com> wrote: > Hi Simon, > > thanks for the issue report. Comments in line below. > > On 30/09/2020 21:00, Simon Kennedy wrote: > > Hi > > today I have reinstalled 2.3.0rc1 64 bit on ubuntu 20.04 from the deb > package with no problem. I have also compiled from source on my RPi Buster > successfully. > > The first bug I have confirmed exists I have replicated on ubuntu 20.04. > The use case is: > - start wsjtx > - change mode from an 'old' mode to FST4 or FST4W > - waterfall stops updating and wsjtx has to be killed from the command > line. > If the mode is already FST4 or FST4W then you can change to an 'old' mode > ok. > > I cannot readily reproduce this issue, can you give a more specific recipe > for reproduction please? > Ubuntu 20.04, new clean install using 64 bit deb package Start wsjtx Set mode=wspr, band=160m Exit wsjtx Start wsjtx from menu or command line (same behaviour exhibited) Change band to 630m Change mode to FST4W or FST4 Waterfall stops updating wsjtx process cpu usage jumps to 100% and stays there. File/Exit will close the program but the process does not end and stays at 100% cpu usage. I can replicate the same behaviour on the RPi when running from the command line but not when running from the menu. > > The second bug I have confirmed exists on the RPi. Use case: > - start wsjtx from command line like "wsjtx --rig-name=FST4W" > - enter Settings > - set radio to FT-817 on /dev/ttyUSB0 > - press 'Test CAT' > - output in terminal is: > pi@raspberrypi:~ $ wsjtx --rig-name=FST4W > libEGL warning: DRI2: failed to authenticate > qt5ct: using qt5ct plugin > qt5ct: D-Bus global menu: no > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > The Test PTT button does not activate. When starting wsjtx from the menu > option the 'Test CAT' button works as expected (although it doesn't turn > green but does activate the Test PTT button). > > The Hamlib messages to the console can be ignored, it is a Hamlib debug > message that has an error severity but it is not an error. If the "Test > CAT" button does not turn to green then it should turn red and an error > message bow will eventually appear, it may take a while due to retries. > > > On ubuntu 20.04 with my IC-7300 I get the following output: > simon@simon-desktop:~$ wsjtx --rig-name=FST4W > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > Hamlib: rig_get_vfo: no get_vfo > However, the Test CAT button does turn green but the Test PTT button does > not activate. As with the RPi when starting wsjtx from the menu option the > 'Test CAT' button works as expected. > > If the "Test PTT" button does not activate then you probably have > "Settings->Radio->PTT Method->VOX" selected. > Oops, you are correct. However, on the RPi the Test CAT button works as it then allows the Test PTT button to be pressed but the Test CAT button does not turn green (I think the same happened in the previous version). > > I have had another issue on the RPi where my FST4W signals stopped being > decoded by anyone. When I got the 20.04/7300 combo working I was able to > monitor my own signals and could see that although the tx frequency was set > to 1442 Hz the tones were actually being transmitted on 1228 Hz. I had > previously set the Rx freq to 1495 Hz, resetting this to 1500 Hz and it > works ok although I cannot replicate this issue. > > There is a kwnon issue in WSJT-X v2.3.0 RC1 that does not always > initialize the Tx audio offset to the Tx audio offset spin box, it is fixed > for the next release. You should be able to synchronize the Tx offset with > the spin box by changing the spin box value. > Noted, thanks. > > 73 Simon > G0FCU. > > 73 > Bill > G4WJS. > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel