Re: [wsjt-devel] Call for information about PC systems being used for WSJT-X

[Frank Kirschner]

>
> My reconditioned Dell Optiplex 9020, purchased for around $200 from
> Discount Electronics, has 8 i7-4770 cores running at 3.4 GHz. Pretty cheap
> for the processing power.


73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Rig verification

[Frank Kirschner]

Bill,

Thanks. I thought I had done that, but apparently, there was something left
in memory. I rebooted, and it installed fine.

73,
Frank
KF6E

On Thu, Jul 16, 2020 at 10:54 AM Bill Somerville 
wrote:

> On 16/07/2020 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:
>
> [image: image.png]
>
> Running Win 7 64, i7 with 16 GB.
>
> 73,
> Frank
> KF6E
>
> Hi Frank,
>
> shut down all instances of WSJT-X before trying to upgrade.
>
> 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] Rig verification

[Frank Kirschner]

I got v 2.2.2 to install. Exhibits the same behavior. When "Rig" is
selected under Split Operation, wsjt-x crashes. The function seems to work
properly when I select Fake It, so this isn't a critical issue.

73,
Frank
KF6E

On Thu, Jul 16, 2020 at 10:50 AM 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:
>
> [image: image.png]
>
> 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 <
> 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
>> BetaRIG_MODEL_FT1000D
>>   1005  Yaesu  FT-747GX20200323.0
>> BetaRIG_MODEL_FT747
>>   1006  Yaesu  FT-757GX20200325.0
>> BetaRIG_MODEL_FT757
>>   1016  Yaesu  FT-990  20200323.0
>> Alpha   RIG_MODEL_FT990
>>   1017  Yaesu  FRG-100 20160409.0
>> BetaRIG_MODEL_FRG100
>>   1018  Yaesu  FRG-960020160409.0
>> UntestedRIG_MODEL_FRG9600
>>   1019  Yaesu  FRG-880020160409.0
>> UntestedRIG_MODEL_FRG8800
>>   1021  Yaesu  FT-100  20200323.0
>> BetaRIG_MODEL_FT100
>>   1026  Yaesu  VR-5000 20200505.0
>> Alpha   RIG_MODEL_VR5000
>>   1027  Yaesu  FT-450  20200614.0
>> BetaRIG_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
>> BetaRIG_MODEL_FTDX3000
>>   1039  Yaesu  FT-600  20200113.0
>> BetaRIG_MODEL_FT600
>>   1040  Yaesu  FT-DX101D   20200614.0
>> BetaRIG_MODEL_FTDX101D
>>   2001  KenwoodTS-50S  20200624.0
>> Alpha   RIG_MODEL_TS50
>>   2003  KenwoodTS-450S 20200624.0
>> BetaRIG_MODEL_TS450S
>>   2005  KenwoodTS-690S 20200624.0
>> BetaRIG_MODEL_TS690S
>>   2006  KenwoodTS-711  20200624.0
>> UntestedRIG_MODEL_TS711
>>   2008  KenwoodTS-811  20200624.0
>> UntestedRIG_MODEL_TS811
>>   2009  KenwoodTS-850  20200624.0
>> BetaRIG_MODEL_TS850
>>   2010  KenwoodTS-870S 20200624.0
>> BetaRIG_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
>> BetaRIG_MODEL_THD7A
>>   2019  KenwoodTH-F6A  20200701.0
>> BetaRIG_MODEL_THF6A
>>   2020  KenwoodTH-F7E  20200701.0
>> BetaRIG_MODEL_THF7E
>>   2021  Elecraft   K2  20200624.0
>> BetaRIG_MODEL_K2
>>   2022  KenwoodTS-930  20200624.0
>> UntestedRIG_MODEL_TS930
>>   2023  KenwoodTH-G71  20200701.0
>> BetaRIG_MODEL_THG71
>>   2024  KenwoodTS-680S 20200624.0
>> BetaRIG_MODEL_TS680S
>>

Re: [wsjt-devel] Rig verification

[Frank Kirschner]

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:

[image: image.png]

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 <
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
> BetaRIG_MODEL_FT1000D
>   1005  Yaesu  FT-747GX20200323.0
> BetaRIG_MODEL_FT747
>   1006  Yaesu  FT-757GX20200325.0
> BetaRIG_MODEL_FT757
>   1016  Yaesu  FT-990  20200323.0
> Alpha   RIG_MODEL_FT990
>   1017  Yaesu  FRG-100 20160409.0
> BetaRIG_MODEL_FRG100
>   1018  Yaesu  FRG-960020160409.0
> UntestedRIG_MODEL_FRG9600
>   1019  Yaesu  FRG-880020160409.0
> UntestedRIG_MODEL_FRG8800
>   1021  Yaesu  FT-100  20200323.0
> BetaRIG_MODEL_FT100
>   1026  Yaesu  VR-5000 20200505.0
> Alpha   RIG_MODEL_VR5000
>   1027  Yaesu  FT-450  20200614.0
> BetaRIG_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
> BetaRIG_MODEL_FTDX3000
>   1039  Yaesu  FT-600  20200113.0
> BetaRIG_MODEL_FT600
>   1040  Yaesu  FT-DX101D   20200614.0
> BetaRIG_MODEL_FTDX101D
>   2001  KenwoodTS-50S  20200624.0
> Alpha   RIG_MODEL_TS50
>   2003  KenwoodTS-450S 20200624.0
> BetaRIG_MODEL_TS450S
>   2005  KenwoodTS-690S 20200624.0
> BetaRIG_MODEL_TS690S
>   2006  KenwoodTS-711  20200624.0
> UntestedRIG_MODEL_TS711
>   2008  KenwoodTS-811  20200624.0
> UntestedRIG_MODEL_TS811
>   2009  KenwoodTS-850  20200624.0
> BetaRIG_MODEL_TS850
>   2010  KenwoodTS-870S 20200624.0
> BetaRIG_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
> BetaRIG_MODEL_THD7A
>   2019  KenwoodTH-F6A  20200701.0
> BetaRIG_MODEL_THF6A
>   2020  KenwoodTH-F7E  20200701.0
> BetaRIG_MODEL_THF7E
>   2021  Elecraft   K2  20200624.0
> BetaRIG_MODEL_K2
>   2022  KenwoodTS-930  20200624.0
> UntestedRIG_MODEL_TS930
>   2023  KenwoodTH-G71  20200701.0
> BetaRIG_MODEL_THG71
>   2024  KenwoodTS-680S 20200624.0
> BetaRIG_MODEL_TS680S
>   2025  KenwoodTS-140S 20200624.0
> BetaRIG_MODEL_TS140S
>   2026  KenwoodTM-D700 20200701.0
> BetaRIG_MODEL_TMD700
>   2027  KenwoodTM-V7   20200701.0
> BetaRIG_MODEL_TMV7
>   2029  Elecraft   K3  20200624.0
> BetaRIG_MODEL_K3
>   2030  KenwoodTRC-80  20200624.0
> Alpha   RIG_MODEL_TRC80
>   2032  SigFox Transfox20111223.0
> Alpha   RIG_MODEL_TRANSFOX
>   2033  KenwoodTH-D72A 20200701.0
> BetaRIG_MODEL_THD72A
>   2034  KenwoodTM-D710(G)  20200624.0
> BetaRIG_MODEL_TMD710
>   2036  FlexRadio  6xxx20130717.0
> BetaRIG_MODEL_F6K
>   2037  KenwoodTS-590SG  

Re: [wsjt-devel] RTTY

[Frank Kirschner]

On Fri, Jan 17, 2020 at 3:01 PM David Gilbert 
wrote:

>
> I realize that you aren't proposing "changing RTTY", but that is
> essentially what you would have to do if you wanted to make use of the
> majority of FTx's better sensitivity ... so clearly you still do not
> understand.
>

I do understand that most of the improvement in sensitivity using FT modes
comes from other sources, like longer integration time, redundancy, error
correction, multiple decoding passes, etc. I would never expect RTTY to
approach the low signal levels that FT modes are capable of.

But there is a wide range of capabilities in the RTTY programs that are
currently available, so it is clear that some have more robustness in the
presence of noise than others. And none of the programs I have tried
achieve the performance that my old hardware T/U exhibited in 1970. So I'm
sure there is still room for improvement.

  I'm not sure what your degree is in, but I'm pretty sure it wasn't signal
> processing.
>

Ph. D. in EE from Ohio State, with minors in digital signal processing and
communications theory. I have taught both at the graduate and undergraduate
level. I took a course in error correction codes from Dick Hamming, after
whom hamming codes are named.

>
> The bulk of WSJT-X's better performance compared to RTTY comes from
> several things ... among them the requirement to be locked to preset time
> windows, the use of 8 (or 4) tones instead of 2 tones, the use of forward
> error correction, and multi-pass decoding.  Sophisticated filter algorithms
> have been around for decades and do not provide the bulk of FTx's better
> performance.
>
> My son (degree in both math and computer science) actually writes
> extremely sophisticated signal processing software for a state-of-the-art
> quasi-military company and I asked him to look at the WSJT-X source code
> (which is readily available under GNU).  He was impressed with K1JT's
> implementation of modern decoding systems like the Costas arrays (less so
> with the heavy use of Fortran coding), but the really clever schemes are
> not generally applicable to just any set of time-variable tones ...
> particularly if there are only two of them.
>

I didn't say they were. But current RTTY programs can be improved
considerably.

>
> K1JT does other things that are clever (albeit also known in the signal
> processing industry) such as recreating the signals decoded in a first
> pass, subtracting them from the recorded data, and doing a second pass
> decode ... as well as what K1JT calls a prior decoding, which essentially
> means don't spend resources decoding anything that you already know, like
> the callsign of the other station by the time you get to message #3.
> Again, these aren't applicable to standard RTTY.
>
> And if you still aren't convinced, here is a direct quote from the WSJT-X
> manual:
>
> I've read the manual.

> Standard RTTY doesn't pre-compress the data, does not use FEC, and none of
> the information in the quote above is compatible with standard RTTY.
>
So you believe that all the RTTY programs currently available are at the
theoretical maximum in robustness in the presence of noise?

> With that, I'm done arguing with you.
>
Well, you never were really arguing with me. You started with strawman
argument, and then went grasping for straws.

> Believe what you want, but it isn't supported by reality.
>
The reality is that there is a wide range of performance among the
currently available RTTY programs, and even the best ones can be improved.

> Dave   AB7E
>
> 73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

On Wed, Jan 15, 2020 at 1:44 PM David Gilbert 
wrote:

>
> You're assuming that the algorithms used in WSJT-X would be adaptable to
> RTTY to give better performance than what is already out there.
>

It is certainly true that the algorithms used in WSLT-X for discriminating
frequencies could be adapted for RTTY. Why wouldn't they? All they do is
discriminate what frequency is being received. I'm not sure that the newest
RTTY programs don't already use this same algorithm, but the noise
performance of the RTTY programs I've tried so far has been pretty poor,
and improving the algorithm used would ameliorate that.

  I don't think there is any evidence of that being the case, given the
> very rigid constraints that every single WSJT-X mode requires.
>

That has nothing to do with it. At some point in the flow of the both RTTY
programs and WSJT-X, a decision is made: was it this frequency or that
frequency? There's an algorithm that does this. I suspect that the writers
of WSJT-X have used the best algorithm that would run on computers
available, This algorithm, used in a RTTY program, would improve the noise
performance of decoding. The integration time available for RTTY is much
less than modes like FT8, and FT8 uses redundancies and limited code words,
but they both need to discriminate between frequencies. The work that
WSJT-X does over and above frequency discriminating has nothing to do with
RTTY, and it wouldn't be in a RTTY program.


> The appeal of RTTY for almost everyone (compared to FT8 or FT4) is its
> free form nature.  Just go read the current dialog on the CQ-Contesting
> reflector to see what I mean.
>

PSK-31 is much better for free-form communications than RTTY. It has better
noise performance and can copy through fades better. I believe most people
who operate in RTTY contests don't use a free-form mode anyway. They have
the exchange in macros, including the QSO counter, and they never touch the
keyboard. If there are many stations on, retyping the same info for every
QSO would be a waste of valuable operating time. All the RTTY programs I've
tried have macros and some sort of contesting mode.


> If you try to turn RTTY into a 2-tone version of FT8 neither user base
> will ever use it because it doesn't have the advantages of either mode.
>

I don't know why people keep saying that. I never suggested a change to
RTTY. All I suggested was that improving the software discriminator in a
RTTY program might produce a useful improvement in noise performance. And
if somebody wrote such a program, it would be useful to integrate it to
some extent with WSJT-X to make switching modes easier.

>
> Secondly, WSJT-X is simply a very bad contest user interface.  It was
> designed for weak signal DXing and it does a very good job for that, but it
> is terrible for contesting.  Again, check out the CW-Contesting reflector
> (you can just read the archives if you aren't subscribed) to see more
> comments on that point ... most of which have been from me.
>

No one suggested using the WSJT-X UI for a RTTY program. The discriminator
and the UI are independent of one another. Someone could create a program
with the same discriminator algorithm that WSJT-X uses, and give it a very
contest-ready UI. The pace of FT8 contesting is much slower than that of CW
or RTTY. It's very leisurely, and optimizing the UI for contesting isn't
necessary. WSJT-X does have a number of user conveniences, like automatic
logging, so clearly some thought has been put into making it a practical
program, as opposed to just a test program for a lab.

>
> I really don't think you understand what you keep proposing here,
>

I assure you, I do. I have the academic and teaching credentials that show
I do. But that's not the issue here.

I suspect you don't understand what I'm proposing, based on your comment
above. I'm not proposing a change to RTTY, as you suggested, but an
improvement in an algorithm in RTTY receiving programs.

Let me restate in clearer terms: It would be nice if someone (not
necessarily the WSJT-X developers - there are other programmers in the
world, so it wouldn't take time away from the WSJT development) wrote a
RTTY program that played well with WSJT-X, SliceMaster, and JTAlert, and
used the best frequency discrimination algorithm currently available. That
would facilitate switching modes, provide very useful "needed" and "B4"
alerts, and improve noise performance over current RTTY programs. Since FT8
and RTTY are often used in the same contests, switching back and forth
easily would be useful feature. I'm NOT proposing any changes to RTTY.

but it doesn't really matter because there is no way Joe Taylor is going to
> mess with it since I'm sure he does.
>

Joe Taylor is a very good scientist and programmer, but he's not the only
programmer in the world. Other people might be interested in this.

There is rumored to be a new version of CW Skimmer in the works, one that
will integrate well with Flex Radio's 

Re: [wsjt-devel] RTTY

[Frank Kirschner]

On Wed, Jan 15, 2020 at 2:27 AM Neil Zampella  wrote:

> The only reason you'd add RTTY to WSJT-X is if there were some way to
> improve it for weak signal work, the program and its protocols were not
> designed for any other reason.
>
And to make contest operation more convenient.


>The other reason is one you overlooked in Dave's post:
>
> Quote:
>
> 3. Each candidate development task has an "opportunity cost". The time spent 
> extending WSJT-X to support RTTY is time that can't be spent improving WSJT-X 
> in other dimensions. The WSJT-X developers are in a unique position to 
> improve their product; there are many other developers who can further 
> improve RTTY applications. David and Alex continue to improved their 
> applications, and MMTTY is open source.
>
> Thus I strongly recommend that the WSJT-X team continue to apply that 
> all-too-rare skill among software developers: focus.
>
> Unquote.
>
> Neil, KN3ILZ
>
>
>
> I didn't overlook it. In that post, I was responding to the strawman
argument offered. I have addressed the other point in another post.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

On Wed, Jan 15, 2020 at 5:41 AM Wolfgang  wrote:

> Hello Dwayne,
>
> adding RTTY to WSJT-X is like:
>
> "... can I add a Diesel engine to my advanced hydrogen driven car."
>
> Then why do they allow WSJT-X to be used in RTTY contests?

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

On Tue, Jan 14, 2020 at 11:32 PM David Gilbert 
wrote:

>
> What would that be?  FT8/FT4 uses a better detection scheme than RTTY
> precisely because of the constraints that FT8/FT4 require.  Those
> constraints are what allow the better decoding ... there is no "magic"
> involved here.
>
> No one suggested magic. The program has MFSK as one mode option. (It has
many modes, not just FT8.)  RTTY uses BFSK, and BFSK is a subset of MFSK.
In order to discriminate which tone is being sent, there is an algorithm
the program uses. Some algorithms are better than others. If you look at
the various RTTY programs available, you will see a considerable variation
in error rate vs. S/N. DM780, for example, requires an S5 signal to get
reasonably good print, and around S9 for 100% print. Others are slightly
better. My thought was that the frequency discrimination algorithm in
WSJT-X is better in the presence of noise than most of the other programs
available. (I've hear the word, "bins" used, so I suspect that FFT is at
the heart of the discriminator.) Using this as the heart of a RTTY program
might provide an improvement in performance on RTTY in the presence of
noise. I understand that RTTY doesn't use or allow the redundancy and error
correction techniques found in FT8, so the performance will never approach
that of FT8. But it could be improved. Many years ago, I used a T/U with
tuned circuits using 88 mH toroids, and Kleinschmidt teletype equipment,
and could get very good print even when the signal faded below my ability
to hear it in the headphones. I haven't found a single program currently
available that approaches that.

I understand that there is finite time available for programmers. For me,
as a user, WSJT-X works splendidly, and short of printing out QSL cards,
putting stamps on them, and taking them to the post office, I don't know
what else it could do for my operating practice. Since WSJT-X is now used
in RTTY contests, it seems like it would be a natural fit to add a RTTY
window to the program. The UI is completely different, but much simpler for
RTTY. An alternative might be for someone who already knows the code in
WSJT-X to write a small external program that is called when "RTTY" is
selected as the mode in WSJT-X. Since WSJT-X is used in RTTY contests, this
would make it more convenient. Is WSJT-X more of a test bed for
experimenting with new communications modes or a T/U program intended for
daily and contest use by hams? Of course, the developers make the choice as
to the mix. I was simply stating my preference as one ham among many.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

On Tue, Jan 14, 2020 at 8:23 PM Dave AA6YQ  wrote:

> 1. RTTY is a well-defined protocol; the result of any modifications to
> this protocol would not be RTTY.
>
>
> I don't understand. No one suggested modifying RTTY, just using a better
discrimination technique on the receive end.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Frank Kirschner]

I'm not suggesting changing the RTTY FSK standard. I'm suggesting a better
detection scheme for the existing RTTY standard.

73,
Frank
KF6E

On Tue, Jan 14, 2020 at 7:54 PM David Gilbert 
wrote:

>
> I'm not so sure it would be that easy.  All of the WSJT-X modes require
> some pretty rigid rules, not the least of which is fixed time frames
> closely locked to the same reference.  They also require some pretty
> narrowly constrained message formats.  I really doubt that very many
> current RTTY users would be willing to give up their current flexibility.
> If they were, they'd be a whole lot better off just to migrate to FT8 or
> FT4.
>
> Besides, the RTTY protocol by definition has some rather severe
> limitations, only two tones being one of them.
>
> 73,
> Dave   AB7E
>
>
> On 1/14/2020 5:21 PM, Frank Kirschner wrote:
>
> Dwayne,
>
> That's what I suggested some time ago. Not only would it put all the
> digital modes I use together in one program, but it would provide an
> opportunity to implement a really good RTTY detection algorithm. Some of
> the current programs require a very high S/N, and with the signal
> processing know-how of the originators of WSJT-X, I'm sure that could be
> improved upon.
>
> 73,
> Frank
> KF6E
>
>
> On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair  wrote:
>
>> Hey all,
>>
>> My background is IT infrastructure with some code development and I
>> although I have been active in the amateur radio community for less than a
>> year, given my software, IT infrastructure background, and electronics
>> background I have been assisting my local amateur radio community in all
>> aspects of computer interfacing to radios. First off, I am really impressed
>> with what has been accomplished with WSJT-X and I am an avid user of all
>> digital protocols including FT8, FT8 WSPR and others. I recently attended a
>> DX Club meeting and got to see first hand the resentment towards FT8 in the
>> context of DXCC awards. I never got to speak in defense of FT8 but what I
>> do believe is there is a basic misunderstanding on the fact that WSJT-X’s
>> success is much about the interface that WSJT-X provides to managing QSO’s.
>> “Ease of digital use” is completely missed on much of our older amateur
>> radio community yet the same operators have fully embraced RTTY as a
>> digital protocol.
>>
>> I would like to propose adding RTTY to WSJT-X for two reasons 1. As a
>> means to reframe the DXCC discussion away from FT8 itself to “it’s just a
>> UI for managing QSO’s”, and 2. I believe WSJT-X would be a great tool for
>> RTTY. From an implementation perspective it may be possible to run interval
>> and interval less with RTTY with the WSJT-X UI.
>>
>> Regards Dwayne Sinclair NA6US
>> Redondo Beach, CA
>>
>>
>
> ___
> 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] RTTY

[Frank Kirschner]

Dwayne,

That's what I suggested some time ago. Not only would it put all the
digital modes I use together in one program, but it would provide an
opportunity to implement a really good RTTY detection algorithm. Some of
the current programs require a very high S/N, and with the signal
processing know-how of the originators of WSJT-X, I'm sure that could be
improved upon.

73,
Frank
KF6E


On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair  wrote:

> Hey all,
>
> My background is IT infrastructure with some code development and I
> although I have been active in the amateur radio community for less than a
> year, given my software, IT infrastructure background, and electronics
> background I have been assisting my local amateur radio community in all
> aspects of computer interfacing to radios. First off, I am really impressed
> with what has been accomplished with WSJT-X and I am an avid user of all
> digital protocols including FT8, FT8 WSPR and others. I recently attended a
> DX Club meeting and got to see first hand the resentment towards FT8 in the
> context of DXCC awards. I never got to speak in defense of FT8 but what I
> do believe is there is a basic misunderstanding on the fact that WSJT-X’s
> success is much about the interface that WSJT-X provides to managing QSO’s.
> “Ease of digital use” is completely missed on much of our older amateur
> radio community yet the same operators have fully embraced RTTY as a
> digital protocol.
>
> I would like to propose adding RTTY to WSJT-X for two reasons 1. As a
> means to reframe the DXCC discussion away from FT8 itself to “it’s just a
> UI for managing QSO’s”, and 2. I believe WSJT-X would be a great tool for
> RTTY. From an implementation perspective it may be possible to run interval
> and interval less with RTTY with the WSJT-X UI.
>
> Regards Dwayne Sinclair NA6US
> Redondo Beach, CA
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Suggestion for Additional Checkbox

[Frank Kirschner]

Bill,

Thanks for the info. I'm an old CW op at heart, and even with a PhD in EE,
I sometimes scratch my head trying to figure out why the software works the
way it does.

73,
Frank
KF6E

On Thu, Apr 25, 2019 at 9:54 AM Bill Somerville 
wrote:

> On 25/04/2019 14:15, Frank Kirschner wrote:
> > Someone wrote that the software prevented using Hound mode in the
> > regular band segments. I was just demonstrating that this was not the
> > case. I didn't actually transmit, since I saw no stations in Fox mode.
>
> Frank,
>
> WSJT-X tries to prevent *Fox* FT8 DXpedition mode stations from
> operating on the "usual" FT8 frequencies. Clearly we cannot stop use of
> Fox mode if the DX does not use CAT control. Other programs like MSHV
> allow a mode similar to Fox mode on normal FT8 frequencies but AFAIK you
> do not need to select WSJT-X Hound mode to work DX using that
> application. This causes considerable confusion and when the so-called
> multi-threaded mode on MSHV is enabled on normal FT8 frequencies it
> causes QRM to other users by using more bandwidth than other stations,
> but TBH that's what happens with DXpeditions anyway. WSJT-X Fox & Hound
> DXpedition mode was designed to facilitate the larger DXpeditions, i.e.
> in the top 100 most wanted lists and able to operate 24/7 for most of
> the DXpedition operation. This warrants using a separate pre-published
> frequency schedule and there using multiple QSOs in parallel is quite
> acceptable for maximum throughput, thereby allowing as many users as
> possible to get in the DXpedition log without having to use high gain
> aerials and high power levels.
>
> 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] Suggestion for Additional Checkbox

[Frank Kirschner]

On Tue, Apr 23, 2019 at 10:49 PM Jim Shorney  wrote:

> On Tue, 23 Apr 2019 14:11:19 +0100
> "Martin Davies G0HDB"  wrote:
>
> > The use of Split is all-but essential for slick operation in Hound mode,
> which is presumably
> > why the software complained if you changed to a Hound configuration
> without one or other of
> > the Split options being selected.
>
> Actually, no it (rig split via CAT) is not at all essential. However,
> using the software without CAT control requires actual radio knowledge.
>
> Actually, it's pretty easy if you have the right equipment. The Flex Radio
6600 and Maestro combination allow control without the usual CAT
functionality. They communicate via TCP ports. There is a CAT program
provided, but I don't even run it when using the Maestro to control the rig.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Suggestion for Additional Checkbox

[Frank Kirschner]

Martin,

Thanks for you complete reply. I appreciate your taking the time. My
comments are below.

On Tue, Apr 23, 2019 at 9:20 AM Martin Davies G0HDB 
wrote:

>
> Frank:
>
> If the station you want to work is concurrently transmitting multiple
> (typically 3) signals 60Hz
> apart, and conducting multiple simultaneous QSOs, within a 'standard' FT8
> band segment
> then it'll be almost certain that the station is NOT operating in true F/H
> DXpedition mode but
> is instead using one of the derivative apps such as MSHV.
>
> To work such a station, should you wish to do so (although some people
> discourage it), it's
> NOT NECESSARY to switch your mode to Hound; you can work them using the
> standard
> FT8 mode.


 OK. Then a few of the stations I worked who were transmitting
other-than-normal messages were of the derivative type. However, often, the
program puts up a screen that says I should switch to F/H mode. I assume
these are genuine F/H signals.

Indeed, I'm puzzled as to why you feel it's necessary to toggle seemingly
> quite
> often between standard and Hound mode; the latter should only ever be
> necessary when
> you're trying to work a DXpedition, most (if not all) of which will have
> declared in advance
> which frequencies away from the standard segments they will be using for
> F/H mode.  There
> should never really be a need to change your system to Hound mode when
> you're operating
> in the standard band segments - it doesn't matter if you're trying to work
> a local or some
> exotic DX.
>

I don't believe I ever stated anything about the frequency of toggling F/H
ON or OFF. It's just that when a F/H signal appears, it would be convenient
to get into that mode as quickly as possible, since they are often weak,
and QSB takes them below the useful signal strength.

A DXpedition is usually active for a week or more. When one is coming in on
FT8, I switch to that band and frequency, toggle the F/H mode from OFF to
ON, and try to work them. Once I work them (or they fade out and I lose
patience), I again toggle the F/H mode from ON to OFF, and look for less
exotic DX. With ten bands of interest, this means that in two weeks, I
could toggle the F/H mode between OFF and ON many times. When there are no
DXpeditions active, of course I don't need to toggle it at all.

I don't believe that most people toggle F/H mode to ON when there is a
DXpedition active and leave it there for the duration.

>
> You stated in another email:
>
> > I have responded to stations in F/H mode in the regular band segment on
> > numerous occasions with no interference from the software. This
> screen-grab
> > shows Hound mode in the regular band segment.
>
> There's nothing in your screen-grab to indicate that any of the stations
> are operating in either
> true F/H mode or even in a derivative multi-channel mode such as MSHV, so
> why are you in
> Hound mode?
>

Someone wrote that the software prevented using Hound mode in the regular
band segments. I was just demonstrating that this was not the case. I
didn't actually transmit, since I saw no stations in Fox mode.

>
> If you've been switching to Hound mode whenever you want to try to work a
> DX station


I have not. The large majority of DX stations I have worked have been in
the normal mode. However, with 265 DXCC entities and 1233 band-entities
confirmed on LOTW, and band conditions as bad as they are, working new
entities without the benefit of a DXpedition at the distant end is getting
harder. Since I mostly hunt new band-entities, I don't generally work DX
that already have confirmed on that band. So the ratio of F/H contacts to
regular contacts is going up.


> With regard to being able to use Hound mode in the standard band segments,
> I've
> discovered that if I select my specific Hound configuration which excludes
> all the standard
> frequency segments (my frequency list for Hound mode only includes the
> declared
> DXpedition frequencies, eg. 14095kHz), then there's nothing to prevent me
> from manually
> retuning the rig down to 14074kHz and then transmitting within the
> standard segment.
> Perhaps the software developers could take a look at explicitly preventing
> transmissions in
> the standard segments whenever Hound mode is selected, irrespective of how
> the frequency
> is set.
>

That was my point, above. So it would also be true that a DX station (or
anybody, really) could switch to Fox mode in the regular band segment.

>
> You also stated, in another email:
>
> > I tried that, and it worked fine, switching between F/H and normal mode,
> > and switching Split between Rig and None. Until I closed and restarted
> the
> > program. The first time I switched configurations, the S/W complained
> that
> > I needed to use Rig or Fake It for the Split parameter. Once I reset it,
> it
> > worked fine again.
>
> Does this mean that you only select 'Split' operation when you change to
> Hound mode?  Why
> would you not use 'Split' when operating in normal FT8 

Re: [wsjt-devel] Suggestion for Additional Checkbox

[Frank Kirschner]

Just found my reading glasses and noticed that it is 10.131, not 10.136, so
that's not an example.

But that has noting to do with the point of improving the user interface.

I created hundreds of databases for industry and government, and found that
they were best-received when the most used functions were easiest to access.

73,
Frank
KF6E

On Mon, Apr 22, 2019 at 5:14 PM Frank Kirschner 
wrote:

>
>
> On Sun, Apr 21, 2019 at 5:51 PM Martin Davies G0HDB 
> wrote:
>
>> On 21 Apr 2019 at 13:47, Frank Kirschner wrote:
>>
>>
>> I've been a user of FT8 F/H mode since its inception and I can't recall
>> any instances where
>> *genuine* F/H signals have appeared in the standard FT8 band segments;
>> can anyone
>> confirm any instances of this?  However, there have been (and still are)
>> numerous stations
>> using the MSHV multi-thread mode in the standard band segments; such
>> stations
>> superficially appear to be using F/H mode because of the multiple
>> concurrent QSOs but
>> they're most definitely not.
>>
>
>  Here's a DX cluster report of a station using F/H in the regular band
> segment:
>
> [image: image.png]
>
> I can't receive him (low-band antenna blew down), and I wouldn't know if
> he was or wasn't, but I have worked several stations using F/H mode in the
> regular band segment.
>
>>
>> I use a specific, separate configuration for F/H mode and see no need to
>> have a main-screen
>> check-box to select the mode; as has already been pointed out selecting
>> that, and any other,
>> configuration can already be quickly and easily selected via a couple of
>> clicks.
>>
>
>  Yes, that's one work-around, probably the one I will use. But since
> toggling F/H mode is done more often than toggling Hold Tx Freq or Call
> 1st, it seems like that should be quicker to get to. A good UI has the
> most-used features closest to the user.
>
> 73,
> Frank
> KF6E
>
>>
>> --
>> 73, Martin G0HDB
>>
>>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Suggestion for Additional Checkbox

[Frank Kirschner]

On Sun, Apr 21, 2019 at 5:51 PM Martin Davies G0HDB 
wrote:

> On 21 Apr 2019 at 13:47, Frank Kirschner wrote:
>
> I use a specific, separate configuration for F/H mode and see no need to
> have a main-screen
> check-box to select the mode; as has already been pointed out selecting
> that, and any other,
> configuration can already be quickly and easily selected via a couple of
> clicks.
>

I tried that, and it worked fine, switching between F/H and normal mode,
and switching Split between Rig and None. Until I closed and restarted the
program. The first time I switched configurations, the S/W complained that
I needed to use Rig or Fake It for the Split parameter. Once I reset it, it
worked fine again.

Why does the program lose that setting when I close it?

73,
Frank
KF6E

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

Re: [wsjt-devel] Suggestion for Additional Checkbox

[Frank Kirschner]

On Sun, Apr 21, 2019 at 7:08 PM Jim Shorney  wrote:

> On Mon, 22 Apr 2019 08:06:26 +0930
> "Grant VK5GR"  wrote:
>
> > Fox and Hound was never in the main FT8 channels – indeed I believe
> Bill, Frank Joe and the team coded the system to not let you run F/H mode
> on the main FT8 channels.
>
>
> which can easily be subverted by not using CAT control of frequency.
>

Here is the program set to F/H mode in the regular band segment:


[image: image.png]

I'm using DAX with my Flex 6600, and Split is set to "Rig." Am I missing
something? There doesn't seem to be anything to prevent this.

73,
Frank
KF6E

>
> Not that anyone would do that.
>
> 73
>
> -Jim
> NU0C
>
> --
> “There’s something out of place – let’s go and poke it with a stick.” –
> The Doctor, "Amy’s Choice"
>
>
> ___
> 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] Suggestion for Additional Checkbox

[Frank Kirschner]

Grant,

On Sun, Apr 21, 2019 at 6:40 PM Grant VK5GR  wrote:

> Frank,
>
>
>
> Fox and Hound was never in the main FT8 channels – indeed I believe Bill,
> Frank Joe and the team coded the system to not let you run F/H mode on the
> main FT8 channels.
>

Interesting. If that's the case, that function isn't working:



[image: image.png]

>
>
I have responded to stations in F/H mode in the regular band segment on
numerous occasions with no interference from the software. This screen-grab
shows Hound mode in the regular band segment.


> There have been non WSJT based “derivatives” that unfortunately did not
> give due consideration to the problems of mixing F/H mode with standard FT8
> traffic.
>

OK. How do I tell whether it's a F/H mode station or a "derivative"
program? Most of the time, when I switch to F/H mode to work DX, I am able
to work them. Does that indicate the DX station is, indeed, running F/H?

Thanks.

73,
Frank
KF6E

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

Re: [wsjt-devel] Suggestion for Additional Checkbox

[Frank Kirschner]

On Sun, Apr 21, 2019 at 5:51 PM Martin Davies G0HDB 
wrote:

> On 21 Apr 2019 at 13:47, Frank Kirschner wrote:
>
>
> I've been a user of FT8 F/H mode since its inception and I can't recall
> any instances where
> *genuine* F/H signals have appeared in the standard FT8 band segments; can
> anyone
> confirm any instances of this?  However, there have been (and still are)
> numerous stations
> using the MSHV multi-thread mode in the standard band segments; such
> stations
> superficially appear to be using F/H mode because of the multiple
> concurrent QSOs but
> they're most definitely not.
>

 Here's a DX cluster report of a station using F/H in the regular band
segment:

[image: image.png]

I can't receive him (low-band antenna blew down), and I wouldn't know if he
was or wasn't, but I have worked several stations using F/H mode in the
regular band segment.

>
> I use a specific, separate configuration for F/H mode and see no need to
> have a main-screen
> check-box to select the mode; as has already been pointed out selecting
> that, and any other,
> configuration can already be quickly and easily selected via a couple of
> clicks.
>

 Yes, that's one work-around, probably the one I will use. But since
toggling F/H mode is done more often than toggling Hold Tx Freq or Call
1st, it seems like that should be quicker to get to. A good UI has the
most-used features closest to the user.

73,
Frank
KF6E

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

Re: [wsjt-devel] Suggestion for Additional Checkbox

[Frank Kirschner]

Gary,

Thanks; very helpful.

It is interesting to see that the F/H choice was on the main page early on.
It is toggled much more often than Hold Tx Freq or Call 1st.

73,
Frank
KIF6E

On Sun, Apr 21, 2019 at 3:03 PM Gary Hinson  wrote:

> Here’s a different suggestion, Frank: take a look at JTDX which has a
> hound button on the main screen.  Click the button to turn on hound mode’s
> short QSO sequence, then right click it to also enable the automatic
> frequency control thing that moves us below 1000 to the DX frequency when
> (if!) he calls us.
>
>
>
> Also, by the way, click the waterfall to set the green marker, or right
> click to set the red marker – simple, intuitive and easy.
>
>
>
> 73 GL
>
> Gary   ZL2iFB
>
>
>
> *From:* Frank Kirschner 
> *Sent:* 22 April 2019 05:38
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Suggestion for Additional Checkbox
>
>
>
>
>
>
>
> On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ  wrote:
>
> F/H is not something you would normally select on a frequent basis,
>
>
>
> Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have
> been in F/H mode. Normally, I never respond to CQs from band-entities that
> I already have confirmed on LoTW. If someone calls me while I'm working DX,
> I will respond, but that requires turning off F/H mode before doing so. A
> checkbox would make that easier. I certainly select or unselect F/H mode
> more often than Hold Tx Freq or Call 1st, and there are checkboxes for
> those.
>
> so a check box cluttering the main screen is not necessary.
>
>
>
> As I pointed out, it wouldn't clutter the screen. There is ample room for
> several more checkboxes.
>
>
>
> As previously suggested setting a Configuration for that mode (and others)
> are just 2 clicks away and totally customizable.  This procedure is
> outlined in the User Manual.  It's simple and effective.
>
>
>
> Yes, that's an adequate workaround. But there are several selections
> available on the screen that I don't normally change, and these could be
> accessed through different configurations. Yet, they are on the main
> screen. It's just a difference in operating style.
>
>
>
> WB5JJJ - George
>
>
>
> It was just a suggestion. Some people are not open to suggestions.
>
>
>
> Thanks for your input.
>
>
>
> 73,
>
> Frank
>
> KF6E
>
>
>
> On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
> wrote:
>
> Good idea. I'm not familiar enough with the program to have thought of
> that. Thanks.
>
>
>
> 73,
>
> Frank
>
> KF6E
>
>
>
> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
>
> Just a suggestion - works for me:  Create a F/H "configuration" and toggle
> to it.  Two mouse clicks.
>
>
>
> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner 
> wrote:
>
> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is room
> for several more checkboxes. One I would suggest is Fox/Hound mode. I would
> also suggest this automatically set Split to either Rig or Fake It, which
> could be selected somewhere else.
>
>
>
> If the menus are turned off, it takes a while to turn them on and navigate
> to the correct spot to set fox/hound and split mode. This sometimes is long
> enough to miss a weak one. A checkbox would not only make it faster, but it
> would encourage using that mode for those who are still learning FT8
> operation.
>
>
>
> 73,
>
> Frank
>
> KF6E
>
> ___
> 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] Suggestion for Additional Checkbox

[Frank Kirschner]

On Sat, Apr 20, 2019 at 11:19 PM Neil Zampella  wrote:

> There is already a F/H mode, safely placed where it can't be
> accidentally checked as the old VHF contest box (at least I believe it
> was the VHF contest) was at one point.
>
> The suggestion has been to clone your current FT8 configuration, and set
> up the frequencies in that clone to the DXPedition frequencies.All
> you have to do is switch to that configuration, and you're already set
> to go.
>
> However, if you're talking about being able to switch because you see
> what looks like F/H in the standard FT8 frequencies, its not WSJT-X
> DXPedition mode, but another program using the FT8 sources for
> encode/decode but a different 'multi-thread' mode that does NOT block
> out the standard frequencies.
>

That's not completely accurate. Initially, most F/H operation was in the
regular band segment, but as those segments filled up, DX stations moved to
the alternate frequencies. I have worked DX stations in F/H mode in the
regular band segments. That's becoming less frequent, though.

Since I mostly hunt DX, I don't just look for DX on the band activity
window in WSJT-X. I use a DX cluster and jump to the indicated frequency
directly. Since clusters now indicate the transmitted frequency instead of
the QRG, I have to manually change the VFO frequency to the correct one.
Then I look for the DX station, and decide if it's using F/H mode. It would
be convenient to switch to F/H with one click.

73,
Frank
KF6E

>
> I would not want to see such a change as it then rewards bad behavior
> (IMHO).
>
> Neil, KN3ILZ
>
> On 4/20/2019 5:46 PM, Frank Kirschner wrote:
> > Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
> > room for several more checkboxes. One I would suggest is Fox/Hound
> > mode. I would also suggest this automatically set Split to either Rig
> > or Fake It, which could be selected somewhere else.
> >
> > If the menus are turned off, it takes a while to turn them on and
> > navigate to the correct spot to set fox/hound and split mode. This
> > sometimes is long enough to miss a weak one. A checkbox would not only
> > make it faster, but it would encourage using that mode for those who
> > are still learning FT8 operation.
> >
> > 73,
> > Frank
> > KF6E
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.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] Suggestion for Additional Checkbox

[Frank Kirschner]

On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ  wrote:

> F/H is not something you would normally select on a frequent basis,
>

Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have
been in F/H mode. Normally, I never respond to CQs from band-entities that
I already have confirmed on LoTW. If someone calls me while I'm working DX,
I will respond, but that requires turning off F/H mode before doing so. A
checkbox would make that easier. I certainly select or unselect F/H mode
more often than Hold Tx Freq or Call 1st, and there are checkboxes for
those.

> so a check box cluttering the main screen is not necessary.
>

As I pointed out, it wouldn't clutter the screen. There is ample room for
several more checkboxes.

>
> As previously suggested setting a Configuration for that mode (and others)
> are just 2 clicks away and totally customizable.  This procedure is
> outlined in the User Manual.  It's simple and effective.
>
> Yes, that's an adequate workaround. But there are several selections
available on the screen that I don't normally change, and these could be
accessed through different configurations. Yet, they are on the main
screen. It's just a difference in operating style.


> WB5JJJ - George
>

It was just a suggestion. Some people are not open to suggestions.

Thanks for your input.

73,
Frank
KF6E

>
> On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
> wrote:
>
>> Good idea. I'm not familiar enough with the program to have thought of
>> that. Thanks.
>>
>> 73,
>> Frank
>> KF6E
>>
>> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
>>
>>> Just a suggestion - works for me:  Create a F/H "configuration" and
>>> toggle to it.  Two mouse clicks.
>>>
>>> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner <
>>> frank.kirsch...@gmail.com> wrote:
>>>
>>>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
>>>> room for several more checkboxes. One I would suggest is Fox/Hound mode. I
>>>> would also suggest this automatically set Split to either Rig or Fake It,
>>>> which could be selected somewhere else.
>>>>
>>>> If the menus are turned off, it takes a while to turn them on and
>>>> navigate to the correct spot to set fox/hound and split mode. This
>>>> sometimes is long enough to miss a weak one. A checkbox would not only make
>>>> it faster, but it would encourage using that mode for those who are still
>>>> learning FT8 operation.
>>>>
>>>> 73,
>>>> Frank
>>>> KF6E
>>>> ___
>>>> 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] Suggestion for Additional Checkbox

[Frank Kirschner]

Good idea. I'm not familiar enough with the program to have thought of
that. Thanks.

73,
Frank
KF6E

On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:

> Just a suggestion - works for me:  Create a F/H "configuration" and toggle
> to it.  Two mouse clicks.
>
> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner 
> wrote:
>
>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
>> room for several more checkboxes. One I would suggest is Fox/Hound mode. I
>> would also suggest this automatically set Split to either Rig or Fake It,
>> which could be selected somewhere else.
>>
>> If the menus are turned off, it takes a while to turn them on and
>> navigate to the correct spot to set fox/hound and split mode. This
>> sometimes is long enough to miss a weak one. A checkbox would not only make
>> it faster, but it would encourage using that mode for those who are still
>> learning FT8 operation.
>>
>> 73,
>> Frank
>> KF6E
>> ___
>> 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] Suggestion for Additional Checkbox

[Frank Kirschner]

Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is room
for several more checkboxes. One I would suggest is Fox/Hound mode. I would
also suggest this automatically set Split to either Rig or Fake It, which
could be selected somewhere else.

If the menus are turned off, it takes a while to turn them on and navigate
to the correct spot to set fox/hound and split mode. This sometimes is long
enough to miss a weak one. A checkbox would not only make it faster, but it
would encourage using that mode for those who are still learning FT8
operation.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Does the FT8 signal spike at the beginning of each transmission?

[Frank Kirschner]

Some rigs, even high-end rigs including the FTdx5000, exhibit a spike on
initial transmit. I noticed it mostly with the amp. The power would surge
briefly, and then return to the dial value.

I suspect the combination of the surge and a bit of RFI is causing the
problem. I suggest an opto-isolator on both ends of your CAT cable. They
are available for RS-232 and USB. That, plus some ferrites along the run
should help with the problem. Also, if you're using a desktop, try running
several ground straps to the case of the computer. Consumer-grade computers
aren't very resistant to RFI, and there is no bonding between the pieces of
sheet metal.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Feature Request

[Frank Kirschner]

George,

I believe you've explained the anomaly.

LOL

73,
Frank
KF6E

On Mon, Apr 1, 2019, 12:33 George J Molnar  wrote:

> KF6E has spilled the beans! The secret “whine mode” feature in WSJT-X has
> been revealed. On April 1st, of all days.
>
> Whine mode is exotic code that scans the operator’s brainwaves for signs
> of frustration, and just as he/she is about to give up (afterwards on
> slower computers) permits a DX decode. Otherwise, only calls from your ITU
> region are displayed.
>
> If you’re calling CQ DX, the software also generates multiple callers from
> your DXCC entity. Only when you give up and/or answer one will the
> application unlock DX decoding.
>
> There are variants on this mode for VHF/UHF, described in the supplemental
> operators’ guide, chapter 42.
>
> George J Molnar
> KF2T - Virginia, 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

[wsjt-devel] Feature Request

[Frank Kirschner]

Almost every time I'm trying to work a DX station, I call and call with no
success, until I hit Halt TX. As soon as I do that, the DX station comes
back to me.

Could you write some software that would get the DX station to respond
sooner? This would help everyone, including the DX station.

Also, some software that encouraged DX stations to respond to QSLs would be
nice. I've sent lots of "green stamps" with no result.

Thanks, and happy April 1!

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Automatic QSY on 160m!!

[Frank Kirschner]

I don't believe it involved double-clicking. I experienced the same thing a
while ago, and just assumed it was a feature of the software with which I
was unfamiliar. The transceiver changed frequency with no action on my
part. I saw in a DX cluster that the DX station (a JA, as I recall), was
listening on 1908. I had called him several times on 1840 with no answer.
After the rig QSY'd, I couldn't hear him, of course, so I manually set the
rig (Flex 6600) to receive on 1840 and transmit on 1908. I worked him right
away after that.

On Wed, Mar 6, 2019 at 3:38 PM Gary Hinson  wrote:

> Hi Bill.
>
>
>
> It sounds to me as if you may have double-clicked a CQ message containing
> a number e.g. “CQ 1908 AB1CDE”: I think WSJT-X interprets that number as a
> frequency and automatically QSYs the radio for you – like it or not.  I
> don’t know what kind of validation or bounds checking there is, but I
> suspect if I sent “CQ 2010 ZL2IFB”, I might be sending callers well outside
> the 160m band.   [Please don’t try this at home!]
>
>
>
> Generally speaking, we should NOT be sending numbers in our CQ calls on
> HF.  The workaround is NOT to double-click CQ messages containing numbers.
> If you want to call someone sending numbers, you can manually enter their
> callsign into the DX call box, generate the messages then call the station
> without QSYing.
>
>
>
> FWIW on HF, I would prefer to be able to disable the auto-QSY function,
> either as a user-option or by default.  In fact, it would be much more
> useful to allow directed CQ messages to contain up to 4 letters and/or
> digits e.g. “CQ E51 ZL2iFB”.  At present, directional CQs can only contain
> up to 4 letters, no numbers – possibly due to conflict with the auto-QSY
> function.  However, that would require a change to the software …
>
>
>
> 73,
>
> Gary   ZL2iFB
>
>
>
> *From:* Bill 
> *Sent:* 07 March 2019 03:50
> *To:* WSJT software development 
> *Subject:* [wsjt-devel] Automatic QSY on 160m!!
>
>
>
> I just ran into an issue while operating on 160m FT8. When I try to work
> JA stations on 160m I normally go into the WSJT-X preferences and turn the
> Radio Split operation from RIG to NONE then manually set my radio for a
> 1840 transmit and 1908 receive split. Before transmitting I make sure that
> I am on a clear frequency within the 1840 segment. This method has always
> worked well.
>
>
>
> This morning while calling a regular CQ on the standard 1840 allocation
> (split control set to standard RIG control - normal 160m operation) WSJT-X
> displayed a purple line in the RX window saying "QSY 1908" and my rig was
> automatically sent to both transmit and receive to 1908. Where did this
> come from and more importantly how do I turn it off!! Some online research
> showed some information about a QSO partner requesting a QSY but I don't
> want someone else controlling my radio and possibly making it transmit
> outside of my frequency allocations.
>
>
>
> I've never seen this before and needless to say I was more than surprised.
> I'm glad that I caught it in time.
>
>
>
> Thanks!
>
>
>
> 73,
>
>
>
> Bill - AK6A
> ___
> 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 RX Window not in chronological order

[Frank Kirschner]

I think you just noticed it. I've been seeing that since version 1.9. I use
Windows 7. I never thought much about it, looking at several lines to
figure out which one was the last one sent.

73,

Frank

KF6E

On Tue, Feb 26, 2019, 13:18 Bill  wrote:

> I recently upgraded to version 2.0.1 and noticed an issue I haven't seen
> before. It appears that the entries in the RX window are not always in
> chronological order with the intermixed TX lines. I've been in the habit of
> always looking at the last line of the RX display to see what I am
> transmitting out and who I am answering, especially when multiple people
> are calling me. Now it appears that I am seeing RX decodes showing up after
> my TX line is displayed. This threw me off thinking my transmit wasn't
> enabled and I was still decoding but that wasn't the case.
>
> During my troubleshooting I looked at the information in the ALL.txt file
> to try to see what was happening and discovered the timestamps inside the
> ALL.TXT file were different from the times shown in the RX window. ALL.TXT
> times appear to be correct but the RX window did not correlate with the
> times recorded there. Do the displayed records "round up" the time?
>
> I  am not sure what files can be attached to these posts so if this
> problem is of interest to the developers I can provide a copy of my ALL.TXT
> file and screen shoots showing the RX display issue.
>
> I've been using all versions and RCs of WSJT-X for ever the past year and
> never noticed this before.
>
> Bill - AK6A
>
> ___
> 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] Unexpected Behavior

[Frank Kirschner]

I was trying to work 9LY1JM on 80 m FT8. QRG was 3.567 MHz, which I have in
the frequencies list for FT8.  His audio offset was 355 Hz.

First thing I noticed was that when I double-clicked on his call in the
Band Activity window, it wasn't made the active call. The last call I
worked stayed in the transmit messages list. So I manually entered his
call. It seemed to transmit the first message OK. However, every few
minutes, either the active call in the transmit messages window would
switch back to the previous call, or the QRG would jump to 3.573 MHz. I
switched back and transmitted some more, but this kept happening.

I tried it both in Fox/Hound mode and standard mode with the same results.

He did eventually answer me, but I had to keep manually entering his call
and bringing the VFO back to the correct frequency.

Any ideas?

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Using WSJT-X Decoding Technique with RTTY

[Frank Kirschner]

Thanks. I'll try that.

73,
Frank
KF6E

On Thu, Jan 3, 2019, 11:42 Patrick 9A5CW  Hi Frank,
> You can try to download 2Tone for RTTY.
> So far best decoder was made for MSDOS by K6STI Bitty and Ritty. That was
> better than any Windows or so RTTY software nowdays.
>
> Best 73
> Patrik 9A5CW
>
>
> Datuma čet, 3. sij 2019. 17:14 Frank Kirschner  piše:
>
>> Hi, Bill,
>>
>> Thanks for your reply.
>>
>> I wasn't suggesting a change to the standard for RTTY, which, of course,
>> would be impossible at this point. I was pointing out that the software I
>> have used to decode RTTY is nowhere close to the theoretical limit, or even
>> the hardware discriminator I built years ago. DM780 and MMTTY, the two
>> programs I remember using, require very high signal to noise ratios to
>> provide even moderately good decoding.
>>
>> Do you have a recommendation on software that might perform better than
>> what I am using?
>>
>> I first used RTTY in the late 1960s, when I had my home-brew TU and a
>> Kleinschmidt teleprinter, so I'm familiar with the electro-mechanical
>> technology for which Baudot code was designed. I designed a weather
>> collection network for Thailand in the early 1970s that used mechanical
>> teleprinters and prepared tape messages. It was a bit of a kluge, but it
>> worked for years.
>>
>> 73,
>> Frank
>> KF6E
>>
>> On Thu, Jan 3, 2019 at 10:52 AM Bill Somerville 
>> wrote:
>>
>>> On 03/01/2019 15:33, Frank Kirschner wrote:
>>> > Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids
>>> > in the tuned circuits and a differential amplifier as a detector.
>>> > Occasionally, the received signal would fade below the noise, but the
>>> > Kleinschmidt teleprinter would keep printing the decoded text. I have
>>> > tried several current software packages for decoding RTTY signals, and
>>> > all of them require quite strong signals to decode at all, and very
>>> > strong signals to provide 100% print.
>>> >
>>> > I was wondering if the decoding method used in WSJT-X for FT8 could be
>>> > ported to a RTTY decoder. I realize that FT8 has a lower symbol rate,
>>> > which provides more time to integrate, and incorporates redundancy,
>>> > which improves accuracy. But the theoretical lower limit for decoding
>>> > RTTY is something like -5 dB S/N, and the current programs are nowhere
>>> > near that.
>>> >
>>> > If RTTY facilities could be integrated with WSJT-X, not only would the
>>> > decoding be better, but the log scanning functions of WSJT-X and
>>> > JTAlert would be better, significantly improving contest operation.
>>> >
>>> > I confess I haven't looked at the decoding techniques used by RTTY
>>> > software, but I suspect, based on performance, that it could be
>>> improved.
>>> >
>>> > 73,
>>> > Frank
>>> > KF6E
>>> >
>>> Hi Frank,
>>>
>>> this is well covered ground, some existing Baudot decoders have very
>>> good performance with built in weak and fading signal models to optimize
>>> them.
>>>
>>> The techniques used to decode FT8 are based around a block message
>>> format that includes parity bits and checksums for advanced forward
>>> error detection and correction, Baudot is a character based stream code
>>> with no forward error correction capability. RTTY was designed for an
>>> era where automation was mechanical and quite limited, just having a
>>> code that could be used to modulate a transmitter and be printed by a
>>> receiver was about the sum of the technical design. RTTY's *only*
>>> similarity with FT8 is that it is a frequency shift keyed constant
>>> amplitude signal. Even the simplest addition of a single parity bit to
>>> detect, but not correct, single bit errors would need a fundamental
>>> non-backwards compatible change to the Baudot code.
>>>
>>> 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] Using WSJT-X Decoding Technique with RTTY

[Frank Kirschner]

Hi, Bill,

Thanks for your reply.

I wasn't suggesting a change to the standard for RTTY, which, of course,
would be impossible at this point. I was pointing out that the software I
have used to decode RTTY is nowhere close to the theoretical limit, or even
the hardware discriminator I built years ago. DM780 and MMTTY, the two
programs I remember using, require very high signal to noise ratios to
provide even moderately good decoding.

Do you have a recommendation on software that might perform better than
what I am using?

I first used RTTY in the late 1960s, when I had my home-brew TU and a
Kleinschmidt teleprinter, so I'm familiar with the electro-mechanical
technology for which Baudot code was designed. I designed a weather
collection network for Thailand in the early 1970s that used mechanical
teleprinters and prepared tape messages. It was a bit of a kluge, but it
worked for years.

73,
Frank
KF6E

On Thu, Jan 3, 2019 at 10:52 AM Bill Somerville 
wrote:

> On 03/01/2019 15:33, Frank Kirschner wrote:
> > Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids
> > in the tuned circuits and a differential amplifier as a detector.
> > Occasionally, the received signal would fade below the noise, but the
> > Kleinschmidt teleprinter would keep printing the decoded text. I have
> > tried several current software packages for decoding RTTY signals, and
> > all of them require quite strong signals to decode at all, and very
> > strong signals to provide 100% print.
> >
> > I was wondering if the decoding method used in WSJT-X for FT8 could be
> > ported to a RTTY decoder. I realize that FT8 has a lower symbol rate,
> > which provides more time to integrate, and incorporates redundancy,
> > which improves accuracy. But the theoretical lower limit for decoding
> > RTTY is something like -5 dB S/N, and the current programs are nowhere
> > near that.
> >
> > If RTTY facilities could be integrated with WSJT-X, not only would the
> > decoding be better, but the log scanning functions of WSJT-X and
> > JTAlert would be better, significantly improving contest operation.
> >
> > I confess I haven't looked at the decoding techniques used by RTTY
> > software, but I suspect, based on performance, that it could be improved.
> >
> > 73,
> > Frank
> > KF6E
> >
> Hi Frank,
>
> this is well covered ground, some existing Baudot decoders have very
> good performance with built in weak and fading signal models to optimize
> them.
>
> The techniques used to decode FT8 are based around a block message
> format that includes parity bits and checksums for advanced forward
> error detection and correction, Baudot is a character based stream code
> with no forward error correction capability. RTTY was designed for an
> era where automation was mechanical and quite limited, just having a
> code that could be used to modulate a transmitter and be printed by a
> receiver was about the sum of the technical design. RTTY's *only*
> similarity with FT8 is that it is a frequency shift keyed constant
> amplitude signal. Even the simplest addition of a single parity bit to
> detect, but not correct, single bit errors would need a fundamental
> non-backwards compatible change to the Baudot code.
>
> 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] Using WSJT-X Decoding Technique with RTTY

[Frank Kirschner]

Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids in the
tuned circuits and a differential amplifier as a detector. Occasionally,
the received signal would fade below the noise, but the Kleinschmidt
teleprinter would keep printing the decoded text. I have tried several
current software packages for decoding RTTY signals, and all of them
require quite strong signals to decode at all, and very strong signals to
provide 100% print.

I was wondering if the decoding method used in WSJT-X for FT8 could be
ported to a RTTY decoder. I realize that FT8 has a lower symbol rate, which
provides more time to integrate, and incorporates redundancy, which
improves accuracy. But the theoretical lower limit for decoding RTTY is
something like -5 dB S/N, and the current programs are nowhere near that.

If RTTY facilities could be integrated with WSJT-X, not only would the
decoding be better, but the log scanning functions of WSJT-X and JTAlert
would be better, significantly improving contest operation.

I confess I haven't looked at the decoding techniques used by RTTY
software, but I suspect, based on performance, that it could be improved.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Operation problem WIN 10 wsjt-x or Flex 6700

[Frank Kirschner]

I'm experiencing the same problem. It has happened on all the versions of
WSJT-X I've tried, including the latest, which I am now using. Running Win
7 64.

I don't think it's USB ports, since my Flex Radio doesn't use USB for any
connection to the computer. I also experienced the same thing with my
previous rig: a Yaesu FTdx5000, with which I was using a Navigator
interface via USB..

It happens only while in receive mode, so it isn't RFI. I suspect it has
something to do with parameters that are changed when the computer goes to
sleep and is re-awakened, since that is when I see the problem.

73,
Frank
KF6E

On Thu, Jan 3, 2019 at 5:31 AM  wrote:

> HI Al,
> Don't feel like the Lone Ranger on this one, I have experienced the same
> phenomena as U... Not only with 2.0, but
> all the earlier versions as well, its like there is a hidden activity
> timer !!! It only happens when I'm not active, never
> when I'm actively using the program... I turned off the USB timers long
> ago to no avail, I've swapped computers, used
> a different radio, so far no luck... Its not that big of a deal with me,
> just restart WSJT, so I haven't really pursued it too
> much. I have an older laptop around here with XP in it, may have to load
> 2.0 in it and try it, should tell me if its a Win 10
> problem or not... Anybody out there using something besides Win 10 having
> the same problem ???
> 73, Paul, W3NZL
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Tune Mode Disabled

[Frank Kirschner]

Unfortunately, that had no effect. I would have been surprised if it had,
since there is no USB connection between my computer and the radio.
Everything goes over Ethernet. I experienced the same thing with my old rig
(FTdx5000) when I was connected via USB.

So I'll keep looking for a solution. I suspect it has something to do with
the interaction between WSJT-X and Windows, because WSJT-X comes up on a
different screen when the computer awakens after sleep mode.

73,
Frank
KF6E

On Tue, Jan 1, 2019 at 10:31 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Right-click Windows icon in lower left
> Device Manager
> Go to each USB controller and each device -- some but not all will have a
> "Power Management" tab.  Disable the "Allow the computer to turn off this
> device to save power" option.
>
> Additionally, in the Power & Sleep settings you can go into the Advanced
> setting and turn off "USB selective suspend".
>
> de Mike W9MDB
>
>
>
>
>
> On Tuesday, January 1, 2019, 9:18:27 AM CST, Richard Solomon <
> w1...@outlook.com> wrote:
>
>
> I don't find USB Power Options anywhere you mention.
> Perhaps it's a Windows 10 thing ??
>
> Can you give me more explicit instructions ?
>
> Tnx es HNY, Dick, W1KSZ
>
> Sent from Outlook <http://aka.ms/weboutlook>
> --
> *From:* Bill Somerville 
> *Sent:* Tuesday, January 1, 2019 8:03 AM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Tune Mode Disabled
>
> On 01/01/2019 14:57, Frank Kirschner wrote:
> > I often experience the same thing. If wsjt-x runs for awhile (about an
> > hour or so), it no longer transmits. Both the enable transmit button
> > and the tune button have no effect. It probably has something to do
> > with how the program interacts with Windows. Closing and restarting
> > the program fixes it.
> >
> > 73, Frank,
> >
> > KF6E
>
> Hi Frank,
>
> non-responsive audio after an hour or so is a symptom of Windows
> powering down USB devices to save power, make sure that you have
> disabled power saving options for USB hubs in Windows Device Manager and
> for USB devices in the Windows Power Plan Advanced Settings.
>
> 73 & HNY
> 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] Tune Mode Disabled

[Frank Kirschner]

I often experience the same thing. If wsjt-x runs for awhile (about an hour
or so), it no longer transmits. Both the enable transmit button and the
tune button have no effect. It probably has something to do with how the
program interacts with Windows. Closing and restarting the program fixes it.

73, Frank,

KF6E

On Mon, Dec 31, 2018, 23:49 Richard Solomon  I know I have very little data to go on, but on a few occasions
> I have had the Tune button not work. Re-starting FT8 cures
> the problem.
>
> Just recently, I was monitoring 160 for about an hour and
> decided to look at the SWR on the Antenna.
>
> I put the SPE-1.3K in Stand-by and hit the Tune button, That
> usually results in keying the rig and tickling the Antenna with
> about 35 Watts.
>
> Normally this works, but, now being the third time this anomaly
> has occurred, this time nothing. Usually, when I first turn everything
> on, I check the antennas, so I really don't keep track of every action
> after that.
>
> I know this is not much to go on, but I thought I would mention it,
> just in case someone else is experiencing this.
>
> 73 es HNY, Dick, W1KSZ
>
> Sent from Outlook 
> ___
> 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] Run Two Versions of FT8

[Frank Kirschner]

Dick,

I'm doing that with no issues. I can even leave JTAlert-X running, and it
connects to whichever version of WSJT-X is running. If you want to run both
simultaneously, you need to start the instances of WSJT-X from the command
line and assign a different "rig" to each instance. You can also create a
batch file to do that. Neal, N6YFM, showed me how to do that. Here's the
gist, from his message:

---
The first, and every time, you run the second program, you want to use
the --rig-name=SomethingElseoption to make sure the second WSJT-X
program uses a new folder for the setup, config, log files, etc.

See this post, scroll down, 4th post entry;
https://www.eham.net/ehamforum/smf/index.php/topic,123004.0.html
---

I found I didn't switch often enough to make running both simultaneously
worth it. If I see signals that aren't decoding, I close one instance and
start the other.

73,
Frank
KF6E

On Mon, Dec 10, 2018 at 9:52 AM Richard Solomon  wrote:

> Will there be any issues if I want to run both (1.9 & 2.0)
> versions ?
> I could put one in C:\WSJT1.9 and the other in C:\WSJT2.0
> Directories. Create shortcuts to both.
>
> That way, I could close down one and then open the other.
>
> It seems to me a way to ease into the transition until the
> majority switch over to 2.0.
>
> Does anyone see any issues with doing this ?
>
> Tnx es HH, Dick, W1KSZ
>
> Sent from Outlook 
> ___
> 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] Running 1.9 and 2.0 Simultaneously

[Frank Kirschner]

Thanks to all. I'll do some experimenting and see what I can do.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Running 1.9 and 2.0 Simultaneously

[Frank Kirschner]

I'd like to run both versions of WSJT-X simultaneously, linked to two
different receiver slices. When I try to run the second program, it says it
needs a different radio name. I don't see anywhere to enter a radio name. I
would have thought it would be under Settings, Radio, but there is only
Rig, which is a drop-down, and has to be HRD.

Is there a way to run both versions simultaneously? Any help would be
appreciated.

Flex 6600/Maestro
Win 7 64
HRD latest version

Thanks.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] "FT8 Roundup" mock contest

[Frank Kirschner]

Having written database software for mostly non-technical users, I
completely agree. Users love progress, but they hate change. In order to
get enthusiastic adoption of new releases, I had to show it would be
easier, faster, or more powerful for the users.

Hams, on the other hand, are technically-oriented, and I'm a bit surprised
at the reluctance to move forward. I love new releases and exploring the
new capabilities. But that's an engineer talking.

73,
Frank
KF6E

On Sat, Dec 1, 2018 at 11:00 AM Hisashi T Fujinaka 
wrote:

> As someone who actually works in the computer industry on software,
> getting people to upgrade is a mess. I can't tell you about the large
> customers who refuse to update to anything from this decade, but there
> are tons of them.
>
> For a data point, think of how many people (not just hams) are on Win7
> (or even XP).
>
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Graphic confusion ;-)

[Frank Kirschner]

Allan,

I think I see the problem. You are misinterpreting the word "to" in the
tool tip. If the tool tip for the arrow from Rx to Tx said, "Copy Rx freq
to Tx," instead of "Set Tx freq to Rx freq," (and conversely for the other
button), would that help?

Or, as has been suggested, just ignore the tool tip and look at the arrow
direction.

Hope that helps.

73,
Frank
KF6E

On Sat, Dec 1, 2018 at 5:10 AM  wrote:

> Just a single confusing graphic detail that might be corrected: On the two
> buttons for moving TX / RX to the same frequency, the arrows turn
> illogically (remains from 1.9 and earlier). The arrows should turn opposite
> so they point to what you do, i.e. that "Set RX frequency to TX frequency"
> points from RX to TX. It took me some time to get used to making things
> "wrong" to get the right result. :-)
>
>
>
> Thank you for continuing the great work! :-)
>
> 73, Allan
>
>
>
>
> ___
> 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] Contest mode: Crashing on attempting to log QSO

[Frank Kirschner]

It worked perfectly for me, except for one operator error. I worked 27
stations, including a new band-entity via LOTW.

I forgot that it is JT-Alert, not WSJT-X, that pushes logging info to HRD
Logbook, and I closed JT-Alert in the middle of the contest, thinking I
wouldn't need alerts since I was working everyone. The last 2/3 of the QSOs
weren't logged to HRD Logbook.

I created a Cabrillo file of the log, but it has a .log extension. I
thought Cabrillo files had a .cbr extension. Did I do something wrong?

Thanks to Joe for creating this useful and usable tool for hams.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Improving S/N

[Frank Kirschner]

Yes, that makes sense. I should have realized that the narrow filtering had
to be done somewhere.

Frank

On Fri, Oct 19, 2018 at 11:19 AM George J. Molnar  wrote:

> If I recall correctly, the S/N calculation is made in WSJT-X based on a
> fixed value somewhere around 2.8 kHz. Applying a wider or narrower
> bandwidth to the decoder will provide numerically different values, but not
> affect decoding performance UNLESS the narrowed bandwidth had an incidental
> improvement in noise rejection, AGC capture, or some other condition.
>
> It may look good on the screen. It may sound better to your ear, but the
> software doesn’t really care.
>
>
>
> *George J Molnar*
> Arlington, Virginia, USA
> KF2T   -   FM18lv
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Improving S/N

[Frank Kirschner]

When reducing the BW, the signal doesn't change, but the amount of noise
does, and that changes the S/N. In a system that didn't do optimum digital
filtering, reducing the BW to match that of the signal provides a S/N
improvement. In SSB, for example, increasing the BW to more than the signal
BW decreases the S/N.

Here's a paper that discusses it in the general case:

https://www.wiley.com/legacy/wileychi/hbmsd/pdfs/mm395.pdf
<https://www.google.com/url?sa=t=j==s=web=18=2ahUKEwjBxOqM6JLeAhUOJt8KHd4DBlsQFjARegQICBAC=https%3A%2F%2Fwww.wiley.com%2Flegacy%2Fwileychi%2Fhbmsd%2Fpdfs%2Fmm395.pdf=AOvVaw2AAgDJSbeQLpAJ5g4OSo-4>

However, as Joe pointed out, it doesn't provide a decoding advantage,
because the digital filtering (I assume using FFT bins) already filters at
the optimum bandwidth. So unless there is AGC pumping from  a very strong
signal or something like that, the pre-filtering I suggested doesn't help.

Oh, well...

73,
Frank
KF6E

On Fri, Oct 19, 2018 at 11:18 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

>  A decrease of bandwidth by a factor of 6 will increase reported SNR by
> approximately 16dB.
> But that's just a matter of what noise reference you use...not any real
> change in the signal level.
> If you used signal peak instead of RMS the SNR reported would be really
> lowit's all relative to the value chosen for N.
>
> You could just as well divide the signal level by some really small number
> and have 100's of dBs shownthe signal never changed though.
>
> de Mike W9MDB
>
>
>
> On Friday, October 19, 2018, 9:58:10 AM CDT, DG2YCB, Uwe 
> wrote:
>
>
> Frank, seems indeed to work! Just tested during RX of station KG4HF with
> bandwidth of either 3 kHz or 500 Hz. See the following S/N comparison.
> Astonishing!
>
>
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Frank Kirschner [mailto:frank.kirsch...@gmail.com]
> *Gesendet:* Freitag, 19. Oktober 2018 15:48
> *An:* WSJT software development
> *Betreff:* [wsjt-devel] Improving S/N
>
>
>
> One thing I haven't seen discussed on this reflector is improving the S/N
> by narrowing the receiver bandwidth. It is no surprise that decreasing the
> bandwidth received increases the S/N, by 10 to 15 dB, sometimes more. When
> I see a station I want calling at -24 or so, I can narrow the BW and get
> solid communications. This is very easy with the graphical presentation and
> digital filtering of the Flex 6600, but with a little practice, could be
> done on any modern receiver.
>
>
>
> This means that, if we knew where the stations were calling at -30 or so,
> we could focus on them and bring them up to the point of making contact.
> Since you can't decode stations at that S/N, it would have to be done "out
> of band." Is there any thought being given to setting up an FT8-only DX
> cluster with exact frequencies?
>
>
>
> What a fascinating hobby!
>
>
>
> 73,
>
> Frank
>
> KF6E
> ___
> 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] Improving S/N

[Frank Kirschner]

One thing I haven't seen discussed on this reflector is improving the S/N
by narrowing the receiver bandwidth. It is no surprise that decreasing the
bandwidth received increases the S/N, by 10 to 15 dB, sometimes more. When
I see a station I want calling at -24 or so, I can narrow the BW and get
solid communications. This is very easy with the graphical presentation and
digital filtering of the Flex 6600, but with a little practice, could be
done on any modern receiver.

This means that, if we knew where the stations were calling at -30 or so,
we could focus on them and bring them up to the point of making contact.
Since you can't decode stations at that S/N, it would have to be done "out
of band." Is there any thought being given to setting up an FT8-only DX
cluster with exact frequencies?

What a fascinating hobby!

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Delay in PTT

[Frank Kirschner]

Also, the sounds in JTAlert are now missing, even though I didn't do
anything specifically with them.

On Wed, Sep 19, 2018 at 4:36 PM Frank Kirschner 
wrote:

> Mike,
>
> I don't seem to be able to get it to work. Any PTT Method in WSJT-X other
> than CAT won't key the transmitter. I can't find common COM ports between
> WSJT-X and SmartSDR CAT. Some combinations give me an error, others just
> don't work. I assume if I could figure out how to create another COM port
> pair, it might work, but the dashboard for com0com is missing.
>
> Frank
>
> On Wed, Sep 19, 2018 at 2:56 PM Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> You should be able to do it by setting up a new port in PowerSDR under
>> the CAT control for PTT Control RTS or DTR.
>> Then pick that COM port and method in WSJT-X Radio setup.
>>
>> de Mike W9MDB
>>
>>
>>
>>
>> On Wednesday, September 19, 2018, 1:44:57 PM CDT, Frank Kirschner <
>> frank.kirsch...@gmail.com> wrote:
>>
>>
>> I am slowly getting all my programs to work with my new Flex
>> 6600/SmartSDR.
>>
>> One glitch left is that there is a three-second delay in transmit. I'm
>> using Ham Radio Deluxe as the rig, and PTT is via CAT. How do I change that
>> so WSJT-X sends PTT directly to the Flex?
>>
>> 73,
>> Frank
>> KF6E
>>
>> ___
>> 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] Delay in PTT

[Frank Kirschner]

Mike,

I don't seem to be able to get it to work. Any PTT Method in WSJT-X other
than CAT won't key the transmitter. I can't find common COM ports between
WSJT-X and SmartSDR CAT. Some combinations give me an error, others just
don't work. I assume if I could figure out how to create another COM port
pair, it might work, but the dashboard for com0com is missing.

Frank

On Wed, Sep 19, 2018 at 2:56 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> You should be able to do it by setting up a new port in PowerSDR under the
> CAT control for PTT Control RTS or DTR.
> Then pick that COM port and method in WSJT-X Radio setup.
>
> de Mike W9MDB
>
>
>
>
> On Wednesday, September 19, 2018, 1:44:57 PM CDT, Frank Kirschner <
> frank.kirsch...@gmail.com> wrote:
>
>
> I am slowly getting all my programs to work with my new Flex 6600/SmartSDR.
>
> One glitch left is that there is a three-second delay in transmit. I'm
> using Ham Radio Deluxe as the rig, and PTT is via CAT. How do I change that
> so WSJT-X sends PTT directly to the Flex?
>
> 73,
> Frank
> KF6E
>
> ___
> 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] Integration with HRD

[Frank Kirschner]

The callsign database file is associated with JTAlertX, not WSJT-X. I was looking in the wrong place.

 

Frank

 

Sent: Thursday, August 02, 2018 at 5:29 PM
From: "Laurie, VK3AMA" <_vk3a...@vkdxer.net>
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Integration with HRD



On 3/08/2018 4:03 AM, Frank Kirschner wrote:
> Mike Black got me set up with JTAlertX, and it's working well. Thanks.
>
> I remember reading about a callsign database that should be
> downloaded, but I can't find the reference or the database itself.
> Where is either one?
>
> 73,
> Frank
> KF6E
Frank or Mike,

What was the solution?

de Laurie VK3AMA


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Integration with HRD

[Frank Kirschner]

On Thu, Aug 2, 2018 at 6:51 PM, Laurie, VK3AMA <_vk3a...@vkdxer.net> wrote:

>
>
> On 3/08/2018 8:36 AM, Black Michael via wsjt-devel wrote:
>
>> The main solution was turning on HRD logging :-)
>>
>
It's actually a little more complicated than that. First, you have to know
that you must turn on that feature. I watched a couple of tutorial videos
on using JTAlert-X to link logging info from WSJT-X to HRD, and neither of
them mentioned this.

Then you have to know exactly what to do. If, in the "Help File," for
JTAlert-X, under Settings, Logging, HRD V5/V6, instead of "Under
Construction," it read, "Once JTAlert-X is communicating with WSJT-X, in
JTAlert-X, go got Settings, Manage Settings, click on the + to the left of
Logging to expand it, and select HRD V5/V6. Check 'Enable HRD V5/V6
Logging.' Check the Log Name and PC IPv4 Address against what HRD Logbook
uses to insure they are identical. Click 'OK,' " that would help.


>> Other things had to do with audio settings for operations, wide graph
>> settings, and such.
>>
>> de Mike W9MDB
>>
> Thanks Mike,
>
> Hmmm, Not having the logging enabled would not have produced the "Unable
> to communicate with the WSJT-X process" error posted.


You're right. I managed to fix that before the session with Mike. What was
happening was the UDP settings in WSJT-X weren't "taking." When I closed
the program and opened it again, the settings had reverted to their
original, which kept the programs from communicating.  I closed everything
and started again from scratch, and the setting changes persisted.

>
>
> de Laurie VK3AMA
>
>
> 73,
Frank
KF6E
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Integration with HRD

[Frank Kirschner]

Doh! I was looking at the WSJT page. Short between the headsets.

Thanks.

Frank

On Thu, Aug 2, 2018 at 3:01 PM, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Frank
> If you got to the same place as you downloaded JTAlert the callsign
> database link is a bit below it.
>
> de Mike W9MDB
>
>
>
>
> On Thursday, August 2, 2018, 1:06:13 PM CDT, Frank Kirschner <
> fr...@fkirschner.net> wrote:
>
>
> Mike Black got me set up with JTAlertX, and it's working well. Thanks.
>
> I remember reading about a callsign database that should be downloaded,
> but I can't find the reference or the database itself. Where is either one?
>
> 73,
> Frank
> KF6E
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Integration with HRD

[Frank Kirschner]

Mike Black got me set up with JTAlertX, and it's working well. Thanks.

I remember reading about a callsign database that should be downloaded, but
I can't find the reference or the database itself. Where is either one?

73,
Frank
KF6E
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Integration with HRD

[Frank Kirschner]

John,

Yes. Mine says 2237. No idea how to check to see if this is correct. I'm
going to connect with Mike Black in a bit, and he can get this fixed.

Frank
KF6E

On Thu, Aug 2, 2018 at 4:55 AM, John  wrote:

> Frank,
>
>
>
> Did you check the udp port in JTalert. Settings<->Applications<->WSJT-X
> …. UDP Port is here 2334
>
>
>
> John PA5JS
>
>
>
> *Van:* Frank Kirschner [mailto:fr...@fkirschner.net]
> *Verzonden:* donderdag 2 augustus 2018 02:11
> *Aan:* Black Michael; WSJT software development
> *Onderwerp:* Re: [wsjt-devel] Integration with HRD
>
>
>
> My memory isn't very good, and I forgot that I tried this a while back. I
> tried it again, and get the same error message:
>
>
>
>
>
> The settings in WSJT-X look exactly like those shown in the Setup section
> of the help file.
>
>
>
> No idea what to do now.  Any suggestions would be appreciated.
>
>
>
> 73,
>
> Frank
>
> KF6E
>
>
>
> On Wed, Aug 1, 2018 at 3:44 PM, Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> JTAlert will do it with WSJT-X plus more
>
>
>
> http://www.hamapps.com
>
>
>
> de Mike W9MDB
>
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Integration with HRD

[Frank Kirschner]

My memory isn't very good, and I forgot that I tried this a while back. I
tried it again, and get the same error message:



The settings in WSJT-X look exactly like those shown in the Setup section
of the help file.

No idea what to do now.  Any suggestions would be appreciated.

73,
Frank
KF6E

On Wed, Aug 1, 2018 at 3:44 PM, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> JTAlert will do it with WSJT-X plus more
>
> http://www.hamapps.com
>
> de Mike W9MDB
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Integration with HRD

[Frank Kirschner]

I'm still pretty inexperienced with the WSJT-X software, so forgive me if
I'm missing the obvious, but it would be really nice if the WSJT-X program
could feed QSO information to HRD Logbook.

In DM-780, when I send a macro with the command to log the QSO, it does so.
It seems like it should be possible to get WSJT-X to do the same. When the
line with "73" is sent and the Enable Send is cleared, a write to HRD
Logbook with the QSO info would be very convenient.

Is this possible? Maybe it's already available, and I just don't know how
to do it.

Thanks.

73,
Frank
KF6E
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Odd Behavior in WSJT-X

[Frank Kirschner]

Mike,

Yes, that was it. I changed the rig control program from HRD to Win4Yaesu,
and that required changing the Rig setting in WSJT-X from HRD to Yaesu
FTdx5000. That apparently changed the Split setting and the Bandwidth
setting.

Going back and looking at it, you are also right about the changes in
frequency. They seemed random to me, sometimes going up, sometimes going
down as the setting changed. If I had plotted it out, I probably would have
seen the pattern.

Thanks for the help.

73,
Frank
KF6E

On Wed, Jul 11, 2018 at 11:44 PM, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> It sounds like you have File/Settings/Radio/Split Operations set to "Rig".
> Rather than saying random freqs it would help if you were explicit about
> them.
> The expected behavior is 500Hz changes every 500Hz of offset.
>
>
> de Mike W9MDB
>
>
> On Wednesday, July 11, 2018, 6:25:48 PM CDT, Frank Kirschner <
> fr...@fkirschner.net> wrote:
>
>
> I was using WSJT-X with no anomalies, making contacts regularly. A few
> nights ago, it started doing two strange things.
>
> First, it would transmit on VFO B of my FTdx5000, regardless of how I had
> it set, and regardless of the band or frequency of VFO B.
>
> Second, the audio transmit frequency seems to bear no relationship to the
> setting in the TX audio frequency field. I started at 300 Hz and
> incremented it by 100 Hz throughout the range, and the frequency jumped
> around seemingly at random.
>
> I have not been able to make contacts reliably since this started.
>
> I was hoping there was a "Screw-up TX frequency" setting somewhere in the
> settings that had accidentally become checked, but I couldn't find it.
>
> Any ideas?
>
> 73,
> Frank
> KF6E
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
> _
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Odd Behavior in WSJT-X

[Frank Kirschner]

I was using WSJT-X with no anomalies, making contacts regularly. A few
nights ago, it started doing two strange things.

First, it would transmit on VFO B of my FTdx5000, regardless of how I had
it set, and regardless of the band or frequency of VFO B.

Second, the audio transmit frequency seems to bear no relationship to the
setting in the TX audio frequency field. I started at 300 Hz and
incremented it by 100 Hz throughout the range, and the frequency jumped
around seemingly at random.

I have not been able to make contacts reliably since this started.

I was hoping there was a "Screw-up TX frequency" setting somewhere in the
settings that had accidentally become checked, but I couldn't find it.

Any ideas?

73,
Frank
KF6E
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Support

[Frank Kirschner]

David,

Yup, short between the headsets!

73,
Frank

On Wed, Jul 11, 2018 at 5:37 PM, David Kaplan  wrote:

>
>
>
> Frank,
>
> If you look at the original address you sent to, it was to “ne”, not “net”.
>
> 73,
>
> David, WA1OUI
>
>
>
> Begin forwarded message:
>
> *From: *"Frank Kirschner" 
> *Subject: **[wsjt-devel] Fw: Mail delivery failed: returning message to
> sender*
> *Date: *July 11, 2018 at 4:59:37 PM EDT
> *To: *wsjt-devel@lists.sourceforge.net
> *Reply-To: *WSJT software development 
>
> How do I get support on WSJT-X?
> From: "Frank Kirschner" 
> * To: wsjt-de...@lists.sourceforge.ne 
>  <+*
> Subject: Support
> Content-Type: text/html; charset=UTF-8
> Date: Wed, 11 Jul 2018 22:50:22 +0200
> Importance: normal
> Sensitivity: Normal
> X-Priority: 3
> X-Provags-ID: V03:K1:96zWeByhcI+VD+fg5Mimx/LyqqKroHA1H6DkE0YqkEJzpEUDI1SW
> NhxHCAZdPW31QpQUM
> /Hx0GTypGSc56Kh2LmhUUd1zl4rJVafQh6fVXaSgjmOZiMC+
> SNpMsCt7NvtQNBfW7mVDrx1H7OtH
> 7ElqLIrgjMU0l9w1CKdwQqXilVcB5KcvLuqzBhNVq7VrKFxoBaYiBWftIRA+
> 8T9dvWWjKG5WtRiB
> QRRYSInOOT63loO44b0ge6oU5aseRGzzz8YnEX0/X3+/0RGo4wjTiXtkS6ZNzSQuMzBStQ7TFy
> To
> zg=
> X-UI-Out-Filterresults: notjunk:1;V01:K0:u3O4dH1+7aY=:
> O2rhF8YAcLAZBvVotCWk1O
> j8APqt1xYw/8j9B3/Ib6TZ62GmUDk+mzgtAif6oUed79oOLXOqIsE8K0tMMQFoqV/D+TiXAzm
> lNbpKPPQvwh6QsHKOlg8yYos89xajgD+hOlHCS3lwOsilddCsTBJmfVquy/yrvRZ/UXgidk1y
> /hSiJmHSEFMwa2sOtzNC3IgOqNw6YqzMAhvNW9aQP6g5A5IGRWksu85eDxkKej4Za6jusDkGR
> 6eZILuDY25QpkzBu2pivnWEFLFlC40Jy2QlCnuoD4aA9Z1B6OHl4lETNYsMAvwm8IrZdakBnb
> NtkjZJs+SSmHgLdJVGS5mw5UkPsSfk2twARzvkY2YlkgTbdl/I9uztvg+eCeC9Z7m/iadWGHl
> SD7bVV8IpSi1REtGfgAt6r8Gauwxr+QgL39KjvOZlla7q4tn4m4hj5K1eBJJmfTHWyi//AghR
> Ell6OeD5b/FvVL706E2mTlFP+1eZK2bcjV8/btG4tt4UEK6pM2+HrcSsEhSgGrXHnsTEZxY/8
> WRRBHpLNG1RKvO6LNQPv318Pm3XpnugX31J1EqkizJGjOkGSXK/vI7+ED1HAYhJw/4fqOdvyL
> Kx087deRpgj4SK3rO/17pKrlQ6aDO2JQvRQpMloYKBdRZraXgpv0x/GA==
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://slashdot.org/>!
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Support

[Frank Kirschner]

How do I get support on WSJT-X? I joined the Yahoo group and the
SourceForge group, and got confirmation emails, but my posts all bounce.

What am I doing wrong?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Support

[Frank Kirschner]

How do I get support on WSJT-X?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Fw: Mail delivery failed: returning message to sender

[Frank Kirschner]

How do I get support on WSJT-X?


From: "Frank Kirschner" 
To: wsjt-de...@lists.sourceforge.ne
Subject: Support
Content-Type: text/html; charset=UTF-8
Date: Wed, 11 Jul 2018 22:50:22 +0200
Importance: normal
Sensitivity: Normal
X-Priority: 3
X-Provags-ID: V03:K1:96zWeByhcI+VD+fg5Mimx/LyqqKroHA1H6DkE0YqkEJzpEUDI1SWNhxHCAZdPW31QpQUM
/Hx0GTypGSc56Kh2LmhUUd1zl4rJVafQh6fVXaSgjmOZiMC+SNpMsCt7NvtQNBfW7mVDrx1H7OtH
7ElqLIrgjMU0l9w1CKdwQqXilVcB5KcvLuqzBhNVq7VrKFxoBaYiBWftIRA+8T9dvWWjKG5WtRiB
QRRYSInOOT63loO44b0ge6oU5aseRGzzz8YnEX0/X3+/0RGo4wjTiXtkS6ZNzSQuMzBStQ7TFyTo
zg=
X-UI-Out-Filterresults: notjunk:1;V01:K0:u3O4dH1+7aY=:O2rhF8YAcLAZBvVotCWk1O
j8APqt1xYw/8j9B3/Ib6TZ62GmUDk+mzgtAif6oUed79oOLXOqIsE8K0tMMQFoqV/D+TiXAzm
lNbpKPPQvwh6QsHKOlg8yYos89xajgD+hOlHCS3lwOsilddCsTBJmfVquy/yrvRZ/UXgidk1y
/hSiJmHSEFMwa2sOtzNC3IgOqNw6YqzMAhvNW9aQP6g5A5IGRWksu85eDxkKej4Za6jusDkGR
6eZILuDY25QpkzBu2pivnWEFLFlC40Jy2QlCnuoD4aA9Z1B6OHl4lETNYsMAvwm8IrZdakBnb
NtkjZJs+SSmHgLdJVGS5mw5UkPsSfk2twARzvkY2YlkgTbdl/I9uztvg+eCeC9Z7m/iadWGHl
SD7bVV8IpSi1REtGfgAt6r8Gauwxr+QgL39KjvOZlla7q4tn4m4hj5K1eBJJmfTHWyi//AghR
Ell6OeD5b/FvVL706E2mTlFP+1eZK2bcjV8/btG4tt4UEK6pM2+HrcSsEhSgGrXHnsTEZxY/8
WRRBHpLNG1RKvO6LNQPv318Pm3XpnugX31J1EqkizJGjOkGSXK/vI7+ED1HAYhJw/4fqOdvyL
Kx087deRpgj4SK3rO/17pKrlQ6aDO2JQvRQpMloYKBdRZraXgpv0x/GA==

 




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel