Re: [wsjt-devel] Configurations

[Hasan al-Basri]

I use configurations for every mode as well as DXpeditions. They work
great.

*One feature I never understood is the "Clone Into"*

I guessed that it might be a simultaneous Clone and Rename, but I've never
used it.

The way I make new configurations is to start from a known perfectly
working configuration (in my case FT8).

Start with FT8 Config
Configuration > FT8 > Clone
Cursor to: Configuration > FT8 - Copy
> Rename  (Test for my example)
Configuration > Test > Switch To

Now make all the changes for the configuration you are wanting to "save" or
"create"the changes are applied immediately without any save command.
Each change is applied as it is made. e.g. Mode, Radio , Audio, etc. etc.

Select the mode and any other settings you want "remembered" in the new
configuration.

To use the new config: in this example MSK144.

Configuration > MSK144 > Switch To

I have separate configurations for:

FT8
160M JA   (no longer needed)
Default
F+H 9J2LA  (Fox and Hound mode with only their known frequencies)
F+H EX0QR (ditto)
F+H TO7DL (ditto)
FT4
FreqCal
MSK144
WSPR

One can add or delete configs as they are no longer useful, as in the Fox
and Hound DXpeditions shown above.

If there is a better or faster way to do this, let me know and I'll write
all this up as a simple guide and post it to the main list.

73, N0AN

Hasan


On Tue, May 19, 2020 at 6:08 PM Joe Taylor  wrote:

> Hi Ed,
>
> Thanks for your comments, they are much appreciated.  A few comments
> inline below.
>
> On 5/19/2020 4:59 PM, j...@comcast.net N4II wrote:
> > I sense a bit of, er, annoyance on behalf of WSJT-X developers with the
> fact
> > that relatively few users seem to be using Configurations -- at least,
> the
> > solution proposed to a fair number of user interface issues raised here
> > recently seems to be the same:  "Use Configurations".
> >
> > When I first used the software, years ago, I didn't use configurations
> for
> > three reasons:
> >
> > (1)  I couldn't find a list anywhere in the manual of just what
> "settings"
> > were being "configured" (the File/Settings... settings?  To include the
> main
> > window check boxes?  Frequencies?  I still don't know the complete list,
> > even today);
>
> Configurations save all settings that are normally restored after a
> program restart, including which of the defined configurations is
> currently active.
>
> > (2)  The manual didn't explain that I could avoid a lot of UI annoyances
> by
> > doing so, just that "[m]any users prefer to create and use entries on the
> > Configurations menu for switching between modes," without saying why they
> > have that preference; and
> >
> > (3)  The Configurations menu picks didn't seem to do what I *thought* I
> > would want to do to start, which was to CREATE a configuration for the
> > settings I already had, followed by SAVE a configuration.  (I knew I
> didn't
> > want to CLONE anything . . . .)  If one has the manual at hand, one has
> the
> > single-sentence instruction to "Simply Clone the Default entry, Rename
> it as
> > desired, and then make all desired settings for that configuration."  But
> > even then, one has to make an assumption on how the settings are saved,
> > since the manual says nothing about what one has to do to save a
> > configuration (change modes or bands?  Switch to a different
> configuration?
> > Exit the program?).  Without an EDIT menu pick, it's also not at all
> clear
> > how one might modify a configuration to correct an error, which makes
> > experimenting with the feature a high-risk endeavor for new users.
>
> CLONE is a much better description than CREATE for what happens.  You
> should start with a working setup, configured the way you like it for
> some mode.  (If the only entry on your Configuration menu is "Default",
> you might want to rename it as, say FT8.  Or Clone it, and rename the
> copy to FT8.)  There is no need to re-enter most of your setup details.
>
> After making clone, rename it to something sensible, switch to it, and
> then change anything you want to be different in the new configuration.
>
> Modifying a configuration requires nothing more than changing whatever
> you want changed.  The active configuration is saved whenever you
> terminate the program.  The next program restart will put you back where
> you were.
>
> > Note that, when the user has finally found a collection of settings he
> > likes, as currently implemented the configurations feature requires the
> user
> > to go back to the default settings and then change the settings back to
> the
> > values he likes, *again*, in order to create the configuration.  For most
> > new users, all this does is break the software, since they likely have
> not
> > made a list in advance of all the changes they've made from the default.
>
> If you follow the instructions above, nonw of this is true.
>
> > All of these points discourage the new user from experimenting with, and
> > eventually using, the Configuration feature, which 

Re: [wsjt-devel] new version 2.2.

[Hasan al-Basri]

Frank,
It's probably not delay, but the decoder finishing earlier than you expect.
On a crowded band you will see the decoder finish early, then about 2 sec
later, add a few more stations
73, N0AN

(new feature)
Hasan


On Mon, May 18, 2020 at 1:31 AM Frank Hunger  wrote:

> Hi, installing new version yesterday. My rig is : Flex 6400M , dipole,
> Laptop WIN 10 , reference TRX TS 2000
> Observations: after some tries I lost power output of the transmitter (
> after restarting programm the power is back)
> I think I have a little delay before trx begins to transmit
> May be I have some wrong setups.
> I use the programme every day (nerd).
> 73 de Frank DM5KK
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] DB.EXE attachment?

[Hasan al-Basri]

Rich,
Someone may have included a link to my google drive to the file db.exe
which is a signal analysis progrm written by w9mdb that I posted in another
thread a few days ago.

It is a small dos program that looks at your all.txt file and shows the
differences in reports sent and received by band, call, and mode, depending
on the arguments you provide when you run it.

If you need the link, I'll post it again.
73, N0AN
Hasan


On Wed, May 6, 2020 at 7:08 AM Rich Zwirko - K1HTV 
wrote:

> Hi Joe and the WSJT-X Development team.
>   First, thanks for incorporating the Ctrl-R and ALT-R shortcuts and
> other changes into WSJT-X Version 2.2.0-rc1.  Adding they will help the
> blind and visually impaired Hams as they work FT8 using the QLog program
> developed by Sam, W2JDB.  I'm looking forward to testing RC1 when it comes
> out next Monday.
>
> At the end of your recent announcement message I noticed a box with
> "db.exe shared in drive" was included, a 64KB file. I was wonder what it is.
>
> Joe, thanks for your efforts to get 4U1UN on the air. They sure are
> creating some big pileups when they get on the air on FT8.
>
> Although I'm still working plenty of DX with my 75 Watts (4U1UN was FT8
> DXCC entity #271). I'm sure that you all have noticed the increased QRM and
> greater competition from some pretty strong QRO signals. It is becoming
> more and more difficult for many FT8 users to work DX. Both the 20M and 40M
> FT8 frequencies, as you have seen, are really over packed at times. I
> wonder if it may be time to start talking about the creation of well
> defined, and agreed upon, secondary FT8 frequencies, at least on 20 & 40
> Meters.
>
> Hope you are all well in these crazy COVID-19 times. Thanks again to
> the WSJT-X Development Team for making WSJT-X an even greater communication
> tool than ever for its many users.
>
> 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

Re: [wsjt-devel] F/H with the DX calling on 2nd (odd)

[Hasan al-Basri]

When working one of the non-F/H multi-streamers, I would recommend calling
them >1000 Hz above their freq, to keep their area clean.

Basically there are two types of Multi-Streaming operations:

1. F/H which is the WSJT-X Standard
2. All others, including MSHV,  for which you *do not* use F/H mode. Just
call them as normal, but preferably > 1000 Hz above their frq.

I have worked many of them and the software works quite well. Most pick
their own non-standard X freq. A few don't. In both cases, I have had no
trouble working any of them in standard FT8 mode.

Operating tip: Always look for multiple streams from these dx or pseudo-dx
stations. If they are operating inside the normal X frequencies, they are
almost certain to be running MSHV or some other non-F/H compliant software.
Adjust your operating technique accordingly.

...or don't call them if their operation offends you.

73, N0AN
Hasan


On Sat, Mar 14, 2020 at 11:33 AM Rich Zwirko - K1HTV 
wrote:

> John,
>   The station may have been using MSHV or one of the other WSJT-X clones
> which allows the user to transmit multiple streams. Such stations are not
> constrained by having to transmit as a Fox on the even sequence, even
> though you may be seeing them transmitting multiple streams. Unlike WSJT-X
> which requires Hounds to call using tones above 1000 Hz, the cloned
> versions will respond to stations in the entire passband.
>
> So, when you come across these stations, turn off the Hound option and
> respond as you would when making contacts in the normal FT8 way.
>
> 73,
> Rich - K1HTV
> = = =
> NA6L wrote:
>
>  F/H with the DX calling on 2nd (odd)
>From: John V 
>Date: Sat, 14 Mar 2020 11:15:14 EDT
>
> Last night there was a DX station on 160m FT8 FH that I needed. The
> problem was that he was calling on 2nd sequence (odd) and answering on 1st
> (even) rather that 1st sequence. He seemed to be working stations but I
> never figured it out. Other that getting him to change sequence is there
> away to "fool" FT8 FH on my end? Was he using a program other than WSJT-X
> FT8 FH that would allow the Caller to use odd for innating calls?
>
> Thanks, John NA6L
> ___
> 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] 2nd Errror in WSJT-x This Morning

[Hasan al-Basri]

Enclosed my 2nd crash this morning from WSJT-X. I have been getting these
crashes fairly consistently since running the trace version of 2.1.2 to
look at a different problem. Ever since I reinstalled 2.1.2 normal over the
trace version, I have been left with an unstable setup for WSJT-X.
---
conhost.exe - System Error
---
Exception Processing Message 0xc005 Parameters 0x7ff94ed92d58
0x7ff94ed92d58 0x7ff94ed92d58 0x7ff94ed92d58
---
OK
---
Here begins the 2nd error
---
WSJT-X
---
Subprocess Error
---
Subprocess failed with exit code 3
---
OK   Show Details...
---
Running: C:\WSJT\wsjtx\bin\jt9 -s WSJT-X -w 1 -m 3 -e C:\WSJT\wsjtx\bin -a
C:\Users\15152\AppData\Local\WSJT-X -t
C:\Users\15152\AppData\Local\Temp\WSJT-X

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x
#13  0x
#14  0x
#15  0x
#16  0x
#17  0x
#18  0x
#19  0x
#20  0x
#21  0x
#22  0x
#23  0x
fftw: ../../kernel/alloc.c:269: assertion failed: p

Any ideas how to resolve this?

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

Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes

[Hasan al-Basri]

I missed it in the discussion. I've adopted yours and see if it improves.
I just had it happen twice on AO-85 and AO-91 under the old settings of 100
and 200 ms.

Thanks again.
73, N0AN
Hasan


On Sun, Aug 18, 2019 at 5:12 PM Andy Durbin  wrote:

> "What values are you using for Poll and Timeout in OmniRig?"
>
>
> The values were declared in my post.  Here they are again - poll 250,
> timeout 1000, Baud 38,400.
>
> I used my station controller to generate a 'scope trigger when TS-590 data
> was not refreshed within 500 (later changed to 600 ms).   I now have
> multiple 'scope captures that show OmniRig polling sometimes has large
> deviations from the specified poll interval.  In all these cases my TS-590S
> responded to every poll that was issued by OmniRig.
>
> In the most recent event there was a period of 800 ms between routine
> polling frames instead of the specified 250 ms period.   This event
> probably resulted in WSJT-X ver 2.1.0 loss of rig control but, with no time
> stamps in OmniRIg client or in the WSJT-X failure message, that correlation
> is not certain.  It would be helpful if detail "Rig went offline"  included
> a timestamp.
>
> OmniRIg recovers from these excessive poll periods but WSJT-X ver 2.1.0
> does not.  The same configuration of OmniRIg gives no issues with WSJT-X
> ver 2.0.1.
>
> 73,
> Andy, k3wyc
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X ver 2.1.0 spontaneous frequency changes

[Hasan al-Basri]

Andy,
What values are you using for Poll and Timeout in OmniRig?

I'm using 100 ms polling and 200 ms timeout.

I ask because I have been having a problem with transmitting (with an
external radio in FM mode when using SDRC's External Radio capability)

I have played with the Polling and Timeout values, but not see any
change...and this is the 2nd computer I've run this on with the same
behavior. Both Windows10, one Home and Pro.

I'm very suspicious of Omnirig at this point.

While this may seem disconnected with WSJT-X , don't think it is. I think
it is a side-effect of Omni-Rig losing connection to the FT-857D external
radio.

I only use Omni-Rig for this purpose, I don't use it with WSJT-X.

Interestingly, this never happens with SSB or CW modes, only FM. ...and if
I wait a bit, I can resume TX'ing. The symptom is, PTT is asserted, but
their is no RF out.

I'm guessing OmniRig issues, but don't really know how to follow up with it.

Anythoughts that might help?

73, N0AN
Hasan


On Sun, Aug 18, 2019 at 11:43 AM Andy Durbin  wrote:

> I have attempted to use WSJT-X ver 2.1.0 a few more times but continue to
> be plagued by rig control failure messages.   I have found that WSJT-X rig
> control failures are associated with  OmniRig Client declarations  "Status:
> Rig not responding.   However,  OmniRig seems to issue these messages when
> when communication is still good.  For example, with OmniRig  Poll Int =
> 250 and Timeout = 1000, Baud 38400, simply opening the Client "Dialog"
> window and then closing it with "OK" will result in a "Rig not responding"
> message and WSJT-X rig control error.
>
> May I suggest that WSJT-X should be desensitized from these transient
> OmniRig fault reports by only responding if they persist for x seconds.
>
> Typical OmniRig Client Event report:
>
> Dialog VISIBLE
> Rig type: WSJT-X
> Dialog invisible
> Status: Rig is not responding
> Status: Rig is not responding
> Status: Rig is not responding
> Status: On-line
>
> Typical station controller log for WSJT-X recovery from loss of rig
> control:
>
>  1:06:53.976  New IF - IF00010136055  0037502001;
>  1:06:53.985  New FA - FA00010136055;
>  1:06:53.987  New RX freq=10136055
>  1:06:53.988  split offset = 945
>  1:06:54.300  New IF - IF00010136000  0037502001;
>  1:06:54.309  New FA - FA00010136000;
>  1:06:54.311  New RX freq=10136000
>  1:06:54.313  split offset = 1000
>
>
> My station controller is currently set to alarm if TS-590 data is not
> received for 5 seconds.   There is no alarm for events that cause WSJT-X
> ver 2.1.0 to abandon rig control.
>
> BTW - OmniRIg setting "Timeout" does not behave as I had expected.  I
> expected it to re-try for timeout period and then, if no response received,
> declare rig not responding.   What it actually does is send nothing for
> timeout period then resume polling by repeating the command that had no
> response.If it missed a reply that was actually sent then it cannot
> recover until timeout period has elapsed.
>
> None of this is an issue with WSJT-X ver 2.0.1.
>
> 73,
> Andy, k3wyc
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 decodes only on alternate 15-second cycles

[Hasan al-Basri]

I've seen it before and I had to reboot the computer which solved the
problems.

I've also seen pending Windows Updates cause this and other problems. win10
is ready to update, but you have done it. If you Right click to shut down
Win10, it may say Update and Restart.

If it does, it's a sure sing that Win10 is or will become unstable.

73, N0AN
Hasan


On Wed, Jul 31, 2019 at 8:38 PM Josh Rovero  wrote:

> Windows 10 v1903 on i7 CPU, WXJT-X v2.1.0 24fcd1
>
> I run 8 instances of WSJT-X,  7 fed from QS1R and CWSL Tee, 1 from a
> separate SDR.  Not common, but   CPU load is only 30% or so, and
> there's plenty of free RAM.
>
> After an hour or so in FT8 mode, most of the WSJT-X instances only show
> the blue decode indicator (and actually decode signals that are present) on
> alternate cycles (15 and 45 seconds, or 00 and 30 seconds).
>
> Any ideas?
>
> --
> P.J. "Josh" Rovero http://www.roveroresearch.org
> Ham Radio: KK1D http://www.roveroresearch
> .net
> http://www.roveroresearch.info
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

Laurie,

How about this then:

taskkill /IM /T jtalert.exe

That is supposed to not forcefully terminate but issue a WM_CLOSE followed
by telling any Child Process started by the JTA program to also close.

Is that safe? Or what is the proper command line to tell JTALERT.EXE to
close "properly" ?

Once I have that, I can put it in the batch file and JTA will close
gracefully and it can be restarted a few minutes later.

Hasan


On Tue, Jul 30, 2019 at 4:41 PM Hasan al-Basri 
wrote:

> Ok, I'll look at another way to close it.
> Tnx tip, 73, N0AN
> Hasan
>
>
> On Tue, Jul 30, 2019 at 3:53 PM Laurie, VK3AMA <_vk3a...@vkdxer.net>
> wrote:
>
>>
>> On 31/07/2019 2:03 am, Hasan al-Basri wrote:
>>
>> Put this in a batch file: (use notepad to create)
>>
>> taskkill /F /IM jtalert.exe
>>
>>
>> NO, don't do this!
>>
>> Force killing the JTAlert process, rather than a managed shutdown, *doesn't
>> close any of the JTAlert plugin processes or the Decodes History process*,
>> they are all still left running becoming zombie processes.
>>
>> Force killing JTAlert significantly increases the risk of corruption of
>> the config.sqlite database file and the decodes database.
>>
>> de Laurie VK3AMA
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

Ok, I'll look at another way to close it.
Tnx tip, 73, N0AN
Hasan


On Tue, Jul 30, 2019 at 3:53 PM Laurie, VK3AMA <_vk3a...@vkdxer.net> wrote:

>
> On 31/07/2019 2:03 am, Hasan al-Basri wrote:
>
> Put this in a batch file: (use notepad to create)
>
> taskkill /F /IM jtalert.exe
>
>
> NO, don't do this!
>
> Force killing the JTAlert process, rather than a managed shutdown, *doesn't
> close any of the JTAlert plugin processes or the Decodes History process*,
> they are all still left running becoming zombie processes.
>
> Force killing JTAlert significantly increases the risk of corruption of
> the config.sqlite database file and the decodes database.
>
> de Laurie VK3AMA
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

Since I'm replacing this AMD computer with an Intel Core I5 in a short
while, I don't want to invest a ton of time chasing down this problem if it
only affects me and a couple others. It will go away when I change
computers, as I have this same combo running on another machine with no
issues.

In the mean time, here is the work-around I've set up:

Put this in a batch file: (use notepad to create)

taskkill /F /IM jtalert.exe

Mine is called jta_kill.bat
Save to desktop

Use Microsoft Scheduler to Create a Task to Run this program (a.k.a. Batch
File in this case) every day at 1:15 a.m.  (which will stop JTAlert)

Use Microsoft Scheduler to Create another Task in which you tell it run
jtalert.exe with the argument /wsjtx every day at 1:18 a.m. (which will
start JTAlert 3 min after the above kill)

Here is a YouTube video on how to do it, but I used the written
instructions that were below the video:

https://www.youtube.com/watch?v=h1Cc29ZMpr0

This video shows how to create the batch file and use it in Windows
Scheduler to Stop a program. Just create a 2nd scheduled task after this
and have it start JTAlert.exe with the /wsjtx argument.

There is a mistake in the written instructions:
Type "taskill /f /im "*filename*.exe"

Should read: taskkill /F /IM jtalert.exe

No need for the quotes and he forgot a "K" in taskkill

I can't believe how simple it was! While it doesn't solve the mystery, it
covers up the problem as long as X doesn't keep decoding for 24 hours. If
it does hang, it will get fixed at the next run of Scheduler.

73, N0AN

Hasan


On Tue, Jul 30, 2019 at 8:32 AM Black Michael  wrote:

> When it happens again do the WWV recording with Audacity and note the time
> you shut down JTAlert in the recording time indication.
> It has to be doing something to the sound recording --
>
> Having both the Audacity and WAV files would be of use.
>
>
> On Tuesday, July 30, 2019, 08:21:29 AM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> Hi Mike
>
> Never. The monitor (Hi-Sense TV) is on until I go to bed, then I turn the
> TV off. Ever since I found out that there was a JTA > X interaction that
> was causing the problem, I have looked carefully in the morning when I come
> down to the shack to see if X is still decoding...and it is, except on
> those occasions every 2 days or so, when it isn't. This is NOT correlated
> with the monitor going on or off. I have looked at that issue carefully.
>
> *Further this has been going on long before I started using the HDMI TV's
> audio for JTA. I changed it to see if it would solve the issue you and I
> have been discussing (for over a month now).*
>
> I finally made some reliable, reproducible progress. JTA and X are
> interacting in such a way that decoding in X stops and can easily be
> restored by doing nothing more than closing JTA. period.
>
> I can then restart JTA and go for days. Then it will happen again, and the
> solution is the same.
> 73, N0AN
> Hasan
>
>
> On Tue, Jul 30, 2019 at 8:09 AM Black Michael  wrote:
>
> Does your monitor go to sleep?  JTAlert should only be hooking up to the
> playback device so not sure how it could affect recording.  Possible that
> the JTAlert package does passively hook up to recording...that would
> explain why a restart might have an effect on recordingperhaps changing
> the sample rate?
>
> One thing that might be of interest is, when decoding stops, switch the
> rig to WWV and record the WWV signal.  Then restart JTAlert and note the
> time it stops an starts and we can look at the WAV file to see what changes.
>
> Recording with Audacity would be nice.
>
> Mike
>
>
>
> On Tuesday, July 30, 2019, 08:04:14 AM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> Totally different sound cards. JTA uses my HDMI monitor seen as an Nvidia,
> X uses my USB sound dongle. I've changed dongles, ...no difference. I've
> chased the sound card potential issue from several angles...that's not it.
>
> ...and Windows system uses the internal sound card of the computer.
>
> Hasan
>
>
> On Tue, Jul 30, 2019 at 7:43 AM Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> What do you have for the soundcard setting in JTAlert and WSJT-X?
>
>
>
>
> On Tuesday, July 30, 2019, 07:30:17 AM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> Uwe,
> I just changed both those settings you recommended. Now, I'll have to
> wait, up to a couple days to see if it accomplished anything.
>
> Unfortunately the onset of the problem is random, and can take 2 or 3 days
> or only a few hours. Curing it is easy. I'll report back as I'm watching
> it. For sure will post fir

Re: [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

Hi Mike

Never. The monitor (Hi-Sense TV) is on until I go to bed, then I turn the
TV off. Ever since I found out that there was a JTA > X interaction that
was causing the problem, I have looked carefully in the morning when I come
down to the shack to see if X is still decoding...and it is, except on
those occasions every 2 days or so, when it isn't. This is NOT correlated
with the monitor going on or off. I have looked at that issue carefully.

*Further this has been going on long before I started using the HDMI TV's
audio for JTA. I changed it to see if it would solve the issue you and I
have been discussing (for over a month now).*

I finally made some reliable, reproducible progress. JTA and X are
interacting in such a way that decoding in X stops and can easily be
restored by doing nothing more than closing JTA. period.

I can then restart JTA and go for days. Then it will happen again, and the
solution is the same.
73, N0AN
Hasan


On Tue, Jul 30, 2019 at 8:09 AM Black Michael  wrote:

> Does your monitor go to sleep?  JTAlert should only be hooking up to the
> playback device so not sure how it could affect recording.  Possible that
> the JTAlert package does passively hook up to recording...that would
> explain why a restart might have an effect on recordingperhaps changing
> the sample rate?
>
> One thing that might be of interest is, when decoding stops, switch the
> rig to WWV and record the WWV signal.  Then restart JTAlert and note the
> time it stops an starts and we can look at the WAV file to see what changes.
>
> Recording with Audacity would be nice.
>
> Mike
>
>
>
> On Tuesday, July 30, 2019, 08:04:14 AM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> Totally different sound cards. JTA uses my HDMI monitor seen as an Nvidia,
> X uses my USB sound dongle. I've changed dongles, ...no difference. I've
> chased the sound card potential issue from several angles...that's not it.
>
> ...and Windows system uses the internal sound card of the computer.
>
> Hasan
>
>
> On Tue, Jul 30, 2019 at 7:43 AM Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> What do you have for the soundcard setting in JTAlert and WSJT-X?
>
>
>
>
> On Tuesday, July 30, 2019, 07:30:17 AM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> Uwe,
> I just changed both those settings you recommended. Now, I'll have to
> wait, up to a couple days to see if it accomplished anything.
>
> Unfortunately the onset of the problem is random, and can take 2 or 3 days
> or only a few hours. Curing it is easy. I'll report back as I'm watching
> it. For sure will post first failure, if your idea did not work. Thanks for
> the suggestion.
> 73, N0AN
> Hasan
>
>
> On Tue, Jul 30, 2019 at 5:52 AM DG2YCB, Uwe  wrote:
>
> Hi Hasan,
>
>
>
> An interesting observation!  What if you uncheck the boxed “Color Band
> Activity…” and/or “Highlight Band Activity…”? Is the error still there or
> is it gone?
>
>
>
>
>
>
>
> I had in the past also some (other) troubles with JTAlert, but it turned
> out that some files on my computer must have been corrupted. Uninstalled
> JTAlert completely, removed all remaining files manually and the
> reinstalled JTAlert again, and all the errors were gone. Maybe also worth
> to try…
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Hasan al-Basri [mailto:hbasri.schie...@gmail.com]
> *Gesendet:* Dienstag, 30. Juli 2019 12:33
> *An:* WSJT software development
> *Betreff:* [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still
> Present
>
>
>
> First of all, no, the cause is not clock error.
>
>
>
> I have found the "proximate" cause, however, after weeks of hunting. I
> worked with W9MDB and tested/considered many potential causes. I even
> thought I had found it several times. In all those cases there was a
> confounding variable, which I have now isolated. I have found the cure,
> just not the cause, hence I'm posting this info here.
>
>
>
>   I have been fighting this problem for weeks, and finally found a
> *reproducible*  set of actions that cures the problem, immediately every
> time! (until it recurs and then the same steps solve it)
>
>
>
> In this discussion X means the 64 bit 2.01 version of WSJT-X, and JTA
> means JTAlert. (earlier versions of both programs act the same way, since
> installing the first 64 bit version of X. That may have been a coincidence,
> (64 bit install), but what follows is not!
>
>
>
> *I have observed 100%  correlation  between the problem and running both
> programs involved listed below.* I am *not* assigning cause, but some
> sort of interaction

Re: [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

Bobby,
That has always been my setting. (not checked)
tnx, 73, N0AN
Hasan


On Tue, Jul 30, 2019 at 8:03 AM Bobby Chandler  wrote:

> Hasan,
>
> Try this:
>
> On wsjtx go to settings, General. Make sure 'Start new period decodes at
> top' is not ticked.
>
> Bobby/N4AU
> On 7/30/2019 7:26 AM, Hasan al-Basri wrote:
>
> Uwe,
> I just changed both those settings you recommended. Now, I'll have to
> wait, up to a couple days to see if it accomplished anything.
>
> Unfortunately the onset of the problem is random, and can take 2 or 3 days
> or only a few hours. Curing it is easy. I'll report back as I'm watching
> it. For sure will post first failure, if your idea did not work. Thanks for
> the suggestion.
> 73, N0AN
> Hasan
>
>
> On Tue, Jul 30, 2019 at 5:52 AM DG2YCB, Uwe  wrote:
>
>> Hi Hasan,
>>
>>
>>
>> An interesting observation!  What if you uncheck the boxed “Color Band
>> Activity…” and/or “Highlight Band Activity…”? Is the error still there or
>> is it gone?
>>
>>
>>
>>
>>
>>
>>
>> I had in the past also some (other) troubles with JTAlert, but it turned
>> out that some files on my computer must have been corrupted. Uninstalled
>> JTAlert completely, removed all remaining files manually and the
>> reinstalled JTAlert again, and all the errors were gone. Maybe also worth
>> to try…
>>
>>
>>
>> 73 de Uwe, DG2YCB
>>
>>
>>
>> *Von:* Hasan al-Basri [mailto:hbasri.schie...@gmail.com]
>> *Gesendet:* Dienstag, 30. Juli 2019 12:33
>> *An:* WSJT software development
>> *Betreff:* [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still
>> Present
>>
>>
>>
>> First of all, no, the cause is not clock error.
>>
>>
>>
>> I have found the "proximate" cause, however, after weeks of hunting. I
>> worked with W9MDB and tested/considered many potential causes. I even
>> thought I had found it several times. In all those cases there was a
>> confounding variable, which I have now isolated. I have found the cure,
>> just not the cause, hence I'm posting this info here.
>>
>>
>>
>>   I have been fighting this problem for weeks, and finally found a
>> *reproducible*  set of actions that cures the problem, immediately every
>> time! (until it recurs and then the same steps solve it)
>>
>>
>>
>> In this discussion X means the 64 bit 2.01 version of WSJT-X, and JTA
>> means JTAlert. (earlier versions of both programs act the same way, since
>> installing the first 64 bit version of X. That may have been a coincidence,
>> (64 bit install), but what follows is not!
>>
>>
>>
>> *I have observed 100%  correlation  between the problem and running both
>> programs involved listed below.* I am *not* assigning cause, but some
>> sort of interaction between the two programs has got to be the cause, as 
>> *doing
>> what I describe below restores decoding in X every time.*
>>
>>
>>
>> What doesn't work:
>>
>> Stopping X with button.
>>
>> Closing X and restarting it.
>>
>> Closing other running programs like Chrome, SDRC, etc
>>
>>
>>
>> What has cured it every time:
>>
>>
>>
>> * Shut down JTAlert*.
>>
>>
>>
>> Proof:
>>
>>
>>
>> *Every time I found X not decoding, but audio was still showing on the
>> thermometer and also showing on the waterfall*:
>>
>>
>>
>> *I closed JTA and immediately on the very next sequence, X began decoding
>> again*. (On its own, I did no intervention with X at all)  *I could then
>> restart JTA and X would continue to decode for hours, if not days (2 or 3
>> max).* When it eventually stopped decoding again, a simple closing of
>> JTA restored X decoding at the next sequence.
>>
>>
>>
>> So, the stoppages are random, going no more than a few days, *but the
>> cure is not*!
>>
>>
>>
>> This has worked EVERY time since discovering the correlation between X
>> and JTA!
>>
>>
>>
>> Prior to this, the only cure was to reboot the computer.
>>
>>
>>
>> If you are having this problem, and also run JTA, try my solution.
>>
>>
>>
>> I have no idea what the cause might be, but this correlation should give
>> the development team an idea where to look.
>>
>>
>>
>> Win10 Home, 64 bit, AMD Quad Core
>>
>>
>>
>> Also, this does not happen on every computer I have running copies of X
>> and JTA. Not every one of them is using JTA.
>>
>>
>>
>> 73, N0AN
>>
>> Hasan
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
> Bobby chandlerbob...@bellsouth.net
>n...@arrl.net
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

Totally different sound cards. JTA uses my HDMI monitor seen as an Nvidia,
X uses my USB sound dongle. I've changed dongles, ...no difference. I've
chased the sound card potential issue from several angles...that's not it.

...and Windows system uses the internal sound card of the computer.

Hasan


On Tue, Jul 30, 2019 at 7:43 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> What do you have for the soundcard setting in JTAlert and WSJT-X?
>
>
>
>
> On Tuesday, July 30, 2019, 07:30:17 AM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> Uwe,
> I just changed both those settings you recommended. Now, I'll have to
> wait, up to a couple days to see if it accomplished anything.
>
> Unfortunately the onset of the problem is random, and can take 2 or 3 days
> or only a few hours. Curing it is easy. I'll report back as I'm watching
> it. For sure will post first failure, if your idea did not work. Thanks for
> the suggestion.
> 73, N0AN
> Hasan
>
>
> On Tue, Jul 30, 2019 at 5:52 AM DG2YCB, Uwe  wrote:
>
> Hi Hasan,
>
>
>
> An interesting observation!  What if you uncheck the boxed “Color Band
> Activity…” and/or “Highlight Band Activity…”? Is the error still there or
> is it gone?
>
>
>
>
>
>
>
> I had in the past also some (other) troubles with JTAlert, but it turned
> out that some files on my computer must have been corrupted. Uninstalled
> JTAlert completely, removed all remaining files manually and the
> reinstalled JTAlert again, and all the errors were gone. Maybe also worth
> to try…
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Hasan al-Basri [mailto:hbasri.schie...@gmail.com]
> *Gesendet:* Dienstag, 30. Juli 2019 12:33
> *An:* WSJT software development
> *Betreff:* [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still
> Present
>
>
>
> First of all, no, the cause is not clock error.
>
>
>
> I have found the "proximate" cause, however, after weeks of hunting. I
> worked with W9MDB and tested/considered many potential causes. I even
> thought I had found it several times. In all those cases there was a
> confounding variable, which I have now isolated. I have found the cure,
> just not the cause, hence I'm posting this info here.
>
>
>
>   I have been fighting this problem for weeks, and finally found a
> *reproducible*  set of actions that cures the problem, immediately every
> time! (until it recurs and then the same steps solve it)
>
>
>
> In this discussion X means the 64 bit 2.01 version of WSJT-X, and JTA
> means JTAlert. (earlier versions of both programs act the same way, since
> installing the first 64 bit version of X. That may have been a coincidence,
> (64 bit install), but what follows is not!
>
>
>
> *I have observed 100%  correlation  between the problem and running both
> programs involved listed below.* I am *not* assigning cause, but some
> sort of interaction between the two programs has got to be the cause, as 
> *doing
> what I describe below restores decoding in X every time.*
>
>
>
> What doesn't work:
>
> Stopping X with button.
>
> Closing X and restarting it.
>
> Closing other running programs like Chrome, SDRC, etc
>
>
>
> What has cured it every time:
>
>
>
> * Shut down JTAlert*.
>
>
>
> Proof:
>
>
>
> *Every time I found X not decoding, but audio was still showing on the
> thermometer and also showing on the waterfall*:
>
>
>
> *I closed JTA and immediately on the very next sequence, X began decoding
> again*. (On its own, I did no intervention with X at all)  *I could then
> restart JTA and X would continue to decode for hours, if not days (2 or 3
> max).* When it eventually stopped decoding again, a simple closing of JTA
> restored X decoding at the next sequence.
>
>
>
> So, the stoppages are random, going no more than a few days, *but the
> cure is not*!
>
>
>
> This has worked EVERY time since discovering the correlation between X and
> JTA!
>
>
>
> Prior to this, the only cure was to reboot the computer.
>
>
>
> If you are having this problem, and also run JTA, try my solution.
>
>
>
> I have no idea what the cause might be, but this correlation should give
> the development team an idea where to look.
>
>
>
> Win10 Home, 64 bit, AMD Quad Core
>
>
>
> Also, this does not happen on every computer I have running copies of X
> and JTA. Not every one of them is using JTA.
>
>
>
> 73, N0AN
>
> Hasan
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net

Re: [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

Uwe,
I just changed both those settings you recommended. Now, I'll have to wait,
up to a couple days to see if it accomplished anything.

Unfortunately the onset of the problem is random, and can take 2 or 3 days
or only a few hours. Curing it is easy. I'll report back as I'm watching
it. For sure will post first failure, if your idea did not work. Thanks for
the suggestion.
73, N0AN
Hasan


On Tue, Jul 30, 2019 at 5:52 AM DG2YCB, Uwe  wrote:

> Hi Hasan,
>
>
>
> An interesting observation!  What if you uncheck the boxed “Color Band
> Activity…” and/or “Highlight Band Activity…”? Is the error still there or
> is it gone?
>
>
>
>
>
>
>
> I had in the past also some (other) troubles with JTAlert, but it turned
> out that some files on my computer must have been corrupted. Uninstalled
> JTAlert completely, removed all remaining files manually and the
> reinstalled JTAlert again, and all the errors were gone. Maybe also worth
> to try…
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Hasan al-Basri [mailto:hbasri.schie...@gmail.com]
> *Gesendet:* Dienstag, 30. Juli 2019 12:33
> *An:* WSJT software development
> *Betreff:* [wsjt-devel] Loss of Decoding in WSJT-X with Audio Still
> Present
>
>
>
> First of all, no, the cause is not clock error.
>
>
>
> I have found the "proximate" cause, however, after weeks of hunting. I
> worked with W9MDB and tested/considered many potential causes. I even
> thought I had found it several times. In all those cases there was a
> confounding variable, which I have now isolated. I have found the cure,
> just not the cause, hence I'm posting this info here.
>
>
>
>   I have been fighting this problem for weeks, and finally found a
> *reproducible*  set of actions that cures the problem, immediately every
> time! (until it recurs and then the same steps solve it)
>
>
>
> In this discussion X means the 64 bit 2.01 version of WSJT-X, and JTA
> means JTAlert. (earlier versions of both programs act the same way, since
> installing the first 64 bit version of X. That may have been a coincidence,
> (64 bit install), but what follows is not!
>
>
>
> *I have observed 100%  correlation  between the problem and running both
> programs involved listed below.* I am *not* assigning cause, but some
> sort of interaction between the two programs has got to be the cause, as 
> *doing
> what I describe below restores decoding in X every time.*
>
>
>
> What doesn't work:
>
> Stopping X with button.
>
> Closing X and restarting it.
>
> Closing other running programs like Chrome, SDRC, etc
>
>
>
> What has cured it every time:
>
>
>
> * Shut down JTAlert*.
>
>
>
> Proof:
>
>
>
> *Every time I found X not decoding, but audio was still showing on the
> thermometer and also showing on the waterfall*:
>
>
>
> *I closed JTA and immediately on the very next sequence, X began decoding
> again*. (On its own, I did no intervention with X at all)  *I could then
> restart JTA and X would continue to decode for hours, if not days (2 or 3
> max).* When it eventually stopped decoding again, a simple closing of JTA
> restored X decoding at the next sequence.
>
>
>
> So, the stoppages are random, going no more than a few days, *but the
> cure is not*!
>
>
>
> This has worked EVERY time since discovering the correlation between X and
> JTA!
>
>
>
> Prior to this, the only cure was to reboot the computer.
>
>
>
> If you are having this problem, and also run JTA, try my solution.
>
>
>
> I have no idea what the cause might be, but this correlation should give
> the development team an idea where to look.
>
>
>
> Win10 Home, 64 bit, AMD Quad Core
>
>
>
> Also, this does not happen on every computer I have running copies of X
> and JTA. Not every one of them is using JTA.
>
>
>
> 73, N0AN
>
> Hasan
> ___
> 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] Loss of Decoding in WSJT-X with Audio Still Present

[Hasan al-Basri]

First of all, no, the cause is not clock error.

I have found the "proximate" cause, however, after weeks of hunting. I
worked with W9MDB and tested/considered many potential causes. I even
thought I had found it several times. In all those cases there was a
confounding variable, which I have now isolated. I have found the cure,
just not the cause, hence I'm posting this info here.

  I have been fighting this problem for weeks, and finally found a
*reproducible*  set of actions that cures the problem, immediately every
time! (until it recurs and then the same steps solve it)

In this discussion X means the 64 bit 2.01 version of WSJT-X, and JTA means
JTAlert. (earlier versions of both programs act the same way, since
installing the first 64 bit version of X. That may have been a coincidence,
(64 bit install), but what follows is not!

*I have observed 100%  correlation  between the problem and running both
programs involved listed below.* I am *not* assigning cause, but some sort
of interaction between the two programs has got to be the cause, as *doing
what I describe below restores decoding in X every time.*

What doesn't work:
Stopping X with button.
Closing X and restarting it.
Closing other running programs like Chrome, SDRC, etc

What has cured it every time:

* Shut down JTAlert*.

Proof:

*Every time I found X not decoding, but audio was still showing on the
thermometer and also showing on the waterfall*:

*I closed JTA and immediately on the very next sequence, X began decoding
again*. (On its own, I did no intervention with X at all)  *I could then
restart JTA and X would continue to decode for hours, if not days (2 or 3
max).* When it eventually stopped decoding again, a simple closing of JTA
restored X decoding at the next sequence.

So, the stoppages are random, going no more than a few days, *but the cure
is not*!

This has worked EVERY time since discovering the correlation between X and
JTA!

Prior to this, the only cure was to reboot the computer.

If you are having this problem, and also run JTA, try my solution.

I have no idea what the cause might be, but this correlation should give
the development team an idea where to look.

Win10 Home, 64 bit, AMD Quad Core

Also, this does not happen on every computer I have running copies of X and
JTA. Not every one of them is using JTA.

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

Re: [wsjt-devel] FT4 Default Frequencies

[Hasan al-Basri]

Well said and to the point.

Perhaps the most important thing to understand is that this is an
experimental and adjustment time for FT4 that will (and needs to) fade
away. It's use after the current fascination with it subsides, needs to be
reserved for contests only.

Its only advantage is speed. It is less sensitive and more bandwidth hungry
than FT8.

The problem: the perceived "need for speed", becomes expected making FT8
seem downright slow.

Unless strongly discouraged by people held in respect by those inclined to
run this mode outside contests, it will gain a following. People lack
patience and seem to have a preference for immediate gratification.

F + H was extolled as a  dxpedition mode. Now it is showing up from
everyone who thinks they are important enough to justify it. FT4 was
developed for contests, will the same trend of unintended consequences
continue?

Most likely it will, no matter what the developers say their intent was.

A lockout, except for pre-approved contests would be appropriate, but is
loaded with its own set of unintended consequences, and obvious loopholes.

User education and peer pressure may be the only option left, however
historically ineffective they have been.

73, N0AN

Hasan

On Thu, Jul 18, 2019, 8:49 AM Ed Muns  wrote:

> I find the words "pretty inconsiderate or pretty ignorant" to be insulting
> and inflammatory, regardless of context.  And, they add no value to the
> discussion.
>
> For example, one could say that "users are pretty inconsiderate or pretty
> ignorant of the intended purpose of FT4" and the dialogue would be
> distracted from an important point.
>
> The use of FT4 during a highly active contest is different than using it
> in everyday operating.  There are specific frequency claims or "band plans"
> for virtually all of our HF spectrum.  Attempting to carve out everyday
> slots for yet another use (FT4) is extremely difficult and invites
> unnecessary controversy.
>
> On the other hand, a precedent exists from the long-standing convention of
> spectrum utilization during contests.  In major CW contests, operation
> extends into the digital portions of the everyday band plan.  In RTTY
> contests, the same happens in the everyday CW operating areas.  It is
> generally accepted that extensive use of the our HF spectrum during
> contests is a good thing for all amateur interests and a worthwhile
> compromise of everyday frequency usage.
>
> FT4 is a slightly adjusted companion to FT8 intended for a specific
> application.  There is little need to use it outside of contesting.  For
> non-contest usage, FT8 is more sensitive and narrower bandwidth.  Twice the
> cycle time is a negligible cost in daily operation.
>
> Similarly, the WSJT-X team gave us Fox and Hound mode intended exclusively
> for DXpeditions.  The QSO rate benefit comes at the cost of the radio
> generating significant IMD around the resulting RF signals.  In this
> specific DXpedition application, that IMD is confined to a small portion of
> the sub-band where no one is affected by the signal quality.  It is our
> responsibility as users to respect that intended use of Fox and Hound mode,
> lest we knowingly cause QRM to other users.  Multiple "foxes" distributed
> throughout the FT sub-band would subject most users to the ill-effects of
> unnecessary IMD.
>
> As users, we can choose to set a convention of using FT8 for everyday
> operation and reserve FT4 for contests.  Wouldn't that be a better use of
> our hobby time than exacerbating the ongoing bandplan conflicts?
>
> Ed W0YK
>
>
>
> -Original Message-
> From: Jim Brown 
> Sent: 17 July, 2019 14:52
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] FT4 Default Frequencies
>
> On 7/17/2019 12:14 PM, Joe Taylor wrote:
> > out frequencies we have suggested are made by people who have been
> > silent when we've asked for community input.  It's not helpful to call
> > those who have worked hard to come up with acceptable defaults
> > "inconsiderate" or "ignorant" -
>
> Out of context quotation! You could be a politician. :) I said "either
> pretty inconsiderate or pretty ignorant of long established practice on
> the band."
>
> Ignorant of long established practice on the band" is quite different
> from "ignorant."
>
> And I stand by my comments. General practice on 40M has long been for
> digital operation above 7070 kHz. Yes, FT4 is INTENDED for contesting,
> but many hams will use it simply because it'd the latest and greatest,
> or because it gets the buzz. N4TM noted that 7072 was proposed earlier,
> but seems to have been rejected.
>
> As to my failing to make suggestions -- I spend a LOT of time making my
> own contributions to ham radio.
>
> 73, Jim K9YC
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> ___
> wsjt-devel mailing 

Re: [wsjt-devel] WSJT-X 2.1.0 64-bit GA release: TX audio level has changed

[Hasan al-Basri]

yes, had to go to 100% but works just fine
73, N0AN
Hasan


On Mon, Jul 15, 2019 at 4:09 PM Jim Record  wrote:

> Yes. I had to push it to almost 100% and push the Windows Pro 10 audio to
> 60%.
>
> On Mon, Jul 15, 2019 at 9:52 AM DG2YCB, Uwe  wrote:
>
>> Many thanks for the new GA version! Works well so far here on my computer
>> (64-bit Windows).
>> One observation: With the new 64-bit GA version I needed to increase PWR
>> slider from around 50 % to now nearly 100 % to get sufficient audio level
>> at
>> my FT-991. Old settings resulted in a few mW TX output. Will do some
>> further
>> tests, but seems to be reproducible.
>> Anyone else experiencing that with the 64-bit version?
>>
>> 73 de Uwe, DG2YCB
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> --
> Jim Record
> *Firgenholt Joyner*
> (Old English (sort of) for Mountain Wood Joiner)
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.0 64-bit GA release: TX audio level has changed

[Hasan al-Basri]

Yes, same here, my power slider now has to be set at maximum to just barely
tickle the ALC on my TS-590sg. Not a problem, just different from some of
the prior versions...in fact a recent debug version showed the same
characteristic, requiring power slider to be at max with Speaker Output
level at 0 dB.

Again, not a problem, just a change in behavior. Program (64 bit Win10) is
doing very, very well on both fT8 and FT4

Will try msk144 on 6m in the morning.
73, N0AN
Hasan


On Mon, Jul 15, 2019 at 2:20 PM DG2YCB, Uwe  wrote:

> For comparison I am running the 32-bit and the 64-bit version of WSJT-X
> v2.1.0 GA concurrently. PWR sliders of both versions are set to about 50%
> (= -20.1 dB transmit digital gain). To reach in both cases the same TX PWR
> output at my Yaesu FT-991 I have to increase Windows Volume Control from 7
> for all the 32-bit versions (and for 64-bit until 2.1.0-rc7) to about 80
> for the new 64-bit GA release of WSJT-X. Although with that the audio level
> can be adjusted, this means a big difference in digital audio gain between
> the two versions. What may cause this difference? Is there another bug in
> QT 5.12.4? Or might there be a defect in the new 64-bit GA version of 2.1.0?
>
>
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Paul Kube [mailto:paul.k...@gmail.com]
> *Gesendet:* Montag, 15. Juli 2019 18:19
> *An:* WSJT software development
> *Betreff:* Re: [wsjt-devel] WSJT-X 2.1.0 64-bit GA release: TX audio
> level has changed
>
>
>
> >  Anyone else experiencing that with the 64-bit version?
>
>
>
> Yes.
>
>
>
> Tune power also.
>
>
>
> IC-7300, Win 10 x64 Pro.
>
>
>
> 73, Paul K6PO
>
>
>
>
>
> On Mon, Jul 15, 2019 at 8:52 AM DG2YCB, Uwe  wrote:
>
> Many thanks for the new GA version! Works well so far here on my computer
> (64-bit Windows).
> One observation: With the new 64-bit GA version I needed to increase PWR
> slider from around 50 % to now nearly 100 % to get sufficient audio level
> at
> my FT-991. Old settings resulted in a few mW TX output. Will do some
> further
> tests, but seems to be reproducible.
> Anyone else experiencing that with the 64-bit version?
>
> 73 de Uwe, DG2YCB
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

OK, Mike; it failed at 054430 last night:

054430 -9 -0.1 1767 ~ EA4LU WA2VCQ EL87

40.463 dataSink1 33/50, k=114048, dT=3ms, catchup


Test Run Stared (timestamp of first saved file) on:


07/05/2019 @ 0956


the last decode I have in save file is timestamped:


07/07/2019 0200


Curiously,there is a big gap between it and 2nd to last save file:


07/07/2019 0044


I don't know why the last saved file is an hour and 16 minutes after the
2nd to lastI guess it could be that 40m was very quiet at that time,
but I'm skeptical.


Let me know if you need any of the saved files and if so, which ones.


Note;

Failure was identical to all others. Decoding stopped, now Blue Decode
light does not come on.


Audio Thermometer is normal , sigs show on waterfall.


Here is a question:


If this is a single catchup eror, why doesn't X just reset itself and
resume on the next sequence? ...and why would it require reboot to get X
working again?


I tried shutting down and restarting, same issue, which is what I noticed
b4, once it fails, only a reboot restores decoding.


73, N0AN

On Sat, Jul 6, 2019 at 10:32 PM Black Michael  wrote:

> You can run a 2nd copy of WSJT-X (perhaps the other version that had
> problems?) and see if it locks up.
>
> Just add the -r option and pick a name
>
> wsjtx -r test
>
> de Mike W9MDB
>
>
>
>
> On Saturday, July 6, 2019, 04:57:44 PM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> 31 hours and counting since I installed the debug version you sent me the
> link to. No errors. Will report more tomorrow morning.
> I can't imagine that this install somehow fixed the issue?
> 73, N0AN
> Hasan
>
>
> On Sat, Jul 6, 2019 at 2:38 PM Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> What web browser do you use?  There aren't a lot of these report so it
> doesn't seem like this is a common problem otherwise we'd hear more about
> it5.
>
> There has to be something in common.
>
> So what does your audio path look like?  Rig, sound card, USB Hub?, PC
> model.
>
> de Mike W9MDB
>
>
>
>
> On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel 
> wrote:
>
>
> Your observations match those I have seen for about a year.  I've tried to
> find a common set of circumstances that always cause the failure but have
> had no luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check
> band performance over a long time period.  After a random amount of time,
> WSJT-X come to a halt.  Specifically the Wide Graph Display and the Band
> Activity Display stop updating.  The UTC in the Wide Graph Display no
> longer matches the UTC in the bottom left portion of the Main window.
> There is no correlation between the activity on the band and the time it
> takes to hang.  Rarely does it not hang.
>
> As a software developer this has all the hallmarks of a race condition
> failure.  Two (or more) threads update a shared resource without using a
> LOCK, UPDATE, UNLOCK sequence.  During a thread context swap one of the
> threads reads the value, loses control to another thread that updates the
> value, then the first thread gets scheduled and writes back its stale
> value.  The result is undefined behavior.
>
> Most of the time there is no conflict.  Even under a heavy load.  Then it
> fails unexpectedly.  This makes it extremely difficult to debug.
>
> To recover I have to exit out of WSJT-X and restart it.
>
> This might not be the root cause but I would put it high on my list of the
> usual suspects.
>
> 73, Rick
> WK1P
>
>
> --
> *From:* Peter Putnam 
> *Sent:* Wednesday, July 3, 2019 3:06 PM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* [wsjt-devel] WSJT Audio Input Loss
>
> Greetings,
>
> I have been using WSJT-X quite successfully for several years during
> June VHF Contests. I experienced a failure of the WSJT program to accept
> received audio input after several hours of proper operation during the
> recent Field Day exercise.
>
> I'll provide a brief outline and reply with more detail, should it be
> needed.
>
> My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The
> WSJT-X software version is 2.0.1 7ddcb7.
>
> My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX"
> program that interfaces various applications that wish to receive the
> audio stream. WSJT accepts the stream and displays results on the Wide
> Graph and a small audio signal-strength window. Activity proceeded
> normally for the first three hours of Field Day, until both the Wide
> Graph and the audio signal-strength stopped showing any incoming audio.
>
> I can't offer any help on what might have caused the 

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

31 hours and counting since I installed the debug version you sent me the
link to. No errors. Will report more tomorrow morning.
I can't imagine that this install somehow fixed the issue?
73, N0AN
Hasan


On Sat, Jul 6, 2019 at 2:38 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> What web browser do you use?  There aren't a lot of these report so it
> doesn't seem like this is a common problem otherwise we'd hear more about
> it5.
>
> There has to be something in common.
>
> So what does your audio path look like?  Rig, sound card, USB Hub?, PC
> model.
>
> de Mike W9MDB
>
>
>
>
> On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel 
> wrote:
>
>
> Your observations match those I have seen for about a year.  I've tried to
> find a common set of circumstances that always cause the failure but have
> had no luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check
> band performance over a long time period.  After a random amount of time,
> WSJT-X come to a halt.  Specifically the Wide Graph Display and the Band
> Activity Display stop updating.  The UTC in the Wide Graph Display no
> longer matches the UTC in the bottom left portion of the Main window.
> There is no correlation between the activity on the band and the time it
> takes to hang.  Rarely does it not hang.
>
> As a software developer this has all the hallmarks of a race condition
> failure.  Two (or more) threads update a shared resource without using a
> LOCK, UPDATE, UNLOCK sequence.  During a thread context swap one of the
> threads reads the value, loses control to another thread that updates the
> value, then the first thread gets scheduled and writes back its stale
> value.  The result is undefined behavior.
>
> Most of the time there is no conflict.  Even under a heavy load.  Then it
> fails unexpectedly.  This makes it extremely difficult to debug.
>
> To recover I have to exit out of WSJT-X and restart it.
>
> This might not be the root cause but I would put it high on my list of the
> usual suspects.
>
> 73, Rick
> WK1P
>
>
> --
> *From:* Peter Putnam 
> *Sent:* Wednesday, July 3, 2019 3:06 PM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* [wsjt-devel] WSJT Audio Input Loss
>
> Greetings,
>
> I have been using WSJT-X quite successfully for several years during
> June VHF Contests. I experienced a failure of the WSJT program to accept
> received audio input after several hours of proper operation during the
> recent Field Day exercise.
>
> I'll provide a brief outline and reply with more detail, should it be
> needed.
>
> My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The
> WSJT-X software version is 2.0.1 7ddcb7.
>
> My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX"
> program that interfaces various applications that wish to receive the
> audio stream. WSJT accepts the stream and displays results on the Wide
> Graph and a small audio signal-strength window. Activity proceeded
> normally for the first three hours of Field Day, until both the Wide
> Graph and the audio signal-strength stopped showing any incoming audio.
>
> I can't offer any help on what might have caused the problem. It was
> abrupt and seemingly unrelated to any other system actions. I am unable
> to reproduce the problem.
>
> Several operators spent several hours speculating about what a solution
> might be. Program restarts and computer re-boots (time-tested favorite
> of generations) changed nothing. The only useful clue was that the DAX
> audio output stream was present and could be re-directed to Fldigi, but
> not to WSJT-X.
>
> I was able to restore operation for a brief period by stopping WSJT,
> renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour.
> Repeating the procedure provided operation for the rest of Field Day.
>
> The two .ini files that were renamed are available for your inspection,
> along with the one that continued to function.
>
> Any suggestions you can offer to prevent a recurrence would be greatly
> appreciated.
>
> Regards,
> Peter
> NI6E
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
>
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0
> 
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

Not an issue, I monitor CPU at all times, and keep in mind, once it stops
decoding, even one time, it never resumes without a reboot.
73, N0AN
Hasan


On Fri, Jul 5, 2019 at 10:14 AM Roy Gould  wrote:

> I have had the problem of the Decode button not coming on after the end of
> a receive interval. In my case I found the problem to be that the computer
> was being overloaded by high CPU usage of a web browser. This occurred with
> Edge, Chrome, or Firefox. This high CPU usage was seen by Task Manager. The
> solution was to close the web browser.  What does Task Manager reveal in
> your case?
>
> On Fri, Jul 5, 2019 at 8:59 AM Hasan al-Basri 
> wrote:
>
>> Ok, I'll check it out.
>>
>> Downloading now, then will install right over the top of my existing 2.01
>> Tnx
>> 73, N0AN
>>
>> Hasan
>>
>>
>> On Fri, Jul 5, 2019 at 7:46 AM Black Michael  wrote:
>>
>>> This is version 2.0.1 with dropout debugging.
>>> If the decode light is not flashing then it sounds like you may have
>>> audio dropouts occurring.
>>> This version will show you when it fails with messages in the band
>>> activity window about "dropout".  You'll see a few messages on startup
>>> which is normal as the audio catches up.
>>>
>>>
>>> https://www.dropbox.com/s/isxwjybws1i8u6f/wsjtx-2.0.1-win32-dropouts.exe?dl=1
>>>
>>> de Mike W9MDB
>>>
>>>
>>> On Friday, July 5, 2019, 04:45:38 AM CDT, Hasan al-Basri <
>>> hbasri.schie...@gmail.com> wrote:
>>>
>>>
>>> Ok Mike, it decoded for > 24 hours but then stopped early this morning
>>> just before I got to the shack.
>>>
>>> Started 07/03/2019 @ 1723
>>> Stopped 07/05/2019 @ 0407 Both local
>>>
>>> These are the file saved dates. Again, I had to reboot a few minutes ago
>>> to get it to start saving files/decoding again.
>>>
>>> The rig was unattended from about 6 p.m. last  night until 4:19 a.m.
>>> when I came down to see if it was still decoding...I noticed it had stopped
>>> decoding 12 minutes b4 I got down here.
>>>
>>> Another symptom: When it stops decoding incoming signals, the Blue
>>> Decode light does NOT flash at the end of a sequence, ...even though the
>>> thermometer and the waterfall show sigs for the full sequence.
>>>
>>> Any other suggestions?
>>> 73, N0AN
>>> Hasan
>>>
>>>
>>> On Thu, Jul 4, 2019 at 5:35 AM Hasan al-Basri 
>>> wrote:
>>>
>>> Ok, I'll check it out. Time is perfect and always is, I'm GPS locked to
>>> it.
>>>
>>> When I got down here this morning it was still decoding full fill of
>>> JTAlert. ...but it's only been 12 hours. (I did the remove driver, unplug
>>> it and let Win10 reinstall it at a reboot) . That's where I am now in my
>>> test.)
>>>
>>> Save none was checked, I just checked Save All, will provide if needed.
>>>
>>> Here's hoping...
>>>
>>> 73, N0AN
>>> Hasan
>>>
>>>
>>> On Wed, Jul 3, 2019 at 10:37 PM Black Michael 
>>> wrote:
>>>
>>> We seem to be hearing problems with a few people on both 2.0.1 and
>>> 2.1.0-rc7.
>>> 2.0.1 has been out for a long time and if this was common I'd think we
>>> would have heard a lot more reports of the problem.
>>> Upgrading to 2.1.0-rc7 and back to 2.0.1 should (and I emphasize should)
>>> just revert completely back to 2.0.1 thought there is a bug with FT4 in
>>> that case.
>>>
>>> The common thread probably is Windows updatesor time is off.  Check
>>> http://time.is to ensure you're time is reported as "Exact".
>>>
>>> If you see waterfall activity but no decodes on of three things is
>>> likely happening.
>>>
>>> #1 Time is off
>>> #2 WAV files are not being recorded.  Ensure Save/All is checked and see
>>> if WAV files are showing up in the Save folder.  One user found using
>>> Remote Desktop that audio files weren't being saved.  TeamViewer worked
>>> though.
>>> #3 Audio corrupted.  If WAV files are showing up but not decoding and
>>> your time is correct then send in a few audio files so we can look at them.
>>>
>>> de Mike W9MDB
>>>
>>>
>>>
>>>
>>> On Wednesday, July 3, 2019, 10:27:56 PM CDT, Tod Farrell WE5TR <
>>> we5t...@gmail.com> wrote:
>>>
>>>

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

INstalled and running Mike. Will watch for it...when it fails, it stays
failed, so all I have to do is watch the Save directory last decode having
started just now. Probably wont show until tomorrow. It'w working fine now,
but it does for hours before the first freak out.
73, N0AN
Hasan


On Fri, Jul 5, 2019 at 9:53 AM Hasan al-Basri 
wrote:

> Ok, I'll check it out.
>
> Downloading now, then will install right over the top of my existing 2.01
> Tnx
> 73, N0AN
>
> Hasan
>
>
> On Fri, Jul 5, 2019 at 7:46 AM Black Michael  wrote:
>
>> This is version 2.0.1 with dropout debugging.
>> If the decode light is not flashing then it sounds like you may have
>> audio dropouts occurring.
>> This version will show you when it fails with messages in the band
>> activity window about "dropout".  You'll see a few messages on startup
>> which is normal as the audio catches up.
>>
>>
>> https://www.dropbox.com/s/isxwjybws1i8u6f/wsjtx-2.0.1-win32-dropouts.exe?dl=1
>>
>> de Mike W9MDB
>>
>>
>> On Friday, July 5, 2019, 04:45:38 AM CDT, Hasan al-Basri <
>> hbasri.schie...@gmail.com> wrote:
>>
>>
>> Ok Mike, it decoded for > 24 hours but then stopped early this morning
>> just before I got to the shack.
>>
>> Started 07/03/2019 @ 1723
>> Stopped 07/05/2019 @ 0407 Both local
>>
>> These are the file saved dates. Again, I had to reboot a few minutes ago
>> to get it to start saving files/decoding again.
>>
>> The rig was unattended from about 6 p.m. last  night until 4:19 a.m. when
>> I came down to see if it was still decoding...I noticed it had stopped
>> decoding 12 minutes b4 I got down here.
>>
>> Another symptom: When it stops decoding incoming signals, the Blue Decode
>> light does NOT flash at the end of a sequence, ...even though the
>> thermometer and the waterfall show sigs for the full sequence.
>>
>> Any other suggestions?
>> 73, N0AN
>> Hasan
>>
>>
>> On Thu, Jul 4, 2019 at 5:35 AM Hasan al-Basri 
>> wrote:
>>
>> Ok, I'll check it out. Time is perfect and always is, I'm GPS locked to
>> it.
>>
>> When I got down here this morning it was still decoding full fill of
>> JTAlert. ...but it's only been 12 hours. (I did the remove driver, unplug
>> it and let Win10 reinstall it at a reboot) . That's where I am now in my
>> test.)
>>
>> Save none was checked, I just checked Save All, will provide if needed.
>>
>> Here's hoping...
>>
>> 73, N0AN
>> Hasan
>>
>>
>> On Wed, Jul 3, 2019 at 10:37 PM Black Michael 
>> wrote:
>>
>> We seem to be hearing problems with a few people on both 2.0.1 and
>> 2.1.0-rc7.
>> 2.0.1 has been out for a long time and if this was common I'd think we
>> would have heard a lot more reports of the problem.
>> Upgrading to 2.1.0-rc7 and back to 2.0.1 should (and I emphasize should)
>> just revert completely back to 2.0.1 thought there is a bug with FT4 in
>> that case.
>>
>> The common thread probably is Windows updatesor time is off.  Check
>> http://time.is to ensure you're time is reported as "Exact".
>>
>> If you see waterfall activity but no decodes on of three things is likely
>> happening.
>>
>> #1 Time is off
>> #2 WAV files are not being recorded.  Ensure Save/All is checked and see
>> if WAV files are showing up in the Save folder.  One user found using
>> Remote Desktop that audio files weren't being saved.  TeamViewer worked
>> though.
>> #3 Audio corrupted.  If WAV files are showing up but not decoding and
>> your time is correct then send in a few audio files so we can look at them.
>>
>> de Mike W9MDB
>>
>>
>>
>>
>> On Wednesday, July 3, 2019, 10:27:56 PM CDT, Tod Farrell WE5TR <
>> we5t...@gmail.com> wrote:
>>
>>
>> Similar issue here on 2.0.1, win10, and flex6700 after a long operating
>> session or even a long monitoring session. I.e. I’ll leave the shack
>> powered up monitoring a band while I’m at work or elsewhere in the house.
>>
>> When I come back sometimes the waterfall is showing activity, dT is good,
>> time.is is good, but no decodes.
>> Other times it’s that clicking transit or tune causes no generated audio
>> to the DAX  software which has a meter that shows me no incoming audio is
>> present from WSJT-X.
>>
>> Typically corrected with a WSJT-X restart
>>
>> --
>> 73
>>
>> TodWE5TR
>> While mobile
>>
>> On Jul 3, 2019, at 16:52, Hasan a

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

Ok, I'll check it out.

Downloading now, then will install right over the top of my existing 2.01
Tnx
73, N0AN

Hasan


On Fri, Jul 5, 2019 at 7:46 AM Black Michael  wrote:

> This is version 2.0.1 with dropout debugging.
> If the decode light is not flashing then it sounds like you may have audio
> dropouts occurring.
> This version will show you when it fails with messages in the band
> activity window about "dropout".  You'll see a few messages on startup
> which is normal as the audio catches up.
>
>
> https://www.dropbox.com/s/isxwjybws1i8u6f/wsjtx-2.0.1-win32-dropouts.exe?dl=1
>
> de Mike W9MDB
>
>
> On Friday, July 5, 2019, 04:45:38 AM CDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> Ok Mike, it decoded for > 24 hours but then stopped early this morning
> just before I got to the shack.
>
> Started 07/03/2019 @ 1723
> Stopped 07/05/2019 @ 0407 Both local
>
> These are the file saved dates. Again, I had to reboot a few minutes ago
> to get it to start saving files/decoding again.
>
> The rig was unattended from about 6 p.m. last  night until 4:19 a.m. when
> I came down to see if it was still decoding...I noticed it had stopped
> decoding 12 minutes b4 I got down here.
>
> Another symptom: When it stops decoding incoming signals, the Blue Decode
> light does NOT flash at the end of a sequence, ...even though the
> thermometer and the waterfall show sigs for the full sequence.
>
> Any other suggestions?
> 73, N0AN
> Hasan
>
>
> On Thu, Jul 4, 2019 at 5:35 AM Hasan al-Basri 
> wrote:
>
> Ok, I'll check it out. Time is perfect and always is, I'm GPS locked to it.
>
> When I got down here this morning it was still decoding full fill of
> JTAlert. ...but it's only been 12 hours. (I did the remove driver, unplug
> it and let Win10 reinstall it at a reboot) . That's where I am now in my
> test.)
>
> Save none was checked, I just checked Save All, will provide if needed.
>
> Here's hoping...
>
> 73, N0AN
> Hasan
>
>
> On Wed, Jul 3, 2019 at 10:37 PM Black Michael  wrote:
>
> We seem to be hearing problems with a few people on both 2.0.1 and
> 2.1.0-rc7.
> 2.0.1 has been out for a long time and if this was common I'd think we
> would have heard a lot more reports of the problem.
> Upgrading to 2.1.0-rc7 and back to 2.0.1 should (and I emphasize should)
> just revert completely back to 2.0.1 thought there is a bug with FT4 in
> that case.
>
> The common thread probably is Windows updatesor time is off.  Check
> http://time.is to ensure you're time is reported as "Exact".
>
> If you see waterfall activity but no decodes on of three things is likely
> happening.
>
> #1 Time is off
> #2 WAV files are not being recorded.  Ensure Save/All is checked and see
> if WAV files are showing up in the Save folder.  One user found using
> Remote Desktop that audio files weren't being saved.  TeamViewer worked
> though.
> #3 Audio corrupted.  If WAV files are showing up but not decoding and your
> time is correct then send in a few audio files so we can look at them.
>
> de Mike W9MDB
>
>
>
>
> On Wednesday, July 3, 2019, 10:27:56 PM CDT, Tod Farrell WE5TR <
> we5t...@gmail.com> wrote:
>
>
> Similar issue here on 2.0.1, win10, and flex6700 after a long operating
> session or even a long monitoring session. I.e. I’ll leave the shack
> powered up monitoring a band while I’m at work or elsewhere in the house.
>
> When I come back sometimes the waterfall is showing activity, dT is good,
> time.is is good, but no decodes.
> Other times it’s that clicking transit or tune causes no generated audio
> to the DAX  software which has a meter that shows me no incoming audio is
> present from WSJT-X.
>
> Typically corrected with a WSJT-X restart
>
> --
> 73
>
> TodWE5TR
> While mobile
>
> On Jul 3, 2019, at 16:52, Hasan al-Basri 
> wrote:
>
> Hi Mike,
> No transmitting at all. RF Chokes all over the place. No issues running KW
> out on any band 6m through 80m. (if I have just rebooted the computer).
> Once it has run for several hours. it will stop decoding, whether I have
> transmitted or not, no matter qrp or qro. I monitor 24x7 , go days without
> tx'ing...it still goes deaf.
>
> IOW, it's not a USB RFI problem.
>
> All power settings for USB have been set to never sleep.
>
> I"m baffled, like I said, it acts like a memory leak and I don't think
> it's a coincidence that it showed up the very first time after installing
> and running RC7 64 bit.
>
> The problem NEVER showed up b4 RC7 64 bit was installed. I didn't change a
> thing in my setup or operating habits. Now I have to reboot eve

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

Ok Mike, it decoded for > 24 hours but then stopped early this morning just
before I got to the shack.

Started 07/03/2019 @ 1723
Stopped 07/05/2019 @ 0407 Both local

These are the file saved dates. Again, I had to reboot a few minutes ago to
get it to start saving files/decoding again.

The rig was unattended from about 6 p.m. last  night until 4:19 a.m. when I
came down to see if it was still decoding...I noticed it had stopped
decoding 12 minutes b4 I got down here.

Another symptom: When it stops decoding incoming signals, the Blue Decode
light does NOT flash at the end of a sequence, ...even though the
thermometer and the waterfall show sigs for the full sequence.

Any other suggestions?
73, N0AN
Hasan


On Thu, Jul 4, 2019 at 5:35 AM Hasan al-Basri 
wrote:

> Ok, I'll check it out. Time is perfect and always is, I'm GPS locked to it.
>
> When I got down here this morning it was still decoding full fill of
> JTAlert. ...but it's only been 12 hours. (I did the remove driver, unplug
> it and let Win10 reinstall it at a reboot) . That's where I am now in my
> test.)
>
> Save none was checked, I just checked Save All, will provide if needed.
>
> Here's hoping...
>
> 73, N0AN
> Hasan
>
>
> On Wed, Jul 3, 2019 at 10:37 PM Black Michael  wrote:
>
>> We seem to be hearing problems with a few people on both 2.0.1 and
>> 2.1.0-rc7.
>> 2.0.1 has been out for a long time and if this was common I'd think we
>> would have heard a lot more reports of the problem.
>> Upgrading to 2.1.0-rc7 and back to 2.0.1 should (and I emphasize should)
>> just revert completely back to 2.0.1 thought there is a bug with FT4 in
>> that case.
>>
>> The common thread probably is Windows updatesor time is off.  Check
>> http://time.is to ensure you're time is reported as "Exact".
>>
>> If you see waterfall activity but no decodes on of three things is likely
>> happening.
>>
>> #1 Time is off
>> #2 WAV files are not being recorded.  Ensure Save/All is checked and see
>> if WAV files are showing up in the Save folder.  One user found using
>> Remote Desktop that audio files weren't being saved.  TeamViewer worked
>> though.
>> #3 Audio corrupted.  If WAV files are showing up but not decoding and
>> your time is correct then send in a few audio files so we can look at them.
>>
>> de Mike W9MDB
>>
>>
>>
>>
>> On Wednesday, July 3, 2019, 10:27:56 PM CDT, Tod Farrell WE5TR <
>> we5t...@gmail.com> wrote:
>>
>>
>> Similar issue here on 2.0.1, win10, and flex6700 after a long operating
>> session or even a long monitoring session. I.e. I’ll leave the shack
>> powered up monitoring a band while I’m at work or elsewhere in the house.
>>
>> When I come back sometimes the waterfall is showing activity, dT is good,
>> time.is is good, but no decodes.
>> Other times it’s that clicking transit or tune causes no generated audio
>> to the DAX  software which has a meter that shows me no incoming audio is
>> present from WSJT-X.
>>
>> Typically corrected with a WSJT-X restart
>>
>> --
>> 73
>>
>> TodWE5TR
>> While mobile
>>
>> On Jul 3, 2019, at 16:52, Hasan al-Basri 
>> wrote:
>>
>> Hi Mike,
>> No transmitting at all. RF Chokes all over the place. No issues running
>> KW out on any band 6m through 80m. (if I have just rebooted the computer).
>> Once it has run for several hours. it will stop decoding, whether I have
>> transmitted or not, no matter qrp or qro. I monitor 24x7 , go days without
>> tx'ing...it still goes deaf.
>>
>> IOW, it's not a USB RFI problem.
>>
>> All power settings for USB have been set to never sleep.
>>
>> I"m baffled, like I said, it acts like a memory leak and I don't think
>> it's a coincidence that it showed up the very first time after installing
>> and running RC7 64 bit.
>>
>> The problem NEVER showed up b4 RC7 64 bit was installed. I didn't change
>> a thing in my setup or operating habits. Now I have to reboot every day or
>> it just stops decoding, even having uninstalled RC7 64 bit and returned to
>> 2.01 Gen Release.
>>
>> Audio level is perfect, waterfall shows signals...no decode.
>> Reboot...decodes resume. No other program shows any symptoms like this at
>> all on the same computer. WSJT-X is running on its own USB Sound Dongle for
>> both RX and TXand has been for over a year.
>>
>> Any further ideas are most welcome (TS-590sg, running from headphone jack
>> for rx audio) Audio sounds perfect to the ear. Levels are right...
>> Most peculiar!
>>
&

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

Ok, I'll check it out. Time is perfect and always is, I'm GPS locked to it.

When I got down here this morning it was still decoding full fill of
JTAlert. ...but it's only been 12 hours. (I did the remove driver, unplug
it and let Win10 reinstall it at a reboot) . That's where I am now in my
test.)

Save none was checked, I just checked Save All, will provide if needed.

Here's hoping...

73, N0AN
Hasan


On Wed, Jul 3, 2019 at 10:37 PM Black Michael  wrote:

> We seem to be hearing problems with a few people on both 2.0.1 and
> 2.1.0-rc7.
> 2.0.1 has been out for a long time and if this was common I'd think we
> would have heard a lot more reports of the problem.
> Upgrading to 2.1.0-rc7 and back to 2.0.1 should (and I emphasize should)
> just revert completely back to 2.0.1 thought there is a bug with FT4 in
> that case.
>
> The common thread probably is Windows updatesor time is off.  Check
> http://time.is to ensure you're time is reported as "Exact".
>
> If you see waterfall activity but no decodes on of three things is likely
> happening.
>
> #1 Time is off
> #2 WAV files are not being recorded.  Ensure Save/All is checked and see
> if WAV files are showing up in the Save folder.  One user found using
> Remote Desktop that audio files weren't being saved.  TeamViewer worked
> though.
> #3 Audio corrupted.  If WAV files are showing up but not decoding and your
> time is correct then send in a few audio files so we can look at them.
>
> de Mike W9MDB
>
>
>
>
> On Wednesday, July 3, 2019, 10:27:56 PM CDT, Tod Farrell WE5TR <
> we5t...@gmail.com> wrote:
>
>
> Similar issue here on 2.0.1, win10, and flex6700 after a long operating
> session or even a long monitoring session. I.e. I’ll leave the shack
> powered up monitoring a band while I’m at work or elsewhere in the house.
>
> When I come back sometimes the waterfall is showing activity, dT is good,
> time.is is good, but no decodes.
> Other times it’s that clicking transit or tune causes no generated audio
> to the DAX  software which has a meter that shows me no incoming audio is
> present from WSJT-X.
>
> Typically corrected with a WSJT-X restart
>
> --
> 73
>
> TodWE5TR
> While mobile
>
> On Jul 3, 2019, at 16:52, Hasan al-Basri 
> wrote:
>
> Hi Mike,
> No transmitting at all. RF Chokes all over the place. No issues running KW
> out on any band 6m through 80m. (if I have just rebooted the computer).
> Once it has run for several hours. it will stop decoding, whether I have
> transmitted or not, no matter qrp or qro. I monitor 24x7 , go days without
> tx'ing...it still goes deaf.
>
> IOW, it's not a USB RFI problem.
>
> All power settings for USB have been set to never sleep.
>
> I"m baffled, like I said, it acts like a memory leak and I don't think
> it's a coincidence that it showed up the very first time after installing
> and running RC7 64 bit.
>
> The problem NEVER showed up b4 RC7 64 bit was installed. I didn't change a
> thing in my setup or operating habits. Now I have to reboot every day or it
> just stops decoding, even having uninstalled RC7 64 bit and returned to
> 2.01 Gen Release.
>
> Audio level is perfect, waterfall shows signals...no decode.
> Reboot...decodes resume. No other program shows any symptoms like this at
> all on the same computer. WSJT-X is running on its own USB Sound Dongle for
> both RX and TXand has been for over a year.
>
> Any further ideas are most welcome (TS-590sg, running from headphone jack
> for rx audio) Audio sounds perfect to the ear. Levels are right...
> Most peculiar!
>
> 73, N0AN
> Hasan
>
>
> On Wed, Jul 3, 2019 at 4:39 PM Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Failing audio or rig connections are most always due to RFI or USB ports
> going to sleep.
> If RFI low power transmissions can be tested and if they work but high
> power does not then it's RFI.
> The USB ports going to sleep can be solved.
> https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices
>
> de Mike W9MDB
>
>
>
>
> On Wednesday, July 3, 2019, 04:31:39 PM CDT, rjai...@gmail.com <
> rjai...@gmail.com> wrote:
>
>
> I’ve seen this with other radios. Definitely not a flex only issue.
>
> Ria
> N2RJ
>
> On Wed, Jul 3, 2019 at 4:58 PM DX Jami via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Peter,
>
> Flex has its own set of unique problems and fixes.  Suggest you post your
> question on the Flex forum page.  Good luck.
>
> Danny
> AH6FX/W4
>
> On Wednesday, July 3, 2019, 3:11:48 PM EDT, Peter Putnam 
> wrote:
>
>
> Greetings,
>
> I 

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

I also followed the link from Mike and verified that I had already done
what he recommended...months and months ago.
It's not an RFI problem.

I've thought about uninstalling X and then going into the registry and
searching for anything related to WSJT-X and deleting it, along with any
left-over files like *.ini, etc

...but, that's a pretty drastic step for something that might be cured by
the general release or finding and replacing a corrupt file. I just don't
know what to find and what to replace   :-)

73, N0AN

Hasan


On Wed, Jul 3, 2019 at 4:53 PM Peter Putnam  wrote:

> No USB ports are involved in a Flex -> DAX -> WSJT setup. Audio is passed
> from one program to another in memory.
>
> One would not suspect RFI to be the culprit after three hours of steady
> operation at full power without an issue.
>
>
>
> On 7/3/2019 2:36 PM, Black Michael via wsjt-devel wrote:
>
> Failing audio or rig connections are most always due to RFI or USB ports
> going to sleep.
> If RFI low power transmissions can be tested and if they work but high
> power does not then it's RFI.
> The USB ports going to sleep can be solved.
> https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices
>
> de Mike W9MDB
>
>
>
>
> On Wednesday, July 3, 2019, 04:31:39 PM CDT, rjai...@gmail.com
>   wrote:
>
>
> I’ve seen this with other radios. Definitely not a flex only issue.
>
> Ria
> N2RJ
>
> On Wed, Jul 3, 2019 at 4:58 PM DX Jami via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Peter,
>
> Flex has its own set of unique problems and fixes.  Suggest you post your
> question on the Flex forum page.  Good luck.
>
> Danny
> AH6FX/W4
>
> On Wednesday, July 3, 2019, 3:11:48 PM EDT, Peter Putnam 
> wrote:
>
>
> Greetings,
>
> I have been using WSJT-X quite successfully for several years during
> June VHF Contests. I experienced a failure of the WSJT program to accept
> received audio input after several hours of proper operation during the
> recent Field Day exercise.
>
> I'll provide a brief outline and reply with more detail, should it be
> needed.
>
> My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The
> WSJT-X software version is 2.0.1 7ddcb7.
>
> My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX"
> program that interfaces various applications that wish to receive the
> audio stream. WSJT accepts the stream and displays results on the Wide
> Graph and a small audio signal-strength window. Activity proceeded
> normally for the first three hours of Field Day, until both the Wide
> Graph and the audio signal-strength stopped showing any incoming audio.
>
> I can't offer any help on what might have caused the problem. It was
> abrupt and seemingly unrelated to any other system actions. I am unable
> to reproduce the problem.
>
> Several operators spent several hours speculating about what a solution
> might be. Program restarts and computer re-boots (time-tested favorite
> of generations) changed nothing. The only useful clue was that the DAX
> audio output stream was present and could be re-directed to Fldigi, but
> not to WSJT-X.
>
> I was able to restore operation for a brief period by stopping WSJT,
> renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour.
> Repeating the procedure provided operation for the rest of Field Day.
>
> The two .ini files that were renamed are available for your inspection,
> along with the one that continued to function.
>
> Any suggestions you can offer to prevent a recurrence would be greatly
> appreciated.
>
> Regards,
> Peter
> NI6E
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

Hi Mike,
No transmitting at all. RF Chokes all over the place. No issues running KW
out on any band 6m through 80m. (if I have just rebooted the computer).
Once it has run for several hours. it will stop decoding, whether I have
transmitted or not, no matter qrp or qro. I monitor 24x7 , go days without
tx'ing...it still goes deaf.

IOW, it's not a USB RFI problem.

All power settings for USB have been set to never sleep.

I"m baffled, like I said, it acts like a memory leak and I don't think it's
a coincidence that it showed up the very first time after installing and
running RC7 64 bit.

The problem NEVER showed up b4 RC7 64 bit was installed. I didn't change a
thing in my setup or operating habits. Now I have to reboot every day or it
just stops decoding, even having uninstalled RC7 64 bit and returned to
2.01 Gen Release.

Audio level is perfect, waterfall shows signals...no decode.
Reboot...decodes resume. No other program shows any symptoms like this at
all on the same computer. WSJT-X is running on its own USB Sound Dongle for
both RX and TXand has been for over a year.

Any further ideas are most welcome (TS-590sg, running from headphone jack
for rx audio) Audio sounds perfect to the ear. Levels are right...
Most peculiar!

73, N0AN
Hasan


On Wed, Jul 3, 2019 at 4:39 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Failing audio or rig connections are most always due to RFI or USB ports
> going to sleep.
> If RFI low power transmissions can be tested and if they work but high
> power does not then it's RFI.
> The USB ports going to sleep can be solved.
> https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices
>
> de Mike W9MDB
>
>
>
>
> On Wednesday, July 3, 2019, 04:31:39 PM CDT, rjai...@gmail.com <
> rjai...@gmail.com> wrote:
>
>
> I’ve seen this with other radios. Definitely not a flex only issue.
>
> Ria
> N2RJ
>
> On Wed, Jul 3, 2019 at 4:58 PM DX Jami via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Peter,
>
> Flex has its own set of unique problems and fixes.  Suggest you post your
> question on the Flex forum page.  Good luck.
>
> Danny
> AH6FX/W4
>
> On Wednesday, July 3, 2019, 3:11:48 PM EDT, Peter Putnam 
> wrote:
>
>
> Greetings,
>
> I have been using WSJT-X quite successfully for several years during
> June VHF Contests. I experienced a failure of the WSJT program to accept
> received audio input after several hours of proper operation during the
> recent Field Day exercise.
>
> I'll provide a brief outline and reply with more detail, should it be
> needed.
>
> My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The
> WSJT-X software version is 2.0.1 7ddcb7.
>
> My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX"
> program that interfaces various applications that wish to receive the
> audio stream. WSJT accepts the stream and displays results on the Wide
> Graph and a small audio signal-strength window. Activity proceeded
> normally for the first three hours of Field Day, until both the Wide
> Graph and the audio signal-strength stopped showing any incoming audio.
>
> I can't offer any help on what might have caused the problem. It was
> abrupt and seemingly unrelated to any other system actions. I am unable
> to reproduce the problem.
>
> Several operators spent several hours speculating about what a solution
> might be. Program restarts and computer re-boots (time-tested favorite
> of generations) changed nothing. The only useful clue was that the DAX
> audio output stream was present and could be re-directed to Fldigi, but
> not to WSJT-X.
>
> I was able to restore operation for a brief period by stopping WSJT,
> renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour.
> Repeating the procedure provided operation for the rest of Field Day.
>
> The two .ini files that were renamed are available for your inspection,
> along with the one that continued to function.
>
> Any suggestions you can offer to prevent a recurrence would be greatly
> appreciated.
>
> Regards,
> Peter
> NI6E
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] clock patch

[Hasan al-Basri]

Not all USB based GPS have issues. Not all software is the same. NMEATime2
does not show the issues you describe with a USB GPS. while the BKT
software does. (for me)

This one, from Amazon works. I have two of them.

GlobalSat BU-353-S4 USB GPS Receiver (Black)

The above USB based GPS used with NMEATime2, is certainly accurate enough
for all the WSJT-X suite of programsand many of us have the DT to prove
it.

Please don't throw the baby out with the bath water, with a pursuit of
unnecessary perfection.

73, N0AN
Hasan


On Wed, Jul 3, 2019 at 3:07 AM Matthew Miller  wrote:

> Beware those GPS receivers – I got one (unstable latency was throwing me
> off by as much as 550mS on NTP) and I found that when I tried to set up
> ntpd to use GPS it was showing jitter of around 0.8 seconds.
>
>
>
> Further research, USB GPS is a BAD IDEA because there is often buffering
> in the serial-USB converter chips as well as overhead with the USB
> protocol.  Depending on what port you use it may also be connected thru one
> or more hubs adding additional overhead and latency.  You may not “see” a
> hub but many computers now have internal USB hubs for touchpad, keyboard,
> webcams, touchscreens, Bluetooth, and a variety of other “built in”
> features that now all hang off internal hubs.
>
>
>
> If you are going to go with a proper GPS time sync you really need a
> non-USB serial GPS and PPS input…which is not trivial.
>
>
>
> Its not cheap, but I solved my problem with one of these…its plug and play
> then just set your computer to point at its IP address.  I now have a
> reliable source that indicates it has only 0.5mS jitter and 3mS latency
> even going thru multiple network switches and a fairly busy WiFi network.
>
> https://timemachinescorp.com/product/gps-time-server-tm1000a/
>
>
>
> There are also other cheaper DIY Raspberry Pi projects (which have some of
> their own challenges I didn’t feel like dealing with right now) that can be
> built for under $100 to make a stratum-1 time server that works without
> Internet but PLEASE PLEASE do not tell people to use USB GPS for time, its
> going to increase the problems not fix them!
>
>
>
> -Matt / KK4NDE
>
>
>
> *From:* Neal Pollack [mailto:nea...@gmail.com]
> *Sent:* Wednesday, June 26, 2019 12:08 PM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] clock patch
>
>
>
> Only some are due to lack of internet.
>
> USB GPS receivers are now approx $12 USD on Ebay.  I have tested a few
> and they work fine with NMEAtime2. Which is none simple software.
>
> The message could suggest what to do for both internet connected and
> off-grid users.  But really, to keep the message short, it should point to
> a help page or file that is specific to time setting options, rather than a
> huge user guide, since the public no longer reads very much.
>
>
>
> With regard to time setting software, I really can't recommend BKTtimeSync
> for the same reasons we are discussing this issue:  It works for me but is
> far too complicated for the average ham, and lacks sufficient docs or help.
>
>
>
> But NMEAtime2 is really simple and just works, for using GPS.
>
>
>
> For internet users,  NetTime or Dimension4 for basic users or Meinberg NTP
> for more advanced users.
>
>
>
> BUT!!!  All of the users, both internet and GPS, need to be reminded to
> turn OFF windows automatic time setting before using the software's above.
> I see too many users whose DT is swinging wildly between plus and minus 2.5
> seconds, then next at 0.2 DT.  This is because they have windows trying to
> set time while also using the above programs to set time, and the two are
> fighting a tug of war.
>
>
>
> If you guys put a DT warning message in the code that points to a time
> help page, then I volunteer to be one of several editors for the above type
> of help content about time sync'ing options.
>
>
>
> Cheers,
>
>
>
> Neal
>
> N6YFM
>
>
>
> On Wed, Jun 26, 2019, 3:16 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. Re: Clock patch (DG2YCB, Uwe)
>2. Re: Clock patch (Roeland Jansen)
>3. Re: Clock patch (Bill Somerville)
>
>
> --
>
> Message: 1
> Date: Wed, 26 Jun 2019 11:36:58 +0200
> From: "DG2YCB, Uwe" 
> To: "'Black Michael'" , "'WSJT software
> development'" 
> Subject: Re: [wsjt-devel] Clock patch
> Message-ID: <004801d52c02$b33f1430$19bd3c90$@gmx.de>
> Content-Type: 

Re: [wsjt-devel] Field Day time problem

[Hasan al-Basri]

I also agree with Fred, why do we constantly focus on reinventing the wheel?

WWV or other world time services and a mouse click will even work. A Cheap
CASIO watch has NIST time in it for $30. (works well Stateside).

The GPS dongles are dirt cheap and some even come with time setting
software. Another good program for setting time from GPS is NMEATime2,
which I use.

Let's not turn WSJT-X into Bloatware just because people can't seem to set
their own clocks from readily available sources. I'm not disputing the
problem, (FD particularly is full of incompetent first time, ill-trained
digital ops who have the thought, "oh, wouldn't this be fun, I'll show the
guys what a cool mode this is").

 I just don't agree with constantly trying to make up for poor operating
practices with software solutions.

In WSJT-X, not setting one's clock when only a cursory RTFM, as well as
minimal effort and investment are required is, to my mind,  poor operating
practice.

...and BTW, get off my lawn.   :-)

73, N0AN

Hasan


On Mon, Jun 24, 2019 at 4:11 AM Tom Melvin  wrote:

> All
>
> This posting by Fred gets my vote - easy, fool proof and does not distract
> the dev team.
>
>
> --
> 73’s
>
> Tom
> GM8MJV (IO85)
>
>
>
>
>
> On 24 Jun 2019, at 09:27, Fred Price  wrote:
>
> You are all overthinking the problem. There are programs to set your
> computer clock by a GPS dongle. A good plug in dongle from Amazon is $12USD
> and the program I use BktTimeSync is a free download.
> Also if the dev group keeps adding more n more WSJT will become bloatware.
> I'd rather see improvements in what is in the software already. If you want
> a color to denote a time that is getting out use JTAlert, it already has
> that in it.
>
> On Jun 24, 2019 4:07 AM, "DG2YCB, Uwe"  wrote:
>
> A very good idea to set up time beacons, Reino! I like this approach!
>
>
> However, as a short-term solution IMO dev team should find a way to use
> the EXISTING data set of DT values for a pop-up saying that very likely
> time is not synced correctly, plus an option to correct time by one click.
> Look the following example. Only one station has a DT value which is
> totally out of the average. Would be easy to detect such things by any well
> programmed algorithm. Even the old JT65-HF software had two additional
> buttons, where one could simply set PC clock + or – some 100 ms (until +-
> 2.5 s). Was very helpful for fieldday activities. Just click on + or – as
> long as most of the other stations have DT around 0. Simple approach, but
> worked 100%.
>
>
>
>
> 73 de Uwe, DG2YCB
>
>
> -Ursprüngliche Nachricht-
> Hi,
>
>
> We are amateurs and could provide another time distribution experiment
> especially during Field Day events. I mean setting up time beacon or
> beacons that send e.g. every 15 s a short pulse, say 100 ms, on the base
> carrier frequency e.g. 14.080 MHz. Timing of that pulse could be 'minute
> mark - 1 s' or something similar agreed time. It would allow manual PC time
> setting in the same manner as time marks of standard frequency stations.
> That transmission would not disturb any FT8 message as nobody should
> transmit at that time. It could be more useful, if the beacon frequency is
> set to 1 kHz up (14.081), then you could hear it without detuning VFO and
> disturbing you normal operation. Well, you could get same information from
> dT values providing there are enough time accuracy in other stations and
> you timing is good enough for decoding.
>
>
> Of course those beacons should be carefully synchronized to an accurate
> time reference e.g. GPS. Depending on local regulations also a station
> identity shall be sent at regular intervals using some applicable
> modulation perhaps just before the time tick. I think that voluntary
> stations would provide this service as needed.
>
>
> You could automate the time setting with a suitable program, if that could
> be made safely and reliably (perhaps the pulses needs to be modulated for
> identification), but that's next step if ever considered useful.
>
>
> 73 Reino oh3ma
>
>
>
>
> ___
>
> wsjt-devel mailing list
>
> wsjt-devel@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[Hasan al-Basri]

Working fine 64 bit Win10 Home
Tnx quick fix! 73, N0AN
Hasan


On Mon, Jun 3, 2019 at 2:04 PM Al  wrote:

> RC 7 OK so far..
> AL, K0VM
>
> On 6/3/2019 12:56 PM, Joe Taylor wrote:
>
> To:   Users of WSJT-X -- especially those interested in radio contesting
> From: WSJT Development Group
>
> We apologize for the confusion created by release yesterday of WSJT-X
> 2.1.0-rc6.  That program version had a bug that prevented it from running
> for some users.  This bug has been fixed in Release Candidate 7, which is
> now available for download.  We have also corrected a problem seen by some
> users of Omni-Rig.
>
> The remainder of this message is mostly a repeat of things in yesterday's
> announcement, with "rc7" replacing "rc6".
>
>
> As you know, we have been developing a protocol called FT4 for use in
> radio contesting.  A new version of FT4 is now available for testing in
> WSJT-X 2.1.0-rc7.
>
> PLEASE NOTE THAT FT4 IN RELEASE CANDIDATE 7 IS NOT COMPATIBLE WITH THAT IN
> RELEASES RC5 and EARLIER.
>
> Therefore: Please stop using WSJT-X 2.1.0-rc5 and WSJT-X 2.1.0-rc6.  If
> you wish to use FT4 after today or to take advantage of other recent
> program corrections or enhancements, you should use WSJT-X 2.1.0-rc7.
>
> MOCK CONTEST SESSION
> 
> A special session for testing the contesting features of FT4 is scheduled
> for six hours from June 4, 1900 UTC through June 5, 0100 UTC: Tuesday
> afternoon/evening, North American time, starting about 24 hours from now.
> Get on the air whenever you can during this mock contest session, using
> dial frequency 7.090 or 14.080 MHz, as appropriate to the time of day.  As
> in previous tests, be sure to check "RTTY Roundup messages" on the Settings
> | Advanced tab.
>
>
> Here's a list of changes, improvements, and bug fixes that have been made
> since WSJT-X 2.1.0-rc5:
>
> IMPORTANT CHANGES TO THE FT4 PROTOCOL *** NOT BACKWARD COMPATIBLE ***
>  - T/R sequence length increased from 6.0 to 7.5 seconds
>  - Symbol rate decreased from 23.4375 to 20.8333 baud
>  - Signal bandwidth decreased from 90 Hz to 80 Hz
>
> OTHER FT4 IMPROVEMENTS
>  - Allowable time offsets -1.0 < DT < +1.0 s
>  - Tx4 message with RRR now allowed, except in contest messages
>  - Audio frequency is now sent to PSK Reporter
>  - Add a third decoding pass
>  - Add ordered statistics decoding
>  - Improved sensitivity: threshold S/N is now -17.5 dB
>  - Improved S/N calculation
>  - In FT4 mode, Shift+F11/F12 moves Tx freq by ± 100 Hz
>
> OTHER IMPROVEMENTS
>  - Improvements to accessibility
>  - Updates to the User Guide (not yet complete, however)
>  - New user option: "Calling CQ forces Call 1st"
>  - N1MM Logger+ now uses the standard WSJT-X UDP messages
>  - OK/Cancel buttons on Log QSO window maintain fixed positions
>  - Put EU VHF contest serial numbers into the ADIF SRX and STX fields
>
> BUG FIXES
>  - Fix generation of Tx5 message when one callsign is nonstandard
>  - Fix a bug that prevented use on macOS
>  - Fix a bug that caused mode switch from FT4 to FT8
>  - Fix a bug that caused FT4 to do WSPR-style band hopping
>  - Fix a bug that caused a Fortran bounds error
>
> Release candidate WSJT-X 2.1.0-rc7 will be available for beta-testing
> through July 21, 2019.  It will be inoperable during the ARRL June VHF QSO
> Party (June 8-10) or ARRL Field Day (June 22-23).  It will permanently
> cease to function after July 21, 2019.  If all goes according to plan, by
> that time we will have made a General Availability (GA) release of WSJT-X
> 2.1.0.
>
> Downloadable installation packages for WSJT-X 2.1.0-rc7 under Windows,
> Linux, and macOS are available on the WSJT-X web page:
>
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> -- 73 from Joe, K1JT; Steve, K9AN; and Bill, G4WJS
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug report

[Hasan al-Basri]

Same here, 64 bit win won't start and does not show up as an installed
program. The files are in the install directory, but it neither starts, nor
does is show up in the start program list.

N0AN
Hasan


On Sun, Jun 2, 2019 at 2:00 PM Jari A  wrote:

> win 7 64 bit
>
> Does not start, reboot does not help.
>
> FYI
>
> Best rgds,
>
> :Jari / oh2fqv
>
>
> ---
>
>
> Problem signature:
>   Problem Event Name: APPCRASH
>   Application Name: wsjtx.exe
>   Application Version: 0.0.0.0
>   Application Timestamp: 5cf07e87
>   Fault Module Name: wsjtx.exe
>   Fault Module Version: 0.0.0.0
>   Fault Module Timestamp: 5cf07e87
>   Exception Code: c005
>   Exception Offset: 0027cc44
>   OS Version: 6.1.7601.2.1.0.256.48
>   Locale ID: 1035
>   Additional Information 1: deed
>   Additional Information 2: deed2ee1fb10a9245a68e6f47ba9b087
>   Additional Information 3: e981
>   Additional Information 4: e98176a476e5df4a870310674973c595
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] No Longer Decoding

[Hasan al-Basri]

I've had the new 64 bit version go deaf in a similar manner after sitting
unused perhaps 36 hours. Nothing would solve it...rebooted, fixed it
immediately with no changes of any kind.
73, N0AN
Hasan


On Thu, May 9, 2019 at 7:02 PM Ed Deichler  wrote:

> Both LINE IN and LINE OUT were previously set to mono and the program
> worked fine.  Changing to RIGHT channel made no difference in the decoding,
> i.e. still a blank waterfall.  I'm not sure whether the soundcard is dead
> or the K3 output is dead.
>
> Ed
>
> On Thu, May 9, 2019 at 4:52 PM Bill Somerville 
> wrote:
>
>> On 09/05/2019 16:57, Ed Deichler wrote:
>> > Bill,
>> >
>> > Yes.  The K3 has respective jacks for line in and line out.  According
>> > to the manual, the K3 has two settings for the audio output.  NORMAL
>> > is usually used for digital modes and a separate PHONES setting allows
>> > the audio to match headphones and be controlled by the AF/SUB gain
>> > controls.  Either choice makes no difference.
>> >
>> > 73 de Ed
>>
>> Hi Ed,
>>
>> the NOR option also has a level, default is 10. Also make sure you have
>> the right stereo channel (i.e. left for MAIN Rx) selected in the WSJT-X
>> "Settings->Audio" panel.
>>
>> 73
>> Bill
>> G4WJS.
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Another observed drawback - audio input level

[Hasan al-Basri]

Thanks Bill, and yes it does get set to +23 dB with any change in config.
Think I'll leave the sound setting window open  :-)
73, N0AN

Hasan


On Tue, Apr 30, 2019 at 5:01 PM Bill Somerville 
wrote:

> On 30/04/2019 22:42, Hasan al-Basri wrote:
> > BTW, I assume we are talking about transmit level setting, not rx?
>
> Hi Hasan,
>
> no, this issue only affects audio input devices.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Another observed drawback - audio input level

[Hasan al-Basri]

I am also using an external usb sound dongle (the $5 variety from Amazon).
I am not seeing any of the noted audio issues with the 64 bit version.

I have set the audio once, gone back and forth, started, stopped the
program, changed configs. I don't see it. I assumed it was because it was
not the motherboard sound card. Now I gather from Bill that it is because
it has no level setting.

BTW, I assume we are talking about transmit level setting, not rx?

73, N0AN
Hasan


On Tue, Apr 30, 2019 at 3:35 PM Bill Somerville 
wrote:

> On 30/04/2019 21:03, Neil Zampella wrote:
> >
> > FWIW .. Mike recommended a few years ago at least that you change the
> > properties from showing a PERCENTAGE to a dB level. I have mine set to
> > 0 dB on the properties, and have not see the issues others are seeing
> > with the 64 bit version.
> >
> > I am using an external USB soundcard with the system (Sound Blaster
> > xFi) which may be the reason I'm not seeing the issues, but I'm
> > thinking its more the property setting.
> >
> > Neil, KN3iLZ
> >
> Hi Neil,
>
> the issue is universal for all sound cards, including virtual devices
> like loopback services. For some devices 100% level is 0dB, i.e. they
> have no gain ahead of the ADC (or no ADC if they are a virtual device)
> apart from the mic. boost stage which is not affected by this issue.
>
> So for those using digital audio loopback devices and sound cards with
> no front end gain adjustment, there is no real problem assuming 0dB is
> compatible with the audio level being sampled. The real issue is where a
> sound card has gain ahead of the ADC because we cannot detect that and
> it will be set to maximum unconditionally on restart.
>
> The Qt fix that is in the pipeline will revert to not changing the
> existing gain settings when an audio input stream is opened.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[Hasan al-Basri]

Hi Jim, and tnx 20m FT4 qso.

I have been spotted on 40m, 20m, 30m in the last 10 min or so. I have not
seen any spots from my 17m signal, nor have I seen any sigs.

I'll try a few CQs on 15 and 10 to see if any spots show up.

73, N0AN
Hasan


On Tue, Apr 30, 2019 at 9:50 AM James Shaver  wrote:

> I watched one CW signal on 40 intentionally move until it was zero beat
> with it signal.  Not a single QSO was disrupted by them. Hilariously, their
> attempt to QRM gave me great data about how easily the protocol will reject
> DQRM of that nature. The irony is delicious.
>
> Jim S.
> N2ADV
>
> On Apr 30, 2019, at 7:43 AM, Gary Kohtala - K7EK via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> It's already happening. Just a few minutes ago on the current 40m FT4
> frequency I am hearing multiple
> attempts at jamming and harassment. People tuning up and swishing their
> VFO's, sending unidentified
> CW messages such as "Go away", etc. They have to be very optimistic
> thinking that (m)any of the folks on
> JT modes are able to hear them and/or be expected to respond to CW
> messages. Absolutely hilarious.
> The jammers don't know that the software will just see their attempts at
> disruption as very insignificant
> bumps in the road. FT4 will just keep on sending until the message is
> received, just like the other JT
> modes. Very entertaining. I seem to remember something similar when FT8
> exploded onto the scene in a similar manner. Let's revisit this in six
> months and see where we stand.
>
> Best regards,
>
> Gary, K7EK
>
> ---
>
>
> On Tuesday, April 30, 2019, 7:32:44 AM EDT, James Shaver 
> wrote:
>
>
> 60 is never included because people don’t read before they transmit (I
> know that’s a shocker) and were transmitting out of band or illegally
> because of the vast differences between 60 meter rules.
>
> > On Apr 30, 2019, at 7:25 AM, Christoph Berg  wrote:
> >
> > Re: Bill Somerville 2019-04-29 <
> 6c16f722-5577-e692-e1a3-78a3c38b9...@classdesign.com>
> >> In summary WSJT-X v2.1.0 RC5 will have the following FT4 suggested
> >> frequencies (the Iter1 column):
> >>
> >> Band Iter0  Iter1  Notes
> >> -
> >> 8035953575  (plus 3568 Region 3)
> >> 4070907047
> >
> > Shouldn't 60m be included here as well? (Also FT8)
> >
> > (My assumption is that FT4 will take much of the existing FT8 traffic,
> > because people hate waiting. Judging by the amount of FT4 on the first
> > day, that might happen very soon.)
> >
> > Christoph
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] PJ4P Operation

[Hasan al-Basri]

I worked them in the normal mode calling them about 100 Hz above where they
were tx'ing.
73, N0AN
Hasan


On Wed, Jan 23, 2019 at 4:00 PM John Zantek  wrote:

> Has anyone observed the FT8 operation of the PJ4P expedition team?  Maybe
> I’m missing something obvious, but….
>
>
>
> It LOOKS they’re operating as a Fox, but on the conventional FT8
> frequencies.
>
>
>
> They’re transmitting on ODD, not EVEN, so I can’t engage them as a Hound
> with WSJT-X 2.0.
>
>
>
> Their transmissions are varying between < 500Hz and > 1000Hz.
>
>
>
> I looked at PSKReporter to see if I could find out what app and version
> they’re using, but they’re not sharing their spots.
>
>
>
> I know this isn’t a Developer issue, but I trust the folks on his list.
> I’m after PJ4 on 160M, but wasted an entire evening last night trying to
> figure out how to work them.
>
>
>
> 73 John W7CD
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Required duplication feature

[Hasan al-Basri]

Tnx Bill,

This is what caused me concern. It is a note on installing listed on their
web site:

I read that to mean that I download the file, but when I go to run it, I
have to use Admin privileges, which is what I thought  you had warned
about. I'll try to get to the install tomorrow and see how it might work.


   - Do not use the Run option when connected to the website. Save the file
   to your computer first and then run it *as administrator* from the PC


Tnx Help, much appreciated.
73, N0AN
Hasan


On Tue, Jan 22, 2019 at 3:49 PM Bill Somerville 
wrote:

> On 22/01/2019 21:32, Hasan al-Basri wrote:
>
> *Bill, what do you think about installing N1MM+ given it's requirement to
> install as Admin?*
>
> Hi Hasan,
>
> I am not aware that it does need to be installed as Administrator.
> Installers on Windows normally run from a non-privileged user account and
> request elevation for any parts of the installation that need extra rights.
> How that elevation request presents itself depends on the system setup,
> either a UAC prompt to continue or a request to login as a privileged user
> is normal.
>
> It appears that the N1MM+ installer needs to register several components
> and that will require Administrator rights, if they recommend running the
> initial installer as Administrator (by right-clicking it and selecting "Run
> as Administrator") then I would do that. As for installing updates, it is
> integrated and does not ask for elevated access.
>
> Note that applications that install into the "Program Files (x86)" or
> "Program Files" directories will definitely need elevated rights at some
> point during installation.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Required duplication feature

[Hasan al-Basri]

Bill, Joe,

I looked at N1MM+ and was about to install it, when I saw you had to
install it as "Administrator" and recalling Bill's admonition about
installing things as Admin, I held off until I could ask about it.

*Bill, what do you think about installing N1MM+ given it's requirement to
install as Admin?*

My comments were not directed at what X's behavior was w/r to  the cab
file, it was directed at the cumbersome process it became to upload a cab
file to ARRL web site (if you had not done it before...and I hadn't)

Filling out a form with no hints as to the format to the values to be
entered is not that much fun. ("one" "1" or "single"), actual watts vs low,
medium, high, aided vs not (which I'm sure could have been gleaned from a
careful reading of the rules, so ignore that one)

The combination of self-duping, self scoring and figuring out the format
and particulars of the values that are required at the ARRL site, nearly
caused me to just throw the data away. I'm not a contest enthusiast. I
enjoy the propagation aspect of it, but wanted to help others out with a
check log. If I had several hundred contacts, that's just what I would have
done. With 40 it was merely tedious.

...and Joe, thanks for putting all that effort into the interface with
N1MM+. It looks to me like it would do it "all", dupe, score, format cbr
for ARRL and possibly even upload the final cbr file.

If it turns out to be "safe" to do the Admin install, I'll give it a try.
The X software performed just beautifully during the contest, and made
operating a real pleasure.
73, N0AN

Hasan


On Mon, Jan 21, 2019 at 4:41 PM Bill Somerville 
wrote:

> On 21/01/2019 22:09, Hasan al-Basri wrote:
>
> I like your suggestion about just real time export to N1MM. I may ask you
> about how to do that in more detail in the future.
>
> I will say this, based on this contest (which I thoroughly enjoyed!), if I
> have to go through what I did to submit a log in the futureI won't
> bother to submit it. The operating was fun, the ARRL method of processing
> required was not.
>
> 73, N0AN
> Hasan
>
> Hi Hasan,
>
> the defect in the WSJT-X Cabrillo contest entry file has already been
> fixed for the next release, apologies for the inconvenience. We were aware
> of the requirements to use special names for QSO frequencies on 6m and
> above, the code to do so was there but did not get triggered due to a
> miscalculation between kHz and Hz.
>
> If I get chance and demand is high enough I will write a small utility to
> fix up individual entries.
>
> For integration with N1MM Logger+, all you need to do is set up N1MM for
> the correct contest and enable its WSJT-X integration
> "Menu->Config->Configure Ports, Mode Control, Audio, Other ...->Broadcast
> Data", at the WSJT-X end you must enable sending logged UDP messages to
> N1MM in "Settings->Reporting". Make sure you have the latest N1MM update as
> recent changes have enhanced the WSJT-X integration. Rig control must be
> disabled in N1MM while WSJT-X is in use during the contest.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Required duplication feature

[Hasan al-Basri]

I agree, George, CM worked wonderfully. Processing my log for ARRL was a
complete pain. The cab file has full freq in it, and ARRL won't accept it
in the upload. So I had to edit the file. The file had full freq and ARRL
would only accept 50   (for 6m)

I like your suggestion about just real time export to N1MM. I may ask you
about how to do that in more detail in the future.

I will say this, based on this contest (which I thoroughly enjoyed!), if I
have to go through what I did to submit a log in the futureI won't
bother to submit it. The operating was fun, the ARRL method of processing
required was not.

73, N0AN
Hasan


On Mon, Jan 21, 2019 at 12:13 PM George J. Molnar  wrote:

> What a great pleasure to work contest mode this time — kudos to the dev
> team for a HUGE improvement.
>
> Tricky thing is that the “Contest Log” shows only contacts for that
> particular profile. So with one or more -rig setup, a unique log is
> generated. Understandable, but inconvenient. Probably best to export to
> N1MM (or equivalent) in real-time, and use that for all-circumstance
> logging/duping?
>
> *George J Molnar*
> KF2T, Arlington, Virginia, USA
>
>
> Please note my new email: George@Molnar.*TV*
>
> On Jan 20, 2019, at 7:10 PM, ComDaC  wrote:
>
> Hello,
>
> Although, there were multiple contacts in today’s, and yesterday’s event,
> to be the primary mode – as it appears to be with no SSB posts – it needs a
> duplicate noting feature.  I attempted a contact with K1JT with no success,
> but that’s understandable.  I like the mode, and it brought me back to VHF
> and HF with little use in the recent past.  Thank you for your efforts, and
> it shows the move to the digital modes for efficiency.  Your efforts are
> appreciated.
>
> 73,
> Durf
> KX8D
> www.comdac.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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Possible bug in V2 GA ?

[Hasan al-Basri]

If you didn't double click to get on his frq, you really weren't on his
freq. Single click moves rx, double click moves both.

What I think happened was you single clicked (and stayed on your prior tx
freq), so, when he answered someone else, you continued to call him (but
off his rx freq), which is "good". He might see you for the next qso, hence
my queue comment.
Hasan


On Mon, Dec 31, 2018 at 4:11 PM Chris Getman 
wrote:

> Thanks for the information.
>
> I thought I was exactly on his frequency,
> I had just clicked on him calling CQ,
> And sent his call then mine.
> But he responded to someone else.
>
> So if this is to allow others to queue up,
> then what am I transmitting?
> And why would I want stations to queue up on his frequency?
>
> Sorry for rambling on, but I am just confused on this one
> Is this somewhere I can read up on, to better understand?
>
> Thanks
> Chris. -  N3PLM
>
> On Mon, Dec 31, 2018 at 4:41 PM Hasan al-Basri 
> wrote:
>
>> Chris,
>> If you are not calling right on or close to the station's frequency, the
>> tx will not go out, it will continue. This is a feature, not a bug. It
>> allows the "rare" station to queue up some callers while continuing to work
>> an existing station that may or may not be on his tx freq.
>> 73, N0AN
>> Hasan
>>
>>
>> On Mon, Dec 31, 2018 at 11:09 AM Chris Getman 
>> wrote:
>>
>>> When responding to someone calling CQ.
>>>
>>> But the calling station reply’s to someone else,
>>>
>>> The enable TX button goes out, and the transmit is supposed to stop
>>>
>>> But once in a while,  the transmitter keep transmitting each cycle,
>>>
>>> Nothing shows up on the right hand screen .
>>>
>>>
>>>
>>> The only way to stop the repeating transmit, you have to manually
>>> re-enable the Enable TX button
>>>
>>> and the hit the Halt TX button.
>>>
>>> Hitting the Halt TX button alone does nothing.
>>>
>>>
>>>
>>> Windows 10 – Dell 6400 – Signalink SL1+ - FT-847
>>>
>>>
>>>
>>> Doesn’t happen often and it isn’t a big problem
>>>
>>> Once you know what it is.
>>>
>>> Just Wondering if anyone else encountered this issue.
>>>
>>>
>>>
>>> Chris – N3PLM
>>>
>>>
>>> ___
>>> 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
>>
> --
>
> Chris Getman
>
> 413 Militia Drive
>
> Lansdale, PA  19446
>
> 215-368-1005 – Home
>
> 215-353-6429 – Cell
>
> chris.getman...@gmail.com
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Possible bug in V2 GA ?

[Hasan al-Basri]

Chris,
If you are not calling right on or close to the station's frequency, the tx
will not go out, it will continue. This is a feature, not a bug. It allows
the "rare" station to queue up some callers while continuing to work an
existing station that may or may not be on his tx freq.
73, N0AN
Hasan


On Mon, Dec 31, 2018 at 11:09 AM Chris Getman 
wrote:

> When responding to someone calling CQ.
>
> But the calling station reply’s to someone else,
>
> The enable TX button goes out, and the transmit is supposed to stop
>
> But once in a while,  the transmitter keep transmitting each cycle,
>
> Nothing shows up on the right hand screen .
>
>
>
> The only way to stop the repeating transmit, you have to manually
> re-enable the Enable TX button
>
> and the hit the Halt TX button.
>
> Hitting the Halt TX button alone does nothing.
>
>
>
> Windows 10 – Dell 6400 – Signalink SL1+ - FT-847
>
>
>
> Doesn’t happen often and it isn’t a big problem
>
> Once you know what it is.
>
> Just Wondering if anyone else encountered this issue.
>
>
>
> Chris – N3PLM
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Mobile operation

[Hasan al-Basri]

For time lock, I use this:
http://visualgps.net/nmeatime2

It does a lot more than just time, but it won't automatically update your
grid square inside X

73, N0AN

Hasan


On Sun, Dec 23, 2018 at 7:42 PM Chris Knox  wrote:

> Is there a way to have the program automatically update your grid square
> based on input from a GPS?  Second can I use a GPS for the clock updates?
> I am thinking of operating in many grid squares throughout my travels
> Chris
> KI1P
>
> Get Outlook for iOS 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Tab 2

[Hasan al-Basri]

I prefer TAB 1, do not use TAB 2, ever.

Hasan


On Sun, Dec 2, 2018 at 8:06 AM WB5JJJ  wrote:

> Bill:
>
> As you requested, I have never used Tab 2.  One vote to remove it.  Tab 1
> has all the information as to what is going on during a contact with no
> thinking required.
>
> I have NOT had the UTC/Local time stamp issue.  My Contest Log has the
> correct 24 hour UTC for every entry and I'm set to Central Time in my
> automatic MS time keeping offset.
>
> Enjoyed reading your all-inclusive review of problems/solutions and fixes
> in one place, great work putting that together.  Thanks.
>
> Windows 10 Pro 64 bit here and all aspects of WSJTx-RC5 have worked
> perfectly. I for one, have not had a single problem with the Contest
> Logger, so never had a reason to "edit" it for any reason.  Everything is
> logging to HRD LB directly without a glitch - and I DO check every entry
> while waiting on next contact.
>
> Even though most contacts do not include a Grid Square along with all
> other personal information, HRD LB does get the 6 digit GS with the query
> of QRZ upon adding the entry.  Of course this field is "0" characters in
> the WSJTX log file.  This could cause a problem for some that use the adi
> file as the import to their logger.  The  size may not allow
> the GS to be edited in their logger to a 4 or 6 character count since space
> was not allocated by the adi file import.
>
> Bottom Line - the program requires absolutely no interaction from me for
> proper logging.  I do edit the HRD LB entry when some European stations
> have their Postal Code in front of  their QTH information, so I do delete
> that.  (Future note to coders to fix this if possible, could be a problem
> as there are several variations being seen).
>
> 73's
> --
> George Cotton, WB5JJJ
>
> ___
> 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] View Contest Log Shows No Data Under Received Column?

[Hasan al-Basri]

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

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

Looking at the Cabrillo export Log:

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

... shows that a Rx exchange exists.

What am I missing?

73, N0AN

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

[wsjt-devel] Contest Log: Received not filled in

[Hasan al-Basri]

In View > Contest Log

The Sent is filled in, the Rx is empty

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

Re: [wsjt-devel] 2.0 RC4

[Hasan al-Basri]

GA Jim,
Tnx qso earlier. Win10 decided it needed to update, so it started to
misbehave. All is well., 73, N0AN
Hasan


On Mon, Nov 19, 2018 at 4:17 PM  wrote:

> Just my .02 worth. On 40m now with  very compromised antenna ( a 20’ piece
> of downspout) and I’m decoding a lot of 77bit traffic. Even worked K1JT
> just a few ago. I’m convinced and looking forward to the final release.
>
>
>
>
>
> 73
>
> Jim  NY0J
>
>
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_1684203513308485152_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC 4 testa.

[Hasan al-Basri]

Ya know, Chuck, it's almost refreshing not having a bajillion sigs to hunt
thru. I'm find RC4 just fine.
I'm on 40m right now, have worked about 6 guys in the last 15 minutes, and
had time to ready your email
:-)
73, N0AN
Hasan


On Mon, Nov 19, 2018 at 12:35 PM Chuck Furman 
wrote:

> I have gone to RC4 and I’m not looking back. I guess everyone is desperate
> to make as many contacts as possible. If you are, maybe you shouldn’t be a
> beta tester. I’m making lots of contacts on 20/40 Meters. And when I can’t
> find anyone, I switch to JT65. Remember, you can’t just listen. Call CQ.
> You would be surprised at the number of answers you will get. Be patient.
> This is a temporary problem.
>
> Chuck
> KG6PH
>
> On Mon, Nov 19, 2018 at 12:23 PM Krzysztof Krzemiński 
> wrote:
>
>> Oh, yes,
>> Lets give up everybody.
>>
>> Joe and his team was wasting his time, creating for you previous perfect
>> version.
>> Of course previous version was perfect from the start.
>> No one RC was created.
>> So, why to help him now? He should be perfect as you are.
>> They are doing a lot of RC's, why, software should bo perfect from the
>> start.
>> They spend a lot of time testing and helping you.
>> You never make mistakes, so why they can?
>> And of course, why to read documentation and lose your time, if you can
>> ask here once again and again the same question?
>>
>> Let's go back to the stones. It's the easiest way.
>> Do not help them, it is not your business.
>>
>> We are in 21 century, so ham spirit is not for us. Is it?
>>
>> Kris, SP5NOH
>>
>> PS: I create that thread, so I think, I can write such message, in such
>> form.
>> All the best for you Joe and for your super team. See you in few hours on
>> the band @ FT8 mock contest.
>>
>>
>>
>> 
>>  Wolny
>> od wirusów. www.avast.com
>> 
>> <#m_-3442301369802422482_m_2746071087593298410_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> pon., 19 lis 2018 o 17:50 Scotty W7PSK  napisał(a):
>>
>>> I have it downloaded but have not fully migrated yet.  Reason, on the
>>> west coast
>>> of the US there are very few if any stations I can hear and work yet.
>>>
>>> Scotty W7PSK
>>>
>>>
>>> -- Original Message --
>>> From: "M Lewton" 
>>> To: "WSJT software development" 
>>> Sent: 11/19/2018 8:06:51 AM
>>> Subject: Re: [wsjt-devel] RC 4 testa.
>>>
>>> >Hello
>>> >
>>> >I have been trying to use rc4 since the morning it was released.
>>> >Probably made 10 or 20 contacts each day.
>>> >
>>> >This morning for one hour on 40 meters I called CQ many, many times no
>>> >luck.
>>> >Lots of signals but no decodes.
>>> >A few answered in the waterfall but they didn't decode.
>>> >I get out quite well on 40.
>>> >
>>> >Moved to 20 and made one contact, France.  Lots signals there too but
>>> >only a
>>> >few decoded.
>>> >
>>> >Moved to 15 made one contact VP8LP the only lonely ham using using rc4.
>>> >
>>> >I think if the known bugs were fixed more hams would not get
>>> >discouraged and
>>> >move back to the previous versions.
>>> >You could have rc4a, rc4b etc.
>>> >
>>> >The version wsjtx_1.9.1 was so good and bug free I don't think many
>>> >want to
>>> >abandon it.
>>> >
>>> >If not enough hams move to rc4 I too will move back to the earlier
>>> >version.
>>> >
>>> >73 Maurice
>>> >WA6PHR
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >-Original Message-
>>> >From: Patrick 9A5CW
>>> >Sent: Monday, November 19, 2018 7:19 AM
>>> >To: WSJT software development
>>> >Subject: Re: [wsjt-devel] RC 4 testa.
>>> >
>>> >
>>> >Hi all,
>>> >We Mutants and surrogates are watching closely ;) don't worry about us.
>>> >Both or more software's are installed.
>>> >
>>> >Best regards and RR73 9A5CW
>>> >
>>> >
>>> >Datuma pon, 19. stu 2018. 15:21 Ryan Tourge >> >piše:
>>> >
>>> >I suspect a large population is using one of the mutants (JTDX etc.)
>>> >and
>>> >probably don't even know about any of this. That said... I have used
>>> >both
>>> >and WSJT-X pretty much offers everything now that I looked for in JTDX.
>>> >
>>> >
>>> >On Mon, Nov 19, 2018 at 3:34 AM dgb  wrote:
>>> >
>>> >
>>> >Amen
>>> >
>>> >I tried RC4 for the last hr. with CQ's on 160-30 and got many replies
>>> >but
>>> >not one using RC4!!
>>> >
>>> >Apparently a very small part of the population using RC4.
>>> >
>>> >What's it going take to get them to change their ways? ;-)
>>> >
>>> >73 Dwight NS9I
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >On 11/17/2018 4:01 AM, Krzysztof Krzemiński wrote:
>>> >
>>> >Ladies and gentelmen, HAMs,
>>> >
>>> >Where is the ham spirit?
>>> >
>>> >Quite nobody WW is using RC4.
>>> >
>>> >Let's start and run RC4, nobody will do it in your name.
>>> >
>>> >Even if new, super contact "do not change colour on your log".
>>> >
>>> >Help Joe and his team.
>>> >
>>> >Kris, SP5NOH
>>> >
>>> >
>>> >Wysłano z 

Re: [wsjt-devel] Problems with RC4

[Hasan al-Basri]

Tnx for correction!
73

Hasan

On Sat, Nov 17, 2018, 9:16 AM Jim Nuytens  Hasan,
>
> That's not entirely correct. RC3 can decode RC4 TXs, but RC4 doesn't
> decode RC3 TXs, unless you set RC3 to 77-bit messages in settings.
>
> I have been running RC4 on and off for the last several days. I can get
> spots on PSK Reporter from stations running RC3. It's just that if they
> respond to me without setting RC3 to 77-bit, I'll never decode them.
>
> Jim
>
> On 11/17/2018 14:53, Hasan al-Basri wrote:
> >  RC4 cannot be copied by RC3 in FT8. RC3 cannot be copied by RC4 in FT8.
>
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problems with RC4

[Hasan al-Basri]

Giuseppe,

It may appear that RC4 is less sensitive, but that is  not true. It is most
likely that you are misinterpreting what you are seeing.

The reason you see 90% fewer decodes on RC4 than RC3 is that there are 90%
fewer people using RC4 at this point. RC4 cannot be copied by RC3 in FT8.
RC3 cannot be copied by RC4 in FT8.

RC4 is decoding just fine...there just aren't that many people running RC4
on HF yet.

You appear to be attributing causation when there is none. The decrease in
decodes has NOTHING to do with the inherent sensitivity of RC3 vs RC4. It
has everything to do with the population using each mode.

The reason installing and uninstalling didn't change anything for you, is
because it shouldn't. It's not the install, it's not the sensitivity of the
software. It's cockpit trouble. :-)

73, N0AN
Hasan


On Fri, Nov 16, 2018 at 6:40 PM M Lewton  wrote:

> Hello
>
> I find this version the most sensitive vs. the older versions.  I am also
> using a IC-7300 with only a vertical antenna.
> I just worked JR3GPP calling CQ at -21 we completed the QSO with his -24
> RR73.
>
> RC4 has other problems that most people have already commented on.
> For me I miss the "Already Worked" the most.
>
> Maurice
> WA6PHR
>
> -Original Message-
> From: Giuseppe Molinaro via wsjt-devel
> Sent: Friday, November 16, 2018 9:38 AM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Giuseppe Molinaro
> Subject: [wsjt-devel] Problems with RC4
>
>
> I would like to bring to your attention that I had to reinstate version
> RC3
> because for some unknown reason the RX sensitivity is extremely low when
> using RC4 (about 90% less station decoded as compared to version RC3) on a
> Icom 7300 transceiver.
>
> I reinstalled RC4 twice with identical results both times
>
> 73 Giuseppe KE8FT
>
>
>
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C7f49fd6c8bb24a07430d08d64beadd3d%7C84df9e7fe9f640afb435%7C1%7C0%7C636779869479520310sdata=gpvP%2B%2F%2BNVgS%2Fv4mzd5afNx4OCKs3SfEvhRRpmLBwSuA%3Dreserved=0
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[Hasan al-Basri]

The five minute mouse timer business is going too far. Long MSK144 qsos
over difficult paths, should not require the OP to be chained to the desk.

Several ops are running (on a clear freq), for hours to complete. They
aren't sitting in front of the mouse. The developers may not approve of
this operational style. but it should NOT be hard coded. It is going to
discourage long standing efforts to see a contact to completion.

...and who hasn't wandered around the shack, or even made a bathroom run,
in the course of an hour long attempt?

Please don't throw the baby out with the bathwater, *unless there is a
compelling reason to do so*.

Running smoothly on 260 MSK144, no problems noted, but it's early.  :-)

Thanks for all the hard work!
73, N0AN
Hasan


On Tue, Nov 13, 2018 at 10:37 AM George J. Molnar  wrote:

> Congrats, dev team. Running smoothly so far (Mac OS 10.14).
>
> Not sure I understand the intent of the five minute no-mouse timer. Isn’t
> this essentially competing with the watchdog? Not sure of a use case that
> requires this second timer.
>
> Can you elaborate?
>
> Thanks
>
>
>
> *George J Molnar*
> KF2T, Arlington, Virginia, USA
>
>
> Please note my new email: George@Molnar.*TV*
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error loading LoTW Users Data and Network Error

[Hasan al-Basri]

Thanks!
Hasan


On Fri, Oct 19, 2018 at 8:35 AM Bill Somerville 
wrote:

> On 19/10/2018 14:26, Hasan al-Basri wrote:
>
> Bill,
>
> I downloaded and installed the 32 bit OpenSSL software this morning.
> (after I had downloaded and copied the the *.csv file yesterday as a short
> term fix)
> ...and the copy fix worked. So, I thought I would do the full fix.
>
> After the install, I went to the colors tab where the Fetch button is, and
> it is now Gray...is that how it is supposed to be? Since I can't do a
> Fetch, I assume it will auto-update and either I can no longer do a manual
> fetch, or the program is smart enough to realize I don't need an update.
>
> In either case, I don't get the error (Win10 Home 64bit).
>
> Just wanted to make sure what I installed is working.
>
> TIA, 73, N0AN
> Hasan
>
> Hi Hassan,
>
> the download is done in the background and while it is happening the
> "Fetch" button is disabled, it gets re-enabled when the download is
> conformed to be complete, that doesn't happen until the first attempt to
> highlight a decode.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Error loading LoTW Users Data and Network Error

[Hasan al-Basri]

Bill,

I downloaded and installed the 32 bit OpenSSL software this morning.
(after I had downloaded and copied the the *.csv file yesterday as a short
term fix)
...and the copy fix worked. So, I thought I would do the full fix.

After the install, I went to the colors tab where the Fetch button is, and
it is now Gray...is that how it is supposed to be? Since I can't do a
Fetch, I assume it will auto-update and either I can no longer do a manual
fetch, or the program is smart enough to realize I don't need an update.

In either case, I don't get the error (Win10 Home 64bit).

Just wanted to make sure what I installed is working.

TIA, 73, N0AN
Hasan


On Wed, Oct 17, 2018 at 3:43 PM  wrote:

> I’ve been reading about these errors when starting wsjtx-rc3.  Some said
> to hit ok and let it go.  Others say the download 2 files to correct the
> errors.
>
>
>
> I am using Windows 8.1 on this notebook and Windows 10 on the desktop when
> I get around to the move.  So, what’s what?  If the errors will go away in
> RC4, I’ll continue to hit OK and let it go.  Everything else seems to be
> working great!
>
>
>
> Thanks for responses, and KODOS to the programmer(s)!
>
>
>
> Ron – KE7RON
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] "L" instead of colors for LOTW

[Hasan al-Basri]

I agree, the colors are becoming so ubiquitous, that they end up diguising
as much as they highlight.

Some color is good, a lot of color can be overwhelming. I like a simple L
for LoTW user. Save the colors for things more dramatic that require
immediate notice like CQ, and My call



Hasan

On Thu, Oct 18, 2018, 5:09 PM Richard Zwirko - K1HTV 
wrote:

> With the past few WSJT-X release candidates there have been a number of
> concerns expressed about the use of colored letters over various colored
> backgrounds to indicate decoded stations that use LOTW. In addition to the
> visibility issues, the user now has to remember the meanings of the various
> colors.
>
> If it is at all possible, why not get away from colors and KISS. Keep It
> Simple   use a single letter "L" to indicate an LOTW using station. The
> "L" could be placed on the far right side of the line after the country
> prefix or name. RXCLUS, a program that I've been using for over a decade to
> monitor DXcluster nodes, appends an "L" on the far right side of putouts
> for LOTW users. It works great. If you don't want to see it, simply shrink
> the right side of the display.
>
> I believe that the use of an "L" versus using various colors is a much
> more effective and less confusing way to indicate FT8 stations that use
> LOTW.
>
> 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

Re: [wsjt-devel] Major Virus Like Bug in V2

[Hasan al-Basri]

That's why I said "virus-like" in that anyone receiving the bad tone set
would begin transmitting it.

...but it pays to be careful., I don't want anyone thinking I was saying
that the team unleashed a computer virus :-)

Thanks for the quick attention.

73, N0AN
Hasan


On Wed, Sep 19, 2018 at 10:40 AM Joe Taylor  wrote:

> Many thanks to all the MSK144 gang who helped to identify a bug in
> WSJT-X 2.0.
>
> I believe the bug is now fixed in our development code.  We will post a
> -rc2 candidate release very soon, probably next week.  In the meantime,
> it's best to use v1.9.1 for MSK144 QSOs.
>
> BTW: this was a rather ordinary bug, although it was manifested in a
> rather unusual way.  It has nothing to do with a "computer virus", in
> the sense that term is generally used.  No harm will come to your computer!
>
> -- 73, Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Major Virus Like Bug in V2

[Hasan al-Basri]

Steve,
First of alla large group of people had migrated to 280. We ran a bunch
yesterday, and this showed up out  of the blue this morning...and it
"infected" everyone who heard those tones.

So, I was in a  hurry to let someone know that this was happening on 280
where a lot of people were using V2. It literally took over the entire
country. Everywhere those tones were heard, the software on the listening
computer, immediately (on next transmission) caused that computer to
transmit the offending or corrupted tones. It did it to me in the middle of
a CQ sequence (in other words, I was calling CQ , listened one seq, heard
the corrupt tones, and my next TX seq of CQ was composed of the offending
tones, and thus infecting everyone on freq that heard me...)

This was not a "bug report" as much as a warning that this was going to
produce a mass infection of tone corruption and to try to get it stopped.

People were trying to figure out what happened to their computers...

I wouldn't have said a thing if this only affected a few people beta
testing...well it was far more than that because so many people switched to
V2, and it was causing havoc.

In any case, it appears that it may be connected to the auto-contest mode
correction code.

I was not in contest mode, btw. Normal MSK144 setup, 6 meters. I installed
V2 in wsjtx\v2  and it remembered all my prior settings.

It was behaving perfectly for me around 6 p.m. last night. First thing this
morning, all  hell broke loose as soon as KB7IJ transmitted those corrupt
tones. Then I started transmitting them, then others and others.

If it didn't seem urgent to me, I would have tried to provide more info...

Since I did not see myself originate the tones (KB7IJ was the source ...at
least for my infection), my conditions were just my everyday operation on
6m msk144. I was listening...that's it. That's all I can provide ...

But, no worries, I will no longer post anything, or comment on the
performance of the software at all.
I'm sure it will get sorted out, and I'm off 280 anyway.

73, N0AN
Hasan


On Wed, Sep 19, 2018 at 7:13 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hasan,
>
> Unfortunately, your report isn’t very useful as it stands. To you and
> others who are testing the recent beta release of v2.0: when making a bug
> report, please carefully document and report a sequence of steps needed to
> reproduce the problem. When running a beta release, always run with “Save
> all” turned on and, as in this case, if the problem involves behavior that
> is triggered by receiving a certain type of signal or message, please
> submit a saved wav file that triggers the problem with your bug report.
>
> If you are not willing or able to do the careful documentation that is
> necessary to help us find and debug problems then, like Hasan, I recommend
> that you follow his lead:
> >
> > Going back to 1.9 on 260, V2 abandoned until fixed.
> >
>
>
> 73 Steve k9an
>
> > On Sep 19, 2018, at 10:52 AM, Hasan al-Basri 
> wrote:
> >
> > When running MSK144, the program will start tx'ing some weird sounding
> tones...they will "infect" any V2 MSK144 station that hears them and they
> will start sending the same strange tones.
> >
> > 5 of us have experienced this same bug...all simultaneously upon hearing
> those "odd" tones.
> >
> > I'm betting it is connected to the CM auto-correct code.
> >
> > If you TX for a bit with v2 msk144, you WILL infect other listemers/
> >
> > Going back to 1.9 on 260, V2 abandoned until fixed.
> >
> > 73, N0AN
> > Hasan
> > ___
> > 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] Major Virus Like Bug in V2

[Hasan al-Basri]

When running MSK144, the program will start tx'ing some weird sounding
tones...they will "infect" any V2 MSK144 station that hears them and they
will start sending the same strange tones.

5 of us have experienced this same bug...all simultaneously upon hearing
those "odd" tones.

I'm betting it is connected to the CM auto-correct code.

If you TX for a bit with v2 msk144, you WILL infect other listemers/

Going back to 1.9 on 260, V2 abandoned until fixed.

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

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

[Hasan al-Basri]

Igor,
If you believe that DX-Spotting is equivalent to internet assisted
sensitivity enhancement, then there is no point in further discussion.

Apples and oranges, at the very least.
N0AN
Hasan


On Mon, Sep 10, 2018 at 12:58 AM Игорь Ч via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hello Laurie,
> .
> DX cluster usage is an Internet dependant DX-ing and contesting, it is
> accepted by community and organizers.
> .
> 73 Igor UA3DJY
>
> Date: Mon, 10 Sep 2018 08:39:13 +1000
> From: "Laurie, VK3AMA" <_vk3a...@vkdxer.net>
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> IMO, it is very likely that an Internet dependant mode will not be
> accepted for award purposes or by Contest organisers.
>
> de Laurie VK3AMA
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

[Hasan al-Basri]

Bravo, George!

Internet help with the decode? That's downright silly. If we are going to
use the internet to replace even a portion of  the performance of rf, heck
why bother with rf at all, and we can have infinite sensitivity?


Hasan

On Sat, Sep 8, 2018, 6:13 PM George J Molnar  wrote:

> While it probably is a remote possibility that the WSJT-X team is
> contemplating adding internet-based linkages, I want to agree with N2ADV
> and emphatically say “no!” to any ham radio communications protocol that
> relies on anything but ham radio to work effectively.
>
> Even in this day of skimmers and spotting networks, automatic rotators,
> and auto-sequenced contacts, the contact itself is still a radio contact,
> and should remain so in its entirety.
>
>
> *George J Molnar*
> Arlington, Virginia, USA
> KF2T   -   FM18lv
>
>
>
>
>
>
> On Sep 8, 2018, at 6:38 PM, James Shaver  wrote:
>
> Yes but my previous question about Internet usage still stands: When I am
> sitting in a park or out on a snowmobile trail with my KX3 and my laptop
> using a GPS for time sync since there’s no cell reception there, anything
> that relies on the Internet will be basically useless to me.  Why would we
> aim to exclude a growing number of such users like me?  Perhaps I’m
> misunderstanding.
>
> Jim S.
> N2ADV
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on Expedition Mode

[Hasan al-Basri]

1239 UTC 01July18 , 14.090 USB Fox/Hound FT8

Up to 4 streams running -3 dB with a Tribander at 52'. Also seeing them
with 110' CF dipole at -8 db, and with -8 dB on my 6 meter LFA!

In other words, very good signals on 20m

I worked them in less than 2 minutes, probably first call.

Latest 5 streams at -6 dB on Tribander, working well, 3 RR 73 to stations
and 2 reports to other stations, all simultaneous.

Congrats Joe and Team, impressive!

73, N0AN
Hasan


On Sat, Jun 30, 2018 at 8:47 PM Tsutsumi Takehiko 
wrote:

> Joe and all Dx Pedition Mode developers,
>
>
>
> I am with Joe about the share of modes which he raised in the statistics.
>
>
>
> Congratulations and I hope FT8 will soon beat the rest of the modes. FT8
> gives me a new joy about Dx pedition hunting while listening my favorite
> music and writing e-mails to my friends.
>
>
>
> However, we need to be careful about the expected story is right or not
> i.e.  “to run CW and SSB when band conditions are good, when QSO rates can
> be highest.  FT8 works well even in poorer conditions”.
>
>
>
> It is well said that EU is the most difficult continent to QSO with Baker
> Island before the operation. “Continent by Mode” statistic indicates EU
> total average is 8.7% and very small percentage as expected. However, the
> breakdown of mode is 5.3%(SSB), 13%(CW), 7.3%(FT8). FT8 is a half of CW and
> on a par with SSB. I feel EU may be frustrated with FT8 as well as SSB and
> stay at CW mode.
>
>
>
> It is a (scientific) fact that less than 2 days operation statistics would
> not tell the solid answer and thus,  I am carefully watching them.
>
>
>
> Regards,
>
>
>
> take
>
>
>
> de JA5AEA
>
>
>
> Sent from Mail  for
> Windows 10
>
>
> --
> *From:* Joe Taylor 
> *Sent:* Sunday, July 1, 2018 3:56:39 AM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
>
> On 6/30/2018 10:14 AM, Black Michael via wsjt-devel wrote:
>
> > ... I noticed the the Baker team gave a lukewarm endorsement
> > of FT8 on their news update ...
>
> I do not consider their endorsement of FT8 to be lukewarm, at all.
>
> Currently they have uploaded 12,319 QSOs to ClubLog:
>
> CQ   4,735
> SSB  4,507
> FT8  3,077
> ---
>  12,319
>
> One of their intentions was to run CW amd SSB when band conditions are
> good, when QSO rates can be highest.  FT8 works well even in poorer
> conditions.  I believe they are happy with their decision to use FT8 and
> its DXpedition Mode.
>
> They would be even happier if more people used the correct software and
> followed the Hound operating instructions, preferably with a dollop of
> common sense.
>
> -- 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
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] How much operating time before rebooting your computer

[Hasan al-Basri]

I have observed this issue when win10 is waiting to update, but I haven't
been notified that an update is pending.

I discovered this when I noticed My 2nd wsjt-x machine was only decoding
about one half the stations that my other machine was. When I told the 2nd
ma Hine to restart, it immediately notified me that it was updating during
the reboot and not to turn the machine off.

I have seen this scenario present itself 3 times now, over a three month
period.

In each case the 2nd computer began decoding exactly as the first.

Typically I have wsjt-x running on both computers 24/7

73, N0AN


Hasan

On Wed, Apr 25, 2018, 5:53 PM Ray Jacobs  wrote:

> I left WSJT running on my computer for several hours, (not on purpose) but
> found out the program lost sensitivy during that time.
> My question is after a couple hours should you shut down the program and
> reboot your Computer?
> Ray KA3PCX
>
> Sent from AOL Mobile Mail
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: April 7, 1400-1600 UTC

[Hasan al-Basri]

Random callers below 1000 are ignored. Those who have already "engaged" the
Fox are automatically moved below 1000 to finish the qso...that's how the
software works.

Of course, there are those who have no idea what they are doing, can't read
and/or won't read, plus the deliberate qrm'ers...I saw one guy calling the
fox below 1000, at the same time the fox was transmitting. Obviously not
running the right version of the software.

There was lots of stuff like that.

73, N0AN

BTW: K1JT and W7/KH7Z were both S9 +15 to 20 dB in Iowa with all 5 streams
> +3 most of the time.

Hasan

On Sat, Apr 7, 2018 at 9:38 AM, Gene Marsh  wrote:

> Joe and the group:
>
> First, no propagation in northeast OH for the first test. Bummer.
>
> Second, maybe I’m confused (as usual):
> -  I thought signals below 1000Hz are ignored?  Many are. Some are not.
> -  I thought the Hounds were expected to transmit above 1000Hz and the Fox
> would ignore below?
>
> See the attached picture.
>
> 73 de W8NET Gene
> 3905 Century Club Master #47
> Portage County Amateur Radio Service (PCARS) since 2008
> ARRL A-1 Op
>
>
>
>
> > On Apr 5, 2018, at 10:49 AM, Joe Taylor  wrote:
> >
> > Hi all,
> >
> > I write to remind you of the second public test of *FT8 DXpedition Mode*
> scheduled for Saturday, April 7, 1400-1600 UTC.  You are cordially invited
> to participate -- the more participants, the better!
> >
> > Our main goal is to simulate pileups in which many "Hounds" call and
> attempt to work a desirable rare DX station, the "Fox".  The test will help
> us to improve our software so as to maximize the practical QSO rate in such
> situations.  We hope you can be there and try to work both Foxes.
> >
> > Here's the detailed schedule:
> >
> > Date  UTC   FrequencyFox Callsign  Operator
> > ---
> > April 7  1400   14.105 MHzW1/KH7Z   N1DG
> > April 7  1500   14.105W7/KH7Z   AA7A
> >
> > All participating stations must use program version WSJT-X v1.9.0-rc3.
> If you don't yet have it, download links are available near the bottom of
> the page here:
> > https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> >
> > [If you are compiling the program for yourself, be sure to use code
> revision r8576 or later, taken from the repository's WSJT-X development
> branch.  All revisions since r8576 will perform identically in FT8
> DXpedition Mode.]
> >
> > Detailed instructions for both Fox and Hound are posted here:
> > http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
> > Some details in these instructions have changed, so be sure to read and
> follow the latest instructions carefully!  Don't just try to wing it.
> >
> > As you will know after reading the instructions, Fox can conduct up to 5
> QSOs simultaneously, using frequency slots spaced by 60 Hz.  Fox
> transmissions always occur in the frequency range 300-900 Hz above dial
> frequency.
> >
> > If you (as a Hound) can legitimately use more than one callsign -- your
> spouse's call, club call, etc. -- feel free to work each Fox multiple
> times.  No dupe QSOs with the same call, though.
> >
> > Real-time liaison will be available on the "Ping Jockey Relief" chat
> page (PJB), https://www.pingjockey.net/cgi-bin/pingtalkB .  Everyone
> should monitor this page for possible last-minute announcements of a
> frequency change, etc.  To ensure that announcements from Fox stations are
> easily visible, Hounds should monitor PJB but not post messages there
> during the test.
> >
> > The deepest pileups will help us tune the final-release software version
> for optimum performance on both Fox and Hound sides.  After the test,
> please post any comments you feel will be helpful to one of our two email
> forums, wsjtgr...@yahoogroups.com or wsjt-devel@lists.sourceforge.net .
> You will need to be subscribed to the list in order to post there.
> >
> > We sincerely hope you can join us for this test, and that you will work
> both Foxes!
> >
> >-- 73, Joe, K1JT (for the WSJT Development Group)
> >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community 

Re: [wsjt-devel] DXpedition Mode on 40 Meters?

[Hasan al-Basri]

Agreed on all counts, Gary.
73, N0AN

Hasan

On Wed, Mar 28, 2018 at 1:21 PM, Gary McDuffie <mcduf...@ag0n.net> wrote:

>
>
> > On Mar 28, 2018, at 5:48 AM, Hasan al-Basri <hbasri.schie...@gmail.com>
> wrote:
> >
> > Running DXp by the developers for testing and evaluation is justifiable.
> Releasing DXp "into the wild" with no restraints or protections from abuse
> is irresponsible.
>
> After seeing the results of “turning it loose”, I’m convinced that the
> test versions like rc3 should have a fuse that will make the software (or
> at least the DXp mode) inop after a certain date.  This would force an
> upgrade to the current thinking for its use.  I doubt this is doable with
> public software, but it would help to limit some of the abuses seen on the
> bands by non-legit DXpeditions.
>
> As an aside, I suspect that many people who are pi$$ed off about what DXp
> mode does to the spectrum will not know enough to be able to separate DXp
> from the basic mode itself, FT8.  This would perpetuate the hate that some
> seem to be generating toward it.
>
> 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
>
--
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

[Hasan al-Basri]

Excellent, Look forward to it, Joe.
73, N0AN

Hasan

On Wed, Mar 28, 2018 at 12:35 PM, Joe Taylor  wrote:

> The second public test of FT8 DXpedition mode will be conducted on April
> 7, a little over a week from now.  You are cordially invited to join us for
> this test.  See the original announcement (copied below) for details.
>
> Even if you read it before, be sure to read the latest revision of the
> *FT8 DXpedition Mode User Guide.* It is dated March 28 and is available
> here:
> http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
> There are some changes from previously posted instructions!
>
> I draw your particular attention to the following sentences found on page
> 1:
> 
> 
> Please note: DXpedition Mode is not yet ready for “production” use. Until
> WSJT-X v1.9.0 is fully released, this mode should be used only in
> controlled test situations.  Please remember to send us your test results.
>
> ...
>
> Subject to future revision, we are temporarily suggesting the following
> frequencies for testing DXpedition mode: 1.8265, 3.567, 7.066, 10.1405,
> 14.105, 18.095, 21.067, 24.911, 28.067 MHz.
> 
> 
>
> The first warning is included because several operators or groups have
> been trying, against our advice, to use the not-yet-complete DXpedition
> Mode in real pileup situations.  This misuse of a WSJT-X beta release (or
> of code taken from the WSJT-X development branch) has been
> counter-productive, to say the least.
>
> The second item copied above is the result of early efforts to identify
> suggested FT8 DXpedition Mode operating frequencies for each HF band that
> will minimize interference with other modes.  We will welcome thoughtful
> suggestions that might improve this list of suggested frequencies.
>
> We hope to see you in the pileups calling W1/KH7Z and W7/KH7Z on 14.105
> MHz, 1400-1600 UTC on April 7!
>
> -- 73, Joe, K1JT
>
>
> On 3/19/2018 10:09 AM, Joe Taylor wrote:
>
>> The WSJT Development Group is pleased to announce a third Release
>> Candidate of WSJT-X Version 1.9.0.  A second release candidate, v1.9.0-rc2,
>> has been tested in the field over the past three weeks, including a public
>> test of FT8 DXpedition Mode conducted on March 6-7.
>>
>> A General Availability (GA) release of v1.9.0 will be announced at a
>> suitable time, probably in the near future.  After that time you should
>> stop using any -rc# release candidate.
>>
>> Here’s a short list of features and capabilities added to WSJT-X since
>> Version 1.9.0-rc2:
>>
>> 1. Corrected a number of flaws in Fox behavior, FT8 DXpedition Mode
>>
>> 2. Allow Hounds to use compound callsigns in FT8 DXpedition Mode
>>
>> 3. Write debugging information to FoxQSO.txt
>>
>> 4. Fix the "Blue Decode Button" bug
>>
>> 5. Allow partial processing of incoming UDP Reply messages so that
>> non-CQ/QRZ decodes can be processed. The processing is the same as
>> double-clicking the same decoded message within WSJT-X except that
>> "Enable Tx" will not be enabled.
>>
>> 6. Send DX grid locator to wsjt_status.txt, for use by applications like
>> PstRotatorAZ
>>
>> 7. Correct the display of DXCC status of KG4 calls
>>
>> 8. Updated copy of cty.dat
>>
>> 9. Updates to documentation
>>
>> 10. Updated Hamlib functionality including changes to the Yaesu FT-817
>> back end that allows the uBITx kit transceiver to be CAT controlled
>> by WSJT-X.
>>
>> 10. Other minor bug fixes
>>
>>
>> ###
>>
>>*Second Public Test of FT8 DXpedition Mode*
>>---
>>
>> If you decide to install v1.9.0-rc3, please help us by participating in
>> the second public test of FT8 DXpedition Mode scheduled for April 7. Once
>> again, the goal is to simulate a rare-DXpedition pileup by having many
>> stations ("Hounds") calling and trying to work a designated
>> pseudo-DXpedition station ("Fox").  Note that everyone participating in the
>> test *MUST* use WSJT-X v1.9.0-rc3.  In addition, you must read, understand,
>> and carefully follow the instructions posted here:
>> http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
>>
>> Please be sure to read this document carefully, again.  A few of its
>> details are different from the previous version.
>>
>> If you have legitimate access to more than one callsign (spouse, club
>> call, or whatever) please feel free to call and work the Fox more than
>> once. We want the test pileup to be as deep as possible.
>>
>> The scheduled test will take place as follows:
>>
>> DateUTC   Frequency Fox callsign  Operator
>> ---
>> April 7  1400   14.105 MHzW1/KH7Z   N1DG
>> April 7  1500   14.105W7/KH7Z  

Re: [wsjt-devel] Alternative FT8 DXpedition mode freqs.

[Hasan al-Basri]

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

Very constructive, Rich. I would add that if a real DXp freq plan can be
"generated", it needs to be *enforced in the software* , not just be in an
easily manipulated frequency table.

If, after due consideration of the needs of all the digital modes, a plan
can be implemented, then the place to do it is *inside *the software. Hard
code the mode/freq. If left up to users, DXp will be done wherever anyone
chooses. The choice cannot be left up to DXpeditionsthat's what started
this conversation in the first place.

73, N0AN


Hasan

On Tue, Mar 27, 2018 at 10:16 PM, Rich - K1HTV  wrote:

>
> *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
>
>
--
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] DXpedition Mode on 40 Meters?

[Hasan al-Basri]

Quoting from K9YC:

"It is a LONG established principle of ham radio, defined by FCC Rules and
corresponding laws in other countries, that no one person or group has
priority on any given frequency at any given time; indeed, these Rules
(laws) establish only permitted emission types for a range of frequencies."

No on has said that what DXp mode is doing is illegal, or violating rules.
Spare us us the straw man arguments. The crux of the matter has been the
devastating impact this particular mode of operation (DXp, not FT8
specifically) has on the existing digital mode operations. To use your own
"logic"..."*It has been a long established principle to have modes
segregated by users' agreement to preserve their viability*" This prevents
chaos, as well as incidental and deliberate interference that does no one
justice.

These *voluntary* agreements among people of good will (not the hysterical
I gotta have that new grid or country and screw anyone in my road, crowd),
have been around a long time.

Further quoting:

"This discussion is totally out of place on the developers' reflector.
Rather, it should be addressed to those hearty individuals who give of
their time and treasure to put stations on the air from usually very
difficult places and under difficult conditions, and for the benefit of
tens of thousands of hams around the world. Choice of operating frequencies
and times is THEIRS."


My Response: :

Not at all. The developers knew or should have known (legal standard for
*neglect*, by the way) the impact that DXp; would have had on any set of
frequencies *where they encouraged* DXp mode use.. Proof of this knowledge
is in the developers' explicit instructions to "*not run DXp mode in the
normal FT8 usage area*" . Why? For two reasons: 1) DXp trashes the spectrum
for whomever was already using it;  2). It was a cleaner test to be away
from the mutual interference of current FT8 usage.

In other words, "We don't want to mess up our nest, someone else's nest
will do nicely" This is what I meant when I referred to the approach
as "*hypocritical
and dismissive indifference" To say there are no nests is disingenuous at
best.*

*Running DXp by the developers for testing and evaluation is justifiable.
Releasing DXp "into the wild" with no restraints or protections from abuse
is irresponsible. *

*There are solutions, but they rest ONLY in the hands of the developers*.
Many DX'ers (do you listen to the conduct during DXpediitons?) have no
conscience whatever. They are incapable of self-restraint in the pursuit of
their self-imagined accomplishments. DXpeditions spend enough money and are
sufficiently popular to create in their minds and the minds of their
minions,  the firm belief that they are *entitled* to do whatever they like.

I happily stipulate that the software is amazing. I love using it. Yet,
there are *norms* that exist for the benefit of all of us.

In summary, norms and agreements may be even more important than FCC
rules. Rules
are a required element of success, but they are not sufficient for same.
Success ultimately requires  cooperation and consideration

Discussion of the impact of DXp mode on the developers' list is precisely
where it should take place. It was created and released by the developers.
The deleterious impact of that release is at least partially their
responsibility.

 73, N0AN

Hasan

On Tue, Mar 27, 2018 at 8:01 PM, Mike Besemer  wrote:

> Like or not, the inconsistency exists.  I'm not the one who set it up that
> way and neither of our opinions really matters anyway; the fact is that
> 7070 has been in use by PSK for over 15 years in Region 2 and there is no
> reason NOT to know that; it is widely published for anyone to see.  If you
> think I'm pulling that fact out of my posterior, feel free to Google it
> yourself.
>
> I'm not sure where you get the idea I have a limited world view; I clearly
> stated in several of my emails that things always go to hell in a
> handbasket when rare DX hits the bands.  As for not buying my comment about
> 7040 being mostly EU, that's the way the bandplan has it set up.  Again,
> Google is your friend.  If you're hearing PSK on 7040 during the day in
> your area, there are obviously stations in your area using it; leave it to
> the left coast to have it ass-backwards.  I'm not a no-code tech... I've
> been doing this for over 40 years and I don't appreciate you talking down
> to me.
>
> I get it... you don’t like PSK-31.  That's fine, but you need not throw
> stones at those of us who do.  If you like FT8 and the
> wham-bam-thank-you-ma'am type of contact, more power to you.  Those of us
> who care more about the human element of ham radio than our DXCC or grid
> count are fine with that.  All we ask is that you leave us the hell alone
> in our little 2 KHz segment of the band and for God's sake be a gentleman
> and listen before you transmit; anything less is nothing less than an
> indication of a piss-poor operator.   

Re: [wsjt-devel] DXpedition Mode on 40 Meters?

[Hasan al-Basri]

It doesn't matter how inconvenient it is to code in various region's FT8
"sub band". The DXp mode created the problem, it is already very
complicated code. The further complication of exclusion zones for DXp by
region, is a pittance compared to the initial investment.

Otherwise all we have is the tyranny of the majority, instead of respecting
the legitimate concerns of existing mode users.

*It was a virtual certainty that DXp would be abused*. It's one thing to
not have foreseen this (Law of Unintended Consequences), it is entirely
another to be dismissively indifferent to said consequences (let them eat
cake)

The utter hypocrisy of "NIMBY", is stunning. (Not in MY Back Yard). If DXp
is such a great thing and not disruptive, and only a minor inconvenience
that will "quiet down",  put your money where your mouth is do it
INSIDE the normal FT8 "allocation". Tell me what you think after a few "dx
operations"


Hasan

On Tue, Mar 27, 2018 at 7:51 AM, Tom Melvin <t...@tkrh.co.uk> wrote:

> Not going to work.
>
> Taking 40m as example -  What is the ‘FT8 allocation’ ? - all that could
> be coded would be the MGM allocation - nothing says FT8 needs to be 7.074 -
> UK band plan has digi modes 7.053 - 7.060  and the rest of the 7 Mhz
> allocation is ‘All Modes’.  PSK31 starts from 7.040 - which is actually
> well away from 7.071 that was in use last night.
>
> Yes there are a few 'centre of activities’, may vary slightly by region -
> heck a job to code all those into Dx mode esp the number of bands and
> regions there are these days.
>
> How many ‘proper’ DX piditions will there be? - if you have your favourite
> chat freq on SSB suddenly taken over by an expedition do you throw toys out
> of pram and blame those that introduced SSB - no you realises it will be a
> few days or a week or so and you live with it.
>
> The general usage of the watering holes will quieten down over time - not
> addressing that just the Dx Mode - 100% of the time it will be the
> expedition itself that specifies the frequencies they plan to use - it is
> those people you need to address this issue to.  Remind them there are
> others ‘watering holes’ in the all mode section they should avoid. Perhaps
> there should be a ‘Centre of activity’ on each band for DX operations?
>
> 73’
> Tom
> GM8MJV
>
>
>
>
> On 27 Mar 2018, at 13:15, mwbese...@cox.net wrote:
>
> Hasan,
>
> Thank you for that very eloquent post!  I think your suggestions are
> spot-on and I'd LOVE to see all of them implemented.
>
> 73,
>
> Mike
> WM4B
>
>
>
>
> On Tue, Mar 27, 2018 at 7:46 AM, Hasan al-Basri wrote:
>
>  I agree with every point that Mike (WM4B) made. DXpedition mode is
> becoming a scourge on the bands w/r to other modes.
>
>
> Another person asked for suggestion instead of complaints.
>
>
> OK, try this on:
>
>
> 1.Disable the mode until *real *precautions are taken to observe the
> current watering holes for other modes.
>
>
> 2. *Recode so that DXp mode can ONLY be run in the normal FT8 band
> space...that way, when these rogue or even legitimate DXp projects come on,
> they will trash the normal FT8 sections *...see how much you like it when
> your favorite operating (and agreed upon) frequencies are trashed by a
> bunch of hysterical dx'ers.
>
>
> Since DXp largely requires CAT mode, it should be straightforward (and
> only responsible on the part of the authors) to code in a requirement to *run
> DXp mode in the current FT8 Allotment.  *
> *They did it for WSPR... *
>
>
> This would be especially fitting since the FT8 authors created this
> monster...the FT8 crowd should be made to live with it.
>
>
> ...and it's easy to dismiss things as "not much of  a crisis" when it's
> someone else's nest that's being fowled.
>
>
> Maybe it's time for the FT8 nest to be fowled. and see how much that is
> appreciated.
>
>
>
> Hasan
>
> On Tue, Mar 27, 2018 at 6:22 AM, < *mwbese...@cox.net*> wrote:
> Gary,
>
> As I said, I've recently heard some very good conversation here about the
> need to avoid QRM to other modes; that's part of the reason it was so
> disappointing to see 40 meters get trashed last night all the way down to
> 7068 - or perhaps lower.
>
> The reason I address the developers is twofold.  First, I (for one)
> certainly saw the potential for this to happen when DXpedition mode was
> first discussed.  This is the genie they let out of the bottle and I can't
> believe they didn't' foresee the potential consequences.  Second, as
> developers, they should take some responsibility for how their product is
> used - and you'd certainly think they'd want it to be used

Re: [wsjt-devel] DXpedition Mode on 40 Meters?

[Hasan al-Basri]

My suggestions were specifically about the DXp mode, not FT8 in general.

..and it isn't a popularity contest, it's about observing the existing
watering holes.

PSK31 is in use, it will recover somewhat when more people get bored with
"wham bam , thankyou ma'am" operating style.

I enjoy both FT8 and PSK31, it need not be an either/or...but again, I am
only referring to DXp mode at this point, nothing else.

Do DXp INSIDE the current agreed upon FT8 frequencies, and then sort it out
amongst the FT8 users, instead of foisting it on others to live with.


Hasan

On Tue, Mar 27, 2018 at 7:14 AM, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Everybody needs to realize a little math here.
>
> In the last 2 hours there were 488 PSK reports showing on pskreporter.
> Compare that to 516,312 FT8 reports.
>
> 516,312/488 = 1058 times more.
>
> Now...let's say the odds of finding a bad actor in all those PSK reports
> is 1-in-488 over that 2 hour period.  Probably a conservative estimate of
> the # of ops who are operating too much power and causing intermod and
> harmonicsthough you may not see them since PSK sensitivity is notably
> less than FT8 plus we're only talking 1 observed problem in 2 hours.
>
> 1-in-488 PSK would mean over 1,000 in FT8 (500 per hour, 8 per minute).
> So the odds of seeing a problem child is greatly enhanced by the simple
> popularity and operating sequence of the mode.
>
> If the ARRL gets 15M, 40M, and 80M opened up to techncians this will only
> get worse.
>
> de Mike W9MDB
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] DXpedition Mode on 40 Meters?

[Hasan al-Basri]

I agree with every point that Mike (WM4B) made. DXpedition mode is becoming
a scourge on the bands w/r to other modes.

Another person asked for suggestion instead of complaints.

OK, try this on:

1.Disable the mode until *real* precautions are taken to observe the
current watering holes for other modes.

2. *Recode so that DXp mode can ONLY be run in the normal FT8 band
space...that way, when these rogue or even legitimate DXp projects come on,
they will trash the normal FT8 sections*...see how much you like it when
your favorite operating (and agreed upon) frequencies are trashed by a
bunch of hysterical dx'ers.

Since DXp largely requires CAT mode, it should be straightforward (and only
responsible on the part of the authors) to code in a requirement to *run
DXp mode in the current FT8 Allotment. *
*They did it for WSPR...*

This would be especially fitting since the FT8 authors created this
monster...the FT8 crowd should be made to live with it.

...and it's easy to dismiss things as "not much of  a crisis" when it's
someone else's nest that's being fowled.

Maybe it's time for the FT8 nest to be fowled. and see how much that is
appreciated.


Hasan

On Tue, Mar 27, 2018 at 6:22 AM,  wrote:

> Gary,
>
> As I said, I've recently heard some very good conversation here about the
> need to avoid QRM to other modes; that's part of the reason it was so
> disappointing to see 40 meters get trashed last night all the way down to
> 7068 - or perhaps lower.
>
> The reason I address the developers is twofold.  First, I (for one)
> certainly saw the potential for this to happen when DXpedition mode was
> first discussed.  This is the genie they let out of the bottle and I can't
> believe they didn't' foresee the potential consequences.  Second, as
> developers, they should take some responsibility for how their product is
> used - and you'd certainly think they'd want it to be used in a manner that
> would show them and their product in a positive light.
>
> Recent discussion suggested moving towards the underutilized JT
> frequencies, and I think that makes sense.  Aside from low utilization, FT8
> and the JT modes share a father, so I think it's only fair that they live
> together as family.
>
> Nobody is asking for a curtailing of anything except for poor operating
> practice.  Many PSK QSOs were QRM'd to the point of making communications
> impossible last night, and I don't believe for a minute that the PSK
> activity was not visible to the FT8 users.  There is no excuse for anyone
> on any mode to spoil the fun of others, and yet it's happening daily.  I
> agree that direction and guidance is needed, but I'm not so sure I agree
> with the ability to self-regulate; we all know that the rules go out the
> window when DX shows up.  If the shoe were on the other foot and some other
> mode were causing interference to your mode-of-choice, I have to think
> you'd be upset too.  I don't know what sort of guidance or discussion about
> being good neighbors is occurring on other email reflectors, but I hope
> there is active discussion about the problem.
>
> As I stated in another email, PSK is alive and well and I believe it is
> underreported by PSKReporter, based on observations of my own activity.
>
> With regard to a crisis, all I can tell you is that the PSK community is,
> for lack of a better word, pissed about the intrusion.  For the most part,
> we stick to about 1500 Hz in each band, but every time there is a digital
> contest, everyone creeps down to that segment.  But at least the contests
> were short-lived and predictable.  FT8 shows up with total randomness, but
> alarming regularity.  I supposed in reality there isn't a thing we PSKers
> can do about it and if FT8 wants to march over the top of us, you can
> certainly do it - but I'd really like to think it won't come to that.
>
> Despite my negative feelings towards the way the mode is being utilized
> now, I am NOT anti-FT8 (or anti any-mode), but I DO believe that what we're
> seeing now is extremely poor operating practice and it needs to be reigned
> in.  Now, I'm going to fade back into the noise and see what the bands look
> like this evening after 2200 or so with great hope that sanity and civility
> have been restored.
>
> 73,
>
> Mike
> WM4B
>
>
>
>
> On Tue, Mar 27, 2018 at 12:55 AM, g...@isect.com wrote:
>
> I don’t think it’s fair to blame the developers, Mike, or ask them to
>> resolve this – at least, not without help from the wider ham community.
>> They gave us the mode but we are the users – the tools are in our hands now
>> so we’re all part of this.
>>
>> Do you or anyone else have any specific or even general suggestions on
>> how to take this forward?  What are we hoping to achieve or avoid? What are
>> our priorities and timescales?
>>
>> Despite the emotive words, I am still not convinced there is a crisis
>> right now, nor is there necessarily one brewing.  I would be very reluctant
>> to curtail the 

Re: [wsjt-devel] DXpedition mode: dissapointed somehow

[Hasan al-Basri]

...but, they DO QRM others, that is why DXp is reserved for legitimate full
blown DXpeditions, not just rare DX Stations, but Full DXpeditions.

Otherwise, any time a "rare" dx station comes on, DXp mode destroys the
entire segment that it has hijacked from some other digital mode that is
used to running there. It is selfish, boorish and poor operating practice
to use DXp when you aren't a high demand full blown DXpedition.

Look at my posting in the WSJT-X group and you will see the difference.

73, N0AN


Hasan

On Wed, Mar 14, 2018 at 6:34 AM, Charles Suckling <
char...@sucklingfamily.free-online.co.uk> wrote:

> Jim
>
>
>
> I don’t think the test was on the designated FT8 frequency for 40m, or am
> I mistaken?
>
>
>
> In which case I thought “private” tests were OK provided they don’t QRM
> users of other modes?
>
>
>
> The answer to why the station is only transmitting to one station at a
> time is because Nslots would have been set to 1, I think.
>
>
>
> 73
>
>
>
> Charlie G3WDG
>
>
> --
>
> *From:* James Shaver (N2ADV) [mailto:n2...@windstream.net]
> *Sent:* 14 March 2018 10:25
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] DXpedition mode: dissapointed somehow
>
>
>
> TY7C should not have even been using DXPedition Mode.
>
>
>
> Jim S.
>
> N2ADV.
>
>
> On Mar 14, 2018, at 5:15 AM, DG2YCB, Uwe  wrote:
>
> Hi,
>
> Today I’ve had my first real-life experience with the new DXpedition mode.
> TY7C was the fox, the frequency was 7.070 MHz. The station came in with a
> rather stable signal around -12dB, and most stations (with exception of one
> Italian and one Romanian and a few others…) were following the instructions
> for DXpedition mode.
>
> However, I was somehow disappointed:
>
> - Although about five to ten hounds were calling TY7C simultaneously (in
> the correct range 1000 – 4000 Hz), in most cases TY7C sent his reply only
> to one station each. Means that number of QSOs per minute was nearly the
> same as in normal mode. As sometimes up to four stations occurred in the
> rage 300 – 900 Hz, there must have been more than one QSO in the queue. Why
> did that happen?
>
> - Fox disappeared and reappeared suddenly without any notice, leaving many
> stations alone who were then finally trying to call Fox in his rage. I
> don’t know whether there were some troubles with power supply, but all in
> all it was quite unsatisfactory.
>
> I don’t know either what might be improved. However, I wanted to share
> this experience with you. For the purpose of further analysis: here is
> traffic in Fox’s range (two times I activated Rx All Freqs):
>
>  40m
>
> 064730 -10 -0.1 298 ~ F6GCP TY7C RR73
>
>  40m
>
> 064830 -10 -0.1 298 ~ IK8DNJ TY7C +13
>
>  40m
>
> 064900 -12 -0.1 298 ~ IK8DNJ TY7C +13
>
>  40m
>
> 064930 -11 -0.5 298 ~ IK8DNJ TY7C RR73
>
>  40m
>
> 065000 -11 -0.1 298 ~ IK8DNJ TY7C RR73
>
>  40m
>
> 065030 -8 -0.1 297 ~ CQ TY7C JJ16  ~Benin
>
>  40m
>
> 065100 -10 -0.1 298 ~ CQ TY7C JJ16  ~Benin
>
>  40m
>
> 065130 -11 -0.1 297 ~ CQ TY7C JJ16  ~Benin
>
>  40m
>
> 065200 -9 -0.1 297 ~ CQ TY7C JJ16  ~Benin
>
>  40m
>
> 065230 -10 -0.1 297 ~ CQ TY7C JJ16  ~Benin
>
>  40m
>
> 065345 5 0.2 419 ~ TY7C F8BUO -04
>
> 065345 2 0.2 500 ~ TY7C ZL1AIX -06
>
> 065345 -6 -0.8 588 ~ TY7C DL5MFS -09
>
> 065345 7 0.1 1838 ~ TY7C F8DZU R-17
>
>  40m
>
> 065415 5 0.2 419 ~ TY7C F8BUO -04
>
> 065415 0 0.2 500 ~ TY7C ZL1AIX -06
>
> 065415 -8 -0.8 688 ~ TY7C DL5MFS JN58
>
> 065415 -16 0.1 995 ~ TY7C KU4XO EM84
>
> 065415 9 0.1 1838 ~ TY7C F8DZU R-17
>
>  40m
>
> 065430 -3 -0.2 298 ~ N6ML TY7C +05
>
>  40m
>
> 065500 -11 -0.2 297 ~ N6ML RR73; ON6SM  +03
>
>  40m
>
> 065530 -11 -0.3 297 ~ ON6SM TY7C +03
>
>  40m
>
> 065600 -10 -0.2 297 ~ ON6SM TY7C +03
>
>  40m
>
> 065630 -8 -0.2 298 ~ ON6SM TY7C +03
>
>  40m
>
> 065645 -4 0.2 500 ~ TY7C ZL1AIX -06
>
> 065645 -7 -0.8 687 ~ TY7C DL5MFS -08
>
> 065645 -18 0.1 995 ~ TY7C KU4XO EM84
>
>  40m
>
> 065700 -8 -0.2 297 ~ ON6SM TY7C +03
>
>  40m
>
> 065730 -11 -0.2 297 ~ F6EQZ TY7C -01
>
>  40m
>
> 065800 -12 -0.2 297 ~ F6EQZ RR73; DG2YCB  -17
>
>  40m
>
> 065830 -9 -0.2 297 ~ DG2YCB TY7C -17
>
>  40m
>
> 065900 

Re: [wsjt-devel] Status patch

[Hasan al-Basri]

Bill and Mike:

I have received an updated pstRotatorAZ file from Codrut,  to test with the
new Grid Square presence in wsjtx_status.txt

Initial tests successful.

I clicked on a CQ with Grid square and rotor turned to grid
coordinateAND, there was no lookup or call fill-in next to the green Go
button. That means, to methat it used the Grid Square and ignored the
call sign...PERFECT. USA Station with Grid

Then...I double clicked on a call where they were in QSO, so there was no
grid square. A call populated the box next to the Green Go button, info
returned and rotor turned to the FCC database bearing. USA Station w/o Grid

Now...DX Station with Girid: IT9PQO. Antenna turned to 49 deg , same
heading as in WSJT-X.

Now...DX Station with no Grid: DF1MHL. He was sending RRR, of course, no
Grid. Antenna did not turn! (DF1 probably missing from pstRotatorAZ
internal dx database)

Another DX Station with no Grid: LU5HA. Called filled in the Box next to
Green button and antenna turned to proper heading for Argentina.

DX Stations with No Grids:

ZF2A: Turned to proper heading
DL2IAU: Ditto
YU7YG: Ditto
IU8BWU: Ditto

Summary:

In USA Grid or  no Grid work perfectly every time.
DX: Grid works perfectly every time.
DX: No Grid works nearly all the time, some prefixes probably not in
database.

Congrats, Codrut, it looks like it works perfectly! I will give it a more
thorough workout tomorrow morning on 6 meters meteor scatter, where all
will be in USA (or maybe a Canad or Mexico)

Thanks so much...will report back more if anything else shows up while I'm
on 20m this afternoon.

I'll let everyone know when the testing is finished and Codrut has released
a new public version.

Thanks to the TEAM!

73, N0AN

Hasan

On Tue, Mar 6, 2018 at 3:57 PM, Bill Somerville 
wrote:

> On 01/03/2018 23:05, Black Michael via wsjt-devel wrote:
>
> I sent this about 4 days ago but haven't heard anything about it
> Is this OK to apply?
>
> Add hisGrid to wsjtx_status.txt so programs like PstRotatorAZ can use
> actual grid. Assigns "NA" if not available.
>
> https://www.dropbox.com/s/rbibasioq6io8nd/status.patch?dl=1
> 
>
> de Mike W9MDB
>
> Hi Mike,
>
> is the choice of "NA" for grid not available for any firm reason? I would
> prefer something less ambiguous like "n/a" if that is ok.
>
> 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
>
>
--
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] Frequency Labels Suggestion

[Hasan al-Basri]

You can have as many lists with as much or as little frq info as you like,
if you will just create a configuration for it.

I did this for the Fox/Hound Test. I Cloned a working FT8 configuration. I
switched to that "Copy (as it is labled -Copy) , then renamed it to
Fox/Hound Test.

Then I went into the Freq Table and deleted all entries. At this point, all
I had to do was put in the 20/30/40/80 m freqs (Right Click Insert)
frequencies.

No separate list is needed. Just do a config and you're set.

I have separate configurations for:

FT8 HF and VHF
6M MSK144
Default
FT8 Fox and Hound
JT9G HF Scatter
WSPR

In each case, I just click on Configurations and select one of the above.
They all have their own Freq Table. Couldn't be simpler.
If a "real" DXpedition shows up, Clone your FT8 Fox and Hound test config,
switch to that copy, rename to KH7 Baker Island, set freqs in the
tabledone.

You can have as many configs as you like and they can be highly customized.

73, N0AN

Hasan

On Fri, Mar 9, 2018 at 12:34 PM, David Tiller  wrote:

>  > If the future actual fox/hound dxpedition modes are going to be on
> non-standard frequencies like the
>
> > recent test was, it would be good if we could add a label to the
> frequencies so that we don't get confused
>
> > after we capture the fox and go back to regular mode.
>
>
> How about a separate list for normal ops vs fox/hound ops?
>
>
> *David Tiller | *Senior Manager
> dtil...@captechconsulting.com
> c 804.304.0638 <(804)%20304-0638> / o 804.355.0511 <(804)%20355-0511>
>
> 
>
> 
> 
> 
> 
> 
> 
> *Best Firms 2016 #2* in Information Technology
>
>
> --
> *From:* Kirk Crawford 
> *Sent:* Friday, March 9, 2018 1:22 PM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* [wsjt-devel] Frequency Labels Suggestion
>
> If the future actual fox/hound dxpedition modes are going to be on
> non-standard frequencies like the recent test was, it would be good if we
> could add a label to the frequencies so that we don't get confused after we
> capture the fox and go back to regular mode.  I personally deleted the
> frequencies I had entered for the open fox/hound test afterwards because
> then I had two 20m and 40m etc in my drop down menu.  If we had a label
> that showed up in that menu as well, we could distinguish the frequencies
> easier than just the number.
>
> Kirk
> KK6KC
>
>
> --
> Kirk Crawford
> k...@kirkanddonna.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
>
>
--
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] Timer

[Hasan al-Basri]

All four stations were strong. K1JT started out at +15 on 20 meters, but
within 20 minutes had dropped to -23  (late afternoon band change). 30 dB
change in about 20 minutes...talk about catching the band moving!

Completed with all 4 stations, but one completion was aided by a trick on
my end. After I had been "moved" to the lower freq tier by the Fox, it put
me in a mess of others. So I watched the rx window for a while and when I
saw a  hole develop, I moved my TX there (still in the lower freq tier area
where the Fox had put me, but in a clearer spot). Immediately on my next
transmission, the qso finished out.

The attached image shows a  nice trace of the N=5 Fox ...very cool!

It was a fun test, noticed same anomalies as others. Had two lockups on Rx.
Killed and restarted program and all was fine.

Deliberate qrm was significant in amount, but  ineffective. I saw it all,
but it cause me no problems with the Fox, nor completing contacts.

I look look forward to the next test. This was MOST enjoyable. Congrats to
the team!

73, N0AN



Hasan

On Wed, Mar 7, 2018 at 10:09 AM, Joe Taylor  wrote:

> Jim --
>
> I don't think you had to scramble.  If Fox calls you, your Tx3 message
> will be sent (somewhere in 300-900 Hz), even if Tx Enable is not engaged.
> -- Joe
>
>
> On 3/7/2018 11:05 AM, James Shaver wrote:
>
>> Yep, twice the timer had expired on me right as the “Fox” called me and I
>> had to scramble.
>>
>> Jim S.
>> N2ADV
>>
>> *From:*Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourc
>> eforge.net]
>> *Sent:* Wednesday, March 7, 2018 11:03 AM
>> *To:* WSJT Software Development
>> *Cc:* Bill Turner
>> *Subject:* [wsjt-devel] Timer
>>
>> Great job with the test last night.  I did find the 2 minute timer to be
>> a real pain, however. I understand you do not want a robot operation, but a
>> 5 or 10 minute timer would be less frustrating.
>>
>> When the software shuts off the Enable TX, how do we know that we are
>> still on the correct sequence when we click on Enable TX?  I noticed some
>> comments about folks calling on the wrong sequence last night.
>>
>> Again, thanks for the effort in the test.
>>
>> Bill Turner, W4WNT
>>
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Timer

[Hasan al-Basri]

Bill,

TX timeout timer is about right. Prevents non-stop (when not being heard)
QRM from Hounds. Also, when it times out, you have time to let a couple
cycles go by and see where in the band it might be best to call (look for
hole).

I did this multiple times (let it expire), watched the pileup, found a
hole, then simply hit Enable Tx...off it went. No settings needed to be
changed.

Sequence is automatic, no intervention needed. If people were off sequence
it was either caused by 1) Incompetence, 2) a bug , 3) Deliberate
interference, of which  there was a bunch.

As far as the Hounds are concerned, there is no sequence...it is all
controlled by the Fox. If you double click on the Fox, after setting your
Tx freq > 1000, then the only intervention required is if you aren't
getting heard, and then just Enable Tx again.

73, N0AN



Hasan

On Wed, Mar 7, 2018 at 10:02 AM, Bill Turner via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Great job with the test last night.  I did find the 2 minute timer to be a
> real pain, however. I understand you do not want a robot operation, but a 5
> or 10 minute timer would be less frustrating.
>
> When the software shuts off the Enable TX, how do we know that we are
> still on the correct sequence when we click on Enable TX?  I noticed some
> comments about folks calling on the wrong sequence last night.
>
> Again, thanks for the effort in the test.
>
> Bill Turner, W4WNT
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Timing

[Hasan al-Basri]

1. Cheap: WWV (free) Set manually. It's easy to get within 1 second.
2. BktTimeSync (free and will use either internet or gps)
3. Meinberg (free)
4. Dimension4 (free)

All work . I have used 2 and 4 and they are both terrific.

Lastly, the timing requirement has been relaxed a bit, about 2 seconds or
2.5...in any case, you should run a timesetting program as above and you
will be within milliseconds..

73, N0AN




Hasan

On Thu, Nov 16, 2017 at 5:27 PM, Gilbert Baron  wrote:

> What is the best timing software for W10? I did not realize the need for 1
> sec accuracy when I started thinking about these modes.
>
>
>
> W0MN EN34rb 44.08226 N 92.51265 W
>
> Hierro candente, batir de repente
>
> HP Laptop
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] False Frequency reports

[Hasan al-Basri]

If that was fixed, I missed it! It would be wonderful if that's the case.
I'll have to watch for it. Tnx tip

73, N0AN

Hasan

On Wed, Oct 25, 2017 at 9:17 PM, Gary McDuffie <mcduf...@ag0n.net> wrote:

>
>
> > On Oct 25, 2017, at 7:51 PM, Hasan al-Basri <hbasri.schie...@gmail.com>
> wrote:
> >
> > A radio connection does not prevent false reports from being sent to
> pskr. If one switches frequencies at just the right time, the report will
> be wrong, even if cat control is being used.
>
> I thought that was corrected in an earlier version.  Reports stop for a
> brief time after changing frequencies???
>
> I still think disabling pskreporter reports being sent when not using
> working CAT is a simple fix.
>
> 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
>
--
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] Capter 13.1 Freq Cal document problems 1.8-RC3

[Hasan al-Basri]

Nice job of cleaning that mess up, Neal. Thanks and I'll send that out
when/if further requests come in.

PDF version looks pretty good, that was done by WA5TKU, I think.

73, N0AN

Hasan

On Fri, Oct 20, 2017 at 9:41 PM, Neal Pollack <nea...@gmail.com> wrote:

> Wow.
> Perfect.
> The missing manual :-)
>
> As a thanks, I took a try at cleaning up the text formatting, and
> re-attached the MS doc file for you.
>
> THANKS again,
>
> Neal
> N6YFM
>
> On Fri, Oct 20, 2017 at 4:16 PM, Hasan al-Basri <hbasri.schie...@gmail.com
> > wrote:
>
>> Neal,
>>
>> That's why I wrote the attached. If you follow it, it will work.
>>
>> (I'm not a developer...I had to work through the instructions to end up
>> with what I"m sending you.)
>>
>> If you  have RC3 1.80 WSJT-X, these instructions work perfectly.
>>
>> Lemme know how you make out.
>>
>> 73, N0AN
>>
>> Hasan
>>
>> On Fri, Oct 20, 2017 at 2:31 PM, Neal Pollack <nea...@gmail.com> wrote:
>>
>>> I was unable to get the Frequency Calibration to work for me due
>>> to multiple vague, unclear portions of the manual that must assume
>>> the user was also the developer or had previously been shown how
>>> to use it.
>>>
>>> The following are questions, but they need to be clarified IN THE MANUAL,
>>> not just in reply here.
>>>
>>> *Problems:*
>>>
>>> A.  In this portion:
>>>
>>>
>>> * In the Working Frequencies box on the Settings → Frequencies tab,
>>> delete any default frequencies forFreqCal mode that are not relevant for
>>> your location. You may want to replace some of them with reliablyknown
>>> frequencies receivable at your location.*
>>>
>>> There is no description as to how many local station editions are
>>> sufficient, or if we should delete
>>> ALL frequencies that are difficult to receive locally.   How many WWV
>>> and local broadcast stations
>>> are enough?
>>>
>>> B.   in this portion;
>>>
>>>
>>>
>>> *To cycle automatically through your chosen list of calibration
>>> frequencies, check Execute frequencycalibration cycle on the Tools menu.
>>> WSJT-X will spend 30 seconds at each frequency. Initially nomeasurement
>>> data is saved to the fmt.all file although it is displayed on screen, this
>>> allows you tocheck you current calibration parameters.*
>>>
>>> 1.  What mode does the transceiver need to be in?  Leave it in
>>> USB-DATA mode, or change it?
>>> 2.   Does the cycle really start when I select the Execute Cal menu
>>> choice, or do I then need to
>>>   check the MESAURE tick box on screen before it really starts?
>>>
>>> C.  In this portion:
>>>
>>>
>>>
>>> *To start a measurement session check the Measure option and let the
>>> calibration cycle run for at leastone complete sequence. Note that, while
>>> measuring, any existing calibration parameters are automaticallydisabled so
>>> you may have to increase the FTol range if your rig is off freqeuncy by
>>> more than a few Hertzin order to capture valid measurements.*
>>>
>>> So, presumably the user is doing this calibration because they have NO
>>> IDEA how far off their rig
>>> might be.  So what is a safe/decent starting point for the FTol range
>>> for new users?
>>>
>>> D.  In this portion:
>>>
>>> * With modern synthesized radios, small measured offsets from 1500 Hz
>>> will exhibit a straight-line dependenceon frequency.* [Which is below
>>> the graphic on page 68]
>>>
>>> I am trying this for the first time with a Yaesu FT-DX3000 that I have
>>> never used for digi-modes.
>>> [My previous 4,000 QSOs with WSJT-X have been using an Icom 7300].
>>> I notice the received carrier line at 2500 hz.  The graphic on page 68
>>> shows the
>>> received carrier lines at approx 1500 hz.
>>> So it seems there is an approx 1,000Hz offset between my Yaesu FT-DX3000
>>> VFO display
>>> and the WSJT-X waterfall.I don't see this on my Icom 7300.
>>> So next, I went back to FT8 mode, and sure enough, at 7.074 Mhz there
>>> was very little activity.
>>> But if I turned the radio VFO knob to 7.075, the WSJT-X waterfall became
>>> quite crowed as
>>> expected.
>>> Are there any other Yaesu FT-DX3000 users that can explain if this
>>> of

Re: [wsjt-devel] Capter 13.1 Freq Cal document problems 1.8-RC3

[Hasan al-Basri]

Neal,

That's why I wrote the attached. If you follow it, it will work.

(I'm not a developer...I had to work through the instructions to end up
with what I"m sending you.)

If you  have RC3 1.80 WSJT-X, these instructions work perfectly.

Lemme know how you make out.

73, N0AN

Hasan

On Fri, Oct 20, 2017 at 2:31 PM, Neal Pollack  wrote:

> I was unable to get the Frequency Calibration to work for me due
> to multiple vague, unclear portions of the manual that must assume
> the user was also the developer or had previously been shown how
> to use it.
>
> The following are questions, but they need to be clarified IN THE MANUAL,
> not just in reply here.
>
> *Problems:*
>
> A.  In this portion:
>
>
> * In the Working Frequencies box on the Settings → Frequencies tab, delete
> any default frequencies forFreqCal mode that are not relevant for your
> location. You may want to replace some of them with reliablyknown
> frequencies receivable at your location.*
>
> There is no description as to how many local station editions are
> sufficient, or if we should delete
> ALL frequencies that are difficult to receive locally.   How many WWV and
> local broadcast stations
> are enough?
>
> B.   in this portion;
>
>
>
> *To cycle automatically through your chosen list of calibration
> frequencies, check Execute frequencycalibration cycle on the Tools menu.
> WSJT-X will spend 30 seconds at each frequency. Initially nomeasurement
> data is saved to the fmt.all file although it is displayed on screen, this
> allows you tocheck you current calibration parameters.*
>
> 1.  What mode does the transceiver need to be in?  Leave it in
> USB-DATA mode, or change it?
> 2.   Does the cycle really start when I select the Execute Cal menu
> choice, or do I then need to
>   check the MESAURE tick box on screen before it really starts?
>
> C.  In this portion:
>
>
>
> *To start a measurement session check the Measure option and let the
> calibration cycle run for at leastone complete sequence. Note that, while
> measuring, any existing calibration parameters are automaticallydisabled so
> you may have to increase the FTol range if your rig is off freqeuncy by
> more than a few Hertzin order to capture valid measurements.*
>
> So, presumably the user is doing this calibration because they have NO
> IDEA how far off their rig
> might be.  So what is a safe/decent starting point for the FTol range for
> new users?
>
> D.  In this portion:
>
> * With modern synthesized radios, small measured offsets from 1500 Hz will
> exhibit a straight-line dependenceon frequency.* [Which is below the
> graphic on page 68]
>
> I am trying this for the first time with a Yaesu FT-DX3000 that I have
> never used for digi-modes.
> [My previous 4,000 QSOs with WSJT-X have been using an Icom 7300].
> I notice the received carrier line at 2500 hz.  The graphic on page 68
> shows the
> received carrier lines at approx 1500 hz.
> So it seems there is an approx 1,000Hz offset between my Yaesu FT-DX3000
> VFO display
> and the WSJT-X waterfall.I don't see this on my Icom 7300.
> So next, I went back to FT8 mode, and sure enough, at 7.074 Mhz there was
> very little activity.
> But if I turned the radio VFO knob to 7.075, the WSJT-X waterfall became
> quite crowed as
> expected.
> Are there any other Yaesu FT-DX3000 users that can explain if this offset
> is a Yaesu setting, menu,
> or known feature of the Yaesu?
>
> E.  In this portion:
>
> *After running Execute frequency calibration cycle at least once with good
> results, check and edit the filefmt.all in the log directory and delete any
> spurious or outlier measurements.*[which is below the line fitting graph
> shown on page 69]
> Two questions;
>   1.  After running?   How do you stop it?   Cycling the Tools menu or
> the on-screen measure tick box?
>I did manage to get the application to lock up more than once.
>
>   2.  Delete any spurious measurement?   OK,  How do I know what is
> considered a spurious measurement?
>After managing to stop or get the app to lock up, I  opened
> fmt.all.  There is not an example extract of
> the log shown in the doc, but mine has Df's that vary as much as +/- 18
> hz.  What is normal?  Is that too much?
> The doc should provide guidance to a first-timer on what would be
> considered good data and why, so they
> know what to delete and what to leave.
>
>3.  When I next select tools menu option Solve for Calibration
> Parameters, I get a pop-up about
> bad data.  I assume that is related to not knowing how to prune, per above
> comments?
>
>
>
> I hope this helps improve the manual for new users like myself.
>
> Cheers,
>
> Neal
> N6YFM
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 

Re: [wsjt-devel] WSJT 1.8.0 RC3

[Hasan al-Basri]

True, Dave, I don't know what the solution for that might be. (I'm not a
developer, just an avid and enthusiastic user).

Hopefully there is a way to accommodate you.

73, N0AN

Hasan

On Tue, Oct 17, 2017 at 3:39 PM, Dave Thorpe <d...@webslave.co.uk> wrote:

> That does not work if you only have one functioning hand!
>
>
>
> Regards
>
>
>
> Dave
>
> (M6RUG)
>
>
>
> *From:* Hasan al-Basri [mailto:hbasri.schie...@gmail.com]
> *Sent:* 17 October 2017 21:19
> *To:* WSJT software development <wsjt-devel@lists.sourceforge.net>
> *Subject:* Re: [wsjt-devel] WSJT 1.8.0 RC3
>
>
>
> Probably not and easily worked around. Instead of double clicking on the
> station, do a Ctrl-Double Click...that will put rx and tx on same freq.
>
>
>
> Just learn the "new" way to do the old thing and you will be fine. Lock Rx
> /Tx was removed for good reasons...but I don't want to get into a
> discussion of that, as it has been beaten to death.
>
>
>
> If your goal is to have it work the way it used to, then it only involves
> the holding down of the ctrl key when you double click.
>
>
>
> 73, N0AN
>
>
> Hasan
>
>
>
> On Tue, Oct 17, 2017 at 2:19 PM, Chris Getman <chris.getman...@gmail.com>
> wrote:
>
> I just downloaded Version 1.8.0 RC3 and found it missing the Lock Rx-Tx
> feature.
>
> In using FT8 from the beginning, I have only twice found a station wanting
> to work splits.
>
> So I really miss this feature.
>
> Any chance of putting it back?
>
>
>
> 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
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT 1.8.0 RC3

[Hasan al-Basri]

Probably not and easily worked around. Instead of double clicking on the
station, do a Ctrl-Double Click...that will put rx and tx on same freq.

Just learn the "new" way to do the old thing and you will be fine. Lock Rx
/Tx was removed for good reasons...but I don't want to get into a
discussion of that, as it has been beaten to death.

If your goal is to have it work the way it used to, then it only involves
the holding down of the ctrl key when you double click.

73, N0AN

Hasan

On Tue, Oct 17, 2017 at 2:19 PM, Chris Getman 
wrote:

> I just downloaded Version 1.8.0 RC3 and found it missing the Lock Rx-Tx
> feature.
>
> In using FT8 from the beginning, I have only twice found a station wanting
> to work splits.
>
> So I really miss this feature.
>
> Any chance of putting it back?
>
>
>
> 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
>
>
--
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] r8053 FreqCal with Apply Works Very Well

[Hasan al-Basri]

I just did a FreqCal on my SDR using the new method in r8053.

It now not only calculates and tests the values collected in fmt.all, it
has an Apply button that writes the values for Slope and Intercept to the
Settings > Frequencies boxes supplied for same.

It also deletes fmt.all, after you tell it to apply.

Very nice!

Results: (10 minutes,0.640,  2.5, 3.3, 5, 10 MHz)

Slope: 0.5635, Intercept: 0.27 Hz

SDR Dial on 50.260 reads 50.260.029
My well calibrated TX sig from TS-590sg: 1499 Hz
K5GZR reads 1503 on both SDR and TS-590sg

Don't think I could ask for more. Tnx much,

73, N0AN
Hasan
--
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] Solve For Calibration Parameters: Suggestion

[Hasan al-Basri]

r8144

When the pop up window shows the results of the calibration run with Slope
and Intercept presented, wouldn't it be nice to have a button or check box
that says:

"Apply Calibration Results Now"...or some such?

Right now OK, closes the window, which is fine, but it would save a lot of
keyboarding if  "APPLY" were a choice and those values were then written to
the appropriate location.

It needs to be a choice, so that current or desired values are not
overwritten.

This is "spit and polish" at best...not essential or even remotely high
priority. After all, it is just some typing on our end.

73, N0AN
Hasan
--
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] Repeating Crash When Changing Slope and Intercept

[Hasan al-Basri]

Every time I either zero out or change the slope and intercept after doing
a calibration run, I get a program crash, and stale lock.

When I restart, the new values are in place and things run fine.

This has been last several versions since I've been playing with FreqCal

Currently r8144

73, N0AN
Hasan
--
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 Internal FreqCal Mode with Solve For ...

[Hasan al-Basri]

r8144 for reference

First of all WONDERFUL.
Makes all that writing I did superflous.

An important reminder (I think):

If you are going to do repeated runs using different frequencies (for
example, eliminating 20 MHz wwv for a night run, or eliminating 2.5 MHz wwv
for a day run), be sure to ZERO OUT your Slope and Intercept values and
delete your fmt.all before you begin a new run

I forgot to do the 1st part (ZERO OUT)...and wasted 2 hours of data
collection, because I was calibrating the calibration...very bad idea).

B4 someone asks, why in the world would you collect data for 2
hours...well, I was making a trip, the radio wasn't doing anything else, so
...

I am doing different runs at different times of the day with different
frequency references, to see how the results differ with the internal
solution provided.

I'm going to do the following:

Use only WWV from 5-20 MHz
Use only WWV from 2.5 to 15 MHz
Use Broadcast Band (BB) 0.640 thru 10 MHz night
Use BB, CHU, WWV at night thru 10 MHz night
Use BB and everything I can find thru 20 MHz day.

I have a baseline to compare to these new runs that has shown itself to be
VERY accurate on 6m MSK144 (Kenwood TS-590sg)

A:-0.78 Hz B: 0.4400 ppm StdDev: 0.257 err: A (0.03) B (0.0021)

These values on my TS-590sg agree with my SDR, and 3 different GPSDO
stations on MSK144...within 1 or 2 Hz at 50.260  (excluding doppler and any
measurement error.)

This is for my own entertainment. I doubt it has any real value for
software development. But, just in case it does... I'll try to put together
a table showing the variables and the results those variables produced. It
may help users decide what the most efficient method of data collection is.

​73, N0AN
​
Hasan
--
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] Same freq moves = QRM!

[Hasan al-Basri]

Rich,

I agree with you completely,  as my experience is the same as yours. No
matter how it is implemented, I'm typically NOT going to call on on the OPS
Tx freq...it is too congested and just adds to the "local" QRM.

It is true that the band fills up with spread out callers using our
approach...but FT8  has no problems with that and there is a lot more room
in the band than on the TX freq fo the originating station.

Calling on the TX frq for a popular station is inefficient, being more
subject to the pileup qrm..but hey, people can do what they want. FT8 gets
decoded wherever it can...and rarely is that on the TX freq of the DX
station.

For casual contacts tx/rx same can work, but if I am actually invested in
working someone, I don't call them on their freq.

73, N0AN



Hasan

On Tue, Sep 26, 2017 at 10:00 AM, Rich - K1HTV  wrote:

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

[Hasan al-Basri]

Ed,

I thought it was a bug too, but it was explained that it was often
desirable to set up a qso by calling even though the is another caller...it
lets people get in line and speeds up the operation. Of course, it clutters
the band a bit too.

73, N0AN

Hasan

On Tue, Sep 26, 2017 at 7:14 AM, Ed Wilson via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hasan,
>
> Thanks for the comment!
>
> Although it may be a feature, I found myself causing QRM several times
> yesterday when I was working FT8 split and some station did not answer me.
> It might not be as much a problem with JT65 or JT9 when there are
> approximately 10 seconds to react and disable Tx manually.
>
> Ed, K0KC
>
> k...@arrl.net
> http://k0kc.us/
>
>
> On Tuesday, September 26, 2017, 8:03:08 AM EDT, Hasan al-Basri <
> hbasri.schie...@gmail.com> wrote:
>
>
> That's a feature,  not a bug, i.e., intentional
> 73, N0AN
>
> Hasan
>
> On Tue, Sep 26, 2017 at 6:30 AM, Ed Wilson via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Although it is not new to r8123, I have noticed that when I call a station
> and someone else is also calling him or her and that calling station does
> not answer me, Tx is not disabled when the Tx frequency is offset from the
> receive frequency. If the Tx and Rx frequencies are the same, Tx is
> disabled as expected (my English teacher would be ashamed of me for the
> run-on sentence).
>
> Again, just an observation to assist in development...an easy work-around.
>
> Ed, K0KC
>
> k...@arrl.net
> http://k0kc.us/
>
> -- --
> --
> 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 <wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/ lists/listinfo/wsjt-devel
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
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 r8123 Comment

[Hasan al-Basri]

That's a feature,  not a bug, i.e., intentional
73, N0AN

Hasan

On Tue, Sep 26, 2017 at 6:30 AM, Ed Wilson via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Although it is not new to r8123, I have noticed that when I call a station
> and someone else is also calling him or her and that calling station does
> not answer me, Tx is not disabled when the Tx frequency is offset from the
> receive frequency. If the Tx and Rx frequencies are the same, Tx is
> disabled as expected (my English teacher would be ashamed of me for the
> run-on sentence).
>
> Again, just an observation to assist in development...an easy work-around.
>
> Ed, K0KC
>
> k...@arrl.net
> http://k0kc.us/
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Dx Call Entry with Gnerate Std Msgs Should Default to TX6 (CQ)

[Hasan al-Basri]

Thanks Steve. ..most interesting.

While it is true that the prior state is retained, let's look at the
probability of the two paths being desired.

1. Is Gen std msgs really used to call cq, or is one more likely to simply
choose tx6, which is CQ, and hit enable Transmit. In all my use of the
software, I have never used Gen std msgs to call cq.

2. In well over 90% of my instant skeds  setup on ping jockey, they never
start with cq, but by specifying the callsign of my partner...because the
qso goes faster if you start wit the call (MSK144 ).

To me the real question is: When using Gen Std Msgs, what is the most
likely action to follow?

In my case, the ONLY time I use that function is to begin a sked. ..and all
my skeds are directed to a callsign.

Perhaps I'm just a victim of my own habits with X 

The bottom line for my suggestion is just operator convenience : is it more
likely that a directed call (tx1), or a CQ take place after Gen Std Msgs is
invoked?

Whichever is most likely is how I would "default" the tx message after Gen
std msgs is invoked.

I can learn it either way, so no biggie. One way seems intuitive to me, and
the other requires an additional step (changing from a prior tx msg to get
to the tx1 sked message.)

Thanks for taking the time to respond, Steve, I do appreciate it, as well
as all the effort put into this amazing piece of software.
73, N0AN

Hasan

On Sep 12, 2017 8:49 PM, "Steven Franke" <s.j.fra...@icloud.com> wrote:

> Hi Hasan,
>
> The behavior that I observe is: populate the DX Call box, click Generate
> Std Msgs box, and the TX1 thru TX6 boxes are populated. The Tx state
> remains wherever it was when this sequence of steps was initiated. If I
> Generate Std Msgs with the Tx1 box checked, then the Tx1 box remains
> checked after the messages are generated. I don’t see the problem. Surely
> it should be up to the operator to determine which state to start in.
>
> Further, it is surely reasonable that one side of a prearranged sked might
> want to populate the DX Call box and then call CQ.  As you know, skeds
> sometimes proceed this way - two stations meet on a frequency with a prior
> understanding that, say, “A” would answer “B’s” CQ, if possible.
>
> Steve k9an
>
> On Sep 12, 2017, at 9:22 PM, Hasan al-Basri <hbasri.schie...@gmail.com>
> wrote:
>
> I have played with this quite a bit and cannot figure out the reason for
> the following:
>
> I meet a station on Ping Jockey and we agree to begin a qso.  I enter his
> call in the blank DX Call box , K1SIX. I click the Generate Std Msgs box,
> and the TX1 thru TX6 populate.
>
> But...the TX defaults to TX6...CQ...that makes no sense to me.
>
> Any time someone bothers to Generate Std Messages, it seems to me that the
> next operation is most certainly going to be TX1...I can think of no
> circumstance after hitting Gen Std Msgs that I would be calling CQ.
>
> Is it possible that any time GEn Std Msgs is clicked, the default
> operation could be set to TX1 ?
>
> Please excuse me if I'm missing something obvious, maybe I'm just blinded
> by my own operational style.
>
> TIA, 73 N0AN
> Hasan
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://slashdot.org>!
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Dx Call Entry with Gnerate Std Msgs Should Default to TX6 (CQ)

[Hasan al-Basri]

I have played with this quite a bit and cannot figure out the reason for
the following:

I meet a station on Ping Jockey and we agree to begin a qso.  I enter his
call in the blank DX Call box , K1SIX. I click the Generate Std Msgs box,
and the TX1 thru TX6 populate.

But...the TX defaults to TX6...CQ...that makes no sense to me.

Any time someone bothers to Generate Std Messages, it seems to me that the
next operation is most certainly going to be TX1...I can think of no
circumstance after hitting Gen Std Msgs that I would be calling CQ.

Is it possible that any time GEn Std Msgs is clicked, the default operation
could be set to TX1 ?

Please excuse me if I'm missing something obvious, maybe I'm just blinded
by my own operational style.

TIA, 73 N0AN
Hasan
--
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