Dwight,
I log everything to the WSJT-X log and periodically export the adi file to
Log4OM which is a Windows based program. There I can import the log to any of
my four call-sign logs.
When on DX-vacations I run a MacBook Pro and do the same thing - export that
file to Log4OM. Having said that I use MacLogger DX on the Apple MacBook Pro.
Log4OM populates many of the missing data elements such as grid when I run the
update utility. FYI - waving the flag for Log4OM ... it was developed by the
same guy who was the brains behind HRD. He sold HRD and later developed
Log4OM, which is simple but still has many basic features we seek in logging
programs. It is free - but many folks contribute to help keep its excellent
support going.
I know I can set up WSJT-X to interface with those logging programs, but I
choose to keep things simple and Murphy-proof as much as possible by doing the
extra steps. I realize too that logging programs may provide the missing grid
too, but ...
Danny W4/AH6FX - Virginia
On Saturday, April 13, 2019, 10:43:50 AM EDT, dgb wrote:
If it's a new call I haven't worked, my logger automatically looks the call in
qrz or if it's previously worked, it grabs it from the old log entry. What
logger are you using, mine is DXLabs?
73 Dwight NS9I
On 4/13/2019 9:13 AM, DX Jami via wsjt-devel wrote:
Dick,
Agree with you Dick. It is a big pain to log an "abbreviated" FT8 QSO which
omits the grid square. I used to use
http://www.levinecentral.com/ham/grid_square.php to look up missing grids.
With the grid square competition now history ... grids to some are less
important. Altho I am not a grid square collector - I always looked up the
missing grid square because my "logs" required them. Of course we can not log
an FT8 contact into the grid square database without a valid grid square.
However, we can log an FT8 exchange into our "FT8 contact" log without a grid.
It simply has no entry for the grid square data element. This is not a big
show stopper because my logging program updates certain missing fields when I
import the WSJT-X log.adi file.
But fundamentally Dick, when working as a DX station, I simply ignore
stations which do not go thru the entire FT8 exchange sequence because many of
them are QRMing my in-progress QSO and simply being rude, like I said
previously. I hear several people talk about speeding up FT8 exchanges by
eliminating certain parts of the FT8 sequences. For the most part, I reject
that argument. Maybe we all have a lot of time on our hands even if we are
working FT8, and working one more redundant DXCC entity is perhaps no big deal.
Have a good day.
Danny W4/AH6FX - Virignia
On Friday, April 12, 2019, 5:38:40 PM EDT, Richard Solomon
wrote:
As fast as FT8 is, there are folks who want a QSO completed faster.
It's a real pain, especially if I have to look up the guys call to get his
Grid Square. And, if it's a portable operation, it's even more difficult.
73, Dick, W1KSZ
Sent from OutlookFrom: Timothy Hickman
Sent: Friday, April 12, 2019 11:44 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] FT8 calling CQ I have noticed lately that when I
send CQ on FT8 A few stations start
their respond with the signal report not their grid square.
Is there something here I do not understand?
Tim
N3JON
___
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
