[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

[wsjt-devel] "FT8 Roundup" mock contest [Two Sessions]

[Ed Muns]

In addition to this practice contest just prior to the actual FT8 Roundup
next weekend, there will be an identical practice on Wednesday evening NA
time (0200-0300 UTC Thursday, 29 November).

Don and I feel another practice will be useful since we all need to ensure
we have installed and configured WSJT-X 2.0, rc5 correctly.  (rc4 will also
work, but rc5 is preferred since it has improvements and bug fixes beyond
rc4.)

73,
Ed W0YK
Don AA5AU

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: 26 November, 2018 13:55
To: WSJT software development
Subject: [wsjt-devel] "FT8 Roundup" mock contest

Hi all,

Another one-hour "practice contest" is scheduled for Saturday, December 
1, 0200-0300 UTC (that's Friday evening, Nov 30, NA time).  This session 
will serve as a final tune-up opportunity for those planning to operate 
in the "FT8 Roundup" on December 1-2 (more details below).

DIAL FREQUENCIES


The practice event will use dial frequencies 7.080-7.100 and 
14.130-14.150 MHz in 2 kHz increments -- the same as recommended for the 
FT8 Roundup and the ARRL RTTY Roundup (January 5-6, 2019).  Start at the 
low end, dial frequency 7.080 or 14.130.  If/when the lower sub-bands 
fill up, QSY upward in 2 kHz increments (7.082, 7.084, etc.).  (Use 
keyboard shortcuts Ctrl+Shift+F11 and Ctrl+Shift+F12 to move dial 
frequency down/up by 2 kHz.)

Everyone works everyone.  Do not use a compound or nonstandard callsign 
in this event.

To participate you must use WSJT-X 2.0 RC5 (or RC4, but RC5 is 
preferred).  Installation packages for RC5 in Windows, Linux, and macOS 
can be found near the bottom of this web page:
https://physics.princeton.edu/pulsar/k1jt/wsjtx.html

A revised "Quick-Start Guide to WSJT-X 2.0" for RC5 is posted here:
https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf
Be sure to read this entire document before using WSJT-X 2.0.

PREPARATION FOR THE MOCK CONTEST


Detailed setup instructions for the FT8 Roundup are posted here:
https://www.rttycontesting.com/ft8-roundup/preparation/
They serve equally well for the practice session.

Rules for the FT8 Roundup specify 100 W maximum power output.  We 
recommend the same limit for the practice session.

OPERATING PROCEDURES


Best operating practices for FT8 in contests will surely evolve as users 
gain experience.  As initial suggestions we recommend procedures 
slightly different from those used for everyday FT8 operation.  CQing 
stations ("Run" stations) should check TX EVEN/1ST and HOLD TX FREQ, and 
select audio Tx frequencies 200, 400, 600, ..., integral multiples of 
200 Hz. Search-and-pounce (S+P) stations should uncheck TX EVEN/1ST and 
HOLD TX FREQ and should call a CQing station at 0, 60, or 120 Hz above 
the CQ frequency.  These procedures should help to contain the 
mini-pileups around Run stations to relatively small frequency ranges. 
S+P stations can use Shift+F11 and Shift+F12 to move their Tx frequency 
down/up by 60 Hz.

If a 2 kHz segment becomes too full of stations, users should QSY upward 
in 2 kHz increments, thus establishing new operating sub-bands.  Again, 
you can use Ctrl+Shift+F11 and Ctrl+Shift+F12 to QSY between 
dial-frequency sub-bands.

THE FT8 ROUNDUP, DECEMBER 1-2
-

The FT8 Roundup starts at 1800 UTC on Saturday, December 1 and ends at 
2359 UTC on Sunday, December 2, 2018.  Power limit is 100 W output: no 
high-power amplifiers!  Full contest rules are posted at 
https://www.rttycontesting.com/ft8-roundup/ .

LOOKING TWO WEEKS AHEAD
---

We are planning to make the full General Availability (GA) release of 
WSJT-X 2.0 on or before December 10, 2018.  The necessary transition 
from from WSJT-X v1.9.1 to WSJT-X v2.0 protocols for FT8 and MSK144 
should take place by the end of calendar year 2018.

THEREFORE: As soon as possible after December 10, and certainly by 
January 1, 2019, everyone should be using WSJT-X 2.0 or a compatible 
v2.0 version of derivative programs such as JTDX or MSHV.  As of today, 
PSKreporter statistics show roughly 3000 users of WSJT-X versions older 
than v1.9.1, 9500 users of v1.9.1, and 3000 users of v2.0-rc#.  Please, 
everyone, help us to spread the word that upgrading to v2.0 after 
December 10 is very important.  There will be no looking back!

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

Re: [wsjt-devel] V2 RC5 logging bug

[Neil Zampella]

Gary,

I'm fairly sure it has always been this way, even before v1.8 and FT8.   
I see to remember that it was the reason the last CQ caller's 73 was 
added to the 'conversation',  to trigger the Log QSO window.   Adding 
the RR73 as an option in v1.9 was to acknowledge what a log of CQ 
callers were actually doing to avoid that last 73 and trigger the Log 
QSO dialog.



Neil, KN3ILZ

On 11/27/2018 7:04 PM, Gary Hinson wrote:


Hi.

The ‘prompt me to log QSO’ setting only seems to do its thing when I 
send a 73 message – specifically, it seems, I have to send a free-text 
message containing the string “73”.  So, if I send a custom message to 
conclude a QSO, one that doesn’t include 73, I’m not prompted to log 
the QSO.


I know I can still hit the Log QSO button … provided I’m aware of the 
issue and log it before the next caller’s info causes the messages to 
be generated for the next QSO.


I’m wary of stirring up the ‘when is a QSO not a QSO’ argument yet 
again but personally I would rather be prompted to log the QSO as I am 
sending or after I have sent an R message (Tx3 or Tx4, both RRR and 
RR73 forms), or at the very least when I send any free text message 
after having sent Tx3 or Tx4, not necessarily one containing “73”.


73
Gary  ZL2iFB

PS  For bonus marks, I’d love the Tx5 message box to warn me if I 
enter too many characters … like perhaps showing the 14^th and later 
characters in red, or bold, or italics.





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

Re: [wsjt-devel] tone markers in JT65

[Peter Sumner]

Hello Dev team,
 while reading the last batch of posts here, I noticed a reference by
another that their system appear to jump into JT9 in certain circumstances
so while pondering what is going on with my RC5 install, I noticed the Red
TX marker on the waterfall is the size I would expect for JT9 and not the
wider one expected for JT65 A, B or C. When I do select JT65C I can start
to see the RX tone marker but all scrunched up together, yet decoding of
our local JT65B beacon works when I go back to JT65B.

When I select JT9 the RX and TX markers are the expected small complimentry
'u' and 'n' shapes, when I switch to JT65 the TX marker is the same narrow
one it was for JT9.

As best as I can tell the actual decoder seems to be happy but the logic
teling the Wide graph what to do seems to be confused.

O/S reasonably fresh install of Windows 10 Pro X64, all updates applied

Is it possible for others to please check the behaviour of the JT65 modes
(VHF/UHF features enabled) ?
Regards,
Peter, vk5pj

On Wed, Nov 28, 2018 at 10:17 AM Peter Sumner  wrote:

> Hello Dev team,
>   I was asked today about the tone markers in the Wide Graph when using
> JT65 as it would seem in V2.x these have been dropped.  Could not see any
> mention of this in the release notes but guess it was a development
> decision, just want to make sure it was not an unexpected outcome?
>
> A side by side screen capture (1.91 and 2.0 TC5)  is here:
> http://www.users.on.net/~pedroj/wsjtx/WSJT-JT65.JPG
>
> Regards,
> Peter vk5pj
>
>
___
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

[WB5JJJ]

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] 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 rc5

[Stephen Taylor - K6SJT]

"Still jumps out of 73 (Tx5) to CQ (Tx6).  Only a problem with the very weak
signals that don't decode it the first time. I am getting better at guessing
who will need it repeated and moving back to TX5 and enabling TX.
Even though "Disable TX after 73" is not checked?"


Maurice - I concur that this is an issue I hope will get resolved in the GA.


As I recall from the earlier days of FT8, so long as the 'Call 1st' box was
NOT CHECKED the 'Auto seq' would STAY on 73 (Tx5).  

If we're not sending CQ but answering others CQs, then I don't want the
'Auto seq' to move to CQ (Tx6) at the end of every QSO.

73
Stephen - K6SJT




From: M Lewton [mailto:mplew...@hotmail.com] 
Sent: Tuesday, November 27, 2018 3:45 PM
To: WSJT software development
Subject: Re: [wsjt-devel] WSJT-X 2.0 rc5


Hello Joe

I tried rc5 on 2 ea. I5 computers running Windows 10 pro..  Latest versions.

Running rc5 yesterday afternoon and today.  Works very good, FT8 only 
tested.
A lot more operators today, must be catching on.
I was getting tired working the same 20 or so hams the last week.

Still jumps out of 73 (Tx5) to CQ (Tx6).  Only a problem with the very weak 
signals that don't decode it the first time.
I am getting better at guessing who will need it repeated and moving back to

TX5 and enabling TX.
Even though "Disable TX after 73" is not checked?

Tried rc5 on my Raspberry Pi3 B+ too.  The only thing that was a problem was

the "colors".  After I reset colors to the default value it too worked as it

should.
No problem decoding the few rc5 operators with this slow Pi computer. 
Remains to be seen when everyone moves to the new version.
My Pi is only to play with.


The following is part of my ALL TXT file this morning.  I have been trying 
to get this guy for several days.
Some operators seem to be working him??
His call seems to be too long ??


Edited out some and QSB did the rest.

175630 -21  0.1 2260 ~  CQ ON1418END

175730 -19  0.1 2260 ~  CQ ON1418END

175800 -20  0.1 2260 ~  CQ ON1418END

175830 -21  0.1 2259 ~  CQ ON1418END
175830  -7  0.1 2507 ~  W2GPK KB3MOW -18
181127_175845  Transmitting 14.074 MHz  FT8:   WA6PHR
181127_175915  Transmitting 14.074 MHz  FT8:   WA6PHR
175900  -5  0.2  694 ~  N7BT W7PP RR73
175900 -10  0.1 2507 ~  W2GPK KB3MOW -18
175930   4  0.2  694 ~  CQ W7PP DM33
175930 -11  0.1 2507 ~  CQ KB3MOW FN01
175945   0  0.4 2382 ~  N8TCP N5OK EM15
175945 -16  0.1 2507 ~  KB3MOW W2GPK R-15
175945 -23  0.1 2589 ~  N8TCP WB2TQE R-06
175945 -15  0.1 2755 ~  KA2AIC N5SD EM27
18   7  0.2  694 ~  CQ W7PP DM33
18 -16  0.1 2508 ~  CQ KB3MOW FN01
180015 -14  0.1 2589 ~  N8TCP WB2TQE 73
180015  -9  0.1 2755 ~  KA2AIC N5SD EM27
180030 -20  0.1 2260 ~  N4AB  +00
180030   3  0.2  694 ~  CQ W7PP DM33
180045  -1  0.4 2382 ~  N8TCP N5OK EM15
180045  -9  0.2 2440 ~   N4AB R-05
180045 -18  0.1 2589 ~  KA2AIC WB2TQE EL96
180100 -24  0.1 2260 ~   ON1418END RR73
180100   3  0.2  694 ~  CQ W7PP DM33
180115   0  0.4 2382 ~  N8TCP N5OK R+11
180115 -11  0.2 2440 ~  ON1418END  73
180130  -4  0.2  695 ~  CQ W7PP DM33
180145  -2  0.4 2383 ~  N8TCP N5OK 73


Same guy a few days ago while running rc4:
2018-11-25 15:22  14.074 MHz  FT8
152245 -16  0.2 2513 ~  CQ ON1418END
181125_152300  Transmitting 14.074 MHz  FT8:   WA6PHR
152315 -17  0.2 2512 ~  CQ ON1418END
181125_152330  Transmitting 14.074 MHz  FT8:   WA6PHR
152345 -16  0.2 2512 ~  CQ ON1418END
181125_152400  Transmitting 14.074 MHz  FT8:  ON1418END WA6
2018-11-25 15:24  18.1 MHz  FT8

Anyway I, and a lot of others, appreciate all your work.

73 Maurice

WA6PHR 



___
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] RC5 Test

[John Zantek]

Took RC5 for a run late this afternoon on 40M.  6 quick Q's, including 1 DX.
Other than the need to Reset Highlighting at the start (previously
reported), there were no issues.  Very smooth and stable.  Very grateful to
Joe, Steve, Bill for this latest.

Look forward to the FT8 Roundup this weekend.

73 John W7CD




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

Re: [wsjt-devel] RC5 Colors

[Bill Somerville]

On 27/11/2018 23:58, Morris Wideman via wsjt-devel wrote:
Bill I use HRD for logging/rig control and this is what I saved with 
ADIF Master from my log. I use other FT8 software a lot and this meant 
many qso`s were not in WSJTX and I had previously trimmed down my HRD 
log with master and replaced the ADI file with this but I noticed I 
had left fields in that were not in what WSJTX saves. What is in this 
attachment is same as what WSJTX saves just out of order. Do you see 
any problems with this format before I proceed to make a new 
replacement. Also it would be a big help to include a "worked B4" 
filter in what is processed by WSJTX. I was on 20M this AM and several 
77 bit stations on from EU I was able to work most but I would keep 
clicking on stations I had just worked most annoying to not have some 
way to distinguish/eliminate B4`s.

Thank you for your help
Morris WA4MIT

20m 5X TU best 73 GL 14.076878 
JK13bm FT8 EM63eh 
WA4MIT -13 -24 
WA4MIT 154100 154000 
35.000 20181127 



Hi Morris,

that's fine.

The needed call or needed call on band is equivalent to a worked before 
marker. If you turn those on then any CQ calls with a green background 
(or whatever highlighting options you choose for CQ calls) are worked 
before stations.


73
Bill
G4WJS.



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

[wsjt-devel] V2 RC5 logging bug

[Gary Hinson]

Hi.

The 'prompt me to log QSO' setting only seems to do its thing when I send a
73 message - specifically, it seems, I have to send a free-text message
containing the string "73".  So, if I send a custom message to conclude a
QSO, one that doesn't include 73, I'm not prompted to log the QSO.

I know I can still hit the Log QSO button . provided I'm aware of the issue
and log it before the next caller's info causes the messages to be generated
for the next QSO.

I'm wary of stirring up the 'when is a QSO not a QSO' argument yet again but
personally I would rather be prompted to log the QSO as I am sending or
after I have sent an R message (Tx3 or Tx4, both RRR and RR73 forms), or at
the very least when I send any free text message after having sent Tx3 or
Tx4, not necessarily one containing "73".  

73
Gary  ZL2iFB

PS  For bonus marks, I'd love the Tx5 message box to warn me if I enter too
many characters . like perhaps showing the 14th and later characters in red,
or bold, or italics.

 

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

Re: [wsjt-devel] RC5 Colors

[Morris Wideman via wsjt-devel]

 Bill I use HRD for logging/rig control and this is what I saved with ADIF 
Master from my log. I use other FT8 software a lot and this meant many qso`s 
were not in WSJTX and I had previously trimmed down my HRD log with master and 
replaced the ADI file with this but I noticed I had left fields in that were 
not in what WSJTX saves. What is in this attachment is same as what WSJTX saves 
just out of order. Do you see any problems with this format before I proceed to 
make a new replacement. Also it would be a big help to include a "worked B4" 
filter in what is processed by WSJTX. I was on 20M this AM and several 77 bit 
stations on from EU I was able to work most but I would keep clicking on 
stations I had just worked most annoying to not have some way to 
distinguish/eliminate B4`s. Thank you for your helpMorris WA4MIT
20m 5X TU best 73 GL 14.076878 
JK13bm FT8 EM63eh WA4MIT 
-13 -24 WA4MIT 154100 
154000 35.000 20181127  
On Tuesday, November 27, 2018, 5:09:09 PM CST, Bill Somerville 
 wrote:  
 
  Hi Morris, 
  the order of fields in an ADIF record doesn't matter. The outstanding issue 
with WSJT-X v2.0.0 RC5 is that it doesn't interpret ADIF record contents 
case-insensitively when it could and should. For example at least one logging 
application writes the BAND ADIF field in upper case rather than the ADIF 
specified lowercase, i.e. 80M instead of 80m. WSJT-X should not treat 80M and 
80m as different but currently it does. It is an easy fix that is already 
coded, I just need some confirmations from users, who are seeing issues with 
needed per band highlighting that they are using ADIF exports from other 
logging applications in wsjtx_log.adi . 
  If you are seeing this issue I can send you a patched version of WSJT-X to 
test.
  
  73
 Bill
 G4WJS. 
  On 27/11/2018 22:58, Morris Wideman via wsjt-devel wrote:
  
  Bill if one were to import from a logging program would the order of the 
fields matter if we used something like ADIF Master to par the ADI fields down 
to the same as that WSJT-X saves just in a different order. 
  Thanks 73 Morris WA4MIT 
  On Tuesday, November 27, 2018, 3:50:28 PM CST, Bill Somerville 
 wrote:  
  
  On 27/11/2018 21:30, Al wrote:
   
 Note below the change  in color for GW4HDR after I called him the first time..
 Note also that even though I had just worked N8TCP, now colored for new 
call... 
 
 
Hi Al,
 
there is one outstanding issue in the highlighting that I am aware of, it is 
related to imported ADIF log files. Have you used an export from some logging 
application to replace the wsjtx_log.adi file?
 
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] tone markers in JT65

[Peter Sumner]

Hello Dev team,
  I was asked today about the tone markers in the Wide Graph when using
JT65 as it would seem in V2.x these have been dropped.  Could not see any
mention of this in the release notes but guess it was a development
decision, just want to make sure it was not an unexpected outcome?

A side by side screen capture (1.91 and 2.0 TC5)  is here:
http://www.users.on.net/~pedroj/wsjtx/WSJT-JT65.JPG

Regards,
Peter vk5pj
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.0 rc5

[M Lewton]

Hello Joe

I tried rc5 on 2 ea. I5 computers running Windows 10 pro..  Latest versions.

Running rc5 yesterday afternoon and today.  Works very good, FT8 only 
tested.
A lot more operators today, must be catching on.
I was getting tired working the same 20 or so hams the last week.

Still jumps out of 73 (Tx5) to CQ (Tx6).  Only a problem with the very weak 
signals that don't decode it the first time.
I am getting better at guessing who will need it repeated and moving back to 
TX5 and enabling TX.
Even though "Disable TX after 73" is not checked?

Tried rc5 on my Raspberry Pi3 B+ too.  The only thing that was a problem was 
the "colors".  After I reset colors to the default value it too worked as it 
should.
No problem decoding the few rc5 operators with this slow Pi computer. 
Remains to be seen when everyone moves to the new version.
My Pi is only to play with.


The following is part of my ALL TXT file this morning.  I have been trying 
to get this guy for several days.
Some operators seem to be working him??
His call seems to be too long ??


Edited out some and QSB did the rest.

175630 -21  0.1 2260 ~  CQ ON1418END

175730 -19  0.1 2260 ~  CQ ON1418END

175800 -20  0.1 2260 ~  CQ ON1418END

175830 -21  0.1 2259 ~  CQ ON1418END
175830  -7  0.1 2507 ~  W2GPK KB3MOW -18
181127_175845  Transmitting 14.074 MHz  FT8:   WA6PHR
181127_175915  Transmitting 14.074 MHz  FT8:   WA6PHR
175900  -5  0.2  694 ~  N7BT W7PP RR73
175900 -10  0.1 2507 ~  W2GPK KB3MOW -18
175930   4  0.2  694 ~  CQ W7PP DM33
175930 -11  0.1 2507 ~  CQ KB3MOW FN01
175945   0  0.4 2382 ~  N8TCP N5OK EM15
175945 -16  0.1 2507 ~  KB3MOW W2GPK R-15
175945 -23  0.1 2589 ~  N8TCP WB2TQE R-06
175945 -15  0.1 2755 ~  KA2AIC N5SD EM27
18   7  0.2  694 ~  CQ W7PP DM33
18 -16  0.1 2508 ~  CQ KB3MOW FN01
180015 -14  0.1 2589 ~  N8TCP WB2TQE 73
180015  -9  0.1 2755 ~  KA2AIC N5SD EM27
180030 -20  0.1 2260 ~  N4AB  +00
180030   3  0.2  694 ~  CQ W7PP DM33
180045  -1  0.4 2382 ~  N8TCP N5OK EM15
180045  -9  0.2 2440 ~   N4AB R-05
180045 -18  0.1 2589 ~  KA2AIC WB2TQE EL96
180100 -24  0.1 2260 ~   ON1418END RR73
180100   3  0.2  694 ~  CQ W7PP DM33
180115   0  0.4 2382 ~  N8TCP N5OK R+11
180115 -11  0.2 2440 ~  ON1418END  73
180130  -4  0.2  695 ~  CQ W7PP DM33
180145  -2  0.4 2383 ~  N8TCP N5OK 73


Same guy a few days ago while running rc4:
2018-11-25 15:22  14.074 MHz  FT8
152245 -16  0.2 2513 ~  CQ ON1418END
181125_152300  Transmitting 14.074 MHz  FT8:   WA6PHR
152315 -17  0.2 2512 ~  CQ ON1418END
181125_152330  Transmitting 14.074 MHz  FT8:   WA6PHR
152345 -16  0.2 2512 ~  CQ ON1418END
181125_152400  Transmitting 14.074 MHz  FT8:  ON1418END WA6
2018-11-25 15:24  18.1 MHz  FT8

Anyway I, and a lot of others, appreciate all your work.

73 Maurice

WA6PHR 



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

Re: [wsjt-devel] RC5 Colors

[Morris Wideman via wsjt-devel]

 Bill if one were to import from a logging program would the order of the 
fields matter if we used something like ADIF Master to par the ADI fields down 
to the same as that WSJT-X saves just in a different order.
Thanks 73 Morris WA4MIT
On Tuesday, November 27, 2018, 3:50:28 PM CST, Bill Somerville 
 wrote:  
 
  On 27/11/2018 21:30, Al wrote:
  
Note below the change  in color for GW4HDR after I called him the first time..
 Note also that even though I had just worked N8TCP, now colored for new call...
 
 
Hi Al,
 
there is one outstanding issue in the highlighting that I am aware of, it is 
related to imported ADIF log files. Have you used an export from some logging 
application to replace the wsjtx_log.adi file?
 
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] 2RSC3 > 2RSC4 decoding disappeared FT8

[Ken Myers]

Thanks Neil. Done

Ken VK4GC

On Wed, 28 Nov 2018 at 00:59, Neil Zampella  wrote:

> I'd uninstall RC3 as it is not supposed to be used after Nov 30th.
>
> I'd put 1.9.1 back on for the time being until 2.0 goes general release
> for DXPeditions if nothing else.
>
> Neil, KN3ILZ
> On 11/27/2018 12:08 AM, Ken Myers wrote:
>
> Sure I had read it.  Not the problem.  Needed another station that was
> using RC5 to QSO with - VK3VM was very helpful. Also JA9PHV. All good.
> Just got to get more switched over to RC5.
> Using pSKreporter helped as reporting passive stations decoded me, so they
> were using RC4/5.  I think there is a greater Ham density in USA.
>
> All good now.  I use both RC3 and RC5 installed in different folders.  Go
> back to RC3 when lonely, RC5 when courageous!!
>
> Cheers
>
> Ken
>
> On Tue, 27 Nov 2018 at 14:55, Neil Zampella  wrote:
>
>> Ken,
>>
>> did you read the Quick Start guide.  Release Candidates 4 & 5 (released
>> today) are only 77bit, they will NOT decode 75 bit FT8, which is probably
>> why you're not seeing decodes on a normal FT8 frequency.   The Quick Start
>> advises that you use the standard FT8 frequency, but use the audio range
>> above 2000 for 77 bit work until the General Release in December.
>>
>> Neil, KN3ILZ
>> On 11/26/2018 6:15 PM, Ken Myers wrote:
>>
>> Hi
>> I have been successfully been using RSC3 then changing to RSC4 there was
>> no decode of waterfall content. FT8 mode.
>>
>> 2 installations -
>> 1  MSSurface Win10 up to date, 2 radios (FT991a & FTdx3000 both USB) -
>> non decode,
>> 2  HP Allinone with FT897/Singnalink. - non decode,
>> (both setups using HRD (up to date) for CAT control)
>>
>> For all:
>> 1.9.1 works great
>> 2.0 RC3 works great
>> 2.0 RC4  good waterfall (therefore good audio present) - NO decode.
>>
>> uninstalling/reinstalling forward and back through versions gives the
>> same result.
>>
>> i have concluded:
>> 1  I must be holding my mouth wrong - OR
>> 2  I have missed a new setting.
>> 3  When I have been looking/testing RC4, no RC4 (77 bit) transmissions.
>> Not sure here as I have been especially been looking top band.
>>
>> 2 probably!!
>>
>> In the words of the rich young ruler to Jesus - "What must I do to be
>> saved?"
>>
>> The other problem is occasionally the FT897 does not let go of transmit
>> after sending.
>> Solved by closing WSJTX.  Have tried 2 soundcards, Signalink and
>> Rigblaster P, - persistent intermittent.  MIGHT be my aging FT897 -
>> haven't ruled that out.
>>
>> Great Program Great work.
>>
>> Thanks
>> --
>> Cheers
>>
>> Ken Myers
>> VK4GC
>>
>> Sunnybank Hills QLD AUS
>> M   +61 414 487 004
>>
>>
>>
>> 
>>  Virus-free.
>> www.avg.com
>> 
>> <#m_3691454082358240537_m_5895215522691016707_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> --
> Cheers
>
> Ken Myers
>
> Sunnybank Hills QLD AUS
> M   +61 414 487 004
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Cheers

Ken Myers

Sunnybank Hills QLD AUS
M   +61 414 487 004
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC.4 and RC.5 problem

[Ken Myers]

Thanks, need 77bit both ends or the old protocol both ends.  So at the
moment down under VK/ZL- in the times i operate - few - getting more -
77bit signals. So fa,r 6m FT8 and 2m MSK144 operators still using non 77bit
software.
Build it and they will come - eventually!!
thanks Joe

Ken

On Tue, 27 Nov 2018 at 23:45, Joe Taylor  wrote:

> Please read the Release Notes.  First item on the Help menu.
>
> On 11/26/2018 10:13 PM, Unni Tharakkal wrote:
> > Hai
> >
> > I tried the new RC.4 and. latest RC.5 upgrades. On both there is no RX
> > decode how to solve it
> >
> > VU2TE
> > Unni
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Cheers

Ken Myers

Sunnybank Hills QLD AUS
M   +61 414 487 004
___
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?

[Bill Somerville]

On 27/11/2018 17:00, DG2YCB, Uwe wrote:


Many thanks for great work on the color scheme! Basic functions work 
well now with v2.0.0-rc5 here at my PC. (Windows 10 64 bit)


However, there seems to be some minor bugs left. May the following 
observations help you to identify them as well:


(1) Seems to be, that “New Call on Band” has always a higher priority 
than “New Call”. When both are enabled, a new callsign is always 
highlighted as “New Call on Band”, even when I’ve not yet worked that 
station before on any band. Tried to chance priority settings, but no 
effect (see screenshot 1).


(2) Same seems to be true for “New Grid on band” versus “New Grid”. 
When enabled, all new grids are highlighted as “New Grid on Band” I 
don’t know if it is also the case for “New DXCC”, “New CQ Zone” and 
“New ITU Zone” and so on, but there was no station on the band to check.


(3) When “on Band” settings are disabled color scheme works well. Only 
one exception: I really don’t know why, but even when “New Call on 
Band” is disabled, one callsign (OE3FVU) was highlighted as “New Call 
on Band” (see screenshot 2). Closed WSJT-X and started it again, but 
no change. What may be the reason?


Just for explanation: I’ve already changed default to my favorite 
colors. “New Call” and “New Call on Band” has the same background 
color, but “…on Band” with blue foreground color.



Hi Uwe,

are you using ADIF records imported from another application in your 
wsjtx_log.adi file?


73
Bill
G4WJS.

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

Re: [wsjt-devel] RC5 Colors

[Bill Somerville]

On 27/11/2018 21:30, Al wrote:
Note below the change  in color for GW4HDR after I called him the 
first time..
Note also that even though I had just worked N8TCP, now colored for 
new call...


Hi Al,

there is one outstanding issue in the highlighting that I am aware of, 
it is related to imported ADIF log files. Have you used an export from 
some logging application to replace the wsjtx_log.adi file?


73
Bill
G4WJS.

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

Re: [wsjt-devel] Quick-Start Guide to WSJT-X 2.0

[Joe Taylor]

Hi Eugene,

On 11/27/2018 2:26 PM, Eugene UA1NAN wrote:

Hi friends!
I can send a translation (not machine) into Russian of the article
"Quick-Start Guide to WSJT-X 2.0" from Joe Taylor, K1JT.
  73, Eugene, UA1NAN.


Thanks for this offer!  I will be happy to post your translation on the 
WSJT web site.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] WSJT-X rc5 hard crash

[Joe Taylor]

Hi Steve,

Thanks for the report.  You do know that ""W6XX W7WM RR73 TNX" is not a 
legal FT8 message, right?


Nevertheless, the program should not crash when it's given a bad 
message.  This defect will be fixed in the 2.0 GA release.


-- Joe, K1JT

On 11/27/2018 2:19 PM, Steve Boone W7WM wrote:
Sorry, I didn't report this during RC4 but I accidentally discovered 
this unusual behavior with WSJT-X just before RC5 was released. This 
also happens in RC5.


While in QSO at transmitting step TX1, TX2 or TX3
I manually change TX4 to "W6xx W7WM RR73 TNX"  [1 or 2 extra characters 
does not fail)

Click on TX4 (while TX1 is still transmitting)

WSJT-X 2.0 rc5 aborts:
WSJT-X screen disappears, wsjtx.exe task disappears (jt9.exe is still 
active-see note below)

transceiver hangs in transmit mode (PTT)

On restart of WSJT-X
Popup:
       Killing JT9.exe Process
       KilByName return code: 602

OK continues WSJT-X as normal

On initial startup, wsjt.exe has 3 sub-tasks:
wsjtx.exe
jt9.exe
console window host
I have mode = FT8

Windows 10 Pro 1803





___
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] Quick-Start Guide to WSJT-X 2.0

[Eugene Aa]

Hi friends!
I can send a translation (not machine) into Russian of the article
"Quick-Start Guide to WSJT-X 2.0" from Joe Taylor, K1JT.
 73, Eugene, UA1NAN.


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

[wsjt-devel] WSJT-X rc5 hard crash

[Steve Boone W7WM]

Sorry, I didn't report this during RC4 but I accidentally discovered this
unusual behavior with WSJT-X just before RC5 was released. This also
happens in RC5.

While in QSO at transmitting step TX1, TX2 or TX3
I manually change TX4 to "W6xx W7WM RR73 TNX"  [1 or 2 extra characters
does not fail)
Click on TX4 (while TX1 is still transmitting)

WSJT-X 2.0 rc5 aborts:
WSJT-X screen disappears, wsjtx.exe task disappears (jt9.exe is still
active-see note below)
transceiver hangs in transmit mode (PTT)

On restart of WSJT-X
Popup:
  Killing JT9.exe Process
  KilByName return code: 602

OK continues WSJT-X as normal

On initial startup, wsjt.exe has 3 sub-tasks:
wsjtx.exe
jt9.exe
console window host
I have mode = FT8

Windows 10 Pro 1803
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC5 error in JT65

[Joe Taylor]

On 11/27/2018 12:07 PM, Jari A wrote:
... I work several qsos with RC5 on FT8, then got silent with FT8, so I 
change to JT65 as I saw traffic on it.


I also note, that after I change from JT65 to JT9, RC5 keeps tx on FT8, 
even JT9 is indicated below date/ time window.


Aaah!  Now I understand what you did.  These are defects, and they will 
be fixed.


-- 73, Joe, K1JT


___
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

Re: [wsjt-devel] rc5: Tucson/Arizona is CQ Zone 3 (?)

[Bill Somerville]

On 27/11/2018 15:57, Wolfgang wrote:

Interresting finding:

151030 -11 0.3 2302 ~ CQ W7AH DM42  CQ Zone 3

but

154215 -18 0.2 2445 ~ CQ K0VM EN42  U.S.A.

EN42 in in CQ Zone 4, but rc5 reports it as 'U.S.A.'
  
73 de Wolfgang

OE1MWW


Hi Wolfgang,

the way the zone is calculated is via the AD1C cty.dat file. That has an 
override for all W7 prefixes as zone 3. If a W7 station is not in zone 3 
then they need to contact Jim, AD1C, and get a specific override for 
their callsign added with the correct zone. According to QRZ.COM W7AH is 
in CQ ZOne 3.


The reason K0VM is shown as U.S.A. is because it is not a new 
continent/zone/call depending on the enabled highlighting options and 
their ordering.


The reason W7AH shows a CQ Zone 3 is because WSJT-X has new CQ Zone 
highlighting switched on and it thinks you have not worked anyone in CQ 
Zone 3.


The cty.dat file has K0VM as CQ Zone 4 because all K0 prefixes that 
don't have a specific override are assumed to be CQ Zone 4. Clearly you 
have a prior QSO with a CQ Zone 4 station so K0VM is not being 
highlighted as a new CQ Zone. According to QRZ.COM K0VM is in CQ Zone 4.


As far as I can see the only surprise here is that you appear not to 
have worked anyone in CQ Zone 3 and WSJT-X is telling you just that.


73
Bill
G4WJS.



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

Re: [wsjt-devel] RC5 error in JT65

[Joe Taylor]

Hi Charlie, Jari, and all,

Thanks for your reports -- they are much appreciated.  I'm sure you 
understand that our recent work has mostly been related to HF interests 
-- in particular, the new 77-bit protocols for FT8 and MSK144, and new 
special messages for contesting.


We are certainly not forgetting about VHF+, JT65, QRA64, etc.  Some 
remaining issues, and perhaps some recently introduced ones, will be 
addressed as soon as we can.  This could be in time for the WSJT-X 2.0 
release in two weeks; if that's not possible, we will work with you to 
address them soon after that.


-- 73, Joe, K1JT


___
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

[Joe Taylor]

On 11/27/2018 12:52 PM, Paul Kube K6PO 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


When the popup context menu appears you must select the desired action. 
Move the mouse pointer into the popup box and click there.



___
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

Re: [wsjt-devel] RC5 error in JT65

[charlie]

Thanks, Jari

Sounds like this is a different issue to what I was reporting.

73

Charlie

> Hi Charlie, others
>
> No, I work several qsos with RC5 on FT8, then got silent with FT8, so I
> change to JT65 as I saw traffic on it.
>
> I also note, that after I change from JT65 to JT9, RC5 keeps tx on FT8,
> even JT9 is indicated below date/ time window.
>
> Rgds,
>
> :Jari / oh2fqv
>
> On Tue, Nov 27, 2018 at 6:41 PM 
> wrote:
>
>> Hi Jari
>>
>> Did you start rc5 after getting a mode jump to JT9 with 1.9.1?
>>
>> That is the only way I have found so far to see the effects of a mode
>> jump
>> with rc5.
>>
>> I posted some findings on this a few messages ago.
>>
>> 73
>>
>> Charlie G3WDG
>>
>> > Windows 7 64 bit
>> >
>> > JT65 errors:
>> >
>> > Double click to rx call sign not working to reply
>> > Waterfall pointers looks like JT9
>> > Transmit audio FT8 ( sending my own call with locator )
>> >
>> > Decodes JT65 fine.
>> >
>> > error repeatable, restart did not change the error.
>> >
>> > Rgds,
>> >
>> > :Jari / oh2fqv
>> > ___
>> > wsjt-devel mailing list
>> > wsjt-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> >
>>
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> 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] RC5 error in JT65

[Jari A]

Hi Charlie, others

No, I work several qsos with RC5 on FT8, then got silent with FT8, so I
change to JT65 as I saw traffic on it.

I also note, that after I change from JT65 to JT9, RC5 keeps tx on FT8,
even JT9 is indicated below date/ time window.

Rgds,

:Jari / oh2fqv

On Tue, Nov 27, 2018 at 6:41 PM 
wrote:

> Hi Jari
>
> Did you start rc5 after getting a mode jump to JT9 with 1.9.1?
>
> That is the only way I have found so far to see the effects of a mode jump
> with rc5.
>
> I posted some findings on this a few messages ago.
>
> 73
>
> Charlie G3WDG
>
> > Windows 7 64 bit
> >
> > JT65 errors:
> >
> > Double click to rx call sign not working to reply
> > Waterfall pointers looks like JT9
> > Transmit audio FT8 ( sending my own call with locator )
> >
> > Decodes JT65 fine.
> >
> > error repeatable, restart did not change the error.
> >
> > Rgds,
> >
> > :Jari / oh2fqv
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC5 error in JT65

[charlie]

Hi Jari

Did you start rc5 after getting a mode jump to JT9 with 1.9.1?

That is the only way I have found so far to see the effects of a mode jump
with rc5.

I posted some findings on this a few messages ago.

73

Charlie G3WDG

> Windows 7 64 bit
>
> JT65 errors:
>
> Double click to rx call sign not working to reply
> Waterfall pointers looks like JT9
> Transmit audio FT8 ( sending my own call with locator )
>
> Decodes JT65 fine.
>
> error repeatable, restart did not change the error.
>
> Rgds,
>
> :Jari / oh2fqv
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>




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

[wsjt-devel] rc5: Tucson/Arizona is CQ Zone 3 (?)

[Wolfgang]

Interresting finding:

151030 -11 0.3 2302 ~ CQ W7AH DM42  CQ Zone 3

but

154215 -18 0.2 2445 ~ CQ K0VM EN42  U.S.A.

EN42 in in CQ Zone 4, but rc5 reports it as 'U.S.A.'
 
73 de Wolfgang 
OE1MWW 

P.S: Did Texas leave the United States of America with an 'Texit'? ;-)
-- 



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

[wsjt-devel] RC5 error in JT65

[Jari A]

Windows 7 64 bit

JT65 errors:

Double click to rx call sign not working to reply
Waterfall pointers looks like JT9
Transmit audio FT8 ( sending my own call with locator )

Decodes JT65 fine.

error repeatable, restart did not change the error.

Rgds,

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

Re: [wsjt-devel] ISCAT Problem?

[Rory Bowers]

Is there a chance you will change that to a double click Joe?  I think
ISCAT could be a LOT of fun.  I was amazed at the sensitivity!!
Rory, K5CKS

On Tue, Nov 27, 2018 at 9:17 AM Joe Taylor  wrote:

> On 11/27/2018 9:54 AM, Rory Bowers wrote:
> > I installed rc5 this morning and ran ISCAT B on 6M.  I got two calls
> > from my CQ.  When I tried to double click on one of them the program
> > said "Double Click Not Available for ISCAT Mode".  How do you answer a
> > call in ISCAT Mode??
> > Thanks,
> > Rory, K5CKS
>
> Enter DxCall (and DxGrid, if desired).  Click Generate Std Msgs.  Select
> the desired message, e.g., Tx2, Tx2, etc.  Enable Tx.  Advance to
> subsequent messages as your QSO progresses.
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fwd: Candidate release WSJT-X 2.0.0-rc5

[Stephen Ireland]

Allan,

It is absolutely critical that all spread the vibes… but preaching here where 
the converted play is just the start.

Perhaps beaconing of a V1 message may be required from 10th December until say 
the 20th Jan? i.e. A dead-simple, possibly language-alternating clear message 
such as “UPDATE TO V2” at say 1000hz offset?

Perhaps a special version that also modulates “guard tones” 5hz offset at one 
“pulse” in width either side of the Tx’d message to make the signal dead 
obvious on waterfalls? That should be easy for the developers to whip up… based 
off 1.9.1 code.

Alternating coordinated stations on each timeslot … Say on 20m and 40m – the 
main bands of activity?

There is enough dedicated Amateurs and Clubs in our community to pull this off 
in a short timespan….

As long as the ops callsign via Morse ID is attached to a free message the 
beaconing should pass regulation in most nations.

73

Steve I
VK3VM / VK3SIR

From: vk4qg 
Sent: Tuesday, 27 November 2018 10:15 AM
To: WSJT software development 
Subject: [wsjt-devel] Fwd: Candidate release WSJT-X 2.0.0-rc5

FYI.worth a read, particularly the last paragraph.

Allan

 Original message 
From: Joe Taylor mailto:j...@princeton.edu>>
Date: 27/11/18 7:54 am (GMT+10:00)
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc5

A fifth candidate release ("RC5") of WSJT-X 2.0 is now available for
download and use by beta testers.  RC5 is stable, works well, and fixes
the known problems in RC4.  It is likely that the General Availability
(GA) release of WSJT-X 2.0, scheduled for two weeks from today, will be
nearly identical to RC5.

Changes in RC5 relative to RC4 include the following:

  -  Make the "Auto Seq" checkbox sticky, again
  -  Remove the 5-minute mouse timer
  -  Correct the "worked before" logic for color highlighting
  -  Add "No own call decodes" checkbox in WSPR mode
  -  Display and log UTC (not local time) in contest operations
  -  Validate contest QSO details before allowing logging
  -  Force Aqua theme on macOS to avoid issues with Mojave dark theme
  -  Move Fox log Reset action to Fox log window context menu
  -  Improve layout of Working Frequencies and Station Information tables
  -  Allow deletes and editing in Fox and Contest log windows
  -  Add Tool Tips for Fox and Contest log windows
  -  Fix a bug causing false AP decodes in JT65 VHF+ operation
  -  Fix a bug that could switch unexpectedly from JT65 to JT9 mode

You may need to invoke "Settings | General | Colors | Reset
Highlighting" on your first program start with this version.

The "Quick-Start Guide to WSJT-X 2.0" has been updated. Be sure to read
this entire guide before using RC5:
http://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf

We recommend using RC5 (and therefore the v2.0 FT8 protocol) in the
conventional FT8 sub-bands at audio Tx frequencies 2000 Hz and higher.
Inevitably the necessary transition from v1.x to v2.0 protocols for FT8
and MSK144 will cause some confusion and cross-protocol interference.
Users of v1.9.1 and earlier are unable to decode transmissions from
users of RC4 and later, and vice-versa.

As more users upgrade their software to WSJT-X 2.0 -- and particularly
after the General Availability (GA) release on December 10 -- the new
protocol should start to dominate the conventional FT8 sub-bands.  As
soon as possible after December 10, everyone should upgrade to WSJT-X 2.0.

Download links for RC5 on Windows, Linux, and macOS can be found on the
WSJT-X web page http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

A final FT8 "practice contest" will be held on Saturday, December 1,
0200-0300 UTC (that's Friday evening, Nov 30, NA time).  Watch for a
separate announcement with more details.

If you find any unexpected behavior with WSJT-X 2.0-rc5, please send a
detailed report to the wsjt-devel email list,
wsjt-devel@lists.sourceforge.net. You 
must subscribe to the list in
order to post there.

The first serious FT8 contest is scheduled for the weekend of December
1-2.  See https://www.rttycontesting.com/ft8-roundup/ for full details
and contest rules.  The ARRL RTTY Roundup (January 5-6, 2019) permits
and encourages FT8 as well as traditional RTTY operation.


ONCE MORE: As soon as possible after December 10, and certainly by
January 1, 2019, everyone should be using WSJT-X 2.0 or a compatible
v2.0 version of derivative programs such as JTDX or MSHV.  As of today,
PSKreporter statistics show roughly 3000 users of WSJT-X versions older
than v1.9.1, 9500 users of v1.9.1, and 3000 users of v2.0-rc#.  Please,
everyone, help us to spread the word that upgrading to v2.0 after
December 10 is very important.  There will be no looking back!

 -- 73, Joe, K1JT (for the WSJT Development Group)


___
wsjt-devel mailing list

Re: [wsjt-devel] ISCAT Problem?

[Joe Taylor]

On 11/27/2018 9:54 AM, Rory Bowers wrote:
I installed rc5 this morning and ran ISCAT B on 6M.  I got two calls 
from my CQ.  When I tried to double click on one of them the program 
said "Double Click Not Available for ISCAT Mode".  How do you answer a 
call in ISCAT Mode??

Thanks,
Rory, K5CKS


Enter DxCall (and DxGrid, if desired).  Click Generate Std Msgs.  Select 
the desired message, e.g., Tx2, Tx2, etc.  Enable Tx.  Advance to 
subsequent messages as your QSO progresses.



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

[wsjt-devel] ISCAT

[Rory Bowers]

I forgot to mention ISCAT B decoded almost perfectly at -20.  I Only saw
one character error.
Rory, K5CKS
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2RSC3 > 2RSC4 decoding disappeared FT8

[Neil Zampella]

I'd uninstall RC3 as it is not supposed to be used after Nov 30th.

I'd put 1.9.1 back on for the time being until 2.0 goes general release 
for DXPeditions if nothing else.


Neil, KN3ILZ

On 11/27/2018 12:08 AM, Ken Myers wrote:
Sure I had read it.  Not the problem.  Needed another station that was 
using RC5 to QSO with - VK3VM was very helpful. Also JA9PHV. All 
good.  Just got to get more switched over to RC5.
Using pSKreporter helped as reporting passive stations decoded me, so 
they were using RC4/5.  I think there is a greater Ham density in USA.


All good now.  I use both RC3 and RC5 installed in different folders.  
Go back to RC3 when lonely, RC5 when courageous!!


Cheers

Ken

On Tue, 27 Nov 2018 at 14:55, Neil Zampella > wrote:


Ken,

did you read the Quick Start guide.  Release Candidates 4 & 5
(released today) are only 77bit, they will NOT decode 75 bit FT8,
which is probably why you're not seeing decodes on a normal FT8
frequency.   The Quick Start advises that you use the standard FT8
frequency, but use the audio range above 2000 for 77 bit work
until the General Release in December.

Neil, KN3ILZ

On 11/26/2018 6:15 PM, Ken Myers wrote:

Hi
I have been successfully been using RSC3 then changing to RSC4
there was no decode of waterfall content. FT8 mode.

2 installations -
1  MSSurface Win10 up to date, 2 radios (FT991a & FTdx3000 both
USB) - non decode,
2  HP Allinone with FT897/Singnalink. - non decode,
(both setups using HRD (up to date) for CAT control)

For all:
1.9.1 works great
2.0 RC3 works great
2.0 RC4  good waterfall (therefore good audio present) - NO decode.

uninstalling/reinstalling forward and back through versions gives
the same result.

i have concluded:
1  I must be holding my mouth wrong - OR
2  I have missed a new setting.
3  When I have been looking/testing RC4, no RC4 (77 bit)
transmissions. Not sure here as I have been especially been
looking top band.

2 probably!!

In the words of the rich young ruler to Jesus - "What must I do
to be saved?"

The other problem is occasionally the FT897 does not let go of
transmit after sending.
Solved by closing WSJTX.  Have tried 2 soundcards, Signalink and
Rigblaster P, - persistent intermittent.  MIGHT be my aging
FT897 - haven't ruled that out.

Great Program Great work.

Thanks
-- 
Cheers


Ken Myers
VK4GC

Sunnybank Hills QLD AUS
M   +61 414 487 004





Virus-free. www.avg.com




<#m_5895215522691016707_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Cheers

Ken Myers

Sunnybank Hills QLD AUS
M   +61 414 487 004




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

[wsjt-devel] ISCAT Problem?

[Rory Bowers]

I installed rc5 this morning and ran ISCAT B on 6M.  I got two calls from
my CQ.  When I tried to double click on one of them the program said
"Double Click Not Available for ISCAT Mode".  How do you answer a call in
ISCAT Mode??
Thanks,
Rory, K5CKS
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc5

[charlie]

Hi Joe

More on this.

On closing and restarting rc5 after 1.9.1 has mode jumped, as noted below
rc5 waterfall has the appearance of mode having jumped.

If I then close and start 1.9.1, the waterfall is normal.

On then closing 1.9.1 and restarting rc5 the waterfall is normal.

Charlie

> Hi Joe
>
> I've looked now at the mode jump issue with JT65.
>
> Running rc5 with the set of 100 simulation files using the same settings
> that reliably triggered the mode jump with 1.9.1 there is no sign of the
> mode jump.
>
> However when I used 1.9.1, to check I could still reproduce the behaviour
> (successfully), on closing program and restarting with rc5 the waterfall
> still has the appearance of the mode jump.
>
> So far, my rc5 is now stuck like this.
>
> Any thoughts?
>
> Charlie
>
>
>
>
>
> ___
> 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] Candidate release WSJT-X 2.0.0-rc5

[charlie]

Hi Joe

I've looked now at the mode jump issue with JT65.

Running rc5 with the set of 100 simulation files using the same settings
that reliably triggered the mode jump with 1.9.1 there is no sign of the
mode jump.

However when I used 1.9.1, to check I could still reproduce the behaviour
(successfully), on closing program and restarting with rc5 the waterfall
still has the appearance of the mode jump.

So far, my rc5 is now stuck like this.

Any thoughts?

Charlie





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

Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc5

[Bill Somerville]

On 27/11/2018 08:07, jarmo wrote:

a small update for the project web page. Fedora Linux has moved on to
version 29 and the RPM packages are built for that version.

73
Bill
G4WJS.

Seems to work on Fedora 28 also

Jarmo


Hi Jarmo,

thanks for the report, always worth a try but no guarantees given for 
versions  or distributions other than the one it was built on.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc5

[charlie]

Hi Joe

I have had a first look at rc5 from JT65 EME perspective.

I have not yet looked at the mode jumping fix.

Summary of results here:

https://drive.google.com/drive/folders/11Ph7EMvBTMWv5Ta5tJTufe50FzKu80TM?usp=sharing

Also see that auto-seq checkbox  is not visible for QRA64, JT65 and JT4.
Is this intentional - if so then a strong plea to return this
functionality!

Charlie







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

Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc5

[jarmo]

Mon, 26 Nov 2018 22:28:31 +
Bill Somerville  kirjoitti:


> Hi Joe,
> 
> a small update for the project web page. Fedora Linux has moved on to 
> version 29 and the RPM packages are built for that version.
> 
> 73
> Bill
> G4WJS.

Seems to work on Fedora 28 also

Jarmo


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