Re: [wsjt-devel] N5J - odd cycle reply

[Reino Talarmo via wsjt-devel]

Hi Alan,

You may just dismiss that observation as it is a false positive. That passed 
message error detection. The red message is a DXpedition message used by the 
Fox station in the “old” Fox and Hound protocol, nothing to do with the 
SuperFox transmission.

You should see the high probability of a false message as it contains two 
warnings or advices “?” and “a2”, see user guide 12.1. AP Decoding for further 
information.

 

73, Reino OH3mA

 

From: Alan McDonald via wsjt-devel  
Sent: Wednesday, August 7, 2024 11:22 AM
To: 'WSJT software development' 
Cc: Alan McDonald 
Subject: [wsjt-devel] N5J - odd cycle reply

 

I am not sure how I get a reply from N5J in the odd cycle – any ideas?

 



 

Regards

Alan McDonald

Worimi Country

  VK2MET/VK1AO/VK1O – AllStar 512811 – Echolink 
590992 – GridSquare QF67bg

 

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

Re: [wsjt-devel] ALL.TXT RX freq is not RX DIAL freq

[Reino Talarmo via wsjt-devel]

Hi Andy,
May I conclude that we want to report the actual
(correct) transmit frequency at all wsjt-x modes (by
definition the lowest FSK tone).
There are situations where the rig frequency display is
not correct for various reasons such as the transverter
frequency is not adjusted exactly, but is known. Another
case is the frequency calibration wsjt-x supports. E.g.
my rig shows 14074.007 kHz, when it is correctly at
14074.000 kHz. Not a big deal in FT8 at HF, but on other
bands on different modes in weak signal working can make
a difference. So that correction should be taken into
account in a possible batch. Perhaps as selectable
feature.

73, Reino OH3mA



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

Re: [wsjt-devel] ALL.TXT RX freq is not RX DIAL freq

[Reino Talarmo via wsjt-devel]

My humble opinion is that the reported frequency should be sum of the frequency 
display and the waterfall frequency. That’s in case those are really what is 
actually transmitted. Joe’s case is a bit different and in that sense a 
selection may be needed. 

 

73, Reino OH3mA

 

From: Black Michael via wsjt-devel  
Sent: Monday, July 29, 2024 8:58 PM
To: wsjt-devel@lists.sourceforge.net; Andy Durbin 
Cc: Black Michael 
Subject: Re: [wsjt-devel] ALL.TXT RX freq is not RX DIAL freq

 

That value is meant to only change during band change to avoid messing up 
typing into the freq box.  It's only used in the one place.

 

Unless Joe has some other observation it doesn't appear to me that this change 
harms anything.  Making it an option just means nobody will know to use it to 
avoid the problem.  And we've had plenty of reports of pskreporter things being 
wrong which we've already done some work on to minimize errors.  It's pretty 
critical that pskreporter spots are correct for any number of reasons.

 

Mike W9MDB

 

 

On Monday, July 29, 2024 at 12:50:03 PM CDT, Andy Durbin mailto:a.dur...@msn.com> > wrote: 

 

 

Mike,

 

Thanks for looking at this.

 

I intentionally proposed an option because Joe had indicated there were reasons 
it was implemented to use table frequency rather than current dial frequency.

 

By implementing as an option those who like the way it works now would see no 
change.  

 

I documented a more extreme case than had been in included in draft 2.  With no 
frequency table loaded I tuned a spot collector CW spot at 21.011900.   I 
couldn't hear the spot so I used rig conrols to set USB mode and 21.074000.   
PSK Reporter showed all the stations I decoded  as offsets from 21.011900!

 

e.g.

Dial frequency 21.074

All.txt decode 240728_17414521.012 Rx FT8-12 -0.8 1465 BD4WVQ K4JOM EM60

PSK Reporter showed K4JOM received at 21.013.365

 

73,

Andy, k3wyc

 

 

 

  _  

From: Black Michael mailto:mdblac...@yahoo.com> >
Sent: Monday, July 29, 2024 10:34 AM
To: wsjt-devel@lists.sourceforge.net   
mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Andy Durbin mailto:a.dur...@msn.com> >
Subject: Re: [wsjt-devel] ALL.TXT RX freq is not RX DIAL freq 

 

This small change fixes the problem.

Adding this outside the if clause ensures it is updated with current 
information...

m_freqNominalPeriod = m_freqNominal;

 

Although we should probably not do pskreporter when the frequency changes like 
this as we aren't sure which frequency was decoded.

 

Mike W9MDB

 

 

 

 

 

 

 

void MainWindow::displayDialFrequency ()

{

  if (ui->actionUse_Dark_Style->isChecked()) 
ui->bandComboBox->setStyleSheet("QLineEdit {background-color: #31363b}");  // 
initialize dark style at startup

  Frequency dial_frequency {m_rigState.ptt () && m_rigState.split () ?

  m_rigState.tx_frequency () : m_rigState.frequency ()};

 

  // lookup band

  auto const& band_name = m_config.bands ()->find (dial_frequency);

  m_freqNominalPeriod = m_freqNominal;

  if (m_lastBand != band_name)

 

 

 

 

 

On Sunday, July 28, 2024 at 11:55:46 AM CDT, Andy Durbin via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

 

 

"What rig do you have that WSJT-X does not follow rig freq changes? 

 

Mike W9MDB"

 

 

I have no such rig.  WSJT-X follows my rig frequency with 1 Hz resolution as 
indicated in the draft paper.

 

The issue is not that WSJT-X does not follow the rig frequency.  The issue is 
that WSJT-X knows the rig frequency but may report a different frequency to 
ALL.TXT and PSK Reporter.  

 

Would you please read the full draft and let me know if any part needs 
clarification.

 

Thanks and 73,

Andy, k3wyc

 

 

 

___
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] Question on log and inconsistent worked B4 Status

[Reino Talarmo via wsjt-devel]

> That's not per the adif specs. this is a Wsjtx defect IMO.

 

Hi Laurie,

Thanks, agreed, but I am not sure, whether this defect is corrected or not. 
Just in case I added that possibility into my mail.
By now I have not seen any response from the originator, is it solved or not?

 

73, Reino OH3mA

 

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

Re: [wsjt-devel] Question on log and inconsistent worked B4 Status

[Reino Talarmo via wsjt-devel]

Hi Neal,

I may not know all issues related to your questions, but can give some hints.
The Rescan tries to read the wsjtx_log.adi file, the name must be exactly that.
When the Rescan is run there is a short time information how many WB4 stations 
were identified at the left lowest corner of the main window. 
The wsjtx_log.adi file should have only a single (or none) header information 
ending with .

There should not be any empty lines in the middle of the adi file.
I assume that the record can be divided into lines as long as there in no empty 
ones. You may easily to check that by taking some QSOs from the start of you 
adi file and try to Rescan the short wsjtx_log.adi and see how may WB4 station 
you got.

 

73, Reino OH3mA

 

From: Neal Pollack via wsjt-devel  
Sent: Monday, July 29, 2024 1:55 AM
To: WSJT software development 
Cc: Neal Pollack 
Subject: [wsjt-devel] Question on log and inconsistent worked B4 Status

 

I am one of those user types who install every single RC# for the

last 8 years.  Each time I reinstall wsjtx, I change to a new appdata folder

using the wsjtx --rig-name= .

Over time, I have deleted a number of those older appdata folders.

Therefore, my WSJT-X log.adi is very small, and my worked B4 status is

incomplete.

 

In reading the WSJT-X user docs, I see that I can import my

full 10 year ADIF file from my other logging sources, and then

click the rescan button in WSJT-X.  This was only partially

effective, as some callsigns that are clearly in my log several

times are not showing up in the WSJT-X activity window as  

"Worked Before".Others do show worked B4.   In trying to diagnose 

this issue, I have the following questions to hopefully expand my knowledge;

 

1.   WSJT-X writes it's wsjtx_log.adi entries as a horizontal line

  ending with the expected .

 

 Example: ...DM03 50W N6YFM 

 

  However, when I download my full entire log ADIF from either ACLOG or 
QRZ, 

  each QSO record is a vertically stacked set of  ADIF fields, ending in 
the  

  on the last line all by itself. Example:

...

FM19
FT8
N6YFM
30.0
MD


 

  Does WSJT-X know how to deal with this for the re-scan for B4 status?  

  Or do I first need to edit my full ADIF log and make each QSO one long 
horizontal 

  line ending in , before I place it in the wsjtx log directory and 
rename it to 

  wsjtx_log.adi?

 

2.   Using the latest pre-release for wsjtx v2.7-rc6, when I go into

  SETTINGS -> COLORS, and click the rescan ADIF log button, there is no

  feedback (unless I am missing something).   I tested after rescan, and 
tried a few 

  QSOs.  For two QSOs in search and pounce, the band activity window did 
NOT show 

  that I worked them before. However, my logging software in both QSOs 
showed I had

  worked each callsign 2 or 3 times before.  Other QSOs properly showed 
worked B4

  status.  So something is incomplete for worked B4 status.

  QUESTION:

  What does the rescan actually do?  Are there some changes added to the 
log file,

  or is some data written to another file?   I would like to know what to 
look for, so I 

  can diagnose this issue with worked-B4 status.

 

Sincere Thanks,

 

Neal

N6YFM

 

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

Re: [wsjt-devel] Adjustable frequency shift for split operation?

[Reino Talarmo via wsjt-devel]

>This does make me wonder though, why only jump in 0.5KHz increments? Not that 
>the logic is difficult but wouldn't it be simpler to just allow a "sweet spot" 
>setting and use that to offset the TX frequency? 

 

Richard, you may have not fully understood the Split operation. Your actual RF 
transmit frequency does not change at all. Yes, you see how the VFO i.e. rig’s 
transmit frequency is jumping. What you don’t see is that the audio frequency 
is changed the same amount into opposite direction. 

 

73, Reino OH3mA

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

Re: [wsjt-devel] Adjustable frequency shift for split operation?

[Reino Talarmo via wsjt-devel]

Richard,

You may check your transmitter passband by selecting None in the Split 
Operation. Then your transmit frequency is not jumped at 1500 and 2000 Hz 
boundaries. 

 

73, Reino OH3mA

 

From: Richard Shaw via wsjt-devel  
Sent: Saturday, July 6, 2024 2:49 PM
To: Black Michael 
Cc: Richard Shaw ; WSJT software development 

Subject: Re: [wsjt-devel] Adjustable frequency shift for split operation?

 

On Fri, Jul 5, 2024 at 10:16 PM Black Michael mailto:mdblac...@yahoo.com> > wrote:

And does the power go back up when you go above 1900?

Sounds like it might be a notch filter.

 

Doesn't seem to be the problem. The highest I can get is 1999Hz before the 
frequency changes but it's still <5W. 

 

I checked the data options and they are set to Dave's (W1HKJ) recommendations 
or wider:

 

066 DATA LCUT FREQ - OFF

067 DATA LCUT SLOPE - 18dB/oct

068 DATA HCUT FREQ - 3600Hz

069 DATA HCUT SLOPE - 6dB/oct

 

I also checked 110 SSB TX BPF but I don't think it applies to DATA modes, only 
SSB.

 

Thanks,

Richard

KF5OIM

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

Re: [wsjt-devel] Sequence

[Reino Talarmo via wsjt-devel]

Joe, are you talking about normal working or most Special Event contests? The 
first one requires sending of the Tx1 for the grid. The special events (most of 
them) don’t send Tx1 as the grid is also in Tx2. 

 

73, Reino OH3mA

 

From: Joe via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Monday, June 3, 2024 12:06 AM
To: Black Michael ; WSJT software development 

Cc: Joe 
Subject: Re: [wsjt-devel] Sequence

 

 I understand that.

But they got the grid from me. when I answered the CQ.

If the TX-4 was used it would be a contact like thursday evenings.

Joe WB9SBD

On 6/2/2024 3:57 PM, Black Michael wrote:

Simple -- need to know grid to know distance.  Without grid distance=0.
 
Mike W9MDB
 
 
 
 
 
 
 
 
On Sunday, June 2, 2024 at 03:46:43 PM CDT, Joe via wsjt-devel  
  
wrote: 
 
 
 
 
 
Huh?
Explain this statement.
 
Joe WB9SBD
 
 
On 6/2/2024 1:12 PM, OG55W via wsjt-devel wrote:
 
 

  

People are using Max Distance to select who will be answered!
If You answer without the locator, You are the last one in the queuthe 
nearest one
 
Keijo OG5O
 
 
Joe via wsjt-devel kirjoitti 2.6.2024 klo 20.28:
 
 

  

I wish there was a way to tell it what sequence it does.
 
I'd rather have it do this,
 
Right click  enable S Mode, (Orange Button)
It decides who CQing to call and sends TX-2
If they answer me I want it to send TX-4
 
Joe WB9SBD
 
 
 
 
 
 
___
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] Clear Active Stations list/log from last year

[Reino Talarmo via wsjt-devel]

Hi Les,

‘Real’ contest gurus use external programs for contesting such as N1MM, but you 
can manage also without any. Just name the wsjtx_log.adi file in the Log 
directory to keep it for further normal working. WSJT-X will generate a new 
one, when you log the first QSO in the contest. 
After the contest you may combine the old and new wsjtx_log.adi files together, 
if you consider also the QSOs in the contest as worked before stations. Note 
that in the combining you need to make sure that the is only a single header 
information in the file at the start of the combined file ending with .

 

73, Reino OH3mA

 

From: Leslie L via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Friday, May 31, 2024 4:42 AM
To: WSJT software development 
Cc: Leslie L 
Subject: [wsjt-devel] Clear Active Stations list/log from last year

 

Hi all,

 

 Getting ready for the Digi contest, reset Cabrllo file  but how and were do I 
clear out whatever log  the Active  Station display uses to identify and remove 
stations previously worked on the contest. 

 

Les

W2LPL

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

Re: [wsjt-devel] Hamlib error

[Reino Talarmo via wsjt-devel]

A minor addition for Windows users. The COM port should be ‘Enhanced’ one for 
CAT control, see Device Manager – Ports (COM & LPT).

 

73, Reino OH3mA

 

From: Jeff Stillinger via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Monday, April 29, 2024 8:17 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Jeff Stillinger 
Subject: Re: [wsjt-devel] Hamlib error

 

As Mike has already said, USB is not a valid com port.   So the error message 
says exactly what the problem is.

Linux should be something similar to this:  /dev/ttyUSB0 or /dev/ttyUSB1.
My Icom 7100 is set to /dev/ttyUSB0 for cat control.   

Windows is a completely different beast.   Again, the error message saying that 
USB is not a valid com port.
Windows and the drivers actually assign a com port.   Usually, something 
bizarre like COM5 and COM6 using
the Icom provided drivers.

Follow in the installation instructions in Chapter 3 of the User Guide, 
combined with the driver installation 
instructions available from Icom.




On 4/28/24 17:31, Eric Lundstrom via wsjt-devel wrote:

Installed wsjtx_2.6.1_amd64.deb on a lubuntu OS and received the hamlib error 
shown below.

 

Installed wsjtx-2.6.1-win64.exe on a windows 10 OS and received basically the 
same error.

 

The hamlib DLL on the Windows machine has a file date of 1/10/2023, a size of 
9.7 mb, and a file name of libhamlib-4.dll.

 

Have wsjtx set up for CAT control on an IC-7300. Some years back wsjtx was 
working on both Linux and Windows on the IC-7300.

 

Any suggestions are welcome.

 

73 WB6CVR

 








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





-- 
Jeff Stillinger - KB6IBB
KB6IBB Laboratories, Wylie Tx
http://kb6ibb-15.ham-radio-op.net/
Reddit: r/KB6IBBSWLLogger
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Another fun hash collision P97USI

[Reino Talarmo via wsjt-devel]

Jon,

It would be interesting to know whether you have decoded a message containing 
P97USI/P within 231900 and 232530 and what that message was?

 

73, Reino OH3mA

 

From: Jon Anhold via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, February 27, 2024 2:50 AM
To: WSJT software development 
Cc: Jon Anhold 
Subject: [wsjt-devel] Another fun hash collision P97USI

 

231900 16 0.4 909 ~ BG2AUE  -25 Aruba

232530 5 0.4 909 ~ JR3UIC RR73; JA7WND  +06 DPR of Korea

 

Maybe some logic that checks "am I *really* North Korea?" would be good :)

 

73 de KM8V Jon

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

Re: [wsjt-devel] Misleading QTH info on JTAlert

[Reino Talarmo via wsjt-devel]

Hi,
Just a clarification question. Do you update QRZ.com
Grid Square information each time you move between those
two operation locations?
The question as such may be more appropriate on the
HamsApps forum https://hamapps.groups.io/

73, Reino OH3mA

> -Original Message-
> From: Luis Miguel Castañeda via wsjt-devel
[mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Thursday, February 15, 2024 12:00 PM
> To: WSJT software development  de...@lists.sourceforge.net>
> Cc: Luis Miguel Castañeda
> ; vk3a...@vkdxer.net
> Subject: Re: [wsjt-devel] Misleading QTH info on
JTAlert
> 
> 
> I have the exact same problem, I operate from IM89AW
> and IN70HD with same callsign. I haven't had
complains,
> but saw the issue.
> 
> On Tuesday, February 13 2024, 10:29:02, Ed Stokes via
> wsjt-devel
> wrote:
> 
> > 1.  ( ) text/plain  (*) text/html
> >
> > Laurie & Uwe,
> >
> > As a ham who operates from several locations using
> the same call sign
> > but different grid squares (FN33 & DM04), it often
> happens that other
> > ops will be misdirected by JTAlert, leading them to
> believe they have
> > contacted Vermont (FN33) when they have responded
> to my call clearly
> > indicating my grid as (DM04).
> >
> > As proof to me that they have worked Vermont they
> will send me a
> > screen shot or other image showing the JTAlert box
> misleading them to
> > think so.
> >
> > Is it possible to correct this?
> >
> > Many thanks, Ed
> > W1KOK
> >
> > [4. text/plain]
> >
> > [5. text/plain]
> >
> ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> >
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> --
> Nobody realizes that some people expend tremendous
> energy merely to be normal.
>   --- Mark Twain
> 
> 
> 
> ___
> 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] Not sure if an issue

[Reino Talarmo via wsjt-devel]

[Edited message as I forgot to remove unnecessary part of the mail chain, sorry 
for that]

Hi all,
I have run WSJT-X latest versions now 2 year more or less 24/7 using Windows 10 
and one or two times a Windows update has re-arranged my audio interfaces 
resulting that kind of situation. 
The program alone has not done it as far as I can tell.
I have of course disabled all power saving modes in Windows.

73, Reino OH3mA

> -Original Message-
> From: Tom Paratore via wsjt-devel [mailto:wsjt- 
> de...@lists.sourceforge.net]
> Sent: Wednesday, February 14, 2024 7:42 AM
> To: WSJT software development  de...@lists.sourceforge.net>
> Cc: Tom Paratore 
> Subject: Re: [wsjt-devel] Not sure if an issue
> 
> Sounds like a memory leak.
> 
> If you can run task manger and monitor the memory tab to see which 
> program continues to consume memory, it may help to identify the 
> cause.



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

Re: [wsjt-devel] Not sure if an issue

[Reino Talarmo via wsjt-devel]

Hi all,
I have run WSJT-X latest versions now 2 year more or less 24/7 using Windows 10 
and one or two times a Windows update has re-arranged my audio interfaces 
resulting that kind of situation. 
The program alone has not done it as far as I can tell.
I have of course disabled all power saving modes in Windows.

73, Reino OH3mA

> -Original Message-
> From: Tom Paratore via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Wednesday, February 14, 2024 7:42 AM
> To: WSJT software development  de...@lists.sourceforge.net>
> Cc: Tom Paratore 
> Subject: Re: [wsjt-devel] Not sure if an issue
> 
> Sounds like a memory leak.
> 
> If you can run task manger and monitor the memory tab
> to see which program continues to consume memory, it
> may help to identify the cause.
> 
> > On Feb 14, 2024, at 12:09 AM, Alan McDonald via wsjt-
> devel  wrote:
> >
> > Yes - Windows
> >
> > Alan VK1AO
> >
> > -Original Message-
> > From: jarmo via wsjt-devel  de...@lists.sourceforge.net>
> > Sent: Wednesday, February 14, 2024 3:56 PM
> > To: wsjt-devel@lists.sourceforge.net
> > Cc: jarmo 
> > Subject: Re: [wsjt-devel] Not sure if an issue
> >
> > Wed, 14 Feb 2024 09:44:17 +1100
> > Alan McDonald via wsjt-devel  de...@lists.sourceforge.net>
> > kirjoitti:
> >
> >> It happens to me frequently. I leave the app running
> all the time
> >> (not using it but it sits there).
> >>
> >> Switching CODECs works all the time but curiously I
> never have to do
> >> this for MSHV or JTDX. They keep the CODEC.
> >>
> >> What happens is the sound comes out of my radio
> speaker until I
> >> switch it back to USB again.
> >>
> >>
> >>
> >> Alan / VK1AO
> >
> > Not seen this kind behaviour. Have pretty much wsjtx
> running 24/7 some
> > years now.
> > OS Fedora 39 (now)
> > Just now testing 2.7.1-devel
> > Older genetation i7 desktop...
> >
> > Is this happening with WIN?
> >
> > Jarmo
> >
> >
> >
> ___
> > 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] Response to CQ ignored

[Reino Talarmo via wsjt-devel]

Hi Lance,
See https://groups.io/g/ProgramsByW2JDB 
It's the first one QLog. Look Files for download.

73, Reino OH3mA

> -Original Message-
> From: Lance Collister via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Friday, February 2, 2024 10:47 PM
> To: Sam W2JDB via wsjt-devel  de...@lists.sourceforge.net>
> Cc: Lance Collister 
> Subject: Re: [wsjt-devel] Response to CQ ignored
> 
> Hi Sam,
> 
> I am interested to learn more about your program for
> blind hams. Is it something called WSJT-Z? I know that
is
> what XV9T (who is blind from a stroke) currently uses.
> 
> MNI TNX and VY 73, Lance
> 
> On 1/30/2024 12:55:02, Sam W2JDB via wsjt-devel
> wrote:
> > Hi Uwe,
> >
> > Ed should check the Ini file. there are three
entries in
> there that
> > might create a problem in the program if somehow
> they conflict.
> >
> > I know I ran into this problem when I wrote/updated
> my program for the blind hams.
> >
> > TxFirst=true
> > CallFirst=1
> > ForceCallFirst=true
> >
> >
> > 73,
> >
> >
> > Sam W2JDB
> 
> --
> Lance Collister, W7GJ(ex WA3GPL, WA1JXN,
> WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M,
> TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ,
> CP1GJ, S79GJ, FO/W7GJ, TX7MB, TO7GJ, 3B9GJ) P.O. Box
> 73
> Frenchtown, MT   59834-0073
> USA
> TEL: (406) 626-5728
> QTH: DN27ub
> URL: http://www.bigskyspaces.com/w7gj
> Skype: lanceW7GJ
> 2m DXCC #11 - 6m DXCC #815 - FFMA #7
> 
> Interested in 6m EME?  Ask me about subscribing to the
> Magic Band EME email group, or just fill in the
request
> box at the bottom of my web page (above)!
> 
> 
> 
> ___
> 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] Response to CQ ignored

[Reino Talarmo via wsjt-devel]

Sam, the mail service had hick-up for some reason. My mails were delayed hours.

 

73, Reino OH3mA

 

From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, January 30, 2024 2:46 PM
To: WSJT software development 
Cc: Sam W2JDB 
Subject: Re: [wsjt-devel] Response to CQ ignored

 

Sorry about this. My email service did not show any emails for a while. 

Seems I have a problem here.

 

73,

 

Sam W2JDB

 

 

 

On Tuesday, January 30, 2024 at 07:44:17 AM EST, Sam W2JDB via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Hi Uwe,

 

 

I sent this email earlier, somehow it did not go through.

 

Hi Ed,

 

Make sure you have the right option selected  "CQ:First"

 

73,

 

Sam W2JDB

 

 

 

On Tuesday, January 30, 2024 at 06:53:47 AM EST, Uwe, DG2YCB via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Hi Ed,

At the moment, I have no explanation why it doesn't work with the "231202" i+ 
version. What I can say is that it definitely works well with the current 
"240106" code, as well as with the new "240202" version that will be released 
on Friday this week. I recommend that you download this version on Friday and 
then see whether the error persists or not. This version will also bring a few 
nice new features, which I'll explain in the following video: 
https://www.youtube.com/watch?v=1CqyIGRjbvs  
 


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de  
Info: www.qrz.com/db/DG2YCB  



Am 30.01.2024 um 00:56 schrieb Ed Stokes via wsjt-devel:

I see this over and over….
 
Is it me or is this a bug?
 
I call CQ and someone responds.  But WSJT does not answer the caller.  It 
continues to call CQ until I force it to reply.
 
73, Ed
W1KOK 

 

___
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] Decoding Anomaly

[Reino Talarmo via wsjt-devel]

Hi Dennis,

There may be something to improve in the hash table(s) management as in your 
example the first message CQ PJ5/SP9FIH was sent in full (it is a non-standard 
call, but that should not matter). Why the 10 bits hash was not updated into 
the hash table, but there is DP1POL instead for the 10 bits hash and at the 
same time for PJ5/SP9FIH the longer 22 bits hash it is correct. Of course 
PJ5/SP9FIN and DP1POL don’t collide at the 12 and 22 bits long hashes. 

Well, a simple possibility is that the 10 bits hash table is in alphabetic 
order and the hash values are not updated, but there are two callsigns for the 
same hash and DP1POL is the first found. Sri, I have no fact about the hash 
tables, but in my logic the CQ PJ/SP9FIH message should have ‘updated’ a 
linkage of all hash 10, 12 and 22 values for that callsign and ‘removed’ 
linkage to DP1POL at least for the 10 bits hash for the next messages.

(By the way there are 10, 12 and 22 bits hashes also for SP9FIH in the case 
that were used and those don’t collide with DP1POL.)

 

73, Reino OH3mA

 

From: Dennis Younker NE6I via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, January 30, 2024 1:59 AM
To: 'WSJT software development' 
Cc: Dennis Younker NE6I 
Subject: Re: [wsjt-devel] Decoding Anomaly

 

Thanks, what would be special about PJ5/SP9FIH in this case? I have not seen 
this with others using “portable designators.”

 

--Dennis NE6I

 

From: Jim Reisert AD1C via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Monday, January 29, 2024 3:09 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Jim Reisert AD1C mailto:jjreis...@alum.mit.edu> >
Subject: Re: [wsjt-devel] Decoding Anomaly

 

It's a callsign hash collision.  DP1POL has not been operating on those 
frequencies.

 

 

On Mon, Jan 29, 2024 at 4:07 PM V. Scott Moore via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

I saw similar decodes.  I attributed it to two stations on the same frequency.  
The PJ5 was very strong here and when multi-streaming his/her signal came down 

and revealed the less powerful (but still +10 here) Antarctic station.

 

scott

W1SSN

 

On Jan 29, 2024, at 17:47, Carl Moreschi via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

 

I just saw exactly the same things on 17 meters.

Carl Moreschi N4PY
127 River Moss Way
Hertford, NC 27944
www.n4py.com  

On 1/29/2024 5:31 PM, Dennis Younker NE6I via wsjt-devel wrote:

Wondering if anyone else is seeing this issue. PJ5/SP9FIH is operating F/H. 
When he is transmitting one stream, his call is displayed correctly in the Rx 
Frequency window. When he transmits two streams, the call sign DP1POL is 
displayed instead.  See below for an example.
--Dennis NE6I
222830  -2 -0.4  492 ~  CQ PJ5/SP9FIH   Saba & St. Eustatius
222900  -4 -0.4  492 ~  N5HD  +02
222930   0 -0.4  492 ~  N5HD RR73; EA7QL  -04
223000  -4 -0.4  492 ~  EA7QL  -05
223030  -2 -0.4  492 ~  EA7QL RR73; LU7EML  -12
___
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

 

“Got time to breath, got time for music” - Brisco Darling

 

 

 

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



-- 

Jim Reisert AD1C, mailto:jjreis...@alum.mit.edu> >, 
https://ad1c.us

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

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Reino Talarmo via wsjt-devel]

Yes, that improves decoding sensitivity quite a lot and
is useful once you have started a QSO. You may study the
a priori principle in the user guide 12.1. AP Decoding
and in more details in the reference 33,
https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf, especially
Figure 7, Table 6 and Figure 8. 
Of course you may not use it in FT8, just disable in
Decode menu the Enable AP.
On the other hand also without the AP you still can get
false decodes as the message error detection is not 100
% reliable. There are in the message 77 information bits
and 14 error detection bits and that provides good
enough message error detection after forward error
correction. Perhaps FT8 is too good compared to RTTY and
CW and operators rely on what's written on screen, hi!
I have some 24/7 measurements over two years and I have
collected more than 80 000 callsigns and there are e.g.
108 callsigns starting with '0', 193 callsigns starting
with '1', the latter contains some real ones. That
continues to all figures and numbers, but it is harder
to tell fake ones; say order of 4000 total e.g. 5%. We
should remember that the fake ones are received only
once almost for certain and the real ones 100's of
times. Most of those false decodes are not due to AP,
perhaps half of the recording time I have not used AP as
it takes more processor resources.
It is an operator's fun to use his brains and detect
false decodes although those may be with red background!

73, Reino OH3mA

> -Original Message-
> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Saturday, January 27, 2024 1:12 AM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Glenn Williams 
> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 119,
Issue
> 45
> 
> So,
> Do you mean that a priori information is used to help
> decode?  That's a bias.  Shouldn't decodes stand on
their
> own?
> -73, Glenn, AF8C
> 
> On 1/26/2024 12:32 PM, Reino Talarmo via wsjt-devel
> wrote:
> > Hi Glenn, congrats about a nice false decode. The
'a3'
> > tells that the decoder tried as the known
information
> your call, DX
> > call, and rest is decoded. The '?'
> > indicates that the probability of correct message is
not
> too high.
> > Also the contents of the decoded part is suspicious
as
> the report is
> > just 'R' and the locator 'RA92' is in the middle of
> Antarctica.
> >
> > 73, Reino OH3mA
> >
> >
> >> -Original Message-
> >> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> >> de...@lists.sourceforge.net]
> >> Sent: Friday, January 26, 2024 6:43 PM
> >> To: wsjt-devel@lists.sourceforge.net
> >> Cc: Glenn Williams 
> >> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol
119,
> > Issue
> >> 45
> >>
> >> I am reporting here another issue with my TX5S QSO
> and the FT8
> >> windows that happened last night.  (Previous report
> is under
> >> "Subject:
> >> [wsjt-devel] skips RX frequency window (bug?)
wsjtx-
> >> 2.7.0-rc3".)  I am also NOT confirmed in ClubLog!
> >>
> >> My screenshots with iPhone are in
> >>
> >> https://www.hamfaqs.com/tx5s
> >>
> >> and I don't believe it was RFI because I was ONLY
> receiving at the
> >> time!
> >>
> >> --73, Glenn, AF8C
> >>
> >> On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel
> >> wrote:
> >>> Hi Fred and all,
> >>>
> >>> It's really strange. Seems to be working well
here.
> > Look
> >> at the Rx
> >>> Frequency windows of the three instances. (all
> >> connected via virtual
> >>> audio, so nothing went over HF). To the left the
Fox
> >> station, and to
> >>> the right the two hounds. I tried to reproduce
your
> >> QSO situation when
> >>> the Fox was also in QSO with JH1BAM. Do you see
> any
> >> message not being
> >>> displayed there?
> >>>
> >>>
> >>> 73 de DG2YCB,
> >>> Uwe
> >>> 
> >>> German Amateur Radio Station DG2YCB
> >>> Dr. Uwe Risse
> >>> eMail: dg2...@gmx.de
> >>> Info: www.qrz.com/db/DG2YCB
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> __
> >> _
> >>> 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 Ava

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

[Reino Talarmo via wsjt-devel]

Hi Glenn, congrats about a nice false decode. The 'a3'
tells that the decoder tried as the known information
your call, DX call, and rest is decoded. The '?'
indicates that the probability of correct message is not
too high. 
Also the contents of the decoded part is suspicious as
the report is just 'R' and the locator 'RA92' is in the
middle of Antarctica. 

73, Reino OH3mA


> -Original Message-
> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Friday, January 26, 2024 6:43 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Glenn Williams 
> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 119,
Issue
> 45
> 
> I am reporting here another issue with my TX5S QSO and
> the FT8 windows that happened last night.  (Previous
> report is under "Subject:
> [wsjt-devel] skips RX frequency window (bug?) wsjtx-
> 2.7.0-rc3".)  I am also NOT confirmed in ClubLog!
> 
> My screenshots with iPhone are in
> 
> https://www.hamfaqs.com/tx5s
> 
> and I don't believe it was RFI because I was ONLY
> receiving at the time!
> 
> --73, Glenn, AF8C
> 
> On 1/26/2024 11:28 AM, Uwe, DG2YCB via wsjt-devel
> wrote:
> > Hi Fred and all,
> >
> > It's really strange. Seems to be working well here.
Look
> at the Rx
> > Frequency windows of the three instances. (all
> connected via virtual
> > audio, so nothing went over HF). To the left the Fox
> station, and to
> > the right the two hounds. I tried to reproduce your
> QSO situation when
> > the Fox was also in QSO with JH1BAM. Do you see any
> message not being
> > displayed there?
> >
> >
> > 73 de DG2YCB,
> > Uwe
> > 
> > German Amateur Radio Station DG2YCB
> > Dr. Uwe Risse
> > eMail: dg2...@gmx.de
> > Info: www.qrz.com/db/DG2YCB
> >
> >
> >
> >
> >
> __
> _
> > 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
>
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] Making F/H idiot proof

[Reino Talarmo via wsjt-devel]

Hi, I think that the Fox simply ignores the “R+rpt” part of the message and 
takes it to be a Tx1 message. So Fox sends a report. The Hound station autoseq 
may not work correctly as it has not sent the Tx1 at all. A resending of the 
“R+rpt” should be a correct message. The Hound station sends only Tx1 and Tx3 
in the protocol. Fox should not response by RR73, if it has not sent a Tx2 and 
received after that a R+rpt. No short-cuts allowed.

Well, it is another issue how to get operators to read user guides!

 

73, Reino OH3mA

 

From: Andy Durbin via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Wednesday, January 24, 2024 5:48 PM
To: Brian Moran ; WSJT software development 

Cc: Andy Durbin 
Subject: Re: [wsjt-devel] Making F/H idiot proof

 

Hi Brian,

 

The screen shot and the discussion are in the Clipperton groups.io messages.  
Clipperton is certainly using WSJT-X and operating as Fox.  It appears the 
"user" saw a TX5S CQ and replied with TX3.  TX5S responded with TX2.  

 

ref - https://groups.io/g/Clipperton-2024/message/388

 

You may need to sign up for the group to read messages.  Private email if you 
like me to send a copy of the screen shot.  I don't think this "list" will 
allow images.

 

73,

Andy, k3wyc

  _  

From: Brian Moran mailto:brian.mo...@gmail.com> >
Sent: Wednesday, January 24, 2024 8:36 AM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Andy Durbin mailto:a.dur...@msn.com> >
Subject: Re: [wsjt-devel] Making F/H idiot proof 

 

Hi Andy; can you please help me understand the circumstances better?  

Under “normal” f/h operation, the hound calls with a grid. WSJT-X in fox mode 
can queue a caller with a grid. WSJT-X in fox mode doesn’t queue 
non-grid-supplying callers. 

 

If the “fox” replied to a signal report message as the first call, perhaps the 
fox wasn’t using f/h mode? Perhaps not using wsjt-x?

 

The calling operator could have used the manual message selection buttons to 
change their message to the “fox” reflecting the circumstances, and they could 
have manually logged the station at the appropriate point in the sequence. It 
seems they might have partially done that, since if I understand what you are 
writing, they found and started with the TX3 message. 

 

If you could point me to more information and the screenshot, I’d like to 
follow up to understand this situation better. 

 

Thanks,

-Brian N9ADG

 

Sent via iPhone





On Jan 24, 2024, at 7:16 AM, Andy Durbin via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

 

As implemented in WSJT-X ver 2.6.1 the hound is able to select TX3 as their 
first transmission.  One user has posted a screen shot showing that fox replied 
with a signal report but the QSO could not be completed.

 

Since new WSJT-X ops seem reluctant to read the instructions would the 
developers please consider making TX3 unselectable until a signal report has 
been received.

 

Thanks and 73,

Andy, k3wyc

___
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] Show States for Grids in the Band Activity window

[Reino Talarmo via wsjt-devel]

Hi Ed,

As Fred told that nice feature is built into WSJT-X_improved.  Well, sometimes 
there is a list of possible states, when a grid covers more than a single state.

 

73, Reino OH3mA

 

From: Ed Stokes via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Thursday, January 4, 2024 6:00 PM
To: WSJT software development 
Cc: Ed Stokes 
Subject: Re: [wsjt-devel] Show States for Grids in the Band Activity window

 

Hello Reino, 

 

Thanks.  

 

I’m certain it came from within WSJT-X.  I don’t use any auxiliary apps that 
could do this.

 

73, Ed





On Jan 4, 2024, at 10:14 AM, Reino Talarmo via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

 

Hi Ed,

That message was appended to the display by some companion program as it is 
impossible to convey the additional information using the FT8 CQ message and 
the grid alone tells the state only by change.

 

73, Reino OH3mA

 

From: Ed Stokes via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Thursday, January 4, 2024 2:55 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Ed Stokes mailto:w1...@comcast.net> >
Subject: [wsjt-devel] Show States for Grids in the Band Activity window

 

An earlier version (2.5 or 2.6?) had an option to show states within a grid in 
the Band Activity window .

 

For example:  

125245 Tx 648 ~ CQ W1KOK FN33 VT NY

 

Has this feature been eliminated?

 

If not, how do I find and activate it?

 

Thank you, 

 

Ed 

W1KOK 

 

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto: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] Show States for Grids in the Band Activity window

[Reino Talarmo via wsjt-devel]

Hi Ed,

That message was appended to the display by some
companion program as it is impossible to convey the
additional information using the FT8 CQ message and the
grid alone tells the state only by change.

 

73, Reino OH3mA

 

From: Ed Stokes via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Thursday, January 4, 2024 2:55 PM
To: WSJT software development

Cc: Ed Stokes 
Subject: [wsjt-devel] Show States for Grids in the Band
Activity window

 

An earlier version (2.5 or 2.6?) had an option to show
states within a grid in the Band Activity window .

 

For example:  

125245 Tx 648 ~ CQ W1KOK FN33 VT NY

 

Has this feature been eliminated?

 

If not, how do I find and activate it?

 

Thank you, 

 

Ed 

W1KOK 

 

 

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

Re: [wsjt-devel] WSJT noise estimates

[Reino Talarmo via wsjt-devel]

Hi Andy,

Interesting approach. But how you know that it really enhanced the signal 
detection?
The wanted signal is now close the wanted signal and that may disturb the S/N 
calculation and you will see a better S/N values with your method without a 
real better sensitivity. Possibly the only real comparison could be with two 
radios fed from the same antenna with a power divider (you may need a an 
amplifier before the power divider for compensating attenuation) and two 
instances of wsjt-x. Then a statistical study of success/failure rates could 
tell a real story.

 

Just my two pennies.

 

73, Reino OH3mA

 

From: Andrew Neumeier via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, December 10, 2023 3:40 PM
To: w0fy--- via wsjt-devel 
Cc: Andrew Neumeier 
Subject: Re: [wsjt-devel] WSJT noise estimates

 

Joe,

 

Just a comment here.  I use FT8 frequently and almost always on 2 meters.  My 
interest is in weak signals.  I use a Omni VII here, with a transverter.  I 
have had some luck using my notch filter on very weak FT8

signals.  Setting the notch width at about 75hz, I have been using the edge of 
the filter to enhance the signals I am looking for.  So, the notch is not 
directly on the desired signal, but set a few hundred hertz from it, usually

below it.  Of course, placing the notch directly on the signal would erase it, 
but I don't use it that way.  I have worked a number of stations this way.  It 
took some playing around to get this to work, and it does not always

work, and one must see the signal first and have a decode failure, before 
turning to this remedy.  

 

Just my two cents.

 

Best of luck,

73,

Andy, ka2uqw

 

 

 

On Saturday, December 9, 2023 at 10:05:26 PM EST, w0fy--- via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Been wondering how WSJT-X generates the noise power estimate it uses to 
calculate SNR for each FT8 signal.  Does it simply collect all the signals and 
noise over the bandwidth selected on the waterfall and call that the noise 
power level or does it take a quick snapshot of  the background noise level 
during the brief quiet period at the end of each 15 second FT8 sequence? Or is 
it more complicated than that?

 

I am plagued with a S2 -S3 noise level on 6 meters nearly all the time that if 
not AWGN is pretty close to it.  10 meters is even worse. The DSP noise blanker 
in my TS590 will reduce it slightly. I estimate this is degrading my ability to 
decode FT8 signals on 6 by nearly 20 dB compared to the noise level generated 
by a 50 ohm resistor.  I don’t use an LNA ahead of the radio – would be 
pointless.  I don’t use the noise reduction feature in the radio either as it 
tends to lose very weak signals completely. 

 

Wondering if I can use the DSP in my TS590 to narrow the receiver bandwidth to 
perhaps 300 -500 Hz around a known offset to help pick weak signals out of the 
noise? I realize that the WSJT program filters the audio into much narrower BW 
bins so all the receiver filtering can do is reduce the receiver gain reduction 
caused by the noise pumping up the AGC but that might be beneficial.  Likewise, 
would using the DSP notch to suppress a single strong local signal or birdie 
help since strong signals also reduce receiver gain?  Should I deselect the 
flatness option if I use these tools? Would narrowing the waterfall span help 
any since the program ignores anything outside that span? Would appreciate any 
insight you can share.

 

Joe W0FY

 

 

___
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 noise estimates

[Reino Talarmo via wsjt-devel]

Hi Joe, 
Some quick comments in-line.

73, Reino OH3mA

> Sent: Sunday, December 10, 2023 4:56 AM
> Subject: [wsjt-devel] WSJT noise estimates

> Been wondering how WSJT-X generates the noise power
estimate it uses to calculate SNR for each FT8 signal. 
Does it simply collect all the signals and noise over
the bandwidth selected on the waterfall and call that
the noise power level or does it take a quick snapshot
of  the background noise level during the brief quiet
period at the end of each 15 second FT8 sequence? Or is
it more complicated than that?
3mA: The S/N calculation process is pretty complicated.
It estimates noise over the whole receiver bandwidth and
uses 2500 Hz as the reference bandwidth. Some other
implementations try to calculate S/N over the individual
signal bandwidth, 50Hz, and the values are not directly
comparable.

> I am plagued with a S2 -S3 noise level on 6 meters
nearly all the time that if not AWGN is pretty close to
it.  10 meters is even worse. The DSP noise blanker in
my TS590 will reduce it slightly. I estimate this is
degrading my ability to decode FT8 signals on 6 by
nearly 20 dB compared to the noise level generated by a
50 ohm resistor.  I don’t use an LNA ahead of the radio
– would be pointless.  I don’t use the noise reduction
feature in the radio either as it tends to lose very
weak signals completely. 
3mA: Noise blanker may help only, if the noise have high
and short peaks and the noise is cancelled e.g. limited
at a wide bandwidth point of the receiver chain. On AWGN
it does not help. Then the resulting distortion noise is
distributed over a wide frequency range. Your assumption
about the degradation may be a bit pessimistic,
depending on the noise type, S2 - S3 is quite low
compared what is typical on lower HF.

> Wondering if I can use the DSP in my TS590 to narrow
the receiver bandwidth to perhaps 300 -500 Hz around a
known offset to help pick weak signals out of the noise?
I realize that the WSJT program filters the audio into
much narrower BW bins so all the receiver filtering can
do is reduce the receiver gain reduction caused by the
noise pumping up the AGC but that might be beneficial.  
3mA: The additional receiver bandwidth reduction
improves the calculated S/N values as there is less
noise. But the decoding sensitivity does not usually
improve as long as the linearity of the receiver chain
is kept. There is some S/N calculation oddities at the
edges of a narrow bandwidth. I don't know the actual
reason, but I have recorded up to 40 dB additional
variations of S/N values in a comparison of the same
messages between narrow and wide bandwidths. 

> Likewise, would using the DSP notch to suppress a
single strong local signal or birdie help since strong
signals also reduce receiver gain?  
3mA: That seems to help. Especially, when the disturbing
signal is not very close to the wanted signal. 

> Should I deselect the flatness option if I use these
tools? 
3mA: To my knowledge the flatness option is only for
waterfall display, not for the decoding process.
 
Would narrowing the waterfall span help any since the
program ignores anything outside that span? 
3mA: That is about equivalent as usage of a narrow
filter. If signals outside of the waterfall are not
causing distortion noise (overdriving receiver), then
there will be an apparent S/N improvement, but not a
real decoding improvement. There is another possible
decoding improvement as there are less signal candidates
to process, Decoding is only attempted on frequencies
inside the waterfall. Well at least in principle, I have
seem rear instances, where also signal outside the
waterfall has been decoded.

> Would appreciate any insight you can share.

Joe W0FY

PS. 3mA i.e. is 3 milliamps, my local nickname.



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

Re: [wsjt-devel] 160m S/N needs advanced mode

[Reino Talarmo via wsjt-devel]

Hello Glenn,
I think that you wish is already heard and fulfilled.
The suitable mode is FST4. There are seven modes with
transmission periods from 15 to 1800 seconds. The
performance of the FST4-120 is about the same as for
WSPR. For longer transmission periods transmitter
frequency stability requirement is higher as the used
bandwidth goes down. See user guide 17.2.10. Summary. Of
course the (un)stability of the propagation path on 160m
band may prevent usage of the slowest modes.

73, Reino OH3mA

> -Original Message-
> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Thursday, December 7, 2023 5:46 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Glenn Williams 
> Subject: [wsjt-devel] 160m S/N needs advanced mode
> 
> Hello,
> 
> FT8 on 160m pales.
> 
> WSJT-X operators customarily running FT8 and FT4 on
> 80m through 10m HF bands are likely disappointed with
> trials on 160m. As one of those operators I recently
ran
> WSPR on 160m in comparison to working FT8 QSOs on
> 160m. In NA EST daytime operation at 2220Z WSPR
> faultlessly listed a
> -28 dBm decode.
> 
> Here I suggest we need an improved decode sensitivity
> for 160m QSOs, likely needing to be done with a new
> mode. Granted, the TX and RX times would have to be
> increased (Shannon-Hartley Theorem). That would
> require additional operator patience and associated
> protocols for the extended timing.
> 
> --73, Glenn, AF8C
> 
> --
> This email has been checked for viruses by Avast
> antivirus software.
> www.avast.com
> 
> 
> ___
> 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 parsing of the country file, specifically 4U1A (and others)

[Reino Talarmo via wsjt-devel]

> From: Jim Reisert AD1C via wsjt-devel 
> [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: Thursday, December 7, 2023 3:51 AM

> 3. 4U is listed as a prefix for Italy.
Regarding #3, this was done so that "new" (previously unknown) 4U callsigns 
that are spotted on the DX cluster will propagate through the network.  If that 
prefix mapping were not there, those calls would be ignored because they could 
not be associated with any entity in the country file.  Tis was done at the 
request of Lee VE7CC.  4U has been used numerous times from Italy.  4U24OCT is 
a recent example.  The QTH is the Global Service Centre ARC in Brindisi, Italy, 
normally 4U1GSC.  4U could have just as easily been listed as a prefix for 
Austria, but I chose Italy based on past experience.

Thanks Jim for clarification,
Just for educating myself may I ask, is the United Nations 4U the only "country 
code" that is allowed to pop up in any country without a country prefix xxx/? 
Second question is how long "visiting" individual callsigns are kept in the 
cty.dat file? Related question is why e.g. 4U24OCT and 4U1GSC are not listed 
under Italy? Perhaps those will be listed, if the 4U movement to Austria is 
implemented.
Could it be sensible that 4U will be listed as a separate "country" in addition 
to the United Nations HQ with a line ending e.g. "Location currently unknown:"? 
Of course the new call sign will be listed in the proper entity as soon as it 
is known. 

73, Reino OH3mA



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

Re: [wsjt-devel] WSPR and Diversity Receive

[Reino Talarmo via wsjt-devel]

Hi Ben,

You mentioned that you have two antennas. What kind antennas you have? Do they 
have any radiation patterns different from each other? What’s distance between 
the antennas?
In any case you can affect to the noise level by combining two antennas that 
are at different locations. That beam forming generates nulls to the radiation 
pattern and those may attenuate less wanted signals at least in most 
directions. Result is improved S/N and so detection probability is higher. 
Another is issue is that there is less correlation of noise than signals in 
antennas in different locations or using different polarizations. In the best 
case the noise powers are added, but signal amplitudes are added and S/N 
improvement is 3 dB in ideal case. Well, signals from different directions may 
behave differently.
As Chris noted one of the local noise sources may be even “nulled out”, 
sometimes with a considerable improvement in S/N.

 

73, Reino OH3mA

 

From: Christopher Wawak via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, December 5, 2023 1:15 PM
To: WSJT software development 
Cc: Christopher Wawak 
Subject: Re: [wsjt-devel] WSPR and Diversity Receive

 

On Tue, Dec 5, 2023 at 3:35 AM Ben Gelb via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

Have I actually improved the SNR
substantially? Or is it possible I am just affecting the SNR
calculation (I think it is roughly measuring the average noise level
in the 2.5kHz window, and comparing to peaks) in a way that doesn't
necessarily imply increased probability of decode?

 

Hi Ben! I live in a suburban area with lots of RFI, and use a multiple receive 
antenna phasing system which effectively eliminates much of the local noise my 
antennas pick up. In my experience, only local signals are affected and 
anything further than the antennas' near field seems to remain the same. Based 
on this experience, is it possible that you're affecting near field noise which 
might increase or decrease the snr depending on whether the noise is being 
cancelled? I am not an expert, just trying to do some radio in a noisy 
environment! Hihi.

 

KC2IEB Chris

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

Re: [wsjt-devel] IC-705 little to no decodes

[Reino Talarmo via wsjt-devel]

Could there be some audio enhancements that should be switched off, either 
windows or in rig such as noise blanker or some automatic interference 
reduction? 
Does your computer have two time services activated, perhaps not in the both 
computers?

On those few decodes, what are the dT values? About the same or wildly all over?

 

73, Reino OH3mA

 

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

Re: [wsjt-devel] Source code location for hashcodes.f90?

[Reino Talarmo via wsjt-devel]

Hi David,

Was it at www.arrl.org/qexfiles year 2020

July/August, The FT4 and FT8 Communication Protocols

http://www.arrl.org/files/file/QEX%20Binaries/2020/ft4_f
t8_protocols.tgz

 

73, Reino OH3mA

PS. I like to see that Python utility.

Reino

 

From: David - K2DBK via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Monday, December 4, 2023 12:03 AM
To: wsjt-devel@lists.sourceforge.net
Cc: David - K2DBK 
Subject: [wsjt-devel] Source code location for
hashcodes.f90?

 

Primarily as an exercise for myself, I converted the
hashcodes.f90 utility to python. I'll (eventually)
publish to github and I'd like to provide a link to the
original source, but I can no longer find where I
downloaded it from. Can someone please give me a link to
that?

 

Thanks.

 

73,

 

David, K2DBK

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

Re: [wsjt-devel] Astronomical window not working

[Reino Talarmo via wsjt-devel]

In that situation it normally hides behind the main window. Try to move the 
main one.

 

73, Reino OH3mA

 

From: G Richard Kreuter via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Monday, November 27, 2023 12:01 AM
To: wsjt-devel@lists.sourceforge.net
Cc: G Richard Kreuter 
Subject: [wsjt-devel] Astronomical window not working

 

I’m using WSJT-X 2.7.0-rc2 for 432MHz EME and when I check the astronomical box 
in “view” nothing happens.  I’m running WSJT-X on my windows computer. I did 
try echo test to see if it would show up but no it didn’t. I have restarted my 
computer and reloaded want-x but that didn’t work either. 

G Richard Kreuter

WC8RK

 

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

Re: [wsjt-devel] CQ Hound mode

[Reino Talarmo via wsjt-devel]

Sure, of course nothing what so ever! Mshv should in that case *not* to use it 
on the standard frequencies and when they are just using multifrequency, but 
not F/H protocol. Otherwise we gain nothing at all, hi!
I just wanted to point that it requires everybody to update their wsjt-x 
version. 
In addition should that specific CQ type extended to cover other situations 
where the operator wants to tell what kind of station he is using? Or is it 
just because mshv and perhaps other derivate programs don’t follow the 
intention of the original F/H protocol? Possible additional cases could be QRP, 
POTA, VOTA, etc. a continuously expanding situations where the operator want to 
differentiate from the normal users. As already proposed the directed call 
gives a possibility for the indication, such as CQ FOX …
Should then the program have an automatic jump into Hound mode, when user 
double clicks on that message?

 

73, Reino OH3mA

 

From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, November 5, 2023 11:53 PM
To: Reino Talarmo via wsjt-devel 
Cc: Sam W2JDB 
Subject: Re: [wsjt-devel] CQ Hound mode

 

and what's to stop mshv from adapting the same call method?

 

73

 

Sam W2JDB

 

 

 

On Sunday, November 5, 2023 at 04:27:38 PM EST, Reino Talarmo via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Just a minor point, I assume. If that is programmed into wsjt-x, then the 
change will not be backwards compatible. The CQ part of the message is actually 
a specific pretty long bit string (28 bits, ‘c28’). There could be another bit 
string for the CQF, but none of the current versions would present it as the 
CQF and the protocol machine would not work. If you feel a need to study it 
further, see https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf.

 

73, Reino OH3mA

 

From: Scott Armstrong via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, November 5, 2023 10:53 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Scott Armstrong mailto:aa5am.sc...@gmail.com> >
Subject: Re: [wsjt-devel] CQ Hound mode

 

I believe he meant Fox.

CQF  

I like that idea. It would differentiate between F/H and MSHV.  But this all 
assumes the DX stops and calls CQ ever once in a while.

 

-Scott AA5AM

 

On Sun, Nov 5, 2023 at 2:38 PM Gary McDuffie via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:



> On Nov 5, 2023, at 13:08, Pino Zollo via wsjt-devel 
> mailto:wsjt-devel@lists.sourceforge.net> > 
> wrote:
> 
> Just an idea:
> 
> When in Hound mode the DX station should call  as:
> 
> CQH DX0CALL GRID
> 
> or
> 
> CH  DX0CALL GRID

But why?  He should only be hound if he is on his published frequency (which 
you can determine yourself), and he should never be in hound mode if he is in 
the normal FT frequency segment.  

Gary - AG0N

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

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto: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] CQ Hound mode

[Reino Talarmo via wsjt-devel]

Just a minor point, I assume. If that is programmed into wsjt-x, then the 
change will not be backwards compatible. The CQ part of the message is actually 
a specific pretty long bit string (28 bits, ‘c28’). There could be another bit 
string for the CQF, but none of the current versions would present it as the 
CQF and the protocol machine would not work. If you feel a need to study it 
further, see https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf.

 

73, Reino OH3mA

 

From: Scott Armstrong via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, November 5, 2023 10:53 PM
To: WSJT software development 
Cc: Scott Armstrong 
Subject: Re: [wsjt-devel] CQ Hound mode

 

I believe he meant Fox.

CQF  

I like that idea. It would differentiate between F/H and MSHV.  But this all 
assumes the DX stops and calls CQ ever once in a while.

 

-Scott AA5AM

 

On Sun, Nov 5, 2023 at 2:38 PM Gary McDuffie via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:



> On Nov 5, 2023, at 13:08, Pino Zollo via wsjt-devel 
> mailto:wsjt-devel@lists.sourceforge.net> > 
> wrote:
> 
> Just an idea:
> 
> When in Hound mode the DX station should call  as:
> 
> CQH DX0CALL GRID
> 
> or
> 
> CH  DX0CALL GRID

But why?  He should only be hound if he is on his published frequency (which 
you can determine yourself), and he should never be in hound mode if he is in 
the normal FT frequency segment.  

Gary - AG0N

___
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.7.0 rc2 flagged as malware

[Reino Talarmo via wsjt-devel]

It is only a false positive malware indication.  

73, Reino OH3mA


> -Original Message-
> From: F4FPR Benjamin via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: Friday, October 27, 2023 11:36 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: F4FPR Benjamin 
> Subject: [wsjt-devel] WSJT-X 2.7.0 rc2 flagged as
> malware
> 
> Dear wsjt-x devel list,
> I’ve just tried to download the last update of WSJT-X
> version and it looks like that the last version is flagged as
> the malware onto Sourceforge as such as into
> VirusTotal, what is going on ?
> Best regards & 73
> Benjamin L / F4FPR / K5AW
> __
> _
> 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] No 73 allowed after RR73?

[Reino Talarmo via wsjt-devel]

Keijo, which bands you have used? Perhaps HF and 6 m during Es propagation?

 

73, Reino OH3mA

 

From: OG55W via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, October 22, 2023 10:08 AM
To: WSJT software development 
Cc: OG55W 
Subject: Re: [wsjt-devel] No 73 allowed after RR73?

 

Last two months I have had about 5000 FT8/FT4 QSOs. I have received just one 
RRR, all the others were RR73. So RRR is not in use very much…

73 Keijo OG5O

 

Lähetetty Windowsin Sähköposti <https://go.microsoft.com/fwlink/?LinkId=550986> 
ista

 

Lähettäjä: Reino Talarmo via wsjt-devel 
<mailto:wsjt-devel@lists.sourceforge.net> 
Lähetetty: sunnuntai 22. lokakuuta 2023 8.49
Vastaanottaja: 'WSJT software development' 
<mailto:wsjt-devel@lists.sourceforge.net> 
Kopio: Reino Talarmo <mailto:reino.tala...@kolumbus.fi> 
Aihe: Re: [wsjt-devel] No 73 allowed after RR73?

 

Hi Andy and all,

The protocol is flexible on that issue. The original weak signal QSO do contain 
a “RRR” that is “confirmed” by a “73” to keep both sizes of the QSO happy. 
The “RR73” is really intended for “strong signal” QSO’s and then the “73” is 
not needed to keep the QSO time short.

 

73, Reino OH3mA

 

From: Andrew Neumeier via wsjt-devel [mailto:wsjt-devel@lists.sourcefo 
<mailto:wsjt-devel@lists.sourceforge.net> rge.net] 
Sent: Sunday, October 22, 2023 1:05 AM
To: Neil Zampella via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Andrew Neumeier mailto:ka2...@yahoo.com> >
Subject: Re: [wsjt-devel] No 73 allowed after RR73?

 

In some cases the use of RR73 is problematic.  I operate FT8 almost exclusively 
on 2 meters, weak signal.  If I am working a very weak station, and that 
station chooses to use RR73 instead of 73, there

is a good chance that I have not received it, especially if I am waiting for a 
qsb peak on the signal.  By sending RR73 that station assumes we are done once 
RR73 is sent, but we may not be done.  I continue

sending a signal report, while the station I was in contact with is off working 
another station.  I may then fail to log that qso, since it is incomplete, 
unless the station realizes the mistake and continues the qso.   

 

On occasion I have even seen RR73 used in MSK144 or even Q65 which is just out 
of line in weak signal, or meteor scatter work.  

 

When working weak signals I don't think RR73 should ever be used and I never 
use it myself.  

 

73,

Andy, ka2uqw

 

 

 

On Saturday, October 21, 2023 at 04:53:15 PM EDT, Neil Zampella via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

FWIW ... if you received an RR73 .. there is no need to reply.   

The station is saying that RR I got your last, and 'over and out' ...  

The other party is not waiting for your reply, they're on to another contact.

Neil, KN3ILZ

On 10/21/2023 1:14 PM, Andy Durbin wrote:

WSJT-X ver 2.6.1, Win 8.1.

 

I have observed several times that I could not complete a QSO by sending 73 
after I had received an RR73.  This is expected operation with F/H active but 
not when F/H is not active.  I suspect that something is latched in software if 
F/H mode has been used but is then exited and WSJT-X is not re-started.

 

Has anyone else seen this or have an explanation?

 

73,

Andy, k3wyc

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto: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] No 73 allowed after RR73?

[Reino Talarmo via wsjt-devel]

Hi Andy and all,

The protocol is flexible on that issue. The original weak signal QSO do contain 
a “RRR” that is “confirmed” by a “73” to keep both sizes of the QSO happy. 
The “RR73” is really intended for “strong signal” QSO’s and then the “73” is 
not needed to keep the QSO time short.

 

73, Reino OH3mA

 

From: Andrew Neumeier via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, October 22, 2023 1:05 AM
To: Neil Zampella via wsjt-devel 
Cc: Andrew Neumeier 
Subject: Re: [wsjt-devel] No 73 allowed after RR73?

 

In some cases the use of RR73 is problematic.  I operate FT8 almost exclusively 
on 2 meters, weak signal.  If I am working a very weak station, and that 
station chooses to use RR73 instead of 73, there

is a good chance that I have not received it, especially if I am waiting for a 
qsb peak on the signal.  By sending RR73 that station assumes we are done once 
RR73 is sent, but we may not be done.  I continue

sending a signal report, while the station I was in contact with is off working 
another station.  I may then fail to log that qso, since it is incomplete, 
unless the station realizes the mistake and continues the qso.   

 

On occasion I have even seen RR73 used in MSK144 or even Q65 which is just out 
of line in weak signal, or meteor scatter work.  

 

When working weak signals I don't think RR73 should ever be used and I never 
use it myself.  

 

73,

Andy, ka2uqw

 

 

 

On Saturday, October 21, 2023 at 04:53:15 PM EDT, Neil Zampella via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

FWIW ... if you received an RR73 .. there is no need to reply.   

The station is saying that RR I got your last, and 'over and out' ...  

The other party is not waiting for your reply, they're on to another contact.

Neil, KN3ILZ



On 10/21/2023 1:14 PM, Andy Durbin wrote:

WSJT-X ver 2.6.1, Win 8.1.

 

I have observed several times that I could not complete a QSO by sending 73 
after I had received an RR73.  This is expected operation with F/H active but 
not when F/H is not active.  I suspect that something is latched in software if 
F/H mode has been used but is then exited and WSJT-X is not re-started.

 

Has anyone else seen this or have an explanation?

 

73,

Andy, k3wyc

___
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] Solar Eclipse participation #general

[Reino Talarmo via wsjt-devel]

Yes, e.g. Radio observations of the 2015 solar eclipse
(pa3fwm.nl)
 

 

73, Reino OH3mA

 

From: Marco Calistri via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Friday, September 15, 2023 8:21 PM
To: Black Michael ; WSJT software
development ;
wsjtgr...@groups.io; Wsjt Improved

Cc: Marco Calistri 
Subject: Re: [wsjt-devel] Solar Eclipse participation
#general

 

Hi Mike,

 

Are there studies confirming that a solar eclipse can
affect HF propagation?

 

FWIK, but I'm not an expert on the matter, the most
affected frequencies are the ones falling into the SHF
and microwave bands, in particular the satellite bands,
which are being affected by solar flares too.

 

My PSKREPORTER in WSJTX is enabled since the very
beginning I started to use FT8.

 

Best regards,

 

PY1ZRJ 

 

Inviato da Outlook per Android  

  _  

From: Black Michael via wsjt-devel
mailto:wsjt-devel@lists.sourceforge.net> >
Sent: Friday, September 15, 2023 2:04:19 PM
To: wsjtgr...@groups.io 
mailto:wsjtgr...@groups.io> >;
WSJT Software Development
mailto:wsjt-devel@lists.sourceforge.net> >; Wsjt
Improved
mailto:wsjt-x-improved-commun...@lists.sourceforge.net>
>
Cc: Black Michael mailto:mdblac...@yahoo.com> >
Subject: [wsjt-devel] Solar Eclipse participation
#general 

 

If you have a recent version of WSJTX (like RC2) we
would appreciate you turning on PSKReporter to support
the upcoming solar eclipse Oct 14th.  If you can turn on
PSKReporter now and keep it on until at least Oct  16th
it would be appreciated.

 

We implemented special PSKReporter ability in WSJT-X
during solar eclipses.  All spots will go through where
normally duplicates are  ignored.  Phillip Gladstone at
PSKReporter has implemented special collection recording
to support this.

 

This is  to support the HamSCI community solar eclipse
analysis.

 

Mike W9MDB

 

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

Re: [wsjt-devel] Split

[Reino Talarmo via wsjt-devel]

Hi Jim and all,

I support this proposal. I know that on the rig's point of view the
functionality is the same as in the classical "split". What is seen on the
band may or may not be the same depending how the user selects the
transmission frequency.

In addition some words could be added to note that the activation of the
'Hold Tx Freq' and selecting a 'free' spot on the waterfall is the same
working principle as the classical "split". In FT8 case the transmission
frequency (red mark) is selected outside (not only upper side) the reception
frequency (green mark). The waterfall is a bandscope and decoder is a
build-in FT8 skimmer.

73, Reino OH3mA

> -Original Message-
> From: Jim Brown via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: tiistai 5. syyskuuta 2023 3.57
> To: WSJT software development 
> Cc: Jim Brown 
> Subject: [wsjt-devel] Split
> 
> Team,
> 
> I've several times observed in the more public forum that "split" was a
VERY bad
> word choice to describe the TX shift devised to prevent transmission of
audio
> harmonic distortion. The practice is great, the word choice is terrible,
because it
> is in conflict with what has been standard use of the word "split" in ham
radio
> for almost as long as I've been a ham (and I was licensed in 1955).
> 
> "Split" describes the practice whereby a DXpedition transmits on one
frequency
> and listens for callers in a range of frequencies (usually above his TX
frequency),
> typically 10 kHz wide for CW, 25-35 kHz on SSB), and for at least 50
years, rigs
> have a button labeled "split."
> This is NOT what you've written the code to do! It confused the user who
asked
> me for help, and it likely has confused others. It confused me when I
first read it,
> and I understood what you were doing and why.
> 
> I strongly urge two changes be implemented. First, on the Settings page
where
> "Split" is used, add in parentheses, "TX Shift." Second, modify the WSJT-X
> documentation in the same way, and add at least a paragraph to explain
that it
> isn't really "split" in the sense of the practice that has been used for
more than
> 60 years.
> 
> 73, Jim K9YC
> 
> =   =   =   =   =   =
> 
> All is well here now:)  You're the Man!
> tnx agn
> Jim/k2hn
> 
> On Monday, September 4, 2023 at 04:23:25 AM EDT, Jim Brown
>  wrote:
> 
> 
> On 9/3/2023 11:03 PM, Jim Murray wrote:
>  > Hi Jim,
>  > I wonder if I could impose on you with just one thing that's giving me
>  > fits on the K3s.  Decided to set it up for ft8.  Used k4tax's
>  > settings:Mic sel - Line in, Data MD- Data A.  These settings using only
>  > usb cable. I also used his wsjt settings.
> 
> I have the several of the original K3, no K3S, so don't know setup with
> USB.
> 
> 
>  > All was going well until I
>  > messed with some vfo settings I think.  With the original settings
>  > somehow vfo A and B and split get involved.  After I messed around
>  > seeing if all could be done with just vfo A I messed things up.
> 
> OK. The confusion is WSJT-X's improper use of the word "split." It's NOT
> "split" as we hams have used the word for at least 60 years, but the
> guys who wrote WSJT-X probably wouldn't know anything about CW or SSB if
> it bit them in the ass.
> 
> The proper words for what they're doing is TX Shift." What they are
> doing is shifting the TX audio frequency in one direction and TX RF dial
> frequency in the other, so that the second harmonic of the TX tone is
> always outside the TX SSB filter.
> 
> You should NOT set the radio for split. Simply set "split" on the Radio
> tab in WSJT-X for "Fake it." When you go into transmit, you WILL see the
> VFO shift up on TX if your AF tone is below 1500 Hz, then shift back to
> the right dial frequency on RX. If your AF tone is 1500 Hz or higher, no
> shift occurs.
> 
> 
>  > Now, tx
>  > jumps to B and is .50 off.  21.074.00 jumps to 21.074.50 on transmit
and
>  > shows the same on wsjt.  .50 off.  Well, I've spent hours trying to get
>  > rid of the .50.  Probably touched things I shouldn't have.  I can't
find
>  > anywhere where .50 shows up. I tried changing filter settings etc.
>  > nothing.  Hate to be a PIA but will no longer do so.  I've learned that
>  > the k3s does not like messing with settings unless you know what your
>  > doing:)  Not that all user friendly as some I've had.  But- Rx is
>  > amazing.  Last night I heard 3 China stations and connected with one
>  > with 45W into an  endfed, 15M ft8.  My last ftdx10 never heard China no
>  > less connected with one.
> 
> 
> Best K3 settings are for IF bandwidth of 3 kHz, set the waterfall to
> start at 200 Hz, set the Bins/pixel to 4. Set FAST AGC, set audio drive
> from K3 to computer for decoding so that, WITH SIGNALS, the green bar is
> as close to 80 as possible without ever turning red. This gives maximum
> dynamic range. You can ride gain on the green bar with the RF gain
> control.
> 
> 73, Jim K9YC
> 
> 
> ___
> 

Re: [wsjt-devel] Problem with Hamlib

[Reino Talarmo via wsjt-devel]

Hi Uwe,
I have used the same serial port for CAT (no PTT) and DTR or RTS for PTT with 
my FT1000MP, but of course you can’t have at the same time a hardware flow 
control.

73 Reino OH3mA  

 

I use CAT. If you have DTR or RTS selected, make sure the COM port for that is 
different from the CAT serial port. 

 

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

Re: [wsjt-devel] #Echo Echo shifts TX frequency when clicking "Set RX & TX offset" - should be disabled

[Reino Talarmo via wsjt-devel]

Hi Andreas,

It would be nice for you, if the echo mode had a ‘fail safe’ setting that 
forces the transmission to 1500 Hz. The source code is available and you may 
add that into the program. Otherwise the instructions are clear how to use the 
echo mode.

73, Reino OH3mA 

 

From: Andreas Junge via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: torstai 3. elokuuta 2023 22.16
To: WSJT software development 
Cc: Andreas Junge 
Subject: Re: [wsjt-devel] #Echo Echo shifts TX frequency when clicking "Set RX 
& TX offset" - should be disabled

 

Joe,

 

Yes, I have read it. I also read Bob's (KA1GT) article. Please have a look at 
this short recorded screen session:

 

https://icecreamapps.com/v/fkkg3dt

 

Either right-clicking into the wide graph and setting the offset - which should 
not work since it should be fixed to 1500- or by previously being in Q65 with 
an offset will cause this. 

 

It follows the pattern of @0-500 offset will subtract 1500Hz, @501-1000 will 
subtract 1000Hz, @1001-1500 will subtract 500Hz and so on until +1500Hz

 

I think this feature is used to keep the tones in the middle of the TX 
passband, but it also requires a frequency shift of the generated tone which 
does not happen because it's set to a fixed 1500Hz. 

 

In short, yes, there should not be a frequency shift on TX in the first place 
and that is a bug IMHO.

 

I enabled logging for the rig transactions and the radio is indeed commanded to 
go to the wrong offset on VFO B it should be 144065000.

 

  rig_set_split_freq called vfo=VFOB, curr_vfo=VFOA, tx_freq=144064000 

 

It works fine when I right click on 1500Hz in the wide graphs or when 1500 was 
selected in the previous mode. 

 

 

 73, Andreas, N6NU

 

On Thu, Aug 3, 2023 at 11:45 AM Joe Taylor via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

Hi Andreas,

Have you read the full-length paper about Echo mode in WSJT-X 2.6.0 and 
later? See item #34 in the list of WSJT-related references here: 
https://wsjt.sourceforge.io/refs.html .

As described there, in Echo mode the transmitted audio-frequency tone 
should always be 1500 Hz.

-- 73, Joe, K1JT

On 8/2/2023 10:47 AM, Andreas Junge via wsjt-devel wrote:
> I posted my initial question on the groups.io   list as 
> well, but Charlie, DL3WDG suggested to post it here as well.
> 
> This is reproducible. In Echo Mode right click in the Wide Graph and select 
> “Set RX & TX Offset” it seems to change the TX.
> 
> Steps:
> - In the radio settings set "Split Mode" to Radio or Fake (No difference)
> - Select "Echo Mode"
> - Select 23 cm -> 1296.065 (Default)
> - Select Doppler Tracking mode to "Own Echo"
> - Display shows 1296.065 +/- My Doppler
> - Enable TX
> - The frequency will initially show 1296.06500 and the immediately change to 
> 1296.064500
> - On RX the frequency goes back to the correct 1296.06500 +/- Doppler
> - The Echoes will be shown at the @1000 offset and not @1500, which is 
> expected, but wrong.
> 
> After a few tries I found that selecting “Set RX & TX Offset” in the Wide 
> Graph
> 
> If I click on @1000 I get 64.5000, @1500 65., @2000 65.5000
> 
> The audio should be fixed at @1500 and the Set RX & TX feature should be 
> ignored.
> 
> I think this if half of the feature that keeps the audio in the sweet spot of 
> the bandpass? However, it does not do the necessary 2nd step of shifting the 
> audio to adjust for it.
> 
> 73, Andreas, N6NU
> 
> ___
> 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

[Reino Talarmo via wsjt-devel]

Hi,
Should we have in the rc version a button for a new hamlib file download
like we have one for the cty.dat? May not be that simple to implement.
73, Reino OH3mA

> -Original Message-
> From: Black Michael via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: tiistai 11. heinäkuuta 2023 19.53
> To: wsjt-devel@lists.sourceforge.net
> Cc: Black Michael 
> Subject: Re: [wsjt-devel] High CPU load with 2.7.0-rc2
> 
> It's fixedhad a new send_morse routine (now takes up to 1023 chars to
> transmit) and missed putting a sleep in the main loop.
> With 32 cores here the 3% usage didn't really pop out at me.
> 
> New 64-bit DLL
> 
> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
> 
> New Linux shared library
> 
> https://www.dropbox.com/s/p905wjymw3t0ys0/libhamlib.so.4.0.6?dl=0
> 
> Mike W9MDB
> 
> 
> ___
> 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] list

[Reino Talarmo via wsjt-devel]

Hi Ray,
Best is to do it yourself. Go to  
https://lists.sourceforge.net/lists/listinfo/wsjt-devel (link should also be at 
the bottom of this mail)
and in 'Unsubscribe & Settings' select 'Click here to unsubscribe or change 
settings'
and follow the instructions, please.
73, Reino OH3mA

> -Original Message-
> From: Reinhard via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: sunnuntai 9. heinäkuuta 2023 10.04
> To: wsjt-devel@lists.sourceforge.net
> Cc: Reinhard 
> Subject: [wsjt-devel] list
> 
> Hello,
> 
> please remove me for a while from the mailing list
> 
> tnx
> 
> Ray   dh6...@darc.de
> 
> 
> 
> ___
> 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] I was dropped off list

[Reino Talarmo via wsjt-devel]

599 in Finland.
Did you got my private mails on the sakari.nylund(at)nic.fi?
73, Reino OH3mA

> -Original Message-
> From: Sakari Nylund via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net]
> Sent: perjantai 7. heinäkuuta 2023 6.45
> To: wsjt-devel@lists.sourceforge.net
> Cc: Sakari Nylund 
> Subject: [wsjt-devel] I was dropped off list
> 
> Oh well...
> 
> I have been dropped of from this list at 2023-06-20. I think the reason
was that I
> subscribed list years ago with mail forwarder address oh1kh AT sral.fi
> 
> I was wondering how it was so quiet here. No new mails at all.
> 
> Yet another great security filtering somewhere...
> Argh!
> 
> Let's see if this gets through.
> 
> --
> Saku
> OH1KH
> 
> 
> 
> 
> ___
> 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] New subscriber :)

[Reino Talarmo via wsjt-devel]

Hej Palle,

I identified two main issues in your mail, (1) naming of contest modes and how 
contests are supported and (2) a new way how protocol should support user 
needs. 

Contests naming and supporting protocols
(1) Perhaps it is better to start what is supported in the current autosequence 
machine and needed messages/information elements. The first set of contests are 
NA VHF Contest, ARRL International Digital Contest, Q65 Pileup and WW Digi 
Contest. The contest exchange is Locator. The message is Type 1. Std Msg. At 
VHF the use of 73 is listed, but is defined as optional. 

The second is ARRL Field Day that requires two part field day exchange 
(actually three different elements) and there are two messages Type 0.3 and 
0.4. 

The third is EU VHF Contest requires rpt, QSO number and six digit locator and 
there are two messages needed Type 2. and 5. to support it.

The fourth is FT Roundup (ex. RTTY RU) contest exchange is rpt and ARRL 
section/DX and another message Type 3.

How to identify a contest? That’s really difficult with the four first ones as 
the only possibility is the call direction field e.g. TEST, well WW Digi 
already uses WW. 

The ARRL Field Day used FD and thee contest exchange messages do separate it 
from other types.

In the EU VHF CQ and the first directed message are the same as in the first 
group, it is proposed that the contest identifier should be NAC. After that the 
proper messages require use of the special activity selection.

The FT Roundup identified in CQ by the RU must be answered with the special 
activity message. 

Of course any contest may select to use one of those four contest/field day 
exchanges. 

Now the difficult part is that many non-contesters don’t know meaning of TEST, 
WW, FD, NAC, RU or any other contest specific call direction. 

(2) Request for specific information.

You list as such may not be working as the first two do refer to EU VHF 
Contest, the FT Roundup is missing as well as those using four digit locator, 
hi! On the other hand contest rules could just name the suitable protocol from 
the current options independently of the band. 

Your actual proposal is that operator could request specific information (one 
of the message types) and the program would generate that message. That would 
require a new message as there is not enough room in current messages to 
include that information. It would need five additional bits to cover existing 
contest types. I assume that in addition the ‘Interrogation’ message should 
contain at least two callsigns. Of course CQ message should also have that 
interrogation feature. NonStandard callsigns is another issue and may be 
totally outside of this discussion.
The actual behavior of the state machines is a bit more complicated and should 
be discussed as the ‘interrogation’ information does not fit into all messages.

That’s my two Öre’s.

73, Reino OH3mA

 

From: Palle Preben-Hansen, OZ1RH via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: sunnuntai 18. kesäkuuta 2023 13.15
Cc: Palle Preben-Hansen, OZ1RH 
Subject: Re: [wsjt-devel] New subscriber :)

 

The way the different contest exchanges are implemented in WSJT is confusing 
and has been discussed many times.

 

Users has to select "EU VHF" if they are in a HF contest requiring either a 
serial number and/or the full 6-digit locator. Trying to use a particular 
contest exchange may resulting in a window at the other station "Do you want to 
change to xxx mode". As WSJT in this situation can display a window, WSJT might 
just as well just change to that mode and send the needed exchange.

 

I suggest the labeling on the Settings page regarding contest "modes" is split 
into several saying:

"I need an exchange with serial number"

"I need an exchange with your 6-digit locator"

"I need an exchange for NA fieldday"

 

When a station calls CQ with some of these options set, WSJT in FT4/8, MSK144 
or Q65 of the answering station should automatically transmit the requested 
exchange without flashing a confusing window about a particular contest mode. 

 

The logic should be that you request the exchange you need and you get it 
without intervention from the other station. This should keep all happy and one 
only transmits the exchanges needed by the other station. 

 

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

Re: [wsjt-devel] Log file for changes in settings?

[Reino Talarmo via wsjt-devel]

Glenn,
All settings are stored into wsjt-x.ini file. You may take a copy of it for
comparison before making 'radical' changes into your settings. As it is
intended to be read by the program, it is not easy to interpret by humans,
but in most cased useful.
73, Reino OH3mA

> -Original Message-
> From: Glenn Williams via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: tiistai 13. kesäkuuta 2023 2.44
> To: wsjt-devel@lists.sourceforge.net
> Cc: Glenn Williams 
> Subject: [wsjt-devel] Log file for changes in settings?
> 
> Is there any log file that records changes in settings? Such could be
useful for
> tracking down reasons for unexpected operational failures and surprises.
> 
> --73, Glenn, AF8C
> 
> 
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> 
> 
> ___
> 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] ARRL Digi contest log converting to Cabrillo

[Reino Talarmo via wsjt-devel]

  
http://www.b4h.net/cabforms/arrldigi_cab3.php may work for you. I have not 
checked whether the wsjtx.log or wsjtx_log.adi or both could be used, manual at 
least.

73, Reino OH3mA

 

From: Hannu Eloranta via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: maanantai 5. kesäkuuta 2023 9.39
To: WSJT software development 
Cc: Hannu Eloranta 
Subject: [wsjt-devel] ARRL Digi contest log converting to Cabrillo

 

So Cabrillo log creation didn't work.

How do I convert wsjtx_log.adi to Cabrillo format? (Easiest way)

 

73 OG3Z Hannu

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

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Reino Talarmo via wsjt-devel]

> From: Tom M0LTE via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: lauantai 13. toukokuuta 2023 10.58
>While manual testing could probably never be eliminated in the case of hamlib, 
>has there been any consideration of creating test harnesses to remove/reduce 
>the need for manual testing?

>It strikes me that there could be potential to capture test cases from manual 
>testing with real rigs, then at least there would be regression tests. Future 
>bug fixes could have test cases added to prevent further regression, again 
>without requiring physical radios and manual testing.

Hi Tom,

Your proposal could work in an ideal world.
There are just minor requirements before it is easily done.
#1 There should be a (well) defined and agreed CAT protocol that all rig 
manufactures follow.
#2 All rigs should have tested against that protocol.
#3 Resources to design and prepare the test program.
#4 Resources to design and prepare the Hamlib testing harness against the 
agreed CAT protocol.

On #1 we have a subset of commands that are commonly used. Even no agreed 
minimum responses to commands are agreed. There is no performance requirements 
such as timing.
The #2 is a farfetched dream.
The #3, hups, did I mentioned this?
The #4, just what!

In addition there are in some implementations bugs and the public CAT command 
set behaves differently than assumed. All those deal to a situation that the 
manual testing of most radios is the best way to perform this testing task. For 
that we need is the famous 'somebody' to keep it going and reporting to the 
Hamlib task force. 

Sorry of being to pessimistic, I have some experience on that kind of issue and 
now safely retired.

73, Reino OH3mA



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

Re: [wsjt-devel] WSJTX Cabrillo log time

[Reino Talarmo via wsjt-devel]

Hi Saku

Some comments in-line. A bit long email, sri. It's time for the new candidate 
release discussion.

73, Reino OH3mA

> From: Saku via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: perjantai 12. toukokuuta 2023 21.22

> if you calling CQ (TX1) and someone(s) answer to it qso starts from point you 
> start first TX2 transmission (to any of answering stations).
>It is very clear. There is no exchange happened yet, and your TX2 will start 
>the exchange chain (= qso).
> Same if you try to answer someones CQ. Once he sends first TX2 qso begins.

Reino: LoTW states that "both QSO descriptions specify start times within 30 
minutes of each other". So in that sense start time gets one plus point.

> In case of missed TX2 receive you will get different start time than the 
> opponent, that is true. However the base of qso starting definition is clear.

Reino: That issue is a real challenge especially on pile-up situations. You may 
need to send your Tx2 even hours e.g. as a Hound, before the Fox picks your 
call into the QSO list (= potential earliest start time on the Fox point of 
view). Even the so started QSO may fail and Fox never sends RR73 to you. Now 
would it be a new QSO start, if you send even once again Tx2? 

> End time of qso is more or less unclear. It is clear (by rules) when both 
> sides have exchanged reports and got confirmation to them.
> You get confirmation with report as "R-xx" and you confirm it by sending 
> "RRR" or "RR73".

Reino: That is recommended in the User Guide with a potential need for a 
resending RR73 or RRR due to a repeated "R-xx". To me that is a clear point of 
time as the operator feels the QSO is completed, he has sent RR73 (RRR) or 
received RR73 or 73 and no more a reception of "R-xx". User may need to correct 
the proposed end time in that case. 

> What I mean "unclear" is that someone requires 73 after RRR or RR73 to see 
> the qso complete, someone else do not.
> There has been lot of conversation about this in past and I do not want to 
> make another "split argue" with this.

Reino: Fully agree that there are at least two strong opinions on that and 
absolutely no need to restart any discussion on that issue. As an example is 
DXpedition mode, where Fox simply logs QSO at the sending the RR73. There is 
simply no action defined in that protocol for a reception of 73. For that 
reason there are dupes, but who cares. The same applies to some contests, where 
the sending of the 73 is not defined or stated optional. If there is a 
disagreement between operators, then simply there is no QSO (a NIL). That's a 
different issue, isn't it.

Reino: My comment is also "what about interleaved QSOs or QSO attempts?". Well, 
normally QSO order in a log does not matter. BUT for a program that generates 
some challenges. E.g. how may QSO attempts (sending the first Tx2) it needs to 
remember? 

> My 5 cents is that qso start time is easier to define so that all can agree 
> with definition and should be used with Cabrillo, like it is used with CW and 
> phone, too. 
However the periodical exchange and poor conditions can make big differences in 
log times. That is the thing that contest log checkers should take account when 
defining accepted time windows for qso checks with FT8 qsos. It is different 
than with CW/Phone.

Reino: Yep! The problem is the same for the start time and the end time. I 
think that the end time is in that sense a bit less uncertain and less 
variable. AND easier to implement in the program.

> And it is not getting any easier of one logging program uses "time_on" and 
> other "time_off" when producing Cabrillo log.

Reino: Perhaps both times should be presented! It may depend on the contest 
which one is actually used, but how well that is defined in the contest rules? 
Perhaps this a wrong forum for the discussion, hi!



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

Re: [wsjt-devel] WSJTX Cabrillo log time

[Reino Talarmo via wsjt-devel]

Well, it depends on the band and propagation mode. At crowded HF bands
getting the first report is the issue. At VHF bands situation is diffent,
meteor scatter can be an extreme example, but also QSB could require many
report and report confirmation repeats before a RRR or RR73 is received.

73, Reino OH3mA 

> -Original Message-
> From: Alan McDonald via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net]
> Sent: torstai 11. toukokuuta 2023 10.17
> To: 'WSJT software development' 
> Cc: Alan McDonald 
> Subject: Re: [wsjt-devel] WSJTX Cabrillo log time
> 
> Well typically you can spend a long time calling (off and on) and then
when the
> counterparty responds it takes on 60 secs to complete.
> As far as the counterparty is concerned, it never started until 60 sec
prior to
> complete.
> 
> Alan McDonald
> Worimi Country
> 0413 657 427
> 
> -----Original Message-
> From: Reino Talarmo via wsjt-devel 
> Sent: Thursday, May 11, 2023 5:08 PM
> To: 'WSJT software development' 
> Cc: Reino Talarmo 
> Subject: Re: [wsjt-devel] WSJTX Cabrillo log time
> 
> Hi Saku and Alan,
> 
> I think that Alan already pointed a least indirectly that the definition
of the
> actual start time is a bit more difficult than a defining end time. Also
end time
> may be difficult, if participants have different opinion e.g.
> whether a final 73 is needed or not. I have not studied, whether the end
time  is
> the reception and the sending of the first or last RR73 or RRR. It may be
also the
> actual qso logging time.
> 
> 73, Reino OH3mA
> 
> > -Original Message-
> > From: Alan McDonald via wsjt-devel
> [mailto:wsjt-devel@lists.sourceforge.net]
> > Sent: torstai 11. toukokuuta 2023 9.59
> > To: 'WSJT software development' 
> > Cc: Alan McDonald 
> > Subject: Re: [wsjt-devel] WSJTX Cabrillo log time
> >
> > I agree, big problem also for chasing rare DX that takes quite some
> > time, sometimes to complete.
> > I have to be diligent and make sure my log uses OFF and not ON because
> > the counterparty has OFF in their log.
> > I wish there was an option to leave checked = Use OFF time for ON/OFF
> >
> > Alan McDonald
> > VK1AO
> > -Original Message-
> > From: Saku via wsjt-devel 
> > Sent: Thursday, May 11, 2023 4:38 PM
> > To: wsjt-devel@lists.sourceforge.net
> > Cc: Saku 
> > Subject: [wsjt-devel] WSJTX Cabrillo log time
> >
> > HI!
> >
> > Just worked a short OH-FT8 contest that uses "NA VHF" settings with
> WSJT-X.
> > I had my logging program using UDP remote connect to WSJT-X and once
> > contest was over I created Cabrillo logs. From WSJT-X and from my
> > logging program.
> > Just to compare.
> >
> > Then I started to wonderwhy logs differ?
> >
> > Further investigation from WSJT-X adi log showed out that WSJT-X uses
> > "time_off" as Cabrillo time, while my logging program uses "time_on"
> > for
> it.
> > Difference, when it happens, is usually 1-2 minutes. But if it
> > happens, in
> very
> > poor conditions, that completing qso needs many periods that time
> difference
> > may grow to several minutes, I think. (Depending on used contest format.
> NA
> > VHF is quite straight, while EU VHF has a period more to
> > exchange)
> >
> > I checked Cabrillo definitions from wwrof.org but there seems to be no
> > definition about QSO record time (start or end of qso).
> > That is perhaps because in traditional CW or Phone contests the time
> > is
> always
> > QSO start time as qsos take only few seconds.
> >
> > FT8 world is a bit different, or is it anyway?
> >
> > On what bases it has been chosen that WSJT-X uses qso end time as
> > Cabrillo time?
> >
> >
> > --
> > Saku
> > OH1KH
> >
> >
> >
> > ___
> > 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



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

Re: [wsjt-devel] WSJTX Cabrillo log time

[Reino Talarmo via wsjt-devel]

Hi Saku and Alan,

I think that Alan already pointed a least indirectly that the definition of
the actual start time is a bit more difficult than a defining end time. Also
end time may be difficult, if participants have different opinion e.g.
whether a final 73 is needed or not. I have not studied, whether the end
time  is the reception and the sending of the first or last RR73 or RRR. It
may be also the actual qso logging time.

73, Reino OH3mA

> -Original Message-
> From: Alan McDonald via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net]
> Sent: torstai 11. toukokuuta 2023 9.59
> To: 'WSJT software development' 
> Cc: Alan McDonald 
> Subject: Re: [wsjt-devel] WSJTX Cabrillo log time
> 
> I agree, big problem also for chasing rare DX that takes quite some time,
> sometimes to complete.
> I have to be diligent and make sure my log uses OFF and not ON because the
> counterparty has OFF in their log.
> I wish there was an option to leave checked = Use OFF time for ON/OFF
> 
> Alan McDonald
> VK1AO
> -Original Message-
> From: Saku via wsjt-devel 
> Sent: Thursday, May 11, 2023 4:38 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Saku 
> Subject: [wsjt-devel] WSJTX Cabrillo log time
> 
> HI!
> 
> Just worked a short OH-FT8 contest that uses "NA VHF" settings with
WSJT-X.
> I had my logging program using UDP remote connect to WSJT-X and once
> contest was over I created Cabrillo logs. From WSJT-X and from my logging
> program.
> Just to compare.
> 
> Then I started to wonderwhy logs differ?
> 
> Further investigation from WSJT-X adi log showed out that WSJT-X uses
> "time_off" as Cabrillo time, while my logging program uses "time_on" for
it.
> Difference, when it happens, is usually 1-2 minutes. But if it happens, in
very
> poor conditions, that completing qso needs many periods that time
difference
> may grow to several minutes, I think. (Depending on used contest format.
NA
> VHF is quite straight, while EU VHF has a period more to
> exchange)
> 
> I checked Cabrillo definitions from wwrof.org but there seems to be no
> definition about QSO record time (start or end of qso).
> That is perhaps because in traditional CW or Phone contests the time is
always
> QSO start time as qsos take only few seconds.
> 
> FT8 world is a bit different, or is it anyway?
> 
> On what bases it has been chosen that WSJT-X uses qso end time as Cabrillo
> time?
> 
> 
> --
> Saku
> OH1KH
> 
> 
> 
> ___
> 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] FT8 TX6 mod entry and security hole

[Reino Talarmo via wsjt-devel]

> However attempting to use "CQ 3C AF8C EN81" created a couple of  problems.

Hi Glenn,
You are simply trying something that is not supported in WSJT-X. The only
supported additions to the CQ message are:
CQ 000 - CQ 999 3 to 1002
CQ A - CQ Z 1004 to 1029
CQ AA - CQ ZZ 1031 to 1731
CQ AAA - CQ ZZZ 1760 to 20685
CQ  - CQ  21443 to 532443

The number ranges after possible number or letter combinations are the
actual values used in the message encoding process. 
In short either exactly 3 number characters or from 1 to 4 letters are only
supported in the encoding.
For further information you may study in document
https://wsjt.sourceforge.io/FT4_FT8_QEX.pdf 
It is a bit heavy, I promise.

73, Reino OH3mA



___
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

[Reino Talarmo via wsjt-devel]

>From: Alan via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
>Since WSJT-X shifts any transmit audio below 1500Hz higher up the spectrum how 
>>come we see RX signals on the waterfall below 1500Hz?

>I presume on RX it shifts all signals back down by the same amount as they 
>were >shifted up on TX?

Hi Alan,

You question is answered in the User Guide 4.1. General, see the last bullet 
point 'Split Operation'. If you have any further questions on that issue you 
may send me a private mail (clicking CC: Reino Talarmo should reveal my email 
address).

73, Reino OH3mA



___
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

[Reino Talarmo via wsjt-devel]

> From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
> Much the same as a rig from 50 years ago looks nothing like today -- 
> including the fact that old rigs had no "split" capability at all and you had 
> to use a 2nd transceiver to accomplish the same thing.
> Then they added a split button and operators said "what can I do with this?". 
>  And CW split working a DXpedition or such was born.
> Then software came along and operators said "what can I do with this?".  And 
> WSJT-X rig split was born.
> And then operators said "Rig split doesn't work on my rig with WSJT-X".  And 
> WSJT-X Fake It was born.

Hi Mike,

A nice review of history, I have lived through it! You describe well how rig 
control for split evaluated. BUT the last two made a new usage of the rig split 
function. That split is totally a station's internal action/function as the 
resulting transmitted signal does not change due the split action. Operator is 
still needs to take care of the *split working* i.e. to select a different 
transmission frequency than the target station is using for transmission.

That means we now have two different 'splits'. 

Sam just sent his proposal how to remove the split word in the relation of the 
local split usage. There may be no need for a 'two level' selection and just 
the title could be 'Audio optimization'. For sure related text in the User 
Guide needs same update, but in addition the 'Hold Tx Freq' related description 
should introduce 'split working' and perhaps a note to state that the Audio 
Optimization is independent of that and can be used at the same time.

> Let's just agree that things change over time and we need to revisit our 
> burned-in-the-brain definitions of things.

Yes, but uses should also informed that there are two different splits used, 
when operating WSJT-X.

> This hobby is all about learning so let's learn something newand it's not 
> that new since WSJT-X has been out for a very long time.

Sure, but the learning curve for FT8 is quite steep and any unnecessary 
confusion should be avoided.

> I do realize that many don't understand the nuances of the different modes -- 
> much as I've had to help educate many just about bandwidth alone and have 
> found trying to educate some about the 1500-2000Hz behavior can take some 
> considerable effort for it to sink in.

I have the same feeling. Better to make that specific issue less confusing.

73, Reino OH3mA



___
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

[Reino Talarmo via wsjt-devel]

> From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: sunnuntai 7. toukokuuta 2023 19.35
> That's why I put 3 definitions of split in there.  It means different things 
> in
> different contexts
 
Hi Mike and Sam,
I have had a lot of private discussion with Adrian and we have not yet reached 
final agreement. I am not going to repeat that discussion here.

Let's look first why we have any split action? 
I have spotted two independent issues.

#1 WSJT-X uses split to keep audio to RF mixing at sweet point inside radio.
- Transmitted power is as constant as possible independently of the location of 
the red goalpost on waterfall. Technically it means that internally audio 
frequency is kept in range 1500 to 2000 Hz and rigs VFO frequency is shifted to 
keep the transmit frequency intact. 
- The audio frequency range 1500 to 2000 Hz shifts the harmonics of the audio 
signal outside Tx SSB filter passband and the transmitted signal is kept clean.
- For this WSJT-X uses terminology *Split operation*. This means the radio is 
controlled via CAT using split function of the radio. 
- This split operation is not detectable at the output (antenna connector) of 
the radio.

#2 The second is the 'classical' split working. That simply means that for set 
up and during a QSO stations communicating are using different frequencies.
- Split is used to minimize QRM especially on the transmission frequency of the 
DX station. 
- Usually the split frequency difference is more that signal bandwidth as that 
minimizes QRM. In WSJT-X both signals are normally within rig's audio bandwidth.
- WSJT-X FT8 tolerates a certain amount of QRM and can decode overlapping 
signals. But there is a limit and a pile-up on the DX station transmission 
frequency (= single frequency operation) would be less effective than using 
*split working*. I do remember when Joe K1JT sent free text messages USE SPLIT 
PSE.
- WSJT-X supports split working very well as it has built-in skimmer function 
by decoding all signals inside the waterfall.
- In WSJT-X the *split working* is supported by the Hold Tx Freq and by the 
independent selections of reception and transmission frequencies. e.g. using 
green and red goalposts.
- On the radio frequency point of view the green and red goalposts behave as 
VFOs. (The conversion from audio FT8 to radio frequency FT8 is just a frequency 
translation.)
- There is no real difference between *split working* in CW, SSB and FT8/FT4 
(or almost all WSJT-X modes). In CW operator may use a CW skimmer to help in 
tuning reception frequency, in WSJT-X that is built-in.

#3 Those two splits are independent of each other.
- #1 depends only on the red goalpost location.
- #2 is a user selection.

I do recommend that this issue will be added in some form into the User Guide. 
The current wording seems to generate a lot unnecessary confusion, including me 
at my FT8 novice time.

73, Reino OH3mA




___
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

[Reino Talarmo via wsjt-devel]

Hi Adrian,

This start to be really funny! 

Let me take a real scenario that I participated. If I remember correctly it was 
a FT8 contest and there were a rare station, at least to me, K1JT. So everybody 
called him, including me, quite a pile-up on his transmit frequency. Joe tried 
to manage that pile-up by sending message 'USE SPLIT PSE'.

What he meant by that? Did he recommended that everybody should use Split 
operation 'Rig' or 'Fake It' while working him or something else?

If he meant Split operation, how he knew that the operators were selected Split 
operation 'None'? He had no access to other stations rigs nor monitor function 
of those rigs. By magic, perhaps.

No, no, he meant use Split working i.e. send on another frequency that where he 
is sending. 

I did and managed to work him, but he never sent 73 to my RR73, but that's 
another story as I was novice at that time.

Adrian, split *working* means that you are sending at a different frequency (as 
seen on antenna connector) than the station is transmitting while you try a QSO 
or have a QSO with that specific station. That is the split *working* what is 
discussed. Of course there may be also that split *operation* your see 
happening in your rig, but nobody else sees it. It is just a way how your 50 Hz 
wide transmit frequency is generated (by double or triple mixing depending on 
your rig).

Now the receiving part of a QSO. What it means? There are two stations, yours 
and the DX station. You see the DX station on a specific frequency on the 
waterfall. Once you call him by double clicking or answering to the DX 
station's call, your Rx green goalpost jumps to that frequency. Why it needs to 
do that although you see all the stations at the same time? 

The green goalpost indicates the frequency, where your decoder starts decoding 
i.e. it is your most important received frequency at that time. All other 
station you see in the Band Activity are just extra, but those are not any part 
of your current QSO. So the green goalpost is your receiver frequency. All 
others are from your FT8 skimmer as an extra for you. 

Saku's SDR functionality description was an excellent way to say the same. 

To wrap-up: there are two splits. One for split working also known as classical 
split and the other for split operation that is a totally local issue how the 
transmit signal is generated. The first is seen by other operators and latter 
is hidden inside the transmitting station.

Perhaps my last pennies on this subject, hi!
Have all fun!
73, Reino OH3mA



___
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

[Reino Talarmo via wsjt-devel]

Hi Sam, Adrian and the Experts,
Before I can answer some of the questions, I need to repeat my understanding 
how SPLIT should be defined. I use two different ‘splits’ that can be used at 
the same time or independently.

#Class: the classical split simply means you are using a different radiated 
frequency than the target station is using. So you are not using the classical 
split, when you are calling CQ! The classical split is used to avoid QRM on the 
DX station's transmit frequency i.e. on your receiver frequency. The use of 
this slit is seen over the air.

#Int: the internal station split used to optimize transmission performance, 
audio harmonics attenuated and output power less dependent on the audio 
frequency. Radiated frequency is sum of the WSJT-X base frequency plus audio 
frequency. No relation between received and transmitted frequency. The use of 
this split is not seen over the air.
 
On 2/5/23 23:33, Sam W2JDB via wsjt-devel wrote:
Hi, 

> Having followed this thread from the beginning and being a small part of it 
> (in the beginning) I do have some questions regarding the use of the word 
> SPLIT as it pertains to WSJT-X versus its classical meaning on the HF Bands 
> in CW and SSB, i.e. UP 5 or UP 10 etc.

> First, I would you all agree that while you are in the receive state in 
> WSJT-X, you are listening for the entire band pass beginning at the base, 
> i.e.  14.074 plus a small offset such as 200 and extending to the upper limit 
> of the bandpass that you specified. That does not change no matter where you 
> place your receive goal posts (green). 

# Split requires transmission so irrelevant and so agreed.

> The question now becomes if you are operating split when you move the TX 
> marker away from the RX marker. Suppose you don't have the SPLIT function on, 
> that is it is set to NONE. Are you still operating split if your TX marker is 
> at the edges of the bandpass?   

#Class: yes, "Int: no.

> Now lets look at it the other way, suppose you set the TX marker at 1500 
> smack dab in the center, or close to it, and you do have the SPLIT function 
> on, Fake It or Rig it does not matter. Are you now operating SPLIT? 

#Class: not defined in the question, yes or no depending where the station you 
are calling/working happens to be, #Int: yes, but no rig control action needed.

> How about you have SPLIT on and are on offset 2000, calling someone who is on 
> 500 and he then answered you on offset 2000.  Did you operate SPLIT? 

#Class: yes, but the other operator changes the QSO to non-split, #Int: 
potentially, if activated.

> Here is another question, suppose I am in a QSO, phone, my equalizer is set 
> to emphasize the lower frequencies and attenuate the middle and the highs 
> while my counterparty emphasizes the higher frequencies and attenuates the 
> lower to the middle.  Are we operating SPLIT? 

#Class: no, #Int: not applicable.
   
> How about the situation when you need to use either RIT or XIT function in 
> the rig, Are you operating SPLIT?

#Class, if your RIT or XIT is tuned more than the used bandwidth, then yes.

> As someone said it, no one owns the meaning of the word SPLIT, but the choice 
> of using the word SPLIT within WSJT-X seems to be the wrong word as it runs 
> counter to its classical meaning in the HAM community and introduces 
> confusion. We all know, or should know, that WSJT-X uses a function, should 
> we to choose to use it, optimize the output power and minimize and distortion 
> no matter where the TX marker is. That function simple shifts things around 
> so that the audio component is somewhere around the center of the bandpass.  

The same observation!

73, Reino OH3mA




___
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

[Reino Talarmo via wsjt-devel]

Jim, Mike and all experts,

May I repeat a bit history of 'split' in the WSJT-X as I have learned it.
1# The split operation or split mode is mentioned on the radio settings. It
defines how WSJT-X controls radio and that's the only usage of the split
word in the User Manual.
2# Limiting the usage of the split word to that most probably was a logical
decision to prevent mixing it to the 'split working', hi! Well, in reality
WSJT was designed for various weak signal modes especially EME and there is
(was) no need for any split working as known in HF pileups!
3# Unfortunately that choice is shown to be very misleading to HF operators
due to the split (working) practices in other modes, CW and SSB. 
4# We should dilute the situation by adding suitable words both into the
'split operation' section(s) and the 'Hold Tx Freq' section(s) in the User
Guide. The 'split operation' may just need a 'warning' that this is not the
'classical' split working as the transmitted frequency does change. The
'split mode' as such is clear and no need to make any addition. The 'Hold Tx
Freq' description/recommendation may require just a statement that this is
the (classical) split working as known in DX pileups and should not be mixed
with the CAT control related 'split operation' of the rig. WSJT-X may or may
not use the 'split operation' in the 'split working' depending on the
selected Tx audio frequency.

My second 2 cents.
73, Reino OH3mA

> -Original Message-
> From: Jim Brown via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: tiistai 2. toukokuuta 2023 7.29
> To: wsjt-devel@lists.sourceforge.net
> Cc: Jim Brown 
> Subject: Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles
> 
> On 5/1/2023 8:31 PM, Black Michael via wsjt-devel wrote:
> > Nobody owns the definition of split
> 
> Mike,
> 
> For as long as I've been a ham (68 years) "split" operation has meant
> transmitting on a frequency DIFFERENT from the station you're working.
> The most common application is for a DX station in a rare location, when
he
> tells callers to call higher in frequency. I suspect that this was common
practice
> years before my time.
> 
> I'm only guessing, but several decisions made by the developers of WSJT
modes
> had little if any experience on the HF bands. One decision was to use the
word
> "split" to describe something entirely different from what it had meant
since at
> least since at least the early 1950s. Another bad decision was the choice
of FT4
> operating frequency on 40M. Another was to allow far more empty space
> between watering holes for what has become nearly a dozen on the HF bands.
If
> a WSJT-X channel is 2.8 kHz, 3 kHz spacing makes far more sense than ten!
> 
> My training is electrical engineering, and except for having learned to
use
> computers and software operationally, I live in the analog world. I
wouldn't
> dream of diving into digital and software and start defining things or
> establishing practices for that world -- I'd learn what those practices
were and
> follow them!
> 
> > as for confusing hams they are
> > only confused because they refuse to learn.
> 
> Hams are confused with "split" in WSJT-X 1) because it's NOT "split" as
defined
> within ham radio since the early '50s; and 2) because they don't
understand
> how SSB is used to transmit and receive digital modes.
> 
> If anyone had asked me what to call the practice of shifting the TX
frequency
> and audio frequency in opposite directions to minimize audio distortion I
would
> have suggested the word "shift" or "TX shift,"
> because that's what WSJT-X is doing. "Shift" is the wrong word!
> 
> And when we follow the good operating practice of never calling another
> FT8 or FT4 on their own frequency, we ARE working split!
> 
> BTW -- they guys who developed hardware and software for SDRs did
something
> equally uniformed, using the word "diversity" to describe something that
wasn't
> diversity - diversity reception was first used in the earliest days of
radio (at least
> the 1920s) to deal with selective fading).
> 
> 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

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

[Reino Talarmo via wsjt-devel]

Hi Adrian, Sam and all interested parties,

I also disagree, but that's not fair as we have not defined terminology for 
this discussion! Warning: this takes a bit bandwidth, sri.

Behind there may be two issues. The first is what is meant by the transmission 
frequency in FT8? The second is of course what split means?

Let's first take the FT8 transmission frequency, RF frequency. Before that we 
need to agree that an FT8 signal is 50 Hz wide eight level frequency shifting 
modulated (constant amplitude) signal and for the purposes of WSJT-X nominal 
frequency is the same as the lowest tone of those eight tones. [Quite often the 
center of the transmission is defined as the signal frequency, but it is 
irrelevant for this discussion.]

We need to look what is radiated from the antenna, RF frequency. That is the 
only point an observer e.g. official frequency monitoring unit will see. When 
FT8 is generated in the typical manner, then it is rig's carrier frequency + 
audio frequency. It is irrelevant what are the carrier and audio frequencies, 
only the sum of those has a meaning. [In some rigs the carrier frequency is the 
same as VFO frequency, but in older rigs there are additional mixing stages 
with band frequency generators.] Actually it is possible to generate the FT8 
signal directly on the RF frequency as well. So what you see at antenna is the 
transmission frequency.

[Please note that voice signal is a wide signal typically 300 Hz to 2800 Hz or 
so. The RF frequency is defined as the carrier frequency that is zero Hz at 
audio level. That is a modulation type based definition. It is the same as for 
Amplitude Modulation, just only one sideband is sent and no carrier in SSB. 
Although FT8 signal is generated or actually moved to radio frequency using an 
SSB rig, still it is not an SSB transmission. Some rigs generate CW in the same 
manner, but nobody calls CW as SSB in that case. The same is valid for (ASK) 
RTTY.]

The second is 'split'. WSJT-X uses 'Split Operation' or 'Split Mode' 
internally. By internal I mean that you cannot tell from the antenna radiated 
signal whether that 'internal split' is used or not. [Well, no rig is perfect 
or operator may misuse it and the unwanted radiation can tell how the signal is 
generated. But that's not an issue for this discussion.] So that 'Split 
operation' in only an internal RF signal generation issue.

There is another 'split' mentioned in the User Guide. In that context word 
'split' is not used, but indirect expression such as the recommendation to 
avoid QRM on the DX Rx frequency by using 'Hold Tx Freq' and selecting another 
'free' Tx frequency on the waterfall. Radio amateurs usually call that way of 
working 'split'. Perhaps 'split working' could be used in that context. Coming 
back to the RF frequency. the 'split working' is seen at antenna as the Rx 
frequency is different than the Tx frequency. I could say it is an external 
split. 

Now with those definitions the internal 'Split Operation' does not change radio 
frequency. It changes VFO frequency, but that's irrelevant on the antenna 
radiation point of view. On the other hand having the Rx green goalpost at a 
different (audio) frequency that the Tx red goalpost is classical split working 
(in short 'split') as at the antenna there are different Rx and Tx frequencies.

Perhaps we could add some note into the User Guide on that issue. Currently 
terminology seems to lead to unnecessary disagreements and move discussion to 
irrelevant arguing instead of discussing the original item (a random frequency 
selection for CQ).

My 2 cents.

73, Reino OH3mA

> -Original Message-
> From: Adrian via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: sunnuntai 30. huhtikuuta 2023 11.03
> To: WSJT software development 
> Cc: Adrian 
> Subject: Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles
> 
> I disagree with below.
> 
> Sam explained it well. Keeping the same Pan TX location the RF frequency is
> shifted to maintain and audio frequency suitable for the best passband
> performance and level
> 
> continuity. It is split. The TX VFO adjust to 500, 1000 below the RX RX VFO
> frequency when pan TX marker is set  ~ 500 or 1000 below  the mid mark. and
> opposit when set above so the TX vfo raises frequency 500, 100 Hz and so on.
> The same effect of changing frequency changing the pitch of a received
> voice/signal is the same effect used to get the audio frequency in the 
> sweetspot
> while maintaining pan position for stations listening. Any frequency shift
> between TX and RX is split operation.
> 
> Fake (split) is changing the same (TX/RX) vfo frequency between TX and RX for
> the same effect.
> 
> 
> vk4tux
> 
> 
> > When using sideband modulation (USB/LSB) the RF frequency is tied to
> > audio slot frequency. That is: dumped RF carrier +/- audio frequency
> > depending on sideband used. If we change audio slot we change RF
> > frequency that means we are 

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

[Reino Talarmo via wsjt-devel]

Sam, as you very well know the User Guide talks about CAT ‘Split Operation’ or 
‘Split Mode’. It is the manner how WSJT-X controls your rig. Unfortunately a 
short version ‘Split’ is used in discussions both in that manner and in the 
classical manner what is described in the User Guide in 6.8. FT8:

“To avoid QRM from competing callers, it is usually best to answer a CQ on a 
different frequency from that of the CQing station. The same is true when you 
tail-end another QSO. Choose a Tx frequency that appears to be not in use. You 
might want to check the box Hold Tx Freq.”

 

Bill (sk) wanted to keep the terminology ‘Split operation’ as it is exactly 
what happens in the classical split working i.e. VFO frequency is changed. In 
any other mode outside WSJT-X the split is looked at the antenna interface, 
where is means a different Rx and TX frequency. Currently that mode of working 
is recommended in the User Guide as above. It is ‘use the Hold Tx Freq and 
choose a different Tx frequency that the other station is using i.e. Rx 
frequency’. Too many words, hi! 

 

I think that the ‘Split Operation’ is the WSJT-X terminology and word ‘split’ 
is not used alone. We could use e.g. ‘split working’ to separate those two 
usages of ‘split’. 
The word split is not owned in WSJT-X to cover only one specific meaning.

 

73, Reino OH3ma

 

From: Saku via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: sunnuntai 30. huhtikuuta 2023 10.25
To: wsjt-devel@lists.sourceforge.net
Cc: Saku 
Subject: Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles

 

Sam W2JDB via wsjt-devel kirjoitti 28.4.2023 klo 15.03:

Saku, split on WSJT-X means that WSJT-X can automatically adjust your frequency 
so that your transmit audio is always somewhere within the middle of the audio 
bandpass.   

 

73,

Sam W2JDB

 

 

Hi Sam!

Split, what Google translate says, means "divide by parts". And that it is when 
we are talking about split in Ham radio. I.E. Transmit on other frequency as 
listen, just like Reino says.

When using sideband modulation (USB/LSB) the RF frequency is tied to audio slot 
frequency. That is: dumped RF carrier +/- audio frequency depending on sideband 
used. If we change audio slot we change RF frequency that means we are using 
"split" in means what is in Ham radio.

Using the thoughtlessly named "split operation" of wsjt-x/settings/radio has NO 
effect to RF frequency that is produced. It is always the same as "split 
operation", when used, adjusts the ratio of RF carrier to audio frequency to 
keep the produced RF frequency always the same while centering the audio 
frequency in middle of AF filter passband.

Better would have been to call "settings/radio/split operation" as:

"Optimize audio passband":  none,  using 2 vfos,  adjust 1 vfo

That would have been less confusing, just like Jim says.

 

But that was not the subject after all. 
We were talking about the benefits of having randomized frequency on TX1 and 
TX6.
Reino states that using random TX could prevent neighbor station to complete 
his DX qso. Well, I do not think so.
TX1 and TX6 jumping may disturb neighbor, but only one time. Next transmit is 
again on different frequency. Unless the qso is established and TX locked.

But that is life. It is not worse than losing DX because band polices "trying 
to keep DX frequency clear" causing most qrm by them self.

And usually very close neighbors are using same period for TX when there is no 
harm at all. That is the best benefit of FT8 DXing: keeping the TX periods 
organized, mostly. There always are someones that think that transmitting on 
other period than others could catch DX better.

Ok, now the original subject is splitting again. Best to QRT.

-- 
Saku
OH1KH
___
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

[Reino Talarmo via wsjt-devel]

Hi Sam,

Saku was talking about ‘RF split’. The WSJKT-X Split Operation is only a method 
to keep your signal at optimum range at audio level.

On the other hand I don’t support of the idea that WSJT-X would randomly select 
my transmission frequency. I don’t like that the tx frequency jumps on a 
frequency where my neighbor is about to complete QSO with an important DX 
station. I still believe that an operator is more capable to select a suitable 
transmit frequency, although there is a limited knowledge what the DX is 
receiving at his station, hi.

73, Reino OH3mA 

 

From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: perjantai 28. huhtikuuta 2023 15.03
To: wsjt-devel@lists.sourceforge.net
Cc: Sam W2JDB 
Subject: Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles

 

Saku, split on WSJT-X means that WSJT-X can automatically adjust your frequency 
so that your transmit audio is always somewhere within the middle of the audio 
bandpass.   

 

73,

Sam W2JDB

 

 

-Original Message-
From: Saku via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> >
To: wsjt-devel@lists.sourceforge.net  
Cc: Saku mailto:oh...@sral.fi> >
Sent: Fri, Apr 28, 2023 7:35 am
Subject: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles

 

How do you know that?

Perhaps on low bands but higher HF bands you can not hear others near 

by. Besides most of qsos are running "split" Station A on different 

audio frequency slot as opponent B.

 

I would rather see improvement where CQ (TX6) and answer to CQ (TX1) 

would be randomized. So that every CQ, or every try to answer other's CQ 

would happen on different audio slot. If qso is established then TX 

audlo would be locked to current audio slot for qso.

 

 

-- 

Saku

OH1KH

 

Jim Brown via wsjt-devel kirjoitti 28.4.2023 klo 0.53:

 

> Likewise, if we call CQ (or another station) for more than a few calls 

> without a response, it's good operating practice to pause for at least 

> one cycle to check what's happening on your frequency.

> 

> 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

Re: [wsjt-devel] Unsubscribe

[Reino Talarmo via wsjt-devel]

Hi Dave,

Go to https://sourceforge.net/projects/wsjt/lists/wsjt-devel/unsubscribe and
follow instructions, please.

73, Reino OH3mA

 

From: dave--- via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: tiistai 25. huhtikuuta 2023 16.58
To: wsjt-devel@lists.sourceforge.net
Cc: d...@buckwalter.co
Subject: [wsjt-devel] Unsubscribe

 

 

Unsubscribe

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

Re: [wsjt-devel] Truncated Waterfall Display "Feature"

[Reino Talarmo via wsjt-devel]

Thanks Mike,
I see on 40 m band a bit different distribution of S/N values. In my case 
typical average S/N value is about 5 dB higher than yours and standard 
deviation is a bit below 10 dB, while in your case it is 8 dB. The interesting 
point is the -24 dB value. In your case the lower the less spots, I always have 
more spots on the -24 dB than at -23 dB. Never seen any spot below -24 dB, but 
I have filtered spots from the ALL.txt file as I have in those examples only 
messages that have been present in two ALL.txt files same time and callsign, 
also frequencies need to be closer to each other than 50 Hz.

Was that histogram from ALL.txt or from contacts you have made? There are so 
few spots below -24 dB that those could be from false decodes as the 
presentation values are from -30 to 99 dB. Also some of the high values could 
be from false decodes.

73, Reino OH3mA

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: maanantai 10. huhtikuuta 2023 17.00
To: Reino Talarmo via wsjt-devel 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

-24 is not the minimum SNR reported.  -30 is. Below -24 is pretty rare though 
and is a big "knee"in the data.
Here's a histogram from my station.
Mike W9MDB

  3 -27
 23 -26
 75 -25
   2353 -24
   3907 -23
   8187 -22
  16812 -21
  28821 -20
  41617 -19
  49679 -18
  54327 -17
  56758 -16
  56976 -15
  55953 -14
  54478 -13
  52240 -12
  50195 -11
  47384 -10
  44725  -9
  42112  -8
  38922  -7
  36171  -6
  33457  -5
  30718  -4
  28010  -3
  25648  -2
  23303  -1
  21015   0
  18789   1
  16493   2
  14505   3
  12637   4
  10915   5
   9340   6
   8041   7
   6784   8
   5697   9
   4804  10
   3982  11
   3401  12
   2743  13
   2229  14
   1724  15
   1380  16
   1051  17
796  18
606  19
433  20
313  21
244  22
173  23
110  24
 75  25
 48  26
 38  27
 30  28
 26  29
 13  30
  8  31
 10  32
  1  33
  2  34
  1  35
  2  36
 12  38
  2  39
  5  40
  1  42
  1  43
  1  45
  1  47
  1  48
  1  49
  1  52
  1  57
  1  58
  1  59
  1  60
  1  61
  2  62
  1  63
  2  64





On Monday, April 10, 2023 at 08:44:23 AM CDT, Reino Talarmo via wsjt-devel 
 wrote: 


Hi Sam,

Thanks Sam, I am aware of that problem and for sure it affects to the 
"absolute" S/N values. There is another issue due to the limited dynamic range 
and that all S/N values below -24 dB are reported as -24 dB. I have partially 
tried to avoid the issue by only taking into calculation messages that are 
received by both receives. I also checked how much those measurements with one 
of the values reported as -24 dB (less than 1 % of all values) really affect to 
the calculated average and deviation values and there is a minor shift at one 
or two higher attenuation point, when I leave those out. 

73, Reino OH3mA

-Original Message-
From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: maanantai 10. huhtikuuta 2023 14.38
To: wsjt-devel@lists.sourceforge.net
Cc: Sam W2JDB 
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

Hi Reino, 

The one thing to be aware of when analyzing SNR is that since you can not 
account for the signals that you did not decode, 
those that are below the threshold, the mean will always be biased towards the 
positive side and those missing decodes 
invariable would have affected the variance and standard deviation values. 

73,

Sam W2JDB


-Original Message-
From: Reino Talarmo via wsjt-devel 
To: 'WSJT software development' 
Cc: Reino Talarmo 
Sent: Mon, Apr 10, 2023 3:33 am
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"
Hi,

Just as promised, I looked what happens, when I set waterfall from 200 Hz to 
1500 Hz (just bit more). The measurement was a side result of a study how a 
narrower radio filter affects to the S/N values. I have two similar receivers 
and I feed the same antenna signal via a power divider to those receivers. I 
calculate using ALL.txt files differences of the S/N values for the same 
(common) messages. That removes transmit power and  propagation from the 
equation. For the filtering study I calculate in 25 Hz slots the number of 
messages and an average and standard deviation of S/N differences. By this 
method the filter passband and out of band attenuation on quite wide range up 
to 60 dB on longer measurement times. The typical standard deviation is about 3 
dB. Quite good for a S/N calculation that is not designed at all for this 
purpose. Also linearity seems to be better that in some earlier versions.

Now the result: there is not a single decoding in 35 361 decoded messages above 
1500 Hz.

A related observation close to the waterfall edge. The standard deviation 
increases from 3.8 dB to 7.7 dB in th

Re: [wsjt-devel] Truncated Waterfall Display "Feature"

[Reino Talarmo via wsjt-devel]

Hi Mike,

Perhaps I need to do the same search. I remember that Bill (sk) mentioned that 
the -24 dB is used in WSJT-X for FT8 because the accuracy is so poor below that 
value, but may be changed. Not a big issue.

73, Reino OH3mA

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: maanantai 10. huhtikuuta 2023 17.00
To: Reino Talarmo via wsjt-devel 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

 

-24 is not the minimum SNR reported.  -30 is. Below -24 is pretty rare though 
and is a big "knee"in the data.

Here's a histogram from my station.

Mike W9MDB

 

  3 -27

 23 -26

 75 -25

   2353 -24

   3907 -23

   8187 -22

  16812 -21

  28821 -20

  41617 -19

  49679 -18

  54327 -17

  56758 -16

  56976 -15

  55953 -14

  54478 -13

  52240 -12

  50195 -11

  47384 -10

  44725  -9

  42112  -8

  38922  -7

  36171  -6

  33457  -5

  30718  -4

  28010  -3

  25648  -2

  23303  -1

  21015   0

  18789   1

  16493   2

  14505   3

  12637   4

  10915   5

   9340   6

   8041   7

   6784   8

   5697   9

   4804  10

   3982  11

   3401  12

   2743  13

   2229  14

   1724  15

   1380  16

   1051  17

796  18

606  19

433  20

313  21

244  22

173  23

110  24

 75  25

 48  26

 38  27

 30  28

 26  29

 13  30

  8  31

 10  32

  1  33

  2  34

  1  35

  2  36

 12  38

  2  39

  5  40

  1  42

  1  43

  1  45

  1  47

  1  48

  1  49

  1  52

  1  57

  1  58

  1  59

  1  60

  1  61

  2  62

  1  63

  2  64

 

 

 

 

 

On Monday, April 10, 2023 at 08:44:23 AM CDT, Reino Talarmo via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Hi Sam,

Thanks Sam, I am aware of that problem and for sure it affects to the 
"absolute" S/N values. There is another issue due to the limited dynamic range 
and that all S/N values below -24 dB are reported as -24 dB. I have partially 
tried to avoid the issue by only taking into calculation messages that are 
received by both receives. I also checked how much those measurements with one 
of the values reported as -24 dB (less than 1 % of all values) really affect to 
the calculated average and deviation values and there is a minor shift at one 
or two higher attenuation point, when I leave those out. 

73, Reino OH3mA


-Original Message-
From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: maanantai 10. huhtikuuta 2023 14.38
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
Cc: Sam W2JDB mailto:w2...@aol.com> >
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

Hi Reino, 

The one thing to be aware of when analyzing SNR is that since you can not 
account for the signals that you did not decode, 
those that are below the threshold, the mean will always be biased towards the 
positive side and those missing decodes 
invariable would have affected the variance and standard deviation values. 

73,

Sam W2JDB


-----Original Message-
From: Reino Talarmo via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> >
To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Reino Talarmo mailto:reino.tala...@kolumbus.fi> 
>
Sent: Mon, Apr 10, 2023 3:33 am
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"
Hi,

Just as promised, I looked what happens, when I set waterfall from 200 Hz to 
1500 Hz (just bit more). The measurement was a side result of a study how a 
narrower radio filter affects to the S/N values. I have two similar receivers 
and I feed the same antenna signal via a power divider to those receivers. I 
calculate using ALL.txt files differences of the S/N values for the same 
(common) messages. That removes transmit power and  propagation from the 
equation. For the filtering study I calculate in 25 Hz slots the number of 
messages and an average and standard deviation of S/N differences. By this 
method the filter passband and out of band attenuation on quite wide range up 
to 60 dB on longer measurement times. The typical standard deviation is about 3 
dB. Quite good for a S/N calculation that is not designed at all for this 
purpose. Also linearity seems to be better that in some earlier versions.

Now the result: there is not a single decoding in 35 361 decoded messages above 
1500 Hz.

A related observation close to the waterfall edge. The standard deviation 
increases from 3.8 dB to 7.7 dB in the last 25 Hz slot. The increase starts at 
1425 Hz slot. There is also 4.6 dB gain increase over that range. So there is 
some S/N calculation anomaly close to the band edge and unnatural high S/N 
values are seen close to band edge. 

Of course there is also the natural calcu

Re: [wsjt-devel] Truncated Waterfall Display "Feature"

[Reino Talarmo via wsjt-devel]

Hi Sam,

Thanks Sam, I am aware of that problem and for sure it affects to the 
"absolute" S/N values. There is another issue due to the limited dynamic range 
and that all S/N values below -24 dB are reported as -24 dB. I have partially 
tried to avoid the issue by only taking into calculation messages that are 
received by both receives. I also checked how much those measurements with one 
of the values reported as -24 dB (less than 1 % of all values) really affect to 
the calculated average and deviation values and there is a minor shift at one 
or two higher attenuation point, when I leave those out. 

73, Reino OH3mA

-Original Message-
From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: maanantai 10. huhtikuuta 2023 14.38
To: wsjt-devel@lists.sourceforge.net
Cc: Sam W2JDB 
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

Hi Reino, 

The one thing to be aware of when analyzing SNR is that since you can not 
account for the signals that you did not decode, 
those that are below the threshold, the mean will always be biased towards the 
positive side and those missing decodes 
invariable would have affected the variance and standard deviation values. 

73,

Sam W2JDB


-Original Message-
From: Reino Talarmo via wsjt-devel 
To: 'WSJT software development' 
Cc: Reino Talarmo 
Sent: Mon, Apr 10, 2023 3:33 am
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"
Hi,

Just as promised, I looked what happens, when I set waterfall from 200 Hz to 
1500 Hz (just bit more). The measurement was a side result of a study how a 
narrower radio filter affects to the S/N values. I have two similar receivers 
and I feed the same antenna signal via a power divider to those receivers. I 
calculate using ALL.txt files differences of the S/N values for the same 
(common) messages. That removes transmit power and  propagation from the 
equation. For the filtering study I calculate in 25 Hz slots the number of 
messages and an average and standard deviation of S/N differences. By this 
method the filter passband and out of band attenuation on quite wide range up 
to 60 dB on longer measurement times. The typical standard deviation is about 3 
dB. Quite good for a S/N calculation that is not designed at all for this 
purpose. Also linearity seems to be better that in some earlier versions.

Now the result: there is not a single decoding in 35 361 decoded messages above 
1500 Hz.

A related observation close to the waterfall edge. The standard deviation 
increases from 3.8 dB to 7.7 dB in the last 25 Hz slot. The increase starts at 
1425 Hz slot. There is also 4.6 dB gain increase over that range. So there is 
some S/N calculation anomaly close to the band edge and unnatural high S/N 
values are seen close to band edge. 

Of course there is also the natural calculated S/N increase over the narrow 
passband due to missing noise outside the passband. That easily results to 
misinterpretation that a narrow RX bandwidth will enhance decoding probability, 
it is just the actual "wrong" noise bandwidth in the S/N calculation!

73, Reino OH3mA

>From: Reino Talarmo [mailto:reino.tala...@kolumbus.fi] 
Sent: lauantai 8. huhtikuuta 2023 10.46

>Hi All,
>You may discuss different issues! In FT8 mode Sam is correct as the signals 
>are reached only on the frequencies displayed on the waterfall. In JT65 and 
>Q65 the situation is different at there is a spinner called F Tol that defines 
>the search range independent of the waterfall range. All that is written in 
>the User Guide. If something else is happening, then it is extra for the 
>operator benefit! I’ll do a FT8 test in my next 24 h recording.
73, Reino OH3mA



___
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] Truncated Waterfall Display "Feature"

[Reino Talarmo via wsjt-devel]

Hi,

Just as promised, I looked what happens, when I set waterfall from 200 Hz to 
1500 Hz (just bit more). The measurement was a side result of a study how a 
narrower radio filter affects to the S/N values. I have two similar receivers 
and I feed the same antenna signal via a power divider to those receivers. I 
calculate using ALL.txt files differences of the S/N values for the same 
(common) messages. That removes transmit power and  propagation from the 
equation. For the filtering study I calculate in 25 Hz slots the number of 
messages and an average and standard deviation of S/N differences. By this 
method the filter passband and out of band attenuation on quite wide range up 
to 60 dB on longer measurement times. The typical standard deviation is about 3 
dB. Quite good for a S/N calculation that is not designed at all for this 
purpose. Also linearity seems to be better that in some earlier versions.

Now the result: there is not a single decoding in 35 361 decoded messages above 
1500 Hz.

A related observation close to the waterfall edge. The standard deviation 
increases from 3.8 dB to 7.7 dB in the last 25 Hz slot. The increase starts at 
1425 Hz slot. There is also 4.6 dB gain increase over that range. So there is 
some S/N calculation anomaly close to the band edge and unnatural high S/N 
values are seen close to band edge. 

Of course there is also the natural calculated S/N increase over the narrow 
passband due to missing noise outside the passband. That easily results to 
misinterpretation that a narrow RX bandwidth will enhance decoding probability, 
it is just the actual "wrong" noise bandwidth in the S/N calculation!

73, Reino OH3mA

>From: Reino Talarmo [mailto:reino.tala...@kolumbus.fi] 
Sent: lauantai 8. huhtikuuta 2023 10.46

>Hi All,
>You may discuss different issues! In FT8 mode Sam is correct as the signals 
>are reached only on the frequencies displayed on the waterfall. In JT65 and 
>Q65 the situation is different at there is a spinner called F Tol that defines 
>the search range independent of the waterfall range. All that is written in 
>the User Guide. If something else is happening, then it is extra for the 
>operator benefit! I’ll do a FT8 test in my next 24 h recording.
73, Reino OH3mA



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

Re: [wsjt-devel] F/H mode in wrong period

[Reino Talarmo via wsjt-devel]

And they are using the ”wrong” period on purpose an politely so that  you see 
immediately that the normal FT8 should be used by “hounds”.

73, Reino OH3mA

 

From: Alan McDonald via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: sunnuntai 9. huhtikuuta 2023 15.05
To: WSJT software development 
Cc: Alan McDonald 
Subject: Re: [wsjt-devel] F/H mode in wrong period

 

I think you are assuming that they are using Fox and Hound with WSJT flavours. 
They are more likely using MSHV which does not require odd/even F/H. 

They just look like they are F/H but are just multi stream. You can work them 
as normal

Alan

 

On Sun, 9 Apr 2023 at 19:32, Ton PA0TBR via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

It becomes more often that I see Fox/Hound stations making QSO's in the wrong 
period.
When I check my own time it is exact, according to time.is  
Today again, I noticed a Fox in the wrong (odd) period together with some 
Hounds transmitting in the for them correct (odd) period.

But a few Hounds managed to transmit in the wrong (even) period enabling a QSO.

I wonder how these Hounds are able to follow in the wrong period?

73,
Ton pa0tbr

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




 

-- 

regards
Alan McDonald

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

Re: [wsjt-devel] Truncated Waterfall Display "Feature"

[Reino Talarmo via wsjt-devel]

Hi All,

You may discuss different issues! In FT8 mode Sam is correct as the signals are 
reached only on the frequencies displayed on the waterfall. In JT65 and Q65 the 
situation is different at there is a spinner called F Tol that defines the 
search range independent of the waterfall range. All that is written in the 
User Guide. If something else is happening, then it is extra for the operator 
benefit! I’ll do a FT8 test in my next 24 h recording.

73, Reino OH3mA

 

From: k2txb--- via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 8. huhtikuutata 2023 3:03
To: 'Sam W2JDB' ; 'WSJT software development' 

Cc: k2...@comcast.net
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

 

Hi Sam.  Well, try it.  It does work. The only requirement is to have the 
decode window width wide enough to cover the actual frequency that is being 
received.  It does not matter how wide the waterfall display is.  Of course, it 
is very helpful to be able to see the signal, so being able to decode outside 
of the window is of limited usefulness.  But it can be done.  Just got a 
message from another guy who said that I “hit the nail on the head”, hi.

 

Anyway, good luck with it.  My system is down right now for some antenna 
repairs and to try to fix an oscillating preamp.  Hope to be back on the moon 
sometime in the next week or two.

 

73, Russ K2TXB

 

From: Sam W2JDB via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Wednesday, April 5, 2023 3:23 PM
To: wsjt-devel@lists.sourceforge.net  
Cc: Sam W2JDB mailto:w2...@aol.com> >
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

 

Hi Russ, 

 

I don't beleive WSJT-X will decode any messages beyond the visual 
representation on the wide waterfall. 

 

If the right hand side of the waterfall terminates at 2000 Hz, WSJT-X will not 
decode beyond that.

 

That has been my experience. If your monitor resolution can not display a 
waterfall range of 200 - 2600 with bin/pixel set at 2, just increase it to 3 or 
higher as needed.

 

73,  

 

Sam W2JDB

 

 

-Original Message-
From: k2txb--- via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> >
To: 'Black Michael' mailto:mdblac...@yahoo.com> >; 'WSJT 
software development' mailto:wsjt-devel@lists.sourceforge.net> >
Cc: k2...@comcast.net  
Sent: Wed, Apr 5, 2023 2:45 pm
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

Sorry folks, I agree it would seem that way.  But only because there is no way 
to set the decoding window if you cannot see it.  I did not think of that, when 
I dashed off that message this morning.  And actually, if you set the decoding 
window large enough, I still think it would decode signals outside the 
waterfall range.   For example, I set the range to 1000, and center frequency 
to 1400 Hz.  That will now decode anything from 400 to 2400 Hz.

 

I still do not believe you need to be able to see it, to decode it.

 

Also… I routinely run my system with bins/pixel set to 2.  With the low end set 
to 200 Hz, it shows me everything up to 2600 Hz.  That is almost always 
sufficient.  Don’t see any advantage to asking for a default setting greater 
than that.

Russ K2TXB

 

From: Black Michael via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Wednesday, April 5, 2023 12:47 PM
To: k2txb--- via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Black Michael mailto:mdblac...@yahoo.com> >
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

 

Not true -- you only decode what's in the waterfall.

 

Mike W9MDB

 

 

On Wednesday, April 5, 2023 at 11:41:35 AM CDT, k2txb--- via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Dwane, I am almost certain that your assumption in incorrect.  For WSJT in 
general, it does not matter what the settings for the waterfall display are set 
to.  They have nothing to do with decoding, they provide only visual signal 
recognition.  So, if there is a decodable signal above the 1500 Hz it will 
still decode.  It is much more important to make sure his receiver bandwidth is 
wide enough to pass the signal at that frequency.

73, Russ K2TXB

-Original Message-
From: Dwayne Sinclair via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Wednesday, April 5, 2023 11:35 AM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Dwayne Sinclair mailto:dwayne_sincl...@me.com> >
Subject: [wsjt-devel] Truncated Waterfall Display "Feature"

Last night, I met an operator who was struggling with EME on 23CM after 
abandoning EME on the 70CM band. As soon as he started up WSJT-X, I noted his 
waterfall display was set to Bins/Pixel 2 instead of 5/6 and less than 1500Hz 
was displayed on the screen. All decodes 1500Hz and up were not decoded. I am 
pretty sure this was the cause of his issues on 70CM together with his current 
issues on 23CM 

Re: [wsjt-devel] Truncated Waterfall Display "Feature"

[Reino Talarmo via wsjt-devel]

Hi Russ,

You seems to hit the nail. I did not checked modes JT65 and Q65 and those use a 
frequency tolerance in User Guide 10.4. Center:

*For modes lacking a multi-decode feature, or when Enable 
VHF/UHF/Microwave features has been checked on the File → Settings → General 
tab, the F Tol control sets a frequency tolerance range over which decoding is 
attempted, centered on the Rx frequency.

It does not mention the waterfall at all, hi!

73, Reino OH3mA

 

From: k2txb--- via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 5. huhtikuutata 2023 21:46
To: 'Black Michael' ; 'WSJT software development' 

Cc: k2...@comcast.net
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

 

Sorry folks, I agree it would seem that way.  But only because there is no way 
to set the decoding window if you cannot see it.  I did not think of that, when 
I dashed off that message this morning.  And actually, if you set the decoding 
window large enough, I still think it would decode signals outside the 
waterfall range.   For example, I set the range to 1000, and center frequency 
to 1400 Hz.  That will now decode anything from 400 to 2400 Hz.

 

I still do not believe you need to be able to see it, to decode it.

 

Also… I routinely run my system with bins/pixel set to 2.  With the low end set 
to 200 Hz, it shows me everything up to 2600 Hz.  That is almost always 
sufficient.  Don’t see any advantage to asking for a default setting greater 
than that.

Russ K2TXB

 

From: Black Michael via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Wednesday, April 5, 2023 12:47 PM
To: k2txb--- via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Black Michael mailto:mdblac...@yahoo.com> >
Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"

 

Not true -- you only decode what's in the waterfall.

 

Mike W9MDB

 

 

On Wednesday, April 5, 2023 at 11:41:35 AM CDT, k2txb--- via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote: 

 

 

Dwane, I am almost certain that your assumption in incorrect.  For WSJT in 
general, it does not matter what the settings for the waterfall display are set 
to.  They have nothing to do with decoding, they provide only visual signal 
recognition.  So, if there is a decodable signal above the 1500 Hz it will 
still decode.  It is much more important to make sure his receiver bandwidth is 
wide enough to pass the signal at that frequency.

73, Russ K2TXB

-Original Message-
From: Dwayne Sinclair via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Wednesday, April 5, 2023 11:35 AM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Dwayne Sinclair mailto:dwayne_sincl...@me.com> >
Subject: [wsjt-devel] Truncated Waterfall Display "Feature"

Last night, I met an operator who was struggling with EME on 23CM after 
abandoning EME on the 70CM band. As soon as he started up WSJT-X, I noted his 
waterfall display was set to Bins/Pixel 2 instead of 5/6 and less than 1500Hz 
was displayed on the screen. All decodes 1500Hz and up were not decoded. I am 
pretty sure this was the cause of his issues on 70CM together with his current 
issues on 23CM and the “lack of decodes” as he complained. 

I have to ask - Can we fix this so that irrespective of what the Waterfall 
window displays, decodes will still occur for the full 3KHz or whatever value 
is specified in advanced options.

73 Dwayne AB6A 

___
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] Truncated Waterfall Display "Feature"

[Reino Talarmo via wsjt-devel]

Perhaps also reading User Guide 6.2. Wide Graph Settings should help:

'It is important to set appropriate lower and upper audio frequency limits for 
the Wide Graph because these limits define the FT8 decoder’s search window.'

73, Reino OH3mA

> -Original Message-
> From: Dwayne Sinclair via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: 5. huhtikuutata 2023 19:59
> To: WSJT software development 
> Cc: Dwayne Sinclair 
> Subject: Re: [wsjt-devel] Truncated Waterfall Display "Feature"
> 
> Go ahead and test for yourself - Change bin/pixel to 1 displaying say only
> the first 600Hz and see what your decodes look like.
> 
> 73 Dwayne AB6A
> 
> > On Apr 5, 2023, at 9:37 AM, k2txb--- via wsjt-devel  de...@lists.sourceforge.net> wrote:
> >
> > Dwane, I am almost certain that your assumption in incorrect.  For WSJT
> in general, it does not matter what the settings for the waterfall display
> are set to.  They have nothing to do with decoding, they provide only
> visual signal recognition.  So, if there is a decodable signal above the 1500
> Hz it will still decode.  It is much more important to make sure his receiver
> bandwidth is wide enough to pass the signal at that frequency.
> >
> > 73, Russ K2TXB
> >
> > -Original Message-
> > From: Dwayne Sinclair via wsjt-devel 
> > Sent: Wednesday, April 5, 2023 11:35 AM
> > To: WSJT software development 
> > Cc: Dwayne Sinclair 
> > Subject: [wsjt-devel] Truncated Waterfall Display "Feature"
> >
> > Last night, I met an operator who was struggling with EME on 23CM after
> abandoning EME on the 70CM band. As soon as he started up WSJT-X, I
> noted his waterfall display was set to Bins/Pixel 2 instead of 5/6 and less
> than 1500Hz was displayed on the screen. All decodes 1500Hz and up
> were not decoded. I am pretty sure this was the cause of his issues on
> 70CM together with his current issues on 23CM and the “lack of decodes”
> as he complained.
> >
> > I have to ask - Can we fix this so that irrespective of what the Waterfall
> window displays, decodes will still occur for the full 3KHz or whatever
> value is specified in advanced options.
> >
> > 73 Dwayne AB6A
> >
> > ___
> > 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] Enhancement Recommendation

[Reino Talarmo via wsjt-devel]

Hi All,

 

What Dave is proposing needs only WSJT-X no other logging program. BUT to make 
it work he needs to start WSJT-X from zero as the new grid information is based 
on the used wsjtx_log.adi file. It mean he needs to rename the wsjtx_log.adi 
file to something else e.g. wsjtx_log_230329.adi. After re-starting WSJT-X 
there are no stations worked before. If the only interested item is new grid, 
then in Colors only that it selected, perhaps per band and mode depending on 
the special event.

 

So you’ll have a nice tool for the special event. A new wsjtx_log.adi file will 
be generated at the first contest QSO logging. (I don’t know whether the new 
grid information works also for the VHF EU contest using six character grids.)

 

After the contest you may need to do some cleaning or data arrangements 
depending what you want to see after the special event in normal FT8/FT4 
working. You may just rename the new wsjtx_log.adi to e.g 
wsjtx_log_contest_XYZ_2023.adi and forget which stations and grids your worked 
in the special event or you just copy the new wsjtx_log.adi into your renamed 
wsjtx_log.adi file without the new header line or lines and rename it into 
wsjtx-log.adi (or other way round as then no need for renaming). You need also 
reset the Colors into your normal preferences. After restarting or Rescanning 
in the Colors window you are ready to continue normal working. 

 

Well, you may also use a different –rig name instead of renaming the 
wsjtx_log.adi file, see FAQ. Also a different Configuration helps in the 
contest frequencies and Colors settings.

 

I have used that method in my contesting, but I am not a eager contester or 
special event participant.

 

Well, all that can be done by an external contest soft such as N1MM with much 
less hassle, when you have learned how to. Only issue is whether the actual 
wish “new grid” automatic calling can be implemented in those logging programs 
so that the existing grid information in the wsjtx_log.adi file is not 
disturbing. Or have I missed something?

 

73, Reino OH3mA

 

From: dave--- via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: 29. maaliskuutata 2023 4:08
To: 'WSJT software development' 
Cc: d...@buckwalter.co
Subject: Re: [wsjt-devel] Enhancement Recommendation

 

Yes,  during specific events.  Since WSJT color codes already indicate if a 
received CQ is a new grid or not, I thought having the auto answer on CQ would 
be helpful.  If I’m calling CQ and have WSJT set in Auto response and several 
stations respond,  instead of having WSJT respond to the ‘First’ call, have it 
respond to the first call that is a new grid as priority over any other 
responses.

 

 

Dave Buckwalter

 

From: John Kludt via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Tuesday, March 28, 2023 1:42 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: John Kludt mailto:johnnykl...@gmail.com> >
Subject: Re: [wsjt-devel] Enhancement Recommendation

 

Dave,

 

And just what exactly would be the source of data for grids worked?  I 
frequently work grids via modes other than those in the WSJT-X suite.   Or are 
you proposing that this would apply to only those grids worked within the 
WSJT-X family of programs during a specific event?  When contesting I use 
WSJT-X within N1MMLogger+ and that takes care of dupe checking.

 

Help me better understand for what you are asking.

 

John K7SYS 

 

On Tue, Mar 28, 2023 at 6:46 AM dave--- via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

 

Here's a recommendation for an upgrade: 

 

Since the 2.6.0 release you've had the option for CQ response to be 'None', 
'First' and 'Max Dist'. How about adding the option to auto respond to 'First 
New Grid'. 

This will help when the band is busy and there are multiple responses to your 
CQ. Especially during VHF/UHF contesting, where Grids are multipliers and any 
new Grid could have significant impact on your final score.

 

Dave Buckwalter

K3SK

FM07 Farmville VA 

434-309-1109 (H)

540-270- (C)

 

___
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] Minor nit in sourceforge main WSJT-X page

[Reino Talarmo via wsjt-devel]

> From: Glenn Williams via wsjt-devel
[mailto:wsjt-devel@lists.sourceforge.net]
> 
> To quote:
> 
> "Versions of WSJT-X labeled with a "-rcx" suffix, for example WSJT-X
v2.2.0-rc6,
> are Release..."
> 
> While v2.2.0 is an example, you could update that to
> 
> "Versions of WSJT-X labeled with a "-rcx" suffix, for example WSJT-X
v2.#.#-rc6,
> are Release..."

Just to clear about, which version should be used. Currently *all* versions
with the "'-rcx" suffix are outdated and most of those would not work at all
due to passing the "Use before" date.

73, Reino OH3mA



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

Re: [wsjt-devel] Custom frequencies lost after upgrade from 2.5.4 to 2.6.1

[Reino Talarmo via wsjt-devel]

>From: false via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
>Before the upgrade, I renamed the old version (2.5.4) and when I open it, the 
>custom frequencies are present. Is there any way to add them to 2.6.1 other 
>than manually? 

Hi Bill,
In version 2.5.4 go to Frequencies tab and right-click on the table. A menu 
will be presented and select Save As ... 
Give a suitable name for the file. In version 2.6.1 you select in that menu 
Load ...
73, Reino OH3mA



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

Re: [wsjt-devel] 3Y0J strange F/H operation

[Reino Talarmo via wsjt-devel]

> “ We had issues  with the FT8 due to we did not have any device to sync 
> against, and our clock was 14 seconds off - which meant we at some time were 
> TX odd, while we thought it was even.”

>Well a simple GPS device connected to one of their notebooks would have 
>prevented the problem above.

>So my questions to the developers are:

a)  Is it really possible that lack of sync would lead them to TX in ODD 
periods as FOX ?

b)  How come QSY below 1000 HZ was not necessary for the Hound to finalize 
the QSO with them?

Hi Fred,
I am using only general information about these issues.
a) If the PC cock is really off by 14 s, then simply odd and even sequences are 
crossed. No possibility to see that within wsjt-x.
b) The QSy below 1000 Hz is only improving possibility to have less QRM, but 
the program itself does not care where you are sending your messages. 

73, Reino OH3mA

 

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

Re: [wsjt-devel] Who was I working with???

[Reino Talarmo via wsjt-devel]

> From: Saku via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: 13. helmikuutata 2023 14:57
> The callsign of AJ4YX varied as <...>, ,  and  in
> ALL.TXT and screen.

Hi Saku,
Actually in the ALL.txt file the progress was: 
- <...> any unknown hash, but most probably J8/AJ4YX, you have not yet received 
that callsign in clear
-  probably , but you may have had the UB2FCL in your has table 
for some reason and there is a hash collision
-  you never received that one, I mean your program never printed that 
-  that was added into your hash table at 120015 as YO6EPW sent it.

So I assume that you worked F8/AJ4YK

> And in addition ALL.TXT says that I was receiving on 28.026MHz and
> Transmitting on 28.091MHz 

I am totally lost on that as e.g. your wsjt-x indicates 28.082 (perhaphs Rx) 
and there is Split used.

73, Reino OH3mA



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

Re: [wsjt-devel] Hashed callsign collisions?

[Reino Talarmo via wsjt-devel]

Hi Jon and Paul,
I repeated the situation using my audio link, but could not repeat the 
misbehavior

from V2.5.4 to V2.6.1 or other way round. 
The slashed callsign is hashed completely so that cannot be the reason either.
I still stand my opinion that it is an operator action, hi!
73, Reino OH3mA

PS. I had only two stations in that test, but both recognized the callsigns 
W1WW/0 and W1WW/7 as hash values. 

Reino

 

From: Jon Anhold via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 21. tammikuutata 2023 1:26
To: WSJT software development 
Cc: Jon Anhold 
Subject: Re: [wsjt-devel] Hashed callsign collisions?

 

I guess it isn't shown in that screenshot, but after I worked W1AW/0 (when I 
was calling W1AW/7), W1AW/0 called CQ, I called W1AW/7 again and W1AW/0 
answered me, and I suspect it was the software answering thinking I was calling 
0.

 

On Fri, Jan 20, 2023 at 6:23 PM Jon Anhold mailto:j...@anhold.com> > wrote:

I'm pretty sure, although I can't know for certain, that W1AW/0's WSJT-X auto 
seq answered me after his CQ when I was calling W1AW/7.

 

On Fri, Jan 20, 2023 at 4:42 PM Reino Talarmo via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

Hi Jon,

I don’t see any hash collision in those messages. You should ask what W1WW/0 
did? Perhaps operator was waiting a “73” from your, but you sent one to W1WW/3 
and W1WW/0 decided to send you a new report. I don’t know whether that station 
received your message at 205445 as you changed it to W1WW/7 at 205448. Could be 
possible! In any case both station sent to you “RR73”.
73, Reino OH3mA

 

From: Jon Anhold via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net 
<mailto:wsjt-devel@lists.sourceforge.net> ] 
Sent: 20. tammikuutata 2023 22:56
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Cc: Jon Anhold mailto:j...@anhold.com> >
Subject: [wsjt-devel] Hashed callsign collisions?

 

I was just on 20m trying to work W1AW/7, and W1AW/0 answered me, twice - is 
this a known issue with longer/hashed callsigns?

 



 

73 de KM8V Jon

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto: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] Hashed callsign collisions?

[Reino Talarmo via wsjt-devel]

Hi Jon,

I don’t see any hash collision in those messages. You should ask what W1WW/0 
did? Perhaps operator was waiting a “73” from your, but you sent one to W1WW/3 
and W1WW/0 decided to send you a new report. I don’t know whether that station 
received your message at 205445 as you changed it to W1WW/7 at 205448. Could be 
possible! In any case both station sent to you “RR73”.
73, Reino OH3mA

 

From: Jon Anhold via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 20. tammikuutata 2023 22:56
To: WSJT software development 
Cc: Jon Anhold 
Subject: [wsjt-devel] Hashed callsign collisions?

 

I was just on 20m trying to work W1AW/7, and W1AW/0 answered me, twice - is 
this a known issue with longer/hashed callsigns?

 



 

73 de KM8V Jon

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

Re: [wsjt-devel] Request from WSPRNet Devs

[Reino Talarmo via wsjt-devel]

Hi Gary,

 

My information is limited to the Release notes and it seems that the “15” is 
used in the GA version 2.6.0. See https://wsjt.sourceforge.io/Release_Notes.txt

 

73, Reino OH3mA

 

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

Re: [wsjt-devel] Unable to find how to reset Q65A default Tx duration (defaults to 30 sec and my operating requires 60 seconds)

[Reino Talarmo via wsjt-devel]

Hi Dave,

 

Joe sent this mail on the [WSJTX] list

73, Reino OH3mA

 

Joe’s mail:

 

Sorry about the missing T/R period control in WSJT-X 2.6.0.  This was 
completely unintentional; the problem had been recognized and corrected, but 
the corrected code was inadvertently not moved into the master code branch.  A 
bug-fix release will be made very soon.

 

In the meantime, a simple workaround is to open the file WSJT-X.ini with a text 
editor (such as Notepad) search for any lines that contain "TRPeriod_Q65", and 
change the number to whatever you need.  For example, for one-minute T/R 
sequences you will want the line

 

  TRPeriod_Q65=60

 

You may find more than one instance of TRPeriod_Q65.  Change them all!

 

File WSJT-X.ini is in the Log directory, which can be accessed directly from 
the WSJT-X File menu.

 

-- 73, Joe, K1JT

 

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

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

[Reino Talarmo via wsjt-devel]

Hi Al,
The new User Guide advices in 20.2. Bug Reports:
One of your responsibilities as a WSJT-X user is to help the volunteer
programmers to make the program better. Bugs may be reported to the WSJTX
forum on Groups.io Post Message or the WSJT Developers list
(wsjt-devel@lists.sourceforge.net).

73, Reino OH3mA

-Original Message-
From: Al via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 6. tammikuutata 2023 22:59
To: WSJT software development 
Cc: Al 
Subject: [wsjt-devel] Fwd: WSJT-X 2.6.0 GA Release


 From the 2.6.0 GA announcement .

"Bugs should be reported by following instructions found here in the User
Guide:
>
>
https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.4.ht
ml#_bug_reports"

is this still correct ?

AL, K0VM



___
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-devel] v2.6.0-rc5 User Guide website

[Reino Talarmo via wsjt-devel]

>But this does not solve the problem in the cases of:

>1) I'm not on that computer or even in the shack, or maybe I am in a
meeting or someplace where suddenly I need to obtain the User Guide. I can
get to the website but I can't get to the shack computer.

>2) Similarly I am on my smartphone where I can't install WSJT-X just to
obtain a copy of the User Guide.

>So I need to plan ahead and obtain the User Guide by some means and then
store that copy somewhere where I can always get to it on my terms?

>The User Guide in PDF form does not take up that much disk space on your
approved servers.  So just leave one there.

Glenn,

I see your problem. Unfortunately I don't have PDF-version readily
available, but at
https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.0-rc5/wsjtx-main-2.6.0
-rc5.html/download
you will get html version that provides all search possibilities. It is the
same as available normally at the Princeton site or in the installation
package.

73, Reino OH3mA




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

Re: [wsjt-devel] v2.6.0-rc5 User Guide website

[Reino Talarmo via wsjt-devel]

>Where are the user guides of any version like V2.5.x or above?
Hi Glenn,
If you have downloaded version 2.6.0-rc5, then
C:\WSJT\wsjtx2.6.0_rc5\share\doc\wsjtx. Or ... \
wsjtx2.6.0_rc5\share\doc\wsjtx, if you have installed wsjt-x somewhere else.
The User Guide is wsjtx-main-2.6.0-rc5.html. The same applies to older
versions as well.
73, Reino OH3mA





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

Re: [wsjt-devel] Power Slice Bar

[Reino Talarmo via wsjt-devel]

Hi Marty,

It a known "feature" of the Qt that provides code for MacOS and others. It will 
be corrected in the next general version. I assume that it is already corrected 
in 2.6.0-rc's. 

73, Reino OH3mA

-Original Message-
From: Marty Wayne via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 30. joulukuutata 2022 21:18
To: WSJT software development 
Cc: Marty Wayne 
Subject: [wsjt-devel] Power Slice Bar

Equipment
   FT-1000MP
   SignaLink USB
   MacBook Pro
   Ventura 13.1WSJT-X v2.5.4
Issue
   When adjusting power using the PWR slide bar, The curser arrow moves 
opposite direction from direction I’m  moving my mouse.  The curser remains at 
lower end of scale although the power set inmates correctly.

Do I have something configured incorrectly?

73,

Marty, W6NEV
_ . .   .   . _ _   _ . . . .   _ .   .   . . . _
mcway...@comcast.net
408-234-8023



___
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] v2.6.0-rc5 F/H Issue

[Reino Talarmo via wsjt-devel]

Dennis,

Yes, that's correct. Only messages hound receives especially Tx3 i.e. "OH3MA 
ZL9FOX -20" (that is just a normal message) initiates frequency moves. 

If you mean by R-report e.g. R-15, then that station was *not* a fox at all. 
The only messages fox can send are Tx6 i.e. CQ, Tx3 i.e. a report -13 and TX5 
either RR73 or combined RR73 plus a report to another station. You may study 
https://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf for further 
details.

There is a derivate program that uses the combined "RR73; NE6I  -2" 
type messages and multiple carriers. That program can even be used on standard 
frequencies and on both timeslots although not recommended. Hound protocol has 
a lot of problems with it. Stations using it should be worked using normal FT8 
mode.

If that is the case and the R-report means what I said above, then on the 
reception of an R-report e.g. R-5 you should have sent RR73 or RRR, hi.

73, Reino OH3mA

- Original message -
Thanks, Reino,

Are the moves by the hound all initiated at the hound end based on what it 
receives from the fox? In other words, the fox does not "tell" the hound to 
move below 1000 Hz, correct? 

All.txt is showing the fox responding with R-report for a couple of sequences 
but does not show me responding with a report for some reason, though I 
definitely did. This happened on two attempts to work him. Very strange. On the 
third attempt to work him, it does show the proper exchange, namely fox sending 
R-report, me sending R-report and then the fox sending RR73.

--Dennis NE6I

-----Original Message-
From: Reino Talarmo via wsjt-devel  
Sent: Wednesday, December 7, 2022 9:26 PM
To: 'WSJT software development' 
Cc: Reino Talarmo 
Subject: Re: [wsjt-devel] v2.6.0-rc5 F/H Issue

>The third time this happened, the fox did respond to me with RR73 but I wonder 
>what happened there? It still didn’t move me below 1,000 so I moved myself 
>down. At that point, the fox moved me to where they wanted me (681). 

Hi Dennis,

I don't know what actually happened, but the frequency movements are controlled 
at the hound station based on the received message sequence. Fox has no 
capability to move hounds as there is no frequency control in any of the 
message fox is sending.
Hound should move to fox frequency for sending the R+rpt after receiving report 
from fox. If the hound needs to repeat R+rpt, then it would by its own move 
either 300 Hz up or down. So the first movement is initiated by reception of 
the report from fox. 

By the way the frequency movements as such are not mandatory for the F/H QSO as 
such. They only provide a higher probability for less QRM. Well there are still 
stations that call fox on the fox frequency and cause the QRM! In addition Fox 
will not answer to those stations by design!

A careful study of the ALL.txt record may help to understand what happened.

73, Reino OH3mA







___
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] v2.6.0-rc5 F/H Issue

[Reino Talarmo via wsjt-devel]

>The third time this happened, the fox did respond to me with RR73 but I wonder 
>what happened there? It still didn’t move me below 1,000 so I moved myself 
>down. At that point, the fox moved me to where they wanted me (681). 

Hi Dennis,

I don't know what actually happened, but the frequency movements are controlled 
at the hound station based on the received message sequence. Fox has no 
capability to move hounds as there is no frequency control in any of the 
message fox is sending.
Hound should move to fox frequency for sending the R+rpt after receiving report 
from fox. If the hound needs to repeat R+rpt, then it would by its own move 
either 300 Hz up or down. So the first movement is initiated by reception of 
the report from fox. 

By the way the frequency movements as such are not mandatory for the F/H QSO as 
such. They only provide a higher probability for less QRM. Well there are still 
stations that call fox on the fox frequency and cause the QRM! In addition Fox 
will not answer to those stations by design!

A careful study of the ALL.txt record may help to understand what happened.

73, Reino OH3mA







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

Re: [wsjt-devel] WSJT-X v2.6.0-rcr5 Hound frequency - k3wyc

[Reino Talarmo via wsjt-devel]

>If Hound is then deselected the Fox/Hound frequencies remain in the
frequency selector.

 

Hi Andy,

 

Have you read the related Release notes:

When in Hound mode and click the "H" button again, the frequency 

   is now kept. This gives the user the following two options to return 

   to normal FT8 mode:

- Click the "H" button again. Then you will stay on the QRG.

- Click the "FT8" button (or use the Settings menu). It brings  

  you back to the default FT8 QRG.

 

That may be a part of your experience.

 

73, Reino OH3mA

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

Re: [wsjt-devel] 2.6.0-rc5 "Start new period at top" anomaly

[Reino Talarmo via wsjt-devel]

Hi Rich,

 

This is a long known problem and no solution in the program found. You may 
erase the band activity window at regular intervals and it continues fine or 
restore operation. You may erase both displays with the Erase button or click 
in the Band activity window and select Erase from the drop down list.

 

73, Reino OH3mA

 

From: Richard V Zwirko via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 1. joulukuutata 2022 18:52
To: WSJT-X Development Group 
Cc: Richard V Zwirko 
Subject: [wsjt-devel] 2.6.0-rc5 "Start new period at top" anomaly

 

Using the new WSJT-X Version 2.6.0-rc5, with the Settings, General tab, "Start 
new period decodes at top" checkbox checked, as expected, the display of 
decoded FT8 spots started fine. Each decoding cycle displayed properly from the 
top down. However, within an hour, the top-down display of spots stopped. When 
I scrolled back, the spots from the just decoded cycle were there.  I unchecked 
the "Start new period decodes at top" checkbox and then checked OK. After a few 
decode periods with decodes being appended to the bottom of the last decodes, I 
rechecked the checkbox, but as soon as the next decode cycle was decoded, no 
spots were displayed. Again, the decodes could be seen by scrolling back the 
Activity column data. The only way to get WSJT-X to display decodes again from 
the top down was to restart 2.6.0-rc5.  

 

After about another hour of displaying properly, as I started to compose this 
report, the top-down non-display problem developed again. Only a restart of 
2.6.0-rc5 would get the "Start new decodes at the top" working again.

 

73,

Rich - K1HTV

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

Re: [wsjt-devel] v2.6.0-rc4 observations

[Reino Talarmo via wsjt-devel]

Dave

 

That was not a real Fox at all. You should have used normal FT8 mode. Hound 
will never send RRR or RR73 to fox in the real F/H protocol.

Somebody sending multiple carriers on a standard frequency really indicates 
that operator is not using Fox, but a derivate that can send multiple carriers 
and no F/H protocol is valid. 

 

73, Reino OH3mA

 

From: Dennis W1UE via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 28. marraskuutata 2022 16:06
To: WSJT software development 
Cc: Dennis W1UE 
Subject: Re: [wsjt-devel] v2.6.0-rc4 observations

 

Dave

 

I’ve operated a lot as the Fox from HQ9X the past week.  Let me assure you, if 
u try to operate as the Fox on one of the standard frequencies, you get a 
warning box and PTT won’t energize, ie wSJT won’t xmit.

 

Dennis HQ9X for one more day!

 

On Mon, Nov 28, 2022 at 08:02 Dave Bernheisel via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

I have noticed that if the Hound mode is enabled and on a frequency that is not 
in the list of frequencies,

switching from Hound mode to FT8 also changes the frequency to one of the 
frequencies in the dropdown list.

 

A fox was operating in F/H mode on one of the default frequencies, and I 
changed to Hound mode.  A station, not the Fox,

called me. I responded to the call and then discovered that both RRR and RR73 
were disabled.  I did not find this in the users guide for

F/H operation.  I realize that the Fox was not following the rules.  Since the 
usual frequencies are in the dropdown, perhaps

WSJT-X should prohibit or nag the Fox when operating on one of the known 
frequencies for normal operation.  A warning to the hound 

would not be a bad idea, in my opinion.

73,

Dave Bernheisel, N2DPF

___
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] RC4 crashes

[Reino Talarmo via wsjt-devel]

>Maybe just co-incidence but I have had two crashes now where the last entry in 
>the ...ALL.TXT file was a station with compound call that was answering my CQ.

221123_18124521.074 Rx FT8-12  0.2 1386  KB1EFS/2



Hi AL, 

Could this be the same issue Mike stated: ‘Referring to "Max Dist" in tab 2 and 
the "Call 1st" on the main window.  Those two would cause a crash if receiving 
a TX1 message without a grid.’ 

Which setting you had? It’s in the menu box normally ‘CQ: None’.

 

73, Reino OH3mA

 





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

Re: [wsjt-devel] fail to download

[Reino Talarmo via wsjt-devel]

Hi Cris,

By the way do you have a reason not to download version 2.5.4? The 2.1.0 is 
quite old version and you will miss some features. Or you may have an error in 
the file name.

73, Reino OH3mA

 

From: Larry Banks via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 14. marraskuutata 2022 21:43
To: hansenc--- via wsjt-devel 
Cc: Larry Banks 
Subject: Re: [wsjt-devel] fail to download

 

It's a false positive. Turn off you spam-blocker temporarily or better, add it 
to your allowed list.

73 -- Larry -- W1DYJ




On 11/14/2022 14:29, hansenc--- via wsjt-devel wrote:

I tried to download wsjtx-2.1.0-win64.exe and I got a message that it
can't be downloaded securely.  How do I download the program so I can run
FT8 and other digital programs?
 
Chris
 
 
 
___
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] Fox sends "DUPE" instead of "+rpt" in DX pedition mode

[Reino Talarmo via wsjt-devel]

Hi Take san,

It's not you English, but a protocol challenge.

The reason for not receiving the RR73 from a fox depends on the S/N at the
hound station and the detection probability of various messages. The S/N
depends on the propagation, but also strongly on the number of carriers fox
is using. Quite often fox uses more carriers, when it responses to users
meaning less S/N per carrier. Another issue is decoding probability of the
message such as K1ABC RR73; W9XYZ -08 is a bit less than normal RR73 or
R+rpt messages to a single user, when the hound uses AP decoding. 

Now your proposal is to change the +rpt to a Hound to DUPE in the case the
hound has started a new QSO attempt after some time, not because fox
receives repeated R+rpt from the Hound. At least I understood it that way.
So on the protocol point of view fox uses one timeslot less resources than
is normal QSO, if the Hound receives the DUPE message. BUT even that DUPE
message is a lost timeslot as the QSO is already in the log. The detection
probability of the DUPE message would be the same as for R+rpt or RR73
messages. So how many times the fox should repeat it to make the Hound
happy? On the fox point of view that Hound is not a problem as long as it
can decode other new stations. 

There is another possibility for fox to send the RR73 using less carriers or
even a RR73 to that Hound without combining it with a report to some other
station (again a lost message option). That method could be more effective
due to better S/N and detection probability. I just doubt whether a DX
station would apply either it or your proposal as long as he is completing
new QSOs at "full" speed, hi!

73, Reino OH3mA




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

Re: [wsjt-devel] Request for additional new logging option

[Reino Talarmo via wsjt-devel]

>LOTW now has the option of automatically recording your grid squares from
your log as you travel across the country. This is great, but it doesn't
provide information about what state or county the contact was made from. If
WSJT-X had the option to also log your latitude and longitude in addition to
the grid square you were activating, all that information would be available
to people.

Hi Lance
Which location accuracy is needed? WSJT-X logs the Grid square and it can be
up to six characters, which is about 3 x 3 miles rectangle depending on the
latitude. The Grid square can be easily converted into a longitude/latitude
presentation as you know.

73, Reino OH3mA



___
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-rc4: Sudden shut-down, "CQ: Max Dist" doesn't work, "CQ: None" stops working

[Reino Talarmo via wsjt-devel]

>Frode, I don't know what it means. I read that text hastly, so, apologize.
I stop allways there, where is something mentioned "contest".
Not my thing... :)
We wait now time, when manual is written..

Hi Jarmo, Frode,

The draft User Guide for 2.6.0 states simply:
"When calling CQ you may choose to select CQ: First to reply automatically
to the first decoded responder, or CQ: Max Dist to reply to the most distant
responder."
There is no limitation to only contests. 
It is not defined in that text for CQ: Max Dist, whether the decision is
made after the first decoding round or after the last decoding attempt. If
the latter, then in a slow computer that may happen after the start of the
next transmission time.

73, Reino OH3mA

 



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

Re: [wsjt-devel] Possible RC4 issue

[Reino Talarmo via wsjt-devel]

>Sorry, I forgot to respond to this.  I was only doing the mode change with
the new mode buttons, not the mode drop down.

Hi Gary and All,
So this could be related somehow to the mode change using the new buttons as
you may have not had the same issue using the menu selection. In any case it
may be difficult to catch without a recipe how to repeat it.
73, Reino OH3mA



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

Re: [wsjt-devel] Possible RC4 issue

[Reino Talarmo via wsjt-devel]

Hi Gary,

>I was on 17M FT8, made a few contacts with no problem.  After the last one 
>logged, I hit the FT4 button and jumped up the band as I frequently do when 
>things are busy.  I worked one station on FT8 and logged it.  After it logged, 
>the program simply closed itself - gone.

This may be irrelevant, but how you returned from FT4 to FT8 to work the single 
station? 

>When I tried to restart WSJT-X, it failed, giving me the following error:
Sub Process Error
Failed to close orphaned jt9 process

The failure reason is solely due to the orphaned jt9 (jt8.exe) process that is 
the main engine for decoding within wsjt-x, I think. You could have also kill 
the process (jt8.exe) using Windows Task Manager. Normally that is enough and 
no need to reboot the total system.

73, Reino OH3mA




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

Re: [wsjt-devel] TX..RX with different radios

[Reino Talarmo via wsjt-devel]

>The problem with all this is that completing a QSO does not count for 
>anything. You cannot log to LOTW, QRZ, eQSL since split TX/RX is not 
>permitted. It makes sense for SSB/Net Control/adhoc QSO’s with friends but not 
>for WSJT-X since many of us using WSJT-X are using it for awards.

Hi Dwayne,

I could not see any statement in the QSO matching rules in the LoTW FAQ section 
'What constitutes a QSO "match?" ' about the rig requirements nor about 
frequencies used on a band. 
Actually could you explain what you mean by the "split TX/RX is not permitted", 
please? 

73, Reino OH3mA




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

Re: [wsjt-devel] disable PSKreporter functions unless CAT control is active.

[Reino Talarmo via wsjt-devel]

Hi,

Just a reminder, why there are so many false band spots. From the current 
candidate release notes rc1:

Correct a flaw that could send incorrect frequencies to ALL.TXT

   and PSK Reporter after a band change

 

That happens each time you change the band during monitoring. The previous band 
information is sent as the new band information, if you have not stopped 
monitoring before the band change.

Hopefully version 2.6.0 will came common once it is released. On the other hand 
there are a lot of operators using pre-2.5.4 version or derivate versions that 
may be corrected or not.

 

73, Reino OH3mA

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

Re: [wsjt-devel] RC2 syslog file

[Reino Talarmo via wsjt-devel]

Hi Mike,

Bill (sk) was not concern about short drops at all. He considered those normal.
I have had those all the time in my all WSJT-X installations since 1.9.1.
Now I should have enough data to study whether the drops really affect to 
decoding performance e.g. the number of decodes in each timeslot. It requires 
some programming and it is not my strong point, hi.

73, Reino OH3mA

-Original Message-
From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 23. heinäkuutata 2022 6:44
To: Dennis Younker NE6I via wsjt-devel 
Cc: Black Michael 
Subject: Re: [wsjt-devel] RC2 syslog file

That's a pretty consistent bunch of dropped audio samples.

As I asked another user have you tried raising the priority of WSJT-X to see if 
making it real-time improves things?

Mike W9MDB








On Friday, July 22, 2022 at 07:17:20 PM CDT, Dennis Younker NE6I via wsjt-devel 
 wrote: 





Here a few lines from mine. Win10 and running v2.6.0-rc2. Are you looking for 
something in particular? I seem to get these dropped audio source alerts quite 
a bit!

[SYSLOG][2022-07-22 03:26:29.383606][03:15:14.093551][warning] Detected dropped 
audio source samples: -624 (-0.013 S)
[SYSLOG][2022-07-22 03:27:14.400410][03:15:59.105372][warning] Detected dropped 
audio source samples: 672 (0.014 S)
[SYSLOG][2022-07-22 03:27:29.386450][03:16:14.090066][warning] Detected dropped 
audio source samples: -672 (-0.014 S)
[SYSLOG][2022-07-22 03:28:44.382611][03:17:29.078681][warning] Detected dropped 
audio source samples: -672 (-0.014 S)
[SYSLOG][2022-07-22 03:29:14.372757][03:17:59.065692][warning] Detected dropped 
audio source samples: -576 (-0.012 S)
[SYSLOG][2022-07-22 03:32:14.370149][03:20:59.037622][warning] Detected dropped 
audio source samples: -720 (-0.015 S)
[SYSLOG][2022-07-22 03:35:40.610055][03:24:25.255064][info] Log Finish
[SYSLOG][2022-07-23 00:05:48.112279][00:00:00.004030][info] Log Start
[SYSLOG][2022-07-23 00:05:48.113466][00:00:00.004078][info] WSJT-X  v2.6.0-rc2 
994e3f  by K1JT et al. - Program startup
[SYSLOG][2022-07-23 00:05:48.133505][00:00:00.024524][info] locale: language: 
English script: Latin country: United States ui-languages: en-US
[SYSLOG][2022-07-23 00:05:48.133505][00:00:00.024735][info] Loaded Qt 
translations for current locale from resources
[SYSLOG][2022-07-23 00:05:48.133505][00:00:00.024775][info] Loaded WSJT-X base 
translation file from :/Translations based on language en
[SYSLOG][2022-07-23 00:05:48.133505][00:00:00.024804][info] Loaded WSJT-X 
translations for current locale from resources
[SYSLOG][2022-07-23 00:05:48.483151][00:00:00.376284][info] shmem size: 48275456
[RIGCTRL][2022-07-23 00:05:48.498778][00:00:00.402651][info] Hamlib version: 
Hamlib 4.5~git Sat Jul 16 15:53:03 2022 + SHA=cc7c59
[SYSLOG][2022-07-23 00:06:14.365843][00:00:26.254674][warning] Detected dropped 
audio source samples: 6672 (0.139 S)
[SYSLOG][2022-07-23 00:08:59.396314][00:03:11.254302][warning] Detected dropped 
audio source samples: 960 (0.02 S)

--Dennis NE6I

-Original Message-
From: Black Michael via wsjt-devel  
Sent: Friday, July 22, 2022 8:38 AM
To: WSJT Software Development 
Cc: Black Michael 
Subject: [wsjt-devel] RC2 syslog file

I'd appreciate if users could check their wsjtx_syslog.log file.
For Windows users it will be in C:\Users\[username]\Appdata\WSJT-X
For Linux users /[username]/.local/share/WSJT-X

Should look like this and have one warning possibly about dropped audio.  If 
you see any other warnings please report them.  

[SYSLOG][2022-07-09 11:40:21.572105][00:00:00.000857][info] Read logging 
configuration file: C:/Users/mdbla/AppData/Local/WSJT-X/wsjtx_log_config.ini
[SYSLOG][2022-07-09 11:40:21.572105][00:00:00.000922][info] WSJT-X  v2.6.0-rc1 
6744bc - Program startup
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007037][info] locale: language: 
English script: Latin country: United States ui-languages: en-US
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007155][info] Loaded Qt 
translations for current locale from resources
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007183][info] Loaded WSJT-X base 
translation file from :/Translations based on language en
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007201][info] Loaded WSJT-X 
translations for current locale from resources
[SYSLOG][2022-07-09 11:40:21.686366][00:00:00.115734][info] shmem size: 48275456
[RIGCTRL][2022-07-09 11:40:21.702969][00:00:00.131819][info] Hamlib version: 
Hamlib 4.5~git Fri Jul 08 21:21:34 2022 + SHA=0ec962
[SYSLOG][2022-07-09 11:40:51.067872][00:00:29.488477][warning] Detected dropped 
audio source samples: -480 (-0.01 S)
[SYSLOG][2022-07-09 11:41:07.421339][00:00:45.836939][info] Log Finish

Mike W9MDB


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



___
wsjt-devel mailing list

Re: [wsjt-devel] Hamlib Error

[Reino Talarmo via wsjt-devel]

Hi Marty,

Lets start from beginning. How is your CAT communication signaling built in 
your system? Do you  have a USB to RS-232 converted cable or direct RS-232 to 
RS-232 cable between PC and your FT-1000MP?
To me it seems a simple loss of that connection for some reason. Even just the 
bit rate setting could be changed or COM port number.

73, Reino OH3mA

-Original Message-
From: Marty Wayne via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 23. heinäkuutata 2022 4:29
To: WSJT software development 
Cc: Marty Wayne 
Subject: Re: [wsjt-devel] Hamlib Error

I can’t even get the radio and wsjt-x to communicate.  I misspoke when I said 
that the Hamlib error happened while using FT8.  Actually, I had taken a short 
break.  I believe I shut down wsjt-x and restarted when I returned.  That is 
when aI started getting the Hamlib error.  I hadn’t changed the power as there 
was no communication. In checking the sound preferences, CODEC does not show up 
to select.

Does that mean anything?

Marty Wayne
mcway...@comcast.net
408-234-8023

> On Jul 22, 2022, at 5:56 AM, robert evans LAST_NAME via wsjt-devel 
>  wrote:
> 
> As a diagnostic.. 
> 
> While sending CQ for example..
> 
> Reduce the transmit power,
> by both audio and transmitter settings and see if the phenomenon goes 
> away at lower powers.
> 
> If with the output minimized the phenomenon persists then it is 
> probably not RFI related.
> 
> If you find a reduced output power that does not exhibit the 
> phenomenon, then it is probably RFI related. And, you have a clue as 
> how much shielding and isolation you might need.
> 
> Operating at the reduced power while introducing changes gives you 
> method of testing improvements.
> 
> BCNU DE N2LO~>
> 
>> On 07/22/2022 12:07 AM Black Michael via wsjt-devel 
>>  wrote:
>> 
>> 
>> If it runs at startup but fails during/after transmit than it is probably 
>> RFI.
>> 
>> Here are some potential solutions -- ordered by cost.
>> 
>> #1 Free - Move USB cables to another port -- some ports are more susceptible 
>> than others.
>> #2 Free -- Check your grounding system.  rod-outside-the-shack is a common 
>> problem when it's not bonded to the main house ground. 
>> http://www.k9yc.com/GroundingAndAudio.pdf
>> #3 Add some USB shield isolators (see my QRZ page).
>> #4 Good USB cables like this
>> https://www.amazon.ca/Tripp-U023-006-Device-Ferrite-Chokes/dp/B003MQ2
>> 9B2/ref=sr_1_5?crid=11YRNPWDVWGCU=usb+cable+with+choke=1
>> 658187349=usb+cable+with+choke%2Caps%2C139=8-5
>> #5 Maybe free (if you have chokes...otherwise can get a bit costly) -- add 
>> chokes to USB cables first, then all other cables including power, ethernet, 
>> and control cables. 
>> Fair-Rite torroids are good quality -- do NOT buy cheap Chinese ones --  
>> https://www.fair-rite.com/product/toroids-5943003801/  You can use clip-ons 
>> but torroids allow multiple wraps and give better results.
>> https://www.fair-rite.com/product/round-cable-snap-its-431176451/
>> I couldn't find type 31 torroids at Fair-Rite as of 20220721 but 
>> Palomar has some 
>> palomar-engineers.com/ferrite-products/ferrite-cores/ferrite-ring-tor
>> oid-combo-pack/
>> 
>> 
>> Mike W9MDB
>> 
>> 
>> 
>> 
>> On Thursday, July 21, 2022 at 12:29:33 PM CDT, Marty Wayne via wsjt-devel 
>>  wrote:
>> 
>> 
>> I was working 20 Meter FT-4 and at one point I got a Hamlib error, 
>> communication timed out.  See report below.  Im not computer savvy. What 
>> might be the issue? 
>> 
>> Rig-FT-1000MP
>> iOS 12.5
>> SignaLink USB interface
>> WSJTx 2.5.2
>> WSJTx 2.5.4
>> 
>> Hamlib error: Communication timed out
>> rig_get_vfo: returning -5(Communication timed out 
>> ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication 
>> timed out
>> read_block_generic(): Timed out 0.402040 seconds after 0 chars
>> ft1000mp_get_update_data: Timeout
>> ft1000mp_get_update_data: Timeoutft1000mp.c(1249):ft1000mp_get_vfo 
>> return(-5) Communication timed out
>> ft1000mp_get_update_data: Timeout
>> ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication 
>> timed out
>> read_block_generic(): Timed out 0.402040 seconds after 0 chars
>> ft1000mp_get_update_data: Timeout
>> ft1000mp_get_update_data: 
>> Timeoutft1000mp.c(1675):ft1000mp_get_update_data return(-5) 
>> Communication timed out
>> read_block_generic(): Timed out 0.402040 seconds after 0 chars
>> ft1000mp_get_update_data: Timeout
>> ft1000mp_get_update_data: Timeoutft1000mp.c(1249):ft1000mp_get_vfo 
>> return(-5) Communication timed out
>> ft1000mp_get_update_data: Timeout
>> ft1000mp.c(1675):ft1000mp_get_update_data return(-5) Communication 
>> timed out
>> read_block_generic(): Timed out 0.402040 seconds after 0 chars
>> ft1000mp_get_update_data: Timeout
>> ft1000mp_get_update_data: 
>> Timeoutft1000mp.c(1675):ft1000mp_get_update_data return(-5) 
>> Communication timed out
>> read_block_generic(): Timed out 0.402040 seconds after 0 chars
>> ft1000mp_get_update_data: Timeout
>> 

Re: [wsjt-devel] Hamlib Error

[Reino Talarmo via wsjt-devel]

Marty,

I have used a simple USB to RS-232 converter cable with my FT-1000MP for CAT
control. You have already Signalink for audio audio/PTT.

73, Reino OH3mA

-Original Message-

Marty,

In your list of equipment, I don't see a CAT interface. The Signalink is
only a sound card interface. There is no CAT interface. The error message
shows that WSJT-X was trying to access the FT-1000MP's CAT. To get around
this, In WSJT-X, go to Settings - Radio. Near the top, where it says "Rig:",
select "None". The you won't get the error message. Of course, you will have
to make certain that WSJT-X is set to the frequency that the rig is on. If
possible, I suggest getting a CAT interface - MicroHam, Rig Blaster, etc.

73,

Jim N6VH




___
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 rc1 feed back

[Reino Talarmo via wsjt-devel]

Luis,

That functionality surfaces the general problem of an “instant” mode change. 
Does the operator want to continue/start a new QSO on the current frequency or 
jump to the default/pre-defined frequency for the mode. Additional problem for 
the F/H operation is how the Fox frequency is actually set, when you want to go 
to operate a certain Fox, i.e. jump from a standard frequency to special Fox 
frequency (and later back to the previous standard frequency). There could be 
multiple DXoperation station active at the same time using different 
frequencies. 

 

The same is valid, if the “H” button is modified to cover all Special 
Operations. Perhaps the most useful manner would be just keep the current “VFO” 
or base frequency intact.

 

Of course there is always the Configurations menu available and full control 
what happens to any parameter. Only problem with the Configurations is the time 
it takes to make the change. I don’t mean the needed of two clicks, but the 
processing time that at least with my computers is too long for an “instant” 
mode change in contests.

 

73, Reino OH3mA

 

Subject: Re: [wsjt-devel] WSJT-X 2.6.0 rc1 feed back

 

 Hi, thank you folks for this very nice program.

I’m using the beta version and found it very stable and with nice features. 

The “hound” button is the most interesting for me and I want to share something 
that could be a bug ( or may be not).

If you are trying to work a “fox” station, on a frequency off the regular ft8 
fcy, and somebody insist in calling you, if you push the “hound” button to 
answer that call, the program jumps to answer in the standard ft8 fcy for that 
band. It looks to me that this is a non intentional bug and it would be better 
the program keeps the frequency and just send and spect to receive the standard 
messages in proper ft8 standard order . So this way changing mode would be 
seamless just pushing the button.

Hope this helps.

Congratulations and best wishes.

-- 

Luis F. Arango
HK4L

-- 

Luis F. Arango
HK4L

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

Re: [wsjt-devel] 222 MHz and Up Distance Contest Rules. First full weekend in August.

[Reino Talarmo via wsjt-devel]

That is supported in EU VHF contest. There is one difficulty with that as both 
operator need to use it before a call is really possible.

73, Reino OH3mA

 

From: robert evans LAST_NAME via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 20. heinäkuutata 2022 18:56
To: wsjt-devel@lists.sourceforge.net
Cc: robert evans LAST_NAME 
Subject: [wsjt-devel] 222 MHz and Up Distance Contest Rules. First full weekend 
in August.

 

Exchange: Send 6-character Maidenhead grid-square locator 

 

How to exchange 6 char grid?? 

 

Which mode would offer this? 

 

BCNU DE N2LO~> 

 

 

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