Date   

locked Colors for Mode in Status Bar #FT4 & #FT4 #FT8

Carlo - IK2RPE
 

I downloaded and installed - smoothly - v.2.3.0 Win 64 bit (from v.2.2.2.)
I found that differently vs. v.2.2.2 the colors in the Status Bar for FT8 and FT4 are  NOW *very similar*.
Is there a way to change them in order that they appear quite different?
Where and how?

Thanks

Carlo  IK2RPE


locked Re: My WSJTX Has Gone Wierd #FT8

Bill Somerville
 

Hi Mike,

thanks for the issue report, those images need some updates, along with the text. We will get that sorted out for the next release.

73
Bill
G4WJS.

On 02/02/2021 18:06, G4RAA via groups.io wrote:

Hi Bill

 

In case you are unaware the user guide for 2.3.0 shows the old Tab 2 still in place. It is shown in section 6.4 and 10.5 (where there are instructions on using Tab 2). Both also appear in the pdf version on pages 27 & 73. It caused some confusion here until I found your email!

 

Maybe I missed it but there doesn’t seem to be anything on the old Tab3/new Tab 2 in the regular user guide, although it is in the DXpedition Mode guide of course.

 

73

 

Mike

G4RAA

 

 

From: Bill Somerville
Sent: 02 February 2021 16:17
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] My WSJTX Has Gone Wierd #FT8

 

Hi Steve,

 

Tab 2 has been removed as it was not well maintained and was the source of many defects and support requests.

 

The Tx5 message has the equivalent functionality as the removed Tab2 Free Text field.

 

73
Bill
G4WJS.

 

On 02/02/2021 15:50, Steve - N3SL wrote:

Why is that? How does one now send "free" txt? 

 

On Tue, Feb 2, 2021, 9:32 AM Gary - AG0N <mcduffie@...> wrote:



> On Feb 2, 2021, at 08:26, Jim Forsyth <jim@...> wrote:
>
> Great! That fixed the top part. Thank you Reino.

The bottom part didn’t need fixing.  The old Tab2 has been removed.

Gary - AG0N



locked Re: Automatic power up of rig #WSJTX_config

Bill Somerville
 

On 02/02/2021 18:25, David Ross wrote:
On Thu, Jan 14, 2021 at 06:36 AM, Bill Somerville wrote:
rig to power up
Hi Bill can you please tell me were to enable rig power up in ver 2.3
Many thanks
David Gi4sna 

Hi David,

put the attached file into you WSJT-X log files directory then restart WSJT-X.

73
Bill
G4WJS.


locked Re: Version 2.3.0 64 bit will not install #install

Bill Somerville
 

Hi Andy,

there will be conflicts if you have something from a repository using apt/aptitude/synaptic installed and then try to install our bare Debian package file. To get the latest v2.3.0 release I recommend removing any other version of WSJT-X and then installing our package using dpkg, or alternatively wait for the repo you were using to be updated, which may not take very long.

73
Bill
G4WJS.

On 02/02/2021 18:27, Andy_501 wrote:

Hi Bill,


I tried downloading the wsjt installer .deb file and having the debi installer install it but always just came back installing only message aggregator alone.

I completely purged older version and reran the same process again and it did the same thing aggregator only. So I purged it all and then just installed the package from the synaptic package manager ; it installed OK and runs but is the older version. Can't seem to get newer versions to install. OS here is ubuntustudio 20.04LTS

which wsjtx =  "/usr/bin/wsjtx"  <--- but this is after reinstalling from synaptic pkg manager.




On 2021-02-02 11:34 a.m., Bill Somerville wrote:
Hi Andy,

that doesn't sound, in any way, similar. Can you explain exactly what went wrong? For example what does this command run from a terminal print:
which wsjtx
73
Bill
G4WJS.

On 02/02/2021 17:32, Andy_501 wrote:

I had similar experience trying to upgrade to latest version. Downloaded .deb file and did install and all it installs is message aggregator no wsjt-x

On 2021-02-02 11:19 a.m., Bill Somerville wrote:
On 02/02/2021 17:16, Herb Blue - WB8ASI wrote:
Found the answer to my problem over on the HamApps Group.  Seems 2.3.0 has a couple new additional fields since 2.2.2.   In Settings>Reporting under the UDP Server setup, the new field "Outgoing interfaces:" was blank.  I changed it to the "loopback" choice, and also had to checkmark the "WSJT-X UDP Multicast on Loopback" Setting in JTAlert.  All is well again. 73, Herb WB8ASI

Hi Herb,

it was not supposed to be possible to have the "Outgoing interfaces" field in "Settings->Reporting" as blank, it was meant to have the local loopback network interface as the default as a minimum. That defect is repaired for the next release, apologies for any confusion.

73
Bill
G4WJS.



locked Re: 646,693 files & 203 GIGAbytes ! #IssueReport

Karza
 

John,

On 2.2.2021 19.02, JP Tucson, AZ wrote:
I have had "SAVE" set to NONE set for a long time.
So have most of us.


...that AGAIN my C: drive was nearly 2/3 full ! ... found  646,693 files worth over 203 GB of data in the user... wsjtx - "save" directory...  from late Sept. of 2020 till present- INCLUDING the
NEW Version v2.3.0 GA  !!!
I wonder why no-one else has reported this problem...

So apparently, the NONE button under save, does... nothing, just dead.
Only that for everyone else this button (?) seems to do exactly what is advertises.

That was after I FOUND IT!  What I mean is, that the user...wsjtx...save file was set to HIDDEN, but certainly NOT BY ME!
And certainly not by WSJT-X. Why on earth would WSJT-X try to do something like that?

It's an Open Source project. Just try to find a piece of code doing 'change a directory to hidden'  in there.


Anyway, the WSJTX issue here in that since it is set to off, WHY IS IT STILL SAVING it.
Obviously you have some problem with your computer not related to WSJT-X .

May I suggest that while you are trying to find out what's wrong with your computer, you schedule a task to delete unneeded .wav files using Windows Backgound Task facility

https://www.windowscentral.com/how-create-automated-task-using-task-scheduler-windows-10

BR,73, de Kari, oh2gqc


locked Re: Any Faster/Easier Way? #FT8

Bill Lederer
 

Ken:

I don't have an exact solution to what you are asking. What I do with two instances is that I have two tiny computers attached to each their own rig.  Occasionally, I manually produce a master  adi file by combining (concatenating) each individual, and send that back to each of the two computers when wsjtx-x is idle.

I run Intel NUCs (the least expensive ones), but this could be done with even cheaper computers, like the  PI.

w8lvn




On Tue, Feb 2, 2021 at 12:12 PM Ken WB8UFC <wb8ufc@...> wrote:
I usually run two instances of WSJT-X concurrently (FT8).
I often swap the bands on which each instances is operating in order to swap the (mutually perpendicular) antennas fed by the radios driven by those instances.

For example, I start by running the rig "I" instance on 40M (using an E/W antenna) and the rig "Y" instance on 80M (using a N/S antenna).
After a while, I'll swap and run the rig "Y" instance on 40M (using the N/S antenna) and the rig "I" instance on 80M (using the E/W antenna).

If I want to get the advantage of colors for stations I've worked on each band since each instance was first started, I must rescan the ADIF file (I presume the contents are cached upon startup and maintained in memory for the coloring function).
I do this by pressing F2 (to show the "Settings" dialog) and clicking the "Rescan ADF Log" button on the "Colors" tab.

Other than re-starting each instance whenever I am moving to a band the other instance has worked, is there a better/faster way to keep the colors working properly?




--
--w8lvn--


locked Re: Automatic power up of rig #WSJTX_config

David Ross
 

On Thu, Jan 14, 2021 at 06:36 AM, Bill Somerville wrote:
rig to power up
Hi Bill can you please tell me were to enable rig power up in ver 2.3
Many thanks
David Gi4sna 


locked Re: Version 2.3.0 64 bit will not install #install

Andy_501 <andrew.webb.501.ve4per@...>
 

Hi Bill,


I tried downloading the wsjt installer .deb file and having the debi installer install it but always just came back installing only message aggregator alone.

I completely purged older version and reran the same process again and it did the same thing aggregator only. So I purged it all and then just installed the package from the synaptic package manager ; it installed OK and runs but is the older version. Can't seem to get newer versions to install. OS here is ubuntustudio 20.04LTS

which wsjtx =  "/usr/bin/wsjtx"  <--- but this is after reinstalling from synaptic pkg manager.




On 2021-02-02 11:34 a.m., Bill Somerville wrote:
Hi Andy,

that doesn't sound, in any way, similar. Can you explain exactly what went wrong? For example what does this command run from a terminal print:
which wsjtx
73
Bill
G4WJS.

On 02/02/2021 17:32, Andy_501 wrote:

I had similar experience trying to upgrade to latest version. Downloaded .deb file and did install and all it installs is message aggregator no wsjt-x

On 2021-02-02 11:19 a.m., Bill Somerville wrote:
On 02/02/2021 17:16, Herb Blue - WB8ASI wrote:
Found the answer to my problem over on the HamApps Group.  Seems 2.3.0 has a couple new additional fields since 2.2.2.   In Settings>Reporting under the UDP Server setup, the new field "Outgoing interfaces:" was blank.  I changed it to the "loopback" choice, and also had to checkmark the "WSJT-X UDP Multicast on Loopback" Setting in JTAlert.  All is well again. 73, Herb WB8ASI

Hi Herb,

it was not supposed to be possible to have the "Outgoing interfaces" field in "Settings->Reporting" as blank, it was meant to have the local loopback network interface as the default as a minimum. That defect is repaired for the next release, apologies for any confusion.

73
Bill
G4WJS.






locked Re: My WSJTX Has Gone Wierd #FT8

G4RAA
 

Hi Bill

 

In case you are unaware the user guide for 2.3.0 shows the old Tab 2 still in place. It is shown in section 6.4 and 10.5 (where there are instructions on using Tab 2). Both also appear in the pdf version on pages 27 & 73. It caused some confusion here until I found your email!

 

Maybe I missed it but there doesn’t seem to be anything on the old Tab3/new Tab 2 in the regular user guide, although it is in the DXpedition Mode guide of course.

 

73

 

Mike

G4RAA

 

 

From: Bill Somerville
Sent: 02 February 2021 16:17
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] My WSJTX Has Gone Wierd #FT8

 

Hi Steve,

 

Tab 2 has been removed as it was not well maintained and was the source of many defects and support requests.

 

The Tx5 message has the equivalent functionality as the removed Tab2 Free Text field.

 

73
Bill
G4WJS.

 

On 02/02/2021 15:50, Steve - N3SL wrote:

Why is that? How does one now send "free" txt? 

 

On Tue, Feb 2, 2021, 9:32 AM Gary - AG0N <mcduffie@...> wrote:



> On Feb 2, 2021, at 08:26, Jim Forsyth <jim@...> wrote:
>
> Great! That fixed the top part. Thank you Reino.

The bottom part didn’t need fixing.  The old Tab2 has been removed.

Gary - AG0N

 

 


locked Any Faster/Easier Way? #FT8

Ken WB8UFC
 

I usually run two instances of WSJT-X concurrently (FT8).
I often swap the bands on which each instances is operating in order to swap the (mutually perpendicular) antennas fed by the radios driven by those instances.

For example, I start by running the rig "I" instance on 40M (using an E/W antenna) and the rig "Y" instance on 80M (using a N/S antenna).
After a while, I'll swap and run the rig "Y" instance on 40M (using the N/S antenna) and the rig "I" instance on 80M (using the E/W antenna).

If I want to get the advantage of colors for stations I've worked on each band since each instance was first started, I must rescan the ADIF file (I presume the contents are cached upon startup and maintained in memory for the coloring function).
I do this by pressing F2 (to show the "Settings" dialog) and clicking the "Rescan ADF Log" button on the "Colors" tab.

Other than re-starting each instance whenever I am moving to a band the other instance has worked, is there a better/faster way to keep the colors working properly?


locked Re: WSJT-X 2.3.0 GA Rig Control on Yaesu FTDX-3000 #IssueReport

Mark Steele
 

Thank you for the detailed explanation Bill!

I hereby rescind my bug report.


locked Re: 646,693 files & 203 GIGAbytes ! #IssueReport

Sam Birnbaum
 

HI Jim,

I can not attest to he Save / None function, however I wrote and provide a utility program, AllText.exe
that searches the All.txt file. It does not load the file into memory, can be up and running while WSJT-X
appends to the file and given the date, the two callsigns will return the data in less than 0.5 seconds
regardless of the size of the file. The program can be found in https://groups.io/g/ProgramsByW2JDB
Its free, juts subscribe go to files and download it. Quite a few members of this group have already done so.

73,

Sam W2JDB



-----Original Message-----
From: JP Tucson, AZ <samcat88az@...>
To: main@WSJTX.groups.io
Sent: Tue, Feb 2, 2021 12:02 pm
Subject: [WSJTX] 646,693 files & 203 GIGAbytes ! #BugReport

I have had "SAVE" set to NONE set for a long time.

Was looking over the PC (Win10), and saw that AGAIN my C: drive was nearly 2/3 full ! (this is my system drive and it normally only has about 31 GB on it for the system & a few other things)- Going through it, I found  646,693 files worth over 203 GB of data in the user... wsjtx - "save" directory...  from late Sept. of 2020 till present- INCLUDING the 
NEW Version v2.3.0 GA  !!!  Again, I verified that SAVE was set to off in ver 2.2.2, v2.3.0-rc1 thru 4, and the new v2.3.0, all ARE set to off, yet still saving, even after I deleted all of the junk and the directory, it just reopened a new 'save' directory and still saves files.  So apparently, the NONE button under save, does... nothing, just dead.

That was after I FOUND IT!  What I mean is, that the user...wsjtx...save file was set to HIDDEN, but certainly NOT BY ME!  I have NO hidden files, directories, etc. on my computer - since I am the only one using it, and it is password protected (mainly from burglars, if nothing else), there is no reason to hide it.

Anyway, the WSJTX issue here in that since it is set to off, WHY IS IT STILL SAVING it.


And then the following occurred to me... lots of people here are reporting strange operations, S L O W ... ops, etc. - it seems to me that wsjtx has way, waaaay too much overhead, especially in the file saving arena!!!
It's saving to the log file, it's saving to the adi file, it's saving to the large & ever growing all.txt file, and despite SAVE being turned off (NONE), it is still saving the HUGE .wav files!!!!!

I suggest the following;
a) please fix and ensure the .wav files really are NOT being saved when we select 'NONE'!
a1) Please look into if there is some code bug that is hiding the 'save' directory & .wav files (probably unintentionally- burp... it happens
     btw, it did not re-hide the directory, so I don't know if it does this when on of the versions was installed, or when it became hidden.

b) Please breakup the ALL.TXT file into smaller daily files- it will make searching for things easier, and prevent the file from becoming to large to open or search.
b1) In fact, a small utility would be useful - that would allow a user to search the log file for a callsign or date & time, then open up the appropriate all.txt file to that proper area.

Thank you 




locked Re: 646,693 files & 203 GIGAbytes ! #IssueReport

JP Tucson, AZ
 

P.S. Please pardon my typos...

It's kinda hard typing all this out using 1 finger on a cellphone, and worse trying to review-edit out the typos. 

On Tue, Feb 2, 2021 at 10:11 AM JP Tucson, AZ via groups.io <samcat88az=gmail.com@groups.io> wrote:
I have had "SAVE" set to NONE set for a long time.

Was looking over the PC (Win10), and saw that AGAIN my C: drive was nearly 2/3 full ! (this is my system drive and it normally only has about 31 GB on it for the system & a few other things)- Going through it, I found  646,693 files worth over 203 GB of data in the user... wsjtx - "save" directory...  from late Sept. of 2020 till present- INCLUDING the 
NEW Version v2.3.0 GA  !!!  Again, I verified that SAVE was set to off in ver 2.2.2, v2.3.0-rc1 thru 4, and the new v2.3.0, all ARE set to off, yet still saving, even after I deleted all of the junk and the directory, it just reopened a new 'save' directory and still saves files.  So apparently, the NONE button under save, does... nothing, just dead.

That was after I FOUND IT!  What I mean is, that the user...wsjtx...save file was set to HIDDEN, but certainly NOT BY ME!  I have NO hidden files, directories, etc. on my computer - since I am the only one using it, and it is password protected (mainly from burglars, if nothing else), there is no reason to hide it.

Anyway, the WSJTX issue here in that since it is set to off, WHY IS IT STILL SAVING it.


And then the following occurred to me... lots of people here are reporting strange operations, S L O W ... ops, etc. - it seems to me that wsjtx has way, waaaay too much overhead, especially in the file saving arena!!!
It's saving to the log file, it's saving to the adi file, it's saving to the large & ever growing all.txt file, and despite SAVE being turned off (NONE), it is still saving the HUGE .wav files!!!!!

I suggest the following;
a) please fix and ensure the .wav files really are NOT being saved when we select 'NONE'!
a1) Please look into if there is some code bug that is hiding the 'save' directory & .wav files (probably unintentionally- burp... it happens
     btw, it did not re-hide the directory, so I don't know if it does this when on of the versions was installed, or when it became hidden.

b) Please breakup the ALL.TXT file into smaller daily files- it will make searching for things easier, and prevent the file from becoming to large to open or search.
b1) In fact, a small utility would be useful - that would allow a user to search the log file for a callsign or date & time, then open up the appropriate all.txt file to that proper area.

Thank you 




--
73 - John - N7GHZ



locked Re: Version 2.3.0 64 bit will not install #install

Bill Somerville
 

Hi Andy,

that doesn't sound, in any way, similar. Can you explain exactly what went wrong? For example what does this command run from a terminal print:
which wsjtx
73
Bill
G4WJS.

On 02/02/2021 17:32, Andy_501 wrote:

I had similar experience trying to upgrade to latest version. Downloaded .deb file and did install and all it installs is message aggregator no wsjt-x

On 2021-02-02 11:19 a.m., Bill Somerville wrote:
On 02/02/2021 17:16, Herb Blue - WB8ASI wrote:
Found the answer to my problem over on the HamApps Group.  Seems 2.3.0 has a couple new additional fields since 2.2.2.   In Settings>Reporting under the UDP Server setup, the new field "Outgoing interfaces:" was blank.  I changed it to the "loopback" choice, and also had to checkmark the "WSJT-X UDP Multicast on Loopback" Setting in JTAlert.  All is well again. 73, Herb WB8ASI

Hi Herb,

it was not supposed to be possible to have the "Outgoing interfaces" field in "Settings->Reporting" as blank, it was meant to have the local loopback network interface as the default as a minimum. That defect is repaired for the next release, apologies for any confusion.

73
Bill
G4WJS.



locked Re: Version 2.3.0 64 bit will not install #install

Andy_501 <andrew.webb.501.ve4per@...>
 

I had similar experience trying to upgrade to latest version. Downloaded .deb file and did install and all it installs is message aggregator no wsjt-x

On 2021-02-02 11:19 a.m., Bill Somerville wrote:
On 02/02/2021 17:16, Herb Blue - WB8ASI wrote:
Found the answer to my problem over on the HamApps Group.  Seems 2.3.0 has a couple new additional fields since 2.2.2.   In Settings>Reporting under the UDP Server setup, the new field "Outgoing interfaces:" was blank.  I changed it to the "loopback" choice, and also had to checkmark the "WSJT-X UDP Multicast on Loopback" Setting in JTAlert.  All is well again. 73, Herb WB8ASI

Hi Herb,

it was not supposed to be possible to have the "Outgoing interfaces" field in "Settings->Reporting" as blank, it was meant to have the local loopback network interface as the default as a minimum. That defect is repaired for the next release, apologies for any confusion.

73
Bill
G4WJS.





locked Re: Version 2.3.0 64 bit will not install #install

Bill Somerville
 

On 02/02/2021 17:16, Herb Blue - WB8ASI wrote:
Found the answer to my problem over on the HamApps Group.  Seems 2.3.0 has a couple new additional fields since 2.2.2.   In Settings>Reporting under the UDP Server setup, the new field "Outgoing interfaces:" was blank.  I changed it to the "loopback" choice, and also had to checkmark the "WSJT-X UDP Multicast on Loopback" Setting in JTAlert.  All is well again. 73, Herb WB8ASI

Hi Herb,

it was not supposed to be possible to have the "Outgoing interfaces" field in "Settings->Reporting" as blank, it was meant to have the local loopback network interface as the default as a minimum. That defect is repaired for the next release, apologies for any confusion.

73
Bill
G4WJS.


locked Re: Version 2.3.0 64 bit will not install #install

Herb Blue - WB8ASI
 

Found the answer to my problem over on the HamApps Group.  Seems 2.3.0 has a couple new additional fields since 2.2.2.   In Settings>Reporting under the UDP Server setup, the new field "Outgoing interfaces:" was blank.  I changed it to the "loopback" choice, and also had to checkmark the "WSJT-X UDP Multicast on Loopback" Setting in JTAlert.  All is well again. 73, Herb WB8ASI


locked Re: WSJT-X 2.3.0 GA Rig Control on Yaesu FTDX-3000 #IssueReport

Bill Somerville
 

On 02/02/2021 16:26, Mark Steele wrote:
Bill,

Thank you for responding. I was actually able to resolve it :

- Select a band (starting at 160 meters)
- go to VFO A and set IPO / Mode (USB), Split, Width, etc.
- go to VFO B and set IPO / Mode (USB), Split, Width, etc.
- Select next band (80 meters)
- go to VFO A and set IPO / Mode (USB), Split, Width, etc.
- go to VFO B and set IPO / Mode (USB), Split, Width, etc.

Rinse and repeat for every band.

Shut down WSJT-X and restart - it seems to remember all the settings after that.
Hi Mark,

that is as expected, although the WSJT-X restart is not relevant. The Hamlib library now does band changes on modern Yaesu rigs in the same way you would from the rig front panel. Until this version Hamlib simply set the target frequency which works exactly like changing the band then setting the target frequency on most rigs, not so with modern Yaesu rigs. The advantage of the new arrangement, other than equivalence with using the rig's front panel controls, is that the rig will recall settings like aerial socket selected, IPO/pre-amp settings, and others, per band and mode. That should mean that once each band is set as you prefer your settings will be recalled.

One thing to be aware of, and this is the case for all rigs with triple band/mode "stacking" registers, is that pressing the button to select a band (where there is one) more than once in succession will rotate the stack to another recalled set of settings. The WSJT-X/Hamlib combination should never accidentally execute such a band/mode stack rotation but we cannot avoid the user doing it themselves from the rig's front panel.

73
Bill
G4WJS.


locked 646,693 files & 203 GIGAbytes ! #IssueReport

JP Tucson, AZ
 

I have had "SAVE" set to NONE set for a long time.

Was looking over the PC (Win10), and saw that AGAIN my C: drive was nearly 2/3 full ! (this is my system drive and it normally only has about 31 GB on it for the system & a few other things)- Going through it, I found  646,693 files worth over 203 GB of data in the user... wsjtx - "save" directory...  from late Sept. of 2020 till present- INCLUDING the 
NEW Version v2.3.0 GA  !!!  Again, I verified that SAVE was set to off in ver 2.2.2, v2.3.0-rc1 thru 4, and the new v2.3.0, all ARE set to off, yet still saving, even after I deleted all of the junk and the directory, it just reopened a new 'save' directory and still saves files.  So apparently, the NONE button under save, does... nothing, just dead.

That was after I FOUND IT!  What I mean is, that the user...wsjtx...save file was set to HIDDEN, but certainly NOT BY ME!  I have NO hidden files, directories, etc. on my computer - since I am the only one using it, and it is password protected (mainly from burglars, if nothing else), there is no reason to hide it.

Anyway, the WSJTX issue here in that since it is set to off, WHY IS IT STILL SAVING it.


And then the following occurred to me... lots of people here are reporting strange operations, S L O W ... ops, etc. - it seems to me that wsjtx has way, waaaay too much overhead, especially in the file saving arena!!!
It's saving to the log file, it's saving to the adi file, it's saving to the large & ever growing all.txt file, and despite SAVE being turned off (NONE), it is still saving the HUGE .wav files!!!!!

I suggest the following;
a) please fix and ensure the .wav files really are NOT being saved when we select 'NONE'!
a1) Please look into if there is some code bug that is hiding the 'save' directory & .wav files (probably unintentionally- burp... it happens
     btw, it did not re-hide the directory, so I don't know if it does this when on of the versions was installed, or when it became hidden.

b) Please breakup the ALL.TXT file into smaller daily files- it will make searching for things easier, and prevent the file from becoming to large to open or search.
b1) In fact, a small utility would be useful - that would allow a user to search the log file for a callsign or date & time, then open up the appropriate all.txt file to that proper area.

Thank you 


locked Re: UDP Datagram - delay between WSJT-X and logger. #networking

 

Found my delay issues.

 

I found I was only decoding 1 or 2 datagrams each second. I was letting the FLTK event scheduler get a look-in in between each datagram. So of course with the large number of decode datagrams sent  each timeslot, a large delay very quickly built up. I now only let it in when I run out of datagrams to process.

 

I was also confused by comparing the timestamp in the decode datagram and the time I received it. Of course the timestamp in the datagram is the start of the timeslot and I only receive it towards the end. Hence the 12s minimum I thought I was seeing.

 

73 Phil GM3ZZA

 

 

Sent from Mail for Windows 10

 

From: Philip Rose - GM3ZZA
Sent: 01 February 2021 15:40
To: main@WSJTX.groups.io
Subject: RE: [WSJTX] UDP Datagram - delay between WSJT-X and logger. #udp

 

Hi Bill,

 

I’ve now run some tests.

 

Scenario 1:

On my code development machine: laptop, no rig attached.

My logger running under VS2019 development about 10s delay from closing WSJT-X to getting the close datagram.

My logger stand-alone, almost instantaneous.

Message_aggregator – instant updates.

 

WSJT-X only sends heartbeats and status datagrams when I change say Dx Call on WSJT-X.

 

Scenario 2:

On my shack machine

Message_aggregator – instant updates, so it doesn’t look like it’s AVG interfering.

My logger stand-alone accessing the rig through Flrig every second – minimum 12 second delay on decode datagrams going out to 4 minutes.

My logger stand-alone not accessing the rig – minimum 12 s delay going out a bit. I hoped this would be almost instantaneous as that would point to polling the rig slowing my code down.

 

WSJT-X sends a heartbeat every 15 seconds or so, several status datagrams during this time and several decodes every 15 seconds (20 m afternoon).

 

The only difference between the two cases without connecting my logger to a rig seems to be the number of datagrams I have to handle. I think I am having to go and learn how to multi-thread my code so that I can poll the datagrams more frequently without impacting on other functionality, or some other way to convert the socket handling to be interrupt driven.

 

Phil.

 

Sent from Mail for Windows 10

 

From: Bill Somerville
Sent: 29 January 2021 16:19
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] UDP Datagram - delay between WSJT-X and logger. #udp

 

On 29/01/2021 16:14, Philip Rose via groups.io wrote:

> The last couple of days, I've noticed the delay between WSJT-X sending the datagram and my logger receiving it being in excess of 2 minutes. Both times I had had the event viewer open and using VS2019 to try and trap an exception in my logger. I rebooted to clear any residual effect of the event viewer and without VS2019 attached was seeing delays of about 12s, which is what I remember seeing before installing -rc4. Unfortunately my logger died too soon to see how consistent this was.

> I restarted my logger and attached VS2019 and again  initially I was seeing delays of about 12s. After somewhile this drifted out to about 35s, but drifted back again.

> I have configured the UDP connection as point-to-point with my logger as UDP server on port 2237.

> I had always seen a delay between hitting the log button on WSJT-X and my logging seeing the datagram, but I had put that down to the WSJT-X scheduling algorithm and waiting until it had spare CPU to send the datagram.

> As I am now more aware that others are using JTAlert and other servers to annotate their WSJT-X windows, I now assume that even 12s is a ridiculuously long time.  This might be because I am polling the UDP port, I haven't found out how to get the serial port to interrupt my code. I need to study the Windows documentation more thoroughly, unless anyone has any ideas.

> 73 Phil GM3ZZA

 

Phil,

 

the delay should be of the order of micro-seconds on the local loopback

interface. Try starting the mesage_aggregator test application supplied

with WSJT-X and see how little latency there is between the Log QSO

dialog OK button click and reception of the logged QSO UDP message. The

udp_daemon test application also notifies receipt of logged QSO datagrams.

 

73

Bill

G4WJS.

 

 

 


--
73 Phil GM3ZZA

12961 - 12980 of 34363