Re: [wsjt-devel] Question about transmit hazard via mouse wheel

[alan2--- via wsjt-devel]

On my TS590S, testing at low power into a dummy load, while in Tx the 
rig ignores trying to change the band using the front panel, although I 
can vary the frequency within the selected band.


With WSJT-X transmitting stops immediately if I try to change bands, and 
it's apparently the audio drive that disappears rather than the rig 
hardware stopping Tx.  In those circumstances the rig does not change 
frequency either.


Alan G0TLK

On 02/06/2024 23:05, Glenn Williams via wsjt-devel wrote:

Hi Sam,

Transmitting while driving:  NO.  But there is an Ohio QSO Party rover 
in my area who has a designated driver take him all over the state in 
the Ohio QSO party while he operates.


--73, Glenn, AF8C

On 6/2/2024 1:14 PM, Sam W2JDB via wsjt-devel wrote:

Hi Glenn,

When shifting the focus to a particular object on the screen, that 
object will then receive any inadvertent mouse operation such as done 
by the wheel or button.
An inadvertent press on the space bar or the Enter key would simply 
stop the TX. Rolling the mouse wheel would have no effect. To change 
the band and/or
frequency you will be forced to move the focus to that screen object. 
Now it is no longer an inadvertent action but an intentional one.
Moving the mouse itself can shift the focus but it would have to land 
and end on a particular object.


As far as operating wsjt-x while actually moving/driving, I can only 
ask Why? you are not only endangering yourself but others as well.


If you are visually impaired or blind that is a whole other story and 
its one that I actually became involved in. If you care to, you can 
read about it on my QRZ page.


73,

Sam W2JDB



On Sunday, June 2, 2024 at 11:49:25 AM EDT, Glenn Williams via 
wsjt-devel  wrote:



Fellow operators,

For those of us who have or will have Essential Tremor we might be
sliding the mouse too far to the left. (At least I don't have a serious
tremor yet.)  So how is moving the focus going to prevent accidents?

Also there could be someone operating /M (not driving) while acting as a
rover in a QSO party and is being jerked around by a pothole and bumps
the mouse.  Or someone with serious vision problems.

--73, Glenn, AF8C

On 6/2/2024 7:29 AM, Sam W2JDB via wsjt-devel wrote:
 > Hi Mike and all,
 >
 > As a retired software developer may I make a different suggestion. I
 > would ask Uwe to update the interface so that
 > at the beginning of the TX cycle the focus should switch to the 
"Enable

 > TX" this would remove the possibility of
 > inadvertent use of the mouse wheel or button that might create a 
problem

 > for the rig or amplifier.
 >
 > 73,.
 >
 > Sam W2JDB
 >
 >
 >
 > On Saturday, June 1, 2024 at 11:25:11 PM EDT, Black Michael via
 > wsjt-devel > wrote:

 >
 >
 > No -- it's only on band change -- not just a frequency change 
within band.

 >
 > So jumping around on the waterfall in WSJT-X or Doppler tracking in
 > gpredict still works...
 >
 > Mike W9MDB
 >
 >
 >
 >
 >
 >
 > On Saturday, June 1, 2024 at 05:01:38 PM CDT, Laurie, VK3AMA via
 > wsjt-devel 

 > > wrote:
 >
 >
 >
 >
 >
 > On 02/06/2024 6:49 am, Black Michael via wsjt-devel wrote:
 >
 >
 >
 >  >  I just put a patch in Hamlib to ensure PTT gets turned off if 
it's

 > on during a band change.
 >  >
 >  >
 >
 > Will this change make the existing (and long standing) "Allow Tx
 > frequency changes while transmitting" option obsolete?
 >
 >
 >
 > de Laurie VK3AMA
 > ___
 > 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 

 > >

 >
 >
 > ___
 > wsjt-devel mailing list
 > wsjt-devel@lists.sourceforge.net 

 > https://lists.sourceforge.net/lists/listinfo/wsjt-devel 



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net 

Re: [wsjt-devel] Beacons / Non-synchronous Mode

[alan2--- via wsjt-devel]

Yes, but don't query the NTP servers too often - see 
https://www.ntp.org/documentation/4.2.8-series/rate/ amongst others.


I believe NTP is a volunteer effort, so keep the queries to as few as 
you can.


See also https://forums.raspberrypi.com/viewtopic.php?t=29255 for other 
ideas.


I have a RTC board with one of my Arduino's and it's fine without 
regular NTP sync.  You could probably also use an Arduino for this, but 
from experience don't even think about it without the RTC board!


Alan G0TLK

On 21/05/2024 13:06, Graham c via wsjt-devel wrote:
Another option to consider if using a computer ( i.e. Raspberry Pi or 
other ) connected to the internet is to simply set up ntp or chrony 
for time keeping on that computer. NTP should keep your computer clock 
to within a few 10's of milliseconds - well within the needs of WSJT-X 
synchronous modes. One less external device ( GPS module ) - keep it 
simple.


cheers, Graham ve3gtc


On Tue, May 21, 2024 at 12:14 AM Roger Rehr via wsjt-devel 
 wrote:


Hi Ev,

If I were doing this with audio as you indicated you want to do, I
would use a Raspberry Pi with a USB GPS Dongle to play the audio
files with GPS-aligned timing, rather than avoiding the WSJT
modes.  The RPi has a 3.5 mm jack for audio out at line level, and
you could feed that into your transmitter audio input.

A 4 GB Raspberry Pi (which is what I used) is $55 at adafruit
https://www.adafruit.com/product/4295
and the GPS USB dongle is ~$17 at Amazon

https://www.amazon.com/Navigation-External-Receiver-Raspberry-Geekstory/dp/B078Y52FGQ/

I wrote a simple beacon script using python that cycles through 3
different audio files, each starting at the top of the minute. 
The starting times are plenty precise, consistently less than 10
milliseconds off the minute.

You could use one wav file for Q65-60C, one for CW, one for SSB as
you suggest, or you could make it as complicated as you want,
starting files not only at the 0th second of the minute but also
at the 15, 30, and 45 second marks for the shorter modes, and you
could mix modes within any given minute and timing would be preserved.

The simple python script for a beacon cycling among 3 modes, each
starting at the top of the minute is at the URL
https://w3sz.com/BeaconPlayAudio3.py
The python script starts automatically when the RPi boots and the
unit operates as a black box with no need for user intervention or
internet access.

In this test I used for the 3 modes Q65-60C, Q65-15C, and Q65-15A
only because I had audio files for those modes in front of me so
no work was required.

After I click "Send" on this email I will start making a simple
document with the "prescription" describing the details on setting
this up as well as an illustration of the results.  The document
should be at
https://w3sz.com/AudioBeaconDescription.pdf by daylight tomorrow
(Tuesday 5/21 EDT).

It might seem tedious in the telling but it would take less than
an hour to set this up from the time the RPi box arrived in the
mail.  If you are interested in doing this but not comfortable
with the details, I would be happy to get the RPi set up and
running so that all you had to do was connect the power, plug in
the GPS dongle, and connect the audio cable from the RPi to the
transmitter audio in.

73,

Roger Rehr

W3SZ





On 5/18/2024 02:37 PM, Ev Tupis via wsjt-devel wrote:

Hello all,
Later this fall, I hope to install a constellation of multi-mode
VHF+ beacons.  CW, SSB, and MD (machine decodable) all in the
same transmission.

My intention is to record the audio digitally (MP3) and drive a
multimode radio in "SSB" mode, playing it over-and-over.

Is there a WSx mode that does not require the TXing and RXing
stations to be timeslot locked?

I can always fall "back" to PSK31/63 or RTTY, but would like to
explore the WSx approach a bit before I do.

If this is off-topic, I would be happy to receive off-list input,
of course.

Thank you for the work that you do.

Sincerely,
Ev, W2EV


___
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] High CPU load with 2.7.0-rc2

[alan2--- via wsjt-devel]

Hi, with 2.6.0 CPU average load is around 0.3% to 0.7% in Rx, with 
occasional peaks to 1.6 or 2%, on my W11 system.


Alan G0TLK

On 12/07/2023 13:44, Roger Newey (K7GXB) via wsjt-devel wrote:

Hi Mike,
FYI:
Win10 Task Manager shows:
WSJT-X CPU during Rx: 35-38%
WSJT-X CPU during Tx: 35-36%

System:
WSJT-X running WSPR "wsjtx-2.7.0-rc2-win64.exe" as downloaded 07-Jul-2023 
(Installed over WSJT 2.6.0);
Rig: ICOM 7300; Win10 on dedicated Celeron J4125 with 16GB RAM;
(J4125  has Cores. 4 ; Threads. 4 ; Burst 2.70 GHz ; Processor Base 2.00 GHz ; 
Cache. 4 MB).

Regret I don't have comparable CPU data for 2.6.0 but will install it if that 
helps.

73,
Roger (K7GXB)

-Original Message-
From: Black Michael via wsjt-devel  
Sent: Tuesday, July 11, 2023 20:47

What rig do you have?
Mike W9MDB
..
On my Win10 PC, this new version idles at 32% usage which is essentially the same as the 
earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 idles at 
less than 2%.
Drew K9CW
..
---




___
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

Re: [wsjt-devel] Memory leak in 2.7.0 rc1?

[alan2--- via wsjt-devel]

Quick test on a W10 Intel laptop with no rig connected shows 94MB used.

Alan G0TLK

On 26/05/2023 14:22, Fred Price via wsjt-devel wrote:

I started 2.7.0-rc1 Windows 11 Ryzen 5 task manager shows 473mb for WSJT.exe.
I then closed 2.7.0-Tx1 and opened 2.6.1 task manger shows 147mb for WSJT.exe.
Both were opened on a pretty quiet 6M band.
I let 2.7.0-rc1 run for around 4 hours this morning with no memory leaks. My 
settings for save menu are:
None
Disable writing of ALL.TXT.


On May 25, 2023, at 3:54 PM, Brian Moran via 
wsjt-devel  wrote:

Greetings; can you describe what mode you are using? If you left it going for 
a few days without deciding any signals (e.g. with no antenna) same behavior? 
What radio and interface to the radio? Any other information you could share 
would be most appreciated.

Thanks!
-Brian N9ADG


Sent via iPhone


On May 25, 2023, at 12:11 PM, Björn Ekelund via 
wsjt-devel  wrote:


My RAM (8 Gbyte) fills up if I let rc1 run for a few days. It does not happen 
with 2.6.1.

Interestingly enough the task manager does not show WSJT-X to be the culprit 
but when
I stop it, up to 5Gbyte are freed up.

Also, sometimes rc1 allocates 630Mbyte of RAM when started. Other times 
90Mbyte. It seems random.

2.6.1 is always around 90Mbyte.

I am running Swedish Windows.

Does anyone else experience the same anomalies?

Björn SM7IUN

___
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

___
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

Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles

[alan2--- via wsjt-devel]

The indicated frequency on a counter will not change as you are 
transmitting a 50Hz wide signal within a frequency range defined by the 
upper sideband width.  The position of your 50Hz wide transmission will 
vary within that sideband width but you will need a good spectrum 
analyser to see it.


Alan G0TLK

On 07/05/2023 04:35, Adrian via wsjt-devel wrote:

But the one you tune in by moving green marker is your receiving frequency.
Same way you tune your transmitter by moving red marker.

*No, The green marker is just a decode filter for that mark to place 
that traffic in the right pane for view.The receive frequency covers the whole 3 -4 KHz bandwidth of your pan 
as set. See the left pane for all of these signals.Regardless of your TX 
slot, you will be still receiving there*



If you have
"hold TX freq" checked you and set your TX where ever you want over the
(audio) IF.
In that case you will have a split qso where you transmit on different
frequency as you receive.

*No because you receive also wherever that TX marker is. The green 
marker is not a RX tune, but a decode filter.Your receive all of the pan, not just the green marker slot*



"Split operation" in settings has nothing to do with this. It is
wsjt-x's "artificial intelligence" to optimize TX audio filter usage, if
user allows it by selecting "rig" or "fake it".
Whether or not this "artificial intelligence" is used it does not change
your RX and TX tuning (red and green markers) on RF spectrum, I.E. does
not cause any "split".
Test with frequency counter. Your TX RFcarrier does not change when
selecting "none", "rig" or "fake it".

Saku
OH1KH


*There is no TX RFcarrier as you said earlier, so there is nothing to 
see for change, only the usb sideband sum of RF and audio frequency.However in the radio there is a real ( not artificial ) generation of 
CP and audio signals mixed for the result TX ssb signal.**On 20m at 400 TX marker, my FTDX101MP in 'rig split' has TX Sub vfo 
set (by wsjtx) at 14.072.500, and uses an audio frequency of 1900Hz 
(1500 -2000 Hz being the target passband window) Sum = 14.074.400, the xxx.400 equating to the the pan indicator.*


*My monitor scope pickup indicates the audio at 1900Hz mean with the 
CP frequency at 14.072.500, that are mixed.**The vfo indicates the real CP reference **That is real as the passband filter hardware requires for best signal 
quality and level consistency.**Many not using split/fake wonder why their signal strength/quality 
varies across the pan in use, and the reason is not 'artificial'*

***73**vk4tux*




--





___
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

Re: [wsjt-devel] WSJT-X 2.6.0 GA Release

[alan2--- via wsjt-devel]

W10 64 bit installed OK here, apart from the W10 file catalogue issue I 
posted a few days ago.


Alan G0TLK

On 06/01/2023 18:39, Edfel Rivera via wsjt-devel wrote:

Hi:
Thanks for WSJTX Development. Have 2.6.0 GA crashed (Windows 10 
64bit).  Report from Windows Event Viewer. Tried downloading again, 
same result. If dev team need specifics send email to edfeljose at 
gmail.com 


Thanks

73'

Edfel
KP4AJ

Log Name:      Application
Source:        Application Error
Date:          06/01/2023 12:28:01
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DESKTOP
Description:
Faulting application name: wsjtx-2.6.0-win64 (1).exe, version: 
2.6.0.0, time stamp: 0x60fc9193

Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x
Exception code: 0xc005
Fault offset: 0x
Faulting process id: 0x740
Faulting application start time: 0x01d921fc9a537348
Faulting application path: C:\Users\edfel\Downloads\wsjtx-2.6.0-win64 
(1).exe

Faulting module path: unknown
Report Id: f1c7fed3-a95a-4361-be67-3017793fbcc3
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
http://schemas.microsoft.com/win/2004/08/events/event;>
  
    
    1000
    0
    2
    100
    0
    0x80
    
    91619
    
    
    Application
    DESKTOP
    
  
  
    wsjtx-2.6.0-win64 (1)exe
    2.6.0.0
    60fc9193
    unknown
    0.0.0.0
    
    c005
    
    740
    01d921fc9a537348
    C:\Users\edfel\Downloads\wsjtx-2.6.0-win64 (1).exe
    unknown
f1c7fed3-a95a-4361-be67-3017793fbcc3
    
    
    
    
  


On Fri, Jan 6, 2023 at 11:54 AM Gary Rogers via wsjt-devel 
 wrote:


OK I made the edit to the Hamlib version in cmakelist.txt to 4.5.3
and was able to build 2.6.0 for Mac. A couple of issues I have
encountered during building the last several versions

Build environment MacOS SDK, Xcode, dependencies in Macports  and
Cmake 3.25.1

While building hamlib, I get this error:

*/Users/charlesrogers/Build/hamlib-prefix/src/hamlib/src/parallel.h:31:12:
**fatal error: **'linux/parport.h' file not found*

# include 


I get around this by going into my build/hamlib-prefix/src/hamlib
and running ./configure


This solves the hamlib problem.


Since upgrading the  MacOS 13 Ventura, I’m getting this error:



*/Users/charlesrogers/Build/wsjtx-prefix/src/wsjtx/widgets/mainwindow.cpp:4822:9:
**error: **'sprintf' is deprecated: This function is provided for
compatibility reasons only.  Due to security concerns inherent in
the design of sprintf(3), it is highly recommended that you use
snprintf(3) instead. [-Werror,-Wdeprecated-declarations]*

    sprintf(s,"Tx:  %d Slots",foxcom_.nslots);


There is a similar error on line 4824


I’ve gotten around this by changing sprintf to snprintf in both
locations and rewrite the expression snprintf(s,*sizeof*(s),"Tx:
%d Slots",foxcom_.nslots);

      }*else*{

snprintf(s,*sizeof*(s),"Tx: %s",msgsent);

*
*

I’m providing this info in the event developers wish to update
code to resolve these errors. I’m still able to build from source
with the workaround noted above. Thanks to all for this software!



On Jan 6, 2023, at 9:22 AM, Uwe, DG2YCB via wsjt-devel
 wrote:

Try to download again. I think Sourceforge still had the old
copy. But the one I downloaded 1 minute ago has the correct entry.

73 de DG2YCB,
Uwe


Am 06.01.2023 um 18:07 schrieb Gary Rogers via wsjt-devel:

Same issue for me downloaded from new WSJT-X site.


On Jan 6, 2023, at 8:55 AM, Kari Sillanmäki via wsjt-devel

 wrote:


Hi Uwe,

I just downloaded the tarball.
It still has the wrong CmakeLists.txt entry...

I used this link to download:
https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.0/wsjtx-2.6.0.tgz
Is this the correct link??

73's de Kari, oh2gqc

On 6.1.2023 18.05, Uwe, DG2YCB via wsjt-devel wrote:


Hi Stefan,

Yes, it must be 4.5.3. I have updated the tarball. Please
download again and see if it works better now.

73 de DG2YCB,
Uwe


Am 06.01.2023 um 16:57 schrieb Stefan HB9TMC via wsjt-devel:

Hi,

cmake generated an error:
CMake Error at CMakeLists.txt:56 (file):
  file failed to open for reading (No such file or directory):

~/bin/wsjtx-2.6.0/src/hamlib-4.5.tar.gz.md5sum



I think CMakeLists.txt should be:
6c6
< set (__hamlib_upstream hamlib-4.5.3)
---
> set (__hamlib_upstream hamlib-4.5)


73
Stefan


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list

Re: [wsjt-devel] WSJT-X app list issue - confirmed repeatable

[alan2--- via wsjt-devel]

Hi, thanks, that's interesting and another workaround for what appears 
to me to be an incorrect installer script?


If I'm right this looks to be easily curable by a hopefully relatively 
simple change to the default file path in the installer script, by 
appending the version number (without the periods) into the default 
folder name.  That would then work for the RC's as well.


Alan G0TLK

On 31/12/2022 21:00, Peter Sumner wrote:

Hello Alan,
 to avoid running the installer all together, you can use the '7ZIP' 
utility to uncompress the WSJT-X package EXE file straight into a 
folder on the PC, yes it works.  This is the path I have taken, it 
allows me to have many and varied copies of WSJT-X on a PC and no 
entries in the installed apps catalogue of Windows or entries in the 
system registry.


Once the files have been extracted, you can go to the 'Bin' sub 
folder, right click on the WSJT-X.EXE and select create shortcut if 
you need a dedicated shortcut to start each copy (give each shortcut 
you create a meaningful name).


Regards,
Peter, vk5pj




On Sun, Jan 1, 2023 at 2:39 AM Alan Groups via wsjt-devel 
 wrote:


Last post on this issue.

  * I cleaned ap again, and installed version 2.5.3 into a
wsjtx253 folder, then version 2.5.4 into a wsjtx254 folder
  * That worked, apart from some initial "stale lock file"
complaints that went away on retry.  The Start Menu entry for
2.5.3 started that version and the entry for 2.5.4 started
that one
  * The 2.5.4 entry was missing the Start Menu entries for
uninstaller, documentation and website, but the latter two
appeared on their own when I uninstalled 2.5.3 from
Settings>Apps and Features
  * The uninstaller for 2.5.4 nevertheless worked when I did so
from Settings>Apps and Features

Maybe something like that is all that's necessary to clear this
one up - the installer to suggest a different default folder for
each version?

Alan G0TLK

On 31/12/2022 13:46, Alan Groups via wsjt-devel wrote:


Following a system clean-up I've looked a bit further into the
weird menu and other entries I found on my system and found the
same effects arising on version upgrade, so it's a repeatable issue:

*The Uninstaller*

  * Following a system clean of WSJT-X, installation of v 2.5.4
and after a reboot I uninstalled WSJT-X 2.5.4 using the
uninstal link under the Start button - it runs uninstal.exe
  * WSJT-X went from the Start menu, the W10 apps list, Control
Panel>Programs & Features, and the registry
  * The uninstaller therefore seems to be doing it's job, if run.

*Version upgrade*

I then installed version 2.5.3 and rebooted, followed by an
upgrade to version 2.5.4 by simply running the latter installer. 
This gave me:

  * Start Menu - one entry labelled 2.5.3 that actually runs 2.5.4
  * Registry - two entries, for each of 2.5.3 and 2.5.4
  * Control Panel>Programs & Features - two entries in the list,
one for 2.5.3 and one for 2.5.4, both uninstalling only 2.5.4
  * Settings>Apps & Features - same as Control Panel

The system entries are therefore incorrect, leading to user
confusion and for all I know potential W10 system issues as well.

*Diagnosis*

I don't believe the installer is running the working uninstal.exe
nor is it cleaning up system entries from the previous version,
when a new version is installed over the top of an existing version

*Suggested solutions*

  * Advise users to run the uninstaller first, before version
upgrading; or
  * Incorporate minimum necessary system entry clean-up into the
installer script; or
  * If an ability to run multiple versions on one machine is
required then amend the installer script so that it handles
the system entries to have each version remaining entirely
separate

Hope that helps!

Alan G0TLK



___
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Syslog problem FT8 with TS590SG

[alan2--- via wsjt-devel]

I wasn't aware of this file so just took a look, finding it starting in 
November 2021 and 11MB in size.


Rig in use is a TS590S, and the bulk of those log lines were in the form of:

[RIGCTRL][warning] 
kenwood_get_split_vfo_if(1552): unknown rxVFO=None


For some reason WSJT-X (currently v 2.5.4) is set for None rather than 
Rig or Fake-it as I recall I too was experimenting with what happens 
with different settings but I've not had a chance to use it for many 
months now so I've forgotten!


I therefore suspect those messages might be reflecting the setting I'm 
using, but posting here in case it's useful.  They started while I was 
running v2.5.3 by the looks of it.


Alan G0TLK

On 06/11/2022 15:02, Glenn Williams via wsjt-devel wrote:
I am sending this to the developers list because it seems to be too 
detailed and too specific to only one type of rig to warrant sending 
to the general [WSJTX] reflector.   --de AF8C, Glenn


HARDWARE/SOFTWARE CONFIGURATION

Version 2.5.4
Windows 10
Cabled via USB only to a Kenwood TS590SG.

Do you need more information on the above configuration?

HISTORY

Operation has been flawless for months.  I basically usually never 
look at the file wsjtx_syslog.log. In that file there is nothing 
before November 1, 2022. Something changed on November 1 that caused 
the syslog file to start growing nearly without bounds. That was only 
6 days ago.


In the syslog file appear messages that apparently only started on 
November 1, when possibly I might have tested what happens if I 
selected RIG instead of FAKE-IT,  But then I went back to FAKE-IT 
because that's where I found it when I noticed what syslog was doing.


Then after a few days I accidentally caught that wsjtx_syslog.log was 
getting very large. There is an error message every second, as shown 
below, but only when I am in FAKE-IT mode.


DETAILS OF PROBLEM

After some testing, I learned that the major problem of a warning 
every second goes away while in RIG mode but comes back if I go to 
FAKE-IT mode. The only was to stop it is to go back to RIG.  This did 
not happen before November 1 because I always ran FAKE-IT mode. It's 
as if a flag was set that wasn't set before November 1, indicating 
that my TS590SG transceiver can do RIG so let's no longer accept 
FAKE-IT as valid. (That's a guess.)


Below between the two lines is a transcript of a short test with RIG 
and FAKE-IT, today.I have INSERTED a few comments or questions with a 
leading "greater than" symbol and upper case text.


(My email setup on this computer wants to wrap lines.)
-- 


>STARTED WSJT-X for FT8
[SYSLOG][2022-11-05 19:23:07.085455][00:00:00.000629][info] Log Start
[SYSLOG][2022-11-05 19:23:07.085455][00:00:00.000685][info] WSJT-X 
v2.5.4 d28164  by K1JT, G4WJS, K9AN, and IV3NWV - Program startup
[SYSLOG][2022-11-05 19:23:07.101079][00:00:00.004517][info] locale: 
language: English script: Latin country: United States ui-languages: 
en-US
[SYSLOG][2022-11-05 19:23:07.101079][00:00:00.004726][info] Loaded Qt 
translations for current locale from resources
[SYSLOG][2022-11-05 19:23:07.101079][00:00:00.004773][info] Loaded 
WSJT-X base translation file from :/Translations based on language en
[SYSLOG][2022-11-05 19:23:07.101079][00:00:00.004808][info] Loaded 
WSJT-X translations for current locale from resources
[SYSLOG][2022-11-05 19:23:07.116702][00:00:00.026421][info] shmem 
size: 48275456
[RIGCTRL][2022-11-05 19:23:07.147949][00:00:00.049428][info] Hamlib 
version: Hamlib 4.5~git Sat Jan 01 23:05:51 2022 + SHA=18548e

> WHAT DOES THIS SINGLE NEXT LINE MEAN?  WAS IN FAKE=IT MODE
[RIGCTRL][2022-11-05 19:23:08.335330][00:00:01.251647][warning] 
rig_init: backend for TS-590SG does not contain hamlib_check_rig_caps

> THIS HAPPENS WHILE IN FAKE=IT MODE, EVERY SECOND.   WHY?
[RIGCTRL][2022-11-05 19:23:08.672954][00:00:01.575576][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:08.904705][00:00:01.807581][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:09.991857][00:00:02.894678][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:10.986785][00:00:03.888094][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:11.995429][00:00:04.896624][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:12.990514][00:00:05.891802][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:13.989950][00:00:06.891254][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:14.991988][00:00:07.893143][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:16.018014][00:00:08.925182][warning] 
kenwood_get_split_vfo_if(1583): unknown rxVFO=None
[RIGCTRL][2022-11-05 19:23:16.993229][00:00:09.894732][warning] 

Re: [wsjt-devel] Missing input sanitation for TX_PWR field in ADIF log

[alan2--- via wsjt-devel]

I believe it can be done with Qt using IntValidator on the TextBox input?

Alan G0TLK

On 21/10/2022 10:19, Frode Igland via wsjt-devel wrote:

Roman,
I see your point. Since the power data is manually input in the 
logging window, I guess that the check for "numbers only" in the "Tx 
Power" field must be made in the  logging window, before the "OK" is 
accepted. However, I don't know if this check can be easily 
implemented. In the meanwhile, be disciplined and use numbers only.  


73, Frode LA6VQ

ons. 19. okt. 2022 kl. 22:08 skrev cirnod via wsjt-devel 
:


Hi Frode

I agree with you that in practice many applications are tolerant
and read non-compliant ADIF files without errors. However, my
report was actually triggered by a practical problem. Concretely,
I tried to read the ADIF file created by WSJT-X using the Python
library "hamutils". This did not work and resulted in errors. Upon
further investigation, I realized that (in certain cases) WSJT-X
strictly speaking generates ADIF files that do not conform to the
specifications. After manually correcting the values of the tx_pwr
fields in the ADIF file, the processing using the "hamutils"
library works without issues. To permanently fix this issue and
prevent further similar problems in combination with other
software I would therefore welcome it if the WSJT-X software could
be adapted such that the generated ADIF file always complies with
the specifications.

Regards
Roman HB9HDN


On 19.10.22 15:05, Frode Igland via wsjt-devel wrote:

Hi, Roman.
My experience is that the ADIF format accepts more than the ADIF
specifications may indicate. I have used the "Tx power" field in
the WSJT-X logging window for most of my tens of thousands of
WSJT-X QSOs. Whether I enter "40 W", "40W" or "40", it hits my
HRD Logbook as "40", i.e. a clean number. Apparently, the ADIF
protocol is smart enough to find and understand the numbers,
leaving out the letters. However, that also means that "1kW" or
"1 kW" is transferred as "1". In the practical world, this may be
a smaller problem for WSJT-X, as I cannot see any good reason to
use 1kW for the common WSJT-X modes, except for EME QSOs. EME
operators will soon enough understand that they didn't make a QSO
with 1 W, and should be able to edit the Tx Power in their
logging software. Human interaction and thoughtful discretion is
still a good value in ham radio. 

I guess the issue may be solved practically by changing the field
title in the logging window from "Tx power" to "Tx power (W)" or
"Tx power (watt)", or possibly, like you suggest, make a tooltip
reminding the operator that a watt _number_ is expected, however,
I don't know if the logging window is open for tooltips, as there
are none yet.

73, Frode LA6VQ

ons. 19. okt. 2022 kl. 00:53 skrev cirnod via wsjt-devel
:

Hi

I would like to report an issue with the ADIF log
created by WSJT-X. I'm currently using v2.5.4 on
macOS 12.6.

WSJT-X offers to log QSOs by filling in a form
prompt. One of the fields of the form allows to
log the "Tx power". Apparently, the form accepts
any text string entered into this field.
Furthermore, the unmodified text string is used to
create the ADIF log of WSJT-X. This behavior
potentially leads to invalid ADIF files as they do
not conform with the ADIF specifications [1]. For
example a user could enter "10W" or "1kW".
According to the specifications, the "TX_PWR"
field should contain "the logging station's power
in Watts with a value greater than 0". In
addition, the data type of this ADIF field is
"Number", i.e. "a sequence of one or more Digits
representing a decimal number, optionally preceded
by a minus sign (ASCII code 45) and optionally
including a single decimal point  (ASCII  code 46) ".

I see the following points that could help fixing
the mentioned issue:
* Adding tooltip/instructions for the user to
clarify what data type and value (in what units)
should be entered in the "Tx power" field.
* User input sanitation either for the "Tx power"
field of the QSO log form prompt or before writing
the value entered by the user to the ADIF log
file. One option would be to rejecting the
submission of the form and informing the user in
case a wrong data type has been entered.

Regards
Roman HB9HDN

[1]
https://www.adif.org/313/ADIF_313.htm#QSO_Field_TX_PWR


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.5.3 crash/issues after computer sleep

[alan2--- via wsjt-devel]

Accidental!  Got distracted :-)

Alan G0TLK

On 27/12/2021 16:45, Black Michael via wsjt-devel wrote:

You are letting your PC go to sleep with all this running?
Or are you saying that was just accidental?

Mike W9MDB




On Monday, December 27, 2021, 10:27:36 AM CST, Alan Groups via 
wsjt-devel  wrote:



Hi, I left WSJT-X running on Rx while I had to do something else, which
unexpectedly took longer than I anticipated and the PC entered sleep mode.

On awakening it I completed a QSO and on auto-log WSJT-X crashed,
status.txt file error, path not found (it's in temp folder).

Clicked OK to the error and the error box came back, clicked OK again
and it went away.  However it came back after auto logging another QSO.
Restarting WSJT-X cleared it permanently.

I've since tried to reproduce the issue, this time actively putting the
PC to sleep using Start>Right click>Sleep.  On awakening it WSJT-X would
no longer key the rig, even though it was going into transmit mode, but
this time the status.txt file error didn't appear.  However, as above, a
restart of WSJT-X cleared the issue.

So far I've been unable to repeat either issue but I haven't seen this
kind of behaviour before.

W10 Pro 64 bit

--
Alan G0TLK



___
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___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.5.3 crashes on TX5 with slash in call

[alan2--- via wsjt-devel]

Hi, I don't see this behaviour when sending a TX5 (at low power into a 
dummy load of course!) from my own call to my own call with /P added.


If I try the same but with /MM instead of /P I don't see the behaviour 
either, but the /MM is not transmitted and is also not shown anywhere in 
the UI apart from the TX5 box.


W10 64 Pro, latest updates

Alan G0TLK

On 24/12/2021 07:48, Rich - K1HTV via wsjt-devel wrote:
I have run into a problem with WSJT-X 2.5.3 when transmitting a TX5 
message to any station with a "/"  followed by /MM or /P and probably 
other characters. I'm running the Win 64 bit version on a Windows 10 
computer with the latest updates.


After transmitting the TX5 message, the receive cycle starts and runs 
for 11 seconds. At that point the clock in the lower left corner stops 
and a few lines of decoded data is displayed, then the program ends. 
The problem ican be reproduced.


A jt9.exe process is left running, which must be deleted with Task 
Manager before WSJT-X can be started again.


The issue only occurs with stations with a forward slash in the 
callsign. I tried using a non-standard callsign such as 3DA0XXX, with 
no problem, only with calls with slash.


I've gone back to WSJT-X Version 2.5.2 and ran the same tests without 
the program crashing after a TX5 message with a forward slash in the call.


73,
Rich - K1HTV


___
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

Re: [wsjt-devel] Kenwood TS890S and Win10 21H1

[alan2--- via wsjt-devel]

Hi, I agree with Bill that more detail is needed, but one suggestion 
from a gotcha I had with different software at one point - check the 
stereo channels as sometimes only one is used, and/or try mono sound 
settings instead of stereo.


On the rig settings I suggest also check that audio is being routed to 
the connection port you have in use. Also learned that one the hard way :-)


Alan G0TLK

On 14/10/2021 16:38, Bill Somerville via wsjt-devel wrote:

On 14/10/2021 16:12, Enrico Schürrer OE1EQW via wsjt-devel wrote:

Dear friends,

I have problems to get the audio from the TS890S into Win10.
Kenwood driver installed, the right soundcard of the TS890 selected - 
no tone.


Doing the same on a Win7/64bit-PC I had no problems and it works free 
of errors.


Anybody who can give me a hint?

tnx in advance

Enrico, OE1EQW 


Hi Enrico,

we need more information to address your query. How is your rig 
connected to your PC for audio? Do you have a CAT connection? Which 
application are you trying to run?


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

Re: [wsjt-devel] Idea for "frequency hopping" FT8 to reduce collisions

[alan2--- via wsjt-devel]

Hi, I've been following this thread with interest and have a few 
questions/comments please:


If the proposed protocol frequency changes are set to use the wider 
bandwidth of a SDR receiver linked to a T/R switch with a standard voice 
rig as Tx as I saw in one post, those frequency changes will presumably 
need to use CAT control.  Will that be reliably fast or stable enough 
with such relatively frequent changes, for all rigs?


As someone else posted there's also a need to consider Tx antenna 
bandwidth if the SDR route is chosen, particularly on lower bands where 
a tuner of some kind is likely to be in use.  Even if that tuner is 
automatic will it change fast enough, and will frequent changes cause 
longer term issues with worn relay contacts in such devices for example?


Is there a way of getting some indication of how many collisions are 
currently occurring in any user session, firstly to try and obtain some 
real world data on how big and frequent the issue might be, and secondly 
if possible what the decode conditions were?  I base that on the 
vagaries of HF propagation that I suspect might be the principal 
controlling factor and of course are entirely unpredictable.


Are collisions an issue at VHF and above where propagation is different?

If this gets implemented it would be good to have it switchable in and 
out, so users who are interested can compare what's happening.


Alan G0TLK

On 02/09/2021 07:32, Phil Karn via wsjt-devel wrote:

On 8/29/21 12:30 PM, Gordon Weast via wsjt-devel wrote:

Ed,

When I look at decodes on 20m today, I've seen multiple times when
signals offset by as little as 1 Hz are decoded just fine.
Basically, the protocol works fine with lots of overlap.  There is NO
need to channelize transmission frequencies.

I don't see that that necessarily follows. It is always desirable to try
to make the channel utilization more uniform. The ultimate fix here is
to frequency hop between every *symbol*, not every transmission, and to
use FEC to fix the inevitable collisions. That's true CDMA. But it's not
backward compatible with FT8, so it's a separate topic.

Restricting transmissions to the channels you're proposing would
severely restrict the number of simultaneous users.

Why? The protocol would not necessarily inhibit transmission when it
thinks a channel is busy. It could look at the signal levels and
conclude that it wouldn't necessarily interfere with another
transmission even if it transmitted at the same time.


In any event, you can't avoid overlap since what looks like a clear
channel at your location will probably not look like a clear channel
at a different location.

Again, that's the point of my original MACA paper -- that simply sensing
whether or not the channel is busy doesn't really tell you what you want
to know. Collisions occur at receivers, not transmitters.

Phil




___
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

Re: [wsjt-devel] 'Rpt Rcvd' not being correctly populated

[alan2--- via wsjt-devel]

Could the station calling be in NA contest mode?  That starts with TX2.

Alan G0TLK

On 04/08/2021 20:43, Martin Davies G0HDB via wsjt-devel wrote:

On 4 Aug 2021 at 9:46, j...@comcast.net wrote:


This sounds like it is related to the "WSJT-X 2.5.0-rc3 RST_RCVD logging
issue" that I reported on this reflector on Fri 7/16/2021 10:45 PM.  In the
brief JA-to-NA 6m FT8 openings, it is typical for the JA station to start
with the Tx2 message.

Ed N4II.

Thanks for the reply, Ed.  Unfortunately I don't recall having seen your 
posting; if I had I
would have added my input to your issue report.

I've just found that there's also a (short) thread about this topic on the 
WSJT-X groups.io
forum; the posting that started the thread was from 5H1FF on 6th June and is at:

https://wsjtx.groups.io/g/main/message/2.

Unfortunately the thread is now locked, because I'd like to have been able to 
contribute to the
discussion.

Two of the responses to the issue report from 5H1FF suggest the solution is not 
answering
or working stations that call with the Tx2 message, or removing the option to 
call using Tx2.
In my opinion these are not at all helpful or sensible suggestions because 
there can be many
occasions when it's highly desirable to minimise the duration of a QSO and 
using the Tx2
message to call a station helps achieve this (IMO).

--
73, Martin G0HDB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 'Rpt Rcvd' not being correctly populated

[alan2--- via wsjt-devel]

Vague memory that I may have seen this, but unless such things happen 
regularly I usually assume it's finger trouble!


Alan G0TLK

On 04/08/2021 14:31, Martin Davies G0HDB via wsjt-devel wrote:

I'm running WSJT-X on a PC (i7-9700 CPU @ 3GHz, 16G RAM, 512G SSD, running fully
up-to-date 64bit Win 10 Pro).

The issue I'll describe below is one that I believe has existed for a while - 
it's certainly present
in v2.3.1 and v2.5.0-rc3.  Here's the scenario, which is quite subtle and not 
easy to explain in
straightforward terms...!  As far as I've been able to ascertain thus far, the 
issue exists for
both FT4 and FT8 modes; I haven't (yet) been able to confirm if it also exists 
when using
other modes such as MSK144.

I'm having a QSO with a station, let's say it's K1JT, and we have exchanged 
reports and I've
received K1JT's RR73 and have sent a 73 in reply; at this point the QSO is 
complete and the
prompt to log the QSO has come up and I've OK'ed the logging of the QSO.  Let's 
say the
'Rpt Rcvd' figure that was received from K1JT and displayed in the appropriate 
box in the
logging prompt window was -10.

At some point during the QSO with K1JT I was called by another station, let's 
say it's N8DX,
who sent me his Tx2 message.  After I've completed and logged my QSO with K1JT I
double-click on the N8DX callsign in the decoded Tx2 message, to start a QSO 
with him/her.

I conduct the QSO with N8DX; we exchange reports and our RR73/73 and eventually 
the
logging prompt pops up again, but at that point I notice that the figure 
displayed in the 'Rpt
Rcvd' box isn't the one that was in N8DX's Tx2 message - the 'Rpt Rcvd' figure 
is either the
same -10 figure that was correct for my previous QSO with K1JT, or on some 
occasions the
'Rpt Rcvd' box is completely empty.  In both of these cases I have to enter the 
correct 'Rpt
Rcvd' figure into the box before OK'ing the logging of the QSO.

It would appear that in some circumstances, for example but perhaps not limited 
to starting a
QSO by double-clicking on a received Tx2 message, the report-received figure 
isn't being
picked up correctly from the received Tx2 message and hence isn't being 
displayed correctly
in the 'Rpt Rcvd' box in the logging window, but instead the report-received 
figure from a
previous QSO is being retained or the 'Rpt Rcvd' box is being left blank.  On 
quite a few
occasions I've had to amend an entry in my logging app (Logger32) because the
report-received figure transferred to the app by WSJT-X has been incorrect.

Has anyone else observed these anomalous figures being displayed in the 'Rpt 
Rcvd' box
and hence logged?

--
73, Martin G0HDB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Good old-fashioned Grids-Only mode

[alan2--- via wsjt-devel]

"So signal reports in WSJT tell me far more about their station and its 
RX noise than how well I'm "getting out."  Indeed it does, but that's 
simple physics and has always been the case since radio was invented 
over 100 years ago.  The other factors are of course propagation related.


The key to determining how well one is "getting out" is the pattern one 
sees over a number of contacts with different people, over a suitable 
period.  That then gives a qualitative view of our station performance, 
and if we average the signal strength reports from many such contacts we 
will get reasonably close to a likely signal strength number if one is 
interested in a more quantitative analysis.


In my view the signal strength reports are useful as they give me a view 
on propagation and how that changes, with some quantification.  I can 
also tinker with my system and see whether the QSO pattern changes, 
again with some quantitative view of that.  Yes grid only I could see 
the same patterns but without some numbers behind them I wouldn't know 
by how much things have changed - even if it's only very broad brush.


Alan G0TLK

On 02/08/2021 06:21, Jim Brown via wsjt-devel wrote:

On 8/1/2021 9:13 PM, MIKE LAVELLE via wsjt-devel wrote:
What's wrong with signal reports... lots of us like to know how well 
we are getting out.


But signal reports only tell us signal to noise ratio in the other 
station's receiver, NOT signal strength. I use WSJT modes on 6M and 
160M to make difficult QSOs -- (on 160M it's EU), so I run legal limit 
to better than average antennas and on 160M, have two reversible 
Beverages and two RX loops, but WSJT nearly always give signal reports 
to the stations I work that are 10-15 dB better than what they give me.


So signal reports in WSJT tell me far more about their station and its 
RX noise than how well I'm "getting out."  And especially on VHF, if 
you can eliminate one "over" by exchanging only the grid, or by 
calling with TX2, we can squeeze 30 seconds out of a QSO and squeeze 
one third more into a short band opening!


The only reason I call with TX1 most of the time is that I'm a K9 
living in W6, and don't want the other station to swing their beam in 
the wrong direction. I've lost QSOs that way. :)


73, Jim K9YC


___
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