Date   

locked FW: [WSJTX] Settings for Yaesu FTdxx101MP

Chuck Schloss <cschloss@...>
 

Got it now.

 

73                           Chuck AG0W

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Chuck Schloss
Sent: Friday, June 05, 2020 1:21 PM
To: main@WSJTX.groups.io
Subject: [WSJTX] Settings for Yaesu FTdxx101MP

 

Does anyone have the radio settings page info for this rig.

Am using CAT control cable from radio to USB port Com 4 of Windows 10 laptop.

Had been  using FTDX5000 as radio setting with 9600 baud rate, worked OK, but gave “Hamlib” error if I tried 80m FT8.

So I’m happy to see FTDX101D now in Hamlib.

 

Thanks everyone,

 

Chuck AG0W


locked Re: Tnx for the FT991 fix but ...

neil_zampella <neilz@...>
 

There is no workaround.    The system used to create WSJT-X has dropped all XP and VISTA support.   

The fixes are:
1.  Upgrade to a newer WIndows, probably 10
2.  Replace the computer with something that can run newer versions of Windows (refurb Dells can be found for under $200)
3.  Replace Windows with a good Linux distribution.

Neil, KN3ILZ

On 6/6/2020 3:57 PM, John Kirby wrote:
... still so sad and disappointed

Is there any work around to make 2.2.x run on XP ?

John
N3AAZ

  

    

Virus-free. www.avg.com


locked Tnx for the FT991 fix but ...

John Kirby
 

... still so sad and disappointed

Is there any work around to make 2.2.x run on XP ?

John
N3AAZ

  


locked Re: New feature option for non-CQ New Call color highlighting

Richard Hattaway
 

May I also agree.... I use a pad or my phone for most of my QSOs.  I don't have the luxury of looking up a DX call to see if he is already in the log.  

Maybe I am missing a tool ( knowledge )  that would help, but until I sort that out, I am all in favor of color coding everything

Thanks
--
73
Dick

W4PID@...


locked Re: 20M congestion

Bob McGraw - K4TAX <rmcgraw@...>
 

I find that 14.071 along with 14.074 is in the frequency table for FT-8.  That gives almost 6 kHz useable bandwidth.  Yes, 14.074 is quite busy.  So guess we have to spread out a bit. 

73
Bob, K4TAX


locked Re: 20M congestion

Tony Collett
 

Just a suggestion, why not try other modes or even other bands?
Not suggesting legacy modes like SSB or CW (but when the sunspots return why not talk to people instead).

I actually mean try FT4. Often those frequencies are fairly quiet and you won't need the amplifier to burn a hole in the waterfall just to make yourself heard above all the QRM. I am more than impressed by how well FT4 mode works. The extra sensitivity of FT8 is unachievable when all the waterfall is full.

Claiming more frequencies just for more FT8 really needs organised band planning as few of us are aware of everything that is being used outside our own little island.

73
Tony
G4NBS 


locked Re: 20M congestion

Dave (NK7Z)
 

I see those were removed... Never mind! :)

73, and thanks,
Dave (NK7Z)
https://www.nk7z.net
ARRL Volunteer Examiner
ARRL Technical Specialist
ARRL Asst. Director, NW Division, Technical Resources

On 6/6/20 9:55 AM, Dave Cole wrote:
I believe there are frequencies now built into WSJT-X as backup for when they standards are full.
Just wait until the sunspots return...  all higher bands will be--
interesting, for lack of a better word.
73, and thanks,
Dave (NK7Z)
https://www.nk7z.net
ARRL Volunteer Examiner
ARRL Technical Specialist
ARRL Asst. Director, NW Division, Technical Resources
On 6/6/20 9:23 AM, Kermit Lehman via groups.io wrote:
Yes, there was a proposal to open another 3 kHz at 14,071 but this conflicts with other established modes, especially PSK..

I think it would be better to move up into the 3 kHz from 14.077 to 14.080 which belongs to JT65 and JT9 but is little used.  The existing band occupancy starts to thin out at 14.076.5 so that seems a logical jumping off point for shifting up..

Try moving your dial frequency one kHz to 14.075 and see how that goes. You'll gain another 1 kHz as well as still seeing most of the regular band.

It certainly is true that 20m, and often 40m, are frequently congested almost to the point of uselessness.

73,
Ken, AB1J


-----Original Message-----
From: Rory Bowers <k6cks01@...>
To: main@WSJTX.groups.io
Sent: Sat, Jun 6, 2020 4:07 pm
Subject: [WSJTX] 20M congestion

I try not to bother you very often Joe but over that last week or so 20M congestion has been so bad that it is hard to work a DX station without interfering with someone or being interfered with.  There is literally no vacant spots from 200 Hz to 3 kc.  Has there been any discussion about opening another frequency for FT8?
Thanks Joe... and I love the new 2.2!
73,
Rory, K5CKS



locked Re: ALL.TXT

Sam Birnbaum
 

Hi Bobby,

FYI, I was able to create a on groups IO.
There is a newer version of Alltext,.exe with some additional features there.
There is a mode filter and the ability to do SNR analysis within date ranges as well. Its a simple subscribe.


73, 

Sam W2JDB



-----Original Message-----
From: Bobby Chandler <bobbye@...>
To: main@WSJTX.groups.io
Sent: Sat, Jun 6, 2020 3:36 pm
Subject: Re: [WSJTX] ALL.TXT

Sam, got the attachment here and both files fine with 7zip.

Bobby/N4AU

--
Bobby Chandler
    n4au@...


locked Re: ALL.TXT

Bobby Chandler
 

Sam, got the attachment here and both files fine with 7zip.

Bobby/N4AU

--
Bobby Chandler
bobbye@...
n4au@...


locked Re: WSJT-X 2.2.1 GA Release

Gerald Klotz
 

Joe and the group, did I understand correctly that you removed the added frequencies for now until it can be coordinated?
If so, we will still have the added frequencies until we refresh them correct? I have seen a lot of activity on the added frequencies on 20 meters since 2.2.0

Gerry Klotz

On Jun 6, 2020, at 12:44 PM, Joe <joe@...> wrote:

WSJT-X 2.2.1 is a bug-fix release that addresses several regressions or defects in version 2.2.0.

Most importantly, v2.2.1 incorporates a revised Hamlib version that properly controls the Yaesu FT-891 and FT-991 radios. A list of all program changes since WSJT-X 2.2.0 can be found in the cumulative Release Notes here:
http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt

Upgrading from earlier versions of WSJT-X should be seamless. There is no need to uninstall a previous version or move any files.

Links to installation packages for Windows, Linux, and Macintosh are available here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General Public License (GPL). Development of this software is a cooperative project to which many amateur radio operators have contributed. If you use our code, please have the courtesy to let us know about it. If you find bugs or make improvements to the code, please report them to us in a timely fashion. Follow instructions in the WSJT-X User Guide here:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0.html#SUPPORT

We hope you will enjoy using WSJT-X Version 2.2.1.

-- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS,
for the entire WSJT Development Group


locked Re: Dependency?

Mike Marko <mike.marko.em@...>
 

Thanks, Bill!

I can wait; it's just that I was surprised that 2.1.2 worked before with Ubuntu 20.04 -- but it no longer does.

-- Mike

On 6/6/2020 2:18 PM, Bill Somerville wrote:
On 06/06/2020 19:14, Mike Marko wrote:
Trying to install 2,2.0 (or even 2.1.2) on Ubuntu 20.04.

I had 2.1.2 working, but after trying to install 2.2.0, I can't get it again:
arko@K2NU:~/Desktop$ gdebi wsjtx_2.2.0_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: libgfortran3 (>= 4.8.2)

marko@K2NU:~/Desktop$ gdebi wsjtx_2.1.2_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: libgfortran3 (>= 4.8.2)

I searched for any files *wsjtx* and found none.

TNX,

K2NU
Hi Mike,
the package we provide at release time only targets a handful of commonly used Linux distributions, in this case Ubuntu 18.04 LTS. Until Ubuntu 20.04.1 is released, which is accompanied by a route to upgrade from earlier versions, we will stick with the previous LTS release. If you can wait a while or hard working package maintainers will have done their work and v2.2.1 packages will be rolled out across the distributions they support.
If you can't wait then I suggest you build from sources, it's not hard, and doesn't take long. Instructions in the INSTALL file within the v2.2.1 sources tarball.
73
Bill
G4WJS.


locked Re: Dependency?

Bill Somerville
 

On 06/06/2020 19:14, Mike Marko wrote:
Trying to install 2,2.0 (or even 2.1.2) on Ubuntu 20.04.

I had 2.1.2 working, but after trying to install 2.2.0, I can't get it again:
arko@K2NU:~/Desktop$ gdebi wsjtx_2.2.0_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: libgfortran3 (>= 4.8.2)

marko@K2NU:~/Desktop$ gdebi wsjtx_2.1.2_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: libgfortran3 (>= 4.8.2)

I searched for any files *wsjtx* and found none.

TNX,

K2NU
Hi Mike,

the package we provide at release time only targets a handful of commonly used Linux distributions, in this case Ubuntu 18.04 LTS. Until Ubuntu 20.04.1 is released, which is accompanied by a route to upgrade from earlier versions, we will stick with the previous LTS release. If you can wait a while or hard working package maintainers will have done their work and v2.2.1 packages will be rolled out across the distributions they support.

If you can't wait then I suggest you build from sources, it's not hard, and doesn't take long. Instructions in the INSTALL file within the v2.2.1 sources tarball.

73
Bill
G4WJS.


locked Dependency?

Mike Marko <mike.marko.em@...>
 

Trying to install 2,2.0 (or even 2.1.2) on Ubuntu 20.04.

I had 2.1.2 working, but after trying to install 2.2.0, I can't get it again:
arko@K2NU:~/Desktop$ gdebi wsjtx_2.2.0_amd64.deb
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: libgfortran3 (>= 4.8.2)

marko@K2NU:~/Desktop$ gdebi wsjtx_2.1.2_amd64.deb
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: libgfortran3 (>= 4.8.2)

I searched for any files *wsjtx* and found none.

TNX,

K2NU


locked Re: TX6 Message in NA Contest Mode V2.2.0

Tony Collett
 

Thanks again Bill/Reino

Absolutely agree that the situation SHOULDN'T arise Bill and that it would be good if a common format was agreed and used.
Having said that I have seen stations on HF that are in EU contest mode, and as you acknowledge some VHF contests use NA.... so it will happen.
 
I don't see the answer in the user manual Reino, just examples of ideal QSO exchanges, not what happens if the two should collide. Which format (if any) will try to make the other change I wonder? I guess I will wait to get the aerials back in the air for a test to see what happens!!

Like you I force the RR73 message and if necessary also follow it with 73 to try and end the loop, BTW often the QSO will not log under those circumstances unless you also place the required Locator (NA mode) in the  Exch Rcvd box if it wasn't sent as part of the exchange.

Cheers
Tony


locked Re: WSJT-X 2.2.1 GA Release

Chris G4KVI
 

Absolutely brilliant!! Well done everyone, all working with FT991. Thank you.


locked Re: New feature option for non-CQ New Call color highlighting

K8BL BOB LIDDY <k8bl@...>
 

I wouldn't want (or need) WSJTX to have to search through all 24K+ FT8/4
QSOs in my Log just to let me know if I had already worked someone
every time it does a decode. IMHO, that is definite overkill! Doing it on
a Station's CQ is fully enough.

73,   Bob  K8BL


On Saturday, June 6, 2020, 01:20:39 PM EDT, Bob Lewis <aa4pb@...> wrote:


I wonder how much that would impact the performance of WSJT-x given that it would require many more call sign lookups in the log file than just doing it for the stations calling CQ.

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Geoffrey Mendenhall
Sent: Saturday, June 06, 2020 12:53 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] New feature option for non-CQ New Call color highlighting

 

I agree with Duane that this would be an important enhancement to WSJT-x.   I use the color highlighting to most importantly determine if I have already worked the station just completing a QSO without having to wait for the station to clear all other stations calling and to call CQ again.   I also use the feature to check to see if the station is an LoTW user.   All of the color coding options should be available for activity in progress.
73, Geoff -W8GNM


locked WSJT-X 2.2.1 GA Release

Joe
 

WSJT-X 2.2.1 is a bug-fix release that addresses several regressions or defects in version 2.2.0.

Most importantly, v2.2.1 incorporates a revised Hamlib version that properly controls the Yaesu FT-891 and FT-991 radios. A list of all program changes since WSJT-X 2.2.0 can be found in the cumulative Release Notes here:
http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt

Upgrading from earlier versions of WSJT-X should be seamless. There is no need to uninstall a previous version or move any files.

Links to installation packages for Windows, Linux, and Macintosh are available here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General Public License (GPL). Development of this software is a cooperative project to which many amateur radio operators have contributed. If you use our code, please have the courtesy to let us know about it. If you find bugs or make improvements to the code, please report them to us in a timely fashion. Follow instructions in the WSJT-X User Guide here:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0.html#SUPPORT

We hope you will enjoy using WSJT-X Version 2.2.1.

-- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS,
for the entire WSJT Development Group


locked Re: 20M congestion

a c <jerseyj2@...>
 

Ayes it does Joe and thank you for listening.

Jerry
KB2GCG


- "Defeat lasts one day, giving up lasts a lifetime."

On Jun 6, 2020, at 12:25 PM, Joe <joe@...> wrote:

Hi Rory,

Yes. Did you read the Release Notes for WSJT-X 2.2.0-rc1 ?

Versions 2.2.0-rc1, -rc2, and -rc3 all had built-in alternate frequencies for FT8 on the 40, 30, 20, and 6 meter bands. These trial frequencies were not much used, but the suggestion that these frequencies might be used for FT8 provoked predictable responses from users of other modes that habitually use those frequencies.

We removed the trial extra frequencies from the GA release of v2.2.0, as it seems best to wait for band-planning committees of IARU, ARRL, and other national societies to make some recommendations.

-- 73, Joe, K1JT


locked Re: New feature option for non-CQ New Call color highlighting

Bob Lewis
 

I wonder how much that would impact the performance of WSJT-x given that it would require many more call sign lookups in the log file than just doing it for the stations calling CQ.

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Geoffrey Mendenhall
Sent: Saturday, June 06, 2020 12:53 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] New feature option for non-CQ New Call color highlighting

 

I agree with Duane that this would be an important enhancement to WSJT-x.   I use the color highlighting to most importantly determine if I have already worked the station just completing a QSO without having to wait for the station to clear all other stations calling and to call CQ again.   I also use the feature to check to see if the station is an LoTW user.   All of the color coding options should be available for activity in progress.
73, Geoff -W8GNM


locked Re: Linux HamLib Error #linux

Neil Curtis <neiljcurtis@...>
 

Hi all,

When using my windows 10  box WSJTX switches between VFOa and VFOb without any problems. It is only when running the Linux version of WSJTX that the problem occurs. It switches to the alternative VFO to TX and then fails when switching back to the Rx VFO. Just tried with split mode set to none and still get the failure when switching from TX back to RX, same with Fake It.

73

Neil 2E0CMN

On Sat, 6 Jun 2020, 17:45 Gary Abercrombie, <gabercr@...> wrote:

Bill,

 

I have not thoroughly looked into but when I was developing my CAT interface between WSJT-x and my SDR software, I found it worked much better if you use separate VFO’s (SPLIT mode).  Prior to doing this, the hamlib errors were occurring and what is interesting is the errors occur without sending of the next CAT command to the rig.  Apparently, hamlib does not like something in the configuration CAT command but the error is not reported until it attempts to Tx.

 

What I did was report back to WSJT-x that I had split vfo’s in the Kenwood IF; CAT command.  WSJT-x then attempts to use VFO-A on Rx, and VFO-B on Tx (although this probably works if in reverse mode).  Then all the hamlib errors went away.  I have my own trace setup to see all of the commands issued / replied and I saw nothing incorrect but still got the hamlib errors.

 

Just a thought as seeing this reported a number of times here.

 

Gary N8CQ

 

Sent from Mail for Windows 10

 

From: Bill Somerville
Sent: Saturday, June 6, 2020 12:26 PM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] Linux HamLib Error #hamlib #linux

 

On 06/06/2020 17:18, Neil Curtis wrote:

> Ok I have done some more experimentation. As before I am using Linux

> Mint 19.3, FT817nd ZLP MiniProSC soundcard,  FTDI chipped Cat

> Interface cable. I have CAT control of the radio during Rx and CAT

> will key the radio up, but when the CAT control tries to stop Tx I get

> the HamLib error. If in settings I set the output device to the normal

> audio out /laptop soundcard, WSJTX still receives and decodes as

> normal as expected. On TX obviously the outgoing audio signal is heard

> through the speakers and so although the radio switches to TX via CAT

> control, the MiniProSC stays in receive...again I believe as expected.

> During this there is no error and CAT control of the radio is not

> interrupted.

> 

> And as before everything works fine on Win10 and I actually managed a

> QSO last night to Germany from UK on 2.5watts and a mag loop at ground

> level.

> 

> Sooo...to sum up it is selecting my sound interface that causes my Ham

> Lib error as the radio tries to switch back to receive from

> transmit...anyone know whats going in with Linux here? I'm half

> tempted to get a Signalink but it's alot of money for an experiment

> which may fail

> 

> Thanks

> 

> Neil 2E0CMN

 

Hi Neil,

 

does your audio interface have anything to do with PTT? Are you using

some form of VOX for example? I ask because the FT-817/857/897(D) series

of rigs do not accept CAT QSY commands while transmitting. If the PTT

has a delay anywhere WSJT-X will not know the rig is still keyed and

will send CAT command that will be rejected. Make sure there is no

source of PTT other than the CAT commands from WSJT-X, or try reducing

any VOX delays to minimum.

 

73

Bill

G4WJS.