Date   

locked WSJTX 2.5.0 MacOSX Issues: Memory Issue and Transmit Issue #macOS

Ted Asmus
 

I installed WSJTX 2.5.0 on my Mac running High Sierra 10.13.6 and followed the ReadMe.txt file to install the com.wsjtx.syscti.plist file. It worked perfectly EXCEPT I do not seem to be able to transmit through my Icom-7300.

Just for fun, I downloaded jtdx version 2.2 for my Mac and followed its ReadMe.txt file that changes the memory size down from a shmmax of 52428800 that occurred with the WSJTX 2.5.0 instructions to a shmmax of 14680064. jtdx ran and I received a lot of FT8 CQs. But when I double clicked on a CQ, jtdx would crash.

So, I went back to the downloaded WSJTX 2.5.0 dmg file that previously ran, reread the ReadMe.txt and followed the instructions to change the shmmax back to 52428800. The shmmax does not change from 14680064. Yes, I rebooted every time. Not just a restart, but a complete shut-down and reboot. Of course, I get the dreaded memory error when I try to run WSJTX.

I would appreciate any help in getting (1) WSJTX 2.5.0 back running again and (2) getting some hints on how to get my Icom-7300 transmitting from WSJTX.

By the way, I think this software is amazing!

Thanks for any advice you can provide,

Ted Asmus
K8UKE


locked Re: WSJT-X will not work with some Yaesu Radios using the Raspberry Pi due to HAMLIB incompatibility... #Yaesu #WSJTX_config #raspberryPi #linux

Bill Somerville
 

On 05/10/2021 15:30, regiogringo@... wrote:
Hello Bill,

Perhaps my terminology is incorrect, and being interpreted as "misinformation."  With respect to the attachments I posted in my prior message, a picture is worth a thousand words...

Which of the selections depicted in the prior attachments, which are the selections I am finding under the "AUDIO" tab in WSJT-X Settings, are the proper ones to select for INPUT and OUTPUT if using a Raspberry Pi?

As I mentioned, I have WSJT-X set up on my Windows machine, and it works flawlessly.  So, with respect to the setup and hardware configurations to make WSJT-X work with Windows, I'm familiar with how things are to be configured.  But, this issue with the Raspberry Pi and the HAMLIB error message persists, and I can't figure out why, or what I'm doing wrong.

Thanks!

Randy
KG0BA
Randy,

you are conflating audio devices and CAT control, they are not related.

73
Bill
G4WJS.


locked Re: WSJT-X will not work with some Yaesu Radios using the Raspberry Pi due to HAMLIB incompatibility... #Yaesu #WSJTX_config #raspberryPi #linux

regiogringo@...
 

Hello Bill,

Perhaps my terminology is incorrect, and being interpreted as "misinformation."  With respect to the attachments I posted in my prior message, a picture is worth a thousand words...

Which of the selections depicted in the prior attachments, which are the selections I am finding under the "AUDIO" tab in WSJT-X Settings, are the proper ones to select for INPUT and OUTPUT if using a Raspberry Pi?

As I mentioned, I have WSJT-X set up on my Windows machine, and it works flawlessly.  So, with respect to the setup and hardware configurations to make WSJT-X work with Windows, I'm familiar with how things are to be configured.  But, this issue with the Raspberry Pi and the HAMLIB error message persists, and I can't figure out why, or what I'm doing wrong.   

Thanks!

Randy
KG0BA


locked Re: WSJT-X will not work with some Yaesu Radios using the Raspberry Pi due to HAMLIB incompatibility... #Yaesu #WSJTX_config #raspberryPi #linux

Bill Somerville
 

On 05/10/2021 14:49, regiogringo@... wrote:
Hello Rich,

I am curious as to which drivers you're using, especially because the drivers offered by Yaesu are specific to the Windows operating system. You must be using drivers that are not the Yaesu published drivers because they're supposedly specific to Windows operating systems, and should not work on a Linux operating system.

Since you have it working on your Raspberry Pi, perhaps I need to load some drivers on my Raspberry Pi that will work with my FT-991A so they're there to select from under the AUDIO tab. Maybe with respect to the build I'm using on my Raspberry Pi4, working drivers were omitted from the selection of drivers I have to choose from.

Which drivers have you selected within the WSJT-X "Audio" tab? Can you advise where the working drivers can be downloaded that will work with the Yaesu FT-991A and the Raspberry Pi?

Thanks!

Randy
KG0BA
Randy,

this topic thread is full of misinformation! No user installed drivers are needed for USB audio on any contemporary operating system, the generic USB audio drivers are just fine. On MS Windows user installed drivers are required for the virtual serial port that provides CAT communications with modern rigs using a USB connection to a PC. Linux and the latest macOS versions have suitable virtual serial port drivers available already.

73
Bill
G4WJS.


locked Re: WSJT-X will not work with some Yaesu Radios using the Raspberry Pi due to HAMLIB incompatibility... #Yaesu #WSJTX_config #raspberryPi #linux

regiogringo@...
 

Hello Rich, 

I am curious as to which drivers you're using, especially because the drivers offered by Yaesu are specific to the Windows operating system. You must be using drivers that are not the Yaesu published drivers because they're supposedly specific to Windows operating systems, and should not work on a Linux operating system.

Since you have it working on your Raspberry Pi, perhaps I need to load some drivers on my Raspberry Pi that will work with my FT-991A so they're there to select from under the AUDIO tab. Maybe with respect to the build I'm using on my Raspberry Pi4, working drivers were omitted from the selection of drivers I have to choose from. 

Which drivers have you selected within the WSJT-X "Audio" tab?  Can you advise where the working drivers can be downloaded that will work with the Yaesu FT-991A and the Raspberry Pi?

Thanks!

Randy
KG0BA


locked Re: WSJT-X will not work with some Yaesu Radios using the Raspberry Pi due to HAMLIB incompatibility... #Yaesu #WSJTX_config #raspberryPi #linux

regiogringo@...
 
Edited

Hello Bill,

Thank you for your reply...I agree, it seems to be a rig control issue, but it appears to me to be related to the USB driver selections that are offered within WSJT-X when using a Raspberry Pi.  When I made reference to "audio settings" before, I was referring to the tab entitled "AUDIO" under WSJT-X settings, which appear to me to be the selection of drivers that enable the Raspberry Pi to connect to the radio. 

Attached is a photo of the USB driver selections offered by WSJT-X under the "Audio" tab. I've tried each of the selections, and none of them result in a connection to the radio. Instead, I get a HAMLIB error message. I've attached a photo of the HAMLIB error message as well. 

If using a Windows machine, the drivers can be downloaded from Yaesu, but they are specific to the Windows operating system. When I set up WSJT-X on a Windows machine, I have no problems whatsoever, and the (Yaesu (Silicon Labs) drivers are there to select from.  But, when trying to set up WSJT-X on a Raspberry Pi, that's when I have problems connecting to the radio from the selection of drivers offered under the "AUDIO" tab within WSJT-X, and I get the resulting HAMLIB error message.

I wonder if because Yaesu only offers drivers for Windows, perhaps there aren't compatible drivers that will work with the Raspberry Pi, and the selection of drivers offered to select from within WSJT-X aren't compatible with Yaesu radios. 

Please let me know if you have any other questions or observations.  I'm a relative novice with respect to the Raspberry Pi, but I'll try to provide as much information as possible to resolve the issue.

Thank you!
Randy
KG0BA


locked Re: WSJT-X will not work with some Yaesu Radios using the Raspberry Pi due to HAMLIB incompatibility... #Yaesu #WSJTX_config #raspberryPi #linux

RichW6BOT
 

My Pi /FT-991A work just fine together with WSJT-x and JS8CALL without FLrig.

The Pi image was built from scratch, and WSJT-X and JS8CALL were both loaded without any issue.

I don't understand the problem either.

Rich
W6BOT


locked Re: Rig forced to VFO A by WSJT-X #Windows 10 #Cat_RigControl #Windows10 #WSJTX_config

Bob McGraw - K4TAX <rmcgraw@...>
 

I use FAKE IT as the configuration VFO mode for WSJT-X.  Regardless of the radio mode, the radio is in or configured, when I open WSJT-X it connects to the radio and defaults to VFO A as the TX and RX VFO.  If I change WSJT-X to RIG SPLIT then VFO A is the RX selection and VFO B is the TX selection.  Seems the choice of the user will allow the radio to use one VFO or both VFO's.    I also find this configuration works for both of my radios, Elecraft K3S and Tentec Eagle.  

Bob, K4TAX


locked Re: Rig forced to VFO A by WSJT-X #Windows 10 #Cat_RigControl #Windows10 #WSJTX_config

Sam Birnbaum
 

Hi Bill,

Thank you for explanation. I would not have thought of that as I know that as soon as I change the 
TX offset in WSJT-X, the TS590s  VFO-B TX frequency shifts immediately. That happens without 
any TX taking place.  I never checked out that scenario where I changed VFO-B after you already 
issued the commands to shift it after the original TX Offset was selected.  

I already knew about the timing constraints as that was very well explained by you in one of the very 
early  email threads as well as by my experience writing custom code for tracking/controlling various 
rigs that I and/or friends own.

Thank you again for the explanation and for me anyway, additional knowledge regarding WSJT-X.

Thanks the work/effort you and the rest of the team have put into this product.

If down the road the team has the time and/or inclination to enhance UDP Message #15 by adding 
the TX offset field, it would greatly enhance/simplify the function I use for the blind hams when selecting 
the open slot in the band pass and/or shifting it programmatically.  

73,
 
Sam W2JDB



-----Original Message-----
From: Bill Somerville <g4wjs@...>
To: main@WSJTX.groups.io; wb0kkm@... <wb0kkm@...>
Sent: Tue, Oct 5, 2021 3:39 am
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl

Hi Sam,

WSJT-X takes the view that the rig may have been changed directly, because of that the CAT commands to prepare for Tx, or after returning to Rx, are sent every time. That means that roughly the same amount of CAT traffic is exchanged in either Rig split mode or in Fake It split mode.

What is far more important is the lack of timing constraints when using SPLIT mode on the rig. Several rigs respond differently to CAT commands when in SEND mode, this can cause ambiguity if we do not know exactly when the rig switches from Rx to Tx and back. This happens when using VOX, or external PTT for sequencing pre-amps and amplifiers, when WSJT-X cannot know exactly when the rig switches from Rx to Tx and back. Using SPLIT mode there is no ambiguity since the Rx and Tx VFOs are set independently of Tx/Rx switching timing.

73
Bill
G4WJS.

On 05/10/2021 02:58, Sam Birnbaum via groups.io wrote:
Hi Gary,

Using Split = Rig is more efficient as the program does not need to issue any 
commands associated with shifting the frequency and then waiting for the 
confirmation every time you switch from RX to TX and then back.
On rigs that do have 2 VFOs and using Spilt = Rig, the TX VFO frequency 
is set the second the offset for TX is set. That is done once and there are 
no more commands required to be issued when the program switches from 
RX to TX and back.  Just a point of information. 
 
73,
  
Sam W2JDB



-----Original Message-----
From: Gary - AG0N <wb0kkm@...>
To: main@wsjtx.groups.io <main@WSJTX.groups.io>
Sent: Mon, Oct 4, 2021 5:18 pm
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl



> On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@...> wrote:
>
> So what is so important about VFO B?  Doesn't VFO A have the same capability?  If so, then that which is so important on VFO A can be done on VFO B.  Just let the software do its job and learn to use it as designed. 


One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A.  Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”.  If i’m wrong about that, fine, but that’s how I thought it was.  As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N





locked Re: Rig forced to VFO A by WSJT-X #Windows 10 #Cat_RigControl #Windows10 #WSJTX_config

Bill Somerville
 

Hi Sam,

WSJT-X takes the view that the rig may have been changed directly, because of that the CAT commands to prepare for Tx, or after returning to Rx, are sent every time. That means that roughly the same amount of CAT traffic is exchanged in either Rig split mode or in Fake It split mode.

What is far more important is the lack of timing constraints when using SPLIT mode on the rig. Several rigs respond differently to CAT commands when in SEND mode, this can cause ambiguity if we do not know exactly when the rig switches from Rx to Tx and back. This happens when using VOX, or external PTT for sequencing pre-amps and amplifiers, when WSJT-X cannot know exactly when the rig switches from Rx to Tx and back. Using SPLIT mode there is no ambiguity since the Rx and Tx VFOs are set independently of Tx/Rx switching timing.

73
Bill
G4WJS.

On 05/10/2021 02:58, Sam Birnbaum via groups.io wrote:
Hi Gary,

Using Split = Rig is more efficient as the program does not need to issue any 
commands associated with shifting the frequency and then waiting for the 
confirmation every time you switch from RX to TX and then back.
On rigs that do have 2 VFOs and using Spilt = Rig, the TX VFO frequency 
is set the second the offset for TX is set. That is done once and there are 
no more commands required to be issued when the program switches from 
RX to TX and back.  Just a point of information. 
 
73,
  
Sam W2JDB



-----Original Message-----
From: Gary - AG0N <wb0kkm@...>
To: main@wsjtx.groups.io <main@WSJTX.groups.io>
Sent: Mon, Oct 4, 2021 5:18 pm
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl



> On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@...> wrote:
>
> So what is so important about VFO B?  Doesn't VFO A have the same capability?  If so, then that which is so important on VFO A can be done on VFO B.  Just let the software do its job and learn to use it as designed. 


One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A.  Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”.  If i’m wrong about that, fine, but that’s how I thought it was.  As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N



locked Re: worked before status #macOS

John Wiener
 

I did note that MacLoggerDX came up when I was trying to find the log.  I now see this ... a screenshot.
I don't use MacLoggerDX. I tried it over a year ago and opted not to purchase.  Today I uninstalled it.
Is MacLogger blocking WSJT-X from the log?


locked Re: Rig forced to VFO A by WSJT-X #Windows 10 #Cat_RigControl #Windows10 #WSJTX_config

Sam Birnbaum
 

Hi Gary,

Using Split = Rig is more efficient as the program does not need to issue any 
commands associated with shifting the frequency and then waiting for the 
confirmation every time you switch from RX to TX and then back.
On rigs that do have 2 VFOs and using Spilt = Rig, the TX VFO frequency 
is set the second the offset for TX is set. That is done once and there are 
no more commands required to be issued when the program switches from 
RX to TX and back.  Just a point of information. 
 
73,
  
Sam W2JDB



-----Original Message-----
From: Gary - AG0N <wb0kkm@...>
To: main@wsjtx.groups.io <main@WSJTX.groups.io>
Sent: Mon, Oct 4, 2021 5:18 pm
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl



> On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@...> wrote:
>
> So what is so important about VFO B?  Doesn't VFO A have the same capability?  If so, then that which is so important on VFO A can be done on VFO B.  Just let the software do its job and learn to use it as designed. 


One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A.  Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”.  If i’m wrong about that, fine, but that’s how I thought it was.  As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N





locked Re: worked before status #macOS

John Wiener
 

message says 1704 worked before so I guess the log exists.  So, what am I missing? 


locked Re: worked before status #macOS

John Wiener
 

On Mon, Oct 4, 2021 at 03:09 PM, Bill Somerville wrote:
ls -l ~/Library/Application\ Support/WSJT-X/wsjtx_log.adi

johnwiener@Mac-mini-2 ~ % ls -l ~/Library/Application\ Support/WSJT-X/wsjtx_log.adi

-rw-r--r--@ 1 johnwiener  staff  486566 Oct  4 17:31 /Users/johnwiener/Library/Application Support/WSJT-X/wsjtx_log.adi

johnwiener@Mac-mini-2 ~ %

so what does it mean? 


locked Re: worked before status #macOS

Bill Somerville
 

On 04/10/2021 22:47, John Wiener wrote:
Hi
I cascade thru several problems as I try to reload WSJT after some odd behavior with the latest MacOS update.
I got thru the memory change adjustments in Terminal and got the xmit working after changing mode in WSJT preferences to Data/packet from USB.
so now, it works but I have a new question.
I no longer see ANY worked before status on incoming calls.  The button for DXCC, worked before, etc is pressed in Preferences and colours ticks look correct.  
Did I lose my log?  

Hi John,

unless you deleted it, your log should still be there. The file locations are documented in the WSJT-X User Guide:

https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.5.0.html#_file_locations

So what does the following command in a terminal window print?

ls -l ~/Library/Application\ Support/WSJT-X/wsjtx_log.adi

Also just after WSJT-X starts it will flash up a message in the status bar for a few seconds saying how many worked before records have been read from the log file.

73
Bill
G4WJS.


locked worked before status #macOS

John Wiener
 

Hi
I cascade thru several problems as I try to reload WSJT after some odd behavior with the latest MacOS update.
I got thru the memory change adjustments in Terminal and got the xmit working after changing mode in WSJT preferences to Data/packet from USB.
so now, it works but I have a new question.
I no longer see ANY worked before status on incoming calls.  The button for DXCC, worked before, etc is pressed in Preferences and colours ticks look correct.  
Did I lose my log?  


locked Re: Help using RSPduo with MAP65 v3.0 #map65 #SDR

NR4U Bob AFMARS
 

RSPduoEME User Instructions
David Warwick G4EEV
(For Software Version 1.31)
December 2020


reading now

thank you very much

YZ

--
--
Bob KD7YZ in NE Kentucky


locked Re: Rig forced to VFO A by WSJT-X #Windows 10 #Cat_RigControl #Windows10 #WSJTX_config

Jim Brown
 

On 10/4/2021 2:18 PM, Gary - AG0N wrote:
One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A. Fake it, keeps it this way and I never have to question what is going on with the VFOs.
I do the same, because I work lots of CW and RTTY contests. With rig-split it would leave the radio (a K3) when I quit FT8, which is a PITA.

73, Jim K9YC


locked Re: Intermittent Decodes #adiFiles #decode

Bob McGraw - K4TAX <rmcgraw@...>
 

I'm using 2.5.0 with Windows 10 Pro 64 bit on an old laptop computer originally released with Vista.  {That's old!}  I do allow automatic updates of the Windows system and have suffered ZERO, repeat ZERO, issues with any of my preferred settings, or values after any of the updates.   The dang system is just like the battery bunny, it just keeps working and working and working.   I suppose I feel left out not getting faulty or crappy downloads and not having any issues to resolve.   Any suggestions? 

Oh, when I have had issues it was due to my stupid screw-up!  But I didn't blame it on any software or operating system package.  

Bob, K4TAX


locked Re: Rig forced to VFO A by WSJT-X #Windows 10 #Cat_RigControl #Windows10 #WSJTX_config

Gary - AG0N
 

On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@...> wrote:

So what is so important about VFO B? Doesn't VFO A have the same capability? If so, then that which is so important on VFO A can be done on VFO B. Just let the software do its job and learn to use it as designed.
One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A. Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”. If i’m wrong about that, fine, but that’s how I thought it was. As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N

7861 - 7880 of 36834