Re: [wsjt-devel] Remote WSJT

[Tom M0LTE via wsjt-devel]

This is, effectively, one and the same.

To be frank, a ground-up rewrite, with a headless service, a
well-documented network-accessible API, and a UI, perhaps but not
necessarily using the existing one, would be a highly worthy project in its
own right.

Could be a nice opportunity for rationalisation.

Cheers
Tom

On Wed, 28 Feb 2024 at 19:01, Alex, VE3NEA via wsjt-devel <
wsjt-devel@lists.sourceforge.net> 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
> > <mailto: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
> > <mailto: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 <
> 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 <
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
> >
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Not sure if an issue

[Tom Paratore via wsjt-devel]

Sounds like a memory leak.

If you can run task manger and monitor the memory tab to see which program 
continues to consume memory, it may help to identify the cause.

> On Feb 14, 2024, at 12:09 AM, Alan McDonald via wsjt-devel 
>  wrote:
> 
> Yes - Windows
> 
> Alan VK1AO
> 
> -Original Message-
> From: jarmo via wsjt-devel 
> Sent: Wednesday, February 14, 2024 3:56 PM
> To: wsjt-devel@lists.sourceforge.net
> Cc: jarmo 
> Subject: Re: [wsjt-devel] Not sure if an issue
> 
> Wed, 14 Feb 2024 09:44:17 +1100
> Alan McDonald via wsjt-devel 
> kirjoitti:
> 
>> It happens to me frequently. I leave the app running all the time (not
>> using it but it sits there).
>> 
>> Switching CODECs works all the time but curiously I never have to do
>> this for MSHV or JTDX. They keep the CODEC.
>> 
>> What happens is the sound comes out of my radio speaker until I switch
>> it back to USB again.
>> 
>> 
>> 
>> Alan / VK1AO
> 
> Not seen this kind behaviour. Have pretty much wsjtx running 24/7 some years
> now.
> OS Fedora 39 (now)
> Just now testing 2.7.1-devel
> Older genetation i7 desktop...
> 
> Is this happening with WIN?
> 
> Jarmo
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] Callsign Security

[Tom M0LTE via wsjt-devel]

Broken in 60 seconds by looking at the source code. See APRS-IS.

On Thu, 5 Oct 2023 at 09:36, Adrian via wsjt-devel <
wsjt-devel@lists.sourceforge.net> 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
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Transverter Offset

[tom via wsjt-devel]

Thanks all.

Yes I was following all comments - I have no issue at all with 2m or 70cms 
offsets - same version of Windows, same rig (TS680) same copy of WSJT. Yes 
saving all settings with the OK.

Yes was entering -1268 as offset - one thing - could someone confirm the format 
of the offset on your working system. Here it is  -1,268.000 000 Mhz - note the 
comma as the separator on 1,268

Harry your example had no comma.  Could it be the locale I have set to UK ?


Thanks

Tom



Tom GM8MJV
t...@tkrh.co.uk





> On 18 Jul 2023, at 17:37, Harry E. Hoffman via wsjt-devel 
>  wrote:
> 
> Hi Tom,
> 
> Appending my post:
> 
> The offset frequency is a negative number so it should read:
> 
> Band = 23 cm
> Offset = -1268.000 000 (note the decimal point and the space)
> 
> I am using an IC-7300 as the IF radio on my system and my transverter 
> settings for 1.25 meters and 33 centimeters work fine. I don't use a 
> transverter for 23 centimeters as I also have an IC-9700.
> 
> 73 Harry (KA2ENE)
> 
> ---
> 
> On 7/18/2023 10:18 AM, Harry E. Hoffman via wsjt-devel wrote:
>> Hi Tom,
>> I use transverters for 1.25 meters and 33 centimeters, using the the same 
>> idea try this for 23 centimeters.
>> Band = 23 cm
>> Offset = 1268.000 000 (note the decimal point and the space)
>> Check the frequency list and if there are no entries for 23 cm add them for 
>> the modes you want.
>> Example: Region 2 FT8 1296.174 000
>> good luck.
>> 73 Harry (KA2ENE)
>> ---
>> On 7/18/2023 6:30 AM, tom via wsjt-devel wrote:
>>> Hi - posted on main list but no final solution.
>>> 
>>> Windows 11, wsjt-X 2.6.2 and 2.7.0-rc2
>>> 
>>> Setting up a 23cms Transverter with a 28 MHz IF - seems to be an issue. 
>>> Used an offset -1268 and wsjt-x displayed 23cms ok but cat jumped rig to 
>>> 1.065 MHz.
>>> 
>>> 
>>> Tried the example given on archive for 2m offset -116 and all worked fine, 
>>> cat kicked in and rig (TS680) switched to 28 Mhz and WSJT-X displayed 144 
>>> MHz.
>>> 
>>> Could it be the , in offset freq -1268 is entered and software formats it 
>>> to -1,268.000 000 MHz.
>>> 
>>> Tried the same setup with MSHV and WSJT-X-Improved and worked as expected 
>>> with -1268 offset. Cat and freq both ok.
>>> 
>>> Thanks in advance for any suggestions but it does look like a bug rather 
>>> than user error.
>>> 
>>> Tom GM8MJV
>>> t...@tkrh.co.uk <mailto:t...@tkrh.co.uk>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

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

[wsjt-devel] Transverter Offset

[tom via wsjt-devel]

Hi - posted on main list but no final solution.

Windows 11, wsjt-X 2.6.2 and 2.7.0-rc2

Setting up a 23cms Transverter with a 28 MHz IF - seems to be an issue. Used an 
offset -1268 and wsjt-x displayed 23cms ok but cat jumped rig to 1.065 MHz.


Tried the example given on archive for 2m offset -116 and all worked fine, cat 
kicked in and rig (TS680) switched to 28 Mhz and WSJT-X displayed 144 MHz.

Could it be the , in offset freq -1268 is entered and software formats it to 
-1,268.000 000 MHz.

Tried the same setup with MSHV and WSJT-X-Improved and worked as expected with 
-1268 offset. Cat and freq both ok.

Thanks in advance for any suggestions but it does look like a bug rather than 
user error.

Tom GM8MJV
t...@tkrh.co.uk





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

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

[Tom M0LTE via wsjt-devel]

Hey Jim

Kubuntu 18.04 went out of support in May 2021. Time to upgrade…

Best wishes
Tom

On Sun, 14 May 2023 at 01:58, Jim Shorney via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

>
> 2.7.0-rc1 fails to compile in Kubuntu 18.04 with the following errors:
>
> [ 98%] Building CXX object qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o
> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp: In
> constructor `MainWindow::MainWindow(QWidget*)`:
> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:184:32:
> error: `class QScopedPointer` has no member named `get`
>connect (m_wide_graph_window.get (), ::freezeDecode2, this,
> ::freezeDecode);
> ^~~
> /home/nu0c/src/build/build/wsjtx-prefix/src/wsjtx/qmap/mainwindow.cpp:185:32:
> error: `class QScopedPointer` has no member named `get`
>connect (m_wide_graph_window.get (), ::f11f12, this,
> ::bumpDF);
> ^~~
> qmap/CMakeFiles/qmap.dir/build.make:233: recipe for target
> 'qmap/CMakeFiles/qmap.dir/mainwindow.cpp.o' failed
>
> My Qt version is 5.9.5. There is no newer version available in the
> repository. Getting a newer version by other means does not appear to be a
> trivial task.
>
> 73
>
> -Jim
> NU0C
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Tom M0LTE via wsjt-devel]

Hey Reino

I fully understand your concerns. Clearly this idea has been considered.
Conceptually I believe a slightly different approach might overcome some of
those difficulties, however I am conscious of derailing Uwe’s thread, so I
won’t.

Uwe, good luck with the search.

Best wishes
Tom

On Sat, 13 May 2023 at 11:05, Reino Talarmo via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> > From: Tom M0LTE via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
>
> > Sent: lauantai 13. toukokuuta 2023 10.58
> >While manual testing could probably never be eliminated in the case of
> hamlib, has there been any consideration of creating test harnesses to
> remove/reduce the need for manual testing?
>
> >It strikes me that there could be potential to capture test cases from
> manual testing with real rigs, then at least there would be regression
> tests. Future bug fixes could have test cases added to prevent further
> regression, again without requiring physical radios and manual testing.
>
> Hi Tom,
>
> Your proposal could work in an ideal world.
> There are just minor requirements before it is easily done.
> #1 There should be a (well) defined and agreed CAT protocol that all rig
> manufactures follow.
> #2 All rigs should have tested against that protocol.
> #3 Resources to design and prepare the test program.
> #4 Resources to design and prepare the Hamlib testing harness against the
> agreed CAT protocol.
>
> On #1 we have a subset of commands that are commonly used. Even no agreed
> minimum responses to commands are agreed. There is no performance
> requirements such as timing.
> The #2 is a farfetched dream.
> The #3, hups, did I mentioned this?
> The #4, just what!
>
> In addition there are in some implementations bugs and the public CAT
> command set behaves differently than assumed. All those deal to a situation
> that the manual testing of most radios is the best way to perform this
> testing task. For that we need is the famous 'somebody' to keep it going
> and reporting to the Hamlib task force.
>
> Sorry of being to pessimistic, I have some experience on that kind of
> issue and now safely retired.
>
> 73, Reino OH3mA
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib Beta Testing Group needed

[Tom M0LTE via wsjt-devel]

Hey Uwe

While manual testing could probably never be eliminated in the case of
hamlib, has there been any consideration of creating test harnesses to
remove/reduce the need for manual testing?

It strikes me that there could be potential to capture test cases from
manual testing with real rigs, then at least there would be regression
tests. Future bug fixes could have test cases added to prevent further
regression, again without requiring physical radios and manual testing.

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

Kind regards
Tom M0LTE

On Sat, 13 May 2023 at 08:11, Uwe, DG2YCB via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

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

Re: [wsjt-devel] FT-991A WSJT-X unusable for me

[Tom M0LTE via wsjt-devel]

Probably one for the main mailing list (https://wsjtx.groups.io/g/main)
rather than the dev mailing list

That said, can you describe your whole cable setup please? The issue may be
obvious.

Tom M0LTE

On Sun, 16 Jan 2022 at 16:06, Richard Shaw via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Fedora Linux 35
> hamlib master (as of a couple of days ago)
> WSJT-X 2.5.4
>
> That being said, this has been a problem for some time for me over the
> last couple of hamlib releases and several WSJT-X releases. Mike has worked
> with me a couple of times to fix this, but it never STAYS fixed.
>
> When trying to TX in WSJT-X I get rapid relay clatter. Sometimes it's only
> been when using flrig, sometimes with both flrig and hamlib, which is the
> case right now.
>
> Running Flrig + Fldigi works fine.
> Running rigctl{,d} and putting the radio in TX works fine.
> Trying "Test PTT" in WSJT-X works fine
>
> But anytime I try to make a contact or press the PTT button I get rapid TX
> relay clatter. The audio is turned all the way down so it can't be too much
> audio signal, and anyway that usually goes into TX fine and then shuts down
> the radio when that happens.
>
> Here's a link to the rigctl log:
> https://www.dropbox.com/s/js4fiixbnzm9tsg/WSJT-X_RigControl.log
>
> Thanks,
> Richard
> KF5OIM
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Reproducing 2.5.3 /4 crash WSJT-x

[Tom Berry via wsjt-devel]

On 12/21/2021 3:04 PM, Joe Taylor via wsjt-devel wrote:

Hi all,

If you have seen a bug that can cause WSJT-X 2.5.3 to crash when 
callsigns like W9YOY/M or K0VQM/4 are involved, please help us to 
isolate and fix it.  What we really need is a sequence of steps that 
will reliably reproduce the crash.


If you have seen this bug, please let us know.  If you can reproduce 
it, please send us a recipe.


-- 73, Joe, K1JT



I have had the problem with my Apache Labs 7000 radio and HI3T/QRP.

I called him.
He answered with AA4VV   -08
I then sent      AA4VV  R-10

Then the program exited.  WSJT would not run until I rebooted the computer.

I called him again and the same think happened. (after reboot)

WSJT-X 2.5.3
Win 10
Apachie Labs 7000 Radio
FT8.

73 Tom AA4VV





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

Re: [wsjt-devel] CAT Fail on IC 9700 & 2.5.2

[tom via wsjt-devel]

Hi

Using IC9700 with 2.5.2 with out any issue - I don’t recall seeing any hamlib 
fixes for 'open com port' being reported recently.

That error suggests COM11 is no longer available - if using windows double 
check the device manager to make sure COM11 still exists. Double check it is 
not being used by any other applications.  If using another OS I can't help 
with method of checking com port existence.

Regards

Tom
GM8MJV


> On 16 Nov 2021, at 17:12, crohtun via wsjt-devel 
>  wrote:
> 
> P 
> <https://apps.apple.com/us/app/aol-news-email-weather-video/id646100661>lease 
> point me again to the hamlib files that supposedly fix this problem. Using 
> the same IC 9700 settings that are fine for 2.4.0 and trying to get 2.5.2 to 
> work with it, I get this message even before hitting the Test CAT button:
> 
> Rig failure
> 
> Hamlib error: IO error
> port_open: serial_open(COM11) status=-6, err=No error
> iofunc.c(81):port_open return(-6)
> rig.c(800):rig_open return(-6) while opening connection to rig
> 
> Ray
> KN2K
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] wsjtx-2.5.2-win32.exe

[Tom M0LTE via wsjt-devel]

Installation packages are linked from the WSJT-X website:

https://physics.princeton.edu/pulsar/k1jt/wsjtx.html

This question probably better suited for the users mailing list:
https://groups.io/g/WSJTX

Regards
Tom


On Fri, 5 Nov 2021 at 08:17, Hilik Poleg via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hello developer friend
>
> Just received an email about an update to 2.5.2 version.
>
> When trying to download, I have received a popup message preventing me
> from processing.
>
> Only then  I have realized that the update is for win 32., while my system
> is 64.
> is ther another link to be compatible with my system
>
> Thanks
>
> Hilik 4X4OE
> ___
> 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] Good old-fashioned Grids-Only mode

[tom via wsjt-devel]

Hi All

The defaults seem fine to me - can’t speak for a new ‘US’ mode that just does 
the grid.

It is a real PITA when people don’t send grid in the CQ - in many cases the 
grid in QRZ is just wrong - user changed location but forgot to update on-line 
sources. IT also affects the alerting on new grids - if no grid sent I don’t 
always get an alert.

I have no idea how many people use WSJT-X - I am pretty sure the developers 
won’t want to change a default - will cause no end of support questions, 
documentation needing updated and there are a pile of other things higher on 
to-do-list.

I always have a wee chuckle when couple of users out of xxx thousand think the 
developers have nothing better to do but change THE DEFAULTS to suit. Yes I 
could see a new CM appearing to suit xx hundred users  but not the default. 
Nothing against the developers - take a look at how long it has taken to get 
reports ‘fixed’ so in CM they don’t change. 2 - 3 years ?.

 Ohh people are not sending grids - you really must alter 
things and disable the option to limit this. Really affects my day to day 
operation esp grid chasing

Sorry guys (and girls) being realistic the chances of the developers changing 
something as long standing as grid/report is so small it’s not worth computing.

Have fun and enjoy chasing grids

Tom
GM8MJV


> On 2 Aug 2021, at 21:07, Jeff Stai via wsjt-devel 
>  wrote:
> 
> To save those 30 seconds, I've lately set my software to do signal report 
> only when responding to a CQ on 6 meters, and I have noticed others doing 
> that as well, especially JAs. Which is fine, I'll get the grid when I confirm 
> the contact. 
> 
> I'm sensing that report-only would also not be a good universal default 
> either, however? 73 jeff wk6i
> 
> On Mon, Aug 2, 2021 at 12:59 PM Bill Somerville via wsjt-devel 
> mailto:wsjt-devel@lists.sourceforge.net>> 
> wrote:
> On 02/08/2021 20:32, Jim Brown via wsjt-devel wrote:
>> On 8/2/2021 5:04 AM, Bill Somerville via wsjt-devel wrote: 
>>> If reports were dropped in favour of grid squares the protocols would need 
>>> fundamental changes, including a loss of sensitivity, unless all those 
>>> non-standard calls were to be excluded from normal QSOs. 
>> 
>> Does this mean that Contest Mode is less sensitive than the default with 
>> reports? 
>> 
>> 73, Jim
> Jim,
> 
> no, it means that non-standard calls are not supported in contest modes.
> 
> 73
> Bill
> G4WJS.
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
> 
> 
> -- 
> Jeff Stai ~ WK6I ~ wk6i.j...@gmail.com <mailto:wk6i.j...@gmail.com>
> RTTY op at W7RN
> Twisted Oak Winery ~ http://www.twistedoak.com/ <http://www.twistedoak.com/>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[tom via wsjt-devel]

HiYes the other threads are in relation to log4om. Anyways, seems nothing can 
be done right now about this other than to run as admin.Thanks, TomSent from my 
Galaxy
 Original message From: Bill Somerville via wsjt-devel 
 Date: 2021-07-18  4:16 p.m.  (GMT-05:00) To: 
wsjt-devel@lists.sourceforge.net Cc: Bill Somerville  
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server 
Hi Tom,


OK, so there something else going on as
  well. You state below that old versions of WSJT-X have also
  started showing this issue, that would seem to rule out the WSJT-X
  code *and* any Qt libraries as we package them along with WSJT-X.


I am surprised you state that this
  issue has been reported before, I must have missed that. Can you
  provide a link to a list message that reports the same issue
  please? All the message threads I can find on the WSJTX Groups.io
  group about a "Failed to start OmniRig COM server" error are
  either down to running Log4OM with administrator rights (which
  forces Omni-Rig to require other clients to run elevated), or due
  to incorrect registry contents due to not installing Omni-Rig
  correctly. 



73
  Bill
  G4WJS.


On 18/07/2021 20:56, Tom via wsjt-devel
  wrote:


  Hi
  I
  already did this.  It made no difference in my case.  I have
  also given all groups full control.
  Logging
  in with an account in the local administrators group will only
  work as well if WSJT is run in administrator mode.
  Something
  has been changed with a Windows update since this always
  worked without issues in the past.
  It
  all of a sudden started happening with the older version of
  WSJT.  There has been no update of Omni-rig either.
   
  I
  would say this may have  to do with some update somewhere
  (QT?) since you I am sure have many users that never had to
  modify permissions in the past.
   
  I
  have seen several reports of this in your groups.io group in
  the past.  
   
  Of
  course this is solved by putting in Run as Administrator in
  the shortcut for WSJT. But the question is why all of a
  sudden?
  73
      Tom
   
  

  From: Bill Somerville via wsjt-devel
   
  Sent: Sunday, July 18, 2021 3:29 PM
  To: wsjt-devel@lists.sourceforge.net
  Cc: Bill Somerville 
  Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig:
  Failed to start Omni Rig COM server

  
   
  
    Hi Tom,
  
  
 
  
  
I think I have reproduced the issue. I have
  an account on my Windows PC, I use for testing UAC matters,
  that is not a member of the local administrators group. If I
  use this account I cannot have WSJT-X use Omni-Rig, even
  though I can start the Omni-Rig server by running its
  executable. It would seem that members of the local
  administrator group have the necessary rights via group
  policies. I can fix the problem by granting a full control ACL
  to the Omni-Rig executable for the user that is not a member
  of the local administrators group, like this:
  
  
 
  
  
Start an Administrator CMD prompt and type
  the following command:
  
  
icacls "C:\Program Files (x86)\Afreet\OmniRig\omnirig.exe" /grant 
:F
  
  
where  is the user name (or
  SID) to be granted the right. Use /remove to remove the ACL
  entry to prove it is working.
  
  
 
  
  
Granting full control like this seems like
  a sledge-hammer to crack a nut, but I am not sure exactly
  which access right is required to start an out-of-process COM
  server like Omni-Rig. It could be that the Omni-Rig installer
  is not setting up Omni-Rig correctly for it to be started by
  users outside of the local administrators group, but I am not
  sufficiently knowledgeable on Windows security system to be
  sure.
  
  
 
  
  
73
  Bill
  G4WJS.
  
  
 
  
  
On 18/07/2021 19:37, Tom via wsjt-devel
  wrote:
  
  
Hi
Exactly the same for all
users.
Don’t know where to go
from here….
73 Tom
 
 

  
From: Bill
Somerville via wsjt-devel 

Sent: Sunday, July 18, 2021 2:22 PM
To: wsjt-devel@lists.sourceforge.net
   

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

I already did this.  It made no difference in my case.  I have also given all 
groups full control.

Logging in with an account in the local administrators group will only work as 
well if WSJT is run in administrator mode.

Something has been changed with a Windows update since this always worked 
without issues in the past.

It all of a sudden started happening with the older version of WSJT.  There has 
been no update of Omni-rig either.



I would say this may have  to do with some update somewhere (QT?) since you I 
am sure have many users that never had to modify permissions in the past.



I have seen several reports of this in your groups.io group in the past.



Of course this is solved by putting in Run as Administrator in the shortcut for 
WSJT. But the question is why all of a sudden?

73 Tom



From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 3:29 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



I think I have reproduced the issue. I have an account on my Windows PC, I use 
for testing UAC matters, that is not a member of the local administrators 
group. If I use this account I cannot have WSJT-X use Omni-Rig, even though I 
can start the Omni-Rig server by running its executable. It would seem that 
members of the local administrator group have the necessary rights via group 
policies. I can fix the problem by granting a full control ACL to the Omni-Rig 
executable for the user that is not a member of the local administrators group, 
like this:



Start an Administrator CMD prompt and type the following command:

icacls "C:\Program Files (x86)\Afreet\OmniRig\omnirig.exe" /grant :F

where  is the user name (or SID) to be granted the right. Use /remove to 
remove the ACL entry to prove it is working.



Granting full control like this seems like a sledge-hammer to crack a nut, but 
I am not sure exactly which access right is required to start an out-of-process 
COM server like Omni-Rig. It could be that the Omni-Rig installer is not 
setting up Omni-Rig correctly for it to be started by users outside of the 
local administrators group, but I am not sufficiently knowledgeable on Windows 
security system to be sure.



73
Bill
G4WJS.



On 18/07/2021 19:37, Tom via wsjt-devel wrote:

Hi

Exactly the same for all users.

Don’t know where to go from here….

73 Tom





From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 

Sent: Sunday, July 18, 2021 2:22 PM
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
Cc: Bill Somerville  <mailto:g4...@classdesign.com> 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for that. So it seems that something is blocking COM communications 
between WSJT-X and Omni-Rig that is resolved by running WSJT-X with elevated 
rights. The Windows security model, in general, blocks IPC between processes 
running at different security levels. If that is the issue then perhaps somehow 
Omni-Rig can only be started using elevated rights. Is it possible that the 
OmniRig.exe file has a security restriction applied? On my system if I check 
the effective rights for my non-administrator user to the omnirig.exe file I 
see this:



which includes read and execute. Is it the same on your system?



I am not sure why you are asking about how WSJT-X accesses serial ports, when 
using Omni-Rig it doesn't access serial ports. To access COM services we use a 
Qt library Active that allows us to access COM services without the low level 
details of handling COM in C. We also use a Qt tool called dumpcpp which 
generates Active Qt COM wrappers by querying the COM server via its GUID to 
enumerate its COM API.



https://doc.qt.io/qt-5/activeqt-index.html



73
Bill
G4WJS.



On 18/07/2021 18:55, Tom via wsjt-devel wrote:

Hi

Ok.  I did this.  When you run WSJT without being admin, no log is made at all. 
 You get Failed to start Omni Rig COM server in  WSJT

If you run it as admin, then a log appears.

Here are the first few lines…



13:45:51.670  Omni-Rig started: Version 1.19

13:45:51.675  Loading commands from "ZS-1.ini"

13:45:51.691  Loading commands from "TS-930.ini"

13:45:51.707  Loading commands from "TS-870.ini"



If you run Log4OM for example NOT as admin, a log is created as above.



Since this happens with an older version of WSJT and the latest versions 
(production) most likely a library somewhere has been changed.  Perhaps by 
Windows update.

I remember a couple of years ago, that I had a sound device stuck in WSJT even 
though the device wasn’t installed. .  We worked on it a lot to no resolution.  
A subsequent Windows update fixed it.

What libraries are you using for serial port access? Or the com server?



73 Tom



From: Bill Somerville via wsjt-devel  <mai

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

Exactly the same for all users.

Don’t know where to go from here….

73 Tom





From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 2:22 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for that. So it seems that something is blocking COM communications 
between WSJT-X and Omni-Rig that is resolved by running WSJT-X with elevated 
rights. The Windows security model, in general, blocks IPC between processes 
running at different security levels. If that is the issue then perhaps somehow 
Omni-Rig can only be started using elevated rights. Is it possible that the 
OmniRig.exe file has a security restriction applied? On my system if I check 
the effective rights for my non-administrator user to the omnirig.exe file I 
see this:



which includes read and execute. Is it the same on your system?



I am not sure why you are asking about how WSJT-X accesses serial ports, when 
using Omni-Rig it doesn't access serial ports. To access COM services we use a 
Qt library Active that allows us to access COM services without the low level 
details of handling COM in C. We also use a Qt tool called dumpcpp which 
generates Active Qt COM wrappers by querying the COM server via its GUID to 
enumerate its COM API.



https://doc.qt.io/qt-5/activeqt-index.html



73
Bill
G4WJS.



On 18/07/2021 18:55, Tom via wsjt-devel wrote:

Hi

Ok.  I did this.  When you run WSJT without being admin, no log is made at all. 
 You get Failed to start Omni Rig COM server in  WSJT

If you run it as admin, then a log appears.

Here are the first few lines…



13:45:51.670  Omni-Rig started: Version 1.19

13:45:51.675  Loading commands from "ZS-1.ini"

13:45:51.691  Loading commands from "TS-930.ini"

13:45:51.707  Loading commands from "TS-870.ini"



If you run Log4OM for example NOT as admin, a log is created as above.



Since this happens with an older version of WSJT and the latest versions 
(production) most likely a library somewhere has been changed.  Perhaps by 
Windows update.

I remember a couple of years ago, that I had a sound device stuck in WSJT even 
though the device wasn’t installed. .  We worked on it a lot to no resolution.  
A subsequent Windows update fixed it.

What libraries are you using for serial port access? Or the com server?



73 Tom



From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 

Sent: Sunday, July 18, 2021 1:32 PM
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
Cc: Bill Somerville  <mailto:g4...@classdesign.com> 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Tom,



I did have a minor typo in the first path I wrote below, other than that it 
most certainly is where the Omni-Rig configuration file is found:

C:\Users\bill\build>dir "%AppData%\Afreet\Products\OmniRig\"
 Volume in drive C is Windows8_OS
 Volume Serial Number is 56CD-82B3

 Directory of C:\Users\bill\AppData\Roaming\Afreet\Products\OmniRig

20/04/2017  15:16  .
20/04/2017  15:16  ..
18/07/2021  08:38   762 OmniRig.ini
14/08/2016  00:16   282 OmniRig.ini~
18/07/2021  08:3618,617 OmniRig.log
   3 File(s) 19,661 bytes
   2 Dir(s)  62,254,145,536 bytes free

Note Products, not Produxts as I mis-typed.



At this point I think that running anything here with elevated rights causing 
different behaviour is coincidental.



I also think the "Failed to start Omni-Rig COM server" is somewhat bogus too as 
you have proved that if you stat the server manually WSJT-X still fails to hook 
up with it. I am hoping the Omni-Rig debug log has some entry that tells me 
what is actually happening.



73
Bill
G4WJS.



On 18/07/2021 17:19, Tom via wsjt-devel wrote:

Hi

There is no such path.  I am using omni-rig 1.19 just downloaded from the web 
at dxatlas.



The use of administrator mode only works for the 64 bit WSJT. The 32 bit fails 
with both user and administrator mode.  Always failed to start the omnirig com 
server.

Tom







From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 

Sent: Sunday, July 18, 2021 3:39 AM
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
Cc: Bill Somerville  <mailto:g4...@classdesign.com> 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for the clarification. You didn't confirm which version of Omni-Rig you 
are using.



It would be interesting to see the Omni-Rig debug log for a test where WSJT-X 
claims it is unable to start the Omni-Rig COM server. To enable Omni-Rig debug 
logging put the following into the main Omni-Rig settings file 
"%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini"

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

Ok.  I did this.  When you run WSJT without being admin, no log is made at all. 
 You get Failed to start Omni Rig COM server in  WSJT

If you run it as admin, then a log appears.

Here are the first few lines…



13:45:51.670  Omni-Rig started: Version 1.19

13:45:51.675  Loading commands from "ZS-1.ini"

13:45:51.691  Loading commands from "TS-930.ini"

13:45:51.707  Loading commands from "TS-870.ini"



If you run Log4OM for example NOT as admin, a log is created as above.



Since this happens with an older version of WSJT and the latest versions 
(production) most likely a library somewhere has been changed.  Perhaps by 
Windows update.

I remember a couple of years ago, that I had a sound device stuck in WSJT even 
though the device wasn’t installed. .  We worked on it a lot to no resolution.  
A subsequent Windows update fixed it.

What libraries are you using for serial port access? Or the com server?



73 Tom



From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 1:32 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Tom,



I did have a minor typo in the first path I wrote below, other than that it 
most certainly is where the Omni-Rig configuration file is found:

C:\Users\bill\build>dir "%AppData%\Afreet\Products\OmniRig\"
 Volume in drive C is Windows8_OS
 Volume Serial Number is 56CD-82B3

 Directory of C:\Users\bill\AppData\Roaming\Afreet\Products\OmniRig

20/04/2017  15:16  .
20/04/2017  15:16  ..
18/07/2021  08:38   762 OmniRig.ini
14/08/2016  00:16   282 OmniRig.ini~
18/07/2021  08:3618,617 OmniRig.log
   3 File(s) 19,661 bytes
   2 Dir(s)  62,254,145,536 bytes free

Note Products, not Produxts as I mis-typed.



At this point I think that running anything here with elevated rights causing 
different behaviour is coincidental.



I also think the "Failed to start Omni-Rig COM server" is somewhat bogus too as 
you have proved that if you stat the server manually WSJT-X still fails to hook 
up with it. I am hoping the Omni-Rig debug log has some entry that tells me 
what is actually happening.



73
Bill
G4WJS.



On 18/07/2021 17:19, Tom via wsjt-devel wrote:

Hi

There is no such path.  I am using omni-rig 1.19 just downloaded from the web 
at dxatlas.



The use of administrator mode only works for the 64 bit WSJT. The 32 bit fails 
with both user and administrator mode.  Always failed to start the omnirig com 
server.

Tom







From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 

Sent: Sunday, July 18, 2021 3:39 AM
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
Cc: Bill Somerville  <mailto:g4...@classdesign.com> 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for the clarification. You didn't confirm which version of Omni-Rig you 
are using.



It would be interesting to see the Omni-Rig debug log for a test where WSJT-X 
claims it is unable to start the Omni-Rig COM server. To enable Omni-Rig debug 
logging put the following into the main Omni-Rig settings file 
"%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:

[Debug]
Log=1

The log file is called OmniRig.log and appears in the same 
"%AppData%\Afreet\Products\OmniRig\" directory.



73
Bill
G4WJS.



On 17/07/2021 00:42, tom via wsjt-devel wrote:

Hi

No, I don't think I said this right.

If you open omnirig while you monitor the serial port, the serial port opens, 
then there's a little activity and then the port closed. Omnirig remains open.

Starting wsjt with omnirig open or closed produces the same result. Failed to 
start com server unless you run it as admin.



Tom





Sent from my Galaxy





 Original message 

From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 


Date: 2021-07-16 5:56 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>

Cc: Bill Somerville  <mailto:g4...@classdesign.com> 

Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



that's not how Omni-Rig behaves for me, if I start it manually the setup dialog 
stays open until it is cancelled or closed with the OK button. Starting WSJT-X 
to communicate with it doesn't change that. What version of Omni-Rig are you 
using?



73
Bill
G4WJS.



On 16/07/2021 22:49, Tom via wsjt-devel wrote:

Hi

Omni-rig connects just fine to the radio.  When you open it there is some 
initial comport activity then it closes.  All this is normal.

It is completely reproducible on my system.  There is no issue with any other 
application that uses Omni-rig.

On the groups.io list, there are peop

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

There is no such path.  I am using omni-rig 1.19 just downloaded from the web 
at dxatlas.



The use of administrator mode only works for the 64 bit WSJT. The 32 bit fails 
with both user and administrator mode.  Always failed to start the omnirig com 
server.

Tom







From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 3:39 AM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for the clarification. You didn't confirm which version of Omni-Rig you 
are using.



It would be interesting to see the Omni-Rig debug log for a test where WSJT-X 
claims it is unable to start the Omni-Rig COM server. To enable Omni-Rig debug 
logging put the following into the main Omni-Rig settings file 
"%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:

[Debug]
Log=1

The log file is called OmniRig.log and appears in the same 
"%AppData%\Afreet\Products\OmniRig\" directory.



73
Bill
G4WJS.



On 17/07/2021 00:42, tom via wsjt-devel wrote:

Hi

No, I don't think I said this right.

If you open omnirig while you monitor the serial port, the serial port opens, 
then there's a little activity and then the port closed. Omnirig remains open.

Starting wsjt with omnirig open or closed produces the same result. Failed to 
start com server unless you run it as admin.



Tom





Sent from my Galaxy





 Original message 

From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 


Date: 2021-07-16 5:56 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>

Cc: Bill Somerville  <mailto:g4...@classdesign.com> 

Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



that's not how Omni-Rig behaves for me, if I start it manually the setup dialog 
stays open until it is cancelled or closed with the OK button. Starting WSJT-X 
to communicate with it doesn't change that. What version of Omni-Rig are you 
using?



73
Bill
G4WJS.



On 16/07/2021 22:49, Tom via wsjt-devel wrote:

Hi

Omni-rig connects just fine to the radio.  When you open it there is some 
initial comport activity then it closes.  All this is normal.

It is completely reproducible on my system.  There is no issue with any other 
application that uses Omni-rig.

On the groups.io list, there are people that have reported this in the past.

73 Tom





From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 

Sent: Friday, July 16, 2021 4:03 PM
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
Cc: Bill Somerville  <mailto:g4...@classdesign.com> 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



OK, I've not see that behaviour. Are you able to reproduce it? If yes, then 
does starting Omni-Rig manually before starting WSJT-X work correctly?



73
Bill
G4WJS.



On 16/07/2021 20:59, tom via wsjt-devel wrote:

Hi

Actually no. When you start wsjt it immediately gives an error saying failed to 
start omnirig com server. If you monitor the serial port traffic, nothing 
happens at all. No serial communications at all.

If you start wsjt as administrator it works without an issue. This doesn't 
happen with any other software that uses omnirig. It's strange because this 
always worked in the past.

73 Tom va2fsq







Sent from my Galaxy





 Original message 

From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 


Date: 2021-07-16 3:36 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>

Cc: Bill Somerville  <mailto:g4...@classdesign.com> 

Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



On 16/07/2021 20:10, Tom via wsjt-devel wrote:
> I am the author of Win4IcomSuite and have started getting reports of WSJT
> failing to start the Omni-rig COM server.  This does not happen on all
> computers. In addition, it starts happening when no changes have been made
> to Omni-rig and WSJT.  Installing the latest versions does not correct the
> issue.
> To reproduce:
> Reboot your computer and make sure there are no other applications using
> omni-rig.
> Use Omni-rig definition for your Icom radio;. Start WSJT.  You receive the
> above error.
> Run WSJT as Administrator and it works.
>
> All other applications using Omni-rig work without putting them in
> administrator mode.  No other related software is running.  This is with a
> direct connection to the radio.
>
> Details, version 2.4.0 (happens on previous version as well).
> Windows 10, version 19041.1083
> 73 Tom va2fsq

Tom,

I am looking into this issue, you don't need to keep repeating your query.

So far I see on

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[tom via wsjt-devel]

HiNo, I don't think I said this right.If you open omnirig while you monitor the 
serial port, the serial port opens, then there's a little activity and then the 
port closed. Omnirig remains open.Starting wsjt with omnirig open or closed 
produces the same result. Failed to start com server unless you run it as 
admin.TomSent from my Galaxy
 Original message From: Bill Somerville via wsjt-devel 
 Date: 2021-07-16  5:56 p.m.  (GMT-05:00) To: 
wsjt-devel@lists.sourceforge.net Cc: Bill Somerville  
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server 
Hi Tom,


that's not how Omni-Rig behaves for me,
  if I start it manually the setup dialog stays open until it is
  cancelled or closed with the OK button. Starting WSJT-X to
  communicate with it doesn't change that. What version of Omni-Rig
  are you using?


73
  Bill
  G4WJS.


On 16/07/2021 22:49, Tom via wsjt-devel
  wrote:


  Hi
  Omni-rig
  connects just fine to the radio.  When you open it there is
  some initial comport activity then it closes.  All this is
  normal.
  It
  is completely reproducible on my system.  There is no issue
  with any other application that uses Omni-rig.
  On
  the groups.io list, there are people that have reported this
  in the past. 
  73
  Tom
   
   
  

  From: Bill Somerville via wsjt-devel
   
  Sent: Friday, July 16, 2021 4:03 PM
  To: wsjt-devel@lists.sourceforge.net
  Cc: Bill Somerville 
  Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig:
  Failed to start Omni Rig COM server

  
   
  
Hi Tom,
  
  
 
  
  
OK, I've not see that behaviour. Are you
  able to reproduce it? If yes, then does starting Omni-Rig
  manually before starting WSJT-X work correctly?
  
  
 
  
  
73
  Bill
  G4WJS.
  
  
 
  
  
On 16/07/2021 20:59, tom via wsjt-devel
  wrote:
  
  

  Hi


  Actually no. When you start wsjt it
immediately gives an error saying failed to start omnirig
com server. If you monitor the serial port traffic, nothing
happens at all. No serial communications at all. 


  If you start wsjt as administrator it
works without an issue. This doesn't happen with any other
software that uses omnirig. It's strange because this always
worked in the past.


  73 Tom va2fsq


   


   


   


  
Sent from my Galaxy
  


   


   


  
 Original message 
  
  
From: Bill Somerville via wsjt-devel 

  
  
  
Date: 2021-07-16 3:36 p.m. (GMT-05:00)
  
  
  
To: wsjt-devel@lists.sourceforge.net
  
  
  
Cc: Bill Somerville 
  
  
  
Subject: Re: [wsjt-devel] WSJT-X and
  Omni-Rig: Failed to start Omni Rig COM server 
  
  
 
  

On 16/07/2021 20:10, Tom via wsjt-devel
  wrote:
  > I am the author of Win4IcomSuite and have started getting
  reports of WSJT
  > failing to start the Omni-rig COM server.  This does not
  happen on all
  > computers. In addition, it starts happening when no
  changes have been made
  > to Omni-rig and WSJT.  Installing the latest versions
  does not correct the
  > issue.
  > To reproduce:
  > Reboot your computer and make sure there are no other
  applications using
  > omni-rig.
  > Use Omni-rig definition for your Icom radio;. Start
  WSJT.  You receive the
  > above error.
  > Run WSJT as Administrator and it works.
  >
  > All other applications using Omni-rig work without
  putting them in
  > administrator mode.  No other related software is
  running.  This is with a
  > direct connection to the radio.
  >
  > Details, version 2.4.0 (happens on previous version as
  well).
      > Windows 10, version 19041.1083
  > 73 Tom va2fsq
  
  Tom,
  
  I am looking into this issue, you don't need to kee

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

Omni-rig connects just fine to the radio.  When you open it there is some 
initial comport activity then it closes.  All this is normal.

It is completely reproducible on my system.  There is no issue with any other 
application that uses Omni-rig.

On the groups.io list, there are people that have reported this in the past.

73 Tom





From: Bill Somerville via wsjt-devel 
Sent: Friday, July 16, 2021 4:03 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



OK, I've not see that behaviour. Are you able to reproduce it? If yes, then 
does starting Omni-Rig manually before starting WSJT-X work correctly?



73
Bill
G4WJS.



On 16/07/2021 20:59, tom via wsjt-devel wrote:

Hi

Actually no. When you start wsjt it immediately gives an error saying failed to 
start omnirig com server. If you monitor the serial port traffic, nothing 
happens at all. No serial communications at all.

If you start wsjt as administrator it works without an issue. This doesn't 
happen with any other software that uses omnirig. It's strange because this 
always worked in the past.

73 Tom va2fsq







Sent from my Galaxy





 Original message 

From: Bill Somerville via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net> 


Date: 2021-07-16 3:36 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>

Cc: Bill Somerville  <mailto:g4...@classdesign.com> 

Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



On 16/07/2021 20:10, Tom via wsjt-devel wrote:
> I am the author of Win4IcomSuite and have started getting reports of WSJT
> failing to start the Omni-rig COM server.  This does not happen on all
> computers. In addition, it starts happening when no changes have been made
> to Omni-rig and WSJT.  Installing the latest versions does not correct the
> issue.
> To reproduce:
> Reboot your computer and make sure there are no other applications using
> omni-rig.
> Use Omni-rig definition for your Icom radio;. Start WSJT.  You receive the
> above error.
> Run WSJT as Administrator and it works.
>
> All other applications using Omni-rig work without putting them in
> administrator mode.  No other related software is running.  This is with a
> direct connection to the radio.
>
> Details, version 2.4.0 (happens on previous version as well).
> Windows 10, version 19041.1083
> 73 Tom va2fsq

Tom,

I am looking into this issue, you don't need to keep repeating your query.

So far I see one problem with startup when there is a fault condition
like the rig not being accessible, or if WSJT-X is closed down before it
has completed all the retries it attempts before reporting an error
(that takes up to 10 seconds). Is that consistent with what you are
reporting? If so, then if WSJT-X is left for 20 seconds or so to do its
own thing does an error get reported?

73
Bill
G4WJS.





--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[tom via wsjt-devel]

HiActually no. When you start wsjt it immediately gives an error saying failed 
to start omnirig com server. If you monitor the serial port traffic, nothing 
happens at all. No serial communications at all. If you start wsjt as 
administrator it works without an issue. This doesn't happen with any other 
software that uses omnirig. It's strange because this always worked in the 
past.73 Tom va2fsqSent from my Galaxy
 Original message From: Bill Somerville via wsjt-devel 
 Date: 2021-07-16  3:36 p.m.  (GMT-05:00) To: 
wsjt-devel@lists.sourceforge.net Cc: Bill Somerville  
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server On 16/07/2021 20:10, Tom via wsjt-devel wrote:> I am the author of 
Win4IcomSuite and have started getting reports of WSJT> failing to start the 
Omni-rig COM server.  This does not happen on all> computers. In addition, it 
starts happening when no changes have been made> to Omni-rig and WSJT.  
Installing the latest versions does not correct the> issue.> To reproduce:> 
Reboot your computer and make sure there are no other applications using> 
omni-rig.> Use Omni-rig definition for your Icom radio;. Start WSJT.  You 
receive the> above error.> Run WSJT as Administrator and it works.>> All other 
applications using Omni-rig work without putting them in> administrator mode.  
No other related software is running.  This is with a> direct connection to the 
radio.>> Details, version 2.4.0 (happens on previous version as well).> Windows 
10, version 19041.1083> 73 Tom va2fsqTom,I am looking into this issue, you 
don't need to keep repeating your query.So far I see one problem with startup 
when there is a fault condition like the rig not being accessible, or if WSJT-X 
is closed down before it has completed all the retries it attempts before 
reporting an error (that takes up to 10 seconds). Is that consistent with what 
you are reporting? If so, then if WSJT-X is left for 20 seconds or so to do its 
own thing does an error get 
reported?73BillG4WJS.___wsjt-devel 
mailing 
listwsjt-devel@lists.sourceforge.nethttps://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] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

I am the author of Win4IcomSuite and have started getting reports of WSJT
failing to start the Omni-rig COM server.  This does not happen on all
computers. In addition, it starts happening when no changes have been made
to Omni-rig and WSJT.  Installing the latest versions does not correct the
issue.
To reproduce:
Reboot your computer and make sure there are no other applications using
omni-rig.
Use Omni-rig definition for your Icom radio;. Start WSJT.  You receive the
above error.
Run WSJT as Administrator and it works.

All other applications using Omni-rig work without putting them in
administrator mode.  No other related software is running.  This is with a
direct connection to the radio.

Details, version 2.4.0 (happens on previous version as well).
Windows 10, version 19041.1083
73 Tom va2fsq


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



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

[wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

I am the author of Win4IcomSuite and have started getting reports of WSJT
failing to start the Omni-rig COM server.  This does not happen on all
computers. In addition, it starts happening when no changes have been made
to Omni-rig and WSJT.  Installing the latest versions does not correct the
issue.
To reproduce:
Reboot your computer and make sure there are no other applications using
omni-rig.
Use Omni-rig definition for your Icom radio;. Start WSJT.  You receive the
above error.
Run WSJT as Administrator and it works.

All other applications using Omni-rig work without putting them in
administrator mode.

Details, version 2.4.0 (happens on previous version as well).
Windows 10, version 19041.1083
73 Tom va2fsq


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



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

Re: [wsjt-devel] ANNOUNCEMENT: update_wsjtx_log.py version 1.1.1 released

[tom]

Dave

Remember to remind people not to use it in contests - if there is a mismatch 
between what is sent over the air and what is recorded in QRZ - points will be 
lost.

If the grid is blank it highlights the user need to take action - usually 
checking all.txt and not grabbing qrz.com <http://qrz.com/> data.

Personally think it’s a really bad idea to mess around like this - leave the 
wsjx adi file alone - warn/report by all means but ‘on the fly’ changes are not 
good. 

Tom
GM8MJV



> On 8 Mar 2021, at 15:13, Dave Slotter, W3DJS  wrote:
> 
> Fellow hams and users of WSJT-X:
> 
> I am pleased to announce the creation and immediate availability of version 
> 1.1.1 of a Python application to address some of the deficiencies of WSJT-X 
> not providing a method to automatically look up callsigns and missing grid 
> squares and fill them in.
> 
> Changes:
> * Added support for FREE data source callook.info <http://callook.info/>
> * Enhanced session and error handling
> 
> This Python application has been successfully tested with Python3 and a 
> Raspberry Pi, although may easily be used on other Linux systems with 
> Python3. It has not been tested with Mac, but should probably work there as 
> well. It has not been tested under Windows.
> 
> The script has passed scrutiny by Pylint and Flake8.
> 
> Prerequisites: Requests and Watchdog Python libraries.
> Environment variables: If using QRZ as a data source QRZ_USERNAME and 
> QRZ_PASSWORD to be filled in with your authentication tokens from QRZ.
> 
> Additional backends such as HamQTH may be added in the future if there is 
> demand.
> 
> To use: download the script, and if using QRZ as a data source, set the 
> QRZ_USERNAME and QRZ_PASSWORD environment variables and start up WSJT-X and 
> the script. It will run automatically.
> 
> CAUTION: do not independently edit the wsjtx_log.adi while this script is 
> running, or bad things will happen. This script only works when WSJT-X is 
> appending its ADIF log file with new entries, nothing else.
> 
> The Python script, update_wsjtx_log.py may be located and downloaded from 
> here:
> 
> https://github.com/dslotter/ham_radio_scripts/blob/main/update_wsjtx_log.py 
> <https://github.com/dslotter/ham_radio_scripts/blob/main/update_wsjtx_log.py>
> --
> Dave Slotter, W3DJS 
> <https://www.qrz.com/db/W3DJS>___
> 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] Q65 crashes unexpectantly

[tom]

Any details - screen shots of error messages - seems like there are three 
different one?

What mode are you using

Rig? Cat Control? Time setup?

Could it be RFI - run into a dummy load

With 'fatal error’ anything in Windows Event Viewer?

Will need some more details before can make a suitable suggestion

Tom
GM8MJV



> On 19 Feb 2021, at 20:28, Gary Gearhart  wrote:
> 
> Program version: V2.4.0-rc1
> Operating System: Windows 10 PRO
> Problem: popup error concerning “STACK ERROR” and “orphaned JT9 process” plus 
> “fatal error”
> Sequence: this has occurred 3 times after the transmit cycle has completed 
> and switching back to receive. The only fix is to reboot. It seems to run 
> fine for a while afterwards.
>  
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <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 in WSJT-X 2.3 and 2.4rc1 COM port

[tom]

Thanks for the update Bill

I have no issue with options being configurable but as Alex put it - ’never 
touch a running system’ - tidy up coding to make it more robust yes but 
removing a feature IMO is same as altering a default - it no longer works the 
same.

Also as with Alex just deleted a chuck of this reply so the thread does not go 
down hill fast.

Expressed my point I hope some more consideration may be given if this sort of 
issue arrises in the future.

Tom
GM8MJV

> On 16 Feb 2021, at 10:32, Bill Somerville  wrote:
> 
> Hi Alex and Tom,
> 
> the Hamlib change was not a change of defaults, it was a removal of a feature 
> that apparently was causing issues. I asked that it not be removed and the 
> option offered was to make it a configuration option.
> 
> 73
> Bill
> G4WJS.
> 
> On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:
>> Totally in agree with Tom
>> 
>>  
>> 
>> I delete part of my previous email to avoid start arguments BUT in IT we 
>> always said “never touch a running system” and for programming also apply, 
>> why change the previous default for something doesn’t works? And create just 
>> problems?
>> 
>>  
>> 
>> PTT and associated routines was working great up to WSJT-X 2.2.2, why change 
>> that?, the proof of the pudding is in the eating, for sure exist a valid 
>> reason by “the authors” but unfortunate this time maybe wrong.
>> 
>>  
>> 
>> Alex, HB9DRI
>> 
>>  
>> 
>> From: tom  <mailto:t...@tkrh.co.uk> 
>> Sent: Tuesday, February 16, 2021 4:18 PM
>> To: Black Michael  <mailto:mdblac...@yahoo.com>; WSJT 
>> software development  
>> <mailto:wsjt-devel@lists.sourceforge.net>
>> Subject: Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port
>> 
>>  
>> 
>> Hi All
>> 
>>  
>> 
>> Don’t want to start an argument and please feel free to ignore my comments.
>> 
>>  
>> 
>> It seems a LOT of the errors recently seem to be because HamLib have altered 
>> defaults and others have to pick up the flack.
>> 
>>  
>> 
>> It always used to be the case ’never alter the default’ - yes add new 
>> features but never change the default.
>> 
>>  
>> 
>> There has been the issue of powering rigs on - default changed, shared ptt - 
>> default changed.
>> 
>>  
>> 
>> There are more than a ‘couple of complains’ on this mailing list alone to 
>> keep the status quo.
>> 
>>  
>> 
>> Please Please Please DO NOT start to toss the blame around - oh it up to xyz 
>> to change their software to over-ride the changes we made.  Just keep 
>> defaults as they were and all will be happy.
>> 
>>  
>> 
>> End of rant
>> 
>>  
>> 
>> Tom
>> 
>> GM8MJV
>> 
>>  
>> 
>>  
>> 
>> On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel 
>> mailto:wsjt-devel@lists.sourceforge.net>> 
>> wrote:
>> 
>>  
>> 
>> A couple of complaints from those who were using a single instance were 
>> having problems with the constant open/close of the serial port.
>> 
>> So it was changed to support the simple case and those that want the more 
>> complex case of multiple apps have to use the additional file as WSJT-X 
>> authors have decided to not include any options in the rig control user 
>> interface.
>> 
>>  
>> 
>> I'm looking at the sharing now to see if there is a problem going on.
>> 
>>  
>> 
>> Mike W9MDB
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda, HB9DRI 
>> mailto:hb9...@emeham.com>> wrote:
>> 
>>  
>> 
>>  
>> 
>> Hello Bill
>> 
>>  
>> 
>> Following your instructions I use your file  (looks the same as I use 
>> before) and I place in the properly log directory for each of the WSJT-X 
>> (totally 4) and doesn’t work, the PTT is not share.
>> 
>>  
>> 
>> I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is 
>> not?
>> 
>>  
>> 
>> Regards
>> 
>> Alex, HB9DRI
>> 
>>  
>> 
>> From: Bill Somerville mailto:g4...@classdesign.com>> 
>> Sent: Monday, February 15, 2021 6:29 PM
>> To: wsjt-devel@lists.sourceforge.net 
>> <mailto:wsjt-devel@lists.sourceforge.net>
>> Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 CO

Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

[tom]

Hi All

Don’t want to start an argument and please feel free to ignore my comments.

It seems a LOT of the errors recently seem to be because HamLib have altered 
defaults and others have to pick up the flack.

It always used to be the case ’never alter the default’ - yes add new features 
but never change the default.

There has been the issue of powering rigs on - default changed, shared ptt - 
default changed.

There are more than a ‘couple of complains’ on this mailing list alone to keep 
the status quo.

Please Please Please DO NOT start to toss the blame around - oh it up to xyz to 
change their software to over-ride the changes we made.  Just keep defaults as 
they were and all will be happy.

End of rant

Tom
GM8MJV


> On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel 
>  wrote:
> 
> A couple of complaints from those who were using a single instance were 
> having problems with the constant open/close of the serial port.
> So it was changed to support the simple case and those that want the more 
> complex case of multiple apps have to use the additional file as WSJT-X 
> authors have decided to not include any options in the rig control user 
> interface.
> 
> I'm looking at the sharing now to see if there is a problem going on.
> 
> Mike W9MDB
> 
> 
> 
> 
> On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda, HB9DRI 
>  wrote:
> 
> 
> Hello Bill
> 
>  
> Following your instructions I use your file  (looks the same as I use before) 
> and I place in the properly log directory for each of the WSJT-X (totally 4) 
> and doesn’t work, the PTT is not share.
> 
>  
> I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is 
> not?
> 
>  
> Regards
> 
> Alex, HB9DRI
> 
>  
> From: Bill Somerville  
> Sent: Monday, February 15, 2021 6:29 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
> 
>  
> Hi Alex,
> 
>  
> try the attached file. It needs to go in the log files directory of each 
> WSJT-X instance ("Settings->File->Open log directory").
> 
>  
> 73
> Bill
> G4WJS.
> 
>  
> On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:
> 
> Hello Mike
> 
>  
> Sorry I didn’t answer to the list;
> 
>  
> I create a file named hamlib_settings.json and paste inside the code you send 
> me:
> 
>  
> {
> 
>  "config": {
> 
> "ptt_share": 1
> 
>  }
> 
> }
> 
>  
> Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in
> 
> Each of the 4 WSJT-X folders but doesn’t work,
> 
>  
> Alex, HB9DRI
> 
>  
>  
> From: Black Michael via wsjt-devel  
> <mailto:wsjt-devel@lists.sourceforge.net> 
> Sent: Monday, February 15, 2021 11:11 AM
> To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> Cc: Black Michael  <mailto:mdblac...@yahoo.com>
> Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
> 
>  
> The PTT port is no longer shareable by default.
> 
>  
> Place this file in C:\Users\[username]\AppData\Local\WSJT-X
> 
>  
> {
> 
>  "config": {
> 
> "ptt_share": 1
> 
>  }
> 
> }
> 
>  
>  
> Mike W9MDB
> 
>  
>  
>  
> On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda, HB9DRI 
> mailto:hb9...@emeham.com>> wrote:
> 
>  
>  
> Just to inform you, I found a bug regarding COM port for PTT, it appears in 
> WSJT-X 2.3 and in 2.4 RC1, let me explain.
> 
>  
> I run 4 WSJT-X at the same time, I use Omnirig to control my IC9700 but PTT 
> is manage via a COM port, this is a must for me to TX first a Sequencer via 
> the COM port and later TX the radio, I cannot use CAT for PTT,  that 
> guarantee me no RF spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all 
> configure to use COM3 for PTT, in this configuration I can TX with ANY of the 
> 6 programs, more precise I can TX with the program were the decodes or best 
> decode happens, unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX ONLY with 
> the FIRST program who opens the PTT COM port, the other ones don’t work and 
> MAP65 give a opening COM port ERROR, the other WSJT-X simple don’t TX, would 
> be great to fix this bug because when you run multiple WSJT-X is a must to 
> work with all instance capable of TX, WSJT-X 2.2.2 works perfect.
> 
>  
> To confirm this bug I roll back to 2.2.2 and install 2.3 and later 2.4RC1, 
> the bug appear in 2.3
> 
>  
> 73 de Alex, HB9DRI
> 
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] FLEX radio / ANAN Power SDR / Thetis

[Tom Berry]

I would be happy to help debug it..

Tom AA4VV


On 2/10/2021 5:11 PM, Black Michael via wsjt-devel wrote:

Would you be available for some debugging?

I'll be back in a little while and perhaps we can connect up and I can 
see the problem and debug it?


Mike W9MDB




On Wednesday, February 10, 2021, 03:49:45 PM CST, Tom Berry 
 wrote:



I am using the ANAN 7000 DLE and I selected FLEX radio / ANAN Power SDR
/ Thetis for the Rig driver .

If I select Split Operation = RIG then the split VFO for TX seems to be
off when I run WSJT-X.

When I press Tune the signal may be out of the receive passband for TX.
This also happens when I change bands.

After one TX in FT8 then the TX VFO is set correctly.

I'm using WSJT-X V2.4.0 RC1

Is there any way I can use this driver and have the Split Option to work
like "Fake It" ?

Thanks

Tom AA4VV




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
<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] FLEX radio / ANAN Power SDR / Thetis

[Tom Berry]

I am using the ANAN 7000 DLE and I selected FLEX radio / ANAN Power SDR 
/ Thetis for the Rig driver .


If I select Split Operation = RIG then the split VFO for TX seems to be 
off when I run WSJT-X.


When I press Tune the signal may be out of the receive passband for TX.  
This also happens when I change bands.


After one TX in FT8 then the TX VFO is set correctly.

I'm using WSJT-X V2.4.0 RC1

Is there any way I can use this driver and have the Split Option to work 
like "Fake It" ?


Thanks

Tom AA4VV



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

Re: [wsjt-devel] Valid DXCC checking feature

[tom]

Against it.

There are too many callsigns being issued for numerous reasons - anniversaries 
/ covid / 1st etc.  Having the software check (and keep having to get internal 
lists updates from other sites) is not really practical. 

I can’t think of an easy way to detect pirates - non-dxcc you have the overhead 
and issues as mentioned above - there is no ‘100% verifiable’ list of genuine 
callsigns - also no way to tell that the GM8MJV you are working is in fact me - 
it’s a valid callsign - someone may  be using it - a pirate but unable to 
detect it.

Would be better off concentrating on detecting and blocking the robots and flag 
those.

Tom
GM8MJV


> On 9 Feb 2021, at 10:37, Anders Strange  wrote:
> 
> Would it be an idea to implement a 'Valid DXCC' checking and 'Pirate 
> Detection' feature?
> 
> The problem is that pirate callsigns like the Dxx from the Donetsk region in 
> Russia show up as new/unknown DXCC's. It would be fairly easy to implement a 
> check against the ITU list and the valid DXCC list and make a new color for 
> 'possible pirate' or something.
> 
> What do you think?
> 
> 73's
> Anders / OZ3ACB
> ___
> 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] Transverter support and UDP messages

[tom]

All

Not sure if this can be fixed/worked around - will depend I suspect on UDP 
message content

Testing a 13cm (2320) system - wsjt-x allows me to enter transverter offset so 
it knows what to set the rig to.

2320 - offset (of  -2174) gives IF of 146 - all OK rig changes freq correctly 
as expected.

I am using a 3rd party tool (JTAlert) - this is  reporting 2m - which is 
correct for the rig but not to operating freq

Is there a way wsjt-x can send the actual frequency - not checked my logger yet 
to see if does something similar.

Thanks

Tom
GM8MJV

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

Re: [wsjt-devel] Report wrong - bug or by design?

[tom]

Anyone any thoughts on this?

Happened again on the last RSGB FT4 contest last week.

Tom
GM8MJV


> On 23 Dec 2020, at 12:11, tom  wrote:
> 
> Hi All
> 
> Was in an FT4 contest and noticed the reports logged in wsjt_log.adi do not 
> match up with what was sent - or in this case not sent.
> 
> Basic vanilla FT4 mode no weird contest modes etc.  (apart for the odd 
> person!!!)
> 
> One station:
> 
> 201222_122130 7.048 Tx FT4  0  0.0 1258 GU0XXX GM8MJV IO85
>
> 201222_122145 7.048 Tx FT4  0  0.0 1258 GU0XXX GM8MJV IO85
>
> 201222_122153 7.048 Rx FT4 -1 -0.1  871 GM8MJV GU0XXX R IN89
> 201222_122200 7.048 Tx FT4  0  0.0 1258 GU0XXX GM8MJV RR73
>
> 201222_122208 7.048 Rx FT4 -2 -0.1  870 GM8MJV GU0XXX 73
> 
> He was not sending a report due to the contest mode he was in. Yet the 
> logfile does show it.
> 
> WSJT-X_log.adi:
> 
> GU0XXX IN89 MFSK FT4 +06 
> -09 20201222 122200 
> 20201222 122200 40m 7.048758 
> GM8MJV IO85MU 50 
> GM8MJV 
> 
> 
> What was logged looks like the previous qso - if no report was sent.
> 
> 201222_122023 7.048 Rx FT4  6 -0.0  826 GM8MJV G0VDZ IO91
> 201222_122030 7.048 Tx FT4  0  0.0 1258 G0VDZ GM8MJV +06  
>
> 201222_122038 7.048 Rx FT4  5 -0.0  827 GM8MJV G0VDZ R-09
> 201222_122045 7.048 Tx FT4  0  0.0 1258 G0VDZ GM8MJV RR73 
>
> 201222_122053 7.048 Rx FT4  4 -0.0  826 GM8MJV G0VDZ R-09
> 201222_122102 7.048 Tx FT4  0  0.0 1258 G0VDZ GM8MJV RR73 
>
> 201222_122108 7.048 Rx FT4  9 -0.0  826 GM8MJV G0VDZ 73
> 
> G0VDZ IO91 MFSK FT4 +06 
> -09 20201222 122023 
> 20201222 122045 40m 7.048758 
> GM8MJV IO85MU 50 
> GM8MJV 
> 
> Is this by design or a bug - if no report was sent nothing should be logged, 
> would have thought if something, then 00 and not the previous QSO.
> 
> Tom
> GM8MJV
> 
> 
> 
> 
> 
> ___
> 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] Report wrong - bug or by design?

[tom]

Hi All

Was in an FT4 contest and noticed the reports logged in wsjt_log.adi do not 
match up with what was sent - or in this case not sent.

Basic vanilla FT4 mode no weird contest modes etc.  (apart for the odd 
person!!!)

One station:

201222_122130 7.048 Tx FT4  0  0.0 1258 GU0XXX GM8MJV IO85  
 
201222_122145 7.048 Tx FT4  0  0.0 1258 GU0XXX GM8MJV IO85  
 
201222_122153 7.048 Rx FT4 -1 -0.1  871 GM8MJV GU0XXX R IN89
201222_122200 7.048 Tx FT4  0  0.0 1258 GU0XXX GM8MJV RR73  
 
201222_122208 7.048 Rx FT4 -2 -0.1  870 GM8MJV GU0XXX 73

He was not sending a report due to the contest mode he was in. Yet the logfile 
does show it.

WSJT-X_log.adi:

GU0XXX IN89 MFSK FT4 +06 
-09 20201222 122200 20201222 
122200 40m 7.048758 GM8MJV 
IO85MU 50 GM8MJV 


What was logged looks like the previous qso - if no report was sent.

201222_122023 7.048 Rx FT4  6 -0.0  826 GM8MJV G0VDZ IO91
201222_122030 7.048 Tx FT4  0  0.0 1258 G0VDZ GM8MJV +06
 
201222_122038 7.048 Rx FT4  5 -0.0  827 GM8MJV G0VDZ R-09
201222_122045 7.048 Tx FT4  0  0.0 1258 G0VDZ GM8MJV RR73   
 
201222_122053 7.048 Rx FT4  4 -0.0  826 GM8MJV G0VDZ R-09
201222_122102 7.048 Tx FT4  0  0.0 1258 G0VDZ GM8MJV RR73   
 
201222_122108 7.048 Rx FT4  9 -0.0  826 GM8MJV G0VDZ 73

G0VDZ IO91 MFSK FT4 +06 
-09 20201222 122023 20201222 
122045 40m 7.048758 GM8MJV 
IO85MU 50 GM8MJV 

Is this by design or a bug - if no report was sent nothing should be logged, 
would have thought if something, then 00 and not the previous QSO.

Tom
GM8MJV





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

Re: [wsjt-devel] Is there a program that will directly generate WSJT signals for 630M?

[Tom M0LTE]

Someone I know has forked WSJT-X to get the tone sequence at the start of
the TX cycle, which he then passes to a microcontroller embedded inside an
FM radio, which is set up to change the frequency of the unmodulated FM
carrier as per FT8 tones. RX is an RTL dongle. He makes contacts this way,
so it works...

I guess I could ask him for the patch...

On Mon, 21 Dec 2020 at 14:11, Tim Madden  wrote:

> Would it be easiest for the software to have a port for UDP IQ data on
> both RX and TX?
>
> Then we only need to add the operating frequency for the bottom of the
> band to the software configuration for each UDP port number our station can
> support.
>
> That would open the application to any operating frequency without the
> need to provide updates.
>
> (that's how modern airborne radar works)
>
>
> On 12/21/2020 12:25 AM, lstosk...@cox.net wrote:
>
> Seems foolish to build a whole SSB rig to convert the audio signal from
> WSJT to RF when at low frequencies some direct synthesis should be
> possible.  Or am I dreaming?
>
> N0UU
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Question about QRZ Integration

[Tom M0LTE]

Hi Dave

This seems like an ideal thing to implement on top of the existing UDP
interface, which Bill alluded to. You could have your app listen for QSO
Logged messages from WSJT-X, do your QRZ lookup, popping a dialogue if
necessary, then write the record out to an ADIF file owned by your app. Am
I missing something?

Cheers
Tom

On Sat, 5 Dec 2020 at 22:51, Dave Slotter, W3DJS 
wrote:

> Hi Bill,
>
> You've been very clear in two separate messages that you're not going to
> be accepting any code merges from me for this functionality -- even in a
> suggested reduced format. This leaves me with two options (which are not
> exclusive from each other):
>
> a) Relegate my work to a forked version of WSJT-X -- and one such author
> has already offered to collaborate with me.
>
> b) Write a standalone program (probably in Python) to monitor for
> additions to the wsjtx_log.adi file and then modify *just the log file
> additions* "in-line" and hope that WSJT-X and my program don't have
> contention issues over the log file. As you wrote previously, "WSJT-X
> keeps its main logged QSO information in an ADIF format file. There's
> nothing to stop users replacing that file with one augmented with QSOs in
> other modes," -- it sounds like you're saying that WSJT-X is designed to
> allow other third party applications from modifying the log file while
> WSJT-X is running and the user is adding new log entries. If I
> misunderstood this, please advise.
>
> 73,
>
> --
> Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS>
>
>
> On Sat, Dec 5, 2020 at 11:05 AM Bill Somerville 
> wrote:
>
>> Hi Dave,
>>
>> comments in line below.
>>
>> On 05/12/2020 15:37, Dave Slotter, W3DJS wrote:
>>
>> Hi Bill,
>>
>> Thank you for such a detailed and thoughtful response.
>>
>> Understood that QRZ XML API is a paid service. And yes, there are free
>> services like HamQTH.com XML API.
>>
>> Three questions come to mind:
>>
>> a) What do you mean by "We also allow users to substitute an augmented
>> ADIF log file"?
>>
>> WSJT-X keeps its main logged QSO information in an ADIF format file.
>> There's nothing to stop users replacing that file with one augmented with
>> QSOs in other modes, e.g. they might be interested in working new DXCC
>> Entities that they have not worked in any other mode. WSJT-X even offers a
>> push-button that causes the ADIF log file to be rescanned, to populate the
>> in-memory indexes of worked before information, without having to pause
>> normal WSJT-X operation.
>>
>>
>> b) I re-familiarized myself with the User Guide, section 11. Logging and
>> did not see an answer to this question: To what purpose is an empty name
>> field provided in the WSJT-X Logging dialog?
>>
>> The Name field on the Log QSO dialog it there for the user to insert
>> information that may be gathered at the time of the QSO, similarly the
>> propagation mode was recently added. The Name field value, if present,
>> populates the NAME field of the ADIF QSO record. That same information is
>> published via the WSJT-X UDP Message Protocol "QSO Logged"(5) message and
>> in the "Logged ADIF"(12) message. By this means interoperating station
>> logging applications, or bridge applications to them, can pick up the
>> entered information.
>>
>>
>> c) Understanding that you are concerned with (among other things) feature
>> creep in the core application, would you be willing for a compromise here?
>> Rather than add that functionality into the main application, would you be
>> open to an implementation of a plugin interface to allow third-party
>> developers to add optional functionality for inserting the name field? That
>> way you do not have feature creep in the main application, and users can
>> decide for themselves whether or not to enhance their experience with
>> WSJT-X.
>>
>> Currently WSJT-X has no use for a QSO partner name field in its ADIF log
>> file, even though it has the capability to enter that field when logging a
>> QSO, as I explain above. I assume you envisage WSJT-X scanning previous
>> logged QSOs to redisplay the last name recorded, if any, in the log QSO
>> dialog, or perhaps elsewhere in the UI during QSOs, or even against decoded
>> messages. Each of those options requires a greater degree of processing and
>> data management, but I don't see any real gain for users when the vast
>> majority of QSOs made with WSJT-X do not exchange such niceties as an
>> operator name.
>>
>> It seems to me that an applicati

Re: [wsjt-devel] Bug when using MSK144?

[tom]

Sam

Just a quick observation

You say you are defaulting QLog to 50.260 - Region 1 the default MSK144 freq is 
50.280

If you are defaulting esp with a visually impaired operator, they may not 
notice this and wonder why no QSO’s. 

Would you not be better to look at the frequencies setup in wsjt-x and default 
to what has been set by the user?

Regards

Tom


--
73

Tom
GM8MJV (IO85)





> On 2 Sep 2020, at 16:40, Sam W2JDB via wsjt-devel 
>  wrote:
> 
> Hi Bill,
> 
> Checked with the UDP_Daemon and the mode change was being captured.
> 
> I found the problem in my program and it is now working correctly.
> As soon as QLog detects a mode change to MSK144 and the working frequency in 
> WSJT-X is below 6M,
> QLog changes the frequency in the band box 50.260 which then triggers the CAT 
> command to the rig.
> 
> Thank you again for all your help.
>  
> As an FYI, Georgian (M0EBP) is now setup with WSJT-X and QLog, I also express 
> the opinion that it
> would be advantageous to have CAT control with the TS200.
> 
> Helping multiple blind hams setup WSJT-X, I found that in cases where they 
> are not using multiple
> dedicated sound cards for their Audio software such as NDVA or JAWS, I need 
> to change the sound card
> properties and disable Exclusive Control of the sound card. 
> 
> 73, 
> 
> Sam W2JDB
> 
> 
> 
> -Original Message-
> From: Bill Somerville 
> To: wsjt-devel@lists.sourceforge.net
> Sent: Wed, Sep 2, 2020 10:17 am
> Subject: Re: [wsjt-devel] Bug when using MSK144?
> 
> Hi Sam,
> 
> I am unable to reproduce that behaviour. Here's the output from the 
> udp_daemon tool from your first scenario:
> C:\build>\test-install\wsjtx-dev\Release64\bin\udp_daemon.exe -g 239.255.0.1
> Discovered WSJT-X instance: WSJT-X - test v2.3.0-devel (fcc5df)
> WSJT-X - test: Dial frequency changed to 3574000
> WSJT-X - test: Mode changed to MSK144
> WSJT-X - test: Dial frequency changed to 5026
> WSJT-X - test: Mode changed to FT8
> WSJT-X - test: Dial frequency changed to 50313000
> WSJT-X - test: Dial frequency changed to 184
> WSJT-X - test: Mode changed to MSK144
> Continuing with your second scenario I see:
> Removed WSJT-X instance: WSJT-X - test
> Discovered WSJT-X instance: WSJT-X - test v2.3.0-devel (fcc5df)
> WSJT-X - test: Mode changed to JT9A
> WSJT-X - test: Mode changed to MSK144
> WSJT-X - test: Dial frequency changed to 184
> WSJT-X - test: Dial frequency changed to 14500
> WSJT-X - test: Dial frequency changed to 184
> WSJT-X - test: Mode changed to FT8
> WSJT-X - test: Dial frequency changed to 3573000
> WSJT-X - test: Mode changed to MSK144
> All the mode and frequency changes are faithfully reported by UDP status 
> messages.
> 
> 73
> Bill
> G4WJS.
> 
> On 02/09/2020 14:51, Sam W2JDB via wsjt-devel wrote:
>> Hi Bill,
>> 
>> I have updated and tested my program and I can programmatically change the 
>> value in the band box to 50.260 and thereby have WSJT-X issue the CAT 
>> command to the radio and switch to the correct frequency.
>> 
>> However, I ran into a problem where if I then switch back to FT8, drop down 
>> to a low HF band and then switch again to MSK144, there is no indication 
>> being given through UDP status message that the mode was changed. If I then 
>> shutdown WSJT-X while still in MSK144, then start it back up, switch to FT8 
>> move to a lower HF band and then switch back to MSK144, there is no UDP 
>> Traffic indicating a mode change. If on the other hand, I switch to FT8 and 
>> to a lower HF Band, before shutting down WSJT-X, start it up again, switch 
>> to MSK144, I do received the UDP Status message indicating a mode change. It 
>> seems that the mode change indication happens only once if you are not on 
>> the appropriate MSK144 frequency. Anyway, I hope this information helps.
>> 
>> 73,
>> 
>> Sam W2JDB
>> 
>> 
>> 
>> -Original Message-
>> From: Sam W2JDB via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net 
>> <mailto:wsjt-devel@lists.sourceforge.net>
>> To: wsjt-devel@lists.sourceforge.net 
>> <mailto:wsjt-devel@lists.sourceforge.net> 
>> mailto:wsjt-devel@lists.sourceforge.net 
>> <mailto:wsjt-devel@lists.sourceforge.net>
>> Cc: Sam W2JDB mailto:w2...@aol.com <mailto:w2...@aol.com>
>> Sent: Wed, Sep 2, 2020 7:43 am
>> Subject: Re: [wsjt-devel] Bug when using MSK144?
>> 
>> Hi Bill,
>> 
>> Thank you very much for this thoughtful explanation regarding band changes 
>> in WSJT-X.
>> As I mentioned, I instructed Rich to update their document to change to 6M 
>&g

Re: [wsjt-devel] Rig verification

[tom]

Looks very much like you have a copy of WSJT-X still running while trying the 
install.

Reboot to ensure all wsjt-x processes stopped and re-try.

Tom

--
73

Tom
GM8MJV (IO85)





> On 16 Jul 2020, at 15:50, Frank Kirschner  wrote:
> 
> I'm using a Flex 6600 and wsjt-x v 2.1.0. When I select "Rig" as the split 
> mode, wsjt-x crashes. I thought it might be that I am using an old version of 
> wsjt-x, so I downloaded v.2.2.2. It won't install. I get this error:
> 
> 
> 
> Running Win 7 64, i7 with 16 GB.
> 
> 73,
> Frank
> KF6E
> 
> On Thu, Jul 16, 2020 at 12:11 AM Black Michael via wsjt-devel 
> mailto:wsjt-devel@lists.sourceforge.net>> 
> wrote:
> If anybody has a rig out there that's in this list and you have it working 
> with WSJT-X...or if you have any bugs to report working with WSJT-X please 
> let me know.
> Would like to promote as many of these to stable as possible and WSJT-X is 
> one of a couple programs that exercises a rig pretty well.
> 
> Mike W9MDB
> 
> 
>   Rig #  MfgModel   Version 
> Status  Macro
>   1003  Yaesu  FT-1000D20200323.0  Beta   
>  RIG_MODEL_FT1000D
>   1005  Yaesu  FT-747GX20200323.0  Beta   
>  RIG_MODEL_FT747
>   1006  Yaesu  FT-757GX20200325.0  Beta   
>  RIG_MODEL_FT757
>   1016  Yaesu  FT-990  20200323.0  Alpha  
>  RIG_MODEL_FT990
>   1017  Yaesu  FRG-100 20160409.0  Beta   
>  RIG_MODEL_FRG100
>   1018  Yaesu  FRG-960020160409.0  
> UntestedRIG_MODEL_FRG9600
>   1019  Yaesu  FRG-880020160409.0  
> UntestedRIG_MODEL_FRG8800
>   1021  Yaesu  FT-100  20200323.0  Beta   
>  RIG_MODEL_FT100
>   1026  Yaesu  VR-5000 20200505.0  Alpha  
>  RIG_MODEL_VR5000
>   1027  Yaesu  FT-450  20200614.0  Beta   
>  RIG_MODEL_FT450
>   1030  Yaesu  FTDX-9000   20200614.0  
> UntestedRIG_MODEL_FT9000
>   1031  Yaesu  FT-980  20200114.0  Alpha  
>  RIG_MODEL_FT980
>   1032  Yaesu  FT-DX5000   20200614.0  Alpha  
>  RIG_MODEL_FTDX5000
>   1033  Vertex StandardVX-1700 20200320.0  Alpha  
>  RIG_MODEL_VX1700
>   1037  Yaesu  FT-DX3000   20200614.0  Beta   
>  RIG_MODEL_FTDX3000
>   1039  Yaesu  FT-600  20200113.0  Beta   
>  RIG_MODEL_FT600
>   1040  Yaesu  FT-DX101D   20200614.0  Beta   
>  RIG_MODEL_FTDX101D
>   2001  KenwoodTS-50S  20200624.0  Alpha  
>  RIG_MODEL_TS50
>   2003  KenwoodTS-450S 20200624.0  Beta   
>  RIG_MODEL_TS450S
>   2005  KenwoodTS-690S 20200624.0  Beta   
>  RIG_MODEL_TS690S
>   2006  KenwoodTS-711  20200624.0  
> UntestedRIG_MODEL_TS711
>   2008  KenwoodTS-811  20200624.0  
> UntestedRIG_MODEL_TS811
>   2009  KenwoodTS-850  20200624.0  Beta   
>  RIG_MODEL_TS850
>   2010  KenwoodTS-870S 20200624.0  Beta   
>  RIG_MODEL_TS870S
>   2011  KenwoodTS-940S 20200624.0  Alpha  
>  RIG_MODEL_TS940
>   2015  KenwoodR-5000  20200407.0  Alpha  
>  RIG_MODEL_R5000
>   2017  KenwoodTH-D7A  20200701.0  Beta   
>  RIG_MODEL_THD7A
>   2019  KenwoodTH-F6A  20200701.0  Beta   
>  RIG_MODEL_THF6A
>   2020  KenwoodTH-F7E  20200701.0  Beta   
>  RIG_MODEL_THF7E
>   2021  Elecraft   K2  20200624.0  Beta   
>  RIG_MODEL_K2
>   2022  KenwoodTS-930  20200624.0  
> UntestedRIG_MODEL_TS930
>   2023  KenwoodTH-G71  20200701.0  Beta   
>  RIG_MODEL_THG71
>   2024  KenwoodTS-680S 20200624.0  Beta   
>  RIG_MODEL_TS680S
>   2025  KenwoodTS-140S 20200624.0  Beta   
>  RIG_MODEL_TS140S
>   2026  KenwoodTM-D700 

Re: [wsjt-devel] Rig verification

[tom]

No issues with the FT100

  1021  Yaesu  FT-100  20200323.0  Beta 
   RIG_MODEL_FT100

Tom

--
73

Tom
GM8MJV (IO85)





> On 16 Jul 2020, at 05:11, Black Michael via wsjt-devel 
>  wrote:
> 
> If anybody has a rig out there that's in this list and you have it working 
> with WSJT-X...or if you have any bugs to report working with WSJT-X please 
> let me know.
> Would like to promote as many of these to stable as possible and WSJT-X is 
> one of a couple programs that exercises a rig pretty well.
> 
> Mike W9MDB
> 
> 
>   Rig #  MfgModel   Version 
> Status  Macro
>   1003  Yaesu  FT-1000D20200323.0  Beta   
>  RIG_MODEL_FT1000D

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

[wsjt-devel] Question about this list

[Tom Schaefer]

I’m newly subscribed so I have a question. 

Many of the messages I have seen in the past few day’s seem related more to 
general support or usability questions rather than development questions.  I 
would have expected those questions to be on the general support group. 

Is there an intended demarcation between these groups or is this another 
support group with some development questions tossed in?

I’m asking so I set my expectations. 

Thanks,

Tom NY4I


Principal Solutions Architect
Better Software Solutions, Inc. 
727-437-2771


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

Re: [wsjt-devel] WSJT-X 2.2.1 GA, Hamlib error with FTdx3000 and Microham II router

[Tom Ramberg via wsjt-devel]

I have done this before for a long time with a FT-1000MP, and I have never had 
any problems. At this particular club we also have a station no. 2, with a 
Yaesu FT-1000 Mark V, and the combo WSJT-X in one of the CAT ports from 
Microham router and N1MM+ on the other works, even the Mark V is not listed in 
WSJT-X choice of radios. I use FT-1000MP, and that works, as far as I can see. 
So it still is a FTdx3000 problem. But as I stated earlier, Im not computer 
savvy enough to understand why.

Latest: I happened, by coincidence, to start WSJT-X first, and then N1MM+, 
today's update, and then it worked! I checked, starting N1MM+ first, then 
WSJT-X provokes the Hamlib error again. 

73 de Tom OH6VDA


> 11. jun. 2020 kl. 15:50 skrev Bill Somerville :
> 
> 
> Mike,
> 
> the microHAM uRouter application provides two sets of virtual serial ports 
> per rig. I have been using this facility with issues for many Years. Proper 
> arbitration of CAT commands is provided. Obviously conflicting commands 
> cannot be reconciled, but control from two applications is reasonable and 
> practical using this application with devices like the micro KEYER 2 and 2R+.
> 
> 73
> Bill
> G4WJS.
> 
> On 11/06/2020 13:05, Black Michael via wsjt-devel wrote:
>> Reading the documentation it's implied and refers to a "control channel".  
>> The thing just does a passthru so I don't know how it could possibly share 
>> the rig with CAT control.  That's likely why he got a bus collision error.  
>> I also can't find a single youtube video of anybody doing CAT control using 
>> two programs.  The 2nd cat port is just for monitoring.
>> 
>> Unless I'm reading the wrong documentation.  Nowhere in the docs does it say 
>> you can have two CAT control channels.  If it did they'd be bragging about 
>> it for sure.  They just don't explicitly state the limitation (should be 
>> obvious to the casual user I'm sure :-)
>> 
>> From https://www.microham.com/Downloads/U2_English_Manual.pdf for example:
>> 
>> The virtual COM port assigned for Control can be shared with CW and/or PTT 
>> but sharing must be specifically supported by the application. Many 
>> applications do not know how to share the radio port with other functions, 
>> use the control lines (RTS, CTS, DTR, DSR) for handshaking, or apply a fixed 
>> level. 
>> 
>> 
>> Mike
>> 
>> 
>> 
>> On Thursday, June 11, 2020, 06:43:56 AM CDT, Bill Somerville 
>>  wrote:
>> 
>> 
>> On 11/06/2020 12:36, Black Michael via wsjt-devel wrote:
>> > You can't have two programs doing CAT control to the MKII at the same 
>> > time.
>> >
>> Mike,
>> 
>> that's not correct. The microHAM uRouter provides two sets of COM ports 
>> per radio.
>> 
>> 
>> 73
>> Bill
>> G4WJS.
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.1 GA, Hamlib error with FTdx3000 and Microham II router

[Tom Ramberg via wsjt-devel]

That is: The radio is connected to the computer via the MKII. The COM ports I 
refer to are all virtual ports created in Microham's router.  As I stated in my 
other response, the aim is to keep it as simple as possible for the new hams in 
my club. They use N1MM+ for genaral logging, and that is simple and it works. 
WSJT-X works great as standalone. If I cannot make the applications cooperate, 
so be it. But there had been a lot of talk of Hamlib errors lately, so that is 
why I raised the issue. I beg to be excused if this is not a WSJT-X issue, but 
rather, as it seems now, a Microkeyer router thing. My computer skills have, I 
am afraid, clear limitations.



73,
Tom OH6VDA

> 11. jun. 2020 kl. 09:10 skrev Tom Ramberg :
> 
> No. That's it.
> 
> 73
> Tom OH6VDA
> Sendt fra min iPad Air 2
> 
>>> 10. jun. 2020 kl. 16:20 skrev Bill Somerville :
>>> 
>> 
>> On 10/06/2020 14:11, Bill Somerville wrote:
>>> On 10/06/2020 14:01, Tom Ramberg wrote: 
>>>> First it happens when I set the Com port In the radio tab WSJT-X settings 
>>>> (in this case COM5) and press the "Test CAT" button. It turns red, and a 
>>>> pop up window appears with the message "Rig Failiure. Hamlib error: I/O 
>>>> error while opening connection to rig". See screenshot. 
>>> 
>>> Hi Tom, 
>>> 
>>> is COM5 really the serial port of your rig,or do you have something else in 
>>> between? 
>>> 
>>> 73 
>>> Bill 
>>> G4WJS.
>> Other than the microHAM uRouter and interface device.
>> 
>> 73
>> Bill
>> G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.1 GA, Hamlib error with FTdx3000 and Microham II router

[Tom Ramberg via wsjt-devel]

No. That's it.

73
Tom OH6VDA
Sendt fra min iPad Air 2

> 10. jun. 2020 kl. 16:20 skrev Bill Somerville :
> 
> 
> On 10/06/2020 14:11, Bill Somerville wrote:
>> On 10/06/2020 14:01, Tom Ramberg wrote: 
>>> First it happens when I set the Com port In the radio tab WSJT-X settings 
>>> (in this case COM5) and press the "Test CAT" button. It turns red, and a 
>>> pop up window appears with the message "Rig Failiure. Hamlib error: I/O 
>>> error while opening connection to rig". See screenshot. 
>> 
>> Hi Tom, 
>> 
>> is COM5 really the serial port of your rig,or do you have something else in 
>> between? 
>> 
>> 73 
>> Bill 
>> G4WJS.
> Other than the microHAM uRouter and interface device.
> 
> 73
> Bill
> G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.1 GA, Hamlib error with FTdx3000 and Microham II router

[Tom Ramberg via wsjt-devel]

The rig is Yaesu FTdx3000 connected with a Microham II keyer. I suppose that is 
what I am trying, yes. And when I disconnect N1MM+, WSJT-X works fine with both 
COM4 and COM5.

The problem is that I am trying to set this up in a club, where most of the 
users are new licencees, and I want to make the setup as uncomplicated as 
possible. Getting rid of the Microkeyer is not an option, I am afraid.

Tom OH6VDA
> 10. jun. 2020 kl. 20:23 skrev Black Michael :
> 
> 
> It sounds like you're trying to do port sharing.  I'm don't believe the 
> microham supports that.  I believe it does support PTT on one com port and 
> CAT on another.  And it can also echo CAT responses to another COM port for 
> monitoring...but not CAT control.
> 
> So if you turn off N1MM and connect WSJT-X to COM4 it all works OK?
> 
> What kind of rig do you have?  There are solutions for having multiple 
> programs (like N1MM and WSJT-X) sharing the rig.
> 
> Mike
> 
> 
> 
> 
> On Wednesday, June 10, 2020, 08:06:38 AM CDT, Tom Ramberg via wsjt-devel 
>  wrote:
> 
> 
> First it happens when I set the Com port In the radio tab WSJT-X settings (in 
> this case COM5) and press the "Test CAT" button. It turns red, and a pop up 
> window appears with the message "Rig Failiure. Hamlib error: I/O error while 
> opening connection to rig". See screenshot.
> 
> 
> If I ignore the message by pressing OK, The button turns green, and if I exit 
> the settings and try to change bands, it seems to work okay. But then on a 
> second try to press the "Test CAT" button, the second error message appears, 
> saing "Hamlib error: Communication bus colision while trying to get the 
> current VFO, se screenshot.
> 
> On CAT1 (in this case COM4), I am connected to N1MM+. 
> 
> I have also tried to use Omnirig, but that just makes WSJT-X crash without 
> any warning messages at all.
> 
> Tom OH6VDA
> 
> > 10. jun. 2020 kl. 12:44 skrev Bill Somerville :
> > 
> > On 10/06/2020 07:45, Tom Ramberg via wsjt-devel wrote:
> >> Starting WSJT-X with FTdx3000 and using 2nd CAT port in MicroHams device 
> >> router gives Hamlib error.
> >> 
> >> de OH6VDA TOM
> > 
> > Hi Tom,
> > 
> > what is the full error message, including details, please? When does it 
> > happen?
> > 
> > 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

[wsjt-devel] WSJT-X 2.2.1 GA, Hamlib error with FTdx3000 and Microham II router

[Tom Ramberg via wsjt-devel]

Starting WSJT-X with FTdx3000 and using 2nd CAT port in MicroHams device router 
gives Hamlib error.

de OH6VDA TOM



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

Re: [wsjt-devel] v2.1.2 Radio On/Off CAT Problem?

[tom]

Hi

Just noticed my Icom IC-9700 does it as well - personally would like this to be 
an option - or a way to turn off the rig when exiting the application that 
started it up.

Tom

--
73

Tom
GM8MJV (IO85)





> On 8 Jun 2020, at 23:48, Bill Somerville  wrote:
> 
> Mike,
> 
> how would calling rig_set_powerstat before calling rig_close stop Hamlib 
> unilaterally turning on some rigs. Also since only a few rigs can be turned 
> on by CAT commands the whole premiss that there is some new assumption that 
> the rig is turned on before Hamlib can do a rig_open is bogus. What's wrong 
> with an error return from rig_open that the application can deal with, 
> including calling rig_set_powerstat if it wants to. Libraries that control 
> hardware should not do things that have not been asked for. At least make 
> this new and unnecessary behaviour optional and controllable by the client 
> that is using the Hamlib library, it's not your job to. Do things that are 
> asked for, making it possible to do such things when asked for by the client 
> is fine.
> 
> 73
> Bill
> G4WJS.
> 
> On 08/06/2020 23:35, Black Michael via wsjt-devel wrote:
>> The assumption now is that if you ask hamlib to open the rig than the rig 
>> must be running...so if it's not turned on a power up is attempted.
>> WSJT-X expects a running rig too.
>> 
>> I had numerous requests for this capability from people running remote 
>> operations.  They didn't seem to have any problems turning their rig off but 
>> they were using rigctl to do it.
>> 
>> The only time this is done is when the rig is opened.
>> 
>> So...if you turn off the rig while WSJT-X is running I guess WSJT-X is 
>> reopening the rig causing the powerup again.
>> 
>> You could put in a powerdown checkbox and just call set_powerstat before you 
>> call rig_close.  That should work.
>> 
>> 
>> Mike W9MDB 
>> 
>> 
>> 
>> 
>> 
>> On Monday, June 8, 2020, 04:44:16 PM CDT, Bill Somerville 
>>  <mailto:g4...@classdesign.com> wrote:
>> 
>> 
>> Mike,
>> 
>> I think you mean "set the frequency".
>> 
>> Any chance of not having Hamlib unilaterally messing with the rig power 
>> on/off. A config option or just don't do it and leave it to the application 
>> to decide if this is appropriate?
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> On 08/06/2020 22:31, Black Michael via wsjt-devel wrote:
>>> Do you have "Monitor returns to last used frequency" turned on?
>>> 
>>> That will cause the rig to wake up as it has to get the frequency.
>>> 
>>> Mike W9MDB
>>> 
>>> 
>>> 
>>> 
>>> On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski  
>>> <mailto:k6...@almont.com> wrote:
>>> 
>>> 
>>> Personally, I do not need/want WSJTx to turn my radio on, or off, when 
>>> starting or closing. But, it is no big problem for me either way and might 
>>> be useful for some. I just thought it odd that WSJTx tries to turn the 
>>> radio on when when it closes and had not noticed it doing either previously.
>>> 
>>> 
>>> Al Pawlowski, K6AVP
>>> Los Osos, CA USA
> 
> ___
> 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] RE : FT-991A config problem

[Tom Pickles]

And I tried loading both the 32 bit and the 64 bit versions from both the 
sourceforge and the WSJT sites.  None of that worked.


From: Bensay 1 
Sent: Sunday, June 7, 2020 4:58 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] RE : FT-991A config problem


Looks like WSJT-X can’t connect at all to the rig,



First guess :



Busy COM port ?

Wrong configuration ?

Did you try to temporarily downgrade to 2.1.2 version and try if it’s work with 
that one ?

https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/



If it’s work with 2.1.2 it’s seem to be a version issue.



If it’s the same it’s another kind of issue.



Benjamin – F4FPR



De : Tom Pickles 
Envoyé : dimanche 7 juin 2020 23:42
À : WSJT software development 
Objet : Re: [wsjt-devel] RE : FT-991A config problem





[cid:image001.png@01D63D27.51F46B80]



From: Bensay 1 mailto:bensam...@hotmail.com>>
Sent: Sunday, June 7, 2020 4:37 PM
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: [wsjt-devel] RE : FT-991A config problem



Dear Tom,



My FT-991 works fine with the 2.2.1 version.



Whats the error message from your side ?



Benjamin – F4FPR



Provenance : Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour 
Windows 10



De : Tom Pickles<mailto:cdr...@hotmail.com>
Envoyé le :dimanche 7 juin 2020 23:36
À : wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Objet :[wsjt-devel] FT-991A config problem



WSJT-X Ver 2.2.1 claimed to have fixed the config problem for the FT-991A.  
Downloaded it and still have the same problem.  Now I can't find the old 
version that worked.

Tom W2PIX


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

Re: [wsjt-devel] RE : FT-991A config problem

[Tom Pickles]

Where can I find the old 1.9 versions so I can go back to that and see if it 
works?


From: Bensay 1 
Sent: Sunday, June 7, 2020 4:58 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] RE : FT-991A config problem


Looks like WSJT-X can’t connect at all to the rig,



First guess :



Busy COM port ?

Wrong configuration ?

Did you try to temporarily downgrade to 2.1.2 version and try if it’s work with 
that one ?

https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/



If it’s work with 2.1.2 it’s seem to be a version issue.



If it’s the same it’s another kind of issue.



Benjamin – F4FPR



De : Tom Pickles 
Envoyé : dimanche 7 juin 2020 23:42
À : WSJT software development 
Objet : Re: [wsjt-devel] RE : FT-991A config problem





[cid:image001.png@01D63D27.51F46B80]



From: Bensay 1 mailto:bensam...@hotmail.com>>
Sent: Sunday, June 7, 2020 4:37 PM
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: [wsjt-devel] RE : FT-991A config problem



Dear Tom,



My FT-991 works fine with the 2.2.1 version.



Whats the error message from your side ?



Benjamin – F4FPR



Provenance : Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour 
Windows 10



De : Tom Pickles<mailto:cdr...@hotmail.com>
Envoyé le :dimanche 7 juin 2020 23:36
À : wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Objet :[wsjt-devel] FT-991A config problem



WSJT-X Ver 2.2.1 claimed to have fixed the config problem for the FT-991A.  
Downloaded it and still have the same problem.  Now I can't find the old 
version that worked.

Tom W2PIX


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

Re: [wsjt-devel] RE : FT-991A config problem

[Tom Pickles]

[cid:be12eb32-aebc-4434-b2b5-0781f2ec8105]

From: Bensay 1 
Sent: Sunday, June 7, 2020 4:37 PM
To: WSJT software development 
Subject: [wsjt-devel] RE : FT-991A config problem


Dear Tom,



My FT-991 works fine with the 2.2.1 version.



Whats the error message from your side ?



Benjamin – F4FPR



Provenance : Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour 
Windows 10



De : Tom Pickles<mailto:cdr...@hotmail.com>
Envoyé le :dimanche 7 juin 2020 23:36
À : wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Objet :[wsjt-devel] FT-991A config problem



WSJT-X Ver 2.2.1 claimed to have fixed the config problem for the FT-991A.  
Downloaded it and still have the same problem.  Now I can't find the old 
version that worked.

Tom W2PIX


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

[wsjt-devel] FT-991A config problem

[Tom Pickles]

WSJT-X Ver 2.2.1 claimed to have fixed the config problem for the FT-991A.  
Downloaded it and still have the same problem.  Now I can't find the old 
version that worked.
Tom W2PIX
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] 2.2 RC Bugs

[Tom Melvin]

Windows 7 Pro, 64bit binary

If the a list anywhere of found/fixed defects in rc1?

I have been having problems with VERY slow (15sec) start up or in some case 
will not start due to rogue wsjtx.exe showing as running via task manager.

If been resolved great, if not can spend some time documenting it - if there 
was a visible list could check.

Would rather not do the work and get a response ‘ Yes known defect - fixed in 
next rc’  after spending time on it :-)


Regards

Tom

--
73

Tom
GM8MJV (IO85)





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

Re: [wsjt-devel] WSJT-X Bug?

[Tom Stock]

Please disregard previous bug report

Turns out I had a wonky USB hub.  I think the error handling must be a bit
more robust in the windows version, because the windows version in a
virtual box on my Mac gave me no problems at all. Running the native
version resulted in the original issues reported (on the same computer).

But, replacing the USB hub resolved the problem and now it works fine Mac
native.

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

[wsjt-devel] WSJT-X Bug?

[Tom Stock]

Hello,

I'm having a problem with version 2.1.2 68f9

Problem:

When in transmit mode, WSJT-X will suddenly switch from my usb codec for
output (my signalink usb) to the speakers. I can hear the transmission, and
the transmitter stops transmitting.  If I look in Preferences->Audio both
usb codecs are still selected. The only fix is to restart the program.

I initially suspected this was RF, however I disconnected my radio from my
signalink USB so that I am NOT transmitting and it still happens on the
third transmission every single time.

MacOS 10.13.6 (High Sierra)
WSJT-X 2.1.2 68f9
Macbook Pro 2011, Core i7 16GB ram - SSD HD
Signalink USB

1) Start WSJTX
2) Preferences-Audio. Select USB CODEC for input and output (signalink)
3) Choose CQ (TX 6) and select transmit.
4) On third transmit, signalink will drop PTT and audio will come from
speakers

I tried to recreate the problem with FLDIGI and was unsuccessful.

I've actually had this problem happen a few years ago on
a different MacBook so it does not seem to be new, just worse for me than
before.

I'll try running it in a windows virtual box to rule out any hardware
problems.

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

Re: [wsjt-devel] LF/MF possible new mode ?

[Tom Melvin]

This was asked over on the main WSJT mailing list just recently, there may be 
more details on that thread.

https://groups.io/g/WSJTX/message/6596

--
73’s

Tom
GM8MJV (IO85)





On 23 Feb 2020, at 12:35, Trevor Smithers  wrote:

> Back last August/September there was a brief post about a new
> WSJT mode in the early stages of development by K1JT and K9AN designed
> specifically for 136kHz, 472KHz and 160.
> 
> I thought it was to be based on JT65 (but it might have been JT9) and was
> hoped to be far more sensitive at the designated frequencies than current
> offerings.
> 
> Is this still under consideration ?
> 
> Trevor  G0KTN
> 
> 
> 
> ___
> 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] Crash in VHF-contest

[Tom Melvin]

Jari

What version of wsjt-X?, what were you doing at the time? - ft8 / ft4?

Will need a little more info rather than just the generic windows error.

Any wsjt error messages?

Tom

--
73’s

Tom
GM8MJV (IO85)





On 7 Jan 2020, at 20:11, Jari A  wrote:

> Problem signature:
>   Problem Event Name: APPCRASH
>   Application Name:   wsjtx.exe
>   Application Version:0.0.0.0
>   Application Timestamp:  5ddd4628
>   Fault Module Name:  ntdll.dll
>   Fault Module Version:   6.1.7601.24540
>   Fault Module Timestamp: 5ddf3f5f
>   Exception Code: c005
>   Exception Offset:   0002a365
>   OS Version: 6.1.7601.2.1.0.256.48
>   Locale ID:  1035
>   Additional Information 1:   b3a6
>   Additional Information 2:   b3a6807104b0408d3ac9b2061e15658a
>   Additional Information 3:   b01e
>   Additional Information 4:   b01e84fe8ed63eafb83277969ae99739
> 
> Win 7 pro, 64bit
> 
> Rgds,
> 
> : Jari / oh2fqv
> ___
> 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] Omnirig 2.0 support

[Tom Ramberg via wsjt-devel]

OK. Thanks a lot for the clarification, Bill. And by the way, thank you for 
your excellent support. Let me extend my wishes for a peaceful and merry 
Christmas to you and the rest of the development team!

Tom OH6VDA

> 26. des. 2019 kl. 15:05 skrev Bill Somerville :
> 
> On 25/12/2019 17:57, Tom Ramberg via wsjt-devel wrote:
>> Does WSJT-X support Omnirig 2.0?
>> 
>> Tom OH6VDA
> 
> Hi Tom,
> 
> the first two rigs are supported by the existing Omni-Rig support in WSJT-X. 
> It is unlikely that full support for all four rigs will be added for the 
> following reasons:
> 
> 1) The Omni-Rig v2 project appears to have been abandoned,
> 
> 2) The project source code is not in the public domain, this would appear to 
> be in violation of Alex, VE3ANA's, original Omni-Rig licence,
> 
> 3) The Omni-Rig v2 executable does not contain the correct type library and 
> this is required by the WSJT-X project to access the interface for the third 
> and forth rigs.
> 
> 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

[wsjt-devel] Omnirig 2.0 support

[Tom Ramberg via wsjt-devel]

Does WSJT-X support Omnirig 2.0?

Tom OH6VDA




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

Re: [wsjt-devel] Split mode settings

[Tom Ramberg via wsjt-devel]

Hi Claude!
I have used this way of doing it with FT1000MP, FT1000MP MarkV and FTdx3000 
operating as JW6VDA, and a similar setup also works with my IC7300 from my home 
station, OH6VDA. Originally I was put on the right track by Michael 5P1KZS. 

To operate SPLIT (to work JA) on 160 meters:
In WSJT-X set freq. to 1,908 Mhz - will set ur VFO A to 1,908. Set your VFO B 
to 1.840 Mhz. 
(Look at the manual to see how operate FT-1000MP, FTdx3000 or IC7300 in 
"SPLIT-FREQUENCY OPERATION" - set it up to TX on VFO B and RX on A.) 
In that way WSJT-X thinks it's tx' ing on 1908. 
Don't mark the "Split setting" in WSJT-X as RIG or FAKE. Mark as "None" in 
settings. 
Make sure that your TX VFO is set to USB or USB-D.

You will only see the signals on 1908 on your waterfall, so check before TXing 
and from time to time later how your signal is placed. Choose your audio offset 
to be between 1500Hz and 2500Hz to ensure your outsignal is in your 
transmitter's "sweet spot".

I usually call CQ JA or CQ 908. It seems to work OK.

73 Tom OH6VDA / JW6VDA


> 23. des. 2019 kl. 12:53 skrev Bill Somerville :
> 
> On 23/12/2019 10:37, Claude Frantz wrote:
>> Hi all,
>> 
>> Please allow me to ask about the split mode in the sense of a necessity 
>> resulting from different frequency assignments in different countries, i.e. 
>> a sort of special form of multi-band operation. The typical situation is the 
>> QSO between a Japanese station and a station in Region 1.
>> 
>> What is the recommanded setting in WSJT-X in order to operate under such 
>> conditions while maintaining the "special" split at the TX side in order to 
>> have the audio between 1.5 and 2 kHz ?
>> 
>> Best wishes,
>> Claude (DJ0OT) 
> 
> Hi Claude,
> 
> supporting "legacy" split mode in WSJT-X would require a large enhancement. 
> For example some scheme that allowed each working frequency to have an 
> optional independent transmit frequency. I suspect the requirement does not 
> justify the amount of work as few bands and regions suffer these 
> non-compatible frequency allocations. On top band I doubt there are enough 
> stations active with good enough receiving station aerials to take advantage, 
> such that a wide bandwidth slot would be required. Because of that a manual 
> solution is probably the best. You can create a new configuration and in that 
> set "Settings->Radio->Rig->None". You may need to do some work to get PTT 
> working in that configuration if you currently use CAT PTT. Once the new 
> configuration is selected you can manually tune your rig's split Rx and Tx 
> frequencies just like you would in other modes, be sure to pick a Tx VFO dial 
> frequency that allows you to use an audio offset between 1500 Hz and 2500 Hz.
> 
> I believe the regulators in Japan are addressing the incompatibilities with 
> other regions on 160m.
> 
> 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

Re: [wsjt-devel] USB-D on VFOB

[Tom Ramberg via wsjt-devel]

FWIW, I've had some problems lately with Omnirig 1.19, WSJT-X 2.1.2 and 
Swisslogforwindows. The radio is a FT-1000MP. Using "fake it", the radio did 
not return to the listening frequency on VFO A, but stayed on the Tx frequency. 
Trying a fallback to Omnirig 1.16 and 1.18 did not solve the problem. Using 
"Rig split" did, except for one thing: If the VFO B mode was anything other 
than USB, the mode was not changed when going to Tx. I had to change that to 
USB manually. But then it was problem solved.

Tom OH6VDA

> 19. des. 2019 kl. 12:55 skrev Claude Frantz :
> 
> On 12/18/19 1:24 PM, Black Michael via wsjt-devel wrote:
> 
>> The only reason you would HAVE to run Mode=Rig Split on WSJT-X is if
>> your rig doesn't behave well on Fake It.Generally speaking rigs will
>> behave a bit better in Rig Split.
> Sometimes, Split=FakeIt works better than Split=Rig. We have to examine the 
> situation case by case.
> 
> Best wishes,
> Claude (DJ0OT)
> 
> 
> ___
> 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] Callsign lockout

[Tom Melvin]

Just another view on this - last night there was a UK contest - despite it 
being a ‘Normal’ mode contest a pile of people were using ‘EU Contest mode’. 
What was noticeable, yes WSJT switched modes to follow but in many cases while 
switching you ‘lost’ the report.

While the system went on to sent RR73 etc. and log the contact - it was not 
complete - so stations had to call again.  If there was yet another option to 
remember to switch off/on and both ends needing to recognise the need if one 
was ‘hidden’ 

Nope sorry leave it up to the operator.

Tom

P.S.   I could see on a QUIET band there would be benefit of suppressing the 
odd local - glance at screen if activity cool band opening work the band - the 
local 5 miles away (running in robot mode) makes it not that easy. Thankfully 
JTAlert can limit by distance but that is Windows only.  You would need to make 
sure the entries fully supported ‘wildcards’.

--
73’s

Tom
GM8MJV (IO85)





On 4 Dec 2019, at 05:37, Black Michael via wsjt-devel 
 wrote:

> It's not a lockout file.
> 
> The idea is very simple.
> 
> Right now call first always picks the 1st decode...ergo the problem
> 
> So the idea is that once a call is worked it gets put in a list (doesn't 
> matter whether or not you log it).  The call first logic checks the list and 
> ignores anybody in it.
> If call first does not trigger then the 1st entry that was detected would be 
> used.
> So it would all be completely transparent, only temporarily blocks calls, and 
> clears itself.
> 
> If you have 5 people calling you it will go 1,2,3,4,5 and start over again 
> whereas right now it's 1,1,1,1,1, ad nauseum.
> 
> For the most part nobody would even notice this was happening except the 1st 
> decode may not be the one chosen.
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Tuesday, December 3, 2019, 11:28:30 PM CST, Jim Brown 
>  wrote:
> 
> 
> W9MDB wrote:
> 
> > I'm all ears for opinions from operators who have had a call pileup on them.
> 
> I've been a ham since 1955, General in '56, Extra '59. I've always been 
> primarily a CW op, mostly contesting and chasing DX. I've been the guy 
> on the DX end of pileups working CW in a major contest, no split 
> operation. I also work RTTY contests as part of a club that often wins 
> them. So far, I've not gotten interested in FT4/FT8 contesting on HF.
> 
> I'm near San Francisco and have a very good station. I use FT8 
> extensively on 160M during the winter to work EU, and both FT8 and 
> MSK144 on 6M chasing grids. I rarely call CQ, mostly tail-ending 
> stations I want to work, just as Dave does. That's smart operating.
> 
> The craziest I've seen FT8 is when 6M is open to JA, often with 
> JTAlert's 4x9 display nearly full of decodes. By far the best way to 
> work it is to call CQ with Call First off, Auto Seq on, Hold TX Freq on, 
> and pick the station I want to respond to.
> 
> As to this lockout thing -- IMO, the nuisance calls come from new folks 
> who have little HF experience, have massive receive noise, and never 
> realize the band is open for DX, only look at JTAlert, and are calling 
> the only signals strong enough to get through their noise. A library of 
> lockout calls is quite unlikely to work, because it's different new 
> folks every time! Indeed, those JA openings are almost the only time I 
> call CQ, and for that reason! The only folks I want calling me are the 
> DX I want to work, and I don't want guys who can't hear or don't have a 
> clue covering them up!
> 
> 73, Jim K9YC
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Ramberg via wsjt-devel]

Fred, I see no bitching here, just friendy questions and mostly very polite 
answers.

73 de Tom OH6VDA (occasionally semi-rare JW6VDA)

Sendt fra min iPad Air 2

> 20. nov. 2019 kl. 13:34 skrev Fred Price :
> 
> 
> Ya know if you so much want this why not open your computer and reprogram the 
> interface yourself?
> What's it take 30 seconds to open settings or change a config? Is the DX 
> going to disappear in that time?
> I guess everyone forgot about when the NA contest mode had a check box on the 
> GUI. So many wondered why they were in contest mode because they mistakingly 
> checked the box.
> Most like the dev group has a lot more to do then move a check box. I'd bet 
> they have life's outside of ham radio as well. I think the dev group does a 
> helluva job. Just one last thing, how can anybody bitch about free software
> 
> On Nov 19, 2019 7:25 PM, David Gilbert  wrote:
> 
> If anyone was seriously concerned about real estate usage in the WSJT-X 
> user window there wouldn't be all that wasted space in the lower left 
> corner for any of the modes.  The Frequency display doesn't need to be 
> anywhere near that large, DX Call and DX Grid is mostly superfluous, the 
> size of the Date/Time box is ridiculous ...   and all of that could be 
> resized and repositioned under the Auto Seq and Call 1st buttons.
> 
> All of which has been brought up before.
> 
> Dave   AB7E
> 
> On 11/19/2019 2:36 PM, Grant VK5GR wrote:
> > Joe,
> >
> > As for the band activity window - yes screen realestate is cluttered as it
> > stands - but not being able to see the band activity is an extremely serious
> > problem on the air. The "workarounds" proposed are just that - workarounds.
> > Not all Fox operators will be that savvy (although I wish I had thought of
> > the tail ALL.TXT idea out on the island).
> >
> > Regards,
> > Grant
> >
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Melvin]

Dave

There is not a lot of space under the 'Auto Seq' box - I will agree date and 
time could be smaller - but disagree as to the DX Call/Grid  - they need to be 
easily seen/entered for distance/Bearing - my eyes are not quite what the were 
a few years back and with all the different frequencies in use I really do need 
to see that easily at a glance.

See attached if it made it through



--
73’s

Tom
GM8MJV (IO85)





On 20 Nov 2019, at 00:25, David Gilbert  wrote:

> 
> If anyone was seriously concerned about real estate usage in the WSJT-X user 
> window there wouldn't be all that wasted space in the lower left corner for 
> any of the modes.  The Frequency display doesn't need to be anywhere near 
> that large, DX Call and DX Grid is mostly superfluous, the size of the 
> Date/Time box is ridiculous ...   and all of that could be resized and 
> repositioned under the Auto Seq and Call 1st buttons.
> 
> All of which has been brought up before.
> 
> Dave   AB7E
> 
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Ramberg via wsjt-devel]

Hello Joe, thanks for the info. Awaiting 2.1.1 then! 

73 de Tom, sporadically JW6VDA



Sendt fra min iPhone

> 18. nov. 2019 kl. 19:18 skrev Joe Taylor :
> 
> Hi Grant and all,
> 
> Thanks for reporting the bug in WSJT-X v2.1.0 that causes *Tx Enable* to be 
> turned off when Fox sends RR73.  We knew about this issue and corrected it 
> several months ago, back in August, but -- having received no complaints from 
> users -- we have been waiting to issue a bug-fix release until several other 
> issues are resolved.
> 
> We will schedule a release of WSJT-X v2.1.1 soon.
> 
> Your other request, to have standard "Band Activity" displayed when in Fox 
> mode, will not be addressed in v2.1.1.  Code for Fox mode is based on an 
> understanding that you (the Fox) will have a well-advertised band segment to 
> yourself.
> 
> Have you tried simply running a second instance of WSJT-X, in normal mode, so 
> that you can monitor what's going on in a difficult situation?
> 
>-- 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] Adding "MY_RIG" info to the ADIF file when logging a QSO

[Tom Ramberg via wsjt-devel]

Isn't the need for tracking which operator is on in a multiop stuation covered 
by "OPERATOR"?

73 de Tom OH6VDA

> 18. nov. 2019 kl. 14:43 skrev runninge...@gmail.com:
> 
> Is there any interest for adding a new "My rig" (+ retain tickbox) in the
> Log QSO panel ?
> 
> This information could then be written to the wsjtx_log.adi file and
> propagated to JTAlert ...
> 
> I find it very useful to keep track of the transceiver which was used to
> make the QSO. 
> This could also be helpful for multi-station operations like expeditions,
> contests, .. where operators would like to keep track of their individual
> station's traffic ..
> 
> If there is sufficient appetite for this feature, maybe considering this for
> a future release ?
> 
> Thanks and 73's,
> Erik
> ON4PB
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement

[Tom Ramberg via wsjt-devel]

Frode, I had to re-read your Norwegian ranslation of the maual after reading 
your mail, so that's the reason for replying late. In that manual, I cannot see 
that the need for enabling TX after every RR73 is mentioned at all. Please tell 
me if there is a point here that I have overlooked.

I tried FOX (WSJT-X, 2.1.0) on my last trip to Svalbard. I see you are 
emphasising the "rare DX"here, and JW is hardly rare, even though the pileups, 
and thus demand, can be really big if conditions are there. I have never seen a 
definitien of "really rare", so if you suggest above a specific rating on the 
most wanted list, I find it hard to follow you. IMHO, "rare" is decided by the 
demand, and not a list position.  And I have a pileup when the right pane is 
completely red, and my own yellow TX line is scrolled up out of the window. So 
I took the chance, qsyed down from 7074 and started as FOX. I had the exact 
same experience as Rich describes. It was the same fun as running a pileup in 
any mode, I can tell you.

Now, on an earlier trip to JW-land, in March 2019, I did the same, but with v 
2.0.1 (I don't remember which RC#), and then I could "fill the queue", and TX 
did not stop as long as there were calls in the box. Wether this was 
intentional or not from the dev team I do not know, but operating as FOX, I 
thought it was great. I can assure you there was no unattended operation there! 
Since there is a limit to how "old" a call from a hound can be before it falls 
out of the que, you have to watch the queue constantly, keep in mind how many 
streams you want to operate - an important decision when the number of callers 
with weak signals are big - and keep the queue alive. By the way, I also think 
I had activated automatic logging (like in contest mode), but it is possible 
that my memory does not serve me right on that one.

Back to v 2.1.0 in October 2019, I expected the same behaviour, and lost 
several TX cycles because I was unprepared for the necessity to arm the tx 
button for every RR73 I sent. With  few repeats, and mostly operating 1 to 3 
streamsI was able to maintain  a qso rate of about 100/h. Without the lost TX 
cycles, it could have been - albeit slightly - higher.

So again, I support Rich's view. The need to push TX for every RR73 is not 
nesessary. The 15 seconds you have from the end of one TX cycle to the next are 
not hard to fill with chores.



73 de Tom - from time to time JW6VDA

Sendt fra min iPad Air 2

> 18. nov. 2019 kl. 12:48 skrev Frode Igland :
> 
> 
> As I read Rich's message in digest format, a response may already be given, 
> so my apologies if I repeat a previous reply. 
> 
> It seems like the check box under Settings - General - "Disable Tx after 
> sending 73" repeatedly creates some confusion. The mouse-over help text 
> describes exactly what checking this box does: "Turns off automatic 
> transmission after sending 73 or any other free text message". Nothing more 
> is implied, and specifically this does not mean that unchecking (the default 
> state) it enables automatic transmissions after sending 73. The opposite, or 
> the antithethical interpretation if you like, just does not apply, nor does 
> the mouse-over help text indicate that it applies. Specifically, unchecking 
> this box is no workaround to automatically create a red "Enable TX" button 
> again after sending 73. That would possibly create an FT8 QSO robot enabling 
> operations with no operator in attendance/control, which is illegal in many 
> (most/almost all?) countries. 
> 
> WSJT-X includes considerably more demanding modes than FT8, e.g. meteor 
> modes, where repeating the message after sending 73 may be required to 
> complete a QSO and is normal until a return 73 has been received. However, 
> sometimes the conditions are good even for these modes, and then it may be 
> desirable to not transmit again after sending 73. That is a case when you 
> check the box "Disable Tx after sending 73". For FT8 the general disabling of 
> "Enable TX" after sending your 73 is desired actions and cannot overridden in 
> standard WSJT-X, which has not prevented operators from creating robots.
> 
> Having not worked as a Fox, I am not in a position to jugde whether clicking 
> the "Enable TX" button is a sufficient PITA to enable DXpedition QSO robots. 
> However, even for expeditions to very rare DXCC entities (for which FT8 
> DXpedition mode is created), the requirement for a control operator applies. 
> Unattended FT8 QSO robots are no more legal in exotic places than other 
> places. I understand the clicking inconvenience, but as far as I understand, 
> all other modes used by DXpeditions require the operator to key the 
> transmitter for each exchange in a QSO, either by stepping

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Ramberg via wsjt-devel]

For what it’s worth: I support Grant’s request, specially regarding the 
required need to hit “enable tx” almost constantly. 

Tom JW6VDA 


Sendt fra min iPhone

> 17. nov. 2019 kl. 06:30 skrev Grant VK5GR :
> 
> Folks,
>  
> Having returned home a few weeks ago from conducting the A35JT DXpedition to 
> the south Pacific, there are a number of things in FT8 fox mode that I feel 
> need urgent attention for future expeditions. Some of these are on the 
> critical list and some are workflow and control things that I will discuss at 
> a later date.
>  
> The two items on the critical list that I would encourage the team to quickly 
> address for the sake of current and near future expeditions are as follows:
>  
> 1.   There is a need to restore visibility of the band activity window 
> when you are in FOX operator mode (not hound mode). Right now, a classic 
> example of why FOX operators need access to this window is playing out of 
> 21091. Both YJ0FWA and TX7T are on 21091. As a FOX operator I am pretty sure 
> they have no idea that they are co channel. When you are in FOX mode, you 
> have no access to the band activity window and so cant see if someone else 
> starts up on the same frequency as you.
>  
> When I was in Tonga this was a problem too with 3 other major expeditions 
> running at the same time as A35JT. (it also drove us down to 14067 at times 
> to get away from all of the other activity with FT4 on 080, A82X on 084, ZK3A 
> on 090 and then not wanting to clobber the beacons on 100 or WSPR on 097 or 
> the ALE/Automated  stations above 100).
>  
> So can I please urgently request the development team consider re-instating 
> visibility of the Band Activity window as a high priority so that we can stop 
> having blind fox operators not knowing they are suddenly sharing the channel? 
> (consider that expedition operators do NOT always have access to Internet or 
> clusters to receive other warnings either).
>  
> 2.   Secondly, and this was a MOST frustrating aspect of using the 
> software. No matter what we did we couldn’t seem to find any settings that 
> would stop the “Enable TX” button from being cancelled every time the FOX 
> sent RR73 on any channel. Now it appears as though this is by design although 
> I hope it is in fact a bug. Our view is that if the FOX operator had made the 
> deliberate effort to load a station into the calling queue then the enable TX 
> button should remain active until the last station leaves the calling queue.
>  
> The old 2.0.1 version did work like this when unchecked the “stop 
> transmitting on RR73” option in settings - but had too many other problems 
> with logging to be usable. 2.1.0 however does not work the same way – and 
> even when that setting is unchecked it still stops transmitting whenever an 
> RR73 is sent regardless of the progression state of any other channels that 
> are active mid QSO at the time. The RR73 TX disable appears to work as an OR 
> function (when any channel sends RR73 shut down the TX) where it really needs 
> to be an AND function (when all channels have either sent their RR73 or have 
> timed out due to retries and have nothing more to send).
>  
> The impact of this is that as a FOX operator you are having to hit TX Enable 
> constantly particularly when multiple channels are running, in particular so 
> that you don’t break in progress QSOs that are not at RR73 stage on the other 
> channels. At night when our operator count was low (we had to sleep at some 
> stage), we would have one operator sitting in front of three transmitters VNC 
> networked to a common terminal running 3 band synchronous FT8 fox mode to 
> maintain a presence on the bands. He found that he was constantly hitting 
> enable in all three instances of WSJT – an activity that patently didn’t add 
> value to a QSO’s progression where it would have been better to spend more 
> time watching queue progression and managing sub-channel count to try to 
> increase the success of each QSO in progress.
>  
> For the developer’s consideration please?
>  
> Best Regards,
> Grant VK5GR – A35JT DXpedition Team Leader + E6AG, YJ0AG
>  
> Email: vk5gr.ra...@gmail.com
> Website: https://vk5gr-iota.net/
>  
>  
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsprnet abandoned

[Tom M0LTE]

It would be awesome if the subdomain all the spots get submitted to was
redirected to some community-funded broker server, and some kind of pub-sub
messaging set up for subscribers to be able to consume the data in
real-time, on a par with the wsprnet.org site. Spots could still get
proxied to the existing site. That would really help open the dataset up to
deeper real-time analysis, which is extremely valuable data for the amateur
radio community.

Tom M0LTE

On Tue, 15 Oct 2019 at 04:42, Eric NO3M  wrote:

> Onno
>
> My frustration is specifically with the seeming unwillingness of the admin
> team to recognize the serious system issues that have plagued the site for
> the last two years (at least).  If this assumption is inaccurate, then my
> apologies, as it is based on the comments made by the admin that posted to
> this list and taken as the position of the rest of the admin staff.
>
> Countless offers for help have been made by individuals, either in
> expertise/time or monetary.  It seems at this point a fresh perspective and
> solution is warranted, as the status quo and temporary band-aides that have
> been performed in recent times only alleviates the issues for a short
> period of time.
>
> The rest of my Email just stated observational facts.  At the end of the
> day, I could care less if the site works or not, I still have my own spots
> in the locally running WSJTx to utilize as needed.  But other folks use the
> mass collected data for many purposes and it's become more difficult to
> interact with and acquire that data and parts of the site.
>
> Also, this has nothing to do with the map
>
>
> 73 Eric
>
>
>
> On 10/14/19 10:39 PM, Onno Benschop wrote:
>
> Eric, the frustration in your email is visceral and leads me to one
> question:
>
> When did you last pay for an SLA in relation to wsprnet?
>
>
> --
> finger painting on glass is an inexact art - apologies for any errors in
> this scra^Hibble
>
> ()/)/)() ..ASCII for Onno..
>
> On Tue., 15 Oct. 2019, 08:37 Eric NO3M,  wrote:
>
>> This kind of ignorant response is frankly infuriating and in itself shows
>> why wsprnet.org is going to hell to put it kindly
>>
>> I am very active in the LF/MF community and WSPR is heavily used for
>> propagation studies, realtime band opening indication, etc.  Ask anyone in
>> at least the US and VK LF/MF community what they think of wsprnet.org...
>>
>> There are definitely spots that never make their way to the database,
>> numerous in fact.  The poor system performance is a recurring topic in the
>> LF/MF chat group.  Almost nightly someone complains about slow response or
>> that the database part of the site just simply will not load.  You can't
>> definitively say all spots are being imported into the database... from the
>> site's vantage point there is no way of knowing what is missed due to the
>> site being unreachable when those lost spots are coming in.
>>
>> The "database" part of the site is very often extremely slow to load or
>> never loads at all.  Eventually, without fail, on a daily basis, the page
>> will fail to load when left open in a browser tab when it attempts to auto
>> refresh.
>>
>> I understand you are not part of the technical team, but perhaps the ones
>> responsible can be given the message loud and clear and not continue to
>> assume all is fine.  The site (specifically the database infrastructure)
>> needs serious intervention.  The folks that are responsible for maintaining
>> the site's functional integrity have failed miserably.  Time to step up or
>> pass the responsibility on to a competent team.
>>
>> 73 Eric NO3M
>>
>>
>>
>>
>>
>> On 10/14/19 3:45 PM, Erwin Serle via wsjt-devel wrote:
>>
>> Not sure why you come to these conclusions, the website is not slow, it
>> is not abandoned and the spots enter the database nicely.
>>
>> The map issue is explained in the wsprnet org forum with the appropriate
>> solution as well.
>>
>> Users are managed steadily albeit sometimes slowly as I am probably the
>> only user admin doing any work on it at all most of the time.
>>
>> The other admins focus on keeping the site itself up and running and
>> solving the more technical issues.
>>
>>
>> Happy to give more insight if needed:
>>
>> Erwin,
>>
>> PE3ES/F4VTQ
>>
>>
>> On Thu, Oct 10, 2019 at 4:59 AM Benjamin Bänziger 
>> wrote:
>>
>> Hi,
>>
>> This is probably not the right place for this issue, but all other
>> options didn't get attention unfortunately.
>>
&g

Re: [wsjt-devel] F/H stops calling after 5 cycles

[Tom Ramberg via wsjt-devel]

I believe this is intentional and is mentioned in point 11 under the "detailed 
instructions for hounds" in this document: 
https://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf

73 de Tom OH6VDA



> 8. okt. 2019 kl. 08:45 skrev K2DBK-WSJT :
> 
> 
> I’ve noticed that in F/H mode after I call 5 times Enable Tx will turn off, 
> similar to what happens in non F/H mode when the Tx watchdog expires. 
> However, unlike in that case, there’s no red indicator in the lower left 
> corner, it just stops sending. I’ve confirmed that my watchdog timer is set 
> higher than that (just in case) and it’s set to 6 minutes. The number of 
> cycles seems to be consistent, and I’ve got no issue in other modes, ruling 
> out something like RF causing an issue. I’ve looked through the documentation 
> and couldn’t find any reference to maximum number of calls before it will 
> stop on its own.  I’m not transmitting on top of the Fox, I’ve seen this both 
> with and without “Rx All Freqs” set. One thing I’ve noticed is that just 
> before Enable Tx turns off, the Decode button will flicker very briefly, 
> something I don’t see at any other time. Also, even though it seems to be on 
> the 5th transmit cycle, it looks like sometimes the Enable Tx button will 
> turn off just as a transmission is starting, and sometimes immediately after 
> it’s finished. I’m baffled.
>  
> I’m running v2.1.0 on Windows 10 1903 build 18362. I’ve got Save All checked 
> in case those files would be of any use in diagnosing this.
>  
> 73,
> David, K2DBK
> ___
> 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] State QSO Parties

[Tom Melvin]

>> For non-US QSO parties, similar techniques might work. Consider a QSO party 
>> with the counties of England, Ireland, Scotland, and Wales as the activated 
>> counties. :-)

For RSGB it’s between 2 to 8 characters along with the obligatory signal report 
’59’  :-)

As has been pointed out it’s payload size - suspect will have to wait till the 
next major release FT9? (or FT10, FT11 ….) 

It’s not a simple task even if limited to USA.

Tom

73’s

Tom
GM8MJV (IO85)





On 26 Sep 2019, at 01:12, Bill Frantz  wrote:

> On 9/25/19 at 3:52 PM, g4...@classdesign.com (Bill Somerville) wrote:
> 
>> On 25/09/2019 23:42, Bill Somerville wrote:
>>> whereas the index into a table of 64 values (48 states + 14 provinces + DC 
>>> + DX) takes a mere 7 bits to store.
> 
> This is actually an interesting problem. We can divide the contesters into 
> those activating the counties and those trying to contact them. The worst 
> case I've heard is 252 Texas counties, but the 7QP will also have a big 
> number.
> 
> One other problem is that some of the state QSO parties take place on the 
> same weekend, and of course, some people try to make contacts in more than 
> one QSO party. If the sum of all counties involved is small enough, it might 
> be possible to support this behavior.
> 
> Lets assume: For the US state QSO parties, each station only activates 
> counties in one QSO party. (We do need to support rovers.) It will need to 
> receive locations from all the counties in that QSO party + the other 
> states/provinces. People sending to it will need to know which table it is 
> using.
> 
> We can select the table by the weekend data, and starting week before for 
> testing. There might also be a UI affordance which allows manual selection 
> for use in closed group testing. (For such testing, I suggest ditching the 
> radios and just using the built-in audio of several computers in the same 
> room.)
> 
> For non-US QSO parties, similar techniques might work. Consider a QSO party 
> with the counties of England, Ireland, Scotland, and Wales as the activated 
> counties. :-)
> 
> 73 Bill AE6JV
> 
> ---
> Bill Frantz| When all else fails: Voice   | Periwinkle
> (408)356-8506  | and CW.  | 16345 Englewood Ave
> www.pwpconsult.com |  | Los Gatos, CA 95032
> 
> 
> 
> ___
> 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] State QSO Parties

[Tom Melvin]

And for QSO parties that are NOT in the USA?

RSGB has a couple they introduced this year - doesn’t support FT? yet but it 
will come.

Pretty sure the abbreviations used for USA states will not match up with other 
countries.  The developers, if they are going to support QSO parties, will be 
looking at the global picture.

Tom

--
73’s

Tom
GM8MJV (IO85)





On 25 Sep 2019, at 22:19, Ron WV4P  wrote:

> As a coordinator for the Tennessee QSO Party we fielded the same questions 
> and had to respond the same. MANY wanted to use FT-X Modes. In kind, I don't 
> think TN would be any issue swapping to 3 Letter. Ron, WV4P 
> 
> On Wed, 25 Sep 2019 at 16:08, John Zantek  wrote:
> AKA "All I want for Christmas is something big for WSJT-X 2.2"
> 
> I just finished the 2019 Washington Salmon Run (our state QSO party), both as 
> a contestant and a coordinator.  My DX Club sponsors the event.  See 
> www.wwdxc.org/salmonrun
> 
> This year, we were inundated with inquiries of "Can we use FT8 or FT4?", all 
> of which I had to answer "No, sorry, not this year".  I see Nebraska 
> supported WSJT-X for their QSO party, but it required a totally separate log. 
>  Our Board felt the Salmon Run is too big and popular to create a whole 
> separate category and scoring system, and I didn't want to see the use of 
> FreeMsg frames being blasted blindly into the ether with unacknowledged 
> County exchanges.  I felt it was just abusive and counter to the vision of 
> WSJT-X's smart design.
> 
> I do believe that adding direct support to all the State QSO Parties could be 
> the 'next big thing' for WSJT-X.  Adding FD last year was a step in that 
> direction.  So rather than just ask, I thought "well, what would it require?"
> 
> CQ WAQP W7CD CN87
>W7CD K7ABC SPO(Spokane County)
> K7ABC W7CD R KITS   (Kitsap County)
>W7CD K7ABC RR73
> 
> Thus, I submit a blind start:
> 
> //  QRegExp message_alphabet {"[- A-Za-z0-9+./?]*"};
>   QRegularExpression message_alphabet {"[- @A-Za-z0-9+./?#<>]*"};
>   QRegularExpression WA_QSO_party_exchange {
> R"(
> (
>AL|AZ|AR|CA|CO|CT|DE|FL|GA  # 48 contiguous states
>   |ID|IL|IN|IA|KS|KY|LA|ME|MD
>   |MA|MI|MN|MS|MO|MT|NE|NV|NH|NJ
>   |NM|NY|NC|ND|OH|OK|OR|PA|RI|SC
>   |SD|TN|TX|UT|VT|VA|WA|WV|WI|WY
>   |NB|NS|QC|ON|MB|SK|AB|BC|NWT|NF  # VE provinces
>   |LB|NU|YT|PEI
>   |DC  # District of Columbia
>   |DX  # anyone else outside WA
>   |ADA|ASO|BEN|CHE|CLAL|CLAR|COL   # 39 WA counties
>   |COW|DOU|FER|FRA|GAR|GRAN|GRAY
>   |ISL|JEFF|KING|KITS|KITT|KLI
>   |LEW|LIN|MAS|OKA|PAC|PEND|PIE
>   |SAN|SKAG|SKAM|SNO|SPO|STE|THU
>   |WAH|WAL|SHA|WHI|YAK 
> )
>   )", QRegularExpression::CaseInsensitiveOption | 
> QRegularExpression::ExtendedPatternSyntaxOption};
> 
> 
> Of course, it's not just that simple, I knowbut I feel strongly enough 
> about the subject that I'm willing to try my hand at coding, something I've 
> not done since my FORTRAN77 and PDP-11 school days.
> 
> True, there are some arguments against putting in the effort.
> - Texas has 254 Counties.  My fingers ache just thinking about it.
> - Not every State has a QSO Party.  Out west, those states without the 
> support resources for their own QP (OR, MT, WY, etc) created the 7th Area QSO 
> Party (7QP), which is wildly popular.  It's exchange field requires a field 
> of 5 characters (2-ltr-State + 3-ltr County).
> -Instead of a QRegExp for each QP, a matrix of A through Z would 
> support any 5-ltr combo a particular State QP sponsor might devise.  Of 
> course, that leaves it to the end user to populate them in Settings/Advanced. 
>  Texans would think that insane.  7QP'ers would call it cruel and unusual 
> punishment.
> 
> Am I the only Voice in the Wilderness that thinks this would be worth it?  WA 
> is happily willing to shift from 4 letter County abbreviations to 3 letter if 
> it helps!
> 
> 73 John W7CD
> 
> 
> 
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] v2.1.0 randomly stops decoding ft8

[Tom Melvin]

Alan

Just an observation - for many many people the software works well, the fact 
you cannot reproduce the issue does suggest IF it is an actual wsjtx bug it is 
pretty obscure.  

From doing software development in a different life these are the worst sort of 
issues - it could be rig setup, it could be other applications on the PC, could 
be latest windows (or whatever) update, supplier codex, etc. etc. - how much 
time is justified in tracking it down - you said it is a small team.

One option is to log the details, and then see how any others have issues over 
time, if more and more appear - is it same Rig? is it same version of the OS, 
is it the 32 or 64 bit version of the software (there are known issues with the 
64 bit that are tied to some dev libs) - you never actually mentioned which 
version you were using - if 64 have you tried the 32 bit?

While it may appear dev team are doing nothing it could be they are waiting to 
see if some common factor pops up - 1 week, 1 month, 1 year …  Your email seems 
to suggest you sort of expect the team to give it a higher priority (may be 
wrong but that was way I read the mail)

As to a bug list - yes there are a couple of issues I would like to see fixed - 
I know if a list was published there would be a flurry of activity (myself 
included)  ‘debating’ the severity/fix time scale - almost everyone would want 
their perceived bug higher up the list. All the dev team would end up doing is 
justifying the details.  I can see why no list is publicly available.

I’m sure when it can be reproduced it will be fixed.

Collect info, what is happening around the time of the freeze, are .wav files 
saved, anything running on PC at the time, time of day - how random is random, 
daily, weekly - collecting info in a little text file may provide pointers you 
can report to the team that may help.

Regards

Tom

--
73’s

Tom
GM8MJV (IO85)





On 28 Aug 2019, at 15:48, akirby03...@hotmail.com wrote:

> I assume that the development team uses some bug tracking package.  Is this 
> correct?
> 
> If so, was there a defect logged for the issue that I reported here?  If so, 
> what is the assigned severity and expected fix release?  If not, why not?
> 
> I, and many others, really appreciate the volunteer work done by the 
> development team on WSJT-X, but it would be really nice for users who report 
> a problem to know the status of their issue…
> 
> Thanks,
> 
> Alan / NX1W
> 
>> On Aug 26, 2019, at 4:02 PM, akirby03...@hotmail.com wrote:
>> 
>> Radio is an IC-7000. 
>> Audio is via USB audio dongle to radio ACC socket.  
>> 
>> 73
>> 
>>> On Aug 26, 2019, at 3:04 PM, Bill Somerville  wrote:
>>> 
>>> On 26/08/2019 19:19, Alan Kirby wrote:
>>>> I have a PC continuously running WSJT-X FT8.  Once or twice each week, it 
>>>> stops decoding all messages.  The clock is accurate to within 100ms and 
>>>> the waterfall shows many signals.
>>>>  
>>>> Restarting the program immediately fixes the problem.. I have observed 
>>>> this issue with earlier versions of WSJT-X but had hoped the new version 
>>>> would have fixed it.
>>>>  
>>>> I cannot reproduce this at will – it appears to happen randomly.  I would 
>>>> be happy to help the dev team collect data to diagnose this.
>>>>  
>>>> Windows 10 (64 bit), Intel i5-6400, 2.7GHz 8GB DRAM
>>>> WSJT-X v2.1.0
>>>>  
>>>> Thanks,
>>>>  
>>>> Alan (NX1W)
>>> Hi Alan,
>>> 
>>> which rig and how is it connected to your PC for audio?
>>> 
>>> 73
>>> Bill
>>> G4WJS.
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc9b2173181844d73251c08d72a588c50%7C84df9e7fe9f640afb435%7C1%7C0%7C637024432130899006sdata=0jj5QtA%2Bna8d33AtgV4fg3ZED6Vc2XKH7Qu9xyHVysU%3Dreserved=0
>> 
> 
> ___
> 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] Fwd: Welcome to the "wsjt-devel" mailing list

[Tom Ramberg via wsjt-devel]

Christopher, is it really a good idea to resend your acceptance mail containing 
both your username and password to the whole list? This post certainly was 
accepted and re-sent!

73 de Tom OH6VDA

Sendt fra min iPad Air 2

> 19. aug. 2019 kl. 02:55 skrev Christopher Diederich via wsjt-devel 
> :
> 
> I have been accepted to the list, but my posts keep getting rejected because 
> I am a non-member. Am I doing something wrong?
> 73
> de K1LDO
> Chris Diederich
> 
> 
> -- Forwarded message --
> From: 
> Date: Thu, Aug 15, 2019 at 11:19 AM -0400
> Subject: Welcome to the "wsjt-devel" mailing list
> To: 
> 
> 
> Welcome to the wsjt-devel@lists.sourceforge.net mailing list!
> 
> To post to this list, send your message to:
> 
>   wsjt-devel@lists.sourceforge.net
> 
> General information about the mailing list is at:
> 
>   https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> If you ever want to unsubscribe or change your options (eg, switch to
> or from digest mode, change your password, etc.), visit your
> subscription page at:
> 
>   https://lists.sourceforge.net/lists/options/wsjt-devel/k1ldo%40yahoo.com
> 
> 
> You can also make such adjustments via email by sending a message to:
> 
>   wsjt-devel-requ...@lists.sourceforge.net
> 
> with the word `help' in the subject or body (don't include the
> quotes), and you will get back a message with instructions.
> 
> You must know your password to change your options (including changing
> the password, itself) or to unsubscribe without confirmation.  It is:
> 
>   patefuvi
> 
> Normally, Mailman will remind you of your lists.sourceforge.net
> mailing list passwords once every month, although you can disable this
> if you prefer.  This reminder will also include instructions on how to
> unsubscribe or change your account options.  There is also a button on
> your options page that will email your current password to you.
> ___
> 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] [RttyDigital] WW Digi Contest Practices

[Tom Ramberg via wsjt-devel]

Which logger can I use for this contest? I far as I can see, N1MM+does not 
support it. 

If running only with WSJT-X 2.1.0, which options should I choose on the 
"Special operating activity" tab?

Tom OH6VDA
> 2. aug. 2019 kl. 20:16 skrev Ed Muns, W0YK :
> 
> Two one-hour practices each week leading up to the contest (8 total practice
> sessions):
> 
>Fridays (9, 16, 23, 30 August) 19-20 UTC  (EU evening)
>Saturdays (10, 17, 34, 31 August) 01-02 UTC (NA Friday evening)
> 
> These should be plenty of times for people to practice WW Digi within their
> personal schedule.  It's not ideal for some parts of the world beyond EU and
> NA, but scheduling gets complex and confusing otherwise.
> 
> Use the recommended frequencies in the WW Digi rules.  If you operate in the
> daily FT frequency sub-bands be sure to use only the non-contest message
> sequence with Grid Square and SNR.  ('Special operating activity' is
> disabled in WSJT-X.)
> 
> As part of your practice, feel free to try different scenarios that may
> occur during the contest.  For example, try both the WW Digi contest mode
> (aka NA VHF Contest mode in WSJT-X's 'Special operating activity' function)
> and the standard default message sequence with 'Special operating activity'
> disabled.  Use different calls you may have access to, e.g, club calls.  Try
> different configurations of your software, e.g., automatic vs. manual modes.
> 
> The WW Digi log processing system is up and running so we'd appreciate you
> submitting your practice logs so we can test before the actual contest.  All
> logs will be cleared out before the start of the contest at 12 UTC on 31
> August.
> 
>Cabrillo logs: https://ww-digi.com/logcheck/
>ADIF logs: https://ww-digi.com/adif/
> 
> 73,
> Ed W0YK
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> 
> View/Reply Online (#725): https://groups.io/g/rttydigital/message/725
> Mute This Topic: https://groups.io/mt/32692879/764089
> Group Owner: rttydigital+ow...@groups.io
> Unsubscribe: https://groups.io/g/rttydigital/leave/3500510/1416804849/xyzzy  
> [oh6...@yahoo.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 



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

Re: [wsjt-devel] Hound mode stops decodes?

[Tom Ramberg via wsjt-devel]

Tnx, Kari!

73 de Tom OH6VDA
> 6. aug. 2019 kl. 12:58 skrev Kari :
> 
>> On 6.8.2019 12.19, Tom Ramberg via wsjt-devel wrote:
>> I have wondered about the same, and I cannot find any "Rx all freqs" 
>> anywhere in the settings. Please point me in the right direction.
>> 73 de Tom OH6VDA
> 
> Tom, 
> 
> when in 'Hound' mode ( File => Settings => Advanced ) ...
> 
> 
> 
> ..the option  "Rx All Freqs" appears on the main screen of WSJT-X.
> 
> 
> 
> 
> 
> HTH,
> 
> Kari
> 
> 
> 
> 
> 
>> 
>> 
>> 6. aug. 2019 kl. 08:26 skrev Bill Richter :
>> 
>>> Is it new or did it just get unchecked during an update? I know it was 
>>> working before, but I haven't done any hound mode for a while.
>>> 
>>> --
>>> Thanks,
>>> Bill
>>> 
>>>> On August 5, 2019 at 9:26 PM Black Michael  wrote: 
>>>> 
>>>> Signals > 1000 will only show if you check "Rx All Freqs"
>>>> 
>>>> de Mike W9MDB
>>>> 
>>>> 
>>>> On Monday, August 5, 2019, 11:23:25 PM CDT, Bill Richter 
>>>>  wrote:
>>>> 
>>>> 
>>>> When I switch to Hound mode, I no longer see decodes in the decode window. 
>>>> Signals are still present in the waterfall. Is this expected behavior?
>>>> 
>>>> -- 
>>>> Thanks, 
>>>> Bill Richter 
>>>> KM6MHZ
>>>> ___ 
>>>> wsjt-devel mailing list 
>>>> wsjt-devel@lists.sourceforge.net 
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
>>> 
>>>  
>>> 
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> 
>> 
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hound mode stops decodes?

[Tom Ramberg via wsjt-devel]

I have wondered about the same, and I cannot find any "Rx all freqs" anywhere 
in the settings. Please point me in the right direction.
73 de Tom OH6VDA


> 6. aug. 2019 kl. 08:26 skrev Bill Richter :
> 
> Is it new or did it just get unchecked during an update? I know it was 
> working before, but I haven't done any hound mode for a while.
> 
> --
> Thanks,
> Bill
> 
>> On August 5, 2019 at 9:26 PM Black Michael  wrote: 
>> 
>> Signals > 1000 will only show if you check "Rx All Freqs"
>> 
>> de Mike W9MDB
>> 
>> 
>> On Monday, August 5, 2019, 11:23:25 PM CDT, Bill Richter 
>>  wrote:
>> 
>> 
>> When I switch to Hound mode, I no longer see decodes in the decode window. 
>> Signals are still present in the waterfall. Is this expected behavior?
>> 
>> -- 
>> Thanks, 
>> Bill Richter 
>> KM6MHZ
>> ___ 
>> wsjt-devel mailing list 
>> wsjt-devel@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
>  
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Help! Ft857d, signalink, Windows 7 and ft8

[Tom Ramberg via wsjt-devel]

For what it's worth, at OH2K club station we use Signalink, FT1000MP (I realise 
it's a different rig) and Windows 7 64 bit, and have had no problem with F/H. 
This isn't very helpful, I suppose.

OH6VDA Tom
> 21. jul. 2019 kl. 20:32 skrev Robert Anthony :
> 
> Anyone using the above and getting it to work? I can't get them to work in 
> the f/h mode. Get a error message. 
> 
> W8om Bob Anthony 
> 
> 
> 
> Sent from my Galaxy Tab® A
> ___
> 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] Please read: Windows users installing the latest v2.1.0 GA 64-bit version

[Tom Ramberg via wsjt-devel]

That's the WIN32 version.

73 de Tom OH6VDA
Sendt fra min iPad Air 2

> 18. jul. 2019 kl. 10:15 skrev Maurizio Brameri 
> :
> 
> I have found this link: https://slproweb.com/products/Win32OpenSSL.html
> 
> Bye,
> 
> Maurizio
> 
> 
> 
> Il 18/07/2019 08:38, Tom Ramberg via wsjt-devel ha scritto:
>> Could you please provide a link to the installation file of 
>> WIN64_OpenSSL_1.1.0k_Light?
>> 
>> 73 de OH6VDA Tom
>> Sendt fra min iPad Air 2
>> 
>> 18. jul. 2019 kl. 01:39 skrev Bill Somerville :
>> 
>>> Hi,
>>> 
>>> you may get an SSL/TLS network error when fetching a fresh LoTW users 
>>> database ("Settings->Colors->Logbook of the World User Validation"). The 
>>> WSJT-X User Guide current states that the OpenSSL v1.0.2 libraries are 
>>> required for this to work, this is incorrect for the 64-bit version of 
>>> WSJT-X, that requires the latest v1.1.0 version of the OpenSSL libraries. 
>>> The instructions are the same except use the Win64_OpenSSL_v1.1.0k_Light 
>>> package for the 64-bit version of WSJT-X.
>>> 
>>> Apologies for the release notice not containing this information, I have 
>>> only just discovered this new dependency.
>>> 
>>> 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
> ___
> 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] Please read: Windows users installing the latest v2.1.0 GA 64-bit version

[Tom Ramberg via wsjt-devel]

Could you please provide a link to the installation file of 
WIN64_OpenSSL_1.1.0k_Light?

73 de OH6VDA Tom
Sendt fra min iPad Air 2

> 18. jul. 2019 kl. 01:39 skrev Bill Somerville :
> 
> Hi,
> 
> you may get an SSL/TLS network error when fetching a fresh LoTW users 
> database ("Settings->Colors->Logbook of the World User Validation"). The 
> WSJT-X User Guide current states that the OpenSSL v1.0.2 libraries are 
> required for this to work, this is incorrect for the 64-bit version of 
> WSJT-X, that requires the latest v1.1.0 version of the OpenSSL libraries. The 
> instructions are the same except use the Win64_OpenSSL_v1.1.0k_Light package 
> for the 64-bit version of WSJT-X.
> 
> Apologies for the release notice not containing this information, I have only 
> just discovered this new dependency.
> 
> 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

Re: [wsjt-devel] WSJTX wont accept 3DA callsign

[Tom Ramberg via wsjt-devel]

I actually decoded you yesterday, Vincent. 
De OH6VDA @ OH2K. 

Sendt fra min iPhone

> 11. jul. 2019 kl. 00:47 skrev Black Michael via wsjt-devel 
> :
> 
> Just an example...used my own grid.
> It's in Illinois
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Wednesday, July 10, 2019, 04:44:54 PM CDT, Topher Petty  
> wrote:
> 
> 
> Isn't EM49 in Louisiana or Mississippi somewhere?
> 
> 
> On Tue, Jul 9, 2019 at 12:04 PM Philip Gladstone 
>  wrote:
> I suspect that the root cause is that he can't see any reports on psk 
> reporter. This is probably for two reasons -- there is no locator in the CQ 
> message (and so no psk report) and for other systems which do report this 
> type of message, there is no locator in psk reporter database and so it 
> cannot be displayed.
> 
> Philip
> 
> On Tue, Jul 9, 2019 at 11:36 AM Black Michael via wsjt-devel 
>  wrote:
> Oopsso no disconnect...so now we have to find out what problem he's 
> having specifically.
> 
> C:\WSJT\wsjtxrc7\bin>ft8code "CQ 3DA0VV EM49"
> Message   Decoded 
> Err i3.n3
> 
>  1. CQ 3DA0VV EM49CQ 3DA0VV   
>   *  4.  Nonstandard calls
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Tuesday, July 9, 2019, 10:22:10 AM CDT, Bill Somerville 
>  wrote:
> 
> 
>> On 09/07/2019 16:13, Black Michael via wsjt-devel wrote:
>> There does seem to be a disconnect between the GUI and the coding software.
>> This is with RC7.
>> 
>> 
>> 
>> But looks good here
>> C:\WSJT\wsjtxrc7\bin>jt9code "CQ 3DA0VV EM49"
>> MessageDecoded  Err? Type  Expected
>> 
>>  1. CQ 3DA0VV EM49 CQ 3DA0VV EM491:Std Msg EXACT
>> 
>> de Mike W9MDB
>> 
> Mike,
> 
> you appear to be confusing JT9 mode which uses a 75-bit protocol and has 
> special treatment for non-standard call and FT8 which has the new 77-bit 
> payload which has more general support for non-standard calls.
> 
> 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
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Field Day time problem

[Tom Melvin]

All

This posting by Fred gets my vote - easy, fool proof and does not distract the 
dev team.


--
73’s

Tom
GM8MJV (IO85)





On 24 Jun 2019, at 09:27, Fred Price  wrote:

> You are all overthinking the problem. There are programs to set your computer 
> clock by a GPS dongle. A good plug in dongle from Amazon is $12USD and the 
> program I use BktTimeSync is a free download.
> Also if the dev group keeps adding more n more WSJT will become bloatware. 
> I'd rather see improvements in what is in the software already. If you want a 
> color to denote a time that is getting out use JTAlert, it already has that 
> in it.
> 
> On Jun 24, 2019 4:07 AM, "DG2YCB, Uwe"  wrote:
> A very good idea to set up time beacons, Reino! I like this approach!
> 
>  
> However, as a short-term solution IMO dev team should find a way to use the 
> EXISTING data set of DT values for a pop-up saying that very likely time is 
> not synced correctly, plus an option to correct time by one click. Look the 
> following example. Only one station has a DT value which is totally out of 
> the average. Would be easy to detect such things by any well programmed 
> algorithm. Even the old JT65-HF software had two additional buttons, where 
> one could simply set PC clock + or – some 100 ms (until +- 2.5 s). Was very 
> helpful for fieldday activities. Just click on + or – as long as most of the 
> other stations have DT around 0. Simple approach, but worked 100%.
> 
>  
> 
> 
>  
> 73 de Uwe, DG2YCB
> 
>  
> -Ursprüngliche Nachricht-
> Hi,
> 
>  
> We are amateurs and could provide another time distribution experiment 
> especially during Field Day events. I mean setting up time beacon or beacons 
> that send e.g. every 15 s a short pulse, say 100 ms, on the base carrier 
> frequency e.g. 14.080 MHz. Timing of that pulse could be 'minute mark - 1 s' 
> or something similar agreed time. It would allow manual PC time setting in 
> the same manner as time marks of standard frequency stations. That 
> transmission would not disturb any FT8 message as nobody should transmit at 
> that time. It could be more useful, if the beacon frequency is set to 1 kHz 
> up (14.081), then you could hear it without detuning VFO and disturbing you 
> normal operation. Well, you could get same information from dT values 
> providing there are enough time accuracy in other stations and you timing is 
> good enough for decoding.
> 
>  
> Of course those beacons should be carefully synchronized to an accurate time 
> reference e.g. GPS. Depending on local regulations also a station identity 
> shall be sent at regular intervals using some applicable modulation perhaps 
> just before the time tick. I think that voluntary stations would provide this 
> service as needed.
> 
>  
> You could automate the time setting with a suitable program, if that could be 
> made safely and reliably (perhaps the pulses needs to be modulated for 
> identification), but that's next step if ever considered useful.
> 
>  
> 73 Reino oh3ma
> 
>  
>  
>  
> ___
> 
> wsjt-devel mailing list
> 
> wsjt-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] Bug report: WSJT-X fails to output sound after several minutes idle

[Tom M0LTE]

This happens to me from time to time.

On Sat, 15 Jun 2019 at 22:43, Steve Masticola via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Program version: 2.0.1 7ddcb7
>
> Operating system: Windows 10, ver. 1809 (OS Build 17763.503)
>
> Description: After sitting idle with Monitor on for several minutes,
> WSJT-X will key the transceiver on Tune or transmit, but does not generate
> sound to the soundcard. I have confirmed that the issue is in WSJT-X, not
> Windows or the soundcard. Confirmation was by testing the soundcard with
> the Windows Speaker Properties popup to eliminate Windows or the soundcard
> as the cause. 100% reproducible for users who are seeing this. Have
> identified a small number of other users who are affected. Can obtain
> additional logs if helpful. Please advise.
>
> Sequence of steps to repeat:
>
> N*ote: Only a small number of users reproduce this AFAICT.*
>
> 1. Disable Windows screen saver and all USB power-saving options.
> 2. Start WSJT-X.
> 3. Confirm proper operation of Tune control.
> 4. Let WSJT-X idle for 10-30 minutes.
> 5. Key the Tune control. Rig will be placed in transmit mode but no audio
> will go to the soundcard.
>
> ___
> 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] official ICOM response to ALC deflection on their rigs

[Tom M0LTE]

How is this any more complicated than set rig TX power to 100%, connect a
dummy load, then reduce audio drive level so power meter reads less than
100% in the middle of the passband?

Tom M0LTE

On Fri, 14 Jun 2019 at 07:39, Roeland Jansen 
wrote:

> "However, the action of ALC meter depends on balance between the
> modulation level setting of your transceiver and the audio output level of
> your PC.
> Please adjust them with seeing the ALC meter.
>
> As you already know, if the ALC meter indicates within the ALC zone, there
> is no problem.
>
>
> Best Regards,
>
> 
> Icom World Support Center"
>
> so:
>
> --> As you already know, if the ALC meter indicates within the ALC zone,
> there is no problem. <--
>
> ---
>
> This is icom specific and for ssb-d modes where a PC injects the audio
> into the TRX.
> (e.g. wspr, ft8, ft4 etc etc)
>
>
> ___
> 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] Audio level adjustment

[Tom Ramberg via wsjt-devel]

I just checked my computer soundcard settings and followed your procedure to 
set up the radio, the computer and the tranceiver, resulting in a seemingly 
dramatic enhancement of operation efficiency. For one thing (operator error, no 
doubt), I've never checked that the sound card sample rate was 48kHz 16-bit 
before, and of course it was not. Thanks a lot!

73 de Tom OH6VDA
Sendt fra min iPad Air 2

> 5. jun. 2019 kl. 15:49 skrev Black Michael via wsjt-devel 
> :
> 
> The link below is an article a couple of us wrote which has helped a lot of 
> people understand and fix their audio settings.  We have helped several 
> hundred people with this.
> 
> So decided to send this link out to the groups for general consumption.  
> You'll find it on my QRZ page too.
> 
> If you don't feel 100% confident in explaining the audio chain for WSJT-X (or 
> FLDigi or any other computer-based audio program) this document should help 
> explain it.  Doesn't touch on Linux setups though...one weakness of itbut 
> the principles remain the same.
> 
> Any recommendations for improving it are appreciated.
> 
> https://www.dropbox.com/s/mcj4hklxxgwswsy/FT8Noise5.pdf?dl=1
> 
> 
> de Mike W9MDB
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on decoding

[Tom Ramberg via wsjt-devel]

Sorry for posting this in the wrong thread. Now Trying to delete it and repost-

OH6VDA Tom

Sendt fra min iPad Air 2

> 5. jun. 2019 kl. 22:26 skrev Tom Ramberg :
> 
> I just checked my computer soundcard settings and followed your procedure to 
> set up the radio, the computer and the tranceiver, resulting in a seemingly 
> dramatic enhancement of operation efficiency. For one thing (operator error, 
> no doubt), I've never checked that the sound card sample rate was 48kHz 
> 16-bit before, and of course it was not. Thanks a lot!
> 
> 73 de Tom OH6VDA
> 
> Sendt fra min iPad Air 2
> 
>> 5. jun. 2019 kl. 15:01 skrev Black Michael via wsjt-devel 
>> :
>> 
>> For the IC-7300 you want the ALC meter to show no action at all.  So if it 
>> ever bumps up at all you've got too much audio going into the rig and need 
>> to back off the USB Mod Level.
>> 
>> You should be able to transmit 100W with no ALC (or very close to 100W).
>> 
>> That is the goal of all rigssome of the newer rigs will show < 0dB ALC 
>> (e.g. K3) though so it pays to learn what your ALC meter is really telling 
>> you.  The way you do that is set your rig for 100W, WSJT-X power slider at 
>> -3dB, computer audio out at 0dB, then adjust rig/external sound to show 50W 
>> tranmit power going out.  That should be 0dB ALC and shows you what to 
>> expect when transmitting close to the 100W.  Many rigs cannot do 100W with 
>> no ALC so have to back off to 95W maximum or such.  So as you gradually 
>> increase the power slider in WSJT-X (use the up cursor key) watch your ALC 
>> as you approach 100W.  If you start seeing ALC you have to back off the 
>> audio level at the rig or external sound card so the WSJT-X slider can be at 
>> 0dB and no ALC showing.
>> 
>> de Mike W9MDB
>> 
>> 
>> 
>> 
>> On Tuesday, June 4, 2019, 12:06:34 PM CDT, Black Michael via wsjt-devel 
>>  wrote:
>> 
>> 
>> If you reduce power from WSJT-X (not from the rig) does your ALC drop?  If 
>> so...that's too much audio.
>> 
>> Mike
>> 
>> 
>> 
>> 
>> On Tuesday, June 4, 2019, 11:57:44 AM CDT, Gene Marsh  wrote:
>> 
>> 
>> Mike,
>> 
>> My ALC is ~25% @80W.  But, I have no issues with transmit.  Only observing 
>> the double decode.  Everything else is good. 
>> 
>> 73 de W8NET Miles / “Gene”
>> Secretary, Portage County Amateur Radio Service (PCARS)
>> 3905 Century Club - Master #47
>> DV2/W8NET in the Philippines
>> Licensed since 1974
>> 
>>> On Jun 4, 2019, at 12:46 PM, Black Michael  wrote:
>>> 
>>> I do believe 63% audio on the IC7300 is wayy too much audio.  What does 
>>> your ALC meter say?
>>> 
>>> de Mike W9MDB
>>> 
>>> 
>>> 
>>> 
>>> On Tuesday, June 4, 2019, 11:44:04 AM CDT, Gene Marsh via wsjt-devel 
>>>  wrote:
>>> 
>>> 
>>> Joe,
>>> 
>>> My setup:
>>> 
>>> Windows 10 Pro - see the pic:
>>> 
>>> 
>>> 
>>> 
>>> -rc7
>>> IC-7300
>>> USB audio codec @66% volume
>>> 
>>> Need more info?
>>> 
>>> I will try to save a wav file next time I see it. 
>>> 
>>> 
>>> 73 de W8NET Miles / “Gene”
>>> Secretary, Portage County Amateur Radio Service (PCARS)
>>> 3905 Century Club - Master #47
>>> DV2/W8NET in the Philippines
>>> Licensed since 1974
>>> 
>>>> On Jun 4, 2019, at 12:12 PM, Joe Taylor  wrote:
>>>> 
>>> 
>>>> Hi Gene,
>>>> 
>>>> I have seen nothing like the duplicate decodes you report.  Please send us 
>>>> the .wav file for one or two of your examples, and tell us something about 
>>>> your computer setup.
>>>> 
>>>>-- 73, Joe, K1JT
>>>> 
>>>>> On 6/4/2019 11:39, Gene Marsh via wsjt-devel wrote:
>>>>> FT4: I have seen 7-8 times, double decoding.  Always a strong signal. 
>>>>> Example:
>>>>> image1.png
>>>>> I saw that in the early days of FT8.
>>>>>  Except for that, it’s working really well. (Thank you Joe and your team)
>>>>> 73 de W8NET Miles / “Gene”
>>>>> Secretary, Portage County Amateur Radio Service (PCARS)
>>>>> 3905 Century Club - Master #47
>>>>> DV2/W8NET in the Philippines
>>>>> Licensed since 1974
>>>>> __

Re: [wsjt-devel] Observation on decoding

[Tom Ramberg via wsjt-devel]

I just checked my computer soundcard settings and followed your procedure to 
set up the radio, the computer and the tranceiver, resulting in a seemingly 
dramatic enhancement of operation efficiency. For one thing (operator error, no 
doubt), I've never checked that the sound card sample rate was 48kHz 16-bit 
before, and of course it was not. Thanks a lot!

73 de Tom OH6VDA

Sendt fra min iPad Air 2

> 5. jun. 2019 kl. 15:01 skrev Black Michael via wsjt-devel 
> :
> 
> For the IC-7300 you want the ALC meter to show no action at all.  So if it 
> ever bumps up at all you've got too much audio going into the rig and need to 
> back off the USB Mod Level.
> 
> You should be able to transmit 100W with no ALC (or very close to 100W).
> 
> That is the goal of all rigssome of the newer rigs will show < 0dB ALC 
> (e.g. K3) though so it pays to learn what your ALC meter is really telling 
> you.  The way you do that is set your rig for 100W, WSJT-X power slider at 
> -3dB, computer audio out at 0dB, then adjust rig/external sound to show 50W 
> tranmit power going out.  That should be 0dB ALC and shows you what to expect 
> when transmitting close to the 100W.  Many rigs cannot do 100W with no ALC so 
> have to back off to 95W maximum or such.  So as you gradually increase the 
> power slider in WSJT-X (use the up cursor key) watch your ALC as you approach 
> 100W.  If you start seeing ALC you have to back off the audio level at the 
> rig or external sound card so the WSJT-X slider can be at 0dB and no ALC 
> showing.
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Tuesday, June 4, 2019, 12:06:34 PM CDT, Black Michael via wsjt-devel 
>  wrote:
> 
> 
> If you reduce power from WSJT-X (not from the rig) does your ALC drop?  If 
> so...that's too much audio.
> 
> Mike
> 
> 
> 
> 
> On Tuesday, June 4, 2019, 11:57:44 AM CDT, Gene Marsh  wrote:
> 
> 
> Mike,
> 
> My ALC is ~25% @80W.  But, I have no issues with transmit.  Only observing 
> the double decode.  Everything else is good. 
> 
> 73 de W8NET Miles / “Gene”
> Secretary, Portage County Amateur Radio Service (PCARS)
> 3905 Century Club - Master #47
> DV2/W8NET in the Philippines
> Licensed since 1974
> 
>> On Jun 4, 2019, at 12:46 PM, Black Michael  wrote:
>> 
>> I do believe 63% audio on the IC7300 is wayy too much audio.  What does 
>> your ALC meter say?
>> 
>> de Mike W9MDB
>> 
>> 
>> 
>> 
>> On Tuesday, June 4, 2019, 11:44:04 AM CDT, Gene Marsh via wsjt-devel 
>>  wrote:
>> 
>> 
>> Joe,
>> 
>> My setup:
>> 
>> Windows 10 Pro - see the pic:
>> 
>> 
>> 
>> 
>> -rc7
>> IC-7300
>> USB audio codec @66% volume
>> 
>> Need more info?
>> 
>> I will try to save a wav file next time I see it. 
>> 
>> 
>> 73 de W8NET Miles / “Gene”
>> Secretary, Portage County Amateur Radio Service (PCARS)
>> 3905 Century Club - Master #47
>> DV2/W8NET in the Philippines
>> Licensed since 1974
>> 
>>> On Jun 4, 2019, at 12:12 PM, Joe Taylor  wrote:
>>> 
>> 
>>> Hi Gene,
>>> 
>>> I have seen nothing like the duplicate decodes you report.  Please send us 
>>> the .wav file for one or two of your examples, and tell us something about 
>>> your computer setup.
>>> 
>>>-- 73, Joe, K1JT
>>> 
>>>> On 6/4/2019 11:39, Gene Marsh via wsjt-devel wrote:
>>>> FT4: I have seen 7-8 times, double decoding.  Always a strong signal. 
>>>> Example:
>>>> image1.png
>>>> I saw that in the early days of FT8.
>>>>  Except for that, it’s working really well. (Thank you Joe and your team)
>>>> 73 de W8NET Miles / “Gene”
>>>> Secretary, Portage County Amateur Radio Service (PCARS)
>>>> 3905 Century Club - Master #47
>>>> DV2/W8NET in the Philippines
>>>> Licensed since 1974
>>>> ___
>>>> wsjt-devel mailing list
>>>> wsjt-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>> 
>>> 
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> 
>> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] RU mock contest, some observations

[Tom Ramberg via wsjt-devel]

I operated OH2K, my radio club, and only participated fo a little more than 1 
hour.
40 m was void of FT4 signals, but full of phone. The frequency is in the SSB 
segment, and very often busy, specially by operators from eastern Europe.

On 20, there were hardly any signals from outside EU. VP8LP and SU9JG were 
welcome surprises. I also worked PY7KG and A45XR, but before the test.

Some strange glitches:
1. All the CQ calls turned green after the first couple of qsos. 
2. I experienced a troublesome loop, when the automatic sequence of Tx 
meaasages seemed to crash. I was unable to force the program to send RR73, 
because every time YO6FPW sent his report, the programme jumped back to sending 
my report. I enclose the relevant part of ALL.TXT below.



73 de Tom OH6VDA
Sendt fra min iPad Air 2

190604_19170014.080 Tx FT4  0  0.0 1140 CQ RU OH2K KP20 
 
190604_19170814.080 Rx FT4  1 -0.2 1322 OH2K YO6FPW 549 0046
190604_19171514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 569 0003  
 
190604_19172314.080 Rx FT4 -4 -0.2 1322 OH2K YO6FPW 549 0046
190604_19173014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 559 0003  
 
190604_19173814.080 Rx FT4 -2 -0.0 1323 OH2K YO6FPW 549 0046
190604_19174514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 559 0003  
 
190604_19175314.080 Rx FT4 -7 -0.0 1323 OH2K YO6FPW 549 0046
190604_19180014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 549 0003  
 
190604_19180814.080 Rx FT4  1 -0.0 1323 OH2K YO6FPW 549 0046
190604_19181514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 569 0003  
 
190604_19182314.080 Rx FT4 -3 -0.0 1323 OH2K YO6FPW 549 0046
190604_19183014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 559 0003  
 
190604_19183814.080 Rx FT4  2 -0.0 1323 OH2K YO6FPW 549 0046
190604_19184514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 569 0003  
 
190604_19185314.080 Rx FT4  2 -0.0 1323 OH2K YO6FPW 549 0046
190604_19190014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 569 0003  
 
190604_19190814.080 Rx FT4  6 -0.0 1323 OH2K YO6FPW 549 0046
190604_19191514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 579 0003  
 
190604_19192314.080 Rx FT4  7 -0.0 1323 OH2K YO6FPW 549 0046
190604_19193014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 579 0003  
 
190604_19193814.080 Rx FT4  1 -0.0 1323 OH2K YO6FPW 549 0046
190604_19194514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K 73  
 
190604_19195314.080 Rx FT4 -3 -0.0 1324 OH2K YO6FPW 549 0046
190604_19200014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 559 0004  
 
190604_19200814.080 Rx FT4  0 -0.0 1323 OH2K YO6FPW 549 0046
190604_19201514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 569 0004  
 
190604_19202314.080 Rx FT4 -4 -0.0 1323 OH2K YO6FPW 549 0046
190604_19203014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 559 0004  
 
190604_19203814.080 Rx FT4 -7 -0.0 1323 OH2K YO6FPW 549 0046
190604_19204514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 549 0004  
 
190604_19205314.080 Rx FT4 -8 -0.0 1324 OH2K YO6FPW 549 0046
190604_19210814.080 Rx FT4 -1 -0.0 1324 OH2K YO6FPW 549 0046
190604_19211514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 559 0004  
 
190604_19212314.080 Rx FT4  4 -0.0 1323 OH2K YO6FPW 549 0046
190604_19212314.080 Rx FT4-21 -0.2 1278 OH2K YO6FPW RR73
? a6
190604_19213014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K 73  
 
190604_19213814.080 Rx FT4 -1 -0.0 1324 OH2K YO6FPW 549 0046
190604_19214514.080 Tx FT4  0  0.0 1140 YO6FPW OH2K 73  
 
190604_19215314.080 Rx FT4-14 -0.0 1323 OH2K YO6FPW 549 0046
190604_19220014.080 Tx FT4  0  0.0 1140 YO6FPW OH2K R 539 0004  
 
190604_19220814.080 Rx FT4 -6 -0.0 1324 OH2K YO6FPW 549 0046
190604_19221514.080 Tx FT4  0  0.0 1140 CQ RU OH2K KP20
190604_19225314.080 Rx FT4 -8 -0.0 1324 OH2K YO6FPW 549 0046
190604_19230814.080 Rx FT4-13 -0.0 1323 OH2K YO6FPW 549 0046___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Open SSL problem.

[Tom Ramberg via wsjt-devel]

That did the trick. Thanks!
Made 20 qsos this morning mostly on 20. No problems encountered so far. Kudos 
to the developers!

73 de Tom OH6VDA @ OH2K club station



Sendt fra min iPhone

> 4. jun. 2019 kl. 11:31 skrev DG2YCB, Uwe :
> 
> Hi Tom,
> 
> I had the same issue here with my 64-bit version of WSJT-X. Just installed 
> the following 64-bit version of OpenSSL, and "Fetch now" now works fine: 
> https://slproweb.com/download/Win64OpenSSL_Light-1_0_2s.exe
> Restart WSJT-X after installation.
> 
> 73 de Uwe, DG2YCB
> 
> -Ursprüngliche Nachricht-
> Von: Bill Somerville [mailto:g4...@classdesign.com] 
> Gesendet: Dienstag, 4. Juni 2019 10:16
> An: wsjt-devel@lists.sourceforge.net
> Betreff: Re: [wsjt-devel] Open SSL problem.
> 
>> On 04/06/2019 06:45, Tom Ramberg via wsjt-devel wrote:
>> I’ve installed the WIN64OpenSSL_Light-1_0_2s, but the the lotw user activity 
>> file won’t load. Se error message
> 
> Hi Tom,
> 
> please read he instructions for the 32-bit OpenSSL installation in the 
> WSJT-X v2.0.1 User Guide, there are follow up instructions about 
> installing the Microsoft MSVC++ 2013 Redistributable package, as with 
> the OpenSSL package you need to select the 64-bit installer for the 
> 64-bit versions of WSJT-X and OpenSSL.
> 
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.0.1.html#INSTALL_WIN
> 
> 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



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

[wsjt-devel] Open SSL problem.

[Tom Ramberg via wsjt-devel]

I’ve installed the WIN64OpenSSL_Light-1_0_2s, but the the lotw user activity 
file won’t load. Se error message



73 de Tom OH6VDA 

Sendt fra min iPhone___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Plans for JT6m / FSK144

[Tom Melvin]

Hi

Thanks for update - much appreciated.

Tom


--
73’s

Tom
GM8MJV (IO85)





On 3 Jun 2019, at 16:33, Joe Taylor  wrote:

> Hi Tom,
> 
> There are no plans to support JT6m or FSK441 (which I assume you meant) in 
> WSJT-X.  These modes are deprecated because they have been superseded by 
> superior protocols.
> 
>   -- 73, Joe, K1JT
> 
> On 5/31/2019 7:10 PM, Tom Melvin wrote:
>> Hi Dev Team
>> WSJT supports JT6m and FSK144 while WSJT-X does not. There are a few people 
>> who, depending on mode / activity, still use those modes.
>> Can anyone tell me if adding those ‘older’ modes into WSJT-X is on the to-do 
>> list or will we still need to use V10 of WSJT?
>> 73’s
>> Tom
>> GM8MJV (IO85)
> 
> 
> ___
> 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] Cannot download RC6

[Tom Ramberg via wsjt-devel]

Clicking on the download link for RC5 produces this reactio (Similar for both 
32- and 64-bits versions):

Not Found

The requested URL /pulsar/K1JT/wsjtx-2.1.0-rc6-win64.exe was not found on this 
server.
ADDRESS:
Apache/2.2.15 (Scientific Linux) Server at physics.princeton.edu Port 80

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

[wsjt-devel] Plans for JT6m / FSK144

[Tom Melvin]

Hi Dev Team

WSJT supports JT6m and FSK144 while WSJT-X does not. There are a few people 
who, depending on mode / activity, still use those modes.

Can anyone tell me if adding those ‘older’ modes into WSJT-X is on the to-do 
list or will we still need to use V10 of WSJT? 

Thanks

Tom

--
73’s

Tom
GM8MJV (IO85)







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

Re: [wsjt-devel] Windows crash

[Tom Ramberg via wsjt-devel]

 Hi Bill. 
I never got another response from you, but FYI here's what we've been able to 
find out:1. I cannot find any crash reports or anything in the Windows Event 
Log.2. I uninstalled 2.0.1, and after that we've had no more crashes.
73 de Tom OH6VDA, 
Asemanvalvoja (Station Manager) @ OH2K

On Thursday, May 9, 2019, 11:17:05 PM GMT+3, Tom Ramberg via wsjt-devel 
 wrote:  
 
 Seems like this issue is now on two threads, sorry if I have messed things up. 
No, it is a sudden crash, the computer dies, and only gives out some buzzing 
sounds. It does not react to keyboard at all, and even the power switch doesn't 
react. See section below. There is no error messages, and I have found nothing 
in the event log, but if you give me a hint of where to look and what to look 
for, I'll check tomorrow morning.
>From the other thread: Bill, one of the first time it happened, I was 
>switching, but after that I've been sticking to RC5. And as I stated 
>originally, now it also happens seemingly unprovoked while RC5 is running 
>idle, only monitoring. I also had "blue screen" a couple of times, and I've 
>had to  pull out the mains power cord and wait some minutes to be able to 
>start in safety mode. Are you suggesting that there is some interaction 
>between 2.0.1 and 2.1.0-rc5? Could removing one or both and reinstalling be a 
>solution? I1m very happy with the FT8 of RC5, and still trying my best at FT4.
I'm planning on going to the clubstation again tomorrow morning (that's 0500 
UTC), and I might experiment with un-/reinstall then if that is a viable option.

De Tom OH6VDA
Tom Ramberg Lallukankuja 3 B 40 00920 Helsinki Finland Mobile phone +358 40 
6686922
Sendt fra min iPad Air 2
9. mai 2019 kl. 12:52 skrev Bill Somerville :


On 09/05/2019 07:13, Tom Ramberg via wsjt-devel wrote:

I have experienced several crashes on our Windows 7 PC after installing RC5 
(64bit). Usually it happens in connection with resizing windows, but sometimes 
it is totally unprovoked. I have tried to search the list archive for this, but 
find nothing. Is this only us at OH2K, or have others reported similar problems?





de Tom OH6VDA, operating OH2K, Raido club of Kauniainen (KRK)


Hi Tom,

do you get any error message? Is there anything in the Windows Event Log?

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

Re: [wsjt-devel] Windows crash

[Tom Ramberg via wsjt-devel]

Seems like this issue is now on two threads, sorry if I have messed things up. 
No, it is a sudden crash, the computer dies, and only gives out some buzzing 
sounds. It does not react to keyboard at all, and even the power switch doesn't 
react. See section below. There is no error messages, and I have found nothing 
in the event log, but if you give me a hint of where to look and what to look 
for, I'll check tomorrow morning.

From the other thread: 
Bill, one of the first time it happened, I was switching, but after that I've 
been sticking to RC5. And as I stated originally, now it also happens seemingly 
unprovoked while RC5 is running idle, only monitoring. I also had "blue screen" 
a couple of times, and I've had to  pull out the mains power cord and wait some 
minutes to be able to start in safety mode. Are you suggesting that there is 
some interaction between 2.0.1 and 2.1.0-rc5? Could removing one or both and 
reinstalling be a solution? I1m very happy with the FT8 of RC5, and still 
trying my best at FT4.

I'm planning on going to the clubstation again tomorrow morning (that's 0500 
UTC), and I might experiment with un-/reinstall then if that is a viable option.

De Tom OH6VDA

Tom Ramberg 
Lallukankuja 3 B 40 
00920 Helsinki 
Finland 
Mobile phone +358 40 6686922

Sendt fra min iPad Air 2

> 9. mai 2019 kl. 12:52 skrev Bill Somerville :
> 
>> On 09/05/2019 07:13, Tom Ramberg via wsjt-devel wrote:
>> I have experienced several crashes on our Windows 7 PC after installing RC5 
>> (64bit). Usually it happens in connection with resizing windows, but 
>> sometimes it is totally unprovoked. I have tried to search the list archive 
>> for this, but find nothing. Is this only us at OH2K, or have others reported 
>> similar problems?
>> 
>> de Tom OH6VDA, operating OH2K, Raido club of Kauniainen (KRK)
> 
> Hi Tom,
> 
> do you get any error message? Is there anything in the Windows Event Log?
> 
> 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

Re: [wsjt-devel] wsjt-devel Digest, Vol 63, Issue 64

[Tom Ramberg via wsjt-devel]

Bill, one of the first time it happened, I was switching, but after that I've 
been sticking to RC5. And as I stated originally, now it also happens seemingly 
unprovoked while RC5 is running idle, only monitoring. I also had "blue screen" 
a couple of times, and I've had to  pull out the mains power cord and wait some 
minutes to be able to start in safety mode. Are you suggesting that there is 
some interaction between 2.0.1 and 2.1.0-rc5? Could removing one or both and 
reinstalling be a solution? I1m very happy with the FT8 of RC5, and still 
trying my best at FT4.

I'm planning on going to the clubstation again tomorrow morning (that's 0500 
UTC), and I might experiment with un-/reinstall then if that is a viable option.

De Tom OH6VDA
Sendt fra min iPad Air 2

> 9. mai 2019 kl. 17:42 skrev Bill Somerville :
> 
>> On 09/05/2019 15:38, Al Pawlowski wrote:
>> I have not had any crashes, but have had regular instances of the WSJT-X 
>> main window moving from its previous position and/or increasing in height on 
>> startup, mostly after a preference/settings change. Usually, the window 
>> grows vertically a few rows, pushing JTAlert partially off screen. Then, if 
>> I pull it down before resizing, resizing is no longer possible as the lower 
>> edges are off-screen. I run WSJT-X on a large second monitor. I have to move 
>> the WSJT-X window to the smaller primary screen and then back to make the 
>> resize capable edges accessible. It’s annoying and does not happen with 
>> v2.0.1.
>> 
>> Running 64bit rc5 on Win10, build 17763
>> 
> Hi Al,
> 
> are you switching between v2.1.0 RC5 and v2.0.1 when this happens?
> 
> 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

[wsjt-devel] Windows crash

[Tom Ramberg via wsjt-devel]

I have experienced several crashes on our Windows 7 PC after installing RC5 
(64bit). Usually it happens in connection with resizing windows, but sometimes 
it is totally unprovoked. I have tried to search the list archive for this, but 
find nothing. Is this only us at OH2K, or have others reported similar problems?
de Tom OH6VDA, operating OH2K, Raido club of Kauniainen (KRK)
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Issue installing 2.1.0rc5

[Tom Melvin]

Hi OMOne of the main Mac maintainer’s lives in the UK - it is 4:30am here just now, you posting 4 hours ago - just after midnight local time.It can take a while for some posts to be answered, the Dev team are all volunteers and do need sleep :-)By the way have you checked the ‘Known Issues’ list:http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt(see item 2 - it may help) - not saying it is what you are reporting but it may be easier to switch back to GA until a new Mac build is done.RegardsTom
--73’sTomGM8MJV (IO85)

On 2 May 2019, at 03:44, false via wsjt-devel  wrote: Hi, folks, hoping to get some help with this issue. I searched the 
Yahoo group archives and then sent this request to the group ~4 hours 
ago, have not received a response yet.  I renamed my old 
installation and installed the rc5 version;  the install process 
produced no errors but when I try to start the app, the below messages 
appear in Console. There are ~30 variations on the first message 
regarding varios frameworks when I initially attempt to start the app 
(after which the second message 
appears), any attempts to start the app again after the first attempt 
results only in the third error message. I have deleted the installation
 and reinstalled, with the same results. Any ideas? The 2.0 installation
 still functions... Mac Mini 2.3GHz i7 16GB running El Capitan (10.11.6)
 5/1/19 2:20:44.830 PM CoreServicesUIAgent[70277]: error -1 while 
removing quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtWidgets.framework/Versions/Current
 5/1/19 2:20:44.887 PM com.apple.xpc.launchd[1]: 
(com.apple.xpc.launchd.oneshot.0x10bf.wsjtx[71512]) Service exited 
with abnormal code: 1 5/1/19 2:28:40.539 PM com.apple.xpc.launchd[1]: (org.k1jt.wsjtx.307232[71588]) Service exited with abnormal code: 1I'm attaching the full error message output as a text file.


5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/QtCore
5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/Resources
5/1/19 2:20:44.817 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtCore.framework/Versions/Current
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/QtDBus
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/Resources
5/1/19 2:20:44.818 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtDBus.framework/Versions/Current
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/QtGui
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/Resources
5/1/19 2:20:44.819 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtGui.framework/Versions/Current
5/1/19 2:20:44.820 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/QtMultimedia
5/1/19 2:20:44.820 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/Resources
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtMultimedia.framework/Versions/Current
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/QtNetwork
5/1/19 2:20:44.821 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/Resources
5/1/19 2:20:44.822 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtNetwork.framework/Versions/Current
5/1/19 2:20:44.822 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtPrintSupport.framework/QtPrintSupport
5/1/19 2:20:44.823 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtPrintSupport.framework/Resources
5/1/19 2:20:44.823 PM CoreServicesUIAgent[70277]: error -1 while removing 
quarantine data on path 

Re: [wsjt-devel] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

[Tom Ramberg via wsjt-devel]

Bill, in nature yellow/black are warning colours, like on wasps and bumblebees, 
and emergency vehicles around the world use "neon type" "green" and "orange". 
Could that be an idea?

73 de Tom OH6VDA

Sendt fra min iPad Air 2

> 30. apr. 2019 kl. 16:17 skrev Bill Somerville :
> 
>> On 30/04/2019 14:09, Tom Ramberg via wsjt-devel wrote:
>> As for colour blindness, red and green are the absolute worst alternatives 
>> for us that are affected. (10% of male population).
>> 
>> 73 de Tom OH6VDA
>> Sendt fra min iPad Air 2
> Hi Tom,
> 
> I agree but I have not come across a pair of colours that widely imply 
> stop/go, bad/good, reject/accept, ... conceptually and that are visible to 
> those with red-green colour blindness. Any suggestions?
> 
> 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

Re: [wsjt-devel] Possible bug in WSJTX 2.1.0-RC5 Log-Qso

[Tom Ramberg via wsjt-devel]

As for colour blindness, red and green are the absolute worst alternatives for 
us that are affected. (10% of male population).

73 de Tom OH6VDA
Sendt fra min iPad Air 2

> 30. apr. 2019 kl. 14:07 skrev Sergio Yes UT9LI :
> 
> Hi! Dear ...!!!
> 
> dr Bill! When writing a Log-QSO, why do interfaces of different versions 
> appear? Why does the position of the buttons and their number change? Can 
> this be due to the involvement of interfaces of this function from previous 
> versions of the program that were previously used?
> 
> 
> 30 апреля 2019, 13:59:29, от "Bill Somerville" :
> 
>> On 30/04/2019 03:46, Matthew Miller wrote:
>> I have reasonably good vision and it trips me up, it seems like an 
>> accessibility nightmare for anyone with less than perfect vision.  If the 
>> buttons have to move around, it seems like some other accessibility change 
>> should be made, such as color coding them (also taking into account what 
>> colors people who may be colorblind can differentiate).
> Hi Matt,
> 
> I agree that the accessibility attributes of the WSJT-X Log QSO dialog have 
> been impacted, we feel the changes are necessary. Your suggestion of colour 
> coding is a good one and I will make a change to set the background colour of 
> those buttons in a consistent manner. Here is an example:
> 
> 
> 
> I understand you concerns, does such a change help? I should point out that 
> changing the size or shape of the buttons such that they are dissimilar would 
> defeat the purpose of the original change, as would making one of then a 
> default button. I should also point out that hitting ESC, while the dialog 
> has keyboard focus, still dismisses the Log QSO dialog *without logging a 
> QSO" as it always has done.
> 
> 73
> Bill
> G4WJS.
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> 
> --
> Good Luck! Best DX's! 73!
> de Sergio fm Kharkov BYE-Poka!
> 
> ___
> 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] FT4 40 meter frequency?

[Tom Ramberg via wsjt-devel]

Tnx Jari. I just thought 7047 was suspiciously quiet  :)

De OH6VDA @ OH2K

Tom 

Sendt fra min iPhone

> 30. apr. 2019 kl. 12:24 skrev Jari A :
> 
> In summary WSJT-X v2.1.0 RC5 will have the following FT4 suggested 
> frequencies (the Iter1 column):
> 
> Band Iter0   Iter1   Notes
> -
> 8035953575   (plus 3568 Region 3)
> 4070907047
> 30   10140   10140
> 20   14140   14080
> 17   18104   18104
> 15   21140   21140
> 12   24919   24919
> 10   28180   28180
>  6   50318   50318
>  2  144170  144170
> 73
> Bill
> G4WJS.
> 
> 
> 
> Relayed with regards,
> 
> :Jari  - oh2fqv
> 
>> On Tue, Apr 30, 2019 at 12:11 PM Tom Ramberg via wsjt-devel 
>>  wrote:
>> 
>> I just finished one contact on 20 meter. Now checking 40. What is the 
>> frequency for 40 meters?
>> 
>> De OH6DA & OH2K Tom
>> 
>> Sendt fra min iPhone
>> 
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] FT4 40 meter frequency?

[Tom Ramberg via wsjt-devel]

I just finished one contact on 20 meter. Now checking 40. What is the frequency 
for 40 meters?

De OH6DA & OH2K Tom

Sendt fra min iPhone


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

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting

[Tom Melvin]

Hi All

I don’t want to assume so will ask - FT4 aimed at ‘Contest Friendly digital 
modes’ - cool - BUT will it cater for the pile of weird contest rules that are 
out there. The abundance of requests for QSO Parties, Field Days where 
non-standards messages.  Heck for us UK VHF types - 6 character Locator squares 
etc.

Or … is this aimed specifically at the 'RTTY Contest types’

The docs on the web site for the RC does just refer to the RTTY contest - are 
other types in the pipeline?
If not then perhaps a subtle change to the description now before release may 
stop the multitude region/country contest requests hitting the reflector.

Tom

--
73’s

Tom
GM8MJV (IO85)





On 22 Apr 2019, at 16:34, Joe Taylor  wrote:

> To:   WSJT-X users interested in testing FT4
> From: K1JT, K9AN, and G4WJS
> 
> Soon after the "FT8 Roundup" held on December 1-2, 2018, we started serious 
> work on a faster, more contest-friendly digital mode that can compete with 
> RTTY-contesting QSO rates while preserving many of the benefits of FT8.  The 
> result is FT4 -- a new digital mode specifically designed for radio 
> contesting.
> 
> Over the past month a small group of volunteers have been conducting 
> on-the-air tests of FT4.  The early tests were very successful and helped us 
> to make a number of important design decisions.  We believe FT4 has 
> considerable promise for its intended purpose.
> 
> We'll soon be ready for testing by a larger group.  If you might be 
> interested in participating and offering your considered feedback, please 
> read the descriptive document "The FT4 Protocol for Digital Contesting", 
> posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
> 
> We plan to post downloadable installation packages for WSJT-X 2.1.0-rc5 on 
> April 29, one week from today.  The document linked above includes
> 
> - Instructions for installing WSJT-X 2.1.0-rc5 and FT4 configuration
> 
> - Operating instructions for FT4
> 
> - Basic description of the FT4 protocol, modulation, and waveform
> 
> - Detailed sensitivity measurements for FT4 under a wide variety of
>   simulated propagation conditions
> 
> - Schedule for upcoming test sessions
> 
> Please consider helping us to make FT4 a successful mode for digital 
> contesting
> 
> With best wishes and 73,
> 
>   -- Joe (K1JT), Steve (K9AN), and 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