Hi Bill (ND0B) and all,
I've been away most of the time since your post, and just now finding
time to respond. You gave us a long list of ideas, with no evident
prioritization. You mentioned to me that you were "in the process of
learning C++ and QT by immersion". Of course you're the best judge of
your status in that respect, but keep in mind that it may take some time
to get up to speed.
A few specific comments:
> 1. Add situational awareness to the auto sequencer. Currently
> if the auto sequencer detects any message it will move to the next one
> in the sequence even if it does not make sense to do so. I plan to
> add logic (which is in the one I added to ISCAT in WSJT) so if you are
> currently sending TX1 you will move forward if RXing a TX1 or a TX2, etc.
Many have been using the auto-sequencing with MSK144 and have not found
it to do things that "do not make sense". A couple of things that I
might look at (but do not consider to be extremely important) are these:
a) If already sending a report, i.e. Tx2 or Tx3, allow it to replace the
numerical report by a higher number but not with a lower one.
b) If already sending 73, do not allow a "genStdMsgs()" call to
overwrite an entered-by-hand message that I have typed into one of the
Tx# fields.
> 2. Include MSK144 in the logic for “send 5 73’s after last RRR
> received” logic. This appears to be in place for some (one, ISCAT??)
> of the other protocols and it makes sense for it to be on MSK. I find
> myself clicking enable TX several times to make sure this effectively
> happens. I believe this should be enabled by the Disable TX after
> sending 73 click box.
> 3. Make the number of 73s sent after last RRR received
> configurable. It is currently the magic number 5 for the protocol(s)
> it is implemented for.
Motivation for these two seems weak to me. Why are you "clicking enable
TX several times"? I never do that. I don't want the program to
determine for me how many times to send 73; I'm quite capable of doing
that myself.
We're not attempting to make an automated QSO machine.
> 4. Implement Hamlib rotor control for Az and Hot A: / B: A left
> click on either of these would move the rotor to that direction
> a. Side project: Add Idiom Press and Green Heron controllers
> into Hamlib. Both of these are popular and an offshoot of the Hygain
> controller protocol that inexplicably did not have a facility for
> getting the current position from the controller. Both of these
> controllers added commands to position query but unfortunately is a
> subtly different manner.
> 5. Add a toggle (on right mouse click) between Hot A: and Hot B
> While it usually displays the right one to use sometimes the radiant is
> obviously on the other side. While the mental gymnastics is easy
> enough to convert it would be nice to just click… and then click again
> to move the rotor.
OK, I guess, but again the motivation for adding rotor control to WSJT-X
seems pretty weak to me. Few users have an antenna for 6 or 2 meters
with beamwidth small enough to be able to tell the difference between
pointing at Hot A, Hot B, or the direct path. It a tough call for me to
see any difference, even with my wide-spaced 4 x 2MXP28 array on 2m.
> 6. Make entry of DX Grid so it is not so persnickety. This is a
> simple one trimming leading or trailing white space off. I find that
> my usual way of getting ahold of the grid, copying it out of PJClient,
> often has a leading or lagging space, the entry box does not like this.
I've never found grid entry to be difficult. By all means, make it
better if you see how.
> 7. Add 60s sequences to the fast modes. I know you have had a
> discussion with Ged W8BYA about this, he would like it so he can
> operate diametrically opposed to some local high power EME stations,
> I find that
> a reasonable request. I would like it because I am planning some long
> term (24+ hour) runs and would like to increase the active time. With
> 15 second sequences approximately 4 seconds out of 60 are spent in
> changeover, with 30 second sequences 2 out of 60 and with 60 second
> sequences this is 1 second out of 60. This small but appreciable
> difference help up the chances of success on a long term run that is
> dependent on low probability events. Not by much but enough to make
> the effort worthwhile.
Nearly everyone uses 15s sequences, and it's a big advantage to have a
standard. We allowed for longer and shorter ones, mainly for testing
and specialty purposes.
One minute sequences? Surely the difference between a "sequencing time
loss" of 1/60 or 2/60 is not worth a big programming effort. For your
special 24-hour run, why not just extend it by another few minutes, to
make up the difference?
> 8. If it will fit add a “what the heck I am doing” letter to the
> CQ message for MSK144. This would be a single letter representing the
> T/R period, SH status and Contest Mode status. Clicking on this in an
> RXed CQ would change things to match. Because space is limited this
> would be done by convention using a table...
If you want to try this, I suggest playing with the existing capability
to send "CQ AA" through "CQ ZZ". Keep in mind, though, that these are
already used for such things as "CQ DX", "CQ EU", "CQ VT", etc., etc.
Again, my gut feeling is that we're better off using standard procedures
for everything but special-purpose tests (which of course you can
pre-arrange). For standard random-QSO operating, use 15 s sequences; no
Sh on 6m; do use Sh on 2m and higher; use contest mode during contests
(or by arrangement). Keep in simple.
Anyway, those are a few initial thoughts...
-- 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
