[3830] 50SprngSprnt K2DRH Single Op HP

webform at b4h.net webform at b4h.net
Sun May 12 08:29:04 EDT 2019


                    50 MHz Spring Sprint - 2019

Call: K2DRH
Operator(s): K2DRH
Station: K2DRH

Class: Single Op HP
QTH: EN41vr
Operating Time (hrs): 

Summary:
Total:  QSOs = 67  Mults = 38  Total Score = 2,546

Club: Society of Midwest Contesters

Comments:

Got the repaired stackmatch back up the tower and the 8x7 array working again
the day before so it was nice to have the direction diversity and angle steering
capability back.  Seemed to be decent activity locally and I was busy on SSB for
the first half hour before it reverted to an FT8 contest.  Saw several Es 
bubbles to the NE to and Atlantic areas that kept recurring and tried to exploit
them on FT8, but except for N1JEZ in FN44 in the second hour and K1TOL also in
FN44 at the very end, they were too quick or too weak.  

It was only late into the third hour and the last hour when I asked several
stations on ON4KST to do MSK144 that we made several good long distance QSOs. 
Even had one instance where I was splitting the sequence and running two QSOs at
once like in the old days with FSK441 30 second sequences!  I had a third
instance of WSJT-X running on FT4 and saw a few stations from time to time
trying the new mode but missed them until I captured K0GU and K9MU for my only
two FT4 QSOs. 

Guess I shouldn’t have been surprised to see a lot of stations not in contest
mode, but I was surprised that a few would not advance the QSO past TX2 without
me reverting back to “funny numbers” mode, which is a whole lot less
convenient now that the check box has been removed from the main screen and put
into settings.  Since WSJT-X will recognize “mixed mode” QSOs and advance
accordingly I’m guessing that the Euro clones are still catching up or are too
disdainful of NA contest mode to fix this.
  
Speaking of fixing things I find several quirks in WSJT-X really frustrating. 
One is the auto turn off of Enable TX in FT8 immediately in the listen period
after RR73 or 73 despite NOT having that box checked in settings (works fine in
MSK144).  It is NOT a given on 6M that the other station will see your RR73 the
first time you send it and then you to have to scramble and waste the first
several seconds of the next period by forcing it to TX RR73 again (and again)
after you see them still sending TX3 (thereby cutting it down to one decode
chance instead of 2).  I’ve taken to immediately re-hitting the Enable TX as
soon as it goes off during the RX period so it’s ready to go again “just in
case” (sometimes several times while the QSB waxes and wanes).  Wonder how
many Qs are not logged on the other end because of this?  Maybe this could be
reprogrammed to auto turn back on again if the other station is still sending
TX3? 
 
Another is the random propensity to keep the old call in TX1 and the other
messages when you click on a new call in the left window to answer.  This one
happens maybe one out of 10 times, but when it does you can waste a lot of time
wondering why a strong station is not answering you before you realize it. 
I’ve seen it happen on the other end too when a station I’ve just finished
working calls me again with TX1.  And when you type in the call in the DX Window
to run a sked then hit Generate Standard Messages it doesn’t jump to TX1 like
it used to but stays on TX5.  You wind up starting the conversation with 73 if
you don’t notice and correct this! 

Gee listen to those complaints .. I suddenly realize that those quirks force me
to be aware and OPERATE rather than go into zombie drone mode like so many seem
to do and just let my computer do all the work!   At least there are no other
bands to try and get someone to QSY to using a free message in a single band
sprint!

73 de Bob2


Posted using 3830 Score Submittal Forms at: http://www.3830scores.com/


More information about the 3830 mailing list