Re: [wsjt-devel] DXPedition changes?

[Black Michael via wsjt-devel]

Actually a couple of off-the-top ideas if the new/improved Fox mode doesn't 
make it into V2.0 (sounds like it won't) just to prompt some more fully fleshed 
ideas...
#1 Limit the power on CQ calls to the power for the # of slots selected.  So if 
the Fox wants 5 slots it always uses 5-slot power levels.  Then the DXpedition 
can start out at high # of slots and reduce as things quiet downor perhaps 
some automated reduction in # of slots based on usage of the # of slots.
#2 Limit the power when replying to calls to the last # of slots used.  So if 
the Fox used 3 slots on the last transmission and is replying to anybody it 
just received than it uses no less than 3 slot power until it's "done".

de Mike W9MDB

 

On Tuesday, November 20, 2018, 11:12:25 PM CST, jarmo  
wrote:  
 
 Tue, 20 Nov 2018 12:37:02 -0500
Joe Taylor  kirjoitti:


> On 11/20/2018 11:51 AM, Black Michael via wsjt-devel wrote:
> > It was mentioned a while ago that changes would be made to the Fox
> > mode to avoid the power loss for multiple QSOs going on.

> Some months ago we said "The existing FT8 DXpedition mode will still
> be supported, and a more powerful DXpedition mode may be offered as
> well." We have not yet done serious work on the potentially "more
> powerful mode". -- Joe, K1JT

As during VP6D, was seen, that they used 9 slots! When they CQ'ed, using
only one signal, signal was example -7, great, send my call, next lost
them totally, because they answered to 9 stations. I saw only slot
frames, but no decoding information. Someone, who had better antennas,
told me, that they are answering to me, no see...
I could copy, when they answered with 4 slots and fortunately got
qso.
So, maybe limiting slots to some lower or to documentation some
words for dx, when propagation is bad, don't use more than 3-4 slots
max.

Jarmo 


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

Re: [wsjt-devel] DXPedition changes?

[jarmo]

Tue, 20 Nov 2018 12:37:02 -0500
Joe Taylor  kirjoitti:


> On 11/20/2018 11:51 AM, Black Michael via wsjt-devel wrote:
> > It was mentioned a while ago that changes would be made to the Fox
> > mode to avoid the power loss for multiple QSOs going on.

> Some months ago we said "The existing FT8 DXpedition mode will still
> be supported, and a more powerful DXpedition mode may be offered as
> well." We have not yet done serious work on the potentially "more
> powerful mode". -- Joe, K1JT

As during VP6D, was seen, that they used 9 slots! When they CQ'ed, using
only one signal, signal was example -7, great, send my call, next lost
them totally, because they answered to 9 stations. I saw only slot
frames, but no decoding information. Someone, who had better antennas,
told me, that they are answering to me, no see...
I could copy, when they answered with 4 slots and fortunately got
qso.
So, maybe limiting slots to some lower or to documentation some
words for dx, when propagation is bad, don't use more than 3-4 slots
max.

Jarmo 


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

[wsjt-devel] RC4 Crash on Logging - observation

[Neal Pollack]

I noticed that I could 100% reproduce a crash (app windows vanish, no error
message) if

I click on OK in the Log Prompting dialog pop-up box, WHILE the final 73
was still transmitting.

If I wait until transmit completes, and THEN click OK to the log dialog
box, the app is OK and

does NOT crash.  I tried 30 additional contact this way with no crash.

So the crash has something to do with clicking OK to log DURING transmit,
on windows ver 1803.

Not tested with windows 10 ver 1809.


This is with windows 10 x64 version 1803.   (Not tested with windows 10 ver
1809.)

This is with core i7 CPU, 16GB memory, and using JTalert (latest version)
and using Ham Radio

Deluxe logger, latest version.


To confirm, I did a second installation of WSJT-X ver 2 RC4 in a different
directory.

It will also crash 100% of the time if you click on OK in the log dialog
pop-up box

WHILE it is still transmitting the final 73.


Neal

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

Re: [wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

[David Fisher]

When we demonstrate a real FT8 contesting mode, and plenty of operators 
interested in it, then we can talk to N1MM about providing the needed 
interface.  This is the road we followed in the Flex Radio world, and it worked 
out very nicely.  N1MM now feeds the spot information it gathers to the radio, 
using the radio’s Spot interface, so that the color coded bandmap appears in 
the Flex panadapter display.  As you work the stations, the colors change, 
according to the contest rules in effect, so you can tell at a glance if you 
should stop, or move on.



Perhaps WSJT-X could feed the decoded callsigns to N1MM as if they were spots.  
To be useful, N1MM would need to know where you intend to listen, where your 
green goalpost is located.  This would be equivalent to N1MM reading the 
radio’s tuned frequency and showing you the color coded spot information for 
that frequency.  If we assume that in S mode the “spots” are coming into N1MM 
faster than you can work them, then most of the time you’ll have a good idea if 
you should work a station by simply clicking on it.  The green goalpost moves, 
N1MM “tunes” and shows you the state of that station (green, red, white).  
Then, assuming you are working split (you are, aren’t you?) if it turns out 
that the transmission has started by the time you discover and react to the 
fact that you shouldn’t work the station, you can always just hit “Stop” and 
move on.



Dave / NX6D






From: Bill Somerville 
Sent: Tuesday, November 20, 2018 11:16:11 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

On 20/11/2018 19:01, Jeff Stai wrote:
> If I decide to run WSJT-X in the Roundup, I'm not expecting my
> preferred logger to have any support for it, so I believe I will be
> treating WSJT-X as if it were a stand alone RTTY modem and I'll be
> typing stuff into the contest logger - letting the logger keep track
> of dupes and mults and score as it always does.
>
> This is not how we have come to expect to operate RTTY in contests
> (clicking things or key strokes to get things into the entry window)
> but really it's no worse than operating phone. ;)
>
> It's always seemed to me that the easiest path would be for WSJT-X to
> interact like any modem program (eg MMTTY) with the contest logger,
> let the logger do what it does best, and not reinvent wheels -
> especially when multiple modes and/or logging programs are in the mix.
> But I gather this is not the path being taken.
>
> 73 jeff wk6i

Hi Jeff,

I believe you are missing an important factor with WSJT-X, that it is a
multi-signal decoder. With that it becomes important to be able to
quickly determine which of the up to 40+ decodes each 15-second period
are not dupes and more importantly might be new multipliers. In state of
the art contest loggers these capabilities are provided either when you
type in a call to work, or in assisted categories via some sort of band
map populated from worked QSOs, typed in callsigns, and if in an
assisted category from cluster spots. WSJT-X can already pass all
decodes to another application (JTAlert is a good example) for such
processing but as it stands I don't believe any contest loggers have the
required interfaces. Until contest loggers decide to implement a feed of
decodes heard by WSJT-X and allow the logger operator to pick the next
QSO partner from those decodes, we are stuck with WSJT-X having to
provide some equivalent mechanism if we want the contesting community to
see FT8 as a viable mode for digital contests.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc17ce2c1e6164660ee6808d64f1d064c%7C84df9e7fe9f640afb435%7C1%7C0%7C636783383407250716sdata=0Gv2HzItjnOj83DQwE8kp7E0SI0ghSwvRndG3wYbjqw%3Dreserved=0
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.0 RC4 in congestion !

[Scott Brown]

Settings > Radio > Split Operation > Check Fake It. This seems to do the trick.

Just a bandaid tho. Centering up the dial seems more feasible. 

-Scott
KD4YDD

From: M Lewton 
Sent: Tuesday, November 20, 2018 4:50 PM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !

I agree.  A few of operators operating above 2000 have a good signal on the
waterfall, I copy them well but they can't seem to hear me ??
I am running 100 watts using a IC-7300 with BW set to 3600.
It seem that they are running a KW to my 100 watts.
You are right, with some receivers it would be better to set the Freq. to
14.075 instead of 14.074 etc. using rc8 until the next release.

I am happy with the sensitivity of the decoder though.

Maurice
WA6PHR

-Original Message-
From: Mark James
Sent: Tuesday, November 20, 2018 5:59 AM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !


If you are working above 2000, and might have performance issues on
receiving signals there, another option is to use a higher dial frequency --
eg 7.075 or 7.076. This doesn't affect the actual frequencies used, just may
make it easier to manage.




On Tue, Nov 20, 2018 at 7:52 AM John Nelson  wrote:
Steve,

>  one must “adjust” the AF “Power” drive control as one shifts Tx
> frequency.

Are you not using CAT control with “Split” selected?   If so, VFOB is set
such that the audio tone generated is always between 1500 and 2000 Hz which
should always be within the SSB passband.   The TX offset is managed by
VFOB.

— John G4KLA___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C44e62dccb4654c0a941f08d64ef0fbbb%7C84df9e7fe9f640afb435%7C1%7C0%7C636783194249833574sdata=QLaeCUIjDS9knkwwVaO4%2BEkhYN6Kx9SiaL3OynpeWzI%3Dreserved=0


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

[wsjt-devel] Follow up on Log QSO error

[WB5JJJ]

In checking the wsjtx_log.adi file, I found the state was saved wrongly.

WB3LGC FM29 FT8 +08
+15 20181120 221515
20181120 221615 20m 14.076130
WB5JJJ EM35kg 80
LJ81HM 

-- 
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] Log QSO anomoly

[WB5JJJ]

I just logged a contact in Delaware.  If you notice the lower right Rcvd
box has unknown information.  The 2nd part LJ81HM showed up as the state
when sent to HRD LB.  This looks like a grid square, but if so, it's in the
middle of the ocean off Mogadishu, Somalia.  Pirates location for sure.
Did not see anything unusual on his QRZ page except that his QRZ grid
square is a storage rental facility in an industrial area of the city.

Never seen this before.

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

Re: [wsjt-devel] v2.0 RC4 in congestion !

[M Lewton]

I agree.  A few of operators operating above 2000 have a good signal on the 
waterfall, I copy them well but they can't seem to hear me ??
I am running 100 watts using a IC-7300 with BW set to 3600.
It seem that they are running a KW to my 100 watts.
You are right, with some receivers it would be better to set the Freq. to 
14.075 instead of 14.074 etc. using rc8 until the next release.

I am happy with the sensitivity of the decoder though.

Maurice
WA6PHR

-Original Message- 
From: Mark James
Sent: Tuesday, November 20, 2018 5:59 AM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !


If you are working above 2000, and might have performance issues on 
receiving signals there, another option is to use a higher dial frequency --  
eg 7.075 or 7.076. This doesn't affect the actual frequencies used, just may 
make it easier to manage.




On Tue, Nov 20, 2018 at 7:52 AM John Nelson  wrote:
Steve,

>  one must “adjust” the AF “Power” drive control as one shifts Tx 
> frequency.

Are you not using CAT control with “Split” selected?   If so, VFOB is set 
such that the audio tone generated is always between 1500 and 2000 Hz which 
should always be within the SSB passband.   The TX offset is managed by 
VFOB.

— John G4KLA___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C44e62dccb4654c0a941f08d64ef0fbbb%7C84df9e7fe9f640afb435%7C1%7C0%7C636783194249833574sdata=QLaeCUIjDS9knkwwVaO4%2BEkhYN6Kx9SiaL3OynpeWzI%3Dreserved=0
 


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

[wsjt-devel] View Contest Log Shows No Data Under Received Column?

[Hasan al-Basri]

As I look at my log from last night's Mock :
View > Contest Log

There are no entries displayed under the Received Column. Should there be?

Looking at the Cabrillo export Log:

QSO:  7078 DG 2018-11-19 2006 N0AN 569 IAK9AN 569
IL

... shows that a Rx exchange exists.

What am I missing?

73, N0AN

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

[wsjt-devel] adif log relaod

[Iztok Saje]

Hi!

It would be nice to have function to clean all call tables and reload ADIF log 
file.
Currently it is done by restart of WSJTX.

It is handy when running two copies of WSJTX .
(yes, I already called CQ with 2.0-rc4, get answered by rc3 users in 75 bit, 
and answered in 1.91 to make a QSO).

In RU test, we can run RTTY and WSJTX and exchange "worked" lists.

With a simple script to merge two ADIF logs and restart WSJTX this works.
Reloading logs is just a bit more elegant.

And thanks for not keeping log files open all the time, so they can be edited 
while WSJTX is running.

CU RU, 73
Iztok, s52d


Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana 


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

Re: [wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

[Bill Somerville]

On 20/11/2018 21:14, Jeff Stai wrote:

So contest loggers already implement a feed of decodes.


Hi Jeff,

do you know if this is documented anywhere?

73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

[Jeff Stai]

hi Bill - I do understand that WSJT-X is a multi-decoder. On a busy band in
RTTY I might have say 4 callsigns to choose from in my receive display
after I call CQ, and the contest logger will highlight based on already
worked, new mult, etc. - and I click or use a hotkey to grab the one I want
to work. So contest loggers already implement a feed of decodes.

(And now we get 40 calls to choose from instead of 4 and we better choose
fast or lose our TX slot - time to develop new skills. There's the fun
part!)

There's an existing UI metaphor for digital contests that works. I'm
suggesting that staying within that metaphor may provide the best
contesting environment and take less effort than developing a whole contest
logger within WSJT-X.

thanks and 73 jeff wk6i


On Tue, Nov 20, 2018 at 11:19 AM Bill Somerville 
wrote:

> On 20/11/2018 19:01, Jeff Stai wrote:
> > If I decide to run WSJT-X in the Roundup, I'm not expecting my
> > preferred logger to have any support for it, so I believe I will be
> > treating WSJT-X as if it were a stand alone RTTY modem and I'll be
> > typing stuff into the contest logger - letting the logger keep track
> > of dupes and mults and score as it always does.
> >
> > This is not how we have come to expect to operate RTTY in contests
> > (clicking things or key strokes to get things into the entry window)
> > but really it's no worse than operating phone. ;)
> >
> > It's always seemed to me that the easiest path would be for WSJT-X to
> > interact like any modem program (eg MMTTY) with the contest logger,
> > let the logger do what it does best, and not reinvent wheels -
> > especially when multiple modes and/or logging programs are in the mix.
> > But I gather this is not the path being taken.
> >
> > 73 jeff wk6i
>
> Hi Jeff,
>
> I believe you are missing an important factor with WSJT-X, that it is a
> multi-signal decoder. With that it becomes important to be able to
> quickly determine which of the up to 40+ decodes each 15-second period
> are not dupes and more importantly might be new multipliers. In state of
> the art contest loggers these capabilities are provided either when you
> type in a call to work, or in assisted categories via some sort of band
> map populated from worked QSOs, typed in callsigns, and if in an
> assisted category from cluster spots. WSJT-X can already pass all
> decodes to another application (JTAlert is a good example) for such
> processing but as it stands I don't believe any contest loggers have the
> required interfaces. Until contest loggers decide to implement a feed of
> decodes heard by WSJT-X and allow the logger operator to pick the next
> QSO partner from those decodes, we are stuck with WSJT-X having to
> provide some equivalent mechanism if we want the contesting community to
> see FT8 as a viable mode for digital contests.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Jeff Stai ~ WK6I ~ wk6i.j...@gmail.com
Ask me about Green Keys Night - Jan 1, 2019 -2359 UTC!
RTTY op at W7RN
Twisted Oak Winery ~ http://www.twistedoak.com/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

[Brian Moran]

Hi Bill;
it's hard to hit a performance target without knowing what the numbers
need to be. Checking each call one at a time externally would surely
be the slowest.

But it also seems like the timing requirements on external dupe
checking could be relaxed entirely by doing something like this, which
would even fit into your existing framework in place for communicating
with external programs:

(For contesting dupe-check purposes, you just need a WORKED/NOT-WORKED):
In the speedy internal table used to maintain the wsjt-x worked-before
status, add a field that can store a signal field with values
EXTERNAL_NO_INFO / EXTERNAL_NOT_WORKED / EXTERNAL_WORKED

You only have to externally check call signs that haven't been worked
in WSJT-X, and are EXTERNAL_NO_INFO or EXTERNAL_NOT_WORKED.
End of Decode Interval 0:
   Send all of the non-wsjtx-worked calls with EXTERNAL_NO_INFO or
EXTERNAL_NOT_WORKED  to the external program. Don't wait around. You
can probably use the existing decode message broadcasts for these.
   Paint the status of each decoded call on the screen informed by the
local super-speedy DB for whether they've been worked, but also taking
into account the EXTERNAL_* flags. Use a different color for NO_INFO
and NOT_WORKED statuses.
Start Decode Interval 1:
The external app sends the information to update the EXTERNAL_*
flags (only with WORKED or NOT_WORKED) in the speedy table using the
existing UDP infrastructure you have in place (with a new message type
defined, of course). The colors of a particular callsign may be off by
up to a decode interval.  I don't recall if you can re-color calls
on-screen after they've been decoded, but you could.

You could argue that EXTERNAL_NO_INFO and EXTERNAL_NOT_WORKED are the
same, but if they're colored differently, a wise operator will wait
for the EXTERNAL_NOT_WORKED color if they're concentrating on wsjt-x
operation, and not adding calls into the external one through another
means.

So the only new work here is the extra field consultation and
coloration, and the messages to update your speedy internal table.

-Brian N9ADG

On Tue, Nov 20, 2018 at 11:40 AM Bill Somerville  wrote:
>
> On 20/11/2018 19:25, Brian Moran wrote:
> > Hi Bill! You say time critical -- how many milliseconds are currently
> > available to look up the up-to-40-calls and render a 'worked_before'
> > status for each of them?
>
> Hi Brian,
>
> we have no deadline specified but I would expect the current
> implementation to add no more than a handful of microseconds (probably a
> lot less) to the print delay of each decode it might highlight. Note
> that this is almost certainly orders of magnitude faster than the time
> required assemble a network message, dispatch it, context switch to
> another application, receive the message, parse it, do a lookup, compose
> a reply, dispatch it, context switch again, receive the reply, parse it,
> act on 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

[wsjt-devel] 2.0.0 rc4

[Marco Calistri]

Il 20/11/18 17:41, Dale Wheeler via wsjt-devel ha scritto:
> Running on win10.
> 
> Showing wrong colors. See attached picture.
> 
> wrong colors.jpg
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
That's a know issue and would be removed before de GA version.

-- 

73 de Marco, PY1ZRJ


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

Re: [wsjt-devel] 2.0.0 rc4

[Marco Calistri]

Il 20/11/18 17:41, Dale Wheeler via wsjt-devel ha scritto:
> Running on win10.
> 
> Showing wrong colors. See attached picture.
> 
> wrong colors.jpg
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
That's a know issue and would be removed before de GA version.

-- 

73 de Marco, PY1ZRJ


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

Re: [wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

[Bill Somerville]

On 20/11/2018 19:25, Brian Moran wrote:

Hi Bill! You say time critical -- how many milliseconds are currently
available to look up the up-to-40-calls and render a 'worked_before'
status for each of them?


Hi Brian,

we have no deadline specified but I would expect the current 
implementation to add no more than a handful of microseconds (probably a 
lot less) to the print delay of each decode it might highlight. Note 
that this is almost certainly orders of magnitude faster than the time 
required assemble a network message, dispatch it, context switch to 
another application, receive the message, parse it, do a lookup, compose 
a reply, dispatch it, context switch again, receive the reply, parse it, 
act on it.


73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

[Brian Moran]

Hi Bill! You say time critical -- how many milliseconds are currently
available to look up the up-to-40-calls and render a 'worked_before'
status for each of them?


On Tue, Nov 20, 2018 at 11:09 AM Bill Somerville  wrote:
>
> On 20/11/2018 18:06, Brian Moran wrote:
> > In the ARRL RTTY Roundup, the rules say work stations once per band,
> > regardless of mode.  This means those stations using both RTTY and FT8
> > modes in the same contest will have to check callsigns in BOTH MODES
> > to know what to work efficiently.
> >
> > Will there be a means supported to do an 'outcall' to another program
> > to check duplicate status of any particular contact? For example, N1MM
> > Logger+ uses the SQLite DB, but access doesn't have to be through N1MM
> > Logger+; to check dupe status, a small app could be written to perform
> > the DB query. I'm pretty sure on modern computers the SQLite library
> > is fast enough to handle the lookup of a list of callsigns before
> > display, especially if they're queried in a single SQL lookup (e.g.
> > "WHERE CALLSIGN IN  ('N1ABC', 'K2ABC', 'K3ABC', 'W4ABC'])
> >
> > I would expect that if a serious contest station were employing both
> > modes, they'd keep the 'ground truth' database of stations worked in a
> > contest logger.
> >
> > Brian N9ADG
>
> Hi Brian,
>
> your points are valid but I would be concerned about performance. We
> would effectively be relinquishing the completion of printing of decodes
> to an external application. This is a time-critical operation in WSJT-X
> and the implied round-trip exchange is a potential problem. Currently
> highlighting is done using a high performance in-memory table and
> indexes. Adding dupe and needed multiplier checking is on the list but
> not yet implemented.
>
> I suspect a practical approach may be achieved by having some sort of
> hand-over process where QSOs so far would be passed over to WSJT-X so
> that it could update its table in the background. That approach with a
> push mechanism from the single source of truth application (N1MM Logger+
> for example) would avoid any delays at decode time with two applications
> having to have a conversation during a time-critical phase of
> processing. I do realize that there will certainly be contest operators
> running SO2R or even multi-multi that will want a more real-time scheme.
> That is a much tougher proposition to which I would think about some
> sort of bridging application that becomes the single source of real-time
> truth (SST) of QSOs completed so far. That SST could be the logging
> application a you describe.
>
> Whatever we do will need a lot of thought, and I for one will resist
> adding too much contest (or log specific) functionality into WSJT-X as
> that adds a maintenance burden which is a distraction from the core
> weak-signal QSO tool aims of WSJT-X.
>
> 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 Dupe Checking in ARRL RTTY Roundup

[Bill Somerville]

On 20/11/2018 19:01, Jeff Stai wrote:
If I decide to run WSJT-X in the Roundup, I'm not expecting my 
preferred logger to have any support for it, so I believe I will be 
treating WSJT-X as if it were a stand alone RTTY modem and I'll be 
typing stuff into the contest logger - letting the logger keep track 
of dupes and mults and score as it always does.


This is not how we have come to expect to operate RTTY in contests 
(clicking things or key strokes to get things into the entry window) 
but really it's no worse than operating phone. ;)


It's always seemed to me that the easiest path would be for WSJT-X to 
interact like any modem program (eg MMTTY) with the contest logger, 
let the logger do what it does best, and not reinvent wheels - 
especially when multiple modes and/or logging programs are in the mix. 
But I gather this is not the path being taken.


73 jeff wk6i


Hi Jeff,

I believe you are missing an important factor with WSJT-X, that it is a 
multi-signal decoder. With that it becomes important to be able to 
quickly determine which of the up to 40+ decodes each 15-second period 
are not dupes and more importantly might be new multipliers. In state of 
the art contest loggers these capabilities are provided either when you 
type in a call to work, or in assisted categories via some sort of band 
map populated from worked QSOs, typed in callsigns, and if in an 
assisted category from cluster spots. WSJT-X can already pass all 
decodes to another application (JTAlert is a good example) for such 
processing but as it stands I don't believe any contest loggers have the 
required interfaces. Until contest loggers decide to implement a feed of 
decodes heard by WSJT-X and allow the logger operator to pick the next 
QSO partner from those decodes, we are stuck with WSJT-X having to 
provide some equivalent mechanism if we want the contesting community to 
see FT8 as a viable mode for digital contests.


73
Bill
G4WJS.



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

Re: [wsjt-devel] RU Contest - crash when logging

[Alex Diaz - XE1MEX via wsjt-devel]

 Hi Bill,The requested file is attached. I think it is clear what happened.
This time I was calling CQ RU along the contest period with Auto Seq and Hold 
Tx Freq checked.
02:11:45 the QSO with KG6MC was completed (he got R 549 0005)02:11:30 WB4HXE 
and W5LRU called me.02:12:15 I sent R 559 0006 to W5LRU along 5 TX cycles 
(until 02:14:15) without getting his reply; meanwhile WB4HXE called me two 
times and at 02:14:00 he called to K9AN.02:14:15 I stopped TX and switched to 
call WB4HXE sending him R 559 0006 in two TX periods.02:15:15 I started to call 
CQ since I did not get RR73 from W5LRU nor WB4HXE and I was not prompted to log 
any QSO.02:18:00 S52D replied to my CQ and he got the R 549 0006. This QSO was 
easily completed at 02:18:45.
A similar situation happened at start and end of contest period. Perhaps I am 
in the log of N6RY but never received RR73 so my first logged contest contact 
was with WB3D. Maybe I am also in the log of K9OM at 02:58:45 with R 559 0020 
but he is not in my log because RR73 was not received (or not decoded due QRM 
of an adjacent strong signal).
Thanks for the attention.73AlexXE1MEX 

On Tuesday, November 20, 2018, 6:50:35 AM CST, Bill Somerville 
 wrote:  
 
  On 20/11/2018 05:05, Alex Diaz - XE1MEX via wsjt-devel wrote:
  
 Hi Bill, Carey, Sorry Carey but you are not in log and therefore you did not 
get the report. I revised the .wav files and I did not find your call sign at 
the time you recorded the QSO  (date and time are local PC not UTC as already 
reported by others) This is my log: 
  
 73 Alex XE1MEX 
  
 
Hi Alex,
 
thanks for commenting on this. So we can get the full picture of what happened 
can you reply with the section of your ALL.TXT file that covers the period from 
02:11:00 through 02:15:00 UTC please?
 
73
 Bill
 G4WJS.
 
 ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  021100 -14  0.1  457 ~  NU8M WB3D R 559 VA  
021100   5  0.2  550 ~  CQ RU K5WE EM25 
021100 -21  0.2  770 ~  CQ RU K1JT FN20 
021100 -10  0.1  950 ~  K9OM WA9AFM 559 OK  
021100  -5  0.2 1054 ~  AE5X K4IU 559 MN
021100 -16  0.1 1200 ~  K1HTV N8TFD R 579 OH
021100 -12  0.3 1290 ~  AD4TJ K4SQC RR73
181120_021115  Transmitting 7.078 MHz  FT8:  CQ RU XE1MEX EK08  
  
021100 -17 -0.0 1534 ~  K9OM WD0HXN 559 CO  
021100 -17  0.3 1734 ~  VE2EBK KT4XN R 549 FL   
021100  -5  0.1 1799 ~  K2GC AD5LU 549 TX   
021100  -9  0.1 1855 ~  CQ RU KF4RWA EM63   
021100   2  0.2 1929 ~  CQ RU K5CM EM25 
021100 -12  0.3 1982 ~  N2LO VP8LP R 549 0028   
021100 -14  0.3 2167 ~  CQ RU W4OCO FM26
021100 -10  0.1 2247 ~  XE1MEX KG6MC 549 SC 
021100 -17  0.1 2569 ~  K9AN K6SJT 569 CA   
181120_021115  Transmitting 7.078 MHz  FT8:  KG6MC XE1MEX R 549 0005
  
021100 -14  0.0 2604 ~  K6AVP AE4IN 539 AL  
021100 -18  0.2  495 ~  W4PPC N6YFM 73  
021100 -12  0.2 1083 ~  XE1MEX S52D 539 0002
021100 -16  0.2 1885 ~  VE7KW WB5NHL 539 SC 
021100 -19  0.3 2315 ~  KC1GWX DK7ZT R 539 0004 
021130 -11  0.1  457 ~  NU8M WB3D 73
021130   4  0.2  550 ~  CQ RU K5WE EM25 
021130  -1  0.1  876 ~  CQ RU AA5AU EL49
021130  -2  0.2 1054 ~  AE5X K4IU RR73  
021130 -18  0.2 1200 ~  K1HTV N8TFD 73  
021130 -17  0.3 1416 ~  VE2EBK K4DJG R 539 VA   
021130  -9  0.1 1593 ~  K4IZN K6LL R 539 AZ 
181120_021145  Transmitting 7.078 MHz  FT8:  KG6MC XE1MEX R 549 0005
  
021130  -5  0.2 1637 ~  XE1MEX W5LRU 549 TX 
021130 -15  0.3 1734 ~  VE2EBK KT4XN R 549 FL   
021130  -2  0.1 1799 ~  K2GC AD5LU 549 TX   
021130  -9  0.1 1855 ~  CQ RU KF4RWA EM63   
021130   1  0.2 1929 ~  CQ RU K5CM EM25 
021130 -13  0.3 1982 ~  N2LO VP8LP R 549 0028   
021130 -14  0.2 2058 ~  VE7VZ W9ILY R 529 IL
021130 -19  0.2 2164 ~  N5OSK W4OCO 559 VA  
021130  -8  0.1 2247 ~  XE1MEX KG6MC RR73   
181120_021145  Transmitting 7.078 MHz  FT8:  KG6MC XE1MEX 73
  
021130 -18  0.2 2425 ~  KT5V W9SUS R 549 IL 
021130  -5  0.1  847 ~  XE1MEX WB4HXE 569 GA
021130 -22  0.2  950 ~  K9OM AB1J RR73  
021130 -13  0.2 1885 ~  VE7KW WB5NHL 539 SC 
021200  -6  0.2 

Re: [wsjt-devel] Faster contest sequence

[Jim Brown]

On 11/20/2018 10:54 AM, Dave Hachadorian wrote:
It worked OK sometimes, but several callers kept coming back for more 
info, apparently looking for that final (TX5) “73” from me.


That's partly because some FT8 operators don't have contesting 
experience. The sequence you outline is perfectly right for any 
experienced contester.


73, Jim K9YC


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

Re: [wsjt-devel] v2.0 RC4 in congestion !

[Scott Brown]

Good luck on your surgery Steve!

-Scott
KD4YDD

On Nov 20, 2018, at 1:19 PM, Stephen Ireland 
mailto:vk3...@hotmail.com>> wrote:

Mark,

I had considered this and its a fair suggestion – but the start of our band is 
say 7.074. Are we not best working under real world congestion – especially on 
40m - and not closed-conditions? That is why I raised the Fleishman and Pons 
“Cold Fusion” fiasco – an example that runs shivers down the spine of anyone 
trying to research or develop – in the initial post...

John,

No split selected. Please do not take this the wrong way but I cannot see how 
split is relevant to this discussion .  Splits are a fantastic idea – but by 
far the vast majority of FT8 conduct Tx’s with the extensive split 
functionality disabled my observation; An op selects a frequency and stays 
there. An op responds either directly on the calling Op’s offset OR at their 
own selected frequency. Splits CAN be a nightmare for the unwary !

73, its 5am here ... and off for surgery so I be quiet for a few days ... maybe 
!

Steve I



Sent from Mail for Windows 10


From: Mark James mailto:markhjame...@gmail.com>>
Sent: Wednesday, November 21, 2018 12:59:00 AM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !

If you are working above 2000, and might have performance issues on receiving 
signals there, another option is to use a higher dial frequency -- eg 7.075 or 
7.076. This doesn't affect the actual frequencies used, just may make it easier 
to manage.



On Tue, Nov 20, 2018 at 7:52 AM John Nelson 
mailto:j...@rmnjmn.co.uk>> wrote:
Steve,

>  one must “adjust” the AF “Power” drive control as one shifts Tx frequency.

Are you not using CAT control with “Split” selected?   If so, VFOB is set such 
that the audio tone generated is always between 1500 and 2000 Hz which should 
always be within the SSB passband.   The TX offset is managed by VFOB.

— John G4KLA___
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 Dupe Checking in ARRL RTTY Roundup

[Bill Somerville]

On 20/11/2018 18:06, Brian Moran wrote:

In the ARRL RTTY Roundup, the rules say work stations once per band,
regardless of mode.  This means those stations using both RTTY and FT8
modes in the same contest will have to check callsigns in BOTH MODES
to know what to work efficiently.

Will there be a means supported to do an 'outcall' to another program
to check duplicate status of any particular contact? For example, N1MM
Logger+ uses the SQLite DB, but access doesn't have to be through N1MM
Logger+; to check dupe status, a small app could be written to perform
the DB query. I'm pretty sure on modern computers the SQLite library
is fast enough to handle the lookup of a list of callsigns before
display, especially if they're queried in a single SQL lookup (e.g.
"WHERE CALLSIGN IN  ('N1ABC', 'K2ABC', 'K3ABC', 'W4ABC'])

I would expect that if a serious contest station were employing both
modes, they'd keep the 'ground truth' database of stations worked in a
contest logger.

Brian N9ADG


Hi Brian,

your points are valid but I would be concerned about performance. We 
would effectively be relinquishing the completion of printing of decodes 
to an external application. This is a time-critical operation in WSJT-X 
and the implied round-trip exchange is a potential problem. Currently 
highlighting is done using a high performance in-memory table and 
indexes. Adding dupe and needed multiplier checking is on the list but 
not yet implemented.


I suspect a practical approach may be achieved by having some sort of 
hand-over process where QSOs so far would be passed over to WSJT-X so 
that it could update its table in the background. That approach with a 
push mechanism from the single source of truth application (N1MM Logger+ 
for example) would avoid any delays at decode time with two applications 
having to have a conversation during a time-critical phase of 
processing. I do realize that there will certainly be contest operators 
running SO2R or even multi-multi that will want a more real-time scheme. 
That is a much tougher proposition to which I would think about some 
sort of bridging application that becomes the single source of real-time 
truth (SST) of QSOs completed so far. That SST could be the logging 
application a you describe.


Whatever we do will need a lot of thought, and I for one will resist 
adding too much contest (or log specific) functionality into WSJT-X as 
that adds a maintenance burden which is a distraction from the core 
weak-signal QSO tool aims of WSJT-X.


73
Bill
G4WJS.



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

Re: [wsjt-devel] RTTY roundup dups

[John Zantek]

I, too, was running JTAlertX last night for the ‘test, but for a different 
reason than to check dupes.  JTAlertX and Log4OM are my regularly day-to-day 
system.  N1MM+ is only launched during contests.  Since JTAlertX is basing dupe 
declaration on my big log and not the contest, I’m very happy to hear that RC5 
will report dupes independently, based on a contest-by-contest effort.  

 

It just keeps getting better.  :)

 

From: John Kludt [mailto:johnnykl...@gmail.com] 
Sent: Tuesday, November 20, 2018 8:54 AM
To: WSJT-Dev 
Subject: Re: [wsjt-devel] RTTY roundup dups

 

David,

 

Actually I found JTAlters very useful for exactly that reason - dup checking.  
But see Joe's note - already handled in RC5 or the GA release.

 

John

 

On Tue, Nov 20, 2018 at 11:19 AM David Kjellquist mailto:d...@kjellquist.com> > wrote:

Has anyone come up with ideas for avoiding dups when using FT8 in a 
large contest? JTAlert checks B4 but its display matrix is limited and 
not really designed for contest use. N1MM log integration works well but 
I don't see that it checks for dups prior actual log entry (not much 
help). But, I'm not really N1MM literate so I may be missing something.

JTAlert does preload a call into AClog but I can't check N3FJP contest 
logs since N3FJP integration is AClog only.

-- 
Dave, WB5NHL
5BDXCC, 308 countries confirmed
206 wrkd FT8, 159 confirmed



___
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 Dupe Checking in ARRL RTTY Roundup

[Jeff Stai]

hi Brian - If I decide to run WSJT-X in the Roundup, I'm not expecting my
preferred logger to have any support for it, so I believe I will be
treating WSJT-X as if it were a stand alone RTTY modem and I'll be typing
stuff into the contest logger - letting the logger keep track of dupes and
mults and score as it always does.

This is not how we have come to expect to operate RTTY in contests
(clicking things or key strokes to get things into the entry window) but
really it's no worse than operating phone. ;)

It's always seemed to me that the easiest path would be for WSJT-X to
interact like any modem program (eg MMTTY) with the contest logger, let the
logger do what it does best, and not reinvent wheels - especially when
multiple modes and/or logging programs are in the mix. But I gather this is
not the path being taken.

73 jeff wk6i

On Tue, Nov 20, 2018 at 10:11 AM Brian Moran  wrote:

> In the ARRL RTTY Roundup, the rules say work stations once per band,
> regardless of mode.  This means those stations using both RTTY and FT8
> modes in the same contest will have to check callsigns in BOTH MODES
> to know what to work efficiently.
>
> Will there be a means supported to do an 'outcall' to another program
> to check duplicate status of any particular contact? For example, N1MM
> Logger+ uses the SQLite DB, but access doesn't have to be through N1MM
> Logger+; to check dupe status, a small app could be written to perform
> the DB query. I'm pretty sure on modern computers the SQLite library
> is fast enough to handle the lookup of a list of callsigns before
> display, especially if they're queried in a single SQL lookup (e.g.
> "WHERE CALLSIGN IN  ('N1ABC', 'K2ABC', 'K3ABC', 'W4ABC'])
>
> I would expect that if a serious contest station were employing both
> modes, they'd keep the 'ground truth' database of stations worked in a
> contest logger.
>
> Brian N9ADG
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Jeff Stai ~ WK6I ~ wk6i.j...@gmail.com
Ask me about Green Keys Night - Jan 1, 2019 -2359 UTC!
RTTY op at W7RN
Twisted Oak Winery ~ http://www.twistedoak.com/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] FT8 mock contest: ft8v2r4_ru_2018NOV20_N2LO~>

[robert evans LAST_NAME]

Amazing activity. Please see the attached.
I have had ft8v2r4 up since first day announced.
It was amazing to see the activity build for this mock contest.
Thanks again..
BCNU DE N2LO~>2018-11-20,01:44:15,2018-11-20,01:45:15,K5WE,EM25,7.078543,FT8,569,569,,FT8  
Sent: 569  Rcvd: 569,
2018-11-20,01:46:45,2018-11-20,01:46:45,K1JT,FN20,7.078764,FT8,559,569,,FT8  
Sent: 559  Rcvd: 569,
2018-11-20,01:47:30,2018-11-20,01:48:30,KV4ZY,EN91,7.080303,FT8,559,549,,FT8  
Sent: 559  Rcvd: 549,
2018-11-20,01:51:34,2018-11-20,01:51:34,KV4ZY,,7.079740,FT8,559,549,,FT8  Sent: 
559  Rcvd: 549,
2018-11-20,01:56:45,2018-11-20,01:56:45,WA8P,EM89,7.079746,FT8,559,559,,FT8  
Sent: 559  Rcvd: 559,
2018-11-20,02:03:04,2018-11-20,02:03:04,K9AN,EN50,7.082008,FT8,569,549,,FT8  
Sent: 569  Rcvd: 549,
2018-11-20,02:10:45,2018-11-20,02:10:45,VP8LP,GD18,7.079983,FT8,529,549,,FT8  
Sent: 529  Rcvd: 549,
2018-11-20,02:13:18,2018-11-20,02:13:18,DK7ZT,,7.079347,FT8,559,549,,FT8  Sent: 
559  Rcvd: 549,
2018-11-20,02:16:00,2018-11-20,02:17:15,N4IQ,,7.081099,FT8,569,559,,FT8  Sent: 
569  Rcvd: 559,
2018-11-20,02:22:30,2018-11-20,02:24:15,AE4IN,,7.080935,FT8,549,549,,FT8  Sent: 
549  Rcvd: 549,
2018-11-20,02:30:30,2018-11-20,02:31:45,WA3ZSC,,7.080371,FT8,559,559,,FT8  
Sent: 559  Rcvd: 559,
2018-11-20,02:34:23,2018-11-20,02:34:23,HH2AA,,7.080491,FT8,559,539,,FT8  Sent: 
559  Rcvd: 539,
2018-11-20,02:38:17,2018-11-20,02:38:17,N0AN,EN22,7.080104,FT8,539,549,,FT8  
Sent: 539  Rcvd: 549,
2018-11-20,02:42:00,2018-11-20,02:42:00,S58G,JN65,7.080517,FT8,529,559,,FT8  
Sent: 529  Rcvd: 559,
2018-11-20,02:43:15,2018-11-20,02:44:15,K4IZN,EM62,7.081449,FT8,539,569,,FT8  
Sent: 539  Rcvd: 569,
2018-11-20,02:45:00,2018-11-20,02:46:00,WC4H,EL95,7.080175,FT8,569,559,,FT8  
Sent: 569  Rcvd: 559,
2018-11-20,02:50:30,2018-11-20,02:50:30,NU8M,EN82,7.078717,FT8,539,559,,FT8  
Sent: 539  Rcvd: 559,
2018-11-20,02:50:45,2018-11-20,02:52:30,SV1IYF,KM17,7.078667,FT8,529,559,,FT8  
Sent: 529  Rcvd: 559,
2018-11-20,02:57:05,2018-11-20,02:57:05,KG6MC,EM84,7.080597,FT8,569,559,,FT8  
Sent: 569  Rcvd: 559,
2018-11-20,03:33:45,2018-11-20,03:34:45,F6EQZ,JN19,7.078864,FT8,569,569,,FT8  
Sent: 569  Rcvd: 569,___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Faster contest sequence

[Dave Hachadorian]

I tried using the following sequence in the contest last night. 

I SEND (TX6)  CQ RU K6LL DM22

SHE SENDS (TX2) K6LL K7ABC 569 AZ

I SEND (TX3)  K7ABC K6LL R 579 AZ

SHE SENDS (TX4) K6LL K7ABC RR73

I SEND (TX6) CQ RU K6LL DM22


It worked OK sometimes, but several callers kept coming back for more info, 
apparently looking for that final (TX5) “73” from me.  I guess I don’t 
understand why they were looking for that. When I send TX3, the R tells her 
that I got her report.  When she sends RR73, she tells me that she got my 
report.  The QSO data has gone into the log at both ends and all is good.  Why 
can’t I start an immediate CQ, and why doesn’t the automatic sequence follow 
that pattern?  It would shorten the QSO time from 90 seconds to 60 seconds.

Thanks.

Dave Hachadorian, K6LL
Yuma, AZ






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

Re: [wsjt-devel] v2.0 RC4 in congestion !

[Stephen Ireland]

Mark,

I had considered this and its a fair suggestion – but the start of our band is 
say 7.074. Are we not best working under real world congestion – especially on 
40m - and not closed-conditions? That is why I raised the Fleishman and Pons 
“Cold Fusion” fiasco – an example that runs shivers down the spine of anyone 
trying to research or develop – in the initial post...

John,

No split selected. Please do not take this the wrong way but I cannot see how 
split is relevant to this discussion .  Splits are a fantastic idea – but by 
far the vast majority of FT8 conduct Tx’s with the extensive split 
functionality disabled my observation; An op selects a frequency and stays 
there. An op responds either directly on the calling Op’s offset OR at their 
own selected frequency. Splits CAN be a nightmare for the unwary !

73, its 5am here ... and off for surgery so I be quiet for a few days ... maybe 
!

Steve I



Sent from Mail for Windows 10


From: Mark James 
Sent: Wednesday, November 21, 2018 12:59:00 AM
To: WSJT software development
Subject: Re: [wsjt-devel] v2.0 RC4 in congestion !

If you are working above 2000, and might have performance issues on receiving 
signals there, another option is to use a higher dial frequency -- eg 7.075 or 
7.076. This doesn't affect the actual frequencies used, just may make it easier 
to manage.



On Tue, Nov 20, 2018 at 7:52 AM John Nelson 
mailto:j...@rmnjmn.co.uk>> wrote:
Steve,

>  one must “adjust” the AF “Power” drive control as one shifts Tx frequency.

Are you not using CAT control with “Split” selected?   If so, VFOB is set such 
that the audio tone generated is always between 1500 and 2000 Hz which should 
always be within the SSB passband.   The TX offset is managed by VFOB.

— John G4KLA___
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] General issue : The RRR / 73 "loop"

[Stephen Taylor - K6SJT]

I've also had this issue plus another: I believe in earlier versions if I
DID NOT check the respond to first call and I was answering CQ callers,
after I sent 73 the program would leave the 73 tab in place and NOT MOVE to
CQ tab. 

 

If I'm working others and NOT CALLING CQ, then I do not want the Auto Seq to
move to CQ at the end of my QSOs - it doesn't make any sense to do that.
Again, I believe that at some time in the past the program would not move to
CQ tab unless the 1st call box was checked.

 

Once the other station does not reply as 'expected' by the Auto seq it's
very challenging to get the proper response activate quickly. In fact, even
if I quickly click on the correct tab to send the appropriate response, the
Auto seq overrides my entry and sends what it wants.

 

Stephen - K6SJT

Fallbrook CA

 

  

 

  _  

From: Al Pawlowski [mailto:k6...@almont.com] 
Sent: Tuesday, November 20, 2018 8:45 AM
To: WSJT software development
Subject: Re: [wsjt-devel] General issue : The RRR / 73 "loop"

 

What I have started doing is always going back to the tab after my final
response (RR73 or 73), re-enabling and re-selecting the final message and
then sitting with my mouse of the disable tx button to kill the tx if the
other party responds like they got my last message.

 

At least in non-contest mode, seems like it might be better for the
sequencer not to advance and kill the tx enable, i.e. let the operator hit
kill.

 

 

Al Pawlowski, K6AVP
Los Osos, CA USA







Date: Tue, 20 Nov 2018 09:02:55 +

From: Stephen Ireland <  vk3...@hotmail.com>
To: WSJT software development < 
wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] General  issue : The RRR / 73 "loop"

 

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

[wsjt-devel] WSJT-X Dupe Checking in ARRL RTTY Roundup

[Brian Moran]

In the ARRL RTTY Roundup, the rules say work stations once per band,
regardless of mode.  This means those stations using both RTTY and FT8
modes in the same contest will have to check callsigns in BOTH MODES
to know what to work efficiently.

Will there be a means supported to do an 'outcall' to another program
to check duplicate status of any particular contact? For example, N1MM
Logger+ uses the SQLite DB, but access doesn't have to be through N1MM
Logger+; to check dupe status, a small app could be written to perform
the DB query. I'm pretty sure on modern computers the SQLite library
is fast enough to handle the lookup of a list of callsigns before
display, especially if they're queried in a single SQL lookup (e.g.
"WHERE CALLSIGN IN  ('N1ABC', 'K2ABC', 'K3ABC', 'W4ABC'])

I would expect that if a serious contest station were employing both
modes, they'd keep the 'ground truth' database of stations worked in a
contest logger.

Brian N9ADG


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

Re: [wsjt-devel] Winter Field Day Contest Support Request

[Bill Somerville]

On 20/11/2018 14:24, Brian Waterworth wrote:
Would adding another contest to the list of supported wsjtx contests 
remove the restriction you cited?  And granted, I get that this would 
take more time to develop than broadening the allowable characters for 
the current ARRL Field Day contest.


Hi Brian,

the source encoding of the WSJT-X messages is fundamental to the 
protocols, due to the extreme compression algorithms used to pass the 
maximum message content within the fixed constraint of fixed length code 
word. There is virtually no room for changes and a change is likely to 
mean a whole new protocol has to be rolled out. There are 3 bits 
allocated for the FD class in the block of message encodings used for FD 
exchanges, 3 bits can store a maximum of 8 different  values and that 
cannot be changed without changing the number of bits allocated. The 
number of bits allocated is constrained by the overall codeword size 
(77-bits) and the other parts of a message like the callsigns, the 
message type flags, and the rest of the FD exchange.


Looking at it a different way, a single character (A through Z all the 
same case) can be encoded as an ASCII code which takes 7-bits, or it can 
be reduced to as few as 6 bits because we are not allowing for the other 
case or numbers or common punctuation (6 bits allows for 64 possible 
combinations which is enough for the 26 character alphabet and more). 5 
bits is also enough for alphabetic letters with 32 combinations but 4 
bits is not enough as it only has 16 combinations. 4 bits could be used 
for A through P, but we only had 3 spare bits to encode the FD class, so 
that limits us to 8 combinations which covers A through F with two 
unused spares.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Winter Field Day Contest Support Request

[Bill Somerville]

On 20/11/2018 14:20, Black Michael via wsjt-devel wrote:
Is the specific contest mode used during decode?  Couldn't the meaning 
of those 3 bits change depending on which contest is in place?


de Mike W9MDB


Hi Mike,

that is a possibility for this very specific case where Winter FD 
corresponds very closely with the traditional FD format. OTOH, in 
general, the 77-bit message source encoding is not context specific. 
Having context specific interpretations of decoded messages can have 
nasty and unforeseen consequences, as we learned to our cost with the NA 
VHF contest mode implemented with the 75-bit MSK144 message payloads. In 
fact avoiding such hacks was one of the prime driving forces for the new 
77-bit message payload and source encoding.


73
Bill
G4WJS.



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

Re: [wsjt-devel] DXPedition changes?

[Joe Taylor]

Hi Mike,

On 11/20/2018 11:51 AM, Black Michael via wsjt-devel wrote:
It was mentioned a while ago that changes would be made to the Fox mode 
to avoid the power loss for multiple QSOs going on.


Has this been done?  rc4 still points to the old DXpedition guide.


The only change made to FT8 DXpedition Mode is to upgrade it to using 
77-bit messages.  User operation for both Fox and Hound is unchanged.


Some months ago we said "The existing FT8 DXpedition mode will still be 
supported, and a more powerful DXpedition mode may be offered as well."

We have not yet done serious work on the potentially "more powerful mode".
-- Joe, K1JT


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

Re: [wsjt-devel] General issue : The RRR / 73 "loop"

[K5GZR - Rick]

Just did a test with RC4 in RTTY RU mode...
--
'Disable Tx after sending 73 is unchecked.
Clicked 'Next' radio button for Tx5.
Clicked 'Enable Tx'
WSJT-X sent one Tx5 sequence, and left radio button and 'Enable Tx'
unchanged
At start of next Tx5 sequence, WSJT-X selected 'Next' radio button for 'Tx6'
and turned off 'Enable Tx'.
--
I expected WSJT-X to continue sending Tx5 until I click 'Enable Tx' to
signal stop xmit at end of sequence, or 5 minute 'dead man' timer...
Rick - K5GZR

Date: Tue, 20 Nov 2018 08:53:13 -0800
From: Al Pawlowski 
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel]  General issue : The RRR / 73 "loop"
Message-ID: <78d58804-7dd7-435f-8756-e00d3f272...@almont.com>
Content-Type: text/plain; charset="us-ascii"
I forgot about that box and was reminded about it some weeks ago. In any
case, it does not seem to work for me in rc3, and I think previously in rc2
- the box is unchecked yet tx is still disabled when I send a 73.
Al Pawlowski, K6AVP




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

Re: [wsjt-devel] RTTY roundup dups

[John Kludt]

David,

Actually I found JTAlters very useful for exactly that reason - dup
checking.  But see Joe's note - already handled in RC5 or the GA release.

John

On Tue, Nov 20, 2018 at 11:19 AM David Kjellquist 
wrote:

> Has anyone come up with ideas for avoiding dups when using FT8 in a
> large contest? JTAlert checks B4 but its display matrix is limited and
> not really designed for contest use. N1MM log integration works well but
> I don't see that it checks for dups prior actual log entry (not much
> help). But, I'm not really N1MM literate so I may be missing something.
>
> JTAlert does preload a call into AClog but I can't check N3FJP contest
> logs since N3FJP integration is AClog only.
>
> --
> Dave, WB5NHL
> 5BDXCC, 308 countries confirmed
> 206 wrkd FT8, 159 confirmed
>
>
>
> ___
> 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] General issue : The RRR / 73 "loop"

[Al Pawlowski]

I forgot about that box and was reminded about it some weeks ago. In any case, 
it does not seem to work for me in rc3, and I think previously in rc2 - the box 
is unchecked yet tx is still disabled when I send a 73.



Al Pawlowski, K6AVP
Los Osos, CA USA



> On Nov 20, 2018, at 04:09, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Date: Tue, 20 Nov 2018 12:28:32 +0100
> From: Claude Frantz  >
> To: wsjt-devel@lists.sourceforge.net 
> Subject: Re: [wsjt-devel] General issue : The RRR / 73 "loop"

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

[wsjt-devel] DXPedition changes?

[Black Michael via wsjt-devel]

It was mentioned a while ago that changes would be made to the Fox mode to 
avoid the power loss for multiple QSOs going on.
Has this been done?  rc4 still points to the old DXpedition guide.

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

Re: [wsjt-devel] General issue : The RRR / 73 "loop"

[Al Pawlowski]

What I have started doing is always going back to the tab after my final 
response (RR73 or 73), re-enabling and re-selecting the final message and then 
sitting with my mouse of the disable tx button to kill the tx if the other 
party responds like they got my last message.

At least in non-contest mode, seems like it might be better for the sequencer 
not to advance and kill the tx enable, i.e. let the operator hit kill.


Al Pawlowski, K6AVP
Los Osos, CA USA



> Date: Tue, 20 Nov 2018 09:02:55 +
> From: Stephen Ireland mailto:vk3...@hotmail.com>>
> To: WSJT software development  >
> Subject: [wsjt-devel] General  issue : The RRR / 73 "loop"

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

Re: [wsjt-devel] RTTY roundup dups

[Mark James]

Joe, Steve et al -- thanks for your good work here. Last night I believe I
was able to complete QSOs more reliably than in the past, and other people
seemed to be able to decode me at the same power level that had not been
very effective recently with 1.9.1.

On Tue, Nov 20, 2018 at 11:36 AM Joe Taylor  wrote:

> Hi Dave and all,
>
> On 11/20/2018 11:11 AM, David Kjellquist WB5NHL wrote:
> > Has anyone come up with ideas for avoiding dups when using FT8 in a
> > large contest? JTAlert checks B4 but its display matrix is limited and
> > not really designed for contest use. N1MM log integration works well but
> > I don't see that it checks for dups prior actual log entry (not much
> > help). But, I'm not really N1MM literate so I may be missing something.
> >
> > JTAlert does preload a call into AClog but I can't check N3FJP contest
> > logs since N3FJP integration is AClog only.
>
> This is already taken care of in RC5 (which is not yet released).  In
> RC5 the color highlighting is (finally!) working properly.  See the
> screen shot that I posted to this reflector a couple of hours ago.
>
> Steve, K9AN, and I both used RC5 last night, and we found it highly
> effective.  We'll do our best to make RC5 (or the full v2.0 release)
> available in plenty of time for the December 1-2 "FT8 Roundup".
>
> One other point of interest.  Steve and I were paying particular
> attention to performance of the 77-bit decoder in a crowded band.  The
> mock contest provided an excellent indication of what it will be like
> when everyone upgrades to using the v2.0 protocols.  Decoding
> performance was uniformly excellent -- including the frequent copy of 2
> or even 3 overlapping signals.  THanks mostly to Steve's efforts, the
> 77-bit decoder has some significant improvements over the older 75-bit one.
> -- 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] Mixed Mode Operation Crash

[Al Pawlowski]

After RU time, I responded to a few RU calls while in normal FT8 mode. Got 
message "Do you want to switch to Contest mode”. Dismissing the message box 
with an  “OK”, a close (upper right X) or “close” did not seem to make any 
difference in operation. I expected OK might switch modes. Don’t know if this 
is what should happen, but did not have any crash on my end. I completed one 
QSO of the few I tried so that person, at least, did not seem to have a crash.


Al Pawlowski, K6AVP
Los Osos, CA USA



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

Re: [wsjt-devel] RTTY roundup dups

[Joe Taylor]

Hi Dave and all,

On 11/20/2018 11:11 AM, David Kjellquist WB5NHL wrote:
Has anyone come up with ideas for avoiding dups when using FT8 in a 
large contest? JTAlert checks B4 but its display matrix is limited and 
not really designed for contest use. N1MM log integration works well but 
I don't see that it checks for dups prior actual log entry (not much 
help). But, I'm not really N1MM literate so I may be missing something.


JTAlert does preload a call into AClog but I can't check N3FJP contest 
logs since N3FJP integration is AClog only.


This is already taken care of in RC5 (which is not yet released).  In 
RC5 the color highlighting is (finally!) working properly.  See the 
screen shot that I posted to this reflector a couple of hours ago.


Steve, K9AN, and I both used RC5 last night, and we found it highly 
effective.  We'll do our best to make RC5 (or the full v2.0 release) 
available in plenty of time for the December 1-2 "FT8 Roundup".


One other point of interest.  Steve and I were paying particular 
attention to performance of the 77-bit decoder in a crowded band.  The 
mock contest provided an excellent indication of what it will be like 
when everyone upgrades to using the v2.0 protocols.  Decoding 
performance was uniformly excellent -- including the frequent copy of 2 
or even 3 overlapping signals.  THanks mostly to Steve's efforts, the 
77-bit decoder has some significant improvements over the older 75-bit one.

-- 73, Joe, K1JT


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

Re: [wsjt-devel] v2.0 RC4 in congestion !

[Mark Klein]

On Nov 20, 2018, at 7:18 AM, I wrote:

> I agree with that. My equipment has a sweet spot about 1500Hz. But, it also 
> looks like the software adapts transmit frequency accordingly (I’ve seen it 
> go 500 Hz either way), even so, I did add 7.500 and 7.700 to my frequency 
> list as well.

Du’oh! That’s what I get for emailing when I just woke up. 7.075 and 7.077 was 
what I intended to say. :-)


73 de km6aow
---
Mark Klein






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

Re: [wsjt-devel] RTTY roundup dups

[David Kjellquist]

Has anyone come up with ideas for avoiding dups when using FT8 in a 
large contest? JTAlert checks B4 but its display matrix is limited and 
not really designed for contest use. N1MM log integration works well but 
I don't see that it checks for dups prior actual log entry (not much 
help). But, I'm not really N1MM literate so I may be missing something.


JTAlert does preload a call into AClog but I can't check N3FJP contest 
logs since N3FJP integration is AClog only.


--
Dave, WB5NHL
5BDXCC, 308 countries confirmed
206 wrkd FT8, 159 confirmed



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

[wsjt-devel] RTTY roundup

[SKI W4PPC]

Morning:

Again, I had fun last night..as another stated, it was a "hoot"

Thanks.

Stephen Duncheskie, W4PPC
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] v2.0 RC4 in congestion !

[Mark Klein]

On Nov 20, 2018, at 4:37 AM, Stephen Ireland  wrote:
> 
>  
> I realise that Joe K1JT has recommended that for 2.0 RC4 that we should be 
> transmitting above 2000hz in offset.
> 
> Many of us have radios (i.e. non-SDR’s such as Yaesu’s and Pre-SDR-based 
> Icom’s) that have known “performance curves” – even at digital settings - 
> meaning that AF/sound fed to or taken from our radios below around 500 Hz and 
> above around 2200Hz are not reproduced in a “linear fashion” by our radios . 
> This is evidenced by the way that to maintain constant output power across 
> the entire usable spectrum one must “adjust” the AF “Power” drive control as 
> one shifts Tx frequency.

I agree with that. My equipment has a sweet spot about 1500Hz. But, it also 
looks like the software adapts transmit frequency accordingly (I’ve seen it go 
500 Hz either way), even so, I did add 7.500 and 7.700 to my frequency list as 
well.  


Regards,

M. 

So says my Bro: "Please excuse misspellings and grammar errors, they're the 
fault of [his] iPhone."
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Mock Contest Results

[Mark Klein]

Hi, group.

Here are my comments for last evening:

All in all ... things went pretty good for me.  I did have one issue, though.  
I read somewhere that the color ordering could be changed by drag and drop.  I 
did try that and managed to hang WSJTX in the process.  Nothing worked. My only 
resolution was to kill the pid, clean up and restart.   

CentOS 7.5, QT5 - 5.9.2.  WSTJX built from rc4 tarball (with patch). 

Hope that helps. 


Regards,

M. 

So says my Bro: "Please excuse misspellings and grammar errors, they're the 
fault of [his] iPhone."


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

[wsjt-devel] This a test ignore

[Marco Calistri via wsjt-devel]

-- 
73 de Marco, PY1ZRJ


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

Re: [wsjt-devel] Winter Field Day Contest Support Request

[Brian Waterworth]

Hi Bill,

Thanks for the quick response.

If you are referring to potentially extending the current ARRL Field Day to
support the three additional letters, I had first thought about that too.
I even saw in the code where you do the validation.  However, I bet the
wsjtx developers would have a reason for not broadening the definition of
the ARRL field day contest mode to include that of WFD.  You gave such a
reason.  It wasn't one I had anticipated though :-)

Would adding another contest to the list of supported wsjtx contests remove
the restriction you cited?  And granted, I get that this would take more
time to develop than broadening the allowable characters for the current
ARRL Field Day contest.

BTW...Your suggestion is fine.  The trick is getting all WFD participants
to use it.  You have likely noticed that not everybody who uses wsjtx for
the mock contests or DXpeditions use the right version or set the wsjtx
contest mode.  Getting the word out and getting users to rtfm is a
challenge.

If there is no chance to have WFD added to the list of contests in time for
WFD, then I will approach the WFD organizers and make a plea for a
convention as you suggest.   Then, before submitting the log, a string
substitution will need to be made to ensure that A == I, B == O, and C == H.

regards,
Brian
VE3IBW

On Tue, Nov 20, 2018 at 9:08 AM Bill Somerville 
wrote:

> On 20/11/2018 13:20, Brian Waterworth wrote:
>
> I participated in the mock RTTY Roundup contest yesterday.  What fun.  I
> am now even more energized to use wsjtx for the upcoming Winter Field Day.
> But alas, I won't be able to as the class letters are different from the
> ARRL Field Day contest.
>
> As was posted on the main wsjtx forum, the wsjtx ARRL Field Day support
> validates the class ( [A-F] ) and section.  Winter field day uses different
> classes.  However, the same section and qso cadence as the ARRL Field Day
> is used.  The classes are: I == Inside, O == Outside, H == Home.  By way of
> example, my club's class and section would be 3O GTA.
>
> Here is a link to the WFD Rules: https://www.winterfieldday.com/rules
>
> I know the wsjtx development team has a lot on their plate getting ready
> for the upcoming GA. If at all possible, would you be able to support
> winter field day (Jan 26-27, 2019) given how close it is to the actual ARRL
> Field Day support already in wsjtx.  WFD is actually growing in popularity
> year-over-year.
>
> regards,
> Brian
> VE3IBW
>
> Hi Brian,
>
> the field day class is packed into 3 bits so only eight different classes
> are supported. We cannot support three new class letters on top of the
> existing six. It could be possible by agreement to use, say, 'A', 'B', and
> 'C' to represent 'I', 'O', and 'H' since Winter FD does not use any of the
> normal FD classes.
>
> 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] Winter Field Day Contest Support Request

[Black Michael via wsjt-devel]

Is the specific contest mode used during decode?  Couldn't the meaning of those 
3 bits change depending on which contest is in place?  

de Mike W9MDB
 

On Tuesday, November 20, 2018, 8:07:09 AM CST, Bill Somerville 
 wrote:  
 
  On 20/11/2018 13:20, Brian Waterworth wrote:
  
I participated in the mock RTTY Roundup contest yesterday.  What fun.  I am 
now even more energized to use wsjtx for the upcoming Winter Field Day.  But 
alas, I won't be able to as the class letters are different from the ARRL Field 
Day contest. 
  As was posted on the main wsjtx forum, the wsjtx ARRL Field Day support 
validates the class ( [A-F] ) and section.  Winter field day uses different 
classes.  However, the same section and qso cadence as the ARRL Field Day is 
used.  The classes are: I == Inside, O == Outside, H == Home.  By way of 
example, my club's class and section would be 3O GTA.   
  Here is a link to the WFD Rules: https://www.winterfieldday.com/rules 
  I know the wsjtx development team has a lot on their plate getting ready for 
the upcoming GA. If at all possible, would you be able to support  winter field 
day (Jan 26-27, 2019) given how close it is to the actual ARRL Field Day 
support already in wsjtx.  WFD is actually growing in popularity 
year-over-year. 
  regards,  Brian VE3IBW
 
Hi Brian,
 
the field day class is packed into 3 bits so only eight different classes are 
supported. We cannot support three new class letters on top of the existing 
six. It could be possible by agreement to use, say, 'A', 'B', and 'C' to 
represent 'I', 'O', and 'H' since Winter FD does not use any of the normal FD 
classes.
 
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] Winter Field Day Contest Support Request

[Bill Somerville]

On 20/11/2018 13:20, Brian Waterworth wrote:
I participated in the mock RTTY Roundup contest yesterday.  What fun.  
I am now even more energized to use wsjtx for the upcoming Winter 
Field Day. But alas, I won't be able to as the class letters are 
different from the ARRL Field Day contest.


As was posted on the main wsjtx forum, the wsjtx ARRL Field Day 
support validates the class ( [A-F] ) and section.  Winter field day 
uses different classes.  However, the same section and qso cadence as 
the ARRL Field Day is used.  The classes are: I == Inside, O == 
Outside, H == Home.  By way of example, my club's class and section 
would be 3O GTA.


Here is a link to the WFD Rules: https://www.winterfieldday.com/rules

I know the wsjtx development team has a lot on their plate getting 
ready for the upcoming GA. If at all possible, would you be able to 
support winter field day (Jan 26-27, 2019) given how close it is to 
the actual ARRL Field Day support already in wsjtx. WFD is actually 
growing in popularity year-over-year.


regards,
Brian
VE3IBW


Hi Brian,

the field day class is packed into 3 bits so only eight different 
classes are supported. We cannot support three new class letters on top 
of the existing six. It could be possible by agreement to use, say, 'A', 
'B', and 'C' to represent 'I', 'O', and 'H' since Winter FD does not use 
any of the normal FD classes.


73
Bill
G4WJS.

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

Re: [wsjt-devel] v2.0 RC4 in congestion !

[Mark James]

If you are working above 2000, and might have performance issues on
receiving signals there, another option is to use a higher dial frequency
-- eg 7.075 or 7.076. This doesn't affect the actual frequencies used, just
may make it easier to manage.



On Tue, Nov 20, 2018 at 7:52 AM John Nelson  wrote:

> Steve,
>
> >  one must “adjust” the AF “Power” drive control as one shifts Tx
> frequency.
>
> Are you not using CAT control with “Split” selected?   If so, VFOB is set
> such that the audio tone generated is always between 1500 and 2000 Hz which
> should always be within the SSB passband.   The TX offset is managed by
> VFOB.
>
> — John G4KLA___
> 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] Winter Field Day Contest Support Request

[Brian Waterworth]

I participated in the mock RTTY Roundup contest yesterday.  What fun.  I am
now even more energized to use wsjtx for the upcoming Winter Field Day.
But alas, I won't be able to as the class letters are different from the
ARRL Field Day contest.

As was posted on the main wsjtx forum, the wsjtx ARRL Field Day support
validates the class ( [A-F] ) and section.  Winter field day uses different
classes.  However, the same section and qso cadence as the ARRL Field Day
is used.  The classes are: I == Inside, O == Outside, H == Home.  By way of
example, my club's class and section would be 3O GTA.

Here is a link to the WFD Rules: https://www.winterfieldday.com/rules

I know the wsjtx development team has a lot on their plate getting ready
for the upcoming GA. If at all possible, would you be able to support
winter field day (Jan 26-27, 2019) given how close it is to the actual ARRL
Field Day support already in wsjtx.  WFD is actually growing in popularity
year-over-year.

regards,
Brian
VE3IBW
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC4 Mock

[Joe Taylor]

Hi Julian,

On 11/19/2018 9:46 PM, Julian VK4CMV wrote:
I've noticed that WSJT-X logging thinks it's on local time - see the 
Contest Log - the QSOs do make it in Z time to my HRD log via JTAlert 
though. (We are +10hrs on UTC)


There are some signals at 14.078 that I can't decode in RC4 or 1.9.1 - 
which is a bit of a mystery (they were there before the 'contest' began).


Thanks for your report.  Those undecodable signals are JS8, aka JS8CALL, 
formerly known as FT8CALL -- a mode based loosely on the old FT8, but 
using different sync information.


-- Joe, K1JT


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

Re: [wsjt-devel] General issue : The RRR / 73 "loop"

[Bill Somerville]

On 20/11/2018 09:02, Stephen Ireland wrote:
Can the logic possibly be altered so that wsjt-x does not to head to 
CQ [Tx 6] unless a 73 is received from the other station in the QSO?


Hi Steven,

this behaviour is determined by the options "Settings->General->Disable 
Tx after sending 73" and "Settings->Reporting->Clear DX call and grid 
after logging". You must understand what these options do and also when 
you should press the "Ok" button to log a QSO. It is possible to have 
WSJT-X keep sending your 73 message without your intervention until you 
are happy the QSO is completed.


Your observation and frustration is due to you having enabled features 
to speed up operating that have been requested by many, but they do have 
consequences that your must account for.


73
Bill
G4WJS.



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

Re: [wsjt-devel] v2.0 RC4 in congestion !

[John Nelson]

Steve,

>  one must “adjust” the AF “Power” drive control as one shifts Tx frequency.

Are you not using CAT control with “Split” selected?   If so, VFOB is set such 
that the audio tone generated is always between 1500 and 2000 Hz which should 
always be within the SSB passband.   The TX offset is managed by VFOB.

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RU Contest - crash when logging

[Bill Somerville]

On 20/11/2018 05:23, Carey Fisher wrote:

Attached is my all.txt with the XE1MEX entries.
Here is the line where Alex, XE1MEX gave me an "R":

021415   4  0.1 1125 ~  WB4HXE XE1MEX R 559 0006

Don't know why I'm not in his log.


Hi Carey,

it looks like you both started another QSO before that message above was 
decoded at your end, I think that is how things got messed up.


We need to look at edge cases like this and still have some wrinkles to 
iron out.


73
Bill
G4WJS.

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

Re: [wsjt-devel] RU Contest - crash when logging

[Bill Somerville]

On 20/11/2018 05:05, Alex Diaz - XE1MEX via wsjt-devel wrote:

Hi Bill, Carey,
Sorry Carey but you are not in log and therefore you did not get the 
report. I revised the .wav files and I did not find your call sign at 
the time you recorded the QSO  (date and time are local PC not UTC as 
already reported by others)

This is my log:

Inline image
73
Alex
XE1MEX


Hi Alex,

thanks for commenting on this. So we can get the full picture of what 
happened can you reply with the section of your ALL.TXT file that covers 
the period from 02:11:00 through 02:15:00 UTC please?


73
Bill
G4WJS.

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

Re: [wsjt-devel] v2.0 RC4 in congestion !

[Ryan Tourge]

On Tue, Nov 20, 2018 at 7:41 AM Stephen Ireland  wrote:

> Folks,
>
>
>
> I realise that Joe K1JT has recommended that for 2.0 RC4 that we should be
> transmitting above 2000hz in offset.
>
> Many of us have radios (i.e. non-SDR’s such as Yaesu’s and Pre-SDR-based
> Icom’s) that have known “performance curves” – even at digital settings -
> meaning that AF/sound fed to or taken from our radios below around 500 Hz
> and above around 2200Hz are not reproduced in a “linear fashion” by our
> radios . This is evidenced by the way that to maintain constant output
> power across the entire usable spectrum one must “adjust” the AF “Power”
> drive control as one shifts Tx frequency.
>
> Some of us are in so called “far away places” to prime development
> environs and have what some will call compromised antenna systems i.e. wire.
>
> There is considerable anecdotal discussion on backchannels and
> “unofficial” forums that FT8v2 is not performing as well as FT8v1 on
> congested bands. I am swayed to the direction of this opinion at this stage
> – based upon the number of unsuccessful QSO completion attempts. My
> observed “unsuccessful” rate is in excess of 50% with v2. With v1 is around
> 10%.
>
>
>
> [ “Unsuccessful” definition is that the QSO cannot get beyond the RRR
> state and that the QSO must be aborted ].
>
>
>
> Yes there are far more transmitting v1 than v2.
>
>
>
> I am not prepared to make definitive judgement at this point ...
> especially without more FT8v2 QSOs ... remembering the once highly
> respected Fleishman and Pons and their final collaboration !
>
>
>
> Perhaps more experimentation is needed now below 2000 Hz-in-offset across
> all bands i.e. where everyone is Tx’s above everyone, stations ignore the
> “Tx on 50Hz” conventions and hence transmit partially over other stations,
> and the general chaos of AR rules etc... before V2 goes fully live on the 10
> th December?
>
>
>
> Yes I can fully see the consequences – and hence chaos – that this may
> create.
>
>
>
> 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

[wsjt-devel] v2.0 RC4 in congestion !

[Stephen Ireland]

Folks,

I realise that Joe K1JT has recommended that for 2.0 RC4 that we should be 
transmitting above 2000hz in offset.

Many of us have radios (i.e. non-SDR’s such as Yaesu’s and Pre-SDR-based 
Icom’s) that have known “performance curves” – even at digital settings - 
meaning that AF/sound fed to or taken from our radios below around 500 Hz and 
above around 2200Hz are not reproduced in a “linear fashion” by our radios . 
This is evidenced by the way that to maintain constant output power across the 
entire usable spectrum one must “adjust” the AF “Power” drive control as one 
shifts Tx frequency.

Some of us are in so called “far away places” to prime development environs and 
have what some will call compromised antenna systems i.e. wire.

There is considerable anecdotal discussion on backchannels and “unofficial” 
forums that FT8v2 is not performing as well as FT8v1 on congested bands. I am 
swayed to the direction of this opinion at this stage – based upon the number 
of unsuccessful QSO completion attempts. My observed “unsuccessful” rate is in 
excess of 50% with v2. With v1 is around 10%.

[ “Unsuccessful” definition is that the QSO cannot get beyond the RRR state and 
that the QSO must be aborted ].

Yes there are far more transmitting v1 than v2.

I am not prepared to make definitive judgement at this point ... especially 
without more FT8v2 QSOs ... remembering the once highly respected Fleishman and 
Pons and their final collaboration !

Perhaps more experimentation is needed now below 2000 Hz-in-offset across all 
bands i.e. where everyone is Tx’s above everyone, stations ignore the “Tx on 
50Hz” conventions and hence transmit partially over other stations, and the 
general chaos of AR rules etc... before V2 goes fully live on the 10th December?

Yes I can fully see the consequences – and hence chaos – that this may create.

73

Steve I
VK3VM / VK3SIR





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

Re: [wsjt-devel] RTTY RU Test Results

[John Kludt]

Bill,

Thanks for the reply.  I am running current versions of N1MMLogger+, WSJT-X
and JT Alerts under Win7.   First, and I am sure this is where I need some
help, I have never been able to log directly from WSJT-X into N1MM.  I use
JTAlerts as a "bridge' if you will between WSJT-X and N1MMLogger+.  Not
sure what I am doing wrong - any suggestions?  I have all of the boxes
checked in both WSJT-X and N1MM to use the UDP broadcasts 127.0.0.1 and
port 2333.  If I stick JTAlerts in the chain all works well.  One advantage
of having JTAlerts in the chain: dupe prevention through the B4 flag in
JTAlerts

After the contest I began to suspect I had N1MMLogger+ setup wrong.  On the
contest setup page I had set mode as  (kind of makes sense for a RTTY
contest).  I am wondering if I should have set mode as .

WSJT-X worked fine and was a pleasure to use.  It was pleased with the
speed of the transactions.

Tnx,

John K4SQC

On Mon, Nov 19, 2018 at 11:14 PM Bill Somerville 
wrote:

> On 20/11/2018 04:04, John Kludt wrote:
> > John,
> >
> > One question since you were using N1MM as well in the test. On the
> > Modes tab in N1MM Config I checked "Always RTTY." Logging directly
> > from WSJT-X/JTAlerts into the ARRLRTTY each Q hit the N1MM log fine.
> > Each Q was logged as an FT8 Q. Unfortunately N1MM seems rather fussy
> > as it gave all of the FT8 Q's zero points.  Manually changing every Q
> > from mode=FT8 to mode=RTTY solved the problem but that is obviously
> > not a viable long term solution.
> >
> > Probably an N1MMLogger+ issue but/and I am curios to know how you
> > solved it.
> >
> > John K4SQC
> >
> Hi John,
>
> as far as I understand it, if you have the latest N1MM Logger+ and have
> set it up correctly for an ARRL RTTY RU contest then FT8 contacts should
> be logged correctly. Did you have JTAlert sending QSOs to N1MM or did
> you have WSJT-X doing 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

[wsjt-devel] Mock contest on 2018-11-19

[JOHN MILLS via wsjt-devel]

My experience using wsjt-x 2.0 rc4 last night:

At the end of my first QSO, a window popped up asking whether to log it. I 
clicked on yes and the wsjt-x program crashed.

I did not have my Amateur Contact logging program nor JT-Bridge running.


73, John, K1JSM
-
email:  k1...@arrl.net
phone:   401-258-8604
-





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

Re: [wsjt-devel] General issue : The RRR / 73 "loop"

[Claude Frantz]

On 11/20/18 10:02 AM, Stephen Ireland wrote:

Hi Stephen & all,

The only resolution is to double-click BACK on the station that issued 
the RRR, in which case you often respond with a R-XX response instead of 
a 73 … then part of the way through the you nee to resolve the matter 
with a [TX 5] override instead of a 73… reducing the “confidence” of the 
signal received at the other end.


You end up in a rather nasty, frustrating loop !


In settings -> general, there is a option "disable TX after sending 73". 
If it's not set, the TX is not disabled after 73. You have to disable TX 
 manually, at the right moment, when both sides have exchanged "73".


Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] RTTY RU Test Results

[George J Molnar]

Other than the contest log displaying in local time (with AM/PM!), everything 
seemed to work fine in the mock contest. No crashes, no unexpected operation.

MacOS Mojave, Flex6600.

George J Molnar
KF2T - Virginia, USA




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

Re: [wsjt-devel] Attempt to write log in RTTY contest mode causes WSJT-X to terminate

[Gary Rogers]

I’ve had the same problem. Rc4 has worked flawlessly until ru contest. Upon 
rr73 had to fill in sent report and when I hit log button I got subprocess 
error and program closed without sending qso to log. Using MacBook Pro OS X 
high Sierra, JT bridge 2.5.2 and rumlog 4.0.5. Hope that helps. 73 Gary KO3F 

Sent from my iPhone

> On Nov 19, 2018, at 9:07 PM, K5GZR - Rick  wrote:
> 
> Trying to participate in RTTY RU test tonight with RC4 on Win 10 pro.
> Was able to complete a QSO normally.
> But when I clicked OK on the Log QSO popup, there was a pause, then WSJT-X 
> terminated with no warning or error message.
> Same happens in Field Day mode.
> Works fine when not in RU or FD mode.
> Rick – K5GZR
> ___
> 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] General issue : The RRR / 73 "loop"

[Stephen Ireland]

Hi Folks,

In some far off places where some of us reside often many of us are forced to 
operate at Rx levels-of-confidence that some snooty, arrogant amateurs consider 
to be “low levels of confidence” (this is another issue that is holding back 
FT8v2 ... but this is another story for other posts).

As a result you can often end up in what can be termed a “RRR/73” loop…

i.e. wsjt-x sends the 73, ceases Tx, and then the station responds with a RRR … 
creating somewhat of a messy situation to deal with…

The only resolution is to double-click BACK on the station that issued the RRR, 
in which case you often respond with a R-XX response instead of a 73 … then 
part of the way through the you nee to resolve the matter with a [TX 5] 
override instead of a 73… reducing the “confidence” of the signal received at 
the other end.

You end up in a rather nasty, frustrating loop !

Often you have to disable the “automation” in order just to manually send 
“73’s” to meet the requirements of completing the QSO.

Here is an example with explanation... and under no circumstances am I “having 
a  go” here at Prashant W1APC ... I have made many contacts with him before and 
always welcome repeated contacts ...

083037 Tx 1099 ~ W1APC VK3VM 73 <== <== Tx ceases at the 
completion of this and heads to CQ – TX 6.
083045 -13 0.3 808 ~ VK3VM W1APC RRR  <== <== The loop commences
083101 Tx 1099 ~ W1APC VK3VM R-13   <== <== I click on the call and 
it responds with this
083103 Tx 1099 ~ W1APC VK3VM 73 <== <== I click the Tx 5 
Over-ride and DISABLE the automation
083115 -11 0.3 809 ~ VK3VM W1APC RRR  <== <== The loop re-commences
083130 Tx 1099 ~ W1APC VK3VM 73 <== <== I intervene fast 
enough with a TX
083145 -14 0.3 809 ~ VK3VM W1APC 73   <== <== Prashant finally received me 
satisfactorily !
083200 Tx 1099 ~ W1APC VK3VM 73

Can the logic possibly be altered so that wsjt-x does not to head to CQ [Tx 6] 
unless a 73 is received from the other station in the QSO?

Thanks from all of us in far-away lands and also to those stations that 
willingly work low confidence level transmissions that often see this issue !

73

Steve I
Vk3VM / VK3SIR
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel