Hi Joe,
I know you have been very busy over the last few months, but wonder if you and/or any
of the developers have had a chance to give some thought to the points I raised after
my 6m EME DXpedition last fall.
You may also recall that I also raised a question in a separate November email about
how the AVERAGING function worked in Q65, and have included a copy of that email
again below for your convenience. My hope is that Q65 can be made even more effective
by incorporating some of these features. Thank you again for all your fantastic
development work, which essentially has made 6m EME DXpeditions viable!
A group of journalism students at The University of Montana are making a documentary
video including 6m EME, and I will be giving them a 6m EME demonstration using Q65 in
a few weeks. I have explained to them that 6m EME is only possible because of your
breakthrough innovative digital software, so you may also be hearing from them by email.
GL and VY 73, Lance
I read in an email from someone (perhaps Bill) while I was on the DXpedition that it
may not matter if I send a different report to people anyway because the AVERAGE is
built with weighting on the more recent sequences, and old sequences fade away. If
people were not copying until recently, the fact that my report changed probably
would not make that much difference.
I can see how the above averaging method makes sense for some applications that are
not subject to significant degradation from the addition of noise during prolonged
periods. Perhaps on UHF with circular polarization, or on ionospheric scatter, for
example, it is likely that some positive bits of information will be picked up over
time. However, on VHF EME, it is likely that signals WILL disappear, either due to
Faraday Rotation or the moon moving through nulls in a horizon-only station's antenna
pattern.
This morning I had a thought. Wouldn't it work better for VHF EME if the AVERAGES of
sequences on the various offsets were NOT changed after a message was decoded
(through reception of multiple partial sequences and/or help from CALL3.TXT)? Rather
than have a decoded message eroded by subsequent addition of noise to the AVERAGE, I
think it might be better to simply skip adding anything to the AVERAGE at that offset
location once the sequence was decoded. The only way it could be automatically
removed from the AVERAGE at that offset is if the station was sending RRR or RR73 or
73 or replaced if an even stronger decode from that station was received. Or I
suppose, if CLEAR AVG button were pressed.
As you know, on VHF EME, there is substantial QSB and Faraday Rotation can cause
signals to completely disappear for extended periods of time. It would be a pity if
all the information from an identified caller was lost because the decode in the
AVERAGE was degraded by the addition of noise during the period of QSB when the
changing polarity made the signal disappear. I just hate to see weak signals, that
were eventually identified, degraded away by the addition of noise when they undergo
entirely expected fades. Just a suggestion for a far smarter mind than mine to ponder...
On 11/16/2021 15:26:17, Joe Taylor wrote:
Hi Lance,
I have been looking forward to a summary of results from your heroic efforts in
French Polynesia. Many thanks for sending it!
I'll respond to the specific points you've raised after having some chance to think
them through, more thoroughly.
-- Joe, K1JT
On 11/13/2021 1:10 PM, Lance Collister, W7GJ wrote:
Hi Joe,
I wanted to share some observations from my 6m EME DXpeditions to FO/A and FO/M. I
appreciate that I am not a skilled operator of Q65 and that many of the calling
stations had never used Q65 before. However, I think there are some points worth
considering from the experience.
1. The overall results in terms of number of stations worked were not
substantially different from what can be achieved with similar effort using JT65A.
This may change as operators become more proficient and as Q65 evolves.
2. A big advantage of Q65 that I see as the DX station is that I can jump around
from station to station, and there is never any question as to whom is receiving
what because both callsigns are being sent.
3. As you pointed out before, asking stations to send reports only when they are
copying me defeats the averaging in Q65. It would be a great help if there were
some way to average the calls, but still indicate if no report, a report or RRR
was being sent.
4. Many stations expressed frustration that they saw my trace but could not decode
it. I THINK in most cases this we simply because I was calling someone other than
the station who was having trouble decoding.
5. I did decode some stations who were not in my CALL3.TXT file, which indicates
they had ever been worked before on 6m EME. That is a good sign, and an indication
of the ability of Q65 to decode unknown stations.
6. Unfortunately, we did have a number of issues with the FO/W7GJ callsign, which
I had not anticipated prior to the DXpedition. However, you apparently have fixed
that problem with WSJT-X Version 2.5.2. I was using this most recent version for
my operation from TX7MB but the compound callsign issue was not relevant by then.
Based on your recommendation, I will make sure that future operations do not use a
compound callsign.
6. Many times I had to double click on a trace to decode that station. I also
found that it was often necessary to double click on a trace with the proper
callsign entered in the DX CALL box. When operating from Rimatara (where I very
rarely had internet access), I was left to guess what calls might have moon and
might be calling on a given offset. At TX7MB (where I DID have real time internet
access), I was able to "cheat" the AP decoder by seeing who was calling where, and
madly enter the appropriate callsigns into the DX CALL box, hit ENTER to have them
looked up in CALL3.TXT to fill in their gridsquare, then double click on the
appropriate trace to see if it would decode. It the call DID decode, the program
would switch to calling that station, which was problematic...it may be that I
should have just hit the general DECODE button instead, but I don't know if that
provides the same degree of sensitivity as double clicking on a specific trace. I
didn't feel I had much free time during the DXpedition to experiment with various
options as the moon set for callers.
I guess my question is, how is "internet cheating" different from a pre-arranged
schedule, or the computer automatically looking through CALL3.TXT to see who is
calling on what frequency? It would certainly seem to me, that it is a more
suitable application for a computer than for the operator to try to manually input
a dozen or more calls into the DX CALL box, look them up in CALL3.TXT to provide
their gridsquares and then try to decode them by clicking on their trace before
moving on to try the next callsign. Certainly, when you have no internet access,
there is no good way to guess what the correct callsigns might be. It would seem
to me that having the computer try to search CALL3.TXT to determine who is on what
frequency would be a huge asset during a VHF DXpedition. And this does not take
away from the fact that the contact still has to be made in the normal way.
7. I don't know how long offsets of decoded stations are saved in the file, but I
understand that when I CLEAR AVG, they are gone. It would be great if the
CALL3.TXT search could automatically refresh the callers in the AVERAGE file. It
is a lot easier to know when to clear the average when you are just running with a
single station!
8. It may or may not have been a problem for others trying to decode me, but I was
having a problem trying to maintain the same report each time I was replying to a
caller. The issue is that as I would try to decode other callers during my
transmit sequence, I would then find that the report being sent would change, so I
would take valuable transmit time trying to adjust the report to what it had
originally been, according to my paper logbook. I am sure that screwed up things
even more as the report was being dialed. Then I noticed if I just changed to call
someone else, the report being sent to the previous person would be used. So I was
totally confused as to what to do about that. The whole issue was because I was
trying to decode other people and then return to the original person...or perhaps
begin replying to someone else.
I know the simply solution would be to return to just a standard EME signal report
indicating receipt of callsigns. That way there would be no problem with the
averaging, and no problem with having the values jumping around as you tried to
reply to other stations. But I appreciate the fact that you have designed
everything around the concept of sending some mystery report. Certainly for
one-on-one contacts, this seems to work very well. I wonder though, it it might
make sense for DXpeditions to always send R-00 or something (just like HF
DXpeditions always send 59)...that way callers would not have their average
degraded by changing signal reports. Maybe if the little report wheel was set to
-00, for example, it would bypass all the other report generation and just keep
the reports constant at -00, no matter what.
In conclusion, I think it was the right thing to try Q65 on the first VHF EME
DXpedition. I think there are ways to improve it so it will be more effective on
future VHF DXpeditions, making it a clear advantage over JT65A. Please understand
that my suggestions and observations are meant only in a constructive way, and I
greatly appreciate all the effort and amazing work that you and your team have
done with Q65 to this point. I hope that some of these comments are helpful to you
and look forward to seeing what novel ideas you come up with in the future!
GL and TNX again for making 6m EME possible! VY 73, Lance
--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR,
5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ,
TX7MB)
P.O. Box 73
Frenchtown, MT 59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7
Interested in 6m EME? Ask me about subscribing to the new Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
