Re: [wsjt-devel] WSJT Accessibility with VoiceOver on Mac OS?

2024-08-07 Thread Rich - K1HTV via wsjt-devel
Justin,
Why not use the Hamspots website. After you have created an account, which
is free, just search for N5J. A number of blind Hams in the Groups.IO QLog
Users Group  are using the Hamspots to find where various DXpeditions are
operating. Spots are sent to the Hamspots site by stations using JTAlert.
Displayed on each line is the age of the spot, the spotter's call State and
Country, the frequency in Kilohertz to two decimal places and the mode.
The JAWS screen reader is used by most Q Log users to navigate the Hamspots
website, although I believe that some are using NVDA. The QLog program that
I mentioned is a fully voiced logging program interfaced with WSJT-X and
runs under Windows, but could be run using a Windows emulator on a Mac.
QLog is used worldwide by over 100 visually impaired Hams to work FT4 and
FT8.  Once it is started, your screen reader can be turned off as QLog is
fully voiced.

Good luck in using Hamspots and let me know if you are interested in
learning more about QLog and its support programs.
73,
Rich - K1HTV
www.qrz.com/db/k1htv

Subject: [wsjt-devel] WSJT Accessibility with VoiceOver on Mac OS?
Hi there,
I’m a fan of ft8, and I use it primarily though the built-in flex radio
Smart SDR for Mac app, but I’d like to use WSJTX on the Mac, since it is
the native application used for this protocol.  Is there a way that I could
work with some one around its accessibility?  The app *mostly* works, with
a few caveats.
The first being is that the callsigns that are displayed in the waterfall
are all over the place so when a blind person is using VoiceOver, trying to
find a callsign that you’d like to work is a challenge, Is there a way to
have this displayed in to some kind of workable table, or have the
callsigns appear as links?
Second, in the preferences > general, and preferences > radio dialogues,
and others, some of the popups don’t provide the state of programatic focus
to VoiceOver so it is hard to navigate through those popups when you are
trying to setup a radio for instance, or making changes to your station
setup.  I understand the need to make WSJT cross-platform, but is there
anyway this could be built using some native Apple applications?  This
would solve 99% of the Accessibility stuff that is going on between WSJT,
and VoiceOver for blind hams using a Mac.
THanks,
Justin-ai5os
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Initial Calls&Report line missing from TX Freq column

2024-02-10 Thread Rich - K1HTV via wsjt-devel
While working CB0ZEW on 12M FT8, the Band Activity column displayed the
initial report message that I received as well as the RR73 message which
followed.
[image: image.png]

However, the initial message with calls and report *never appeared in the
RX frequency column*.

Only the RR73 line appeared. Below, you can see me (K1HTV) calling CB0ZEW
at 23:47:30.

The 23:48:00 message from CB0ZEW, is seen on the Band Activity column *but
not in the RX Freq window*. Only the message of CB0ZEW sending a -19 report
to W6VJT is seen at 23:48:00 and not the message to me from CB0ZEW which
appeared in the BA column.
[image: CB0ZEW-RXfreq-window.JPG]

Earlier, using F/H, I was moved down from my calling tone frequency to the
transmit frequency of CB0ZEW. After 3 retries there and another 3 up 300 Hz
the QSO was not complete.

For the QSO shown above, I  switched off the F/H mode and called again,
this time  on 2283 Hz.  CB0ZEW answered my call and we completed our QSO
while I continued transmitting  my TX tone  frequency.

I have seen this before, but it hasn’t happened very often.

73,

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


[wsjt-devel] Unwanted Band Activity background color

2024-01-29 Thread Rich - K1HTV via wsjt-devel
Many times a day, using the most current and previous WSJT-X improved
versions, the background color for the entire Band Activity column changes
from the normal white to a color. The only way to go back to the desired
no-color background is to do a right click, erase. But that wipes out the
recent history of decodes. I think that this anomaly only occurs when the
"Start new decodes periods at top" feature is used.

Is there a way to stop this unwanted background color action? If not, Is
there a way to remove the unwanted background without having to erase the
recent history of decodes in the BA column window?

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


[wsjt-devel] "Highlight orange:" feature

2024-01-29 Thread Rich - K1HTV via wsjt-devel
I have been using the "Highlight orange:" feature in the "Colors" tab
screen, and have added a number of  /MM callsigns to the comma delimited
list of stations that I'm interested in re-working for new water grids.

I noticed that in the Band Activity column, when a station on that list
that I had previously contacted is decoded, the background color around the
callsign briefly flashes orange, then quickly turns and stays gray.

It would be better if the color behind the decoded stations on the list
would stay orange and not revert back to gray.

I am using the WSJT-X v2.7.1-devel 240206 improved PLUS version under
Windows 10.

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


Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

2024-01-26 Thread Rich - K1HTV via wsjt-devel
I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in
the Rx Frequency column.I am presently running the "WSJT-X V2.7.1 devel
231031 Improved PLUS" version.

Also, when the "Start new period decodes at top" checkbox is checked, many
times a day the background color will change from white to another
background color. When this occurs it is not always the same color.

Also, at times when using  the  "Start new period decodes at top" option,
the Band activity columns display will revert back to the earliest decodes,
often many tens of minutes earlier.

73,
Rich - K1HTV


On Fri, Jan 26, 2024 at 7:55 AM 
wrote:

> Send wsjt-devel mailing list submissions to
> wsjt-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
> wsjt-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> wsjt-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> Today's Topics:
>
>1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)
>
>
>
> -- Forwarded message --
> From: Glenn Williams 
> To: wsjt-devel@lists.sourceforge.net
> Cc:
> Bcc:
> Date: Thu, 25 Jan 2024 08:12:51 -0500
> Subject: [wsjt-devel]  skips RX frequency window (bug?) wsjtx-2.7.0-rc3
> V 2.7.0-rc3
> Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10. (This
> has happened once or twice before.)  His S/N report on me popped up in
> Band Act window after my TX1, but no report in RX Freq window. TX3
> completed OK in both Windows.  I use COLORS and so red was instantly
> obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the order
> of 450 watts with tuner. Not thinking RFI because no other times ever I
> see any.
>
> -73, Glenn, AF8C
> --
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] WSJT-X 2.5.3 crashes on TX5 with slash in call

2021-12-23 Thread Rich - K1HTV via wsjt-devel
I have run into a problem with WSJT-X 2.5.3 when transmitting a TX5 message
to any station with a "/"  followed by /MM or /P and probably other
characters. I'm running the Win 64 bit version on a Windows 10 computer
with the latest updates.

After transmitting the TX5 message, the receive cycle starts and runs for
11 seconds. At that point the clock in the lower left corner stops and a
few lines of decoded data is displayed, then the program ends. The problem
ican be reproduced.

A jt9.exe process is left running, which must be deleted with Task Manager
before WSJT-X can be started again.

The issue only occurs with stations with a forward slash in the callsign. I
tried using a non-standard callsign such as 3DA0XXX, with no problem, only
with calls with slash.

I've gone back to WSJT-X Version 2.5.2 and ran the same tests without the
program crashing after a TX5 message with a forward slash in the call.

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


[wsjt-devel] WSJT-X 2.3.5 anomaly

2021-12-09 Thread Rich - K1HTV via wsjt-devel
After downloading and successfully installing the Win64 version of WSJT-X
2.5.3, I made a successful FT8 QSO. After it was complete I sent one  "$DX
12345" TX5 macro to that same station with my radio in the test mode. The
line for that $DX message transmission appeared fine in the "Rx Frequency"
column.  A minute or so later, I looked up and the WSJT-X main and wide
graph screens were gone. They were not in the Windows taskbar. When I
tried to restart WSJT-X, an error message popped up; "Sub-process error
Failed to close orphaned jt9 process". I opened the Task Manager and
stopped the jt9 process.

After restarting WSJT-X again, I was able to make another QSO, but a minute
or so later, again WSJT-X disappeared from the screen. When I tried again
to restart WSJT-X, I again received the message about the orphaned jt9
process. I again killed the jt9 process.

After the third restart of WSJT-X,  I made a number of successful QSOs and
so far the program has not closed itself again.

Has anyone else experienced this anomaly?
73,
Rich - K1HTV
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] wsjt-devel Digest, Vol 93, Issue 47

2021-11-20 Thread Rich - K1HTV via wsjt-devel
Thanks Mike. I've added the exclusions.
73,
Rich - K1HTV

On Thu, Nov 18, 2021 at 10:50 AM 
wrote:

> Send wsjt-devel mailing list submissions to
> wsjt-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
> wsjt-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> wsjt-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> Today's Topics:
>
>1. Status File Error WSJT-X v2.5.2 (Rich - K1HTV)
>2. Re: Status File Error WSJT-X v2.5.2 (Black Michael)
>
>
>
> -- Forwarded message --
> From: Rich - K1HTV 
> To: WSJT 
> Cc:
> Bcc:
> Date: Thu, 18 Nov 2021 10:36:54 -0500
> Subject: [wsjt-devel] Status File Error WSJT-X v2.5.2
>
> Since I started using WSJT-X version 2.5.2, I have seen this error message
> pop up every few days.
> [image: image.png]
>
>
> Sometimes I must click the OK button multiple times to finally clear the
> last of multiple “Status File Error” message boxes.
>
> I checked the path and there is no WSJT-X folder in the
> “k1htv\AppData\Local\Temp” folder. Any idea what might be triggering this
> error message?
>
> 73,
>
> Rich – K1HTV
>
>
>
> -- Forwarded message --
> From: Black Michael 
> To: Rich - K1HTV via wsjt-devel 
> Cc:
> Bcc:
> Date: Thu, 18 Nov 2021 15:50:02 + (UTC)
> Subject: Re: [wsjt-devel] Status File Error WSJT-X v2.5.2
> Exclude the path in your antivirus.
> You can google "defender exclusions" or such depending on your antivirus.
>
> Mike W9MDB
>
>
>
>
> On Thursday, November 18, 2021, 09:47:23 AM CST, Rich - K1HTV via
> wsjt-devel  wrote:
>
>
> Since I started using WSJT-X version 2.5.2, I have seen this error message
> pop up every few days.
> [image: image.png]
>
>
> Sometimes I must click the OK button multiple times to finally clear the
> last of multiple “Status File Error” message boxes.
>
> I checked the path and there is no WSJT-X folder in the
> “k1htv\AppData\Local\Temp” folder. Any idea what might be triggering this
> error message?
>
> 73,
>
> Rich – K1HTV
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Status File Error WSJT-X v2.5.2

2021-11-18 Thread Rich - K1HTV via wsjt-devel
Since I started using WSJT-X version 2.5.2, I have seen this error message
pop up every few days.
[image: image.png]


Sometimes I must click the OK button multiple times to finally clear the
last of multiple “Status File Error” message boxes.

I checked the path and there is no WSJT-X folder in the
“k1htv\AppData\Local\Temp” folder. Any idea what might be triggering this
error message?

73,

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


Re: [wsjt-devel] Bug in 2.5.1?

2021-10-25 Thread Rich - K1HTV via wsjt-devel
Lance, W7GJ  wrote:
...Maybe if there were an option to keep the signal report the
same even if there are a number of intervening contacts or transmissions to
other stations, I guess that is what I am trying to do by hand and failing
miserably at... Do you understand my dilemma?

MNI TNX and VY 73,  Lance


- - -

Lance, maybe there needs to be an equivalent of the "599" like we all use
for working DX or in contestseverybody is 599 :-). Maybe for Q65
everybody should be -25.

73,

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


[wsjt-devel] Exaggerated reports given to lower tone freqs

2021-10-15 Thread Rich - K1HTV via wsjt-devel
Has anyone experienced exaggerated dB signal reports given by WSJT-X to
decoded FT8 signals of stations transmitting tone frequencies below 500 Hz?
I use a K3 with 2.8 KHz filter using WSJT-X Version 2.5.0 . I have also
seen this in earlier versions.

When stations using low audio tones are decoded, the signal levels that
WSJT-X gives them far exceeds the levels given to signals with higher
frequency tones of equal intensity level observed visually on the wide
graph.

I have run the “Measure Reference Spectrum” tool on a quiet frequency and
have the “Ref Spec” checkbox on the Wide Graph checked. This didn’t resolve
the noted anomaly. I first observed this on Foxes running 3 or 4 streams
using tones below 500 Hz with the lower tones appearing a few DB stronger
than the higher tones.

Any idea as to why this may be happening.

73,

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


[wsjt-devel] WSJT-X vs JTDX sensitivity comparison

2021-09-14 Thread Rich - K1HTV via wsjt-devel
After this past weekend's ARRL VHF contest, one of the top SOHP scorers,
Mike, W3IP, posted a note to the PVRC reflector along with the breakdown of
his score. In his comments he compared the FT8 sensitivity of WSJT-X vs
JTDX.  Mike is a technically sharp guy and I trust what he has reported.
Here is what W3IP wrote:

*"When operating on FT8, I ran WSJT-X and JTDX in parallel. The JTDX decode
capability on weak signals is significantly better - but JTDX doesn't
recognize contest mode. I had several contacts that decoded only on JTDX so
I had to manually advance the transmit side exchange on WSJT-X each time. I
had only one occasion when I decoded a wanted signal in WSJT-X only. What a
pain!"*

I wonder what might explain the better performance of JTDX over WSJT-X on
weak signals and if something can be done so WSJT-X can match the weak
signal performance of JTDX.

I used WSJT-X v2.5.0-rc5 in the VHF contest on 6M & 2M and it performed
well for me on FT8. I haven't yet compared WSJT-X at my QTH with JTDX.

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


[wsjt-devel] Received RR73 Tx4 msg turning off our "Enable Tx"

2021-08-06 Thread Rich - K1HTV via wsjt-devel
Presently on FT8, when we turn on our “Tx enable” button to call a station
ending a QSO with another station, when we receive his Tx4 “ RR73” message,
WSJT-X disables our “Enable Tx” button.

Even when calling with a different Tx tone frequency, as to not cause
on-freq QRM, as long as our Rx window is within 50 Hz of the station we
want to call, the disabling of "Tx Enable" occurs.

Is there any reason why this feature couldn't be eliminated, so we can
proceed calling that station without having to re-enable the “Enable Tx”
button when an "RR73" message is received?

73,

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


[wsjt-devel] RC4 Watchdog anomaly

2021-05-16 Thread Rich - K1HTV
I've been running WSJT-X version 2.4.0-rc4 on a quad core Dell Z440
computer using Windows 10. I've found what appears to be an anomaly that I
don't recall seeing as being reported. I was calling a BD station in China
on 17M FT8,. I called using the Tx2 vs the Tx1 message. I noticed that as
the minutes passed, and the BD station contacted other stations, the WD
timer stayed at the default value of 6 as I continued calling higher on the
widegraph screen. However, after a period of time, probably 6 minutes, the
Enable Tx light went off and my transmissions stopped. The counter in the
lower right corner of the main WSJT-X screen remained at 6 until the
transmission stopped. It never decremented at all.

Next, I tested the watchdog timer , calling the BD station using the Tx1
message, By that time that station was much weaker. As I continued calling,
after about 2 minutes the WD counter decremented to 5. After another 2
minutes, the WD timer decremented to 4. But even stranger, after another 2
minutes, the watchdog time *incremented* from 4 to 5 as I continued calling
that same BD station. Two minutes later, the WD timer *incremented again*,
from 5 to 6.

I continued calling the BD station and the WD timer then started
to decrement every couple of minutes and this time it got down to 3. But, a
few minutes later, it jumped from 3 to 6.
At this point I stopped the test.

Have others seen this strange behavior?
73,
Rich - K1HTV
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Few FT8 decodes on Even cycles

2021-04-22 Thread Rich - K1HTV
Bill - G4WJS,
  OK on the suggestion of switching to Meinberg NTP instead of D4.EXE,
which I have been using successfully for years. Today, the problem of poor
odd cycle and almost no even cycle FT8 decodes started again. I checked and
found the Windows Internet Time Sync tool was disabled. One would think
that if D4.EXE was the cause of the problem, disabling it would stop the
anomaly, so I shut down D4.EXE, but the poor decode problem continued.

Note that after a week of not leaving Chrome running, I started it again
yesterday and left it running. When the poor decode problem started again
today, I checked Task Manager and found that Chrome's memory use had
increased to over 1.3 GB. That is still a small fraction of the 16GB of
available RAM.

What might cause this poor and asymmetrical number of decoded FT8 stations
with the number of odd cycle decodes being greater than the almost zero
number of even cycle decodes?

Is it possible that some of the JT9.exe decoder code in RAM is getting
contaminated?

I'm in the process of bringing a 4 core computer online, replacing the dual
core computer now in use for WSJT-X. It will use Meinberg NTP. Hopefully
the poor decode problem will go away.with the new box.

73,
Rich - K1HTV
= = -

From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Mon, 19 Apr 2021 18:07:49 +0100
Subject: Re: [wsjt-devel] Few FT8 decodes on Even cycles
Hi Rich,

you describe symptoms that could be explained by your time synchronization
application making step changes, that is sure to cause discontinuities in
the audio streams which in turn are very likely to disrupt decoding of all
signals in periods where that happens. One cause of this could be multiple
time sync applications running simultaneously, e.g. not disabling the
Windows Internet Time Sync tool if you are running another 3rd party time
sync tool. Note also that we no longer recommend SNTP time sync tools as
they are prone to this sort of time stepping on systems that keep poor time
when unsynchronized. On MS Windows the Meinberg NTP Client is a proper NTP
implementation and only steps the time during initialization, if configured
to do so, to get a fast synchronization. There are other time sync tools
that implement NTP rather than SNTP, if Meinberg is not to your liking. On
other platforms the default network time sync tool will be a full NTP
implementation like the *nix ntpd or more modern chronyd, so there just
enabling the system network time synchronization is sufficient.

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


Re: [wsjt-devel] Few FT8 decodes on Even cycles

2021-04-19 Thread Rich - K1HTV
Bill - W2PKY,
Thanks for the idea of playing back the WAV files which had few or no
decodes.  I played the WAV files back and they sound normal, full of
signals but still decode few if any of them when I play them back for
decoding.

I wonder if WSJT-X has a shared memory buffer which another program had
access to which caused part of the decoding part of the program to produce
the poor decodes. Another thing that I noticed was that when there were FT8
decodes on the odd cycles, at times most of the decoded signals had a DT of
0.1 then in some of the next receive cycles almost all decoded stations had
a DT of 0.4 seconds. Then they would be back to 0.1 second DT numbers.
However, when the problem occured, as I checked the PC clock a number of
times using the "time.is" URL, it indicated "Your time is Exact" usually
within 1- milliseconds of exact.

My station is band switching and decoding 24/7. I've left all normally used
programs running but have shut down Chrome. So far, in the past few days
the problem has not re-occurred. Maybe Chrome is the culprit. The last time
when the problem occured, Chrome was consuming over 1 GB of RAM, still far
less than the available 16GB but still a lot. Once the problem starts,
shutting down Chrome and apps doesn't fix it, only a reboot of the computer.

Thanks also for the suggestion about checking if standby memory is being
used when the problem occurs. Will have to do that.

73,
Rich - K1HTV.

-- Forwarded message --
From: Bill B 
To: WSJT software development 
Cc:
Bcc:
Date: Fri, 16 Apr 2021 21:56:27 -0400
Subject: Re: [wsjt-devel]
Hello Rich-
Have you listened to the .wav files to see if they sound clean and
undistorted?

Windows allows audio channels to be monitored. Open sound control panel >
recording tab, locate input device > properties > listen tab > click listen
to this device.
Listen to the audio quality when the app fails to decode everything that’s
in the waterfall.

Bring up Task Manager > performance > open resource monitor > Memory and
check if Standby memory is used up. That’s when my system starts acting
strange. You may need to reboot more often.

Hope this helps.
Bill W2PKY

Sent from my iPad

On Apr 16, 2021, at 1:47 PM, Mike Lewis  wrote:



I have been seeing cycles with only a few decode counts on busy bands
periodically



I am usually run 2 WJST-X instances 24/7 comparing the decode count each
cycle of a new SDR rig while I am working on it, compared to my K3, both on
the same antenna.  I watch the decode count number and waterfall images
constantly, but not the actual decodes much.  I do not reboot very often,
the short decode count only happen to me once then back to normal. I blamed
that on the possibility the missing decodes would appear in the next decode
group as late decodes, but I have not verified that happens/happened.  Need
to look  at that next time.   I usually see it a few times a day. I will
look to see if it is odd or even as well.  This is 2.4.0-rc4.  It occurred
on earlier rc versions, maybe on 2.3 also.



Mike

K7MDL  EL87sm & CN88sf



*From:* Rich - K1HTV 
*Sent:* Friday, April 16, 2021 08:14
*To:* WSJT 
*Subject:* [wsjt-devel] Few FT8 decodes on Even cycles



In the past couple of months, using both the GA and the RC versions of
WSJT-X, I've been plagued with an intermittent decode problem while running
FT8. I am using Win10 on a dual core i5-2500 @ 3.3GHz with 16GB of RAM. It
may take days and sometimes less for the problem to occur. On a busy 20
Meter band, the decode count and corresponding number of decodes are
normally between 30 and 60 per 15 second FT8 sequence.



When the problem develops, with a full waterfall display, on the *odd
cycles*, only 4 to 8 signals are decoded and counted. On the *even cycles* only
a few and often NONE of the many dozen signals are decoded. The DT on most
of the few decoded signals is usually 0.1 seconds, so it's not a clock
issue.



The only fix is to reboot the computer and then the count goes back to the
30 to 60 decodes on both even and odd 15 second cycles.



When the problem occurs, checking with Task Manager, the max CPU usage on
WSJT-X peaks at less than 5% and the max total CPU usage with other apps is
no more than 20% on peaks. A max of 30% of the 16GB RAM is being used. I
use the Chrome browser, using 300-800MB of RAM. When I shut down Chrome and
all other apps, there doesn't appear to be any phantom occurrences of their
processes running, but the very poor decoding problem still exists.



I turned on WSJT-X "Save all" and played back the saved WAV files and the
number of decodes matched the low counter readings noted for the same
sequences. I switched from using the Elecraft K3 USB CODEC to using the
sound card with audio from the K3 Line Out jack and get the same poor
performance when the problem arises.



As I said, only a reboot of the computer will bring things back 

[wsjt-devel] Few FT8 decodes on Even cycles

2021-04-16 Thread Rich - K1HTV
In the past couple of months, using both the GA and the RC versions of
WSJT-X, I've been plagued with an intermittent decode problem while running
FT8. I am using Win10 on a dual core i5-2500 @ 3.3GHz with 16GB of RAM. It
may take days and sometimes less for the problem to occur. On a busy 20
Meter band, the decode count and corresponding number of decodes are
normally between 30 and 60 per 15 second FT8 sequence.

When the problem develops, with a full waterfall display, on the *odd
cycles*, only 4 to 8 signals are decoded and counted. On the *even cycles*
only a few and often NONE of the many dozen signals are decoded. The DT on
most of the few decoded signals is usually 0.1 seconds, so it's not a clock
issue.

The only fix is to reboot the computer and then the count goes back to the
30 to 60 decodes on both even and odd 15 second cycles.

When the problem occurs, checking with Task Manager, the max CPU usage on
WSJT-X peaks at less than 5% and the max total CPU usage with other apps is
no more than 20% on peaks. A max of 30% of the 16GB RAM is being used. I
use the Chrome browser, using 300-800MB of RAM. When I shut down Chrome and
all other apps, there doesn't appear to be any phantom occurrences of their
processes running, but the very poor decoding problem still exists.

I turned on WSJT-X "Save all" and played back the saved WAV files and the
number of decodes matched the low counter readings noted for the same
sequences. I switched from using the Elecraft K3 USB CODEC to using the
sound card with audio from the K3 Line Out jack and get the same poor
performance when the problem arises.

As I said, only a reboot of the computer will bring things back to normal.
I'm at a loss to figure out what is causing this intermittent problem and
how to correct it. Does anyone have any ideas of the cause and how it can
be fixed? Thanks.

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


[wsjt-devel] Re-decoding past transmission on FT8

2021-04-15 Thread Rich - K1HTV
In the past, in the FT8 mode, after using the "CQ Only" checkbox option on
the main WSJT-X screen, by unchecking it the user could display all decodes
from the same cycle as the CQ Only results.

Would it be possible to reinstate this feature or does the WAV file for
that 15 second sequence only contain signals that pass the "CQ Only"
filter? If all signals are in the WAV file, How about using the "Decode"
button to re-decode that WAV file so the user could see the stations that
couldn't be copied with "CQ Only": filter enabled?

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


[wsjt-devel] Cabrillo file creation question

2021-03-22 Thread Rich - K1HTV
For the Virginia QSO Party (VQP) this past weekend I wanted to use the
WSJT-X FT4 and FT8 modes to work a number of DX QSOs. Since none of the
special activities supported by WSJT-X matched the VQP requirements, I had
to improvise. I stored  "CUL VQP 73" as a Tx5 macro. "CUL" is my VA county
abbreviation. When a station answered my "CQ DX", I used the Tx5 pulldown
menu to select the stored message and prepended a 3 digit QSO number. When
the QSO was completed. in order to store the QSO number sent and county
number, I entered them in the WSJT-X "Log QSO" window. The "CUL" county was
stored in the "Tx power"  field with the "Retain" option checked so the
county abbreviation wouldn't have to be entered for each QSO.  The QSO
number was entered into the "Comments" field. All of the required data for
each QSO was successfully stored in the comma delimited "wsjtx.log" file.

I would like to submit my VQP log of digital QSOs to the VQP sponsor as a
Cabrillo file but can't find a way to do so. A  ".cbr" file can only be
exported for one of the WSJT-X "Special Activities" options.

My question is, when the WSJT-X "Export Cabrillo Log" option is selected,
what file is used to create the CBR file? Presently when I run this option,
all I get is the header information based on information entered in the
window that pops up before the otherwise empty CBR file is created.

I'd like to create a Cabrillo using WSJT-X non-contest data. Is that
possible?

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


[wsjt-devel] Re" FT8 poor decoding problem solved

2021-03-17 Thread Rich - K1HTV
Reino - OH3MA,
 The radio is an Elecraft K3 with audio fed via USB cable from its internal
CODEC. I received a call from Sam, W2JDB, creator of the QLog program for
blind Hams to use FT8/FT4. Sam suggested that the problem may be that
Windows, for some reason, stops handling the time correction data. My PC
clock, if not updated with a time sync program, my PC clock will be off by
2 seconds in a day. That might explain the low number of decoded stations,
with clock settings that probably are also close to the +/- 2 second mark.

One thing that I should have done was to check the WSJT-X time compared to
my WWVB sync'd atomic clock , even though the "TIME.IS"  website said that
my time was "Exact".

73,
Rich - K1HTV
= = =

To: "'WSJT software development'" 
Cc:
Bcc:
Date: Wed, 17 Mar 2021 21:07:34 +0200
Subject: Re: [wsjt-devel] FT8 poor decoding problem solved

I'm passing along this info for others who might be experiencing low
numbers of FT8 decodes.

In the past month on 3 occasions the number of FT8 decodes on very busy
bands didn’t match the activity noted on the Wide Graph. Although many
dozens of stations were seen, fewer than 10 were being decoded on the odd
cycles and only 1 or 2 stations were decoded during the even cycles. This
same pattern was noted on all 3 times that this problem was observed. The
problem occurred while using WSJT-X V2.3.0 GA as well as 2.4.0-rc1 & 3
versions.

I verified that D4.EXE had recently updated the time and the “Time.IS”
website said the computer clock was “Exact”, so it wasn’t a time issue.
Using the Windows Task Manager, the maximum CPU usage with the dual core
I5-2500 CPU running at 3.3 GHz never exceeded 40% on peaks. There was
plenty of the 16GB of memory available, so it didn’t appear to be a memory
issue either. The audio receive level was between 50 and 60 dB on the
WSJT-X bar meter.

I shut down all other apps but the poor decode performance continued with
only WSJT-X running. Shutting down and restarting WSJT-X didn’t correct the
problem.

The fix?  I rebooted the computer and during subsequent decode cycles,
between 40 and 60+ stations were decoded each cycle. The reboot fixed the
poor decoding each time the problem was observed.

Any thoughts as to why this was happening?

Thanks Rich of your positive report. Could you remind us which rig are
using and how it is connected to your PC, please?
73, Reino OH3mA
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] FT8 poor decoding problem solved

2021-03-17 Thread Rich - K1HTV
I'm passing along this info for others who might be experiencing low
numbers of FT8 decodes.

In the past month on 3 occasions the number of FT8 decodes on very busy
bands didn’t match the activity noted on the Wide Graph. Although many
dozens of stations were seen, fewer than 10 were being decoded on the odd
cycles and only 1 or 2 stations were decoded during the even cycles. This
same pattern was noted on all 3 times that this problem was observed. The
problem occurred while using WSJT-X V2.3.0 GA as well as 2.4.0-rc1 & 3
versions.

I verified that D4.EXE had recently updated the time and the “Time.IS”
website said the computer clock was “Exact”, so it wasn’t a time issue.
Using the Windows Task Manager, the maximum CPU usage with the dual core
I5-2500 CPU running at 3.3 GHz never exceeded 40% on peaks. There was
plenty of the 16GB of memory available, so it didn’t appear to be a memory
issue either. The audio receive level was between 50 and 60 dB on the
WSJT-X bar meter.

I shut down all other apps but the poor decode performance continued with
only WSJT-X running. Shutting down and restarting WSJT-X didn’t correct the
problem.

The fix?  I rebooted the computer and during subsequent decode cycles,
between 40 and 60+ stations were decoded each cycle. The reboot fixed the
poor decoding each time the problem was observed.

Any thoughts as to why this was happening?

73,

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


[wsjt-devel] Rc4 Tx levels will cause future QRM problems

2021-02-15 Thread Rich - K1HTV
I noticed that while running WSJT-X v2.4.0-rc1, the original WSJT-X "Pwr"
control setting produced excessive AGC levels on my K3 transceiver. TX
levels are over 5 dB higher with WSJT-X Version 2.4.0-rc1 than with
previous versions.

Unless a software change is made so TX audio levels match those of previous
versions of WSJT-X, I'm afraid that we all will be hearing more kazoo
sounds on the FT8 & FT4 frequencies and will be seeing more and more
spurious signals on our Wide Graph screens.

"Pwr" slider idea:
Would it be possible to change the way to read the "Pwr" slider setting dB
level?  Presently, users must move the slider setting in order to check the
dB level,We should be able to read the setting without having to change it.

How about adding a small "dB' box right under the "Pwr" label  I think that
would make more sense than the way it is now. Can this change be
implemented?

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


Re: [wsjt-devel] VHF Contest available bands feature?

2021-01-23 Thread Rich - K1HTV
Phil,
Getting the info to all VHF contesters about the letter equivalents for
each band simply won't happen. It is just as easy and more clear if you
create WSJT-X macros for Tx5 such as "QSY 2M 73" or "QSY 1296 73". The
space followed by "73" at the end of the line is copied as a valid 73
message by the other station. Not including the 73 in the message will
result in repeat roger reports from the station you are working. Serious
FT8 users in the contest will know the FT8 frequency for each band.

If you work a stationon FT8 and you use a tone within 50 Hz,your message
should be displayed at the bottom of his "Rx Frequency" column. If you use
a tone frequency outside of this +/- 50 Hz , your Tx5 message will only
appear in the left column. However, since the message doesn't include his
call, he may miss the request to QSY. Because of the 13 character message
limit, it is not possible to include the other station's call along with
the QSY message.

73,
Rich - K1HTV

From: phumphr...@columbus.rr.com
To: "'wsjt-devel@lists.sourceforge.net'" 
Cc:
Bcc:
Date: Fri, 22 Jan 2021 17:39:33 +
Subject: [wsjt-devel] VHF Contest available bands feature?
Hello Everyone,

I have been having a great time using digital modes for day to day and
contesting in the VHF/UHF/SHF  bands. One very common complaint I get is
that it is difficult to communicate to the other station that you wish to
QSY to the next higher band or a specific band. While using SSB or CW you
can convey your intentions, but while using digital the only way is to use
the free text feature. There are 10 common bands people use during NA
contesting:

2 , 222, 432, 903, 1.2, 2.3, 3.4. 5.7, 10G, 24G

Most will run 6 meters continuously.

Here is my idea, assign each band one letter or number. At the end of the
tx5 message, indicate your next available band or a character to indicate
that the current QSO is the last band you have. I don't believe that
stations are using all the available data to convey the tx5 message. I had
even thought that the tx4 message could be used and the tx5 message could
confirm the next band to QSY to. I am sure that bands used would be
indicated in the setup configuration. Taken a step further even the Tx1
message could indicate how many or which bands are available. This idea
could also be used for HF Contests.

I am sure others have a better ideas, but it would enhance VHF contesting
without many repeated exchanges of free text during a contesting.

Thank you all for the many features and improvements made to accommodate
contesting modes.

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


Re: [wsjt-devel] wsjt-devel Digest, Vol 83, Issue 56

2021-01-10 Thread Rich - K1HTV
Thanks to Bill, G4WJS and Laurie, VK3AMA for the answer on how to get
Multicasting working and for the reason why the changes were made to the
settings.

73,
Rich - K1HTV

On Sat, Jan 9, 2021 at 6:28 PM 
wrote:

> Send wsjt-devel mailing list submissions to
> wsjt-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> or, via email, send a message with subject or body 'help' to
> wsjt-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> wsjt-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wsjt-devel digest..."
> Today's Topics:
>
>1. Re: Multicast with 2.3.0-rc3 (Laurie, VK3AMA)
>
>
>
> -- Forwarded message --
> From: "Laurie, VK3AMA" <_vk3a...@vkdxer.net>
> To: WSJT software development 
> Cc:
> Bcc:
> Date: Sun, 10 Jan 2021 10:08:11 +1100
> Subject: Re: [wsjt-devel] Multicast with 2.3.0-rc3
> The WSJT-X 2.3.0-rc's introduced a new outgoing interface selector for
> multicast UDP (Reporting tab of the WSJT-X Settings). You need to have a
> loopback interface selected and then tell JTAlert that your using UDP
> Multicast on the Loopback via the "Settings" menu , top most entry. This is
> a departure from the traditional JTAlert automatic setting of the necessary
> parameters as there is now no reliable way to determine the WSJT-X settings
> and if the loopback interface is being used
>
> de Laurie VK3AMA
>
>
> On 10/01/2021 9:46 am, Rich - K1HTV wrote:
>
> With WSJT-X version 2.2.2 I had been successfully using multicat with
> WSJT-X passing UDP packets simultaneously to JTAlert, GridTracker and QLog,
> a program developed for blind Hams to make FT8 & FT4 QSOs. I was using a
> USP server address of 239.255.0.1 with port 2237.
>
> In version 2.3.0-rc3, using this address and port, multicasting does not
> work with any of the programs. I tried the 224.0.0.1 with port 2237 as
> described in the latest release notes, but that doesn't work either.
>
> After running for a few minutes, JTALert displayed this message box:
> [image: image.png]
>
> Am I the only one experiencing this problem. Any clue why? Thanks.
>
> For now with WSJT-X version 2.3.0-rc3 I'm stuck with only using one add-on
> program at a time to receive UDP packets using 127.0.0.1 Port 2237, which
> still works fine.
>
> 73,
> Rich - K1HTV
>
>
> ___
> 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] Multicast with 2.3.0-rc3

2021-01-09 Thread Rich - K1HTV
With WSJT-X version 2.2.2 I had been successfully using multicat with
WSJT-X passing UDP packets simultaneously to JTAlert, GridTracker and QLog,
a program developed for blind Hams to make FT8 & FT4 QSOs. I was using a
USP server address of 239.255.0.1 with port 2237.

In version 2.3.0-rc3, using this address and port, multicasting does not
work with any of the programs. I tried the 224.0.0.1 with port 2237 as
described in the latest release notes, but that doesn't work either.

After running for a few minutes, JTALert displayed this message box:
[image: image.png]

Am I the only one experiencing this problem. Any clue why? Thanks.

For now with WSJT-X version 2.3.0-rc3 I'm stuck with only using one add-on
program at a time to receive UDP packets using 127.0.0.1 Port 2237, which
still works fine.

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


Re: [wsjt-devel] no decode - ntp ?

2018-07-26 Thread Rich - K1HTV
Chris,
With D4.exe turned off, have you checked your PC clock to see if it is gaining 
or loosing time? Do a manual sync them wait 10 minutes and do another manual 
sync. Then hover your mouse pointer over the Dx.exe icon in the lower right 
toolbar. It should indicate the delta time from the last sync.


One thing I noticed which adversely affected my PC clock time. When I use the 
PC mouse roller up or down while scrolling through documents or websites in my 
browser, the PC clock time slows down.


I've been continuously using D4.EXE since a few years after its introduction in 
1995. I've had no issues with it except when a server goes down. I've been 
using 'time.nist.gov' which has been super reliable for years.
73,
Rich - K1HTV

= = =
Hello Chris, Hello Tim

ntp time sync goes like this:

---
your PC sends local time t1 to ntp

time t2 arrived at ntp:
local time t1 + delay client to ntp ( = upload delay) - offset

ntp sends correct time t3

time t4 arrived at PC:
ntp-time t3 + delay ntp to client ( = download delay) + offset

expectation: up/down delay is the same. no jitter!

time t4 is the time to set the correct time at PC

Conclusion: delay for 'up' and 'down' must be the same.
No jitter is allowed on both legs.
---

Had a similar problem like yours using an ADSL line. The ADSL modem
had apparently some hick-ups (?) resulting of delays from time to time.
Using a utility, like Dimension4 seems to be not a good solution in
such case. Dimension4 connects to just one ntp server all the time.

If you having no decodes - dont' force sync etc, check immediately at
https://time.is/ to verify your local PC time. If your time is way
off, try Meinberg software.

Install Meinberg software and all will be good. During setup enter
your regional ntp pool server.
Ntp pool can be found here: https://www.pool.ntp.org/zone/north-america

Meinberg (free) software:
https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable

73's de OE1MWW
Wolfgang


Wednesday, July 25, 2018, 7:04:34 PM, you wrote:


Tim, Mike,

Well this happened again. FT8 just stopped decoding.
I checked and jt9.exe was still running.

I looked at the time and everything appeared OK,
But I hit the sync time function in Dimension 4 and
Everything started working again.

So even through you can’t see it, this is apparently a time sync issue.

It is a new Dell 6400, Windows 10 and I am running the Dimension 4 v5.31 sync 
software.
A manual sync appeared to fix everything.

Thanks for all the support.
This is a great product, please keep up the fantastic work !

Chris - N3PLM

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


[wsjt-devel] WSJT-X sync

2018-07-26 Thread Rich - K1HTV
Chris,
Sounds like you will need to set D4.exe to sync more frequently. My old PC 
clock was so bad that I had to re-sync every 5 minutes. GL.


73,
Rich - K1HTV

= = =

Tim, Mike,

 

Well this happened again. FT8 just stopped decoding.

I checked and jt9.exe was still running.

 

I looked at the time and everything appeared OK,

But I hit the sync time function in Dimension 4 and

Everything started working again.

 

So even through you can’t see it, this is apparently a time sync issue.

 

It is a new Dell 6400, Windows 10 and I am running the Dimension 4 v5.31 sync 
software.

A manual sync appeared to fix everything.

 

Thanks for all the support.

This is a great product, please keep up the fantastic work !

 

Chris - N3PLM

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


[wsjt-devel] Re FT-8 DXpedition Mode

2018-07-03 Thread Rich - K1HTV
Mark,

 All excellent suggestions for the development crew to seriously consider. If 
suggestion #4 is implemented, I'd suggest that an initial Tx tone frequency 
between 1000 and 2000 Hz be randomly generated, rather than a fixed 1900 Hz 
tone.


I've had excellent luck working KH1/KH7Z using transmit tones above 3600 Hz. I 
was able to work them on  FT8 with 75 Watts and an A3S tribander on 20M and 
wire antennas on 30M & 40M.


On a separate topic, on the HF bands, many of 13 Colonies special event 
stations have been using the FT8 mode. Worked all 13 States, 8 of the QSOs 
while using FT8.


73,

Rich - K1HTV


= = =

   


[wsjt-devel] FT-8 DXpedition Mode

m.we...@yahoo.com https://connect.xfinity.com/appsuite/#

To  wsjt-devel@lists.sourceforge.net https://connect.xfinity.com/appsuite/#  

* Delete
* Actions https://connect.xfinity.com/appsuite/#

Hello WSJT-X developers….

This not a bug report.  I’m sending this email to share a couple of thoughts 
that might enhance the already fine program.

DXpedition Mode

It is apparent to me that many hams have difficulty in understanding the 
settings changes that must be implemented in order to use this mode.  (Witness 
the KH1 DXpedition.)

Perhaps the addition of tabs or icons on the main data screen would help.  One 
such tab or icon could bear the title “Enter DXpedition Mode” and a second one 
could be entitled “Exit DXpedition Mode.”

When clicking on the DXpedition Mode, the following could occur:

1. “Hound” function would automatically be enabled,
2. A pop-up window would require the user to supply the DXpedition’s call and 
grid square,
3. The Rx field would automatically be set to 300Hz,
4. A pop-up would appear to alert the user to view the waterfall to select a Tx 
frequency above 1,000Hz.  If less than 1,000Hz is entered, the entry would be 
rejected and a bold message would alert the user to use an acceptable Tx 
frequency.  Perhaps a default of, say, 1,900Hz could be provided by the program.

When “Exit DXpedition Mode” is clicked, all of the WSJT-X settings would 
automatically be restored to the normal FT-8 options.

Location of adif log file

I regularly import wsjtx_log.adi into my DX4WIN log.  I would like to be able 
to select the computer directory into which the wsjt-x adif log file is to be 
saved.  Perhaps the program could cause the log entries to be saved at the 
default location and concurrently at the location I specify.

Thank you for spending the time to read this email.

73 & keep up the great work.

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


Re: [wsjt-devel] FT8: Three extra bits are available

2018-06-14 Thread Rich - K1HTV
Joe,

  I would hope that the enhanced 75-bit message structure will allow for the 
Tx3 and Tx4 messages to contain all of the 0-9 and A-Z characters. This would 
allow FT8 to be used in a number of other operating events & contests such as 
State QSO parties and Field Day exercises.  


Can we assume that WSJT-X would NOT include the capability of inserting an 
incrementing contest number? If that is the case, there needs to be a way for 
an operator who has a station answering his CQ, to quickly insert  of the 
contest exchange in the Tx3 message. It would be helpful if WSJT-X could insert 
a fixed string variable such as 3A MDC for Field day, a 2 character State 
abbreviation, or a 3 or 4 character county abbreviation. This should be 
followed by a space, with the cursor placed after the space. This would allow 
for the user to quickly type in any additional data, such as a contest number, 
after it. The station answering a CQ would have a little more time to insert 
any additional contest data, such as a contest number, after the fixed format 
part of the contest exchange in standard Tx4 message. If things are too tight, 
the space could be eliminated.


If the above capability could be added, FT8 could be incorporated in many 
worldwide contest events.


73,

Rich - K1HTV


= = =


On Fri, Jul 28, 2017 at 8:49 PM, Joe Taylormailto:j...@princeton.edu >wrote:

> Hi Palle (and other VHF+ contest enthusiasts in IARU Regioin 1),
> 
> Thanks for the suggestions you posted to wsjt-devel concerning VHF+ 
> contest exchanges in EU.
> 
> I have been sketching out some possible enhanced 75-bit message 
> structures for FT8 mode aimed (among other things) at supporting your Region 
> 1 contests.
> 
> I would appreciate your comments on the following model contest QSO 
> structure based roughly on common HF contest practices:
> 
> 1. CQ G4ABC IO91
> 2.G4ABC PA9XYZ JO22
> 3. PA9XYZ 590003 IO91NP
> 4.G4ABC R 570007 JO22DB
> 5. PA9XYZ G4ABC RR73
> 
> The 4-character locators in messages 1 and 2 are redundant (and anyway 
> optional).  But they cost nothing to include, and they do provide some useful 
> initial information.
> 
> The first two digits of the exchanges in messages 3 and 4 are an "RS" 
> signal report.  Because of the strong forward error correction in FT8, the 
> first digit will always be "5".  The second digit would be the FT8 S/N 
> reading mapped onto a S1 to S9 scale, using 6 dB per S unit. Something like 
> S1=-24, S2=-18, ... S9=+24 dB.
> 
> Is this an acceptable format for your Region 1 contest exchanges?  Do you 
> think FT8 might be a popular mode for some use in EU VHF+ contests?
> 
> -- 73, Joe, K1JT
> 

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


[wsjt-devel] Decouple Contest checkbox?

2018-06-12 Thread Rich - K1HTV
Is there any reason why the WSJT-X "NA VHF Contest" checkbox cannot be 
decoupled from the "Enable VHF/UHF/Microwave Features" check box under the 
"General" settings tab? One of the most frequent questions asked on contest 
club reflectors, prior to and during the recent ARRL VHF Contest, related to 
how to find the "NA VHF Contest" box.


If that check box is always available on the main screen, when an alert message 
about having to be in the VHF Contest mode pops up, it would be less 
complicated for all to activate it. This is especially important for the newer 
or more casual FT8 ops who haven't yet read the manual.


A number of post-VHF contest emails, specifically mentioned the problem of 
trying to complete contest QSOs with casual FT8 ops who called w/o activating 
the "NA VHF Contest" box, which probably didn't even appear on their main 
WSJT-X screen. 


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


Re: [wsjt-devel] working stations over 10000 km on 6m (Ned)

2018-05-31 Thread Rich - K1HTV
Ned & Jim,
Using WSJT-X V 1.9.1 v8747, to activate the "NA VHF Contest" check box hit F2 
(File/Settings) and
click the 'General' tab. check the "Enable VHF/UHF/Microwave" features" box. 
After you click 'OK',
the "NA VHF Contest" box will appear on the main WSJT-X screen under the 'Hold 
Tx Freq' check box.


Jim, K9YC, nice to work you last night on 6M double hop. Lots of W6/W7 
stations. If you want to see what I'm decoding on 6M and other HF bands you can 
connect to 'k1htv.to.us:7373".  I'm using a Redpitaya that son Andy, K1RA, gave 
me for my birthday, as an 8 band FT8 skimmer.


73,

Rich - K1HTV

= = =

On 5/30/2018 6:30 PM, Ned wrote:
This happened to me at the most inopportune time. I was sending a signal
report to DS4AOW for a ATNO on 6m and it sent a NA Contest TX3 exchange
instead of what was expected. The only way I could clear the problem was
to change the mode to to anything other than FT8 and then back to get
the right TX3 message. While I was sorting that all out, the band faded
and I did not complete.

It's rare to hear stations over 10 KM, so this is a hard thing to test.


- --
Yes, this needs to get fixed. I ran into it tonight when an east coast
station called me and and gave me an NF grid. To deal with my neck
posture issues, I run WSJT-X on an extension screen above my laptop, and
the NA contest exchange query showed up on the laptop screen. It took
several cycles before I even noticed it. He kept calling me, I kept
trying to respond. We also lost the QSO. I had to kill First Call and
ignore him.

FWIW -- I t doesn't happen often, but I have almost a dozen 6M Qs
greater than 10,000 km (SA, VK, ZL, FK, other OC), mostly CW, a few
JT65, all short transequatorial openings.

The fix could be something as simple as not requiring that the operator
acknowledge the message.

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


[wsjt-devel] Stations with bad clocks

2018-05-15 Thread Rich - K1HTV
Notifying a station whose timing is at the edge of decoding limits is 
problematic because once his timing slips past the max tolerable limit, no 
helpful messages about his clock will be decoded by the station you are trying 
to alert.


If WSJT-X had a rubber clock feature which would temporarily speed up or slow 
down the computer clock by a number of seconds, then a message could be sent 
and decoded by those whose with  inaccurate clocks. 


73,

Rich - K1HTV


= = =

PA5Y wrote:


This would be quite useful based on my recent observations on 6m. We all
suffer when someone inadvertently transmits across two periods. I have
on occasion sent something like

PA0XX CLOCK or indeed DL0XX, ON0XX and G0XXX of course 😊
It normally works but it feels wrong because the station does not know
who the message is from. I don't like doing it and it really is a last
resort. Other problem is TX distortion/overmodulation/wide signals.

Messages to cover that would be useful, after all no one want to radiate
a bad signal or cause unnecessary interference do they? We need a better
expression than PA0XX WIDE, it seems too confrontational.

I do hope that when conditions on 6m get even better that alternative
frequencies are used.

73

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


Re: [wsjt-devel] WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode

2018-03-29 Thread Rich - K1HTV
Being a 160M CW DXer, I too agree that 1826.5 is NOT a good spot for the FT8 
DXpedition frequency, as many other Topband DXers would also agree. The highest 
end of the band has plenty of room, but many antennas, cut for the low end of 
the band, won't load well up there. 

Although the 1836.6 KHz WSPR frequency has a number of users, with the advent 
of FT8, very few, if any, JT65 stations can be heard around 1838. Maybe that 
would be a better place for the DXpedition mode on 160 Meters.

If not there, then 1830 to 1835 KHz, considered the Topband 'DX window', would 
probably work, as CW ops could slide down a few KHz without to many problems. 
Of course, during contests, don't expect any frequency on the band to be free 
from QRM.


73,

Rich - K1HTV


= = =

KA9CFD wrote:


Is the suggested Dxpedition frequency 1.8265 a typo? That would put it right in 
the middle of the CW DX window on 160m. Surely a frequency of 1.836 would be a 
better choice IMHO.

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


[wsjt-devel] Alternative FT8 DXpedition mode freqs.

2018-03-27 Thread Rich - K1HTV

With all of the discussion about the QRM to 40 Meter PSK users from 7Q7EI's use 
of the FT8 DXpedition mode, it is now time to take a serious look at 
alternative DXpedition frequencies.


IARU Regions 1, 2 & 3 already have drawn up 'Bandplan Recommendations'. You can 
read about their 40 Meter recommendations at:
https://en.wikipedia.org/wiki/40-meter_band#Band_plans


Recommendations for the use of 'DATA' modes are:
Region #1 - 7040-7060 plus 7060-7200
Region #2 - 7040-7050 plus 7050-7300
Region #3 - 7025-7040 (appears to be the most restrictive, although many R#3 
Pacific stations use 7074 for FT8)


Also mentioned are:
Japan - 7025-7030 plus 7030-7300
USA - 7025-7125
Canada - 7035-7050 (but we know that VE's use 7070 and above for the various 
digital modes)


As I listen in the evening to hundreds of FT8 stations on 7074 KHz, using the 
main and Beverage antennas, I hear very few, if any, signals just above 7080 
KHz.  I know that during the dozen of so weekends when RTTY contests are 
scheduled, these frequencies (+/- tens of KHz) are full of RTTY stations. But 
during non-contest times, these frequencies are virtual empty. The same can be 
said about 20 Meters and frequencies just above 14.080 KHz and 15 Meters just 
above 21.080 KHz. .


My suggestion would be, if possible, to have WSJT-X software inhibit the use of 
the already defined standard FT8 HF operating frequencies whenever the 'Fox' 
box is checked. In addition, notify the 'Fox' via a message box to use 
alternate recommended DXpedition mode frequencies from the band pull down menu.


The WSJT-X Development Group selected the FT8 frequencies now being used by 
all. I believe that after serious consideration, they should define a 
recommended DXpedition mode frequencies for each HF band.  I'd further 
recommend that the 'Frequencies' table be populated with these recommended 
DXpedition mode frequencies. Even better, whenever the 'Fox' box is checked, 
display ONLY the recommended DXpedition mode frequencies' in the band pull down 
menu.


Comments and discussion?

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


[wsjt-devel] FT8 for 2018 Field Day

2018-03-27 Thread Rich - K1HTV
FT8 for 2018 Field Day

Regarding the use of FT8 on Field Day, you can do what I did during the recent 
VA QSO Party, that is, use the Tx5 (73) message to send contest data. The VQP 
exchange sent was number, county & State, "nnn CUL VA 73", where 'nnn' was my 
QSO number and 'CUL' was the abbreviation for Culpeper county. The 'VA' for 
Virginia was not a contest exchange  requirement. The Tx5 message met the 13 
character maximum and ended with '73', which trigger the '73' message of the 
station being worked. I created a Tx5 macro message "000 CUL VA 73". When a QSO 
started, I simply pulled down that macro message and manually changed the 000 
to the next number in the sequence.


Unfortunately almost no FT8 stations worked in the VA QSO Party knew how to 
send the required data. As a result I focused mainly on working DX on FT8, 
where the only a number (dB report) was required. 285 of the 287 VA QSO Party 
QSOs were with DX stations.


If a future WSJT-X release could have a check box for ""Lock Tx5 message", that 
would allow the easier use of FT8 in various contests, such as Field Day and 
State QSO parties. Once the 'Lock' box was checked, the user would type in the 
fixed contest exchange text into the Tx5 message box. It would remain there 
until the contest was over and not be overwritten when a new station was being 
worked.


Sponsors would have to explain, in their rules, how to use FT8 in their 
contest. The Field day exchange wouldn't  present any problem. However, those 
State QSO parties that presently requiring sequential QSO number exchanges 
could switch to using the dB report as the numbers exchanged.


73,
Rich - K1HTV


= = =

Jordan Sherer, KN4CRD wrote:

At that very least you can use a free text message for the exchange, Don: 
"KN4CRD 1B GA"

You just won't be able to use auto sequencing when operating FT8 during field 
day.

Best,
Jordan
KN4CRD

On Mar 27, 2018, 7:40 AM -0400, Don Goldston , wrote:
Any chance that an FT8 mode that performs the required exchange of information 
for the 2018 Field Day could be
created?

I know y'all are wrapped up in DXP mode, but thought it was worth asking.

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


[wsjt-devel] FT8 TX2 response Bug?

2018-03-26 Thread Rich - K1HTV
TX2 bug response in v1.9.0-rc3


At times, multiple callers answer my CQs. The decoded red lines from both 
callers appear as expected, in both the 'Band Activity' and 'RxFrequency' 
columns. After working the first station, if the next station I want to work is 
sending me a Tx2 message (Calls & Report), when I double click on his call in 
the 'RXFrequency' column, instead of my sending a TX3 message, my automatic 
response is an incorrect TX2 message.


If on the other hand I double click on the same station callsign in the 'Band 
Activity' column, I start sending the correct TX3 message.


A Bug?


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


Re: [wsjt-devel] New FT8 Frequencies?

2018-03-24 Thread Rich - K1HTV
OK Gary,

  You've got the job. :-) When will the report be ready. Then what's next? It 
doesn't take a rocket scientist to see where the number of FT8 users is 
goingUP, UP, UP!!!FT8 use will continue to expand and with it, the need 
for additional frequencies. Although it appears that you have doubts, I have no 
doubt that more frequencies will soon, if not already, be needed on some bands.


73,

Rich - K1HTV


= = =

[wsjt-devel] New FT8 Frequencies?

g...@isect.com https://connect.xfinity.com/appsuite/#

To  WSJT software development https://connect.xfinity.com/appsuite/#

A ‘separate small group’ wasn’t exactly my proposal, Take: I simply suggested 
that rather than simplyassumingorassertingthat there is an issue with 
overcrowding and pushing for something to be done, we should take a more 
scientific approach. 

What would help address the claim(hypothesis)that the HF FT8 allocations are 
“overcrowded”?   

For example, we could systematically collect, collate and analyze our ALL.TXT 
files for things such as:

* How many stations are using FT8 on each of the HF bands
* The proportion of FT8 overs that are repeats of previous overs, suggesting 
communications failures due to factors such as QRM, QRN, QSB etc.
* Trends i.e. how these factors vary over time

73

Gary  ZL2iFB

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


[wsjt-devel] New FT8 Frequencies?

2018-03-22 Thread Rich - K1HTV
As we all know, when bands are open, it is not unusual to find the standard FT8 
frequencies packed, end-to-end with stations. The waterfall is full of dozens 
of QSOs and many more dozens of stations calling others. There is no doubt that 
with the super success of the FT8 mode, it is imperative that additional 
frequency “Channels” within each HF band be identified for not only the new 
DXpedition mode, but more importantly for normal day to day FT8 operations. 
Although the number of JT65 users has greatly dwindled, there are still many of 
them using the mode on HF, so these frequencies and their JT65 users should be 
left alone.


The same holds for PSK31 and its army of Hams who like its rag chew 
capabilities that the FT8 and JT65 modes can’t provide. Then there is, on a 
normal weekday, a vast wasteland of the 14.080 to 14.099 RTTY band. When you 
tune across that frequency range during the week, rarely do you hear more than 
a few RTTY signals, while at the same time, packed into 2 KHz, many dozens of 
FT8 stations can be heard working each other. The only times that the RTTY band 
comes alive is during weekend RTTY contests and during DXpeditions to countries 
that RTTY users need to work for digital DXCC. DXpeditions usually operate 
around the upper 10 KHz of the RTTY frequencies. There are around a dozen major 
RTTY contests spaced throughout the year, all scheduled over weekend days.


A proposal needs to be made to the community of RTTY operators, most of whom 
probably already use FT8, to see if there would be a serious problem if some of 
the present RTTY frequencies could be shared with FT8. These might consist of 
the 4 KHz at the low end of each of the presently used HF RTTY bands. Floating 
the idea on the ‘rttycontesting.com’website would be a good place to start.


The frequencies above the NCDXF HF beacons flagged for digital use, but as 
‘Packet’ where you probably will find Winlink transmissions, so those 
frequencies probably should be left alone.


Of course, the final additional FT8 frequencies chosen must adhere to Regions 
1, 2 & 3 band plans.


So, where do we start? Time is flying by and the number of FT8 users are 
quickly growing.


Comments?

73,

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


Re: [wsjt-devel] Split FT8 QSY bug?

2018-03-15 Thread Rich - K1HTV
If at all possible, I'd recommend that a 4-digit (160 thru 40M) or 5-digit (30M 
thru 6M) number in a CQ text message be interpreted as the frequency to set 
VFO-B. It is harder to misinterpret an exact frequency, especially once the 
DXpedition mode starts being used and DX stations use Rx frequencies well above 
(or below) their Tx frequency. 


73,

Rich - K1HTV


= = =


OK...so it added the 1st 3 digits as 190kHz to 1MHz to come up with 1.190


So what do we want to do with a 4 or 5 digit QSY like this?


#1 Ignore it?

#2 Change to it and handle it differently than the 3-digit QSY?


de Mike W9MDB




On Thursday, March 15, 2018, 9:59:33 AM CDT, Rich - K1HTV mailto:k1...@comcast.net > wrote:


Mike, yes a QSY message was seen:

>From the Band Activity window:

--- 160m

112315 10 0.2 700 ~ CQ N9MB EN70   K

112315 4 1.4 864 ~ CQ WB9JOX EN61   K

112315 -18 0.7 1957 ~ CQ 1908 H40YM  !where?



>From the Rx Frequency window:

(I clicked on the above CQ message, with this message. The K3  VFO-B switched 
to 1190 KHz)

 

112331 QSY 1.190

112337 Tx 2131 ~ H40YM K1HTV FM18

112400 Tx 2131 ~ H40YM K1HTV FM18

112441 QSY 1.190   (I had clicked again on the above CQ line)

112701 QSY 1.190 (and again, with the same QSY to the frequency that WSJT-X 
instructed to it to do )

112830 Tx 2131 ~ H40YM K1HTV FM18

 

A 190 KHz movement would have moved the frequency from 1840 to 2030 KHz, if 
added, or 1650 KHz, if subtracted. So that's not the answer. Haven't yet tried 
to replicate the problem with another local FT8 user.

73,

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


Re: [wsjt-devel] Split FT8 QSY bug?

2018-03-15 Thread Rich - K1HTV
Mike, yes a QSY message was seen:


>From the Band Activity window:

--- 160m

112315 10 0.2 700 ~ CQ N9MB EN70   K

112315 4 1.4 864 ~ CQ WB9JOX EN61   K

112315 -18 0.7 1957 ~ CQ 1908 H40YM  !where?




>From the Rx Frequency window:

(I clicked on the above CQ message, with this message. The K3  VFO-B switched 
to 1190 KHz)

 

112331 QSY 1.190

112337 Tx 2131 ~ H40YM K1HTV FM18

112400 Tx 2131 ~ H40YM K1HTV FM18

112441 QSY 1.190   (I had clicked again on the above CQ line)

112701 QSY 1.190 (and again, with the same QSY to the frequency that WSJT-X 
instructed to it to do )

112830 Tx 2131 ~ H40YM K1HTV FM18

 


A 190 KHz movement would have moved the frequency from 1840 to 2030 KHz, if 
added, or 1650 KHz, if subtracted. So that's not the answer. Haven't yet tried 
to replicate the problem with another local FT8 user.


73,

Rich - K1HTV

= = =

[wsjt-devel] Split FT8 QSY bug?

Black Michael https://connect.xfinity.com/appsuite/#
To  WSJT https://connect.xfinity.com/appsuite/#  
* Delete
* Actions https://connect.xfinity.com/appsuite/#

That's almost a QSY request but that format is expecting a 3-digit frequency so 
would've thought you'd see a 190kHz movement


Did you see a QSY message in your Rx window?


de Mike W9MDB

On Thursday, March 15, 2018, 6:49:15 AM CDT, Rich - K1HTV mailto:k1...@comcast.net > wrote:


This morning, a few minutes before local sunrise,  H40YM showed up on 160 Meter 
FT8 on 1840 KHz calling "CQ 1908 H40YM". He was listening up the band in the 
160M Japan operating area frequency window. Wanting to to work the H40 split, I 
temporarily set the WSJT-X File/Settings/Radio/ "Split Operations" to 'None', 
but left my K3 in the SPLIT mode.

But, when clicked on the "CQ 1908 H40YM", instead of moving VF0-B to 1908 KHz, 
it was moved instead to 1190 KHz.  I tried a number of times but each time 
VFO-B was moved to the broadcast band frequency of 1190 KHz instead of 1908 
KHz. By the time manually set VFO-B to 1908 MHz, H40YM disappeared into the 
noise.

Might there be some kind of software bug in the v1.9.0-rc2 software causing the 
wrong split frequency to be set in VFO-B ?

73,

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


[wsjt-devel] Split FT8 QSY bug?

2018-03-15 Thread Rich - K1HTV
This morning, a few minutes before local sunrise,  H40YM showed up on 160 Meter 
FT8 on 1840 KHz calling "CQ 1908 H40YM". He was listening up the band in the 
160M Japan operating area frequency window. Wanting to to work the H40 split, I 
temporarily set the WSJT-X File/Settings/Radio/ "Split Operations" to 'None', 
but left my K3 in the SPLIT mode.


But, when clicked on the "CQ 1908 H40YM", instead of moving VF0-B to 1908 KHz, 
it was moved instead to 1190 KHz.  I tried a number of times but each time 
VFO-B was moved to the broadcast band frequency of 1190 KHz instead of 1908 
KHz. By the time manually set VFO-B to 1908 MHz, H40YM disappeared into the 
noise.


Might there be some kind of software bug in the v1.9.0-rc2 software causing the 
wrong split frequency to be set in VFO-B ?


73,

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


Re: [wsjt-devel] Guantanemo Bay callsigns

2018-03-13 Thread Rich - K1HTV
Yes Bill, I saw that but only the single suffix KG4 call was mentioned. Just 
wanted to make sure that the KG4xxx triple suffixes were also included.

Thanks for all you continue to do to improve the already great WSJT-X FT8 
software. Worked 3D2EU on Routma and H40YM on 60M at this morning's sunrise for 
my FT8 DXCC countries #207 & 208 with 75W or less..

FT8 is GREAT!

73,
Rich - K1HTV


> On March 13, 2018 at 11:23 AM Bill Somerville  wrote:
> 
> On 13/03/2018 15:19, Rich - K1HTV wrote:
> 
> > > 
> > Bill,
> > 
> >   Not only KG4x but also KG4xxx calls need to identified as USA and 
> > NOT Guantanamo Bay call signs. Only KG4 callsigns with a 2 letter suffix 
> > should be identified as the Guantanamo Bay DXCC entity. Presently KG4x or 
> > KG4xxx callsign show up as USA as they should, but are highlighted in 
> > purple.
> > 
> > 
> > 73,
> > 
> > Rich - K1HTV
> > 
> > > 
> Hi Rich,
> 
> this has been fixed for the next release as mentioned as recently as 
> yesterday:
> 
> https://sourceforge.net/p/wsjt/mailman/message/36259588/
> 
> 73
> Bill
> G4WJS.
> 
 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Guantanemo Bay callsigns

2018-03-13 Thread Rich - K1HTV

Bill,  Not only KG4x but also KG4xxx calls need to identified as USA and NOT Guantanamo Bay call signs. Only KG4 callsigns with a 2 letter suffix should be identified as the Guantanamo Bay DXCC entity. Presently KG4x or KG4xxx callsign show up as USA as they should, but are highlighted in purple.73,Rich - K1HTV
 

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


Re: [wsjt-devel] Public test of FT8 DXpedition mode March 6-7

2018-03-07 Thread Rich - K1HTV
While on 20M FT8 a few days ago I saw 5B4AIF and called him. It appeared that 
he was using the DXpedition mode (N=1). While sending a RR73 message to one 
station, it was followed by a semicolon and my call and report. I had called 
the 5B4, hundreds of Hertz higher in frequency. When he answered my call, I 
received an alert message about having to be in the DXpedition mode. I did NOT 
enter the Fox/Hound mode, nor did I manually move lower in frequency, as the 
mode would do automatically. I continued calling the 5B4, but he never 
responded. I wonder If I had manually moved my frequency closer to him if the 
QSO would continue. Probably not, because the magic "byte" was not set, right?


See you all Tuesday EST for the FT8 DXpedition mode test pileups. I'm sure that 
they will be big!


73,

Rich - K1HTV 


= = =

To  WSJT software development https://connect.xfinity.com/appsuite/#  
* Delete
* Actions https://connect.xfinity.com/appsuite/#

I’m curious to know what will happen when someone wanders into these tests, 
without RC2, and tries to send one of the messages not used in these 
abbreviated sequences.  Will those callers be ignored?

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


[wsjt-devel] DXpedition mode test results

2018-03-06 Thread Rich - K1HTV
As expected, propagation from K1JT in NJ to K1HTV in VA on 20M was marginal. It 
took a skewed path beam heading towards SA to produce a report from Joe, but no 
complete QSO was made on 20M. QRM from XE1GK on 14080.250 didn't help. On 30 
Meters, signals from Don, N1DG, as W1/KH7Z, started OK but the skip quickly 
lengthened and again XE1GK was on the bottom end of 10141 KHz, again causing 
QRM during the test, calling CQ and working stations. 


The 01Z 40 Meter test went better on this end with quick QSOs using K1HTV, 
K1WSN (XYL's call) and KW4VA (Jr. Op K1RA trustee of club call). 


Using the KW4VA call, after exchanging reports with W7/KH7Z at 0105Z , the Fox 
proceeded to send "RR73" reports at 0115Z, 011630Z, 011730Z,101830Z, 0120Z and 
0125Z before the "RR73" messages finally stopped. Others reported same, so it 
looks like some debugging needs to be done.


80M signals from K9AN were great. When I stood by at times to listen during the 
02-03Z hour, I copied over 40 Hounds simultaneously calling Bill. 


One thing  noted was that there were long delays in completing QSOs. It 
appeared that as the Fox worked Hounds, either sending calls and reports or 
sending "RR73" messages, the Fox's cue of stations being worked got longer. As 
a result, the number of Hounds transmitting their  "R-xx" reports to the Fox in 
the transmit range below 1000 Hz started to cause a log jam. The result is that 
the stations in the cue appear to be causing QRM to each other. To prove this 
theory, after starting a K1HTV QSO with K9AN and sending reports for 13 minutes 
without receiving a 'RR73", I decided to try something.  I stopped transmitting 
and to look for a quiet spot and found one at 450 Hz and moved there. One call 
on that quiet frequency and I received a "RR73" message to complete the QSO!


So, what is needed? More Fox TX streams? How about a higher priority be given 
to completing QSOs before starting more QSOs, thus reducing the number of 
repeat "R-xx" reports of Hound and the resulting QRM to each other in the 
frequency tone range below 1000 Hz.


The QSO rates made in this public test are truly impressive. Congrats to the 
entire WSJT-X team for a great job done. Looks like a little more debugging and 
tweaking needs to be done, but it looks like the FT8 DXpedition mode is almost 
ready for prime time!


73,

Rich - K1HTV


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


Re: [wsjt-devel] Repeating after QSO succeeds

2018-01-04 Thread Rich - K1HTV

Gil,What you are experiencing is what happens if you are using an older version of WSJT-X and working a station running the current version and  sends the RR73 as the TX4 message. Instead of answering with a TX5 '73' message, with the older version, you go back to sending the TX2 message. What version are you using? Check by selecting 'Help' on the tool bar then 'About WSJT-X'. If you are NOT presently using WSJT-X version "1.8.0 r8193", you can download the latest Windows, Linux & Mac OS one at:https://physics.princeton.edu/pulsar/k1jt/wsjtx.html73,Rich - K1HTVMessage: 1Date: Thu, 4 Jan 2018 16:10:42 -0600From: "Gilbert Baron" To: "'WSJT software development'" ,"'WSJT Group'" Subject: [wsjt-devel] Repeating after QSO succeedsMessage-ID: <021a01d385a8$dd231460$97693d20$@gmail.com 021a01d385a8$dd231460$97693d20$@gmail.com >Content-Type: text/plain; charset="utf-8"I am getting some sort of QSO looping. After any QSO is confirmed with the RRR the program stars all over again as if I just double clicked on a QSO in the monitoring window. I am sure people are not happy with me doing that ?_I certainly want to stop that happening.I am attaching an example.One good thing though, I did get JTALERT to DXKeeper working although every time it sends a message that it is not able to be sure it actually logged it. It has logged it. It shows in the log with no problem, even did the QRZ lookup. Maybe that is the problem because I do not have a QRZ account, just using the free lookup for now. I may sign up since I am getting back into radio with this JT and MWA contest group and my new FT590SG ? I do not have it set to log automatically to DXKEEPER, it waits until I click Log This QSO. I may change that after I buy a QRZ account again.Outlook Desktop Gil W0MN
 

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


Re: [wsjt-devel] Another Compound Callsign Problem

2017-12-04 Thread Rich - K1HTV
A caution to those of us who often bypass the TX1 message (calls & grid) and 
start with TX2 (Calls and report). When calling a DX station with a complex 
callsign, when the DX station responds, none of the messages in his transmitted 
sequences will have YOUR callsign in them. There is no way to know for sure 
that the DX station is responding to you or another station. 

The fix, when calling stations with complex callsigns, is to start with the TX1 
message.

Another note, when using the alternate TX4 (RR73) message, if after you send 
your "RR73" message the station you are working responds with a TX2 (calls and 
report) instead of a TX5 (73) message, that indicates that the station is 
probably using an older version of WSJT-X. I've sent out numerous emails to 
those who have responded that way when I worked them and almost all have 
responded, confirming that they were using an older version. 

73,
Rich - K1HTV
196 DXCC worked, 156 confirmed with 75W - FT8 is GREAT!

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


Re: [wsjt-devel] Call change while logging

2017-11-26 Thread Rich - K1HTV
Mike & Mike,
I agree, that it would be a good idea to inhibit the changing of the data of 
the station just worked until AFTER the logging has been completed and the log 
box has been closed. Although the call sign being logged does not change, some 
of the data does change to that of the newer station. I use DX Lab Suite's 
DXKeeper for logging. Too many times, before I get a chance to click "OK" in 
the WSJT-X log box, the next calling station's data gets embedded in the log 
data (country, continent, WPX prefix, report, etc.) for the previously station 
worked, but not yet logged. That throws log errors requiring editing the data 
in the DXKeeper log. 

Disabling the changing of the DX call while the logging box is open would 
prevent the problems now being experienced for those that don't act fast enough 
to log the previous QSO.

73,
Rich - K1HTV  
= = =
Date: Sat, 25 Nov 2017 13:17:13 + (UTC)
From: Black Michael 
To: WSJT Software Development 
Subject: [wsjt-devel] Call change while logging
Message-ID: <150424686.2916460.1511615833...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

There's a problem logging with JTAlert (and perhaps other apps too) if you 
leave the logging dialog box open and change the active call sign.
JTAlert maintains the additional logging info by the active call signlike 
countryso you may end up logging the wrong country.
There's a potential fix for WSJT-X that's not too oneroussimply disalow 
changing the DX Call while the logging box is open...simply disable it (to make 
it obvious) and reenable after logging.
I'll be happy to make that patch if deemed appropriate.
de Mike W9MDB

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


Re: [wsjt-devel] Problem with standard message generation

2017-11-21 Thread Rich - K1HTV
Scott,
Have you tried using the F4 key to clear the current QSO messages then click on 
the new station call that you want to work?

73,
Rich - K1HTV

sc...@bidstrup.com

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


Re: [wsjt-devel] WSJT Development Team Honored

2017-11-09 Thread Rich - K1HTV
Joe,
  Congrats to you and the whole WSJT-X team for receiving this year's Yasme 
Excellence Award. And thanks for acknowledging us folks on the reflector who 
bombarded you with suggestions, corrections, complaints, etc. as the WSJT-X 
software got better and better. 

I'm sure that all involved in its development are pleased to see how widely 
accepted the FT8 mode has become and how well it works. As an example, a few 
evenings ago, on 40 Meters, I worked ZA/IK2RLM in Albania for country #183 
using the FT8 mode. We were both running low power but the amazing thing was 
that his antenna was a magnetic loop on the balcony of his apartment! 

Keep up the good work. We DXers are still waiting to see FT8 decodes from the 
presently active VK9MA DXpedition on Mellish Reef. Were the DXpedition features 
developed in time for them to use?

73,
Rich - K1HTV

= = =


Date: Wed, 8 Nov 2017 15:38:48 -0500
From: Joe Taylor 
To: WSJT software development 
Subject: [wsjt-devel] WSJT Development Team Honored
Message-ID: <4a839ada-c98f-be64-17f9-17bacabe1...@princeton.edu>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi all,

I write to share the good news that the WSJT Development Group has been 
awarded the Yasme Excellence Award for 2017.  A few details can be found 
here:

http://www.yasme.org/yasme-excellence-awards/

http://www.arrl.org/news/yasme-foundation-announces-excellence-awards-and-supporting-grant

The award specifically cites major contributors G4WJS, K9AN, KI7MT, 
W9MDB, PY2SDR, and IV3NWV, as well as K1JT.  But everyone who reads this 
list knows that the team includes many additional members who have 
contributed code, documentation, test reports, and suggestions for 
improvement.

We (the callsigns listed above) have decided to donate the $1000 cash 
award to the ARRL Spectrum Defense Fund.

Congratulations to all, and thanks again for your continued support of 
this project!

-- 73, Joe, K1JT

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


Re: [wsjt-devel] FT8 Call sign anomaly with 3XY4D

2017-10-29 Thread Rich - K1HTV
Hi Joe,
  As I mentioned, I understand what the users manual stated about the format of 
call signs as I also quoted it. However, in the case of the 3XY prefix, it has 
been used for over 18 years. Since 1999 I've made 63 QSOs with stations 
operating in Guinea and 46 of them were assigned the 3XY prefix include 3XD2Z, 
3XM6JR, 3XY2D, 3XY8A, 3XY6A, 3XY7C, 3XY1L, 3XY1D, 3XY0A, 3XY1T, 3XY3D/p and 
today 3XY4D.

I understand the reluctance of making 3XY a special case, but over the years, 
the majority of the assigned calls for Guinea have had the prefix 3X plus 
another letter, a number and 1 to 3 letters. Since the 1980 start of my 
electronic log of 131K+ QSOs, I found a total of only 106 QSOs with such 
formatted prefixes. So unless a general exception can be made for calls of that 
format I guess the DX station stuck with such a call sign and those of us 
calling him will just have to deal with the occasional confusion that will 
occur when such a station call sign shows up.

Since a similar prefix, 3DA0 does not result in this problem, I guess the best 
fix would get the folks who maintain the CTY.DAT database to add "3XY" to the 
existing "3X" valid prefix for Guinea.

Thanks again to you and the WSJT-X development team for a great piece of 
communications software. With 75 Watts, an A3S and wire antennas, as of this 
writing I've made 7823 FT8 QSOs in 176 countries.

FT8 is GREAT!

73,
Rich - K1HTV

= = =
Joe Taylor, K1JT wrote:

The behavior you described is no surprise to anyone who has read the 
definition of what's treated as a standard callsign in any of the slow 
modes in WSJT-X.

See, for example, the original defining document for JT65:
J. Taylor, K1JT, "The JT65 Communications Protocol" (QEX,
September-October 2005, p 3):
http://physics.princeton.edu/pulsar/K1JT/JT65.pdf

... or the WSJT-X User Guide here:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#PROTOCOLS

Relevant text:

"A standard amateur callsign consists of a one- or two-character prefix, 
at least one of which must be a letter, followed by a digit and a suffix 
of one to three letters."

The callsign 3XY4D does not follow this worldwide standard convention. 
For this reason, the messages you showed are all treated as free-text 
messages.

I am sure it is very frustrating for 3XY4D, and also for those trying to 
work him (as I did, yesterday, by using free text messages in FT8).

In principle, we could make a "3XY" an acceptable, three-character 
prefix, as a special case.  Not a very attractive possibility, but...

-- 73, Joe, K1JT

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


[wsjt-devel] FT8 Call sign anomaly with 3XY4D

2017-10-29 Thread Rich - K1HTV
This event anomaly started with me using WSJT-X RC3.

A new FT8 DXCC country popped up today, 3XY4D. When I double clicked on his CQ 
call, it did not populate the message boxes. Thinking that he had manually 
typed in a non-standard format message, I typed "3XY4D" in the 'DX Call' box 
and generated a set of standard messages. So far so good. 

I started calling him but noticed that even though my Tx1 message was set to 
"3XY4D K1HTV FM18" what I was sending him was "3XY4D K1HTV F". So for my next 
transmissions calling him I send the TX2 message "3XY4D K1HTV -10". But that 
message was truncated so what I was sending was "3XY4D K1HTV -" After a number 
of calls he finally answered me but instead of receiving from him a normal 
"K1HTV 3XY4D -nn" report, all I saw was "K1HTV 3X4D -" .

H. Assuming that he was sending some kind of dB report I followed up with 
calls and RRR, But instead of my Tx3 box message "3XY4D K1HTV R-10" my 
transmission to him instead was truncated to "3XY4D K1HTV R". Instead of me 
receiving from him a "K1HTV 3XY4D RRR" all I received was "K1HTV 3XY4D R". I 
sent Tx5 message "3XY4D K1HTV 73" and what came out was "3XY4D K1HTV 7". 

After completing the QSO with 3XY4D, country #176 with 75W, I thought I'd 
restart WSJT-X RC3. After I did I noticed that he was still sending CQ. When I 
double clicked on his CQ line, I still couldn't populate the message boxes. 
Also noticed 3XY4D working others, also with truncated messages, but the 
messages varied in length, depending on the number of characters in the call 
sign of the station he was working.

OK, thought I'd better download the latest WSJT-X development build and did so. 
Using "WSJT-X v1.7-develop r8195", I ran the same tests with the same results. 
Then I replaced the "3XY4D" call with the same format call "3DA4D" (Swaziland) 
and ran tests of my generating and sending messages with the K3 in the TEST 
mode and everything came out normal.

Next I simulated using "3XY4D" in Settings/General "My Call" and ran more 
tests. Here is what I found while simulating 3XY4D as my call. When I clicked 
on a station calling CQ, all of the standard message boxes were correctly 
populated. But... when I made simulated transmissions using 3XY4D as my call 
sign, the actual messages being send varied, depending on the length of the 
call sign of the other station.

Using the TX6 CQ message "call 3XY4D IJ39":
A 3 character call resulted in "call 3XY4D IJ3" being transmitted.
A 4 character call resulted in "call 3XY4D IJ" 
A 5 character call resulted in "call 3XY4D I"
A 6 character call resulted in "call 3XY4D "

It appears that any "3XY" callsign being used is treated as a non standard call 
and is limited to the 13 character maximum limit. 

The Users Guide states "A standard amateur callsign consists of a one- or 
two-character prefix, at least one of which must be a letter, followed by a 
digit and a suffix of one to three letters." Looks like the prefix length needs 
to be expanded to include the 3-character prefix "3XY". The CTY.DAT file only 
has "3X" and not "3XY" as the prefix for Guinea so all WSJT-X users will be 
affected.

So it looks like for now, Luc Jean Pierre THIBAUDAT, 3XY4D, and all "3XY" 
stations appear to be victims of the reported problem.

73,
Rich - K1HTV

cc:3XY4D

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


Re: [wsjt-devel] Double-click Band Activity responses

2017-09-28 Thread Rich - K1HTV
Joe,
  I downloaded and was using r8134 this afternoon and it works fine, as 
described, with no problems. I really like your idea of replacing the Tx=Rx 
with the 'Lock Tx Freq' option. If this option is included in the next release, 
the benefits of running split over simplex operation should be strongly 
emphasized in the documentation. 

I believe that the approach of a user locking his TX frequency to the quiet 
spot that he picked should greatly reduce the on-frequency pileups that are 
presently occurring. It has been frustrating to call CQ and have multiple 
callers but no decodes. One trick I have done is to Shift-click up or down 50 
to 100 Hz. Some times at least one of the callers, with their Tx=Rx checked, 
will follow me. Then I can copy at least one of the callers. 

I was on 40M this morning and around 1150Z and decoded 4S7AB in the middle of 
the band. I quickly Shift-clicked on 2200+ Hz to run split and gave him a call. 
I almost fell off my chair when he responded to my call. A quick set of 
exchanges and Sri Lanka was in the K1HTV log for FT8 DXCC country #147. I was 
running 75W to a ZS6BKW (modified G5RV) antenna at 65 ft and the K3 at 75W. He 
was on solar power and using a 2 element 40M quad. Also snagged XT2AT on 60M 
FT8 yesterday. You might want to add 5357 KHz to the FT8 frequency list, as 
that seems to be the channel that FT8 and some JT65 is being worked at least in 
NA, Europe and by the Africans that I've seen on 60M FT8.

Thanks again to you and the WSJT-X Team for all the work done to develop and 
improve the new FT8 mode.

As I've said before, FT8 is GREAT!

73,
Rich - K1HTV

= = =


> On September 28, 2017 at 11:14 AM Joe Taylor  wrote:
> 
> 
> Hi Rich,
> 
> Now that SourceForge seems to have fixed their problems, please build 
> and test WSJT-X r8131 (or later) from the development branch and let me 
> know how you like the Tx Freq behavior.
> 
>   -- Joe, K1JT

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


[wsjt-devel] Same freq moves = QRM!

2017-09-26 Thread Rich - K1HTV
Ed,
How does every caller moving to the TX frequency of a CQing station with a 
double click REDUCE QRM? That INCREASES QRM. The station that sent CQ is now 
faced with multiple callers, and as a result often NOTHING is decoded. This 
wastes time. Then when he finally picks out a station, he is faced with the QRM 
from those other on-frequency callers who insist on re-enabling their TX to 
continue calling, causing the receive station even more problems decoding the 
station he is trying to work. 
   
I believe that the way WSJT-X was configured in r8019 and r8021 would result in 
much LESS QRM than the way it was before r8019 and the way it is now in r8023. 
I encouraged Martti, OH2BH, to try FT8 in the very first FT8 DXpedition, to 
Market Reef, OJ0. In a post-expition exchanges of emails with Martti, he 
related the great frustration of having to deal with many calling on his TX 
frequency, resulting in a much lower QSO rate. With over 5,500 FT8 QSOs in my 
log, and having to deal with multiple on-freq callers,I know of what I speak! 
Making split the default by leaving your TX frequency where you want it and NOT 
moving it a CQer's frequency is the way to reduce QRM.

73,
Rich - K1HTV

= = =
   
   
From: Ed Wilson via wsjt-devel [wsjt-devel@lists.sourceforge.net]
Sent: Tuesday, September 26, 2017 6:22 AM
To: wsjt-devel@lists.sourceforge.net
Cc: Ed Wilson 
Subject: [wsjt-devel] r8123 UDP Communication

I built r8123 this morning and was pleased to see that double-clicking on a 
station calling CQ moves both the Tx and Rx frequencies to that of the caller. 
Although I can appreciate the comments of some of my colleagues suggesting that 
only the Rx frequency be moved, I believe that moving both is the best approach 
to reducing QRM.

Now to the subject of this posting: it appears that communication between 
WSJT-X and JTAlert has been lost. I cannot double-click on a caller in JTAlert 
and get any response from WSJT-X. I can, however, double-click on the caller in 
WSJT-X and make a contact as usual.

I am just passing this info along to assist in the development process...I can 
work around the issues as they arise in the testing process.

Ed, K0KC

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


[wsjt-devel] Double-click Band Activity responses

2017-09-25 Thread Rich - K1HTV
In the development release r8121 I notice different responses when double 
clicking on stations in the Band Activity column.

Double click on station calling CQ:
The green marker moves to the CQ caller's frequencyGood.
The red marker and the TX frequency both stay put Good!

Double click on a station NOT calling CQ:
The green marker moves to the CQ caller's frequency...Good
The red marker and TX frequency also moves to the other station's 
frequencyBad! 
The TX frequency and red marker should NOT move.

73,
Rich - K1HTV

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


Re: [wsjt-devel] r8119

2017-09-25 Thread Rich - K1HTV
I really like the change in r8119 through r8121 to move only the Rx frequency 
when double clicking on a CQ line in the Band Activity column. If this feature 
remains in future candidate releases, the number of multiple callers on the 
same frequency should be greatly reduced. Most casual ops will simply click on 
a CQ line, move the green RX marker and leave their TX frequency elsewhere in 
the passband. This should make running split the norm.a good thing. The 
result will be fewer no-decodes because of multi-caller QRM.

If desired, calling on a CQing station's exact frequency can be accomplished 
with a Control-double click on the CQ line in the Band Activity column. This 
will move both green and red markers to his frequency.  A CTRL-click on a 
frequency in the waterfall display will also move both TX and RX markers to 
that frequency.

Setting ONLY your TX frequency is easily done with a Shift-Click while pointing 
to a clear frequency in the waterfall display. This should be the first step in 
setting up for split before calling a station.

I have found that running split is really the key to completing QSOs with fewer 
repeats due to QRM from competing callers. The recent change, if retained, will 
make running split much easier for FT8 users.

73,
Rich - K1HTV
PS - Now up to 143 countries worked and 118 confirmed with FT8 with 75W or less.

= = =

From: Ed Wilson 
To: 
Subject: [wsjt-devel] r8119

I built r8119 this morning and was surprised to find that with Lock Tx=Rx 
unchecked, double-clicking on someone calling CQ (or otherwise calling another 
station) just moves the Rx frequency to that of the station calling rather than 
both the Tx and Rx frequency as before.
I have been trying to train myself to operate without the Tx=Rx box checked and 
this change kind of threw me for a loop. Is this the intended behavior for the 
future or is it a bug?
As an aside, the last few builds seem to be more effective in helping me 
achieve contacts for whatever reason...nice work!
Ed, K0KC

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


Re: [wsjt-devel] WSJT-X 1.7.1 builds now fail to start

2017-09-20 Thread Rich - K1HTV
Greg,

   Dummy me!  I just created a shortcut for the latest build of wsjtx.exe from 
the 'install' folder and it works just  fine. Many thanks for your rapid reply.


With over 5000 FT9 QSOs in the K1HTV log, I'm now up to 140 FT8 DXCC countries 
worked and 108 confirmed via LOTW while running 50 to 75W.  


FT8 is GREAT!!!


Thanks for all you are doing as part of the WSJTX Development team. Super job 
guys!


73,

Rich - K1HTV


= = =



Date: Wed, 20 Sep 2017 00:27:26 -0600
From: Greg Beam mailto:ki7m...@gmail.com
To: 'WSJT software development' mailto:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 1.7.1 builds now fail to start
Message-ID: <00ea01d331d9$8780dd30$96829790$@gmail.com 
mailto:00ea01d331d9$8780dd30$96829790$@gmail.com >
Content-Type: text/plain; charset="utf-8"

Hi Rich,

Typically, you do not run the build from the ?build? folder. Rather, you run it 
from the release/install folder, as that is where all the required QT / GCC 
dll?s are copied to. The auto-run setting for JTSDK (assuming that is what you 
are building with) changes directory to the revision / release / install 
directory, then runs the wsjtx.exe. This would be the same action as if you 
were to run WSJT-X after using the package installer. The plugins directory 
typically resided one level above the /bin directory. However, when running 
from the build directory, that structure does not exist.

I can?t really speak to your older build situation.

73?s

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


[wsjt-devel] WSJT-X 1.7.1 builds now fail to start

2017-09-20 Thread Rich - K1HTV
I had been successfully  building and running WSJT-X development releases for 
many months up to r8072. When RC2 came out I started using it to check it for 
bugs and hadn't built any new 1.7.1 releases until today. I built r8098 and it 
auto started and ran OK. I went into the 8098/release/build folder and made a 
shortcut for wsjtx.exe but when I ran it I received an error message. Running 
the wsjtx.exe directly gives the same error. The message says that the app 
failed to start because it could not find or load the QT platform plugin 
"windows". I tried rebuilding with the same results.

I also tried running wsjtx-exe from a number of older (8060 & 8071) builds 
which previously were working but get the same error.

Can you shed some light as to what might be happening?  Thanks.

73,

Rich - K1HTV

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


[wsjt-devel] WSJT-X 1.7.1 builds now fail to start

2017-09-19 Thread Rich - K1HTV

   I had been successfully  building and running WSJT-X development releases for many months up to r8072. When RC2 came out I started using it to check it for bugs and hadn't built any new 1.7.1 releases until today. I built r8098 and it auto started and ran OK. I went into the 8098/release/build folder and made a shortcut for wsjtx.exe but when I ran it I received an error message. Running the wsjtx.exe directly gives the same error. The message says that the app failed to start because it could not find or load the QT platform plugin "windows". I tried rebuilding with the same results.I also tried running wsjtx-exe from a number of older (8060 & 8071) builds which previously were working but get the same error.Can you shed some light as to what might be happening?  Thanks.73,Rich - K1HTV
 

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


[wsjt-devel] A suggested FT8 split option

2017-09-19 Thread Rich - K1HTV
Gary,

   Operating split on FT8 should be the rule and not the exception. Why would 
any want to call on the same frequency and a CQer? Your chances of working a 
station are so much better when you are calling on a clearer frequency. 


I use VNC Viewer with my Android smartphone to view the 3 shack monitors and 
control WSJT-X while working around the  house or when in town. Setting up a 
split is much more difficult with a smart phone with no ALT key. It becomes a 
multi-step process which usually takes so much time that one calling period is 
wasted in setting up the split.


Joe & the WSJT-X Team:

I wonder if there could be an option which, if checked, would allow the user's 
TX frequency to remain as selected.  If this could be done, when you double 
click on a  station's call (without the ALT key)  in the Band Activity column, 
only the green RX indicator would move and the red TX indicator would stay 
where it was set. . Implementing this option would result in much more split 
operating and a better frequency distribution of multiple callers. Fewer 
multi-station pileups would result in faster QSOs because of less single 
frequency QRM. Why not make this the default?  Operating simplex  would require 
a CTRL-left mouse click on that station callsign. 


73,

Rich - K1HTV
--

Date: Mon, 18 Sep 2017 08:18:43 -0600
From: Gary McDuffie mailto:mcduf...@ag0n.net >
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >
Subject: Re: [wsjt-devel] FT8 is forcing the discipline of split ...

Funny. Same guy finally forced me to go split this morning on 80m. Took about 4 
tries and some moving around, but I finally got him. I?ve been seeing him 
pretty much daily on 80m in the morning, so some of you might want to snag this 
one.

Gary - AG0N

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


Re: [wsjt-devel] FT8 is forcing the discipline of split ...

2017-09-19 Thread Rich - K1HTV
Sig,

  The only way I can find a way to go split after clicking on his call 
inJTAlert is to hold the shift key down, move the pointer to a clear frequency 
and left click the mouse. If you are fast enough you may be able to be decoded 
the first try.


I find it much easier to first find a quiet frequency and shift left-click on 
it to set your TX frequency. Then when you see a station in the Band Activity 
list, hold the ALT key while double clicking on the line containing the station 
that you want to work. This procedure has worked very well for me in chasing 
and working DX. Make sure that SFile/Settings/General/Display/"Blank line 
between decoding periods" is checked. It makes it much easier if 15 second 
periods are separated by dashes. And as a bonus, you get to know what country 
the CQer is in.


73,

Rich - K1HTV 

Now over 5,000 FT8 Q's in 139 DXCC countries (116 confirmed) with 50-75W


= = =

Message: 2
Date: Mon, 18 Sep 2017 11:30:57 -0500
From: Joe mailto:n...@mwt.net >
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >, Gary
McDuffie mailto:mcduf...@ag0n.net >
Subject: Re: [wsjt-devel] FT8 is forcing the discipline of split ...


I just WSJT-X and JT-Alert can figure out how to run split together.

I love how JT-Alert works, and does, but any clicking in JT-Alert puts
both REC and TX on the same freq no matter what you have checked in WSJT-X

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


[wsjt-devel] Bogus Grids and message progression

2017-09-09 Thread Rich - K1HTV
Bill, G4WJS  & Steve, K9AN,

  Thanks for your explanation in your previous messages regarding why some FT8 
contesters are seeing what appear to be bogus grids being sent.


So if I understand correctly, when a user checks the box for the NA contest, 
his grid is converted to its equivalent antipodal counterpart grid and is 
transmitted that way.  If a receiving station is also set up in the NA contest 
mode, the antipodal grid which was transmitted is decoded, converted to the 
actual grid of the sender, and displayed correctly.


But if someone receiving that transmission does NOT have the  NA contest mode 
box checked, the grid sent is seen as the antipodal equivalent grid on his 
display and appears as a bogus grid square to that user, right?


If that reformatting the grid for transmission in the NA contest mode is the 
way it must be done because of bit limitations, then the users will have to 
deal with it.  BUT, explaining it to the average Ham FT8 user is going to be a 
difficult task. Teaching him how to deal with it is going to be even tougher.


As long as there are less knowledgeable FT8 users, during NA VHF contests there 
will be those who will send contest format messages and the unknowing that will 
send the non-contest format messages. That is the way it is now, and in all 
likelihood the way it will continue for all future NA VHF contests.  This will 
continue to cause the frustration and confusion that is being experienced 
during this VHF contest.


How about this suggestion?   Is there any way to modify the program to accept 
either the contest format (K9AN K1HTV FM18) or the non-contest  format (K9AN 
K1HTV -15) as valid TX2 messages and proceed by replying with a Tx3  message?


The same holds for the TX3 message reception. Could the program be written in 
such a way as to accept either a contest TX4 message (K9AN K1HTV R FM18) or a 
non-contest TX4 message (K9AN K1HTV RRR) as being valid, then continue on to 
the Tx5 message?


If this software change can be implemented, then the situation that exists 
between contest mode and non-contest mode setups will be eliminated. I'm 
referring to the fact that presently, neither station can automatically 
progress through the Tx messages. They are doomed to sending the same message 
until the the WD timer stops them or the users manually step through the 
sequences to complete the QSO.


Those serious VHF contesters who configure WSJT-X for the NA contest mode will 
see valid grid numbers, even if the sender hasn't set up for the contest mode. 
He will note the grid from the initial Tx1 message received. Those that don't 
set up to use the contest format will continue to ask "what are those bogus 
grids that I am seeing?".  Of course, the answer to them is to RTFM or ask 
their local FT8 guru..


73,

Rich - K1HTV


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


[wsjt-devel] More on bogus grid reports

2017-09-09 Thread Rich - K1HTV
OK,  while running WSJT-X Version 1.8.0-rc 8069, I too now have see a bogus 
grid report being sent. 


I answered a CQ by W3ARO .


He sent me a report, a Tx2 message, “K1HTV W3ARO OE28”, a bogus grid number, 
apparently mis-formated by the software version that he was using.

.

I had switched back to non-contest mode, and turned auto sequence OFF and sent 
him “W3ARO K1HTV -05”.


He responded with an apparent free form text message of “K1HTV W3ARO R FN20” 
which is a properly formatted Tx3 message.

Apparently, seeing that I was sending a dB report, he switched to the 
non-contest format and we completed the QSO.


So, the only bogus grid message that he sent appears to be the Tx2 message.


73,

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


[wsjt-devel] WSJT-X compatibility bugs?

2017-09-09 Thread Rich - K1HTV
While operating in this weekend's ARRL VHF contest using FT8, two major 
problems have appeared.


1) Not all stations are using the CONTEST MODE (File, Settings, Advanced tab). 
As a result,  stations using differing "Contest mode"  check box settings  can 
not complete FT8 QSOs. The reports being received  are not  being interpreted 
as valid exchanges. This results in endless repeats and no completed FT8 
contest QSOs.


2) Some stations are reporting receiving bogus 4 character grid squares.  I 
just received an email from a local contester concerning confusing reports 
being received during the VHF contest using FT8 on 6M.  He writes:

= = =


"Rich,
I am puzzled by the unexpected OF10, OF11, OE39, OE39 initial FT8 exchanges 
some stations (you, K3AJ, N2NT, W3IP, WA3VNV) were sending. Some resulted in 
puzzled receivers re-sending the R report several times. Where is this 
explained."


= = =


I've sent him a reply, asking what version of WSJT-X he is using. If an older 
version, there may be a compatibility problem. Another local, whom II believe 
is using Build 1.7.1 r8072, reports decoding a few stations sending  bogus grid 
reports.


I have switched from the development builds and have been shaking down " 
v1.8.0-rc2 8069" but so far I have seen no such bogus grids yet in what I have 
decoded.


I'll report more as I get more input from the guys.


73,

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


Re: [wsjt-devel] Unchecked Disable Tx after 73 not working?

2017-09-08 Thread Rich - K1HTV
Jim & Team programmers,
I can understand the "QSO machine" reasoning, but why is the "Disable Tx after 
73" box even there? With the box unchecked, the "Enable Tx" box changes from 
red to gray and no further transmissions are made until manually enabled again, 
as is expected. One would think, logically, that if the box is CHECKED instead, 
that this disabling action would NOT take place,. But, we know that a QSO 
machine feature is NOT desired, so why does the box even exist?


Instead, what happens when the "Disable Tx after 73" box is UNCHECKED is that a 
long series of Tx5 "73" messages is sent at the end of a QSO. They continue to 
be sent until they are manually stopped. I see no benefit of the box even being 
there, unless I'm missing something as to what it is supposed to do.


Why not hard code the disabling of further transmissions after a Tx5 (73) 
message is sent and eliminate the "Disable Tx after 73" check box completely?


73,
Rich - K1HTV
4,200+  FT8 Q's in 133 countries with <75W

= = =

Date: Thu, 7 Sep 2017 21:42:35 -0400
From: James Shaver 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Unchecked Disable Tx after 73 not working?

That's normal - user interaction to start another QSO is required to
prevent "QSO machines"

Jim S.

N2ADV

On 9/7/2017 7:49 PM, Rich - K1HTV wrote:

Using 1.8.0-rC2 r8069

Under Settings, General tab, under 'Behavior', ?the "Disable TX after
73" unchecked. However, ?when the Tx5 (73) message is sent, the log
QSO box comes up as it should, but the "Enable Tx" goes from red to
gray. This disables further transmissions until the "Enable Tx" button
is clicked gain.

Shouldn't the system continue on to Tx6, and send the CQ message in
the next transmit sequence ?

Has this feature been eliminated or maybe I am misunderstanding what
the check box is supposed to do?

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


[wsjt-devel] Unchecked Disable Tx after 73 not working?

2017-09-07 Thread Rich - K1HTV
Using 1.8.0-rC2 r8069


Under Settings, General tab, under 'Behavior',  the "Disable TX after 73" 
unchecked. However,  when the Tx5 (73) message is sent, the log QSO box comes 
up as it should, but the "Enable Tx" goes from red to gray. This disables 
further transmissions until the "Enable Tx" button is clicked gain.


Shouldn't the system continue on to Tx6, and send the CQ message in the next 
transmit sequence ?


Has this feature been eliminated or maybe I am misunderstanding what the check 
box is supposed to do?


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


[wsjt-devel] 4 periods before band is displayed

2017-09-03 Thread Rich - K1HTV
When the box for "Blank line between decoding periods" at the 
File/Settings/General tab is checked, while using the FT8 mode, is there any 
reason why four 15 second segments must pass before the band is displayed on 
the right side of the line?


Was the original intent to wait for one 60 second period for JT65 before 
decoded data was forwarded to PSKReporter to avoid wrong band reports? Instead 
of 60 seconds before the band is displayed while using and of the 15 second 
sequence modes, why not skip only one 15 second sequence, then display the band 
at the right side of the dashed line.


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


Re: [wsjt-devel] 8056 (correction)

2017-09-01 Thread Rich - K1HTV
Jim,

A correction:


The first line in my response should read "What you state about skipping the 
grid message and starting with the Tx2 (calls and report) message is NOT the 
case, at least with the present R-8055 build that I'm using. "


That feature does NOT exist in r8055.


73,

Rich - K1HTV

= = =

Message: 1
Date: Fri, 1 Sep 2017 09:50:05 -0400 (EDT)
From: Rich - K1HTV mailto:k1...@comcast.net >
To: n2...@windstream.net mailto:n2...@windstream.net , WSJT 
mailto:wsjt-devel@lists.sourceforge.net >
Subject: Re: [wsjt-devel] 8056
Message-ID: <880004648.137269.1504273806...@connect.xfinity.com 
mailto:880004648.137269.1504273806...@connect.xfinity.com >
Content-Type: text/plain; charset="utf-8"

Jim,

What you state about skipping the grid message and starting with the Tx2 (calls 
and report) message is the case, at least with the present R-8055 build that 
I'm using. When a station is initially called with the Tx2 message, what is 
received in reply is a Tx3 (calls plus R-report) message. A high percentage of 
the almost 4,000 FT8 QSOs that I have made in the past 2 months have been made 
starting with the Tx2 message.

You will find stations starting with the TX2 message in order to work callers 
at a faster pace. Skipping the grid and saving 15 seconds , as is often being 
done, is very important, especially when conditions are marginal.

Sending a grid square is not a requirement for a QSO to be valid. Send, 
receiving and confirming the reception of those reports is required.

I hope that the 'feature' which you described of getting the message sequence 
'back on track' does NOT become part of future builds and eventually the new RC 
release, which should be out soon.

73,

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


Re: [wsjt-devel] 8056

2017-09-01 Thread Rich - K1HTV
Jim,

   What you state about skipping the grid message and starting with the Tx2 
(calls and report) message is the case, at least with the present R-8055 build 
that I'm using.  When a station is initially called with the Tx2 message, what 
is received in reply is a Tx3 (calls plus R-report) message. A high percentage 
of the almost 4,000 FT8 QSOs that I have made in the past 2 months have been 
made starting with the Tx2 message.  


You will find stations starting with the TX2 message in order to work callers 
at a faster pace. Skipping the grid and saving 15 seconds , as is often being 
done, is very important, especially when  conditions are marginal.


Sending a grid square is not a requirement for a QSO to be valid. Send, 
receiving and confirming the reception of those reports is required.


I hope that the 'feature' which you described of getting the message sequence 
'back on track' does NOT become part of future builds and eventually the new RC 
release, which should be out soon.


73,

Rich - K1HTV


PS:

123/98 FT8 DXCC countries worked/confirmed so far


= = =
Message: 1
Date: Fri, 1 Sep 2017 08:23:07 -0400
From: James Shaver mailto:n2...@windstream.net >
To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 8056
Message-ID: <728d54e4-33bc-9d93-742f-615a05ae4...@windstream.net 
mailto:728d54e4-33bc-9d93-742f-615a05ae4...@windstream.net >
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

This was done early on to make sure people followed the sequence - if
someone decided to get creative and skip a step, the software is smart
enough to get them back on track.? Not sure why skipping the grid and
saving 15 seconds is so desired.

Jim S.

N2ADV


-

On 9/1/2017 8:19 AM, Erik - wrote:

> After calling CQ, if a respondent skips the grid and sends dB report,
> the software does not send a R+dB report. Instead it sends a dB report.
> 
> An example:
> 
> I double-clicked on JA4DNC who had answered with -12 but I sent him
> -21 instead R-21. This then caused a R+dB report to come back to me
> instead of 73.
> 
> Erik EI4KF.
> 
> 
> --
> 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Wrong country name displayed

2017-08-28 Thread Rich - K1HTV
Using R8035,  on FT8, with the "Show DXCC entity and worked before status" box 
CHECKED,  certain free form CQs messages result in the wrong country name being 
displayed on the right side of the line in the "Band Activity"  column.


Examples:

CQ USA EA5SW Ukraine

CQ ASIA K4MMPakistan

CQ N4ERC EM11   Puerto Rico (why would an N4 callsign be interpreted as a KP4?)


I thought that free form messages were not supposed to trigger the display of a 
country name because of the possibility of improper interpretation of the  
letters following the CQ characters.


73,

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


[wsjt-devel] TX freqs change while xmttg

2017-08-28 Thread Rich - K1HTV
Using R3035, in FT8, with the "Allow Tx frequency changes while transmitting" 
box UNCHECKED, I am still able to change the TX frequency by Shift-clicking on 
a different frequency on the waterfall. 

73,
Rich - K1HTV

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


Re: [wsjt-devel] 20 M FT8 freqs for DXpeditions? (long)

2017-08-21 Thread Rich - K1HTV
Ned- AA7A,
Thanks for your insightful response to my post. We agree that new chunks of 
spectrum need to be identified and used on each band. On 20M that may mean 
using a segment above 14.115 MHz. Also, the use of FT8 operation can only be 
successful if calling stations spread out, but as you mentioned, not all 
transceivers have super wide receive capabilities. But almost all DO have 
mechanical SPLIT capability, which also could be used. Stations calling the DX 
from +100 Hz to +2.2 KHz higher than his TX frequency do this software split 
with a mouse click.

But.. SPLIT can also be done with the caller using his transceiver's 
mechanical SPLIT capability OR by using his transceiver's XIT feature. A DX 
station transmitting on 14070.2 KHz could easily call "CQ14116 VK9MA" or 
"UP14KHZ VK9MA" and listen up there. This would force users to do a mechanical 
transceiver SPLIT. The DX would NOT respond to anyone in the 14.074-076 range. 
Callers will eventually get the message that the DX is listening UPreally 
UP :-). This info, of course, would be published in advance.


Longer CQ messages may require a software change, but there is a feature used 
when doing MSK144 split operations. That is, check the box below the "T/R 15 s" 
box and type in the 3 digit  QSX frequency. This will embed the QSX frequency 
into the CQ message. 

As mentioned in one of my earlier posts, if the DX decides to stay withing the 
14.074-076 segment to work stations, allowing the software to force his TX 
frequency to QSY to the caller's TX frequency can have positive results with 
less QRM being received by the calling station. This will be so because the 
caller hopefully has selected his TX frequency to be on a clear spot on his 
waterfall display. This should result in fewer repeats by the DX station to the 
caller being worked.

Either way, staying withingthe present 20M FT8 segment or doing a big split, 
the DX station, after making a number of contacts on one TX frequency may have 
to move to another one to avoid DQRM.

More thoughts/discussion on the SPLIT topic?

73,
Rich - K1HTV


= = =

> On August 20, 2017 at 12:18 PM Ned  wrote:
> 
> 
> Rich,
> 
> I would like to add some perspective of what might happen when what is 
> called a "Top Ten" DXpedition (a DXCC entity that is in the Top Ten slots in 
> published need lists...examples being Bouvet and Baker Island that will be 
> QRV early next year) takes place on RTTY (or any digitial) mode. Having been 
> the "RTTY guy" on both VP8STI and VP8SGI last year (both on the Top Ten at 
> that time), the pileups are hard to describe. RTTY operation on these two 
> DXpeditions was confined to 2 bands, basically, in order to prevent issues 
> that arise in the use of Clublog Leaderboard. So the DXpedition leadership 
> opted to limit RTTY to two bands (30 and 15 meters) in order to maximize the 
> number of ATNOs (All Time New Ones) on the digital modes. As a result, the 
> pileups were huge and stayed huge until we left both islands.
> 
> When I called CQ the very first day on South Sandwich Island (VP8STI), 
> the pileup was 30 KHz wide and hundreds deep. I have been in many RTTY 
> contests and other DXpeditions (27 so far), but I had never experienced 
> anything like this before. Using MTTY from within N1MM, the logging 
> application for the DXPedition, it was virtually impossible at times to find 
> complete calls in the pile. Over half of the time, I had to work QSOs in the 
> same manner as one does on CW where I would type in a partial call and fix it 
> when the station would send their report. There seemed to be few chances for 
> me to use a mouse to pick a call out of an area on the computer screen. My 
> hands were literally glued to the keyboard to make QSOs at a high rate. I 
> manually spread the pile by trying to randomly pick calls across the breadth 
> of the pile to prevent "tailending". I could never pick out one call in a 
> tailend pile. So, while I was sending my QSL/QRZ message, I literally spun 
> the dial of the receiver either up or down to a new frequency to work the 
> next station. After doing this a while, everyone in the pile stopped trying 
> to tail end and the rates settled into the best that could be done. FT8 is 
> perfect for doing this, BTW.
> 
> The only real tool in the hands of the DXpedition operator is to spread 
> the pile until calls could be copied and making it easy for the DXpedition 
> team operator to briskly sweep the spreadout pile to find calls. What Rich is 
> suggesting below is spot on. FT8 operation at a Top Ten DXpedition might only 
> be possible if the operator can make QSOs at a good rate, otherwise they will 
> go back to RTTY. Rate is king. My fear is that the piles might get so deep 

[wsjt-devel] 20 M FT8 freqs for DXpeditions?

2017-08-20 Thread Rich - K1HTV
Additional 20 M FT8 frequencies for DXpeditions & general DX use


The question has been posed as to the best frequencies for DXpeditions while 
operating the FT8 mode.

Lets focus on 20 Meters, which will probably be the most heavily used DX band 
as we approach the bottom of the solar cycle.


>From the IARU Region 1,2 & 3 Bandplan documents:

IARU Region 1:

14 060 – 14 070 (200 Hz BW) CW,
14 060 kHz – QRP Centre of Activity

14 070 – 14 089 (500 Hz BW) - Narrow band modes – digimodes

14 089 – 14 099 (500 Hz BW) -Narrow band modes - digimodes automatically 
controlled data stations (unattended)

14 099 – 14 101 - IBP, exclusively for beacons

14 101 – 14 112 (2700 Hz BW) - All modes – digimodes, automatically controlled 
data stations (unattended)

14 112 – 14 125 (2700 Hz BW) All modes


* * * * **


IARU Region 2:

14060-14090 (500Hz BW) - ALL MODES, DIGIMODES
14100.5-14125 (2700Hz BW) - ALL MODES, FAST DIGIMODES, AUTOMATIC


IARU Region 3:

Considering the dramatic increase in data mode usage on the 20 meter band, it 
is recommended that the sub-band for
these classes of signals be 14.070 MHz to 14.112 MHz (with +/- 500 Hz at 14.100 
MHz for beacons), and within that
data sub-band the current practices of traditional data modes may continue up 
to 14.095 MHz with 14.095 to 14.112 MHz
being reserved for other data modes including Packet.


- - - - - - -


In IARU Regions 1 & 2, both indicate ALL modes up to 14.125 MHz. Only in Region 
3 are the digital modes recommended
between 14.070 and 14.112 MHz.


For major DXpeditions in Regions 1 & 2 is there any reason why frequencies 
above 14.112 MHz can't be used for the FT8 mode by
DXpeditions or for FT8 DXing in general? It has been less that 2 months since 
WSJT-X software with the FT8 mode has been made available to the general Ham 
population. But already the frequency range between 14074.2 and 14076.4 KHz is 
very often packed with hundreds of stations simultaniously using that small 
segment. And the congestion will only get worse in the months to come, 
especially when DXpeditions start using the new digital mode.


I would strongly suggest that serious consideration be given for the use the 
FT8 mode on 20 Meter frequencies between
14.112 and 14.125 MHz.


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


[wsjt-devel] DXpeditions - FT8, Split or not to split

2017-08-19 Thread Rich - K1HTV

DXpeditions - FT8, Split or not to split


Having a great amount of success DXing on HF (363 countries, 7 band triple 
DXCC, HR, etc) running low power, and
having already worked over 2800 QSOs in 117 DXCC countries on FT8 with 50-75 
Watts, I believe that I have a pretty
good insight of what does and does not work when it comes to working DX in 
general and working FT8 DX in particular.


It has been suggested that a DXpedition remain on one transmit frequency while 
operating the FT8 mode and work split, listening over a wide range of 
frequencies. If you are a DXer who has been around for a while, you probably 
have suffered from the effects of DQRM (Deliberate QRM). It wouldn't take much 
for a few frustrated DQRMers to double click on the DXpedition's fixed FT8 
frequency and transmit garbage messages. They would make it next to impossible 
for many callers to decode the DXpedition's FT8 transmissions. Then there is 
the case of newbie FT8 ops click on the line of a caller, causing the newbie to 
transmit during the same TX cycle as the DXpedition. I see it happening 
nowI will see it again and again as even more new ops show up on FT8 to 
work a new DXCC entity on a digital mode. 


Because of this, I strongly recommend that future DXpeditions' FT8 operators 
consider the following:
1) Check the "Lock Tx=Rx" box
2) UNCHECK the "Call 1st" box.
3) Check the "Auto Seq" box


With the "Lock Tx=Rx" box checked, when the DX clicks on the line of a caller, 
he would QSY and call on the caller's relatively quiet (to the caller's ears) 
TX frequency. Callers would try to pick a transmit frequency which appears to 
be quiet during his station's receive cycle. That means when the DX station 
replies to a caller, the caller would have a much better chance of decoding the 
DX. This moving target would completely foil DQRMers ability to cause QRM to 
the  DXpedition.


Since the caller is decoding the entire passband, the DX station's 
transmissions should be copied most of the time, no matter which frequency the 
DXpedition transmits on.


Unchecking the "Call 1st" box would allow the DX station to call anyone he 
wants, the strongest, the weakest, or callers being copied over a difficult 
propagation path during a very short opening to that area.


With the "Auto Seq" box checked, the software would sequence through the QSO 
steps, but only after the DXpedition op started the process manually by 
selecting the station he wants to answer next.


I'll comment on the best frequencies to use in my next post.


73,
Rich - K1HTV

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


Re: [wsjt-devel] Wrong country

2017-08-16 Thread Rich - K1HTV
Thanks Bill for the software fix for this issue and for all that you do as part 
of the WSJT-X Development team.


73, 

Rich - K1HTV


PS I'm now up to 116 DX countries worked on FT8 with low power. FT8 is 
GREAT!

= = =


From: Bill Somerville mailto:g4...@classdesign.com >
To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Wrong countrty
Message-ID: <15d89051-9919-0064-b419-20e89abda...@classdesign.com 
mailto:15d89051-9919-0064-b419-20e89abda...@classdesign.com >
Content-Type: text/plain; charset=utf-8; format=flowed

On 16/08/2017 04:47, Rich - K1HTV wrote:

While using FT8 I noticed this anomaly. 031330 -14 0.1 1769 ~ CQ E51 W3BTX !S. 
Cook Is. With the "Show DXCC entity and worked before status" box under the " 
General" tab checked, instead of W3BTX being flagged as U.S.A. it used the E51 
prefix in the line and erroneously marked the country as South …

Hi Rich,

thanks for reporting this issue. The problem is two fold, firstly is not
a standard form message and secondly the WSJT-X handling of extracting
the callsign from CQ and other similar general call messages was not
discriminating enough. I have made a change for the next release that
will not make the above mistake, nor will it recognize the above message
as a general call in standard format so no attempt will be made to tag
it with a DXCC entity name. Other valid standard form messages such as
"CQ VT G4WJS IO91" will be correctly tagged with the DXCC entity.

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


[wsjt-devel] Wrong countrty

2017-08-15 Thread Rich - K1HTV
While using FT8 I noticed this anomaly. 


031330 -14 0.1 1769 ~ CQ E51 W3BTX !S. Cook Is.


With the "Show DXCC entity and worked before status"  box under the " General" 
tab checked, instead of W3BTX being flagged as U.S.A. it used the E51 prefix in 
the line and erroneously marked the country as South Cook Island.


This occurred using v1.7.1-devel r8026 build.


73,

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


Re: [wsjt-devel] Auto seq while answering split

2017-08-14 Thread Rich - K1HTV
Ron,

   As long as your signal frequency is within plus or minus 50 Hz of the 
station you are calling, the red "Enable Tx"  will be disabled and go grey when 
you decode the station you called replying to someone else. However, when your 
signal is 51 Hz or more either side of the stations frequency, you will 
continue transmitting during your TX sequence. When your transmitting frequency 
is outside the decoding window for the nominal 47 Hz wide signal, the QRM 
problem to the decoder is greatly reduced.  


Operating more than 50 Hz away from a station that you are calling will 
increase your chances of being decoded by that station. The majority of 
stations calling a DX station are probably operating zero beat right on the DX 
station's frequency and as a result the DX will probably not decode any of 
them.  


Running split with the "Lock Tx=Rx" box UNCHECKED for the most part, I've been 
able to work 111 DXCC countries in the 4+ weeks that I've been running FT8 on 
the HF bands with low power (50 to 80 Watts).  Just double click on the DX 
station callsign, find a quiet frequency, then Shift-click on it and your 
chances of working the DX will greatly increase.


73,

Rich - K1HTV

--

From: Ron Gibson mailto:ve3...@sympatico.ca >
To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Auto seq while answering split
Message-ID: <190ab13b-642f-459c-80a6-6d7f090b2...@sympatico.ca 
mailto:190ab13b-642f-459c-80a6-6d7f090b2...@sympatico.ca >
Content-Type: text/plain; charset=utf-8; format=flowed

Even though I fear that I'll be criticized for reporting a 'known'
defect, I would like to report that when I answer a CQ and I'm using
split, if the calling station responds to another caller r8018 does not
disable TX. If no split it works as it should.
73 de Ron
VE3CGR / CG3CGR--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] 15 vs 30 sec Fast Graph header

2017-08-11 Thread Rich - K1HTV
While running MSK144 with 15 second sequencing for Perseids meteor scatter 
operation this morning, I noticed that instead of the Fast Graph header reading 
0-15 it reads 0-30 seconds. Would it be possible for the time header to change 
based on the length of the chosen 15 or 30 second sequence?


73,

Rich - K1HTV


PS - The Perseids meteors were flying this morning. Looks like a good shower 
this year with the peak coming within the next 24 hours.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Why wipe Tx6 message?

2017-08-11 Thread Rich - K1HTV
Mike,

Tnx for responding to this request. Until the modification gets into the 
version downloaded by the masses, this feature won't be able to be used by 
most. I don't believe that this weekend's crew doing the OJ0 (Market Reef) 
DXpedition are building their WSJT-X software and will be using the present RC1 
version.


Thanks for the changed code. Hope that it can permanently be implemented in the 
final release for all to use.


73,

Rich - K1HTV

--

Message: 1
Date: Fri, 11 Aug 2017 11:13:00 + (UTC)
From: Black Michael mailto:mdblac...@yahoo.com >
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >
Subject: Re: [wsjt-devel] Why wipe Tx6 message?
Message-ID: <1301556709.1708692.1502449980...@mail.yahoo.com 
mailto:1301556709.1708692.1502449980...@mail.yahoo.com >
Content-Type: text/plain; charset="utf-8"

Seems to me we just need to fill TX 6 when it's empty and leave it alone after 
that. ?It never changes under normal ops. ?So when you put in your custom CQ it 
never gets touched again.
This simple patch sets TX6 only if it's empty for modes other than JT6 and 
QRA64,
This should get you going for the weekend I think.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Why wipe Tx6 message?

2017-08-10 Thread Rich - K1HTV
Bill,

  Yes, I know that the Tx5 messages can easily be stored and retrieved.  But in 
R8021 and other builds, when I  click on a call of a station replying to my CQ, 
the special message stored in TX5 gets wiped out. That means every time I want 
to again use that special message I need to go the Tx5 drop down menu, find it 
and select it AGAIN.


In the case of future DXpeditions using FT8, of which I'm sure there will be 
many, having to pull down a special message such as "CQ P5AA SPLT" or "CQ P5AA 
UP" after every QSO will be a real inconvenience and a pain.


Again, what is needed is a CQ message box that can be frozen without having to 
reprogram it after each QSO. Many DXers use special CQ messages such as "CQ DX 
call Grid" or CQ NA call Grid".  As the program works now, after each DX QSO 
they need to re-populate the CQ box.


Why can't one of the boxes be frozen is again my question.


73,

Rich - K1HTV


= = =



Date: Fri, 11 Aug 2017 00:47:54 +0100
From: Bill Somerville mailto:g4...@classdesign.com >
To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Why wipe Tx6 message?
Message-ID: mailto:a494f2b1-2be6-915e-94ac-1fc57b1a2...@classdesign.com >
Content-Type: text/plain; charset=utf-8; format=flowed

On 11/08/2017 00:40, Rich - K1HTV wrote:

The first FT8 DXpedition using FT8 will occur this weekend as OH2BR & OH2JR 
operate from Market Reef as OJ0BR & OJ0JR. In responding to an email from 
Martti, OH2BR, I suggested that since he would not be able to copy anything 
from multiple stations calling on the same frequency, that he run split. I…

HI Rich,

non-standard messages can be added to the free text macros, just enter
them into Tx5 (or Free text on tab 2) and hit ENTER, they will be save
on the macros list and can be recalled with a couple of mouse clicks. On
tab 2 they do not get overwritten either.

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


[wsjt-devel] Why wipe Tx6 message?

2017-08-10 Thread Rich - K1HTV
The first FT8 DXpedition using FT8 will occur this weekend as OH2BR & OH2JR 
operate from Market Reef as OJ0BR & OJ0JR.


In responding to an email from Martti, OH2BR, I suggested that since he would 
not be able to copy anything from multiple stations calling on the same 
frequency, that he run split. I suggested he program a CQ message "CQ OJ0BR UP" 
or CQ OJ0BR SPLT".  


However, this Tx6 message would only  work for one CQ. When a station was 
answered, clicking on it would erase the Tx6 message. He would have to type in 
the special CQ message over and over to direct stations to call on another 
frequency.


Is there any reason why the TX6 message couldn't be left alone when clicking on 
a station answering a CQ message and NOT be changed to the stock "CQ call Grid" 
Tx6 message?


73,

Rich - K1HTV

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


[wsjt-devel] Quicker FT8 QSOs

2017-08-09 Thread Rich - K1HTV
Although Alex's idea of speeding up DXpedition QSOs using is a great one, how 
would the caller's software recognize that the 73 was directed to his station? 
Neither the caller just worked or DX station's call would be contained in the 
"73" line which starts a QSO with the next station. It appears that, as it is 
now done for CW QSOs with DXpeditions, it would require manual intervention by 
the station being worked to stop further transmissions after the "73" message 
was received. 


However, might I suggest the following idea:


All callers would start with the "Tx2" message (Calls and report).

During each of the DXpedition station's 15 sequences, it  would respond with, 
for example:


"W3LPL +30 VK9MMM RR73"


Next, many callers call VK9MMM and hearing K1JT, VK9MMM would respond with:


"K1JT +20 VK9MMM RR73"


more callers call VK9MMM and hearing VE3NEA he responds with:


"VE3NEA +10 VK9MMM RR73"


Etc, etc, etc. until the pileup is worked. As long as there is a never ending 
line of callers, the DXpedition could maintain a maximum QSO rate of 120 per 
hour. 


The caller's software, recognizing both his and the DXpedition's call signs 
plus the "RR73" would stop further transmissions, as no more would be required.


What say WSJT-X software specialists? Can do?


73,

Rich - K1HTV


PS - In less than a month, I've worked 102 DXCC countries using FT8 and 50 
Watts. 


FT8 IS GREAT!!!


= = =


Date: Tue, 8 Aug 2017 15:17:39 -0400
From: Alex, VE3NEA mailto:alsh...@dxatlas.com
To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT on DXpedition
Message-ID: mailto:e3238a4d-de01-870f-4757-419937eff...@dxatlas.com >
Content-Type: text/plain; charset=utf-8; format=flowed

FT8 differs from the traditional modes in one important way: multiple signal 
decoding. This opens a possibility to significantly
increase the speed of a pileup QSO by using a shortened QSO sequence. Here is 
one possibility that would increase the QSO rate
up to 120/hour:

CQ VK9MMM QH72
VK9MMM VE3NEA FN03, VK9MMM K1JT FN20, VK9MMM W3LPL FM19
---
W3LPL VK9MMM +30
VK9MM W3LPL -20
---
73 NOW K1JT +20
VK9MM K1JT -20
---
73 NOW VE3NEA +10
VK9MM VE3NEA -20
---
73 CQ VK9MMM QH72
...

This would require a new message, "73 NOW...", in addition to already defined 
"CQ...", "CQ DX...", etc. Another message, "73
CQ...", would also save some redundant transmissions by confirming the current 
QSO and requesting new calls at the same time.

73 Alex VE3NEA


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


Re: [wsjt-devel] FT8 "Tx Even/1st" label ambiguity

2017-08-04 Thread Rich - K1HTV
Bill,

There is no confusion as to what are considered even and odd minute numbers. 
But as long as I have been doing meteor scatter (since the mid 60's),  here in 
the States, for 15 second sequence M/S schedules,  we have always considered 
each minute to be broken into  4 sequences.  The first and third 15 second 
periods are called  ODD  and the 2nd and 4th periods are called EVEN.


Your way of reasoning 'even' and 'odd', when referring to 15 second periods, 
assumes that the even periods begin at the 00, 15, 30 & 45 second marks. Others 
may reason that the first period starts at second number 01 and not second 
number 00.  Have European meteor scatter enthusiasts always considered the 
first 15 second period of each minute to be odd or even?  


I believe that my suggestion of changing the present FT8 screen's  "Tx 
even/1st"  description to "1st & 3rd 15 second sequence" or an abbreviated 
version of "1st & 3rd 15 sec seq"  will make the meaning of the check box very 
clear as to eliminate the present ambiguity.


73,

Rich - K1HTV


= = =


Date: Fri, 4 Aug 2017 18:59:40 +0100
From: Bill Somerville mailto:g4...@classdesign.com >
To: wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT8 "Tx Even/1st" label ambiguity
Message-ID: <15936bbf-e02c-0491-420c-19b944bf1...@classdesign.com 
mailto:15936bbf-e02c-0491-420c-19b944bf1...@classdesign.com >
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 04/08/2017 18:52, Rich - K1HTV wrote:

> On the FT8 screen, there is an ambiguity as to meaning "Tx even/1st".
> A number of folks new to the mode have expressed some confusion as to
> their meanings.
> 

Hi Rich,

I don't understand. 0 and 30 are even numbers, 15 and 45 are odd. If
anything the 60s T/R periods should cause confusion, but there minutes
1, 3, 5, ... are odd, minutes 0, 2, 4, 6, ... are even.

Time uses zero based indexing (well apart from months but they are
strange in all respects!), so the 15s T/R periods are the zeroth, first,
second, third.

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


[wsjt-devel] FT8 "Tx Even/1st" label ambiguity

2017-08-04 Thread Rich - K1HTV
On the FT8 screen, there is an ambiguity as to meaning "Tx even/1st". A number 
of folks new to the mode have expressed some confusion as to their meanings. 


With 15 second sequencing, "Tx even" can be interpreted as meaning transmit on 
the even sequences, that is, the 2nd and 4th 15 second sequence.


With 15 second sequencing, "1st" can be interpreted as transmit on the first, 
and subsequently, on the 3rd sequence.


The two meanings, as related to 15 second sequencing, are at odds.


Why not, for the FT8 screen, change that check box definition to:

"1st & 3rd 15 second sequence" or an abbreviated "1st & 3rd 15 sec seq" ?


73,

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


[wsjt-devel] Remove "Lock Tx=Rx" QSY 'feature'?

2017-08-04 Thread Rich - K1HTV
Bill, Jim, et al,

   As we all know,  a double click on a CQer's callsign results in both the TX 
and RX frequency changing to the CQer's frequency, even with the "Lock Tx=Rx" 
unchecked. However, with the box unchecked, if a user clicks on a different 
frequency to call CQ, only the RX frequency and the green bracket change. To 
change the TX frequency one must hold the 'Shift' key... but then only the 
TX frequency and the red bracket change. Not many know that to move both TX & 
RX freqs requires holding the "Ctrl"key down while clicking on the desired 
TX/RX frequency. That is why most folks keep the TX=RX box checked, because it 
is easier. But as Jim mentioned, doing so pulls the station you just worked 
back to your frequency, resulting in possible QRM to you.


Maybe the answer with FT8 would be to remove the feature of pulling the other 
station to your frequency and have him stay on his original TX frequency. A 
good reason for him to stay there is because:

1) You were copying him well there.

2) In all likelihood, he was copying you better on your frequency rather that 
through multiple callers on his own frequency.


I can see that with modes where a narrow 'Tol' is used that the calling station 
to be on or very near to your TX frequency. But with FT8, where almost all 
users want the the entire frequency range decoded,  I don't think that it is 
desirable to have a calling station moved away from his original operating 
frequency to a different one simply because he had the "Locked Tx=Rx" box 
checked. What is gained by this?


If the box was completely eliminated then double clicking on a call sign would 
move the TX & RX freqs to the CQer's frequency. After this is done, those who 
want to call off frequency can use one of a number of available keyboard 
shortcuts.


73,

Rich - K1HTV


= = =


On 04/08/2017 02:22, James Shaver (N2ADV) wrote:

I had a FT8 QSO with W7PSK earlier (thanks!) where I was calling CQ, he 
responded to me, we went through the sequence, he sent his 73 and then moved 
off to call CQ elsewhere on the band. Unfortunately, my 73 pulled his TX back 
to where I was causing him to accidentally start calling CQ where he had …


Hi Jim,

I can reproduce that behaviour if I have him with "Lock Tx=Rx" checked.
The more use cases I test with auto-sequencing the more I am growing to
dislike "Lock Tx=Rx".

I will see if I can work out how to stop this sort of thing happening.

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


[wsjt-devel] WSJT-X Shortcut list

2017-07-28 Thread Rich - K1HTV
Mike,

   Duhhh, so its under HELP. What a novel idea :-).   So far I've made 1009 FT8 
QSOs  and you would think that I would explore the menus more to learn more 
about this great program. Nope, I'm too busy using WSJT-X to read all the doco.


Thanks.


73,

Rich - K1HTV


= = =


Date: Thu, 27 Jul 2017 19:52:50 + (UTC)
From: Black Michael mailto:mdblac...@yahoo.com >
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >
Subject: Re: [wsjt-devel] Disabling "Enable TX" only works with "TX1"
Message-ID: <1220099253.558097.1501185170...@mail.yahoo.com 
mailto:1220099253.558097.1501185170...@mail.yahoo.com >
Content-Type: text/plain; charset="utf-8"

Shortcut keys are under Help/Keyboard Shortcuts and F3
de MIke W9MDB--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] More on disabling TX when not answered

2017-07-27 Thread Rich - K1HTV
Using R7965, I noticed that if I answer a station's CQ and my TX frequency is 
more than 10 Hz away from his frequency, if he comes back to another station, 
my "Enable Tx"  is NOT turned off. The result is that I continue to call as the 
station that called CQ as he is working another station. I must manually stop 
my transmissions. 


I can see that if I am more than 50 Hz away, I probably am not causing any 
problems to the CQer. However, if my frequency is within +/- 50 Hz of the 
CQer's frequency I could be causing enough QRM to prevent him from decoding the 
station he is trying to work.


Wouldn't it be better that if the CQer responds to another station, that my TX 
be disabled only if my TX frequency was LESS than +/- 50 Hz from the CQer?


73,

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


[wsjt-devel] Band indicator on separating lines

2017-07-27 Thread Rich - K1HTV
Using R7965, I have Settings/General/Display "Blank line between decoding 
periods" checked. When the band is changed using the band pull down menu, my K3 
changes bands properly and the proper meter band is properly displayed on the 
right side of each line of dashes in the "Band Activity" column. 


However, when the band is changed on the K3 via the radio's  'Band" up/down 
buttons, the name of the band being decoded does not appear on the far right 
side of the separating dashed lines until FOUR 15 second sequencing periods go 
by. 


Is this normal? 


73,

Rich - K1HTV

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


Re: [wsjt-devel] Disabling "Enable TX" only works with "TX1"

2017-07-27 Thread Rich - K1HTV
 

Bill,

   OK, so the key to starting with the TX2 message is to double click on the 
round bullet to the left of TX1 until the message text is greyed out. Then when 
I click on the CQing station's call, the TX1 message is skipped and the TX2 
message is transmitted...got it.


By doing this, now when a station called does NOT come back to my call, even if 
I use the TX2 message, the red "Enable Tx" button goes grey and my further 
calls to that station are stopped.


Thanks.


BTW, I've been reading the WSJT - Revision 7960: guide at:


/branches/wsjtx/doc/user_guide/en

But I haven't yet found where all of the various shortcut keys are defined.


73,

Rich - K1HTV


= = =


Hi Rich,

how are you selecting Tx2 to reply to a CQ call? If you are doing so by
clicking the buttons next to it then WSJT-X will assume you know what
you are doing and are already in a QSO. To use Tx2 to reply to CQ or QRZ
calls you can double-click either of the buttons next to the Tx1 message
to disable it, it will be greyed out to show that and Tx2 will be
automatically used to reply to make initial calls to stations when you
double click a decode.

73
Bill
G4WJS.

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


[wsjt-devel] Disabling "Enable TX" only works with "TX1"

2017-07-26 Thread Rich - K1HTV
Using R7956, Tom is correct in that if the station you called answers another 
station, the "Enable TX" is stopped.  But it is only true if you use the "Tx1" 
message to make the call.


If the TX1 (Calls & Grid) message is skipped and the call is made by using TX2 
(Calls and report), if the station called comes back to another station, the 
"Enable TX" remains red and calling continues on subsequent sequences until the 
"Halt Tx" button is clicked.


I believe that no matter which TX message is being used, "Enable Tx" should be 
turned off automatically if the station I called is in the process of working 
another station.


73,

Rich - K1HTV


= = =
Date: Wed, 26 Jul 2017 15:38:18 -0500
From: Tom-KQ5S mailto:kq5s...@gmail.com >
To: WSJT-Dev mailto:wsjt-devel@lists.sourceforge.net >
Subject: [wsjt-devel] 7956 - Stop Transmitting when Another Station
Answers a CQ
Message-ID:
mailto:CABBJzNijFxppHxbmPZZohYFmmfcnHPHx4tf2=1-25cqjp5k...@mail.gmail.com >
Content-Type: text/plain; charset="utf-8"

Really like how the program will now stop transmitting if another station
beats you answering a CQ call.

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


Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

2017-07-20 Thread Rich - K1HTV
I wouldn't worry about anyone ever being active in grid RR73. It is a water 
grid in the Russian Arctic region. $100 to the first guy to work a legitimate 
maritime mobile station on FT8 from grid RR73 :-). Its a non-problem.

73,
Rich - K1HTV

> On July 20, 2017 at 12:29 PM Bill Somerville  wrote:
>
>
> On 20/07/2017 17:27, Bill Turner wrote:
> > How about R-73 to avoid confusion with grids RR-73?
>
> Hi Bill,
>
> that defeats the purpose of RR73, it is because it is a valid grid that
> two complete callsigns can be sent with it as a standard message. You
> suggestion would require a free text message with a 13 character (inc.
> spaces) size limitation.
>
> 73
> Bill
> G4WJS.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

2017-07-20 Thread Rich - K1HTV
G4WJS.  


Bill,
Regarding the use of "RR73", I believe that it should be formalized as an 
option to the present "73" TX5 message.


Let's look at this senario regarding when a QSO is assumed to be complete:

Station #1 sends Station #2 a report.
Station #2 sends either "RRR" or "RR73" because he has received Station #1's 
"RR-report".


At this point Station #2 believes the QSO is complete because of the rogers he 
has heard in the "RRR" or "RR-report"
which has been received.


But Station #1 still needs to have confirmed that his "RRR" or "RR73" report 
has been received.

This confirmation in the mind of Station#1 is realized if:
1) An "RRR" or "RR73" message is received from #2.
2) He copies Station #2 that he was working immediately calling CQ or 
responding to another station.


In either of these two cases, the contact can be assumed to be complete. There 
would be no need for station #2 to
continue sending either "73" or a repeat of "RR73". I believe that if either 
TX5 messages ("73" or optional "RR73")
is sent, it should only be sent only once, then the TX disabled, if this option 
is checked.


However..if Station #1 does NOT hear Station #2 either calling "CQ" or 
another station, then there will be a
question in his mind of the QSO being complete. This can happen under rapidly 
changing propagation conditions, as
happens on 50 MHz. In that case, I would assume that Station #1 would continue 
sending his "RR-report" in hopes that
Station #2 would see that Station #1 still needed a confirmation. If Station #2 
saw this, he would have to click "TX Enable" and send another "73" or "RR73".


Thanks for the coding that you have been doing to make the WSJT-X suite of 
modes the success that they have become.


73,
Rich - K1HTV


= = =

Date: Thu, 20 Jul 2017 13:18:01 +0100
From: Bill Somerville mailto:g4...@classdesign.com >
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >
Subject: [wsjt-devel] WSJT-X: How to handle using RR73 as a final
message
Message-ID: <83d72269-18c6-a0ee-1f35-f19987dc1...@classdesign.com 
mailto:83d72269-18c6-a0ee-1f35-f19987dc1...@classdesign.com >
Content-Type: text/plain; charset=utf-8; format=flowed

Hi All,

we are looking at changing the WSJT-X logic such that a grid message of
the form:

"  RR73"

is treated as a sign off message.

This has several implications and I need some clarification so that I
can adjust the code. For now I will put aside any potential issues for
holders of compound callsigns as I have not analysed the impact for them
yet.

The first change is already in place, sending such an RR73 message is
treated the same as sending a standard 73 message or any free text
message containing the word "73". This means that, if prompt to log
after 73 is set the log QSO window will be popped up, and if
"Settings->General->Behavior->Disable Tx after 73" is checked, auto
transmit will be disabled and the next message to be sent will be moved
on to Tx6 (CQ message). This part is straightforward.

I propose to add a check box option to "Settings->General->Behavior"
along the lines of "Use RR73 in place of RRR", when checked this would
generate the above RR73 message for the Tx4 (RRR) message, thus
formalizing the usage of RR73 as a final QSO message.

So now the questions. If we have disabled auto Tx and switched the next
message to Tx6/CQ, how do we proceed if no "73" message is received from
ones QSO partner. Listening on the bands it seems that sending an RR73
message has some special significance in that it is always assumed to be
received by ones QSO partner. This may be reasonable in propagation such
that any subsequent messages can be taken by ones QSO partner to mean
that the QSO is indeed complete even if the RR73 message was never decoded.

For example if you have called a station calling CQ, received a report,
sent a R+report and then get no decode from them in the next period;
then the next decode from the other station is a CQ call or them giving
a report to a different station or even calling another station on a
different frequency, then are we safe to assume that our QSO was
complete and there is no requirement to repeat the R+report message (the
normal action if an RRR message is not decoded) or even send a 73
message ourselves? BTW this does beg the question of how a station
running a frequency completes their last QSO on a band, do we take
silence to be an indication that a missed RR73 decode was in fact sent.

The above is fairly easy to implement in that, if an RR73 message is
received from ones QSO partner ones next message will be set to Tx5/73
(note not RR73) and if prompt to log is checked the log QSO window will
pop up. Al

[wsjt-devel] Add "FT8 Contest Mode" option

2017-07-19 Thread Rich - K1HTV
In the recent CQ VHF contest I used both MSK144 and FT8 for making many (110) 
digital contacts. The MSK144 mode already has a checkbox under 
File/Settings/Advanced for "MSK144 Contest Mode" which allowed the transmission 
of grid square reports. There presently is no such option for FT8.


I believe that with the most certain heavy usage of FT8 in future VHF contests, 
it would be a good idea to also make an "FT8 Contest Mode" option available. 
Thanks for your consideration of this for future releases of WSJT-X.


73,
Rich - K1HTV

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


Re: [wsjt-devel] Rovers and FT8

2017-07-18 Thread Rich - K1HTV
Tim,
You are right, as I thump my forehead :-). ! The problem is there, but the ones 
that have the problem are us folks that work the rovers or other stations with 
the slash bar. However as was mentioned, this issue is already being addressed 
an will be resolved in the R2 release of 1.8 in the near future.

73,
Rich - K1HTV


> On July 18, 2017 at 7:07 PM Tim Goeppinger  wrote:
> 
> Rich,
> 
> The problem is that as a rover, the people I contact have to be the ones 
> who have to be on their toes with the mouse clicks, as N6RMJ was for me.  
> There is nothing I can do on my end.
> 73,
> Tim N6GP
> 
> 
> ---------
> From: Rich - K1HTV 
> To: tim...@yahoo.com; WSJT 
> Sent: Tuesday, July 18, 2017 2:34 PM
> Subject: Rovers and FT8
> 
> Tim,
>   I believe that since the "/R" is eliminated from the exchanges, the 
> original "CALL/R" which a station responds to does not match the "CALL" w/o 
> the "/R" which is sent in subsequent steps. Since there isn't a match, it 
> won't automatically proceed to the next step in the sequence. Until/Unless 
> this can be fixed, the answer is to manually step through the steps, which 
> means you will have to always be on your toes with a quick mouse button 
> trigger finger to successfully complete each QSO. I believe that this holds 
> true for any complex station call with a slant bar in it.
> 
> 73,
> Rich - K1HTV
> 
> 
> 
> 
 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Rovers and FT8

2017-07-18 Thread Rich - K1HTV
Tim,

  I believe that since the "/R" is eliminated from the exchanges, the original 
"CALL/R" which a station responds to does not match the "CALL" w/o the "/R" 
which is sent in subsequent steps. Since there isn't a match, it won't 
automatically proceed to the next step in the sequence. Until/Unless this can 
be fixed, the answer is to manually step through the steps, which means you 
will have to always be on your toes with a quick mouse button trigger finger to 
successfully complete each QSO. I believe that this holds true for any complex 
station call with a slant bar in it.


73,

Rich - K1HTV

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


[wsjt-devel] FT8 for the visually impaired

2017-07-14 Thread Rich - K1HTV
Joe and the WSJT-X software development team,

   First, congrats on the superb job you all have done in the creation of the 
new FT8 mode. It works great! In 5 days, while running 50 Watts, a triband yagi 
and wire antenna, I've managed to  work 62 countries using FT8,  including some 
nice catches such as Bahrain, Iraq, Armenia, Japan, Gabon on 20M  and multiple 
VK's on 20M & 40M . I wish that 6 Meter propagation to DX lands would improve 
so we can exercise the mode under multi-hop conditions on the Magic Band.


Its been fun, but, the main reason for this note is a request for you all to 
consider.


One of my fellow DXer friends, with 355 countries confirmed and on the DXCC 
Honor Roll, is interested in using the new FT8 mode but is visually impaired. I 
wonder if there might be a way to make FT8 available to him and other blind 
Radio operators?


Some additional features would need to be incorporated, such as:

- Shortcut keys for various required functions (TX Enable, TX disable, TX6-CQ, 
Monitor ON, etc.)

- If voice output of alpha numeric WAV files is not possible, maybe an ASCII 
output stream could be fed to a second COM port to feed an external 
text-to-voice reader.

- UP/Down function keys to control pointing to lines in the "Band Activity" 
window to be voiced.

- A key to select a chosen line which would then populate the message box and 
activate TX Enable.

- Voice the characters of the line being transmitted so the blind op would know 
the progress of the QSO.

- Although an ALT-Q will manually log a QSO, it would be helpful is there was 
an automatic logging of a completed QSO data into an ADIF file for easy 
uploading to LOTW.


I know that it is important to get solid WSJT-X code for release. But,  once 
this has been done, it would be
great if the WSJT-X team could make the necessary additions so visually 
impaired Hams could use the new FT8 mode.


Thanks in advance for your consideration of this request to help our fellow 
blind Radio Amateurs join in the fun of this new digital mode.


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


Re: [wsjt-devel] FT8 and "Call 1st"

2017-07-12 Thread Rich - K1HTV
Gordon,

   I believe that is that way because once you disable Auto Seq it will 
continue sending your last message over and over and not go to the next step to 
disable TX.


The answer is that if you want to send a free test TX5 message, populate the 
message box and turn off Auto Sequence.   Then proceed the old fashion, JT65 
way, of clicking on the message you want to be sent next until the QSO is 
complete.


73,

Rich - K1HTV


= = =



Send wsjt-devel mailing list submissions to

Date: Wed, 12 Jul 2017 12:38:16 +0100
From: Gordon Higgins mailto:g3pxt1...@gmail.com >
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >
Subject: Re: [wsjt-devel] FT8 and "Call 1st"
Message-ID:
mailto:cadbfavh2ztxabpkqueucsavj4pg45ct-jrfsl_zyk-zudak...@mail.gmail.com >
Content-Type: text/plain; charset="utf-8"

? why in auto seqence will it not send free text tx5 ft8 ?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Disable TX if called stn answers other

2017-07-12 Thread Rich - K1HTV
I agree with Ross, N4RP in the software automatically halting your transmission 
if the station you called came back to another station. The problem is that by 
the time 'wetware'  gets info from eballware which has to scan the screen to 
see if another is calling, and then tell fingerware to determine where eyeware 
says the disable TX button is...by that time you have interfered with the QSO 
in progress.


For that reason, having the WSJT-X software halt your calling the station that 
answered someone else, I believe that the suggested feature be incorporated 
into future releases.


73,

Rich - K1HTV


PS  -  I'm finding FT8 to be great for DXing. In the past 2 days with 50W on HF 
I've already worked 25 countries, the best DX being Australia, Japan, Armenia 
and a contact with a rare one, Iraq.

  

= = =


Date: Wed, 12 Jul 2017 07:15:31 -0400
From: James Shaver (N2ADV) mailto:n2...@windstream.net
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net >
Subject: Re: [wsjt-devel] FT8 and "Call 1st"
Message-ID: mailto:f60d4286-935e-4897-ba37-17cf76847...@windstream.net >
Content-Type: text/plain; charset=utf-8

That's built into the wetware (brain matter) of the person controlling the 
program 😊


> On Jul 11, 2017, at 10:22 PM, Ross Primrose  mailto:n...@n4rp.com > wrote:
> 
> One feature I'd like to see is if you answer a CQ, and the station comes 
> back to someone else, halt tx...
> 
> 73, Ross N4RP
> 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel