wsjt-devel — WSJT software development

Re: [wsjt-devel] Q65 Pileup Feature Request

[Charles S. <g3...@gm...>]

Hi Lance

I understand your reason for wanting blind callers.  I had not quite
understood your comment at the end of your first email, but all is now
clear thanks.

We  used to use a somewhat similar scheme when Rex VK7MO was touring
Australia with a small dish on 10GHz,  The interested stations were
allocated a single tone frequency beforehand, As soon as someone had
decoded Rex, they would transmit a single tone and that would tell Rex who
was copying him, and he would then call them, or call them next.  I think
we got up to about 6 stations in the end with this scheme. With GPS locked
systems and CFOM  Doppler control it worked well.

73

Charlie DL3WDG






On Tue, 19 Aug 2025 at 07:31, Lance Collister, W7GJ via wsjt-devel <
wsj...@li...> wrote:

> Hello Charlie et al,
>
> Yes, I invite "blind callers" for the following two reasons:
>
> 1. I need their calls to be decoded to populate the Q65 PILEUP ACTIVE
> STATIONS LIST ("ASL") and provide the added sensitivity when it comes
> time to participate in a contact exchange with them.
>
> 2. Due to the nature of Faraday Rotation on VHF EME, there may appear to
> be "one way propagation" for extended periods of time. If people waited
> until they copied me before calling, I may have lost the opportunity for
> a complete Faraday Rotation cycle to receive them and add them to the
> ASL. Since many of the callers are horizon-only stations utilizing
> narrow ground gain antenna lobes, there are by nature very limited
> windows during which to complete with them; having them delay the start
> of the contact until they decode me further reduces the available time
> for a contact exchange to take place.
>
> I am sure you can appreciate the huge difference between this type of
> weak signal contact and the essentially instantaneous strong signal
> reciprocal contacts on HF using Fox/Hound or Superfox.  On VHF EME, it
> is quite an advantage to be able to determine which station(s) to engage
> in a QSO that might be able to provide a quick reciprocal type of
> contact. Currently, the only way to do this (without resorting to the
> internet to have people report "I am decoding you now", which
> essentially makes the contact invalid) is to try to work through the
> pile of callers, replying to each in turn to see which ones may be
> capable of completing a quick "reciprocal" type of contact with you.
> Thanks to the ASL, it may be that some of the callers to whom you reply
> may actually receive your message, although you won't know it until you
> receive "RRR" from them at some later time.  However, the best success
> rates involve choosing the proper QSO partners with which you have the
> highest probability of making a quick reciprocal contact thinning out
> the number of callers.
>
> It struck me that the Q65 PILEUP mode may finally actually provide the
> means to transmit this information! I thought that there might be room
> for this information the way the R report is inserted in TX3. I wonder
> if the program could automatically send a message in place of TX2, but
> similar to TX2 except with some other character (perhaps just a dash
> instead of a space) to indicate that the station copied a yellow spike
> during the receive cycle immediately preceding their transmit cycle.
> This would be in place of TX2, and would revert to the standard TX2 if
> no such yellow spike were received. It would not affect the AUTO
> SEQUENCE of either station (other than the current action upon receipt
> of a TX2 message) but would simply be displayed as a received message.
> But it would be a sign to the DXpedition (or other) station to "please
> select me next because I am copying your trace".  I suspect that the
> activation of this feature should be manually turned on by the callers,
> although I guess it wouldn't hurt to have it running all the time
> (unless it would add significant processing to the computers on one or
> both ends).
>
> Perhaps there are significant impediments that would make something like
> this impractical. However, after hours of trying to answer callers one
> at a time who don't copy at the time you tried them, I think it would be
> a tremendous improvement if it were in any way possible!
>
> Thank you for your kind consideration, and for the HUGE advance that Q65
> PILEUP provides. It is already the standard on 6m EME! VY 73, Lance
>
> On 19 Aug 2025 03:58, Jim Brown via wsjt-devel wrote:
> > On 8/18/2025 8:32 PM, Charles Suckling via wsjt-devel wrote:
> >> It seems from your last point that you suffer a lot from 'blind
> >> calling'.  This was a real problem during the early days of Superfox
> >> mode, and was overcome by code that prevents a 'hound' from
> >> transmitting at all until they have managed to decode the signal from
> >> the fox.
> >
> > Hi Charles,
> >
> > To understand Lance's request, you must understand his operating
> > conditions. He does 6M moon-bounce Dxpeditions to remote places, which
> > requires very low noise, high power, and big antennas. To minimize his
> > need for power, which translates to minimizing the cost of buying and
> > transporting fuel over oceans, and then to remote locations where
> > there's no noise, he INVITES blind callers. This is a method of
> > operation he devised years ago. He's currently somewhere in the South
> > Pacific, don't remember where.
> >
> > This is his website.  https://www.bigskyspaces.com/  Scroll down to
> > see his instructions to callers.
> >
> > I would encourage the development team to take his request seriously
> > and do your best to accommodate it.
> >
> > 73, Jim K9YC
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > wsjt-devel mailing list
> > wsj...@li...
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
> Lance Collister, W7GJ (ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX,
> 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ,
> S79GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
> P.O. Box 73
> Frenchtown, MT   59834-0073
> USA
> TEL: (406) 626-5728
> QTH: DN27ub
> URL: http://www.bigskyspaces.com/w7gj
> Skype: lanceW7GJ
> 2m DXCC #11 - 6m DXCC #815 - FFMA #7
>
> Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
> email group, or just fill in the request box at the bottom of my web
> page (above)!
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Q65 Pileup Feature Request

[Lance C. W. <w7...@bi...>]

Hello Charlie et al,

Yes, I invite "blind callers" for the following two reasons:

1. I need their calls to be decoded to populate the Q65 PILEUP ACTIVE 
STATIONS LIST ("ASL") and provide the added sensitivity when it comes 
time to participate in a contact exchange with them.

2. Due to the nature of Faraday Rotation on VHF EME, there may appear to 
be "one way propagation" for extended periods of time. If people waited 
until they copied me before calling, I may have lost the opportunity for 
a complete Faraday Rotation cycle to receive them and add them to the 
ASL. Since many of the callers are horizon-only stations utilizing 
narrow ground gain antenna lobes, there are by nature very limited 
windows during which to complete with them; having them delay the start 
of the contact until they decode me further reduces the available time 
for a contact exchange to take place.

I am sure you can appreciate the huge difference between this type of 
weak signal contact and the essentially instantaneous strong signal 
reciprocal contacts on HF using Fox/Hound or Superfox.  On VHF EME, it 
is quite an advantage to be able to determine which station(s) to engage 
in a QSO that might be able to provide a quick reciprocal type of 
contact. Currently, the only way to do this (without resorting to the 
internet to have people report "I am decoding you now", which 
essentially makes the contact invalid) is to try to work through the 
pile of callers, replying to each in turn to see which ones may be 
capable of completing a quick "reciprocal" type of contact with you.  
Thanks to the ASL, it may be that some of the callers to whom you reply 
may actually receive your message, although you won't know it until you 
receive "RRR" from them at some later time.  However, the best success 
rates involve choosing the proper QSO partners with which you have the 
highest probability of making a quick reciprocal contact thinning out 
the number of callers.

It struck me that the Q65 PILEUP mode may finally actually provide the 
means to transmit this information! I thought that there might be room 
for this information the way the R report is inserted in TX3. I wonder 
if the program could automatically send a message in place of TX2, but 
similar to TX2 except with some other character (perhaps just a dash 
instead of a space) to indicate that the station copied a yellow spike 
during the receive cycle immediately preceding their transmit cycle. 
This would be in place of TX2, and would revert to the standard TX2 if 
no such yellow spike were received. It would not affect the AUTO 
SEQUENCE of either station (other than the current action upon receipt 
of a TX2 message) but would simply be displayed as a received message. 
But it would be a sign to the DXpedition (or other) station to "please 
select me next because I am copying your trace".  I suspect that the 
activation of this feature should be manually turned on by the callers, 
although I guess it wouldn't hurt to have it running all the time 
(unless it would add significant processing to the computers on one or 
both ends).

Perhaps there are significant impediments that would make something like 
this impractical. However, after hours of trying to answer callers one 
at a time who don't copy at the time you tried them, I think it would be 
a tremendous improvement if it were in any way possible!

Thank you for your kind consideration, and for the HUGE advance that Q65 
PILEUP provides. It is already the standard on 6m EME! VY 73, Lance

On 19 Aug 2025 03:58, Jim Brown via wsjt-devel wrote:
> On 8/18/2025 8:32 PM, Charles Suckling via wsjt-devel wrote:
>> It seems from your last point that you suffer a lot from 'blind 
>> calling'.  This was a real problem during the early days of Superfox 
>> mode, and was overcome by code that prevents a 'hound' from 
>> transmitting at all until they have managed to decode the signal from 
>> the fox.
>
> Hi Charles,
>
> To understand Lance's request, you must understand his operating 
> conditions. He does 6M moon-bounce Dxpeditions to remote places, which 
> requires very low noise, high power, and big antennas. To minimize his 
> need for power, which translates to minimizing the cost of buying and 
> transporting fuel over oceans, and then to remote locations where 
> there's no noise, he INVITES blind callers. This is a method of 
> operation he devised years ago. He's currently somewhere in the South 
> Pacific, don't remember where.
>
> This is his website.  https://www.bigskyspaces.com/  Scroll down to 
> see his instructions to callers.
>
> I would encourage the development team to take his request seriously 
> and do your best to accommodate it.
>
> 73, Jim K9YC
>
>
>
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

-- 
Lance Collister, W7GJ (ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!

Re: [wsjt-devel] Q65 Pileup Feature Request

[Jim B. <k9...@au...>]

On 8/18/2025 8:32 PM, Charles Suckling via wsjt-devel wrote:
> It seems from your last point that you suffer a lot from 'blind 
> calling'.  This was a real problem during the early days of Superfox 
> mode, and was overcome by code that prevents a 'hound' from transmitting 
> at all until they have managed to decode the signal from the fox.

Hi Charles,

To understand Lance's request, you must understand his operating 
conditions. He does 6M moon-bounce Dxpeditions to remote places, which 
requires very low noise, high power, and big antennas. To minimize his 
need for power, which translates to minimizing the cost of buying and 
transporting fuel over oceans, and then to remote locations where 
there's no noise, he INVITES blind callers. This is a method of 
operation he devised years ago. He's currently somewhere in the South 
Pacific, don't remember where.

This is his website.  https://www.bigskyspaces.com/  Scroll down to see 
his instructions to callers.

I would encourage the development team to take his request seriously and 
do your best to accommodate it.

73, Jim K9YC

Re: [wsjt-devel] Q65 Pileup Feature Request

[Charles S. <g3...@gm...>]

Hi Lance

I'll leave it others to comment on the first part of your request

It seems from your last point that you suffer a lot from 'blind calling'.
This was a real problem during the early days of Superfox mode, and was
overcome by code that prevents a 'hound' from transmitting at all until
they have managed to decode the signal from the fox.

The code for this exists already, and could perhaps be applied to Q65
pileup at some point if you felt this would at least partially alleviate
your problem.

In the meantime, perhaps you could ask your followers to just adopt the
discipline of not calling you unless they have decoded you first, in
everybody's interest.

73

Charlie DL3WDG

On Tue, 19 Aug 2025 at 00:08, Lance Collister, W7GJ via wsjt-devel <
wsj...@li...> wrote:

> This request is for a feature that would (I think) be primarily of use
> during pileup situations during DXpeditions. So Q65 PILEUP makes it the
> logical place for it. As I have been suggesting for years, it would be
> EXTREMELY HELPFUL and make DXpedition operations so much more
> productive, if there could be an indicator when a station is receiving
> during the last receive sequence. When multiple stations are calling at
> the same time (especially during common moonset windows), a lot of time
> can be wasted by cycling through the list of all the callers and trying
> to reply to each one to see if there happens to be any reciprocal
> propagation with any of them. By the time one tries responding to 10 or
> 12 callers, plus delays in running out to aim the antenna, considerable
> valuable common moon time has been used up :-(  I don't profess to have
> any idea how the system works, but here are my suggestions from a
> DXpeditioner's point of view:
>
> 1. In Q65 PILEUP, apparently there is some way to transmit "R" with the
> callsigns and grid TX3) and for that information to be received by the
> other station.
>
> 2. If a station could optionally turn on the feature, perhaps they could
> send an * (or some other symbol or letter or number) when they receive a
> yellow spike (perhaps with some adjustable threshold above the
> background noise) during their previous reception period.
>
> 3. The DXpedition station could receive the new TX3 message with the *
> (or whatever instead of the R), and know that he could reply with a
> standard TX3 message and have it received by that caller. Of course,
> reception of that * message should not engage the AUTO SEQUENCE.  If the
> caller stops receiving a yellow spike, the program would go back to
> automatically sending TX2.
>
> The HUGE advantage would be that the DXpedition station would be able to
> identify stations that have the capability for a reciprocal contact!
> Today, for example, I spent a lot time replying to a number of different
> stations who never received any decodes from me at all when I tried to
> reply to them :-(
>
> MNI TNX for your kind consideration!  VY 73, Lance  at H40GJ
>
> --
> Lance Collister, W7GJ (ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX,
> 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ,
> S79GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
> P.O. Box 73
> Frenchtown, MT   59834-0073
> USA
> TEL: (406) 626-5728
> QTH: DN27ub
> URL: http://www.bigskyspaces.com/w7gj
> Skype: lanceW7GJ
> 2m DXCC #11 - 6m DXCC #815 - FFMA #7
>
> Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
> email group, or just fill in the request box at the bottom of my web
> page (above)!
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

[wsjt-devel] Q65 Pileup Feature Request

[Lance C. W. <w7...@bi...>]

This request is for a feature that would (I think) be primarily of use 
during pileup situations during DXpeditions. So Q65 PILEUP makes it the 
logical place for it. As I have been suggesting for years, it would be 
EXTREMELY HELPFUL and make DXpedition operations so much more 
productive, if there could be an indicator when a station is receiving 
during the last receive sequence. When multiple stations are calling at 
the same time (especially during common moonset windows), a lot of time 
can be wasted by cycling through the list of all the callers and trying 
to reply to each one to see if there happens to be any reciprocal 
propagation with any of them. By the time one tries responding to 10 or 
12 callers, plus delays in running out to aim the antenna, considerable 
valuable common moon time has been used up :-(  I don't profess to have 
any idea how the system works, but here are my suggestions from a 
DXpeditioner's point of view:

1. In Q65 PILEUP, apparently there is some way to transmit "R" with the 
callsigns and grid TX3) and for that information to be received by the 
other station.

2. If a station could optionally turn on the feature, perhaps they could 
send an * (or some other symbol or letter or number) when they receive a 
yellow spike (perhaps with some adjustable threshold above the 
background noise) during their previous reception period.

3. The DXpedition station could receive the new TX3 message with the * 
(or whatever instead of the R), and know that he could reply with a 
standard TX3 message and have it received by that caller. Of course, 
reception of that * message should not engage the AUTO SEQUENCE.  If the 
caller stops receiving a yellow spike, the program would go back to 
automatically sending TX2.

The HUGE advantage would be that the DXpedition station would be able to 
identify stations that have the capability for a reciprocal contact! 
Today, for example, I spent a lot time replying to a number of different 
stations who never received any decodes from me at all when I tried to 
reply to them :-(

MNI TNX for your kind consideration!  VY 73, Lance  at H40GJ

-- 
Lance Collister, W7GJ (ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!

[wsjt-devel] JTAlert

[f5mnw <f5...@sf...>]

‌Hello everyone,

I just installed the V 2.80.4 JTAlert.

Fake Manip?? I only have the main window displayed, I no longer have the 'All Decode' window...

Thank you for your help.

Guy/F5MNW

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Peter S. <vk...@gm...>]

Hello,
 it seems users of FLRIg and WSJT-X / Improved are not too common, what I
have found so far is, when WSJT-X starts, it queries the list of rigs from
the HAMLIB DLL (lib-hamlib-4.dll) to create its rig list.  This list of
rigs appears to be a dynamic array as when HAMLIB finds any updated
information it then presents that updated information to WSJT-X and the
list of rigs when the pulldown list is viewed next.

In WSJT-X 2.61 and before, the HAMLIB DLL that is part of the package
provides only the 'basic' information from FLRig and in this way provides a
stable RigName during use in the lrig list and in the WSJT-X.INI file.
This version from WSJT-X v2.61 shows up as being: "HamLib 4.5~git Mon Jun
13 14:51:03 2022"

At some point HAMLIB was changed to pass through extra information from
FLRig, in this case it is the type of Rig that FLRig is connected to that
is now passed through to WSJT-X.  In my case, it is an Icom IC-7610.

Initially the list of Rig types has a Rig type of "FLRig FLRig" in the
earlier version of the DLL that came with WSJT-X 2.61 but the Release
candidates of WSJT-X v2.7x all came with an updated HAMLIB that includes
the extra information being passed through to it and ultimately defective
for WSJT-X user that have FLRig in use.

I have had a response from one of the HAMLIB team (Nate N0NB) that he had
an update in play to correct the name for FLRig in the list to
be: Manufacturer to "W1HJK" and the Model to "FLrig". which means all new
HAMLIB DLL's with have the entry for FLRig as "WIHJK FLRig"

Unfortunately this is just a cosmetic change for my needs as even this new
DLL still gets the actual name of the Rig from FLFRig and dynamically
changes the list from this: "W1HKJ FLRig" to this: "W1HKJ IC-7610(FLRig)"

One could say this is all just cosmetic BUT the information in the Rig List
is used to write data into the WSJT-X.INI for the next startup or to define
other WSJT-X configurations.  This then means what rig type in the INI file
does not match the initial list of rigs queried from HAMLIB and then WSJT-X
has a hissy fit and I get a world of hurt.

For 99.9% of you, this probably will never happen but for me it's chaos.  I
can avoid all this by replacing the lib-hamlib-4.dll file with an older one
each time WSJT-X gets an update but eventually there will be a critical
change that stops me doing this.

While this is primarily not a WSJT-X error and seems to live in the HAMLIB
arena, I thought I would round out this topic as this is where it started
and will pursue this with the HAMLIB team via their 'sourceforge' help
forum.

Regards,
Peter, vk5pj

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Conrad F. <g0...@g0...>]

Same here Peter, what a shame. Mike was (always) helpful. I feel a little ashamed that it took me 4 months to realise.

Rest in peace Mike.

Regards

Conrad PA5Y

From: Peter Sumner via wsjt-devel <wsj...@li...>
Sent: Wednesday, 30 July 2025 14:45
To: Wolfgang <oe...@gm...>; WSJT software development <wsj...@li...>
Cc: Peter Sumner <vk...@gm...>
Subject: Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

thanks Wolfgang,

I knew Mike was unwell but had no idea he had passed away, that is quite a loss for the ham community.

regards,
Peter vk5pj

On Wed, Jul 30, 2025 at 9:13 PM Wolfgang via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> wrote:

Hello Peter,



a simple search using 'ReplaceStudio64' will reveal that 'Flrig' or 'flrig' string is only in "libhamlib-4.dll"



Btw., Mike is SK since a while. He may rest in peace.



73's de OE1MWW

Wolfgang





Wednesday, July 30, 2025, 12:39:51 PM, you wrote:


Hi,
 if there is anyone who reads this who is familiar with the source code for WSJT-X who could help me identify how the list of rigs in the 'RADIO' tab gets populated?  I have been wandering through the source (downloaded a tarball from the main WSJT-X web site) but my level of experience is just scripting, its all a bit much for me.

My theory at this point is the list of rigs has an error in it or the way the list is read has an error.  In ver 2.61 the rig list showed the entry for FLrig as being: "FLRig FLRig"  and the INI file shows it as: Rig=FLRig FLRig

When I go to one of the 2.7x version, the entry for FLRig is just : "FLRig" and in the INI file it is:  Rig="FLRig "

next test...

On my ver 2.61 folder if I change the libhamlib-4.dll to be a newer version the wheels fall off with the same problems at startup (radio selection goes back to Adat and a com port) I see on ver 2.7x  BUT if I try the reverse and install an OLD libhamlib-4.dll into the ver 2.7x folder it does not improve things sadly but will recheck this in the morning (8pm local and feeling tired)

Does WSJT-X read the list of rigs from the Hamlib DLL file to populate the list of rigs on the radio TAB of the Settings screen?  as it feels like that is what is happening as when I change the Hamlib DLL's, the entry for FLRig changes inside WSJT-X.

If this a Hamlib error, then I guess I need to contact Mike but until I can clarify where it is I am lost to know where to look.

Regards,
Peter vk5pj





----------

under construction: https://www.oe1mww.work/
_______________________________________________
wsjt-devel mailing list
wsj...@li...<mailto:wsj...@li...>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Peter S. <vk...@gm...>]

thanks Wolfgang,

I knew Mike was unwell but had no idea he had passed away, that is quite a
loss for the ham community.

regards,
Peter vk5pj

On Wed, Jul 30, 2025 at 9:13 PM Wolfgang via wsjt-devel <
wsj...@li...> wrote:

> Hello Peter,
>
>
>
> a simple search using 'ReplaceStudio64' will reveal that 'Flrig' or
> 'flrig' string is only in "libhamlib-4.dll"
>
>
>
> Btw., Mike is SK since a while. He may rest in peace.
>
>
>
> 73's de OE1MWW
>
> Wolfgang
>
>
>
> Wednesday, July 30, 2025, 12:39:51 PM, you wrote:
>
>
> Hi,
>  if there is anyone who reads this who is familiar with the source code
> for WSJT-X who could help me identify how the list of rigs in the 'RADIO'
> tab gets populated?  I have been wandering through the source (downloaded a
> tarball from the main WSJT-X web site) but my level of experience is just
> scripting, its all a bit much for me.
>
> My theory at this point is the list of rigs has an error in it or the way
> the list is read has an error.  In ver 2.61 the rig list showed the entry
> for FLrig as being: "FLRig FLRig"  and the INI file shows it as: Rig=FLRig
> FLRig
>
> When I go to one of the 2.7x version, the entry for FLRig is just :
> "FLRig" and in the INI file it is:  Rig="FLRig "
>
> next test...
>
> On my ver 2.61 folder if I change the libhamlib-4.dll to be a newer
> version the wheels fall off with the same problems at startup (radio
> selection goes back to Adat and a com port) I see on ver 2.7x  BUT if I try
> the reverse and install an OLD libhamlib-4.dll into the ver 2.7x folder it
> does not improve things sadly but will recheck this in the morning (8pm
> local and feeling tired)
>
> Does WSJT-X read the list of rigs from the Hamlib DLL file to populate the
> list of rigs on the radio TAB of the Settings screen?  as it feels like
> that is what is happening as when I change the Hamlib DLL's, the entry for
> FLRig changes inside WSJT-X.
>
> If this a Hamlib error, then I guess I need to contact Mike but until I
> can clarify where it is I am lost to know where to look.
>
> Regards,
> Peter vk5pj
>
>
>
> ----------
>
> under construction: https://www.oe1mww.work/
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Wolfgang <oe...@gm...>]

Hello Peter,
 
a simple search using 'ReplaceStudio64' will reveal that 'Flrig' or 'flrig' string is only in "libhamlib-4.dll"
 
Btw., Mike is SK since a while. He may rest in peace.
 
73's de OE1MWW
Wolfgang 


Wednesday, July 30, 2025, 12:39:51 PM, you wrote:

> Hi,
>  if there is anyone who reads this who is familiar with the source code for WSJT-X who could help me identify how the list of rigs in the 'RADIO' tab gets populated?  I have been wandering through the source (downloaded a tarball from the main WSJT-X web site) but my level of experience is just scripting, its all a bit much for me.

> My theory at this point is the list of rigs has an error in it or the way the list is read has an error.  In ver 2.61 the rig list showed the entry for FLrig as being: "FLRig FLRig"  and the INI file shows it as: Rig=FLRig FLRig

> When I go to one of the 2.7x version, the entry for FLRig is just : "FLRig" and in the INI file it is:  Rig="FLRig "

> next test...

> On my ver 2.61 folder if I change the libhamlib-4.dll to be a newer version the wheels fall off with the same problems at startup (radio selection goes back to Adat and a com port) I see on ver 2.7x  BUT if I try the reverse and install an OLD libhamlib-4.dll into the ver 2.7x folder it does not improve things sadly but will recheck this in the morning (8pm local and feeling tired)

> Does WSJT-X read the list of rigs from the Hamlib DLL file to populate the list of rigs on the radio TAB of the Settings screen?  as it feels like that is what is happening as when I change the Hamlib DLL's, the entry for FLRig changes inside WSJT-X.

> If this a Hamlib error, then I guess I need to contact Mike but until I can clarify where it is I am lost to know where to look.

> Regards,
> Peter vk5pj

----------
under construction: https://www.oe1mww.work/

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Peter S. <vk...@gm...>]

Hi,
 if there is anyone who reads this who is familiar with the source code for
WSJT-X who could help me identify how the list of rigs in the 'RADIO' tab
gets populated?  I have been wandering through the source (downloaded a
tarball from the main WSJT-X web site) but my level of experience is just
scripting, its all a bit much for me.

My theory at this point is the list of rigs has an error in it or the way
the list is read has an error.  In ver 2.61 the rig list showed the entry
for FLrig as being: "FLRig FLRig"  and the INI file shows it as: Rig=FLRig
FLRig

When I go to one of the 2.7x version, the entry for FLRig is just : "FLRig"
and in the INI file it is:  Rig="FLRig "

next test...

On my ver 2.61 folder if I change the libhamlib-4.dll to be a newer version
the wheels fall off with the same problems at startup (radio selection goes
back to Adat and a com port) I see on ver 2.7x  BUT if I try the reverse
and install an OLD libhamlib-4.dll into the ver 2.7x folder it does not
improve things sadly but will recheck this in the morning (8pm local and
feeling tired)

Does WSJT-X read the list of rigs from the Hamlib DLL file to populate the
list of rigs on the radio TAB of the Settings screen?  as it feels like
that is what is happening as when I change the Hamlib DLL's, the entry for
FLRig changes inside WSJT-X.

If this a Hamlib error, then I guess I need to contact Mike but until I can
clarify where it is I am lost to know where to look.

Regards,
Peter vk5pj




> On Saturday, July 26, 2025 at 09:22:07 PM EDT, Peter Sumner via wsjt-devel
> <wsj...@li...> wrote:
>
>
> Hi,
>  for some time now (all of the 2.7 variants and now 2.8) when I open
> WJST-X or swap between configurations, I end up with a rig control error
> and the current rig is shown to be "ADAT www.adat.ch" and not the
> previously selected FLRIG setting.
>
> I have learned to live with this for a while and today decided I should
> report this difficulty for evaluation.
>
> I use the FLRIG interface as it lets me see on my PC desktop what the SWR,
> power out and other settings of my two icom rigs as I do a lot of operating
> from the comfort of the house rather than the 50 metre journey to my shack
> in the stables shed.
>
> So far I have tried an empty INI file a few times and the error occurs
> with each iteration of testing I do, where I have set up multiple
> configurations.
>
> If I leave it as a SINGLE configuration then there is no error seen. Once
> I add a second or more configuration using FLRIG as the rig type I start
> seeing the Rig control error when starting WSJT-X or swapping
> configurations.
>
> When testing, if I use a direct connection (IC-7610) then I can add
> multiple configurations and not see an error when starting or swapping
> configs so the error seems to be confined to having FLRIG selected as a rig
> type.
>
> PC is a Windows 10 X64 O/S which is current with all updates.
>
> I have noticed that in the WSJT-X.INI file, that FLRig is shown in there
> with a trailing space and has inverted commas in some instances and in
> differently in other config (quite a puzzle for me), where as other entries
> are not shown like that, here are some examples from my BIG ini file that
> has about 8 configurations in it
>
> Rig=Icom IC-7610
> Rig=FLRig FLRig
> Rig="FLRig "
> Rig=FLRig IC-7610(FLRig)
>
> hope I have no missed anything, any help would be appreciated
>
> Regards,
> Peter, vk5pj
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] CMake 4.0 compatibility (and Fortran issue)

[Richard S. <hob...@gm...>]

On Tue, Jul 22, 2025 at 8:33 PM Richard Shaw <hob...@gm...> wrote:

> I "fixed" it by adding "-z noexecstack" to LDFLAGS but I'm not sure it's a
> good idea to add this as a global linking flag.
>

That is indeed a bad idea, it breaks other fortran objects...

I also tried applying -no-automatic to just the fortran target and just to
decoder.f90 but did not have any success.

Hopefully this is being addressed. Until it is, WSJTX cannot be built in
Fedora Rawhide (future 43 release).

Thanks,
Richard
KF5OIM

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Peter S. <vk...@gm...>]

Hello,
  when I look at this further and compare running up ver 2.61 and any of
the 2.7x versions I have, the pull down list for choosing the RIG in
version 2.61 shows an option with this text: FLRig FLRig     any of the 2.7
or 2.8 releases in that same section of the rig selector show just: FLRig

I am unsure if this is an error in an array of rigs or some other method
used to populate the list of rigs but what is in the pull down list seems
to correlate to what is populated in the WSJT-X.ini file.  At some point
when the 'bad' value is read at startup it seems to trigger an error and
this is the details of the error:

Hamlib error: rig_token_lookup called for client

rig_confparam_lookup called for client

1:rig.c(817):rig_open entered

rig_settings_get_path: path=.hamlib_settings

rig_settings_load_all: settings_file (.hamlib_settings): No such file or
directory

rig_open: cwd=C:\ham_radio\wsjtx-2.8.0-imp\bin

rig_open: C:\ham_radio\wsjtx-2.8.0-imp\bin/hamlib_settings does not exist

rig_open: async_data_enable=0, async_data_supported=0

serial_open: COM3

serial_open(229): open failed#1

serial_open(229): open failed#2

serial_open(229): open failed#3

serial_open(229): open failed#4

serial_open: Unable to open COM3 - No such file or directory

port_open: serial_open(COM3) status=-6, err=No such file or directory

rig_open: rs->comm_state==0?=0

1:rig.c(1023):rig_open returning(-6) IO error


IO error

IO error

while opening connection to rig


Timestamp: 2025-07-28T06:57:34.969Z


There is no COM port in my configuration, CAT is used for PTT so I have no
clue why it is trying to open COM3 (My 1st COM port on the PC)


Regards,

Peter, vk5pj



On Sun, Jul 27, 2025 at 10:48 AM Peter Sumner <vk...@gm...> wrote:

> Hi,
>  for some time now (all of the 2.7 variants and now 2.8) when I open
> WJST-X or swap between configurations, I end up with a rig control error
> and the current rig is shown to be "ADAT www.adat.ch" and not the
> previously selected FLRIG setting.
>
> I have learned to live with this for a while and today decided I should
> report this difficulty for evaluation.
>
> I use the FLRIG interface as it lets me see on my PC desktop what the SWR,
> power out and other settings of my two icom rigs as I do a lot of operating
> from the comfort of the house rather than the 50 metre journey to my shack
> in the stables shed.
>
> So far I have tried an empty INI file a few times and the error occurs
> with each iteration of testing I do, where I have set up multiple
> configurations.
>
> If I leave it as a SINGLE configuration then there is no error seen. Once
> I add a second or more configuration using FLRIG as the rig type I start
> seeing the Rig control error when starting WSJT-X or swapping
> configurations.
>
> When testing, if I use a direct connection (IC-7610) then I can add
> multiple configurations and not see an error when starting or swapping
> configs so the error seems to be confined to having FLRIG selected as a rig
> type.
>
> PC is a Windows 10 X64 O/S which is current with all updates.
>
> I have noticed that in the WSJT-X.INI file, that FLRig is shown in there
> with a trailing space and has inverted commas in some instances and in
> differently in other config (quite a puzzle for me), where as other entries
> are not shown like that, here are some examples from my BIG ini file that
> has about 8 configurations in it
>
> Rig=Icom IC-7610
> Rig=FLRig FLRig
> Rig="FLRig "
> Rig=FLRig IC-7610(FLRig)
>
> hope I have no missed anything, any help would be appreciated
>
> Regards,
> Peter, vk5pj
>

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Andrew N. <ka...@ya...>]

 Peter,
I should have pointed out that there are several support pages for W1HKJ software, depending on the O/S you are using.  Here is the link for W1HKJ website, there are more details there.  
73,Andy, ka2uqw
https://www.w1hkj.org/

    On Sunday, July 27, 2025 at 06:01:54 PM EDT, Peter Sumner via wsjt-devel <wsj...@li...> wrote:  
 
 Hi Andy, thanks for the link, will have a look there.
Since my original post I have dug deeper and widened my field of testing.   I can see on 'other' derivatives of WSJT-X that the rig type is stored as "Q65-eme\Configuration\Rig=FLRig FLRig" and not the mangled: Rig="FLRig " I see in the current releases of WSJT-X and the Improved version.
It would seem an error has crept into the code base at some point that mangles the storage of this parameter when selecting FLRig in the Configuration menu.
Regards,Peter, vk5pj
On Mon, Jul 28, 2025 at 3:07 AM Andrew Neumeier via wsjt-devel <wsj...@li...> wrote:

 Peter,
I don't know if this is a wjstx issue or a flrig issue.  If you are unable to rectify your problem with help from this group, may I suggest posing the question to the linuxham group.  I have placed the link below.  That group is active and involves the programs created by W1HKJ, including flrig. 
Best of luck,73,Andy, ka2uqw
https://groups.io/g/linuxham




    On Saturday, July 26, 2025 at 09:22:07 PM EDT, Peter Sumner via wsjt-devel <wsj...@li...> wrote:  
 
 Hi, for some time now (all of the 2.7 variants and now 2.8) when I open WJST-X or swap between configurations, I end up with a rig control error and the current rig is shown to be "ADAT www.adat.ch" and not the previously selected FLRIG setting.
I have learned to live with this for a while and today decided I should report this difficulty for evaluation.
I use the FLRIG interface as it lets me see on my PC desktop what the SWR, power out and other settings of my two icom rigs as I do a lot of operating from the comfort of the house rather than the 50 metre journey to my shack in the stables shed.
So far I have tried an empty INI file a few times and the error occurs with each iteration of testing I do, where I have set up multiple configurations.
If I leave it as a SINGLE configuration then there is no error seen. Once I add a second or more configuration using FLRIG as the rig type I start seeing the Rig control error when starting WSJT-X or swapping configurations.
When testing, if I use a direct connection (IC-7610) then I can add multiple configurations and not see an error when starting or swapping configs so the error seems to be confined to having FLRIG selected as a rig type.
PC is a Windows 10 X64 O/S which is current with all updates.
I have noticed that in the WSJT-X.INI file, that FLRig is shown in there with a trailing space and has inverted commas in some instances and in differently in other config (quite a puzzle for me), where as other entries are not shown like that, here are some examples from my BIG ini file that has about 8 configurations in it
Rig=Icom IC-7610Rig=FLRig FLRigRig="FLRig "Rig=FLRig IC-7610(FLRig)
hope I have no missed anything, any help would be appreciated
Regards,Peter, vk5pj_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  _______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Doug B. Sr. <dou...@gm...>]

Great use for AI: have it deal with the configuration for Flrig, Fldigi,
Js8call and Wsjtx.

"AI, I'm going to get a coffee, when I come back, have these all talking to
the radio properly, and have it come up the same way every time things get
posted up. Cheers"



On Sun, Jul 27, 2025, 6:03 PM Peter Sumner via wsjt-devel <
wsj...@li...> wrote:

> Hi Andy,
>  thanks for the link, will have a look there.
>
> Since my original post I have dug deeper and widened my field of testing.
>  I can see on 'other' derivatives of WSJT-X that the rig type is stored as
> "Q65-eme\Configuration\Rig=FLRig FLRig" and not the mangled: Rig="FLRig " I
> see in the current releases of WSJT-X and the Improved version.
>
> It would seem an error has crept into the code base at some point that
> mangles the storage of this parameter when selecting FLRig in the
> Configuration menu.
>
> Regards,
> Peter, vk5pj
>
> On Mon, Jul 28, 2025 at 3:07 AM Andrew Neumeier via wsjt-devel <
> wsj...@li...> wrote:
>
>> Peter,
>>
>> I don't know if this is a wjstx issue or a flrig issue.  If you are
>> unable to rectify your problem with help from this group, may I suggest
>> posing the question to the linuxham group.  I have placed the link below.
>> That group is active and involves the programs created by W1HKJ, including
>> flrig.
>>
>> Best of luck,
>> 73,
>> Andy, ka2uqw
>>
>> https://groups.io/g/linuxham
>>
>>
>>
>>
>>
>> On Saturday, July 26, 2025 at 09:22:07 PM EDT, Peter Sumner via
>> wsjt-devel <wsj...@li...> wrote:
>>
>>
>> Hi,
>>  for some time now (all of the 2.7 variants and now 2.8) when I open
>> WJST-X or swap between configurations, I end up with a rig control error
>> and the current rig is shown to be "ADAT www.adat.ch" and not the
>> previously selected FLRIG setting.
>>
>> I have learned to live with this for a while and today decided I should
>> report this difficulty for evaluation.
>>
>> I use the FLRIG interface as it lets me see on my PC desktop what the
>> SWR, power out and other settings of my two icom rigs as I do a lot of
>> operating from the comfort of the house rather than the 50 metre journey to
>> my shack in the stables shed.
>>
>> So far I have tried an empty INI file a few times and the error occurs
>> with each iteration of testing I do, where I have set up multiple
>> configurations.
>>
>> If I leave it as a SINGLE configuration then there is no error seen. Once
>> I add a second or more configuration using FLRIG as the rig type I start
>> seeing the Rig control error when starting WSJT-X or swapping
>> configurations.
>>
>> When testing, if I use a direct connection (IC-7610) then I can add
>> multiple configurations and not see an error when starting or swapping
>> configs so the error seems to be confined to having FLRIG selected as a rig
>> type.
>>
>> PC is a Windows 10 X64 O/S which is current with all updates.
>>
>> I have noticed that in the WSJT-X.INI file, that FLRig is shown in there
>> with a trailing space and has inverted commas in some instances and in
>> differently in other config (quite a puzzle for me), where as other entries
>> are not shown like that, here are some examples from my BIG ini file that
>> has about 8 configurations in it
>>
>> Rig=Icom IC-7610
>> Rig=FLRig FLRig
>> Rig="FLRig "
>> Rig=FLRig IC-7610(FLRig)
>>
>> hope I have no missed anything, any help would be appreciated
>>
>> Regards,
>> Peter, vk5pj
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Peter S. <vk...@gm...>]

Hi Andy,
 thanks for the link, will have a look there.

Since my original post I have dug deeper and widened my field of testing.
 I can see on 'other' derivatives of WSJT-X that the rig type is stored as
"Q65-eme\Configuration\Rig=FLRig FLRig" and not the mangled: Rig="FLRig " I
see in the current releases of WSJT-X and the Improved version.

It would seem an error has crept into the code base at some point that
mangles the storage of this parameter when selecting FLRig in the
Configuration menu.

Regards,
Peter, vk5pj

On Mon, Jul 28, 2025 at 3:07 AM Andrew Neumeier via wsjt-devel <
wsj...@li...> wrote:

> Peter,
>
> I don't know if this is a wjstx issue or a flrig issue.  If you are unable
> to rectify your problem with help from this group, may I suggest posing the
> question to the linuxham group.  I have placed the link below.  That group
> is active and involves the programs created by W1HKJ, including flrig.
>
> Best of luck,
> 73,
> Andy, ka2uqw
>
> https://groups.io/g/linuxham
>
>
>
>
>
> On Saturday, July 26, 2025 at 09:22:07 PM EDT, Peter Sumner via wsjt-devel
> <wsj...@li...> wrote:
>
>
> Hi,
>  for some time now (all of the 2.7 variants and now 2.8) when I open
> WJST-X or swap between configurations, I end up with a rig control error
> and the current rig is shown to be "ADAT www.adat.ch" and not the
> previously selected FLRIG setting.
>
> I have learned to live with this for a while and today decided I should
> report this difficulty for evaluation.
>
> I use the FLRIG interface as it lets me see on my PC desktop what the SWR,
> power out and other settings of my two icom rigs as I do a lot of operating
> from the comfort of the house rather than the 50 metre journey to my shack
> in the stables shed.
>
> So far I have tried an empty INI file a few times and the error occurs
> with each iteration of testing I do, where I have set up multiple
> configurations.
>
> If I leave it as a SINGLE configuration then there is no error seen. Once
> I add a second or more configuration using FLRIG as the rig type I start
> seeing the Rig control error when starting WSJT-X or swapping
> configurations.
>
> When testing, if I use a direct connection (IC-7610) then I can add
> multiple configurations and not see an error when starting or swapping
> configs so the error seems to be confined to having FLRIG selected as a rig
> type.
>
> PC is a Windows 10 X64 O/S which is current with all updates.
>
> I have noticed that in the WSJT-X.INI file, that FLRig is shown in there
> with a trailing space and has inverted commas in some instances and in
> differently in other config (quite a puzzle for me), where as other entries
> are not shown like that, here are some examples from my BIG ini file that
> has about 8 configurations in it
>
> Rig=Icom IC-7610
> Rig=FLRig FLRig
> Rig="FLRig "
> Rig=FLRig IC-7610(FLRig)
>
> hope I have no missed anything, any help would be appreciated
>
> Regards,
> Peter, vk5pj
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Andrew N. <ka...@ya...>]

 Peter,
I don't know if this is a wjstx issue or a flrig issue.  If you are unable to rectify your problem with help from this group, may I suggest posing the question to the linuxham group.  I have placed the link below.  That group is active and involves the programs created by W1HKJ, including flrig. 
Best of luck,73,Andy, ka2uqw
https://groups.io/g/linuxham




    On Saturday, July 26, 2025 at 09:22:07 PM EDT, Peter Sumner via wsjt-devel <wsj...@li...> wrote:  
 
 Hi, for some time now (all of the 2.7 variants and now 2.8) when I open WJST-X or swap between configurations, I end up with a rig control error and the current rig is shown to be "ADAT www.adat.ch" and not the previously selected FLRIG setting.
I have learned to live with this for a while and today decided I should report this difficulty for evaluation.
I use the FLRIG interface as it lets me see on my PC desktop what the SWR, power out and other settings of my two icom rigs as I do a lot of operating from the comfort of the house rather than the 50 metre journey to my shack in the stables shed.
So far I have tried an empty INI file a few times and the error occurs with each iteration of testing I do, where I have set up multiple configurations.
If I leave it as a SINGLE configuration then there is no error seen. Once I add a second or more configuration using FLRIG as the rig type I start seeing the Rig control error when starting WSJT-X or swapping configurations.
When testing, if I use a direct connection (IC-7610) then I can add multiple configurations and not see an error when starting or swapping configs so the error seems to be confined to having FLRIG selected as a rig type.
PC is a Windows 10 X64 O/S which is current with all updates.
I have noticed that in the WSJT-X.INI file, that FLRig is shown in there with a trailing space and has inverted commas in some instances and in differently in other config (quite a puzzle for me), where as other entries are not shown like that, here are some examples from my BIG ini file that has about 8 configurations in it
Rig=Icom IC-7610Rig=FLRig FLRigRig="FLRig "Rig=FLRig IC-7610(FLRig)
hope I have no missed anything, any help would be appreciated
Regards,Peter, vk5pj_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  

[wsjt-devel] when starting WSJT-X rig defaults to "ADAT www.adat.ch" and not the wanted rig

[Peter S. <vk...@gm...>]

Hi,
 for some time now (all of the 2.7 variants and now 2.8) when I open
WJST-X or swap between configurations, I end up with a rig control error
and the current rig is shown to be "ADAT www.adat.ch" and not the
previously selected FLRIG setting.

I have learned to live with this for a while and today decided I should
report this difficulty for evaluation.

I use the FLRIG interface as it lets me see on my PC desktop what the SWR,
power out and other settings of my two icom rigs as I do a lot of operating
from the comfort of the house rather than the 50 metre journey to my shack
in the stables shed.

So far I have tried an empty INI file a few times and the error occurs with
each iteration of testing I do, where I have set up multiple configurations.

If I leave it as a SINGLE configuration then there is no error seen. Once I
add a second or more configuration using FLRIG as the rig type I start
seeing the Rig control error when starting WSJT-X or swapping
configurations.

When testing, if I use a direct connection (IC-7610) then I can add
multiple configurations and not see an error when starting or swapping
configs so the error seems to be confined to having FLRIG selected as a rig
type.

PC is a Windows 10 X64 O/S which is current with all updates.

I have noticed that in the WSJT-X.INI file, that FLRig is shown in there
with a trailing space and has inverted commas in some instances and in
differently in other config (quite a puzzle for me), where as other entries
are not shown like that, here are some examples from my BIG ini file that
has about 8 configurations in it

Rig=Icom IC-7610
Rig=FLRig FLRig
Rig="FLRig "
Rig=FLRig IC-7610(FLRig)

hope I have no missed anything, any help would be appreciated

Regards,
Peter, vk5pj

[wsjt-devel] I have a question about JT65B.

[JP3EXR <ex...@gm...>]

Hi WSJT develop team.

 

I am Taka, Japanese 2m EMEer.

I always thank you for your supporting.

I have a question about run two JT65Bs of WSJT-X on one PC.

 

This is because, I happened the decoding not ended problem with non TX side
JT65B again.  This is because I replaced my WSJT-PC to new one for Windows
11 recently.  I noticed a strange situation with I am testing the run two
JT65Bs of WSJT-X on one PC.  I would like to confirm whether the following
picture of two JT65Bs main screen are as specified or if it is different.



You can see two JT65B main screens, I was TXing every even periods on the
left side JT65B.  At that time on the right side JT65B did not decoding
every even periods on the same periods.  Is this according to the
specifications? or bug?

 

And I have a question about run two JT65Bs of WSJT-X on one PC.

This is because, my JT65B is sensitive with the audio input level.  This
situation occurs when probably the audio input level from both RIGs is below
about 27dB or so.  I think if both audio input level from the RIGs rises
above that, on the right side JT65B that is not transmitting will start
decoding even periods too.  If the input level from the both RIGs then
exceeds probably 35dB, the right-side JT65B of the non TX side will be
decoding not ended situation with even period after TX.

 

Do you know why the non TX side JT65B is sensitive to the audio input level?

 

Taka, JP3EXR

Re: [wsjt-devel] CMake 4.0 compatibility (and Fortran issue)

[Richard S. <hob...@gm...>]

I "fixed" it by adding "-z noexecstack" to LDFLAGS but I'm not sure it's a
good idea to add this as a global linking flag.

Thanks,
Richard
KF5OIM

Re: [wsjt-devel] CMake 4.0 compatibility (and Fortran issue)

[Marco C. <PY...@ou...>]

Please be so kind to apply the change globally at the WSJT-X source 
code,  to avoid customization at the users end!

Many thanks for the advise!


Regards,

---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**


Il 22/07/25 10:30, Richard Shaw via wsjt-devel ha scritto:
> Fedora will be upgrading to CMake 4.0 which is dropping compatibility 
> with CMake versions < 3.5.
>
> This means that setting CMAKE_MINIMUM_REQUIRED < 3.5 will exit with an 
> error.
>
> My workaround for Fedora is to set CMAKE_POLICY_VERSION_MINIMUM=3.5 as 
> an environment variable or passed as an option to CMake, where I ran 
> into a new Fortran issue.
>
> /usr/bin/ld: error: decoder.f90.o: is triggering the generation of an 
> executable stack (because it has an executable .note.GNU-stack section)
> /usr/bin/ld: failed to set dynamic section sizes: No such file or 
> directory
> collect2: error: ld returned 1 exit status
>
> This of course usually happens with major updates to gcc (15.1.1) 
> which also updates fortran.
>
> Thanks,
> Richard
> KF5OIM
>

[wsjt-devel] CMake 4.0 compatibility (and Fortran issue)

[Richard S. <hob...@gm...>]

Fedora will be upgrading to CMake 4.0 which is dropping compatibility with
CMake versions < 3.5.

This means that setting CMAKE_MINIMUM_REQUIRED < 3.5 will exit with an
error.

My workaround for Fedora is to set CMAKE_POLICY_VERSION_MINIMUM=3.5 as an
environment variable or passed as an option to CMake, where I ran into a
new Fortran issue.

/usr/bin/ld: error: decoder.f90.o: is triggering the generation of an
executable stack (because it has an executable .note.GNU-stack section)
/usr/bin/ld: failed to set dynamic section sizes: No such file or directory
collect2: error: ld returned 1 exit status

This of course usually happens with major updates to gcc (15.1.1) which
also updates fortran.

Thanks,
Richard
KF5OIM

Re: [wsjt-devel] WSOT ???

[Jim B. <k9...@au...>]

Thanks, Joe. Yes, I did study both it and the corresponding doc for Q65 
carefully when the modes were introduced, but it took so long for the LF 
modes to find favor on 160M that I forgot about them. I did manage a 
160M QSO with a guy in VK. They are all great modes, and are much 
appreciated.

At your suggestion, I couldn't find a link, so did a google search. I 
did find the problem -- I needed to reset the working frequencies via 
the menu system to make that change. Seems to me that ought to be more 
prominently noted in the doc. And it could be why it's taken so long for 
FST4W to take over from WSPR.

BTW -- during the few evenings I was monitoring, all the activity I saw 
was down around 1300 Hz offset.

73, Jim K9YC

On 7/21/2025 6:25 AM, Joseph Taylor via wsjt-devel wrote:
> Did you find and read "Quick-Start Guide to FST4 and FST4W"

Re: [wsjt-devel] WSOT ???

[Joseph T. <jo...@Pr...>]

On 7/17 Jim Brown K9YC wrote:

> BUT -- a question emerged. There were several other signals on the band
> last night with solidly visible traces for the entire 2 minute period,
> but when I moved the window to include a few hundred Hz to include them,
> they didn't decode, but WB6CXC did. Does FST4W only decode one signal at
> at a time. I looked for documentation specific to FST4W, but didn't find
> anything.

Hmmm... Did you look on the WSJT-X Help menu?  Did you find and read "Quick-Start Guide to FST4 and FST4W" and have additional questions?  Feel free to post them here, perhaps with a link to a saved .wav file.

    -- 73, Joe, K1JT

Re: [wsjt-devel] Icom IC-910 rig failure

[Kyle Y <yo...@gm...>]

Hello all. Thanks for the comments and suggestions. I am using the 64 bit
version of WSJT-x 2.7.0 b4f9a4 on a Windows 10 machine. I have tried both
auto Baud rate and a fixed baud rate on the radio. Today's attempt was from
a fresh reboot and WSJT-x was ran before Ham Radio Deluxe or any other
program that uses the CI-v protocol to talk to the radios. I am able to
control my Icom 706mk2g with WSJT-x and the same interface but not my
IC-910.

After noting the failures here, I closed WSJT-x and opened Ham Radio
Deluxe, It connects to my IC-910 no problem.

I have attached part of my syslog from today's attempt to use the Icom 910.
One thing I've noticed is that the errors mention both the IC7300 and
IC9700:

Command rejected by the rig
[SYSLOG][2025-07-19 16:00:35.121753][00:00:24.063441][error]
handle_transceiver_failure: reason: Hamlib error:
**2:ic7300.c(2390):ic9700_set_vfo returning(-9) Command rejected by the rig

Command rejected by the rig

Thanks for any suggestions. 73

Kyle
K0KN


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Jul 19, 2025 at 2:27 AM Peter Sumner via wsjt-devel <
wsj...@li...> wrote:

> Hi Kyle,
>  seems odd for Hamlib to throw an error for a 910 connection, I use it
> every week in MSK144 skeds without ever seeing an error (i know that does
> not help you). To check I just updated HAMLIB too, I now have 4.7~git
> 2025-07-15T in use and that works well too.
>
> Are you on Windows X64 or a 32bit version?
>
> Can you try a reboot and NOT open HRD before you try WSJT-X to see if it
> works?
>
> Hope you find an answer soon.
> Peter, VK5PJ
>
> On Sat, Jul 19, 2025 at 8:27 AM Kyle Y via wsjt-devel <
> wsj...@li...> wrote:
>
>> [image: image.png]
>>
>> Hello,
>>
>> I am having trouble using WSJT-x version 2.7.0 with my Icom IC-910.
>>
>> I can connect via Ham Radio Deluxe but attempting to connect directly
>> gives me the following error. Looks like maybe WSJT-x is using the IC-9700
>> radio info instead of the IC-910. See attached. I updated Hamlib within
>> WSJT-x to the latest version 4.7~git 2025-0710
>>
>> Thanks. 73
>>
>> Kyle
>> K0KN
>>
>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> Virus-free.www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> <#m_-3255328679627688007_m_2584336365070807127_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>