Re: [wsjt-devel] Hamlib error

[Black Michael via wsjt-devel]

Is the port you selected actually named "USB" ?  If so that's not a valid port 
name in either Linux or Windows.

Mike W9MDB








On Sunday, April 28, 2024 at 05:53:18 PM CDT, 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


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

Re: [wsjt-devel] WSJT-X v 2.7.0-rc4/hamlib bug report; CAT failure casues hung process

[Black Michael via wsjt-devel]

Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0


C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location
Here's a youtube video showing Windows users howto -- 
https://www.youtube.com/watch?v=q9tAvhNmSvc


For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X


For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X


Then send me the WSJT-X_RigControl.log file
Mike W9MDB








On Wednesday, March 20, 2024 at 06:59:10 PM CDT, Scott Armstrong via wsjt-devel 
 wrote: 





Hi All,
I have encountered a problem running  2.7.0-rc4 with Hamlib version
 
This impacts an Icom IC-756ProII and IC-746. The issue is not observed when 
running a IC-9700
The problem is also observed running 2.7.0-rc3 with the new Hamlib version

The workaround is to roll back to the previous version of Hamlib





See below for the problem details. If more information/data is required I'd be 
glad to provide it.

Thanks,
Scott AA5AM

PROBLEM: 
CAT failure causes v2.7.0-rc4 to hang, requiring the process to be killed.



WSJT:



Hamlib:


Windows/PC:



Rigs impacted:

Icom IC-756ProII
Icom IC-746


PROBLEM DESCRIPTION

If CAT becomes disabled by turning the radio off or other problem that causes a 
disconnect, the WSJT CAT connection indicator remains green. It never 
transitions to amber or red.



The Rig Control Error pop-up message is not raised.



When CAT is restored by turning on the radio or resolving other errors, there 
is still no connection between the SW and the radio even though the indicator 
is still green.
WSJT-X v2.7.0-rc4 is then closed and relaunched. 

The pop-up indicating that another instance may be running is observed. 


Then it becomes necessary to go into Task Manager and kill the wsjt.exe process 
that is hung from the previous instance of the SW running.






___
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 v 2.7.0-rc4/hamlib bug report; CAT failure casues hung process

[Black Michael via wsjt-devel]

Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0


C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location
Here's a youtube video showing Windows users howto -- 
https://www.youtube.com/watch?v=q9tAvhNmSvc


For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X


For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X


Then send me the WSJT-X_RigControl.log file
Mike W9MDB








On Wednesday, March 20, 2024 at 06:59:10 PM CDT, Scott Armstrong via wsjt-devel 
 wrote: 





Hi All,
I have encountered a problem running  2.7.0-rc4 with Hamlib version
 
This impacts an Icom IC-756ProII and IC-746. The issue is not observed when 
running a IC-9700
The problem is also observed running 2.7.0-rc3 with the new Hamlib version

The workaround is to roll back to the previous version of Hamlib





See below for the problem details. If more information/data is required I'd be 
glad to provide it.

Thanks,
Scott AA5AM

PROBLEM: 
CAT failure causes v2.7.0-rc4 to hang, requiring the process to be killed.



WSJT:



Hamlib:


Windows/PC:



Rigs impacted:

Icom IC-756ProII
Icom IC-746


PROBLEM DESCRIPTION

If CAT becomes disabled by turning the radio off or other problem that causes a 
disconnect, the WSJT CAT connection indicator remains green. It never 
transitions to amber or red.



The Rig Control Error pop-up message is not raised.



When CAT is restored by turning on the radio or resolving other errors, there 
is still no connection between the SW and the radio even though the indicator 
is still green.
WSJT-X v2.7.0-rc4 is then closed and relaunched. 

The pop-up indicating that another instance may be running is observed. 


Then it becomes necessary to go into Task Manager and kill the wsjt.exe process 
that is hung from the previous instance of the SW running.






___
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] Remote WSJT

[Black Michael via wsjt-devel]

Depend on what you are trying to seperate -- sounds like the GUI FFT processing 
is you concern perhaps the decoding too?
Here's the flow
RigAudio -> PC -> GUI (both fft and collect for decoder -> wav file -> decoder 
(e.g. JT9.EXE) -> GUI
And you are talking aboutRigAudio -> PicoITX -> GUIWhere PicoITX could do FFT 
display data and decoding.
Moving the decoder to a separate processor would be the easer step as JT9.EXE 
just processes a WAV file and returns the decodes.Moving the FFT processing in 
the GUI would be more complicated.
Mike W9MDB 

On Wednesday, February 28, 2024 at 06:15:16 AM CST, Rafael Pinto via 
wsjt-devel  wrote:  
 
 Hello folks
Sorry if this has already been discussed!
I am Rafael, PU1OWL, and I was thinking if it would be possible to detach the 
GUI frontend from the modulation/audio/realtime backend of WSJT-X so we can 
make it a remote module
The architecture I envision is having a remote processor (e.g., some bulky 
raspberry pi, a PicoITX i9 board...) dealing with the mathematical heavy 
lifting while not having to put CPU into presenting its GUI. The GUI could be 
remote, on a PC or another raspberry pi, or something even lighter... Or maybe 
even  some audio sink board, forwarding to a hugely capable math processor, to 
a lightweight GUI...
I started studying the source code, but I cannot find somewhere to split the 
code. Has it been tried before?
73 de PU1OWL
Rafael Pinto___
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] 2.7.0-rc3 UI defect

[Black Michael via wsjt-devel]

I think you can put those values in the qt.conf file also that you'll find in 
the bin directory.
Did you try the wsjtx.exe I sent youi?
Mike W9MDB

 

On Sunday, February 11, 2024 at 03:18:03 PM CST, Laurie, VK3AMA via 
wsjt-devel  wrote:  
 
  
 
 On 10/02/2024 4:46 pm, Alan McDonald via wsjt-devel wrote:
  
I set my QT scaling to 75% with good results
 
 Where is this documented? I could not find any mention of QT_SCALE_FACTOR or 
QT_AUTO_SCREEN_SCALE_FACTOR in the 2.6.1 or 2.7.0 documentation.
 
 Setting these environment variables affects all other QT based applications 
installed like JTDX and MSHV.
 This should not be needed to fix one specific broken area of the Wsjtx UI.
 
 Hopefully one of the Wsjtx devs will respond.
 
 de Laurie VK3AMA
 (JTAlert author)
 
 ___
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] 2.7.0-rc3 UI defect

[Black Michael via wsjt-devel]

Try this executable -- not sure this is the fix but it may be.

https://www.dropbox.com/scl/fi/988papncf8o0wtuy56urw/wsjtx.exe?rlkey=nrkyyw7nerl21oatqlyhs27uz=0








On Saturday, February 10, 2024 at 07:04:04 PM CST, Laurie, VK3AMA via 
wsjt-devel  wrote: 





On 11/02/2024 5:06 am, Black Michael wrote:
> Give Uwe's improved version a try -- seems to behave differently.

With respect. I am not interested in yet another fork of Wsjtx.

Uwe is on the Wsjtx development team and I recall that he introduced 
these new mode buttons that crop the text. If his personal fork of Wsjtx 
behaves correctly, why cant the same code be applied to Wsjtx?


de Laurie VK3AMA
(JTAlert author)


___
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] 2.7.0-rc3 UI defect

[Black Michael via wsjt-devel]

Are you using more than 100% scaling?

Mike W9MDB








On Friday, February 9, 2024 at 05:35:27 PM CST, Laurie, VK3AMA via wsjt-devel 
 wrote: 






This defect has been present in all recent release candidates and the 2.6.1 GA 
release since the mode selection buttons were first introduced.

Running Win 11, X64, 4K monitor.

The mode selection buttons on the main window do not scale correctly the text 
is cropped horizontally.
All other controls of the window scale correctly without any cropping of text. 
It is only the mode selection buttons at fault, none of the other controls are 
affected.

Adjusting (reducing) the font size is not the fix as that will make all other 
controls unreadable (too small).
In this image the font is set at 8pt so oversized font is not the problem. 

    
        

de Laurie VK3AMA




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


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

Re: [wsjt-devel] Wsjt 2.7.0 rc3 apparent holes in transmission

[Black Michael via wsjt-devel]

If the new machine is a Dell look for "WAV" services in the services manager 
and disable them.

Mike W9MDB








On Tuesday, January 30, 2024 at 06:28:24 AM CST, Nic Sears via wsjt-devel 
 wrote: 





Hi there, Nic G3YEG here.

I have been using wsjt for quite a few years both ft8 (hf, vhf and uhf) and 
q65-60b on 432 eme and have never consciously notice the power output of any of 
my previous rigs varying during ft8 or q65 tx cycles.

Recently I Started using a new laptop with much higher spec than old machine  
and also changed over to rc3. I then noted that the alc on my ic9700 had 
started spiking on the tx cycle. 

This seems to be completely random and does not appear to effect the decoding 
of my signal at all, hf, vhf ,uhf ft8 and even with my very low power q65 eme 
set up having had 3 recent eme qso’s and seen the spikes occur on tx. It also 
occurs on the ts2000 i use for hf.

I have investigated and it seems that the transmission does have “holes” in it 
when you actually listen to it.

It is not consistent as sometimes the tx cycle is completely clean and 
sometimes has a number of holes.

I have reverted back to 2.6.1 and that also exhibits the same problem but it 
does seem to be to a lesser extent. However Not done that many tests on 2.6.1

I always run with nil or very low alc on both my rigs so the recent spiking has 
been quite obvious. The tx power output on both the rigs doesn’t seem to dip 
that but the 9700 current drain certainly drops on the rig metering.

The old machine was a Lenovo running Windows 10 with an amd a10 and 12gb memory 
driving the 9700 via a single usb interface. The new machine is an intel i7 
running Windows 11 with 32Gb memory again driving the 9700 via a single usb 
interface. The ts2000 is driven from the new machine via a usb to rs232 dongle 
for cat control and a usb to analogue dongle for the audio interface. The icom 
Ic-9700 usb driver was in use on both old and new machines.

I mentioned this observation to another local eme operator who has also noted 
these “holes” but also observed that it doesn’t seem to cause any remote 
station decoding problems.

Be grateful if you could consider my observation and advise if there is a real 
problem.

Thank you, Nic 





___
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] Problem with WSJT-X 2.7.0 RC3 and Hamlib +Flrig

[Black Michael via wsjt-devel]

Assuming this is repeatable we now need to see FLRig debug data to see why mode 
is not being read correctly.

So Config/Setup/Trace and turn on all the checkboxes.  

Duplicate the problem.  Then find the trace.txt file in flrig.files and send it 
to me.

Mike W9MDB








On Monday, January 29, 2024 at 07:03:57 AM CST, Richard Shaw 
 wrote: 





On Sun, Jan 28, 2024 at 10:16 PM Black Michael  wrote:
> What rig?  For some reason that call is not returning any value for your rig 
> when getting the current mode.

FT-991A

Thanks,
Richard 



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

Re: [wsjt-devel] Polling Disable

[Black Michael via wsjt-devel]

What version of Hamlib are you running?  There's currently no way to disable 
polling.

rigctl-wsjtx --version


FT747 behavior was supposedly fixed Aug 2022.

Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0


C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location
Here's a youtube video showing Windows users howto -- 
https://www.youtube.com/watch?v=q9tAvhNmSvc


For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X


For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X


Then send me the WSJT-X_RigControl.log file
Mike W9MDB

Mike W9MDB







On Monday, January 29, 2024 at 01:44:48 AM CST, Adrian  
wrote: 





Is there  a way to disable cat polling in wsjtx config ini file etc?

This is on a Catalina Macbook.

I have a FT-747GX that poll reads +08 tail to set frequency > red freq 
band shows OOB etc but sets fine,

basically the poll read frequency adds 08 to the tail of the number.

28.074 000  becomes 2,807.400 008 . The radio is showing correct 
frequency, so a program issue.

I have found others mention this before in wsjtx group archives.

Have tried a big range of wsjtx editions, and all the same result.

I can set poll to 99 s , but would like to disable. I could set rig = none,

but I have good cat control to set bands, and would like to retain that.

The issue prevents me working split,as the huge number with shift is

sent to the 747 which then displays err, game over. So I stay set over 
1500 hz on pan



73




vk4tux




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

Re: [wsjt-devel] Problem with WSJT-X 2.7.0 RC3 and Hamlib +Flrig

[Black Michael via wsjt-devel]

What rig?  For some reason that call is not returning any value for your rig 
when getting the current mode.

Mike W9MDB








On Sunday, January 28, 2024 at 07:37:38 PM CST, Richard Shaw via wsjt-devel 
 wrote: 





I decided to test out the RC3 release and everything comes up fine but as soon 
as I try to change TX frequency in the waterfall or make a contact I get 
something like this:

Rig Control Error
Hamlib error: Content-length: 168






xml_parse2: value returned=''
xml_parse2: xml='


'
flrig_transaction: no value returned
    4:flrig.c(600):flrig_transaction returning(8) 
   3:flrig.c(1701):flrig_get_mode returning(8) 
  2:flrig.c(2018):flrig_set_split_freq_mode returning(8) 
 1:rig_set_split_freq_mode: elapsed=22ms
 1:rig.c(4843):rig_set_split_freq_mode returning(8) 
Protocol error
Protocol error
 while setting split TX frequency and mode

Timestamp: 2024-01-29T01:29:30.026Z
---

- Everything I try in Flrig works perfectly. 
- Clicking the 1kc up and down arrows work fine in WSJT-X.
- Test CAT and Test PTT in WSJT-X works fine.

Thanks,
Richard
KF5OIM

___
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 Digest, Vol 119, Issue 46

[Black Michael via wsjt-devel]

I don't see the 240202 update at your "find it here" link.

It points to 
https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/

Mike W9MDB








On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via wsjt-devel 
 wrote: 





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, 
I have now added another line of code as a test for my upcoming 'improved' 
2.7.1-devel "240202" update, which has the effect that if you are in FT8 Hound 
mode, all messages (below 1000 Hz) are really displayed in the right window if 
they contain your own callsign. 

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on 
when you are in FT8 Hound mode, because this confuses many OMs and makes little 
sense, at least from my point of view. Tell me if there is any good reason why 
this was/is necessary.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:


>  

"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.   



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



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


___
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 46

[Black Michael via wsjt-devel]

Should be able to use this instead.  Your call always has a space before/after.

contains(" " + m_baseCall +" "))

Mike W9MDB






On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via wsjt-devel 
 wrote: 





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, 
I have now added another line of code as a test for my upcoming 'improved' 
2.7.1-devel "240202" update, which has the effect that if you are in FT8 Hound 
mode, all messages (below 1000 Hz) are really displayed in the right window if 
they contain your own callsign. 

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on 
when you are in FT8 Hound mode, because this confuses many OMs and makes little 
sense, at least from my point of view. Tell me if there is any good reason why 
this was/is necessary.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:


>  

"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.   



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



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


___
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

[Black Michael via wsjt-devel]

Actually CW operators use apriori operation all the time.

When you're in a poor signal CW QSO with a dxepedition or such all you listen 
for is your call sign -- not theirs.  You assume (apriori) that they are the 
ones responding and you have a sequence you follow so you just continue.

Mike W9MDB








On Saturday, January 27, 2024 at 12:50:50 AM CST, Jim Shorney via wsjt-devel 
 wrote: 






I would agree to that. I saw one with a P7 call yesterday that looked quite 
legitimate. My finger wanted badly to click on it but I said "no, wait...". 
Never saw it again. Despite what the nay-sayers claim, FT modes do require some 
human thought to get the best out of them. :)

73

-Jim
NU0C

On Sat, 27 Jan 2024 08:29:56 +0200
Reino Talarmo via wsjt-devel  wrote:

> Perhaps FT8 is too good compared to RTTY and
> CW and operators rely on what's written on screen, hi!


-- 

73

-Jim
NU0C



___
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] Strange problem with the RC's

[Black Michael via wsjt-devel]

Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0


C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location
Here's a youtube video showing Windows users howto -- 
https://www.youtube.com/watch?v=q9tAvhNmSvc


For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X


For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X


Then send me the WSJT-X_RigControl.log file
Mike W9MDB










On Friday, January 26, 2024 at 02:38:09 PM CST, kgross jensalt.com via 
wsjt-devel  wrote: 





  


I’m very confused.  I have 2 different XGGcoms digimode 4’s for two different 
models of Kenwoods.  They work fine with the GA version but with 2.7.0RC as 
soon as the wsjt-x software is loaded and accessing the radio viat CAT control, 
the radios go into TX,  (ts-2000 and tx-480).  I knew I had them working before 
so in my testing I went back to the GA version, and they work fine.   What can 
I do to help test this. 

 

Windows 10. 

 



___
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 Digest, Vol 119, Issue 45

[Black Michael via wsjt-devel]

#1 That's a false decode (detectable as a funky message)
#2 Not on the Fox offsets.  Fox never transmitted at 474

Mike W9MDB








On Friday, January 26, 2024 at 11:19:40 AM CST, Glenn Williams via wsjt-devel 
 wrote: 





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] wsjt-devel Digest, Vol 119, Issue 45

[Black Michael via wsjt-devel]

No...it just appends the file.  Size doesn't matter as the saying goes...

Mike W9MDB








On Friday, January 26, 2024 at 11:10:08 AM CST, Glenn Williams via wsjt-devel 
 wrote: 





So,
Once upon a time I asked a question and the gurus had an answer (V2.2.2 
I think).

My question was about "how does FT8 keep huge files open and still keep 
up with the band activity while updating huge files". Today's question 
is about that.  ALL.TXT has grown really large.  Is there a practical 
limit on how large it can grow before the data flow bogs down and causes 
errors during Decode time?

--73, Glenn, AF8C

On 1/26/2024 9:18 AM, Rich - K1HTV via wsjt-devel wrote:
> I have noticed the same thing at times while running as Hound in F/H 
> where the report from the Fox will appear in the Band Activity column 
> but not in the Rx Frequency column.I am presently running the "WSJT-X 
> V2.7.1 devel 231031 Improved PLUS" version.
> 
> Also, when the "Start new period decodes at top" checkbox is checked, 
> many times a day the background color will change from white to another 
> background color. When this occurs it is not always the same color.
> 
> Also, at times when using  the  "Start new period decodes at top" 
> option, the Band activity columns display will revert back to the 
> earliest decodes, often many tens of minutes earlier.
> 
> 73,
> Rich - K1HTV
> 
> 
> On Fri, Jan 26, 2024 at 7:55 AM 
>  > wrote:
> 
>    Send wsjt-devel mailing list submissions to
>    wsjt-devel@lists.sourceforge.net
>    
> 
>    To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>    
>    or, via email, send a message with subject or body 'help' to
>    wsjt-devel-requ...@lists.sourceforge.net
>    
> 
>    You can reach the person managing the list at
>    wsjt-devel-ow...@lists.sourceforge.net
>    
> 
>    When replying, please edit your Subject line so it is more specific
>    than "Re: Contents of wsjt-devel digest..."
>    Today's Topics:
> 
>         1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn
>    Williams)
> 
> 
> 
>    -- Forwarded message --
>    From: Glenn Williams     >
>    To: wsjt-devel@lists.sourceforge.net
>    
>    Cc:
>    Bcc:
>    Date: Thu, 25 Jan 2024 08:12:51 -0500
>    Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
>    V 2.7.0-rc3
>    Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
>    has happened once or twice before.)  His S/N report on me popped up in
>    Band Act window after my TX1, but no report in RX Freq window. TX3
>    completed OK in both Windows.  I use COLORS and so red was instantly
>    obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the
>    order
>    of 450 watts with tuner. Not thinking RFI because no other times ever I
>    see any.
> 
>    -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


___
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 Digest, Vol 119, Issue 45

[Black Michael via wsjt-devel]

Perhaps when the fox offset for your callsign changes?
I think I've seen that.









On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via wsjt-devel 
 wrote: 





Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest code) 
using three instances all connected via virtual audio.  One in FT8 Fox mode and 
the other two in FT8 Hound mode. Then I simulated just such QSO situations, but 
each time the reports appeared in the right-hand window of the two Hound 
stations. Not a single issue, even if I set the Rx frequency next to the Fox's 
audio signal. So, at the moment I can't reproduce this unwanted effect. 

Please note that the "231031" code of 2.7.1-devel has received several updates 
in the meantime. Test it again with the current "240106" code, or with the 
soon-to-be released "240202" code. With the latter I will repeat the same test 
from last night.


73 de DG2YCB,
Uwe

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




Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:


>  

I have noticed the same thing at times while running as Hound in F/H where the 
report from the Fox will appear in the Band Activity column but not in the Rx 
Frequency column.I am presently running the "WSJT-X V2.7.1 devel 231031 
Improved PLUS" version.




Also, when the "Start new period decodes at top" checkbox is checked, many 
times a day the background color will change from white to another background 
color. When this occurs it is not always the same color.




Also, at times when using  the  "Start new period decodes at top" option, the 
Band activity columns display will revert back to the earliest decodes, often 
many tens of minutes earlier.




73,

Rich - K1HTV







On Fri, Jan 26, 2024 at 7:55 AM  
wrote:


> Send wsjt-devel mailing list submissions to
>         wsjt-devel@lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
>         wsjt-devel-requ...@lists.sourceforge.net
> 
> You can reach the person managing the list at
>         wsjt-devel-ow...@lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> Today's Topics:
> 
>    1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)
> 
> 
> 
> -- Forwarded message --
> From: Glenn Williams 
> To: wsjt-devel@lists.sourceforge.net
> Cc: 
> Bcc: 
> Date: Thu, 25 Jan 2024 08:12:51 -0500
> Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
> V 2.7.0-rc3
> Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This 
> has happened once or twice before.)  His S/N report on me popped up in 
> Band Act window after my TX1, but no report in RX Freq window. TX3 
> completed OK in both Windows.  I use COLORS and so red was instantly 
> obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the order 
> of 450 watts with tuner. Not thinking RFI because no other times ever I 
> see any.
> 
> -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


___
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-2.7.0-rc3

[Black Michael via wsjt-devel]

You must have old source code in your system somewhere and it's picking up and 
old yaesu.h file.

That is defined in ft9000.c
Hamlib/rigs/yaesu# grep ft9000Old_caps *.c *.hft9000.c:struct rig_caps 
ft9000Old_caps =yaesu.c:    rig_register(_caps);yaesu.h:extern struct 
rig_caps ft9000Old_caps;
Mike W9MDB
 

On Wednesday, January 24, 2024 at 05:13:00 PM CST, Greg Cook via wsjt-devel 
 wrote:  
 
 
Different cmake error but still problems on Pi3. No problems with 2.6.1

  

Greg g4cui

  

Making all in tests

libtool: link: gcc -Wall -g -O2 -fPIC -fdata-sections -ffunction-sections 
-Wl,--gc-sections -o rigctl rigctl-rigctl.o rigctl-rigctl_parse.o 
rigctl-dumpcaps.o rigctl-dumpstate.o rigctl-rig_tests.o  
../src/.libs/libhamlib.a -lusb-1.0 ../lib/.libs/libmisc.a -ldl -lm -pthread

../src/.libs/libhamlib.a(yaesu.o): In function `initrigs4_yaesu':

/home/pi/Downloads/hamlib-prefix/src/hamlib/rigs/yaesu/yaesu.c:127: undefined 
reference to `ft9000Old_caps'

collect2: error: ld returned 1 exit status

Makefile:1118: recipe for target 'rigctl' failed

make[4]: *** [rigctl] Error 1

Makefile:632: recipe for target 'all-recursive' failed

make[3]: *** [all-recursive] Error 1

CMakeFiles/hamlib-install.dir/build.make:65: recipe for target 
'hamlib-prefix/src/hamlib-stamp/hamlib-build' failed

make[2]: *** [hamlib-prefix/src/hamlib-stamp/hamlib-build] Error 2

CMakeFiles/Makefile2:195: recipe for target 'CMakeFiles/hamlib-install.dir/all' 
failed

make[1]: *** [CMakeFiles/hamlib-install.dir/all] Error 2

Makefile:83: recipe for target 'all' failed

make: *** [all] Error 2

  

From: wsjt-devel-requ...@lists.sourceforge.net
Sent: 24 January 2024 16:46
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 119, Issue 42

  

Send wsjt-devel mailing list submissions to

  wsjt-devel@lists.sourceforge.net

  

To subscribe or unsubscribe via the World Wide Web, visit

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

or, via email, send a message with subject or body 'help' to

  wsjt-devel-requ...@lists.sourceforge.net

  

You can reach the person managing the list at

  wsjt-devel-ow...@lists.sourceforge.net

  

When replying, please edit your Subject line so it is more specific

than "Re: Contents of wsjt-devel digest..."

  

  

Today's Topics:

  

   1. Re: Making F/H idiot proof (Reino Talarmo)

   2. Re: Making F/H idiot proof (Jeff Stillinger)

  

  

--

  

Message: 1

Date: Wed, 24 Jan 2024 18:13:10 +0200

From: "Reino Talarmo" 

To: "'WSJT software development'" 

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

Message-ID: <009001da4ee0$3a06dca0$ae1495e0$@kolumbus.fi>

Content-Type: text/plain; charset="utf-8"

  

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 

Re: [wsjt-devel] I have in trouble JT65B of WSJT-X 09th Jan No2

[Black Michael via wsjt-devel]

So I see a Behringer sound card.

Does this setup work or not?

Mike W9MDB








On Monday, January 8, 2024 at 09:04:58 PM CST, JP3EXR  
wrote: 






Hi Mike and the wsjt development team.
 
Thank you for supporting me.
 
Sorry I was unable to send two attached picture of my result because my 
previous email was the overflow.
I attached 2 files of my test result.
Best regard
 
Taka, JP3EXR


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

Re: [wsjt-devel] I have in trouble JT65B of WSJT-X 08th Jan

[Black Michael via wsjt-devel]

For the most part all but one of your "no good" involve the Sound Blaster on an 
Input channel.
So two suggestions.
#1 Put a choke on the audio lines for all your sound lines into the Sound 
Blaster.  Possible RFI into the computer might be locking up the card.#2 
Replace the Sound Blaster with another ASUS.  I assume the driver for the Sound 
Blaster is really old.
Mike W9MDB

 

 

On Monday, January 8, 2024 at 04:29:02 AM CST, JP3EXR via wsjt-devel 
 wrote:  
 
 
Hi wsjt development team.

  

Thank you for supporting me.

I send attached files of the test result, input and output audio port of two 
sound cards, and my system diagram.

  

All combinations have test finished.

Please check the test result of the Excel sheet.

Sorry I don't know why but you are able to see Okay and No good results.

I expected all the test results to be No good, but that was not the case.

Sorry, but I don't understand why this is happening.

Will this result help the development team?

  

I installed just Windows 10 64bit OS and two sound card drivers and two JT65 of 
WSJT-X in advance so I was testing it with the simple PC.

And then I checked all combinations.

I am combination test with the two audio sound cards.

Two inputs and two outputs, total 16 types.

And each test number is a maximum 5 times for tx V and tx H.

Problems might occur if you test more than that number of times.

Unfortunately, the test results did not work with the port I use setting.

I hope you can solve in my trouble it with software.

The test environment of my PC is still in place.

Please contact me if there is anything I can do to help.

  

Taka, JP3EXR
___
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 have in trouble JT65B of WSJT-X number 2

[Black Michael via wsjt-devel]

When it freezes check Task Manager and see if the jt9.exe process is using any 
CPU time.

We need to know if the jt9.exe process is stuck or the user interface is just 
not disabling the decode button.

There have a been other reports of the Decode button getting stuck.

Mike W9MDB


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

Re: [wsjt-devel] I have in trouble JT65B of WSJT-X

[Black Michael via wsjt-devel]

Please confirm what you mean by "freezing".

>From the last pictures you sent it looks like the "Decode" button is still 
>enabled when the decoding stops?

Mike W9MDB


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

Re: [wsjt-devel] I have in trouble JT65B of WSJT-X

[Black Michael via wsjt-devel]

There is a checkbox you need to turn off in the Windows Sound Control Panel.
You can go direct to this control panel by typing "mmsys.cpl" in the search bar 
in Windows.

Right-click your audio device (do this for both Playback and Record).  
Select Properties
Advanced tab
Uncheck "Allow applications to take exclusive control of this device".

Mike W9MDB





On Friday, January 5, 2024 at 06:52:43 AM CST, JP3EXR via wsjt-devel 
 wrote: 





Hi Uwe and the wsjt development team.
Thank you for supporting us with our JT65B problem.
I sent two emails about my situation.
 
Probably my settings is different from other stations.
I ask you the following question.
I have 6 icons and I have 6 folders under AppData Local of two JT65B for H and 
V-pol, Q65A for H and V-pol and FT8 for H and V-pol of WSJT-X.
And I have 2 icons and I have 2 folders under AppData Local of two FT8 for H 
and V-pol of JTDX.
So I have their 8 folders under AppData Local, are those folders causing 
trouble?
And I use the output all of the audio port are the same port as H and V-pol for 
each WSJT and JTDX.
This is because I just use one side of TX which both IC-746pro.
Of course, I use it the same as WSJT-X and JTDX.
Is it okay to use the output audio port of the only one port to all of the 
instances as share on one PC?
 
Taka, JP3EXR
 
From: Uwe, DG2YCB via wsjt-devel  Sent: 
Friday, January 5, 2024 7:44 PMTo: WSJT software development 
Cc: Uwe, DG2YCB Subject: Re: 
[wsjt-devel] I have in trouble JT65B of WSJT-X
 
Hi Taka, Larry, and allI would really like to help you, but the error simply 
does not occur on my PC. I have run numerous tests with two instances this 
morning. Both with WSJT-X v2.6.1 and v2.7.0-rc3 and with wsjt-x_improved 
v2.7.1-devel. I tested various settings (EME delay on/off, with FT-991 CAT 
control vs without (i.e. CAT = None), real transmission via antenna vs virtual 
audio, and so on). Result: There was not a single case where this error 
occurred. It always worked perfectly with JT65B, and with the other modes. The 
decode button did not get stuck, and I was also able to decode my own 
transmissions from the first instance with the second one without any problems 
when using my virtual audio cable. (Due to time constraints, I only tested the 
latter for my 2.7.1-devel version).Very important: The error that the second 
instance hangs after you have transmitted with the first one (visible by the 
fact that the Decode button remains cyan) always occurs if not both instances 
were started with the " --rig-name=InstanceNameXYZ" parameter but only the 
second one. In this case, the "zeroth" instance (that without the " 
--rig-name..." parameter) shoots down all the others. So please make sure once 
again that this is not the case. Perhaps caused by a spelling mistake (" 
-rig-name..." instead of " --rig-name..." or something like that).
73 de DG2YCB,UweGerman Amateur Radio 
Station DG2YCBDr. Uwe RisseeMail: dg2ycb@gmx.deInfo: www.qrz.com/db/DG2YCB
Am 05.01.2024 um 04:19 schrieb Larry Davis via wsjt-devel:
>   
> i can run any of the other modes msk q65 but to try to run 2 jt65b on the 
> same computer one tx and one rxing the second one hang up on decode you can 
> run one all day long no problem i just stoped running two version of jt65b 
> On Thursday, January 4, 2024 at 08:27:45 PM CST, Larry Davis via wsjt-devel 
>  wrote: 
>   
>   
> i don,t think it is a problem with the computer i ran into same problem with 
> 13900k 64 gb of ram with 2 wsjtx open on jt65b second computer 14900k 64gb of 
> ram  same problem  i just think it a bug when you run 2 wsjtx the second one 
> hang up on decodes
>   
> 
> From: JP3EXR via wsjt-devel 
> Sent: Thursday, January 4, 2024 5:28 PM
> To: 'Black Michael' ; wsjt-devel@lists.sourceforge.net 
> 
> Cc: JP3EXR 
> Subject: Re: [wsjt-devel] I have in trouble JT65B of WSJT-X 
>  
> Hi Mike W9MDB
> 
> Good morning from Japan.
> Thank you for your cooperation.
> 
> Thank you for asked me about my current PC spec.
> You are able to see the attached picture of my current PC specification.
> My current PC has 16GB memory and CPU has i7-4790K.
> 
> I used an older PC has 8GB memory and i5 CPU for WSJT-X.
> I thought that my JT65B in problem was caused by the slow speed of my old PC.
> So I was thinking the same thing as Mike until November last year.
> I thought I was able to solve my JT65B problem by replacing it with the 
> current faster PC.
> Then I replaced my older PC to my current PC in November last year.
> But unfortunately, my in problem with run two JT65B cannot be resolved at 
> this time.
> 
> I will test the advice you gave me yesterday on my WSJT PC today.
> Then I will also email you of the test results.
> 
> Thank you
> 
> Taka, JP3EXR
> 
> -Original Message-
> From: Black Michael  
> Sent: Friday, January 5, 2024 2:40 AM
> To: wsjt-devel@lists.sourceforge.net
> Cc: JP3EXR 
> Subject: Re: 

Re: [wsjt-devel] I have in trouble JT65B of WSJT-X

[Black Michael via wsjt-devel]

Your time looks off by quite a bit.  Is your waterfall still working and just 
not decoding?

Check here http://time.is

And you can use Meinberg NTP to keep your time in sync.

Just be careful when installing.  Easy to miss the configuration setup right 
after it shows the installation files scrolling by.

Here's a video showing how to install it...
Mike W9MDB










On Thursday, January 4, 2024 at 03:51:24 AM CST, JP3EXR via wsjt-devel 
 wrote: 






Hi wsjtx development team.
 
Thank you for helping me with my trouble.
 
Sorry I forgot to send you about my trouble situation.
Please check the two attached pictures.
I am sorry for the Japanese display on the two attached screens.
 
Both pictures run two JT65B of WSJT-X on my PC.
Then you know two JT65B were decoding every periods.
 
Please check the sample aa.
I turned on the Enable TX on the left side of two JT65B.
Then on the left side of two JT65B had TXing started at 0721.
The on the right side JT65B was decoding every periods even on the left side of 
two JT65B had TXing started.
You can see the decoding time of the single pass decode on the right side of 
JT65B.
The decoding process of JT65B on the right side became freezing from 0721.
 
Please check the sample ca.
I turned on the Enable TX on the right side of two JT65B.
Then on the right side of two JT65B had TXing started.
Then The decoding process of JT65B on the left side is the same as the sample a.
 
I am checking under what circumstances multiple JT65B are decoding freeze.
I think two JT65B are decoding every periods if both JT65B does not TX.
But JT65B of the TXing side does not decode in the TX period.
I think the decoding freeze of JT65B at the same periods of not TX side of 
JT65B when TXing of JT65B finished of TXing period.
And the decoding freeze may occur immediately at the earliest, or until about 
10 TXing at the latest.
 
Please contact me if you need additional confirmation.
Best regard
Thank you
 
Taka, JP3EXR
___
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 have in trouble JT65B of WSJT-X

[Black Michael via wsjt-devel]

How much memory do you have in your computer?


Mike W9MDB





On Thursday, January 4, 2024 at 03:51:24 AM CST, JP3EXR via wsjt-devel 
 wrote: 






Hi wsjtx development team.
 
Thank you for helping me with my trouble.
 
Sorry I forgot to send you about my trouble situation.
Please check the two attached pictures.
I am sorry for the Japanese display on the two attached screens.
 
Both pictures run two JT65B of WSJT-X on my PC.
Then you know two JT65B were decoding every periods.
 
Please check the sample aa.
I turned on the Enable TX on the left side of two JT65B.
Then on the left side of two JT65B had TXing started at 0721.
The on the right side JT65B was decoding every periods even on the left side of 
two JT65B had TXing started.
You can see the decoding time of the single pass decode on the right side of 
JT65B.
The decoding process of JT65B on the right side became freezing from 0721.
 
Please check the sample ca.
I turned on the Enable TX on the right side of two JT65B.
Then on the right side of two JT65B had TXing started.
Then The decoding process of JT65B on the left side is the same as the sample a.
 
I am checking under what circumstances multiple JT65B are decoding freeze.
I think two JT65B are decoding every periods if both JT65B does not TX.
But JT65B of the TXing side does not decode in the TX period.
I think the decoding freeze of JT65B at the same periods of not TX side of 
JT65B when TXing of JT65B finished of TXing period.
And the decoding freeze may occur immediately at the earliest, or until about 
10 TXing at the latest.
 
Please contact me if you need additional confirmation.
Best regard
Thank you
 
Taka, JP3EXR
___
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 have in trouble JT65B of WSJT-X

[Black Michael via wsjt-devel]

Exclude all of your ham software folders and data locations.
The antivirus programs are interfering with all sorts of ham stuff including 
logging QSOs.  I helped one of the DXpeditions a couple years ago when they 
were losing QSOs in the log due to antivirus scanning of the log file for 
example.


For Windows Defender: 
https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-security


For example I exclude all of these
c:\Program Files (x86)\HamApps
c:\ProgramData\HamApps
c:\WSJT
%LOCALAPPDATA%\WSJT-X (and any other WSJT-X directories for alternate 
configurations)
%LOCALAPPDATA%\HamApps
%HOMEPATH%\flrig.files
%HOMEPATH%\fldigi.files


Also exclude your logging program and it's data files too and database 
location.  I use Log4OMV2 for example
For Log4OM2 I also have
%HOMEPATH%\AppData\Roaming\LogOMV2


Mike W9MDB










On Thursday, January 4, 2024 at 05:34:52 AM CST, Larry Davis via wsjt-devel 
 wrote: 







i see the same problem over the last few years on jt65b when running 2 or 3 
slices on my flex




On Thursday, January 4, 2024 at 03:50:18 AM CST, JP3EXR via wsjt-devel 
 wrote: 






Hi wsjtx development team.
 
Thank you for helping me with my trouble.
 
Sorry I forgot to send you about my trouble situation.
Please check the two attached pictures.
I am sorry for the Japanese display on the two attached screens.
 
Both pictures run two JT65B of WSJT-X on my PC.
Then you know two JT65B were decoding every periods.
 
Please check the sample aa.
I turned on the Enable TX on the left side of two JT65B.
Then on the left side of two JT65B had TXing started at 0721.
The on the right side JT65B was decoding every periods even on the left side of 
two JT65B had TXing started.
You can see the decoding time of the single pass decode on the right side of 
JT65B.
The decoding process of JT65B on the right side became freezing from 0721.
 
Please check the sample ca.
I turned on the Enable TX on the right side of two JT65B.
Then on the right side of two JT65B had TXing started.
Then The decoding process of JT65B on the left side is the same as the sample a.
 
I am checking under what circumstances multiple JT65B are decoding freeze.
I think two JT65B are decoding every periods if both JT65B does not TX.
But JT65B of the TXing side does not decode in the TX period.
I think the decoding freeze of JT65B at the same periods of not TX side of 
JT65B when TXing of JT65B finished of TXing period.
And the decoding freeze may occur immediately at the earliest, or until about 
10 TXing at the latest.
 
Please contact me if you need additional confirmation.
Best regard
Thank you
 
Taka, JP3EXR
___
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] I have in trouble JT65B of WSJT-X

[Black Michael via wsjt-devel]

Can you show the command line you are using to start each of the two JT65B 
programs?
Mike W9MDB

 

On Tuesday, January 2, 2024 at 07:36:17 AM CST, JP3EXR via wsjt-devel 
 wrote:  
 
 
Hello WSJT software development team.

  

Sorry I asked you about in my problem of I run two JT65B of WSJT-X on the 29th 
of December. But I am unable to received your advice yet. Is it able to okay 
accept my problem? I am able to provide various information for you. What 
should I do? 

  

Best regard

  

Taka, JP3EXR
___
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] Release Candidate WSJT-X 2.7.0-rc3

[Black Michael via wsjt-devel]

Look for openssl here
https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.6.1.html

Mike W9MDB 

On Monday, January 1, 2024 at 12:20:11 PM CST, lktenpas--- via wsjt-devel 
 wrote:  
 
 One very minor observation.

I tried to updated the hamlib, 64 bit version.  I have several
radios/instances on my PC for various radios, I tried with 3 installations.
In each case, pushing the Update Hamilb produced the error "Error Loading
Hamlib-r.dll TLS Initialization failed" the first time I tried running.
Attempting a second update greyed out both the Update and Revert button so
they were not accessible.  

I am not sure if the file was updated or not.  

-Original Message-
From: Joe Taylor via wsjt-devel  
Sent: Monday, January 1, 2024 10:00 AM
To: WSJT software development 
Cc: Joe Taylor 
Subject: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc3

Dear WSJT-X Users,

We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc3 is ready
for download by beta testers.

WSJT-X 2.7.0 Release Candidate 3 includes new features as well as bug fixes.
A full list of enhancements can be found in the Release Notes:

https://wsjt.sourceforge.io/wsjtx-doc/Release_Notes_2.7.0-rc3.txt

See also Section 1.1 of the WSJT-X User Guide for this candidate release:

https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0-rc3.html#NEW_FEATURES

Release Candidates are intended for beta testers.  If you download and use
WSJT-X 2.7.0-rc3, please remember to provide feedback to us on the new
features in version 2.7, and on anything that does not seem to work properly
for you.

Direct links to installation packages for Windows, Linux, and macOS can be
found on the WSJT-X page https://wsjt.sourceforge.io/wsjtx.html
Scroll down to the heading "Candidate release:  WSJT-X 2.7.0-rc3".

For those who like to compile from source, a complete source-code tarball is
available at the WSJT-X page. Public access to the git repository for the
WSJT project is also available on the "Git" tab here: 
https://sourceforge.net/projects/wsjt/
It may take a short time for the code to be updated on SourceForge.


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.

The authors and Copyright holders of WSJT-X request that derivative works
should not publish programs based on features in WSJT-X before those
features are made available in a General Availability (GA) release of
WSJT-X.  We will cease making public Release Candidate (RC) pre-releases for
testing and user early access purposes if this request is ignored.

Feedback should be sent to this email list or one of the of the others
mentioned here in the User Guide:

https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0-rc3.html#SUPPORT

We hope you will enjoy using WSJT-X 2.7.0-rc3, and that you will help us to
create a new General Availability (GA) release soon.

    -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG2YCB;
          Brian, N9ADG; and John, G4KLA


___
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] callsigns in <>

[Black Michael via wsjt-devel]

That's correct -- you cannot do two compound calls like that.  It's a known 
limitation of the message format.
There is an option for "full call in..." options but they don't seem to 
honored.  I'm still seeing full call transmitted in all messages.

Would be more than nice if WSJT-X could call ft8code internally and show what 
is actually going to get transmitted.
 1.  W9MDB/4 +11                   W9MDB/4                      
*  4.  Nonstandard call


Mike W9MDB


 

On Wednesday, December 27, 2023 at 09:44:28 AM CST, Bruce Dagel via 
wsjt-devel  wrote:  
 
 WSJT-X version 2.6.1

My mistake, I was going from memory.
The actual problem comes with a longer call.  WB0GAG/1  R+11 
transmits as WB0GAG 

73,
Bruce, WB0GAG


___
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] callsigns in <>

[Black Michael via wsjt-devel]

What version of WSJT-X?
This message seems to encode OK as a standard message.    Is it possible your 
decode window isn't wide enough to see the R+11??
C:\WSJT\wsjtx\bin>ft8code "WB0GAG  R+11"    Message                     
          Decoded                             Err 
i3.n3
 1. WB0GAG  R+11                  WB0GAG  R+11                  
   1.  Standard msg
Mike W9MDB
 

On Wednesday, December 27, 2023 at 08:59:04 AM CST, Bruce Dagel via 
wsjt-devel  wrote:  
 
 While coordinating W1AW/O for Iowa, I observed that I couldn't make some 
contacts because the signal report was cut off, i.e., Tx2 would be 
WB0GAG   when WB0GAG  R+11 should be sent.  I believe it 
is a matter of too many characters.  The called station had nothing to 
confirm.

A solution would appear to be to change so that the angle brackets 
replace the spaces instead of being added to them, i.e. 
WB0GAGR+11, where the angle brackets would do double duty.

73,
Bruce, WB0GAG


___
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] Cannot clone Hamlib fork

[Black Michael via wsjt-devel]

No...that particular fork was created when Hamlib was not getting updated.

Mike W9MDB








On Sunday, December 10, 2023 at 02:27:28 PM CST, Daniel Uppström 
 wrote: 





Oh, that's unfortunate.
I thought this particular fork was necessary for WSJT-X and not the main branch 
of Hamlib?

/SM6VFZ

Den sön 10 dec. 2023 19:22Black Michael via wsjt-devel 
 skrev:
> Since Bill is silent key that repository has been removed.
> 
> The permanent home of Hamlib is here:
> 
> https://github.com/Hamlib/Hamlib
> 
> Mike W9MDB
> 
> 
> 
> 
> 
> 
> On Saturday, December 9, 2023 at 02:33:42 PM CST, Daniel Uppström via 
> wsjt-devel  wrote: 
> 
> 
> 
> 
> 
> Hi,
> When trying to build WSJT-X from source these days I cannot any longer access 
> the Hamlib fork:
> 
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> Cloning into 'src'...
> fatal: remote error: access denied or repository not exported: 
> /u/bsomervi/hamlib
> 
> Any ideas?
> 
> /Daniel SM6VFZ
> 
> ___
> 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] Cannot clone Hamlib fork

[Black Michael via wsjt-devel]

Since Bill is silent key that repository has been removed.

The permanent home of Hamlib is here:

https://github.com/Hamlib/Hamlib

Mike W9MDB






On Saturday, December 9, 2023 at 02:33:42 PM CST, Daniel Uppström via 
wsjt-devel  wrote: 





Hi,
When trying to build WSJT-X from source these days I cannot any longer access 
the Hamlib fork:

git clone git://git.code.sf.net/u/bsomervi/hamlib src
Cloning into 'src'...
fatal: remote error: access denied or repository not exported: 
/u/bsomervi/hamlib

Any ideas?

/Daniel SM6VFZ

___
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] Cannot clone Hamlib fork

[Black Michael via wsjt-devel]

Since Bill is silent key that repository has been removed.
The permanent home of Hamlib is here:
https://github.com/Hamlib/Hamlib

Mike W9MDB

 

On Saturday, December 9, 2023 at 02:33:42 PM CST, Daniel Uppström via 
wsjt-devel  wrote:  
 
 Hi,When trying to build WSJT-X from source these days I cannot any longer 
access the Hamlib fork:
git clone git://git.code.sf.net/u/bsomervi/hamlib src
Cloning into 'src'...
fatal: remote error: access denied or repository not exported: 
/u/bsomervi/hamlib
Any ideas?
/Daniel SM6VFZ
___
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] Auto logging to QRZ.COM

[Black Michael via wsjt-devel]

There are several programs that will log to QRZ.
JTAlertLog4omDXKeeperHam Radio Deluxe
And others that can chime in with their fav'.
Mike W9MDB

 

On Thursday, December 7, 2023 at 03:40:01 PM CST, Marty Wayne via 
wsjt-devel  wrote:  
 
 Is there a way to use UDP or other method to automatically log to QRZ.com log 
book?

Marty waynemcway...@comcast.net



___
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] WSPR and Diversity Receive

[Black Michael via wsjt-devel]

I take it you are running two receivers?   Seems to me a software solution is 
possible.

Do we need to do any more than just average the two?  In your example doesn't 
look like time delays are needed for steering.

Mike W9MDB








On Tuesday, December 5, 2023 at 09:18:28 AM CST, robert evans LAST_NAME via 
wsjt-devel  wrote: 





Having used diversity reception techniques as
far back as the 70s and knowing it was used in
the 40s to improve RTTY reception for mil comms,
that improvement is possible.

An early technique used 2 coherent R-390As and 
dual fsk demod unit.  The antennas were often
of different polarization because they knew
the fading was often due ordinary and
extraordinary propagation though the ionosphere
producing changes in polarization.
But, sometimes just two horizonal antennas far
enough apart offer improvements, for example.
Diversity reception made RTTY via the HF
ionosphere very reliable in the 40s.

Present day wifi benefits from direct sequence
spread spectrum but also mimo.

Knowing the present code in wsjt does not offer
hooks for diversity, but I asked Joe once did it
ever or was it once considered?

There are now two eme antennas at dvra.

N2LO~>




> On 12/05/2023 3:34 AM EST Ben Gelb via wsjt-devel 
>  wrote:
> 
>  
> I have been messing around with WSPR decoding on 630m with a pair of
> phase-locked receivers and two receive antennas.
> 
> I have put together some software to save two sets of coherent samples
> for each 2-minute period, and then after the fact I can combine the
> two sets of samples w/ a configurable relative gain and phase shift.
> 
> I then wrote some scripts to call wsprd repeatedly w/ whilst sweeping
> the gain/phase parameters, and looking at the change in reported SNR.
> 
> My real aim is to help hear a little bit better (i.e. have a higher
> chance of pulling out decodes near the limit) and quantify the
> benefit.
> 
> In latest experiment, I am often able to see 2-3dB improvement in
> reported SNR from wsprd by tweaking gain/phase parameters. I'm
> wondering what this really means. 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? If I happen to have
> cancelled some noise outside of the 150Hz WSPR passband, it might
> improve SNR but not really matter for the purposes of decoding?
> 
> Are there other metrics within the decoder that might provide useful
> feedback for experiments here?
> 
> Thanks for any thoughts/suggestions.
> 
> Ben, N1VF
> 
> 
> ___
> 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] IC-705 little to no decodes

[Black Michael via wsjt-devel]

Check your time

http://time.is

Mike W9MDB








On Monday, December 4, 2023 at 03:57:05 PM CST, robert evans LAST_NAME via 
wsjt-devel  wrote: 








Using a IC-705 over the weekend and after 
installing the usb drivers in a asus win11 
i9 laptop i started WSJT-X 2.7.0-rc2. 

  

The rig control worked fine and the signals 
where being displayed in the spect graph, 
but no decodes. Double checked the time set. 
Still no decodes. 

  

Walked away for many minutes and there were 
decodes when i got back, but only a few. 

Installed WSJT-X 2.6.1 and tried again. 

Same behavior. 

  

Every once in a awhile it would decode a 
frame and then none for long periods of 
time even though the spectrum graph showed 
signals on the waterfall continuously. 

  

Switched to an old dell i3 win10 laptop 
and saw the same behavior with wsjt-x. 

Tried fldigi and it decoded Olivia and 
psk31 as well as cw no problem. 

  

Tried JS8 as well - no problem. 

  

Back to WSJT-X and double checked the 
settings. Every once in a long while 
it might decode what looks like a frame. 

  

N2LO~> 

  

  



___
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 WSPR decoder uploads spur decode instead of main decode for strong signals

[Black Michael via wsjt-devel]

Actually the strongest is not indicative at all of current conditions.  You can 
have momentary band conditions either way.

What matters is what signal you heard them at.  e.g. "I initially received you 
at XXdB".  If a user wants to see band conditions for their callsign they can 
use PSKReporter or HamSpots.net.
One signal report doesn't tell you much.

And does anybody even look at that data anyways?

Mike W9MDB









On Friday, December 1, 2023 at 06:26:37 AM CST, William Smith via wsjt-devel 
 wrote: 





Well, OK, Joe wrote the program, so he really is the ultimate authority.

But the “decoded a spur and used that number for the SNR” seems to be the real 
issue here.

In an ideal world, signals for a particular call should be sorted _after_ all 
the decodes are done, and the strongest (very probably not the spur) should be 
used.

However, if the program flow is “Decode at a random spot on the waterfall, 
queue the results to upload to PSKreporter, set as number to report to QSO 
partner”, and then another one comes along, you have to do all these gyrations 
to determine if it’s ‘better’ and replace it, and unqueue from PSKreporter and 
all this messy stuff.

73, Willie N1JBJ

> On Dec 1, 2023, at 3:53 AM, Geoff Van der Wagen via wsjt-devel 
>  wrote:
> 
> Hi Joe,
> 
> Puzzled by your response.  I agree with not uploading dupes, but I can't 
> fathom why you wouldn't compare dupes and pick the strongest one.  In a 
> situation like this, clearly the strongest signal is representative of the 
> real conditions. I can't think of a use for uploading any other decode, 
> besides as punishment for any stations that dare to have their spurs strong 
> enough to be heard (ironically the worse their transmitter is, the less they 
> get punished).
> 
> Anyway, it sounds like a conscious choice, so good luck with it.
> 
> Regards,
> 
> Geoff VK2WA
> 
> 
> 
> On 1/12/23 13:14, Joe Taylor via wsjt-devel wrote:
>> Hi Geoff,
>> 
>> On 11/30/2023 9:03 PM, Geoff Van der Wagen VK2WA via wsjt-devel wrote:
>>> I just had a funny one with a close station, S9+10dB, the transmission was 
>>> +32 SNR but WSJT-X uploaded only the first decode at -19dB:
>>> 
>>> Queried for all spots me + target, unique NOT ticked:
>>> 
>>> Would have been better to upload the 32dB spot!
>> 
>> Perhaps that would be your choice.  It was not ours.
>> 
>> We don't post duplicate decodes.  Any decode of a message identical to one 
>> already staged for posting in the same Rx sequence is considered a dupe and 
>> discarded.
>> 
>>    -- Joe
>> 
>> 
>> ___
>> 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] Hamlib fork repository

[Black Michael via wsjt-devel]

That sourceforge link is no good anymore since Bill is SK.
Here is the master repo https://github.com/Hamlib/Hamlib
And here are the packages -- https://n0nb.users.sourceforge.net/
Mike W9MDB


> On Nov 7, 2023, at 4:27 PM, Matt Melling via wsjt-devel 
>  wrote:
> 
> Hi,
> 
> I am hacking on the WSJT-X package in NixOS, and looking at how we can
> split out the hamlib fork in to a separate package that can be shared
> with our js8call package.
> 
> The INSTALL references
> https://sourceforge.net/u/bsomervi/hamlib/ci/master/tree/ where the
> latest tag is 4.3.1. The master branch appears to be somewhere between
> 4.3.1 and 4.4, while the tarball (for 2.6.1 which is the current WSJT-X
> we are on) has 4.5.4.
> 
> Is there a publicly accessble repo we can get it from?
> 
> For reference: https://github.com/NixOS/nixpkgs/pull/265897
> 
> 73 Matt G4IYT
> 
> 
> ___
> 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] CQ Hound mode

[Black Michael via wsjt-devel]

The one thing I have noticed on every dxpedition I've worked over the last year 
so
WSJTX Fox mode bill on an 300Hz offset for channel 1.MSHV will normally be 
above  500Hz.
You'll also see MSHV work people calling below 1000Hz.
I can always tell the difference.
And you don't really need Hound mode -- just be prepared to stop the last 73 
tranmission (it's definitely not needed for dxpeditions and just causes QRM).

Mike W9MDB

 

On Monday, November 6, 2023 at 02:31:48 AM CST, Reino Talarmo via 
wsjt-devel  wrote:  
 
 
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 
 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 
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 
 wrote:




> On Nov 5, 2023, at 13:08, Pino Zollo via wsjt-devel 
>  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
___
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?

[Black Michael via wsjt-devel]

It's not a waste of time
Here's why (especially on weak signals or when the band is flaky or QRM).
.start of QSOW9MDB W0YK R-13W0YK W9MDB RR73 -- band goes flaky but I'm 
supposed to think the QSO is done...but you don't decode the RR73.W9MDB W0YK 
R-13 -- you repeat because you didn't get the  RR73 but since our path is flaky 
I don't get this R-13 so I still think I'm done.W9MDB W0YK R-13 -- you repeat 
again -- I still don't receive  youad nauseum until you give up.
I logged you because I sent RR73 and got no other message from you.  You didn't 
log me as you never received RR73.If had sent RRR instead I would repeat 73 
until I got your 73.
That's why it says only use RR73 on a strong signal that you don't expect to 
have any problems with.
Mike W9MDB
 

On Sunday, October 22, 2023 at 12:09:40 AM CDT, Ed W0YK via wsjt-devel 
 wrote:  
 
 RR73 completes the QSO.   Both QSO partners have sent calls, exchanges and 
QSLs.  Am additional 73 message is a waste of time.
73,Ed W0YK

 Original message From: sdegroff via wsjt-devel 
 Date: 10/21/23 13:18 (GMT-08:00) To: WSJT 
software development  Cc: sdegroff 
 Subject: Re: [wsjt-devel] No 73 allowed after RR73? 
I don't know what F/H is,  but i have seen wsjtx hang and not complete the qso 
after RR73.
Stan DeGroff W8SRD


Sent from my Verizon, Samsung Galaxy smartphone

 Original message From: Andy Durbin via wsjt-devel 
 Date: 10/21/23 3:49 PM (GMT-05:00) To: 
wsjt-devel@lists.sourceforge.net Cc: Andy Durbin  Subject: 
[wsjt-devel] No 73 allowed after RR73? 
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] No 73 allowed after RR73?

[Black Michael via wsjt-devel]

Fox/Hound
For dxpeditions...see the Help
Mike W9MDB

 

On Saturday, October 21, 2023 at 11:24:46 PM CDT, sdegroff via wsjt-devel 
 wrote:  
 
 What is F/H mode ?


Sent from my Verizon, Samsung Galaxy smartphone

 Original message From: sdegroff via wsjt-devel 
 Date: 10/21/23 11:22 PM (GMT-05:00) To: WSJT 
software development  Cc: sdegroff 
 Subject: Re: [wsjt-devel] No 73 allowed after RR73? 
Huh?


Sent from my Verizon, Samsung Galaxy smartphone

 Original message From: Andy Durbin via wsjt-devel 
 Date: 10/21/23 7:06 PM (GMT-05:00) To: 
wsjt-devel@lists.sourceforge.net Cc: Andy Durbin  Subject: 
Re: [wsjt-devel] No 73 allowed after RR73? 
After a review of ALL.TXT I no longer think this was related to prior use of 
F/H mode.  I had set TX5 to a "CQ DX message" and that was auto sequenced after 
RR73 was received.
I'll need to be careful to ensure TX5 is set correctly when in QSO. 
73,Andy, k3wyc



From: Andy Durbin
Sent: Saturday, October 21, 2023 12:14 PM
To: wsjt-devel@lists.sourceforge.net 
Subject: No 73 allowed after RR73? 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] Extra characters in ALL.TXT for F/H

[Black Michael via wsjt-devel]

Search the Help file for "a4" or "a3".
Mike W9MDB

 

On Saturday, October 21, 2023 at 07:26:27 AM CDT, Glenn Williams via 
wsjt-devel  wrote:  
 
 Hi,
The following line of text is found once in my huge ALL.TXT file.  Note 
the "a4" far to the right.

V2.6.1  Windows 10 USB-USB to TS590SG DATA port, Special Op F/H, Split->Rig

"231005_005300    24.911 Rx FT8    -20  0.0  720 AF8C RR73; NR4N 
 -14          a4"

The following 2 lines of text are found in K8LBT's ALL.TXT file.  Note 
the "a3" far to the right. (I transcribed this from his email image of 
file; in case the columns appear to have misalignment - it's just my 
typing.)  I do not know whether his file contains more than two instances.

V2.5.4    Windows 10  through Signalink USB, TS590S, microphone port, 
Special Op F/H, SPLIT-> None

"231015_114530    1.836 Rx FT8    -20  1.2  364  K8LBT  W8S  -15
          a3"
...
...
"231015_115000    1.836 Rx FT8    -19  1.1  304  K8LBT  W8S  -19
          a3"

Explanation would be interesting to see. Should I send any of my files 
such as a log?

--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] Fortran runtime error in MAP65 3.0.1

[Black Michael via wsjt-devel]

What version of WSJT-X?

Mike W9MDB








On Tuesday, October 17, 2023 at 06:23:56 AM CDT, Erik Icket via wsjt-devel 
 wrote: 





Dear developers,

The following Fortran runtime error occurred a number of times in MAP65.exe
:

Running: C:\WSJT\wsjtx\bin\m65 -s
At line 13 of file C:\JTSDK64-Tools\WSJTX\BBdevelop\lib\pctile.f90
Fortran runtime error: Index '-240641' of dimension 1 of array 'tmp' below
lower bound of 1

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0 0x
#1 0x
#2 0x
#3 0x
#4 0x
#5 0x
#6 0x
#7 0x
#8 0x
#9 0x
#10 0x
#11 0x
#12 0x
#13 0x
#14 0x
#15 0x
#16 0x


I have the impression this error occurs more frequently in the presence of
strong interference signals in the passband of MAP65.
Also, MAP65 runs with selected mode Q65A and JT65B.

For information, MAP65 (and QMAP) received its baseband feed from the new
MAP65/QMAP interface built into SDRConsole 3.3

73's Erik
ON4PB




___
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-improved-community] [wsjtgroup] Solar Eclipse participation #general

[Black Michael via wsjt-devel]

I got some more info from the HamSCI group.  So if you could maintain one band 
for the duration of the  SEQP that would be best.
>From W2NAF
The SEQP is going to run for 10 hours from 1200-2200 UTC. See 
https://hamsci.org/seqp-rules
 

What we actually analyze will depend on the quality of the data we receive. We 
will likely be building off of the analysis published in 
https://doi.org/10.1029/2018GL077324, which focused on 1.8, 3.5, 7, and 14 MHz. 
We are also now at a higher point in the solar cycle, so hopefully the higher 
bands will also be useful.

 

TNX es 73 Nathaniel W2NAF



> 
> On 9/15/2023 1:04 PM, Mike Black W9MDB via groups.io wrote:
>> 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
>>
>> _._,_._,_
>> 
>> Groups.io Links:
>>
>> You receive all messages sent to this group.
>>
>> View/Reply Online (#1104)  
>> | Reply To Group 
>> 
>>  | Reply To Sender 
>> 
>>  | Mute This Topic  | New Topic 
>> 
>> Mute #general 
>> Your Subscription  | 
>> Contact Group Owner  | Unsubscribe 
>>  
>> [a...@alumni.caltech.edu]
>>
>> _._,_._,_
> 


___
Wsjt-x-improved-community mailing list
wsjt-x-improved-commun...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Solar Eclipse participation #general

[Black Michael via wsjt-devel]

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

[Black Michael via wsjt-devel]

Many fewer harmonics generators now than in the past.
WA1SXK and I went on the war path for the last several years contacting 
everybody we saw and getting them fixed.The FT8Noise paper on my QRZ page is 
the result of testing with numerous rigs and explains it all.
Mike W9MDB

 

On Tuesday, September 5, 2023 at 08:37:07 AM CDT, Lance Collister, W7GJ via 
wsjt-devel  wrote:  
 
  
TNX Mike! I am amazed how many people I keep seeing on the air who are 
transmitting audio harmonics and don't understand that they need to have the 
XMTR frequency changed if they want to select XMIT offsets lower than 1500 Hz.  
They insist that they have checked their audio and it is not overdriving their 
amp...
 
 
GL and VY 73, Lance
 
 On 5 Sept 2023 11:48, Black Michael via wsjt-devel wrote:
  
 
  No -- the target is not good quality of signals -- that's misleading 
tooit's all about shifting the audio (actually shifting the suppressed 
carrier). 
  #1 Avoid transmit band edges (rigs can actually transmit outside of their 
bandpass) #2 Avoid harmonics #3 Avoid non-linear power behavior (some rigs 
don't transmit the same power on all frequencies) 
   This thing has historically been brought up every few years and nobody has  
come up with better terminology. I will propose this. 
  Box title -- "Audio shift method" in lieu of "Split Operation". Then we leave 
the others alone but update the tool tips to use "audio shift" in their 
description instead  of "split". None/Rig/Fake It 
  No mention of split needed except in the manual describing what this does in 
detail.   
  Mike W9MDB 
  On Tuesday, September 5, 2023 at 06:10:38 AM CDT, Henryk Majcher via 
wsjt-devel  wrote:  
  
 Hi Jim 
  I agree - it is a very frustrating situation, especially for foreign users 
with English language problems. 
  The target is the good quality of signals. So the title: "Split Operation" is 
bad. Split operation is one of the ways to get it. "None" is OK. "Rig" is not 
OK, it should be "Rig SPLIT". "Fake It" is not OK, it should be "Like Split" or 
"Kind Of Split" or "Special Split" or "WSJT Shift". 
       I mean "SPLIT" - the button and "Split" - the word. 
  
  My proposal title and others is: 
  
  
  Signal Quality Special Management 
  O  None                          O  Rig SPLIT                        O  WSJT 
Shift 
  
  
  Sorry for poor English 
  73 Henryk  SP3E 
  
   
  wt., 5 wrz 2023 o 10:29 Reino Talarmo via wsjt-devel 
 napisał(a):
   
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 yea

Re: [wsjt-devel] Split

[Black Michael via wsjt-devel]

No -- the target is not good quality of signals -- that's misleading 
tooit's all about shifting the audio (actually shifting the suppressed 
carrier).
#1 Avoid transmit band edges (rigs can actually transmit outside of their 
bandpass)#2 Avoid harmonics#3 Avoid non-linear power behavior (some rigs don't 
transmit the same power on all frequencies)
This thing has historically been brought up every few years and nobody has  
come up with better terminology.I will propose this.
Box title -- "Audio shift method" in lieu of "Split Operation".Then we leave 
the others alone but update the tool tips to use "audio shift" in their 
description instead  of "split".None/Rig/Fake It
No mention of split needed except in the manual describing what this does in 
detail. 
Mike W9MDB
On Tuesday, September 5, 2023 at 06:10:38 AM CDT, Henryk Majcher via 
wsjt-devel  wrote:  
 
 Hi Jim
I agree - it is a very frustrating situation, especially for foreign users with 
English language problems.
The target is the good quality of signals. So the title:"Split Operation" is 
bad. Split operation is one of the ways to get it."None" is OK."Rig" is not OK, 
it should be "Rig SPLIT"."Fake It" is not OK, it should be "Like Split" or 
"Kind Of Split" or "Special Split" or "WSJT Shift".
     I mean "SPLIT" - the button and "Split" - the word.

My proposal title and others is:


Signal Quality Special Management
O  None                          O  Rig SPLIT                        O  WSJT 
Shift


Sorry for poor English
73Henryk  SP3E


wt., 5 wrz 2023 o 10:29 Reino Talarmo via wsjt-devel 
 napisał(a):

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 

Re: [wsjt-devel] Button sizes not correct

[Black Michael via wsjt-devel]

You have to reposition the windows once.  You can't switch back and forth.
Also try setting that value to 1 instead of 0 and see what difference it makes.

 

On Friday, September 1, 2023 at 12:54:40 PM CDT, mark mgg4.com 
 wrote:  
 
 
All of them.  Most annoying is the Log popup which I have positioned for easy 
tapping (touch screen).
 
  
 
  
 
--Mark
 
  
 
From: Black Michael  
Sent: Friday, September 1, 2023 10:52 AM
To: WSJT software development ; Mark 
Galbraith 
Cc: mark mgg4.com 
Subject: Re: [wsjt-devel] Button sizes not correct
 
  
 
Which windows?
 
  
 
  
 
  
 
  
 
On Friday, September 1, 2023 at 12:46:50 PM CDT, Mark Galbraith  
wrote:
 
  
 
  
 
After a few more experiments, I’ve reverted this change.  The program no longer 
remembers where certain windows open on the screen, opening all windows in the 
center.  This is a bit more disruptive than the narrow buttons.
 
 
 
--Mark, N7YD
 
 
 
 
 
From: mark mgg4.com via wsjt-devel 
Sent: Friday, September 1, 2023 10:37 AM
To: Black Michael ; WSJT software development 

Cc: mark mgg4.com 
Subject: Re: [wsjt-devel] Button sizes not correct
 
 
 
Thank you.  That does change a few things, and some of the text seems a bit 
less sharp, but it does fix the problem and I like the overall effect better.  
I very much appreciate your response.
 
 
 
 
 
--Mark, N7YD
 
 
 
 
 
 
 
From: Black Michael via wsjt-devel 
Sent: Friday, September 1, 2023 9:25 AM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Button sizes not correct
 
 
 
Try this to replace the qt.conf in your bin directory
 
 
 
[Paths]
 
Plugins = ../plugins
 
 
 
[Platforms]
 
WindowsArguments = dpiawareness=0
 
 
 
 
 
Mike W9MDB
 
 
 
 
 
On Thursday, August 31, 2023 at 10:43:43 PM CDT, Laurie, VK3AMA via wsjt-devel 
 wrote: 
 
 
 
 
 
On 01/09/2023 8:15 am, Mark Galbraith via wsjt-devel wrote:
 

Not sure what’s happening here, but my guess would be that the screen 
resolution may be off, but I was seeing this on other computers as well.


 
 
 
My computer is a Microsoft Surfacebook 2, with a screen resolution of 3240 x 
2160.  I was also seeing the same thing on my other computer with a 32” ultra 
widescreen resolution of 2560 x 1080.  I’m also seeing this on v2.6.1 and 
v2.7.0-rc2.  Is there a setting I need to adjust, or is this something that 
requires a program change to fix?
 
 
 
 
 
73
 
-.. . / -- .- .-. -.- / -. --... -.-- -..
 
DE  MARK  N7YD
 



A long standing defect that I gave up on getting the devs to correct.

All other UI controls inducing the Tx1-6 buttons are scaled correctly except 
these buttons!

Here's mine, like you replicated across multiple devices.


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

Re: [wsjt-devel] Button sizes not correct

[Black Michael via wsjt-devel]

Which windows?

 

On Friday, September 1, 2023 at 12:46:50 PM CDT, Mark Galbraith 
 wrote:  
 
 
After a few more experiments, I’ve reverted this change.  The program no longer 
remembers where certain windows open on the screen, opening all windows in the 
center.  This is a bit more disruptive than the narrow buttons.
 
  
 
--Mark, N7YD
 
  
 
  
 
From: mark mgg4.com via wsjt-devel 
Sent: Friday, September 1, 2023 10:37 AM
To: Black Michael ; WSJT software development 

Cc: mark mgg4.com 
Subject: Re: [wsjt-devel] Button sizes not correct
 
  
 
Thank you.  That does change a few things, and some of the text seems a bit 
less sharp, but it does fix the problem and I like the overall effect better.  
I very much appreciate your response.
 
  
 
  
 
--Mark, N7YD
 
  
 
  
 
  
 
From: Black Michael via wsjt-devel 
Sent: Friday, September 1, 2023 9:25 AM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Button sizes not correct
 
  
 
Try this to replace the qt.conf in your bin directory
 
  
 
[Paths]
 
Plugins = ../plugins
 
  
 
[Platforms]
 
WindowsArguments = dpiawareness=0
 
  
 
  
 
Mike W9MDB
 
  
 
  
 
On Thursday, August 31, 2023 at 10:43:43 PM CDT, Laurie, VK3AMA via wsjt-devel 
 wrote: 
 
  
 
  
 
On 01/09/2023 8:15 am, Mark Galbraith via wsjt-devel wrote:
 

Not sure what’s happening here, but my guess would be that the screen 
resolution may be off, but I was seeing this on other computers as well.


 
 
 
My computer is a Microsoft Surfacebook 2, with a screen resolution of 3240 x 
2160.  I was also seeing the same thing on my other computer with a 32” ultra 
widescreen resolution of 2560 x 1080.  I’m also seeing this on v2.6.1 and 
v2.7.0-rc2.  Is there a setting I need to adjust, or is this something that 
requires a program change to fix?
 
 
 
 
 
73
 
-.. . / -- .- .-. -.- / -. --... -.-- -..
 
DE  MARK  N7YD
 



A long standing defect that I gave up on getting the devs to correct.

All other UI controls inducing the Tx1-6 buttons are scaled correctly except 
these buttons!

Here's mine, like you replicated across multiple devices.


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

Re: [wsjt-devel] Button sizes not correct

[Black Michael via wsjt-devel]

Try this to replace the qt.conf in your bin directory
[Paths]Plugins = ../plugins
[Platforms]WindowsArguments = dpiawareness=0

Mike W9MDB 

On Thursday, August 31, 2023 at 10:43:43 PM CDT, Laurie, VK3AMA via 
wsjt-devel  wrote:  
 
  On 01/09/2023 8:15 am, Mark Galbraith via wsjt-devel wrote:
 
 
Not sure what’s happening here, but my guess would be that the screen 
resolution may be off, but I was seeing this on other computers as well.
 
 
 
  
 
My computer is a Microsoft Surfacebook 2, with a screen resolution of 3240 x 
2160.  I was also seeing the same thing on my other computer with a 32” ultra 
widescreen resolution of 2560 x 1080.  I’m also seeing this on v2.6.1 and 
v2.7.0-rc2.  Is there a setting I need to adjust, or is this something that 
requires a program change to fix?
 
  
 
  
 
73
 
-.. . / -- .- .-. -.- / -. --... -.-- -..
 
DE  MARK  N7YD
 
 
 
 A long standing defect that I gave up on getting the devs to correct.
 
 All other UI controls inducing the Tx1-6 buttons are scaled correctly except 
these buttons!
 
 Here's mine, like you replicated across multiple devices.
 
 
 de Laurie VK3AMA
 
 
 ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with Hamlib

[Black Michael via wsjt-devel]

Shut down WSJTX.

Rename C:\Users\[username]\AppData\Local\WSJT-X\WSJT-X.ini

Then start WSJTX again -- it will be new config.  

See if that fixed the problem.  If it does please send in the old WSJT-X.ini 
file.

Mike W9MDB








On Tuesday, August 29, 2023 at 12:39:25 AM CDT, on4...@telenet.be 
 wrote: 





Hi Mike,
hanks for the info. But I have already tested both COM ports. I had seen in 
device manager and there COM ports 3 and 4 were assigned. I have tested both 
but always with the Hamlib error message. I'm going to compare this evening 
again with the settings that Uwe, DG2YCB sent me. I may find a solution there. 
I'll keep you informed.

Thanks in advance.
ON4CKT Rudy

- Oorspronkelijk bericht -
Van: "Black Michael via wsjt-devel" 
Aan: "on4ckt--- via wsjt-devel" 
Cc: "Black Michael" 
Verzonden: Maandag 28 augustus 2023 23:08:50
Onderwerp: Re: [wsjt-devel] Problem with Hamlib

That makes it sound like it's the wrong port.

You should have two COM ports -- the Extended port is the one you want.

Mike W9MDB








On Monday, August 28, 2023 at 10:07:56 AM CDT, on4ckt--- via wsjt-devel 
 wrote: 






Hello, today I tried to install WSJT-X v2.7.0-rc2 on my laptop Windows10 and 
connect via CAT to my Yaesu FT991. But I get the following error message in 
WSJT-X. 

Hamlib error: rig_settings_get_path: path=.hamlib_settings
rig_settings_load_all: settings_file (.hamlib_settings): No such file or 
directory
rig_open: cwd=C:\WSJT\wsjtx
rig_open: C:\WSJT\wsjtx/hamlib_settings does not exist
rig_open: async_data_enable=1, async_data_supported=0
serial_open: COM3
serial_setup: tcgetattr
serial_setup: cfsetispeed=38400,0x000f
serial_setup: cfsetospeed=38400,0x000f
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: Handshake=Hardware
serial_setup: tcsetattr TCSANOW
serial_setup: tcsetattr failed: No error
port_open: serial_open(COM3) status=-2, err=No error
rig_open: rs->comm_state==0?=0
rig.c(1069):rig_open returning2(-2) Invalid configuration

Invalid configuration
Invalid configuration
while opening connection to rig

Timestamp: 2023-08-28T14:46:31.621Z

On the transceiver I have adjusted the following parameters: 029=38400, 
030=10msec, 031=38400, 062=OTHERS, 064=1500Hz, 066=OFF, 068=OFF, 070=REAR, 
071=DAKY and 072=USB. Can someone help me further with this. 

Thanks in advance.

-- 
73's ON4CKT Rudy
https://www.qsl.net/on4ckt
___
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

-- 
73's ON4CKT Rudy
https://www.qsl.net/on4ckt


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

Re: [wsjt-devel] Problem with Hamlib

[Black Michael via wsjt-devel]

That makes it sound like it's the wrong port.

You should have two COM ports -- the Extended port is the one you want.

Mike W9MDB








On Monday, August 28, 2023 at 10:07:56 AM CDT, on4ckt--- via wsjt-devel 
 wrote: 






Hello, today I tried to install WSJT-X v2.7.0-rc2 on my laptop Windows10 and 
connect via CAT to my Yaesu FT991. But I get the following error message in 
WSJT-X. 

Hamlib error: rig_settings_get_path: path=.hamlib_settings
rig_settings_load_all: settings_file (.hamlib_settings): No such file or 
directory
rig_open: cwd=C:\WSJT\wsjtx
rig_open: C:\WSJT\wsjtx/hamlib_settings does not exist
rig_open: async_data_enable=1, async_data_supported=0
serial_open: COM3
serial_setup: tcgetattr
serial_setup: cfsetispeed=38400,0x000f
serial_setup: cfsetospeed=38400,0x000f
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: Handshake=Hardware
serial_setup: tcsetattr TCSANOW
serial_setup: tcsetattr failed: No error
port_open: serial_open(COM3) status=-2, err=No error
rig_open: rs->comm_state==0?=0
rig.c(1069):rig_open returning2(-2) Invalid configuration

Invalid configuration
Invalid configuration
while opening connection to rig

Timestamp: 2023-08-28T14:46:31.621Z

On the transceiver I have adjusted the following parameters: 029=38400, 
030=10msec, 031=38400, 062=OTHERS, 064=1500Hz, 066=OFF, 068=OFF, 070=REAR, 
071=DAKY and 072=USB. Can someone help me further with this. 

Thanks in advance.

-- 
73's ON4CKT Rudy
https://www.qsl.net/on4ckt
___
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] Bug Report WSJT-X 2.7.0-RC2: Rig Control Error pops up when adjusting TX slot frequency

[Black Michael via wsjt-devel]

New hamlib for installation directions

#1 Shut down WSJTX

#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of 
WSJTX -- hopefully your browser doesn't block it but may warn you multiple 
times.

If you can do a "Save As" you can save it directly in the appropriate WSJTX 
directory
C:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.

http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll

http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll

Linux/Unix/Mac users need to compile the latest tar file from 
http://n0nb.users.sourceforge.net
Note: If compiling on Unix-like systems please uninstall any Hamlib package you 
have before installing the new build

#3 If you don't save directly you need to open a file browser and move the file 
that way.

If you're not familiar with that here's a video on the file browser - 
https://www.youtube.com/watch?v=AyVqCJrs9dk

Once installed on Linux do "ldconfig".

rigctl --version should then show a relatively recent date of the download


Then if you still have the problem...
Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0

C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location

For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X

For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X

Then send me the WSJT-X_RigControl.log file
Mike W9MDB





On Monday, August 28, 2023 at 02:45:23 AM CDT, Mark Galbraith via wsjt-devel 
 wrote: 





  


When using Shift-click on the waterfall to set the TX frequency, the “Rig 
Control Error” popup is displayed.  Clicking the “Show Details…” button shows 
the following error information:


Hamlib error: port_wait_for_data_direct(733): timeout=1,0

port_wait_for_data_direct(742): timeout=1,0

read_string_generic(): RX 1 characters, direct=1

 3b ; 

newcat_set_cmd_validate: cmd validation failed, 'MD1C;'!=';', try#8

9:newcat.c(10969):newcat_set_cmd_validate returning(-8) Protocol error

 

newcat_set_cmd: set_cmd_validate failed

8:newcat.c(11010):newcat_set_cmd returning(-8) Protocol error

 

7:newcat.c(1528):newcat_set_mode returning(-8) Protocol error

 

6:rig_set_split_mode: elapsed=806ms

6:rig.c(4647):rig_set_split_mode returning(-8) Protocol error

 

5:rig_set_split_freq_mode: elapsed=911ms

5:rig.c(5022):rig_set_split_freq_mode returning(-8) Protocol error

 

Protocol error

Protocol error

while setting split TX frequency and mode

 

Timestamp: 2023-08-28T02:28:24.231Z

 

 

This error has not occurred using WSJT-X 2.6.1.  My configuration is as follows:

Radio: Yaesu FT-710

Software stack:

 
* Win4YaesuSuite (latest version)
 
* Software control of the radio.  Also provides virtual COM ports 
(using com0com) to allow additional software to access the CAT control stream.
* CAT connection to radio on COM3.  Provides CAT virtual CAT 
connections on COM7, COM9, COM11, COM13, and COM15.
* 3rd party software connections are mentioned below.  COM13 and COM15 
connections are used for unrelated programs not involved in FT8/FT4 operation.

* DXLabs Suite (latest version)
 
* Has additional software control features for the radio but lacked the 
virtual COM support.  Control program needed to support additional functions of 
the suite.
* Used for general logging and other functions.
* Connects to CAT interface on COM9

* N1MM+ (latest version)
 
* Used for contest logging.
* Connects to CAT interface on COM11

* WSJT-X
 
* Normally use 2.6.1.  Downloaded 2.7.0-RC2 to check out some of the 
new features.
* Connects to CAT interface on COM7

* JTAlert for WSJT-X (latest version)
 
* Better visual representation of decodes.


 

The DXLabs and N1MM+ portions of the stack are not involved in this error as 
they are not in the stack between WSJT-X and the radio.  They are shown for 
completeness. 

 

Please let me know if you have any questions or need more information to help 
track this down.  For now I have reverted back to v2.6.1 so I can continue 
working FT8/FT4.

 

 

73

-.. . / -- .- .-. -.- / -. --... -.-- -..

DE  MARK  N7YD

 



___
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] #Echo Echo shifts TX frequency when clicking "Set RX & TX offset" - should be disabled

[Black Michael via wsjt-devel]

I can duplicate the behavior here with my Apache 7000 and Thetis.
Using RC2 here.

Both the Tune button and Enable Tx follow the 500hz offsets.

Both Fake It and Rig Split behave this way.

Split=None works correctly.

Mike W9MDB








On Thursday, August 3, 2023 at 03:13:30 PM CDT, Andreas Junge via wsjt-devel 
 wrote: 





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 
 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


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

Re: [wsjt-devel] VFO readout on FT8 shutdown

[Black Michael via wsjt-devel]

No...Yaesu rigs do not have  CI-V transceive.
Mike W9MDB 

On Thursday, July 20, 2023 at 03:21:36 PM CDT, Marco Calistri 
 wrote:  
 
  Il 20/07/23 16:07, Christoph Berg ha scritto:
  
 
 Check if CIV Transceive is off.
 
 Christoph DF7CB 
 
 What is it? CIV...
 
 Are you sure that Yaesu FT-100 has this feature available?
 
 
 ---
 73 de Marco, PY1ZRJ (former IK5BCU)
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO readout on FT8 shutdown

[Black Michael via wsjt-devel]

It's on github
Mike W9MDB

 

On Thursday, July 20, 2023 at 10:33:40 AM CDT, Marco Calistri 
 wrote:  
 
 Do you have the link for the source hamlib?
I'm using Linux (mainly).
If this newer version is on GitHub,  I can try compiling from it.
Regards,
Marco, PY1ZRJ 
Inviato da Outlook per AndroidFrom: Black Michael 
Sent: Thursday, July 20, 2023 12:28:54 PM
To: WSJT software development ; Marco 
Calistri 
Subject: Re: [wsjt-devel] VFO readout on FT8 shutdown Please test the latest 
hamlib.
https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0

Some rigs cannot change frequency while transmitting.  Are you using VOX?  
SignaLink?
Some fixes were put in for these Yaeus rigs with this problem so hopefully this 
works now for the FT-100 too.
If notPlease place this file as described 
belowhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0
C:\Users\[username]\AppData\Local\WSJT-XThe WSJT-X_Rigcontrol.log file will be 
in the same location
For Linux put it in  ~/.configThe WSJT-X_Rigcontrol.log file will be 
here:~/.local/share/WSJT-X
For MacOS put it in/Users/[username]/Library/Preferences Restart WSJT-X and 
duplicate the problem.Shut down WSJT-X
Then send me the WSJT-X_RigControl.log fileMike W9MDB







On Thursday, July 20, 2023 at 09:45:37 AM CDT, Marco Calistri 
 wrote:

I face a similar behavior which last for two or three transmissions sequences 
at the beginning of my FT8 session.
This phenomenal started since some months then if it is due Hamlib, it is 
something that is being dragged along the new releases.
In my case (using an Yaesu FT-100, mode rig split) starting for example the 
transmission on 28074 Mhz, on RX vfo, during the 15 seconds TX displays 28073, 
at RX switch the RX vfo shifts to 28073, then TX vfo during the second 
transmission, shifts to 28072 Mhz. At third sequence the behavior repeats, so 
RX is now at 28072 and TX shifts to 28071.
To correct it, I need to switch the frequency bands selector of WSJTX back to 
28074.
Then the next sequences of RX/TX, after my manual intervention, keeps stably 
within the 1 Khz shift: 28074 RX and 28073 TX.
This is not a blocking issue to me but it is a bit annoying having to correct 
manually.
Regards,
Marco, PY1ZRJ 
Inviato da Outlook per AndroidFrom: Black Michael via wsjt-devel 

Sent: Thursday, July 20, 2023 10:42:39 AM
To: wsjt-devel@lists.sourceforge.net 
Cc: Black Michael 
Subject: Re: [wsjt-devel] VFO readout on FT8 shutdown That's what you get when 
you start smooshing buttons.
Here's what happened.
You swap VFOs -- WSJT-X doesn't care.You exit -- WSJT-X saves the VFOB 
frequency as the "last frequency" used.You start again -- if you have "Monitor 
returns to last used frequency" it  will then load VFOB's frequency into 
VFOA.Of course rig split will set VFOB based on VFOA's frequency.
So...
#1 Don't smoosh buttons unless you know what you are doing#2 Turn off "Monitor 
returns"
Mike W9MDB




On Thursday, July 20, 2023 at 01:38:29 AM CDT, Glenn Williams via wsjt-devel 
 wrote:

Hello,
Comment: The following Human Induced confusion of VFO frequency occurs 
on FT8 shutdown. Not necessarily a "bug" in WSJT-X. Just thought
I would send out the information.

Setup:  Windows 10, Kenwood TS590SG, USB cable driven, both WSJT-X 2.6.1 
and 2.7.0-rc2. Bands: at least on HF bands.  Everything going well as 
usual.  TX frequency high enough to separate VFO A and VFO B by 1.000 
kHz (RIG SPLIT) in this example.

Action creating problem:  Human manually toggles VFO A/B button. Now VFO 
B is in the main position, VFO A on the side, no frequency changes have 
occurred in either VFO.  Next steps:  EXIT out of WSJT-X. Restart 
WSJT-X.  Now VFO A displays what VFO B was displaying. VFO B is still 1 
kHz higher, which is now 2 kHz from the original.  Examples follow.

TX  = 2800 Hz
  PC          rig        rig
FT8 Display  VFO A      VFO B
24915.00    24915.00  24916.00 <-A on main, B on side. Not in QSO.
Toggle A/B on rig.
24916.00    24915.00  24916.00 <-B on main, A on side. Not in QSO.
EXIT and restart. Symptoms begin.
24916.00    24916.00  24917.00 <-A on main, B on side. Not in QSO.

This effect also might happen on other CAT-based rigs?
Problem with hamlib?

--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] VFO readout on FT8 shutdown

[Black Michael via wsjt-devel]

Please test the latest hamlib.
https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0

Some rigs cannot change frequency while transmitting.  Are you using VOX?  
SignaLink?
Some fixes were put in for these Yaeus rigs with this problem so hopefully this 
works now for the FT-100 too.
If notPlease place this file as described 
belowhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0
 C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will 
be in the same location
For Linux put it in   ~/.config The WSJT-X_Rigcontrol.log file will be here: 
~/.local/share/WSJT-X
For MacOS put it in /Users/[username]/Library/Preferences Restart WSJT-X and 
duplicate the problem.Shut down WSJT-X
Then send me the WSJT-X_RigControl.log fileMike W9MDB





 

On Thursday, July 20, 2023 at 09:45:37 AM CDT, Marco Calistri 
 wrote:  
 
 I face a similar behavior which last for two or three transmissions sequences 
at the beginning of my FT8 session.
This phenomenal started since some months then if it is due Hamlib, it is 
something that is being dragged along the new releases.
In my case (using an Yaesu FT-100, mode rig split) starting for example the 
transmission on 28074 Mhz, on RX vfo, during the 15 seconds TX displays 28073, 
at RX switch the RX vfo shifts to 28073, then TX vfo during the second 
transmission, shifts to 28072 Mhz. At third sequence the behavior repeats, so 
RX is now at 28072 and TX shifts to 28071.
To correct it, I need to switch the frequency bands selector of WSJTX back to 
28074.
Then the next sequences of RX/TX, after my manual intervention, keeps stably 
within the 1 Khz shift: 28074 RX and 28073 TX.
This is not a blocking issue to me but it is a bit annoying having to correct 
manually.
Regards,
Marco, PY1ZRJ 
Inviato da Outlook per AndroidFrom: Black Michael via wsjt-devel 

Sent: Thursday, July 20, 2023 10:42:39 AM
To: wsjt-devel@lists.sourceforge.net 
Cc: Black Michael 
Subject: Re: [wsjt-devel] VFO readout on FT8 shutdown That's what you get when 
you start smooshing buttons.
Here's what happened.
You swap VFOs -- WSJT-X doesn't care.You exit -- WSJT-X saves the VFOB 
frequency as the "last frequency" used.You start again -- if you have "Monitor 
returns to last used frequency" it  will then load VFOB's frequency into 
VFOA.Of course rig split will set VFOB based on VFOA's frequency.
So...
#1 Don't smoosh buttons unless you know what you are doing#2 Turn off "Monitor 
returns"
Mike W9MDB




On Thursday, July 20, 2023 at 01:38:29 AM CDT, Glenn Williams via wsjt-devel 
 wrote:

Hello,
Comment: The following Human Induced confusion of VFO frequency occurs 
on FT8 shutdown. Not necessarily a "bug" in WSJT-X. Just thought
I would send out the information.

Setup:  Windows 10, Kenwood TS590SG, USB cable driven, both WSJT-X 2.6.1 
and 2.7.0-rc2. Bands: at least on HF bands.  Everything going well as 
usual.  TX frequency high enough to separate VFO A and VFO B by 1.000 
kHz (RIG SPLIT) in this example.

Action creating problem:  Human manually toggles VFO A/B button. Now VFO 
B is in the main position, VFO A on the side, no frequency changes have 
occurred in either VFO.  Next steps:  EXIT out of WSJT-X. Restart 
WSJT-X.  Now VFO A displays what VFO B was displaying. VFO B is still 1 
kHz higher, which is now 2 kHz from the original.  Examples follow.

TX  = 2800 Hz
  PC          rig        rig
FT8 Display  VFO A      VFO B
24915.00    24915.00  24916.00 <-A on main, B on side. Not in QSO.
Toggle A/B on rig.
24916.00    24915.00  24916.00 <-B on main, A on side. Not in QSO.
EXIT and restart. Symptoms begin.
24916.00    24916.00  24917.00 <-A on main, B on side. Not in QSO.

This effect also might happen on other CAT-based rigs?
Problem with hamlib?

--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] VFO readout on FT8 shutdown

[Black Michael via wsjt-devel]

That's what you get when you start smooshing buttons.
Here's what happened.
You swap VFOs -- WSJT-X doesn't care.You exit -- WSJT-X saves the VFOB 
frequency as the "last frequency" used.You start again -- if you have "Monitor 
returns to last used frequency" it  will then load VFOB's frequency into 
VFOA.Of course rig split will set VFOB based on VFOA's frequency.
So...
#1 Don't smoosh buttons unless you know what you are doing#2 Turn off "Monitor 
returns"
Mike W9MDB


 

On Thursday, July 20, 2023 at 01:38:29 AM CDT, Glenn Williams via 
wsjt-devel  wrote:  
 
 Hello,
Comment: The following Human Induced confusion of VFO frequency occurs 
on FT8 shutdown. Not necessarily a "bug" in WSJT-X. Just thought
I would send out the information.

Setup:  Windows 10, Kenwood TS590SG, USB cable driven, both WSJT-X 2.6.1 
and 2.7.0-rc2. Bands: at least on HF bands.  Everything going well as 
usual.  TX frequency high enough to separate VFO A and VFO B by 1.000 
kHz (RIG SPLIT) in this example.

Action creating problem:  Human manually toggles VFO A/B button. Now VFO 
B is in the main position, VFO A on the side, no frequency changes have 
occurred in either VFO.  Next steps:  EXIT out of WSJT-X. Restart 
WSJT-X.  Now VFO A displays what VFO B was displaying. VFO B is still 1 
kHz higher, which is now 2 kHz from the original.  Examples follow.

TX  = 2800 Hz
  PC          rig        rig
FT8 Display  VFO A      VFO B
24915.00    24915.00  24916.00 <-A on main, B on side. Not in QSO.
Toggle A/B on rig.
24916.00    24915.00  24916.00 <-B on main, A on side. Not in QSO.
EXIT and restart. Symptoms begin.
24916.00    24916.00  24917.00 <-A on main, B on side. Not in QSO.

This effect also might happen on other CAT-based rigs?
Problem with hamlib?

--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] High CPU load with 2.7.0-rc2

[Black Michael via wsjt-devel]

Please test the latest hamlib and send a debug log.
Please place this file as described 
belowhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0
 C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will 
be in the same location
For Linux put it in   ~/.config The WSJT-X_Rigcontrol.log file will be here: 
~/.local/share/WSJT-X
For MacOS put it in /Users/[username]/Library/Preferences Restart WSJT-X and 
duplicate the problem.Shut down WSJT-X
Then send me the WSJT-X_RigControl.log fileMike W9MDB

 

On Saturday, July 15, 2023 at 08:46:28 AM CDT, Björn Ekelund 
 wrote:  
 
 Crossing posts so I am not sure which post responds to what but using the 
win64 hamlib dll linked below, WSJT-X 2.7.0-rc2 still crashes when trying to 
use the IC-7610. Regardless if the radio is on or off.
Björn SM7IUN
On Sat, Jul 15, 2023 at 2:49 PM Black Michael  wrote:

This has been fixed in the latest hamlib...
New hamlib for installation directions
#1 Shut down WSJTX
#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of 
WSJTX -- hopefully your browser doesn't block it but may warn you multiple 
times.
If you can do a "Save As" you can save it directly in the appropriate WSJTX 
directoryC:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.
http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
Linux/Unix/Mac users need to compile the latest tar file from 
http://n0nb.users.sourceforge.netNote: If compiling on Unix-like systems please 
uninstall any Hamlib package you have before installing the new build
#3 If you don't save directly you need to open a file browser and move the file 
that way.
If you're not familiar with that here's a video on the file browser - 
https://www.youtube.com/watch?v=AyVqCJrs9dk
Once installed on Linux do "ldconfig".
rigctl --version should then show a relatively recent date of the download
Mike W9MDB


 

On Saturday, July 15, 2023 at 12:30:39 AM CDT, Björn Ekelund 
 wrote:  
 
 1.30. I cannot believe why anyone would run an outdated firmware on a radio.In 
DXLog.ne we simply do not support outdated firmwares. 

Björn
On Fri, Jul 14, 2023 at 12:13 AM Black Michael via wsjt-devel 
 wrote:

Also what firmware version are you running?I made some changes which SHOULD be 
both forward/backward compatible with the new firmware.
Mike W9MDB 

On Thursday, July 13, 2023 at 02:07:03 PM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
 
 The currently published version of the hamlib dll still crashes when selecting 
ICOM IC-7610, regardless of async setting.
It does not seem to work for other ICOM models either, but it does not crash 
the program. 
Control via DXLab Commander is a good workaround while this is being worked on.

Björn SM7IUN
On Wed, Jul 12, 2023 at 3:20 PM Black Michael via wsjt-devel 
 wrote:

Save this into a file called "hamlib_settings.json" and place in the same 
folder as WSJT-X.ini
Should improve things until I get this fixed.

{
     "config": {
            "async": "0"
     }
}


Mike W9MDB








On Wednesday, July 12, 2023 at 07:44:53 AM CDT, Roger Newey (K7GXB) 
 wrote: 





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

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

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

73,
Roger (K7GXB)

-Original Message-
From: Black Michael via wsjt-devel  
Sent: Tuesday, July 11, 2023 20:47
What rig do you have?
Mike W9MDB
...
On my Win10 PC, this new version idles at 32% usage which is essentially the 
same as the earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 
idles at less than 2%.
Drew K9CW
...
---




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

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

[Black Michael via wsjt-devel]

This has been fixed in the latest hamlib...
New hamlib for installation directions
#1 Shut down WSJTX
#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of 
WSJTX -- hopefully your browser doesn't block it but may warn you multiple 
times.
If you can do a "Save As" you can save it directly in the appropriate WSJTX 
directoryC:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.
http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
Linux/Unix/Mac users need to compile the latest tar file from 
http://n0nb.users.sourceforge.netNote: If compiling on Unix-like systems please 
uninstall any Hamlib package you have before installing the new build
#3 If you don't save directly you need to open a file browser and move the file 
that way.
If you're not familiar with that here's a video on the file browser - 
https://www.youtube.com/watch?v=AyVqCJrs9dk
Once installed on Linux do "ldconfig".
rigctl --version should then show a relatively recent date of the download
Mike W9MDB


 

On Saturday, July 15, 2023 at 12:30:39 AM CDT, Björn Ekelund 
 wrote:  
 
 1.30. I cannot believe why anyone would run an outdated firmware on a radio.In 
DXLog.ne we simply do not support outdated firmwares. 

Björn
On Fri, Jul 14, 2023 at 12:13 AM Black Michael via wsjt-devel 
 wrote:

Also what firmware version are you running?I made some changes which SHOULD be 
both forward/backward compatible with the new firmware.
Mike W9MDB 

On Thursday, July 13, 2023 at 02:07:03 PM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
 
 The currently published version of the hamlib dll still crashes when selecting 
ICOM IC-7610, regardless of async setting.
It does not seem to work for other ICOM models either, but it does not crash 
the program. 
Control via DXLab Commander is a good workaround while this is being worked on.

Björn SM7IUN
On Wed, Jul 12, 2023 at 3:20 PM Black Michael via wsjt-devel 
 wrote:

Save this into a file called "hamlib_settings.json" and place in the same 
folder as WSJT-X.ini
Should improve things until I get this fixed.

{
     "config": {
            "async": "0"
     }
}


Mike W9MDB








On Wednesday, July 12, 2023 at 07:44:53 AM CDT, Roger Newey (K7GXB) 
 wrote: 





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

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

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

73,
Roger (K7GXB)

-Original Message-
From: Black Michael via wsjt-devel  
Sent: Tuesday, July 11, 2023 20:47
What rig do you have?
Mike W9MDB
...
On my Win10 PC, this new version idles at 32% usage which is essentially the 
same as the earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 
idles at less than 2%.
Drew K9CW
...
---




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

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

[Black Michael via wsjt-devel]

Also what firmware version are you running?I made some changes which SHOULD be 
both forward/backward compatible with the new firmware.
Mike W9MDB 

On Thursday, July 13, 2023 at 02:07:03 PM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
 
 The currently published version of the hamlib dll still crashes when selecting 
ICOM IC-7610, regardless of async setting.
It does not seem to work for other ICOM models either, but it does not crash 
the program. 
Control via DXLab Commander is a good workaround while this is being worked on.

Björn SM7IUN
On Wed, Jul 12, 2023 at 3:20 PM Black Michael via wsjt-devel 
 wrote:

Save this into a file called "hamlib_settings.json" and place in the same 
folder as WSJT-X.ini
Should improve things until I get this fixed.

{
     "config": {
            "async": "0"
     }
}


Mike W9MDB








On Wednesday, July 12, 2023 at 07:44:53 AM CDT, Roger Newey (K7GXB) 
 wrote: 





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

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

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

73,
Roger (K7GXB)

-Original Message-
From: Black Michael via wsjt-devel  
Sent: Tuesday, July 11, 2023 20:47
What rig do you have?
Mike W9MDB
...
On my Win10 PC, this new version idles at 32% usage which is essentially the 
same as the earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 
idles at less than 2%.
Drew K9CW
...
---




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

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

[Black Michael via wsjt-devel]

Please place this file as described 
belowhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0
 C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will 
be in the same location
For Linux put it in   ~/.config The WSJT-X_Rigcontrol.log file will be here: 
~/.local/share/WSJT-X
For MacOS put it in /Users/[username]/Library/Preferences Restart WSJT-X and 
duplicate the problem.Shut down WSJT-X
Then send me the WSJT-X_RigControl.log fileMike W9MDB

 

On Thursday, July 13, 2023 at 02:07:03 PM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
 
 The currently published version of the hamlib dll still crashes when selecting 
ICOM IC-7610, regardless of async setting.
It does not seem to work for other ICOM models either, but it does not crash 
the program. 
Control via DXLab Commander is a good workaround while this is being worked on.

Björn SM7IUN
On Wed, Jul 12, 2023 at 3:20 PM Black Michael via wsjt-devel 
 wrote:

Save this into a file called "hamlib_settings.json" and place in the same 
folder as WSJT-X.ini
Should improve things until I get this fixed.

{
     "config": {
            "async": "0"
     }
}


Mike W9MDB








On Wednesday, July 12, 2023 at 07:44:53 AM CDT, Roger Newey (K7GXB) 
 wrote: 





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

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

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

73,
Roger (K7GXB)

-Original Message-
From: Black Michael via wsjt-devel  
Sent: Tuesday, July 11, 2023 20:47
What rig do you have?
Mike W9MDB
...
On my Win10 PC, this new version idles at 32% usage which is essentially the 
same as the earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 
idles at less than 2%.
Drew K9CW
...
---




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

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

[Black Michael via wsjt-devel]

Save this into a file called "hamlib_settings.json" and place in the same 
folder as WSJT-X.ini
Should improve things until I get this fixed.

{
     "config": {
            "async": "0"
     }
}


Mike W9MDB








On Wednesday, July 12, 2023 at 07:44:53 AM CDT, Roger Newey (K7GXB) 
 wrote: 





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

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

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

73,
Roger (K7GXB)

-Original Message-
From: Black Michael via wsjt-devel  
Sent: Tuesday, July 11, 2023 20:47
What rig do you have?
Mike W9MDB
...
On my Win10 PC, this new version idles at 32% usage which is essentially the 
same as the earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 
idles at less than 2%.
Drew K9CW
...
---




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

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

[Black Michael via wsjt-devel]

This is a problem on Windows with the async routine enabled.   With async 
enabled Windows uses 100% of 1 core.  Async disabled runs at 1.6% of 1 core.  
It really should be closer to zero than the 1.6% but Windows has a problem with 
timing.

Linux doesn't have this problem.

I'm working on a solution for Windows.  

Mike W9MDB









On Wednesday, July 12, 2023 at 05:22:46 AM CDT, Brian Morrison via wsjt-devel 
 wrote: 





On Tue, 11 Jul 2023 15:53:25 -0500
Andrew White via wsjt-devel  wrote:

> On my Win10 PC, this new version idles at 32% usage which is
> essentially the same as the earlier "4.6~git Jun 28" version.  The
> older libhamlib-4.dll v4.5.4 idles at less than 2%.

This new pull request may be relevant:

https://github.com/Hamlib/Hamlib/pull/1336

I have not tried it, I will if Mike decides to merge it.

-- 

Brian  G8SEZ



___
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

[Black Michael via wsjt-devel]

What rig do you have?

Mike W9MDB


On Tuesday, July 11, 2023 at 04:19:09 PM CDT, Andrew White via wsjt-devel 
 wrote: 





On my Win10 PC, this new version idles at 32% usage which is essentially the 
same as the earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 
idles at less than 2%.

Drew K9CW


On 7/11/2023 11:52 AM, Black Michael via wsjt-devel wrote:


>  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
> 

-- 
**
* K9CW Thomasboro, IL  EN50wf
* email: k...@yahoo.com
* DXCC: 363/340  CW: 351/339 (need P5!)
*
___
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

[Black Michael via wsjt-devel]

We do post a libhamlib-X.dll file but not a .so file for Linux or one for Mac.

The directions are here but are missing doing an "ldconfig" on Linux when put 
in the new .so file.


New hamlib for installation directions

#1 Shut down WSJTX

#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of 
WSJTX -- hopefully your browser doesn't block it but may warn you multiple 
times.

If you can do a "Save As" you can save it directly in the appropriate WSJTX 
directory
C:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.

http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll

http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll

Linux/Unix/Mac users need to compile the latest tar file from 
http://n0nb.users.sourceforge.net
Note: If compiling on Unix-like systems please uninstall any Hamlib package you 
have before installing the new build

#3 If you don't save directly you need to open a file browser and move the file 
that way.

If you're not familiar with that here's a video on the file browser - 
https://www.youtube.com/watch?v=AyVqCJrs9dk

Once installed on Linux do "ldconfig".

rigctl --version should then show a relatively recent date of the download

Mike W9MDB









On Tuesday, July 11, 2023 at 01:02:03 PM CDT, Reino Talarmo 
 wrote: 





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] High CPU load with 2.7.0-rc2

[Black Michael via wsjt-devel]

Did you do an ldconfig after copying the new library

rigctl --version should show

rigctl Hamlib 4.6~git 2023-07-11T16:41:54Z SHA=5a8bd9 64-bit

Mike W9MDB









On Tuesday, July 11, 2023 at 04:19:09 PM CDT, Andrew White via wsjt-devel 
 wrote: 





On my Win10 PC, this new version idles at 32% usage which is essentially the 
same as the earlier "4.6~git Jun 28" version.  The older libhamlib-4.dll v4.5.4 
idles at less than 2%.

Drew K9CW


On 7/11/2023 11:52 AM, Black Michael via wsjt-devel wrote:


>  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
> 

-- 
**
* K9CW Thomasboro, IL  EN50wf
* email: k...@yahoo.com
* DXCC: 363/340  CW: 351/339 (need P5!)
*
___
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

[Black Michael via wsjt-devel]

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

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

[Black Michael via wsjt-devel]

I can duplicate the problem herewill be fixed ASAP.

Mike W9MDB








On Tuesday, July 11, 2023 at 10:35:20 AM CDT, Brian Morrison via wsjt-devel 
 wrote: 





On Tue, 11 Jul 2023 15:12:00 +0100
Brian Morrison via wsjt-devel  wrote:

> Running on Linux under Fedora 38 I am seeing the latest release using
> 100% of one CPU (8-core) when running, stopping monitoring/decoding
> makes no difference, closing the waterfall graph reduces the 100% to
> ~97%.
> 
> Not sure what else to try, but this appears to be new behaviour with
> this release.
> 

And it turns out that this is down to a change in hamlib-4.6~git, so
not WSJTX at all.

Sorry for the noise.


-- 

Brian  G8SEZ


___
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] Release Candidate WSJT-X 2.7.0-rc2

[Black Michael via wsjt-devel]

Yes it is always possible to modify things to do what you want.
For example when you compile Hamlib using JTSDKTools you get the most current 
hamlib by default unless you give it an -ng switch to NOT get the current 
version.
Mike W9MDB

 

On Saturday, July 8, 2023 at 05:56:03 PM CDT, Marco Calistri via wsjt-devel 
 wrote:  
 
  Il 08/07/23 12:16, Black Michael via wsjt-devel ha scritto:
  
 I guess you must be compiling the latest hamlib from github.

Please pull the latest and try again.  It  should be fixed.

Mike W9MDB


 
 
 Hello,
 
 Are there any oddities in my thoughts regarding Hamlib release included into 
the WSJT-X source archive, which I suppose is not the latter available.
 
 It could be possible to modify the installer wsjt-x compiler script, in order 
to use always the latest Hamlib release from Github, instead to rely on a 
static ( at least I suppose it being so) hamlib release?
 
 Sorry if my thoughts are nonsense.
 
 ---
 73 de Marco, PY1ZRJ (former IK5BCU)
  ___
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] Release Candidate WSJT-X 2.7.0-rc2

[Black Michael via wsjt-devel]

I guess you must be compiling the latest hamlib from github.

Please pull the latest and try again.  It  should be fixed.

Mike W9MDB


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

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc2

[Black Michael via wsjt-devel]

Try this 64-bit DLL

https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0

Mike W9MDB










On Saturday, July 8, 2023 at 01:39:11 AM CDT, jarmo via wsjt-devel 
 wrote: 





Fri, 7 Jul 2023 11:50:06 -0400
Joe Taylor via wsjt-devel  kirjoitti:

> Dear WSJT-X Users,
> 
> We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc2 is 
> ready for download by beta testers.

Hamlib no worky anymore with TS-890S

Hamlib error: 
netrigctl_open: vfo_mode=0
netrigctl_transaction: called len=12
network_flush called
write_block(): TX 12 bytes, method=2
    5c 64 75 6d 70 5f 73 74 61 74 65 0a                \dump_state.    
read_string_generic called, rxmax=1024 direct=1, expected_len=1
read_string_generic(1350): retrying read timeout 1/1 timeout=1
read_string_generic(): Timed out 0.014 seconds after 0 chars, direct=1
2:netrigctl.c(295):netrigctl_open returning(-5) Communication timed out

2:rig.c(7811):async_data_handler_stop entered
2:rig.c(7844):async_data_handler_stop returning(0) 
2:rig.c(7852):morse_data_handler_stop entered
2:rig.c(7882):morse_data_handler_stop returning(0) 
network_close: close socket ret=0
rig.c(1378):rig_open returning2(-5) Communication timed out

Communication timed out
Communication timed out
while opening connection to rig

Timestamp: 2023-07-08T06:26:28.196Z

Jarmo, oh1mrr



___
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] Need Hamlib Testers for IC7300 and IC7600

[Black Michael via wsjt-devel]

The 7610/7600 will behave better (if it's the latest firmware) with the more 
current version of  Hamlib than Uwe said he was going to use.
Icom decided to add the 0x25 0x26 command but did it differently than all other 
Icoms (actually they did it the  "right" for the 76xx IMHO).

Mike W9MDB








On Thursday, June 29, 2023 at 07:41:26 AM CDT, Dennis W1UE via wsjt-devel 
 wrote: 





Thank you Gene!

UE

On Thu, Jun 29, 2023 at 8:31 AM Gene Hinkle via wsjt-devel 
 wrote:
> K5PA, Yes, for IC-7300, IC-705, IC-7610
> 
> Gene, K5PA
> 
> 
> Gene
> 
>> On Jun 29, 2023, at 6:03 AM, Dennis W1UE via wsjt-devel 
>>  wrote:
>> 
>> 
>> Anyone around that can test the upcoming Hamlib dispersal with the RC2 
>> software that's coming out in the near future?  Instructions will be 
>> provided to volunteers.  Its simple, probably won't take you 30 minutes.
>> 
>> Dennis w1UE
>> 
>> ___
>> 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] Log file for changes in settings?

[Black Michael via wsjt-devel]

I would recommend that WSJT-X save a dated copy of the file during the closing 
of the  Settings dialog where it checks for changes.So...if something changed 
save  the current config with MMDDHHMMSS which would end up showing when 
the change took place 
Mike W9MDB

 

On Wednesday, June 14, 2023 at 06:14:24 AM CDT, Glenn Williams via 
wsjt-devel  wrote:  
 
 Hi,
I am aware of what wsjt-x.ini looks like.  My point was to have a log 
file in plain words that accumulates each change in any of the settings 
so that later on if something is acting up one could look at that file 
to see what changes in settings might be causing a problem. That would 
be as opposed to looking for RFI-induced problems, etc.  One could try
manually to keep versions of wsjt-x.ini and "diff" for what the most 
recent changes have been but the format of wsjt-x.ini does not lend 
itself to obtaining useful results from diff.

And, I was not talking about trying to induce changes by manually 
editing wsjt-x.ini and restarting WSJT-X.

--73, Glenn, AF8C

On 6/12/2023 8:49 PM, Reino Talarmo via wsjt-devel wrote:
> 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

-- 
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] Hamlib testing

[Black Michael via wsjt-devel]

Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0


C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location


For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X


For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X


Then send me the WSJT-X_RigControl.log file
Mike W9MDB



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

Re: [wsjt-devel] Hamlib testing -Testing IC-7300/IC-705, IC-7610 Results

[Black Michael via wsjt-devel]

-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-toroid-combo-pack/
Newark also carries them 
https://newark.com/c/passive-components/emc-rfi-suppression/ferrites-ferrite-assortments?brand=fair-rite
RFI Problems


Mike W9MDB










On Sunday, June 11, 2023 at 09:12:55 AM CDT, Gene Hinkle via wsjt-devel 
 wrote: 






Testing IC-7300/IC-705, IC-7610 Results

Mike, on the IC-7610 so far the new libhamlib-4.dll seems to work.

On the IC-705 and the IC-7300 however:


The WSJT-X program crashes if I start either radio from 7.074 MHz or higher and 
THEN change the band setting drop down to 80m e.g., 3.573 MHz or lower and do a 
TUNE transmit. It works OK at on 7.074 MHz and above frequencies but when I 
then drop to 3.573 MHz or the 1.840 MHz band and TUNE for Transmit it will 
crash and I have to then restart the program which then immediately crashes and 
a second restart operates correctly works unless I repeat the sequence I state 
above.

I should note that in both radio test cases, they are being operated from 
different computers, in fact all radios have their own computers.

I will be out most of the morning to church but back in the afternoon CDST.


73, Gene, K5PA
















On 6/10/2023 10:18 PM, Black Michael via wsjt-devel wrote:


>  Need people to test the latest Hamlib please
> 
> https://n0nb.users.sourceforge.net/
> 
> #1 Backwards compatibility with WSJT-X has been fixed.
> #2 Notable speedups for Windows operations
> Here's an FT-991 comparison
> Old:
>  1:rig_get_freq: elapsed=16ms
>  1:rig_get_freq: elapsed=17ms
>  1:rig_get_split_vfo: elapsed=30ms
>  1:rig_get_mode: elapsed=47ms
>  1:rig_get_ptt: elapsed=17ms
> New:
>  1:rig_get_freq: elapsed=6ms
>  1:rig_get_freq: elapsed=6ms
>  1:rig_get_split_vfo: elapsed=14ms
>  1:rig_get_mode: elapsed=13ms
>  1:rig_get_ptt: elapsed=4ms
> 
> Mike W9MDB
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
-- 
-- Gene
___
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] Hamlib testing

[Black Michael via wsjt-devel]

Need people to test the latest Hamlib please

https://n0nb.users.sourceforge.net/

#1 Backwards compatibility with WSJT-X has been fixed.
#2 Notable speedups for Windows operations
Here's an FT-991 comparison
Old:
 1:rig_get_freq: elapsed=16ms
 1:rig_get_freq: elapsed=17ms
 1:rig_get_split_vfo: elapsed=30ms
 1:rig_get_mode: elapsed=47ms
 1:rig_get_ptt: elapsed=17ms
New:
 1:rig_get_freq: elapsed=6ms
 1:rig_get_freq: elapsed=6ms
 1:rig_get_split_vfo: elapsed=14ms
 1:rig_get_mode: elapsed=13ms
 1:rig_get_ptt: elapsed=4ms

Mike W9MDB


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

Re: [wsjt-devel] Tx frequency display bug in V2.7.0-rc1

[Black Michael via wsjt-devel]

Two things to do -- try the latest hamlib and if that doesn't solve the problem 
I need some debug.
ew hamlib for installation directions

#1 Shut down WSJTX

#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of 
WSJTX -- hopefully your browser doesn't block it but may warn you multiple 
times.

If you can do a "Save As" you can save it directly in the appropriate WSJTX 
directory
C:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.

http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll

http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll

Linux/Unix/Mac users need to compile the latest tar file from 
http://n0nb.users.sourceforge.net
Note: If compiling on Unix-like systems please uninstall any Hamlib package you 
have before installing the new build

#3 If you don't save directly you need to open a file browser and move the file 
that way.


If you're not familiar with that here's a video on the file browser - 
https://www.youtube.com/watch?v=AyVqCJrs9dk

===
For debug info please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0

C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location

For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X

For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X

Then send me the WSJT-X_RigControl.log file
Mike W9MDB










On Friday, June 9, 2023 at 10:08:01 AM CDT, jan0--- via wsjt-devel 
 wrote: 





if I open WSJT-X, transmit on several (two? three? or more) different bands in 
succession, eventually this will happen:
 
Just over two seconds into the transmission on the latest band, the frequency 
display in the main WSJT-X window changes from the correct transmit frequency 
on the latest band to a frequency used on one of the earlier bands.  (For 
example, if transmitting on 28.074 MHz, after two seconds the displayed 
frequency may change to 3.573 MHz.)  At the end of the transmission, the 
display changes from the incorrect transmit frequency back to the correct 
receive frequency.  Once it starts, it will do this consistently on every 
transmit cycle on the latest band.  The problem is not band-specific; it’s 
happened on most HF bands.
 
The band-selector pull-down follows the frequency display; that is, it is 
correct at the beginning of the Tx cycle, changes to the same (incorrect) band 
as the frequency display after two seconds, then changes back to the correct 
band at the end of the Tx cycle.
 
As an experiment, I tried transmitting with zero RF output and the problem 
still occurs, so it doesn’t seem to be an RF-related issue.
 
The actual rig transmit frequency remains on the correct frequency (on the 
latest band) throughout; the rig VCOs do not change bands.  QSOs seem to be 
unaffected.  The usual df-driven Tx frequency offsets occur normally.
 
Operating on Win10 with an IC-7610 with the Split Operation setting set to 
“Rig.”
 
Ed Callaway N4II
 
___
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] Propagation modeling

[Black Michael via wsjt-devel]

Would this paper relate to WSJT-X's method?

https://ieeexplore.ieee.org/document/6349716

Mike W9MDB


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

Re: [wsjt-devel] spots to WSPRnet stop from a RaspPi

[Black Michael via wsjt-devel]

You would run tcpdump on the PI.  You cannot watch one computer's network 
traffic from another computer using wireshark.   Everybody uses a switch now 
and the cheap switches do not have a monitoring capability (sometimes referred 
to as an aggregation port).  You can only see your own traffic.

Mike W9MDB








On Friday, June 2, 2023 at 06:04:08 AM CDT, Peter Sumner via wsjt-devel 
 wrote: 





Hello Alex,
 all other web related activities like web browsing, system update, NTP and the 
like remain functional through the whole time, it appears to be on traffic from 
WSJT-X that suffers.

Each of the PI's run as a headless devices and all checks are done over VNC, 
which is quite sensitive to any network problems.

Regards,
Peter, vk5pj

On Fri, Jun 2, 2023 at 4:37 PM Alex Lelievre via wsjt-devel 
 wrote:
> Have you tried running WireShark on another machine and watching the traffic? 
>  Perhaps all the traffic dies and not just WSPRnet?
> 
> alex
> K6LOT
> 
>> On Jun 1, 2023, at 10:03 PM, Peter Sumner via wsjt-devel 
>>  wrote:
>> 
>> Hello,
>> while WSJT-X is a small part of this puzzle, it is a key one so hence I am 
>> posting this here. I have for a long time now been using WSJT-X (v1.8 right 
>> through to the current release for ARM v2.61 ) on a Raspberry Pi for a 
>> dedicated WSPR station with two Icom rigs on VHF. Over time both the Pi3 and 
>> Pi4 have been used along with tests with the Raspberry Pi 32 and 64 bit O/S. 
>>  Each of these configurations have been quite stable with the exception of 
>> the spots and status on WSPRnet just stop getting through.
>> 
>> On the last incarnation of my setup I actually loaded one of the popular 
>> firewall packages (UFW) thinking I could then be exact by defining the 
>> allowed apps and ports for WSJT-X to get to WSPRnet. All was good for a few 
>> weeks then back to the no spots and no status on WSPRnet.
>> A reboot of the PI brings things back to life for a period of time (seems to 
>> vary) but in the end my status and spot on WSPRnet stop appearing.
>> Looking to see if anyone has come across anything similar or any good 
>> pointers on what might be wrong at my end?
>> 
>> have looked for ways to set the WSJT-X syslogs to be more granular but no 
>> luck so far
>> 
>> Regards,
>> Peter, vk5pj
>> ___
>> 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] Memory leak in 2.7.0 rc1?

[Black Michael via wsjt-devel]

Turns out Task Manager shows different memory usage then the System Informer I 
use and also Process Explorer.

System Informer says 444MB but Task Manager says 44MB on a clean config (no rig 
selected or anything done).

Process Explorer shows 450MB.

So I don't believe Task Manager is correct at all.

In any case there's no memory leak -- just inaccurate memory reporting.

Mike W9MDB





On Friday, May 26, 2023 at 08:56:48 AM CDT, Hasan N0AN via wsjt-devel 
 wrote: 





Around 125 MB, consistent with changing configurations (separate configs for 
each mode).
FT8, MSK144, FT8,...all around 125 MB starting. Q65 127 MB after about 2  hours 
of operation, so it is essentially the same.

We checked with our zoom group, we are all running WSJT-X 2.7.0 RC1 Improved 
Plus by Uwe:

KB7IJ, K5GZR, NM3G, W8LMG, WB4HIE and I all reported approximately 125 MB 
initially and 125 MB after two hours of MSK144 and Q65 operation. One station, 
ND0B was reporting approx. 600 MB upon startup  ...but he attributes that to a 
gigantic *.adi file, that he thinks is loaded upon startup?

So, 125 MB appears to be the baseline for most of us (no matter what mode), 
with one outlier, ND0B.

73, N0AN

Hasan


On Thu, May 25, 2023 at 8:16 PM Joe Taylor via wsjt-devel 
 wrote:
> Hi Björn,
> 
> I have not been able to reproduce anything like the behavior you 
> describe.  For one example, I started WSJT-X in FT8 mode, monitoring a 
> fairly busy 15 m band.  Memory usage reported by Windows TaskManager 
> over the first ~5 hours looks like this:
> 
>   UTC  Memory
> --
> 1930  97.1 MB
> 1950  99.5
> 2140  96.0
> 0105  94.2
> 
> So far, I have seen no evidence of any memory leak.
> 
>         -- 73, Joe, K1JT
> 
> 
> On 5/25/2023 3:49 PM, Brian Moran via wsjt-devel wrote:
>> Greetings; can you describe what mode you are using? If you left it going 
>> for a few days without deciding any signals (e.g. with no antenna) same 
>> behavior? What radio and interface to the radio? Any other information you 
>> could share would be most appreciated.
>> 
>> Thanks!
>> -Brian N9ADG
>> 
>> 
>> Sent via iPhone
>> 
>>> On May 25, 2023, at 12:11 PM, Björn Ekelund via wsjt-devel 
>>>  wrote:
>>>
>>> 
>>> My RAM (8 Gbyte) fills up if I let rc1 run for a few days. It does not 
>>> happen with 2.6.1.
>>>
>>> Interestingly enough the task manager does not show WSJT-X to be the 
>>> culprit but when
>>> I stop it, up to 5Gbyte are freed up.
>>>
>>> Also, sometimes rc1 allocates 630Mbyte of RAM when started. Other times 
>>> 90Mbyte. It seems random.
>>>
>>> 2.6.1 is always around 90Mbyte.
>>>
>>> I am running Swedish Windows.
>>>
>>> Does anyone else experience the same anomalies?
>>>
>>> Björn SM7IUN
>>>
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> 
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

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


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

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

[Black Michael via wsjt-devel]

2.6.1 gives me the same 450MB on a clean AppData\Local\WJST-X setup.

Mike W9MDB








On Friday, May 26, 2023 at 08:30:02 AM CDT, Fred Price via wsjt-devel 
 wrote: 





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

> On May 25, 2023, at 3:54 PM, Brian Moran via wsjt-devel 
>  wrote:
> 
> Greetings; can you describe what mode you are using? If you left it going 
> for a few days without deciding any signals (e.g. with no antenna) same 
> behavior? What radio and interface to the radio? Any other information you 
> could share would be most appreciated. 
> 
> Thanks!
> -Brian N9ADG
> 
> 
> Sent via iPhone
> 
>> On May 25, 2023, at 12:11 PM, Björn Ekelund via wsjt-devel 
>>  wrote:
>> 
>> 
>> My RAM (8 Gbyte) fills up if I let rc1 run for a few days. It does not 
>> happen with 2.6.1.
>> 
>> Interestingly enough the task manager does not show WSJT-X to be the culprit 
>> but when 
>> I stop it, up to 5Gbyte are freed up.
>> 
>> Also, sometimes rc1 allocates 630Mbyte of RAM when started. Other times 
>> 90Mbyte. It seems random.
>> 
>> 2.6.1 is always around 90Mbyte. 
>> 
>> I am running Swedish Windows. 
>> 
>> Does anyone else experience the same anomalies?
>> 
>> Björn SM7IUN
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

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


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

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

[Black Michael via wsjt-devel]

I don't see a memory leak -- but do see a large chunk of memory being 
used...over 400MB by both 32-bit and 64-bit Windows versions.  Others have 
mentioned this too.
330MB of that is the main wsjtx.exe program and not the DLLs.

I was able to compile a debug version and put a break point in main() and the 
memory was already in-use at the 1st line of main.

I've got an AMD Ryzen 9 5950X if that makes any difference.

Mike W9MDB








On Thursday, May 25, 2023 at 08:22:01 PM CDT, Joe Taylor via wsjt-devel 
 wrote: 





Hi Björn,

I have not been able to reproduce anything like the behavior you 
describe.  For one example, I started WSJT-X in FT8 mode, monitoring a 
fairly busy 15 m band.  Memory usage reported by Windows TaskManager 
over the first ~5 hours looks like this:

  UTC  Memory
--
1930  97.1 MB
1950  99.5
2140  96.0
0105  94.2

So far, I have seen no evidence of any memory leak.

    -- 73, Joe, K1JT


On 5/25/2023 3:49 PM, Brian Moran via wsjt-devel wrote:
> Greetings; can you describe what mode you are using? If you left it going for 
> a few days without deciding any signals (e.g. with no antenna) same behavior? 
> What radio and interface to the radio? Any other information you could share 
> would be most appreciated.
> 
> Thanks!
> -Brian N9ADG
> 
> 
> Sent via iPhone
> 
>> On May 25, 2023, at 12:11 PM, Björn Ekelund via wsjt-devel 
>>  wrote:
>>
>> 
>> My RAM (8 Gbyte) fills up if I let rc1 run for a few days. It does not 
>> happen with 2.6.1.
>>
>> Interestingly enough the task manager does not show WSJT-X to be the culprit 
>> but when
>> I stop it, up to 5Gbyte are freed up.
>>
>> Also, sometimes rc1 allocates 630Mbyte of RAM when started. Other times 
>> 90Mbyte. It seems random.
>>
>> 2.6.1 is always around 90Mbyte.
>>
>> I am running Swedish Windows.
>>
>> Does anyone else experience the same anomalies?
>>
>> Björn SM7IUN
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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


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


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

Re: [wsjt-devel] wsjtx-2.7.0-rc1 and hamlib

[Black Michael via wsjt-devel]

So I need a debug file from rigtctld and from WSJT_X.


For rigctld add this "-v -Z >log.txt 2>&1"


And for WSJT-X please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0


C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location


For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X


For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X


Then send me the WSJT-X_RigControl.log file

Mike W9MDB



On Tuesday, May 23, 2023 at 08:11:02 AM CDT, Josh Rovero via wsjt-devel 
 wrote: 





Since installing 2.7.0-rc1 (built from source), I have observed the following 
behavior on Fedora Core 38, 64-bit, hamlib 4.5.4.  Yaesu FT-950, tty/USB0 for 
serial, and Signalink USB sound card.  PTT method is CAT.  Everything worked 
normally in FC37 and wsjtx-2.6.1.

"Test CAT" does not turn green, but WSPR band-hopping works.  Changing 
frequency at the radio results in changing frequency in the WSJT-X window.  So 
there is serial communication

"Test PTT" works.  So there is serial communication..

"Enable TX" button is reset (unset) on each band hopping band change, whether 
or not "tune" is selected in the WSPR band-hopping schedule.

"Enable TX" followed by "Tune" transmits as expected, but the second press of 
"Tune" to stop tuning turns off both "Tune" and "Enable Tx" buttons.

Output of rigctl seems pretty normal with the same serial parameters.
 
-- 
P.J. "Josh" Rovero     http://www.roveroresearch.org                  
Ham Radio: KK1D

___
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.7-rc1 with IC-7610 No TX

[Black Michael via wsjt-devel]

Please place this file as described below
https://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0

C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location

For Linux put it in  
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X

For MacOS put it in
/Users/[username]/Library/Preferences
 
Restart WSJT-X and duplicate the problem.
Shut down WSJT-X

Then send me the WSJT-X_RigControl.log file
Mike W9MDB








On Saturday, May 20, 2023 at 07:39:50 PM CDT, Leslie L via wsjt-devel 
 wrote: 





Uploaded latest version of hamlib and installed it.

7610 follows band changes from WSJT-, but no TX

In Settings - Test CAT , turns  Green and Test PTT turns red, but no keying of 
Rig.

When I hit Tune ( Fake it )  Freq changes, but no TX

Les
W2LPL


___
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] v2.7.0-RC1 Excessively large wsjx_syslog.log #IssueReport

[Black Michael via wsjt-devel]

Fixed it -- will be in tonight's build 20230520 

https://n0nb.users.sourceforge.net/

Mike W9MDB








On Friday, May 19, 2023 at 04:25:07 PM CDT, Sam W2JDB  wrote: 





Hi Mike, 



Saw this thread, decided to look at the log.





[SYSLOG][2023-05-19 18:26:29.239145][00:00:00.000273][info] Log Start

[SYSLOG][2023-05-19 18:26:29.239145][00:00:00.000299][info] WSJT-X   v2.7.0-rc1 
662af6  by K1JT et al. - Program startup

[SYSLOG][2023-05-19 18:26:29.264209][00:00:00.024658][info] locale: language: 
English script: Default country: United States ui-languages: en-US

[SYSLOG][2023-05-19 18:26:29.264209][00:00:00.024775][info] Loaded Qt 
translations for current locale from resources

[SYSLOG][2023-05-19 18:26:29.264209][00:00:00.024801][info] Loaded WSJT-X base 
translation file from :/Translations based on language en

[SYSLOG][2023-05-19 18:26:29.264209][00:00:00.024821][info] Loaded WSJT-X 
translations for current locale from resources

[SYSLOG][2023-05-19 18:26:29.277213][00:00:00.037807][info] shmem size: 48275456

[RIGCTRL][2023-05-19 18:26:29.290215][00:00:00.050774][info] Hamlib version: 
Hamlib 4.6~git May 17 19:10:32Z 2023 SHA=0f5982 64-bit

[SYSLOG][2023-05-19 18:26:29.662298][00:00:00.422928][info] Configuration 
Settings (C:/Users/sambi/AppData/Local/WSJT-X/WSJT-X.ini)

[SYSLOG][2023-05-19 18:26:29.663299][00:00:00.423709][info] Reading frequencies

[SYSLOG][2023-05-19 18:26:29.663299][00:00:00.423716][info] read_settings found 
FrequenciesForRegionModes_v2

[SYSLOG][2023-05-19 18:26:29.663299][00:00:00.423720][info] read_settings ALSO 
found FrequenciesForRegionModes

[SYSLOG][2023-05-19 18:26:29.769322][00:00:00.529756][info] Loading CTY.DAT 
from C:/WSJT/wsjtx/wsjtx_27x/wsjtx/share/wsjtx/cty.dat

[SYSLOG][2023-05-19 18:26:29.930358][00:00:00.691131][info] Loaded CTY.DAT 
version VER20230223, Kaliningrad

[SYSLOG][2023-05-19 18:26:29.930358][00:00:00.691258][info] Loading CTY.DAT 
from C:/WSJT/wsjtx/wsjtx_27x/wsjtx/share/wsjtx/cty.dat

[SYSLOG][2023-05-19 18:26:30.092395][00:00:00.853209][info] Loaded CTY.DAT 
version VER20230223, Kaliningrad

[SYSLOG][2023-05-19 18:26:30.450475][00:00:01.211496][info] LotWUsers: Loaded 
124396 records from C:/Users/sambi/AppData/Local/WSJT-X/lotw-user-activity.csv

[RIGCTRL][2023-05-19 18:26:30.501486][00:00:01.262098][error] 
kenwood_safe_transaction: wrong answer; len for cmd SH: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:30.554497][00:00:01.315095][error] 
kenwood_safe_transaction: wrong answer; len for cmd SL: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:30.651519][00:00:01.411994][error] 
kenwood_safe_transaction: wrong answer; len for cmd SH: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:30.706531][00:00:01.467011][error] 
kenwood_safe_transaction: wrong answer; len for cmd SH: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:30.761543][00:00:01.521996][error] 
kenwood_safe_transaction: wrong answer; len for cmd SH: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:30.816556][00:00:01.577029][error] 
kenwood_safe_transaction: wrong answer; len for cmd SL: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:30.872568][00:00:01.632886][error] 
kenwood_safe_transaction: wrong answer; len for cmd SL: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:30.928581][00:00:01.688913][error] 
kenwood_safe_transaction: wrong answer; len for cmd SL: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:31.998601][00:00:02.758810][error] 
kenwood_safe_transaction: wrong answer; len for cmd SH: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:32.053607][00:00:02.813837][error] 
kenwood_safe_transaction: wrong answer; len for cmd SH: expected = 15, got 4

[RIGCTRL][2023-05-19 18:26:32.109602][00:00:02.869764][error] 
kenwood_safe_transaction: wrong answer; len for cmd SH: expected = 15, got 4




This error message keep going until you exit wsjt-x.




73,







Sam W2JDB









-Original Message-From: Mike Black via groups.io 
To: m...@wsjtx.groups.io 
Sent: Fri, May 19, 2023 1:54 pmSubject: Re: [WSJTX] 
v2.7.0-RC1 Excessively large wsjx_syslog.log #IssueReport
Delete it and restart -- then stop soon after running WSJT-X and send me a copy 
of the file.
Mike W9MDB



    On Friday, May 19, 2023 at 12:29:41 PM CDT, kbstackhouse 
 wrote:  

I installed v2.7.0-rc1 a few days ago. Everything appears to be working OK, but 
I have noticed that the wsjx_syslog.log files grows to 311 Gbytes (filling up 
my C drive, maybe to the max).  I can't examine it and have deleted it almost 
daily.  Is anyone else experiencing this?  Anyone know what editor to use to 
examine this file?
Thanks,
Ken, K6UF





  


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44541): https://WSJTX.groups.io/g/main/message/44541 

Mute This Topic: https://groups.io/mt/99017063/821688

Mute #issuereport:https://WSJTX.groups.io/g/main/mutehashtag/issuereport
Group Owner: main+ow...@wsjtx.groups.io
Unsubscribe: 

Re: [wsjt-devel] Wish

[Black Michael via wsjt-devel]

You have to decode them once when they do NOT get their callsign in brackets.  
A lot of people like to skip TX1 which causes this problem.

Mike W9MDB








On Monday, May 15, 2023 at 03:02:58 PM CDT, Bo Nilsson FJE via wsjt-devel 
 wrote: 





  


Hi Gents,

 

This msg has hit me a couple of times: 175815 -3 -0.1 616 ~ SM7FJE <...> -15 Of 
course it is hard to respond to the station calling. Would it be possible for 
the program to put the report in brackets or just forget it until the calling 
station is identified?

 

73

Bo 

SM7FJE



___
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] Candidate Release WSJT-X 2.7.0-rc1

[Black Michael via wsjt-devel]

BTW -- The community would appreciate everybody turning on PSKReporter.  We 
have put changes in WSJT-X to support the HamSCI community doing analysis on 
solar eclipses where the spotting will increase +/- 6 hours around a solar 
eclipse event.

By default WSJT-X removes duplicate spots now before sending to PSKReporter to 
try and reduce the load on PSKReporter.  During solar eclipses all spots will 
be sent...duplicate or not.

The next solar eclipse will be 2023-10-14 18:00:40.   We have some testing 
dates so PSKReporter can see the effect of all the spots coming on starting 
today at 12:00 and the 1st/15th of month until Sep 1st.


Mike W9MDB









On Monday, May 15, 2023 at 08:06:48 AM CDT, robert evans LAST_NAME via 
wsjt-devel  wrote: 





Hi Captain Joseph & crew,

2.7.0-rc1 win7 i5 sdrplay rx 6m & still there posting to pskreporter now.

2.7.0-rc1 win7 i3 laptop ft-991 made a few qsos no problems.

Tried aurora 30s-a no contacts yet, but tested okay.
Will point the 2m yagi-uda north and try 30s-C soon.

Unable to install on RasPi4 will try another build...
probably my error.

A friend in a similar decade got covid with severe symptoms.
He was amazed how well PAXLOVID reduced symptoms.

Great presentation for DVRA/W2QZ.

Thank You,
BCNU DE N2LO~>


> On 05/12/2023 1:15 PM Joe Taylor via wsjt-devel 
>  wrote:
> 
>  
> Too many mistakes, this morning.
> 
> At the bottom of my email announcing availability of Candidate Release 
> WSJT-X 2.7.0-rc1, I listed my colleague Uwe Risse's callsign as DG3YCB. 
>  As most of you know, and as I know perfectly well, his callsign is 
> DG2YCB.  Moreover, Uwe had already drawn my attention to this typo in a 
> previous announcement.  Forgetting about that, I simply copied the typo 
> from the previous message.
> 
> Mea culpa, mea maxima culpa, Uwe.  Let's hope the software performs 
> better than one of its authors has done.
> 
> Maybe I can blame it on my health.  I came down with COVID yesterday, 
> and am feeling very poorly.
> 
>     -- 73, Joe, K1JT
> 
> 
> On 5/12/2023 11:52 AM, Joe Taylor wrote:
> > Dear WSJT-X Users,
> > 
> > We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is 
> > ready for download by beta testers.
> > 
> > WSJT-X 2.7.0 Release Candidate 1 introduces a new program called "QMAP",
> > a new Special Operating Activity known as "Q65 Pileup", and a number of
> > other program enhancements and bug fixes.  A full list of enhancements 
> > can be found in the Release Notes:
> > 
> > https://wsjt.sourceforge.io/wsjtx-doc/Release_Notes_2.7.0-rc1.txt
> > 
> > Release Candidates are intended for Beta testers.  If you download and 
> > use WSJT-X 2.7.0-rc1, please remember to provide feedback to us on its 
> > new features -- and on anything that does not seem to work properly.
> > 
> > Direct links to installation packages for Windows, Linux, and macOS can 
> > be found on the WSJT-X page https://wsjt.sourceforge.io/wsjtx.html
> > Scroll down to the heading "Candidate release:  WSJT-X 2.7.0-rc1".
> > 
> > For those who like to compile from source, a complete source-code 
> > tarball is available at the WSJT-X page. Public access to the git 
> > repository for the WSJT project is also available on the "Git" tab here:
> > https://sourceforge.net/projects/wsjt/  It may take a short time for the 
> > code to be updated on SourceForge.
> > 
> > 
> > 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.
> > 
> > The authors and Copyright holders of WSJT-X request that derivative 
> > works should not publish programs based on features in WSJT-X before 
> > those features are made available in a General Availability (GA) release 
> > of WSJT-X.  We will cease making public Release Candidate (RC) 
> > pre-releases for testing and user early access purposes if this request 
> > is ignored.
> > 
> > Feedback should be sent to this email list or one of the of the others 
> > mentioned here in the User Guide:
> > 
> > https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0-rc1.html#SUPPORT
> > 
> > We hope you will enjoy using WSJT-X 2.7.0-rc1, and that you help us to 
> > create a GA release of this version very soon.
> > 
> >     -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Uwe, DG3YCB;
> >      Brian, N9ADG; and John, G4KLA
> 
> 
> ___
> 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] Compiling new hamlib

[Black Michael via wsjt-devel]

What do you mean "it does not find my Hamlib net rigctld,"  -- is there some 
error message?

Mike W9MDB






On Saturday, May 13, 2023 at 09:41:27 AM CDT, jarmo  wrote: 





Sat, 13 May 2023 12:42:20 +0000 (UTC)
Black Michael via wsjt-devel 
kirjoitti:
Hi Mike &

No, I did git pull on to existing hamlib. Renamed it and With clean
git clone, everything went ok. Compiled and is running.

Now BUT...
When I take wsjtx, git clone etc... Seems to go ok, compilation
and install. Start wsjtx, I see version 2.6.1 still? And what
worse, it does not find my Hamlib net rigctld, my logprog, CqrLog
works ok with new hamlib.

No panic... sure find solution..

jarmo, oh1mrr
> Do you have an old libhamlib sitting around?  Did you uninstall the
> hamlib package?
> 
> Mike W9MDB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Saturday, May 13, 2023 at 04:35:41 AM CDT, jarmo via wsjt-devel
>  wrote: 
> 
> 
> 
> 
> 
> Just started trying compile hamlib in Fedora 38.
> Got error
> make[1]: Siirrytään hakemistoon ”/home/oh1mrr/Hamlib/c++”
>   CXXLD    libhamlib++.la
> /usr/bin/ld: cannot find
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crti.o: No such
> file or directory /usr/bin/ld: cannot find
> /usr/lib/gcc/x86_64-redhat-linux/12/crtbeginS.o: No such file or
> directory collect2: error: ld returned 1 exit status
> 
> But, find /usr/ -name crti*
> /usr/lib64/crti.o
> 
> find /usr/ -name crtbeginS*
> /usr/lib/gcc/x86_64-redhat-linux/13/crtbeginS.o
> /usr/lib/gcc/x86_64-redhat-linux/13/32/crtbeginS.o
> 
> As known, I don't "speak nerd" well :), if I could get
> easy way out?
> I see that ld is looking first hand /12/, but F38 has /13/.
> 
> Any solution???
> 
> Jarmo, oh1mrr
> 
> 
> ___
> 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] [wsjtgroup] Volunteers Needed- Hamlib Reviews

[Black Michael via wsjt-devel]

Looks for any errors at all during startup or normal operations.

In particular using Fake It or Rig Split

Mike W9MDB







On Saturday, May 13, 2023 at 09:35:42 AM CDT, Hisashi T Fujinaka via wsjt-devel 
 wrote: 





I have an Elecraft K3 and an Elecraft K4 and I'm running MacOS.

I could test but I haven't had much problem and I'm not entirely sure
what we're testing. The only thing I ever check to make sure is tht the
band is changing. I've never been on the QA side of software
development.

On Sat, 13 May 2023, Dennis W1UE wrote:

> I'm looking to get a group of ops together to review Hamlib files prior to
> the release of new ones.  Any op with any rig is eligible to apply.
>
> If you're interested, please specify your rig, version of Windows (or your
> OS), and any other specifics that may be applicable.
>
> Our immediate task is to review the last several Hamlib files, and see if
> we have a "best working"  file that can be released with the upcoming
> version of WSJT-improved.  After that, we will be looking to check out
> Hamlib files PRIOR to their
> release.  Instructions will be provided on how to do the testing.
>
> Dennis W1UE
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#282): https://groups.io/g/wsjtgroup/message/282
> Mute This Topic: https://groups.io/mt/98867433/239357
> Group Owner: wsjtgroup+ow...@groups.io
> Unsubscribe: 
> https://groups.io/g/wsjtgroup/leave/12257253/239357/1979070917/xyzzy 
> [ht...@twofifty.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
>

-- 
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee


___
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] Compiling new hamlib

[Black Michael via wsjt-devel]

Do you have an old libhamlib sitting around?  Did you uninstall the hamlib 
package?

Mike W9MDB









On Saturday, May 13, 2023 at 04:35:41 AM CDT, jarmo via wsjt-devel 
 wrote: 





Just started trying compile hamlib in Fedora 38.
Got error
make[1]: Siirrytään hakemistoon ”/home/oh1mrr/Hamlib/c++”
  CXXLD    libhamlib++.la
/usr/bin/ld: cannot find 
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crti.o: No such file or 
directory
/usr/bin/ld: cannot find /usr/lib/gcc/x86_64-redhat-linux/12/crtbeginS.o: No 
such file or directory
collect2: error: ld returned 1 exit status

But, find /usr/ -name crti*
/usr/lib64/crti.o

find /usr/ -name crtbeginS*
/usr/lib/gcc/x86_64-redhat-linux/13/crtbeginS.o
/usr/lib/gcc/x86_64-redhat-linux/13/32/crtbeginS.o

As known, I don't "speak nerd" well :), if I could get
easy way out?
I see that ld is looking first hand /12/, but F38 has /13/.

Any solution???

Jarmo, oh1mrr


___
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] Hamlib Beta Testing Group needed

[Black Michael via wsjt-devel]

I have been writing simulators but they do not have the nuances that the rigs 
do.  There's all sorts of oddities.

Butthe plan is to eventually incorporate those simulators in the "make 
test" in Hamlib that should catch big mistakes.

It's on my to-do list but don't hold your breath...it's a low priority.

Mike W9MDB








On Saturday, May 13, 2023 at 03:29:25 AM CDT, Tom M0LTE via wsjt-devel 
 wrote: 





Hey Uwe

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.

Apologies if I am not the first to ask this question.

Kind regards
Tom M0LTE

On Sat, 13 May 2023 at 08:11, Uwe, DG2YCB via wsjt-devel 
 wrote:
>  
>  Dear WSJT-X users,
> 
> Please allow me to summarize again here on this email reflector a topic that 
> is very important to me and to all of us. My original post was on 
> https://groups.io/g/wsjtgroup, so maybe it's best if you join the discussion 
> there.  
> 
> Despite great personal commitment of the hamlib developers it has 
> unfortunately happened very often that immediately after a new WSJT-X release 
> serious problems with one or another hamlib rig driver become apparent. If 
> something like this happens over and over again, it shows that there is a 
> systematic error somewhere. In my opinion this is due to the fact that too 
> few users try the current development versions of hamlib, so that errors are 
> detected too late. Keep in mind that hamlib drivers often change as they 
> evolve.
> 
> So I would like to ask you all that enough OMs act as hamlib bata tester in 
> the future. For those who own one of the rigs below and work on Windows, just 
> do the following every 2, 3 or 4 weeks:
> 
> 1. Download the daily updated libhamlib-4.dll file available on 
> https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
> 2. Copy the file to the bin folder of your WSJT-X installation (i.e. 
> usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file 
> beforehand so you can use it again later.
> 3. Start WSJT-X (or the respective variant), connect your rig via hamlib 
> (i.e. not via OmniRig, HRD, DXLabSuite, etc.) and check if the CAT control 
> runs properly.
> 4. If anything is not working properly, please contact Mike W9MDB via 
> direct email, so he or his team can fix the bug in time.
> 5. If everything works fine, keep the new libhamlib-4.dll file, otherwise 
> delete it and rename the previously used one.
> 6. In the future I would like to contact you before a new WSJT-X or 
> wsjt-x_improved release to be able to choose a bug free hamlib version.
> In my opinion, at least the following rigs need to be tested regularly 
> regarding hamlib:
> 
> * Yaesu: FT-991, FT-101, FT-847
> * Kenwood: which models?
> * Icom: IC-7300, IC-9100, IC-9700, IC-705
> * Elecraft: KX3, what else?
> * FlexRadio: which models?
> * Anything else?
> Now, the most important thing is that one of you  organizes it. I can't do it 
> myself because of time constraints, and Mike W9MDB is also overloaded with 
> work. 
> 
> For example, what about the people who have stood out so intensively in the 
> last few days with posts about something trivial? Wouldn't one of you like to 
> take over and invest your energy there? Seriously: Who? You are now requested!
> 
> I mean, what needs to be done is evident:
> 
> 1. Create a list of commonly used rig models.
> 2. Find beta testers for each of these models and assign responsibilities.
> 
> 3. Get an overview of the status quo and summarize the results clearly.
> 
> Something like this can be done e.g. with a simple Excel file:
> 
> 
> 
> 
> It's sad enough that obviously, the hamlib development team can't do 
> something so essential themselves. But this definitely has to come now, 
> because we can't get the next frustration after every new WSJT-X release. 
> Makes no sense!
> 
> So, again: Who of you will take this in hand and organize such a systematic 
> beta testing?
> 
> I do not want to see one more "stupid" post as long as this problem is not 
> solved, hi, hi!
> 
> 73 de Uwe, DG2YCB 
>  ___
> 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

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1

[Black Michael via wsjt-devel]

Try this dll please

https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0

Mike W9MDB








On Friday, May 12, 2023 at 12:37:02 PM CDT, Gerald Smith via wsjt-devel 
 wrote: 





Hi Mike,

Thanks for the link.

Well, I placed the dll file in this directory C:\WSJT\wsjtx\bin, and 
rebooted the computer, but I am still getting the error.

So, then I tried re-installing 2.7.0-rc1, and rebooting the computer 
again, I still have the error.

Sorry.

73 de WA3ZSC - Jerry


On 5/12/2023 13:07, Black Michael via wsjt-devel wrote:
> Direct link
>
> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=1
>
> Mike W9MDB
>
>
>
>
>
>
>
>
> On Friday, May 12, 2023 at 12:01:57 PM CDT, Black Michael via 
> wsjt-devel  wrote:
>
>
>
>
>
> Please try this DLL
>
> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
>
> Mike W9MDB
>
>
>
>
>
>
>
>
>
> On Friday, May 12, 2023 at 11:55:54 AM CDT, Gerald Smith via 
> wsjt-devel  wrote:
>
>
>
>
>
>
> Hi Joe,
>
> Sorry, but I get this error with WSJT-X 2.7.0-rc1.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Radio IC-7700, interface - Timewave Navigator.
>
> WSJT-X 2.6.1 works fine though thought that I should let you know.
>
> 73 de WA3ZSC - Jerry
>
>
>
>
>
>
>
>
> On 5/12/2023 11:20, Joe Taylor via wsjt-devel wrote:
>
>
>> We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is
>> ready for download by beta testers.
>>
>>
>>
>>
>> ___
>> 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


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

Re: [wsjt-devel] Release Candidate WSJT-X 2.7.0-rc1

[Black Michael via wsjt-devel]

We had somebody who was nicely compiling MacOS versions

https://github.com/Hamlib/Hamlib

Hopefully they are still out there...

Mike W9MDB








On Friday, May 12, 2023 at 12:38:31 PM CDT, Greg Vatt  wrote: 





Mike,

    I’m having the same problem here on MacOS M1 (13.3.1) + IC-7610. Even tried 
again with a clean install.






Greg, NC7B



> On May 12, 2023, at 9:57 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Please try this DLL
> 
> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
> 
> Mike W9MDB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Friday, May 12, 2023 at 11:55:54 AM CDT, Gerald Smith via wsjt-devel 
>  wrote: 
> 
> 
> 
> 
> 
> 
> Hi Joe,
> 
> Sorry, but I get this error with WSJT-X 2.7.0-rc1.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Radio IC-7700, interface - Timewave Navigator.
> 
> WSJT-X 2.6.1 works fine though thought that I should let you know.
> 
> 73 de WA3ZSC - Jerry
> 
> 
> 
> 
> 
> 
> 
> 
> On 5/12/2023 11:20, Joe Taylor via wsjt-devel wrote:
> 
> 
>> We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is 
>> ready for download by beta testers. 
>> 
>> 
>> 
>> 
>> ___ 
>> 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] Release Candidate WSJT-X 2.7.0-rc1

[Black Michael via wsjt-devel]

Direct link

https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=1

Mike W9MDB








On Friday, May 12, 2023 at 12:01:57 PM CDT, Black Michael via wsjt-devel 
 wrote: 





Please try this DLL

https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0

Mike W9MDB









On Friday, May 12, 2023 at 11:55:54 AM CDT, Gerald Smith via wsjt-devel 
 wrote: 






Hi Joe,

Sorry, but I get this error with WSJT-X 2.7.0-rc1.














Radio IC-7700, interface - Timewave Navigator.

WSJT-X 2.6.1 works fine though thought that I should let you know.

73 de WA3ZSC - Jerry








On 5/12/2023 11:20, Joe Taylor via wsjt-devel wrote:


> We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is 
> ready for download by beta testers. 
> 
> 
> 
> 
> ___ 
> 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] Release Candidate WSJT-X 2.7.0-rc1

[Black Michael via wsjt-devel]

Please try this DLL

https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0

Mike W9MDB









On Friday, May 12, 2023 at 11:55:54 AM CDT, Gerald Smith via wsjt-devel 
 wrote: 






Hi Joe,

Sorry, but I get this error with WSJT-X 2.7.0-rc1.














Radio IC-7700, interface - Timewave Navigator.

WSJT-X 2.6.1 works fine though thought that I should let you know.

73 de WA3ZSC - Jerry








On 5/12/2023 11:20, Joe Taylor via wsjt-devel wrote:


> We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc1 is 
> ready for download by beta testers. 
> 
> 
> 
> 
> ___ 
> 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] [wsjtgroup] Enhancement suggestion - 30 second cycles

[Black Michael via wsjt-devel]

And ya'll are confusing the purpose of split with the rig split function.
We have 3 choices
#1 Fake It#2 Rig#3 None
The all refer to split -- not to any reason for using it.  You are trying to 
put the reason as the title.
Mike W9MDB

 

On Monday, May 8, 2023 at 10:51:17 AM CDT, Adrian via wsjt-devel 
 wrote:  
 
   
No, leave the split rig/fake checkpoints, as is, but place within a field/box 
titled 'Signal Optimization' ,
 
 
which should be an easy ui update ?
 
 
No need to remove rig split or fake split, because that is what is activated 
via CAT.
 

 
 
73
 

 
 
vk4tux
 
 On 9/5/23 01:42, Alan wrote:
  
  I think I suggested something similar much earlier in the thread. 
  However with that new name rig and fake it don't mean anything so I'd suggest 
change to hardware and software respectively. 
   Alan G0TLK, sent from my mobile device  
 
On 8 May 2023 16:37:35 Adrian via wsjt-devel  
wrote:
 
 
Sam, That is what I mentioned earlier, however 'Signal Optimization' makes more 
sense,
 
as that is the end result.
 

 
 
73
 

 
 
vk4tux
 
 On 9/5/23 01:28, Sam Birnbaum via groups.io wrote:
  
Hi All, 
  As a retired software developer with extensive UI development experience, may 
I make a suggestion to  whomever is in charge of the UI, to change this part of 
the display in Radio Settings tab from what is the  current version (left side) 
to this new version (right side) and explain its function in the WSJT-X manual/ 
  
 
  This removes the ambiguity and confusion regarding the use of the word SPLIT. 
  
  73, 
  
   Sam W2JDB 

 
 -Original Message-
 From: Adrian via wsjt-devel 
 To: WSJT software development 
 Cc: Adrian 
 Sent: Mon, May 8, 2023 10:17 am
 Subject: Re: [wsjt-devel] Fwd: Enhancement suggestion - 30 second cycles
 
  Consistent TX level control, making alc minimum set easier for whole pan 
TX usage. 
  73 vk4tux
   On 9/5/23 00:08, Björn Ekelund via wsjt-devel wrote:
  
 
 So what more does it do? 
 Björn SM7IUN  
  On Mon, May 8, 2023 at 3:43 PM Black Michael  wrote:
  
That's not the only thing it does so that's not a good choice.  Nobody has 
every come up with anything better than Split. Let's just learn that Split from 
50 years ago has changed and is much more flexible now than before. 
  Mike W9MDB 
   

  
  On Monday, May 8, 2023 at 08:37:26 AM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
  
 I propose that the option "Split operation" in the radio settings of 
WSJT-X is renamed "Transmit harmonics prevention"  to remove some of the 
confusion to those who struggle with digital radio technology. 
  The three options below should be "I don't care if I QRM the band", "Use VFO 
B", and "Use CAT".
 
  Björn SM7IUN 
 
   On Mon, May 8, 2023 at 10:24 AM Jim Brown via wsjt-devel 
 wrote:
  
On 5/6/2023 10:41 PM, Reino Talarmo via wsjt-devel wrote:
 > This start to be really funny!
 
 There's a saying in the States that "you can't argue with a drunk." A 
 corollary is that it's a waste of time to one who only wants the world 
 to tell him he's right.
 
 The story related in your post is perfect!
 
 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
  
  
  
  ___
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
 

 -- 
 73,
 
 Sam W2JDB _._,_._,_  Groups.io Links: 
 You receive all messages sent to this group. 
 
 View/Reply Online (#206) | Reply To Group | Reply To Sender | Mute This Topic 
| New Topic
 Your Subscription | Contact Group Owner | Unsubscribe [vk4...@gmail.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
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[Black Michael via wsjt-devel]

I don't see what the problem is.
When you click "Rig" your rig goes into Split mode -- why would want to confuse 
people now with asking "why does my rig go into split mode when I click Rig in 
audio optimization".
Fake It is running split on just one VFO.
What we're missing in WSJT-X is the ability to get "Help" on items easily and 
we frequently have to explain to people how to find stuff in the 
manual.https://doc.qt.io/qt-6/qthelp-framework.html

Mike W9MDB___
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

[Black Michael via wsjt-devel]

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.
Let's just agree that things change over time and we need to revisit our 
burned-in-the-brain definitions of things.
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.
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.
Mike W9MDB

 

On Monday, May 8, 2023 at 09:40:39 AM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
 
 Fair enough, they come with keeping the transmit audio frequency centered in 
the passband.
"Use optimal transmit audio frequency" then?
Given the huge and often uninformed debates (not only here), avoiding the 
s-word would have a lot of value. 
Björn SM7IUN
On Mon, May 8, 2023 at 4:29 PM Black Michael via wsjt-devel 
 wrote:

#1 It allows you to transmit outside your passband.#2 It avoids roll off of 
power at band edges.#3 It avoids non-linearities in the audio digitization.
Mike W9MDB
 

On Monday, May 8, 2023 at 09:13:02 AM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
 
 So what more does it do?
Björn SM7IUN
On Mon, May 8, 2023 at 3:43 PM Black Michael  wrote:

That's not the only thing it does so that's not a good choice.  Nobody has 
every come up with anything better than Split.Let's just learn that Split from 
50 years ago has changed and is much more flexible now than before.
Mike W9MDB

 

On Monday, May 8, 2023 at 08:37:26 AM CDT, Björn Ekelund via wsjt-devel 
 wrote:  
 
 I propose that the option "Split operation" in the radio settings of WSJT-X is 
renamed "Transmit harmonics prevention" to remove some of the confusion to 
those who struggle with digital radio technology.
The three options below should be "I don't care if I QRM the band", "Use VFO 
B", and "Use CAT".

Björn SM7IUN

On Mon, May 8, 2023 at 10:24 AM Jim Brown via wsjt-devel 
 wrote:

On 5/6/2023 10:41 PM, Reino Talarmo via wsjt-devel wrote:
> This start to be really funny!

There's a saying in the States that "you can't argue with a drunk." A 
corollary is that it's a waste of time to one who only wants the world 
to tell him he's right.

The story related in your post is perfect!

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