Re: [wsjt-devel] Hashed callsign collisions?

[Paul Kube via wsjt-devel]

I would not be surprised if only the main call is used to compute the hash.
Then this admittedly rare and apparently unforseen case, the same main call
being used by multiple different stations at the same time,
distinguished only by their slash "decoration", arises. Result: collisions
among W1AW slash whatever calls.

73, Paul K6PO

On Fri, Jan 20, 2023 at 1:46 PM George J Molnar via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I had the same thing happen - as if the hash is the same for both /0 and
> /7, so they both respond.
>
>
>
> *George J Molnar, KF2T*
> FM19ma - Maryland, USA
>
>
>
>
>
>
>
> On Jan 20, 2023, at 3:56 PM, Jon Anhold via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> I was just on 20m trying to work W1AW/7, and W1AW/0 answered me, twice -
> is this a known issue with longer/hashed callsigns?
>
> 
>
> 73 de KM8V Jon
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib errors please for RC4 #hamlib

[Paul Kube via wsjt-devel]

Hi Michael --

I have only so far seen warnings about dropped audio samples as shown
below. I guess these have nothing in particular to do with Hamlib, but if
you want more details, please let me know.  73, Paul K6PO

[SYSLOG][2022-09-15 04:46:35.661153][00:00:00.000650][info] Log Start
[SYSLOG][2022-09-15 04:46:35.661153][00:00:00.000719][info] WSJT-X - ForEW1
  v2.6.0-rc4 c35798  by K1JT et al. - Program startup
[SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013098][info] locale:
language: English script: Latin country: United States ui-languages: en-US
[SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013300][info] Loaded base
translation file from :/Translations based on language en
[SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013336][info] Loaded
translation file from :/Translations based on language en
[SYSLOG][2022-09-15 04:46:35.723639][00:00:00.061776][info] shmem size:
48275456
[RIGCTRL][2022-09-15 04:46:35.754882][00:00:00.088692][info] Hamlib
version: Hamlib 4.5~git Sun Sep 04 16:38:41 2022 + SHA=6c746c
[SYSLOG][2022-09-15 04:46:59.410039][00:00:23.736465][warning] Detected
dropped audio source samples: 2304 (0.048 S)
[SYSLOG][2022-09-15 04:50:29.415028][00:03:53.740578][warning] Detected
dropped audio source samples: 624 (0.013 S)
[SYSLOG][2022-09-15 04:52:59.388463][00:06:23.713997][warning] Detected
dropped audio source samples: 576 (0.012 S)
[SYSLOG][2022-09-15 04:55:29.390469][00:08:53.716504][warning] Detected
dropped audio source samples: 672 (0.014 S)
[SYSLOG][2022-09-15 04:55:59.380954][00:09:23.706202][warning] Detected
dropped audio source samples: 528 (0.011 S)
...

On Wed, Sep 14, 2022 at 3:13 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> If everyone running RC4 would please check their wsjtx_syslog.log file and
> see if there are any hamlib errors I would appreciate it.  If
> errors/warning are seen please send the log to me
>
> Getting ready to release Hamlib 4.5 and would like to ensure all is
> working well.
>
> For Windows
> C:\Users\[username]\AppData\Local\WSJT-X\wsjtx_syslog.dat
> For Linux
> /home/[username]\.local\share\WSJT-X\wsjtx_syslog.dat
>
> And RC4 version is not available for MacOS so no testing for Macs is
> needed.
>
> Mike W9MDB
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal

[Paul Kube via wsjt-devel]

On Fri, Jan 7, 2022 at 1:25 AM Fons Adriaensen via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> On Thu, Jan 06, 2022 at 09:48:22PM -0800, Paul Kube via wsjt-devel wrote:
>
> > Any change to audio device availability on MS Windows is likely to
> renumber
> > the indexes of other devices, when this happens WSJT-X gets no
> notification
> > that it has happened.
>
> So does this mean that when a new audio device becomes available
> while a music app is playing some file, the output from that
> app would be redirected to some other device ?
>

No, rather it seems to be a result of what happens when an audio device in
use becomes unavailable. For example, headphones get unplugged, or an HDMI
monitor goes into sleep mode, etc. Then it kind of makes sense that Windows
would try to find another device that applications can use. Of course, it
does this badly, not always correctly restoring connections when the device
becomes available again.

Isn't the real issue here that WSJT is opening and closing the audio
> devices again and again for each RX or TX cycle ?
>

I don't think so; have you looked at the source code, or traced audio
subsystem calls?

73, Paul K6PO


>
>
>
> ___
> 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] The #$&% Windows 10 audio issue, and a proposal

[Paul Kube via wsjt-devel]

The problem is well known. As Bill G4WJS put it:

Any change to audio device availability on MS Windows is likely to renumber
> the indexes of other devices, when this happens WSJT-X gets no notification
> that it has happened.


That's an awful way to run an audio subsystem, and I'm sure it annoys more
than WSJT-X users, but we're not likely to get Microsoft to change it.

Bill goes on:

There is no practical solution that I am aware of, we get a device index
> when we initially enumerate the available devices and that index is used to
> address the selected device to send or receive audio samples. Short of
> re-enumerating audio devices just before any significant action with audio I
> don't see a solution. Note re-enumerating takes time which we do not
> usually have at the point it would be necessary.


 I suppose Bill is right that you don't want always to automatically
re-enumerate devices before each transmit cycle "just in case". But let me
suggest a practical partial solution.

There are two ways at present to force a WSJT-X re-enumeration of audio
devices that I know of: (1) Kill and restart WSJT-X, or (2) Switch WSJT-X
to another Configuration, and then switch back. Both of these really take
too much time, but then they are doing a lot more than just re-enumerating
the audio devices.

So my suggestion: add a *Reset Audio* menu item (under File or Tools, say)
that lets the operator manually trigger audio device re-enumeration, and
nothing else, when needed. Should be fast!

A small thing, sir, but my own.

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

Re: [wsjt-devel] FT4 logging prompt

[Paul Kube]

>
> WSJT-X is open source.  You can make those changes you are suggesting,
> thereby customizing your station operations.


Yes I know that. But:

 However, do not be surprised if you actually loose a lot of
> confirmations... My station.  My logbook.  My rules.


Yes and so my proposal is to make the "short QSO" the default for WWDIGI.
The contest's rules, that everybody in the contest plays by. Contesters
will like the higher QSO rates. Maybe it will catch on more generally,
maybe not.

And I would be happy to implement this as a patch against 2.4.0-rc4 or
whatever version, if I had reason to think it would be accepted.

73, Paul K6PO


On Fri, May 7, 2021 at 5:34 PM Jeff Stillinger via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> WSJT-X is open source.  You can make those changes you are suggesting,
> thereby customizing your station operations.   There is no licensing
> restrictions that would stop you from doing so (see GPL 3).
>
> However, do not be surprised if you actually loose a lot of
> confirmations.   Yes, I am one of those stations that expect the basic
> exchange format as outlined in the User Guide to be completed in order to
> be confirmed.   My station.  My logbook.  My rules.   I will always
> complete any QSO regardless.  I just don't log for confirmation the ones
> that have missing pieces.  I strongly believe this helps maintain the
> integrity of awards.   But...  that is me.   Someone else may feel
> differently.   It's all good in the rf hood.
>
>
>
>
> On 5/6/21 3:28 PM, Martin Davies G0HDB wrote:
>
> The FT4 mode was introduced in WSJT-X version 2.1.0 in 2019; the release
> notes and announcements state that the mode is intended for use in HF
> digital contesting where 'quick-fire' exchanges such as those achieved
> using RTTY are desired.  I'd like to suggest a change that would help
> achieve this aim a bit better; the following applies to v2.1.0 and all
> subsequent versions up to and including v2.3.1 (I haven't yet tried any of
> the RC versions of v2.4.0).
>
> An FT4 (and an FT8!) QSO generally looks something like the following:
>
> CQ K1JT FN20
>   K1JT G0HDB IO82
> G0HDB K1JT -10
>   K1JT G0HDB R-08
> G0HDB K1JT RR73
>   K1JT G0HDB 73
>
> Currently, the logging window only pops open on my screen to prompt me to
> log the QSO when the final (Tx5) '73' message is being sent - this is to
> all extents and purposes superfluous because the QSO has been successfully
> completed when K1JT has sent his RR73 (and I've received it).  My sending
> the superfluous '73' message extends the overall duration of the QSO by
> adding a further Tx period at my end of the sequence so I can't move on to
> trying to start the next QSO.
>
> I'd like to suggest that the logging window is opened when I've *received*
> the other station's RR73 message and that sending the final Tx5 '73'
> message is either removed from the sequence altogether or is made
> optional.  This would help to improve the overall throughput of FT4 QSOs.
>
> The code to open the logging window on receipt of an incoming 'RR73'
> message and to desist from sending the Tx5 '73' message must already exist
> within the app because that's what already happens when I operate as a
> Hound in FT8 Fox & Hounds mode - when I receive the Fox's 'RR73' the
> logging window pops open and my system doesn't send the unnecessary Tx5
> '73' .
>
> I'd actually like to see the logging window open in any mode when I either
> send *or receive* an RRR or RR73 message - in my opinion that would align
> the prompting to log the QSO much more closely with the completion of the
> exchange of the essential information for the QSO and would leave the
> sending of a final '73' as an optional nicety.
>
> --
> 73, Martin G0HDB
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_6602682828413212526_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
> Jeff Stillinger - KB6IBB
> KB6IBB Laboratories
> Wylie, Texas - United States
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 logging prompt

[Paul Kube]

I agree with Martin and others, but let me suggest a slight compromise.

Instead of changing the default sequence for all FT4 QSO's, change it for
FT8/FT4 in WWDIGI contest mode only, and advertise the change. This won't
disrupt anyone's ideas about how general FT QSO's should be done;
contesters will understand the change, and appreciate it. 2021 WWDIGI is
August 28-29; should be time enough to implement it.

In more detail:


   1. Eliminate Tx5, “73”, from the default QSO message sequence. Its use
   should be discouraged in WWDIGI (and in fact in all FT4/FT8 contests). It
   is not needed for the exchange and acknowledgement of required information,
   and – because  its use is not widely understood not to be required --  just
   leads to longer QSO’s on average, and general confusion about whether a QSO
   has been completed which increases NIL’s.

   Since in WWDIGI  the only exchange info is callsigns and grids, the
   default QSO -- exchanging and acknowledging all required information --
   could be as short as 3 transmissions. Examples:
  1. Answering a CQ:
  CQ WW W0YK DM97  Tx6
  W0YK K6PO R DM12   Tx3
  K6PO W0YK RR73 Tx4
  2. Tailending a QSO. K6PO has already copied W0YK’s grid. Then:
  W1AW W0YK RR73  Tx4
  W0YK K6PO R DM12   Tx3
  K6PO W0YK RR73 Tx4
  3. Tailending a QSO. K6PO has not yet copied W0YK’s grid. Then:
  W1AW W0YK RR73  Tx4
  W0YK K6PO DM12   Tx2
  K6PO W0YK R DM97   Tx3
  W0YK K6PO RR73 Tx4

  2. Automatically log the QSO sending *or receiving* Tx4, “RR73”. One
   reason sending Tx5, “73”, is currently in the default QSO sequence for
   WWDIGI is that this triggers automatic logging of the QSO from  WSJT-X. Tx5
   is never sent in examples 1a-1c above, and so one QSO partner would need to
   manually log the QSO in each case (i.e. hit the “Log QSO” button in WSJT-X,
   and in the case of 1b, perhaps also manually enter the copied grid). If
   automatic logging is desired, triggering it on sending *or receiving*
   Tx4 would accomplish that.

   3. Note: in some of the examples above, part of the contest exchange
   (the grid) is not explicitly sent from the first QSO partner (W0YK) to the
   second (K6PO). Some might object to this, but note that it is copied by the
   second QSO partner as part of the first partner’s CQ or other transmission,
   and so this  is as much or more in the spirit of 2-way over-the-air
   communication as commonly used contest techniques like call history files,
   giving your call only once every few QSO’s in a run, etc.


73, Paul K6PO

On Thu, May 6, 2021 at 1:34 PM Martin Davies G0HDB 
wrote:

> The FT4 mode was introduced in WSJT-X version 2.1.0 in 2019; the release
> notes and announcements state that the mode is intended for use in HF
> digital contesting where 'quick-fire' exchanges such as those achieved
> using RTTY are desired.  I'd like to suggest a change that would help
> achieve this aim a bit better; the following applies to v2.1.0 and all
> subsequent versions up to and including v2.3.1 (I haven't yet tried any of
> the RC versions of v2.4.0).
>
> An FT4 (and an FT8!) QSO generally looks something like the following:
>
> CQ K1JT FN20
>   K1JT G0HDB IO82
> G0HDB K1JT -10
>   K1JT G0HDB R-08
> G0HDB K1JT RR73
>   K1JT G0HDB 73
>
> Currently, the logging window only pops open on my screen to prompt me to
> log the QSO when the final (Tx5) '73' message is being sent - this is to
> all extents and purposes superfluous because the QSO has been successfully
> completed when K1JT has sent his RR73 (and I've received it).  My sending
> the superfluous '73' message extends the overall duration of the QSO by
> adding a further Tx period at my end of the sequence so I can't move on to
> trying to start the next QSO.
>
> I'd like to suggest that the logging window is opened when I've *received*
> the other station's RR73 message and that sending the final Tx5 '73'
> message is either removed from the sequence altogether or is made
> optional.  This would help to improve the overall throughput of FT4 QSOs.
>
> The code to open the logging window on receipt of an incoming 'RR73'
> message and to desist from sending the Tx5 '73' message must already exist
> within the app because that's what already happens when I operate as a
> Hound in FT8 Fox & Hounds mode - when I receive the Fox's 'RR73' the
> logging window pops open and my system doesn't send the unnecessary Tx5
> '73' .
>
> I'd actually like to see the logging window open in any mode when I either
> send *or receive* an RRR or RR73 message - in my opinion that would align
> the prompting to log the QSO much more closely with the completion of the
> exchange of the essential information for the QSO and would leave the
> sending of a final '73' as an optional nicety.
>
> -

Re: [wsjt-devel] The FT4 and FT8 Communication Protocols

[Paul Kube]

Interesting to see how FT4 outperforms FT8 (by a lot!) in the high-latitude
moderately disturbed channel model.

Question: am I understanding correctly that the standard message payload
devotes two whole bits for callsign suffixes /p and /r? (So it is
theoretically possible to have a call using both?) Since these suffixes are
so rare in practice I wonder if in retrospect you think this is a perhaps
regrettable use of the message payload.

73, Paul K6PO

On Fri, Jun 12, 2020 at 11:52 AM Joe Taylor  wrote:

> If you're interested in how the FT4 and FT8 modes work, and how they are
> implemented in WSJT-X, you can find all the technical details in a
> paper by Steve Franke, K9AN, Bill Somerville, G4WJS, and Joe Taylor,
> K1JT, published in the July/August issue of QEX.
>
> A copy has been posted on the WSJT web site here:
> https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf
>
> -- 73, Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trans-Atlantic 6m opening

[Paul Kube]

Needed a couple more Es hops for US west coast folks to participate! We may
have to wait for the F layer to light up for that path to work for us
though.

I appreciate your recommendation of FT4 for these snapshot openings, and
that raises a question: Does it make sense to try using ISCAT for this?
Some of the E layer patches seem so small and fast-moving it is almost like
a meteor burn.

73, Paul K6PO




On Sun, Jun 7, 2020 at 6:16 PM Joe Taylor  wrote:

> Hi all,
>
> I know that like me, some of you enjoyed today's excellent multi-hop
> sporadic E opening across the Atlantic.  It was an excellent test of the
> original design goals of FT8, and more recently also FT4.
>
> Over a span of several hours I completed 76 QSOs with European stations.
>   Of these 37 were with FT8 on 50.313 (mostly) or 50.323 MHz.  The
> remaining 39 QSOs used FT4 on 50.318, and took place in just 44 minutes.
>
> I strongly recommend that for such openings in the future you should try
> FT4.  It's twice as fast as FT8, with only a 3 dB penalty on the AWGN
> channel.  The sensitivity penalty is even less on a fading channel.
>
> Today's conditions also provided an excellent chance to take advantage
> of good operating practices.  As recommended, most European stations
> transmitted "in the "1st/Even" sequence in both FT4 nd FT8.  North
> American stations transmitted in second sequence.  This procedure
> minimizes QRN from strong local stations and helps everyone to work DX.
>
> -- 73, Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] calling CQ every 2nd round

[Paul Kube]

On Mon, May 25, 2020 at 3:33 PM Rik Strobbe  wrote:

>
> For now I do the manually (via the enable TX button), but if others find
> this useful as well it might be considered to add it as an option in WSJT-X?
>

In my opinion, this should be the default, for FT8 and FT4.

73, Paul K6PO

___
> 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] Clicking on RR73 produced wrong TX response msg

[Paul Kube]

On Wed, May 20, 2020 at 2:05 PM Gary McDuffie  wrote:

>
> If you call letting him know that you got his acknowledgement of your
> report a courtesy, I guess so.  I call it a necessity in order to allow him
> to move on.  If I don’t send the 73, it means I didn’t get his RR73.  If he
> doesn’t finish, he isn’t in the log.
>

If you didn't get his RR73 (Tx4), certainly the thing to do is to resend
your report (Tx3), no?

On the other hand, if you did get his RR73, you can consider the QSO
completed, and respond in whatever way you want. At least, that's the view
I've come to after using the FT* modes since they were invented. Was it
"really" a QSO? I'll let LoTW or the contest logcheck software sort it out.

A special case is when I see a station I've worked sending RR73 again. That
shows they're probably expecting a 73 from me and didn't get it. So in that
case I'll send 73 (Tx5, which is totally customizable, there's even a TX
Macros page in Settings that lets you create a whole library of them). But
that almost never happens anymore.

73, Paul K6PO


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

Re: [wsjt-devel] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

[Paul Kube]

An oddity related to this is that checking "Allow Tx Frequency Changes
While Transmitting" is required not just for Tx, but also for Rx frequency
changes while transmitting. When not checked, when transmitting, both Tx
and Rx spinners are grayed out, and left-clicking on the waterfall does
nothing. A small thing, but was there in 2.1 also.

Now 2.2.0-rc1, Windows 10 Pro 64 bit, IC-7300 via USB connection.

73, Paul K6PO



On Mon, May 18, 2020 at 9:21 PM Stephen VK3SIR  wrote:

> Hi Folks,
>
> Does the "Allow Tx Frequency Changes While Transmitting"
> (File/Settings/General Tab) when not-checked function as intended?
>
> My expectation would be that if disabled that any frequency changes
> observed in the Tx spin-box widget on the Main Window should be delayed
> until the end of the cycle and should not be immediate (or perhaps these
> boxes disabled until the end of the cycle) under this circumstance.
>
> I just performed a slight frequency change on 20m while transmitting and
> noted that in the "Rx Frequency Window" that a frequency change during the
> Tx cycle from 851 to 899 to 900 Hz was noted.
>
> 035400  Tx   851 ~  CQ VK3VM QF11
> 035405  Tx   851 ~  CQ VK3VM QF11
> 035408  Tx   851 ~  CQ VK3VM QF11
> 035410  Tx   899 ~  CQ VK3VM QF11
> 035430  Tx   900 ~  CQ VK3VM QF11
> 035500  Tx   900 ~  CQ VK3VM QF11
>
> I have also observed some frequency shifts on waterfalls that may or may
> not be related to this.
>
> I cannot recall any inquiry on this so far and if I have missed it my
> apologies.
>
> 73
>
> Steve I
> VK3VM / VK3SIR
>
>
> ___
> 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 2.2.0-rc1

[Paul Kube]

Hello Bill,


> Here is a little more data on this.
>
> Here's a screenshot showing the issue. KG8DH is transmitting in
> even periods. Red arrows show where his signal is decoded but grouped with
> the previous odd period. This I guess might just be an issue of the "80m"
> separator not being inserted before his decode is displayed. Green arrow
> shows one of his decodes correctly displayed. His signal is stronger in
> that period, and I suspect is was decoded in an earlier pass than the
> problem cases
> [image: decode07.PNG]
>
> (I think I said in an earlier email that this issue involves incorrect
> timestamps, but shown here the timestamps are correct, it's just the decode
> pane's grouping that's confused.)
>
> Another thing. Here's a screenshot of the decodes replayed from the saved
> wav files. Now KG8DH's 093130 decode is grouped correctly (first green
> arrow), but interestingly his 093230 transmission doesn't appear at all.
> Are the new 2.2 decode passes being applied during wav file replays?
>
> [image: decode07-replay.PNG]
>
> I hope this helps in some way. Those 8 wav files are too big to email to
> you via this mailing list, if you'd like them let me know how to get them
> to you.
>
> 73, Paul K6PO
>
>
> On Thu, May 14, 2020 at 3:46 AM Bill Somerville 
> wrote:
>
>> HI Paul,
>>
>> thanks for that clarification, we too are finding this issue hard to
>> reproduce so be patient, we will sort it out eventually.
>>
>> 73
>> Bill
>> G4WJS.
>>
>> On 14/05/2020 4:09, Paul Kube wrote:
>>
>> Hi Bill,
>>
>> Yes this is with v2.2.0-rc1, Win 10 64 bit.
>>
>> As I recall, it only occurred when there was just one late decode, and no
>> decodes in the following period. It happened several times in quick
>> succession, but I failed to get a screenshot or any more clues; and I
>> haven't seen it again. I apologize for such a sketchy bug report. I'll try
>> to reproduce it and let you know.
>>
>> Meanwhile, thanks for all your hard work on this. I'm liking this new
>> release a lot.
>>
>> 73, Paul K6PO
>>
>> On Tue, May 12, 2020 at 6:11 PM Bill Somerville 
>> wrote:
>>
>>> On 13/05/2020 02:01, Paul Kube wrote:
>>>
>>> On Tue, May 12, 2020 at 1:29 PM Bill Somerville 
>>> wrote:
>>>
>>>>   Most users will see ... more decodes overall with the last few maybe
>>>> only printing some time into the following period.
>>>>
>>>> On this point: When a signal is sent in a period, but decoded in the
>>> next period, I have seen the transmission appear with the "wrong" timestamp
>>> in the Band Activity pane.
>>>
>>> 73, Paul K6PO
>>>
>>> Paul,
>>>
>>> are you observing this behaviour in WSJT-X v2.2.0 RC1, or in a prior
>>> version?
>>>
>>
>> ___
>> 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 2.2.0-rc1

[Paul Kube]

Hi Bill,

Yes this is with v2.2.0-rc1, Win 10 64 bit.

As I recall, it only occurred when there was just one late decode, and no
decodes in the following period. It happened several times in quick
succession, but I failed to get a screenshot or any more clues; and I
haven't seen it again. I apologize for such a sketchy bug report. I'll try
to reproduce it and let you know.

Meanwhile, thanks for all your hard work on this. I'm liking this new
release a lot.

73, Paul K6PO

On Tue, May 12, 2020 at 6:11 PM Bill Somerville 
wrote:

> On 13/05/2020 02:01, Paul Kube wrote:
>
> On Tue, May 12, 2020 at 1:29 PM Bill Somerville 
> wrote:
>
>>   Most users will see ... more decodes overall with the last few maybe
>> only printing some time into the following period.
>>
>> On this point: When a signal is sent in a period, but decoded in the next
> period, I have seen the transmission appear with the "wrong" timestamp in
> the Band Activity pane.
>
> 73, Paul K6PO
>
> Paul,
>
> are you observing this behaviour in WSJT-X v2.2.0 RC1, or in a prior
> version?
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc1

[Paul Kube]

On Tue, May 12, 2020 at 1:29 PM Bill Somerville 
wrote:

>   Most users will see ... more decodes overall with the last few maybe
> only printing some time into the following period.
>
> On this point: When a signal is sent in a period, but decoded in the next
period, I have seen the transmission appear with the "wrong" timestamp in
the Band Activity pane.

73, Paul K6PO


___
> 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] Killing the TX stream

[Paul Kube]

On Fri, Apr 3, 2020 at 1:42 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> You should not be selecting "default" for WSJT-X.  Select your rig sound
> card instead and that problem will go away.
>

One would think that would be true. But one would be wrong.

I've reported this before, and so have several others. Windows 10 sound
configuration is such a giant kludge at this point that it is obscure
whether it's a problem on WSJT-X's side or not, but it is a problem. To
wit: In WSJT-X v2.1.2, Settings Audio Soundcard, select the proper USB
codec for both Input and Output. In Windows 10, Settings Sound App volume
and device preferences, select the same USB codec for both Output and Input
for WSJT-X. Now make some change to your computer's sound devices. For
example, unplug and replug a headphone. Should have no effect on WSJT-X,
right? But WSJT-X's output is now disabled, and it needs to be restarted.


> And..your rig sound device should not be the default...when it is all your
> computer boops and beeps will go out your rig.
>

That, on the other hand is easy to fix. Mute System Sounds on that device,
and that problem will go away.

73, Paul K6PO


> On Friday, April 3, 2020, 03:30:51 PM CDT, Al  wrote:
>
>
> I don't know how much of this is windows vs WSJT-X...
>
> Assuming the WSJT-X has a properly configured output sound device and
> verified working on TX...
>
> 1) If the default windows sound device is changed after WSJT-X is started
> then there is no TX stream on TX until A) WSJT-X is restarted or B) a
> different output sound device is selected in WSJT-X
>
> 2) If the default sound device is changed while WSJT-X is transmitting the
> current TX stream will complete but there will be no TX stream on the
> following TX cycles.
>
> Given that Windows feels free to change default sound devices on its own (
> plugging/unplugging a speaker or adding removing a usb/hdmi sound device )
> ..
>
> AL, K0VM
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X+OmniRig+IC-7300 : DATA mode not set for VFO-B

[Paul Kube]

One workaround for this is to use WSJT-X's "Fake it" instead of "Rig" for
split operation. "Fake it" uses only one VFO, so it doesn't matter what the
other VFO's mode is.

"Fake it" works very well with the IC-7300; I haven't found any reason not
to use it.

73, Paul K6PO

On Wed, Mar 25, 2020 at 11:39 AM Zeev Stadler 
wrote:

> Hello All,
>
> My configuration is:
>
>- WSJT-X 2.1.2 on Windows 10 Home, "Split Operation"="Rig",
>"Mode"="Data/Pkt"
>- Icom IC-7300
>- OmniRig 1.19 with "IC-7300-DATA" rig profile
>
> I recently noticed that sometimes there is no output power when WSJT-X
> puts the rig in transmit mode.
> When starting WSJT-X after operating in "Phone" SSB mode, VFO-B remains in
> "USB" mode rather than use "USB-D" (data) mode.
> If I manually change VFO-B to "USB-D" and continue to use WSJT-X,
> transmission works as expected.
>
> Attached is and Omnirig log file saved from this scenario:
>
>- Set VFO-B to "USB" mode, turn-off split mode
>- Execute WSJT-X
>- Click "Tune"
>- Click "Tune" again
>- Exit
>
> Best regards and 73,
> Zeev
> 4X5ZS
> ___
> 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] How to set up for WSJT-X development?

[Paul Kube]

Hi Bill --



On Mon, Jan 20, 2020 at 8:53 AM Bill Somerville 
wrote:

> You could use the tarball as a starting point for casual development but
> cloning the official public git repository is best for anything other than
> the simplest of development.
>

Sounds good to me, I'd like to get that working.

> The errors you show above are due to you not having a recent version of
> Hamlib built for use with WSJT-X, the versions of Hamlib in most (probably
> all) Linux repositiories are too old. You should be able to clone the
> official Hamlib git repo and build the master branch for use with WSJT-X.
> You should configure the Hamlib build to build a static library and its
> probably best to install that locally in your own directories using the
> --prefix option of configure. Once you have a locally installed Hamlib you
> can tell the WSJT-X CMake build script where to find it using the
> configuration variable CMAKE_PREFIX_PATH which should include the root
> directory of your locally install Hamlib package.
>
Bill, I did all that. As I said, I followed your
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL. To wit:

$ mkdir ~/hamlib-prefix
> $ cd ~/hamlib-prefix
> $ git clone git://git.code.sf.net/u/bsomervi/hamlib src
> $ cd src
> $ git checkout integration
> $ ./bootstrap
> $ mkdir ../build
> $ cd ../build
> $ ../src/configure --prefix=$HOME/hamlib-prefix \
>--disable-shared --enable-static \
>--without-cxx-binding --disable-winradio \
>CFLAGS="-g -O2 -fdata-sections -ffunction-sections" \
>LDFLAGS="-Wl,--gc-sections"
> $ make
> $ make install-strip
> $ mkdir -p ~/wsjtx-prefix/build
> $ cd ~/wsjtx-prefix
> $ git clone git://git.code.sf.net/p/wsjt/wsjtx src
> $ cd ~/wsjtx-prefix/build
> $ cmake -D CMAKE_PREFIX_PATH=~/hamlib-prefix ../src
> $ cmake --build .
> $ cmake --build . --target install


The next to last line, cmake --build ., dies with those unresolved symbols
in HamlibTransceiver.cpp. I've taken care not to have any other hamlib
packages installed on this machine. So it seems to me that something
in  git://git.code.sf.net/u/bsomervi/hamlib or  git://
git.code.sf.net/p/wsjt/wsjtx is wrong.

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

[wsjt-devel] How to set up for WSJT-X development?

[Paul Kube]

A simple question: Suppose I want to do a little WSJT-X development...
experimenting with new features, bug fixing, submitting the occasional
patch. I'll be coding on Linux, but will want to compile for Windows as
well as Linux for testing. (Not particularly interested in building my own
source tarball.)  What's the best way to do this now?

I can build from
https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/wsjtx-2.1.2.tgz

just
fine; but I've seen email saying the repository has moved to git, so I'm
not sure that tarball is up to date. On the other hand, following the
git-centric instructions at
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL, the build dies
with errors like:

wsjtx-prefix/src/HamlibTransceiver.cpp:590:66: error:
‘RIG_PASSBAND_NOCHANGE’ was not declared in this scope
   rig_set_mode (rig_.data (), RIG_VFO_CURR, dummy_mode_,
RIG_PASSBAND_NOCHANGE);

wsjtx-prefix/src/HamlibTransceiver.cpp:811:32: error:
‘rig_set_split_freq_mode’ was not declared in this scope
   error_check (rig_set_split_freq_mode (rig_.data (),
RIG_VFO_CURR, tx, new_mode, RIG_PASSBAND_NOCHANGE), tr ("setting split TX
frequency and mode"));

[BTW: Attempting to answer my question with a web search turns up the
promising looking WSJT Developers Guide
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/dev-guide-main.html,
but that begins with a notice that it's obsolete, and to use
https://sourceforge.net/projects/jtsdk/ instead. OK fine, I go there, and
from there to https://sourceforge.net/projects/jtsdk/files/linux/ for the
Linux version, which page tells me the repository has been moved to github
at https://github.com/KI7MT/jtsdk-nix. There I see the announcement that
"This project is no longer under active development", "Those wishing to use
JTSDK should follow the JTSDK .Net Core cross-patform project instead."
Right, OK, but the page https://github.com/KI7MT/jtsdk-tools for that
project only says "Linux - Coming Soon!" A dead end.]

Thanks for any help,

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

Re: [wsjt-devel] RTTY

[Paul Kube]

On Fri, Jan 17, 2020 at 8:21 AM Frank Kirschner  wrote:

> All I suggested was that improving the software discriminator in a RTTY
> program might produce a useful improvement in noise performance.
>

Frank, in my opinion you are lobbying the wrong developers here. If there
are ideas in WSJT-X that could significantly improve 170 Hz 45.45 RTTY
decoding, it's the RTTY decoder developers who are in the best position to
implement them. WSJT-X code is GPL'd; point the RTTY folks to the relevant
parts and tell them to have at it.


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

Now that just seems wrong-headed. There is nothing in WSJT-X that
recommends itself as a framework for a conversational mode like RTTY.

73, Paul K6PO

On Fri, Jan 17, 2020 at 8:21 AM Frank Kirschner  wrote:

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

Re: [wsjt-devel] Not a Bug, But a PITA

[Paul Kube]

>  WSJT-X's tendency to change frequencies when you switch in or out of
contest, fox / hound mode, etc is annoying and unexpected.

Fortunately the frequency is prominently displayed in the WSJT-X window
(and on the front of my radio). I've learned to always check it after any
mode or band change, and adjust as necessary. Not hard to do, just hard to
remember to do at first.

I think Jim K9YC was complaining about a slightly different thing though:
WSJT-X decodes when displayed are only tagged with the band and audio
offset, not the exact base VFO frequency, and that would be useful
sometimes.

73, Paul K6PO


On Sat, Dec 21, 2019 at 2:17 PM Jon Anhold  wrote:

> I agree that WSJT-X's tendency to change frequencies when you switch in or
> out of contest, fox / hound mode, etc is annoying and unexpected.
>
> On Sat, Dec 21, 2019 at 3:50 PM Jim Brown 
> wrote:
>
>> This morning, I fired up to work AG6EE on 6M with MSK144 on an
>> expedition to a couple of rare grids in the desert along the US/Mexico
>> border. He was on 50.265 to stay out of the way of casual QRM, and I
>> worked him in one of those grids yesterday. This morning, online chat
>> told me he was now using NA VHF Contest mode, so I set that and returned
>> to monitoring. When I did, WSJT-X moved me to 50.260. I had a bunch of
>> decodes on the screen from before I had switched to Contest mode, and I
>> wasn't certain whether I had been on .260 or .265 when I decoded them.
>> MUCH wasted time figuring that out. PITA
>>
>> 73, Jim K9YC
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[Paul Kube]

On Tue, Dec 17, 2019 at 2:53 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> v2.1.2
>
> We're getting an inconsistent and somewhat hard to reproduce situation
> where on an IC-7300 VFOB is not getting set to USB-D.
>

I have seen this also. My setup runs WSJT-X through N1MM+ using DX Lab
Commander radio setting, then through Win4IcomSuite to the IC-7300, and
tracking it down the culprit in that chain was taking time, so I just
changed WSJT-X to use "Fake It" instead of Split; problem solved for me.
But I could go back to Split and collect some data if it would help.

73, Paul K6PO


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

Re: [wsjt-devel] Problem with radio's audio input

[Paul Kube]

On Mon, Dec 2, 2019 at 4:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Audio dropout like this is usually caused by the USB audio device
> disconnecting.
> And that is usually case by RFI.
>

I had a dropout problem where WSJT-X audio output would occasionally switch
from the desired "Speakers (5- USB Audio CODEC)" to "Headphones (High
Definition Audio Device)" when I had headphones plugged in to my Windows 10
desktop machine. This of course caused loss of transmitter modulation. Kind
of a mystery, since I had only the USB codec selected as output for WSJT-X
both in WSJT-X's settings Audio tab and in Windows sound settings; I don't
know why Windows should ever take it upon itself to re-route that.

I tried ferrites on the headphone cable to fix this. Ultimately lots of
ferrites, including 10 turns through a 3/4" I.D. mix 31. (I already have
chokes on everything else, and no RFI-like problems except for this.) It
didn't help! But unplugging the headphones does eliminate the problem, so I
now just forego watching Netflix while working FT8 :).

Anyway, if you're having problems with TX audio dropout with Windows 10,
try popping up the Volume Mixer to see which output devices are connected
to WSJT-X; maybe the operating system has switched to using something other
than the one you want.

73, Paul K6PO



On Mon, Dec 2, 2019 at 4:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Audio dropout like this is usually caused by the USB audio device
> disconnecting.
> And that is usually case by RFI.  Chokes on USB cables (and all other
> cables) usually solves the problem.
> Ensure your ethernet cables are shielded too.  Newer CAT 7 or CAT 8 cables
> are already shielded.  And ground your ethernet hub too (most don't have a
> built-in ground)
> I even put chokes on all my power lines going into the breaker box to
> reduce what's riding on the power.
>
> And, if you have an outside round rod (like many I have helped) that is
> not tied to the house ground either stop using it (and use the house
> ground) or tie the outside rod to the house ground properly.  That has also
> solved many RFI problems.
>
> de Mike W9MDB
>
>
>
>
> On Monday, December 2, 2019, 05:26:25 AM CST, Claude Frantz <
> claude.fra...@bayern-mail.de> wrote:
>
>
> On 12/1/19 10:46 PM, Frederic Beaulieu wrote:
>
> Hi Frederic,
>
> > I start to notice on my IC-7300's audio scope that occasionnaly, no
> > audio was sent to the radio. The problem seems to get worse (more
> > frequent) and now I'm seeing a kind of noise at the beginning of many
> > of my transmission. Anyone knows how I could verify if it is a
> > problem with my radio, the sound card (which is embedded in the radio
> > I think) or the WSJT-X software?
> This problem of occasional no audio output has been reported here by
> various users, included myself. I have encountered it while running with
> Windows XP and using Linux, on different hardware. I cannot remember
> that an valuable diagnostic has been reported about the reasons of these
> sporadic recurrences.
>
> Best wishes,
> Claude (DJ0OT)
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] State QSO Parties

[Paul Kube]

On Thu, Sep 26, 2019 at 10:03 PM David Gilbert 
wrote:

>
> If WSJT used unique non-descriptive three letter/number combinations,
> there would easily be enough to cover every county in the United States and
> probably all of the rest of the world as well.  I.E.,  AAA, D9Y, 5V7,
> etc.  After all, 35x35x35 (I'll assume zero is protected) = 42,875.
>

The WSJT modes can code any Maidenhead square (well, minus RR73). There are
32,400 of those, so by using one of the available selector bits, it ought
to be possible to switch to an alternate locator scheme almost as rich as
what you propose. I'm not sure it would be rich enough to map to *all *the
counties, oblasts, prefectures, sections, districts etc. that will ever be
used in any contest exchange, but maybe it is.

Then there's the issue of how to manage the mapping between entries in that
selected WSJT table and all those political entities. The WSJT team would
want it to be universal, published and transparent to every user; otherwise
it involves too much of what Bill G4WJS calls "not passing all information
on air" -- I take it he is alluding to proscriptions against encrypted
amateur digital communication. I suppose that could be done, but I wouldn't
want to do it! ARRL has a hard enough time managing DXCC, which is a much
simpler problem.

73, Paul K6PO



> On 9/26/2019 12:55 PM, Ron WV4P wrote:
>
> Almost all US Counties, within the state, have a Number.
> Could, for the purposes of QSO Parties the designation be Hardin - HARN -
> 40 as would be the case of mine ? Would that help any, just using an
> already assigned number VS the County Name ? Ron WV4P
>
> On Thu, 26 Sep 2019 at 13:48, Bill Somerville 
> wrote:
>
>> On 26/09/2019 11:59, John Zantek wrote:
>> >
>> > ØThe bottom line is that there are still a handful of selectors
>> > available in the FT4/FT8/MSK144 message payload bits that could be
>> > used for new message schemes but nowhere near the number that would be
>> > needed to support a series of county based QSO parties or similar.
>> >
>> > But Bill, isn’t the FD message structure just that, with a lookup
>> > table that doesn’t exceed the payload ceiling?
>> >
>> > What’s the difference between the existing QRegularExpression
>> > field_day_exchange_re with a table of ARRL/RAC Sections and a proposed
>> > QRegularExpression WA_QSO_party_exchange_re of WA counties  as I had
>> > suggested at the start of this thread?
>> >
>> > 73 John W7CD
>> >
>> John,
>>
>> the source code you are referring to is the validation for GUI input
>> when entering one's state or province, it has no bearing on what is
>> packed into transmitted messages other than the selected value is used.
>> If you were to have a different set of information to pack into messages
>> then you must also pack into the message the selector to tell the
>> receiving decoder to interpret the message bits in the way that you
>> require. Even if your proposed table of counties only take the same
>> number of bits to store as the RTTY Roundup values do; you still need
>> another bit somewhere else in the payload to select that table. Extend
>> that to each and every QSO Party set of counties and you will need many
>> more bits to select the right table. That many bits are not available in
>> the FT4/FT8/MSK144 payload, it might be possible for one or maybe two
>> QSO Party formats but who decides which QSO Parties get support and
>> which ones are excluded?
>>
>> 73
>> Bill
>> G4WJS.
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> 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] Grid proposal

[Paul Kube]

>
>  Maybe so, but how many stns really do *not* send their grid ( except for
> long non-standard callsings )?
>

Quite a few. On Tab 1, Hover your mouse over  the Tx1 button to see the
option enabled with double click. Any station can enable this, not just
nonstandard callsigns.

Umm, no. The message length of FTx messages is the same whether grid
> locator is included in the message or not.
>
Any single FT8 transmission takes the same amount of time, but a QSO,
consisting of a mutually acknowledged exchange of call signs and signal
reports, can save one transmission if the caller skips Tx1 and uses Tx2
first:

CQ OH2GQC KP20
OH2GQC K6PO DM12
K6PO OH2GQC -10
OH2GQC K6PO R-12
K6PO OH2GQC RR73

vs.

CQ OH2GQC KP20
OH2GQC K6PO -12
K6PO OH2GQC R-10
OH2GQC K6PO RR73

Personally I have not noticed anyone being annoyed by either choice, but
then the FT modes aren't optimized for communicating annoyance.

73, Paul K6PO


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

Re: [wsjt-devel] FT4 Frequency on 40-m

[Paul Kube]

TOK, thanks Steve. If I get inspired maybe I'll fire up ft8sim and ft4sim
and run some experiments.

73, Paul K6PO

On Mon, Jul 29, 2019 at 9:35 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Paul,
>
> I don’t know the answer to your question(s).
>
> In addition to frequency separation and signal strength difference, one
> would have to consider overall signal strength (not just difference), the
> DT difference between the two signals, and the delay and Doppler spread on
> each of the two channels that are involved. There are too many dimensions
> in that parameter space!
>
> Steve k9an
>
> On Jul 28, 2019, at 8:06 PM, Paul Kube  wrote:
>
> Steve --
>
> Related to this, and to another recent thread on replying to CQ's on the
> caller's frequency:
>
> What is the decoding probability a FT8 (or FT4) signal when being
> interfered with by another FT8 (or FT4) signal, as a function of frequency
> separation and signal strength difference? Seems clear that it would not be
> appropriate to model the interfering signal as additive Gaussian noise, so
> is this even something that you can solve or nicely approximate
> analytically? I'd be interested to know.
>
> 73, Paul K6PO
>
> On Sun, Jul 28, 2019 at 7:38 AM Steven Franke via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> Hi Gene,
>>
>> FT8 is WAY MORE sensitive! (~8db)
>>
>>
>> That number is not right. On the additive white Gaussian noise (AWGN)
>> channel, the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the
>> 50% decode probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity
>> difference is therefore 3.3 dB.
>>
>> On channels with severe Doppler spreading, the threshold SNR is higher
>> for both modes, and the difference between FT8 and FT4 will decrease
>> somewhat because FT4’s larger tone separation tends to give it an advantage
>> in those cases.
>>
>> It might be of interest to some to consider that FT8 uses symbols with
>> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms
>> to send 2 bits apiece. For a given average transmitter power, the energy
>> that is transmitted per bit for FT8 is larger than the energy transmitted
>> per bit for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical
>> sensitivity difference (ignoring any differences in signal detection,
>> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB,
>> very close to the actual difference of 3.3 dB that I quoted above.
>>
>> I have no strong feelings one way or the other about your main point, but
>> I think that it’s preferable to base the discussion on accurate numbers.
>>
>>
>> FT4 is awesome for MORE contacts (i.e. contests).
>>
>> I’m sticking with FT8 for QUALITY.
>>
>> 73 de W8NET Miles / “Gene”
>> Secretary, Portage County Amateur Radio Service (PCARS)
>> 3905 Century Club - Master #47
>> DV2/W8NET in the Philippines
>> Licensed since 1974
>>
>>
>> Steve, K9AN
>>
>>
>> ___
>> 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] FT4 Frequency on 40-m

[Paul Kube]

Steve --

Related to this, and to another recent thread on replying to CQ's on the
caller's frequency:

What is the decoding probability a FT8 (or FT4) signal when being
interfered with by another FT8 (or FT4) signal, as a function of frequency
separation and signal strength difference? Seems clear that it would not be
appropriate to model the interfering signal as additive Gaussian noise, so
is this even something that you can solve or nicely approximate
analytically? I'd be interested to know.

73, Paul K6PO

On Sun, Jul 28, 2019 at 7:38 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Gene,
>
> FT8 is WAY MORE sensitive! (~8db)
>
>
> That number is not right. On the additive white Gaussian noise (AWGN)
> channel, the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the
> 50% decode probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity
> difference is therefore 3.3 dB.
>
> On channels with severe Doppler spreading, the threshold SNR is higher for
> both modes, and the difference between FT8 and FT4 will decrease somewhat
> because FT4’s larger tone separation tends to give it an advantage in those
> cases.
>
> It might be of interest to some to consider that FT8 uses symbols with
> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms
> to send 2 bits apiece. For a given average transmitter power, the energy
> that is transmitted per bit for FT8 is larger than the energy transmitted
> per bit for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical
> sensitivity difference (ignoring any differences in signal detection,
> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB,
> very close to the actual difference of 3.3 dB that I quoted above.
>
> I have no strong feelings one way or the other about your main point, but
> I think that it’s preferable to base the discussion on accurate numbers.
>
>
> FT4 is awesome for MORE contacts (i.e. contests).
>
> I’m sticking with FT8 for QUALITY.
>
> 73 de W8NET Miles / “Gene”
> Secretary, Portage County Amateur Radio Service (PCARS)
> 3905 Century Club - Master #47
> DV2/W8NET in the Philippines
> Licensed since 1974
>
>
> Steve, K9AN
>
>
> ___
> 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 2.1.0 64-bit GA release: TX audio level has changed

[Paul Kube]

>  Anyone else experiencing that with the 64-bit version?

Yes.

Tune power also.

IC-7300, Win 10 x64 Pro.

73, Paul K6PO


On Mon, Jul 15, 2019 at 8:52 AM DG2YCB, Uwe  wrote:

> Many thanks for the new GA version! Works well so far here on my computer
> (64-bit Windows).
> One observation: With the new 64-bit GA version I needed to increase PWR
> slider from around 50 % to now nearly 100 % to get sufficient audio level
> at
> my FT-991. Old settings resulted in a few mW TX output. Will do some
> further
> tests, but seems to be reproducible.
> Anyone else experiencing that with the 64-bit version?
>
> 73 de Uwe, DG2YCB
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals?

[Paul Kube]

I’ve seen various kinds of problematic  FT8 signals that I think I
understand -- “barcode” harmonics etc. – but what is going on here:


[image: multiple decode.PNG]

The “blackbox” station there (call elided, no need to name names) has
multiple sidebands on his main signal, some of them strong enough to be
separately decoded, all at multiples of 60 Hz. What is causing this?
Inadequate power supply filtering?



Pretty sure it’s not in my receive chain; I see many signals stronger than
this +12 dB one that are perfectly clean.



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

Re: [wsjt-devel] WSJT-X 2.1.0-rc6

[Paul Kube]

Here also. Both 64 and 32 bit packages under Windows 10 Pro x64.

*Windows:*

   - 32 bit: wsjtx-2.1.0-rc6-win32.exe
   
   (WinXP, Vista, Win 7, Win 8, Win10)
   - 64 bit: wsjtx-2.1.0-rc6-win64.exe
   
   (Vista, Win 7, Win 8, Win10, 64-bit)


Installation finishes, but starting wsjtx fails. Event log:

Faulting application name: wsjtx.exe, version: 0.0.0.0, time stamp:
0x5cf07e87
Faulting module name: wsjtx.exe, version: 0.0.0.0, time stamp: 0x5cf07e87
Exception code: 0xc005
Fault offset: 0x0027cc44
Faulting process id: 0xaa0
Faulting application start time: 0x01d51984296f7e16
Faulting application path: C:\WSJT\wsjtx\bin\wsjtx.exe
Faulting module path: C:\WSJT\wsjtx\bin\wsjtx.exe
Report Id: 90f94897-f27f-4781-9789-0f1ff063c7c8
Faulting package full name:
Faulting package-relative application ID:

On Sun, Jun 2, 2019 at 1:13 PM Dana Myers  wrote:

> On 6/2/2019 11:32 AM, Joe Taylor wrote:
> > To: Users of WSJT-X -- especially those interested in radio contesting
> > From: WSJT Development Group
> >
> > As you know, we have been developing a protocol called FT4 for use in
> radio contesting.  A new version of FT4 is now available
> > for testing in WSJT-X 2.1.0-rc6.
> >
> > PLEASE NOTE THAT FT4 IN RELEASE CANDIDATE 6 IS NOT COMPATIBLE WITH THAT
> IN ANY PREVIOUS RELEASE.
> >
> > Therefore: Please stop using WSJT-X 2.1.0-rc5.  If you wish to use FT4
> after today or to take advantage of other recent program
> > corrections or enhancements, you should use WSJT-X 2.1.0-rc6.
>
> On Windows 10 Pro 64-bit 1903:
> I've installed -rc6 64-bit  in a new folder and attempts to launch it
> simply... don't
> launch anything that I can see. -rc5 64-bit works correctly.
>
> Any suggestions where to look first?
>
> Thanks,
> Dana  K6JQ
>
>
>
> ___
> 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] S+P operation

[Paul Kube]

Joe --


> I think you'll get what you want (for contesting) if you check only
> these (top to bottom) on the Settings -> Colors tab:
>
> X  My Call in message
> X  New DXCC
> X  New Call on Band
>

Thanks, yes, that does it.


> No guarantees that we are maintaining our sanity!  Would you like to
> volunteer to organize and operate such a system?  :-)
>

Ah, probably not; too busy being retired :).

Sourceforge has its native bug ticket system
https://sourceforge.net/p/forge/documentation/Tickets/ and since you are
already hosting the project there, that might be the easiest way to go.

Personally I like Bugzilla https://en.wikipedia.org/wiki/Bugzilla. Set it
up on one of your Princeton machines; it's pretty lightweight
https://www.bugzilla.org/. Or run it in Amazon's cloud
https://aws.amazon.com/marketplace/pp/B007I8OOJ0.

But anything will have startup costs and you might not find that worth it.

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

Re: [wsjt-devel] S+P operation

[Paul Kube]

The documentation
http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf says,
re S+P: "Here “best potential QSO partner” means “New Multiplier” (1st
priority) or “New Call on Band” (2nd priority)."

Now it seems to me that "New Call" implies "New Call on Band", and so
should qualify as a potential QSO partner.

However, in my setup, it does not. (That is, a new call on the band can
trigger the S+P response; while entirely new call, i.e. new on all bands,
doesn't.)

73, Paul K6PO

P.S. I'm posting this as a reply to George's note, since its topic fits his
subject line. Just doing my part to try to keep comments here organized a
bit. I do not know how the developers continue to maintain their sanity
without a proper bug reporting and tracking system.


On Thu, May 2, 2019 at 7:45 AM WB5JJJ  wrote:

> Trying new features with FT4 and noticed that when S+P is active during
> non-CQ (receive only) operation, it will pounce on stations using directed
> calls such as CQ DX WB5JJJ EM35.  In a contest situation, which FT4 is
> designed for, this would be fine since there will not be any directed CQ's
> typically.  So, should this option not be shown on the main UI unless a
> contest is selected since it can cause frustration to some operators that
> don't want to be bothered by local stations pouncing on their directed CQ?
>
> Judging from some comments, it appears that FT4 may be the new norm for
> those seeking their first WAS, DXCC and not just contests.
>
> WB5JJJ - George
> ___
> 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] Another observed drawback - audio input level

[Paul Kube]

Looking at this ("Microphone Properties" for the USB Audio Codec that the
IC-7300 provides and that WSJT-X uses as input):

[image: miclevel.png]

It gets set to 100% whenever WSJT-X 2.1.0-rc5 starts, and I have to set it
to 40% "by hand". WSJT-X  2.0.1 did not have this issue.

Windows 10 Pro x64 here.

73, Paul K6PO


On Tue, Apr 30, 2019 at 5:48 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Are you guys looking at the dB level in the audio management panel?  Or
> the % level?
> WSJT-X does not touch the audio so it has to be Windows doing it.
>
> Recording audio should be at 0dB.
>
> de Mike W9MDB
>
>
>
>
> On Tuesday, April 30, 2019, 6:55:30 AM CDT, kf8my--- via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
> It also does it in Win7, audio sound recording to max on restart.
> Mike/kf8my
>
>
>
> -Original Message-
> From: Joe, LB1HI 
> To: wsjt-devel 
> Sent: Tue, Apr 30, 2019 6:46 am
> Subject: [wsjt-devel] Another observed drawback - audio input level
>
> Hi,
> Another observed  drawback is that after each WSJT-X restart, previously
> pre-set audio (Win 10 64 bit) signal input level of the sound card
> changes. It changes spontaneously. It changes to a maximum  - 100% of
> the  level setting range.
>
> 73`s Joe
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] GFSK for FT8?

[Paul Kube]

Bill --

empirical tests using multiple simulated FT8 signals
>

 Do you have software for us civilians that can do that? Create .wav files
with multiple FT8 signals with controllable frequencies and strengths, I
mean. SimJT doesn't, according to documentation
https://physics.princeton.edu/pulsar/k1jt/SimJT_User.pdf.

Thanks

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

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

[Paul Kube]

Thanks Joe, Steve, and Bill. This looks very good.

1. Where do you want folks to submit their feedback after using the RC? You
all seem to be good at dealing with the firehose of emails coming in to
wsjt-devel, but maybe you want to set up something just for this.

2. Any chance of having "Best S+P" also consider end-of-QSO messages (RR73,
etc.) as well as CQ's? Tailending, without waiting for a CQ, can really
help with rates.

3. Any chance of implementing F/H style "W1ABC 73; W0XYZ 569" call queueing?

Thanks!

73, Paul K6PO

On Mon, Apr 22, 2019 at 8:38 AM Joe Taylor  wrote:

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

Re: [wsjt-devel] People are rude at times

[Paul Kube]

 click moves Rx, ctl-click moves both, shift click moves Tx.  I knew
> something moved them both...and sometimes I hit control instead of shift in
> the heat of he moment.
>

I think it would be better user interface design to have "move Rx" be left
click and "move Tx" to be right click, so those basic functions can each be
done with one hand. But that's another topic.

Do you have any theories on why a station gets covered by another station
> on exactly the same frequuency +/- 1-2 Hz?
>

I don't know, maybe the other station chose that frequency because it
looked clear to transmit (the weak station was weak enough that they didn't
see it). On a crowded FT8 segment, like 14.074 in the evening here, signals
are packed in like sardines and you have to do your best to find a
relatively open slot.

Or maybe he was just a lid! But IMHO it's going to be futile to try to
eliminate liddish behavior through software.

73, Paul K6PO


> On Sat, Apr 20, 2019 at 2:05 AM Paul Kube  wrote:
>
>> Jeff,
>>
>>
>>> What I think is happening is that people click on signals so they can
>>> see them in the Rx Frequency window.  They have not checked the Hold Tx
>>> Frequency and so the transmitter frequency is automatically following the
>>> Rx frequency.
>>>
>>
>> Are you talking about single-clicking in the waterfall? That only moves
>> the Rx frequency, whether or not Hold Tx Freq is checked.
>>
>> 73, Paul K6PO
>>
>>
>>> On Thu, Apr 18, 2019 at 4:41 PM James Shaver  wrote:
>>>
>>>> And speaking of S/N, I just realized this is the “devel” reflector and
>>>> not the generic WSJT Group reflector.  This really isn’t a topic suitable
>>>> for the development side, to be honest...
>>>>
>>>> 73,
>>>>
>>>> Jim S.
>>>> N2ADV (ex KD2BIP)
>>>>
>>>> > On Apr 18, 2019, at 4:34 PM, James Shaver  wrote:
>>>> >
>>>> > It never ceases to amaze me how so many hams instantly jump to the
>>>> conclusion that what they witness on the air is automatically attributed to
>>>> intentional “rudeness” or ill intent.
>>>> >
>>>> > His s/n is not really relevant - it’s very possible that even if
>>>> propagation was, to coin a phrase, putting this person in your lap, that
>>>> does not mean you’re even a weak trace on his/her end. That person may have
>>>> a very high local noise floor due to an indoor antenna or a lot of noisy
>>>> consumer electronics around them or it could even be as simple as plain old
>>>> propagation differences or it could be someone who has just jumped into
>>>> digital modes for the very first time and is not yet familiar with the
>>>> interface.
>>>> >
>>>> > If it bothers you that much, look up their email on QRZ and send them
>>>> a screen shot and *politely* ask if they even heard/saw you. If they
>>>> didn’t, offer to help them track down local noise generators or help them
>>>> optimize their receive setup.
>>>> >
>>>> > It pays to give people the benefit of the doubt. If they turn out to
>>>> be a jerk, then you can at least walk away with the satisfaction that you
>>>> tried your best to be an “Elmer” and are, at the end of the day, the better
>>>> person.
>>>> >
>>>> > And relax. It’s just ham radio. Nobody died on the table. This is
>>>> supposed to be fun.
>>>> >
>>>> > Jim S.
>>>> > N2ADV
>>>> >
>>>> > ___
>>>> > wsjt-devel mailing list
>>>> > wsjt-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>
>>>>
>>>> ___
>>>> wsjt-devel mailing list
>>>> wsjt-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] People are rude at times

[Paul Kube]

Jeff,


> What I think is happening is that people click on signals so they can see
> them in the Rx Frequency window.  They have not checked the Hold Tx
> Frequency and so the transmitter frequency is automatically following the
> Rx frequency.
>

Are you talking about single-clicking in the waterfall? That only moves the
Rx frequency, whether or not Hold Tx Freq is checked.

73, Paul K6PO


> On Thu, Apr 18, 2019 at 4:41 PM James Shaver  wrote:
>
>> And speaking of S/N, I just realized this is the “devel” reflector and
>> not the generic WSJT Group reflector.  This really isn’t a topic suitable
>> for the development side, to be honest...
>>
>> 73,
>>
>> Jim S.
>> N2ADV (ex KD2BIP)
>>
>> > On Apr 18, 2019, at 4:34 PM, James Shaver  wrote:
>> >
>> > It never ceases to amaze me how so many hams instantly jump to the
>> conclusion that what they witness on the air is automatically attributed to
>> intentional “rudeness” or ill intent.
>> >
>> > His s/n is not really relevant - it’s very possible that even if
>> propagation was, to coin a phrase, putting this person in your lap, that
>> does not mean you’re even a weak trace on his/her end. That person may have
>> a very high local noise floor due to an indoor antenna or a lot of noisy
>> consumer electronics around them or it could even be as simple as plain old
>> propagation differences or it could be someone who has just jumped into
>> digital modes for the very first time and is not yet familiar with the
>> interface.
>> >
>> > If it bothers you that much, look up their email on QRZ and send them a
>> screen shot and *politely* ask if they even heard/saw you. If they didn’t,
>> offer to help them track down local noise generators or help them optimize
>> their receive setup.
>> >
>> > It pays to give people the benefit of the doubt. If they turn out to be
>> a jerk, then you can at least walk away with the satisfaction that you
>> tried your best to be an “Elmer” and are, at the end of the day, the better
>> person.
>> >
>> > And relax. It’s just ham radio. Nobody died on the table. This is
>> supposed to be fun.
>> >
>> > Jim S.
>> > N2ADV
>> >
>> > ___
>> > 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] People are rude at times

[Paul Kube]

I don't know what the other guy was thinking in this case, but the issue is
complicated by some FT8 experts pushing the "always work split" idea,
i.e. "*Never
call a station on his transmit frequency".* If everyone follows that, then
each station's transmit frequency should be free for someone else to use
use to transmit on the other cycle.

Obviously, a problematic idea unless everyone follows it. Kind of like
"let's some of us drive on the left side of the road and see how that
works."

73, Paul K6PO

On Thu, Apr 18, 2019 at 9:13 AM Scotty W7PSK  wrote:

> I was on the air just now when a Jerk just started CQing dead on top of
> me.  I was in the process of trying to work a new one when I lost it due to
> him.  I even posted  IN USE QSY and he just kept blasting away
>
> WTH people, have we forgotten ham courtesy ?
>
> Scotty W7PSK
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO-B behavior

[Paul Kube]

"  perhaps there should be a note in the User Manual that, at least
for Icom rigs, the 'Fake It' split mode is preferred/recommended?"

"Rig" mode works fine with my IC-7200 and IC-7300.

73, Paul K6PO

On Mon, Mar 4, 2019 at 1:45 PM Martin Davies G0HDB 
wrote:

> On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:
>
> > Both conditions need to fixed.  VFO-A needs to be set as selected VFO
> > and VFO-B set to the split freq at all times.  Otherwise a tune
> > instigated from an external source will be on the wrong frequency.And
> > yes...I know you can click Tune in WSJT-X and then VFO-B gets
> > set...but that leaves the amplifier in-line with too much power to
> > tune and for some could fry the amplifier.
> > Mike
>
> Hi Mike (and all), for what it's worth I've found that using the 'Fake It'
> split mode, rather than
> the 'Rig' mode, works best with my Icom IC-7600.
>
> Some years ago, when I first tried using the 'Rig' mode with WSJT I found
> that the time taken
> to switch VFOs (from A to B in my case) and then to re-tune the
> newly-selected VFO with the
> desired offset (eg. +1kHz) was significantly longer than just re-tuning
> the active VFO,
> presumably because there was a longer command sequence to be received,
> processed and
> then actioned by the rig.  The delay in the rig switching VFOs and then
> re-tuning was
> resulting in the transmission not starting until (IIRC) some 2-3secs into
> a Tx period.
>
> I would assume that using the 'Fake It' mode would work equally well
> irrespective of which
> VFO was the active one, so perhaps there should be a note in the User
> Manual that, at least
> for Icom rigs, the 'Fake It' split mode is preferred/recommended?
>
> --
> 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] VFO-B behavior

[Paul Kube]

If VFO-B is the active VFO and you switch bands on WSJT-X only VFOB gets
set...VFOA does not change..


The same is true if VFO-A is the active VFO; VFO-B does not get set with a
band change until you transmit.

I just hit WSJT-X's "Tune" button for a second when switching bands. Works
fine on the IC-7300 with tune-on-PTT enabled.

73 Paul K6PO

On Sun, Mar 3, 2019 at 12:56 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Found an undesirable behavior that I think can be easily fixed.
>
> On ICOM rigs hamlib assumes split is always on VFOB to cover rigs without
> status commands...as does FLRig (and perhaps others).
>
> If VFO-B is the active VFO and you switch bands on WSJT-X only VFOB gets
> set...VFOA does not change...so it appears to do a reverse split and tuning
> can, of course, be way off depending on where VFOA is sitting.  Once you
> click transmit VFOA does get changed but by then it can be too late for
> your tuner.
>
> I believe all that we need to do is make VFOA the active VFO when
> switching bands before any frequencies are set.  Is there any reason not to
> make VFOA the active one?
>
> de Mike W9MDB
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WD timer engages even on reply

[Paul Kube]

I've noticed this "nit" too. Consider this another vote in favor of the
change Richard proposed.

73, Paul K6PO

On Sat, Mar 2, 2019 at 5:50 AM Richard Shaw  wrote:

> Small nit...
>
> I use my WD timer to limit the number of time I try to reach a station, I
> currently have it set to 3 minutes. One thing I've noticed is that the WD
> timer still kills TX if the station responds on the cycle following the WD
> timer running out.
>
> I assume it would not be difficult to check for a response before killing
> TX?
>
> Thanks,
> Richard
> KF5OIM
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] About that watchdog...

[Paul Kube]

I like enabling the Tx Watchdog. It is pretty much essential, in my opinion.

But there there are things that should be changed about the user interface
to it.

The watchdog can now only be adjusted in whole-minute increments. This made
sense with the one-minute transmit cycle of the older modes, but not so
much with FT8's 15 second cycle.

I'd suggest changing the Tx Watchdog units under Settings to "Tx cycles".
More intuitive to me at least, I think of it in terms of the number of the
maximum times I will try a message before giving up, rather than limiting
the time I spend doing it.

Then also the Watchdog progress output... Now it's just an integer
countdown of whole minutes in the far bottom left corner of the main
window. This should show Tx cycles remaining. A bar graph might be nice,
but it would need more horizontal space.

Anyway, just a suggestion.

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

Re: [wsjt-devel] Short Tx inhibits decode...

[Paul Kube]

> Try turning it on its head, Paul.  Pre-decide NOT to transmit on the
*next* cycle by deselecting

> Enable Tx during the *current* cycle … unless you spot something in the
decodes that

> makes you change your mind, in which case you reselect Enable Tx.


Hi Gary, yes; but letting auto seq run works just fine most of the time.
Toggling Enable off only to toggle it on at the beginning of the next cycle
is very often superfluous. Plus it requires thinking ahead a bit, which I
find I'm not always able to do.


Anyway, I have my vote in for getting decode to work, if possible, in
cycles where transmit has been halted in the first few seconds.


Thanks!


73, Paul K6PO



On Thu, Jan 17, 2019 at 4:11 PM Gary Hinson  wrote:

> Try turning it on its head, Paul.  Pre-decide NOT to transmit on the
> *next* cycle by deselecting Enable Tx during the *current* cycle … unless
> you spot something in the decodes that makes you change your mind, in which
> case you reselect Enable Tx.
>
>
>
> Slightly delayed transmissions are generally decoded OK.  You have about 5
> seconds to make your mind up.  Beyond that, your transmissions *may* not
> be decoded (but you might still be lucky!).
>
>
>
> [Another handy thing about delayed starts is that you can see whether your
> transmit frequency is busy or clear during the periods when you would
> otherwise be transmitting.]
>
>
>
> We’re not saying your change proposal is unnecessary, unhelpful or not a
> good idea, simply offering a pragmatic workaround that gives most of the
> user benefit with none of the development costs.
>
> 73
> Gary  ZL2iFB
>
>
>
> *From:* Paul Kube 
> *Sent:* 18 January 2019 11:05
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Short Tx inhibits decode...
>
>
>
> Gary and Gary,
>
>
>
> But I want to stop transmitting near the start of a cycle, and still see
> decodes from that cycle. As you point out, deselecting Enable doesn't do
> that.
>
>
>
> The problem arises when I don't know whether I want to continue
> transmitting until I see the decodes from a cycle. For examples: I called a
> station off frequency, and I see they didn't hear me and I'd rather not
> call again. Or, I'm calling CQ, see no replies, and I don't want to CQ
> again. It takes me a second or two to look at the decode list and decide I
> want to listen instead of transmit. So autosequence has me transmitting a
> little into the start of the next cycle, but I want to stop and see decodes
> in that cycle instead.
>
>
>
> Both of those examples could be handled better and faster by options
> within WSJT-X, so if that were implemented with checkboxes I'd be pretty
> happy. (Already happens with on-frequency calls to a CQing station.) Which
> might be easier than modifying the decode code to handle starting late in a
> cycle, I don't know.
>
>
>
> 73, Paul K6PO
>
>
>
> On Thu, Jan 17, 2019 at 1:43 PM Gary Hinson  wrote:
>
> Friends,
>
>
>
> Try deselecting *Enable Tx* prior to the start of the next cycle instead
> of hitting the *Halt Tx* button.  Think of the *Halt Tx* button as a big
> angry red emergency stop button that slams the brakes on and drops
> everything.  It drops the anchor.
>
>
>
> Deselecting Enable TX is not so abrupt, and not so tight on timing: if you
> deselect it at any point in a transmission, the remainder of that
> transmission continues to the end as normal but your *next* transmission
> doesn’t happen.  It’s more elegant.  More refined.  Less screeching of
> tyres.
>
>
>
> Find this and other pragmatic tips in the FT8 Operating Guide
> <http://www.g4ifb.com/FT8_Hinson_tips_for_HF_DXers.pdf>.
>
>
>
> 73,
>
> Gary   ZL2iFB
>
>
>
>
>
> *From:* WB5JJJ 
> *Sent:* 18 January 2019 10:12
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Short Tx inhibits decode...
>
>
>
> I've noticed that as well.  Been this way for many versions back.  Once
> the Tx cycle has been initiated (i.e. odd or even Tx has started), and if
> you then click Halt Tx, the radio will go to receive, the WF will show the
> signals, but none are decoded for the aborted Tx cycle.  At the start of
> the next cycle, all is normal.
>
>
>
> WB5JJJ - George
>
>
>
> On Thu, Jan 17, 2019 at 3:01 PM Paul Kube  wrote:
>
>
>
> If I cancel my own transmission right at the beginning of a cycle, I see
> no decodes at all for that cycle.
>
>
>
> For example, say I'm CQing on even cycles. After a couple, I decide I want
> to stop CQing if I don't get any replies, so I hit Halt Tx as soon as I see
> the list of deco

Re: [wsjt-devel] is this hash error?

[Paul Kube]

Jari, This seems to be a known issue. See
https://sourceforge.net/p/wsjt/mailman/message/36518222/.

73, Paul K6PO

On Fri, Jan 18, 2019 at 5:26 AM Jari A  wrote:

> Did I experience another hash error?
>
> Had one previously, but thought it was a glitch, now I had this again:
> Just to let you know, as this is repeatable within certain conditions, but
> if I understood right, this is noted previously?
>
> Good weekend,
>
> :Jari
>
> 130930 -4 -0.2 1787 ~ CQ PA3HGL/QRP  Netherlands
>
> 130951 Tx 1787 ~  OH2FQV
>
> 131015 Tx 1787 ~  OH2FQV
>
> 131030 -4 0.1 1787 ~ OH2FQV  -03
>
> 131045 Tx 1787 ~  OH2FQV R-04
>
> 131100 -12 0.2 1787 ~  PA3HGL/QRP RR73
>
> 131115 Tx 1787 ~  OH2FQV
>
> 131145 Tx 1787 ~  OH2FQV
>
> 131200 -9 0.1 1788 ~ OH2FQV  -05
>
> 131215 Tx 1787 ~  OH2FQV R-09
>
> 131245 Tx 1787 ~  OH2FQV R-09
>
> 131300 -6 0.1 1787 ~  PA3HGL/QRP RR73
>
> 131315 Tx 1787 ~  OH2FQV
>
> 131345 Tx 1787 ~  OH2FQV
>
> 131358 Tx 1787 ~ PA3HGL/QRP  73
>
> 131418 Tx 1787 ~ DE OH2FQV 73
>
> 131500 8 0.1 1785 ~ OH2FQV  -06
>
> 131600 0 0.1 1785 ~ OH2FQV  -06
>
> 131615 Tx 1787 ~  OH2FQV R+00
>
> 131630 0 0.1 1785 ~  PA3HGL/QRP RR73
>
> 131645 Tx 1785 ~  OH2FQV
>
> 131649 Tx 1785 ~ PA3HGL/QRP  RR73
>
> 131650 Tx 1785 ~ PA3HGL/QRP  RRR
>
> 131715 Tx 1785 ~ DE OH2FQV 73
> ___
> 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] Short Tx inhibits decode...

[Paul Kube]

Gary and Gary,

But I want to stop transmitting near the start of a cycle, and still see
decodes from that cycle. As you point out, deselecting Enable doesn't do
that.

The problem arises when I don't know whether I want to continue
transmitting until I see the decodes from a cycle. For examples: I called a
station off frequency, and I see they didn't hear me and I'd rather not
call again. Or, I'm calling CQ, see no replies, and I don't want to CQ
again. It takes me a second or two to look at the decode list and decide I
want to listen instead of transmit. So autosequence has me transmitting a
little into the start of the next cycle, but I want to stop and see decodes
in that cycle instead.

Both of those examples could be handled better and faster by options within
WSJT-X, so if that were implemented with checkboxes I'd be pretty happy.
(Already happens with on-frequency calls to a CQing station.) Which might
be easier than modifying the decode code to handle starting late in a
cycle, I don't know.

73, Paul K6PO

On Thu, Jan 17, 2019 at 1:43 PM Gary Hinson  wrote:

> Friends,
>
>
>
> Try deselecting *Enable Tx* prior to the start of the next cycle instead
> of hitting the *Halt Tx* button.  Think of the *Halt Tx* button as a big
> angry red emergency stop button that slams the brakes on and drops
> everything.  It drops the anchor.
>
>
>
> Deselecting Enable TX is not so abrupt, and not so tight on timing: if you
> deselect it at any point in a transmission, the remainder of that
> transmission continues to the end as normal but your *next* transmission
> doesn’t happen.  It’s more elegant.  More refined.  Less screeching of
> tyres.
>
>
>
> Find this and other pragmatic tips in the FT8 Operating Guide
> <http://www.g4ifb.com/FT8_Hinson_tips_for_HF_DXers.pdf>.
>
>
>
> 73,
>
> Gary   ZL2iFB
>
>
>
>
>
> *From:* WB5JJJ 
> *Sent:* 18 January 2019 10:12
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Short Tx inhibits decode...
>
>
>
> I've noticed that as well.  Been this way for many versions back.  Once
> the Tx cycle has been initiated (i.e. odd or even Tx has started), and if
> you then click Halt Tx, the radio will go to receive, the WF will show the
> signals, but none are decoded for the aborted Tx cycle.  At the start of
> the next cycle, all is normal.
>
>
>
> WB5JJJ - George
>
>
>
> On Thu, Jan 17, 2019 at 3:01 PM Paul Kube  wrote:
>
>
>
> If I cancel my own transmission right at the beginning of a cycle, I see
> no decodes at all for that cycle.
>
>
>
> For example, say I'm CQing on even cycles. After a couple, I decide I want
> to stop CQing if I don't get any replies, so I hit Halt Tx as soon as I see
> the list of decodes from a just-finished odd cycle. Maybe I am transmitting
> for a second or two into the adjacent even cycle; but there are never any
> decodes from it at all even when lots of signals are present in the
> waterfall.
>
>
>
> Naively, it seems to me that this doesn't need to happen. I often see FT8
> decodes for stations that start late -- as much as 4 seconds late -- in a
> cycle. So why does missing the first second or two prevent decoding
> anything?
>
>
>
> If this could be changed, it would be nice. A few of those wasted 15
> seconds add up!
>
>
>
> Thanks, and 73,
>
>
>
> Paul K6PO
>
>
>
>
>
>
>
>
>
> ___
> 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] Short Tx inhibits decode...

[Paul Kube]

If I cancel my own transmission right at the beginning of a cycle, I see no
decodes at all for that cycle.

For example, say I'm CQing on even cycles. After a couple, I decide I want
to stop CQing if I don't get any replies, so I hit Halt Tx as soon as I see
the list of decodes from a just-finished odd cycle. Maybe I am transmitting
for a second or two into the adjacent even cycle; but there are never any
decodes from it at all even when lots of signals are present in the
waterfall.

Naively, it seems to me that this doesn't need to happen. I often see FT8
decodes for stations that start late -- as much as 4 seconds late -- in a
cycle. So why does missing the first second or two prevent decoding
anything?

If this could be changed, it would be nice. A few of those wasted 15
seconds add up!

Thanks, and 73,

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

Re: [wsjt-devel] Strange hash collision?

[Paul Kube]

Bill,

Then I don't understand why the hashcode for my call isn't used. It is
known, or my call wouldn't be correctly decoded in those two received
messages. Or so it seems to me.

73, Paul K6PO


On Tue, Jan 15, 2019 at 4:11 PM Bill Somerville 
wrote:

> On 16/01/2019 00:02, Paul Kube wrote:
> > But why is my call hashed wrong in my own Rx Frequency window?
>
> Hi Paul,
>
> hash codes are just numbers, what you see is a lookup of a table indexed
> by the hash code. The wrong call is being looked up and printed. There
> is nothing wrong with the hash code, just a problem with how it is
> translated to a callsign.
>
> 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] Strange hash collision?

[Paul Kube]

Have a look at this QSO between me (K6PO) and K8CHY/4:

[image: hashdecode.PNG]

The strangeness is in my transmissions at 23 and 230030, where 
appears instead of . When my QSO partner's transmissions are decoded,
 appears as it should. I guess he was able to decode my transmissions
all right. But why is my call hashed wrong in my own Rx Frequency window?

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

Re: [wsjt-devel] DT Observation

[Paul Kube]

Interesting. Back in the "old days" of JT65, if the DT's I saw were
approximately zero mean, I figured that meant my clock was about right.
During the FT8 RU, I never saw any negative DT decodes, and I worried that
my clock was fast, in spite of checking it before the contest. Maybe some
clock nudging would have picked up a few more QSO's.

73, Paul K6PO


On Mon, Dec 3, 2018 at 7:37 PM Coy Day  wrote:

> My setup: Using FT8 V2CR5 on an Optiplex 9010 running Win7 Pro
>
> During the RU I observed WF signals where they were obviously calling me
> but they didn't decode. I observed the same to day while running stations
> on 7.074. Today I was not in RU mode.
>
> I saw a post that mentioned that DT may be an issue so I ran an experiment
> to see what effect it would have. I used TimeFudge v1.0 to nudge the time
> on my comuputer in .05 sec increments. I did this while watching the DT on
> the signals that I was decoding. As the DT became negative the signals
> stopped decoding. They would go from say 0.2 to 0.1 then 0.0 and then they
> wouldn't decode. As I continued eventually all the stations stopped
> decoding. When I nudged the computer time back up the stations started
> coming back.
>
> This explained to me why I was not decoding some stations that were
> calling me but it also could be the cause for some of those that said they
> didn't copy any signals from the WF. It could be that their computer clock
> was off just enough the cause all the signals DT to be negative.
>
> Coy, N5OK
>
> ___
> 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] TX not moving on double-clcik

[Paul Kube]

Me three :).

Well described by Charlie and Jim.

73, Paul K6PO

On Sun, Dec 2, 2018 at 4:48 PM Jim Shorney  wrote:

>
> Thanks Charlie! Nice to know it isn't just me...  :)
>
> 73
>
> -Jim
> NU0C
>
>
> On Sun, 2 Dec 2018 21:20:39 -
> char...@sucklingfamily.free-online.co.uk wrote:
>
> > Hi Jim
> >
> > Yes, we experienced the same behaviour where clicking an earlier message
> > when bailing on a QSO ended up splitting the TX and RX frequencies.
> >
> > We also found it labour intensive to have to select TX4 and enable TX
> > manually when the calling station sent R report again, clearly not having
> > received our initial RR73 message.  On some occasions we needed to do
> this
> > several times during more difficult QSOs.
> >
> > 73
> >
> > Charlie G3WDG
> > >
> > > I have noticed a specific scenario that has happened several times
> during
> > > the contest. This happens when I have called a CQing station two or
> three
> > > times with no reply and I bail and go call another. Then I see the
> first
> > > station replying to me with TX3 while I am calling the new one. So I
> bail
> > > on that call and try to go back to work the first station with a
> > > double-click on the message. This moves the RX back to the first
> station's
> > > frequency, but not the TX. It is acting like Hold TX is on, but it is
> not.
> > > I tried toggling Hold TX. and shift-doubleclick, but the TX refuses to
> > > move until I use one those "confusing" arrows. (j/k, I'm not confused
> -
> > > much).
> > >
> > > Maybe I'm just a bad op. I know we are supposed to offset our signals
> and
> > > call split, but that doesn't seem to be happening. At any rate, it
> seems
> > > like the TX should move in this scenario, otherwise I end up QRMing the
> > > second op until I remember where I am.
> > >
> > > While I am at it, it would be nice if, when calling running station,
> Tx4
> > > could me made sticky until the final 73 is received. Leave TX disable
> > > alone, just let Tx4 stay selected in case it needs to be re-sent. One
> less
> > > thing to have to scramble for when things don't go as planned.
> > >
> > > Anyway, 70 contacts so far before I needed to take a break.
> > >
> > > 73
> > >
> > > -Jim
> > > NU0C
> > >
> > >
> > > --
> > > The universe we're in will reach absolute zero in three hours. Safe is
> > > relative. - Idris, "The Doctor's Wife"
>
>
> ___
> 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

[Paul Kube]

Frank -- The only way I know to do this is from the command line.

See http://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main.html#FAQ.

*How should I configure WSJT-X to run multiple instances?*

Start *WSJT-X* from a command-prompt window, passing each instance a unique
identifier as in the following two-instance example. This procedure will
isolate the *Settings* file and the writable file location for each
instance of *WSJT-X*.

wsjtx --rig-name=TS2000
wsjtx --rig-name=FT847



73, Paul K6PO

On Sun, Dec 2, 2018 at 10:44 AM Frank Kirschner 
wrote:

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

Re: [wsjt-devel] Very few decodes with RC5

[Paul Kube]

Or, send a bunch of CQ's and type your call in to
https://pskreporter.info/pskmap.html.

73, Paul K6PO

On Sat, Dec 1, 2018 at 8:50 PM Edfel Rivera  wrote:

> Hi:
>
> Your callsign is?
>
> Could check,  I am at 40m, KP4AJ
>
> On Sat, Dec 1, 2018 at 11:45 PM Bill Pence  wrote:
>
>> Yep
>>  I see lots of cq ru using rc5. Few answers when i reply.
>>
>> On Sat, Dec 1, 2018, 11:40 PM Edfel Rivera >
>>> Hi:
>>>
>>> Be sure to use frequencies 7080 40m, 14130 20m.  Also clock sync is
>>> essential.  UTC diff no more than 1.5 seconds.  RC5 testing HUGE today (day
>>> and night).  Worked bunch stations.
>>>
>>> 73'
>>>
>>> Edfel
>>> KP4AJ
>>>
>>> On Sat, Dec 1, 2018 at 11:33 PM Dave Barr  wrote:
>>>
 During the FT8 Roundup, I am decoding only a fraction of the signals I
 can hear and see on the water fall.  RX selectivity is wide.  RF gain
 has been lowered.  The rx level bar hovers between 50 and 60.  Yet I
 decode only a few, or one, or none of the signals present.  Earlier RCs
 and 1.9 had no such problem.  Any ideas?

 Dave, K2YG



 ___
 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] Graphic confusion ;-)

[Paul Kube]

>  . You'll just have to learn the convention and put up with it.

Bill, You really should change the tooltips though. "Set Tx frequency to Rx
Frequency" makes it sound like the direction is from Tx to Rx, and then the
arrows seem to point the "wrong" direction.

"Copy Tx frequency to Rx frequency" or "Push Tx frequency to Rx frequency"
would be less confusing.

73, Paul K6PO

On Sat, Dec 1, 2018 at 9:12 AM Bill Somerville 
wrote:

> On 01/12/2018 10:05, m...@oz5xn.dk 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
>
> Hi Allan,
>
> this is an endian issue (
> https://en.wikipedia.org/wiki/Gulliver%27s_Travels#Part_I:_A_Voyage_to_Lilliput).
> There is no correct resolution that satisfies everyone. You'll just have to
> learn the convention and put up with it.
>
> 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] Defect or Design? Contest Exchanges not logged.

[Paul Kube]

If by "internal tests" you mean simulating logging a contact by clicking
Log QSO and filling out fields in the popup dialog, your experience
coincides with mine; the exchange fields in WSJT-X's .adi log, and in the
UDP log packet, do not appear correctly.

However, if I actually work a RU contact and log it, all fields are correct.

I do not know why just entering from fields in the WSJT-X popup log form
does not work,  but this seems to be the case.

Anyway, try with actual contacts during the FT8 RU mock contest Dec 1
0200-0300 UTC and check.

73 Paul K6PO

On Fri, Nov 30, 2018 at 9:25 AM Tom Ramberg via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Comments from the dev team on this?
>
> Tom OH6VDA
>
> 29. nov. 2018 kl. 23:17 skrev Laurie, VK3AMA <_vk3a...@vkdxer.net>:
>
> Running some simple internal tests today (RTTY RU) and note that Contest
> exchanges are not being recorded in the wsjtx_log.adi file.
>
> Similarly, contest exchanges are not conveyed in the UDP interface logged
> QSO packet (to be expected as the UDP interface has not been updated with
> any of the new v2.0 changes).
>
> Is this by design, defect or oversight?
>
> de Laurie VK3AMA
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Color scheme: "on band" always highest priority?

[Paul Kube]

Bill, thanks for your reply. I understand UI design is a hard problem and
I'm glad you're on it. It sure seems that WSJT-X has a solid technical core
to build around, which is a good thing.

*As always, finding the balance of developing a tool that makes digital *
*communication by amateur radio fun and requires traditional aspects of *
*operating skill to do it well without making an automated QSO server *
*that spoils the fun for everyone.*

Yes. On that point, I was a little surprised to see that "Call 1st" was
available as an option in RU contest mode.

*I wonder if anyone has reverted to the old fashioned dupe sheet *
*techniques using a pen and paper? *


 Back in the day, my memory was a lot better and I would work without a
dupe sheet until a break, when I would go back over the log and update it.
Now I'm totally spoiled with contest logging software...

73, Paul K6PO

On Thu, Nov 29, 2018 at 5:52 AM Bill Somerville 
wrote:

> On 29/11/2018 04:47, Paul Kube wrote:
> > Is there any way to control colors of a non-CQ message? There doesn't
> > seem to be, and I would like to do that.
> >
> > For example:, I'd like to have a visual cue when someone not in the
> > log is finishing a QSO, so I know they're not a dupe and I can tailend
> > without waiting for their next CQ: highlight their "W1XYZ K0ABC 73"
> > message. (This came up a lot in this evening's mock contest.)
> >
> > Possible?
> >
> Hi Paul,
>
> not currently. Clearly applying decode colour highlighting to non-CQ
> messages is very desirable and it is on the to-do list but is not
> trivial to implement given the current code base. Also some sort of
> mechanism to highlight new multipliers, in contests like the ARRL RTTY
> RU where multipliers are not covered by the current decode highlighting
> facility, would be equally desirable for serious contest operators.
>
> For some background, as the speed of QSOs has increased and the number
> of decodes has increased with modes like FT8 on HF, it has become
> necessary for WSJT-X to do more and more interpretation of message
> content for it to be anything like satisfying and ergonomic to use. This
> has evolved organically on top a framework that was originally developed
> to just display the decoded messages and let he user make all the
> decisions about what to transmit next and what to log at the end of a
> QSO. Some fairly major internal reworking is desperately needed to make
> further implementation like this practical without introducing many new
> defects as a side-effect.
>
> As always, finding the balance of developing a tool that makes digital
> communication by amateur radio fun and requires traditional aspects of
> operating skill to do it well without making an automated QSO server
> that spoils the fun for everyone.
>
> I wonder if anyone has reverted to the old fashioned dupe sheet
> techniques using a pen and paper? I always used to use an A3 sheet
> divided into 26 boxes for each letter of the alphabet and enter worked
> calls indexed by the first letter of the end letters part of their
> callsign, e.g. my call G4WJS would be written into the 'W' square when
> worked. Another sheet was used for mults worked, ok until trying the WPX
> contest!
>
> 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] Color scheme: "on band" always highest priority?

[Paul Kube]

Bill,

(I'll put this comment in this thread instead of starting a new one, since
you are the "color" guy :)

Is there any way to control colors of a non-CQ message? There doesn't seem
to be, and I would like to do that.

For example:, I'd like to have a visual cue when someone not in the log is
finishing a QSO, so I know they're not a dupe and I can tailend without
waiting for their next CQ: highlight their "W1XYZ K0ABC 73" message. (This
came up a lot in this evening's mock contest.)

Possible?

Thanks,

Paul K6PO

On Wed, Nov 28, 2018 at 1:42 PM Bill Somerville 
wrote:

> On 28/11/2018 21:22, DG2YCB, Uwe wrote:
>
> Just one further question: N9BUB is a new call for me, but also a new call
> on band. Thus, background color is assigned to the darker green and
> foreground color is assigned to blue. Correct? But that means that
> currently I cannot use the foreground color for differentiation between
> “totally new” and “new…on Band”, because a new call is always also a new
> call on band. Is that right?
>
> Hi Uwe,
>
> sure you can, make the "on band" highlight the higher priority of the two.
>
> I would suggest that using foreground colour for an "all bands" highlight
> type and background colour for its "on band" partner is wasteful, you would
> be better to stick to pairs either using different foreground or different
> background.
>
> Hmmm, perhaps the default ordering should the "on band" variants as higher
> priority than their "all band" partners, I will switch them around.
>
> 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] Changing bands when Split operation = Rig: a suggestion

[Paul Kube]

I use Split operation = Rig with my Icom radios, which puts the radio in
SPLIT mode, in which VFO A is the receive VFO, and VFO B is the transmit
VFO.

Now, when changing bands, WSJT-X only changes the frequency of VFO A,
leaving VFO B on the preious band, until a WSJT-X initiated transmission
occurs; then VFO B is commanded to the appropriate frequency on the new
band.

A downside to this is that when changing bands, my automatic antenna tuner
needs to adjust itself to the new band, and to do this the radio needs to
transmit at a low power level. But since VFO B is the transmit VFO, and it
is still on the previous band, this doesn't work.

Of course there are various ways to get it to work, that involve pushing a
button or two before initiating the antenna tuner sequence. But I don't see
why changing bands within WSJT-X couldn't just move both VFO A and VFO B to
the new band to begin with.

WSJT-X  v2.0.0-rc5
Windows 10 Pro x64  Build 17134
Icom IC-7300 and Icom IC-7200

Thanks,

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

Re: [wsjt-devel] Yet another RC5 colors issue

[Paul Kube]

It seems my issue may be related to an aspect of the problems reported
here: https://sourceforge.net/p/wsjt/mailman/message/36478478/.

In that thread, Uwe describes trying to distinguish between "New Call" and
"New Call on Band" with foreground color only, and observes that it doesn't
work.

FWIW, I have never merged any other log files into my WSJT-X log.

Paul K6PO

On Tue, Nov 27, 2018 at 7:55 PM Paul Kube  wrote:

> Hi George,
>
> In my instructions for reproducing the problem, I unchecked everything,
> except for CQ in message, and New Call on Band. It doesn't make
> any difference what foreground color LoTW User Highlight is using. And it
> doesn't make any difference what foreground color CQ in message is using,
> it gets used for both New Call on Band and for CQ in message. Whereas the
> background color for CQ in message is used only for CQ in message. This
> is... counterintuitive.
>
> 73, Paul K6PO
>
> On Tue, Nov 27, 2018 at 6:23 PM WB5JJJ  wrote:
>
>> Prob uncheck LoTW User highlight or change it to see if that's the
>> problem.
>>
>> On Tue, Nov 27, 2018 at 8:00 PM Paul Kube  wrote:
>>
>>> This issue involves foreground color, not background color:
>>>
>>> In Settings > Colors:
>>>
>>>
>>>1. Click Reset Highlighting, and confirm
>>>2. Uncheck all boxes in the Decode Highlighting list
>>>3. Right click CQ in message, Foreground Color, pick something other
>>>than black, e.g. red; click OK
>>>4. Check only boxes for New Call on Band, and CQ in message
>>>5. Note that New Call on Band and CQ in message have different
>>>background AND foreground colors.
>>>6. Click OK
>>>
>>> Now one would expect decodes for New Call on Band, and CQ in message,
>>> would have different background AND foreground colors.
>>>
>>> However: background colors are indeed different, but foreground colors
>>> are the same, e.g. red.
>>>
>>> WSJT-X  v2.0.0-rc5
>>> Windows 10 Pro x64  Build 17134
>>>
>>> Thanks,
>>>
>>> Paul K6PO
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>>
>>
>> --
>> George Cotton, WB5JJJ
>> PO Box 1025
>> Russellville, AR  72811
>>
>> 479.968.7737 Home
>> 479.857.7737 Cell
>>
>> DMR K5CS (Local Repeater) - 310515, CC1, TS2
>> DMR Arkansas - 3105
>>
>> 4
>> ___
>> 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] Yet another RC5 colors issue

[Paul Kube]

Hi George,

In my instructions for reproducing the problem, I unchecked everything,
except for CQ in message, and New Call on Band. It doesn't make
any difference what foreground color LoTW User Highlight is using. And it
doesn't make any difference what foreground color CQ in message is using,
it gets used for both New Call on Band and for CQ in message. Whereas the
background color for CQ in message is used only for CQ in message. This
is... counterintuitive.

73, Paul K6PO

On Tue, Nov 27, 2018 at 6:23 PM WB5JJJ  wrote:

> Prob uncheck LoTW User highlight or change it to see if that's the
> problem.
>
> On Tue, Nov 27, 2018 at 8:00 PM Paul Kube  wrote:
>
>> This issue involves foreground color, not background color:
>>
>> In Settings > Colors:
>>
>>
>>1. Click Reset Highlighting, and confirm
>>2. Uncheck all boxes in the Decode Highlighting list
>>3. Right click CQ in message, Foreground Color, pick something other
>>than black, e.g. red; click OK
>>4. Check only boxes for New Call on Band, and CQ in message
>>5. Note that New Call on Band and CQ in message have different
>>background AND foreground colors.
>>6. Click OK
>>
>> Now one would expect decodes for New Call on Band, and CQ in message,
>> would have different background AND foreground colors.
>>
>> However: background colors are indeed different, but foreground colors
>> are the same, e.g. red.
>>
>> WSJT-X  v2.0.0-rc5
>> Windows 10 Pro x64  Build 17134
>>
>> Thanks,
>>
>> Paul K6PO
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> --
> George Cotton, WB5JJJ
> PO Box 1025
> Russellville, AR  72811
>
> 479.968.7737 Home
> 479.857.7737 Cell
>
> DMR K5CS (Local Repeater) - 310515, CC1, TS2
> DMR Arkansas - 3105
>
> 4
> ___
> 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] Yet another RC5 colors issue

[Paul Kube]

This issue involves foreground color, not background color:

In Settings > Colors:


   1. Click Reset Highlighting, and confirm
   2. Uncheck all boxes in the Decode Highlighting list
   3. Right click CQ in message, Foreground Color, pick something other
   than black, e.g. red; click OK
   4. Check only boxes for New Call on Band, and CQ in message
   5. Note that New Call on Band and CQ in message have different
   background AND foreground colors.
   6. Click OK

Now one would expect decodes for New Call on Band, and CQ in message, would
have different background AND foreground colors.

However: background colors are indeed different, but foreground colors are
the same, e.g. red.

WSJT-X  v2.0.0-rc5
Windows 10 Pro x64  Build 17134

Thanks,

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

Re: [wsjt-devel] wsjt-x 2.0.0-rc5 right click on waterfall not as documented

[Paul Kube]

Ah. Thanks, Joe and Wolfgang.

73 Paul K6PO

On Tue, Nov 27, 2018 at 10:11 AM Wolfgang  wrote:

> Hello Paul,
>
> oh yes, if you left click into that pop-up window, RX & TX is set on that
> position
>
> 73 de Wolfgang
> OE1MWW
>
> Tuesday, November 27, 2018, 6:52:52 PM, you wrote:
>
>
> wsjt-x 2.0.0-rc5
> Windows 10 Pro x64 Version10.0.17134 Build 17134
>
> Position the mouse cursor in the waterfall window.
> Right click.
> A small dialog pops up announcing "Set Rx and Tx Offset".
> The Rx and Tx offsets themselves are not affected.
>
> However, the WSJT-x Special Mouse Commands documentation displayed with F5
> says:
> Ctrl-click or Right-click to set Rx and Tx frequencies
>
> Thanks,
>
> Paul K6PO
>
>
>
>
>
>
> --
> Amateur radio is the most expensive type of free-of-charge communication!
> Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] wsjt-x 2.0.0-rc5 right click on waterfall not as documented

[Paul Kube]

wsjt-x 2.0.0-rc5
Windows 10 Pro x64 Version10.0.17134 Build 17134

Position the mouse cursor in the waterfall window.
Right click.
A small dialog pops up announcing "Set Rx and Tx Offset".
The Rx and Tx offsets themselves are not affected.

However, the WSJT-x Special Mouse Commands documentation displayed with F5
says:
Ctrl-click or Right-click to set Rx and Tx frequencies

Thanks,

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