Re: [wsjt-devel] Remote WSJT

[Kevin McQuiggin (SFU) via wsjt-devel]

That’s what we did for Linux on my project, but it’s kind of a kludge.  Better to have WSJT-X be able to handle audio IQ natively.On the Mac I used netcat and the “Blackhole” virtual audio driver.  I pointed WSJT-X at the virtual audio device.73,KevinSent from my iPadOn Feb 28, 2024, at 11:15, Thomas Reynolds via wsjt-devel  wrote:In the Linux world you can use PulseAudio to transport soundcard audio from a remote RPi and radio over the net to a local desktop running WSJT-X.  I do this.  It works fine provided that the latency is not too large.On Wed, Feb 28, 2024 at 11:03 AM Alex, VE3NEA via wsjt-devel  wrote:Splitting the UI and data processing code would mean a major rewrite of the project. It might be much easier to implement some 
API, e.g. REST-based, for the functions that are currently performed via the UI. Then WSJT-X would run with its main window 
minimized or hidden on the remote system, and the controlling app with UI would run in the shack.

73 Alex VE3NEA


On 2024-02-28 13:12, Rafael Pinto via wsjt-devel wrote:
> William,
> 
> You got the architecture right. The point is not having to render images and treat UI events, thus having all processing power 
> for mathematical computation. X Windows System and Wayland are memory and CPU hogs and in some cases those resources are at a 
> premium...
> 
> As I read the code, trying to figure out how WSTJ-X works, I notice how tightly coupled UI and data processing are. I understand 
> it can be easier to show things on the GUI, but decoupling those could allow for some different UX  (text-only, for example) or, 
> as I suggested, some "smart" remoting.
> 
> To be 100% honest, the distributed processing approach I proposed is just a thought experiment on how to decouple the many 
> modules. Having each "module" on a different machine is usually how I think when I try to decouple complex stuff.
> 
> I'll keep studying the code to try and figure out how it would be possible...
> 
> 73
> 
> Rafael
> 
> On Wed, Feb 28, 2024 at 1:01 PM William Smith via wsjt-devel  wsjt-devel@lists.sourceforge.net>> wrote:
> 
>     I get what you were trying to do, and it is not a perfect solution, but many people use VNC or some other kind of remote
>     desktop protocol to remotely control the computer that is running WSJT.
> 
>     Yes, it would be much better to unload the GUI and the output video requirements from the poor Raspberry Pi and let that run
>     on some machine that has a lot more available horsepower. However, as you are determining, that is a lot of work, and the
>     remote desktop thing has the advantage of not requiring any coding at all from the WSJT team.
> 
>     73, Willie N1JBJ
> 
> 
>      > On Feb 28, 2024, at 7:11 AM, Rafael Pinto via wsjt-devel      wsjt-devel@lists.sourceforge.net>> 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 wsjt-devel@lists.sourceforge.net>
>      > https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
> 
>     ___
>     wsjt-devel mailing list
>     wsjt-devel@lists.sourceforge.net 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 listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel___
wsjt-devel mailing list

Re: [wsjt-devel] Remote WSJT (IQ I/O for WSJT-X)

[Kevin McQuiggin via wsjt-devel]

Hi All:

A perfect solution would be to uncouple WSJT-X from sound cards and simply 
allow it to send and receive audio IQ data over the net.  This would allow 
WSJT-X to run anywhere, as long as it could send/receive the audio IQ.  A 
straightforward interface at the radio end of the link would interact with a 
WSJT-X IP connection to send and receive the IQ.

You could run a local copy of WSJT-X to connect to a radio anywhere.

I have code that provides the “radio end” of this functionaltiy that I 
developed as part of a software-based EME SDR project here.  It’s an 
software-based solution that uses an Ettus SDR as the front end.  It generates 
IQ audio output for a specific frequency and bandwidth, and accepts audio IQ 
input which gets up-converted and transmitted.  The RF frequency and bandwidth 
are controllable by WSJT-X or through a control port.  You just telnet to my 
server, but it has a hamlib emulator as well so that WSJT-X can interact with 
it.  WSJT-X thinks it is talking with a rig.

However, because WSJT-X cannot currently work on IQ data I have to shoe-horn 
the IQ data through a virtual sound card to keep WSJT-X happy.  This would be 
an unnecessary step  if WSJT-X could work with IQ audio directly.

I have mentioned this to the WSJT-X team in the past (say 2-3 years ago) but 
with the passing of Bill Sommerville I don’t know if anyone is still aware of, 
or working on the idea.
for a specific frequency and bandwidth

73,

Kevin

> On Feb 28, 2024, at 4:08 AM, 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



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Auto-logging for iOS compiuters

[Kevin McQuiggin via wsjt-devel]

Hi Marty:

MacLoggerDX is an excellent logging program for MacOS, and it includes 
automatic uploading of QSOs to LoTW in real time.  See 
https://dogparksoftware.com/MacLoggerDX.html.

It does not run on iOS though.  Do you really need a logging program for your 
iPhone/iPad?  Perhaps you meant MacOS.

73,

Kevin VE7ZD


> On Feb 20, 2024, at 2:53 PM, Marty Wayne via wsjt-devel 
>  wrote:
> 
> I have seen and heard of programs that automatically log a contact to LoTW 
> but as far as I can determine, they are all .exe applications are there any 
> for iOS?
> 
> Marty Wayne
> mcway...@comcast.net
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign Security

[Kevin McQuiggin via wsjt-devel]

It won’t “solve” the problem, but you can always register for a free account at 
https://hamalert.org  and set up a trigger for your own 
callsign.  Then you will receive an email or a text message when your call is 
spotted on the bands.

It doesn’t solve the problem but at least you will know when a pirate is using 
your call; you can then post messages or alerts on various sites saying that 
the rogue operation is fake.

73,

Kevin VE7ZD/KN7Q



> On Oct 5, 2023, at 1:33 AM, Adrian via wsjt-devel 
>  wrote:
> 
> As a victim of another local foundation ham (caught) unlawfully using my 
> callsign on 20m FT8 recently, and reports
> 
> heard of other fake and unauthorized callsign use, I wonder about the 
> possibility
> 
> of a digital Mode database setup & registered to , with license proof etc, 
> similar to QRZ.
> 
> A hex code only then secure issued to the ham passing this test for software 
> use.
> 
> Wsjtx would be coded to have a code entry near Callsign field, and only 
> accepting on correct code entered.
> 
> This would go a long way to providing confidence that the callsign worked is 
> genuine (DXPeditions etc), and protecting
> 
>  your own callsign from mis-use.
> 
> 
> 73
> 
> 
> vk4tux
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Is there a way to set an alarm for "ATNO" ?

[Kevin McQuiggin via wsjt-devel]

And if you are on a Mc, run MacLoggerDX.  You can be alerted verbally, by an 
alarm sound, or via email and/or SMS.


> On Apr 5, 2023, at 8:44 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> If you are on Windows use JTAlert...can alert you for all sorts of things 
> both audio and email/text.  I have a script on my QRZ page for email/text 
> alerts.
> Mike W9MDB
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] #Bug - Frequency Tracking Error - IC9700 (and IC-7300)

[Kevin McQuiggin via wsjt-devel]

Thanks Christoph and Fred: I checked and indeed had CI-V transceive set to ON.

Problem RESOLVED!  WSJT-X tracks the dial perfectly now!!!

73,

Kevin


> On Jan 16, 2023, at 1:06 PM, Christoph Berg via wsjt-devel 
>  wrote:
> 
> Re: Fred Price via wsjt-devel
>> Do you have CV-I Transcrive turned off in the menu? If not turn off and test 
>> again.
> 
> Hi Fred,
> 
> I had bad problems with frequency readout with my IC-7610 through
> rigctld when using the VFO knob - mostly in tlf, but wsjtx was also
> affected (though less since there's less tuning).
> 
> The problems started when I upgraded hamlib from 4.3.1 to 4.5, and
> went away when downgrading it again.
> 
> Disabling CI-V Transceive made the problems go away on 4.5.4. Thanks
> for the tip!
> 
> 73,
> Christoph DF7CB
> (one of the Debian maintainers for hamlib and wsjtx)
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] #Bug - Frequency Tracking Error - IC9700 (and IC-7300)

[Kevin McQuiggin via wsjt-devel]

Hi All:

I am another op who sees this tuning regression on the IC-9700.   My rig’s 
firmware is up to date and WSJT-X frequency tracks fine if I revert to 2.5.4 or 
even 2.6.0-rc1.  

There was some change made to the software (either WSJT-X or hamlib) between 
WSJT-X 2.6.0-rc1 and later versions that introduced this bug.  A marginal 
workaround is to increase the data rate on the IC-9700’s serial port and to 
make manual frequency changes on the radio very slowly.  However, eventually 
WSJT-X/hamblib misses a frequency change, tracking between WSJT-X and the radio 
starts to differ, and it never recovers.  

It is not a complete “show stopper”, but very frustrating as it is usually 
necessary to tune the radio manually for normal operations, EME on 23cm for 
example when you want to change to “075" or “082" or wherever for a QSO.

I have worked with Michael Black quite a bit on this, sent logs, tried 
alternate configurations, etc, but so far there has been no resolution to the 
bug.  Thanks Michael for your help on this, but the issue still exists.

The biggest clue, I think, is the fact that it was introduced with -rc2.  -rc1 
ran fine.  This should provide a good starting point for finding out what 
changed.

73,

Kevin


> On Jan 16, 2023, at 11:19 AM, David Cutajar via Moon-net 
>  wrote:
> 
> Hi Joe
> here still the issue still persists on the ic 7300 /9700 and not only mine 
> even another two friends of mine.
> The issue is wsjt x not  following the rig when turn the dial on q65/jt65 as 
> there normally i change qrg.But  Version 2.5.4 is working ok so i got back 
> for the old version.
> 73 David 9H1TX
> 
> ___
> Moon-Net posting and subscription instructions are at 
> http://www.nlsa.com/nets/moon-net-help.html
> 

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

Re: [wsjt-devel] [Moon-Net] wsjt x 2.6 rc5 - Bug Likely Persists

[Kevin McQuiggin via wsjt-devel]

Hi David:

I reported this issue with RC3 but I assumed it was fixed in RC5 as I have not 
seen it happen since the upgrade.  I run an IC9700 for EME, interesting that 
you are seeing the issue on a ‘7300 as well.

It was quite frustrating in RC3, and in fact I reverted to RC1 because the 
tuning knob was essentially unusable.  

I advised the [wsjtx-devel] folks that the issue showed up in RC2, RC1 did not 
display this behaviour.



> On Dec 5, 2022, at 7:41 AM, David Cutajar via Moon-net 
>  wrote:
> 
> Dowloaded last version of wsjt x and i am having n issue not sure if its from 
> my side.
> My set freq on Q65 is 50.190 for EME traffic ,my setup is with ic 7300 
> nothing fancy so when i turn the dial to choose another qrg lets say 50.195 
> the freqon the wsjt x does not follow its like start following but then stop 
> on lets say 50.193.
> Anyone else having this issue?
> 73 David 9H1TX
> ___
> Moon-Net posting and subscription instructions are at 
> http://www.nlsa.com/nets/moon-net-help.html
> 



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

[wsjt-devel] Nothing Heard in Reply: Regression in 2.6.0-rc2 and -rc3 #bug #regression

[Kevin McQuiggin via wsjt-devel]

Hi All:

I submitted this bug report several days ago and it seems to have gotten no 
traction at all.  It concerns miscommunication between WSJT-X RC2 and RC3 and 
an Icom 9700.  WSJT-X no longer accurately tracks frequency changes on the 
radio.  

RC1 was fine in this respect and the interaction between my IC-9700 and WSJT-X 
was functional and “normal”.

Please see the original message below.  It contains details of the issue, which 
I see as serious because it makes RC2 and RC3 unusable for ‘9700 users.

73,

Kevin


== ORIGINAL MESSAGE ===

Hi All:

I run MacOS 10.14.6 Mojave.

I have been running 2.6.0-rc1 without issue since its release.  I have an 
Icom-9700 and operate primarily on 23cm EME.  This issue may show up on other 
bands on the ‘9700 but I have not tried this.

This issue relates to frequency tracking within -rc2 and -rc3 when I adjust the 
main frequency dial on the radio.  

Manual changes to the radio’s dial frequency lag greatly within the WSJT-X 
application.  It is like WSJT-X. Starting in -rc2, no longer “notices” dial 
changes on the ‘9700.  Changing the dial frequency slowly makes not difference 
and  does not seem to get noticed by the application, so WSJT-X’s frequency 
does not match that of the radio dial.

Moving the dial at a normal rate similarly generates lag in frequency changes 
within -rc2 and -rc3, and the results are that:
The radio frequency does not match that of -rc2 and -rc3
Once the two frequencies are different, with the lag, it is near impossible to 
get them matching again.
This regressive behaviour is observable in the Astronomical Window under the 
Doppler tracking section.  See the field “Sked Frequency”.

On two occasions I have been unable to accurately QSY and have had to shut down 
-rc2/-rc3 and re-load -rc1.

-rc1 does NOT show this behaviour, and the application action communicates with 
the radio easily.  

This might be related to something in the CAT control area, but other than the 
frequency change lag everything else in CAT seems to function normally.

I can answer more questions as required.

73,

Kevin VE7ZD/KN7Q

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

[wsjt-devel] Regression in 2.6.0-rc2 and -rc3

[Kevin McQuiggin via wsjt-devel]

Hi All:

I run MacOS 10.14.6 Mojave.

I have been running 2.6.0-rc1 without issue since its release.  I have an 
Icom-9700 and operate primarily on 23cm EME.  This issue may show up on other 
bands on the ‘9700 but I have not tried this.

This issue relates to frequency tracking within -rc2 and -rc3 when I adjust the 
main frequency dial on the radio.

Manual changes to the radio’s dial frequency lag greatly within the WSJT-X 
application.  It is like WSJT-X. Starting in -rc2, no longer “notices” dial 
changes on the ‘9700.  Changing the dial frequency slowly makes not difference 
and  does not seem to get noticed by the application, so WSJT-X’s frequency 
does not match that of the radio dial.

Moving the dial at a normal rate similarly generates lag in frequency changes 
within -rc2 and -rc3, and the results are that:
The radio frequency does not match that of -rc2 and -rc3
Once the two frequencies are different, with the lag, it is near impossible to 
get them matching again.
This regressive behaviour is observable in the Astronomical Window under the 
Doppler tracking section.  See the field “Sked Frequency”.

On two occasions I have been unable to accurately QSY and have had to shut down 
-rc2/-rc3 and re-load -rc1.

-rc1 does NOT show this behaviour, and the application action communicates with 
the radio easily.

This might be related to something in the CAT control area, but other than the 
frequency change lag everything else in CAT seems to function normally.

I can answer more questions as required.

73,

Kevin VE7ZD/KN7Q



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Regression in 2.6.0-rc2 and -rc3

[Kevin McQuiggin via wsjt-devel]

Hi All:

I run MacOS 10.14.6 Mojave.

I have been running 2.6.0-rc1 without issue since its release.  I have an 
Icom-9700 and operate primarily on 23cm EME.  This issue may show up on other 
bands on the ‘9700 but I have not tried this.

This issue relates to frequency tracking within -rc2 and -rc3 when I adjust the 
main frequency dial on the radio.  

Manual changes to the radio’s dial frequency lag greatly within the WSJT-X 
application.  It is like WSJT-X. Starting in -rc2, no longer “notices” dial 
changes on the ‘9700.  Changing the dial frequency slowly makes not difference 
and  does not seem to get noticed by the application, so WSJT-X’s frequency 
does not match that of the radio dial.

Moving the dial at a normal rate similarly generates lag in frequency changes 
within -rc2 and -rc3, and the results are that:
The radio frequency does not match that of -rc2 and -rc3
Once the two frequencies are different, with the lag, it is near impossible to 
get them matching again.
This regressive behaviour is observable in the Astronomical Window under the 
Doppler tracking section.  See the field “Sked Frequency”.

On two occasions I have been unable to accurately QSY and have had to shut down 
-rc2/-rc3 and re-load -rc1.

-rc1 does NOT show this behaviour, and the application action communicates with 
the radio easily.  

This might be related to something in the CAT control area, but other than the 
frequency change lag everything else in CAT seems to function normally.

I can answer more questions as required.

73,

Kevin VE7ZD/KN7Q

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

Re: [wsjt-devel] Exaggerated reports given to lower tone freqs

[Kevin McQuiggin (SFU) via wsjt-devel]

Hi Marco:

Did you follow the steps to record a reference spectrum first?  You have to 
record a minute or so of noise in order for the program to be able to compute 
gain figures which are then used to flatten frequency response.  I am not sure 
what would happen if you activated reference spectrum without recording it 
first.  

Kevin

Sent from my iPad

> On Oct 16, 2021, at 15:11, Marco Calistri via wsjt-devel 
>  wrote:
> 
> Il 16/10/21 17:30, Kevin McQuiggin via wsjt-devel ha scritto:
>> Hi All:
>> 
>> There is a pretty good article on the why and how of reference spectrum use 
>> by Bob KA1GT at http://www.bobatkins.com/radio/WSJTX_flatten.html.  His site 
>> is targeted primarily at EME and UHF-and-above users, but the information 
>> applies to use of the reference spectrum at HF as well.
>> 
>> 73,
>> 
>> Kevin
>> 
>> 
> Hi Kevin,
> 
> I found this topic very interesting.
> 
> I've followed the step by step described in the article by KA1GT but when I 
> click on Ref Spec my WSJT-X crashes!
> 
> I'm using WSJT-X 2.5.0 on Linux openSUSE Tumbleweed.
> 
> Regards,
> ---
> 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] Exaggerated reports given to lower tone freqs

[Kevin McQuiggin via wsjt-devel]

Hi All:

There is a pretty good article on the why and how of reference spectrum use by 
Bob KA1GT at http://www.bobatkins.com/radio/WSJTX_flatten.html.  His site is 
targeted primarily at EME and UHF-and-above users, but the information applies 
to use of the reference spectrum at HF as well.

73,

Kevin




> On Oct 16, 2021, at 1:20 PM, Patrick 9A5CW via wsjt-devel 
>  wrote:
> 
> Hi Bill,
> I will take a look into the manual and I will try to measure it.
> 
> 73, Patrik 9A5CW
> 
> 
> 
> On Sat, Oct 16, 2021 at 10:18 PM Bill Somerville via wsjt-devel 
> mailto:wsjt-devel@lists.sourceforge.net>> 
> wrote:
> On 16/10/2021 21:09, Patrick 9A5CW via wsjt-devel wrote:
> > Hi Reino,
> > no you are wrong, the filter is wide enough, and I never pressed any 
> > buttons on my old IC706mk2 radio.
> >
> > I rarely use any kind of filter on JT digi modes, as narrow as I can 
> > go is 1800 Hz and that's only when I have high noise.
> >
> > Try to select Ref spec and see the difference.
> >
> > 73, Patrik
> >
> > p.s. i don't know the purpose of the Ref Spec option on the waterfall ;)
> 
> Patrik,
> 
> you must capture a reference spectrum for you receive equipment before 
> it can be used to correct for pass-band irregularities. If you don't 
> know what the purpose of the reference spectrum is then it seems 
> unlikely that you have measured your receiver reference spectrum.
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
> 
> 
> -- 
> 9A5CW - Patrik Hrvatin
> --... ...--
> ___
> 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] Update Re: #PTT #DTR Inconsistency

[Kevin McQuiggin via wsjt-devel]

Hi All:

I did further troubleshooting on this issue this morning.  There was a recent 
MacOS driver update from Prolific Technology on my USB/Serial device that I had 
not installed.  Updating the MacOS driver has resolved the problem.  DTR is now 
toggling accurately and consistently.

Strange that Coolterm worked fine before the update but WSJT-X did not.

In any case, the driver update seems to have resolved my issue.

Sorry for taking up list bandwidth, 73,

Kevin


> On Aug 11, 2021, at 4:37 PM, Kevin McQuiggin  wrote:
> 
> Hi All:
> 
> I am running 2.5.0-rc5 on MacOS 10.14.6 Mojave.
> 
> I am interfacing WSJTX to a PA and sequencer and thus need to send the PTT 
> signal to the sequencer, which will manipulate some relays and then key my 
> rig. I have added a USB to serial converter that brings out DTR and am 
> attempting to send the PTT signal from WSJTX in that manner, as per the User 
> Guide.
> 
> I am having trouble getting PTT method DTR to work consistently.  WSJTX does 
> indeed toggle DTR using, for example, the Tune pushbutton, but the behaviour 
> is inconsistent.  
> 
> I have a Prolific USB to serial adapter that brings out DTR.  When I run the 
> open source “Coolterm” application and select the Prolific serial port 
> (/dev/cu.usbserial) and toggle DTR through that program, DTR follows the 
> selected state in Coolterm consistently and correctly.  
> 
> However, when I select the correct serial port (/dev/cu.usbserial again) and 
> DTR as the PTT method in WSJTX, I can “Test PTT” and the initial toggling of 
> the DTR line works correctly, but then the DTR line gets stuck “high” and I 
> cannot get it lowered again except through multiple (and inconsistent) 
> additional presses of “Test PTT”.  There is no pattern to this.
> 
> Another observation: if I use the main window and select “Tune” then DTR will 
> go high (as expected) but if Tune is depressed for more than approximately 
> two seconds then either a second press of Tune or a press of “Halt TX” will 
> not lower DTR again.  Again it is inconsistent.  If I am crafty and keep 
> pressing “Tune” several times then eventually DTR will go low again.  
> 
> The configuration cannot be used for PTT to my PA/sequencer as DTR is getting 
> “stuck”.  
> 
> The fact that I can toggle DTR consistently and correctly through the other 
> app would seem to indicate that the OS is seeing and interacting with the 
> serial port properly.
> 
> I am wondering if there is some additional configuration I might need in the 
> wsjtx.ini file or something that will alleviate this problem.
> 
> I am monitoring the state of DTR via an RS232 breakout board and a voltmeter. 
>  Once I have the DTR line tracking WSJTX TX/RX state properly then I already 
> have a simple circuit which will transform the -6 / +6 volt RS232 signals to 
> the proper levels for the sequencer.  
> 
> A web search and my cursory inspection of wsjtx.ini did not turn up any 
> solutions or obvious config changes.
> 
> Any assistance or additional information appreciated.
> 
> 73,
> 
> Kevin VE7ZD
> 
> 
> 



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

[wsjt-devel] #PTT #DTR Inconsistency

[Kevin McQuiggin via wsjt-devel]

Hi All:

I am running 2.5.0-rc5 on MacOS 10.14.6 Mojave.

I am interfacing WSJTX to a PA and sequencer and thus need to send the PTT 
signal to the sequencer, which will manipulate some relays and then key my rig. 
I have added a USB to serial converter that brings out DTR and am attempting to 
send the PTT signal from WSJTX in that manner, as per the User Guide.

I am having trouble getting PTT method DTR to work consistently.  WSJTX does 
indeed toggle DTR using, for example, the Tune pushbutton, but the behaviour is 
inconsistent.  

I have a Prolific USB to serial adapter that brings out DTR.  When I run the 
open source “Coolterm” application and select the Prolific serial port 
(/dev/cu.usbserial) and toggle DTR through that program, DTR follows the 
selected state in Coolterm consistently and correctly.  

However, when I select the correct serial port (/dev/cu.usbserial again) and 
DTR as the PTT method in WSJTX, I can “Test PTT” and the initial toggling of 
the DTR line works correctly, but then the DTR line gets stuck “high” and I 
cannot get it lowered again except through multiple (and inconsistent) 
additional presses of “Test PTT”.  There is no pattern to this.

Another observation: if I use the main window and select “Tune” then DTR will 
go high (as expected) but if Tune is depressed for more than approximately two 
seconds then either a second press of Tune or a press of “Halt TX” will not 
lower DTR again.  Again it is inconsistent.  If I am crafty and keep pressing 
“Tune” several times then eventually DTR will go low again.  

The configuration cannot be used for PTT to my PA/sequencer as DTR is getting 
“stuck”.  

The fact that I can toggle DTR consistently and correctly through the other app 
would seem to indicate that the OS is seeing and interacting with the serial 
port properly.

I am wondering if there is some additional configuration I might need in the 
wsjtx.ini file or something that will alleviate this problem.

I am monitoring the state of DTR via an RS232 breakout board and a voltmeter.  
Once I have the DTR line tracking WSJTX TX/RX state properly then I already 
have a simple circuit which will transform the -6 / +6 volt RS232 signals to 
the proper levels for the sequencer.  

A web search and my cursory inspection of wsjtx.ini did not turn up any 
solutions or obvious config changes.

Any assistance or additional information appreciated.

73,

Kevin VE7ZD





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

Re: [wsjt-devel] WSJT-X 2.4.0-rc3 Audio Issue - Issue Persists on MacOS As Well

[Kevin McQuiggin]

Hi Bill and [WSJT-X Devel] group:

More info on this bug:

This “TX but no audio” on first transmission after band change issue persists 
as well in 2.4-rc3, using an iMac and KX3.  Second TX cycle, all is well.  The 
behaviour is generally reproducible, but not always.  I’ve seen it on FT8, 
MSK144, and Q65.  I can make another video for YouTube using 2.4-rc3 if that 
will help, but the behaviour is unchanged from 2.3.0 other than the problem 
occurring as well on new mode Q65.

I note that the workaround of hitting “Tune”; then “Halt” after each band 
change usually seems to fix the issue, but this does not always prevent the 
behaviour either.

I will assist in testing as required, just let me know.

73,

Kevin VE7ZD

> On Mar 17, 2021, at 9:48 AM, David Birnbaum  wrote:
> 
> I've been having the same issue - no transmit audio although TUNE does work.  
> Same setup except I'm connected to the IC7300 directly via USB.
> 
> dave
> k2lyv 
> ___
> 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] RC2 Bug Report on MacOS "Mojave" - Q65

[Kevin McQuiggin]

Hi All:
I tried submitting this earlier today, but it didn’t seem to make to the list.  
Hence, a re-submission:

Just trying out RC2 on an iMac, MacOS version 10.14.6 Mojave.

Selection of “Q65_Sync” from dropdown box on the wide graph causes a crash as 
soon as the application starts to TX.  Selection of “Cumulative” (the default) 
and TX/RX are normal.

Specific exception was "EXC_BAD_ACCESS (SIGSEGV)”.

I have saved the crash dump and can provide as necessary.

73,

Kevin VE7ZD



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

[wsjt-devel] #rc2 - #bug - #Q65 - #MacOS

[Kevin McQuiggin]

Hi All:

Just trying out RC2 on an iMac, MacOS version 10.14.6 Mojave.

Selection of “Q65_Sync” from dropdown box on the wide graph causes a crash as 
soon as the application starts to TX.  Selection of “Cumulative” (the default) 
and TX/RX are normal.

Specific exception was "EXC_BAD_ACCESS (SIGSEGV)”.

I have saved the crash dump and can provide as necessary.

73,

Kevin VE7ZD



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug in RC2 - ISCAT Mode

[Kevin McQuiggin]

Thanks Joe.  I am on 6m with a local ISCAT group so you’re right I should have 
checked the VHF/UHF box.  I will do that now!

73,

Kevin

Sent from my iPhone

> On May 26, 2020, at 08:41, Joe Taylor  wrote:
> 
> Hi Kevin,
> 
>> On 5/26/2020 9:27 AM, Kevin McQuiggin VE7ZD/KN7Q wrote:
>> 
>> I note that if you quit RC2 while in ISCAT B mode, that when you restart the 
>> application the indicated mode on the bottom status bar is “ISCAT B”, but 
>> that the spinner control on the window is set to “Submode A".   See the 
>> screen shot:
> 
> ...
> 
>> While this may just be a UI initialization issue, it is an operational and 
>> visual distraction, so the spinner should probably be set to match the saved 
>> submode.  Support for operator situational awareness should have the two 
>> indicators match.
> 
> Thanks for pointing out this anomaly.  It will be corrected in the next 
> release.
> 
> Evidently you are operating with "Enable VHF/UHF/Microwave features" 
> unchecked.  As a general policy, WSJT-X recommends using submodes (such as 
> JT65B, ISCAT B, etc.) only on VHF bands and higher.  Unless you have some 
> specific reason I don't know about, you should check that box when using 
> ISCAT.
> 
> And then, you would never have noticed the anomaly you reported -- hi.
> 
>-- 73, Joe, K1JT
> 
> 
> ___
> 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 - 2.2rc1 - ISCAT Mode

[Kevin McQuiggin]

Thank you Joe, glad to help, if even with a little-used mode.

As others have said, we have a small group of ISCAT users here in the west, so 
we may have further info for you as time progresses.

We need to thanks James K7KQA for this as he is the driver out here for getting 
people to try out ISCAT.

Additional info is that the bug also exists in Windows.  As I stated I run 
WSJT-X on an iMac.

73 and thanks for all your (and the development group’s) great work.

Kevin VE7ZD/KN7Q

Sent from my iPhone

> On May 22, 2020, at 08:55, Joe Taylor  wrote:
> 
> Hi Kevin,
> 
>> On 5/22/2020 10:45 AM, Kevin McQuiggin VE7ZD/KN7Q wrote:
>> 
>> In ISCAT mode, if one double-clicks a message in the left hand RX signals 
>> pane this presents a dialog box “Double clicking is not supported in ISCAT 
>> mode”.  When this dialog box is dismissed, the app crashes.
> 
> Many tThanks for reporting this bug.  Who knows how many years it must have 
> been present?  It will be fixed in the coming "RC2" release of WSJT-X 2.2.0.
> 
>-- 73, Joe, K1JT



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

[wsjt-devel] Bug Report - 2.2rc1 - ISCAT Mode

[Kevin McQuiggin]

Hi All:

In ISCAT mode, if one double-clicks a message in the left hand RX signals pane 
this presents a dialog box “Double clicking is not supported in ISCAT mode”.  
When this dialog box is dismissed, the app crashes.

I am running rc1 on MacOS version 10.14.6 Mojave.

If you need further info then please email me.

73,

Kevin VE7ZD/KN7Q




signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fwd: 40 Meter Power USB-D issue

[Kevin McQuiggin]

Hi Chris:

Possibly a suggestion that you have already checked, but how does the power 
look into a dummy load?  Perhaps the power reduction on 40m is due to a new 
mismatch.  It may be a hardware issue rather than a WSJT-X issue!

73,

Kevin


> On Nov 19, 2019, at 5:55 PM, Christopher Diederich via wsjt-devel 
>  wrote:
> 
> 
> Get Outlook for iOS 
> From: Christopher Diederich 
> Sent: Tuesday, November 19, 2019 8:26 PM
> To: wsjtgr...@yahoogroups.com
> Subject: 40 Meter Power USB-D issue
> 
> Good evening,
> 
> I am experiencing a recent issue that has arisen where my IC-7300 is 
> transmitting on reduced power on 40 meters using FT8 with WSJT-X.  Other 
> digital modes and phone work fine, and no other bands have the low power 
> issue.  Also, the rig occasionally changes from USB-D to USB when keying. Any 
> ideas?
> 
> IC-7300
> Win 10 Pro 64 bit
> HRD version 6.7.0.244
> WSJT-X version 2.1.0
> 
> 73
> Chris Diederich K1LDO
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Any Update on 2.1 Fixes for MacOS?

[Kevin McQuiggin]

Hi All:

Just curious as to whether there’s a update as to a fix for the few problems we 
MacOS users had with (for example) MSK144 on the released 2.1.

No pressure of course (I’m a software developer myself), just wondering if 
there’s a 2.1.1 in the works or anything!

That said, if there’s anything I can do to help then let me know.

73,

Kevin VE7ZD/K7MCQ




signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Lid operators or bad design?

[Kevin McQuiggin]

Same behaviour when switching mode from MSK144 to FT8.  “Hold TX” gets 
unchecked when returning to FT8.  This caught me too!

73,

Kevin VE7ZD/K7MCQ

> On Jul 28, 2019, at 11:07 AM, Jim Brown  wrote:
> 
> On 7/28/2019 8:53 AM, Andy Durbin wrote:
>> Everyone who uses WSJT-X for FT8 must have noticed the number of operators 
>> who answer a CQ and then, when the QSO is complete, call CQ on the same 
>> frequency.   Are all these operators really stupid or are they being trapped 
>> by a weakness in the user interface design?
> 
> Let's say a combination of failure to RTFM and a poor decision in the user 
> interface design. That decision is the default to uncheck the box of Hold TX 
> frequency, and to not remember it's last used state when switching modes.
> 
> Also, when switching between modes, the box is unchecked. So, for example, 
> you're working FT8 on 6M with the box checked, go to MSK144 to look for MS 
> activity, then return to FT8 to find the box unchecked and your default TX at 
> 1500 Hz.
> 
> IMO, when using FT8, I consider it rude and poor operating practice to call a 
> station on their frequency, simply because the station is more likely to be 
> able to decode multiple callers of they're spread out. My standard method is 
> to pick a TX frequency after watching band activity for a few cycles so that 
> I can quickly click on the decode of someone I want to work.
> 
> 73, Jim K9YC
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Kevin McQuiggin]

Hi Steve and Bill:

FYI, I get a similar error when changing to MSK144 mode.   My terminal listing:

iMac:MacOS mcquiggi$ ./wsjtx
At line 2 of file /Users/bill/wsjtx-prefix/src/lib/hspec.f90
Fortran runtime error: Actual string length is shorter than the declared one 
for dummy argument 'mycall' (-4294967284/12)
iMac:MacOS mcquiggi$

Hope this helps,

Kevin


> On Jul 21, 2019, at 11:44 AM, Steven Franke via wsjt-devel 
>  wrote:
> 
>> On Jul 21, 2019, at 12:58 PM, John Nelson via wsjt-devel 
>>  wrote:
>> 
>> Hi Bill,
>> 
>> I managed to get someone to run the code from a Terminal window.  It exits 
>> with:
>> 
>> “At line 1 of file /Users/bill/wsjtx-prefix/src/lib/gen65.f90
>> Fortran runtime error: Actual string length is shorter than the declared on 
>> for dummy argument ‘msgsent’ (-216172782113783786/22)”
>> 
>> — John G4KLA___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> Hi John,
> 
> I’ve lost track of which issue your report pertains to. It seems that there 
> are 3 possibly unrelated issues at play on MacOS.
> 
> 1. Crash related to reading the LoTW user file. Bill has identified the cause 
> of this problem.
> 2. Kevin, VE7DS’s report of a crash related to MSK144 mode. I have tried, but 
> have not yet been able to reproduce this here.
> 3. George, KF2T’s report of a crash on startup when running a beta version of 
> MacOS. I have not tried to reproduce this.
> 
> Which one does your report address?  Or is your report yet another problem?
> 
> Steve k9an
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Kevin McQuiggin (SFU)]

Bill, thanks for this info!

The crashes I have seen are related to selection of MSK144 mode.  This 
invariably causes the app to crash.  Sometimes MSK144 mode will “come up” in 
the UI, but in that case any interaction with the UI elements will cause the 
app to crash.  I submitted a report about this to the list several days ago.  
The only message in the system log says something about launched and “abnormal 
exit code 2”.

I am not at my machine but can provide whatever specific info you need.  Thanks 
to the team for all the great work on he apps!

73,

Kevin VE7ZD 

Sent from my iPad

> On Jul 21, 2019, at 03:34, Bill Somerville  wrote:
> 
> Hi all,
> 
> some of you have reported a crash on startup, thanks to those who have 
> provided the crash report.
> 
> I can confirm there is a defect which appears to be in the underlying Qt 
> library we use for cross platform portability. The issue is fixed in Qt v5.11 
> but using that will entail dropping support for macOS Yosemite (10.10), that 
> will probably happen at the next release of WSJT-X.
> 
> In the meantime there is a workaround with some minor loss of functionality. 
> The crash happens in code to read the LoTW user file downloaded from the ARRL 
> LoTW web site. WSJT-X will function without that file but without 
> highlighting of known LoTW user's CQ calls. To avoid the issue delete 
> following file:
> 
> ~/Library/"Application Support"/WSJT-X/lotw-user-activity.csv
> Once deleted you should not use the "Preferences->Colors->Logbook of the 
> World user Validation->Fetch" button until this issue is resolved.
> 
> Note that this issue is not affecting all users, if you are not seeing this 
> crash then you may be able to continue using WSJT-X v2.1.0 without taking the 
> action.
> 
> 73
> Bill
> G4WJS.
> ___
> 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